Oddbean new post about | logout
 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 
 Yeah @rabble has another proposal somewhere as well on this topic.  
 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. 
 So this pointer / link could direct to:
1) web app, and/or
2) iOS app store, and/or
3) zap.store deeplink? 
 hardcoding is an anti-pattern in nostr 
 Freakin' beautiful to see this in the wild 
 really really great job executing that UX