# 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 22
# self = https://watcher.sour.is/conv/ucgvfmq
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.
@movq going a little sideways on this, "*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? 😅*", wouldn't it preparing for a potential (even if very, very, veeeeery remote) growth be a good thing? Mastodon signs all messages, keeps a history of edits, and it doesn't break threads. It isn't a problem there.😉 It is here.
I think keeping hashes is a must. If anything for that "feels good" feeling.*
@movq going a little sideways on this, "*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? 😅*", wouldn't it preparing for a potential (even if very, very, veeeeery remote) growth be a good thing? Mastodon signs all messages, keeps a history of edits, and it doesn't break threads. It isn't a problem there.😉 It is here.
I think keeping hashes is a must. If anything for that "feels good" feeling.*
@movq it would work, you are right, however, it has drawbacks, and I think in the long term would create a new set of problems that we would also then have to solve.
@movq it would work, you are right, however, it has drawbacks, and I think in the long term would create a new set of problems that we would also then have to solve.
@prologic Can you come up with actual scenarios where it would break? Or is it more of a gut feeling?
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and (replyto:…), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround “to avoid broken threads all the time”.) The net result would be *less code*.
Implementing this whole (edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)
Do you see why I’m so reluctant to jump on this bandwagon? 😅
I haven’t come up yet with good, concrete examples where (replyto:…) would break. As soon as that happens, I’ll change my mind. 🤔
@prologic Can you come up with actual scenarios where it would break? Or is it more of a gut feeling?
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and (replyto:…), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround “to avoid broken threads all the time”.) The net result would be *less code*.
Implementing this whole (edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)
Do you see why I’m so reluctant to jump on this bandwagon? 😅
I haven’t come up yet with good, concrete examples where (replyto:…) would break. As soon as that happens, I’ll change my mind. 🤔
@prologic Can you come up with actual scenarios where it would break? Or is it more of a gut feeling?
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and (replyto:…), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround “to avoid broken threads all the time”.) The net result would be *less code*.
Implementing this whole (edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)
Do you see why I’m so reluctant to jump on this bandwagon? 😅
I haven’t come up yet with good, concrete examples where (replyto:…) would break. As soon as that happens, I’ll change my mind. 🤔
@prologic Can you come up with actual scenarios where it would break? Or is it more of a gut feeling?
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and (replyto:…), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround “to avoid broken threads all the time”.) The net result would be *less code*.
Implementing this whole (edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)
Do you see why I’m so reluctant to jump on this bandwagon? 😅
I haven’t come up yet with good, concrete examples where (replyto:…) would break. As soon as that happens, I’ll change my mind. 🤔
Okay, the recently implemented --fetch-context, which asks a Yarn pod for a twt, wouldn’t *break*, but jenny would not be able anymore to verify that it actually got the correct twt. That’s a concrete example where we would lose functionality.
Okay, the recently implemented --fetch-context, which asks a Yarn pod for a twt, wouldn’t *break*, but jenny would not be able anymore to verify that it actually got the correct twt. That’s a concrete example where we would lose functionality.
Okay, the recently implemented --fetch-context, which asks a Yarn pod for a twt, wouldn’t *break*, but jenny would not be able anymore to verify that it actually got the correct twt. That’s a concrete example where we would lose functionality.
Okay, the recently implemented --fetch-context, which asks a Yarn pod for a twt, wouldn’t *break*, but jenny would not be able anymore to verify that it actually got the correct twt. That’s a concrete example where we would lose functionality.
@movq The more I think about it, the more do I like the location-based addressing. That feels fairly in line with the spirit of twtxt, just like you stated somewhere else.
The big downside for me is that the subjects then become super long.
And if the feed relocates, we end up with broken conversation trees again. Just like nowadays. At least it's not getting worse. :-)
Using the feed URL in there might become a little challenging for new folks, when the twt rotates away into archive feeds. But I reckon, we already have a similar situation with the hashes. So, probably not too bad.
@lyse Right, feed rotation gets ugly. We’d have (replyto:example.com/tw.txt,$timestamp) but maybe that feed doesn’t actually contain that stamp, so you have to got further back … but you should NOT reference an archived feed in your (replyto:…) thingy, it should still be the “main feed URL” (because the contents of archived feeds aren’t stable, see @prologic’s feeds for example). That’s not too great.
Man, I’m completely torn on this. I’d almost prefer not to decide anything. 😂
@lyse Right, feed rotation gets ugly. We’d have (replyto:example.com/tw.txt,$timestamp) but maybe that feed doesn’t actually contain that stamp, so you have to got further back … but you should NOT reference an archived feed in your (replyto:…) thingy, it should still be the “main feed URL” (because the contents of archived feeds aren’t stable, see @prologic’s feeds for example). That’s not too great.
Man, I’m completely torn on this. I’d almost prefer not to decide anything. 😂
@lyse Right, feed rotation gets ugly. We’d have (replyto:example.com/tw.txt,$timestamp) but maybe that feed doesn’t actually contain that stamp, so you have to got further back … but you should NOT reference an archived feed in your (replyto:…) thingy, it should still be the “main feed URL” (because the contents of archived feeds aren’t stable, see @prologic’s feeds for example). That’s not too great.
Man, I’m completely torn on this. I’d almost prefer not to decide anything. 😂
@lyse Right, feed rotation gets ugly. We’d have (replyto:example.com/tw.txt,$timestamp) but maybe that feed doesn’t actually contain that stamp, so you have to got further back … but you should NOT reference an archived feed in your (replyto:…) thingy, it should still be the “main feed URL” (because the contents of archived feeds aren’t stable, see @prologic’s feeds for example). That’s not too great.
Man, I’m completely torn on this. I’d almost prefer not to decide anything. 😂
@movq Yeah, but hashing also uses the main feed URL or whatever is written in the feed's first url metadata field. So, it's not a new problem, it's exactly the same.