Yessssss! Finally it's here. Such a needed thing to incentivise larger relays to run, but also to show how lightning is the perfect fit as the payment layer.
A couple thoughts as I read this.
1. What are your thoughts on using LSAT since it's tied into the 402 http status code? Then you can pass those credentials around to other people while the relay keeps track of the remaining credits. I can then share it with my family or resell on a secondary (nostr based) market.
2. With a bunch of these web clients coming out for Nostr would you reconsider webln as a way for them to interact with ZBDs extension like you had before?
Awesome article even more awesome developments. Looking forward to the next!
In my opinion the ideas/problems you laid out above don't exist in a nostr-first world. A client does not talk to relays using HTTP so LSATs don't make a ton of sense. All communication is done through nostr events, so the `pay me for access` messaging back and forth should be entirely on nostr itself.
I'd prefer a set of NIPs that specify an event such that once a client connects to a paid relay, the relay returns an event with the bolt11 invoice, and the client app allows the user to handle it whatever way they want. Once paid the relay sends another success event and the client can now connect / post / fetch events. LSATs have no bearing here imo.
The ZBD Browser Extension currently handles invoices and LNURL pays/withdraws and LN Addresses directly by clicking on it from a web page. This is built-in, there's no need for magic or additional standards here. Most web clients are displaying the QR codes or a button to pay/withdraw. We already handle those, and its natively handled. We have also received 0 requests for WebLN support in general, so we do not see the real value in it atm.
> A client does not talk to relays using HTTP so LSATs don't make a ton of sense.
Ah you're right, web sockets don't use the same status codes. So ye the credentials could themselves be part of the relay / pub key relationship. Fair point thanks.
> We have also received 0 requests for WebLN support in general, so we do not see the real value in it atm.
I've got my NOSTREAM relay up and running and would like to enable pay-per-relay. While this post gives a general sense of how to set it up. I can't seem to find a detailed set of instructions especially the zebedee side of things. Registered for an API key but that seems stuck waiting on approval.
Can you provide a links to specific docs? Thanks for all the hard work on this. Anxious to try it out.
For those seeking an invite to the ZeBeDee dev program. I found you needed to DM Andre directly. There is a mention of this in his article that I'd missed.
Yessssss! Finally it's here. Such a needed thing to incentivise larger relays to run, but also to show how lightning is the perfect fit as the payment layer.
A couple thoughts as I read this.
1. What are your thoughts on using LSAT since it's tied into the 402 http status code? Then you can pass those credentials around to other people while the relay keeps track of the remaining credits. I can then share it with my family or resell on a secondary (nostr based) market.
2. With a bunch of these web clients coming out for Nostr would you reconsider webln as a way for them to interact with ZBDs extension like you had before?
Awesome article even more awesome developments. Looking forward to the next!
Thanks Johns! Always looking to innovate.
In my opinion the ideas/problems you laid out above don't exist in a nostr-first world. A client does not talk to relays using HTTP so LSATs don't make a ton of sense. All communication is done through nostr events, so the `pay me for access` messaging back and forth should be entirely on nostr itself.
I'd prefer a set of NIPs that specify an event such that once a client connects to a paid relay, the relay returns an event with the bolt11 invoice, and the client app allows the user to handle it whatever way they want. Once paid the relay sends another success event and the client can now connect / post / fetch events. LSATs have no bearing here imo.
The ZBD Browser Extension currently handles invoices and LNURL pays/withdraws and LN Addresses directly by clicking on it from a web page. This is built-in, there's no need for magic or additional standards here. Most web clients are displaying the QR codes or a button to pay/withdraw. We already handle those, and its natively handled. We have also received 0 requests for WebLN support in general, so we do not see the real value in it atm.
> A client does not talk to relays using HTTP so LSATs don't make a ton of sense.
Ah you're right, web sockets don't use the same status codes. So ye the credentials could themselves be part of the relay / pub key relationship. Fair point thanks.
> We have also received 0 requests for WebLN support in general, so we do not see the real value in it atm.
I thought we were good. You think I'm no one? 🥲
I've got my NOSTREAM relay up and running and would like to enable pay-per-relay. While this post gives a general sense of how to set it up. I can't seem to find a detailed set of instructions especially the zebedee side of things. Registered for an API key but that seems stuck waiting on approval.
Can you provide a links to specific docs? Thanks for all the hard work on this. Anxious to try it out.
For those seeking an invite to the ZeBeDee dev program. I found you needed to DM Andre directly. There is a mention of this in his article that I'd missed.
Thank you for this article! I ended up getting my private relay setup at https://relay.bigred.social .