I've been running Ergo for the past year for my friends/family chat. I went this route because of the ease of hosting, very low resource requirements and a protocol and codebase that I feel I can understand and debug if needed.
The v3 chathistory support and the always-on[1] multi-client[2] features paired with modern clients (like Goguma) go a long way at providing a modern chat environment. Most others on the server don't even know that they are using IRC.
The built-in websocket support is another key feature for me since it lets me to provide a web client just by serving some static files (I use Gamja for this).
Just think of all that information, stuck in the walled garden, away from the prying eyes of search engines or any other forms of public discoverability. Just waiting to get flushed down the drain or shoved into the training data of a future round of AI crapware...
IRC is pretty much the opposite of the definition of a walled garden. Its content is not discoverable by search engines by default, but that is not the definition of a walled garden, which is typically a synonym for closed platforms where you have no choice how to access their content (e.g. being forced to use a specific client software).
Many years ago at $WORK we had an in house IRC server (pre-Slack). It was well archived and logs were easily searchable. It was a pretty easy setup.
And for IRC, I think this is a good compromise between "everything is public at all times" and "everything is walled off and private at all times".
If you want to have a log of your use, it's possible. If the org running the server wants a log, they can do that too. Is that possible with something like Discord?
The point still stands. Regardless of how easy it might be to access logs, not a single popular Freenode (or otherwise) server I spent years chatting on has an archive online.
It might as well have all taken place on Discord.
Turns out what matters isn’t how easy it is to access logs but whether anyone cares to do it.
I’m not exactly sure why you think that matters. Everyone in those channels have logs that any program can read.
The point that I am making is that the capability and software exists, even for others to view, if you want. I mean: did you need an account or specialised client for these logs?
Thats the point.
Be the change you want to see if you want archives uploaded. Or, do what others do: grep your local files or znc logs.
Being knowingly throwaway meant that any long term knowledge got turned into a blog post, documentation, a forum thread, or a search engine indexable logs-to-html site in the worst case.
With discord the message might get pinned if a mod thinks it was useful and remains undiscoverable for the majority of people
> remains undiscoverable for the majority of people
IME it doesn't work very well. If you hang around a discord server long enough you see the same conversations happening over and over and over. And the app is not good at helping you finding old conversations (which is why they are repeated endlessly).
It's also very bad at resuming where you left off, so it's incredibly difficult to follow an active thread without missing anything:
Lots of people log channels, and that is another discussion when you see yourself online. They usually mention it in the topic though that the channel is logged.
For me, a "walled garden" is also something controlled and regulated by a party I have no influence over. They can arbitrarily make and change rules and decide who to let in or not, which feature to drop, how the UX looks like etc.
IRC is an open, community protocol, and as such not a walled garden. Even if I'm not involved, which I could be, I trust the composition of people there much more than any single commercial actor. The power dynamics are fundamentally different.
A single instance (an IRC network) may be a "walled garden", in control of the group that runs it. The incentives are different. Also because people can simply migrate to another network given the open protocol (and different, third party clients; the API cannot be shut down like with Twitter/X). Historical example e.g. Freenode ownership change.
It's not a website a search engine can crawl but anyone on the internet can log all the messages on IRC as long as they want without any restrictions. In fact if you are nice, you will never need to login and can have conversation for as long as you want with a guest login. It is not a walled garden.
A walled garden is a platform where auth is required to come in and user content is owned and stuck within.
IRC is not a walled garden. You will have a better time registering with Nickserv, but you can pull content and logs channels. So, more like a fenced meadow.
You must have a truly mind-boggling amount of social capital to be able to switch your family/friends off of a mega platform like Discord or WhatsApp. Do you just onboard every single person who wants to talk to any of them also? Or do they see your system as "how to reach donio"
You'd be surprised how easy it is to move a group chat to a new platform. Often you'll need to run a couple through, but people expect to be on multiple platforms.
Nobody is on a single messaging platform these days they also use other stuff of course. They look at it as a simple way to reach this group of people.
I'm in the process of switching over from ngircd to ergo and have contributed a FreeBSD initscript to ergo.
My little IRC community has been going on for what must be more than 15 years now.
There has been a noticeable slowdown this year. Maybe it will be the end of the line in a few years.
Nice to hear that at least there are others out there.
I have vivid memories of the first time I connected my Nokia to a laptop and used mobile dialup-internet from the passenger seat of a car to connect to the IRC server while going down the Autobahn.
Mobile internet was unheard of at the time, so it was totally exciting!
The last line of OP:
"The built-in websocket support is another key feature for me since it lets me to provide a web client just by serving some static files (I use Gamja for this)."
My fam chat is currently on Telegram, but there recently (Durov's arrest) was a long discussion about that; everyone is actually interested in switching to something E2EE and/or self-hosted. But we want to keep the core features: share photos/videos, keep a history, 1-on-1 voice/video calls, etc. So the main alternatives are WhatsApp, and (distant second) Signal - the latter doesn't offer history for newly joining devices.
If self-hosting in general wasn't such a PITA, I'd probably research the options and set something up. But honestly, I'm burnt out with trying to maintain even the most basic setups. I have a Raspberry Pi with NixOS under my desk that hosts Miniflux over Tailscale, and I can forget it exists 99.7% of the time - until I accidentally unplug it, and 6 hours later, wonder wtf happened again.
Now multiply the problem by the average funny cat video size and crappiness of my residential uplink. Won't happen.
This is not a feature, this is a limitation. It would've been a feature if Signal offered you a choice of whether the history should be synced up or not (perhaps with a default of "no" for existing users, to maintain the established expectation). As it is, this is a limitation.
In order for Signal to provide this history, said history would have to be stored on their servers, massively nerfing one of their core competitive advantages.
This “limitation” is the ultimate advantage from the perspective of Signal’s core competency.
It could be saved on devices and supplied as needed from that device history. They wouldn’t need to keep it on their servers. I don’t think you can fault signal for not wanting to do that, but it also means signal is a terrible communications platform if you want that sort of thing.
> It could be saved on devices and supplied as needed from that device history.
Then what if a new person joined the group convo? Do they have a right to see everything that everyone has said in that group convo, right back to the beginning? What if someone objects to sharing past conversations? What if sharing past conversations is a legitimate security concern to the group?
How does one filter out those past statements by someone who doesn’t want to share past statements? With security-state and foreign-state moles being a rather big issue in some groups, this is a legitimate rabbit’s hole that needs addressing. Some companies that standardize on Signal may not want any prior convos to become available to new entrants.
Personally, I see the lack of history to be a very real competitive advantage, and not any sort of a nerf.
Sure, your own history can be shared between installs on devices that you yourself own. But that is your chat history, meant for only you.
Does Signal, in fact, enjoy any competitive advantages?
Where I live (Canada) only a single person I know uses Signal. Everyone else is on Whatsapp and/or iMessage. As far as I am concerned, Signal is a wasteland.
I have received 400% more spam on Signal than I have received real messages.
Probably that they don't bother to have another chat app just for a few people.
A older family member has WhatsUp and Signal and gets sometimes confused. I have WhatsUp, signal, telegram, discord, meta messenger and would be .. hesitant to install an IRC client for like 3 people.
The reason that most people don't want another chat app is not just because of the initial work. Every chat app adds a mental overhead for some activities.
Want to find that recipe that you remember that some person shared with you a while back? Now you have to look through four different apps.
And the overhead grows quite fast as you add apps.
Yes. People install a handful of known apps and that's it. You would never convince any of my friends or family to install this. In fact, I wouldn't either.
Although I understand your point, and certainly have some friends that would feel like they're hacking the gibson connecting to an irc server, is Discord et. al really that much different?
It’s an inertia issue. I already have iMessage, FB Messenger, WhatsApp, and Signal as “primary” messaging apps, plus Instagram and LinkedIn and Teams as secondary— my tolerance would be basically zero for installing something else to connect with a specific person or friend group.
That is because you already have an absurd lots of them though.
I have whatsapp and conversations and that's it. I only use teams on my professional computer, you will never see me install "work" on my personal smartphone and nobody needs a linkedin app, the website is enough.
iMessage is needed for texting, Messenger for neighbours and FB Marketplace, WhatsApp for group chats, and Signal to have a non-meta option.
I agree about LinkedIn and will probably get rid of it; I mostly installed it as I was going to a conference and wanted the easy option for swapping contact details using camera codes.
Yes, they just download the app and enter the server name, username and pw. It's a private server and I manage the accounts so there is no registration step. And they only need to worry about any of this when they get a new phone.
I disagree. I run all comms for https://pico.sh through IRC on libera and people really struggle to onboard into IRC. People will pop-in ask a question, then leave because they arrive to a chat that is empty and didnt see any activity in 5mins and bounce.
We tried to offer a bouncer instance for users and even that had a barrier to entry because it requires creating 2 accounts: one for libera and one for pico.
I think about us switching to ergo every few months because I think the onboarding experience will be much nicer.
Logging into a channel for the first time and see the chat log will make people a lot more motivated to stay.
I agree. The reason IRC is so good is that it is mostly stateless and stores very little information beyond lists of IPs associated with each socket it's stuffing messages into.
Once a server starts hosting for people there are a huge set of problems and pressures. IRC is the text chat layer of the internet. It's not by itself, it's part of a larger network of open protocols. If you avail yourself to these it far exceeds the capabilities of even the most featureful walled corporate garden.
I didn't bother setting up proper push notification so we use the "Servers supporting chathistory" mode. This means that when the app is not in the foreground a workmanager task polls every few minutes. So in this mode notifications can be delayed by a few minutes which is fine for our use case.
IRC is often romanticized, but after working with its protocol spec, I found it rather unsavory. Its unstructured message format looks like this:
:User1 PRIVMSG User2 :Hello, are you receiving this message?
While this might look fine at first glance, the lack of more regular structure caused issues. Some messages are easier to parse than others. Each implementation introduced quirks and variations, creating countless edge cases and hairy parsing code. To be fair, IRC _was_ a product of its time... but s-expressions were invented in the 1950s, so adding more structure and rigor to the messages wasn't out of reach.
My memories are from a long time ago so I may be overreacting... perhaps the Ergo authors can comment on their experiences if they are around here! I heard about IRCv3 but I doubt that effort solved most of my main gripes with the protocol.
If I were to work on a messaging app today, I'd look elsewhere for inspiration. From a quick search, it seems there's room for a modern and _simple_ protocol for chat, simpler than XMPP or Matrix. Essentially, we need a protocol that is for messaging what Gemini is for HTTP. Stretch: squinting a bit, the NATS client protocol looks close to a starting point for something like that [1].
Matrix was invented because XMPP was getting too complex.
Are we once again at a point where it's time to start over?
A federated asynchronous group chat protocol with modern e2e encryption for desktop and mobile use (thus, not always online) is impossible to build without a faire share of complicated corner cases.
I guess I did not make the scope of the project clear. Both Matrix and XMPP specs add up to 100s of pages, 500 or so give or take. IRCv3 seems to be over 100 pages too. In comparison, Gemini is about 10 pages long or so.
A bunch of people here talk about setting up a small server for family and friends, so I think a smaller protocol, akin to Gemini in size, could be a lot of fun to work with for small scale deployments.
The protocol isn't really an issue for the use-case you talk about. I founded the Snikket project, which aims squarely at the family-and-friends use case you mention (after all, it was made to scratch my own itch - my family's excessive use of WhatsApp for communicating with each other). I can tell you that my family don't care a bit whether Snikket uses IRC, XMPP or Matrix or some real-time Gemini equivalent.
There may be some scalability differences between different protocols/implementations for the admin of the service, but Snikket fits comfortably on even low-end Raspberry Pi devices, and literally over half of the typical resource usage is by the web dashboard (yay Python).
So what difference does the protocol make? It can make a difference to the developer experience. If all you want to do is exchange text messages, then yeah, XMPP and Matrix are absolutely overkill. But - especially for a family-and-friends use case - people also want file sharing, audio/video calls, and all that stuff. It very quickly gets quite complex to support all this stuff, especially in a way that allows you to evolve the protocol over time (trust me, what you think of as core messaging features today, were not a thing 10+ years ago, and messaging in 10+ years will also involve a new set of features).
There will always be a set of users for whom plain text messaging is enough (90% of my own daily communication is via messaging in a terminal app). However that set does not intersect significantly with the general population, and practically none of my family members would accept such a solution as a replacement for WhatsApp.
Hey, your project looks interesting, thanks for building and sharing it.
One question: are you aware of Jami[1], f.k.a. Ring? If so, how does it compare to Snikket?
I see that Snikket requires a server, whereas Jami is P2P. The benefit of a server is probably that messages can be stored centrally and not on each device. But I can see pros and cons of either approach.
Hey, thanks! I've been into messaging for quite a long time - network protocols and particularly those involving online communication are among my favourite tech topics :) So yeah, I follow various projects.
You're right that there are pros and cons. Obviously, not having to run a server is a big pro for many. However, the first thing to remember when researching messaging solutions - no matter what anyone tells you - there are always servers! What differs between projects/platforms is what the servers do, and who runs them.
Jami uses a network of public servers that form a distributed hash table (see https://github.com/savoirfairelinux/opendht ). It's a neat design, and they have done a good job tackling the challenges of P2P messaging. Last time I looked in, it still required both users to be connected at the same time for message delivery/sync to work (the devices use the DHT to discover each other, and then exchange messages). This is a fairly common issue for P2P systems, and can be frustrating in a mobile-dominated world. Their DHT software does support push notifications, which helps with that though.
With Snikket, instead of using existing publicly shared infrastructure, you just run your own server (e.g. VPS or Raspberry Pi or whatever) which is responsible just for your users, and your users connect directly to it, improving (meta)data locality. This makes the design very simple, reliable and efficient (e.g. with battery/bandwidth). It also enables some important (for our use case) convenience/UX features, such as the ability to add restrictions on certain accounts (e.g. for children), and server-managed contact lists so all your family members don't have to manually add each other as contacts one-by-one. Things like that.
No approach is universally better than every other, but I much prefer the Snikket model for the family-and-friends use case. Not that we don't have our own challenges. Our iOS app is probably the weakest part right now (in terms of UX and general polish). Something I'm working hard to get fixed in 2025.
Yeah, there are definite challenges of the P2P architecture. But like you say, Jami seems to have done a good job addressing them.
I looked at Briar, but it has a different focus and is more limited in functionality and less polished than Jami. My use case is text messaging and audio/video calls with a close group of contacts, so Jami and your project look like a better fit. I also considered Matrix/Element/FluffyChat, but the Matrix architecture is confusing, and the clients are underwhelming.
Anyway, good luck with Snikket! If Jami doesn't work out for me, I'll definitely give it a try.
Well, all the XEPs add up to 100s of pages, but the minimal requirements for basic chat are pretty small. It gets more complex as you add more features, but importantly the complexity is managed well. You don't have to do the crazy fragile hacks that IRC needs, because XMPP was designed expressly as an extensible protocol.
> Are we once again at a point where it's time to start over?
Ask Sisyphus.
In the meantime, while everything else keeps going through newer iterations of XKCD 927 (https://xkcd.com/927/), IRC keeps chugging along, and gaining new features and functionality as it enters its fourth decade despite the previous commenter's gripes.
To me, it's slowly become obvious that Matrix was invented because certain people wanted to ride the trendy wave of VC money propping up Slack and friends back in those days.
Matrix has been all about superlative marketing and over-promises with little substance and theoretical underpinnings to back it up.
The fact that they were spreading FUD and disinformation against XMPP and the alternatives in their early days should have been a red herring. The fact that they haven't stabilized their protocol and made it scalable to mid-level deployments after more than a decade should be a reason for pause. The fact that after so long, due to the sheer complexity of it, only one entity has emerged as willing to sink the costs of Matrix should be a reason for worries.
I think that we are due for an XMPP resurgence. Not that it is perfect by any stretch of mind, but it is no-BS, mature, lightweight on resources and bandwidth and verifiably fit for purpose, whether you want to host small-scale for your family & friends, or for the whole world with the ambition to be the next GTalk, facebook messenger, or whatsapp (all of them XMPP services at one point or another of their histories)
If folks are interested seeing the companies currently sinking $ into Matrix by routing $ to the Matrix Foundation, you can see them at https://matrix.org/support. Thankfully it’s not just Element these days, but companies like Thales and Huawei too. That said, there’s still a $ gap in funding.
I do regret saying that XMPP had fallen behind, 10 years ago, when we launched Matrix, though - not least because 10 years later folks are still bringing it up ;)
> Meanwhile Matrix 2.0 is a genuine pleasure to use
"trust us it's good this time" → (still the very same at its core) → "you are right, we are sorry, but bear with us, <buzzword> is just about to be ready!" → (buzzword is abandoned/releases but doesn't improve things in a meaningful way) → "trust is it's good this time" → …
Matrix 2.0 on the server is all about "sliding sync", which, once you read through the buzzword, is about running the client on the server so it sucks less at fetching history. Even that works super randomly, if it works at all, even on EMS-hosted instances. The rest is the same. On the client-side, Element X is not daily-drivable because of the bugs and missing essential features. Nothing has improved in a year on that front, which is reminiscent of dendrite: dropping it for the sake of salvaging the original hack would surprise nobody at this point.
> I do regret saying that XMPP had fallen behind, 10 years ago
By no means am I saying that XMPP was great 10 years ago (what was back then, really?), but that's a very poor rationale for torpedoing another project by spreading lies about it on your FAQ, especially when that project was working on the problems and eventually came to address them, across a whole ecosystem of clients and server, while Matrix to this day is still poking at the beast wondering how to tame its single-vendor/single-client/single-server complexity.
I guess the question is whether it’s better to spread objectively and demonstrably false info today (as you are with the completely bogus Matrix 2.0 critique), versus me putting subjective info into a FAQ 10 years ago ;)
It might be worth considering that whining about Matrix is misdirected anger - it may be better off pointed at the proprietary centralised surveillance capitalism alternatives rather than us…
> I guess the question is whether it’s better to spread objectively and demonstrably false info today (as you are with the completely bogus Matrix 2.0 critique), versus me putting subjective info into a FAQ 10 years ago ;)
Outright denying people's bad experience with Matrix has also been a sad part in Matrix marketing for so long. Unfortunately, I don't have experience with Element X, since my provider doesn't support it yet, so I can't confirm or deny that testimonial, but my exceptations are not high.
> It might be worth considering that whining about Matrix is misdirected anger - it may be better off pointed at the proprietary centralised surveillance capitalism alternatives rather than us…
It's not either or. People are frustrated on the other hand because of the annoying proprietary platforms, but also because there are currently no alternatives to them that one could whole-heartedly recommend as a replacement.
> Outright denying people's bad experience with Matrix has also been a sad part in Matrix marketing for so long
I think if you look at my comments on HN you'll see me spending most of my time trying to explain or apologise for people's bad experience, but ymmv.
> Unfortunately, I don't have experience with Element X, since my provider doesn't support it yet, so I can't confirm or deny that testimonial, but my exceptations are not high.
> Matrix has been all about superlative marketing and over-promises with little substance and theoretical underpinnings to back it up.
I don't think so. The underpinnings were there, may it be the concepts for E2EE, P2P, Verification, Bridging, decentralized rooms and conferencing, synchronized history, etc. Not everything is production ready let alone finished with perfect UX, but it doesn't lack theoretical underpinnings.
> The fact that they were spreading FUD and disinformation against XMPP
In the past, I have experienced it more often vice versa than this way.
> The fact that they haven't stabilized their protocol and made it scalable to mid-level deployments after more than a decade should be a reason for pause.
There are already pretty large deployments (1+ million users), so I think it's scalable to mid-level deployments.
> only one entity has emerged as willing to sink the costs of Matrix should be a reason for worries.
idk what you mean
> all of them XMPP services at one point or another of their histories
> I don't think so. The underpinnings were there, may it be the concepts for E2EE, P2P, Verification, Bridging, decentralized rooms and conferencing, synchronized history, etc. Not everything is production ready let alone finished with perfect UX, but it doesn't lack theoretical underpinnings.
Let me cut it short: either you think that there's nothing to be said about the current state resolution machinery, and that's an admission that Matrix will never reach its stated goal to become a mainstream decentralized network (because federation at scale just doesn't work with the current status-quo), or you agree with me that something needs to be done (but, like me, could turn impatient that nothing materializes after a decade).
>> The fact that they were spreading FUD and disinformation against XMPP
> In the past, I have experienced it more often vice versa than this way.
I am not challenging your experience, I am talking about what was effectively written about XMPP on the Matrix website. If this was reciprocal as you say, I'd like to be shown where and in which terms XMPP has engaged in disinformation campaigns against Matrix. At least, with the xmpp.org website's history being on github, it should be very easy: https://github.com/search?q=repo%3Axsf%2Fxmpp.org%20matrix&t...
>> all of them XMPP services at one point or another of their histories
> histories is an important keyword
If by that you mean that WhatsApp, the single largest chat network to have ever existed, is history, I've got news for you. While we may regret that federation never was a thing with this network, talking about underpinnings, they are still very much versed in XMPP. And that's not an exception. All Android devices depend on XMPP for push notifications, so do every Nintendo switch, and millions of access points, networking and IoT devices. XMPP is all but dead.
IRC is a Very Old Protocol, you're right. if you dig through the spec you will find a few historic relics: 7-bit ASCII only, 254 character max total line length (some reserved for the message itself), and many many more.
NATS as an IRC replacement is using the wrong tool for the wrong job.
I've long been thinking about how I'd replace IRC and I keep coming back to another IRC-era protocol that wasn't as popular but was definitely ahead of its time by some amount: Hotline. It wasn't Open like IRC and was limited to Macintosh users for a long time, but it has a lot of what most people are looking for in a "chat system" today. One thing, however, that I think would benefit the protocol designers of the future: Learn from MSN.
MSN separated their Authentication and Chat systems. You ask for a token that identifies you to the chat system from the authentication system. These were two separated protocols that did one thing specifically for each other. I honestly think that separating chat-locus and identity from one another is important.
Perhaps I'm just a bit dim but I don't really understand the problem here. If that had commas and { ... } around itself no one would give a second thought. But you also mention s-expressions, and there you dont even have to add the commas!
Something a little more tightened up might be nice, because who likes scanning for line endings, when you could have a byte count, and what's up with the colons, and while you're there, might as well have a single byte command, right? But preferably without having seven layers of byte counts, like TLS.
But from my recollection of writing bad IRC client in the 90s (including in mIRC script after they added support for sockets in the scripting language in mIRC v5.3 released December 1997), the protocol isn't that hard to work with. Once you figured out you needed to send a : in front of your message text, I don't remember any other big gotchas.
It's not XML, and I don't remember any quoting issues, but maybe there's some I forgot. CTCP maybe isn't ideal either. DCC probably doesn't work anymore, but it was a different time when being on the internet meant an expectation that you were a peer and could accept inbound connections.
> including in mIRC script after they added support for sockets in the scripting language in mIRC v5.3 released December 1997
You could write your own servers and services too :). My mIRC scripts all had s:lines on my network, all running in my mIRC (NoNameScript) environment, which I'm sure were on Hawkee somewhere.
Without unconditionally endorsing the content of this blog (especially the more recent parts of it) you may find this post interesting: http://www.loper-os.org/?p=4003
Meh, a binary protocol would've been more efficient in every way, I don't think they really prioritized efficiency. It would've also been simpler for implementers, but there was a time when people thought text-based protocols were good for some reason. They're usually not, and getting the supposed "benefit" of the protocol being human-readable at a glance is trivial to do by just having a code path that turns the binary one into a human-readable one, in whatever shape you want, so you don't have to make your base protocol shitty just because you want human-readability.
Complaining about IRC in 2024 is bleh, by the way. The protocol is what it is, you've had a long time to get over it and if you were late to the party you need to realize that yes, there are tons of old protocols that are pretty badly designed, welcome to the world. IRC as a way of public chatting (and maybe even more so running a closed chat) is still somehow among the best we have and personally I'd prefer it if Slack, Microsoft Teams and Discord died completely for "Hey, we've set up a place to talk about this work/event/hobby thing!".
It feels really nice to see stuff like this while the most of the people think Slack, Discord and a few others are the only choices.
I recently went through the hassle of deciding on something small for my family + company circle. Mainly considered XMPP and Matrix, and went with Matrix. Didn't know there was such a thing as "always-on" on IRC tho.
> Didn't know there was such a thing as "always-on" on IRC tho.
It's a server feature and might be unique to Ergo. It's a per-user setting (with a global default) and when it's on the user always appears to be online so you can type at them any time like you would with other DM systems. The v3 chathistory support ensures that they don't miss messages. For clients that don't support chathistory the server can replay any unseen messages.
It's a lot like what bouncers provide but integrated and very easy to enable for everybody so no extra steps required for my users.
Have you had any issue with messages/notifications not be sent/received with Matrix? I wanted to try Matrix for friends and family, but either I would never get the message until I opened the app, or I'd get the notification but my phone wouldn't vibrate. Eventually settled on XMPP with Conversations on Android.
Not really, I didn't have any delivery-related issues, and didn't get any complaints from other people as well. I have mixed feelings towards Matrix due to;
1. The only stable and maintained implementation is "matrix-synapse" and it is written in Python.
2. The most commonly used client is "element", and it is governed by the same people. So it feels we are the mercy of a single company.
I wanted hard to go with a more established protocol like XMPP but failed to get a server running properly :)
Not sure if you tried prosody[0], but I found it rather powerful and simple to configure, including multiuser chat(muc) and peering. It's written in lua and has a module system so it's easy to extend. In particular I used the dovecot auth module[1] so users could login with their email credentials and I could manage a single user repo.
Yep, Prosody was one of my failed attempts :P I am running everything on a kubernetes cluster, so a maintained helm chart is the first thing I check when running something. I didn't have much luck with XMPP servers with this.
That IMAP auth trick is really awesome thinking BTW, kudos!
Ah interesting, I haven't tried running it on k8s yet. Migrating my mail stack over to k8s has been on my todo list for a little while; should probably get around to it since dovecot and postfix have supported inet sockets for user/domain db and auth for ~12 years now.
Dovecot is really great, and a ton of stuff supports using it as a sasl auth backend (postfix being an important one). I made a simple facade service that feeds it and postfix from couchdb via its dict backend[0] and postfix's tcp_tables[1], then point everything at dovecot for auth. Couch document IDs map really well to email/user, domain, and sieve script lookups; helluva lot simpler than setting up and managing LDAP.
I've been running XMPP/ejabberd for a decade, it's a single service embarking everything you need, including what it takes to do A/V calls (NAT traversal & al.). Nonetheless, it's also the quietest and lowest-profile piece of server software I've ever used. I don't need a container for that, but if you want, there's an official docker image for it. Without going to host millions of concurrent users and needing to distribute the service across multiple physical servers via clustering, I don't see what good an "helm chart" does for you, but then you do you.
Ive been running matrix for small company/group for almost 10years. No need to use Synapse as there are many other solid servers (and have been for years). Matrix (the company) software like Synapse and Denderite (their “performant” server in go) are aimed at mega servers that federate and the features revolve around that.
If you want to selfhost just make it easy and get Conduit. Its single binary and uses embedded db (rocksdb or sqlite). I cant say about federation but for private chat server this has been solid for me for years. I still run it with sqlite (worse than rocksdb) and with 30 very active people its more responsive than Synapse ever was.
What clients do you use to connect to it? I just setup a Conduit server and can connect from my Mac via https://app.element.io as well as the official MacOS app, but the iPhone apps cannot find it somehow. Does that work for you too?
I think the answer is no, but can Ergo connect to other IRC servers? I'd like to set it up linked with my existing ngircd, for my users to try out, and then if it goes well shut down ngircd, which is a pattern I've used before when migrating between servers.
Here [1] is a table that has IRCv3 features by platform and then view each platforms web site to see all the standard features they support outside of IRCv3. FWIW one of the most popular by market share is UnrealIRCD [2].
Look under the hood sometime and witness the lovecraftian horror. You can enable the electron dev console via env var. Everything from how they layout the page, to the underlying structure for messages and threads (and how they are accessed) is super complex.
Maybe, but is there a particular reason you need to use a ~20-year-abandoned IRC client when there's literally dozens of actively-maintained ones for any platform you could reasonably think of?
Whenever IRC comes along, someone mentions its lack of chathistory/backlog as a missing feature. Having witnessed what Discord have wrought, I am now in the firm belief that backlog - at least for communities - is an anti-feature. Because the logs persists between sessions, people start to post things there for perpetuity, a task classically reserved for bulletin forums.
Without a server-side backlog, the chat is fleeting, and everyone knows that, so to preserve important content, people know to save it somewhere else. This keeps the chat as it was meant to; a live chat, mimicking that of a human conservation, where nothing is recorded until someone makes the conscientious effort to do so.
Fully agreed, but let's not forget the psychological quirk of Discord moderators loving to divide the world into neat little boxes, so the mark of any established server is the myriad of different topic channels.
Every single community has become a silo with their own memes channel. It's like they emulate modern social media websites where they try to keep you engaged and in one spot forever.
I find it dystopian and power-tripping personalities trying to invent rules upon rules on their little kingdom is really not conducive to spontaneous socialisation.
Now, sorry, you cannot contribute to this conversation because you haven't fully read the rules on #welcome, didn't complete the captcha from our bot and, worse of all, you have not chosen a role for yourself.
Unfortunately it's worse than that now. It used to be that everything got siloed into channels, now things get siloed into the new forum system.
These forum channels don't automatically appear in the sidebar and you get no indication of anything new added unless you specifically follow the thread.
Moving into forum threads is a great way to kill a conversation, perfect even, honestly I wouldn't be surprised if the feature was added just so Discord could appear in "forum" searches. There's no way the feature was planned when it's so bad for conversations.
In any case the discord mod quirk of stomping on discussion inertia plus this horrible new forum system guarantees a conversation fizzles out immediately.
I'd rather software chats not be on Discord, but that said I've found the forum feature quite helpful for help channels. You get auto-search for the topic as you type out a title, and if you don't see what you need, you can turn it straight into a topic. It's a lot better than the old system of posting into a rolling scroll and hoping one of the regulars is around, and that you're not asking a question which should be in the docs but isn't (and therefore gets asked an annoying amount of times).
It's quite possible the communities I'm active in are using the forums feature wrong if it works well for a QnA/helpdesk scenario haha
Thinking about it that use case makes far more sense than what the communities I'm in are using it for (basically just dynamic #channels that anyone can create) - especially with how nobody is a part of the discussion by default. That does make way more sense for a helpdesk kinda setup rather than misc discussion threads.
> personalities trying to invent rules upon rules on their little
kingdom is really not conducive to spontaneous socialisation
Seems like a neglected area of research in UX/UI - perhaps an
opportunity for a good PhD or Masters: To what extent do software
paradigms enable/inhibit pathological/virtuous personality traits?
And no - not all software is a "neutral" blank canvas. Behaviours
cluster around latent or implied structures. Designers imprint their
own values on code, perhaps even unconsciously.
People just started to build IRC bots for notes and reminders. Or used IRC proxies to keep history while offline. All just hacks and gatekeeping the history to people who are not that tech savvy.
I recognise someone may not have been introduced to what I meant by what Discord has wrought; specifically Discord channels (including forum channels) are not indexable by search engines, meaning posts with important details cannot be uncovered by an outsider. Classic bulletin forums are public, and so obscure technical details shared there could later be dug up by a curious soul. It's not too infrequent to see a blog shared on HN, with the author complaining about how hard it was to find some details, because they weren't a member of an obscure Discord server.
The irony of the persistent backlogs for Discord means that a lot of this information is practically lost. Archive.org cannot preserve copies, so if the Discord server is closed or whenever Discord itself decides to call it quits, it's all gone.
I've been running Ergo for the past year for my friends/family chat. I went this route because of the ease of hosting, very low resource requirements and a protocol and codebase that I feel I can understand and debug if needed.
The v3 chathistory support and the always-on[1] multi-client[2] features paired with modern clients (like Goguma) go a long way at providing a modern chat environment. Most others on the server don't even know that they are using IRC.
The built-in websocket support is another key feature for me since it lets me to provide a web client just by serving some static files (I use Gamja for this).
[1] always-on: https://github.com/ergochat/ergo/blob/master/docs/USERGUIDE....
[2] multiclient: https://github.com/ergochat/ergo/blob/master/docs/USERGUIDE....
As heavy Discord user, it's nice to see that IRC is still kicking and might be available if/when Discord ZIRP gas runs out.
Just think of all that information, stuck in the walled garden, away from the prying eyes of search engines or any other forms of public discoverability. Just waiting to get flushed down the drain or shoved into the training data of a future round of AI crapware...
I did not realize IRC chats were archived on search engines.
IRC is also a walled garden.
IRC is pretty much the opposite of the definition of a walled garden. Its content is not discoverable by search engines by default, but that is not the definition of a walled garden, which is typically a synonym for closed platforms where you have no choice how to access their content (e.g. being forced to use a specific client software).
But in general IRC is not really archived etc? So just as throw-away as Discord imo.
However on IRC this is not for technical reasons, but limited interest.
Pre-LLM-GenAI gathering information from huge chat logs was quite limited.
But different extraction mechanisms always existed. Some people kept logs, some servers/channels had web-archives.
Discord tries to keep it exclusive to them.
(Focussing on technical side here, whether it's socially wanted is a different big question, which ends with a "it depends")
That's nice for finding Keywords, but dismantling a chat discussion, which probably consists of many parallel threads in a channel, isn't easy.
Any single client can upload their logs, since it's "archived" in plaintext on every users PC.
You can also log from the server; using a multitude of modules; https://docs.inspircd.org/4/modules/log_syslog/ or https://docs.inspircd.org/4/modules/log_json/ if you're using inspircd.
Many years ago at $WORK we had an in house IRC server (pre-Slack). It was well archived and logs were easily searchable. It was a pretty easy setup.
And for IRC, I think this is a good compromise between "everything is public at all times" and "everything is walled off and private at all times".
If you want to have a log of your use, it's possible. If the org running the server wants a log, they can do that too. Is that possible with something like Discord?
The point still stands. Regardless of how easy it might be to access logs, not a single popular Freenode (or otherwise) server I spent years chatting on has an archive online. It might as well have all taken place on Discord.
Turns out what matters isn’t how easy it is to access logs but whether anyone cares to do it.
You sure? There are loads. Have you tried looking?
Heres an archive searcher for #bitfighter on freenode: https://bitfighter.org/irclogs/search.php
That's the counter example?
A channel with one day logged in 2024, then nothing for two years, then nine days logged in 2022, five days logged in 2021, etc?
What about big tech channels like, say, nodejs and javascript?
I’m not exactly sure why you think that matters. Everyone in those channels have logs that any program can read.
The point that I am making is that the capability and software exists, even for others to view, if you want. I mean: did you need an account or specialised client for these logs?
Thats the point.
Be the change you want to see if you want archives uploaded. Or, do what others do: grep your local files or znc logs.
[dead]
Being knowingly throwaway meant that any long term knowledge got turned into a blog post, documentation, a forum thread, or a search engine indexable logs-to-html site in the worst case.
With discord the message might get pinned if a mod thinks it was useful and remains undiscoverable for the majority of people
> remains undiscoverable for the majority of people
IME it doesn't work very well. If you hang around a discord server long enough you see the same conversations happening over and over and over. And the app is not good at helping you finding old conversations (which is why they are repeated endlessly).
It's also very bad at resuming where you left off, so it's incredibly difficult to follow an active thread without missing anything:
https://www.reddit.com/r/discordapp/comments/18d4tiv/inexpli...
Lots of people log channels, and that is another discussion when you see yourself online. They usually mention it in the topic though that the channel is logged.
[dead]
This is notably not the definition from the thread you’re responding to, though.
So…
[dead]
Hm, for me the definition of the walled garden is "you have to have an account to see any discussions"
Which you don’t need for irc. Also pretty sure that’s not an accurate definition as you can be walked without needing an account technically.
For me, a "walled garden" is also something controlled and regulated by a party I have no influence over. They can arbitrarily make and change rules and decide who to let in or not, which feature to drop, how the UX looks like etc.
IRC is an open, community protocol, and as such not a walled garden. Even if I'm not involved, which I could be, I trust the composition of people there much more than any single commercial actor. The power dynamics are fundamentally different.
A single instance (an IRC network) may be a "walled garden", in control of the group that runs it. The incentives are different. Also because people can simply migrate to another network given the open protocol (and different, third party clients; the API cannot be shut down like with Twitter/X). Historical example e.g. Freenode ownership change.
It's not a website a search engine can crawl but anyone on the internet can log all the messages on IRC as long as they want without any restrictions. In fact if you are nice, you will never need to login and can have conversation for as long as you want with a guest login. It is not a walled garden.
Search engines could crawl it if they wanted to.
IRC is not "walled off" - open protocol, open servers, open clients.
A walled garden is a platform where auth is required to come in and user content is owned and stuck within.
IRC is not a walled garden. You will have a better time registering with Nickserv, but you can pull content and logs channels. So, more like a fenced meadow.
explain ur definition of walled garden please
And if it's not, or you need something more secure, there's always Matrix.
https://matrix.org
Ehhhh, Not a fan of Matrix but I haven't investigated it a ton. What I'm looking for probably doesn't exist.
Central Login Server hosted by Foundation of Chat Program and servers authenticate via OAuth2.
Central Login Server keeps track of which Servers identity is in and their endpoints so people don't lose track of servers.
Central Mobile Notification Service because mobile app notification is so important AND SO PAINFUL TO RUN.
Federation NOT required.
fwiw Matrix does do this, although making the OIDC IdP track the right target homeserver might need a bit of config.
You must have a truly mind-boggling amount of social capital to be able to switch your family/friends off of a mega platform like Discord or WhatsApp. Do you just onboard every single person who wants to talk to any of them also? Or do they see your system as "how to reach donio"
You'd be surprised how easy it is to move a group chat to a new platform. Often you'll need to run a couple through, but people expect to be on multiple platforms.
Nobody is on a single messaging platform these days they also use other stuff of course. They look at it as a simple way to reach this group of people.
I'm in the process of switching over from ngircd to ergo and have contributed a FreeBSD initscript to ergo.
My little IRC community has been going on for what must be more than 15 years now. There has been a noticeable slowdown this year. Maybe it will be the end of the line in a few years.
Nice to hear that at least there are others out there. I have vivid memories of the first time I connected my Nokia to a laptop and used mobile dialup-internet from the passenger seat of a car to connect to the IRC server while going down the Autobahn. Mobile internet was unheard of at the time, so it was totally exciting!
your family and friends care enough to download and set this up?
The last line of OP: "The built-in websocket support is another key feature for me since it lets me to provide a web client just by serving some static files (I use Gamja for this)."
https://github.com/Libera-Chat/gamja
https://codeberg.org/emersion/gamja is probably what you want, the repo above seems like a local branch and it's a few months behind.
My fam chat is currently on Telegram, but there recently (Durov's arrest) was a long discussion about that; everyone is actually interested in switching to something E2EE and/or self-hosted. But we want to keep the core features: share photos/videos, keep a history, 1-on-1 voice/video calls, etc. So the main alternatives are WhatsApp, and (distant second) Signal - the latter doesn't offer history for newly joining devices.
If self-hosting in general wasn't such a PITA, I'd probably research the options and set something up. But honestly, I'm burnt out with trying to maintain even the most basic setups. I have a Raspberry Pi with NixOS under my desk that hosts Miniflux over Tailscale, and I can forget it exists 99.7% of the time - until I accidentally unplug it, and 6 hours later, wonder wtf happened again.
Now multiply the problem by the average funny cat video size and crappiness of my residential uplink. Won't happen.
> Signal doesn't offer history for newly joining devices
This is a great feature for privacy though
This is not a feature, this is a limitation. It would've been a feature if Signal offered you a choice of whether the history should be synced up or not (perhaps with a default of "no" for existing users, to maintain the established expectation). As it is, this is a limitation.
In order for Signal to provide this history, said history would have to be stored on their servers, massively nerfing one of their core competitive advantages.
This “limitation” is the ultimate advantage from the perspective of Signal’s core competency.
It could be saved on devices and supplied as needed from that device history. They wouldn’t need to keep it on their servers. I don’t think you can fault signal for not wanting to do that, but it also means signal is a terrible communications platform if you want that sort of thing.
> It could be saved on devices and supplied as needed from that device history.
Then what if a new person joined the group convo? Do they have a right to see everything that everyone has said in that group convo, right back to the beginning? What if someone objects to sharing past conversations? What if sharing past conversations is a legitimate security concern to the group?
How does one filter out those past statements by someone who doesn’t want to share past statements? With security-state and foreign-state moles being a rather big issue in some groups, this is a legitimate rabbit’s hole that needs addressing. Some companies that standardize on Signal may not want any prior convos to become available to new entrants.
Personally, I see the lack of history to be a very real competitive advantage, and not any sort of a nerf.
Sure, your own history can be shared between installs on devices that you yourself own. But that is your chat history, meant for only you.
Exactly, matrix.org has this feature IIRC.
When you switch to a new phone, Signal can sync the history just fine.
When you add a new computer, Signal refuses to sync the history.
Does Signal, in fact, enjoy any competitive advantages?
Where I live (Canada) only a single person I know uses Signal. Everyone else is on Whatsapp and/or iMessage. As far as I am concerned, Signal is a wasteland.
I have received 400% more spam on Signal than I have received real messages.
Isn't it just: install app, enter myserver.net and username+password ?
yeah, this part itself. How easy it is to get them to do it?
Any app that requires a login will be exactly the same? What's exactly your point? That people can't login to phone apps?
> That people can't login to phone apps?
Probably that they don't bother to have another chat app just for a few people.
A older family member has WhatsUp and Signal and gets sometimes confused. I have WhatsUp, signal, telegram, discord, meta messenger and would be .. hesitant to install an IRC client for like 3 people.
Whatsapp wins because it doesn't require a username and password, that's too complex for many people
> wins because it doesn't require a username and password
And lose because you can't give it to a kid that doesn't have a mobile phone number.
I have shared custody of my daughter and we communicate via xmpp on a tablet they carry over there when they spend a week at their mother's.
True, but I mean wins in a global "it's now the default platform for most people in the world" sense.
The reason that most people don't want another chat app is not just because of the initial work. Every chat app adds a mental overhead for some activities.
Want to find that recipe that you remember that some person shared with you a while back? Now you have to look through four different apps.
And the overhead grows quite fast as you add apps.
Yes. People install a handful of known apps and that's it. You would never convince any of my friends or family to install this. In fact, I wouldn't either.
Your incredulous attitude is naive. Yes, people don’t want to have yet another increasingly niche chat app to communicate with just a few people.
yeah, people definitely don't want to switch to use another app to chat. Is that too hard to understand?
why would they need to download and setup a server? can't they just log in to OP's with the client of their choice?
i am asking about download the client and even registering and entering a password
Although I understand your point, and certainly have some friends that would feel like they're hacking the gibson connecting to an irc server, is Discord et. al really that much different?
It’s an inertia issue. I already have iMessage, FB Messenger, WhatsApp, and Signal as “primary” messaging apps, plus Instagram and LinkedIn and Teams as secondary— my tolerance would be basically zero for installing something else to connect with a specific person or friend group.
That is because you already have an absurd lots of them though.
I have whatsapp and conversations and that's it. I only use teams on my professional computer, you will never see me install "work" on my personal smartphone and nobody needs a linkedin app, the website is enough.
iMessage is needed for texting, Messenger for neighbours and FB Marketplace, WhatsApp for group chats, and Signal to have a non-meta option.
I agree about LinkedIn and will probably get rid of it; I mostly installed it as I was going to a conference and wanted the easy option for swapping contact details using camera codes.
discord is totally different. I assure you they are not going to download Signal, Whatsapp. there is massive network effect involved and inertia
Even getting people to use a different messaging app (such as Facebook Messenger) already installed on their phones is difficult.
Yes, they just download the app and enter the server name, username and pw. It's a private server and I manage the accounts so there is no registration step. And they only need to worry about any of this when they get a new phone.
>(like Goguma)(I use Gamja for this).
Is everything related to potatoes lol?
Yep, both are by the same author (emersion) and there is definitely a running theme in the project names.
I think ircd is the wrong layer to attach those features to.
You can run something like thelounge and have that on any server.
I disagree. I run all comms for https://pico.sh through IRC on libera and people really struggle to onboard into IRC. People will pop-in ask a question, then leave because they arrive to a chat that is empty and didnt see any activity in 5mins and bounce.
We tried to offer a bouncer instance for users and even that had a barrier to entry because it requires creating 2 accounts: one for libera and one for pico.
I think about us switching to ergo every few months because I think the onboarding experience will be much nicer.
Logging into a channel for the first time and see the chat log will make people a lot more motivated to stay.
I agree. The reason IRC is so good is that it is mostly stateless and stores very little information beyond lists of IPs associated with each socket it's stuffing messages into.
Once a server starts hosting for people there are a huge set of problems and pressures. IRC is the text chat layer of the internet. It's not by itself, it's part of a larger network of open protocols. If you avail yourself to these it far exceeds the capabilities of even the most featureful walled corporate garden.
Interesting, does push notification work? Will phones receive messages and notify while sleeping?
This explains the notification options with Goguma, the mobile client we use: https://codeberg.org/emersion/goguma/src/branch/master/doc/n...
I didn't bother setting up proper push notification so we use the "Servers supporting chathistory" mode. This means that when the app is not in the foreground a workmanager task polls every few minutes. So in this mode notifications can be delayed by a few minutes which is fine for our use case.
IRC is often romanticized, but after working with its protocol spec, I found it rather unsavory. Its unstructured message format looks like this:
While this might look fine at first glance, the lack of more regular structure caused issues. Some messages are easier to parse than others. Each implementation introduced quirks and variations, creating countless edge cases and hairy parsing code. To be fair, IRC _was_ a product of its time... but s-expressions were invented in the 1950s, so adding more structure and rigor to the messages wasn't out of reach.My memories are from a long time ago so I may be overreacting... perhaps the Ergo authors can comment on their experiences if they are around here! I heard about IRCv3 but I doubt that effort solved most of my main gripes with the protocol.
If I were to work on a messaging app today, I'd look elsewhere for inspiration. From a quick search, it seems there's room for a modern and _simple_ protocol for chat, simpler than XMPP or Matrix. Essentially, we need a protocol that is for messaging what Gemini is for HTTP. Stretch: squinting a bit, the NATS client protocol looks close to a starting point for something like that [1].
--
1: https://docs.nats.io/reference/reference-protocols/nats-prot...
Matrix was invented because XMPP was getting too complex.
Are we once again at a point where it's time to start over?
A federated asynchronous group chat protocol with modern e2e encryption for desktop and mobile use (thus, not always online) is impossible to build without a faire share of complicated corner cases.
I guess I did not make the scope of the project clear. Both Matrix and XMPP specs add up to 100s of pages, 500 or so give or take. IRCv3 seems to be over 100 pages too. In comparison, Gemini is about 10 pages long or so.
A bunch of people here talk about setting up a small server for family and friends, so I think a smaller protocol, akin to Gemini in size, could be a lot of fun to work with for small scale deployments.
The protocol isn't really an issue for the use-case you talk about. I founded the Snikket project, which aims squarely at the family-and-friends use case you mention (after all, it was made to scratch my own itch - my family's excessive use of WhatsApp for communicating with each other). I can tell you that my family don't care a bit whether Snikket uses IRC, XMPP or Matrix or some real-time Gemini equivalent.
There may be some scalability differences between different protocols/implementations for the admin of the service, but Snikket fits comfortably on even low-end Raspberry Pi devices, and literally over half of the typical resource usage is by the web dashboard (yay Python).
So what difference does the protocol make? It can make a difference to the developer experience. If all you want to do is exchange text messages, then yeah, XMPP and Matrix are absolutely overkill. But - especially for a family-and-friends use case - people also want file sharing, audio/video calls, and all that stuff. It very quickly gets quite complex to support all this stuff, especially in a way that allows you to evolve the protocol over time (trust me, what you think of as core messaging features today, were not a thing 10+ years ago, and messaging in 10+ years will also involve a new set of features).
There will always be a set of users for whom plain text messaging is enough (90% of my own daily communication is via messaging in a terminal app). However that set does not intersect significantly with the general population, and practically none of my family members would accept such a solution as a replacement for WhatsApp.
Hey, your project looks interesting, thanks for building and sharing it.
One question: are you aware of Jami[1], f.k.a. Ring? If so, how does it compare to Snikket?
I see that Snikket requires a server, whereas Jami is P2P. The benefit of a server is probably that messages can be stored centrally and not on each device. But I can see pros and cons of either approach.
[1]: https://jami.net/
Hey, thanks! I've been into messaging for quite a long time - network protocols and particularly those involving online communication are among my favourite tech topics :) So yeah, I follow various projects.
You're right that there are pros and cons. Obviously, not having to run a server is a big pro for many. However, the first thing to remember when researching messaging solutions - no matter what anyone tells you - there are always servers! What differs between projects/platforms is what the servers do, and who runs them.
Jami uses a network of public servers that form a distributed hash table (see https://github.com/savoirfairelinux/opendht ). It's a neat design, and they have done a good job tackling the challenges of P2P messaging. Last time I looked in, it still required both users to be connected at the same time for message delivery/sync to work (the devices use the DHT to discover each other, and then exchange messages). This is a fairly common issue for P2P systems, and can be frustrating in a mobile-dominated world. Their DHT software does support push notifications, which helps with that though.
Another project in this category is Briar, which uses the existing network of Tor servers - and therefore adds IP address masking and a layer of metadata protection (as always, there are limitations, e.g. https://code.briarproject.org/briar/briar/-/wikis/FAQ#does-b... ). Briar built the concept of "mailbox" nodes you can run ( https://briarproject.org/download-briar-mailbox/ ) to overcome some of the problems with P2P messaging.
With Snikket, instead of using existing publicly shared infrastructure, you just run your own server (e.g. VPS or Raspberry Pi or whatever) which is responsible just for your users, and your users connect directly to it, improving (meta)data locality. This makes the design very simple, reliable and efficient (e.g. with battery/bandwidth). It also enables some important (for our use case) convenience/UX features, such as the ability to add restrictions on certain accounts (e.g. for children), and server-managed contact lists so all your family members don't have to manually add each other as contacts one-by-one. Things like that.
No approach is universally better than every other, but I much prefer the Snikket model for the family-and-friends use case. Not that we don't have our own challenges. Our iOS app is probably the weakest part right now (in terms of UX and general polish). Something I'm working hard to get fixed in 2025.
Thanks for your perspective.
Yeah, there are definite challenges of the P2P architecture. But like you say, Jami seems to have done a good job addressing them.
I looked at Briar, but it has a different focus and is more limited in functionality and less polished than Jami. My use case is text messaging and audio/video calls with a close group of contacts, so Jami and your project look like a better fit. I also considered Matrix/Element/FluffyChat, but the Matrix architecture is confusing, and the clients are underwhelming.
Anyway, good luck with Snikket! If Jami doesn't work out for me, I'll definitely give it a try.
TIL: https://snikket.org/
Well, all the XEPs add up to 100s of pages, but the minimal requirements for basic chat are pretty small. It gets more complex as you add more features, but importantly the complexity is managed well. You don't have to do the crazy fragile hacks that IRC needs, because XMPP was designed expressly as an extensible protocol.
> Are we once again at a point where it's time to start over?
Ask Sisyphus.
In the meantime, while everything else keeps going through newer iterations of XKCD 927 (https://xkcd.com/927/), IRC keeps chugging along, and gaining new features and functionality as it enters its fourth decade despite the previous commenter's gripes.
> Ask Sisyphus.
that doesn't make any sense.
To me, it's slowly become obvious that Matrix was invented because certain people wanted to ride the trendy wave of VC money propping up Slack and friends back in those days.
Matrix has been all about superlative marketing and over-promises with little substance and theoretical underpinnings to back it up.
The fact that they were spreading FUD and disinformation against XMPP and the alternatives in their early days should have been a red herring. The fact that they haven't stabilized their protocol and made it scalable to mid-level deployments after more than a decade should be a reason for pause. The fact that after so long, due to the sheer complexity of it, only one entity has emerged as willing to sink the costs of Matrix should be a reason for worries.
I think that we are due for an XMPP resurgence. Not that it is perfect by any stretch of mind, but it is no-BS, mature, lightweight on resources and bandwidth and verifiably fit for purpose, whether you want to host small-scale for your family & friends, or for the whole world with the ambition to be the next GTalk, facebook messenger, or whatsapp (all of them XMPP services at one point or another of their histories)
> red herring
I think you meant to say red flag, not red herring: https://en.wikipedia.org/wiki/Red_herring
Oh, TIL! Thanks :-)
I’ll take the superlative marketing :D
If folks are interested seeing the companies currently sinking $ into Matrix by routing $ to the Matrix Foundation, you can see them at https://matrix.org/support. Thankfully it’s not just Element these days, but companies like Thales and Huawei too. That said, there’s still a $ gap in funding.
Meanwhile Matrix 2.0 is a genuine pleasure to use, imo. You can see the substance and explore the theoretical underpinnings at https://matrix.org/blog/2023/09/matrix-2-0/ and https://element.io/blog/experimenting-with-matrix-2-0-using-...
I do regret saying that XMPP had fallen behind, 10 years ago, when we launched Matrix, though - not least because 10 years later folks are still bringing it up ;)
> Meanwhile Matrix 2.0 is a genuine pleasure to use
"trust us it's good this time" → (still the very same at its core) → "you are right, we are sorry, but bear with us, <buzzword> is just about to be ready!" → (buzzword is abandoned/releases but doesn't improve things in a meaningful way) → "trust is it's good this time" → …
Matrix 2.0 on the server is all about "sliding sync", which, once you read through the buzzword, is about running the client on the server so it sucks less at fetching history. Even that works super randomly, if it works at all, even on EMS-hosted instances. The rest is the same. On the client-side, Element X is not daily-drivable because of the bugs and missing essential features. Nothing has improved in a year on that front, which is reminiscent of dendrite: dropping it for the sake of salvaging the original hack would surprise nobody at this point.
> I do regret saying that XMPP had fallen behind, 10 years ago
By no means am I saying that XMPP was great 10 years ago (what was back then, really?), but that's a very poor rationale for torpedoing another project by spreading lies about it on your FAQ, especially when that project was working on the problems and eventually came to address them, across a whole ecosystem of clients and server, while Matrix to this day is still poking at the beast wondering how to tame its single-vendor/single-client/single-server complexity.
I guess the question is whether it’s better to spread objectively and demonstrably false info today (as you are with the completely bogus Matrix 2.0 critique), versus me putting subjective info into a FAQ 10 years ago ;)
It might be worth considering that whining about Matrix is misdirected anger - it may be better off pointed at the proprietary centralised surveillance capitalism alternatives rather than us…
> I guess the question is whether it’s better to spread objectively and demonstrably false info today (as you are with the completely bogus Matrix 2.0 critique), versus me putting subjective info into a FAQ 10 years ago ;)
Outright denying people's bad experience with Matrix has also been a sad part in Matrix marketing for so long. Unfortunately, I don't have experience with Element X, since my provider doesn't support it yet, so I can't confirm or deny that testimonial, but my exceptations are not high.
> It might be worth considering that whining about Matrix is misdirected anger - it may be better off pointed at the proprietary centralised surveillance capitalism alternatives rather than us…
It's not either or. People are frustrated on the other hand because of the annoying proprietary platforms, but also because there are currently no alternatives to them that one could whole-heartedly recommend as a replacement.
> Outright denying people's bad experience with Matrix has also been a sad part in Matrix marketing for so long
I think if you look at my comments on HN you'll see me spending most of my time trying to explain or apologise for people's bad experience, but ymmv.
> Unfortunately, I don't have experience with Element X, since my provider doesn't support it yet, so I can't confirm or deny that testimonial, but my exceptations are not high.
Shame, you're missing out.
> Matrix has been all about superlative marketing and over-promises with little substance and theoretical underpinnings to back it up.
I don't think so. The underpinnings were there, may it be the concepts for E2EE, P2P, Verification, Bridging, decentralized rooms and conferencing, synchronized history, etc. Not everything is production ready let alone finished with perfect UX, but it doesn't lack theoretical underpinnings.
> The fact that they were spreading FUD and disinformation against XMPP
In the past, I have experienced it more often vice versa than this way.
> The fact that they haven't stabilized their protocol and made it scalable to mid-level deployments after more than a decade should be a reason for pause.
There are already pretty large deployments (1+ million users), so I think it's scalable to mid-level deployments.
> only one entity has emerged as willing to sink the costs of Matrix should be a reason for worries.
idk what you mean
> all of them XMPP services at one point or another of their histories
histories is an important keyword
> I don't think so. The underpinnings were there, may it be the concepts for E2EE, P2P, Verification, Bridging, decentralized rooms and conferencing, synchronized history, etc. Not everything is production ready let alone finished with perfect UX, but it doesn't lack theoretical underpinnings.
Let me cut it short: either you think that there's nothing to be said about the current state resolution machinery, and that's an admission that Matrix will never reach its stated goal to become a mainstream decentralized network (because federation at scale just doesn't work with the current status-quo), or you agree with me that something needs to be done (but, like me, could turn impatient that nothing materializes after a decade).
>> The fact that they were spreading FUD and disinformation against XMPP
> In the past, I have experienced it more often vice versa than this way.
I am not challenging your experience, I am talking about what was effectively written about XMPP on the Matrix website. If this was reciprocal as you say, I'd like to be shown where and in which terms XMPP has engaged in disinformation campaigns against Matrix. At least, with the xmpp.org website's history being on github, it should be very easy: https://github.com/search?q=repo%3Axsf%2Fxmpp.org%20matrix&t...
>> all of them XMPP services at one point or another of their histories
> histories is an important keyword
If by that you mean that WhatsApp, the single largest chat network to have ever existed, is history, I've got news for you. While we may regret that federation never was a thing with this network, talking about underpinnings, they are still very much versed in XMPP. And that's not an exception. All Android devices depend on XMPP for push notifications, so do every Nintendo switch, and millions of access points, networking and IoT devices. XMPP is all but dead.
IRC is a Very Old Protocol, you're right. if you dig through the spec you will find a few historic relics: 7-bit ASCII only, 254 character max total line length (some reserved for the message itself), and many many more.
NATS as an IRC replacement is using the wrong tool for the wrong job.
I've long been thinking about how I'd replace IRC and I keep coming back to another IRC-era protocol that wasn't as popular but was definitely ahead of its time by some amount: Hotline. It wasn't Open like IRC and was limited to Macintosh users for a long time, but it has a lot of what most people are looking for in a "chat system" today. One thing, however, that I think would benefit the protocol designers of the future: Learn from MSN.
MSN separated their Authentication and Chat systems. You ask for a token that identifies you to the chat system from the authentication system. These were two separated protocols that did one thing specifically for each other. I honestly think that separating chat-locus and identity from one another is important.
I see nothing wrong with that syntax? Just avoid the extensions. All you really need to do is get text from A to B and it's great for that.
Perhaps I'm just a bit dim but I don't really understand the problem here. If that had commas and { ... } around itself no one would give a second thought. But you also mention s-expressions, and there you dont even have to add the commas!
Something a little more tightened up might be nice, because who likes scanning for line endings, when you could have a byte count, and what's up with the colons, and while you're there, might as well have a single byte command, right? But preferably without having seven layers of byte counts, like TLS.
But from my recollection of writing bad IRC client in the 90s (including in mIRC script after they added support for sockets in the scripting language in mIRC v5.3 released December 1997), the protocol isn't that hard to work with. Once you figured out you needed to send a : in front of your message text, I don't remember any other big gotchas.
It's not XML, and I don't remember any quoting issues, but maybe there's some I forgot. CTCP maybe isn't ideal either. DCC probably doesn't work anymore, but it was a different time when being on the internet meant an expectation that you were a peer and could accept inbound connections.
> including in mIRC script after they added support for sockets in the scripting language in mIRC v5.3 released December 1997
You could write your own servers and services too :). My mIRC scripts all had s:lines on my network, all running in my mIRC (NoNameScript) environment, which I'm sure were on Hawkee somewhere.
Without unconditionally endorsing the content of this blog (especially the more recent parts of it) you may find this post interesting: http://www.loper-os.org/?p=4003
Nobody in the 80s wanted to pay the overhead of s-exprs when a couple of colons did the job. Bandwidth and memory were limited.
Meh, a binary protocol would've been more efficient in every way, I don't think they really prioritized efficiency. It would've also been simpler for implementers, but there was a time when people thought text-based protocols were good for some reason. They're usually not, and getting the supposed "benefit" of the protocol being human-readable at a glance is trivial to do by just having a code path that turns the binary one into a human-readable one, in whatever shape you want, so you don't have to make your base protocol shitty just because you want human-readability.
Complaining about IRC in 2024 is bleh, by the way. The protocol is what it is, you've had a long time to get over it and if you were late to the party you need to realize that yes, there are tons of old protocols that are pretty badly designed, welcome to the world. IRC as a way of public chatting (and maybe even more so running a closed chat) is still somehow among the best we have and personally I'd prefer it if Slack, Microsoft Teams and Discord died completely for "Hey, we've set up a place to talk about this work/event/hobby thing!".
It feels really nice to see stuff like this while the most of the people think Slack, Discord and a few others are the only choices.
I recently went through the hassle of deciding on something small for my family + company circle. Mainly considered XMPP and Matrix, and went with Matrix. Didn't know there was such a thing as "always-on" on IRC tho.
> Didn't know there was such a thing as "always-on" on IRC tho.
It's a server feature and might be unique to Ergo. It's a per-user setting (with a global default) and when it's on the user always appears to be online so you can type at them any time like you would with other DM systems. The v3 chathistory support ensures that they don't miss messages. For clients that don't support chathistory the server can replay any unseen messages.
It's a lot like what bouncers provide but integrated and very easy to enable for everybody so no extra steps required for my users.
Have you had any issue with messages/notifications not be sent/received with Matrix? I wanted to try Matrix for friends and family, but either I would never get the message until I opened the app, or I'd get the notification but my phone wouldn't vibrate. Eventually settled on XMPP with Conversations on Android.
Not really, I didn't have any delivery-related issues, and didn't get any complaints from other people as well. I have mixed feelings towards Matrix due to;
1. The only stable and maintained implementation is "matrix-synapse" and it is written in Python.
2. The most commonly used client is "element", and it is governed by the same people. So it feels we are the mercy of a single company.
I wanted hard to go with a more established protocol like XMPP but failed to get a server running properly :)
Not sure if you tried prosody[0], but I found it rather powerful and simple to configure, including multiuser chat(muc) and peering. It's written in lua and has a module system so it's easy to extend. In particular I used the dovecot auth module[1] so users could login with their email credentials and I could manage a single user repo.
0. https://prosody.im/
1. https://modules.prosody.im/mod_auth_dovecot
Yep, Prosody was one of my failed attempts :P I am running everything on a kubernetes cluster, so a maintained helm chart is the first thing I check when running something. I didn't have much luck with XMPP servers with this.
That IMAP auth trick is really awesome thinking BTW, kudos!
Ah interesting, I haven't tried running it on k8s yet. Migrating my mail stack over to k8s has been on my todo list for a little while; should probably get around to it since dovecot and postfix have supported inet sockets for user/domain db and auth for ~12 years now.
Dovecot is really great, and a ton of stuff supports using it as a sasl auth backend (postfix being an important one). I made a simple facade service that feeds it and postfix from couchdb via its dict backend[0] and postfix's tcp_tables[1], then point everything at dovecot for auth. Couch document IDs map really well to email/user, domain, and sieve script lookups; helluva lot simpler than setting up and managing LDAP.
0. https://doc.dovecot.org/2.3/configuration_manual/dict/
1. https://www.postfix.org/tcp_table.5.html
I've been running XMPP/ejabberd for a decade, it's a single service embarking everything you need, including what it takes to do A/V calls (NAT traversal & al.). Nonetheless, it's also the quietest and lowest-profile piece of server software I've ever used. I don't need a container for that, but if you want, there's an official docker image for it. Without going to host millions of concurrent users and needing to distribute the service across multiple physical servers via clustering, I don't see what good an "helm chart" does for you, but then you do you.
Ive been running matrix for small company/group for almost 10years. No need to use Synapse as there are many other solid servers (and have been for years). Matrix (the company) software like Synapse and Denderite (their “performant” server in go) are aimed at mega servers that federate and the features revolve around that.
If you want to selfhost just make it easy and get Conduit. Its single binary and uses embedded db (rocksdb or sqlite). I cant say about federation but for private chat server this has been solid for me for years. I still run it with sqlite (worse than rocksdb) and with 30 very active people its more responsive than Synapse ever was.
What clients do you use to connect to it? I just setup a Conduit server and can connect from my Mac via https://app.element.io as well as the official MacOS app, but the iPhone apps cannot find it somehow. Does that work for you too?
Nevermind. I think I got it. My server name was set incorrectly so that
curl example.com/.well-known/matrix/client
responded with an incorrect base_url.
Have you seen https://snikket.org ?
Yes, Snikket was also one of my failed attempts. Maybe it's me, I don't know.
The Element app on Android seems to have problems with delivery. I haven't had issues on iOS.
Just in time for taking my chatops onprem. Clear text orchestration with a chat log is pretty nice. !docker-restart :)
I think the answer is no, but can Ergo connect to other IRC servers? I'd like to set it up linked with my existing ngircd, for my users to try out, and then if it goes well shut down ngircd, which is a pattern I've used before when migrating between servers.
It doesn't support any linking at present: https://github.com/ergochat/ergo/blob/stable/docs/MANUAL.md#...
Here [1] is a table that has IRCv3 features by platform and then view each platforms web site to see all the standard features they support outside of IRCv3. FWIW one of the most popular by market share is UnrealIRCD [2].
[1] - https://ircv3.net/software/servers.html
[2] - https://www.ircstats.org/servers
let's hope this replaced slack and all the gimmickware.
What’s wrong with Slack?
Look under the hood sometime and witness the lovecraftian horror. You can enable the electron dev console via env var. Everything from how they layout the page, to the underlying structure for messages and threads (and how they are accessed) is super complex.
IMHO it's expensive and not at all better than IRC, plus it helps kill IRC which was a core part of the public internet, open source culture, etc.
I also find it annoying that the creators of slack pretend they invented something original.
Sounds like a good product if people are willing to pay so much for it...
I think it was a fad that caught on among people who had been writing code for a few weeks.
I find it super expensive if you want to have the history.
To me, lack of history is a feature, not a bug.
Document your shit in proper places.
A year ago I used this server for my friends, then it was called oragono. I really recommend it.
Is it possible to send Webhooks to specific channels of an Ergo/any other IRC server?
Can I connect with.... Bersirc?
Maybe, but is there a particular reason you need to use a ~20-year-abandoned IRC client when there's literally dozens of actively-maintained ones for any platform you could reasonably think of?
Those are all IRC clients (this is a server)
Yea I thought I was replying to a comment but it tossed up top, so I edited.
Whenever IRC comes along, someone mentions its lack of chathistory/backlog as a missing feature. Having witnessed what Discord have wrought, I am now in the firm belief that backlog - at least for communities - is an anti-feature. Because the logs persists between sessions, people start to post things there for perpetuity, a task classically reserved for bulletin forums.
Without a server-side backlog, the chat is fleeting, and everyone knows that, so to preserve important content, people know to save it somewhere else. This keeps the chat as it was meant to; a live chat, mimicking that of a human conservation, where nothing is recorded until someone makes the conscientious effort to do so.
Fully agreed, but let's not forget the psychological quirk of Discord moderators loving to divide the world into neat little boxes, so the mark of any established server is the myriad of different topic channels.
Every single community has become a silo with their own memes channel. It's like they emulate modern social media websites where they try to keep you engaged and in one spot forever.
I find it dystopian and power-tripping personalities trying to invent rules upon rules on their little kingdom is really not conducive to spontaneous socialisation.
Now, sorry, you cannot contribute to this conversation because you haven't fully read the rules on #welcome, didn't complete the captcha from our bot and, worse of all, you have not chosen a role for yourself.
Unfortunately it's worse than that now. It used to be that everything got siloed into channels, now things get siloed into the new forum system.
These forum channels don't automatically appear in the sidebar and you get no indication of anything new added unless you specifically follow the thread.
Moving into forum threads is a great way to kill a conversation, perfect even, honestly I wouldn't be surprised if the feature was added just so Discord could appear in "forum" searches. There's no way the feature was planned when it's so bad for conversations.
In any case the discord mod quirk of stomping on discussion inertia plus this horrible new forum system guarantees a conversation fizzles out immediately.
I'd rather software chats not be on Discord, but that said I've found the forum feature quite helpful for help channels. You get auto-search for the topic as you type out a title, and if you don't see what you need, you can turn it straight into a topic. It's a lot better than the old system of posting into a rolling scroll and hoping one of the regulars is around, and that you're not asking a question which should be in the docs but isn't (and therefore gets asked an annoying amount of times).
It's quite possible the communities I'm active in are using the forums feature wrong if it works well for a QnA/helpdesk scenario haha
Thinking about it that use case makes far more sense than what the communities I'm in are using it for (basically just dynamic #channels that anyone can create) - especially with how nobody is a part of the discussion by default. That does make way more sense for a helpdesk kinda setup rather than misc discussion threads.
> personalities trying to invent rules upon rules on their little kingdom is really not conducive to spontaneous socialisation
Seems like a neglected area of research in UX/UI - perhaps an opportunity for a good PhD or Masters: To what extent do software paradigms enable/inhibit pathological/virtuous personality traits?
And no - not all software is a "neutral" blank canvas. Behaviours cluster around latent or implied structures. Designers imprint their own values on code, perhaps even unconsciously.
Do you think the same people would behave differently as an IRC server mod?
I do. See my suggestion above.
Software shapes behaviour. If you design software for social interaction you are designing mass behaviours.
People just started to build IRC bots for notes and reminders. Or used IRC proxies to keep history while offline. All just hacks and gatekeeping the history to people who are not that tech savvy.
Discord servers can have forums like channels. https://support.discord.com/hc/en-us/articles/6208479917079-...
I recognise someone may not have been introduced to what I meant by what Discord has wrought; specifically Discord channels (including forum channels) are not indexable by search engines, meaning posts with important details cannot be uncovered by an outsider. Classic bulletin forums are public, and so obscure technical details shared there could later be dug up by a curious soul. It's not too infrequent to see a blog shared on HN, with the author complaining about how hard it was to find some details, because they weren't a member of an obscure Discord server.
The irony of the persistent backlogs for Discord means that a lot of this information is practically lost. Archive.org cannot preserve copies, so if the Discord server is closed or whenever Discord itself decides to call it quits, it's all gone.
Perhaps what we need is a group chat that automatically maintains a summary of relevant chat history created by AI?
The AI could maintain a Wiki with relevant stuff gathered from the discussions.
Not sure if it's good enough today, but it does seem like an interesting prospect. Not many people like filling Wikis.
What's wrong with teams?
For starters, it's closed source, centralized and proprietary. You have no control over your data and the product's future.
What's right with teams? Every time I open that miserable app I want to deep fry my computer
MS Teams is designed to create siloed teams and organizations. It discourages public chat and collaboration. It encourages private group chats.
I refuse to believe this isn't a bait comment. Given that there aren't any humans who like Teams, this is either a joke or you're an alien.
It's the singular worst piece of software I've ever used.
everything?
It should be pretty easy to list one thing then, like the fact that Teams doesn't cook bacon.