I have never edited a longform post because we should not be using replaceable events for this. Relays will remove older versions, so you are forced to make replies, reactions and zaps target the naddr which opens up a can of horrible problems in the protocol. People working on longform stuff should fix the spec. Damus will never target naddr’s for replies and zaps because this is pretty dangerous and can lead to people looking like they are supporting things they don’t support.


edits should be like reactions and form a history keeping all notes


我


Why is it dangerous?


You can make a post that says “puppies are awesome”, get lots of people to zap it and reply “agree!”, then update it to “death to all jews” and then there is no way to see the edit history. It just looks like people are supporting that statement with zaps and replies.

See the problem ?


hi will, nostr:npub10qk5zpmhv7rspp87shajf7d24yrf4lyr7w0m25wv9w78grs4k0sq0gq8pc
is this your account? look like different from your account npub key.


Created at  timestamps are also not reliable - otherwise atleast comments can be tagged as made for a previous edit 😔


Wonder if there are people dare to say they don't see the problem 🤣


From: nostr:npub1u8lnhlw5usp3t9vmpz60ejpyt649z33hu82wc2hpv6m5xdqmuxhs46turz


Did you ever think about using CRDT (https://en.m.wikipedia.org/wiki/Conflict-free_replicated_data_type) for editable long form content? We have all tools in place and replacable events are not needed.


Yes, I see it.
It's the same problem that exists today with any self hosted blog, of course. Platforms storically solved it disabling or limiting the edit on a short period.

Maybe the solution is to include the revisions and make them accessible at comments' level. So if something happens the user can always reply to himself and point out that the comment was related to a different context, highlighting the shady update.
A real win would be to somehow force every update/event to include *all* the previous revisions, in this way we can also solve the "vanished from relay" problem, but currently we have only the `d` tag, so revisions are not chainable.


An important and interesting note: what you are worried about is already possible today replacing a image/video linked content, without any formal edit. And it can happens on short notes too. So Damus, like any other clients, is already vulnerable to this sort of "attack".


You are already living the problem with short notes :)


And who will store all that garbage? You?


Comments and zaps should always include and "e" tag alongside the "a" tag, right?


reactions should be made smaller, edits a dif

yes we need more local storage and p2p, media is still centralized


if you `e` tag along with the `a` this problem goes away, even if you original event goes away, you have prove that you didn't react in it's current form

you could currently tweet something like "this is cool www.example.com" and then the people on example.com put a swastika

I think there are problems with NIP-33s in general, but I don't think this is one of them


furthermore, when you e-tag a NIP-33 you could publish the NIP-33 you're tagging to your own relay and then prove that the pubkey that published it was maliciously altering content

I think changing a NIP-33 maliciously like this is much more a cryptographically-sound self-own rather than a problem for people tagging it.


they already do; each "update" is a separate event that *can* be kept (even the NIP now reflects that this might be the case)


It's a similar issue if I post an immutable kind 1 note saying "I love the https://puppies.com/ website" and then an year later the domain is bought by a nazist group.

I think just general education and a caveat in the clients saying that the reply was made to a different event in a different time fixes this as best as possible.


jb was talking about replacable events?


like are we both confused on this?

nostr:nevent1qqsdrq5lsjv429xg22pqh60k7hte5c7rd7vypp6qmzqhr8x6n52s25cpzpmhxue69uhkummnw3ezuamfdejsygpjuxp8vd29p6ancknaztql3eajk52y8xkppfn7au7elkw9c68zg5psgqqqqqqsmgdrs0


same issue with all centralized links, should we hash something? media should be decentralized anyway, have you seen iroh? https://github.com/n0-computer/iroh


Yeah!! The important question! 🤣


Blergh.


Users are more inclined to understand that a external link can change, but they hardly can think that this apply to an embedded content:

