I keep getting this email occadionally:

Your iCloud storage is almost full

Now for various reasons, I don't want my children to be using iCloud to store data, files, photos or any of the sort. They're free to use iMessages, and other Apple services like the App Store, etc, but not storage.

So I've set about blocking iCloud Storage API(s) via AdGuard Home tonight as well as ensuring that my local network (client users) cannot bypass DNS policies and get out other sneaky ways, because some applications will just use other DNS servers, or DOH or DOT.

Of course, all things optional is fine. Like, it will be ignored (just like banner would) for clients having no knowledge of it.

Put another way, what you are proposing/pushing for requires hundreds of lines of code to change across a half dozen or so clients and lots of breaking changes, not to mention unknowns.

What I want us to do is make only a few half dozen or so lines of code changes to our clients and minimize the breaking changes and unknowns.

@zvava Going to have to hard disagree here I'm sorry. a) no-one reads the raw/plain twtxt.txt files, the only time you do is to debug something, or have a stick beak at the comments which most clients will strip out and ignore and b) I'm sorry you've completely lost me! I'm old enough to pre-date before Linux became popular, so I'm not sure what UNIX principles you think are being broken or violated by having a Twt Subject (Subject) whose contents is a cryptographic content-addressable hash of the "thing"™ you're replying to and forming a chain of other replies (a thread).

I'm sorry, but the simplest thing to do is to make the smallest number of changes to the Spec as possible and all agree on a "Magic Date" for which our clients use the modified function(s).

@prologic considering other alternatives we have seeing (of which I have lost track already), yes. Why don’t you guys (client makers) take a step at a time and, for now, increase the hash length to deal with the collisions. Then location-based addressing can be added… or not, you know. 😅

TNO Threading (draft):
Each origin feed numbers new threads (tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).

• Roots: (tno:N) (implicit ofeed=self).
• Replies: (tno:N) (ofeed:<url>).
• Clients: increment tno locally for new threads, copy tags on reply.
• Subjects optional, not required.

...

Here is just a small list of things™ that I'm aware will break, some quite badly, others in minor ways:

1. Link rot & migrations: domain changes, path reshuffles, CDN/mirror use, or moving from txt → jsonfeed will orphan replies unless every reader implements perfect 301/410 history, which they won’t.
2. Duplication & forks: mirrors/relays produce multiple valid locations for the same post; readers see several “parents” and split the thread.
3. Verification & spam-resistance: content addressing lets you dedupe and verify you’re pointing at exactly the post you meant (hash matches bytes). Location anchors can be replayed or spoofed more easily unless you add signing and canonicalization.
4. Offline/cached reading: without the original URL being reachable, readers can’t resolve anchors; with hashes they can match against local caches/archives.
5. Ecosystem churn: all existing clients, archives, and tools that assume content-derived IDs need migrations, mapping layers, and fallback logic. Expect long-lived threads to fracture across implementations.

@zvava And yes yarnd does have a well documented API and two clients (CLI and unmaintained Flutter App)

Wanting to add, this isn't a twtxt client. It is Yarnd on steroids! 😂

@dce Twet is a far better command line client. Yea 👌

@eric Name change is no worries! 😉 Interesting/funnily enough my client yarnd seems to have picked it up automatically which is nice (I've historically always had a few bugs to iron out there 🤣)

@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. 😅