# 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 41
# self = https://watcher.sour.is/conv/opev6mq
@marado I _could_ have sworn we discussed the spec mandating absolute uris no? cc @lyse and @movq for comment. if this is not the case, we should re-discuss and amend the spec.
Otherwise, put up a PR and let's discuss it right there in code 👌
@marado I _could_ have sworn we discussed the spec mandating absolute uris no? cc @lyse and @movq for comment. if this is not the case, we should re-discuss and amend the spec.
Otherwise, put up a PR and let's discuss it right there in code 👌
I'm uncertain I'm looking at the right place, but from how I read it, absolute URLs not only aren't mandated, they aren't even a possibility. I'll open a PR soon(TM)
I'm uncertain I'm looking at the right place, but from how I read it, absolute URLs not only aren't mandated, they aren't even a possibility. I'll open a PR soon(TM)
@prologic @marado IIRC, this was done deliberately: The fragment in feed_prev is relative to the feed you’re currently fetching. Think multi-protocol feeds here.
Could you elaborate what you’re trying to do? 🤔
@prologic @marado IIRC, this was done deliberately: The fragment in feed_prev is relative to the feed you’re currently fetching. Think multi-protocol feeds here.
Could you elaborate what you’re trying to do? 🤔
@prologic @marado IIRC, this was done deliberately: The fragment in feed_prev is relative to the feed you’re currently fetching. Think multi-protocol feeds here.
Could you elaborate what you’re trying to do? 🤔
@prologic @movq Imagine I want to stop updating my feed on my domain.com by starting a new feed at coolerdomain.net, but point to the previous one in its previous address, for history purposes.
Or maybe I want to stop using this pod because I think I like yours best, or I host my own now... so I want to *continue* there, pointing to this as my previous one.
@prologic @movq Imagine I want to stop updating my feed on my domain.com by starting a new feed at coolerdomain.net, but point to the previous one in its previous address, for history purposes.
Or maybe I want to stop using this pod because I think I like yours best, or I host my own now... so I want to *continue* there, pointing to this as my previous one.
@marado There is one problem with this though. We can't guarantee that the prev_url link is actually valid. I _believe_ we'd run into potential "spoofing" problems by allowing that to happen? 🤔
(side-topic) on the other thing you mentioned about "maybe I don't like this pod and I like yours better", that's a planned feature too (I think it's in the backlog) whereby if you decide to delete your account on some pod, you'll get an opportunity to put in a redirect which the pod will honor for some period of time. We want to encourage folks to move around pods (if they want to) and discourage large (high-user count) single pods 😅 (at least this is the greater vision/idea)
@marado There is one problem with this though. We can't guarantee that the prev_url link is actually valid. I _believe_ we'd run into potential "spoofing" problems by allowing that to happen? 🤔
(side-topic) on the other thing you mentioned about "maybe I don't like this pod and I like yours better", that's a planned feature too (I think it's in the backlog) whereby if you decide to delete your account on some pod, you'll get an opportunity to put in a redirect which the pod will honor for some period of time. We want to encourage folks to move around pods (if they want to) and discourage large (high-user count) single pods 😅 (at least this is the greater vision/idea)
@prologic Spoofing is always possible, and always a concern (don't we "deal" with it already for the url field?).
For the side-question, the feature is nice but depends on availability, and trust, I'm more interested in adversarial interoperability. What if I'm moving from a pod because I dislike their new policies, or new terms of service, their monetization model, etc.? And what guarantees do we have that every pod (
@prologic Spoofing is always possible, and always a concern (don't we "deal" with it already for the url field?).
For the side-question, the feature is nice but depends on availability, and trust, I'm more interested in adversarial interoperability. What if I'm moving from a pod because I dislike their new policies, or new terms of service, their monetization model, etc.? And what guarantees do we have that every pod (or even yarn implementation) will have the redirect option available to it
@prologic Spoofing is always possible, and always a concern (don't we "deal" with it already for the url field?).
For the side-question, the feature is nice but depends on availability, and trust, I'm more interested in adversarial interoperability. What if I'm moving from a pod because I dislike their new policies, or new terms of service, their monetization model, etc.? And what guarantees do we have that every pod (or even yarn implementation) will have the redirect option available to its users?
@prologic Spoofing is always possible, and always a concern (don't we "deal" with it already for the url field?).
For the side-question, the feature is nice but depends on availability, and trust, I'm more interested in adversarial interoperability. What if I'm moving from a pod because I dislike their new policies, or new terms of service, their monetization model, etc.? And what guarantees do we have that every pod (or even yarn implementation) will have the redirect option available to its users?
@marado Good points. I _think_ we just have to understand your use-case a bit more... Originally the Archive Ext was developed as a way to let clients fetch older versions of a feed if they wish to (or haven't seen it before). This is less of an issue with the growing Yarn.social (pods) network itself as they're "always online" so to speak (even if it's a single-user pod, which we have many of too).
@marado Good points. I _think_ we just have to understand your use-case a bit more... Originally the Archive Ext was developed as a way to let clients fetch older versions of a feed if they wish to (or haven't seen it before). This is less of an issue with the growing Yarn.social (pods) network itself as they're "always online" so to speak (even if it's a single-user pod, which we have many of too).
@marado So the point is: When you move from one pod to another, you start *afresh* on that new pod? You don’t take your current feed and the archived feeds with you?
Example:
- 2022-01-01: Starts twting on foopod.example.com
- 2022-02-01: Moves to barpod.example.com, puts prev = $hash foopod.example.com/twtxt-old-$hash.txt in header of new feed at barpod; actual feed at barpod.example.com starts empty
Is that it? 🤔
(If yes, then this raises another question for me: What if I want to move from one pod to another and want to keep my entire feed? That’s would I, personally, would want. Like, when I open an account on a Yarn pod, there could be an “import this twtxt file” feature – dunno if that’s already possible.)
@marado So the point is: When you move from one pod to another, you start *afresh* on that new pod? You don’t take your current feed and the archived feeds with you?
Example:
- 2022-01-01: Starts twting on foopod.example.com
- 2022-02-01: Moves to barpod.example.com, puts prev = $hash foopod.example.com/twtxt-old-$hash.txt in header of new feed at barpod; actual feed at barpod.example.com starts empty
Is that it? 🤔
(If yes, then this raises another question for me: What if I want to move from one pod to another and want to keep my entire feed? That’s would I, personally, would want. Like, when I open an account on a Yarn pod, there could be an “import this twtxt file” feature – dunno if that’s already possible.)
@marado So the point is: When you move from one pod to another, you start *afresh* on that new pod? You don’t take your current feed and the archived feeds with you?
Example:
- 2022-01-01: Starts twting on foopod.example.com
- 2022-02-01: Moves to barpod.example.com, puts prev = $hash foopod.example.com/twtxt-old-$hash.txt in header of new feed at barpod; actual feed at barpod.example.com starts empty
Is that it? 🤔
(If yes, then this raises another question for me: What if I want to move from one pod to another and want to keep my entire feed? That’s would I, personally, would want. Like, when I open an account on a Yarn pod, there could be an “import this twtxt file” feature – dunno if that’s already possible.)
@movq That's the scenario, yes. Importing twtxt feeds seems like a good functionality, but it doesn't totally replace (or exaust) the scenarios in which one could want to have their "prev, static twtxt file" on a different path/subdomain/etc...
@movq That's the scenario, yes. Importing twtxt feeds seems like a good functionality, but it doesn't totally replace (or exaust) the scenarios in which one could want to have their "prev, static twtxt file" on a different path/subdomain/etc...
I have nothing to add to @movq's statements. I remember it exactly the way he described. But we might be able to just also allow absolute URLs, if multi-protocol is nothing for feed authors to worry about. Might get messy, though. Didn't completely think this through yet.
@marado I’m not 100% sure yet if I understand the use case correctly. 🤔 Is this for setups where you can’t install redirects on the HTTP level? (Or maybe I’m just too dumb and the other guys understand it. 😅)
@marado I’m not 100% sure yet if I understand the use case correctly. 🤔 Is this for setups where you can’t install redirects on the HTTP level? (Or maybe I’m just too dumb and the other guys understand it. 😅)
@marado I’m not 100% sure yet if I understand the use case correctly. 🤔 Is this for setups where you can’t install redirects on the HTTP level? (Or maybe I’m just too dumb and the other guys understand it. 😅)
@movq That would be a scenario, yes.
@movq That would be a scenario, yes.
@prologic I think so, yes. More generically, places were you have no control over the webserver (hosting services via ssh/ftp without htaccess support is another example).
@prologic I think so, yes. More generically, places were you have no control over the webserver (hosting services via ssh/ftp without htaccess support is another example).
@marado Yup I get it. So hmmm Where does this leave us with the spec?
@marado Yup I get it. So hmmm Where does this leave us with the spec?
@prologic I see reasons for allowing absolute URIs, and see no reason not to.
I suppose I should condense this thread into a write-up proposing the change, explaining why, and proposing client behaviors ("how to deal with a prev pointing to an absolute URI"). But that takes time, and I don't know when will I reserve some to sit down and actually do the proposal :-)
@prologic I see reasons for allowing absolute URIs, and see no reason not to.
I suppose I should condense this thread into a write-up proposing the change, explaining why, and proposing client behaviors ("how to deal with a prev pointing to an absolute URI"). But that takes time, and I don't know when will I reserve some to sit down and actually do the proposal :-)
@marado Please if you could do so that would be great 🙇♀️
@marado Please if you could do so that would be great 🙇♀️