search

nostr-protocol / nips

Nostr Implementation Possibilities
2.4k stars 583 forks source link

Typed URI schemes. #1539

Open vitorpamplona opened 1 month ago

vitorpamplona commented 1 month ago

I am trying to figure out a way to allow micro clients to register only the event types they support on Android/iOS.

Then if we use these URIs when opening external events, a more appropriate client list can be recommended by the OS.

Today, all the dozens of clients pop up and the OS can only have one of them as the default for the nostr: URI.

The more we go into the direction of mini and micro clients, the more we will need something like this.

alexgleason commented 1 month ago

I am kind of against this. IF we do it, we should use nostr+<kind>: eg nostr+1: as the protocol, so it at least matches the existing URI standard of web+ scheme prefix. This would improve parsing sanity going from .startsWith('nostr') to .split('+')[0] == 'nostr'. I think this is a requirement for this scheme to make sense.

It's very uncommon for numbers to be in the protocol part of a URI, and very uncommon to have dynamic protocol schemes at all. But at least with web+ there's some prior art to go by.

The reason I think we shouldn't do it is because it's bloat. It's unfortunate that deep links are so limited, and that it ultimately harms UX, but this is not the first time I've encountered this problem. I am more annoyed that Apple and Google don't improve their system, and then force us to make decisions like this or punt the problem to the user. It's not a problem with Nostr URIs themselves.

These URIs introduce a new validation burden. What do you do if the kind in the nostr+ prefix doesn't match the kind in the naddr or nevent data? Do you take the protocol kind and ignore the bech32 kind, or take the bech32 kind and ignore the protocol kind? When you route the protocol in your client, are you already expecting to render a specific kind but then accidentally render a different kind? This will create a burden on developers and inconsistencies between clients. This is the biggest reason I think we shouldn't do it.

vitorpamplona commented 1 month ago

Updated to add the +

What do you do if the kind in the nostr+ prefix doesn't match the kind in the naddr or nevent data?

Just ignore it just like you would in the regular nostr: call. The type in the scheme should be understood exactly like a relay hint. It could be correct, but you can't rely on it for anything.

But agree: Apple and Google suck at this. Although I don't see a much better picture on the desktops.