@movq Me too 😅 -- Speaking of which i know you've lost a bit of "mojo" or "energy" (so have i of late), rest assured, I want to keep the status quo here with what we've built, keep it simple and change very little. What we've built has worked very well for 5+ years and we have at least 3 very strong clients (maybe 4 or 5?).

<2025-05-10T19:34:00+00:00 https://andros.dev/texudus.txt> Nice:) And is this implemented in your client as well? I've started to brainstorm on how to parse texudus in php, but I guess it could snatch some code from you?

@sorenpeter Unfortunately it does break all clients, because the original spec stated:

Mentions are embedded within the text in either @source.nick or @<source.url> format

@bender My point was that the suggested syntax for extending mentions to point to a specific message (<a href="/profile?url=url timestamp">@nick</a>) and having location based treading this way, might not break older clients, since they might just igonore the last value within the brackets.

@sorenpeter you wrote:

"This might even be backward compatible with older (pre-yarn) clients."

Yarnd is as backwards compatible with older clients as this. I dare to say, even more so. 😅

@andros Thanks for consolidating a lot of good ideas. Especially how you have deiced to just extend the mention syntax for location-based treads. This might even be backward compatible with older (pre-yarn) clients. What about using Z for UTC +00:00- is that allowed in your specs? Regarding url = I would suggest to only allow one and the maybe add url_old = or url_alt = !? I'm still not a fan of a DM feature, even thou it helps that i have now been split out into a separate feed file. Instead if would suggest a contact = field for where people can put an email or other id/link for an established chat protocol like signal or matrix.

@movq I think we can make this work 👌 As long as it's just a client hint.

just for the record I didn't say I was leaving the twtxt 'community' (did I?) but than I have other priorities to focus on in the following months. Please don't be condescending, is not cool.

Development of Timeline (PHP client) has been stale for some reasons, a few of them in my side, so I think it won't be updated to the new thread model, at least pretty soon. So is not that I'll stop using twtxt, just the client I use won't be compatible with the new model in July.

@movq If we're focusing on solving the "missing roots" problems. I would start to think about "client recommendations". The first recommendation would be:

1. Replying to a Twt that has no initial Subject must itself have a Subject of the form (hash; url).

This way it’s a hint to fetching clients that follow B, but not A (in the case of no mentions) that the Subject/Root might (very likely) is in the feed url.

@lyse likewise I don't have the energy for a fundamental shift in any of our specifications that would inevitably cause a lot of toil and try and change in our clients implementations and unforeseen problems that we haven't really fully understood:

@lyse Hahahaha 🤣 I mean it's "okay" every now and then, but what's the point of having good clients and tools if we don't use 'em 🤣

We have 4 clients but this should be 6 I believe with tt2 from @lyse and Twtxtory from @javivf?

Finally I propose that we increase the Twt Hash length from 7 to 12 and use the first 12 characters of the base32 encoded blake2b hash. This will solve two problems, the fact that all hashes today either end in q or a (oops) 😅 And increasing the Twt Hash size will ensure that we never run into the chance of collision for ions to come. Chances of a 50% collision with 64 bits / 12 characters is roughly ~12.44B Twts. That ought to be enough! -- I also propose that we modify all our clients and make this change from the 1st July 2025, which will be Yarn.social's 5th birthday and 5 years since I started this whole project and endeavour! 😱 #Twtxt #Update

And speaking of Twtxt (See: #xushlda, feeds should be treated as append-only. Your client(s) should be appending Twts to the bottom of the file. Edits should never modify the timestamp of the Twt being edited, nor should a Twt that was edited by deleted, unless you actually intended to delete it (but that's more complicated as it's very hard to control or tell clients what to do in a truely decentralised ecosystem for the deletion case). #Twtxt #Client #Recommendations

Just like we don't write emails by hand anymore (See: #a3adoka), we don’t manually write Twts or update our twtxt.txt feeds. Instead, we use modern Twtxt clients that conform to the specifications at Twtxt.dev for a seamless, automated experience. #Twtxt #Twt #UserExperience

Nobody writes emails by hand using RFC 5322 anymore, nor do we manually send them through telnet and SMTP commands. The days of crafting emails in raw format and dialing into servers are long gone. Modern email clients and services handle it all seamlessly in the background, making email easier than ever to send and receive—without needing to understand the protocols or formats behind it! #Email #SMTP #RFC #Automation

@javivf Ahh! So this is your client implementation? 🧐

Was just looking at the client you're using Twtxtory 🤔 Very nice! 👍 is this your client, did you write it? I'd not come across it before!

$ bat https://twtxt.net/twt/edgwjcq | jq '.subject'
""

hahahahaha 🤣 Does your client allow you to do this or what? 🤔

Interesting factoid... By inspecting my "followers" list every now and again, I can tell who uses a client like jenny, tt or any other client where fetches are driven by user interactions of invoking the app. What do we call this type of client? Hmmm 🤔 Then I can tell who uses yarnd because they are "seen" more frequently 🤣

My Hypothesis for why registries didn't work and why they still won't really work today is because the bend the rules of "true" decentralization a bit. Users have to pick one or more registries to "register" to. Why would they want to do this? What is their incentive to do so? Then on the other hand, users need a client that has registry support, but now which registry or sets of registries do you choose?

by commenting out DMs are you giving up on simplicity? See the Metadata extension holding the data inside comments, as the client doesn't need to show it inside the timeline.

I don't think that commenting out DMs as we are doing for metadata is giving up on simplicity (it's a feature already), and it helps to hide unwanted DMs to clients that will take months to add it's support to something named... an extension.

