@itsericwoodward@itsericwoodward.com I used the dates as is for indexing them as string, the ISO format allows for free auto sorting.

@bender@twtxt.net Thanks for asking!

So, I’ve been working on 2 main twtxt-related projects.

The first is small Node / express application that serves up a twtxt file while allowing its owner to add twts to it (or edit it outright), and I’ve been testing it on my site since the night I made that post. It’s still very much an MVP, and I’ve been intermittently adding features, improving security, and streamlining the code, with an eye to release it after I get an MVP done of project #2 (the reader).

But that’s where I’ve been struggling. The idea seems simple enough - another Node / express app (this one with a Vite-powered front-end) that reads a public twtxt file, parses the “follow” list, grabs (and parses) those twtxt files, and then creates a river of twts out of the result. The pieces work fine in seclusion (and with dummy data), but I keep running into weird issues when reading real-live twtxt files, so some twts come through, while others get lost in the ether. I’ll figure it out eventually, but for now, I’ve been spending far more time than I anticipated just trying to get it to work end-to-end.

On top of it, the 2 projects wound up turning into 4 (so far), as I’ve been spinning out little libraries to use across both apps (like https://jsr.io/@itsericwoodward/fluent-dom-esm, and a forthcoming twtxt helper library).

In the end, I’m hoping to have project 1 (the editor) into beta by the end of October, and project 2 (the reader) into beta sometime after that, but we’ll see.

I hope this has satisfied your curiosity, but if you’d like to know more, please reach out!

@bender@twtxt.net Thanks for asking!

So, I’ve been working on 2 main twtxt-related projects.

The first is small Node / express application that serves up a twtxt file while allowing its owner to add twts to it (or edit it outright), and I’ve been testing it on my site since the night I made that post. It’s still very much an MVP, and I’ve been intermittently adding features, improving security, and streamlining the code, with an eye to release it after I get an MVP done of project #2 (the reader).

But that’s where I’ve been struggling. The idea seems simple enough - another Node / express app (this one with a Vite-powered front-end) that reads a public twtxt file, parses the “follow” list, grabs (and parses) those twtxt files, and then creates a river of twts out of the result. The pieces work fine in seclusion (and with dummy data), but I keep running into weird issues when reading real-live twtxt files, so some twts come through, while others get lost in the ether. I’ll figure it out eventually, but for now, I’ve been spending far more time than I anticipated just trying to get it to work end-to-end.

On top of it, the 2 projects wound up turning into 4 (so far), as I’ve been spinning out little libraries to use across both apps (like https://jsr.io/@itsericwoodward/fluent-dom-esm, and a forthcoming twtxt helper library).

In the end, I’m hoping to have project 1 (the editor) into beta by the end of October, and project 2 (the reader) into beta sometime after that, but we’ll see.

I hope this has satisfied your curiosity, but if you’d like to know more, please reach out!

@movq@www.uninformativ.de better than in the US. Our lasts only 10 years, and you need to go through the vision test, and, of course, pay). Recently they added a little gold star denoting “real ID” compliance, and we had to pay $10 to get the old one replaced—out of the regular renew “schedule”.

In here it is all about control, and money.

@alexonit@twtxt.alessandrocutolo.it Yhays kind of love you!! Stance and position on this. If we are going to make chicken changes in the threading model, let’s keep content based addressing, but also improve the use of experience. So in fact, in order to answer your question, I think yes, we can do some kind of combination of both.

@lyse@lyse.isobeef.org @prologic@twtxt.net Can’t we find a middle ground and support both?

The thread is defined by two parts:

1. The hash
   
2. The subject
   

The client/pod generate the hash and index it in it’s database/cache, then it simply query the subject of other posts to find the related posts, right?

In my own client current implementation (using hashes), the only calculation is in the hash generation, the rest is a verbatim copy of the subject (minus the # character), if this is the common implemented approach then adding the location based one is somewhat simple.

function setPostIndex(post) {
    // Current hash approach
    const hash = createHash(post.url, post.timestamp, post.content);

    // New location approach
    const location = post.url + '#' + post.timestamp;

    // Unchanged (probably)
    const subject = post.subject;

    // Index them all
    addToIndex(hash, post);
    addToIndex(location, post);
    addToIndex(subject, post);
}

// Both should work if the index contains both versions
getThreadBySubject('#abcdef') => [post1, post2, post3]; // Hash
getThreadBySubject('https://example.com#2025-01-01T12:00:00') => [post1, post2, post3]; // Location

As I said before, the mention is already location based @<example https://example.com/twtxt.txt>, so I think we should keep that in consideration.

Of course this will lead to a bit of fragmentation (without merging the two) but I think this can make everyone happy.

Otherwise, the only other solution I can think of is a different approach where the value doesn’t matter, allowing to use anything as a reference (hash, location, git commit) for greater flexibility and freedom of implementation (this probably need the use of a fixed “header” for each post, but it can be seen as a separate extension).

@lyse@lyse.isobeef.org I don’t think there’s any point in continuing the discussion of Location vs. Content based addressing.

I want us to preserve Content based addressing.

Let’s improve the user experience and fix the hash commission problems.

@movq@www.uninformativ.de Woah, cool!

(WTF, asciiworld-sat-track somehow broke, but I have not changed any of the scripts at all. O_o It doesn’t find the asciiworld-sat-calc anymore. How in the world!? When I use an absolute path, the .tle is empty and I get a parsing error. Gotta debug this.)

@prologic@twtxt.net I know we won’t ever convince each other of the other’s favorite addressing scheme. :-D But I wanna address (haha) your concerns:

1. I don’t see any difference between the two schemes regarding link rot and migration. If the URL changes, both approaches are equally terrible as the feed URL is part of the hashed value and reference of some sort in the location-based scheme. It doesn’t matter.

2. The same is true for duplication and forks. Even today, the “cannonical URL” has to be chosen to build the hash. That’s exactly the same with location-based addressing. Why would a mirror only duplicate stuff with location- but not content-based addressing? I really fail to see that. Also, who is using mirrors or relays anyway? I don’t know of any such software to be honest.

3. If there is a spam feed, I just unfollow it. Done. Not a concern for me at all. Not the slightest bit. And the byte verification is THE source of all broken threads when the conversation start is edited. Yes, this can be viewed as a feature, but how many times was it actually a feature and not more behaving as an anti-feature in terms of user experience?

4. I don’t get your argument. If the feed in question is offline, one can simply look in local caches and see if there is a message at that particular time, just like looking up a hash. Where’s the difference? Except that the lookup key is longer or compound or whatever depending on the cache format.

5. Even a new hashing algorithm requires work on clients etc. It’s not that you get some backwards-compatibility for free. It just cannot be backwards-compatible in my opinion, no matter which approach we take. That’s why I believe some magic time for the switch causes the least amount of trouble. You leave the old world untouched and working.

If these are general concerns, I’m completely with you. But I don’t think that they only apply to location-based addressing. That’s how I interpreted your message. I could be wrong. Happy to read your explanations. :-)

@prologic@twtxt.net I can see the issues mentioned, but I think some can be fixed.

1. The current hash relies on a url field too, by specification, it will use the first # url = <URL> in the feed’s metadata if present, that too can be different from the fetching source, if that field changes it would break the existing hashes too, a better solution would be to use a non-URL key like # feed_id = <UNIQUE_RANDOM_STRING> with the url as fallback.

2. We can prevent duplications if the reference uses that same url field too or the client “collapse” any reference of all the urls defined in the metadata.

3. I agree that hashing based on content is good, but we still use the URL as part of the hashing, which is just a field in the feed, easily replicable by a bot, also noting that edits can also break the hash, for this issue an alternative solution (E.g. a private key not included in the feed) should be considered.

4. For offline reading the source would be downloaded already, the fetching of non followed feeds would fill the gap in the same way mentions does, maybe I’m missing some context on this one.

5. To prevent collisions there was a discussion on extending the hash (forgot if that was already fixed or not), but without a fallback that would break existing clients too, we should think of a parallel format that maintains current implementations unchanged, we are already backward compatible with the original that don’t use threads at all, a mention style format for that could be even more user-friendly for those clients.

We should also keep in mind that the current mention format is already location based (@<example https://example.com/twtxt.txt>) so I’m not that worried about threads working the same way.

Hope to see some other thought about this matter. 🤓

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.

Apologies if I’ve been spamming anyone out there in twtxt-land today.

I’ve been working on a couple of twtxt-related projects, and one of them is a reader (tentatively called twtstrm) written in JS. I used dummy data for the first few stages of development, but now I’m at the point where I need some real data, and that meant hitting up my actual following list.

Of course, it didn’t help that I had a typo in my If-Modified-Since headers, but all that has since been resolved.

Anyways, if I accidentally spammed you with requests today, I am sorry, and it shouldn’t happen anymore.

We thank you for your patience, and apologize for the inconvenience.

Apologies if I’ve been spamming anyone out there in twtxt-land today.

I’ve been working on a couple of twtxt-related projects, and one of them is a reader (tentatively called twtstrm) written in JS. I used dummy data for the first few stages of development, but now I’m at the point where I need some real data, and that meant hitting up my actual following list.

Of course, it didn’t help that I had a typo in my If-Modified-Since headers, but all that has since been resolved.

Anyways, if I accidentally spammed you with requests today, I am sorry, and it shouldn’t happen anymore.

We thank you for your patience, and apologize for the inconvenience.

@kat@yarn.girlonthemoon.xyz, see this one, regarding “Anubis” (which I believe you use, right?): https://github.com/eternal-flame-AD/pow-buster

@zvava@twtxt.net There would be only one hash for a message. Some to be defined magic date selects which hash to use. If the message creation timestamp is before this epoch, hash it with v1, otherwise hammer it through v2. Eventually, support for v1 could be dropped as nobody interacts with the old stuff anymore. But I’d keep it around in my client, because why not.

If users choose a client which supports the extensions, they don’t have to mess around with v1 and v2 hashing, just like today.

As for the school of thought, personally, I’d prefer something else, too. I’m in camp location-based addressing, or whatever it is called. There more I think about it, a complete redesign of twtxt and its extensions would be necessary in my opinion. Retrofitting has its limits. Of course, this is much more work, though.

@lyse@lyse.isobeef.org i dont mind if the hash is not backward compatible but im not sure if this is the right way to proceed because the added complexity dealing with two hash versions isnt justified

regular end users wont care to understand how twt hashes are formed, they just want to use twtxt! so i guess i could work in protecting users from themselves by disallowing post edits on old posts or posts with replies, but i’m not fond of this either really. if they want to break a thread, they can just delete the post (though i’ve noticed yarn handling post deletes dubiously…)

on activitypub i do genuinely find myself looking through several month or even year old posts sometimes and deciding to edit/reword them a little to be slightly less confusing, this should be trivial to handle on twtxt which is an infinitely simpler specification

Adding too this. The configuration example at the repository reads:

{
	"nick": "Example",
	"description": "alice's twtxt instance!",
	"host": "twtxt.example.com",
	"admin": "alice"
}

Would it make more sense changing nick to instance_name or similar? Usually nick is reserved for users, like here, quark. Right? Also, is host the same FQDN to be used while proxying traffic to the application? That is, using the above configuration, it’s Caddy configuration would be:

twtxt.example.com {
	encode
	reverse_proxy :31212
}

Is that correct?

Hmm, not experiencing that. Using Zen (Firefox), under Linux, with uBlock Origin.

im unable to figure out why bbycll is not generating posts hashes for @lyse@lyse.isobeef.org’s feed correctly (or at least different from the ones generated by yarn)

i’m pretty sure the timezone is stripped off the offset correctly (2025-09-14T12:45:00+02:00 → 2025-09-14T12:45:00Z) though messing with how the hash is generated i can’t get it to make one that matches…but all other hashes for all other feeds seem to be correct? does yarn use a different canonical url for lyse internally? is there a bug in the libraries im using? bwehhh

@kat@yarn.girlonthemoon.xyz @kat@yarn.girlonthemoon.xyz Pretty sure I have many more mentions in the database than the one and only one I see hmmm 🤔 – I’ll have a look at the code when I can and the SQL query it’s using

@lyse@lyse.isobeef.org no, as mentioned this “diagonal arrow” eye shape, is usually used for a smug expression. The optional white part, is in this case, where the dogs sclera would be visible, while they have their eyes, like this.
Here is a comparison between a real dog, making the face it is based on, and the exaggerated drawn version.

@kat@yarn.girlonthemoon.xyz nope, not normal. Something birdy (because why to use fishy all the time?!) is going on.

Woot, thank you! Using a config.json like this:

{
  "host": "localhost:31212",
  "protocols": ["http"]
}

Indeed did the trick! I know it isn’t production ready, but I wanted to see with my own eyes, locally, how did it look. :-) I like where you are going! It is looking very nice, and polished. Can’t wait for an alpha, beta, and release!

Since Google announced their intentions to heavily limit sideloading on Android, starting end of 2026, I’ve been looking for potential solutions, for this policy change, that threatens the majority of projects I maintain, in some way. Google already killed my browser project years ago, but I have no other choice, than to fight this, any way I can.

The best choice to deal with this, will probably be the Android Debug Bridge, which can be used not only to install apps unrestricted, but also to uninstall, or remove, almost any unnecessary part of the OS. Shizuku, combined with Canta Debloater, is the winning combination for now.

I’ve already removed most Google apps from my device: the annoying AI assistant, the stupid Google app adding the annoying articles, left of your homes screen, Google One, Gboard, Safety app… it’s amazing, no distracting Google slopware, like in the good old Android 2 days! And I absolutely intend to keep it this way, from now on, no new Google apps or services on my devices, unless Google can give me a good enough reason, to allow them there and whenever the app that verifies signatures, to block installing apps not approved by Google, I’ll just remove it from my device and advocate others do so too.

@kat@yarn.girlonthemoon.xyz Ta. The only good use for <details> is to collapse long logs in bug analysis reports. Other than that, I find it rather annoying to expand sections manually.

As for spoilers, personally, I don’t care at all. Not the slightest bit. If there is something that I don’t wanna read, I just stop reading. ¯_(ツ)_/¯

But I’ve got the feeling that I’ve got an unpopular opinion on that matter. ;-)

