# 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 20
# self = https://watcher.sour.is/conv/ce4g4qa
(replyto http://darch.dk/twtxt.txt 2024-09-15T12:50:17Z) @sorenpeter I like this idea. Just for fun, I'm using a variant in this twt. (Also because I'm curious how it non-hash subjects appear in jenny and yarn.)
URLs can contain commas so I suggest a different character to separate the url from the date. Is this twt I've used space (also after "replyto", for symmetry).
I think this solves:
- Changing feed identities: although @mckinley points out URLs can change, I think this syntax should be okay as long as the feed at that URL can be fetched, and as long as the current canonical URL for the feed lists this one as an alternate.
- editing, if you don't care about message integrity
- finding the root of a thread, if you're not following the author
An optional hash could be added if message integrity is desired. (E.g. if you don't trust the feed author not to make a misleading edit.) Other recent suggestions about how to deal with edits and hashes might be applicable then.
People publishing multiple twts per second should include sub-second precision in their timestamps. As you suggested, the timestamp could just be copied verbatim.
@falsifian @prologic @lyse
> - editing, if you don't care about message integrity
So that’s the big question, because that’s the only real difference between hashes and the (replyto:…) proposal.
Do we care about message integrity?
With (replyto:…), someone could write a twt, then I reply to it, like “you’re absolutely right!”, and then that person could change their twt to something malicious like “the earth is flat!” And then it would look like I’m a nutcase agreeing with that person. 😅
Hashes (in their current form) prevent that. The thread is broken and my reply clearly refers to something else. That’s good, right?
But now take into account that we want to allow editing anyway. Is there even a point to using hashes anymore? Isn’t message integrity ignored anyway now, at least in practice?
There’s no difference (in practice) between someone writing
2024-09-18T12:34Z Brds are great!
and then editing it to either
2024-09-18T12:34Z (original:#12379) Birds are great! (Whoops, fixed a typo.)
or
2024-09-18T12:34Z (original:#12379) The earth is flat!
The actual original message is (potentially) gone. The only thing that we can be sure of now is that the twt was edited in *some* way. *Essentially*, the actual twt message is no longer part of the hash, is it? What does #12379 refer to? The edited message or the original one? We *want* it to refer to the edited one, because we don’t want to break threads, so … what’s the point of using a hash?
@falsifian @prologic @lyse
> - editing, if you don't care about message integrity
So that’s the big question, because that’s the only real difference between hashes and the (replyto:…) proposal.
Do we care about message integrity?
With (replyto:…), someone could write a twt, then I reply to it, like “you’re absolutely right!”, and then that person could change their twt to something malicious like “the earth is flat!” And then it would look like I’m a nutcase agreeing with that person. 😅
Hashes (in their current form) prevent that. The thread is broken and my reply clearly refers to something else. That’s good, right?
But now take into account that we want to allow editing anyway. Is there even a point to using hashes anymore? Isn’t message integrity ignored anyway now, at least in practice?
There’s no difference (in practice) between someone writing
2024-09-18T12:34Z Brds are great!
and then editing it to either
2024-09-18T12:34Z (original:#12379) Birds are great! (Whoops, fixed a typo.)
or
2024-09-18T12:34Z (original:#12379) The earth is flat!
The actual original message is (potentially) gone. The only thing that we can be sure of now is that the twt was edited in *some* way. *Essentially*, the actual twt message is no longer part of the hash, is it? What does #12379 refer to? The edited message or the original one? We *want* it to refer to the edited one, because we don’t want to break threads, so … what’s the point of using a hash?
@falsifian @prologic @lyse
> - editing, if you don't care about message integrity
So that’s the big question, because that’s the only real difference between hashes and the (replyto:…) proposal.
Do we care about message integrity?
With (replyto:…), someone could write a twt, then I reply to it, like “you’re absolutely right!”, and then that person could change their twt to something malicious like “the earth is flat!” And then it would look like I’m a nutcase agreeing with that person. 😅
Hashes (in their current form) prevent that. The thread is broken and my reply clearly refers to something else. That’s good, right?
But now take into account that we want to allow editing anyway. Is there even a point to using hashes anymore? Isn’t message integrity ignored anyway now, at least in practice?
There’s no difference (in practice) between someone writing
2024-09-18T12:34Z Brds are great!
and then editing it to either
2024-09-18T12:34Z (original:#12379) Birds are great! (Whoops, fixed a typo.)
or
2024-09-18T12:34Z (original:#12379) The earth is flat!
The actual original message is (potentially) gone. The only thing that we can be sure of now is that the twt was edited in *some* way. *Essentially*, the actual twt message is no longer part of the hash, is it? What does #12379 refer to? The edited message or the original one? We *want* it to refer to the edited one, because we don’t want to break threads, so … what’s the point of using a hash?
@falsifian @prologic @lyse
> - editing, if you don't care about message integrity
So that’s the big question, because that’s the only real difference between hashes and the (replyto:…) proposal.
Do we care about message integrity?
With (replyto:…), someone could write a twt, then I reply to it, like “you’re absolutely right!”, and then that person could change their twt to something malicious like “the earth is flat!” And then it would look like I’m a nutcase agreeing with that person. 😅
Hashes (in their current form) prevent that. The thread is broken and my reply clearly refers to something else. That’s good, right?
But now take into account that we want to allow editing anyway. Is there even a point to using hashes anymore? Isn’t message integrity ignored anyway now, at least in practice?
There’s no difference (in practice) between someone writing
2024-09-18T12:34Z Brds are great!
and then editing it to either
2024-09-18T12:34Z (original:#12379) Birds are great! (Whoops, fixed a typo.)
or
2024-09-18T12:34Z (original:#12379) The earth is flat!
The actual original message is (potentially) gone. The only thing that we can be sure of now is that the twt was edited in *some* way. *Essentially*, the actual twt message is no longer part of the hash, is it? What does #12379 refer to? The edited message or the original one? We *want* it to refer to the edited one, because we don’t want to break threads, so … what’s the point of using a hash?
I’m not advocating in either direction, btw. I haven’t made up my mind yet. 😅 Just braindumping here.
The (replyto:…) proposal is definitely more in the spirit of twtxt, I’d say. It’s much simpler, anyone can use it even with the simplest tools, no need for any client code. That is certainly a great property, if you ask me, and it’s things like that that brought me to twtxt in the first place.
I’d also say that in our tiny little community, message integrity simply doesn’t matter. Signed feeds don’t matter. I signed my feed for a while using GPG, someone else did the same, but in the end, nobody cares. The community is so tiny, there’s enough “implicit trust” or whatever you want to call it.
If twtxt/Yarn was to grow bigger, then this would become a concern again. *But even Mastodon allows editing*, so how much of a problem can it really be? 😅
I do have to “admit”, though, that hashes *feel* better. It feels good to know that we can clearly identify a certain twt. It feels more correct and stable.
Hm.
I *suspect* that the (replyto:…) proposal would work just as well in practice.
I’m not advocating in either direction, btw. I haven’t made up my mind yet. 😅 Just braindumping here.
The (replyto:…) proposal is definitely more in the spirit of twtxt, I’d say. It’s much simpler, anyone can use it even with the simplest tools, no need for any client code. That is certainly a great property, if you ask me, and it’s things like that that brought me to twtxt in the first place.
I’d also say that in our tiny little community, message integrity simply doesn’t matter. Signed feeds don’t matter. I signed my feed for a while using GPG, someone else did the same, but in the end, nobody cares. The community is so tiny, there’s enough “implicit trust” or whatever you want to call it.
If twtxt/Yarn was to grow bigger, then this would become a concern again. *But even Mastodon allows editing*, so how much of a problem can it really be? 😅
I do have to “admit”, though, that hashes *feel* better. It feels good to know that we can clearly identify a certain twt. It feels more correct and stable.
Hm.
I *suspect* that the (replyto:…) proposal would work just as well in practice.
I’m not advocating in either direction, btw. I haven’t made up my mind yet. 😅 Just braindumping here.
The (replyto:…) proposal is definitely more in the spirit of twtxt, I’d say. It’s much simpler, anyone can use it even with the simplest tools, no need for any client code. That is certainly a great property, if you ask me, and it’s things like that that brought me to twtxt in the first place.
I’d also say that in our tiny little community, message integrity simply doesn’t matter. Signed feeds don’t matter. I signed my feed for a while using GPG, someone else did the same, but in the end, nobody cares. The community is so tiny, there’s enough “implicit trust” or whatever you want to call it.
If twtxt/Yarn was to grow bigger, then this would become a concern again. *But even Mastodon allows editing*, so how much of a problem can it really be? 😅
I do have to “admit”, though, that hashes *feel* better. It feels good to know that we can clearly identify a certain twt. It feels more correct and stable.
Hm.
I *suspect* that the (replyto:…) proposal would work just as well in practice.
I’m not advocating in either direction, btw. I haven’t made up my mind yet. 😅 Just braindumping here.
The (replyto:…) proposal is definitely more in the spirit of twtxt, I’d say. It’s much simpler, anyone can use it even with the simplest tools, no need for any client code. That is certainly a great property, if you ask me, and it’s things like that that brought me to twtxt in the first place.
I’d also say that in our tiny little community, message integrity simply doesn’t matter. Signed feeds don’t matter. I signed my feed for a while using GPG, someone else did the same, but in the end, nobody cares. The community is so tiny, there’s enough “implicit trust” or whatever you want to call it.
If twtxt/Yarn was to grow bigger, then this would become a concern again. *But even Mastodon allows editing*, so how much of a problem can it really be? 😅
I do have to “admit”, though, that hashes *feel* better. It feels good to know that we can clearly identify a certain twt. It feels more correct and stable.
Hm.
I *suspect* that the (replyto:…) proposal would work just as well in practice.
(Or maybe I’m talking nonsense. That’s known to happen. I’ll go to bed. 😂)
(Or maybe I’m talking nonsense. That’s known to happen. I’ll go to bed. 😂)
(Or maybe I’m talking nonsense. That’s known to happen. I’ll go to bed. 😂)
(Or maybe I’m talking nonsense. That’s known to happen. I’ll go to bed. 😂)
@movq Agreed that hashes have a benefit. I came up with a similar example where when I twted about an 11-character hash collision. Perhaps hashes could be made optional somehow. Like, you could use the "replyto" idea and then additionally put a hash somewhere if you want to lock in which version of the twt you are replying to.
One distinct disadvantage of (replyto:…) over (edit:#): (replyto:…) relies on clients always processing the entire feed – otherwise they wouldn’t even notice when a twt gets updated. a) This is more expensive, b) you cannot edit twts once they get rotated into an archived feed, because there is nothing signalling clients that they have to re-fetch that archived feed.
I guess neither matters that much in practice. It’s still a disadvantage.
One distinct disadvantage of (replyto:…) over (edit:#): (replyto:…) relies on clients always processing the entire feed – otherwise they wouldn’t even notice when a twt gets updated. a) This is more expensive, b) you cannot edit twts once they get rotated into an archived feed, because there is nothing signalling clients that they have to re-fetch that archived feed.
I guess neither matters that much in practice. It’s still a disadvantage.
One distinct disadvantage of (replyto:…) over (edit:#): (replyto:…) relies on clients always processing the entire feed – otherwise they wouldn’t even notice when a twt gets updated. a) This is more expensive, b) you cannot edit twts once they get rotated into an archived feed, because there is nothing signalling clients that they have to re-fetch that archived feed.
I guess neither matters that much in practice. It’s still a disadvantage.
One distinct disadvantage of (replyto:…) over (edit:#): (replyto:…) relies on clients always processing the entire feed – otherwise they wouldn’t even notice when a twt gets updated. a) This is more expensive, b) you cannot edit twts once they get rotated into an archived feed, because there is nothing signalling clients that they have to re-fetch that archived feed.
I guess neither matters that much in practice. It’s still a disadvantage.