# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 13
# self = https://watcher.sour.is/conv/tukxcsq
@anth 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 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:
- ~65/35 in favor of Content Addressing
- ~60/40 in favor of supporting Edit/Delete
- ~70/30 against more cryptograph
And an NPS score of 7/10 🤣~
Well the poll clearly shows:
- ~65/35 in favor of Content Addressing
- ~60/40 in favor of supporting Edit/Delete
- ~70/30 against more cryptograph
And an NPS score of 7/10 🤣~
@xuu Do you think we should just detect edits at the client-level then? 🤔
@xuu Do you think we should just detect edits at the client-level then? 🤔
@prologic 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;)
@prologic 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;)
@prologic 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;)
@prologic 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 well edits can be detected with either approach really
@sorenpeter well edits can be detected with either approach really