@bender@twtxt.net I see, thanks. Well, I never found these warnings useful. To hide answers to conundrums or the like, ROT13ing or base64-encoding them is plenty sufficient.

Hahaha, I never heard of Poopgate before. :-D Poor passengers.

@lyse@lyse.isobeef.org a content warning is kind of like a forum spoiler cut, or like the <details> tag in HTML; it lets you write a sentence or so that someone can then click to expand to see the actual post. it’s called a CW because most people use it to warn for potentially triggering/harmful subjects, but you can really use it for anything, like spoilers in a TV show or even for joke punchlines

@zvava@twtxt.net I never used any of the social media platforms, that’s why I’m probably ignorant.

I don’t understand the concept of a retwt. Just quote the (relevant) parts from whereever and comment on that. Or post a link instead of a quote. Sounds simple enough. :-) That’s also has the benefit that it works with every source, no matter what. Since it’s called retwt, I’d imagine this to only work (well) with whatever messages the system itself offers. But I could be wrong. What would be the benefit of having a dedicated message type or structure for “hey, look at that” messages in your opinion?

Hmm, what’s a content warning?

in the same vein, i think content warnings can be faithfully implemented by parsing CW: ..., tw // ..., etc. from the first line of a post followed by two newlines, like how they’re used on platforms that don’t have content warnings

