# 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 19
# self = https://watcher.sour.is/conv/knryyga
Some more arguments for a local-based treading model over a content-based one:
1. The format: (#<DATE URL>)
or (@<DATE URL>)
both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash)
and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.
2. Having something like (#<DATE URL>)
will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash
. This will also make it possible to make 3th part twt-mentions services.
3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
Some more arguments for a local-based treading model over a content-based one:
1. The format: (#<DATE URL>)
or (@<DATE URL>)
both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash)
and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.
2. Having something like (#<DATE URL>)
will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash
. This will also make it possible to make 3th part twt-mentions services.
3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
Some more arguments for a local-based treading model over a content-based one:
1. The format: (#<DATE URL>)
or (@<DATE URL>)
both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash)
and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.
2. Having something like (#<DATE URL>)
will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash
. This will also make it possible to make 3th part twt-mentions services.
3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
Some more arguments for a local-based treading model over a content-based one:
1. The format: (#<DATE URL>)
or (@<DATE URL>)
both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash)
and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.
2. Having something like (#<DATE URL>)
will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash
. This will also make it possible to make 3th part twt-mentions services.
3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
@sorenpeter Points 2 & 3 aren't really applicable here in the discussion of the threading model really I'm afraid. WebMentions is completely orthogonal to the discussion. Further, no-one that uses Twtxt really uses WebMentions, whilst yarnd
supports the use of WebMentions, it's very rarely used in practise (_if ever_) -- In fact I should just drop the feature entirely.
The use of WebSub OTOH is far more useful and is used by every single yarnd
pod everywhere (_no that there's that many around these days_) to subscribe to feed updates in ~near real-time _without_ having the poll constantly.~
@sorenpeter Points 2 & 3 aren't really applicable here in the discussion of the threading model really I'm afraid. WebMentions is completely orthogonal to the discussion. Further, no-one that uses Twtxt really uses WebMentions, whilst yarnd
supports the use of WebMentions, it's very rarely used in practise (_if ever_) -- In fact I should just drop the feature entirely.
The use of WebSub OTOH is far more useful and is used by every single yarnd
pod everywhere (_no that there's that many around these days_) to subscribe to feed updates in ~near real-time _without_ having the poll constantly.~
So really your argument is just that switching to a location-based addressing "just makes sense". Why? Without concrete pros/cons of each approach this isn't really a strong argument I'm afraid. In fact I probably need to just sit down and detail the properties of both approaches and the pros/cons of both.
I also don't really buy the argument of simplicity either personally, because I don't technically see it much more difficult to take a echo -e "<url>\\t<timestamp>\\t<content>" | sha256sum | base64
as the Twt Subject or concatenating the <url> <timestamp>
-- The "effort" is the same. If we're going to argue that SHA256 or cryptographic hashes are "too complicated" then I'm not really sure how to support that argument.
So really your argument is just that switching to a location-based addressing "just makes sense". Why? Without concrete pros/cons of each approach this isn't really a strong argument I'm afraid. In fact I probably need to just sit down and detail the properties of both approaches and the pros/cons of both.
I also don't really buy the argument of simplicity either personally, because I don't technically see it much more difficult to take a echo -e "<url>\t<timestamp>\t<content>" | sha256sum | base64
as the Twt Subject or concatenating the <url> <timestamp>
-- The "effort" is the same. If we're going to argue that SHA256 or cryptographic hashes are "too complicated" then I'm not really sure how to support that argument.
So really your argument is just that switching to a location-based addressing "just makes sense". Why? Without concrete pros/cons of each approach this isn't really a strong argument I'm afraid. In fact I probably need to just sit down and detail the properties of both approaches and the pros/cons of both.
I also don't really buy the argument of simplicity either personally, because I don't technically see it much more difficult to take a echo -e "<url>\t<timestamp>\t<content>" | sha256sum | base64
as the Twt Subject or concatenating the <url> <timestamp>
-- The "effort" is the same. If we're going to argue that SHA256 or cryptographic hashes are "too complicated" then I'm not really sure how to support that argument.
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.
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.
With Location-based addressing there is no way to verify that a single Twt _actaully_ came from that feed without actually fetching the feed and checking. That has the effect of always having to rely on fetching the feed and storing a copy of feeds you fetch (_which is okay_), but you're force to do this. You cannot really share individual Twts anymore really like yarnd
does (_as peering_) because there is no "integrity" to the Twt identified by it's <url> <timestamp>
. The identify is meaningless and is only valid as long as you can trust the location and that the location at that point hasn't changed its content.
With Location-based addressing there is no way to verify that a single Twt _actaully_ came from that feed without actually fetching the feed and checking. That has the effect of always having to rely on fetching the feed and storing a copy of feeds you fetch (_which is okay_), but you're force to do this. You cannot really share individual Twts anymore really like yarnd
does (_as peering_) because there is no "integrity" to the Twt identified by it's <url> <timestamp>
. The identify is meaningless and is only valid as long as you can trust the location and that the location at that point hasn't changed its content.
There is also a ~5x increase cost in memory utilization for any implementations or implementors that use or wish to use in-memory storage (yarnd
does for example) and equally a 5x increase in on-disk storage as well. This is based on the Twt Hash going from a 13 bytes (content-addressing) to 63 bytes (on average for location-based addressing). There is roughly a ~20-150% increase in the size of individual feeds as well that needs to be taken into consideration (_on the average case_).
There is also a ~5x increase cost in memory utilization for any implementations or implementors that use or wish to use in-memory storage (yarnd
does for example) and equally a 5x increase in on-disk storage as well. This is based on the Twt Hash going from a 13 bytes (content-addressing) to 63 bytes (on average for location-based addressing). There is roughly a ~20-150% increase in the size of individual feeds as well that needs to be taken into consideration (_on the average case_).
And finally the legibility of feeds when viewing them in their raw form are worsened as you go from a Twt Subject of (#abcdefg12345)
to something like (https://twtxt.net/user/prologic/twtxt.txt 2024-09-22T07:51:16Z)
.
And finally the legibility of feeds when viewing them in their raw form are worsened as you go from a Twt Subject of (#abcdefg12345)
to something like (https://twtxt.net/user/prologic/twtxt.txt 2024-09-22T07:51:16Z)
.