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.
> 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.
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.
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.
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.
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 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).
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
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 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.
Check out Tuwunel too https://github.com/matrix-construct/tuwunel for a Matrix implementation in Rust
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.
> 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.
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.
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.
Do you not use AI for coding?
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.
I use Dino on the desktop and the experience has been almost as good as Conversations on mobile. For what it's worth.
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)
> 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).
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
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 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".
I'm keeping an eye on Iroh https://www.iroh.computer/
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.
Nice work ortuman!!
author here! thanks for the interest. :)
if anyone has questions about the motivation behind building this, feel free to ask.