# 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/kjjdgua
@lyse How does tt handle feeds with multiple sources for the same βnickβ? π€
@lyse How does tt handle feeds with multiple sources for the same βnickβ? π€
@prologic I just use a different nick for different URLs. :-D The thing is that I'm still using the reference twtxt implementation under the hood, so there's no way around.
@lyse Yeah yarnd is too. But maybe we _shoudl_ change this? It's probably client specific though? I _think_ there's a difference between the set of specs that form a set of valid and useful feeds and clients that access those and interact with other clients right? π€
@lyse Yeah yarnd is too. But maybe we _shoudl_ change this? It's probably client specific though? I _think_ there's a difference between the set of specs that form a set of valid and useful feeds and clients that access those and interact with other clients right? π€
@prologic The only real stable and unique thing is the feed URL (if we ignore moving to other servers for now). So ideally a URL is mapped to a nick but not the other way around. At least not in a bidirectional sense. When one wants to map a nickt to a URL is needs to be a list of URLs instead. I just think that whenever twtxt started out nobody thought of duplicate nicks, because the twtxt space was just so small.
@prologic If I'm not mistaken the twtxt spec doesn't mention anything that nicks must be unique. It also doesn't claim the oppsite. Only the implemention makes the assumption, that nicks are unique, have a look at the [following] section of the config, mapping nicks to URLs. I think when comparing stuff, only the URL is considered, not the nick. So at least in that regard it's done "correctly".
@prologic Maybe we need a third entity here to reason about nicks and URLs. For now call it the identity. If a nick resolves to multiple URLs, is it the same feed? Same as in by the same author or contentwise. Tricky. That way moves could be handled as moves, backups as backups, different authors as truely different authors and so on.
With so many new pods podding up right now it would make sense to have a standard for identity consisting of a (optional?) nick and the URL to the actual feed. it is already visual present on yarn-pod as (@)nick@url @lyse and @movq and others not using yarn, how it is the nick+url presented in your UI?
With so may pod podding up right now it would make sense to have a standard for identity consisting of a (optional?) nick and the URL to the actual feed. it is already visual present on yarn-pod as (@)nick@url @lyse and @movq and others not using yarn, how it is the nick+url presented in your UI?
Yes, it will get rather messy. I am fastidious here, and fastidious in my own pod. I follow me, but when I use @fastidious ~~~it only gives me me (here) to pick from, not me on Arrakis~~~. Actually, it worked.
@lyse Agreed a list here is better and a simple change π
@lyse Agreed a list here is better and a simple change π
Also turns out at least on yarnd you can follow a "person" who _might_ have multiple feeds like @adi and @old_adi (_as long as you name them differently, as the mapping here is nick -> url_) but that it doesn't matter because in both cases the nick = metadata is adi so they both appear as "adi" although @adi would display as @adi@f.adi.onl. So it's not too bad, "nick" here isn't appropriate for clients I think, it should be called "alias" or "name".
Also turns out at least on yarnd you can follow a "person" who _might_ have multiple feeds like @adi and @old_adi (_as long as you name them differently, as the mapping here is nick -> url_) but that it doesn't matter because in both cases the nick = metadata is adi so they both appear as "adi" although @adi would display as @adi@f.adi.onl. So it's not too bad, "nick" here isn't appropriate for clients I think, it should be called "alias" or "name".
@prologic Yeah I found that out just before by adding his twtxt.net feed as "adi2"
@eldersnake Same π I need to do a better job of documenting things π€¦ββοΈ
@eldersnake Same π I need to do a better job of documenting things π€¦ββοΈ