I feel like there needs to be a custom UI element (maybe could use a NIP?) for paid relays that simply utilizes how ZAPs and NPUBs already work in Nostr.

Currently the process is as follows:

• Go to paid relay list (hopefully in your client, but probably not)

• Click to go to paid relay website

• Pay a btcpay or lnbits invoice

• Go back to client

• Copy NPUB

• Back to site

• Paste NPUB

• Copy WSS://address

• Back to client

• Paste WSS://address

• Connect

• Rinse and repeat for every relay

Now imagine this is built right into a client relay list, using zaps exactly as they are:

• Go to list, see relays & prices

• Hit zap button with set amount

• Relay gets proof of payment, plus pubkey, relay is auto added to connected list, relay auto whitelists your NPUB

... done.

You could connect to 5 paid relays in practically 10 seconds this way. And because this is all directly in Nostr, relays could DM or maybe have a custom notification on the relay page itself for needing to pay for another month/year of subscription.

Just seems like all of the pieces are already there, and this would not be a difficult script to just package this process up into a "one click, connect" experience. 🤔

Reply to this note

Please Login to reply.

Discussion

That's a good suggestion. The client can create a relay marketplace with proper integration, and we can do it without the need for NIP.

Agreed. There’s no reason for the payment flow to be outside of the nostr system.

My recommendation:

- paid relay allows minimal usage, for example to DM a specific relay bot

- relay bot offers up invoice

- once invoice is paid, relay allows upgraded access

The relay-bot system also offers a way for the relay to inform you when it’s time to pay up. The relay bot can tell you how much credit/bandwidth you have left, etc.

Here is a #damus paid relay feature request I updated. I empathize with the idea of not having to jump through the hoops #[2]​ outlined.

Probably request needs some more work.

https://github.com/damus-io/damus/issues/405

#[5]​ what do you think?

I support it! We’ll implement whatever clients decide to support.

For now, we do support the pubkey param on our invoice page so clients could at least page that on to the invoice URL to avoid the first back and forth. https://nostr.wine/invoices?pubkey=npub18kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sks0mx5sz

Add instead of page*

I want this and a similar process for media uploads, though that will be a bit more complex and needs an API defined. Similarly for other auxiliaries like nostr nests, badge creation and acceptance. To feel integrated, we need to define the APIs for the service connections and implement in clients. But also need to avoid half baked solutions and consider how to address as though they are extensions, and how to do discovery with centralization avoidance.

On nostr relays, and other services, I feel this needs to make onramping to sats as seamless as possible, to avoid nostr appearing to be a bitcoin only app

Just had a thought, that a Nostr marketplace basically does both of these at once. Just make the relay list a specifically tagged relay market, and image hosting one built right into the post interface. But they could both be the same “events” or “products” hosted on the individual user or account market page as well.

A marketplace is very much needed and can help with discovery for sure.

This brings up the need to handle different offering types.

- Physical goods transferred out of band

- Digital with links to retrieve

- Ongoing digital services with configurations and expirations.

Ongoing services like relays and file uploads need to offer "top-up" support to keep going, reminders of upcoming expiration, and the abilityforr people to buy and gift a service to others. Then who gets the reminder of expiration.. The gift giver or the recipient? Nuances to work out on that platform for sure

Great idea!

If someone solves this we can do the same thing for translation services like at https://nokyctranslate.com, just instead of relay address we would send back a private API Key