# 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 47
# self = https://watcher.sour.is/conv/ba3fxtq
So⦠This is an example of what happens if you follow a feed that happens to be served over two different schemes or protocols.
So⦠This is an example of what happens if you follow a feed that happens to be served over two different schemes or protocols.
The one in blue is served over ordinary HTTP whilst the one in green is served over a TLS enabled HTTPS
The one in blue is served over ordinary HTTP whilst the one in green is served over a TLS enabled HTTPS
@prologic You're correct, but those are actually separate feeds. Green is /twtxt.txt, my "canonical" feed with all my posts. Blue is /twtxt-25.txt, the one with only the most recent 25 posts. I understand how this can create confusion. Does Yarn respect url metadata entries as specified on dev.twtxt.net?
You're correct, but those are actually separate feeds. Green is /twtxt.txt, my "canonical" feed with all my posts. Blue is /twtxt-25.txt, the one with only the most recent 25 posts.
@mckinley Oh! π€¦ββοΈ I see. Can I _blame_ my blindness for not spotting this?! π€£ So Sorry!
@mckinley Oh! π€¦ββοΈ I see. Can I _blame_ my blindness for not spotting this?! π€£ So Sorry!
Maybe it _might_ be worthwhile putting some metadata at the top of those feeds? Maybe at a minimum a # description = ...? (See Metadata extension)
Maybe it _might_ be worthwhile putting some metadata at the top of those feeds? Maybe at a minimum a # description = ...? (See Metadata extension)
@prologic Ah, I finished editing my post after you already saw it.
> I understand how this can create confusion. Does Yarn respect url metadata entries as specified on dev.twtxt.net?
@prologic Ah, I finished editing my post after you already saw it.\n> I understand how this can create confusion. Does Yarn respect url metadata entries as specified on dev.twtxt.net?
@prologic Man, you're really killing me with these quick replies.
@mckinley \n\n> Does Yarn respect url metadata entries as specified on dev.twtxt.net?\n\nFor computing the Twt Hash? π€
@mckinley
> Does Yarn respect url metadata entries as specified on dev.twtxt.net?
For computing the Twt Hash? π€
@mckinley
> Does Yarn respect url metadata entries as specified on dev.twtxt.net?
For computing the Twt Hash? π€
@mckinley
> Man, you're really killing me with these quick replies.
Sorry I'll slow down π€£ on-pod the cache is updated instantly. cross-pod it's ~5mins.~
@mckinley \n\n> Man, you're really killing me with these quick replies.\n\nSorry I'll slow down π€£ on-pod the cache is updated instantly. cross-pod it's ~5mins.~
@mckinley
> Man, you're really killing me with these quick replies.
Sorry I'll slow down π€£ on-pod the cache is updated instantly. cross-pod it's ~5mins.~
@prologic Yeah, isn't the idea to make sure twts from the same feed at different locations have the same hash by specifying a canonical feed url? That should solve the http:// https:// problem *and* the twtxt twtxt-25 problem if the standard is widely adopted.
@mckinley I _believe_ so... Let me go re-read the spec we all agreed upon and wrote! π\n\n> What's the point of having a spec if no-one sticks to it!\n\nπ€£ if yarnd is indeed not compliant, shame on me π€¦ββοΈ
@mckinley I _believe_ so... Let me go re-read the spec we all agreed upon and wrote! π
> What's the point of having a spec if no-one sticks to it!
π€£ if yarnd is indeed not compliant, shame on me π€¦ββοΈ
@mckinley I _believe_ so... Let me go re-read the spec we all agreed upon and wrote! π
> What's the point of having a spec if no-one sticks to it!
π€£ if yarnd is indeed not compliant, shame on me π€¦ββοΈ
Says here:\n\n> url\n> This specifies the URL(s) of the feed. There might be several url fields in a single feed. The first url field > value will be used for twt hashing.\n\nSo I've got some work to do π
Says here:
> url
> This specifies the URL(s) of the feed. There might be several url fields in a single feed. The first url field > value will be used for twt hashing.
So I've got some work to do π
Says here:
> url
> This specifies the URL(s) of the feed. There might be several url fields in a single feed. The first url field > value will be used for twt hashing.
So I've got some work to do π
Hold on. If the standard was implemented verbatim, couldn't anyone could hijack your feed by adding # url = https://twtxt.net/user/prologic/twtxt.txt to their feed?
@mckinley Hijack it how? π€ You would have to effectively post identical content as me at the exact same timestamp to come up with the same hash.
@mckinley Hijack it how? π€ You would have to effectively post identical content as me at the exact same timestamp to come up with the same hash.
How about this: The url field is replaced by a canonical field and an alternate field. If the location that the client has of Feed A doesn't match what it says in Feed A's canonical field, the client downloads the canonical feed, Feed B, once to make sure that the location of Feed A appears in Feed B's alternate tags. If so, the client will continue to follow Feed A but it will use the canonical URL for hashing.
As I'm typing it, though, it seems like an extremely complicated solution to a problem that isn't all that bad.
How about this: The url field is replaced by a canonical field and an alternate field. If the location that the client has of Feed A doesn't match what it says in Feed A's canonical field, the client downloads the canonical feed, Feed B, once to make sure that the location of Feed A appears in Feed B's alternate tags. If so, the client will continue to follow Feed A but it will use the canonical URL for hashing.\nAs I'm typing it, though, it seems like an extremely complicated solution to a problem that isn't all that bad.
@prologic \n> Hijack it how?\n\nWouldn't they be able to make their own posts that would appear as having come from your account?
@prologic
> Hijack it how?
Wouldn't they be able to make their own posts that would appear as having come from your account?
\n> As I'm typing it, though, it seems like an extremely complicated solution to a problem that isn't all that bad.\n\nPoor wording. Feedjacking would be a pretty bad problem. I meant that it might be best to keep things as they are without adding any crazy url switching.
> As I'm typing it, though, it seems like an extremely complicated solution to a problem that isn't all that bad.
Poor wording. Feedjacking would be a pretty bad problem. I meant that it might be best to keep things as they are without adding any crazy url switching.
@mckinley Don't get me wrong... You've actually presented us an interesting and valid (IHMO) problem and use-case. I'd like to hear from @movq and @lyse on this as we also attempt to formalize a way to archive and rotate and paginate feeds. Initially when we've discussed this particular problem before I _believe_ it was suggested that the Twt Hash ignore the Schema part of the URI, but this case is different but still legitimate IHMO.
@mckinley Don't get me wrong... You've actually presented us an interesting and valid (IHMO) problem and use-case. I'd like to hear from @movq and @lyse on this as we also attempt to formalize a way to archive and rotate and paginate feeds. Initially when we've discussed this particular problem before I _believe_ it was suggested that the Twt Hash ignore the Schema part of the URI, but this case is different but still legitimate IHMO.
@prologic My apologies. I didn't interpret the specification correctly. The feeds are supposed to be distinct, with the url field used for hashing and hashing only. I got carried away with separate feeds becoming one and whatnot. Ignore everything I've written to this point. Perhaps I should go to bed.
Here's the thing though... The more I _think_ about this the more I'm convinced that your two feeds are in fact "different feeds" and thereby what yarnd is doing to compute the Twt Hash is _correct_. I _think_ this is basically a type of user error so to speak, since _someone_ on my pod has basically followed both feeds π Maybe the Feed Archival and Pagination Extension will eliminate your need to have this "Top 25" feed that duplicates entries from your main feed? π€
Here's the thing though... The more I _think_ about this the more I'm convinced that your two feeds are in fact "different feeds" and thereby what yarnd is doing to compute the Twt Hash is _correct_. I _think_ this is basically a type of user error so to speak, since _someone_ on my pod has basically followed both feeds π Maybe the Feed Archival and Pagination Extension will eliminate your need to have this "Top 25" feed that duplicates entries from your main feed? π€
@mckinley No apologies necessary π€ G'night! π΄
@mckinley No apologies necessary π€ G'night! π΄