your clients don't support NIP-31 then look at how coracle, which also doesn't support torrents, renders this https://image.nostr.build/d28758f77a894d171b0e81d5751cdb19e9a0e7cbd1cab2ad84917321cae09e37.png
add in NIP-89 support and now coracle can even open a client that can handle that unknown kind https://video.nostr.build/6b9c22f94ccf9d8bbc7c7873bf7caa1e1636ff97ed3fa4fea7f2bab2d9e6eae6.mp4
Regarding the suggested options to open this event, did Jon provide those, or are they provided/recommended by you Pablo?
None of the above. They client asks around for handlers (and might or might not store / know about your favorite apps for it). afaik
> They client asks around for handlers Who does the client ask?
Users in your network.
Only just realized this when rereading the nip. That's not ideal, mmmm. It incentivizes apps to publicly add their app tags to events the user is publishing, without them knowing.
Does it? The client tag just helps people know what client published the note, which is a different thing from knowing how best to read the note, which is what handlers are for.
So you'd only look at kind 31989's published by users you know?
That's an extra action for the users to take (which very few currently do). @Zapstore might be the kind of app where it feels more natural for users to publicly recommend handlers.
Coracle looks for recommendations from people you follow, and surfaces any handlers that are recommended. This is all automatic, and shows up at the bottom of a note in a drop down you can use to open any recommended handler. It is an extra step, but I'm not sure how you could get it shorter.
We have been talking about adding this tag only to follow list updates on a temporary basis to try to track down the lost lists problem. We don’t believe it is a Nos problem bc we’re only seeing partial lost lists. In general I don’t think it’s a good idea to add these tags w/o user permission but the Nostr ecosystem also needs to stop losing user follow lists. If all the clients added the tag temporarily we could likely pinpoint the issue and stop frustrating users and also wasting dev time trying to figure out if it’s our respective app.
Hehe yep, I get why you'd do that. Follow lists are a mess though, I like the proposal to instead start using individual events for it: nostr:nevent1qvzqqqqqqypzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqyghwumn8ghj7mn0wd68ytnvv9hxgtcpr3mhxue69uhhg6r9vd5hgctyv4kzumn0wd68yvfwvdhk6tcqyqjwewmrj4yz58jnu87p5fevr4f8lwulavks4jkmwegyrfjnherqq6v33px
relays see NIP-89
Does this sound right: it can either be: 1) an application that publishes (i.e. self-ceritifies) that it can handle a specific event/kind type, and/or 2) a recommendation from a user
yes and provides a URL (which could be a deep link) to handle the bech32, so when, e.g.. coracle, wants to open a specific event, it knows what URL to use to open that specific event on the app.