Replying to Avatar brugeman

Welcome Nostr App Manager: https://nostrapp.link

Nostr microapp ecosystem needs a smooth way to discover apps and switch between them.

With this app manager, you can paste a note id/npub or a link, and get a list of apps that support this event kind. The app can remember your app selection on the current device, and will redirect you straight to your app of choice next time.

It is already integrated into Nostr.Band - an 'open' button will send you to the saved app, and an 'open with' button will show you the list of apps.

You can manage your app settings, and soon will be able to publish your app list on Nostr to recommend apps to your followers. And then we'll get app discovery and web-of-trust checks on Nostr, and then we might slowly get rid of centralized app stores...

Credit for the idea goes to nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft. Obviously.

The app manager is open source, your feedback is welcome!

https://github.com/nostrband/nostr-app-manager

P.S. nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 is this something you had in mind with njump? Just saw it on twitter.

Now, full circle:

You see an unsupported event on your timeline on Damus (because one of your follows interacted with it replying with a note)

Now you see a note with some `alt` text that describes what that event you’re seeing is (ie, a song on #[3]​ )

And now you can click on that event on Damus and it will ask YOUR follows for which apps they know that can handle this unknown event kind.

You receive recommendations Damus open that other application (eg #[4]​ ) with the choose song selected.

Interoperability + discoverability across ALL event types.

Transparently.

Nostr IS the linked internet.

Floating links, like Xanadu Project.

Reply to this note

Please Login to reply.

Discussion

Exactly!

All I wanted was a thing that displayed nice link previews, but I am very interested in using that approach now for displaying links to the events in the generated HTML page.

Is this using that crazy Pablo idea of decentralized app recommendations?

Right now it has a hardcoded list of clients, we'll merge our ideas on how to do that crazy decentralised recommendations and then it will be implemented here.

What is the mechanism for recommendations? I'm working on relay reviews, maybe the same method could be used.

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.

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.

I love the idea, solving things in-protocol ftw