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

#<2025-05-10T19:34:00+00:00 https://andros.dev/texudus.txt> Nice:) And is this implemented in your client as well? I’ve started to brainstorm on how to parse texudus in php, but I guess it could snatch some code from you?

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

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

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

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.

I just noticed that my unread messages counter was off by quite a bit. It showed 8, but I only saw one unread message. Even after restarting my client, which recalculates the number of unread messages, it remained at eight. Weird. Looking in the database revealed that this is indeed correct.

Apparently, my query to build up the message tree must be incorrect. It somehow misses seven messages. They all are orphaned, maybe that’s a clue. However, generating missing root messages (and thereby including the replies) typically works just fine. Hmm.

@quark@ferengi.one No editing old Twts that are the root of a thread with replies in the ecosystem. Just results in a fork. Unless the client has an implementation that does not store Twts keyed by Hash.

@movq@www.uninformativ.de wouldn’t editing your own twtxts cause the same issue Yarnd (or any other client) has, which is breaking any replies to it? Under which conditions would this work the best? When copying the twtxt.txt file asynchronously? In my case I copy the twtxt.txt file to its web root right away, but I figure I could not do that, which would give me a set period of time to edit without worries.

@bender@twtxt.net NOOOO i self host an XMPP server and also revolt but as much as i love XMPP (gajim client reminds me of using skype as a kid highkey) i don’t use it much and revolt is a bitch to maintain. like i broke revolt file uploads and it stayed that way for months until literally last week lmao. i never bothered with matrix tbh maybe i should’ve but it seems not worth it

@andros@twtxt.andros.dev I give you not creating another file, but then I’d vote for commenting out DMs. See https://eapl.me/timeline/post/z5e2bna

It’s easier to find the DM in comments from your side, than asking all the client maintainers to add the regex =P
You can even use a Modified comment, such as
#! <DM content>
Or something like that

This approach is retro-compatible with current and older clients.

@bender@twtxt.net For example:

If you can see this twt in any feed…

xxxx-xx-xxTxx:xx:xxZ	!<bender https://twtxt.net/user/bender/twtxt.txt> U2FsdGVkX1+QmwBNmk9Yu9jvazVRFPS2TGJRGle/BDDzFult6zCtxNhJrV0g+sx0EIKbjL2a9QpCT5C0Z2qWvw==

It is for you. Any other possibility must be ignore (hidden in your timeline).

If your client doesn’t have the posibility to decrypt the twt, hide all direct message. It is all :)

@bender@twtxt.net @aelaraji@aelaraji.com The client should ignore twts if it’s not compatible or not addressed to me. it’s a simple regex to add! It’s similar to Twt Hash Extension, should they be in another file? They are child messages, not flat twt. Not of course!

@doesnm.p.psf.lt@doesnm.p.psf.lt It was always intended to have both Yarn.social and Salty.im integrate together. Yes. This includes having a set of specifications that anyone can write clients to.

my main itch with the DMs extensions is that these messages are intended to be private, not public information. That’s why other extensions make sense, but DMs are another kind of feature.
TwiXter, Mastodon, FB and some other services usually hide the DMs in another section, so they are not mixed with the public timeline.

I find the DM topic interesting, I even made an indie experiment for a centralized messaging system here https://github.com/eapl-gemugami/owl.
Although, as I’ve said a few times here, I’m not particularly interested in supporting it on microblogging, as I don’t use it that much. In the rare case I’ve used them, I don’t have to manage public and private keys, and finally none of my acquaintances use encrypted email.
Nothing personal against anyone, and although I like to debate and even fight, it’s not the case here. This proposal is the only one allowing DMs on twtxt, and if the community wants it, I’ll support it, with my personal input, of course.

A good approach I could find with a good compromise between compatibility with current clients and keeping these messages private is ‘hiding’ the DMs in comments. For example:
# 2025-04-13T11:02:12+02:00 !<dm-echo https://dm-echo.andros.dev/twtxt.txt> U2FsdGVkX1+QmwBNmk9Yu9jvazVRFPS2TGJRGle/BDDzFult6zCtxNhJrV0g+sx0EIKbjL2a9QpCT5C0Z2qWvw==

I think I would encourage anyone in this community is to care less about supporting “legacy clients” and focus more on value-add whilst balancing the burden of client authors – which have very precious little “spare time” 🤣

