Printi, 360imprimir, Rei do Sticker?
(no Brasil)

# 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 194944 # self = https://watcher.sour.is?offset=194944 # prev = https://watcher.sour.is?offset=194844
#
character), if this is the common implemented approach then adding the location based one is somewhat simple.s
function setPostIndex(post) {
// Current hash approach
const hash = createHash(post.url, post.timestamp, post.content);
// New location approach
const location = post.url + '#' + post.timestamp;
// Unchanged (probably)
const subject = post.subject;
// Index them all
addToIndex(hash, post);
addToIndex(location, post);
addToIndex(subject, post);
}
// Both should work if the index contains both versions
getThreadBySubject('#abcdef') => [post1, post2, post3]; // Hash
getThreadBySubject('https://example.com#2025-01-01T12:00:00') => [post1, post2, post3]; // Location
@<example https://example.com/twtxt.txt>
, so I think we should keep that in consideration.url
field too, by specification, it will use the first # url = <URL>
in the feed's metadata if present, that too can be different from the fetching source, if that field changes it would break the existing hashes too, a better solution would be to use a non-URL key like # feed_id = <UNIQUE_RANDOM_STRING>
with the url
as fallback.@<example https://example.com/twtxt.txt>
) so I'm not that worried about threads working the same way.#<https://example.com/twtxt.txt#2025-09-22T06:45Z>
with the timestamp in an anchor link. the need for a mention is avoided like this as well since it's already linking to the replied-to feed!SOURCE > POST
does make more sense indeed.