nostr:nevent1qqswx0yxhlrwvj5a2w60pezkwdh0rnj47nerejz8ev3zrmv74dch4xgpzpmhxue69uhkztnwdaejumr0dshsz9mhwden5te0v96xcctn9ehx7um5wghxcctwvshszyrhwden5te0v5hxummn9ekx7mp0qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcprdmhxue69uhkvet9v3ejumn0wd68ytnzv9hxgtmsd93hxqg7waehxw309anx2etywvhxummnw3ezucnpdejz7ur0wp6kcctjq9n8wumn8ghj7enfd36x2u3wdehhxarj9emkjmn99ah8qatzx9erqunnx4cnyemtxpjnxertxdhxccehvah82veh8pjkxdnrdekx2mn3wquxzvmrdf58j7n4xenrs6e4wdnhxdrnwyukzcelvfex7ctyvdshxapaw3e82egp2amhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0dec82c33wscxu7t8xc6xwdtkwac8yanpx5e8wmrrd46rwentv3erqdmkx4j8ydmnxv6hyct389nnq7r8vvcxkdrcvdek2er2vachvqtxwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tmwwp6kyvtcd3a8wunsdp58sursv4uk5aeswpexcaesv3m8qumd0qexzwr2vsm8j6rwwscrvcmv0qm85anvxpn857nywdnkxefhwucr7cnjdaskgcmpwd6r6arjw4jszrnhwden5te0dehhxtnvdakz7qg7waehxw309ahx7um5wgkhqatz9emk2mrvdaexgetj9ehx2ap0qyv8wumn8ghj7mn0wd68ytnxd46zuamf0ghxy6t69uq3zamnwvaz7tmwdaehgu3wwa5kuef0qyd8wumn8ghj7ur4wfshv6tyvyhxummnw3ezumrpdejz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uq32amnwvaz7tmjv4kxz7fwdehhxarj9e3xwtcprfmhxue69uhhyetvv9ujuam9d3kx7unyv4ezumn9wshskn3a78


"p2p" triggered.


NIP-94 could solve this.


Can relays do some kind of compression for this?


Agreed.


Many users are vulnerable today to screenshot attacks in which you alter something in a page and take a picture of that. Doesn't mean the internet is broken because of that.

There are many things users will have to learn if they are going to start using Nostr.


pretty sure this has been thrashed out pretty well in several forum protocols - the events history is not changed, only a new event that says 'edit this event thusly' and then the edited event is displayed with a 'edited' tag on it at minimum, and ideally, a 'view history' button.

the event history should be immutable even if a 'change event' event exists.


The "right" way to fix this is to not allow any edits to any post once it has been interacted with in any way - if it's had a like or a zap or a reply. It's the way sensible discussion systems work, and it would make sense to have it do the same here. This is a definite problem, and without any obvious "edited" indicator, it's quite a concern.


the 'p2p' need not be brought to the client level, the relays could store the media, point is by using hash ids (like as notes do) we can move media around anywhere

iroh is attempting to vastly improve ipfs, from my investigation they have made some good design choices like blake3


Sure. My point was made to confirm your view and relax the matter in response to Will observation, not to highlight any specific criticism.
That said, it would be nice to have an "atomic" way to store multimedia notes.


but we can fix media posted remaining the media posted quite easy with hashes, and not having distributed media is massively problematic

i cant understand how this is not a top priority, its great we have censorship resistant text but most posts are media and will be taken down or lost


bittorrent v2, ipfs or iroh aka refined ipfs are top contenders for this atomic multimedia

i would say roll a new version of torrent but iroh seems mostly on that path


no


its dumb


notes are quite long on amethyst


i will take that as you have no idea what iroh is


nostr notes could be screenshot alter verifiable


thats a fake, popular npubs have fakes


I second this, replaceable events are bad and introduce a lot of complexity. Lists, especially ones that get updated a lot are also bad because of race conditions between clients.


One of the additions in the approval spec for community posts was to include both the naddr and event id in the approval event. It doesn’t fix the problem, but it at least lets the client display properly if an approval is out of date or invalid. In theory you could do the same with replies, though I agree it seems like a bit of a rabbit hole.


concurrency requires mutual exclude locking, that's one standard approach.


Hain't going to get locking on nostr. The only way (by definition) is CRDTs


that was the other possibility but i'm not aware of one that gives you the ability to push diffs on an existing state. locking really is going to be needed, i think, unless someone invents a radically new CRDT that can do diffs.


https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type#Sequence_CRDTs

the same techniques used for collaborative document editing like meistertask and similar is probably the way to go with this.


breath to all jews


Impressive argument you got there


You can do that today with a kind 1. Just write that sentence in an image in a server you control and change it later. :)


number one there is no proof of time in nostr so you could back date an edit

do i need to say more?


each edit is valid content, it is a can of worms


good times


exactly


The x tag contains the file hash, you don't need the time attestation to spot a remote update.


note hash, good point but delete already covers this use case

edits are good especially as reactions and can be expanded to others doing them, annotations etc, the issues of edits are really a ui problem not the note schema


nice information. thanks.


What do you mean by "diffs"? Isn't op based crdt ("CmRDTs") just that?


when they are on one branch they come into conflict. it's easy to exclude this possibility by making branches tied to a key, but merge conflicts require human intervention.


it's not the same as forks in a blockchain where you can just pick the smaller hash. there is usually tens if not thousands of changes in a commit, and it would be highly impractical to have code rearrange itself as you work on it.

it's good that i bumped into this subject because the project i am helping bring to fruition needed some protection from concurrency and they devised some good solutions.


no