@andros@twtxt.andros.dev I don’t see any “fighting” here. This is just good experimentation. Unfortunately there hasn’t really been enough time or effort by other “client authors” yet, me especially as I’ve been super busy with ya’ know my “day job” that pays the bills and refactoring yarnd to use a new and shiny and much better SqliteCache 🤣 – I certainly don’t think your efforts are wasted at all. I would however like @doesnm.p.psf.lt@doesnm.p.psf.lt encourage you to look at the work we’ve done as a community (which was also driven out of the Yarn.social / Twtxt community years back).

@prologic@twtxt.net @bender@twtxt.net @eapl.me@eapl.me I think opening another file is a bad idea because it adds complexity to the clients, breaks the single feed and I think keeping legacy clients will be more complex to add new features in the future. A modern approach is important.
I’ll be honest, I’m a bit tired of the fight around the direct message. Perhaps, we can remove it as an extension and use the alternative @prologic@twtxt.net . My suggestion apparently doesn’t like to the community. I have no problem with remove it.

@andros@twtxt.andros.dev maybe create a separate, completely distinct feed for DM? That way, clients do not need to do anything, only those wanted to “talk in private” follow themselves, using their very special dm-only.txt feeds. 😂

@eapl.me@eapl.me When it is up and running, I promise to add it to the specification. I will also include some corrections.
The nature of twtxt does not allow us to selectively hide clients. It’s a problem not with DM, but with any extension.
@prologic@twtxt.net Yes, it is a security hole. All dm-echo messages are readable. I intend it to be a debugging tool. Maybe I can include a warning message. If many of you see that it is a serious problem, I can remove the links.
@xuu@txt.sour.is It’s already much better than Mastodon :P . Maybe we can remove the sender and receiver references with an intermediary register.

not a big deal as I can skip those messages, but again, it’s an extension, so older clients shouldn’t be affected by a new feature.

I’m also thinking that some kind of tag might be needed to automatically hide twts from unknown extensions. For example our client doesn’t support DMs and always shows the !<nick url><encrypted_message> syntax which is meaningless.

@bender@twtxt.net Yes! I deleted those repeated twts because it was poor execution by my client. They are currently not present in my feed.
Maybe it would be interesting to check if any twt has disappeared?

Aside from fetching feeds every three minutes (which kind of adds mystery to this puzzle), I think there is something else going on with the client you are using, @andros@twtxt.andros.dev. Some of those twtxts are seconds apart, making me truly stumped. 😅

YEAH THATS ME LOLLLL I HAVE NO CLUE WHAT IT IS….. me haunting ur clients or whatever with my funky version string

yay! A new client 😀

thanks for sharing @xuu@txt.sour.is!

Checking for example https://watcher.sour.is/api/plain/twt or https://registry.twtxt.org/api/plain/tweets, I don’t know whether this syntax is being used by clients or by people. Is it integrated on Yarn in any way? Genuinely asking to know more about it.

If I might throw a quick thought to those working on the registries, it would be nice to have an endpoint with a valid twtxt output (perhaps cached or dumped to a static file) which a client could point to, helping to discover it’s content in a way which is compatible with the twtxt spec.

Taking the first twt I found in https://watcher.sour.is/api/plain/twt as an example:
reddit_world_news https://feeds.twtxt.net/Reddit_World_News/twtxt.txt 2025-03-28T00:29:25Z **China bans US logs. 3 billion dollar[...])
it would be something like
TIME <@NICK URL> TWT
2025-03-28T00:29:25Z <@reddit_world_news https://feeds.twtxt.net/Reddit_World_News/twtxt.txt> **China bans US logs. 3 billion dollar[...])

That way you could watch the latest twts with your client, something similar to what we find on Mastodon: https://mastodon.online/public/local

Some support from the clients to separate these ‘discovery’ content, from your following timeline might be required. 🤔

somehow I forgot that existed.

Perhaps it was its mention of being a demo implementation here:
https://twtxt.readthedocs.io/en/latest/user/registry.html#registry
So I though it wasn’t really active.

Anyway, I think that’s a good idea.

Is there something similar available on Yarn? Sorry for for asking if that was mentioned recently.

I think that the clients may help you to submit your URL to these directories, and also to get a view of the twts in them.

thanks @prologic!
@bender the idea of the RFC was to reach an agreement on a difficult problem, receiving proposals, and the voting is a simple count to gauge the sentiment of “is this a problem worth to be fixed?, are we committed to implement a change in our clients?”

But that’s a fair point. What do the community expect? What do y’all expect?

Twtxt was made for nerds, by nerds.
I’d like to change that. It’s by nerds/hackers, for nerds/hackers and friends of these. It doesn’t have to be hacky all the time, as you don’t need to be a nerd to have a blog.
But, for that to happen, someone has to build the tools to improve UX.

