Given the continued hostility of jam6 and buckket over Yarn’a use of Twtxt (even after several years! 😱) I am continuing to face hard decisions.

I am not sure what to do about this. 🤔 I am quite confident that the hostility and sentiment is not held by all Twtxt users past and present 😢

This is a case of a few upset purists who prefer to mock, shame and behave passive aggressively instead of contributing to a healthy discussion and ecosystem.

I am uncertain what Yarn should do here 😢

Huh? Not sure what you are referring to here to be honest.

@stigatle@yarn.stigatle.no I’ll take a copy of the conversations over the last few days in the #twtxt ITC channel and link here 👌

@stigatle@yarn.stigatle.no Does this work? 🤔 https://www.irccloud.com/log-export/160242/irccloud-export-110340-2023-04-16-09-41-27.zip

Arggg “Forbidden” 🤦‍♂️

Here you go: https://files.mills.io/download/Twtxt%20IRC%20Logs%202023-04-14.md

@prologic@twtxt.net net::ERR_HTTP_RESPONSE_CODE_FAILURE

@marado@twtxt.net Working for me?

=> https://files.mills.io/download/Twtxt%20IRC%20Logs%202023-04-14.md

Here’s an alternative link: https://gist.github.com/prologic/16a88f1ebbd3d13e4cc6352615919b87

@prologic@twtxt.net the other still doesn’t work for me, but this one does

@prologic@twtxt.net What I take out from this log is that buckets client is truncating twts when seeing one of those characters you use for newline: a PR fixing that should suffice. As for the rest, I see twtxt as meant to be a readable format, and I think yarn is not messing with that. Is someone doesn’t like yarn’s writing style (or anything else on any other feed) they can simply not follow them. I see no reason at all for yarn to change its underlying format away from twtxt.

@marado@twtxt.net Yup I completely agree. 💯 @lyse@lyse.isobeef.org has significant bug fixes for buckket’s original twtxt client, including support for multi-lines (\u2028), I suppose anyone (even I) could put up a PR that addresses that, it’s a trivial 1-line patch.

As for your very positively written position and point, absolutely 100% 👌 The fact that some folks write cryptic posts to their Twtxt feed (e.g: the feed that posts geospatial coordinates updates and a status of some reading off a device), or some other formats (rare, but do exit), plain text, Markdown or HTML are all attributes of what the author chooses to write. Probably the only form that would be quite hard to cope with manually would be XML/HTML 🤣

But as you say, if you don’t find it useful, don’t like it, or whatever, simply don’t follow it.

Also whilst I understand the appeal of curl url | less to read a feed, I find this a terrible user experience in the first place, yes it should be possible to use UNIX text manipulation tools for feeds, which is why using Twtxt as the “spec” and “transport” of the content is so ideal. – Should you read feeds this way primarily? Probably not.

here’s the 1-line patch: https://github.com/buckket/twtxt/compare/master…prologic:twtxt-1:patch-1 (untested)

@prologic@twtxt.net I’d actually not replace it with newlines but with a space or something like that, so there’s nothing breaking (twtxt output parsers or whatever, expecting only one line per twt).

@marado@twtxt.net Ahh good point, or with a --? I sometimes try to separate different paragraphs or points with a -- instead of a new line / paragraph break. I don’t mind either way, but will amend the PR later when I get back from the tournament, unless you’d like to make the suggested change and I’ll just accept it? 🙏

@prologic@twtxt.net Honestly this is quite disappointing to see as someone new to the twtxt/yarn ecosystem - it feels like the entirety of the buckket argument is based on a “purist” viewpoint when nothing yarn does feels fundamentally incompatible with original twtxt

Very sad 😔

However I do agree with jan6 on that while yarn is a great twtxt client, twtxt is a terrible yarn client

That doesn’t mean that yarn should change its underlying format away from twtxt though, twtxt is probably yarn’s biggest selling point

my view of twxt is essentially a feed of arbitrary plain text data with timestamps, which can open up the ecosystem to all sorts of good experimentation in clients

and for the specific case of multiline twts, when you actively have a pr waiting which addresses the issue, the stubbornness of the opposition seems quite unreasonable

that’s just my two cents, didn’t mean to write a paragraph (lol a multiline twt for you right here)

@shreyan@twtxt.net Thanks for your encouraging words 🤗

I also agree that buckket’s twtzt dlient makes a terrible Yarn client – I would even go so far as to say it’s not very well maintained either as it has been broken for some time 😢

Yes we can raise a PR against the original reference client – But I’m not convinced it’ll get accepted 😢

@prologic@twtxt.net You can’t win them all. Just leave that channel. Fixed. :-)

@prologic@twtxt.net I get ‘forbidden’ on that link.

I don’t buy jan6’s premise that twts with markdown and image links is hard to read. Markdown came out of how people simulated typeset text in plain text and the URL part of links to images and others resources are also easy for humans to read and parse.

Multi-line is another matter, but I also never used the original client. I guess it could have been implemented in a was that would not break other clients. Using something like -- or just two space at the end of a line like in markdown would also work.

This is a nice idea: Suggestion: a convention for multiline statuses (line breaks) · Issue #157 · buckket/twtxt – But it would break out treading model with (#hash)

@darch@twtxt.net case in point, I used to twtxt images before using yarn or markdown tp do it - and markdown isn’t making twts like this any less readible.

@marado@twtxt.net ++ 💯