Re-write NIP 89 to accommodate relays/dvms

[staab]

This is a just a draft/RFC. Most of the changes are just a re-write of what already was there, but I've added two new event kinds for DVMs and relays.

I added a new kind for DVMs for a few reasons:

• DVMs aren't really clients in the same way as software with a UI is. It would be valid for a client to specialize in generating kind 5300 requests and displaying kind 6300 events. If such a listing existed, there would be ambiguity about what was a DVM and what was a client, since "handling" here is overloaded.
• Implicit in the current (31990) spec is that DVMs need to publish a kind 10002 list of relays. But since multiple app handlers may be published by the same pubkey (which might belong to a normal user), we've now overloaded the kind 10002 relays to be both for personal use and service fulfillment.

I added a new kind for relays because:

• There has been some talk recently about addressing relays by pubkey rather than by url, since there may be multiple ways of addressing a single relay (clear net, onion, etc). A "relay handler" listing would be a first step toward enabling this.

Neither of the additions is supported yet, so this should wait until some DVMs and/or relays have implemented the changes. But I'm interested to see what people think.

[mikedilger]

Thank you for doing this. This or something like it is needed IMHO.

1. I like having relays advertise their endpoints in this way. A first (or second) step along a long path towards awesomeness.

2. I'm of the opinion that if we are going to change anyways, then applications should have keypairs and use normal ways to get their metadata and relays like 0 and 10002. That is, the difficulty of changing to a new keypair does not seem more difficult than adding code for this new 31991 event. Of course for 31990 events we must be aware that if they have metadata in the content, then we must presume the key is a user and so we cannot use their 0 or 10002 events, to be backwards compatible. But for new 31991, 31992 we could go the other way.

3. If One or more handler tags (web|ios|android|<other>) MUST be included then gossip can't participate. There is no URL where you can access gossip. Just change to "SHOULD".

4. We should document the other fields that people are using in 31990 (and now 31991, 31992) such as "r" (perhaps with "source" marker), "t" hashtags, "alt", etc, even though these are in other NIPs; at least show them in the example.

5. I've not quite understood the purpose of the "d" tag and it's reason to be random. Is it just to separate things in case the pubkey represents a person? This isn't re: your edit, just a question.

[mikedilger]

As for point 2, don't worry about the symmetry-breaking. God himself participates in symmetry breaking all throughout fundamental physics.

[staab]

Good feedback, I'll draft a new version today

[staab]

By "today", I of course mean today. Just published an update with all your suggested changes. I went ahead and bumped the kind numbers so that kind 31990 can continue to work as-is indefinitely. I also changed handlers to kind 1xxxx events, since I think you're right about the d tag — it's totally redundant if the application has a dedicated pubkey.

[mikedilger]

I think this is good. It adds new things, but is not a breaking change. Existing code that finds 11991 a tags in 31989 events should just be ignoring those since they don't start with 31990.

[mikedilger]

"... which allows users to select their preferred application handlers."

Since you can configure more than one handler per kind, "default" isn't right.

[staab]

Yeah, I'm not sure what to do with this. Multiple defaults could be ok though, clients would just need a heuristic for selecting one. They could just grab the first one, or they could compare the handler metadata to find the best option (based on platform for example).

[vitorpamplona]

@believethehype check these changes out

[fiatjaf]

@nostrband what do you think?

[nostrband]

Discovery of DVMs and Relays should be their own NIPs.

1. DVM practically needs it's own key, at least bcs it needs an inbox relay list. Apps don't need their own keys, managing keys for each app is a hurdle, and it's practically hard to prove an app release is published by a particular pubkey.
2. Apps need "handler url" (domain.com/<bech32>) that's supposed to be opened to view an existing event. DVM doesn't need handler url - it needs a relay list to accept new events (requests).

I'm sure there will be similar big differences btw Apps and Relays as well. I like the DVM/Relay discovery NIP, it just shouldn't be NIP-89.

[staab]

Closing this since DMV-specific stuff should be re-worked as part of the DVM discussion #1903 and the relay kind is adding something we don't really need right now.

[dtdannen]

Our new DVM spec proposal #1941 has proposed changing the DVM announcement kinds to be 31999 (for DVMs) and 11999 (for DVM Providers)