Typed schemes.

[vitorpamplona]

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.

[staab]

I think this makes sense. It has the nice side benefit of allowing entity embeds in content to include the event kind. It will require parsers to be updated, but in a pretty minimal way. And it gives us infinite content-type granularity.

[pablof7z]

Great idea

[alexgleason]

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]

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.