@anth@a.9srv.net you wrote:
“Edits and Deletions should go; see also Section 6. This is probably the worst example of this document pushing a text document to do more protocol-like things.”
Edit and deletions are precisely what brought us here. Currently, if one replies to a twtxt, and the original gets later edited, it breaks replies, and potentially drastically changes context.
@bender@twtxt.net I am also in camp no edit signals. deletes only breaks the head of a thread. all the replies are unaffected.
@xuu what do we want then? Just up the hash size to avoid collisions? I figure that’s easy. It’s going to be a short call tomorrow then. 😂🥳
Well the poll clearly shows:
And an NPS score of 7/10 🤣
@xuu Do you think we should just detect edits at the client-level then? 🤔
@prologic@twtxt.net YES James, it should be up to the client to deal with changes like edits and deletions. And putting this load on the clients, location-addressing with make this a lot easier since what is says it: Look in this file at this timestamp, did anything change or went missing? (And then threading will not break;)
@sorenpeter@darch.dk well edits can be detected with either approach really