@thecanine@twtxt.net So cool!

It reminds me of the monsters in Heart of Darkness on PSX (just replayed the other day).

https://www.youtube.com/shorts/ZnGOpT5NKxc

@movq@www.uninformativ.de No doubt, some things are just so much better the low-tech way. Waste paper, like an opened envelope, suits a shopping list perfectly fine. You’ve got a nice handwriting, I like it.

@movq@www.uninformativ.de \o/

@thecanine@twtxt.net Oh no, the poor crocodile is struck by lightning!

Hello again everyone! A little update on my twtxt client.

I think it’s finally shaping a bit better now, but… ☝️

As I’m trying to put all the parts together, I decided to build multiple parallel UIs, to ensure I don’t accidentally create a structure that is more rigid than planned.

I already decided on a UI that I would want to use for myself, it would be inspired by moshidon, misskey and some other “social feeds” mock-ups I found on dribbble.

I also plan on building a raw HTML version (for anyone wanting to do a full DIY client).

I would love to get any suggestions of what you would like to see (and possibly use) as a client, by sharing a link, app/website name or even a sketch made by you on paper.

I think I’ll pick a third and maybe a fourth design to build together with the two already mentioned.

For reference, the screens I think of providing are (some might be optional or conditionally/manually hidable):

• Global / personal timeline screen
  
• Profile screen (with timeline)
  
• Thread screen
  
• Notifications screen or popup (both valid)
  
• DM list & chat screens (still planning, might come later)
  
• Settings screen (it’ll probably be a hard coded form, but better mention it)
  
• Publish / edit post screen or popup (still analysing some use cases, as some “engines” might not have direct publishing support)
  

I also plan on adding two optional metadata fields:

• display_name: To show a human readable alternative for a nick, it fallback to nick if not defined
  
• banner: Using the same format as avatar but the image expected is wider, inspired by other socials around
  

I also plan on supporting any metadata provided, including a dynamically parsable regex rule format for those extra fields, this should allow anyone to build new clients that don’t limit themselves to just the social aspect of twtxt, hoping to see unique ways of using twtxt! 🤞

@bender@twtxt.net The first format use the subject extension while the other is a new format that is inspired by mentions format, the first one should be compatible but I’m not sure, if it’s used verbatim by the client it would work, but if we consider the new proposal for it to have an optional part it wont work on clients without changes.

@movq@www.uninformativ.de While using the a frament is pretty nice, I think we can have a twtxt only format if the formatting seems to be a problem.

@lyse@lyse.isobeef.org I think will be bad if handled incorrectly.

The client must reference both properly or it would miss posts, including both this way is a bit pointless if you can’t use the hash or url separately.

Being a highly likely a breaking change anyway I think @zvava@twtxt.net proposal looks much better.

