# 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 21
# self = https://watcher.sour.is/conv/wnq5qva
@sorenpeter
> 3. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
I think I like this a lot. đ¤
The problem with using *hashes* always was that theyâre âone-directionalâ: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see #weadxga, I have no idea what that could possibly refer to.
But of course something like (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldnât it? đ¤ That thing that I just implemented â jenny asking some Yarn pod for some twt hash â would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.
Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now donât have to read, understand, and implement a âtwt hash specificationâ before you can reply to someone.
The only problem, really, is that (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. đ
@sorenpeter
> 3. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
I think I like this a lot. đ¤
The problem with using *hashes* always was that theyâre âone-directionalâ: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see #weadxga, I have no idea what that could possibly refer to.
But of course something like (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldnât it? đ¤ That thing that I just implemented â jenny asking some Yarn pod for some twt hash â would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.
Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now donât have to read, understand, and implement a âtwt hash specificationâ before you can reply to someone.
The only problem, really, is that (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. đ
@sorenpeter
> 3. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
I think I like this a lot. đ¤
The problem with using *hashes* always was that theyâre âone-directionalâ: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see #weadxga, I have no idea what that could possibly refer to.
But of course something like (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldnât it? đ¤ That thing that I just implemented â jenny asking some Yarn pod for some twt hash â would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.
Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now donât have to read, understand, and implement a âtwt hash specificationâ before you can reply to someone.
The only problem, really, is that (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. đ
@sorenpeter
> 3. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
I think I like this a lot. đ¤
The problem with using *hashes* always was that theyâre âone-directionalâ: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see #weadxga, I have no idea what that could possibly refer to.
But of course something like (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldnât it? đ¤ That thing that I just implemented â jenny asking some Yarn pod for some twt hash â would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.
Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now donât have to read, understand, and implement a âtwt hash specificationâ before you can reply to someone.
The only problem, really, is that (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. đ
@movq we can shorten it by six characters, with (r:https://...). đ
@movq we can shorten it by six characters, with (r:https://...). đ
@movq What's you definition of "complete thread"? ;-) There might be feeds participating in the conversation that you have no idea of.
But yes, this has a nice discoverability bonus. And even simpler than a hash, that's right.
@lyse Argh. Yeah. Well. đ¤Ś
@lyse Argh. Yeah. Well. đ¤Ś
@lyse Argh. Yeah. Well. đ¤Ś
@lyse Argh. Yeah. Well. đ¤Ś
Noting that this scheme cannot support disjoint threads that should be merged together once either party discovers each other đ
Noting that this scheme cannot support disjoint threads that should be merged together once either party discovers each other đ
This scheme also only support threading off a specific Twt of someone's feed. What if you're not replying to anyone in particular?
This scheme also only support threading off a specific Twt of someone's feed. What if you're not replying to anyone in particular?
@movq I'm glad you like it. A mention (@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@movq I'm glad you like it. A mention (@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@movq I'm glad you like it. A mention (@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@movq I'm glad you like it. A mention (@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@movq I'm glad you like it. A mention (@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions:
(#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@movq I'm glad you like it. A mention (@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person.