Warum erfahre ich erst im Jahr 2025 von Server-sent events (SSE) 🤔?
Das Zeug scheint für die webbasierte Server-Client-Kommunikation in JavaScript ideal zu sein und ist sehr einfach umzusetzen.

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.

My open letter, to the European Commission digital markets act team:

Hello,

I am joining other developers, concerned about Googles new plan, to approve every app and effectively destroy most of the competing 3rd party stores this way. The biggest one of these alternative stores, most known for their focus on user and developer privacy, already states, this would make it impossible for them to operate: https://f-droid.org/cs/2025/09/29/google-developer-registration-decree.html
Even communities like the XDA forum, where new developers are often introduced to the world of Android development, would likely be strongly impacted, as making, publishing and installing Android apps is made less accessible.

I am not just writing on their behalf, I run a small website myself (https://thecanine.ueuo.com/), that both provides legal modifications, for some android apps - for example adding an amoled dark theme, to the most popular XMPP chat client for Android, or increasing one of Androids keyboard apps height. This all comes after Googles previous changes to the Android operating system, that prevent users from installing old apps (old to Google, can mean only a couple of months, without an update - https://developer.android.com/google/play/requirements/target-sdk and the target version gets increased every year). I rely on apps developed by a single developer, even for things like making the pixel art presented on my website and sideloading as a way to make these apps work, before developers can catch up to Google’s new requirements - if Google is allowed to slowly kill these options, us digital artists will soon lose the tools we need to create digital art.

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

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! 🤞

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

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

Great to see so many new clients popping up. 👌

Hi everyone, here’s a little introduction of my twtxt client (still WIP).

The client I’m developing is a single tenant project that runs entirely in the browser (it might use an optional backend).

It’s entirely based on native web-components and vanilla JS, it is designed to act closer to a toolkit than a full-fledged client, allowing users to “DIY” their own interface with pure html or plain javascript functions.

Users can also build their own engines by including a global javascript object that implement the defined internal API (TBD).

I’m planning to build a system that is easy enough to build and use with any skill level, using only pure html (with a homebrew minimal template engine) or via plain JS (I’ll be also providing some pre-made templates too).

Everything can be self-hosted on any static hosting provider, this allows to spread twtxt within communities like Neocities and similarly hosted websites (basically any Indieweb/Smallweb/Digital garden website and any of the common GitHub/Lab/Berg/lify Pages).

It will be probably named something like TxtCraft or craf.txt but I’m not really sure yet… 🤔 (Maybe some suggestions could help)

I’m still in the experimental phase, so there’s no decent source-code to share yet, but it will soon enough!

Exactly, @zvava@twtxt.net, I agree. (Although, in my client at least, I wouldn’t use hashes anywhere.)

That’s what I’m using right now, while my own client is still in the making.

A simple bash script to write a post in a mktemp file then clean it with regex.
I don’t even bother to hash the replies, I just open https://twtxt.net and copy the hash by hand since I’m checking the new posts from there anyway (temporarily, as I might end up DoS-ing everyone’s feed in my client right now).

plus, if hashv2 was implemented in combination with text fragments the way you proposed that would solve both scripting and human readability woes!!

…though, the presence of the text fragments then makes reversing the replied-to twt (and therefore its hash) trivial, which could allow clients to tolerate the omission of the hash — and while it would be ‘non-standard’ this would be the best of both worlds; potential to tolerate (or pave a glacial path toward? :o) human writable replies whilst keeping a unique id for twts that is universal across all pods

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@twtxt.net 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@twtxt.net the simplest thing to do is to completely forgo hashing anything because we are communicating using plain text files right now :3 while i agree hashes are incredibly helpful in the backend im not sure it has a place outside of it, it basically eliminates two core design principals of twtxt (human readability and integrating well with unix command line utilities) and makes new clients more difficult to build than it should be

@prologic@twtxt.net 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.
  

…

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

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@twtxt.net @lyse@lyse.isobeef.org I also think a location based reference might be better.

A thread is a single post of a single feed as a root, but the hash has the drawback of not referencing the source, in a distributed network like twtxt it might leave some people out of the whole conversation.

I suggest a simpler format, something like: (#<TIMESTAMP URL>)

This solves three issues:

• Easier referencing: no need to generate a hash, just copy the timestamp and url, it’s also simpler to implement in a client without the rish of collisions when putting things together
  
• Fetchable source: you can find the source within the reference and construct the thread from there
  
• Allow editing: If a post is modified the hash becomes invalid since it depends on [ timestamp, url, content ]

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!

@sysop ao tentar ir a https://ciberlandia.pt/conversations levo com isto:

ReferenceError: account is not defined
U= (https://ciberlandia.pt/packs/direct_timeline-index-CclzgTb8.js:1:5335)
ie (https://ciberlandia.pt/packs/logo-CwPlYIww.js:15:35348)
ie (https://ciberlandia.pt/packs/logo-CwPlYIww.js:15:25299)
ie (https://ciberlandia.pt/packs/logo-CwPlYIww.js:15:35287)
U= (https://ciberlandia.pt/packs/direct_timeline-index-CclzgTb8.js:1:5304)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:61330)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:116588)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:112269)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:112197)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:112051)

@zvava@twtxt.net Good question. This is the spec, I think:

https://twtxt.dev/exts/metadata.html#nick

It doesn’t say much. 🤔

In the wild, I’ve only seen “traditional” nick names, i.e. ASCII 0x21 thru 0x7E.

My client removes anything but r'[a-zA-Z0-9]' from nick names.

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

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

@bender@twtxt.net @thecanine@twtxt.net well now this has me thinking abt the feasibility of making an android twtxt app for pods, the actual apis of pods would have to be standardized (or the fucked up way that activitypub does it, where the “mastodon api” is the defacto client api (does yarn even have an api reference?)) or the client is just simply..a client..but editing feeds via PUT, PATCH, DELETE etc. is standardized!…? (not to mention i dont even know where to begin making an android app lmao)

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

@kat@yarn.girlonthemoon.xyz I reckon the original <details> need to have the open attribute set in order to expand it, so I cannot just define some custom CSS rules to do that in my browser.

But in regards to twtxt, my client won’t hide anything in that realm anyway. :-) It’s just more noise.

What kind of client for linux do I need?

i know yarn has a CLI client in yarnc but ngl i wish there was a TUI client. that’d be really fun

@zvava@twtxt.net Hooray for more twtxt clients 🥳

Mas qual destas características faz realmente s diferença?

É o facto de ser um projecto público?
É por ser um projecto de investigação?
É por ser de código aberto?
É uma conjugação de dois ou mais desses factores?
Quais?
Porquê?
Já estabelecemos atrás que iniciar os trabalhos não é proibído (só má prática). Em que é que estes outros factos fazem a diferença?
E, já agora, quais são as implicações dessa diferença?
A Amália assim treinada pode ser usada por projectos que não sejam públicos?
E se forem projectos que não sejam de investigação?
Quais são as licenças de código aberto qie a Amália vai ter, e que obrigações de licenciamento terão os seus clientes ou derivados?

As perguntas não foram feitas, e, está claro, também ficaram sem ser reapondidas. Também não há resposta para as tentativas de contacto de vários dos detentores de direitos de autor de conteúdos utilizados para o treino - lá está, talvez porque a análise que poderá dar essas respostas ainda não sstá - no mês de lançamento! - concluída.

Ainda assim, temos garantias: a “versão base” do Amália será disponibilizada publicamente já no final de setembro. “A partir desse momento qualquer entidade poderá utilizar o modelo”. Como é que conseguem dar essa garantia sem ter a análise legal feita é que fica por compreender.

²⁄₂

I finally have my new (top-secret) twtxt client in a working state. Next comes the deployment, which I hope to finish tonight. Release date: TBD. Stay tuned!

@prologic@twtxt.net @movq@www.uninformativ.de My metadata only has my HTTPS URL. I didn’t consider having multiple. I was talking about my config.yaml. Jenny sounds like a good client, so I might give that a try.

@dce@hashnix.club Ah, oh, well then. 🥴

My client supports that, if you set multiple url = fields in your feed’s metadata (the top-most one must be the “main” URL, that one is used for hashing).

But yeah, multi-protocol feeds can be problematic and some have considered it a mistake to support them. 🤔

It might just be my client, but it seems that I cannot track multiple URLs at once. As such, all three of my twtxt URLs will work for following, but mentions will only reach me at my HTTPS URL (https://hashnix.club/~dce/twtxt.txt). If there is a client that can cope with twtxt mirrors, I would love to know about it.

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

This would have been neater, but evidently my client foesn’t support multiline posts.

Apparently twtxt wasn’t the right client to use. twet seems to be alright, though.

@eric@itsericwoodward.com 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 🤣)

Ok fedimigues contem-me lá como é o vosso setup de RSS

tenho saudades de seguir feeds mas há tantos clientes/plataformas que não faço ideia por onde seguir

In 1996, they came up with the X11 “SECURITY” extension:

https://www.reddit.com/r/linux/comments/4w548u/what_is_up_with_the_x11_security_extension/

This is what could have (eventually) solved the security issues that we’re currently seeing with X11. Those issues are cited as one of the reasons for switching to Wayland.

That extension never took off. The person on reddit wonders why – I think it’s simple: Containers and sandboxes weren’t a thing in 1996. It hardly mattered if X11 was “insecure”. If you could run an X11 client, you probably already had access to the machine and could just do all kinds of other nasty things.

Today, sandboxing is a thing. Today, this matters.

I’ve heard so many times that “X11 is beyond fixable, it’s hopeless.” I don’t believe that. I believe that these problems are solveable with X11 and some devs have said “yeah, we could have kept working on it”. It’s that people don’t want to do it:

Why not extend the X server?

Because for the first time we have a realistic chance of not having to do that.

https://wayland.freedesktop.org/faq.html

I’m not in a position to judge the devs. Maybe the X.Org code really is so bad that you want to run away, screaming in horror. I don’t know.

But all this was a choice. I don’t buy the argument that we never would have gotten rid of things like core fonts.

All the toolkits and programs had to be ported to Wayland. A huge, still unfinished effort. If that was an acceptable thing to do, then it would have been acceptable to make an “X12” that keeps all the good things about X11, remains compatible where feasible, eliminates the problems, and requires some clients to be adjusted. (You could have still made “X11X12” like “XWayland” for actual legacy programs.)

Here’s an example of X11/Xlib being old and archaic.

X11 knows the data type “cardinal”. For example, the window property _NET_WM_ICON (which holds image data for icons) is an array of “cardinal”. I am already not really familiar with that word and I’m assuming that it comes from mathematics:

https://en.wikipedia.org/wiki/Cardinal_number

(It could also be a bird, but probably not: https://en.wikipedia.org/wiki/Cardinalidae)

We would probably call this an “integer” today.

EWMH says that icons are arrays of cardinals and that they’re 32-bit numbers:

https://specifications.freedesktop.org/wm-spec/latest-single/#id-1.6.13

So it’s something like 0x11223344 with 0x11 being the alpha channel, 0x22 is red, and so on.

You would assume that, when you retrieve such an array from the X11 server, you’d get an array of uint32_t, right?

Nope.

Xlib is so old, they use char for 8-bit stuff, short int for 16-bit, and long int for 32-bit:

https://x.org/releases/current/doc/libX11/libX11/libX11.html#Obtaining_and_Changing_Window_Properties

That is congruent with the general C data types, so it does make sense:

https://en.wikipedia.org/wiki/C_data_types

Now the funny thing is, on modern x86_64, the type long int is actually 64 bits wide.

The result is that every pixel in a Pixmap, for example, is twice as large in memory as it would need to be. Just because Xlib uses long int, because uint32_t didn’t exist, yet.

And this is something that I wouldn’t know how to fix without breaking clients.

OpenBSD has the wonderful pledge() and unveil() syscalls:

https://www.youtube.com/watch?v=bXO6nelFt-E

Not only are they super useful (the program itself can drop privileges – like, it can initialize itself, read some files, whatever, and then tell the kernel that it will never do anything like that again; if it does, e.g. by being exploited through a bug, it gets killed by the kernel), but they are also extremely easy to use.

Imagine a server program with a connected socket in file descriptor 0. Before reading any data from the client, the program can do this:

unveil("/var/www/whatever", "r");
unveil(NULL, NULL);
pledge("stdio rpath", NULL);

Done. It’s now limited to reading files from that directory, communicating with the existing socket, stuff like that. But it cannot ever read any other files or exec() into something else.

I can’t wait for the day when we have something like this on Linux. There have been some attempts, but it’s not that easy. And it’s certainly not mainstream, yet.

I need to have a closer look at Linux’s Landlock soon (“soon”), but this is considerably more complicated than pledge()/unveil():

https://landlock.io/

@movq@www.uninformativ.de 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?).

Security updates for Thursday
Security updates have been issued by Debian (chromium and mariadb-10.5), Oracle (firefox, ghostscript, git, go-toolset:ol8, golang, kernel, krb5, mingw-freetype and spice-client-win, nodejs:20, nodejs:22, perl-CPAN, python36:3.6, rsync, varnish, and varnish:6), Red Hat (firefox, thunderbird, and webkit2gtk3), Slackware (curl and python3), SUSE (apache-commons-beanutils, apache2-mod_security2, avahi, buildkit, ca-certificates-mozilla, cloud-regionsrv-client, cloud-regionsrv-client, py … ⌘ Read more

Aisla finds ‘freedom’ under water. Now the NDIS is pulling the plug
Research on injured ex-service personnel before and after scuba diving exercise show improvements, but NDIS clients are no longer able to access funding for similar therapies. ⌘ Read more

How to Play Fortnite on Mac with FnMacAssistant & Sideloadly
Gamers everywhere are happy that Fortnite is back for iPhone and iPad users, but there’s no Mac client in sight (yet anyway). But that doesn’t mean you can’t play Fortnite on the Mac, because if you have an Apple Silicon Mac, and you’re comfortable running some mods and tweaks, you can get the iOS/iPadOS version … [Read More](https://osxdaily.com/2025/05/31/how-to-play-fortnite-on-mac-with-fnmacassistant-sidel … ⌘ Read more

Security updates for Thursday
Security updates have been issued by AlmaLinux (kernel and kernel-rt), Debian (firefox-esr, libvpx, net-tools, php-twig, python-tornado, setuptools, varnish, webpy, yelp, and yelp-xsl), Fedora (xen), Mageia (cimg and ghostscript), Oracle (gstreamer1-plugins-bad-free, kernel, libsoup, thunderbird, and unbound), Red Hat (firefox, mingw-freetype and spice-client-win, pcs, and varnish:6), Slackware (curl and mozilla), SUSE (apparmor, containerd, dnsdist, go1.23-openssl, go1.24 … ⌘ Read more

Security updates for Tuesday
Security updates have been issued by AlmaLinux (gstreamer1-plugins-bad-free, libsoup, and python-tornado), Debian (libavif and pgbouncer), Red Hat (gstreamer1-plugins-bad-free, mingw-freetype and spice-client-win, and webkit2gtk3), SUSE (firefox, govulncheck-vulndb, and python310-setuptools), and Ubuntu (flask, intel-microcode, openjdk-17-crac, tika, and Tomcat). ⌘ Read more

Android is a brunch of linux. You only need to install a terminal app. But the termux app on Google Apps will not run on old android. Perhaps connectbot (ssh client) will run.

#<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?

GitHub for Beginners: Building a React App with GitHub Copilot
Follow along and build a frontend client using React and Copilot Chat.

The post GitHub for Beginners: Building a React App with GitHub Copilot appeared first on The GitHub Blog. ⌘ Read more

MCP 超強源碼解讀！Streamable HTTP 如何實現服務端向客戶端通信
在最新的 Model Context Protocol（MCP，模型上下文協議）版本（2025-03-26）[1] 中引入了 Streamable HTTP 的通信方式，取代了舊版本中的 SSE 通信方式，成爲了新的遠程 MCP 調用標準。Streamable HTTP 通信下的 client 向 server 的請求不需要像之前必須保持 SSE 的長連接，而是通過 client 發起 HTTP ⌘ Read more

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

Mentions are embedded within the text in either @ or @ format

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

@sorenpeter@darch.dk 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@twtxt.andros.dev 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.

Passei boa parte da tarde a tentar montar um servidor doméstico do #Luanti (ex-Minetest) e bato sempre em connection timeouts, mesmo dentro da rede local.

Não compreendo mesmo o que se passa, consigo ligar sem problema entre as máquinas (cliente/server), mas na hora de ligar com o jogo ao servidor, timeout. Experimentei pôr outro pc a fazer de server, mesmo resultado.

Aquela frustração de ter de desistir, especialmente num domingo. Ugh.

@andros@twtxt.andros.dev @eapl.me@eapl.me Still lots of bugs in my client. 🥴 I’ll try to fix it next week.

And yes, using the same timestamp twice will very likely break threads.

@movq@www.uninformativ.de ok, I have included a small modification in the documentation to allow you to reply in your own thread: https://texudus.readthedocs.io/en/latest/
You can see my reply: https://andros.dev/texudus.txt
Don’t delete anything and give me time to make my modifications to the client.

@andros@twtxt.andros.dev I set up a test feed here:

https://www.uninformativ.de/texudus.txt

I made some preliminary adjustments to my client so that it can work with the different threading model. (And I totally get the concerns, this can be quite a bit of work. Especially in a large code base like Yarn.)

I’ve just released version 1.0 of twtxt.el (the Emacs client), the stable and final version with the current extensions. I’ll let the community maintain it, if there are interested in using it. I will also be open to fix small bugs.
I don’t know if this twt is a goodbye or a see you later. Maybe I will never come back, or maybe I will post a new twt this afternoon. But it’s always important to be grateful. Thanks to @prologic@twtxt.net @movq@www.uninformativ.de @eapl.me@eapl.me @bender@twtxt.net @aelaraji@aelaraji.com @arne@uplegger.eu @david@collantes.us @lyse@lyse.isobeef.org @doesnm@doesnm.p.psf.lt @xuu@txt.sour.is @sorenpeter@darch.dk for everything you have taught me. I’ve learned a lot about #twtxt, HTTP and working in community. It has been a fantastic adventure!
What will become of me? I have created a twtxt fork called Texudus (https://texudus.readthedocs.io/). I want to continue learning on my own without the legacy limitations or technologies that implement twtxt. It’s not a replacement for any technology, it’s just my own little lab. I have also made a fork of my own client and will be focusing on it for a while. I don’t expect anyone to use it, but feedback is always welcome.
Best regards to everyone.
#twtxt #emacs #twtxt-el #texudus

@movq@www.uninformativ.de 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@www.uninformativ.de 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.

i’m using netcat installed on an android phone as a gopher client rn lol

Gopher browser (not a client) for all Windows starting with XP. Do not suffer http://shibboleths.org/roman/index.html

What’s your go-to Gopher client?

從 0 開始實現 MCP-Client
什麼是 MCP-Client？MCP-Client是Model Context Protocol（模型上下文協議）架構中的一個重要組件，用於連接AI模型（如Claude、GPT等大型語言模型）與外部數據源、工具和服務的橋樑。MCP（Model Context Protocol）是由Anthropic公司在 2024 年底首次提出並開源的一種開放標準協議，旨在解決大語言模型（LLM）與外部世界的連接 ⌘ Read more

@lyse@lyse.isobeef.org 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:

@movq@www.uninformativ.de Agreed, finding the right motivation can be tricky. You sometimes have to torture yourself in order to later then realize, yeah, that was actually totally worth it. It’s often hard.

I think if you find a project or goal in general that these kids want to achieve, that is the best and maybe only choice with a good chance of positive outcome. I don’t know, like building a price scraper, a weather station or whatever. Yeah, these are already too advanced if they never programmed, but you get the idea. If they have something they want to build for themselves for their private life, that can be a great motivator I’ve experienced. Or you could assign ‘em the task to build their own twtxt client if they don’t have any own suitable ideas. :-)

Showing them that you do a lot of your daily work in the shell can maybe also help to get them interested in text-based boring stuff. Or at least break the ice. Lead by example. The more I think about it, the more I believe this to be very important. That’s how I still learn and improve from my favorite workmate today in general. Which I’m very thankful of.

@lyse@lyse.isobeef.org 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@lyse.isobeef.org and Twtxtory from @javivf@adn.org.es?

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@adn.org.es 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'
"(#yarnd)"

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 #abcdfeg 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.

Security updates for Tuesday
Security updates have been issued by AlmaLinux (java-1.8.0-openjdk, kernel, libxslt, mod_auth_openidc:2.3, and webkit2gtk3), Fedora (c-ares, giflib, jupyterlab, perl, perl-Devel-Cover, perl-PAR-Packer, prometheus-podman-exporter, python-notebook, python-pydantic-core, rpki-client, ruby, rust-adblock, rust-cookie_store, rust-gitui, rust-gstreamer, rust-icu_collections, rust-icu_locid, rust-icu_locid_transform, rust-icu_locid_transform_data, rust-icu_normalizer, rust-icu_normalizer_data … ⌘ Read more

@bender@twtxt.net 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@twtxt.andros.dev 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.

Security updates for Monday
Security updates have been issued by Debian (erlang, fig2dev, shadow, wget, and zabbix), Fedora (chromium, jupyterlab, llama-cpp, prometheus-podman-exporter, python-notebook, python-pydantic-core, rpki-client, rust-adblock, rust-cookie_store, rust-gitui, rust-gstreamer, rust-icu_collections, rust-icu_locid, rust-icu_locid_transform, rust-icu_locid_transform_data, rust-icu_normalizer, rust-icu_normalizer_data, rust-icu_properties, rust-icu_properties_data, rust-icu_provider, rust-icu\ … ⌘ Read more

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.

@kat@yarn.girlonthemoon.xyz At the core, you need an ngircd.conf like this:

[Global]
    Name = your.irc.server.com
    Password = yourfancypassword
    Listen = 0.0.0.0
    Ports = 6667

    AdminInfo1 = Well, me.
    AdminInfo2 = Over here!
    AdminEMail = forget.it@example.invalid

[Options]
    Ident = no
    PAM = no

[SSL]
    CertFile = /etc/ssl/acme/your.irc.server.com.fullchain.pem
    KeyFile = /etc/ssl/acme/private/your.irc.server.com.key
    DHFile = /etc/ngircd/dhparam.pem
    Ports = 6669

Start it and then you can connect on port 6667. (The SSL cert/key must be managed by an external tool, probably something like certbot or acme-client.)

I’m assuming OpenBSD here. Haven’t tried it on Linux lately, let alone Docker. 😅

@prologic@twtxt.net I also thought it was a client-server thingy at first and usually it is, I guess, there’s just this workaround:

If it is not possible to install Borg on the remote host, it is still possible to use the remote host to store a repository by mounting the remote filesystem, for example, using sshfs.

is it like… ethical to offer access to certain self hosted services as patreon exclusives. like i wanna offer the IRC client/bouncer i hosted which seems ok i think because i’ve seen pico.sh offer their instances of that as paid services. but the other ones i have in mind are alt web frontends for stuff like imgur and pinterest. and i just feel weird about it for some reason. idk i’m trying to think of ways to support my server stuff but every time i come up with something it feels weird

@prologic@twtxt.net oooh this looks interesting!!! maybe i could play around with it in docker and see how to integrate it with caddy layer4 for TLS + my existing web client and bouncer!!

@movq@www.uninformativ.de i tried ngircd but couldn’t figure it out T__T i left it at the web client and bouncer for now but i might toy with an IRC server another time!

@prologic@twtxt.net 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 😅

@movq@www.uninformativ.de no clue! i’ve never had issues setting up websockets and the gamja client itself seems to work fine when connecting to other servers, but my bouncer doesn’t work right so it’s soju T__T i THINK there’s a problem with the websockets but it seems to be working right so i’m just confused

@javivf@adn.org.es 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.