Oddbean

I woke up in the middle of the night and started thinking about deniable nostr notes, notes that do not have a signature so you can’t prove someone actually wrote it if it gets leaked from a private relay. The idea is simple: you use your key to AUTH when connecting, after doing that, all notes sent are unsigned. The relay can verify its you but notes sent afterward have no signatures. This is a “trusted” relay mode, no clients can know for sure if the person wrote said notes, but said persons get deniability if the data leaks. The notes are also protected from rebroadcasting to public relays because there are no signatures. I wonder if anyone is interested in something like this? As long as it’s very clear on the UI that the notes are not verified?

you have to trust the relay, there’s no way around that. I’ve looked into other mechanisms: - undeniable signatures - delegate keys that you leak occasionally after some epoch But they are somewhat complicated. This is a dumb yet simple alternative

There have been plenty of people who have expressed explicit distaste for it @fiatjaf @semisol @PABLOF7z @Cameri and probably more i’m forgetting. I think someone even tried to remove it as a nip if I remember correctly.

I thought Pablo was the one to propose it ¯\_(ツ)_/¯ I haven't followed the discussion but imagine the distaste boils down to the added complexity all while not being a perfect solution. If nostr were centralize, this wouldn't be a concern since we could shove key delegation down everyone's throats.

yes this is the concern, and it complicates relay implementations. It was originally created by the cto at minds.com as a way they can transition to use nostr, but i don’t think they pushed that very hard and they seem to have lost interest

I didn't propose it, I was an advocate for it -- we even did a panel with @KeithMukai at Nostrica for it. The closer I got to it the more I realize it was a very problematic NIP. I think NIP-46 is the right way of doing "delegation" as it's equivalent to taking complexity offchain

unsigned notes can’t be pumped into the network. If you connected to one of these trusted relays today most clients would reject the messages. They can’t be spread to public relays because they have no signatures. You can spam the network with signed notes just the same anyways.

Private relays for businesses. Generally you trust the corporate network but don’t want to be held liable when things leak. It’s the same idea as DKIM on email, sometimes that bites you in the ass when it leaks, but if there is no signature you can claim it was forged.

It's quite easier to make a change and nobody will know whenever it's actually changed except the author itself. I don't think this is actually needed for storing real sensitive and classified stuff. You could simply make every single posts being encrypted with NIP-44 and then post it to relay.

To a [group] of people where each of them know the private key for decrypting the post, which then could be also used for encrypting a post that then will sent to [group]. The [group] is basically pretending to be a normal nostr user. However it's used for different use case, so sort of like another "Nostr Community" section except it has encryption being set around it. During creation, The client that the owner of the [group] group would like to send the private key information (which encrypted with NIP-44) regarding [group] to a list of members that has been set by the owner. So yet, we are reinventing another Private Messaging NIP, but this one is not for normal private messaging. It was designed for the [secret group] members to know the key to decrypt and encrypt their post. ``` C -> Client U -> User MC -> Member's Client U: *creates [secret group] with 20 members in it* C: *make a private key for that group and then spread the info of the private group and seal the private key with NIP-44 to these members* MC: *receives the info and then store that sealed private key information so these members could read and write a post into that group* ``` In other end, I think it's possible to make it not need to spread the private keys to members. In case of private key leakage, The owner of the [group] could always make a new private key and reannounce the new private key to these members for future READ-ing and WRITE-ing to the same [group]. The owner could also blacklist someone in the group by doing the same thing and reannounce the new key to the list of members, with exception of the blacklisted members.

First, this is different, these are unsigned events. Second the "-" tag is a fiatjaf thing that I implemented because it was straightforward that means "Please don't accept this note from anybody other than the author".