More implementations of standard protocols is always nice!
I see no reason for me to change from my beloved https://prosody.im/ which is more than lightweight enough already. But having options is nice, and standards only make sense when there are several implementations of them.
AGENTS.md on a standard protocol. Sorry but no. You either understand the thing or you don’t.
It’s a chat protocol. Something that is supposed to be very private and secure. Seeing an AGENT.md file is a huge turn-off there, sorry to say. Feel free to burn my karma down to oblivion.
I'd actually feel pretty safe with a LLM project if spec'd against the protocol documentation as opposed to a rookie's handcoded implementation. If security is the concern, I don't think using random reimplements is very safe to begin with.
Same. I had a couple LLM's rewrite, harden an anonymous image board. It's not popular but exposed to the internet and the Tor network. Not worried at all.
Unless the model changes and messes half the code base on next iteration. Or Anthropic decides to A/B test your agent.
Or when shit goes sideways and someone actually needs to take a human look at the BF s. I’d rather have the guy who manually with human eyes read the specs.
> Something that is supposed to be very private and secure
Not sure how using an LLM for development of the tool has any affect on this. From a security perspective, I think that would've had more validity a year or two ago, but these days, I'd argue LLMs practice better security in generated code on average than a normal developer.
From the privacy angle, I have no idea how having an AGENTS.md (for development purposes) has any impact on privacy.
I don't want to "burn [your] karma to the ground", I just want to understand this angle, because I'm not sure I see how it applies.
Indeed, Linus Torvalds is infamous for not caring what he ships (https://news.ycombinator.com/item?id=50111350). That's why he's never been known to go on, let's say impassioned tirades against people who submit bad patches to the linux kernel. After all, it's not like he's ever apologized for inflammatory behavior before (https://news.ycombinator.com/item?id=18000698).
On a more serious note, it's not a dichotomy that one either uses AI to code or they care about what they ship. Some people use AI to code and care what they ship.
But that's because it does way more. Matrix is the foundation to build a self-hosted Slack-like platform (public/private rooms, audio and video support, threads, e2e encryption, etc). XMPP is basically self-hosted AOL Instant Messenger.
Whatever you can think of, XMPP supports it. Whether enough clients support it for it to be reliable is another question entirely!
(The XEPs I mentioned are considered "core modern" so most clients support them, you can browse through https://docs.modernxmpp.org/client/protocol/ to see what's considered the bare minimum for a full client)
Matrix doesn't do way more. The client features you mention are also widespread in XMPP world, and some clients even do more (look at Movim for instance).
Where matrix does do more is on the protocol level, because it objectively absurdly complex and unnecessarily so. Matrix stands to offer distributed rooms as the one differentiating feature over XMPP. The complexity price to pay for that is substantial. All along, XMPP had fMUCs and distributed servers, because the complexity of clustering could be absorbed by the runtime better, for those who cared/needed it (as proven by the overwhelming success of WhatsApp, a fork of ejabberd, running on top of the Erlang platform)
> Matrix is the foundation to build a self-hosted Slack-like platform (public/private rooms, audio and video support, threads, e2e encryption, etc)
Yes. And since that’s more than most Matrix users use Matrix for - it’s a design cost brought on to every single user to accommodate the needs of the 0.1%.
The complexity and cost of running a Matrix home-server instance is ridiculous. Should you ever need to do admin work - you’ll be forced to curl your own server using bespoke APIs (or use Claude to do it for you) - because element never thought an admin portal was important to include in a globally federated com-product which just keeps accumulating more and more data.
I use Matrix myself - because what else is there - but let’s be honest about what this thing is.
It’s a giant, over-engineered, under-implemented promise - which fails to deliver the second you push it past the IRC stage.
Btw - I’ve run IRC servers for 20+ years with less total lifetime maintenance than a Matrix home-server has in a single year. Just so many things breaking.
Matrix is almost as old now as XMPP was when Matrix first came out, and yet, after all those years and grandiose promises, and loads of venture capital, it doesn't strike me as approaching the problem in a better/sounder manner than the protocol it was set to replace (quite the opposite, actually, Matrix, the protocol and its implementations are worse on almost every metric).
Eh, I've used both a lot and matrix is kinda flailing from my perspective. At least for casual use. If you are a client of Element maybe the experience is better, but with their "next-gen" battery friendly client they've been working on for years, I can't even get notifications working through public unified push servers when using matrix.org. Meaning that just to get started using it I have to run my own matrix or up server.
I switched from Matrix back to XMPP, because it has a lower setup and operating cost. I would have loved to use IRC, but the XMPP client mobile support is a bit better
I don't think the server space needs any innovation, current servers are very good.
What we do need are clients that are palateable to the masses. Something on desktop with the polish of Conversations. That's what will really drive adoption from people. I think a big part of Matrix being so popular versus XMPP is that they had a stronger unified client set that looked modern was appealing to many people.
All the widely deployed XMPP servers support a great number of XEPs. The perceived fragmentation of the XMPP ecosystem is mostly a client problem.
So true. The existing clients are actually the only reason I haven't asked all my friends to join my server. Only the ones who will put up with jank.
Gajim is _okay_ on desktop, but it leaves a LOT to be desired. Everything else feels way too bare-bones to feel comfortable recommending to Discord expats. Fluux Messenger is the closest I've seen, but it's sluggish for me. Maybe that's just Tauri on Linux.
Conversations is good on Android (bit barebones feeling), and I haven't tried out voice with it. IDK what the situation is in the Apple ecosystem.
I really, really wish I had the time to just start building a strong suite of XMPP clients. Every day Discord shoves a new ad in my face I get closer to biting the bullet.
I'm a big fan of Tuwunel. Run Synapse myself since I've had a server running for about 7 years now, but if I had to start over, Tuwunel all the way.
There's also Continuwuity, which I think is more popular, but I don't fully understand the difference. I think it's a community split issue? As someone who maintains a client, Tuwunel seems to match the spec better, but I'm sure folks have better reasons to pick one over the other.
I saw some coding harness (OMP i think?) labeling sub-agent comms as "IRC" for the agents to use. XMPP is another one I bet AI would just understand what to use it for. I have been absorbing whether tried-and-true old tech like these are going to revive in the AI era, just because it's "locked in" in the training data. AI is going to keep some of these torches burning forever maybe.
> ...I have been absorbing whether tried-and-true old tech like these are going to revive in the AI era, just because it's "locked in" in the training data. AI is going to keep some of these torches burning forever maybe.
I agree with you 100%! With so much open source software and know-how material that has been available for AI to train on, it seems inevitable that such tools will be used that much more often...and then as the AI trains on newer content, it will continue a virtuous cycle of open source software that will keep being used, and further improved...and as you stated "burning forever".
Don't really get the hype over Rust... I, personally, like C more. It would be much more smarter to make another server on simple and clean C, rather than using a language that already has a big toolchain and also compiles longer.
Considering that LLMs more often than not forget stuff when writing code, I definitely prefer Rust's automatic memory management system compared to balancing mallocs and frees throughout the code.
You could do RAII in C++, but the compiler won't warn on unsafe code.
More implementations of standard protocols is always nice!
I see no reason for me to change from my beloved https://prosody.im/ which is more than lightweight enough already. But having options is nice, and standards only make sense when there are several implementations of them.
totally agree, Prosody is great, and in a lot of ways, it's been a real source of inspiration.
> it's been a real source of inspiration
Tell me more!
AGENTS.md on a standard protocol. Sorry but no. You either understand the thing or you don’t.
It’s a chat protocol. Something that is supposed to be very private and secure. Seeing an AGENT.md file is a huge turn-off there, sorry to say. Feel free to burn my karma down to oblivion.
I'd actually feel pretty safe with a LLM project if spec'd against the protocol documentation as opposed to a rookie's handcoded implementation. If security is the concern, I don't think using random reimplements is very safe to begin with.
I'd actually feel pretty safe with a LLM project
Same. I had a couple LLM's rewrite, harden an anonymous image board. It's not popular but exposed to the internet and the Tor network. Not worried at all.
This is a false choice. You can pick neither and for all you know you're picking both.
Unless the model changes and messes half the code base on next iteration. Or Anthropic decides to A/B test your agent.
Or when shit goes sideways and someone actually needs to take a human look at the BF s. I’d rather have the guy who manually with human eyes read the specs.
> Something that is supposed to be very private and secure
Not sure how using an LLM for development of the tool has any affect on this. From a security perspective, I think that would've had more validity a year or two ago, but these days, I'd argue LLMs practice better security in generated code on average than a normal developer.
From the privacy angle, I have no idea how having an AGENTS.md (for development purposes) has any impact on privacy.
I don't want to "burn [your] karma to the ground", I just want to understand this angle, because I'm not sure I see how it applies.
Do you not use AI for coding?
> Do you not use AI for coding?
A lot of people prefer to understand the things they ship. I don't understand why this remains surprising to some.
Indeed, Linus Torvalds is infamous for not caring what he ships (https://news.ycombinator.com/item?id=50111350). That's why he's never been known to go on, let's say impassioned tirades against people who submit bad patches to the linux kernel. After all, it's not like he's ever apologized for inflammatory behavior before (https://news.ycombinator.com/item?id=18000698).
On a more serious note, it's not a dichotomy that one either uses AI to code or they care about what they ship. Some people use AI to code and care what they ship.
I remember when jabber was cool and there used to be public gateways to icq and what not.
Looks like matrix is in this niche now.
Matrix is way more expensdve to run by its protocol design
But that's because it does way more. Matrix is the foundation to build a self-hosted Slack-like platform (public/private rooms, audio and video support, threads, e2e encryption, etc). XMPP is basically self-hosted AOL Instant Messenger.
> public/private rooms
Fully supported by XMPP: https://xmpp.org/extensions/xep-0045.html
> audio and video support
Supported by some clients (usually over Jingle) but nothing standard AFAIK: https://xmpp.org/about/technology-overview/#jingle
> threads
Rooms can have multiple threads but I don't think they're used the way they are in discord/slack/etc.
> e2e encryption
XMPP has multiple ways. Currently the most widely used by clients is OMEMO https://xmpp.org/extensions/xep-0384.html
> etc
Whatever you can think of, XMPP supports it. Whether enough clients support it for it to be reliable is another question entirely!
(The XEPs I mentioned are considered "core modern" so most clients support them, you can browse through https://docs.modernxmpp.org/client/protocol/ to see what's considered the bare minimum for a full client)
Matrix doesn't do way more. The client features you mention are also widespread in XMPP world, and some clients even do more (look at Movim for instance).
Where matrix does do more is on the protocol level, because it objectively absurdly complex and unnecessarily so. Matrix stands to offer distributed rooms as the one differentiating feature over XMPP. The complexity price to pay for that is substantial. All along, XMPP had fMUCs and distributed servers, because the complexity of clustering could be absorbed by the runtime better, for those who cared/needed it (as proven by the overwhelming success of WhatsApp, a fork of ejabberd, running on top of the Erlang platform)
> Matrix is the foundation to build a self-hosted Slack-like platform (public/private rooms, audio and video support, threads, e2e encryption, etc)
Yes. And since that’s more than most Matrix users use Matrix for - it’s a design cost brought on to every single user to accommodate the needs of the 0.1%.
The complexity and cost of running a Matrix home-server instance is ridiculous. Should you ever need to do admin work - you’ll be forced to curl your own server using bespoke APIs (or use Claude to do it for you) - because element never thought an admin portal was important to include in a globally federated com-product which just keeps accumulating more and more data.
I use Matrix myself - because what else is there - but let’s be honest about what this thing is.
It’s a giant, over-engineered, under-implemented promise - which fails to deliver the second you push it past the IRC stage.
Btw - I’ve run IRC servers for 20+ years with less total lifetime maintenance than a Matrix home-server has in a single year. Just so many things breaking.
what server are you actually using? the admin portal you’re looking for is https://github.com/element-hq/element-admin.
> Looks like matrix is in this niche now.
Matrix is almost as old now as XMPP was when Matrix first came out, and yet, after all those years and grandiose promises, and loads of venture capital, it doesn't strike me as approaching the problem in a better/sounder manner than the protocol it was set to replace (quite the opposite, actually, Matrix, the protocol and its implementations are worse on almost every metric).
Eh, I've used both a lot and matrix is kinda flailing from my perspective. At least for casual use. If you are a client of Element maybe the experience is better, but with their "next-gen" battery friendly client they've been working on for years, I can't even get notifications working through public unified push servers when using matrix.org. Meaning that just to get started using it I have to run my own matrix or up server.
i remember that too. XMPP is still alive and kicking, just a lot quieter these days. :)
I switched from Matrix back to XMPP, because it has a lower setup and operating cost. I would have loved to use IRC, but the XMPP client mobile support is a bit better
I don't think the server space needs any innovation, current servers are very good.
What we do need are clients that are palateable to the masses. Something on desktop with the polish of Conversations. That's what will really drive adoption from people. I think a big part of Matrix being so popular versus XMPP is that they had a stronger unified client set that looked modern was appealing to many people.
All the widely deployed XMPP servers support a great number of XEPs. The perceived fragmentation of the XMPP ecosystem is mostly a client problem.
So true. The existing clients are actually the only reason I haven't asked all my friends to join my server. Only the ones who will put up with jank.
Gajim is _okay_ on desktop, but it leaves a LOT to be desired. Everything else feels way too bare-bones to feel comfortable recommending to Discord expats. Fluux Messenger is the closest I've seen, but it's sluggish for me. Maybe that's just Tauri on Linux.
Conversations is good on Android (bit barebones feeling), and I haven't tried out voice with it. IDK what the situation is in the Apple ecosystem.
I really, really wish I had the time to just start building a strong suite of XMPP clients. Every day Discord shoves a new ad in my face I get closer to biting the bullet.
I use Dino on the desktop and the experience has been almost as good as Conversations on mobile. For what it's worth.
Check out Tuwunel too https://github.com/matrix-construct/tuwunel for a Matrix implementation in Rust
I'm a big fan of Tuwunel. Run Synapse myself since I've had a server running for about 7 years now, but if I had to start over, Tuwunel all the way.
There's also Continuwuity, which I think is more popular, but I don't fully understand the difference. I think it's a community split issue? As someone who maintains a client, Tuwunel seems to match the spec better, but I'm sure folks have better reasons to pick one over the other.
I saw some coding harness (OMP i think?) labeling sub-agent comms as "IRC" for the agents to use. XMPP is another one I bet AI would just understand what to use it for. I have been absorbing whether tried-and-true old tech like these are going to revive in the AI era, just because it's "locked in" in the training data. AI is going to keep some of these torches burning forever maybe.
I'm keeping an eye on Iroh https://www.iroh.computer/
> ...I have been absorbing whether tried-and-true old tech like these are going to revive in the AI era, just because it's "locked in" in the training data. AI is going to keep some of these torches burning forever maybe.
I agree with you 100%! With so much open source software and know-how material that has been available for AI to train on, it seems inevitable that such tools will be used that much more often...and then as the AI trains on newer content, it will continue a virtuous cycle of open source software that will keep being used, and further improved...and as you stated "burning forever".
Don't really get the hype over Rust... I, personally, like C more. It would be much more smarter to make another server on simple and clean C, rather than using a language that already has a big toolchain and also compiles longer.
Considering that LLMs more often than not forget stuff when writing code, I definitely prefer Rust's automatic memory management system compared to balancing mallocs and frees throughout the code.
You could do RAII in C++, but the compiler won't warn on unsafe code.
C is a loaded gun pointed at your foot regarding memory management. Rust directs your gun somewhere safer. That is why.
This vibe coded slop is driving me nuts!
Any elaboration on the name?
Nice work ortuman!!
author here! thanks for the interest. :)
if anyone has questions about the motivation behind building this, feel free to ask.