Here’s a early draft of a possible way we can define Nostr services in a common way. It has a lot of gaps, however I'd like to start by gather use-cases we want to support.

Ideally other services can include premium relays, CDNs, trending APIs, POW, etc.

Early feedback welcome. Can create a formal PR/Issue for this, so we can collaborate more easily.

CC

#[0]

#[1]

#[2]

#[3]

#[4]

https://gist.github.com/blakejakopovic/eb82a2e417fd0846f2afcfc380988520

Reply to this note

Please Login to reply.

Discussion

Left some comments. Looks promising! 🐶🐾🫡

Hot off the press, this one is kind of related, but focused on the HTTP Auth flow.

https://gist.github.com/blakejakopovic/fe384b8fd97231ece267bf264eb466ef

Good idea 🤝

Maybe we end up with some openapi (swagger) style definition. May be reinventing the wheel - or perhaps greenfield makes sense.

A process to automatically obtain an API key is pretty great - it would need to enable payments.

Sounds like it could be simple… do a handshake, client sends API Key and a ln invoice, invoice prompts user and they can pay… done?

If API key can be replaced with a pubkey + NIP-98, then this approach can work, and provide possible payment options.

The image was a POC for paid services manager built into Damus.

https://gist.github.com/blakejakopovic/fe384b8fd97231ece267bf264eb466ef

Now I’m going to go read about NIP-98!

POC looks super cool

Interesting! Wouldn’t need to hardcode in app, the client could browse or record ones it sees ? 🤔 very cool.

I like the idea, but this is looking so bloated.

Help me simplify it 🙂

So far I have:

* endpoint

* auth methods accepted

* input transform/options

* possible input validation

* output success/error check

* output value transform/mapping

* optional payment offers or info

I think many services can be defined with those basics. Maybe openapi or some common validation library for forms can have parts stolen.

I would like to participate, it is something I have been trying for months (a consensus).

On the other hand, I don't think we should set up something sophisticated, but rather base ourselves on what is already there, NIP98, NIP05, NIP94, NIP51, to adapt our services. We have to use ephemeral notes to communicate some things and normal notes for others, I don't see any more complication. I have applied this philosophy in my API with the intention that people can implement it themselves, do forks, etc.