nip18: do not set content of repost event

[mattn]

For security reasons, I think that the JSON string of the reposted note should NOT be set in the kind 6 content. For example, suppose someone accidentally posted confidential or private content to a Nostr relay. It could be a link to an image showing someone's nudity. And if someone has already reposted the event even though they receive a request to cancel it from the person in the picture, we will not be able to erase it. I think that all of nostr client should not store a copy of the event.

[mattn]

FYI, I believe that the current specification is not acceptable in EU.

[alexgleason]

I agree with you. In my implementation I chose to just ignore this feature so deletions can be processed correctly.

[staab]

I don't think this really solves anything, since events can always be stored and re-published. It would be nice if deletes were checked by clients/relays and cascade to reposts. If that's the intention of the PR, that would be an ok alternative. But there are use cases for reposts improving durability too, like keeping people accountable who delete stuff. In any case, on nostr there is no delete.

[mattn]

The author of a post can use kind-5 to stop the wrong post from being reposted and spreading. However, the current specification does not allow kind-5 to stop the spread. This only encourages damage.

[vitorpamplona]

We use stringified events in many NIPs (Zaps for instance) that don't allow the original author to delete them. Do we want to stop doing them all and force clients to do a query to download each inner event?

I think it is easier if Clients simply load/apply Kind 5 deletions when loading any inner event into their databases.

On a repost, Amethyst will show that the inner post has been deleted by the original author but allow the receiving user to override and see it if we have in memory.

[alexgleason]

I don't think this NIP will change, which is why I didn't suggest it a year ago when I ran into the same issue. I just simply didn't embed the event in my client.

Kind 1 notes are different than zaps. You can't take back a zap anyway. To me it's not really about privacy, it's when you said something stupid and you want to delete it. Yes it could still be out there, but it at least deletes it for me, and probably a lot of other places. Embedding the post allows continued bullying that makes the user want to throw the phone out the car window and go for a walk in the park.

[staab]

Embedding the post allows continued bullying that makes the user want to throw the phone out the car window and go for a walk in the park.

Possibly a feature rather than a bug

[fiatjaf]

The author of a post can use kind-5 to stop the wrong post from being reposted and spreading. However, the current specification does not allow kind-5 to stop the spread.

We could modify NIP-05 to say relays can use any discretion they want to allow deletes. And give the explicit example of allowing reposts of someone's note to be deleted by that person.

[mattn]

We could modify NIP-05 to say relays can use any discretion they want to allow deletes. And give the explicit example of allowing reposts of someone's note to be deleted by that person.

That method require actions that delete it from all relays. If the contents are synced to unknown relays, it is impossible to avoid the risk of private information being left on the Internet. We can't stop worrying. Of course, it is not completely safe, but it is better than the current specification. On the other hand, if you empty the content, you can avoid the spread of damage by deleting your own posts.

[mikedilger]

I don't care if we include these in the content or not, it was just to make the note easy to find because people aren't including relay hints or using the outbox model.

But remember that deletions aren't real and the laws of the EU may be in conflict with the laws of information science.

When my girlfriend died in a hang glider accident, immediately afterward I would have done anything to go back in time and make different choices so as to avoid what just happened. I kept thinking about it over and over and over again, I couldn't stop replaying what had just happened. So I sympathize with wanting to undo something. But the nature of information is that this is strictly impossible. Once the quantum fields of an event entangle with other quantum fields, there is no un-entanglement. There is no going backwards in time. There is no delete. Nobody can erase the memory of the nude picture you accidentally sent that is in my head, nor can they come to my personal computer and erase it from my hard disk. So I suggest that people prepare themselves to accept any possible future, to maybe be stoic or zen about it, and just play the new cards you now find in your hand.

[staab]

As I've mulled this over, I think it would be ok to make the stringified event optional. I do think the current wording is too strong, but since Alex is already omitting the content, changing the current MUST to a MAY would be fine. Something like this:

Publishers MAY json-encode the reposted note and include it in the `content` field of the repost event.

[fiatjaf]

An year ago I campaigned against including the event inside the repost content because it felt unelegant and against Nostr principles and that a relay hint would be much better. After fierce resistance from some people I reevaluated and concluded it was actually not so bad and maybe even good -- although I still think the relay hint would be a good thing to have there.

Now I think an argument against it could still be made and I could probably even be convinced of it, but I wouldn't have any hope to change it at this point, so it's hard for me to even think about this question.

[nikolat]

Talking about the elegance of the specification, I think it is unelegant. A parameterized replaceable event such as kind 30023 should not be embedded in the content. Because it may be an out-of-date event before it has been updated. And it will never be deleted forever. There is no way to retrieve the latest event except by querying relays, and clients should retrieve the latest event referenced by the a tag from the relays. This is also true for events referenced by e tags that may have already been deleted. I feel that the current specification is unelegant, as it burdens communication by embedding events that should not be used.