# 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 30
# self = https://watcher.sour.is/conv/bawn2ca
movq
www.uninformativ.de
View Thread
All this hash breakage made me wonder if we should try to introduce “message IDs” after all. 😅

But the great thing about the current system is that nobody can spoof message IDs. 🤔 When you think about it, message IDs in e-mails only work because (almost) everybody plays fair. Nothing stops me from using the same Message-ID header in *each and every mail*, that would break e-mail threading all the time.

In Yarn, twt hashes are *derived* from twt content and feed metadata. That is pretty elegant and I’d hate see us lose that property.

If we wanted to allow editing twts, we could do something like this:

2024-09-05T13:37:40+00:00 (~mp6ox4a) Hello world!

Here, mp6ox4a would be a “partial hash”: To get the actual hash of this twt, you’d concatenate the feed’s URL and mp6ox4a and get, say, hlnw5ha. (Pretty similar to the current system.) When people reply to this twt, they would have to do this:

2024-09-05T14:57:14+00:00 (~bpt74ka) (#hlnw5ha) Yes, hello!

That second twt has a partial hash of bpt74ka and is a reply to the full hash hlnw5ha. The author of the “Hello world!” twt could then edit their twt and change it to 2024-09-05T13:37:40+00:00 (~mp6ox4a) Hello friends! or whatever. Threading wouldn’t break.

Would this be worth it? It’s certainly not backwards-compatible. 😂
movq
www.uninformativ.de
View Thread
All this hash breakage made me wonder if we should try to introduce “message IDs” after all. 😅

But the great thing about the current system is that nobody can spoof message IDs. 🤔 When you think about it, message IDs in e-mails only work because (almost) everybody plays fair. Nothing stops me from using the same Message-ID header in *each and every mail*, that would break e-mail threading all the time.

In Yarn, twt hashes are *derived* from twt content and feed metadata. That is pretty elegant and I’d hate see us lose that property.

If we wanted to allow editing twts, we could do something like this:

2024-09-05T13:37:40+00:00 (~mp6ox4a) Hello world!

Here, mp6ox4a would be a “partial hash”: To get the actual hash of this twt, you’d concatenate the feed’s URL and mp6ox4a and get, say, hlnw5ha. (Pretty similar to the current system.) When people reply to this twt, they would have to do this:

2024-09-05T14:57:14+00:00 (~bpt74ka) (#hlnw5ha) Yes, hello!

That second twt has a partial hash of bpt74ka and is a reply to the full hash hlnw5ha. The author of the “Hello world!” twt could then edit their twt and change it to 2024-09-05T13:37:40+00:00 (~mp6ox4a) Hello friends! or whatever. Threading wouldn’t break.

Would this be worth it? It’s certainly not backwards-compatible. 😂
movq
www.uninformativ.de
View Thread
All this hash breakage made me wonder if we should try to introduce “message IDs” after all. 😅

But the great thing about the current system is that nobody can spoof message IDs. 🤔 When you think about it, message IDs in e-mails only work because (almost) everybody plays fair. Nothing stops me from using the same Message-ID header in *each and every mail*, that would break e-mail threading all the time.

In Yarn, twt hashes are *derived* from twt content and feed metadata. That is pretty elegant and I’d hate see us lose that property.

If we wanted to allow editing twts, we could do something like this:

2024-09-05T13:37:40+00:00 (~mp6ox4a) Hello world!

Here, mp6ox4a would be a “partial hash”: To get the actual hash of this twt, you’d concatenate the feed’s URL and mp6ox4a and get, say, hlnw5ha. (Pretty similar to the current system.) When people reply to this twt, they would have to do this:

2024-09-05T14:57:14+00:00 (~bpt74ka) (#hlnw5ha) Yes, hello!

That second twt has a partial hash of bpt74ka and is a reply to the full hash hlnw5ha. The author of the “Hello world!” twt could then edit their twt and change it to 2024-09-05T13:37:40+00:00 (~mp6ox4a) Hello friends! or whatever. Threading wouldn’t break.

Would this be worth it? It’s certainly not backwards-compatible. 😂
prologic
twtxt.net
View Thread
@movq Sorry but what's a partial hash exactly? 🤔
prologic
twtxt.net
View Thread
@movq Sorry but what's a partial hash exactly? 🤔
lyse
lyse.isobeef.org
View Thread
@movq It sounds complicated. After reading it only twice, I haven't gotten it. :-D

Yes, I'm all for dedicated message IDs. That would be a whole new format then. But I would be fine with it. The only thing is that all our clients have to be touched. At the moment, I do not worry about spoofing (however, I definitely should).
prologic
twtxt.net
View Thread
To be honest, I don't really see "editing" as a problem. I see that as a natural behavior of "forking" in the first place, that just forms a. new sub-tree. What's _really_ problematic here is when a feed author changes the "identity" of their feed and changes the # url = metadata field, which is what I _believe_ @cuaxolotl has just done, though I'm not 100% certain, I'm like 98% sure haha 😝
prologic
twtxt.net
View Thread
To be honest, I don't really see "editing" as a problem. I see that as a natural behavior of "forking" in the first place, that just forms a. new sub-tree. What's _really_ problematic here is when a feed author changes the "identity" of their feed and changes the # url = metadata field, which is what I _believe_ @cuaxolotl has just done, though I'm not 100% certain, I'm like 98% sure haha 😝
prologic
twtxt.net
View Thread
For supporting edits, I was thinking more along the lines of: If a client edits a Twt already published, it _should_ put the hash of the previous Twt. Something like:


2024-09-05T13:37:40+00:00   (edit:mp6ox4a) Hello world!
prologic
twtxt.net
View Thread
For supporting edits, I was thinking more along the lines of: If a client edits a Twt already published, it _should_ put the hash of the previous Twt. Something like:


2024-09-05T13:37:40+00:00   (edit:mp6ox4a) Hello world!
prologic
twtxt.net
View Thread
For supporting edits, I was thinking more along the lines of: If a client edits a Twt already published, it _should_ put the hash of the previous Twt. Something like:


2024-09-05T13:37:40Z   (edit:mp6ox4a) Hello world!
prologic
twtxt.net
View Thread
For supporting edits, I was thinking more along the lines of: If a client edits a Twt already published, it _should_ put the hash of the previous Twt. Something like:


2024-09-05T13:37:40Z   (edit:mp6ox4a) Hello world!
prologic
twtxt.net
View Thread
After unfollowing and refollowing on the new feed URL, I'm now 100% certain this is what happened for @cuaxolotl 🤣 The _real_ problem is really this:

> How do we identify a feed?

It cannot be the URL, because the author _could_ change where they serve it from. This was as "good" as we could get it, but time and time again this has proven to be problematic for, well, a few folks that change their mind, which frankly should be allowed 😅
prologic
twtxt.net
View Thread
After unfollowing and refollowing on the new feed URL, I'm now 100% certain this is what happened for @cuaxolotl 🤣 The _real_ problem is really this:

> How do we identify a feed?

It cannot be the URL, because the author _could_ change where they serve it from. This was as "good" as we could get it, but time and time again this has proven to be problematic for, well, a few folks that change their mind, which frankly should be allowed 😅
falsifian
www.falsifian.org
View Thread
@movq @prologic Another option would be: when you edit a twt, prefix the new one with (#[old hash]) and some indication that it's an edited version of the original tweet with that hash. E.g. if the hash used to be abcd123, the new version should start "(#abcd123) (redit)".

What I like about this is that clients that don't know this convention will still stick it in the same thread. And I feel it's in the spirit of the old pre-hash (subject) convention, though that's before my time.

I guess it may not work when the edited twt itself is a reply, and there are replies to it. Maybe that could be solved by letting twts have more than one (subject) prefix.

> But the great thing about the current system is that nobody can spoof message IDs.

I don't think twtxt hashes are long enough to prevent spoofing.
falsifian
www.falsifian.org
View Thread
@movq @prologic Another option would be: when you edit a twt, prefix the new one with (#\n) and some indication that it's an edited version of the original tweet with that hash. E.g. if the hash used to be abcd123, the new version should start "(#abcd123) (redit)".

What I like about this is that clients that don't know this convention will still stick it in the same thread. And I feel it's in the spirit of the old pre-hash (subject) convention, though that's before my time.

I guess it may not work when the edited twt itself is a reply, and there are replies to it. Maybe that could be solved by letting twts have more than one (subject) prefix.

> But the great thing about the current system is that nobody can spoof message IDs.

I don't think twtxt hashes are long enough to prevent spoofing.
prologic
twtxt.net
View Thread
@falsifian I like this idea actually for edits.
prologic
twtxt.net
View Thread
@falsifian I like this idea actually for edits.
bender
twtxt.net
View Thread
@prologic I kind of want to think of twtxts as chalk text written on a board hanging in front of the user’s house. As the user is in full control of their own board, they can erase, and rewrite it as they deem fit.

So, how to reply, and engage with something that can potentially change? I think the email based message-id, and in-reply-to would work best, without the rigid boundary of a hash that’s bound to break on edit.
prologic
twtxt.net
View Thread
@bender The problem with the approach Email clients do things is;

- How do you come up with the message/thread id in the first place? I'm pretty sure most clients just use a UUID.
- How do you know what you're replying to if you don't see the message/thread id in the first place?
- How do two different users that don't know each other, but follow the same feed (say /.) make two independent responses forming a thread? What message/thread id do they use? (see above)
prologic
twtxt.net
View Thread
@bender The problem with the approach Email clients do things is;

- How do you come up with the message/thread id in the first place? I'm pretty sure most clients just use a UUID.
- How do you know what you're replying to if you don't see the message/thread id in the first place?
- How do two different users that don't know each other, but follow the same feed (say /.) make two independent responses forming a thread? What message/thread id do they use? (see above)
prologic
twtxt.net
View Thread
I _think_ Email Message-Id(s) only ever worked because typically you are exchanging emails with recipients you know and vice versa. It's much easier to cope with the problems above, because you just ensure your client preserves the Message-Id. Email is a federated system, but by no means is it "decentralised". You still have to send your email somewhere, not just post it on a website on your own server like Twtxt 😅

There are some subtitles differences like this that makes Message/Thread Id(s) not really that suitable IMO.
prologic
twtxt.net
View Thread
I _think_ Email Message-Id(s) only ever worked because typically you are exchanging emails with recipients you know and vice versa. It's much easier to cope with the problems above, because you just ensure your client preserves the Message-Id. Email is a federated system, but by no means is it "decentralised". You still have to send your email somewhere, not just post it on a website on your own server like Twtxt 😅

There are some subtitles differences like this that makes Message/Thread Id(s) not really that suitable IMO.
prologic
twtxt.net
View Thread
We _can_ also make use of comments in the feed to build support for detecting/declaring Twts(s) were edited in a feed that are ignored by clients that don't understand the comments. By design clients ignore comments anyway, but the parser we build for yarnd (_which I'd love to turn into a C library that others can just import_) can do some interesting things here. @xuu can probably talk more on this...
prologic
twtxt.net
View Thread
We _can_ also make use of comments in the feed to build support for detecting/declaring Twts(s) were edited in a feed that are ignored by clients that don't understand the comments. By design clients ignore comments anyway, but the parser we build for yarnd (_which I'd love to turn into a C library that others can just import_) can do some interesting things here. @xuu can probably talk more on this...
falsifian
www.falsifian.org
View Thread
@movq Another idea: just hash the feed url and time, without the message content. And don't twt more than once per second.

Maybe you could even just use the time, and rely on -mentions to disambiguate. Not sure how that would work out.

Though I kind of like the idea of twts being immutable. At least, it's clear which version of a twt you're replying to (assuming nobody is engineering hash collisions).
movq
www.uninformativ.de
View Thread
Wow, there are a lot of ideas in this thread already. 😃
movq
www.uninformativ.de
View Thread
Wow, there are a lot of ideas in this thread already. 😃
movq
www.uninformativ.de
View Thread
Wow, there are a lot of ideas in this thread already. 😃
movq
www.uninformativ.de
View Thread
Wow, there are a lot of ideas in this thread already. 😃