Avatar
sandwich
e771af0b05c8e95fcdf6feb3500544d2fb1ccd384788e9f490bb3ee28e8ed66f
author of nips that you use every day but have no idea exist. infamous shit-stirrer. former full-time nostr developer.

You can test myrelay.page before you build and deploy. You can even edit the configuration from the demo page. Note: Only works for wss (secured) relays.

https://relaypage.netlify.com/?url=wss://YOUR_RELAY

Replying to Avatar sandwich

Thanks! While that may appear to support many cases, it doesn't support the case where a relay isn't at root (in a subdirectory). Unset url case is handled here:

https://github.com/sandwichfarm/myrelay.page/blob/main/src/lib/core/MRP.ts#L119-L128

It additionally handles potential issue where someone attempts to connect to `wss` from `http` or vice-versa (would throw client-side errors) by clamping websocket/http SSL in alignment with browser limitations, which is implicitly compatible with onion.

Coracle stripped the line number hash on me `#L119-L128`

Thanks! While that may appear to support many cases, it doesn't support the case where a relay isn't at root (in a subdirectory). Unset url case is handled here:

https://github.com/sandwichfarm/myrelay.page/blob/main/src/lib/core/MRP.ts#L119-L128

It additionally handles potential issue where someone attempts to connect to `wss` from `http` or vice-versa (would throw client-side errors) by clamping websocket/http SSL in alignment with browser limitations, which is implicitly compatible with onion.

Ok, I think I understand. In general, you shouldn't have to set the URL. It handles detection and handles both ws (necessary for edge-cases and onion relays) and wss in the url setter. There's no harm in setting it manually ofc, but it's an unnecessary step.

Replying to Avatar PABLOF7z

what if... (and you probably know what I'm going to say...)

we publish these features on nostr.

Say for example I add "pin-note" support to nostr:npub1w0rthyjyp2f5gful0gm2500pwyxfrx93a85289xdz0sd6hyef33sh2cu4x

I publish a new event kind tagging my NIP-89 entry of Highlighter. Thus I signal that Highlighter supports that feature.

That way, say for example I later add "mute-list" support; I could just publish the event.

There is NO WAY someone, not even nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5 , will be able to keep up with all the clients and all the features we are all constantly pushing.

But we can push it to the edges, me as a developer, it is basically no extra work to publish an event indicating the new feature when I cut a new version.

nostr:nevent1qqspv6sma6atmdax3apc009rv4u9xqsa7zs5ejgdh8jdw4umassx83cppemhxue69uhkummn9ekx7mp0qgsdv8emcke7k3qqaldwv956tstu40ejg663gdsaayuuujs6pknw7jsrf43u3

yes.

It's the hole in the wall that gives you internets.

Replying to Avatar calle

Ok I've built this for fun and it's incredible.

A Cashu gateway: it's a normal Cashu user who has a Lightning node (or another Lightning payment backend). Everyone can act like a gateway as long as the mint supports ecash HTLCs (NUT-15).

If you as a Cashu user know of such a gateway, your wallet can send your Lightning payment request to it instead of to the mint.

The gateway responds with an amount (it can take a fee). If you agree, you send it ecash, and it pays your Lightning invoice. The process is atomic.

What does that mean? Let's think a little ahead and imagine this was deployed on a significant scale.

Even if the mint is full KYC for peg-in and peg-outs, a user could still make Lightning payments anonymously with the help of other users.

(!!! this alone would be huge !!!)

This would also enable us to make on-chain-only mints which opens up a whole new way of building mints (reserves could be in a multisig for example).

Crazy part: Gateways can be lazy and use custodial Lightning backends. The user doesn't care as long as the invoice gets paid.

Yes. That means you could use your Strike or Blink or LNbits account to act as a Gateway for a Cashu mint you like.

There could be many of crazy people like you. Nobody would ever know. Neither the mint. nor your LN service provider would notice. They all just see invoices.

It gets weirder. Gateways could use *another Cashu mint* as an LN backend. I know sounds like an inception nut but bare with me.

A user of mint M1 can ask a gateway of mint M1 to pay an invoice. The gateway could pay the invoice via mint M2 and receive ecash from M1 in return.

I always thought "you could run a mint for a thousand users on a Strike or a Blink backend without them even noticing the smallest thing".

Now I think you could probably run a mint for 100k users without them noticing, if there are other gateways handling payments for everyone.

Note: this is still experimental. Only paying works right now over the gateway, not receiving (more complicated).

The bast part though is that it doesn't require any Cashu protocol changes and the mints don't have to give you permission to do this.

It's all pretty nuts.

nostr:note142qdxj9dnp9nsmsuet9vw5pgtgtwj4e7vxv5qa0wvk8vdqy76cdqw3d5kr

gonna take a minute to crack that nut