by design there really is no way to easily discovers others
Yeah, I agree, and although there are directories of email addresses, usually you don’t want that, unless you are a ‘public figure’.
I couldn’t say that a microblogging is a “social network” by default, as a blog is not either. At the same time, people would expect to find new people and conversations, as you’d do in a forum.

I think of two features on top of the current spec:

• Clients showing a few posts of what your following are watching but you don’t, so perhaps you find something interesting to follow next. Or that feature of “Your ‘followings’ are following these accounts/people”. (Hard to explain in english, but I hope you get the idea)
  
• Sharing your .txt into some directory, saying “Hey, I have this twtxt URL, I want to be discovered”. I’m thinking of something like the Federated tab on Mastodon.

Hmm so looking at the swagger of the registry spec client it seems to just take a “page”.. That seems worse than doing an offset. Lol.

https://github.com/DracoBlue/twtxt-registry/blob/master/src/swagger.json

thanks andros!

instead of adding the new twt at the end of the feed, do it at the beginning
The PHP client did that originally, although I didn’t see a real benefit if you use… a client.
It could help if you read the .txt file through a browser or something. Also, not many clients are prepared to cut the request, and you can’t rely on the file being organized that way, so finally we dropped that feature.

@lyse@lyse.isobeef.org I’m glad to hear that! Yay for more clients. 😊

I now subscribed to most feeds in my Go tt reimplementation that I already followed with the old Python tt. Previously, I just had a few feeds for testing purposes in my new config. While transfering, I “dropped” heaps of feeds that appeared to be inactive.

This might motivate me to actually “finish” the new client, so that it could become my daily driver. No need to use the old software stack any longer. Let’s see how bad this goes.

@movq@www.uninformativ.de Yeah, most of the graphical applications are actually KDE programs:

• KMail – e-mail client
  
• Okular – PDF viewer
  
• Gwenview – image viewer
  
• Dolphin – file browser
  
• KWallet – password manager (I want to check out pass one day. The most annoying thing is that when I copy a password, it says that the password has been modified and asks me whether I want to save the changes. I never do, because the password is still the same. I don’t get it.)
  
• KPatience – card game
  
• Kdenlive – video editor
  
• Kleopatra – certificate manager
  

Qt:

• VLC – video player
  
• Psi – Jabber client (I happily used Kopete in the past, but that is not supported anymore or so. I don’t remember.)
  
• sqlitebrowser – SQLite browser
  

Gtk:

• Firefox – web browser
  
• Quod Libet – music player (I should look for a better alternative. Can’t remember why I had to move away from Amarok, was it dead? There was a fork Clementine or so, but I had to drop that for some unknown reason, too.)
  
• Audacity – audio editor
  
• GIMP – image editor
  

These are the things that are open right now or that I could think of. Most other stuff I actually do in the terminal.

In the past™, I used the Python KDE4 bindings. That was really nice. I could pass most stuff directly in the constructor and didn’t have to call gazillions of setters improving the experience significantly. If I ever wanted to do GUI programming again, I’d definitely go that route. There are also great Qt bindings for Python if one wanted to avoid the KDE stuff on top. The vast majority I do for myself, though, is either CLI or maybe TUI. A few web shit things, but no GUIs anymore. :-)

“it is very easy to filter or ignore it” This is the interesting part for legacy clients, hehe

Joking aside, let’s see how it works in the wild!

@eapl.me@eapl.me I think the benefits do not outweigh the disadvantages. Clients would have to read and merge the information from 2 txt and a new metadata would have to be added with the address of this file.
Also, it is very easy to filter or ignore it.

well, I assume by syntax you mean Gemtext (which I like a lot, my personal blog is built on top of it), so I think it might work for twtxt clients…

I knew of twtxt in Gemini Antenna, so at least the 2017 spec might work on that protocol. I think the main issue with extensions is that they weren’t designed with many URLs and protocols in mind.

Also I have to admit that the Gemini community significantly reduced in the last few years. I don’t know how worth it is to add support for Gemini now.

I have applied your comments, and I tried to add you as an editor but couldn’t find your email address. Please request editing access if you wish.

Also, could you elaborate on how you envision migrating with a script? You mean that the client of the file owner could massively update URLs in old twts ?

@andros@twtxt.andros.dev Can you reproduce any of this outside of your client? I can’t spot a mistake here:

