Anthony Accioly on Nostr: GM fiatjaf. This is what I referred to as "fiatjaf method 2" above. The main ...
GM fiatjaf. This is what I referred to as "fiatjaf method 2" above. The main shortcoming is the lack of edit history, which can be addressed with a bit of added complexity.
For example, type 31000 could tag a linear history of immutable "edit version" events. Clients would always publish both a new 31000 event and an immutable edit version event. When publishing an edit, clients should mutate the bodu contents of the 31000 event to reflect the contents of the latest version and add a new tag pointing to the latest edit version.
This approach is generic enough to accommodate everyone and is reasonably easy to implement (simpler to read, at the cost of slightly more complex writes).
1. Want the latest version? Fetch kind 31000 and simply display the body.
2. Want purely immutability? Use kind 1.
3. Want the full history, Amethyst style? Check the tags of the kind 31000 event.
The write trade-off here is that clients supporting kind 31000 would need to publish two events: one for the regular immutable edit version, and one updated kind 31000 event. They also need to be aware of potential race conditions. That is, they should replace version kind 31000 n with version n+1, if n+1 correctly tags n. This can also be enforced at the relay level. However, clients would need to retry in a CAS-style manner to avoid "corrupting" the index.
What do you think? Also tagging Vitor Pamplona (nprofile…pyug)
For example, type 31000 could tag a linear history of immutable "edit version" events. Clients would always publish both a new 31000 event and an immutable edit version event. When publishing an edit, clients should mutate the bodu contents of the 31000 event to reflect the contents of the latest version and add a new tag pointing to the latest edit version.
This approach is generic enough to accommodate everyone and is reasonably easy to implement (simpler to read, at the cost of slightly more complex writes).
1. Want the latest version? Fetch kind 31000 and simply display the body.
2. Want purely immutability? Use kind 1.
3. Want the full history, Amethyst style? Check the tags of the kind 31000 event.
The write trade-off here is that clients supporting kind 31000 would need to publish two events: one for the regular immutable edit version, and one updated kind 31000 event. They also need to be aware of potential race conditions. That is, they should replace version kind 31000 n with version n+1, if n+1 correctly tags n. This can also be enforced at the relay level. However, clients would need to retry in a CAS-style manner to avoid "corrupting" the index.
What do you think? Also tagging Vitor Pamplona (nprofile…pyug)