# 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 15
# self = https://watcher.sour.is/conv/wdu6cca
Related with my current conversation, what do you think of using twtxt.txt as a format for feeds?

Indeed I knew the format since it was used in Gemini capsules as a sort of Atom alternative
@eaplmx I think twtxt is a fine feed format, especially if you're allergic to XML.
@eaplmx I see it as a way to add feed to all sort of sites so people don't have to relay on twitter, facebook and instragam to share their updates, but instead selfhost a twtxt.txt that people can follow in any way they see fit
Not sure which conversation you mean, @eaplmx (it's already quite late here), but here's my take: I think twtxt it's not heavy enough. For a real feed format I would like to have a clear separation between titles and content. And more options for the content. Plaintext and HTML at least. Twtxt is plaintext, but lots of folks (me included) actually use markdown in their yarns. However, the actual format being used is not advertised anywhere. To make things worse, I actually prefer reStructuredText over markdown. For podcasts some enclosure-like thing would be nice as well. Twtxt being line based also really limits structuring of longer content by hand. Just can't produce a nice source file.

On the other hand, RSS and Atom being XML are way too heavy for my taste. And then there's JSON feed. It's been a while since I skimmed over it, can't remember the details, but I wasn't sold on this one either. I also never encountered any JSON feed in the wild. So I'm still on my quest to find an optimal feed format.
> For a real feed format I would like to have a clear separation between titles and content. And more options for the content. Plaintext and HTML at least.

I don't think it's a very good idea to include content when using twtxt as a syndication format. Anything based on twtxt, in my opinion, should retain the spirit of the original specification, especially readability by humans and machines. 10K of HTML in one line absolutely breaks human readability.

What about TIMESTAMP\\tTITLE\\tPERMALINK, like the following?


2022-09-22T14:53:26-07:00\tBringing Back a Useful Browser Feature With a Bookmarklet\thttps://mckinley.cc/blog/20220922.html
> For a real feed format I would like to have a clear separation between titles and content. And more options for the content. Plaintext and HTML at least.

I don't think it's a very good idea to include content when using twtxt as a syndication format. Anything based on twtxt, in my opinion, should retain the spirit of the original specification, especially readability by humans and machines. 10K of HTML in one line absolutely breaks human readability.

What about TIMESTAMP\tTITLE\tPERMALINK, like the following?


2022-09-22T14:53:26-07:00	Bringing Back a Useful Browser Feature With a Bookmarklet	https://mckinley.cc/blog/20220922.html
@mckinley that's more or less what saait from codemadness does
@akoizumi It looks like that feed uses TIMESTAMP\\tTITLE: PERMALINK which would be harder to parse programmatically.

This discussion has me thinking of a serious syndication format built on twtxt that could be implemented in normal feed readers. It would be limited, but extremely easy for a Webmaster to implement. You could also receive updates with a normal twtxt client. I think there could be some utility in it.
@akoizumi It looks like that feed uses TIMESTAMP\\tTITLE: PERMALINK which would be harder to parse programmatically.

This discussion has me thinking of a serious syndication format built on twtxt that could be implemented in normal feed readers. It would be limited, but extremely easy for a Webmaster to implement. You could also receive updates with a normal twtxt client. I think there could be some utility in it.
@akoizumi It looks like that feed uses TIMESTAMP\\tTITLE: PERMALINK which would be harder to parse programmatically.

This discussion has me thinking of a serious syndication format built on twtxt that could be implemented in normal feed readers. It would be limited, but extremely easy for a Webmaster to implement. Users could also receive updates with a normal twtxt client. I think there could be some utility in it.
@akoizumi It looks like that feed uses TIMESTAMP\tTITLE: PERMALINK which would be harder to parse programmatically.

This discussion has me thinking of a serious syndication format built on top of twtxt that could be implemented in normal feed readers. It would be limited, but extremely easy for a Webmaster to implement. Users could also receive updates with a normal twtxt client. I think there could be some utility in it.
@akoizumi It looks like that feed uses TIMESTAMP\\tTITLE: PERMALINK which would be harder to parse programmatically.

This discussion has me thinking of a serious syndication format built on top of twtxt that could be implemented in normal feed readers. It would be limited, but extremely easy for a Webmaster to implement. Users could also receive updates with a normal twtxt client. I think there could be some utility in it.
@mckinley hey! CodeMadness.org has amazing projects 😀
@eaplmx I wasn't making a criticism, I was just pointing out the difference in the format. I agree, there's some great stuff on there.
@mckinley I guess I didn't say it correctly.

I didn't know about that page, it's cool!


About how do they use Twtxt as a feed, I agree on the problem you mention, and of the lack of a convention (unless we use the title/subject as someone suggested later) for automated parsing