Oddbean new post about login | logout > 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). @zap.store 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.