I have the nip written; I’ll post it as soon as I get to the Airbnb tonight (traveling again today 😅)
It basically creates a nip-33 event with a d as the kind that you want managed pointing to uri handlers
When a user uses something like zapstr to handle 31337 kinds they can optionally create one of this events with d tag 31337 and zapstr’s pubkey, and zapstr’s pubkey has uri handler schemas.
When a user wants an app that can handle 31337 they can query for this new nip’s kind and #d 31337, discover zapstr’s pubkey and get all uri handlers for mobile, desktop, etc;
I am skeptical of an idea that users should post url handlers, but otherwise yes, having a 30k list with the pubkeys of apps I use for kind D which goes to d tag seems like a good idea to efficiently query 'which apps people I follow use to handle this kind'. And url handlers should go to the apps' profile so that only app could change them, otherwise malicious apps could insert random urls to my app list for other apps.
Thread collapsed
Why a replaceable event and not just normal events?
- Yesterday user B recommended app X for kind Z
- Today the same user B recommended app Y for kind Z
I guess the same reason why contact list is a single event, not each follow. Easier to manage, easier to withdraw your recommendation, easier to fetch w a single REQ - one spammer won't occupy all feed of recomms.
Thread collapsed
Thread collapsed
I love the idea, solving things in-protocol ftw
Thread collapsed