NIP-404 - Deniable events

[gu1p]

I have zero experience developing for Nostr, and I probably did more things wrong than right, but this was my best attempt at expressing my ideas.

Let me know if there is something we can save or it's just crap.

@vitorpamplona @fiatjaf

[vitorpamplona]

TLDR, @gu1p wants to do some form of key delegation with "expiration" based on proof of work difficulty.

The main key generates a new key and uses the first chars of that new npub as a challenge. Anyone that solves that challenge and finds an npub that matches it can publish as the main key. Because it is proof of work, it will become easier and easier to solve over time. Which creates some form of plausible deniability for the author.

Clients have to warn users that the new key might not represent the author anymore based on the time it has passed and the proof of work required by the author.

[arthurfranca]

It is hard to make sure PoW will take a certain min time length.

edit: the following was a bad idea =]~
A simpler alternative would be to use kind 6 (or 16? does anyone use it?) reposts signed by your main account. The reposted event is always from the all zeroed privkey (everyone can use it) and its corresponding pubkey.

Reposts in this case must add the stringified json of the reposted event to the .content field.

Clients, optionally, add a special case when they see a repost of an event from the zeroed keypair by presenting the post visually as a regular note view (as if it were from the kind 6 author) instead of a repost view.

Edit: the ephemeral part is simply the expiration tag

[gu1p]

I didn’t quite understand your point, @arthurfranca. The PoW and the reference event's challenge event's timestamp are crucial elements in creating the trustless, ephemeral nature of authorship in my proposal. What you described seems vulnerable to spammers, as it doesn't prevent anyone from easily creating and reposting events.

My proposal ensures that when a challenge is issued, Alice is the best-positioned person to solve it due to her control over the challenge's creation. Over time, however, the challenge becomes solvable by others, making the event's authorship increasingly ambiguous as time passes. This mechanism provides ephemeral interaction through plausible deniability.

edit: fixed an important aspect

[arthurfranca]

A repost is in fact two events in one, the outter one is signed for example by your main pubkey. The inner one would be from a keypair everyone knows, thus anyone could be its author, so you can deny it was you who created it. Anyone can repost the same inner event, reinforcing deniability.

edit: An important detail would be the client tweaking the repost presentation when the inner event is from that pubkey everyone controls, so that it looks like as a regular note (the inner event kind) instead of a repost kind.

[gu1p]

@arthurfranca the outer signature confirms who shared it. You cannot deny that the outer signer is not aware or endorses what the the inner anonymous author is saying. I don't like that much.

[arthurfranca]

Alice publishes a challenge event signed by her primary key...

How in your proposal Alice followers would discover the ephemeral event if not by subscribing to that challenge event kind with author=Alice? It has the same problem you pointed doesn't it?

edit: I didn't read the NIP throughly xD but I do wonder how a follower would know what to fetch

[pablof7z]

I didn’t quite understand your point, @arthurfranca. The PoW and the reference event's timestamp are crucial elements in creating the trustless, ephemeral nature of authorship in my proposal. What you described seems vulnerable to spammers, as it doesn't prevent anyone from easily creating and reposting events.

My proposal ensures that when a challenge is issued, Alice is the best-positioned person to solve it due to her control over the challenge's creation. Over time, however, the challenge becomes solvable by others, making the event's authorship increasingly ambiguous as time passes. This mechanism provides ephemeral interaction through plausible deniability.

this is vulnerable to a withhold attack or even simply a backdated attack.

[gu1p]

Alice publishes a challenge event signed by her primary key...

How in your proposal Alice followers would discover the ephemeral event if not by subscribing to that challenge event kind with author=Alice? It has the same problem you pointed doesn't it?

edit: I didn't read the NIP throughly xD but I do wonder how a follower would know what to fetch

Clients will have to subscribe to that tag. But it is trivial to figure out who solved the challenge. The most important thing is that you cannot imply that was Alice that was the one who solved.

I don't know much about Nostr internals, but I think that 'relays' could, if they want, to ignore the answers to challenges that are wrong or answers for too old challenges.

