NIP-89 support via links

mikedilger commented

2024-09-28 20:55:09 +12:00

(Migrated from github.com)

Copy link

We can do NIP-89 support if the registered app handlers are websites.

mikedilger commented

2024-10-09 10:57:50 +13:00

(Migrated from github.com)

Copy link

Here is the plan, which is already underway

New type HandlerKey(pubkey, dtag)
New type Handler with all the details:
- HandlerKey, Metadata, kinds, up to 2 URLs (web+nevent & web+naddr)
Table of known Handlers
Always listen for 31989 recommendation events from everybody that we follow. Don't store these permanently, but when they flow in (if we don't already have that handler registered) trigger a process to fetch the 31990 event, registering the Handler in our table of possible handlers.
Table from kind -> (HandlerKey, bool) with duplicate keys enabled.
- We store every registered handler here, indexed by the kinds it supports, so that we can find all possible handlers for a kind.
- We also store the user's selected handler by setting the bool to 'true' if the user chose to enable this handler. They can enable multiple handlers for a single kind.
Create UI/UX method of users assigning handlers to event kinds. This will show the metadata of the handler. They should be able to select and deselect as many as they like for each kind.
When an event is rendered by the UI:
- Show links for all the enabled handlers in the menu.

This work proceeds on branch nip89

Here is the plan, which is already underway - [x] New type HandlerKey(pubkey, dtag) - [x] New type Handler with all the details: - HandlerKey, Metadata, kinds, up to 2 URLs (web+nevent & web+naddr) - [x] Table of known Handlers - [x] Always listen for 31989 recommendation events from everybody that we follow. Don't store these permanently, but when they flow in (if we don't already have that handler registered) trigger a process to fetch the 31990 event, registering the Handler in our table of possible handlers. - [x] Table from kind -> (HandlerKey, bool) with duplicate keys enabled. - We store every registered handler here, indexed by the kinds it supports, so that we can find all possible handlers for a kind. - We also store the user's selected handler by setting the bool to 'true' if the user chose to enable this handler. They can enable multiple handlers for a single kind. - [x] Create UI/UX method of users assigning handlers to event kinds. This will show the metadata of the handler. They should be able to select and deselect as many as they like for each kind. - [x] When an event is rendered by the UI: - [x] Show links for all the enabled handlers in the menu. This work proceeds on branch `nip89`

mikedilger commented

2024-10-10 15:27:37 +13:00

(Migrated from github.com)

Copy link

I think that every handler that comes in will be enabled by default, and the event menu will let you pick one. But also there will be a settings page to disable handlers that the user doesn't want. How's that?

mikedilger commented

2024-10-14 14:54:53 +13:00

(Migrated from github.com)

Copy link

Ok this is on unstable. All the handlers are made available (as well as njump.me, but really that should be published to nostr as a 31990 and 31989 recommendations and not have an unfair advantage).

Handlers flow in rather slowly, after 30 minutes of usage you should have some.

We don't yet have a place where users can disable handlers they don't like.

We don't yet have any way users can type in their own handlers.

We don't yet have any way users can publish their own handlers.

We don't yet have any way users can recommend handlers (theirs or others).

Ok this is on unstable. All the handlers are made available (as well as njump.me, but really that should be published to nostr as a 31990 and 31989 recommendations and not have an unfair advantage). Handlers flow in rather slowly, after 30 minutes of usage you should have some. We don't yet have a place where users can disable handlers they don't like. We don't yet have any way users can type in their own handlers. We don't yet have any way users can publish their own handlers. We don't yet have any way users can recommend handlers (theirs or others).

mikedilger commented

2024-10-16 12:43:57 +13:00

(Migrated from github.com)

Copy link

All of the original plan is done, but we need to do a bit more:

~~Remove njump.me.~~
~~Nudge dtonon to publish a 31990 for njump.me~~
Add a way to import a 31990 (naddr or id) for a handler that wasn't pointed to by your friends
Add a button to recommend a handler to your friends

All of the original plan is done, but we need to do a bit more: - [ ] ~~Remove njump.me.~~ - [ ] ~~Nudge dtonon to publish a 31990 for njump.me~~ - [x] Add a way to import a 31990 (naddr or id) for a handler that wasn't pointed to by your friends - [x] Add a button to recommend a handler to your friends

mikedilger commented

2024-12-03 09:54:39 +13:00

(Migrated from github.com)

Copy link

I've decided not to remove njump.me because advertising it via NIP-89 is tortorous (as it handles EVERY kind, AFAIK).

So this is done

I've decided not to remove njump.me because advertising it via NIP-89 is tortorous (as it handles EVERY kind, AFAIK). So this is done

No Branch/Tag specified