@lyse@lyse.isobeef.org hahaha very rarely!!! it wasn’t quite a sky scraper, just a few floors up, but my perspective may be skewed because i’m used to high buildings :P

I have a feeling that learning to play electric double bass through an amplifier was a big mistake.

At the core, this is an acoustic instrument. If you play it through an amp, you will instinctively only do the bare minimum to get some sound going, because the amp does the heavy lifting. But it’s just not right.

This is a very physical instrument. It needs a lot of force and strength – in comparison, an electric bass guitar is almost flimsy and delicate. I need to “feel” what’s going on and that’s just not the case when using headphones.

I feel like I wasted ~3 years. 🫤 But maybe it’ll get better from now on …

i love htmx i just need to find somewhere to use it

@thecanine@twtxt.net I’d expect especially power users not to use the web frontend. Unfortunately, in order to submit MR reviews that’s very often just the only option.

How about no longer using in-browser Git repo viewers? Make the AI bots do the work and actually clone the repo.

@movq@www.uninformativ.de Interesting, yes. I didn’t know that.

No AI being used is really great. However, the same clips shown over and over again and some images being mirrored was quite annoying to me. Also, there were some quite terrible computer animations and sometimes the narration and picture didn’t match at all. Talking about the medieval period and then showing an image from the 18th hundred or so. What the heck?

