# 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 25
# self = https://watcher.sour.is/conv/fj7dppq
Trying to sum up the current proposal (keeping hashes):
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, “update twts”.
- A twt starting with (edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.
- A twt starting with (delete:#3f36byq) advises clients to delete #3f36byq from their storage.
Right?
Trying to sum up the current proposal (keeping hashes):
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, “update twts”.
- A twt starting with (edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.
- A twt starting with (delete:#3f36byq) advises clients to delete #3f36byq from their storage.
Right?
Trying to sum up the current proposal (keeping hashes):
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, “update twts”.
- A twt starting with (edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.
- A twt starting with (delete:#3f36byq) advises clients to delete #3f36byq from their storage.
Right?
Trying to sum up the current proposal (keeping hashes):
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, “update twts”.
- A twt starting with (edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.
- A twt starting with (delete:#3f36byq) advises clients to delete #3f36byq from their storage.
Right?
For implementations, it would be nice if “update twts” always came *after* the twt they are referring to. So I thought about using this opportunity to mandate append-style feeds. But that’s just me being lazy. Implementations will *have to* be able to cope with any order, because feeds cannot/should not be trusted. 🫤
For implementations, it would be nice if “update twts” always came *after* the twt they are referring to. So I thought about using this opportunity to mandate append-style feeds. But that’s just me being lazy. Implementations will *have to* be able to cope with any order, because feeds cannot/should not be trusted. 🫤
For implementations, it would be nice if “update twts” always came *after* the twt they are referring to. So I thought about using this opportunity to mandate append-style feeds. But that’s just me being lazy. Implementations will *have to* be able to cope with any order, because feeds cannot/should not be trusted. 🫤
For implementations, it would be nice if “update twts” always came *after* the twt they are referring to. So I thought about using this opportunity to mandate append-style feeds. But that’s just me being lazy. Implementations will *have to* be able to cope with any order, because feeds cannot/should not be trusted. 🫤
@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.
The important bits missing from this summary (_devil is in the details_) are two requirements:
- Clients _should_ order Twts by their timestamp.
- Clients *must* validate all edit and delete requests that the hash being indicated belongs to and came from that feed.
- Client _should_ honour delete requests and delete Twts from their cache/archive.
The important bits missing from this summary (_devil is in the details_) are two requirements:
- Clients _should_ order Twts by their timestamp.
- Clients *must* validate all edit and delete requests that the hash being indicated belongs to and came from that feed.
- Client _should_ honour delete requests and delete Twts from their cache/archive.
What about edits of edits? Do we want to “chain” edits or does the latest edit simply win?
Chained edits:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd222) Hello Birds!]
Latest edit wins:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd111) Hello Birds!]
Does the first version have any benefits? I don’t think so … ?
What about edits of edits? Do we want to “chain” edits or does the latest edit simply win?
Chained edits:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd222) Hello Birds!]
Latest edit wins:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd111) Hello Birds!]
Does the first version have any benefits? I don’t think so … ?
What about edits of edits? Do we want to “chain” edits or does the latest edit simply win?
Chained edits:
\n \n \n
\n \n [(edit:#abcd111) Hello World!]
\n \n [(edit:#abcd222) Hello Birds!]
Latest edit wins:
\n \n \n
\n \n [(edit:#abcd111) Hello World!]
\n \n [(edit:#abcd111) Hello Birds!]
Does the first version have any benefits? I don’t think so … ?
What about edits of edits? Do we want to “chain” edits or does the latest edit simply win?
Chained edits:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd222) Hello Birds!]
Latest edit wins:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd111) Hello Birds!]
Does the first version have any benefits? I don’t think so … ?
What about edits of edits? Do we want to “chain” edits or does the latest edit simply win?
Chained edits:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd222) Hello Birds!]
Latest edit wins:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd111) Hello Birds!]
Does the first version have any benefits? I don’t think so … ?
@lyse
> So, what would happen if there is no original message anymore in the feed and you encounter an "edit" subject?
We’d *have to* classify this as invalid and discard it. If the referenced twt is not present in the feed (or any archived feed), then it might potentially belong to some other feed, and feeds overwriting the contents of other feeds is pretty bad. 😅
As @prologic said, clients must always check that twts referenced by edit and delete are actually present in that very feed.
@lyse
> So, what would happen if there is no original message anymore in the feed and you encounter an "edit" subject?
We’d *have to* classify this as invalid and discard it. If the referenced twt is not present in the feed (or any archived feed), then it might potentially belong to some other feed, and feeds overwriting the contents of other feeds is pretty bad. 😅
As @prologic said, clients must always check that twts referenced by edit and delete are actually present in that very feed.
@lyse
> So, what would happen if there is no original message anymore in the feed and you encounter an "edit" subject?
We’d *have to* classify this as invalid and discard it. If the referenced twt is not present in the feed (or any archived feed), then it might potentially belong to some other feed, and feeds overwriting the contents of other feeds is pretty bad. 😅
As @prologic said, clients must always check that twts referenced by edit and delete are actually present in that very feed.
@lyse
> So, what would happen if there is no original message anymore in the feed and you encounter an "edit" subject?
We’d *have to* classify this as invalid and discard it. If the referenced twt is not present in the feed (or any archived feed), then it might potentially belong to some other feed, and feeds overwriting the contents of other feeds is pretty bad. 😅
As @prologic said, clients must always check that twts referenced by edit and delete are actually present in that very feed.
It just occurs to me we're now building some kind of control structures or commands with (edit:…) and (delete:…) into feeds. It's not just a simple "add this to your cache" or "replace the cache with this set of messages" anymore. Hmm. We might need to think about the consequences of that, can this be exploited somehow, etc.
@movq I think not.
> What about edits of edits? Do we want to “chain” edits or does the latest edit simply win?
This gets too complicated if we start to support this kind of nonsense 🤣
@movq I think not.
> What about edits of edits? Do we want to “chain” edits or does the latest edit simply win?
This gets too complicated if we start to support this kind of nonsense 🤣