Replies (38)
They would have to track who I'm talking to in order to censor certain conversations, the public IDs are opaque. Totally possible, but not straightforward.
Another privacy counterpoint: today, clients see ALL you decrypted messages. This would potentially reduce how many messages a client decrypts. Moot in terms of trust with a client, but it does reduce how much plaintext gets slung around.
The biggest benefit to this IMO you didn't mention, which is UX — downloading and decrypting 100s of messages in the background tanks user bandwidth usage, battery usage, and perceived performance.
Otherwise, good points.
I listed the UX gains as well. I just don't think they matter that much for clients that can correctly paginate by time. They will need to assemble the other chats anyway.. so... downloading the extra rooms in the same time-window, to me, is not that big of a deal.
Nope.
This is just more complicated than the original DMs that revealed who was messaging who.
That's retarded.
But I'm also retarded... So... 🤷♂️
Sounds like you both need to review what I have done with group chats in Nymchat 😅
Ephemeral keys used for every message. Each key is saved to a time-bucketed self-addressed gift wrap. Your next key is inside the encrypted rumor sent to participants.
The only real possible metadata leak is that there is a REQ to each key to check for any messages to them, so someone monitoring the relay could infer these sets of pubkeys are linked to this IP, but that's it. You could of course shard the REQ and use proxy to mitigate that.
DMs aren't used all that much right now, and maybe clients could only request all DMs within the last X amount of time by default to reduce the amount of bandwidth, only requesting older DMs if the user scrolls up and requests to "load previous" or "search for previous." That would help with the bandwidth considerations.
The benefits for spam mitigation is what I am more interested in. Maybe not a terrible tradeoff.
Are we basically admitting that NIP-17 DMs are the best we're going to get for the time being, and we should just make them as good as they can be. I know there have been some struggles getting MLS to play nice with Nostr, especially for group chats.
I think I more or less understand how your proposal would work, as
@Vitor Pamplona explained it. I assume that since you still don't see the pubkey of the sender, each side of a given conversation would have its own public conversation code?
Why should nip17 be used now that we have marmot?
Does nip17 have any significant benefit over marmot?
I'm still optimistic for other schemes in the long term, but nip 17 is pretty well supported and this is a very easy and relatively compatible lift. And no actually, the same key would be used to sign events no matter who sent the message (hence
@Vitor Pamplona's point about attackers being able to rewrite history, which is significant). For the record, I don't exactly know where I fall yet.
This is just a patch to slightly improve NIP 17. Eventually I'm sure some other messaging scheme will get enough adoption to matter, but none of them knock it out of the park yet.
Marmot depends on reliable message ordering/completeness, which nostr doesn't provide. So it's not only more complicated, it's unsolved so far.
My vote is to always push the boundaries of what is possible with privacy and censorship resistance, and to stay inspirational in that regard.
That is our niche.
That is our thing.
Nobody else cares as much about censorship resistance as we do, but there are lots of people who care about making reasonable engineering trade-offs in software, to gain users.
I want to make the best tools. Not the tools for the masses.
Historical safety is the biggest problem here, IMO. I can envision some NIP-17 use cases where it is of paramount importance. It's tough, but I think I'd vote this proposal down.
Here is the current breakdown of my relay by event type. I don't know if my relay is representative, but gift wraps are by far the most popular event type that I am hosting.
It is possible that NIP-17 as it is currently running is the most popular event type on nostr that my relay sees.
You could argue that this means it is ripe for optimization. On the other hand, you could ask why mess with what is obviously working.
The reduction of NIP-17’s metadata footprint represents a significant optimization for network scalability—a foresight often missed by human assessment.
Yeah, it's one of my main concerns for sure. Changing the past creates whole new attack vectors for scammers.
Well the NIP 17 is probably of not much interest
don't know much about the technical details of nostr. but it sounds like the original one should be kept, but add new functions (if it is not already there) to allow the sender to tag it with deleted and a pointer to a possible new note. And then when the UI sees the tag, it should automatically hide the deleted note but leave a hard-to-access button to reveal the "deleted" message.
I would say that when this tradeoff is made, it will be time to move on some self hosted private chat server with few friends and stick there. Non private things in this time are worthless.
We're getting there
govs kill people because of metadata
don't fuck with the metadata privacy do it as another alternative NIP or some other way so that there's a choice
Would rate limit nullifiers help partially?
IMO a bad idea. Metadata correlation is a gold mine for network snoopers and can bite our ases in the least expected moment
Bad idea, imho. Not as bad as NIP-04, but getting closer. Also, it will make nip 17 DM traffic distinguishable from all other gift wrap traffic, which, from my point of view, really harms metadata protection. Currently, I don’t consider nip 17 private, but this would make it much worse. Have you read my article on this subject?
could you split it:
🔒 Private DM (NIP‑17a) — strongest privacy, highest bandwidth
⚡ Fast DM (NIP‑17b) — lower privacy, lower bandwidth
Client has one sub for all gift wraps regardless of which conversation it's in, downloading is happening anyway? I don't see how this helps anything
We use auth relays for dms to filter spam
I'm an ignorant pleb, but why change an existant NIP so drastically instead of introducing a new one for this spec? Seems to me that retroactive changes are dangerous, even if the old spec was shitty.
This is a breaking change... Why are y'all not creating an entirely new nip for this since it seems like the scheme is entirely new?
Nope, just make messages encrypted, make the metadata minimized so that nobody can build a social graph, and make relays route the messages in DM's and discard them immediately after sending and receiving messages and files.
This idea comes from the SimpleX's design, so if you decide to follow the same footsteps of what SimpleX chat is doing, then you are welcome. However, I say the proposal is just, too invasive. Metadata can be used against you, by law and by court. I just give it a hard pass.
A new nip should be made, not completely change nip17. Are we out of cool nip numbers or something? Also, I've added support for deleting NIP17 by p-tag to my nip86 endpoint, as requested by
@Vitor Pamplona . This helps with bandwidth and spam, and you can also delete by timestamp.. The only reason nip17 seems broken to most is the huge IOS clients did not implement it. Other than that it is has a lot of current usage.. Muddling the nip this late in the game seems unwise. Cc
@fiatjafThings will be muddled in any way or another. Making a new NIP doesn't really change that. You're just moving the muddling to another department, but you'll have to deal with it anyway.
It's like making a new kind with a different content-type, or a new "version". It's all cosmetics for "making a new protocol". Essentially it all comes down to creating new work for everybody to maintain everything at the same time and wrap their heads around the new stuff.
In this case I think it is worth it.
But honestly, I just wish someone did something different. Would be nice to have a more specialized and more efficient Nostr-like protocol around "chat servers" (as opposed to Nostr relays). Reuse Nostr identities, use Nostr for signaling, I don't know, but don't send the actual messages as Nostr events to relays, that is ugly.
Yeah, IRC is pretty neat for large chats. Twitch still uses it and its spec keeps getting better. I added nostr registration to it. It uses DMs (4 or 17) but only once to deliver the registration link. (Instead if the standard, email based IRC nickserv).
I kinda like NIP17, I suppose we can just move it to a new nip if this one merges over top.
That sounds like a big problem
IRC is nice, but doesn't use Nostr identities and chats can't migrate across servers. Insert these two elements and you get NIP-29.
Still, that isn't what I was dreaming about for 1-on-1 DMs, but maybe variations of NIP-17 is the best we'll ever get anyway.
It does use nostr identity though, I can be sure someone I'm chatting in IRC is the same person I chat with in nostr, with just a single registration flow. (Obviously I have to trust the IRC operator though, who is me.) Nostr can be used this way, but only if we keep around specs like NIP17 so that someone can send/receive invite codes.
This new spec is so much different than NIP17, I can't figure out why it's good to merge over, what's the point, just to try to kill off nip17? Why didn't we merge nip17 over kind04? Just pick a new number or letter. The people talking about metadata are also correct, more metadata exposed is not a good thing at all..
Sounds like you need a NIP to specify how to privately send a tree of that that identifying metadata so a server can know what to securely send. That might help reduce the size NIP-17 traffic.
Well that's cordn sir
i chimed in with my thoughts. looking forward to reading both of your comments on this.
