Speaking of WAF(s) / Web Applicaiton Firewalls – I actually had forgotten that not only have I designed a new WAF from scratch, but I’ve actually implemented it already, and done some local testing. I just haven’t put it into production yet… What od you think @aelaraji@aelaraji.com ? 🤔 https://git.mills.io/prologic/caddy-waf

@prologic@twtxt.net I remember reading a blog-post where someone has been throwing redirects to some +100GB files (usually used for speed testing purposes) at a swarm of bots that has been abusing his server in order to criple them, but I can’t find it anymore. I’m pretty sure I’ve had it bookmarked somewhere.

@prologic@twtxt.net Let me know if you still need an account for testing. My tin-can bandwidth is slow AF but usable if you don’t mind the speed.

@movq@www.uninformativ.de @bender@twtxt.net @prologic@twtxt.net That’s fine with me. It could be even the 1st January 2026, as simple as the change really is.

But it would be also alright to just stick with July, so that I don’t have to update the tests. :-P

@movq@www.uninformativ.de That’s what tests are for. To fix them. :-D

All my newly added test cases failed, that movq thankfully provided in https://git.mills.io/yarnsocial/twtxt.dev/pulls/28#issuecomment-20801 for the draft of the twt hash v2 extension. The first error was easy to see in the diff. The hashes were way too long. You’ve already guessed it, I had cut the hash from the twelfth character towards the end instead of taking the first twelve characters: hash[12:] instead of hash[:12].

After fixing this rookie mistake, the tests still all failed. Hmmm. Did I still cut the wrong twelve characters? :-? I even checked the Go reference implementation in the document itself. But it read basically the same as mine. Strange, what the heck is going on here?

Turns out that my vim replacements to transform the Python code into Go code butchered all the URLs. ;-) The order of operations matters. I first replaced the equals with colons for the subtest struct fields and then wanted to transform the RFC 3339 timestamp strings to time.Date(…) calls. So, I replaced the colons in the time with commas and spaces. Hence, my URLs then also all read https, //example.com/twtxt.txt.

But that was it. All test green. \o/

Testing 1 2 3

Testing 1 2 3

Test

@prologic@twtxt.net no, I really meant small. I only have a handful of GiBs left of storage. If you can wait until mid-December, then no probleml. Right now it is kind of running on fumes. For testing, and to do not disturb anyone timelines, I recommend you run a small test instance. Running GtS is easier than running Yarn, by the way. Word.

@prologic@twtxt.net ah, yes, one of those, yes. Too small for testing though. 😅

Test (_did I fix this shit™-)?

Hey @manton@bridge.twtxt.net 👋 Why yes I believe I did!

Anyone run a Mastodon serve rI can have an account on to help test the Twtxt <-> Activity Pub bridge? 🙏

Testing 1 2 3 @manton@twtxt.net

Test @-mentioning@twtxt.net an AP actor via the Bridge. Hey @manton@twtxt.net 👋

I need some test Activity Pub / Mastodon users to test with 🤔

WOW LOL

fetch https://weaknotes.com/users/david: status 500 Internal Server Error

First real test failed trying to lookup / follow @david@weaknotes.com

For those curious, the new Twtxt <-> ActivityPub bridge I’m building (bidirectional) simply requires three things:

1. You register your Twtxt feed to the bridge: https://bridge.twtxt.net
   
2. You verify that you in fact own/control the feed by putting the verification code somewhere on/in your feed (doesn’t matter where or how)
   
3. You proxy/forward requests for /.well-known/webfinger to the Bridge bridge.twtxt.net.
   

I’m still testing through and ironing out bugs 🐛 Please be patient! 🙏

Testing new design, architecture and implementation of a Twtxt bridge I’m working on…

verification-token: ee9bc4da3356f4990671

Please ignore.

@bender@twtxt.net Just wrote better code with tests 🤣

