Correct, I want to configure a relay from the client, pay an invoice and have it deployed and ready to use. 

 Do you think this should be a new NIP to have this standardized? It does make sense. Probably having this as an http request makes more sense than some nostr event, since you may not be connected to anything yet?  

 HTTP with nip-98 sounds good, would love to see a spec for this kind of thing. 

 That's a good pro-http argument I didn't think about yet, thanks. 

And it's probably time to NIP this indeed.  

 I've always assumed this would be a good feature, and RT is in a good position code-wise to build it.  Since its been mentioned a bit lately, I will put some priority on it in the various roadmap planning Im doing.

nip98, has anyone actually used it?  It's a standard but I am curious if users will be wanting to sign for every api req, or instead with extra effort, get a jwt token to perform further calls (currently i use jwt, but it seems like people 'say' they prefer 98.. :) I agree, that it's probably easier to implement.

The flow could be something like:

98auth - POST /api/relays {name, desc ... duration of service}
returns: bolt invoice, id

GET un-auth - /api/invoices/id
returns paid/unpaid

and some further crud stuff like GET all, delete etc..

cc nostr:nprofile1qqsrx4k7vxeev3unrn5ty9qt9w4cxlsgzrqw752mh6fduqjgqs9chhgppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg3waehxw309ahx7um5wgh8w6twv5hsxct838 nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspz3mhxue69uhhyetvv9ujuerpd46hxtnfduq35amnwvaz7tmjv4kxz7fwwajhxar9wfhxyarr9e3k7mgprdmhxue69uhksmmyd33x7epwvdhhyctrd3jjuar0dak8x6lmt90, any thoughts on nip98?

 

 We use nip98 in nsec.app and npub.pro, definitely prefer over jwt 

 Please do it and we'll be offering it in npub.pro 

 🫡