Add # for comments in Feed

[DracoBlue]

Hello,

it would be nice, if the client ignores lines starting with #. This way the feed format would be extensible with e.g. the date of creation or other meta fields (e.g. # nickname dracoblue is a hint for clients, who get it).

[dontdieych]

2016-02-08T02:05:53+09:00 how about using 'mbox' format for twtxt selectively? we could only use 'From:', 'To:', 'Date:', 'Subject:' etc.

That is my tweet few mins ago.

how about just use subset of mail header format and optional body?

[mkody]

@dontdieych The current format is great because it's simple and "human readable". Adding something like you said would make it harder to read, in my opinion.

[dontdieych]

if we need to add some kind of metadata eventually, avoid new format as possible as.

how about toml? twtxt already use this ini style in own config file.

date = 2016-02-07T18:59:41+0000
tweet = "another 140 characters log tweet"
to = "http://example.com/twtxt.txt"
cc = [ 'http://1.example.com/tw.txt'
     , 'http://2.example.com/tw.txt'
]

[timofurrer]

@dontdieych I see the same problems with the suggested toml as @mkody already pointed out. In my opinion it's even worse.

I like the approach of the plain human readable tweet format. It makes working with other linux tools just perfect ...

However, what @DracoBlue and you guys are suggesting seem to be a different discussion.
I think @DracoBlue was not talking about enhancing the tweet format per se but the metadata for the twtxt user itself ...

[DracoBlue]

Yep!

But one could use

# general meta
# line two
TIMESTAMP tweet content
# meta for the tweet
TIMESTAMP tweet no. 2 content
# meta for second tweet

if really necessary

If you add only comments, it is not that difficult fir simple clients and yet powerful enough for more advanced usage.

[mkody]

This could be interesting if this adds metadata. Someone pointed out to maybe have a list of people we follow somewhere (#3) or even have a "replied to" block too. I could imagine something like that:

# following: bob <http://example.org/twtxt.txt>, foo <http://foobar.com/twtxt.txt>
# source: twtxt
2016-02-07T10:12:58+01:00   Hello, world!
# source: htwtxt - in reply to: http://foobar.com/twtxt.txt#2016-02-07T16:23:33+01:00
2016-02-07T16:53:00+01:00   @<http://foobar.com/twtxt.txt> Great idea!

[timofurrer]

I like this comment-metadata approach for the twtxt itself - like nicknames, etc.

I'm not pretty sure about the metadata for the tweets ..
I think we need to come up with an idea of what we want to support in future, like media files, mentions, responses .. maybe retweets etc...
The comment approach in this sense is very useful because it would be easy to extend and ignore unknown data ..

[mkody]

@timofurrer

I think we need to come up with an idea of what we want to support in future, like media files, mentions, responses .. maybe retweets etc...

I think we know that we can't put media files inside a .txt except by linking to them with an url (could be self-hosted or just be imgur links). For responses, I've given my idea on how to "mark" them (so we could make something like a "thread"). For the retweets, this could be done with a "source: <url>" in the metadata line too.
For mentions, the limitation of twtxt here is that we can't see them if we're not following the user.

---

But hey, that's my point of view, I'd like to see your ideas too 👍

[timofurrer]

@mkody Of course not the media file itself :) I thought about links (whether self-hosted or not). On command line you just open the link (with whatever) and maybe there'll be a rich ui application in future which can display media files properly.

I know ... there are some limitations with the mentions..

[erlehmann]

@DracoBlue Atom XML solves metadata. I generated http://daten.dieweltistgarnichtso.net/tmp/docs/twtxt.xml from http://daten.dieweltistgarnichtso.net/tmp/docs/twtxt.txt.

[erlehmann]

@dontdieych Atom XML already exists. There are a lot of readers for it, and browsers (with the exception of Google Chrome) support it because they support podcasts.

[erlehmann]

@mkody Atom XML can do replies and threads and sources AFAIK.

[erlehmann]

@timofurrer Atom XML can do media. If you have ever used a podcast client, you have probably used the Atom or RSS XML formats.

[timofurrer]

I really don't like XML for twtxt.. but that's probably just my personal preference ..

[tedder]

agree. I don't like XML for anything though. I love the simplicity of this model.

[erlehmann]

@timofurrer my point is that Atom XML has solved all the problems that people brought up in this thread in an open, interoperable and widely implemented manner. There are lots of programs that create it and lots of programs that consume it.

If you think “I do not like” is not a good reason to not use a widely implemented working solution, do you think that your feelings are more important than that software works well?

[erlehmann]

@tedder I like the simplicity of this model as well. What I am saying is: If your use case is more complex, there is already a file format that can provide it – with a software ecosystem around it as well. twtxt does not even have the software ecosystem (something that often works in favour of proprietary solutions).

[tedder]

if that's the case, where's the twtxt equivalent in OPML and atom?

[timofurrer]

@erlehmann Yes 🍻

No, the thing is .. I love the way of simplicity twtxt has at the moment and I really hope this is gonna stay that way as long as possible. I'm glad you mentioned OPML - it's definitely worth to check out and consider it but like I said I would try to stay away from XML and try to find another good solution ..

[erlehmann]

@tedder http://newsbeuter.org/screenshots.html

[erlehmann]

@timofurrer Atom XML is widely implemented: There are lots of emitters, and lots of consumers. Regarding staying away from XML … what argument do you have that is more important than “there is a lot of software that interoperabley emits and consumes the file format” ? Do you have a suggestion for a format that is widely implemented and, for example, even more human-readable?

[buckket]

I’m still thinking about this one, but one thing I can say for sure: XML-based formats are definitely not an option. Total overkill for what this tool tries to solve and archive. We may not be able to map every complex use cases that way, but in my opinion that’s worth it for the sake of simplicity.

[erlehmann]

@buckket XML formats have one thing going for them, they are composable and forwards compatible because of that. You can just insert new elements under a new namespace.

[tedder]

XML vs text is pretty much an intractable discussion. XML has great advantages but it comes with its own disadvantages- it can't be piped through simple tools like cut and grep, broken XML breaks the whole thing (unless you use specific libraries to guard against it).

[tedder]

(while we're at it, vim or emacs?)

[erlehmann]

@tedder have you checked out newsbeuter? What do you think of it?

[tedder]

yeah- looked at it. Looks like a great app (for a given workflow/UI preference), but I (personally) don't like the LOC required to get something like that running.

[erlehmann]

What is LOC in this context?

[tedder]

Lines of code.

[erlehmann]

@tedder on my system, twtxt has ~550 LOC, newsbeuter-2.8 has >18k LOC, coreutils-8.24 has >64k LOC. May I ask what kind of browser you are posting with and how many LOC it has? I am interested how a browser looks and feels that appeals to your aesthetic.

[tedder]

I use twtxt on the command line.

But this is all offtopic; I won't reply further.

[erlehmann]

@tedder you did not answer my question.

[DracoBlue]

Any chance to move this discussion out of this thread ? ;)

Am Dienstag, 9. Februar 2016 schrieb Nils Dagsson Moskopp :

@tedder https://github.com/tedder you did not answer my question.

—
Reply to this email directly or view it on GitHub
#22 (comment).

http://dracoblue.net

[mkody]

Yes, please open a new issue if you want to discuss about using an another format.

[archusr]

Talking about feed, is the twtxt.txt file defined to be appending? Should the convention state maybe be .log instead of .txt?

[mdom]

Although the spec just notes that

A specific ordering of the statuses is not mandatory.

that's what all clients i know of are doing.

[DracoBlue]

Closed in favour of #48