$ curl -sI 'http://movq.de/v/8684c7d264/.html%2Dindex%2Dthumb%2Dgimp11%2D1.png.jpg'
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 2615
Content-Type: image/jpeg
Date: Wed, 19 Mar 2025 19:53:17 GMT
Last-Modified: Wed, 19 Mar 2025 17:34:08 GMT
Server: OpenBSD httpd

$ curl -sI 'https://movq.de/v/8684c7d264/gimp11%2D1.png'
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 131798
Content-Type: image/png
Date: Wed, 19 Mar 2025 19:53:19 GMT
Last-Modified: Wed, 19 Mar 2025 17:18:07 GMT
Server: OpenBSD httpd

$ telnet movq.de 80
Trying 185.162.249.140...
Connected to movq.de.
Escape character is '^]'.
HEAD /v/8684c7d264/.html%2Dindex%2Dthumb%2Dgimp11%2D1.png.jpg HTTP/1.1
Host: movq.de
Connection: close

HTTP/1.1 200 OK
Connection: close
Content-Length: 2615
Content-Type: image/jpeg
Date: Wed, 19 Mar 2025 19:53:31 GMT
Last-Modified: Wed, 19 Mar 2025 17:34:08 GMT
Server: OpenBSD httpd

Connection closed by foreign host.
$ 

@andros@twtxt.andros.dev Hm, looks correct to me. The image to be displayed is a thumbnail and this links to the full-sized image. The thumbnail (JPG) is auto-generated from the full image (PNG), hence the two extensions.

What does look strange, though, is that your client came up with the hash pqsmcka, while it should have been te5quba. 🤔

@prologic@twtxt.net Can we add a table in twtxt.dev with features of each client?

• Is active?
  
• Extensions compatibility
  
• Language
  
• Multiaccount.
  
• Mutiuser
  And so on…

@movq@www.uninformativ.de The urls of the images are strange! My client crashes to display them, and when I tried some urls, I found a redirect. Ah! And the images had two extensions.

@eapl.me@eapl.me Good job! I have added these comments:

1. It is only long for humans. Clients can only leave a hyperlink.
   
2. The nickname is just a decoration, only the date that acts as the id and the URL matter. The nick is used for humans reading the feed.
   
3. It can be migrated with a script, if the feed exists.

i have got to try the jenny yarn client it looks so fun and old school……..

well… it has been an opportunity to build an artisanal microblogging client on top of a minimalist protocol. I agree on the hacker toy part.

And of course it’s about being part of a niche community which is (mostly) amazing, and nurturing. As there is almost no one writing in my native spanish, it has been an interesting challenge to share my thoughts in english, as well.

I couldn’t say it’s a ‘social network’ per se, I think it lack many engagement things usually associated with social networks, although it has a social part of igniting discussions, learnings and behavioral changes, which is the meaning of social for me.

Are there any clients to read gemini?

I have released new updates to the twtxt.el client.

• New feature: Notifications.
  
• Updated: Improved user interface for new posts.
  
• Updated: Documentation.
  
• Updated: Some UI elements and included information about shortcuts in each buffer.
  
• Minor fixes.
  Source code: https://codeberg.org/deadblackclover/twtxt-el
  In the next version: You will be able to send direct messages.
  Enjoy!
  #emacs #twtxt #twtxtel

ah! those german calendars. Somehow I was thinking of something like mine, with spaces to write inside each day.

I worked for a german company and they gave away these calendars to our clients and team every year, but the model you can hang on the wall. Memory unlocked!

@prologic@twtxt.net If it develops, and I’m not saying it will happen soon, perhaps Yarn could be connected as an additional node. Implementation would not be difficult for any client or software. It will not only be a backup of twtxt, but it will be the source for search, discovery and network health.

pls elaborate on a ‘p2p database’, ‘all story’ and ‘Registries’.

My first thought takes me to something like secure-scuttlebutt which it’s painful to sync data using clients, and too slow compared to downloading a text file.

Also I’d like for twtxt to avoid becoming an ActivityPub. Works well but it’s uses too many resources IMO.
https://kingant.net/2025/02/mastodon-the-cost-of-running-my-own-server/

I’m defending being able to self-host your Web client (like you’d do with a Wordpress, twtxt is a micrologging, at the end), instead of federated instances, so in a first thought I’d say Registries have many disadvantages being the first one that someone has to maintain them active.

@prologic@twtxt.net make server actually because i don’t need the client on my server, also i run make deps before just in case lol

You can find the #twtxt-el channel in Libera IRC to talk about the twtxt.el client, I will keep my connection open so you can ask me questions. Thank you!

