# 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 50
# self = https://watcher.sour.is/conv/mf4kvaa
@darch I kind of agree that we can probably omit the nick part in mentions entirely. Since they can be looked up and cached, there's no need for this. But we'll have to spec this all up. First let's see what @lyse and @movq and others like @anth thing about finally formalising a standard way to lookup feed URI(s) and define a slightly more saner? -mention syntax/usage pattern. I for one hate manually typing out (for example) @<darch https://neotxt.dk/user/darch/twtxt.txt> like this @darch š
@darch I kind of agree that we can probably omit the nick part in mentions entirely. Since they can be looked up and cached, there's no need for this. But we'll have to spec this all up. First let's see what @lyse and @movq and others like @anth thing about finally formalising a standard way to lookup feed URI(s) and define a slightly more saner? -mention syntax/usage pattern. I for one hate manually typing out (for example) @<darch https://neotxt.dk/user/darch/twtxt.txt> like this @darch š
@darch I kind of agree that we can probably omit the nick part in mentions entirely. Since they can be looked up and cached, there's no need for this. But we'll have to spec this all up. First let's see what @lyse and @movq and others like @anth thing about finally formalising a standard way to lookup feed URI(s) and define a slightly more saner? -mention syntax/usage pattern. I for one hate manually typing out (for example) @<darch https://neotxt.dk/user/darch/twtxt.txt> like this @darch š
@prologic Clients can always just ignore the nick part when displaying and render their local nickname if they want to. This discussion just started because the configuration data model in the original twtxt client is implemented with a map of nick to URL. So nicks need to be unique. Hence, I have two entries, "darch" for twtxt.net and "darch@neotxt" for neotxt.dk.
I might miss something, but I'm not interested in standardizing anything for URL lookups by nick, that's completely up to the client. I only rarely type an entire mention verbatim, my client does it for me. It adds in all feeds that participated in the thread when replying. I reckon yarnd does (or did) the same.
@lyse I'm thinking of generally the case of solving the of "bad data" when ti comes to -mentions, typos, wrong urls and so on. In general if a client can validate an alias/mention (yes yarnd has a similar thing where we maintain a similar mapping per user and have lookup for that), then we can avoid this whole "bad data" mess in the first place. I'd also be interested to know what folks like @anth was thinking too when he mentioned the use of WebFinger. Anyway we'll see how this pans out, yarnd (at least my pod) now has an experimental webfinger endpoint where you can do for example $ webfinger prologic@twtxt.net
@lyse I'm thinking of generally the case of solving the of "bad data" when ti comes to -mentions, typos, wrong urls and so on. In general if a client can validate an alias/mention (yes yarnd has a similar thing where we maintain a similar mapping per user and have lookup for that), then we can avoid this whole "bad data" mess in the first place. I'd also be interested to know what folks like @anth was thinking too when he mentioned the use of WebFinger. Anyway we'll see how this pans out, yarnd (at least my pod) now has an experimental webfinger endpoint where you can do for example $ webfinger prologic@twtxt.net
@lyse I'm thinking of generally the case of solving the of "bad data" when ti comes to -mentions, typos, wrong urls and so on. In general if a client can validate an alias/mention (yes yarnd has a similar thing where we maintain a similar mapping per user and have lookup for that), then we can avoid this whole "bad data" mess in the first place. I'd also be interested to know what folks like @anth was thinking too when he mentioned the use of WebFinger. Anyway we'll see how this pans out, yarnd (at least my pod) now has an experimental webfinger endpoint where you can do for example $ webfinger prologic@twtxt.net
@lyse I'm thinking of generally the case of solving the of "bad data" when ti comes to -mentions, typos, wrong urls and so on. In general if a client can validate an alias/mention (yes yarnd has a similar thing where we maintain a similar mapping per user and have lookup for that), then we can avoid this whole "bad data" mess in the first place. I'd also be interested to know what folks like @anth was thinking too when he mentioned the use of WebFinger. Anyway we'll see how this pans out, yarnd (at least my pod) now has an experimental webfinger endpoint where you can do for example $ webfinger prologic@twtxt.net
This probably arrants some real-time conversation though. Are you up for a call this weekend/tomorrow? š¤
This probably arrants some real-time conversation though. Are you up for a call this weekend/tomorrow? š¤
This probably arrants some real-time conversation though. Are you up for a call this weekend/tomorrow? š¤
This probably arrants some real-time conversation though. Are you up for a call this weekend/tomorrow? š¤
@prologic I can't make it this week because the scouts are collecting christmas carcasses. I don't see how webfinger helps, though (I also don't have a clue how it works). Clients have all data they need in my opinion.
@prologic Iām not really sure what you mean. Donāt we already have nick = and url = in the metadata section? Which problem are we trying to solve? š¤
@prologic Iām not really sure what you mean. Donāt we already have nick = and url = in the metadata section? Which problem are we trying to solve? š¤
@prologic Iām not really sure what you mean. Donāt we already have nick = and url = in the metadata section? Which problem are we trying to solve? š¤
@movq There are two primary problems that the use of WebFinger can help solve (that I can think of):
- Conveniently sharing your Yarn.social / Twtxt "identity" with others, much like other competing ecosystems have done. e.g: prologic@twtxt.net (which can be looked up now with a webfinger client)
- Verifying -mentions to be correct, potentially even rewriting them (yarnd does this anyway) to their proper @<url> form(s).
@movq There are two primary problems that the use of WebFinger can help solve (that I can think of):
- Conveniently sharing your Yarn.social / Twtxt "identity" with others, much like other competing ecosystems have done. e.g: prologic@twtxt.net (which can be looked up now with a webfinger client)
- Verifying -mentions to be correct, potentially even rewriting them (yarnd does this anyway) to their proper @<url> form(s).
@movq There are two primary problems that the use of WebFinger can help solve (that I can think of):
- Conveniently sharing your Yarn.social / Twtxt "identity" with others, much like other competing ecosystems have done. e.g: prologic@twtxt.net (which can be looked up now with a webfinger client)
- Verifying -mentions to be correct, potentially even rewriting them (yarnd does this anyway) to their proper @<url> form(s).
@movq There are two primary problems that the use of WebFinger can help solve (that I can think of):
- Conveniently sharing your Yarn.social / Twtxt "identity" with others, much like other competing ecosystems have done. e.g: prologic@twtxt.net (which can be looked up now with a webfinger client)
- Verifying -mentions to be correct, potentially even rewriting them (yarnd does this anyway) to their proper @<url> form(s).
@prologic Hmmm.
So youāre suggesting to make prologic@twtxt.net the āprimary identifierā of a user, right? Thatās the string that I would configure in my twtxt client when I want to follow someone. Then when my client fetches the feed, it first does a webfinger lookup to find the feed URL and the nickname. (Or maybe this only immediately after adding the user to my client and then maybe update it every now and then.)
Did I understand correctly so far? š
@prologic Hmmm.
So youāre suggesting to make prologic@twtxt.net the āprimary identifierā of a user, right? Thatās the string that I would configure in my twtxt client when I want to follow someone. Then when my client fetches the feed, it first does a webfinger lookup to find the feed URL and the nickname. (Or maybe this only immediately after adding the user to my client and then maybe update it every now and then.)
Did I understand correctly so far? š
@prologic Hmmm.
So youāre suggesting to make prologic@twtxt.net the āprimary identifierā of a user, right? Thatās the string that I would configure in my twtxt client when I want to follow someone. Then when my client fetches the feed, it first does a webfinger lookup to find the feed URL and the nickname. (Or maybe this only immediately after adding the user to my client and then maybe update it every now and then.)
Did I understand correctly so far? š
@prologic Alright, buuuut ā¦ what do we gain from that?
You could do almost the same thing currently with just the feed URL. nick = can be read from metadata. The canonical feed URL used for twt hashing is well-defined, too (first url = in metadata).
Sorry if Iām being too dumb. š
@prologic Alright, buuuut ā¦ what do we gain from that?
You could do almost the same thing currently with just the feed URL. nick = can be read from metadata. The canonical feed URL used for twt hashing is well-defined, too (first url = in metadata).
Sorry if Iām being too dumb. š
@prologic Alright, buuuut ā¦ what do we gain from that?
You could do almost the same thing currently with just the feed URL. nick = can be read from metadata. The canonical feed URL used for twt hashing is well-defined, too (first url = in metadata).
Sorry if Iām being too dumb. š
It is not all twtxt.txt file that adhere to having a nick = or url = field int them, so the only information we can be sure of is a URL to where the twtxt.txt is served from. That leads to using a domain+path-to-twtxt.txt as be most unambiguous identification and also how the original @<URL> mention are defined in line with the indieweb way of using a domain as id.
But with muti-user pods this get messing with urls like https://neotxt.dk/user/darch/twtxt.net, when it would be much nicer if we had http://darch.neotxt.dk/twtxt.txt like on https://darch.neocities.org/twtxt.txt and then we could omit the /twtxt.txt in daily conversation. </ramble>
@darch Hmmm ā¦ if the argument is ānot all twtxt files have all required fieldsā, then wouldnāt this also apply to webfinger? Not all servers that host a twtxt file will also serve webfinger info. š¤ Youād probably always have to implement some fallback mechanism.
I donāt really know anything about āindiewebā, though. Iāll have to read up on that first. š
@darch Hmmm ā¦ if the argument is ānot all twtxt files have all required fieldsā, then wouldnāt this also apply to webfinger? Not all servers that host a twtxt file will also serve webfinger info. š¤ Youād probably always have to implement some fallback mechanism.
I donāt really know anything about āindiewebā, though. Iāll have to read up on that first. š
@darch Hmmm ā¦ if the argument is ānot all twtxt files have all required fieldsā, then wouldnāt this also apply to webfinger? Not all servers that host a twtxt file will also serve webfinger info. š¤ Youād probably always have to implement some fallback mechanism.
I donāt really know anything about āindiewebā, though. Iāll have to read up on that first. š
@movq I think the only thing this bus us is "shorter identities" with feed uris that can be looked up and validated, really.
@movq I think the only thing this bus us is "shorter identities" with feed uris that can be looked up and validated, really.
@movq I think the only thing this bus us is "shorter identities" with feed uris that can be looked up and validated, really.
@movq I think the only thing this bus us is "shorter identities" with feed uris that can be looked up and validated, really.
And this is true, I wouldn't expect every Twtxt feed on ever web server to have a webfinger service. So we'd have to fallback anyway.
And this is true, I wouldn't expect every Twtxt feed on ever web server to have a webfinger service. So we'd have to fallback anyway.
And this is true, I wouldn't expect every Twtxt feed on ever web server to have a webfinger service. So we'd have to fallback anyway.
And this is true, I wouldn't expect every Twtxt feed on ever web server to have a webfinger service. So we'd have to fallback anyway.
@darch If we want to make follow users and cross-pod mentioning easier for users, I _would_ just drop the whole Twtxt feed URi entirely and just use webfinger period. Its far easier for non-technical people to reason about if we do that. Of course the actual Twtxt feed URL(s) are still there, just abstracted away from the users.
@darch If we want to make follow users and cross-pod mentioning easier for users, I _would_ just drop the whole Twtxt feed URi entirely and just use webfinger period. Its far easier for non-technical people to reason about if we do that. Of course the actual Twtxt feed URL(s) are still there, just abstracted away from the users.
@darch If we want to make follow users and cross-pod mentioning easier for users, I _would_ just drop the whole Twtxt feed URi entirely and just use webfinger period. Its far easier for non-technical people to reason about if we do that. Of course the actual Twtxt feed URL(s) are still there, just abstracted away from the users.
@darch If we want to make follow users and cross-pod mentioning easier for users, I _would_ just drop the whole Twtxt feed URi entirely and just use webfinger period. Its far easier for non-technical people to reason about if we do that. Of course the actual Twtxt feed URL(s) are still there, just abstracted away from the users.
@movq Come to think of it, it's actually an appealing "options" thing to support anyway I _think_. It sure does make looking things up a lot easier. It makes no difference to us now, since we all follow each other and have webb established clients and following maps, but if we think another few years from now how things might evolve, new users might appreciate a more "straight forward" mechanisms/lookup and address/identity.
@movq Come to think of it, it's actually an appealing "options" thing to support anyway I _think_. It sure does make looking things up a lot easier. It makes no difference to us now, since we all follow each other and have webb established clients and following maps, but if we think another few years from now how things might evolve, new users might appreciate a more "straight forward" mechanisms/lookup and address/identity.
@movq Come to think of it, it's actually an appealing "options" thing to support anyway I _think_. It sure does make looking things up a lot easier. It makes no difference to us now, since we all follow each other and have webb established clients and following maps, but if we think another few years from now how things might evolve, new users might appreciate a more "straight forward" mechanisms/lookup and address/identity.
@movq Come to think of it, it's actually an appealing "options" thing to support anyway I _think_. It sure does make looking things up a lot easier. It makes no difference to us now, since we all follow each other and have webb established clients and following maps, but if we think another few years from now how things might evolve, new users might appreciate a more "straight forward" mechanisms/lookup and address/identity.