# 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 37
# self = https://watcher.sour.is/conv/s2dhlvq
I’m still more in favor of (replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to *add* stuff to the protocol.
I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.
I’m still more in favor of (replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to *add* stuff to the protocol.
I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.
I’m still more in favor of (replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to *add* stuff to the protocol.
I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.
I’m still more in favor of (replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to *add* stuff to the protocol.
I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.
@movq One of the biggest reasons I don't like the (replyto:…) proposal (_location addressing vs. content addressing_) is that you just introduce a similar problem down the track, albeit rarer where if a feed changes its location, your thread's "identifiers" are no longer valid, unless those feed authors maintain strict URL redirects, etc. This potentially has the long-term effect of being rather fragile, as opposed to what we have now where an Edit just really causes a natural fork in the thread, which is how "forking" works in the first place.
I realise this is a bit pret here, and it probably doesn't matter a whole lot at our size. But I'm trying to think way ahead, to a point where Twtxt as a "thing" can continue to work and function decades from now, even with the extensions we've built. We've already proven for example that Twts and threads from ~4 years ago still work and are easily looked up haha 😝~
@movq One of the biggest reasons I don't like the (replyto:…) proposal (_location addressing vs. content addressing_) is that you just introduce a similar problem down the track, albeit rarer where if a feed changes its location, your thread's "identifiers" are no longer valid, unless those feed authors maintain strict URL redirects, etc. This potentially has the long-term effect of being rather fragile, as opposed to what we have now where an Edit just really causes a natural fork in the thread, which is how "forking" works in the first place.
I realise this is a bit pret here, and it probably doesn't matter a whole lot at our size. But I'm trying to think way ahead, to a point where Twtxt as a "thing" can continue to work and function decades from now, even with the extensions we've built. We've already proven for example that Twts and threads from ~4 years ago still work and are easily looked up haha 😝~
I like the (replyto:...) as well. If the feed changes, well, it is the same as changing emails (and deleting the old one). No?
@bender Yeah I'll be honest here; I'm not going to be very happy if we go down this "location addressing" route;
- Twt Subjects lose their meaning.
- Twt Subjects cannot be verified without looking up the feed.
- Which may or may not exist anymore or may change.
- Two persons cannot reply to a Twt independently of each other anymore.
_and probably some other properties we'd stand to lose that I'm forgetting about..._
@bender Yeah I'll be honest here; I'm not going to be very happy if we go down this "location addressing" route;
- Twt Subjects lose their meaning.
- Twt Subjects cannot be verified without looking up the feed.
- Which may or may not exist anymore or may change.
- Two persons cannot reply to a Twt independently of each other anymore.
_and probably some other properties we'd stand to lose that I'm forgetting about..._
I just realized the other big property you lose is:
> What if someone completely changes the content of the root of the thread?
Does the Subject reference the feed and timestamp only or the intent too?
I just realized the other big property you lose is:
> What if someone completely changes the content of the root of the thread?
Does the Subject reference the feed and timestamp only or the intent too?
@prologic
Regarding the URL changing issue: That is not a new issue and not addressed by either PR. Do you have some plans to solve this that only works with hashes? 🤔 Is it feed signing? I have to admit here, I forgot most about the feed signing ideas. 🙈
> - Twt Subjects lose their meaning
You mean existing threads in the past? Yeah.
> - Twt Subjects cannot be verified without looking up the feed.
> - Which may or may not exist anymore or may change.
Not sure what you mean? 🤔 But yes, things can change (that’s the point).
> - Two persons cannot reply to a Twt independently of each other anymore.
How so? 🤔 That would be a total show-stopper, I agree. But are you sure that’s going to happen? For example, if people were to reply to this very twt of yours, they would do this:
(replyto:https://twtxt.net/user/prologic/twtxt.txt,2024-09-21T15:22:18Z) foobar
Am I missing something?
@prologic
Regarding the URL changing issue: That is not a new issue and not addressed by either PR. Do you have some plans to solve this that only works with hashes? 🤔 Is it feed signing? I have to admit here, I forgot most about the feed signing ideas. 🙈
> - Twt Subjects lose their meaning
You mean existing threads in the past? Yeah.
> - Twt Subjects cannot be verified without looking up the feed.
> - Which may or may not exist anymore or may change.
Not sure what you mean? 🤔 But yes, things can change (that’s the point).
> - Two persons cannot reply to a Twt independently of each other anymore.
How so? 🤔 That would be a total show-stopper, I agree. But are you sure that’s going to happen? For example, if people were to reply to this very twt of yours, they would do this:
(replyto:https://twtxt.net/user/prologic/twtxt.txt,2024-09-21T15:22:18Z) foobar
Am I missing something?
@prologic
Regarding the URL changing issue: That is not a new issue and not addressed by either PR. Do you have some plans to solve this that only works with hashes? 🤔 Is it feed signing? I have to admit here, I forgot most about the feed signing ideas. 🙈
> - Twt Subjects lose their meaning
You mean existing threads in the past? Yeah.
> - Twt Subjects cannot be verified without looking up the feed.
> - Which may or may not exist anymore or may change.
Not sure what you mean? 🤔 But yes, things can change (that’s the point).
> - Two persons cannot reply to a Twt independently of each other anymore.
How so? 🤔 That would be a total show-stopper, I agree. But are you sure that’s going to happen? For example, if people were to reply to this very twt of yours, they would do this:
(replyto:https://twtxt.net/user/prologic/twtxt.txt,2024-09-21T15:22:18Z) foobar
Am I missing something?
@prologic
Regarding the URL changing issue: That is not a new issue and not addressed by either PR. Do you have some plans to solve this that only works with hashes? 🤔 Is it feed signing? I have to admit here, I forgot most about the feed signing ideas. 🙈
> - Twt Subjects lose their meaning
You mean existing threads in the past? Yeah.
> - Twt Subjects cannot be verified without looking up the feed.
> - Which may or may not exist anymore or may change.
Not sure what you mean? 🤔 But yes, things can change (that’s the point).
> - Two persons cannot reply to a Twt independently of each other anymore.
How so? 🤔 That would be a total show-stopper, I agree. But are you sure that’s going to happen? For example, if people were to reply to this very twt of yours, they would do this:
(replyto:https://twtxt.net/user/prologic/twtxt.txt,2024-09-21T15:22:18Z) foobar
Am I missing something?
@prologic
> I just realized the other big property you lose is:
>
> > What if someone completely changes the content of the root of the thread?
>
> Does the Subject reference the feed and timestamp only or the intent too?
Then the content of that root twt changes. Just like it would with (edit:…). The only difference is that you cannot go back to that person’s feed and find out what the original content was.
In other words, we can’t (reliably) show a little star * like on Mastodon to indicate edits.
@prologic
> I just realized the other big property you lose is:
>
> > What if someone completely changes the content of the root of the thread?
>
> Does the Subject reference the feed and timestamp only or the intent too?
Then the content of that root twt changes. Just like it would with (edit:…). The only difference is that you cannot go back to that person’s feed and find out what the original content was.
In other words, we can’t (reliably) show a little star * like on Mastodon to indicate edits.
@prologic
> I just realized the other big property you lose is:
>
> > What if someone completely changes the content of the root of the thread?
>
> Does the Subject reference the feed and timestamp only or the intent too?
Then the content of that root twt changes. Just like it would with (edit:…). The only difference is that you cannot go back to that person’s feed and find out what the original content was.
In other words, we can’t (reliably) show a little star * like on Mastodon to indicate edits.
@prologic
> I just realized the other big property you lose is:
>
> > What if someone completely changes the content of the root of the thread?
>
> Does the Subject reference the feed and timestamp only or the intent too?
Then the content of that root twt changes. Just like it would with (edit:…). The only difference is that you cannot go back to that person’s feed and find out what the original content was.
In other words, we can’t (reliably) show a little star * like on Mastodon to indicate edits.
@movq That's kind a problem though right?
@movq That's kind a problem though right?
@prologic Kind of. But the (edit:) spec has similar problems in its current form:
1. Post a normal twt with nonsense content, let’s say the content is just a dot “.”.
2. Post an update to that twt, this time filling it with actual content, let’s say: “Birds are great!”
3. Wait for people to reply to your twt (which is the edited one). You might get lots of replies along the lines of “ohhhh, yeah!” or “😍😍😍” or other stuff wholeheartedly agreeing with you.
4. Post another update to the first twt, again changing the content completely, let’s say: “The earth is flat!”
5. Delete your first update from your feed, the one with the birds. Not with (delete:), just remove the line.
6. There’s now a thread with lots of people agreeing to a twt that says “The earth is flat!”
You might be able to see that the original content was just a dot “.”, but the twt that people actually replied to is gone for good and no way to detect that.
This raises two questions:
- The easy question: What do we do when the twt that an (edit:) line refers to is removed *later on* from a feed? We would have to delete that original twt from our caches, including the edit operation. This should be part of the spec.
- The result being a thread without a root, just like it is today. That’s fine.
- The hard question: How do we deal with multiple (potentially malicious or misleading) edits? Do we even want to open that can of worms? People only ever use the original twt hash in their replies, so nobody really knows to which edited version they’re replying. That is very similar to the (replyto:) situation, I think. 🤔
@prologic Kind of. But the (edit:) spec has similar problems in its current form:
1. Post a normal twt with nonsense content, let’s say the content is just a dot “.”.
2. Post an update to that twt, this time filling it with actual content, let’s say: “Birds are great!”
3. Wait for people to reply to your twt (which is the edited one). You might get lots of replies along the lines of “ohhhh, yeah!” or “😍😍😍” or other stuff wholeheartedly agreeing with you.
4. Post another update to the first twt, again changing the content completely, let’s say: “The earth is flat!”
5. Delete your first update from your feed, the one with the birds. Not with (delete:), just remove the line.
6. There’s now a thread with lots of people agreeing to a twt that says “The earth is flat!”
You might be able to see that the original content was just a dot “.”, but the twt that people actually replied to is gone for good and no way to detect that.
This raises two questions:
- The easy question: What do we do when the twt that an (edit:) line refers to is removed *later on* from a feed? We would have to delete that original twt from our caches, including the edit operation. This should be part of the spec.
- The result being a thread without a root, just like it is today. That’s fine.
- The hard question: How do we deal with multiple (potentially malicious or misleading) edits? Do we even want to open that can of worms? People only ever use the original twt hash in their replies, so nobody really knows to which edited version they’re replying. That is very similar to the (replyto:) situation, I think. 🤔
@prologic Kind of. But the (edit:) spec has similar problems in its current form:
1. Post a normal twt with nonsense content, let’s say the content is just a dot “.”.
2. Post an update to that twt, this time filling it with actual content, let’s say: “Birds are great!”
3. Wait for people to reply to your twt (which is the edited one). You might get lots of replies along the lines of “ohhhh, yeah!” or “😍😍😍” or other stuff wholeheartedly agreeing with you.
4. Post another update to the first twt, again changing the content completely, let’s say: “The earth is flat!”
5. Delete your first update from your feed, the one with the birds. Not with (delete:), just remove the line.
6. There’s now a thread with lots of people agreeing to a twt that says “The earth is flat!”
You might be able to see that the original content was just a dot “.”, but the twt that people actually replied to is gone for good and no way to detect that.
This raises two questions:
- The easy question: What do we do when the twt that an (edit:) line refers to is removed *later on* from a feed? We would have to delete that original twt from our caches, including the edit operation. This should be part of the spec.
- The result being a thread without a root, just like it is today. That’s fine.
- The hard question: How do we deal with multiple (potentially malicious or misleading) edits? Do we even want to open that can of worms? People only ever use the original twt hash in their replies, so nobody really knows to which edited version they’re replying. That is very similar to the (replyto:) situation, I think. 🤔
@prologic Kind of. But the (edit:) spec has similar problems in its current form:
1. Post a normal twt with nonsense content, let’s say the content is just a dot “.”.
2. Post an update to that twt, this time filling it with actual content, let’s say: “Birds are great!”
3. Wait for people to reply to your twt (which is the edited one). You might get lots of replies along the lines of “ohhhh, yeah!” or “😍😍😍” or other stuff wholeheartedly agreeing with you.
4. Post another update to the first twt, again changing the content completely, let’s say: “The earth is flat!”
5. Delete your first update from your feed, the one with the birds. Not with (delete:), just remove the line.
6. There’s now a thread with lots of people agreeing to a twt that says “The earth is flat!”
You might be able to see that the original content was just a dot “.”, but the twt that people actually replied to is gone for good and no way to detect that.
This raises two questions:
- The easy question: What do we do when the twt that an (edit:) line refers to is removed *later on* from a feed? We would have to delete that original twt from our caches, including the edit operation. This should be part of the spec.
- The result being a thread without a root, just like it is today. That’s fine.
- The hard question: How do we deal with multiple (potentially malicious or misleading) edits? Do we even want to open that can of worms? People only ever use the original twt hash in their replies, so nobody really knows to which edited version they’re replying. That is very similar to the (replyto:) situation, I think. 🤔
@movq I cases of these kind of "abuse" of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.
@movq I cases of these kind of "abuse" of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.
@movq I cases of these kind of "abuse" of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.
@movq I cases of these kind of "abuse" of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.
@movq I think your scenario doesn't account for clients and their storage. The scenario described only really affects clients that come along later. Even then they would also be able to re-fetch mossing Twts from peers or even a search engine to fill in the gaps.
@movq I think your scenario doesn't account for clients and their storage. The scenario described only really affects clients that come along later. Even then they would also be able to re-fetch mossing Twts from peers or even a search engine to fill in the gaps.
@sorenpeter Lins of agree with dealing with this kind of social nonsense which we've all done in the past 🤣
@sorenpeter Lins of agree with dealing with this kind of social nonsense which we've all done in the past 🤣
@sorenpeter Yes, fully agreed.
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like (replyto:…) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)
For the same reason, GPG signed feeds never took off. It just doesn’t matter. twtxt is small and nieche and that won’t change anytime soon, I think. We only have to make sure that we don’t open the gates for *massive spam* and I think we’re safe on that.
It’s easy to get lost in these scenarios and overshoot the target.
@sorenpeter Yes, fully agreed.
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like (replyto:…) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)
For the same reason, GPG signed feeds never took off. It just doesn’t matter. twtxt is small and nieche and that won’t change anytime soon, I think. We only have to make sure that we don’t open the gates for *massive spam* and I think we’re safe on that.
It’s easy to get lost in these scenarios and overshoot the target.
@sorenpeter Yes, fully agreed.
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like (replyto:…) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)
For the same reason, GPG signed feeds never took off. It just doesn’t matter. twtxt is small and nieche and that won’t change anytime soon, I think. We only have to make sure that we don’t open the gates for *massive spam* and I think we’re safe on that.
It’s easy to get lost in these scenarios and overshoot the target.
@sorenpeter Yes, fully agreed.
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like (replyto:…) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)
For the same reason, GPG signed feeds never took off. It just doesn’t matter. twtxt is small and nieche and that won’t change anytime soon, I think. We only have to make sure that we don’t open the gates for *massive spam* and I think we’re safe on that.
It’s easy to get lost in these scenarios and overshoot the target.