# 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 12
# self = https://watcher.sour.is/conv/ybjlgha
mckinley
twtxt.net
View Thread
> 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
lyse
lyse.isobeef.org
View Thread
@mckinley Even though I miss a title for general purposes, I'm not sold of cramming it into twtxt. It's just not made for it. To only announce new articles, that format would work, though. It's basically what some people already do, except a space rather than a tab is used between the title and link.
darch
neotxt.dk
View Thread
@mckinley we already got a title field in form of (subject) -- it's just hidden here on yarn by design

I agree with @lyse on this. It is outside the scope of twtxt as a microbloging protocol to start including more formel metadata fields such as titles
prologic
twtxt.net
View Thread
Agree with @lyse here too 👌 It adds little value to the spec when we already have mechanisms to share titles by convention.
prologic
twtxt.net
View Thread
Agree with @lyse here too 👌 It adds little value to the spec when we already have mechanisms to share titles by convention.
lyse
lyse.isobeef.org
View Thread
@darch Titles and subjects are two different things in my opinion. A title is a caption, brief summary or some description of a longer content that follows. A subject is a – in this case human readable – reference in a reply to some topic in order to group several twts to a conversation. Forks aside, the first twt starting a discussion typically doesn't have a subject. But some article would have a title in most cases. You are right in that the subject mechanism could be abused for a crude title implementation. I wouldn't do it, though.
mckinley
twtxt.net
View Thread
I'm sorry, I didn't explain this properly and that has led to a misunderstanding of my actual proposal. I was not intending for the title to be a special field unless the client explicitly understood my syndication format.

The original twtxt format specification gives no special meaning to the tab character, excluding the one that separates the timestamp from the text. I was under the impression that the tab character could appear in a twt so it would be interpreted as follows, replacing ␉ with a tab character.


2022-09-22T14:53:26-07:00␉Bringing Back a Useful Browser Feature With a Bookmarklet␉https://mckinley.cc/blog/20220922.html
#^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#|                        |
#
- Timestamp age


Although, I just remembered that the tab character is technically a control code, so it shouldn't be allowed in
mckinley
twtxt.net
View Thread
I'm sorry, I didn't explain this properly and that has led to a misunderstanding of my actual proposal. I was not intending for the title to be a special field unless the client explicitly understood my syndication format.

The original twtxt format specification gives no special meaning to the tab character, excluding the one that separates the timestamp from the text. I was under the impression that the tab character could appear in a twt so it would be interpreted as follows, replacing ␉ with a tab character.


2022-09-22T14:53:26-07:00␉Bringing Back a Useful Browser Feature With a Bookmarklet␉https://mckinley.cc/blog/20220922.html
#^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#|                        |
#
- Timestamp age


Although, I just remembered that the tab character is technically a control code, so it shouldn't be allowed.
lyse
lyse.isobeef.org
View Thread
@mckinley I got your point and I'm also under the impression that \\t is allowed in the message. Can you elaborate on why you think it is not?
lyse
lyse.isobeef.org
View Thread
@mckinley I got your point and I'm also under the impression that \t is allowed in the message. Can you elaborate on why you think it is not?
mckinley
twtxt.net
View Thread
@lyse The specification just says:

> Also note that a status may not contain any control characters.

Which is extremely vague, but U+0009 Horizontal Tabulation *is* in the C0 control code block

I'm sure 99% of twtxt parsers don't treat additional tabs any differently. Even Buckket's reference implementation includes additional tabs in the message. Although, in fairness, it doesn't check for *any* for control codes.

Maybe we need a less ambiguous specification documenting how twtxt feeds are being written in the wild. Did you know that the comment convention is not a part of the original spec? I feel like it's used everywhere, even among feeds that don't use any Yarn extensions.
lyse
lyse.isobeef.org
View Thread
@mckinley Oh, very interesting, thank you! Hahaha, great finding about comments. It never occurred to me either. Same with empty lines I reckon. I reckon a comment extension should be documented next. ;-)