# 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 2
# self = https://watcher.sour.is/conv/j4fqi3q
eaplmx
twtxt.net
View Thread
@lyse Interesting, let me see...

1. I'm out of context, why do we need this? (As a community of users and developers, I think)

2. I'm reading:

The goal is to provide a database that can be fetched periodically to receive a
list of twtxt feed URLs that are known to be wrong for whatever reason.

'Wrong for whatever reason' is too vague in my mind, doesn't help me to understand how it's useful, I think specific reasons would be better like 'File name changed', 'Domain changed', 'URL not available anymore/Gone forever' and such could be easier to understand.

3. What would happen if two URLs have changes, you take the most recent one?

4. Who's gonna be the main user? Systems like Yarnd checking for changes to auto-correct broken links?

These are my first impressions, and not wanting to say something wrong, it looks appealing. Kudos for the initiative!
lyse
lyse.isobeef.org
View Thread
@eaplmx So I have two personal main goals with this:

1. In the long run fix producing broken mentions in yarnd. I reckon the yarnd client is the main source of all those broken mentions I've encountered so far. There might be others, too, but to me it looks like that's the main bad guy. :-)
2. Reduce 404 in my HTTP error logs. Yes, I could configure my web server to exclude some paths, but where's the fun in that?

There are at least three specific reasons why a twtxt feed URL is wrong at some point in time. And there are probably much more.

1. It never existed in the first place, because somebody screwed up the feed URL a mention, some other feed URL should have been used.
2. The feed URL was valid before but it is now gone, the feed author decided to quit.
3. The feed URL was valid before but the feed author decided to move the feed to somewhere else.

I'm not entirely sure what you mean with "two URLs have changes". But the idea would be if URL A becomes wrong for any reason and a mapping to B is added and then later B points to C, A would also be updated to point to C directly.

The main consumers of such a database are search engines/crawlers and clients. Search engines could lookup a twtxt feed URL in this database and follow the mapping instead. Clients could use that DB to check before posting whether a mention should be corrected or use these mappings to fix broken mentions when displaying a twt.