# 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 86
# self = https://watcher.sour.is/conv/v5yaeha
@anth I was reluctant, too, at first, but proper threading seriously improves the twtxt experience. This should have been built-in from the start.
@anth I was reluctant, too, at first, but proper threading seriously improves the twtxt experience. This should have been built-in from the start.
@anth I was reluctant, too, at first, but proper threading seriously improves the twtxt experience. This should have been built-in from the start.
@movq I _really_ appreciate you saying this! Thank you! 🙇♂️ To be fair @anth we just took something that we were observing happening in the real-world and "formalized" it. You can thanks @dbohdan for the initial work on Twt Hash(es) really, and @lyse for making a a format document for it!
@movq I _really_ appreciate you saying this! Thank you! 🙇♂️ To be fair @anth we just took something that we were observing happening in the real-world and "formalized" it. You can thanks @dbohdan for the initial work on Twt Hash(es) really, and @lyse for making a a format document for it!
@movq I _really_ appreciate you saying this! Thank you! 🙇♂️ To be fair @anth we just took something that we were observing happening in the real-world and "formalized" it. You can thanks @dbohdan for the initial work on Twt Hash(es) really, and @lyse for making a a format document for it!
@anth @movq @prologic The hashes are certainly not very elegant, but as an afterthought make the twtxt universe much more pleasant as movq said. Are you really reading the twts in in its raw form, anth?
@lyse How _could_ they be made "more elegant"? 🤔 Is it just a presentation thing? (UX)?
@lyse How _could_ they be made "more elegant"? 🤔 Is it just a presentation thing? (UX)?
@lyse How _could_ they be made "more elegant"? 🤔 Is it just a presentation thing? (UX)?
@prologic @lyse @anth One way to make the raw txt easier to read would be to move the (hash) to the end of the line. Another thing would be to add re: to it so it would be cleared that code-thing is a reply or is in relations/reaction to something else (re: #v5yaeha) (#v5yaeha)
If we're strictly talking about about presentation / UX issues here, @xuu already largely solved this already in changes to how the parser works. See for example:
It would just be a matter of stripping out the "Twt Subject" out now from the presentation layer. But somehow I don't think @anth is talking about this, or is using an old client with a more bland UX?
If we're strictly talking about about presentation / UX issues here, @xuu already largely solved this already in changes to how the parser works. See for example:\n\n \n\nIt would just be a matter of stripping out the "Twt Subject" out now from the presentation layer. But somehow I don't think @anth is talking about this, or is using an old client with a more bland UX?
If we're strictly talking about about presentation / UX issues here, @xuu already largely solved this already in changes to how the parser works. See for example:
It would just be a matter of stripping out the "Twt Subject" out now from the presentation layer. But somehow I don't think @anth is talking about this, or is using an old client with a more bland UX?
If we're strictly talking about about presentation / UX issues here, @xuu already largely solved this already in changes to how the parser works. See for example:\n\n \n\nIt would just be a matter of stripping out the "Twt Subject" out now from the presentation layer. But somehow I don't think @anth is talking about this, or is using an old client with a more bland UX?
@darch @prologic Technically it should be at the start.. Though the parser doesn't currently care where it is. Though that leads to artifacts like any random string inside perens becoming a subject.
@darch @prologic Technically it should be at the start.. Though the parser doesn't currently care where it is. Though that leads to artifacts like any random string inside perens becoming a subject.
@darch @prologic Technically it should be at the start.. Though the parser doesn't currently care where it is. Though that leads to artifacts like any random string inside perens becoming a subject.
@darch @prologic Technically it should be at the start.. Though the parser doesn't currently care where it is. Though that leads to artifacts like any random string inside perens becoming a subject.
@anth @movq @prologic @darch @xuu In my opinion twt hash and subject ideally would be dedicated fields in a twt, similar to Message-ID and In-Reply-To e-mail headers. Something like timestamp \t twt-id \t reply-id \t text. But since twtxt was invented as simple "status" thingies, nobody thought of replies in the beginning, I reckon. And then it happend, what will usually be the case: people use it differently than originally imagined. So the twt hash and twt subjects were bolted on. It obviously works, but it also has its drawbacks. If the originating client would generate a globally unique ID, we wouldn't have the problem of updated twts breaking conversations.
@anth @movq @prologic @darch @xuu In my opinion twt hash and subject ideally would be dedicated fields in a twt, similar to Message-ID and In-Reply-To e-mail headers. Something like timestamp \\t twt-id \\t reply-id \\t text. But since twtxt was invented as simple "status" thingies, nobody thought of replies in the beginning, I reckon. And then it happend, what will usually be the case: people use it differently than originally imagined. So the twt hash and twt subjects were bolted on. It obviously works, but it also has its drawbacks. If the originating client would generate a globally unique ID, we wouldn't have the problem of updated twts breaking conversations.
@anth @movq @prologic @lyse @darch @xuu Yes, the presentation layer can fix a few things. My client hides the subjects completely to save space and I rarely care about the exact hashes. For debugging they can come in handy.
@lyse 100% agree. Fun fact: Couldn’t we actually do that? I mean timestamp \t twt-id \t reply-id \t text. Older clients would just include the IDs in the message, but they wouldn’t break. (I should shut up about extending the format, though. I was *super* skeptical about @prologic’s twtxt.net extensions at first and voiced my opinion on various occasions. I see it a bit differently now, especially since the original twtxt community appears to be pretty much dead, so … maybe there’s room for twtxt 2.0? Maybe not? I don’t know. I don’t want this little community to divide even more. 😨)
@lyse 100% agree. Fun fact: Couldn’t we actually do that? I mean timestamp \t twt-id \t reply-id \t text. Older clients would just include the IDs in the message, but they wouldn’t break. (I should shut up about extending the format, though. I was *super* skeptical about @prologic’s twtxt.net extensions at first and voiced my opinion on various occasions. I see it a bit differently now, especially since the original twtxt community appears to be pretty much dead, so … maybe there’s room for twtxt 2.0? Maybe not? I don’t know. I don’t want this little community to divide even more. 😨)
@lyse 100% agree. Fun fact: Couldn’t we actually do that? I mean timestamp \\t twt-id \\t reply-id \\t text. Older clients would just include the IDs in the message, but they wouldn’t break. (I should shut up about extending the format, though. I was *super* skeptical about @prologic’s twtxt.net extensions at first and voiced my opinion on various occasions. I see it a bit differently now, especially since the original twtxt community appears to be pretty much dead, so … maybe there’s room for twtxt 2.0? Maybe not? I don’t know. I don’t want this little community to divide even more. 😨)
@lyse 100% agree. Fun fact: Couldn’t we actually do that? I mean timestamp \t twt-id \t reply-id \t text. Older clients would just include the IDs in the message, but they wouldn’t break. (I should shut up about extending the format, though. I was *super* skeptical about @prologic’s twtxt.net extensions at first and voiced my opinion on various occasions. I see it a bit differently now, especially since the original twtxt community appears to be pretty much dead, so … maybe there’s room for twtxt 2.0? Maybe not? I don’t know. I don’t want this little community to divide even more. 😨)
And just to be clear, without the work on twtxt.net by @prologic and you other people, twtxt would be very very dead now. That would be a shame. I really appreciate your efforts!
And just to be clear, without the work on twtxt.net by @prologic and you other people, twtxt would be very very dead now. That would be a shame. I really appreciate your efforts!
And just to be clear, without the work on twtxt.net by @prologic and you other people, twtxt would be very very dead now. That would be a shame. I really appreciate your efforts!
I don't have any issue with the (foo) subjects, it's the proliferation of the (foo url) tags. They're just too long and ugly.
I don't have any issue with the (foo) subjects, it's the proliferation of the (foo url) tags. They're just too long and ugly.
@movq No argument that threading is an improvement. But I think (#hash) does that, and I think figuring out how to search should mostly be up to the client.
@movq No argument that threading is an improvement. But I think (#hash) does that, and I think figuring out how to search should mostly be up to the client.
@lyse Yes, I often read the raw messages. But more to the point, the simplicity of the format is the bulk of the appeal.
@lyse Yes, I often read the raw messages. But more to the point, the simplicity of the format is the bulk of the appeal.
@anth @lyse @movq Actually... I _think_ we could change the Twt Hash extension a bit here and remove the need to fully qualify and expand them into full URLs. The reason we did that in the first place was we were just extending the @<nick url> syntax from the original spec and just using a different prefix @ for mentions # for tags, etc. But this is probably unnecessary as the hashes themselves are content addresses and don't need to be URLs. Hmmm? 🤔
@anth @lyse @movq Actually... I _think_ we could change the Twt Hash extension a bit here and remove the need to fully qualify and expand them into full URLs. The reason we did that in the first place was we were just extending the @<nick url> syntax from the original spec and just using a different prefix @ for mentions # for tags, etc. But this is probably unnecessary as the hashes themselves are content addresses and don't need to be URLs. Hmmm? 🤔
@anth @lyse @movq Actually... I _think_ we could change the Twt Hash extension a bit here and remove the need to fully qualify and expand them into full URLs. The reason we did that in the first place was we were just extending the @<nick url> syntax from the original spec and just using a different prefix @ for mentions # for tags, etc. But this is probably unnecessary as the hashes themselves are content addresses and don't need to be URLs. Hmmm? 🤔
@movq As for developing a Twtxt 2.0 spec/format/protocol, I'm not sure. On one hand @buckket _seems_ to be quite upset that we've used his format/spec and named a "codebase" with a similar/identical name or something, actually I'm not really sure I'm just guessing, but its part of the rebranding issue at place here... So maybe we should? Maybe we should just develop our own protocol entirely? I'm not sure. It really isn't up to me per se now as there is a community to think about that spans multiple pods now.
@movq As for developing a Twtxt 2.0 spec/format/protocol, I'm not sure. On one hand @buckket _seems_ to be quite upset that we've used his format/spec and named a "codebase" with a similar/identical name or something, actually I'm not really sure I'm just guessing, but its part of the rebranding issue at place here... So maybe we should? Maybe we should just develop our own protocol entirely? I'm not sure. It really isn't up to me per se now as there is a community to think about that spans multiple pods now.
@movq As for developing a Twtxt 2.0 spec/format/protocol, I'm not sure. On one hand @buckket _seems_ to be quite upset that we've used his format/spec and named a "codebase" with a similar/identical name or something, actually I'm not really sure I'm just guessing, but its part of the rebranding issue at place here... So maybe we should? Maybe we should just develop our own protocol entirely? I'm not sure. It really isn't up to me per se now as there is a community to think about that spans multiple pods now.
@prologicYes, I think tags should just be #foo, and let the client figure out searching if it cares.
@prologicYes, I think tags should just be #foo, and let the client figure out searching if it cares.
@prologicFor example, this should work (no idea if it does).
@prologicFor example, this should work (no idea if it does).
@prologic Looks like twtxt.net is already happy with it, so that's good! I'm just going to aim for that.
@prologic Looks like twtxt.net is already happy with it, so that's good! I'm just going to aim for that.
@anth Yeah we've always supported both forms. @xuu shall we stop fully expanding tags out?
@anth Yeah we've always supported both forms. @xuu shall we stop fully expanding tags out?
@anth Yeah we've always supported both forms. @xuu shall we stop fully expanding tags out?
@prologic @anth Sounds like a good idea. The hash to conv/search url should stay local to a pod.
@prologic @anth Sounds like a good idea. The hash to conv/search url should stay local to a pod.
@prologic @anth Sounds like a good idea. The hash to conv/search url should stay local to a pod.
@prologic @anth Sounds like a good idea. The hash to conv/search url should stay local to a pod.
Indeed, using the shortest form possible (see this twt) would be nice. I’ll change my client accordingly. 👍
Indeed, using the shortest form possible (see this twt) would be nice. I’ll change my client accordingly. 👍
Indeed, using the shortest form possible (see this twt) would be nice. I’ll change my client accordingly. 👍
Or is it? Discoverability is an issue with twtxt. Without the URL, I have absolutely no idea which thread this might belong to *if I’m reading a completely new feed*. But with the URL, I can visit https://twtxt.net/conv/v5yaeha and see what’s going on. Hmmm … #ConfusedBrain
Or is it? Discoverability is an issue with twtxt. Without the URL, I have absolutely no idea which thread this might belong to *if I’m reading a completely new feed*. But with the URL, I can visit https://twtxt.net/conv/v5yaeha and see what’s going on. Hmmm … #ConfusedBrain
Or is it? Discoverability is an issue with twtxt. Without the URL, I have absolutely no idea which thread this might belong to *if I’m reading a completely new feed*. But with the URL, I can visit https://twtxt.net/conv/v5yaeha and see what’s going on. Hmmm … #ConfusedBrain
@anth @movq @prologic @darch @xuu @anth Ah, I understand that, anth. But the noisy mentions alone make it quite terrible to read the raw form, so I really wouldn't want to refrain from a client folding them. Before we make any more changes we should carefully think all this through. Discoverability is a valid problem, I fall back to the twtxt.net URL scheme for hash tags in my client, but this may not work all the time, if there are conversations on other twtds not connected with twtxt.net (hadn't happen so far, but could be easily the case if the twtxt/twtd universe grows).
@prologic @vain This captures my sentiments on both points absolutely perfectly! 😁🤗
@prologic @vain This captures my sentiments on both points absolutely perfectly! 😁🤗
The point re discoverability is an important one. I have to admit I didn't think of that myself, funny how things get used unexpectedly. 😀 As @lyse points out I _would_ think about changing this rather carefully, the point about mentions also causing noise when reading the raw form is also quite valid. IHMO clients should be presenting Twts in a nice readable form and provide a good UX.
The point re discoverability is an important one. I have to admit I didn't think of that myself, funny how things get used unexpectedly. 😀 As @lyse points out I _would_ think about changing this rather carefully, the point about mentions also causing noise when reading the raw form is also quite valid. IHMO clients should be presenting Twts in a nice readable form and provide a good UX.
The point re discoverability is an important one. I have to admit I didn't think of that myself, funny how things get used unexpectedly. 😀 As @lyse points out I _would_ think about changing this rather carefully, the point about mentions also causing noise when reading the raw form is also quite valid. IHMO clients should be presenting Twts in a nice readable form and provide a good UX.
Another thought... The way the tags and the parser @xuu wrote works now, is that, one day we might be able to change the URL they point to, to say a search engine rather than the source pod the conversation started from.
Another thought... The way the tags and the parser @xuu wrote works now, is that, one day we might be able to change the URL they point to, to say a search engine rather than the source pod the conversation started from.
Another thought... The way the tags and the parser @xuu wrote works now, is that, one day we might be able to change the URL they point to, to say a search engine rather than the source pod the conversation started from.
@prologic Exactly, but that reduces the argument for URLs in the post. The client should figure out how to search based on the hashtag.
@prologic Exactly, but that reduces the argument for URLs in the post. The client should figure out how to search based on the hashtag.
I agree clients should present things better (part of why I'm writing one!). But that should be additive. There's a reason we're not passing json around.
I agree clients should present things better (part of why I'm writing one!). But that should be additive. There's a reason we're not passing json around.
I agree! But it’s a trade off. how exactly would clients figure out how to do the searching on their own? without some hints like full URI‘s I don’t really see this benefiting clients at all unless you happen to be someone that follows everyone and archives everything and puts it into a search index 🤣
I agree! But it’s a trade off. how exactly would clients figure out how to do the searching on their own? without some hints like full URI‘s I don’t really see this benefiting clients at all unless you happen to be someone that follows everyone and archives everything and puts it into a search index 🤣
I agree! But it’s a trade off. how exactly would clients figure out how to do the searching on their own? without some hints like full URI‘s I don’t really see this benefiting clients at all unless you happen to be someone that follows everyone and archives everything and puts it into a search index 🤣
Fun fact, I always feed twts in their raw form. Was a bit noisy at first, yes, but I got used to it really fast. 🤔 Not to say there’s no room for improvement, but it’s also not a complete disaster.
Fun fact, I always feed twts in their raw form. Was a bit noisy at first, yes, but I got used to it really fast. 🤔 Not to say there’s no room for improvement, but it’s also not a complete disaster.
Fun fact, I always feed twts in their raw form. Was a bit noisy at first, yes, but I got used to it really fast. 🤔 Not to say there’s no room for improvement, but it’s also not a complete disaster.
@movq @prologic @darch @xuu @anth @jlj I'm composing in raw form, too. While this works quite nicely, I certainly don't want to have to read all of them in raw. Maybe I should take a look at implementing some kind of crude syntax highlighting in my compose form.
Sorry for the _very_ delayed response (_I've been sick all week :/_), but I just remembered that one of the benefits of using full URLs for Tags or Twt Hashes (_which are themselves tags_) is for cross-pod discovery. An example came up the other day when @jlj responded to a Twt that came from an RSS/Atom -> Twtxt aggregation that I didn't follow so I only saw his side of the "conv". I just follow the tag though to his pod, then the conversation from there. So its useful from that perspective.
Sorry for the _very_ delayed response (_I've been sick all week :/_), but I just remembered that one of the benefits of using full URLs for Tags or Twt Hashes (_which are themselves tags_) is for cross-pod discovery. An example came up the other day when @jlj responded to a Twt that came from an RSS/Atom -> Twtxt aggregation that I didn't follow so I only saw his side of the "conv". I just follow the tag though to his pod, then the conversation from there. So its useful from that perspective.
Sorry for the _very_ delayed response (_I've been sick all week :/_), but I just remembered that one of the benefits of using full URLs for Tags or Twt Hashes (_which are themselves tags_) is for cross-pod discovery. An example came up the other day when @jlj responded to a Twt that came from an RSS/Atom -> Twtxt aggregation that I didn't follow so I only saw his side of the "conv". I just follow the tag though to his pod, then the conversation from there. So its useful from that perspective.
In addition we (@xuu and I) are looking to start building out support for Distributed Tags which will make this whole thing make a lot more sense -- At least between pods, but even regular twtxt clients _could_ pull tags too into their cache.
In addition we (@xuu and I) are looking to start building out support for Distributed Tags which will make this whole thing make a lot more sense -- At least between pods, but even regular twtxt clients _could_ pull tags too into their cache.
In addition we (@xuu and I) are looking to start building out support for Distributed Tags which will make this whole thing make a lot more sense -- At least between pods, but even regular twtxt clients _could_ pull tags too into their cache.