NIP-17 (old 24) Sealed Gift-Wrapped Messages for Private DMs and Small Group Chats

[vitorpamplona]

This PR creates a new private messaging scheme from the learnings of many past proposals, including NIP-44, NIP-59, NIP-24, NIP-103, NIP-76.

It brings their best ideas together in a slightly different approach that seems to be better for privacy.

Read here: NIP-17

[staab]

This is really nice, I fully support it. The main change I would make is changing the name of the inner event (as @mikedilger suggested it shouldn't be "Event") from "Gossip" (which is a verb) to "Rumor".

My other complaint may be out of scope, but this nip absolutely won't work for large groups, since the data requirement is O(participants * messages). Fine for a group of 10 people, absurd for a group of 10,000 people. I think it would be reasonably simple to support such a use case by adding invitations back in, but that's probably best handled as a separate concern in a new NIP.

[v0l]

Nice! But very long haha

[vitorpamplona]

Nice! But very long haha

I had a lot of trouble dumbing this down even for myself...

[vitorpamplona]

Fine for a group of 10 people, absurd for a group of 10,000 people

10,000 events from a phone will be hard. But I can actually see it working for a substack-type of service where the author periodically sends a letter to 100K+ people.

[fiatjaf]

@mikedilger

[nanikamado]

Omission of subject should not be interpreted as "same as above" imo. What if the original subject was "subject a", person B changed it to "subject b", and a second later person C posted a new message without a subject tag? Clients would interpret the subject of C's post as "subject b", but C would most likely not have received B's event at the time they sent the post.

I prefer interpreting the omission as "the default subject of the group", which is something like the general or random channel of Discord or Slack.

[vitorpamplona]

So, you are advocating to duplicate subject in all messages to keep the room name? If my group's subject is just "Family", do people need to always send ["subject", "Family"] to keep it?

[nanikamado]

Is the subject supposed to be the name of the group? I thought it was something like the subject of email in a mailing list or the name of a channel in a Discord server.

[vitorpamplona]

Is the subject supposed to be the name of the group?

It's whatever users want to use to identify the group or the current topic of the conversation. It could change frequently or not. It's akin to a WhatsApp group name. Sometimes people change it for the fun of it. Others are more serious about it. Subject should not be a serious commitment or anchor to anything. The participant list is the primary anchor. If that changes, a new group is created.

[nanikamado]

I see.

[haorendashu]

I think the Group DMs should exist a Definition event, just like Badge Definition event.

With the Definition event, user can find all the members in this group dm and needn't create a new group dm after change the member.

Of course some group dm info such as Title, description can config by the Definition event.

[vitorpamplona]

Yep, the issue is that then you have to manage who gets to change that definition event and what to do with the messages when you add or remove people into the group. It gets very complicated, very quickly. And, in many solutions, privacy takes a hit.

@staab tested a few different ways to do it and I think the latest is #875.

This version is just the simplest way to do Group DMs that any client can easily implement. Think about this as sending an email to multiple receivers and #875 as an email mailing list. The two can and will exist separately.

[vitorpamplona]

This is ready to merge. We can always improve the text later.

[tyiu]

I admittedly did not read any of the resolved comments because there's too many of them and they span too far back through several revisions. But I left two comments that stuck out at me from my first read of the current revision of the spec.

[staab]

Let's merge this baby, it's long past time.