NIP-09: Allow cascading deletion of reposts by the original author

[mattn]

Problem

Currently, when a user publishes a kind 1 note and someone else reposts it (kind 6 or kind 16), the original author has no way to request deletion of those reposts. This is a significant problem in cases where the original note contains accidentally leaked private information (e.g., personal data, credentials, sensitive photos). Even if the author deletes their own note via a kind 5 deletion request, the repost — which may contain a full copy of the original event in its content field (as specified by NIP-18) — remains on relays indefinitely, perpetuating the leak.

This is not a theoretical concern. It is a realistic scenario that may have already occurred in practice.

Precedent: NIP-59 Gift Wrap deletion

NIP-59 already establishes a precedent for allowing someone other than the event's signing key to request deletion. Specifically:

Since signing keys are random, relays SHOULD delete kind 1059 events whose p-tag matches the signer of NIP-09 deletions or NIP-62 vanish requests.

In this model, the recipient (identified by the p tag) of a gift wrap can request its deletion, even though the gift wrap was signed by a random ephemeral key. The relay honors this because the recipient is the legitimate stakeholder of that event.

Change

This PR adds a "Cascading Deletion of Reposts" subsection under "Relay Usage" in NIP-09. When a relay receives a kind 5 deletion request, it SHOULD also delete any kind 6 or kind 16 repost events whose p tag matches the deletion request's pubkey and whose e tag references the deleted event. Relays SHOULD perform this cascading deletion even if they no longer hold the original event being deleted.

This is a relay-side specification. It does not require changes to client behavior.

Why this matters

• Privacy and safety: Accidentally leaked private information (personal data, intimate images, credentials) can currently be preserved indefinitely through reposts, even after the original author deletes their note. Under GDPR and similar privacy regulations, the inability to remove such content is problematic.
• Harassment mitigation: Reposts can be used to amplify harmful content. Even if the original author deletes the note (perhaps after being coerced into posting it), the repost continues to circulate. Cascading deletion gives the original author at least partial recourse.
• Consistency with existing specs: NIP-59 already allows non-author deletion in an analogous situation. NIP-70 (Protected Events) also demonstrates the protocol's willingness to let relays enforce author intent. This proposal is a natural extension of those principles.
• Pragmatic, not absolute: Like all deletion on Nostr, this is a request, not a guarantee. Events may already have been cached or replicated. But reducing the surface area of exposure is still valuable — the same rationale behind NIP-09 itself.

Background

This proposal follows from the discussion in #1413, where removing the embedded event from the repost content was proposed but met with resistance. fiatjaf suggested that NIP-09 could be extended to allow relays to cascade deletes to reposts. This PR implements that approach.

[vitorpamplona]

NACK

In [the NIP-59] model, the recipient (identified by the p tag) of a gift wrap can request its deletion, even though the gift wrap was signed by a random ephemeral key. The relay honors this because the recipient is the legitimate stakeholder of that event.

Not really. The relay honors it not only because the recipient is the legitimate stakeholder of that event, but also because the ephemeral key is irrelevant and SHOULDN'T exist anymore (as per NIP) to delete the event.

In this PR, we have a dispute. The repost key is not irrelevant. It's a real user. The real user might have wanted to keep a copy of the event that he/she is reposting. And that is a valid request too in order to keep people accountable for what they say.

Frankly, this need is closer to Reports than to Deletions: it's subjective. In reports, users tell relays that they are unhappy about something, and it is up to the relays (and sometimes clients) to review both sides of that information and take action. If there is a privacy concern, we need to figure out a way to let relays know. If not, this doesn't make much sense.

I don't think a general guidance to automatically delete reposts is a good idea.

[mattn]

However, in the three years I've been using Nostr, I've submitted reports several times, but I've never once received a response from a relay operator.　🙃

[vitorpamplona]

I've never once received a response from a relay operator.　🙃

You shouldn't. Reports should be aggregated, and the post and the report should be deleted from that relay if the relay agrees with you. If the relay disagrees with you, both stay there and then clients can take action if they want.

[mattn]

I don't think we should treat Nostr the same as other SNS platforms. On typical SNS platforms, deleting a post also deletes any reposts.

However, in Nostr, repost events are sent to relay servers even if the original poster isn't using them. Users who see these events then send repost events to other relay servers that no one knows about.