These production issues made me sceptical pretty much early on. So I quickly crosschecked Wikipedia. But it seems spot on from what I’ve read. Very good. Also, the narrator’s voice was really nice to listen to.

Eels are fascinating creatures. :-)

Dear dev.alessandrocutolo.it, do you really need to fetch my twtxt feed every 20-30 seconds? 😅 Not that it’s posing a problem, but I feel like this could be optimized. For example, how about using the if-modified-since request header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/If-Modified-Since

@lyse@lyse.isobeef.org @dce@hashnix.club It’s pretty cool, I won’t argue that, but also really simple, to be completely honest. 😅 The BIOS already provides all you need to send data to the printer:

https://helppc.netcore2k.net/interrupt/bios-printer-services

The BIOS actually does provide a great deal of things, which, to me, was one of the most surprising learnings of this project (the project of writing a little 16-bit real-mode OS, that is). It often doesn’t feel like I was writing an operating system – it felt more like writing a normal program that just uses BIOS calls like we would use syscalls these days.

(I’ve also read a lot of warnings, like “don’t use the BIOS for this or that”. Mostly because it tends to be very slow.)

@dce@hashnix.club Apart from the crap produced in Redmond two decades ago, I only ever used and still happily use Linux, mainly Debian and Ubuntu. I’ve no idea, but maybe something in there catches your eye: https://en.wikipedia.org/wiki/List_of_operating_systems (I know, what a silly recommendation.)

