# 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 31
# self = https://watcher.sour.is/conv/y6idegq
@movq Thanks for the summary!
So, what would happen if there is no original message anymore in the feed and you encounter an "edit" subject? Since you cannot verify that the feed contained it in the first place, would you obey it?
Some feed could just make a client update something from a different feed. In the cache, the client would need to store in a flag that this message was updated, so that when it later encounters the message from the real feed, it has a chance of reverting that bogus edit. Hmm. The devil is in the detail.
It's much easier with a delete subject. When it finds the message in its cache and the feeds match, remove it. Otherwise, just ignore it.
@lyse This is why hashes provide that level of integrity. The hash can be verified in the cache or archive as belonging to said feed.
@lyse This is why hashes provide that level of integrity. The hash can be verified in the cache or archive as belonging to said feed.
@prologic So, this is either me nit-picking or me not understanding the hash system after all. π
An edit twt would look like this:
2024-09-20T14:57:11Z (edit:#123467) foobar
So we now have to verify that #123467 actually exists in this same feed. How do we do that? We must build a list of all twts/hashes of this feed and then check if #123467 is in that list. Right?
Youβre kind of implying that it would be possible to cryptographically validate that this hash belongs to this feed. Thatβs not possible, is it? π€
@prologic So, this is either me nit-picking or me not understanding the hash system after all. π
An edit twt would look like this:
2024-09-20T14:57:11Z (edit:#123467) foobar
So we now have to verify that #123467 actually exists in this same feed. How do we do that? We must build a list of all twts/hashes of this feed and then check if #123467 is in that list. Right?
Youβre kind of implying that it would be possible to cryptographically validate that this hash belongs to this feed. Thatβs not possible, is it? π€
@prologic So, this is either me nit-picking or me not understanding the hash system after all. π
An edit twt would look like this:
2024-09-20T14:57:11Z (edit:#123467) foobar
So we now have to verify that #123467 actually exists in this same feed. How do we do that? We must build a list of all twts/hashes of this feed and then check if #123467 is in that list. Right?
Youβre kind of implying that it would be possible to cryptographically validate that this hash belongs to this feed. Thatβs not possible, is it? π€
@prologic So, this is either me nit-picking or me not understanding the hash system after all. π
An edit twt would look like this:
2024-09-20T14:57:11Z (edit:#123467) foobar
So we now have to verify that #123467 actually exists in this same feed. How do we do that? We must build a list of all twts/hashes of this feed and then check if #123467 is in that list. Right?
Youβre kind of implying that it would be possible to cryptographically validate that this hash belongs to this feed. Thatβs not possible, is it? π€
@movq Is t it? You read each Twt and compute its hash. It's a simple O(1) lookup of the hash in that feed or your cache/archive right?
@movq Is t it? You read each Twt and compute its hash. It's a simple O(1) lookup of the hash in that feed or your cache/archive right?
@prologic Okay, looks like I misunderstood/misinterpreted your previous message then. π
@prologic Okay, looks like I misunderstood/misinterpreted your previous message then. π
@prologic Okay, looks like I misunderstood/misinterpreted your previous message then. π
@prologic Okay, looks like I misunderstood/misinterpreted your previous message then. π
@movq Am I missing something? π
@movq Am I missing something? π
@prologic Nah, just language barrier and/or me being a big stupid. π₯΄ All good. π
@prologic Nah, just language barrier and/or me being a big stupid. π₯΄ All good. π
@prologic Nah, just language barrier and/or me being a big stupid. π₯΄ All good. π
@prologic Nah, just language barrier and/or me being a big stupid. π₯΄ All good. π
@prologic @movq I still don't understand it. If the original message has been replaced with the edited one, I cannot verify that the original was in the same feed. I don't know the original text.
@lyse Yes you do. You keep both versions in your cache. They have different hashes. So you have Twt A, a client indicates Twt B is an edit of A, your client has already seen A and cached and archived it, now your client fetches B which is indicated of editing A. You cache/archive B as well, but now indicate in your display that B replaces A (_maybe display, link both_) or just display B or whatever. But essentially you now have both, but an indicator of one being an edit of the other.
The right thing to do here of course is to keep A in the "thread" but display B. Why? So the thread/chain doesn't actually break or fork (_forking is a natural consequence of editing, or is it the other way around? π€_)._
@lyse Yes you do. You keep both versions in your cache. They have different hashes. So you have Twt A, a client indicates Twt B is an edit of A, your client has already seen A and cached and archived it, now your client fetches B which is indicated of editing A. You cache/archive B as well, but now indicate in your display that B replaces A (_maybe display, link both_) or just display B or whatever. But essentially you now have both, but an indicator of one being an edit of the other.
The right thing to do here of course is to keep A in the "thread" but display B. Why? So the thread/chain doesn't actually break or fork (_forking is a natural consequence of editing, or is it the other way around? π€_)._
If OTOH your client doesn't store individual Twts in a cache/archive or some kind of database, then verification becomes quite hard and tedious. However I think of this as an implementation details. The spec should just call out that clients must validate/verify the edit request and the matching hash actually exists in that feed, not how the client should implement that.
If OTOH your client doesn't store individual Twts in a cache/archive or some kind of database, then verification becomes quite hard and tedious. However I think of this as an implementation details. The spec should just call out that clients must validate/verify the edit request and the matching hash actually exists in that feed, not how the client should implement that.
@prologic This does not hold if the edit happened before I even got the original.
@lyse This is true. But the client MUST supply the original too! Or this doesn't work π’
@lyse This is true. But the client MUST supply the original too! Or this doesn't work π’
i.e: there must be two versions of the Twt in the feed.
i.e: there must be two versions of the Twt in the feed.