[gu1p]

I didn’t quite understand your point, @arthurfranca. The PoW and the reference event's timestamp are crucial elements in creating the trustless, ephemeral nature of authorship in my proposal. What you described seems vulnerable to spammers, as it doesn't prevent anyone from easily creating and reposting events.
My proposal ensures that when a challenge is issued, Alice is the best-positioned person to solve it due to her control over the challenge's creation. Over time, however, the challenge becomes solvable by others, making the event's authorship increasingly ambiguous as time passes. This mechanism provides ephemeral interaction through plausible deniability.

this is vulnerable to a withhold attack or even simply a backdated attack.

Are you sure? The challenge created by Alice, signed by Alice and the reference event is also chosen by her.

[pablof7z]

but Alice can create the challenge and not publish it until she solves it

[gu1p]

but Alice can create the challenge and not publish it until she solves it

Yes, but what that means? It's Alice that is trying to protect her privacy.

[pablof7z]

maybe I'm missing something, but if she wants to protect her privacy why is she doing all this? Why not just post from a new pubkey?

[gu1p]

maybe I'm missing something, but if she wants to protect her privacy why is she doing all this? Why not just post from a new pubkey?

Imagine Instagram Stories, but on Nostr. You want to publish a picture of yourself doing wild things. It might not be a good idea for the post to be replicated across thousands of relays around the globe, but you still want to share it with your friends. This NIP creates a mechanism where, in the very short term, your npub is likely the author, but as time passes, more people could have created that deniable event (it was signed by other keys)

edit: renamed "ephemeral" to "deniable" to avoid confusion

[gu1p]

If Alice picks a medium-sized challenge, an extremely powerful bad actor could always solve it—but doing so would take time and be costly. Alice can publish notes with the solution immediately and with no cost. Clients, seeing the solution and the original time of the challenge proposal, can choose to display the post as likely being from Alice. No one can guarantee that it is from Alice, but in the short term, it is extremely likely. If you want to be 100% sure it was from her, of course, it is a good idea to send her a DM.

[gu1p]

Alice can always deny that the post was from her. The solution was not published with her keys, and a bad actor could be the one pretending to be Alice in this ephemeral deniable note.

edit: renamed "ephemeral" to "deniable" to avoid confusion

[gu1p]

The bottom line for me is that each note I create on Nostr today requires a lot of consideration about how it could be used against me in 10 years as the political mood of society changes significantly and we, as people, evolve. If I post something on my Instagram, I can always delete it, and even if someone takes a screenshot, I can claim it was fake. There is no deletion on Nostr. Each note you write is a marriage of your personal identity to that note forever. As user, that is not something compelling at all.

[mikedilger]

I love this idea. I didn't even think such a thing was possible and I'm kinda floored by the possibility.

When first published, people will know it must be Alice... but over time it could be an imposter mining the challenge and backdating it.

this is vulnerable to a withhold attack or even simply a backdated attack.

That is precisely the point. Because someone else could create such a note, you can't be sure it was Alice, providing plausible deniability. But Alice will create this immediately with no delay because she sets the challenge to the random npub she is using, whereas everybody else has to mine for a match.

I have zero experience developing for Nostr,

Good to have you with us.

I'm not sure about some of the details but I wanted to signal support for this idea, even though it is complicated and will be tricky to get right in all respects.

[gu1p]

That's pretty correct, @mikedilger.

On Instagram, you can set a message post to last a couple of hours. On Nostr, we can emit a challenge event with a specific UTC time that contains a carefully chosen number of initial characters from a public key as a hint. The challenge is solved by deniable events signed by an nsec that produces an npub matching the initial characters of the hint.

Because Alice generated the pair of keys randomly and used them as the hint in the challenge event, she can produce any deniable event. The "duration" of an deniable event is a function of the challenge event's timestamp and the current client's time.

For increased privacy, those deniable events don't even need their own timestamp. They are like ghosts that only make sense in relation to the attached challenge event.

edit: renamed "ephemeral event" to "deniable event" to avoid confusion with existing concepts

