# 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 23
# self = https://watcher.sour.is/conv/yrhfw7q
An idea for helping humans and machines understand when a twtxt-feed are using some of the yarn.social extensions by applying a mix of a hash-bang and a DTD to the first line of the txt-file:

#! DOCTYPE = twtxt (https://twtxt.readthedocs.io) with extension for multi-line and conversation treading from Yarn.social (https://dev.twtxt.net)


It would be nice if the link to the extension could be to dev.yarn.social, docs.yarn.social or similar instead of dev.twtxt.net to make it less confusing.
@darch https://git.mills.io/yarnsocial/yarn/issues/1157
@darch https://git.mills.io/yarnsocial/yarn/issues/1157
@marado obrigado 🙏
Cool idea 👌
Cool idea 👌
Cool idea 👌
I don't like the idea of an additional special bang. DTD, bah! Why not simply use # doctype = whatever? Also, which problem does this solve? What would clients do differently? And humans just could look at the comment or URL and see that this feed makes use of extensions – if they care. Twtxt purists would certainly hate such a new thing, too, I don't think it helps them in any way. So I don't see the use case for that. Can you please elaborate, @darch, what you had in mind?

My feed's preamble starts with (links to be debatable):


# Learn more about twtxt at: https://github.com/buckket/twtxt
# This feed makes use of some extensions: https://dev.twtxt.net/
@lyse i don't have much more than this. But I agree to keep it simple. I like your approach.
@lyse from my POV, both approaches achieve the same, and I'd be happy to see one or the other on yarn generated feeds.
@lyse from my POV, both approaches achieve the same, and I'd be happy to see one or the other on yarn generated feeds.
I guess we should discuss implementation now 😆 even though no client would change 🤦‍♂️
I guess we should discuss implementation now 😆 even though no client would change 🤦‍♂️
I guess we should discuss implementation now 😆 even though no client would change 🤦‍♂️
@prologic I like that the information is there to help those reading the feed - automatically (with a client) or manually.
@prologic I like that the information is there to help those reading the feed - automatically (with a client) or manually.
@marado It's probably about the only use at this point 😅 Probably sounds like we should do with some kind of top-level comment like # type = ... and # exts = ...? 🤔
@marado It's probably about the only use at this point 😅 Probably sounds like we should do with some kind of top-level comment like # type = ... and # exts = ...? 🤔
@marado It's probably about the only use at this point 😅 Probably sounds like we should do with some kind of top-level comment like # type = ... and # exts = ...? 🤔
@prologic Come to think about it, I'm more in favor of @lyse 's approach; Make it human readable with relevant links and not do anything specific for the machines. This is almost already the case for twtxt.txt served by yarnd, we just need to add a line to the Yarn.social section explaining about the extensions.
@darch Yup I think so too 👌 -- It would be a small patch to a template if someone put up a PR 👌
@darch Yup I think so too 👌 -- It would be a small patch to a template if someone put up a PR 👌
@darch Yup I think so too 👌 -- It would be a small patch to a template if someone put up a PR 👌