For some other extensions in https://twtxt.dev/extensions.html (for example the reply-to hash <a href="?search=abcdfeg" class="tag">#abcdfeg</a> or the mention @ < example http://example.org/twtxt.txt >) is not a big deal. The twt is still understandable in plain text. For DM, it's only interesting for you if you are the recipient, otherwise you see an scrambled message like 1234567890abcdef=. Even if you see it, you'll need some decryption to read it. I've said before that DMs shouldn't be in the same section that the timeline as it's confusing.

So my point stands, and as I've said before, we are discussing it as a community, so let's see what other maintainers add to the convo.

@bender You said:

as long as those working on clients can reach an agreement on how to move forward. That has proven, though, to be a pickle in the past.

I think this is because we probably need to start thinking about three different aspects to the ecosystem and document them out:

• Specifications (as they are now)
• Server recommendations (e.g: Timeline, yarnd, etc)
• Client recommendations (e.g: jenny, tt, tt2, twet, etc)

@andros nothing stands still, I agree. I think current twtxt has surpassed the initial specification, while still being relatively backwards compliant/compatible but, for how long?

As for new extensions (DM, for example), they should be OK as long as those working on clients can reach an agreement on how to move forward. That has proven, though, to be a pickle in the past.

The nice thing here is that any Ui/UX rendering for a "good user experience" is similar to what yarnd does for Youtube/Spotify/whatever embedding. Plus anyone can participate, even if they don't really have a client that understand it, it's just text with some "syntax" afterall.

💡 I had this crazy idea (or is it?) last night while thinking about Twtxt and Yarn.social 😅 There are two things I think that could be really useful additions to the yarnd UI/UX experience (for those that use it) and as "client" features (not spec changes). The two ideas are quite simple:

• Voting -- a way to cast, collect a vote on a decision, topic or opinion.
• RSVP -- a way to "rsvp" to a virtual (pr physical) event.

Both would use "plain text" on top of the way we already use Twtxt today and clients would render an appropriate UI/UX.

@prologic no, it is not a “server-client thingy”.

Seem like it's a server-client thingy? 🤔 I much prefer tools in this case and defer the responsibility of storage to something else. I really like restic for that reason and the fact that it's pretty rock solid. I have zero complaints 😅

@javivf having the extension listed means that it has been discussed and, usually implemented. Now, number 6 and 7 on the list as its stands today are not supported by any of the known clients. I believe their (again, 6 and 7) inclusion on the list has been precipitated, and lax.

@quark No editing old Twts that are the root of a thread with replies in the ecosystem. Just results in a fork. Unless the client has an implementation that does not store Twts keyed by Hash.

@andros I give you not creating another file, but then I'd vote for commenting out DMs. See https://eapl.me/timeline/post/z5e2bna

It's easier to find the DM in comments from your side, than asking all the client maintainers to add the regex =P You can even use a Modified comment, such as #! <DM content> Or something like that

This approach is retro-compatible with current and older clients.

@doesnm.p.psf.lt It was always intended to have both Yarn.social and Salty.im integrate together. Yes. This includes having a set of specifications that anyone can write clients to.

my main itch with the DMs extensions is that these messages are intended to be private, not public information. That's why other extensions make sense, but DMs are another kind of feature. TwiXter, Mastodon, FB and some other services usually hide the DMs in another section, so they are not mixed with the public timeline.

I find the DM topic interesting, I even made an indie experiment for a centralized messaging system here https://github.com/eapl-gemugami/owl. Although, as I've said a few times here, I'm not particularly interested in supporting it on microblogging, as I don't use it that much. In the rare case I've used them, I don't have to manage public and private keys, and finally none of my acquaintances use encrypted email. Nothing personal against anyone, and although I like to debate and even fight, it's not the case here. This proposal is the only one allowing DMs on twtxt, and if the community wants it, I'll support it, with my personal input, of course.

