# 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 17
# self = https://watcher.sour.is/conv/ck2oria
@fastidious Yep, exactly. Broken threading. That’s how I noticed in the first place. 🙃\n\nIt’s unfortunate that editing twts breaks threading. Are there alternatives? The only thing I can think of is adding explicit IDs to all twts (like Message-ID and In-Reply-To). I think @lyse already mentioned/proposed this a while ago. The downside of this is that it makes twt feeds *even more* noisy for users who use traditional clients (or no client at all). 🤔
@fastidious Yep, exactly. Broken threading. That’s how I noticed in the first place. 🙃
It’s unfortunate that editing twts breaks threading. Are there alternatives? The only thing I can think of is adding explicit IDs to all twts (like Message-ID and In-Reply-To). I think @lyse already mentioned/proposed this a while ago. The downside of this is that it makes twt feeds *even more* noisy for users who use traditional clients (or no client at all). 🤔
@fastidious Yep, exactly. Broken threading. That’s how I noticed in the first place. 🙃
It’s unfortunate that editing twts breaks threading. Are there alternatives? The only thing I can think of is adding explicit IDs to all twts (like Message-ID and In-Reply-To). I think @lyse already mentioned/proposed this a while ago. The downside of this is that it makes twt feeds *even more* noisy for users who use traditional clients (or no client at all). 🤔
@fastidious Yep, exactly. Broken threading. That’s how I noticed in the first place. 🙃
It’s unfortunate that editing twts breaks threading. Are there alternatives? The only thing I can think of is adding explicit IDs to all twts (like Message-ID and In-Reply-To). I think @lyse already mentioned/proposed this a while ago. The downside of this is that it makes twt feeds *even more* noisy for users who use traditional clients (or no client at all). 🤔
@movq Yes, this is the only reliable way. Everything else is just a quirk. One could put place the message ID in the third field and the reply ID in the fourth to help the purists without clients.
@movq
With those two (Message-ID, and In-Reply-To) the hashing could become superfluous, and no longer needed. I would vote for that!
@movq \nWith those two (Message-ID, and In-Reply-To) the hashing could become superfluous, and no longer needed. I would vote for that!
@quark It is then a very different format, though. Not twtxt anymore. All the extensions we're having now are still backwards-compatible to the original spec. Granted, they don't really work without client support, but technically it's still compatible. At the moment I'm not sold on redoing everything. But a version 2 would allow to fix a couple of things. E.g. feed relocation and stuff like that.
@lyse I was thinking: “If we just put these two fields at the start of the twtxt message (like we do now with mentions and subject hash), it would be backwards-compatible as well. 🤔” But then I remembered: If people write twts the old way (without the two new fields), how do we reply to them? They don’t have an ID. So we’d probably need the current hashing method as a *fallback* – and then we wouldn’t have made a lot of progress compared to the current version. 🤔
@lyse I was thinking: “If we just put these two fields at the start of the twtxt message (like we do now with mentions and subject hash), it would be backwards-compatible as well. 🤔” But then I remembered: If people write twts the old way (without the two new fields), how do we reply to them? They don’t have an ID. So we’d probably need the current hashing method as a *fallback* – and then we wouldn’t have made a lot of progress compared to the current version. 🤔
@lyse I was thinking: “If we just put these two fields at the start of the twtxt message (like we do now with mentions and subject hash), it would be backwards-compatible as well. 🤔” But then I remembered: If people write twts the old way (without the two new fields), how do we reply to them? They don’t have an ID. So we’d probably need the current hashing method as a *fallback* – and then we wouldn’t have made a lot of progress compared to the current version. 🤔
@movq Ah, I see. Yes, the fallback would still be needed and thus, doesn't really change the world. In fact there are now two ways to produce message IDs and if one client doesn't adpopt to the new message ID field, conversations are forking themselves automatically in a rather ugly way.
@lyse
Bottomline, twtxt is a poor's man email system. 🤣
@lyse \nBottomline, twtxt is a poor's man email system. 🤣
@lyse @quark It’s actually a pretty decent microblogging and social media if we stick to what we’ve built 😆
@lyse @quark It’s actually a pretty decent microblogging and social media if we stick to what we’ve built 😆