@lyse@lyse.isobeef.org i would like to ditch hash addressing but as was pointed out it would be a pain in the ass to get clients currently working off of hashv1 to suddenly switch to location-based addressing instead of just hashv2 with the option to eventually phase it out — unless we can rally together all active client developers to decide on a location-based addressing specification (i still think my original suggestion of #<https://example.com/tw.txt#yyyy-mm-ddThh:mm:ssZ> is foolproof)

@lyse@lyse.isobeef.org Finally! The end is near! Rejoice! \o/

@zvava@twtxt.net Hm, I tried with https://www.uninformativ.de/twtxt.txt#:~:text=2025-09- and my Firefox 143 didn’t like it. https://www.uninformativ.de/twtxt.txt#:~:text=2025%2D09%2D worked. 🤔

@bender@twtxt.net technically it’s still the same, but the brackets are different, and the # symbol is on the outside of the brackets, but it makes more sense with @<...> being mentions

@movq@www.uninformativ.de huh, firefox actually does seem to tolerate the dashes in the fragment. also, i did propose simply using an anchor link first, but prologic was not a fan of this :p

@thecanine@twtxt.net content warning please! I had to go home and change, if you catch my drift. LOL. Well done!

Spooky season is upon us, so I can take a month break, from being a paper clip.

@movq@www.uninformativ.de I wish I could truly say that. :-D

@zvava@twtxt.net

(#abcdefghijkl https://example.com/tw.txt#:~:text=2025-10-01T10:28:00Z), because it can be simply hacked in to clients currently on hashv1 and provides an off-ramp to location-based addressing

I like that property (an off-ramp to location-based addressing), so I think I could live with that approach. ✅

(I’m not sure why we’re using text fragments, though. Wouldn’t that link to the first occurence of 2025-10-01T10:28:00Z? That’s not necessarily correct. And, to be proper URLs that Firefox and Chromium understand, it would also need to be written as 2025%2D10%2D01T10:28:00Z. The dash carries meaning, sadly. I think all this just creates needless complication. How about we just go with https://example.com/tw.txt#2025-10-01T10:28:00Z?)

@aelaraji@aelaraji.com, I mean to follow up here on the brief exchange we had on irc.mills.io, but I forgot. Never too late, so here it goes:

18:16 <aelaraji> quark 🙏 much appreciated but it won't be necessary, since there isn't much to miss out on in most of  where I hang out, so I could just disconnect and spare everyone else the noise 
18:17 *** aelaraji (aelaraji@776014f5a3edd32f1ed19658b7b85c8c655945b0feacaedd92fe60e61a3c0ae2) has quit (/ME goes "yeeeeet..!")
18:18 <quark> No noise for me. 
18:18 <quark> It’s all good. 
18:18 <quark> What would IRC be without on/offs?
18:19 <quark> Preeeety boring!
18:19 <quark> Ah, he was gone. 
18:19 <quark> Well, I will twtxt this to him.  LOL. 

Thanks, @alexonit@twtxt.alessandrocutolo.it! Yeah, this classic rivet is a good, yet laborous alternative. I don’t mind the work, I just don’t have any copper at hand. I might give this some more thought, though.

@zvava@twtxt.net My clients trusts the first url field it finds. If there is none, it uses the URL that I’m using for fetching the feed.

No validation, no logging.

In practice, I’ve not seen issues with people messing with this field. (What I do see, of course, is broken threads when people do legitimate edits that change the hash.)

I don’t see a way how anyone can impersonate anybody else this way. 🤔 Sure, you could use my URL in your url field, but then what? You will still show up as zvava in my client or, if you also change your nick field, as movq (zvava).

@alexonit@twtxt.alessandrocutolo.it Hahaha, that made me laugh real good. :-D I find it always surprising what collects in a short amount of time.

@zvava@twtxt.net Mixing both addressing schemes combines the worst of both worlds in my opinion. Please don’t do that.

@zvava@twtxt.net Yes, the specification defines the first url to be used for hashing. No matter if it points to a different feed or whatever. Just unsubscribe from malicious feeds and you’re done.

Since the first url is used for hashing, it must never change. Otherwise, it will break threading, as you already noticed. If your feed moves and you wanna keep the old messages in the same new feed, you still have to point to the old url location and keep that forever. But you can add more urls. As I said several times in the past, in hindsight, using the first url was a big mistake. It would have been much better, if the last encountered url were used for hashing onwards. This way, feed moves would be relatively straightforward. However, that ship has sailed. Luckily, feeds typically don’t relocate.

@zvava@twtxt.net the second format (the one you think should be changed to), is it backwards compatible to what’s currently in place? I believe the first one would be.

@alexonit@twtxt.alessandrocutolo.it prologic has me sold on the idea of hashv2 being served alongside a text fragment, eg. (#abcdefghijkl https://example.com/tw.txt#:~:text=2025-10-01T10:28:00Z), because it can be simply hacked in to clients currently on hashv1 and provides an off-ramp to location-based addressing (though i still think the format should be changed to smth like #<abc... http://example.com/...> so it’s cleaner once we finally drop hashes)

@zvava@twtxt.net Ah okay. Yeah, so far, yarn looks pretty nice and is easy to use. I might even selfhost my own instance too!

@zvava@twtxt.net That was my greatest concern with how it is currently handled, I’m afraid to break threads even by fixing a typo.

Handling it via the pod might work but I think it’s not the best approach, external feeds and clients don’t usually use a pod api but their own implementation, so any workaround won’t work there.

That’s why my proposals addressed those issues:

• the idea of using a “key” instead of the url (with the url as a fallback), the key could even be a public key so it can be used verifieable in crypto functions
  
• using the timestamp to prevent content changes to break threads (plus being simpler to implement)
  
• using an explicit thread reference with an alternative subject format (like [#THREAD_ID] Hello world and replies with (#REPLY_ID) Ahoy) so the content can change without affecting the thread reference, and anyone can use their own schemes freely

@rnlog@yarn.girlonthemoon.xyz bbycll, whenever it is ready, in the meantime you’re already on a pretty good one :3

@zvava@twtxt.net I just have plastic plants at home too.

@zvava@twtxt.net Don’t say that.

The eye candy is always good to have.

@zvava@twtxt.net I’m not sure, I could just set up a cors-anywhere via docker in a minute and it would work the same.

Still, I could write one with just a dozen lines of Go or Node.js, I might consider writing one after the client is working decently.

@zvava@twtxt.net What is a nice twtxt client to use?

@alexonit@twtxt.alessandrocutolo.it terrariums are so cool but i couldn’t even keep grass from the back yard in a jar alive

i desperately want to simply deploy a bbycll instance but i need to change the entire database schema for the Nth time, i haven’t been working on it much recently as this back and forth w the backend (which you don’t expect from a spec as simple as twtxt) is really demotivating, as well as life and stuff getting in the way

perhaps i just need a nice shower and four coffees, midnight is when i am most productive and the hour is approaching..

@alexonit@twtxt.alessandrocutolo.it yeah, i didn’t even consider this as an option lol, though if it works it works! will you be writing a compatible proxy for self-hosting separate from the custom backend you were thinking of? :o

@lyse@lyse.isobeef.org I can suggest you a trick to do a “cold” welding.

Using a copper wire or a similarly malleable material, pass it through a drilled hole, hammer it on one end until flat, then do the same on the other side.

It does the same job of a rivet but it’s flatter and look nicer on both sides, it’s of course weaker but still strong enough for small objects.

It’s sometimes used to reduce risk of deformities due to heat in hand-crafted jewelry and to reduce costs of small tools.

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

@lyse@lyse.isobeef.org Yeah, those are my bad.

A couple of weeks ago, I added CORS support, which is the source of the OPTIONS call. What I didn’t do was store the result so it stops trying to make further attempts. I’ll get that in tomorrow.

As for the “If-Modified-Since” header, the server-based component of TwtStrm should be sending that (along with its user-agent tag and my user info). I wasn’t sure if that could be sent with CORS requests, so I’ll need to look into that a bit more.

Thanks, I appreciate the feedback!

@movq@www.uninformativ.de Same 👌

@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

@lyse@lyse.isobeef.org Just as planned! 😅

@itsericwoodward@itsericwoodward.com (I confess, my brain pronounced it as “TwitStorm”. 😂)

Thank you, @alexonit@twtxt.alessandrocutolo.it! It’s not sealed at all. If you were pouring in a liquid, it would run out on all four corners. It’s just folded over and carefully hammered shut as best as possible. 03 is a bit blurred, but you can see the tab from the right (the short side) tucking in on the left (the long side). The hem on top clamps it in place fairly decently.

I decided against blind rivets, because they leave ugly looking and sharp backsides, which can also interfer with the contents of the box. However, they would be an easy solution to make the corners more rigid and prevent any movement from the short sides.

Unfortunately, I can’t weld or solder, so that’s not an option. It would be the by far best solution. I wanna learn it one day, though.

Yes, Ken is a really great dude. He’s the reason I gave this a shot in the first place. :-)

@itsericwoodward@itsericwoodward.com No worries, all good, mate! We all have to start somewhere. Other software requests my feed several orders of magnitude more often.

I can confirm, the User-Agent header appears to be fixed. \o/

Two other things I noticed, though:

1. There’s now an OPTIONS request for my feed coming from something that claims to be Firefox, pointing to your feed URL in the query. No clue what this is about. In any case, it’s rejected with a 405 Method Not Allowed.

2. Not that these few requests bother me at all, but you might wanna implement caching next with either the If-Modified-Since or If-None-Match request headers. This way, if the feed hasn’t changed, the web server can reply with a 304 Not Modified and no body at all, saving unnecessary traffic. But again, this is really not an issue for me at all. I just wanted to make sure you’re aware of it, that’s all. It might be even already on your agenda. Or you might decide to never do anything about it, which is also fine for me. :-)

@itsericwoodward@itsericwoodward.com Cool! 😎

@prologic@twtxt.net That zs looks pretty cool! I love simple static site generators, and look forward to trying it on my next web site project. Kudos!

@bender@twtxt.net Yes! What you’re seeing in the demo is just demoing the routes file and redirects, etc/. Pathing more.

@lyse@lyse.isobeef.org Thanks, I think I fixed it now. Sorry for the spam.

@bender@twtxt.net Yes and no.

To build a compliant PWA you need to provide a webmanifest json and a service worker.

Those requirements are not directly part of this project.

You can build the client as a standalone PWA or even as a widget inside an existing page.

The general steps are closer to how you would include a third-party library in an existing project, by importing it as a dependency and using it in your website.

I’m pretty sure most users would expect a PWA (me included) so I plan to provide a ready-made template ready to be deployed as is.

@alexonit@twtxt.alessandrocutolo.it so, a PWA, right?