This means the original poster cannot track where the events have been sent.

What they can do is try to stop the reposts before many people see the post.

[vitorpamplona]

However, in Nostr, repost events are sent to relay servers even if the original poster isn't using them.

In those cases, the original event is also re-broadcast there, and since the original author doesn't know about it, that relay will not receive any deletion requests for either the original event or the repost.

Clients can be smarter about this since they see the repost and the deletion of the original post from any relay they are connected to. They can use their users' follow list to decide what to do:

• If the user follows the repost but not the author, then it stays.
• If the user follows the author, but not the repost, then it disappears.
• If the user follows both, it can flag that the original author deleted it, but have a button to show anyway.

If they have access to NIP-85 WoT scores, the client can pick the highest score to decide what to do.

All of these are better than auto-delete on the relay side.

[mattn]

Unfortunately, not all clients meet the specifications you present, and those specifications are not MUST.
To be perfectly honest, I'd like to specify this deletion specification as “MUST”.
Or I'd like to change embedding JSON in the content attribute of the repost event to “MUST NOT”. I strongly want to save poster's privacy.

[mattn]

Furthermore, many relays currently have issues. For example, some relays that were once free but have since switched to paid models require users to pay to delete past posts. To put it mildly, it's the worst.

Why don't I have the authority to delete information I posted immediately? Why does it persist in the content attribute of reposts even after I deleted it? I wish you'd take this a bit more seriously.

[vitorpamplona]

Unfortunately, not all clients meet the specifications you present, and those specifications are not MUST.

NIPs are a reflection of the bahavior on clients/relays, they don't magically make clients and relays do things. Even if this PR is accepted, it's likely that most relays will never implement this... just like most relays don't implement NIP-59 p-tag deletions.

Heck, the vast majority of relays don't even implement basic Deletions correctly. Some clients don't delete at all.

And worse, I have seen some relays that only save deleted events. They pool everything as fast as they can from every relay out there and keep only posts that were deleted because they think those posts are more valuable to sell to companies doing background checks on people.

Why don't I have the authority to delete information I posted immediately? Why does it persist in the content attribute of reposts even after I deleted it? I wish you'd take this a bit more seriously.

Because it is not your post anymore. Once you send it to a relay and another client has downloaded it, that's their post. It's like sending an email. Once you send, you cannot control anything about it. On Amethyst, I can even take your post and create an nostr:nembed1... and the JSON will be inside of it. I can put that link in any post or DM I want.

I wish you'd take this a bit more seriously.

I understand the seriousness of this situation, but there is no good solution in an open network like Nostr to control your own posts. We can try to help, but it's really up to relays and clients to do what they want to do.

[mattn]

Yes, I am certainly aware. For over two years, I have personally maintained and managed the implementation of the Nostr relay server. However, this service is limited to Japanese users. Incidentally, I also handle deletion requests based on NIP-59.

This is NOT magically, for example, it's merely a mechanism to prevent the spread of information that you or your family may have mistakenly posted.

Unfortunately, unless changes are made in the right direction, it seems unlikely that Nostr will gain acceptance among the general user base like other SNS platform, I guess.

I like the Nostr protocol design, but I can't really agree with an approach that prioritizes design constraints over users.

[vitorpamplona]

You should advertise that your relay codebase deletes reposts of deletion events as you described here. If all users end up asking for this and/or using your codebase instead of strfry, then you win, and this PR gets merged, and we all get to delete reposts just because users want us to.

[mattn]

This isn't about winning or losing.
Implementers like me build relay servers based on the specifications. What you're saying is the same as telling me to, for example, “create an extension protocol and make it popular” when I point out problems with HTTP.

We, specification authors should always deeply consider why “MAY,” “MAY NOT,” “SHOULD,” “SHOULD NOT,” “MUST,” and “MUST NOT” exist in RFCs.

[vitorpamplona]

This isn't about winning or losing.

It absolutely is. The reason the NIPs are the way they are is because popular clients implement them. Users define NOSTR. If you go out there and you educate them that this is needed, it will change the NIP to whatever you want it to be.

Don't be tied to the NIPs. They are not specs. They are not RFCs. They just document the winning apps to increase interoperability. That's it. That's all there is.