A good approach I could find with a good compromise between compatibility with current clients and keeping these messages private is 'hiding' the DMs in comments. For example: `# 2025-04-13T11:02:12+02:00

I think I would encourage anyone in this community is to care less about supporting "legacy clients" and focus more on value-add whilst balancing the burden of client authors -- which have very precious little "spare time" 🤣

@andros I don't see any "fighting" here. This is just good experimentation. Unfortunately there hasn't really been enough time or effort by other "client authors" yet, me especially as I've been super busy with ya' know my "day job" that pays the bills and refactoring yarnd to use a new and shiny and much better SqliteCache 🤣 -- I certainly don't think your efforts are wasted at all. I would however like @doesnm.p.psf.lt encourage you to look at the work we've done as a community (which was also driven out of the Yarn.social / Twtxt community years back).

@andros maybe create a separate, completely distinct feed for DM? That way, clients do not need to do anything, only those wanted to "talk in private" follow themselves, using their very special dm-only.txt feeds. 😂

not a big deal as I can skip those messages, but again, it's an extension, so older clients shouldn't be affected by a new feature.

I'm also thinking that some kind of tag might be needed to automatically hide twts from unknown extensions. For example our client doesn't support DMs and always shows the !<nick url><encrypted_message> syntax which is meaningless.

Aside from fetching feeds every three minutes (which kind of adds mystery to this puzzle), I think there is something else going on with the client you are using, @andros. Some of those twtxts are seconds apart, making me truly stumped. 😅

yay! A new client 😀

thanks for sharing @xuu!

Checking for example https://watcher.sour.is/api/plain/twt or https://registry.twtxt.org/api/plain/tweets, I don't know whether this syntax is being used by clients or by people. Is it integrated on Yarn in any way? Genuinely asking to know more about it.

If I might throw a quick thought to those working on the registries, it would be nice to have an endpoint with a valid twtxt output (perhaps cached or dumped to a static file) which a client could point to, helping to discover it's content in a way which is compatible with the twtxt spec.

Taking the first twt I found in https://watcher.sour.is/api/plain/twt as an example: `reddit_world_news

somehow I forgot that existed.

Perhaps it was its mention of being a demo implementation here: https://twtxt.readthedocs.io/en/latest/user/registry.html#registry So I though it wasn't really active.

Anyway, I think that's a good idea.

Is there something similar available on Yarn? Sorry for for asking if that was mentioned recently.

I think that the clients may help you to submit your URL to these directories, and also to get a view of the twts in them.

thanks @prologic! @bender the idea of the RFC was to reach an agreement on a difficult problem, receiving proposals, and the voting is a simple count to gauge the sentiment of "is this a problem worth to be fixed?, are we committed to implement a change in our clients?"

But that's a fair point. What do the community expect? What do y'all expect?

Twtxt was made for nerds, by nerds. I'd like to change that. It's by nerds/hackers, for nerds/hackers and friends of these. It doesn't have to be hacky all the time, as you don't need to be a nerd to have a blog. But, for that to happen, someone has to build the tools to improve UX.

by design there really is no way to easily discovers others Yeah, I agree, and although there are directories of email addresses, usually you don't want that, unless you are a 'public figure'. I couldn't say that a microblogging is a "social network" by default, as a blog is not either. At the same time, people would expect to find new people and conversations, as you'd do in a forum.

I think of two features on top of the current spec:

• Clients showing a few posts of what your following are watching but you don't, so perhaps you find something interesting to follow next. Or that feature of "Your 'followings' are following these accounts/people". (Hard to explain in english, but I hope you get the idea)
• Sharing your .txt into some directory, saying "Hey, I have this twtxt URL, I want to be discovered". I'm thinking of something like the Federated tab on Mastodon.

thanks andros!

instead of adding the new twt at the end of the feed, do it at the beginning The PHP client did that originally, although I didn't see a real benefit if you use... a client. It could help if you read the .txt file through a browser or something. Also, not many clients are prepared to cut the request, and you can't rely on the file being organized that way, so finally we dropped that feature.

"it is very easy to filter or ignore it" This is the interesting part for legacy clients, hehe

Joking aside, let's see how it works in the wild!

well, I assume by syntax you mean Gemtext (which I like a lot, my personal blog is built on top of it), so I think it might work for twtxt clients...

I knew of twtxt in Gemini Antenna, so at least the 2017 spec might work on that protocol. I think the main issue with extensions is that they weren't designed with many URLs and protocols in mind.

Also I have to admit that the Gemini community significantly reduced in the last few years. I don't know how worth it is to add support for Gemini now.

I have applied your comments, and I tried to add you as an editor but couldn't find your email address. Please request editing access if you wish.

Also, could you elaborate on how you envision migrating with a script? You mean that the client of the file owner could massively update URLs in old twts ?

well... it has been an opportunity to build an artisanal microblogging client on top of a minimalist protocol. I agree on the hacker toy part.

And of course it's about being part of a niche community which is (mostly) amazing, and nurturing. As there is almost no one writing in my native spanish, it has been an interesting challenge to share my thoughts in english, as well.

I couldn't say it's a 'social network' per se, I think it lack many engagement things usually associated with social networks, although it has a social part of igniting discussions, learnings and behavioral changes, which is the meaning of social for me.

ah! those german calendars. Somehow I was thinking of something like mine, with spaces to write inside each day.

I worked for a german company and they gave away these calendars to our clients and team every year, but the model you can hang on the wall. Memory unlocked!