Listen missy, don’t you disappear on us like that again, do you hear me?! 😂 Welcome back, kat! I was wondering where you were, but figured something more interesting was keeping you busy. 🙈

@lyse@lyse.isobeef.org IIRC they’re getting attacked by bots on a huge level

also this is a really useful page!

@zvava@twtxt.net may I recommend to change the mention format upon hitting reply to something similar to what it’s used in Yarn, and perhaps hiding the hash on the post too? Looking good!

@movq@www.uninformativ.de I noticed that:

gopher://uninformativ.de/0/phlog/2018/2018-06/2018-06-01.txt

Is the first non-justified, and it is when you started using Markdown. The last justified one was:

gopher://uninformativ.de/0/phlog/2018/2018-05/2018-05-27.txt

So, I might have found the mystery! :-D

Haha, fun! I browsed your gopher hole a little bit. I noticed some entries are fully justified (formatting), while others are not. I didn’t notice a pattern, though it makes sense not to use justification on entries with code. Yet, some prose entries are, and some are not. A mystery. :-)

@klaxzy@klaxzy.net I’ve had many SD cards die in Raspberry Pis. Really annoying. I’ve eventually switched to using a read-only rootfs. 🫤

Now that’s interesting. Some of these bots start crawling at URLs like this:

https://uninformativ.de/projects/lariza/NetTracer-Scenes/GPUTracer/multipass/xlonitor/http-collect/getpw

That is obviously completely wrong. But I can explain it. Some years ago, I screwed up my nginx rewrite rules, and that’s how these broken URLs came to be.

It all redirects to /git now, which is why that endpoint sees so much traffic lately.

But what does that mean? Why do they start there? I can only speculate that this company bought an old database of web links and they use that to start crawling. And it was probably a cheap one, because these redirects have been fixed for quite a long time now.

@prologic@twtxt.net I’m doing that now as well, but I don’t think this is a good solution. This is going to hurt “self-hosting” in the long run: I cannot afford true self-hosting where I actually do host everything here at home – instead, I must use a cloud provider / VPS for that. It is only a matter of time until my provider starts doing AI shit as well (or rather, the customers do it) and then what? I get blocked, e.g. I can’t send email to (some) people anymore. This is already bad and it’s going to get worse.

@lyse@lyse.isobeef.org Yeah, that was a lot of fun. 😃 Now let’s wait and see if I ever get to actually use this. 😂

@thecanine@twtxt.net We don’t use Microsoft at work – but similar products of other big companies. They’re all doing the same. The core product gets worse and worse, because they focus so much on vomiting “AI” over everything.

It will die down eventually. I hope.

@thecanine@twtxt.net I hate it when businesses do this. As well as being annoying and unreliable, Microsoft software is known to have a hell of a lot of security vulnerabilities, and the AI features increase the attack surface. One can use a client like Thunderbird for the email, but Teams doesn’t really have an alternative. Awful stuff.

We use all the Microsoft programs at work - Teams and Outlook especially.

After all kinds of technical problems with Teams, that sometimes go unresolved for over a year, Microsoft shifted their priorities away from fixing things and towards adding an annoying AI Copilot button, that just takes up space and all it does, is loads the website in Teams, so I disabled it. Soon they just add it back, but in a different row of icons, therefore it’s now a different button, you have to disable (I think they added yet another one, to the Teams, on my work phone and I had to disabled that too). Not too long after, the desktop one just enabled itself, because of “an error” and I can disable it, but doing so activates a popup, that begs you to turn it back on, every once in a while. You can’t disable the popup and can only click “Yes” or “Not now” on it. I still keep it disabled, out of principle, but yesterday I noticed yet another Copilot button, this time in the top right corner of my Outlook and this one cannot be disabled, on the business version of Outlook and even on the personal one, it’s only possible to do it through hidden privacy settings, by prohibiting the program from connecting to Microsoft servers, for extra “features”.

There’s people complaining about it online, so it’s clear nobody really wants it, but at this point Microsofts position is that you will have at least one useless AI button on your screen, at any given time, and you will be happy. And yes, their AI sucks and if I absolutely have to use AI for something, there’s already 2 better options, we have access to, at work.