[mikedilger]

I think the challenge events should use an open timestamp (not a previous event) and be published periodically.
(I take back the last part)

[gu1p]

@mikedilger

We don’t need open timestamps, and I would avoid them at all costs. Alice is the one who sets a temporal mark on the challenge event. Since she is interested in publishing ephemeral deniable events and wants them to appear to her friends, she has the incentive to choose the correct time. I mentioned in the NIP a reference event -- that can be optional. A reference event is a stronger mark (low bound) in the temporal line, but we don't need it necessarily.

If she picks a certain date in the past for the challenge event, clients can warn users that we have very little confidence that the emitted ephemeral deniable events are from Alice because it past a lot of time. If Alice picks a certain date in the future, more people will have the opportunity to solve the corresponding challenge event and pretend to be her. Therefore, she would be the most interested person to pick the correct time for her challenge.

[gu1p]

I'm guilty of making comparisons with Instagram Stories. That analogy only makes sense in a few angles. Instagram provides a data ephemerality. This NIP can provide authorship ephemerality.

[mikedilger]

But if the "chronological anchor" is a previous event itself without an open timestamp, we really don't know what it was generated either. We only know that one was after the other. Both could lie about the time in either direction.

And if it doesn't matter, then why reference another event at all?

[gu1p]

@mikedilger it really doesn't matter. But if she wants to guarantee, she can refer to a event that contains Bitcoin block height, for example. It's up to her. It's a relative temporal referential.

[gu1p]

My initial thought was, for example, answer someone's post with that reference event. So we can know that the everything will happen after a arbitrary post is out there

[arthurfranca]

If we still had id prefix search (like id starts with "abcabc") on relays could this be just a tag?

{
  "kind": 1,
  "tags": [
     ["redirect_to_id", "abcabc"],
     ["e", "<...>"], // this is a reply
     ["expiration", "<whatever>"]
  ],
  "content": "", // unused
  "created_at": <timestamp_123>
}

Client uses the filter { limit: 2 /* not 1 */, ids: ["abcabc" /* not the full id */], kinds: [1], since: <timestamp_123>, until: <timestamp_123> }

If there is just one event fetched with the above filter instead of two and the expiration timestamp isn't over, use it.

[gu1p]

If we still had id prefix search (like id starts with "abcabc") on relays could this be just a tag?
...

@arthurfranca I guess here is where my limit knowledge on Nostr's spec become explicit. I didn't understand how what you said is related to the NIP haha

Every contribution is appreciated

[pablof7z]

So the idea is not to masquerade whether it's Alice or not? Everybody would know that the initial event of that pubkey is definitely Alice and the goal is that after some time Alice has plausible deniability?

If that's the case then why doesn't Alice just publish some event saying "this other pubkey is also me for a while" with an expiration date on the event, people that want to pay attention start looking at that pubkey too, and at expiration time Alice she kind:5s the initial event and publishes the private key of the "ephemeral" pubkey so, after the fact, anyone could have published anything in that pubkey and it becomes useless.

[gu1p]

Everybody would know that the initial event of that pubkey is definitely Alice and the goal is that after some time Alice has plausible deniability?

Exactly. And it works! :) I's not Alice's signature there. This can look silly, but the mere fact that is not her signature and everyone potentially can have forge that event have big implications: if someone try to use that note against her, she can say it's fake (specially if it's something very old);

[gu1p]

Deniable events ephemeral events, like those described in this NIP, make it much more difficult to use signed events against people. If someone is motivated to prosecute or shame you because of a note, that person could have forge the event.

edit: changed "ephemeral events" to "deniable events" to avoid confusion with existing concepts

[pablof7z]

btw, just to reduce confusion, we already have a concept of ephemeral event (events that are deleted by relays after some time and typically not stored in a database) -- we should have a different name for this ;)

[gu1p]

btw, just to reduce confusion, we already have a concept of ephemeral event (events that are deleted by relays after some time and typically not stored in a database) -- we should have a different name for this ;)

What do you think about "Deniable Events"? @pablof7z