Add DM relays to nip 65

[staab]

No description provided.

[fiatjaf]

If I understood correctly this is great, let's ship it.

[arthurfranca]

Came to the conclusion that users don't need dm relays. Simply pick good read relays that also treat DMs well (NIP-42).

Besides that, two lists and write/outbox usage overlap contribute to make things more complex for little gain.

[dluvian]

You forgot to add kind 10050 to the Event Kinds table

[vitorpamplona]

I am good with this. I don't really know why it's using two kinds but sure.

[staab]

Came to the conclusion that users don't need dm relays. Simply pick good read relays that also treat DMs well (NIP-42).

Besides that, two lists and write/outbox usage overlap contribute to make things more complex for little gain.

I actually agree with this. The benefits of a separate list is that you can avoid broadcasting messages to more relays than necessary, enhancing privacy. The downside is that clients that don't support the new list won't know to look elsewhere for DMs, and will start missing them. @fiatjaf can you make the case for this change improving deliverability rather than making it worse?

[fiatjaf]

I've been talking about using specific DM relays for many months, and my entire hope for NIP-44 + gift-wraps was that we would change to using specific DM relays.

As far as I know only Amethyst and Coracle implement the new DM scheme and it isn't specified anywhere so this shouldn't break anything for NIP-17.

[staab]

Let's add the new relay kind to NIP 17 instead @vitorpamplona. Where to save hints should be defined by the relevant NIP, not added to NIP 65. That limits the blast radius, because otherwise you end up with tricky compatibility issues like the one I mentioned.

[fiatjaf]

@arthurfranca relays should be able to specialize. We gain literally nothing from just merging together two entirely different functions in the same group of relays. If we can specialize, why not? Clients can easily automate the creation of these lists.

Also the presence of the new kind serves as a signal that this user is ready to accept NIP-17 DMs, otherwise the user probably shouldn't even be contacted.

[staab]

Also the presence of the new kind serves as a signal that this user is ready to accept NIP-17 DMs, otherwise the user probably shouldn't even be contacted.

This is a great idea

[vitorpamplona]

ohh, so the new event kind is for DMs only and not any GiftWrap? I don't think I see a difference between DMs and any other GiftWrap payload in terms of privacy or which relay to use. They are all private.

[staab]

NIP 87 uses gift wrap, but they're not addressed to users, but shared keys, so there wouldn't ever be a NIP 65 available. Instead, the group meta's relays should be used. That's a pretty good example of appropriate relay selection being defined in the relevant NIP.

[vitorpamplona]

Cool I am going to add this over there.

But here's the catch, for DMs, there is no Outbox. Everything is an inbox.

[fiatjaf]

But here's the catch, for DMs, there is no Outbox. Everything is an inbox.

Good point.

Everything is an inbox and you can just connect to that single relay and also publish your outgoing DMs to it as well as access everything you receive from it.

A specialized relay could also allow you to delete directly from it even though you're not the immediate author of the events. It becomes your personal inbox.

[vitorpamplona]

added: https://github.com/nostr-protocol/nips/pull/686/files

[arthurfranca]

relays should be able to specialize. We gain literally nothing from just merging together two entirely different functions in the same group of relays. If we can specialize, why not? Clients can easily automate the creation of these lists.

Just that don't see much to specialize in when relaying DMs compared to what a read relay already provides rather than requiring AUTH when client requests gift-wraps (or kind:4).

Also the presence of the new kind serves as a signal that this user is ready to accept NIP-17 DMs

The user can accept NIP-17 dms if it is currently using a client that supports it. A list won't guarantee anything imo. It depends solely on NIP-17 adoption ratio.

[vitorpamplona]

Just that don't see much to specialize in when relaying DMs compared to what a read relay already provides rather than requiring AUTH when client requests gift-wraps (or kind:4).

I think the main issue is really the difference between a public read (no auth) and a private inbox (authed). Authed relays can do both read and inbox. Non-authed relays should only do reads (only public events).

[vitorpamplona]

Actually, it's about access by third parties:

Public read (anyone can download events that p-tagged you). Public reads are used when the author's write doesn't have an event. In those cases, the client should start looking at other relays from the p-tag list. This type of relay must remain open/unauthed. This type can opt to accept events by or about a given public key. And for privacy, it can opt to not return DMs or GiftWraps until the connection is authed by the author.

Private inbox relays require auth to download any event: They are not supposed to be used by third parties to find posts. They can accept posts by an author or where the author is p-tagged, but they do not respond unless authed.

While read can be seen as a superset of inbox, there might be use cases where the author doesn't want to allow the download of public events (Zaps for instance).

So, in practice, the two relay types intersect, but each has something unique going for them.