# 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 20
# self = https://watcher.sour.is/conv/a6r7c6a
marado
twtxt.net
View Thread
@mckinley @lyse The link rel bit is because the feed can have relative urls. ie, if it is on http://example.com/feed, in can have somewhere in there a for eg.. If I download that feed I to my hard-drive and then try to render it, I need to know that "icon.jpg" is relative to http://example.com/feed, ie, that I will find it at http://example.com/icon.jpg (and not locally, next to the feed file I downloaded).

I hope my explanation makes sense...=
mckinley
twtxt.net
View Thread
@marado As far as I can tell, the spec only provides relative link resolution through the xml:base attribute.

> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it \n\n the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.

This is all it has to say on rel="self":

> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.
mckinley
twtxt.net
View Thread
@marado As far as I can tell, the spec only provides relative link resolution through the xml:base attribute.

> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it [establishes]\n[establishes]\n[establishes]\n[establishes]\n the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.

This is all it has to say on rel="self":

> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.
mckinley
twtxt.net
View Thread
@marado As far as I can tell, the spec only provides relative link resolution through the xml:base attribute.

> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it \n\n\n\n the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.

This is all it has to say on rel="self":

> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.
mckinley
twtxt.net
View Thread
@marado As far as I can tell, the spec only provides relative link resolution through the xml:base attribute.

> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it [establishes][establishes=][establishes][establishes=][establishes][establishes=][establishes][establishes=] the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.

This is all it has to say on rel="self":

> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.
mckinley
twtxt.net
View Thread
@marado As far as I can tell, the spec only provides relative link resolution through the xml:base attribute.

> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it \n\n\n\n\n\n\n\n the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.

This is all it has to say on rel="self":

> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.
mckinley
twtxt.net
View Thread
@marado As far as I can tell, the spec only provides relative link resolution through the xml:base attribute.

> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it [establishes][establishes][establishes][establishes][establishes][establishes][establishes][establishes] the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.

This is all it has to say on rel="self":

> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.
mckinley
twtxt.net
View Thread
@marado As far as I can tell, the spec only provides relative link resolution through the xml:base attribute.

> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it [establishes] the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.

This is all it has to say on rel="self":

> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.
mckinley
twtxt.net
View Thread
@marado As far as I can tell, the spec only provides relative link resolution through the xml:base attribute.

> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it [establishes][establishes=] the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.

This is all it has to say on rel="self":

> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.=
lyse
lyse.isobeef.org
View Thread
@marado Yeah, I also only know of the xml:base attribute, just like @mckinley said. Never heard of <link rel="self" … /> being used for that. Maybe some last resort fallback in some feed readers, though. But that would be very fragile, too.

Unfortunately, the reasoning behind rel="self" remains a mystery.
lyse
lyse.isobeef.org
View Thread
Interesting, another broken mention URL, this time my archive feed by both @marado and @mckinley. Another fucked up cache, @prologic? I probably have to persue my correction database experiment, yarnd is never gonna fix that mentioning properly, I lost my hope. :-( The @nick@hostname yarnd syntax was a mistake. Long live proper @<nick url> twtxt syntax, only.
mckinley
twtxt.net
View Thread
@lyse

> Unfortunately, the reasoning behind rel="self" remains a mystery.

I don't know where it would be useful, either. I have one in each of my Atom feeds for the same reason. It's a Chesterton's Fence situation for me. It's not doing any harm, and the W3C says it should be there, so I put it there.=
prologic
twtxt.net
View Thread
@lyse Yeah I dumped my cache to have a look 🤦‍♂️ Somehow someone or another has followed / fetched your archived feeds and those Twters are now cached 😢

I fixed one case already but this is different 😅

Looking into it... 👀
prologic
twtxt.net
View Thread
@lyse Yeah I dumped my cache to have a look 🤦‍♂️ Somehow someone or another has followed / fetched your archived feeds and those Twters are now cached 😢

I fixed one case already but this is different 😅

Looking into it... 👀
prologic
twtxt.net
View Thread
@lyse After this commit:


* 0d751800 2022-11-11 | Add FeatureFixCachedTwtersForArchivedFeeds (fix_cached_twters_for_archived_feeds) to avoid caching Twter objects for Archived Feeds (HEAD -> filter_and_lists, origin/filter_and_lists) [James Mills]


And blacklisting ^lyse\.isobeef\.org$ (_because I couldn't figure out how to go fix broken/bad Followings of Users on my pod easily_) there should only be two Twter objects for you now, @lyse and @lyse-backup (as expected).

Hopefully we don't run into any other weird edge cases 😅
prologic
twtxt.net
View Thread
@lyse After this commit:


* 0d751800 2022-11-11 | Add FeatureFixCachedTwtersForArchivedFeeds (fix_cached_twters_for_archived_feeds) to avoid caching Twter objects for Archived Feeds (HEAD -> filter_and_lists, origin/filter_and_lists) [James Mills]


And blacklisting ^lyse\.isobeef\.org$ (_because I couldn't figure out how to go fix broken/bad Followings of Users on my pod easily_) there should only be two Twter objects for you now, @lyse and @lyse-backup (as expected).

Hopefully we don't run into any other weird edge cases 😅
prologic
twtxt.net
View Thread
@lyse After this commit:


* 0d751800 2022-11-11 | Add FeatureFixCachedTwtersForArchivedFeeds (fix_cached_twters_for_archived_feeds) to avoid caching Twter objects for Archived Feeds (HEAD -> filter_and_lists, origin/filter_and_lists) [James Mills]


And blacklisting ^lyse\\.isobeef\\.org$ (_because I couldn't figure out how to go fix broken/bad Followings of Users on my pod easily_) there should only be two Twter objects for you now, @lyse and @lyse-backup (as expected).

Hopefully we don't run into any other weird edge cases 😅
lyse
lyse.isobeef.org
View Thread
Thank you very much, @prologic! Blacklisting doesn't feel right, but let's see how it goes from there with that commit.
prologic
twtxt.net
View Thread
@lyse No it's not right but as I said on IRC I haven't figured out a way to handle bad Following yet 🤣
prologic
twtxt.net
View Thread
@lyse No it's not right but as I said on IRC I haven't figured out a way to handle bad Following yet 🤣