# 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 16
# self = https://watcher.sour.is/conv/hkorztq
prologic
twtxt.net
View Thread
Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
prologic
twtxt.net
View Thread
Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
movq
www.uninformativ.de
View Thread
@prologic

> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.

What you’re mentioning is *the primary reason*, imho, *for* location-based addressing. You’re referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing “raw” twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*’s world). It’s one of the core aspects and main selling points: You just have a file that you can edit with vi or whatever, done.

If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that there’s some kind of big misunderstanding going on here. 🤔 Either on your end or on mine/ours. 🤔
movq
www.uninformativ.de
View Thread
@prologic

> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.

What you’re mentioning is *the primary reason*, imho, *for* location-based addressing. You’re referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing “raw” twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*’s world). It’s one of the core aspects and main selling points: You just have a file that you can edit with vi or whatever, done.

If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that there’s some kind of big misunderstanding going on here. 🤔 Either on your end or on mine/ours. 🤔
movq
www.uninformativ.de
View Thread
@prologic

> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.

What you’re mentioning is *the primary reason*, imho, *for* location-based addressing. You’re referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing “raw” twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*’s world). It’s one of the core aspects and main selling points: You just have a file that you can edit with vi or whatever, done.

If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that there’s some kind of big misunderstanding going on here. 🤔 Either on your end or on mine/ours. 🤔
movq
www.uninformativ.de
View Thread
@prologic

> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.

What you’re mentioning is *the primary reason*, imho, *for* location-based addressing. You’re referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing “raw” twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*’s world). It’s one of the core aspects and main selling points: You just have a file that you can edit with vi or whatever, done.

If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that there’s some kind of big misunderstanding going on here. 🤔 Either on your end or on mine/ours. 🤔
prologic
twtxt.net
View Thread
@movq I don't think there's any misunderstand at all. I just treat every lines in a feed as an individual entity. These are stored on their own.
prologic
twtxt.net
View Thread
@movq I don't think there's any misunderstand at all. I just treat every lines in a feed as an individual entity. These are stored on their own.
prologic
twtxt.net
View Thread
Also you're right I guess. But still that also requires the author not to change the timestamp too. Hmmm
prologic
twtxt.net
View Thread
Also you're right I guess. But still that also requires the author not to change the timestamp too. Hmmm
prologic
twtxt.net
View Thread
Also I'm not even sure I can validly cache, let alone index feeds anymore if we do this, because if the structure of a Twt is cuh that I can no longer trust that an individual Twt's content hasn't been changed at the source, what's the point of caching or indexing individual twts at all? This makes the implementations of yarnd and yarns (_the search engine, crawlers and indexer_) kind of hard to reason about.
prologic
twtxt.net
View Thread
Also I'm not even sure I can validly cache, let alone index feeds anymore if we do this, because if the structure of a Twt is cuh that I can no longer trust that an individual Twt's content hasn't been changed at the source, what's the point of caching or indexing individual twts at all? This makes the implementations of yarnd and yarns (_the search engine, crawlers and indexer_) kind of hard to reason about.
prologic
twtxt.net
View Thread
Unless I"m missing something here 🤔 But a <url> <timestamp> does not for me identify an individual Twt, it only identifies its location, which may or may not have changed since I last saw a version of it hmmm 🧐
prologic
twtxt.net
View Thread
Unless I"m missing something here 🤔 But a <url> <timestamp> does not for me identify an individual Twt, it only identifies its location, which may or may not have changed since I last saw a version of it hmmm 🧐
prologic
twtxt.net
View Thread
I think that's one of the worst aspects of the proposed idea of location-based addressing or identity. The fact that Alice reads Twt A and Bob reads Twt A at the same location, but Alice and Bob _could_ have in fact read very different content entirely. It is no longer possible to have consistency in a decentralised way that works properly.

One could argue this is fine, because we're so small and nothing matters, but it's a properly I rely on fairly heavily in yarnd, a properly that if lost would have significant impact on how yarnd works I think. 🤔
prologic
twtxt.net
View Thread
I think that's one of the worst aspects of the proposed idea of location-based addressing or identity. The fact that Alice reads Twt A and Bob reads Twt A at the same location, but Alice and Bob _could_ have in fact read very different content entirely. It is no longer possible to have consistency in a decentralised way that works properly.

One could argue this is fine, because we're so small and nothing matters, but it's a properly I rely on fairly heavily in yarnd, a properly that if lost would have significant impact on how yarnd works I think. 🤔