Thank you for the encouragement and love and kind words, @lyse@lyse.isobeef.org @movq@www.uninformativ.de @bender@twtxt.net @doesnm@doesnm.p.psf.lt and others along the way I’m not sure of their feed uris 💕 I’ll keep at it, but for the time being I will keep my distance, mostly off IRC, because I don’t have the energy to spare in that kind of engagement (what//if the worst happens, it’s so draining). I need to remember what I ever did any of this for, it was back in ~2020 and I wanted really to build small interconnected communities that any non “tech savvy” person (more or less) could also benefit from ane enjoy. Even if there are aspects of the specs we’ve built/extended over time that aren’t “perfect”™, they’re “good enough”™ that they’ve last 5+ years (I believe this is 6 years running now). I want to spend a bit of time going back to why I did any of this in the the first place, and get a little micro-SaaS offering going (barely covering running costs) so encourage more folks to run pods, and thus twtxt feeds and grow the community ever so slightly. Other than that, I plan to get the specs “in order” to a point (with @movq@www.uninformativ.de and @lyse@lyse.isobeef.org’s help) where I hope they’ll stand the test of time – like SMTP.

Thank you all ! 🙏

@prologic@twtxt.net a good DR plan must be tested at least once a year. ☺️

I had a looksie (just to be sure) at the database, and they were thankfully legit test events. But this did spark/trigger me to make sure I have some form of anti-spam measures in place. So I added some per-event / per-rsvp rate-limiting and honeypot(s).

@zvava@twtxt.net CORS is our worst enemy. 🥷

I too had the same issue being a browser-based request, so the only solution is using a proxy.

For testing (and real personal use) I rely on this one https://corsproxy.io/.

In my client, I first check if the source allows me to fetch it without issues first and fallback to prefixing with a proxy if it gives an error.

For security reasons the client don’t give you a readable error for CORS, so you must use a catch-all for that, if it fails again with the proxy you can deal with any other errors it throws as you normally would (preferably outside of the fetch function).

After the fetching responded, I store the response.url value to fetch it again for updates without having to do extra calls (you can store it verbatim or as a flag to be able to change the proxy later).

Here an extract of my code:

export async function fetchWithProxy(url, proxy=null) {
    return await fetch(url).catch(err => {
        if (!proxy) throw err;
        return fetch(`${proxy}${encodeURIComponent(url)}`);
    });
}

// Using it with
const res = await fetchWithProxy('https://twtxt.net/user/zvava/twtxt.txt', 'https://corsproxy.io/?');

// Get the working url (direct or through proxy)
const fetchingURL = res.url;

// Get the twtxt feed content (or handle errors)
const text = await res.text();

I also plan to allow the user to define a custom proxy field, I like the solution used by Delta.chat in their android app, where you can define the URL format with a variable https://my-proxy?$TWTXT_URL since it allows you to define with more freedom any proxy without a prefix format.

If the idea of using a third-party proxy is not to the user liking they can use a self-hosted solution like cors-anywhere or build their own (with twtxt it should just be a GET).

@alexonit@twtxt.alessandrocutolo.it i tried making a webapp initially but i didn’t even get into the initial stages of testing because no one sets the Access-Control-Allow-Origin header, so i just jumped into building a backend instead. did you find away around this limitation? :o

@bender@twtxt.net Well see that’s just what the freak’n tests say about me haha 🤣

immigration and multiculturalism

What about it? I grew up in a multicultural country.

Test.

And I need to make something absolutely clear as well here. Twtxt was completely and utterly dead back in {Aug 2020](https://yarn.social/about.html) when I came across the spec and its simplicity and realised the lost opportunity. Since then we’ve continued to grow a small but thriving community. The extensions we’ve built over time have stood and lasted the test of time for the past ~5 years. We need not break things too badly, because what we have today and was designed years ago actually works quite well™ (despite some flaws).

@bender@twtxt.net A renewed vision test might be a good idea for some people. 😅 I mean, it is kind of curious that you get this license as a young person and then it lasts a lifetime, without any further tests. As long as you don’t screw up really bad, it remains valid …

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

Hello everyone! 👋

After a long while away, I’m back on twtxt with this new feed.

Some of you might remember me as justamoment@twtxt.net, that was a test account I made for trying things out, but I ended up keeping it more than planned.

I also tried other social platforms in search of a place that felt right for me.

In the end twtxt was the one that ticked all of my boxes:

• Slow social: it act more like a feed reader and I really appreciate that there’s no flood of content that I can’t keep up with.
  
• No server needed: I absolutely love to have total control over my content, I tend to avoid having moving parts that might break, plus you can put your feed under version control and it’s all backed up.
  
• Ownership: I can put my feed anywhere I want and nobody can decide if I can access it or not.
  
• For hackers: a single .txt file allows me to join a community, how cool is that!
  

This is why I decided to build my own twtxt client, one that allows you to decide how the feed is presented on your “instance”.

It’s still in the making but I’ll try to share a bit of it once I defined how things should work.

Coincidentally, I discovered that @itsericwoodward@itsericwoodward.com and @zvava@twtxt.net were also building a twtxt client, seems like twtxt is set to grow!

@zvava@twtxt.net @movq@www.uninformativ.de I’m not entirely sure about the spaces, but maybe they were omitted to simplify parsing of mentions in the form of @<nick url>. If the next token after the @<nick does not look like a URL, it’s not a mention but regular text. This is just wild guessing, though.

Looking at the regex and tests in the original twtxt reference implementation seems to confirm that theory in the sense as it relies on whitespace as the delimiter:

https://lyse.isobeef.org/tmp/screenshot-2025-09-17-21-30-25.png

Another thing about nicks is that the original twtxt reference implementation converts nicks to all lowercase:

https://lyse.isobeef.org/tmp/screenshot-2025-09-17-21-20-39.png

You probably know this already, the original twtxt file format specification can be found here: https://twtxt.readthedocs.io/en/latest/user/twtxtfile.html

As for extensions, I don’t know of anything outside of twtxt.dev that has actually been (partially) implemented. However, there is also the issue tracker of the official reference implementation. You might wanna dig through that. For example, there is an alternative suggestions of multiline messages: https://github.com/buckket/twtxt/issues/157

I corrupted my SQLite test database with sed -i s/… $(find …). Clearly, I found too many files. That’s the signal to go to bed.

remote.json | 3.4MiB

i hope testing this doesn’t get me ip banned from Everything

@bender@twtxt.net ty for attempting to test, though, it means a lot! lmk if u find any more silly things i need to clarify or fix :> be prepared for everything breaking during beta :p

@bender@twtxt.net as the host (eg twtxt.net) determines the canonical url of the instance in generated feed url metadata as well as every hash of every post made on the instance internally, i added this error message to make sure people don’t accidentally set up their instance on localhost :p for testing i set it to localhost:31212 and protocols to ["http"], it’s a recent addition that could definitely do with documenting in the getting started section

@zvava@twtxt.net wow, this is a full change, and looking very, very, very good! I am ready to test it. 🙈

test reply please ignore

test edit please ignore

test post please ignore

@lyse@lyse.isobeef.org Didn’t know that, either. 😂 The one guy even tried to test this theory with a Polaroid? And “confirmed” it? What the heck. 🥴

I’ve got a prototype of my hardcopy simulator going. I’m typing on the keyboard and the “display” goes to the printer:

https://movq.de/v/56feb53912/s.png

https://movq.de/v/235c1eabac/MVI_8810.MOV.mp4

The biiiiiiiiiig problem is that the print head and plastic cover make it impossible to see what’s currently being printed, because this is not a typewriter. This means: In order to see what I just entered, I have to feed the paper back and forth and back and forth … it’s not ideal.

I got that idea of moving back/forth from Drew DeVault, who – as it turned out – did something similar a few years back. (I tried hard to read as little as possible of his blog post, because figuring things out myself is more fun. But that could mean I missed a great idea here or there.)

But hey, at least this is running on my Pentium 133 on SuSE Linux 6.4, printer connected with a parallel cable. 😍

(Also, yes, you can see the printouts of earlier tests and, yes, I used ed(1) wrong at one point. 🤪 And ls insisted on using colors …)

@bender@twtxt.net I think it’s actually a new XEP proposal ( https://xmpp.org/extensions/xep-0084.html#proto-info ), but it’s still a bit unclear. Sorry for the late and vague response, I’m still trying to test it and see what it’s even about, didn’t yet find a server, that supports it.

@aelaraji@aelaraji.com I use Alt+. all the time, it’s great. 👌

FWIW, another thing I often use is !! to recall the entire previous command line:

$ find -iname '*foo*'
./This is a foo file.txt

$ cat "$(!!)"
cat "$(find -iname '*foo*')"
This is just a test.

Yep!

Or:

$ ls -al subdir
ls: cannot open directory 'subdir': Permission denied

$ sudo !!
sudo ls -al subdir
total 0
drwx------ 2 root root  60 Jun 20 19:39 .
drwx------ 7 jess jess 360 Jun 20 19:39 ..
-rw-r--r-- 1 root root   0 Jun 20 19:39 nothing-to-see

testing with a new meme

yo let’s test this shit, looks promising

@prologic@twtxt.net Mosaic (2.7) works fine, I maintain that package in the AUR and test my website regularly. 😅

https://movq.de/v/d7787d6fb1/s.png

@movq@www.uninformativ.de yes, I think:

<!--[if !IE]><!-->
<link rel="stylesheet" href="../simplicity.css”>
<!--<![endif]-->

Should work, but I haven’t tested it.