Hacer software código opensource es desafiante y paulatinamente desgasta a su autor. Todo comienza con pasión y entusiasmo, por supuesto. Si logras repercusión, te enfrentas a una carrera de fondo que muchos terminan abandonando por las demandas constantes de usuarios que, a menudo, no valoran el trabajo ni contribuyen de manera significativa. Por mencionar un caso reciente: Hector Martin. Líder del proyecto Asahi Linux, quien dedicó años a adaptar Linux para los procesadores Apple Silicon, un logro técnico impresionante. Sin embargo, terminó renunciando debido a la presión de usuarios que exigían soporte y mejoras como si fueran clientes pagos.

La mayoría de los mantenedores no reciben ningún soporte económico. Solo unos pocos proyectos logran sostenibilidad financiera a través de patrocinios, mientras que la mayoría de los desarrolladores terminan con un segundo empleo no remunerado.

Sin un cambio en la forma en que se valora y apoya los proyectos Opensource, y no solo hablo de las grandes empresas multimillonarias. Sería una perdida para todos si acabaremos con un ecosistema de software archivado y abandonado.

Ahora te paso la pelota a ti, ¿cuando fue la última vez que apoyaste a un mantenedor de software opensource?

#opensource #software #sostenibilidad

I have released new updates to the twtxt.el client.

• New feature: View and interact with threads.
  
• Optimisation of ordering for long feeds.
  
• Minor fixes.
  

In the next version you will be able to see all your mentions.

Enjoy!

#emacs #twtxt #twtxtel

Video

@prologic@twtxt.net Damn! :-( Yeah, I won’t build that into my client. Not worth it for the many things that are still undetectable and the low frequency it happens.

looks good to me!

About alice’s hash, using SHA256, I get 96473b4f or 96473B4F for the last 8 characters. I’ll add it as an implementation example.
The idea of including it besides the follow URL is to avoid calculating it every time we load the file (assuming the client did that correctly), and helps to track replies across the file with a simple search.

Also, watching your example I’m thinking now that instead of {url=96473B4F,id=1} which is ambiguous of which URL we are referring to, it could be something like:
{reply_to=[URL_HASH]_[TWT_ID]} / {reply_to=96473B4F_1}
That way, the ‘full twt ID’ could be 96473B4F_1.

Hey everyone!

About the idea of improving the “thread” extension, what if we set aside March 2025 to gather proposals and thoughts from everyone? We could then vote on them at the end of the month to see if the change and migration are worth it.

The voting could include client maintainers (and maybe even users too). That way, we get a good mix of perspectives before taking a decision in a decent timelapse.

What do you think? If this sounds good, we can start agreeing on this. Let me know your thoughts!

@bmallred@staystrong.run I forgot one more effect of edits. If clients remember the read status of massages by hash, an edit will mark the updated message as unread again. To some degree that is even the right behavior, because the message was updated, so the user might want to have a look at the updated version. On the other hand, if it’s just a small typo fix, it’s maybe not worth to tell the user about. But the client doesn’t know, at least not with additional logic.

Having said that, it appears that this only affects me personally, noone else. I don’t know of any other client that saves read statuses. But don’t worry about me, all good. Just keep doing what you’ve done so far. I wanted to mention that only for the sake of completeness. :-)

@andros@twtxt.andros.dev I don’t see a burst of new twtxt clients popping up. Yeah, the most recent ones are TwtxtReader and twtxt-el. Did I miss one? I agree with @david@collantes.us, looks normal to me. :-)

I’m also working on my rewrite at the moment, but that started… *looking at the git history*… oh wow! O_o Over two years ago! I just implemented jumping to the next/previous unread message.

working on my bookmarks tool, I found out that http(s)://domain.tls is not a valid resource, but http(s)://domain.tls/ is, as you can see here: https://stackoverflow.com/a/2581423

I suppose that internally the wget/curl or whatever client you are using is redirecting it?

@andros@twtxt.andros.dev I wouldn’t call it regular, but cyclical. Since, with the exception of Yarn (maybe?), clients are everything when it comes to twtxt, every now and then we see an increase of interest on new development. I have seeing them come and go, only few “beside remains”. :-)

Question to the twtxt veterans, are we experiencing an explosion of clients or is this a regular occurrence?

I have released new updates to the twtxt.el client.

• Markdown to Org mode (you need to install Pandoc).
  
• Centred column.
  
• Added new logo.
  
• Added text helper.
  

The new version I will try to finish the visual thread. You still can’t see the thread yet.

Video