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

The Software Design I See: Thick–Thin Clients
Comments ⌘ Read more

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

How Let’s Encrypt reduced the impact of zombie clients
Comments ⌘ Read more

How One Path Traversal in Grafana Unleashed XSS, Open Redirect and SSRF (CVE-2025–4123)

Image

Abusing Client Path Traversal to Chain XSS, SSRF and Open Redirect in Grafana

[Continue rea … ⌘ 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

First version of Elicitation to the MCP draft specification
Comments ⌘ 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.

$750 Bounty: for HTTP Request Smuggling on Data.gov

Image

How a cleverly crafted desync attack revealed a hidden path to client-side compromise, JS injection and potential cookie theft

[Continue reading on InfoSec Write-ups »](https://infosecwriteups.com/ … ⌘ Read more

Ending TLS Client Authentication Certificate Support in 2026
Comments ⌘ Read more

HMPL v3.0: Small template language for displaying UI from server to client
Comments ⌘ Read more

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

UUIDs: A False Sense Of Security

Image

Hi Hunters, would you like to learn about a broken access control vulnerability that I discovered recently for a client.

[Continue reading on InfoSec Write-ups »](https://infosecwriteups.com/uuids-a-false-sense-of-security-10467497daae?source=rss—-7b7 … ⌘ 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

What Does “use client” Do?
Comments ⌘ Read more

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

OSTIF Announces NATS Security Audit Results
OSTIF is proud to share the results of our security audit of NATS.  NATS is an open source project made by Synadia Communications for secure always-on messaging for a variety of digital formats and clients. With… ⌘ Read more

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.

(#6kkpdda) The nice thing here is that any Ui/UX rendering for a “good user experience” is similar to what yarnd does for Youtube/Spotify/what …
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. ⌘ Read more

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

💡 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 …
💡 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 “ … ⌘ Read more

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

(#3lokkza) Seem like it’s a server-client thingy? 🤔 I much prefer tools in this case and defer the responsibility of storage to something els …
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 😅 ⌘ Read more

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

(#mkhkhuq) @quark@quark No editing old Twts that are the root of a thread with replies in the ecosystem. Just results in a fork. Unless th …
@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. ⌘ Read more

@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

@eaplme@eapl.me you wrote:

“That PHP snippet could be merged into https://twtxt.dev/exts/twt-hash.html”

Why, though? AFAIK @andros@twtxt.andros.dev’s client is on Emacs, @lyse@lyse.isobeef.org’s is on Python (and Golang, for tt2), @movq@www.uninformativ.de’s is on Python, and @prologic@twtxt.net’s is on Golang. All the client creator needs to know is in the documentation already, coding language agnostic.

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

(#mymzn2a) @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 …
@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. ⌘ Read more

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” 🤣

(#2zhuzoa) I think I would encourage anyone in this community is to care less about supporting “legacy clients” and focus more on value-add whil …
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” 🤣 ⌘ Read more

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

(#2zhuzoa) @andros@andros I don’t see any “fighting” here. This is just good experimentation. Unfortunately there hasn’t really been e …
@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 … ⌘ Read more

Law firms pledge almost $1 billion in free work to Trump
Sam Baker,  Staff Writer  -  Axios

Stephan: Here is a list, it is probably longer today but this was the most fact-based one I could find, of the law firsm that have become the legal servants of dictator Trump. The men and women in these firms are week and unethical. Don’t become a client of any of them, and if you are in law school do not go to work for any of them when you pass your law exam.

![](https://www … ⌘ Read more

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