nostr-protocol
Editing posts
Parameterized replaceable events will allow us to have text notes of kind 30000. The semantics would be mostly the same as kind 1 (although a good opportunity to clean up anything).
The client would generate a UUID for the post (and preferably encode it to a nicer format such as base62) and add it to the "d" tag. Then notes would be looked up with the author in the pathname, eg /@:nip05/:d.
This would be a nightmare for clients. It is a nightmare even on Twitter, which is completely centralized.
In what way? It works pretty well on Mastodon.
I don't see too many problems for Nostr, either. Whenever you sync posts from your followers (eg viewing your home feed) you'll get the edited events, which you can simply update in your cache. If your client supports parameterized replaceable events at all it should "just work"
Without thinking too deeply yet, I don't think it would be too difficult in gossip. We are doing it with long-form content already. Can't speak for other clients.
On the Fediverse, edited posts have a pencil icon. You can click into it to view the post history.
You would get rid of the entire concept of of ids for notes, replacing them with user-generated random identifiers.
Replies and reposts would refer to specific ids or to these random d identifiers?
It would generate inconsistencies everywhere, as it happens with NIP-23 posts, as different relays have different versions of each post.
It would open the door for malicious or tricky edits.
Subscribing to updates to notes would be a giant hurdle for clients that want to operate in a real-time way, which is not a big deal for NIP-23 as that is for long-living old content anyway.
The worst aspect of this proposal is that it would be a mandatory hard-fork.
NIP-23 is seen as a separate, independent feature from the basic kind:1 "social" aspect of Nostr. But this would be largely perceived as the same "social" aspect of Nostr and would fit the exact same flow, even though it would use different event kinds.
Because of that people will begin using it in clients that support that and the older clients would be either forced to implement or would just stop working. A huge centralization vector that we as a community must reject if we want Nostr to stay simple, decentralized and easy to implement.
Not sure the best solution, but users want the ability to edit posts. We can wait longer but eventually it's bound to happen.
An alternative to edit could be "annotations". In threads on github, it's convention for anything more than a minor edit to be appended to the bottom of a comment with EDIT at the beginning. Annotations could be supported in a backwards-compatible way and optionally supported by clients. They would basically be a comment, just displayed differently. So you'd end up with something like:
This makes it much clearer what's going on, and clients don't really have to support them.
There's bound to be a more Nosteric way to do it. I'm very much a proponent of the idea that your designs need to emerge out of your technology and can't be forced upon them from the top-down.
At the same time, Nostr is the underdog, and I genuinely want it to beat big tech.
I think there are more immediate problems to solve than "editing posts" right now, though.
Mastodon's editing feature solved major problems where deleting posts would break threads. Since they couldn't edit posts, users would delete their post and write a new one. I assume Nostr also has this problem somewhat.
This is perceived as less of a problem on Nostr because deleting posts doesn't actually work. So I would say the first problem to solve is to make deleting things actually work. That's something users care about much, much more.
I'm thinking about fetching metadata from relays and only publishing to them if they claim to support nip09. A bit of a tangent.
Kind 1 edits would be nice but NIP-23-like behavior has a problem with ever changing created_ats that makes edits go to the top of the feed (because events are desc sorted by created_at).
I thought no one would accept an editable kind 1 because of problems with backward compatibility already mentioned above, but now that the discussion started...... I see two solutions:
-
"Edit events" with line diffs similar to git. You keep the original event so it can be referenced by its id but now for each event you would have to request the latest diff. But better than that is requiring relays that support "edit events" to use NIP-17 and add the "diff" field to the returned event like
{ kind: 1, ...other-event-fields, "nip17": { "diff": {<latest diff event json>} } } -
A new parameterized replaceable event (PRE), like the suggested 30000 (30000 already exists so 31111), with some tag rules as follows:
We need to fix the NIP-23 problem. So, before posting the event, we create a "Published at event" like { id: "<this will be in the d tag as a prefix>", kind: 1000, content: '', created_at: <now>, ... }.
Then add it to the 31111 event tag like:
{
"id": "...",
"kind": 31111,
"content": "Hello world",
"created_at": <this will change on each edit>,
tags: [
["d", "<Published-at-event's id atleast as a prefix>"],
["published_at", "<Published-at-event's created_at>", "<stringified Published-at-event json as proof>"],
],
...
}
Relays MUST use published_at instead of created_at when sorting PRE events if they contain published_at tag along with the "d" tag starting with the Published-at-event's id. Now users can't fake the published_at tag without losing the likes, zaps, replies etc.
This is a way to also fix some PREs (not all) like NIP-23 events that shouldn't be sorted by created_at.
You would get rid of the entire concept of of ids for notes, replacing them with user-generated random identifiers.
Replies and reposts would refer to specific ids or to these random
didentifiers?It would generate inconsistencies everywhere, as it happens with NIP-23 posts, as different relays have different versions of each post.
It would open the door for malicious or tricky edits.
Subscribing to updates to notes would be a giant hurdle for clients that want to operate in a real-time way, which is not a big deal for NIP-23 as that is for long-living old content anyway.
This has convinced me that we shouldn't do it. I had not thought that part through.
You would just be implementing NIP-33, I think. You can't reference any event in the range 30000 <= n < 40000 by its ID for the same reasons. Or... you just DO reference it by its ID, and then keep an index of "id" to "d" mappings.
"We have editable notes now!" <- It seems to be talking about 30023 note. Is Damus replacing kind 1 creation with this for social notes? Now that would be a hard-fork heheh
It seems like there should be an 'update' kind and that acts as an edit. You would reference the original post and then clients could choose to show updates to the original post or not. They could also show the update history as an edit history if the chose to. I don't think this would break anything.
@rabble has a good framing of this: https://www.nos.social/blog/on-deleting-and-editing-notes
