Hacker News new | past | comments | ask | show | jobs | submit login
Ergo – modern IRC server written in Go (github.com/ergochat)
168 points by modinfo on June 22, 2022 | hide | past | favorite | 105 comments



Anyone interested in IRC protocol improvements should check out https://ircv3.net/irc/

Two of the most major changes:

1. First-class mobile-friendly websocket support.

2. Server can store messages to catch you up when you return

Personally I feel Matrix is the right way forward for most use cases but Matrix will continue to bridge to IRC so you have options. IRC remains a much easier to implement protocol and much easier to deploy for standalone environments where federation is not needed.

There is a reason most infra teams at FAANG companies keep IRC servers around as a fallback for when their complex proprietary solutions fail.


Matrix has a lot of nasty issues, I'd argue XMPP is probably the right way forward for small group chats and one to one convos. I personally refuse to use matrix since I still don't feel comfortable self hosting it.

For large group chats IRC is still king.

EDIT:

There's pretty much one useful server last time I checked and it's too bloated to host in most places and it looks to me like this might be at least partly due to the way federation works. One of the main organizations funding Matrix is that one company in Israel that was contracted to do all the phone surveillance in the US. I haven't really been impressed with the protocol itself either.

In short, I don't think Matrix will "mature" since it's problems are deeper than just technical/implementation. XMPP already is mature and there are good clients and servers for nearly every platform.

IMO: The only reason Matrix is more popular than XMPP right now is just PR.


Amdocs hasn't funded Matrix since 2017

https://en.m.wikipedia.org/wiki/Matrix_(protocol)#History


What are those nasty issues?

I also prefer irc, but been waiting for Matrix to mature so good to know where they are at.


Matrix has really interesting properties for censorship circumvention, but their approach has drawbacks: designing an append-only log with consensus building takes a lot of resources (though the implementations are getting better). It's not uncommon for medium server operators to report >10GB RAM usage and at least twice as much database storage... which is quite too much for most of us.

Also worth noting, there are also issues regarding the fast evolving protocol. Room protocol versions keep increasing and if some server doesn't have the very latest version it may be unable to federate with a more modern room, from what i understand. (please correct me if i got this wrong)

Finally, some pseudonymous persons are really unhappy that as a consequence of decentralized rooms, your public matrix address is leaked to any server federated with a room you joined. Under IRC, addresses are local to a server (not federated) so this concern does not apply, while on XMPP only the servers/services you explicitly connect to know of your JID.

In the meantime, IRC and XMPP provide useful services with 1-10% of those resources, despite most clients being less polished. For example, jabberfr.org uses only a few gigs of RAM for hundreds of clients and over a thousand of server-to-server connections. Not all features may be available on all clients/servers, but "graceful degradation" is definitely there so noone is left out.

To be clear, decentralized room is an amazing concept, and it's really cool the Matrix team has full-time employees to evolve things that quickly. It's just too bad historical standards were left out (decentralized rooms could have been a XMPP extension), and Matrix focuses (though this focus is changing) on high-end clients/servers.


Conduit is lightweight. I'm running it on a tiny VPS. Its main problem at the moment is unreliable Android notifications.

https://conduit.rs/


How is the compatibility with federation and clients? Any issues? Last synapse upgrade half of my clients just stopped working due to some incompatibility between the newer synapse server and a too old shared library (that all the desktop clients used).


I've used web, android and desktop clients without problems, other than the android notifications. I'm using it as a private chat server; I haven't tried out federation since I was setting it up. I can't see an issue on the bug tracker though.


Conduit v0.4.0 was just released and should fix notification problems, see https://conduit.rs/changelog


Does it support gateways properly? I'm still interested to give it a try but last time i checked Bifrost was not compatible with conduit.

Also, how's your database RAM/disk usage? From what i understand conduit.rs is very optimized but still relies on a huge DB for matrix to operate its magic.


> XMPP already is mature and there are good clients and servers for nearly every platform

Bold interpretation of the word 'good' regarding the clients.


What good XMPP clients that non techs feel comfortable with?

I'd just put Mattermost and be done with chat problems.


XMPP is a nonstarter -- there is no decent free iOS client, unless there's something new that has appeared in the last few months with a lot of features


snikket is the best there is that I have ever found.


Monal is also getting better. They recently released a version with OMEMO for group chats.


What good is a chat platform without mobile notifications?

I don't see how people need to stick with a legacy protocol when there are so many working alternatives.


Some people prefer to chat on desktop and don't really like the mobile-derived UI and prefer a text-heavy dense layout. Throw in lightweight resource usage as a requirement and suddenly there are not that many working alternatives anymore.


Man how I miss my time on IRC. It was the "apex" for "decent-social" for me :) I'm old enough to have enjoyed BBS and Usenet. Both the BBS and Usenet was mostly tech/geek.

IRC was just enough mainstream and the lack of mostly economic incentives and a small enough tech-hurdle to filter to keep out "crazies".


interesting. I grew up on IRC as well, but my takeaway from IRC is that people have a very hard time treating others with decency without visual indicators like a profile picture. I did very much appreciate how many people were on IRC just to help other people learn, though.


There were good communities and bad communities. I really don't think profile pictures have much to do with it.


I'd be very surprised if profile pictures didn't have a large impact. Anything you can do to make one end of a conversation seem more human would (I suspect) have large implications in how the other end engages/reacts.

Without human identifiers it's much easier to address an opinion without consideration for the human who is expressing that opinion. I believe many people might take for granted just how much non-verbal signals play a part in effective communication. A smiling picture signals to me, before reading any of the users text, that they are generally a person with a pleasant disposition. There are likely strong non-verbal cues than a profile picture, but they seem likely to play a part and when that part is going from virtually zero non-verbal signals to one, I imagine the impact is noticeable.


I'd argue that profile pictures might even make things worse because people get tempted to use pictures of themselves which drags difficult (and completely irrelevant) ideas like race and sexuality into the situation.

EDIT (out of quota):It's not that your profile picture would be actively used against you, but it's going to create a subconscious effect. Also they take up a ton of space in a text only chat. I stand by the idea that profile pictures are just stupid.


hmm, I'm not sure I'd agree that those things are irrelevant. Maybe it's a subjective understanding of whether a community is more likely to use those context clues to engage more personally and develop relationships or if they're more likely to use those context clues to exclude people.

I'm optimistic that the vast majority of communities use those context clues to better understand someone as opposed to exclude them. I don't believe that holds true universally, but I would probably avoid using a revealing profile picture in communities I suspected would use that against me.


The biggest problem I have with IRC is its feudal social model. The first person to join a channel becomes the monarch, and can appoint deputies to impose their will on the others. There's no system for dealing with an abusive op. It's all very well to say "just start your own channel then", but that's rather like telling someone to move to Canada if they don't like the president. A channel has inertia and cannot simply be "moved", especially when the person running it can simply silence anyone who raises the idea. And there's also a single global namespace - it's not feasible to found a replacement for, say, #chat.


These problems exist with any social network.

The IRCops of most major IRC servers are very hands off - they will not get involved in user disputes at all unless the IRC server itself is in danger.

However, you get kicked out of a Discord server or Facebook group, you're in the same situation, and Discord/Facebook isn't going to help you most of the time unless the group is violating TOS. Most IRC server's TOS are very liberal because the IRC server itself doesn't really store any data other than possibly some actual chat text - it doesn't hold images, files, etc.

> And there's also a single global namespace - it's not feasible to found a replacement for, say, #chat.

With modern IRC services you can actually create "neutral" lobby-type channels that have the services daemon as the op.

But unless you run your own chat server or social media service you'll always be at the mercy of who runs it at least a little bit.


IRC also supports anarchism with + channels that simply have no modes and no ops (also no topic which is slightly annoying) but then you are kinda at the mercy of the network admins to stop the spammers (as well as liberal use of /ignore to ignore spammers). Also some channels just give every non-spammer ops, which kinda also solves the power corrupts issue.


you can build GUIs on top of IRC that abstract away from all of this and still use the underlying protocol. I am curious what you think a better alternative would be for moderation, though. It's easy to point out flaws in all moderated systems, but it would be interesting to consider what an improvement might look like


I'm not sure what you're on about with GUIs, that doesn't seem relevant to any point I was making, but to address your other point:

You're basically asking for alternative systems of government to feudalism. This has been widely studied! Parliamentary democracy is a popular system. Imagine if chanops were chosen by election.


when would elections be held? after N number of new people join? How would you prevent rigged elections with many bots joining to represent many votes for 1 person? Other forms of governance are in wide abundance, but implementing them on top of pseudo-anonymous chatrooms is hard and could lead to mostly benefiting malicious actors.

the GUI is relevant in addressing duplicate channel names as underneath you could have UUID channels that mapped to channels named "chat" for the end user.


Sure there is, run your own network, servers and channels, have better content and attract users. You can have as many #chat channels as you want, and run them as you see fit.

Anyone can run an irc server, and it does not have to appeal or cater to everyone.


i.e. "move to Canada". That is not helpful. Even if I did set up an alternative network, it would have the same issue - a broken social model, enforced at the technical level.

That's assuming I could persuade a critical mass of people to use the new network. "Have better content"? An IRC network has no "content", it has users. Talking to other users is the point. How many IRC networks are there?


Every website has the social model you just described. You'll have to start with a decentralized protocol without server admins (the true monarchs) to get around what you're describing.

This website has dang. Slack has channel owners. Reddit has mods and admins. 4chan has janitors and admins. Flat forums had mods

IRC is the same as everything else. It's a fine thing to point out, it's just not unique to IRC in any way


> You'll have to start with a decentralized protocol without server admins

This is all or nothing thinking. We could design centralized protocols that have, for example, voting. We could design centralized protocols that call together digital juries[1].

Yes there may be powerhungry mods at the very top. They might be able to throw the votes or what not. Abuse is possible on centralized systems. But there's so vastly much we could be trying, could be doing, to alter the gerontocratic imbalance of power, even on centralized systems.

[1] http://digitaljuries.com/


Nothing's stopping you to use IRC this way, and it's trivial to add a bot to your channel with a poll feature.

The problem isn't that nobody has designed or created such a system: it's that they're not very popular.


> The problem isn't that nobody has designed or created such a system: it's that they're not very popular.

This assertion would be more interesting if there were more visible attempts. I haven't found anything on github I can deploy to moderate a channel via any kind of public-governance or other models. Can you?

Personally, I think we've done very little experimentation, and the gerontocratic rulers we dwell under generally would prefer staying in tight control. You talk about popularity, but popular for who? Even if some kind of democratic governance gained mass popularity, how many mods would be willing to hand over their long held control over channels/sites?


I really hate Slack but the killer feature nobody in irc world is solving is mobile connectivity. If get logged out every time I lock my phone then I have to keep dealing with Slack.


This issue has been solved by the ergo in that it integrates the bouncer functionality into the IRC server. So from everyone elses perspective you never get disconnected and combined with support for the chathistory extension (which your mobile IRC client has to support) you won't miss things happening in between either.

But that being said, the mobile phone essentially killing all open tcp connections is not really that great of a thing. IRC is not the only protocol that suffers here, but also IMAP IDLE push notifications suffer here.


Shameless plug: someone is trying to solve these issues: https://sr.ht/~emersion/goguma/

It uses IRCv3 chathistory + a proposed extension for push notifications.


Who's going to babysit the iOS push server? Colloquy already has this and I modified an IRC server to support it but the push server is down so often it's not usable. I'd run the push server myself but Apple requires that I pay them $100/year, buy a macintosh, and convince them my version of the app is substantially different all for the privilege of maintaining a service required to support their miserable OS.

EDIT: ah, of course it's Android only.

EDIT2: They absolutely are Apple problems. Unfortunately Apple has convinced their users that they are IRC problems and the practical reality is that Apple users will not use IRC unless they're fixed which for me means setting up eg MMS bridges with cheogram which is a major pain. Thankfully we're getting web push on iOS next year and that will (hopefully) make all these problems effectively go away.


These sound like Apple problems not IRC problems.


You can always give the possibility that the user enters his API key to Pushover and by pushover you can receive push notifications, I have already written many programs that work with Pushover, one works to this day, every 6 hours I get the current price of bitcoin back with a difference whether the price has decreased or increased.

It's really convenient, I don't even have to pull out my phone because notifications come straight to my Apple Watch.


Just FYI, Pushover has a Glances API so you can push data like that directly to an Apple Watch complication.

https://pushover.net/api/glances


I really miss MutterIRC client for iOS, it was probably the best client, all you had to do was install MutterIRC module on your ZNC, download iOS app and log in to your ZNC account. It was like using WhatsApp, you always got a push notification if someone wrote to you or wrote you a nick in a chat.

I would really like MutterIRC to come back or some alternative to this application.

When I was at work I got a push notification and could quickly write back on IRC chat. That's how it should work. Unfortunately, MutterIRC is not working since 2019.


I’m currently using IglooIRC + ZNC push module (https://github.com/jreese/znc-push). Works decently well.


Thank you!


Very nice. Thank you for the ultra-convenient F-Droid repository!


I don't hate Slack per se, but I hate their bloated Electron client. Fortunately some weeks ago their Linux client stopped working on my machine (it had been warning me for some time that my OS version is "too old" - interestingly other Electron apps and Chrome itself are just fine with that). Since then I discovered that the web version works just as well and is less resource-intensive...


Yeah I use Slack in a pinned browser tab too. I figure if the interface is the same I might as well wrap it with the browser I have open 90% of my day than some separate Electron app I'll forget to open.


Electron hate is in most cases unsubstantiated, esp. when compared to their web counterparts.

Just checked discord - electron app consumes half the memory firefox does with only discord open.


Put https://weechat.org/ on your vpn (or a raspberry pi under your couch or whatever) and install one of the weechat apps.


You can run thelounge somewhere and use thst as web interface. Android and iOS allows you to iconify a website, so that would feel like a native app.

https://thelounge.chat/


I use chat.sr.ht, which is a hosted instance of the ircv3 bouncer soju.im. This keeps me logged in without requiring my phone to be always connected.


The biggest issue with mobile IRC that it needs a constant open TCP connection to the server.

You need to have a client or a proxy client running somewhere 24/7. You can self-host it (bouncer) or you can pay someone else to do it (IRCCloud).

But it's still a protocol level issue. IRCv3 might be doing something about it, but I'm not holding my breath.



That issue was solved ages ago with screen or bouncers. One could also push notifications via e.g. Gotify.


I don't think that's going to change. It's like that by design and I don't think IRC devs are willing to change it.

So you'd have to use a server that's connected to the IRC server 24/7 and connect from your phone to that server.


That’s what a bouncer is. And I already used it to solve this problem 20 years ago. The main point back then was of course that nobody steals your username.


And don't forget idling in your friends chat rooms so it appears higher on the list and randos would join.


The Ergo IRCd has an built in "Always-on" feature which allows you to stay online without an additional server.


Isn't that what BNC is?


It is.


Why is it designed that way? Just to avoid the server having to keep data while you're offline? Or there's a grander motivation?


IRC is a message-passing service, not a log synchronization service -- like many of the more modern ones are. You might say that that is one of its architectural strengths, unless, of course, you want to see old messages that were passed when you were offline. In which case you'll need to hack something like bouncers up, which works in practice really well.

Or https://ircv3.net/specs/extensions/chathistory# this might change it.


IRC doesn't have accounts, you just connect, specify a nickname and it's yours unless it is used by another connected user. So not really possible to track users.


I've been using https://libera.chat/ which allows "claiming" Nicks with a registered email account... I suppose it would be possible to "buffer" messages?

I see some IRCs even keep a mailing-list-like record of all messages posted on a channel... so I don't see how it's not possible.


Logging and nick registration are both extra services that run ontop of IRC.

At one point I extended an IRC server where you could send a list of regex filters. When messages where sent to channels you had joined that matched the filters it would send you push notifications. I think that combined with logging is really all people want on mobile.

Unfortunately someone has to actually run the push server and that

1) Requires more work than volunteers are willing to do

2) Can only be done by people holding the certificates used to publish the app.

I've personally just given up on popular mobile OSes. They're a disaster in nearly every way.


If the nick bot is down, there's no registration.

It's just a bot that runs on IRC just like the bots I made when I was using it.


Today I learned that mobile connectivity issues are another thing I love about IRC.


Tradional way to deal with this is a bouncer on a VPS somewhere


Connection bouncer is what you're yearning for. If that doesn't interest you, then try IRCCloud, which is fantastic on mobile.


irccloud.com has worked wonderfully for me, for many years now.


Irccloud is really nice. Best IRC client I’ve ever used.


Yup, lack of roaming support was what killed IRC for me. I see that IRCv3 tries to address this but it's about 20 years too late and 10 years since I last used IRC.

Props to them for giving it a go but I feel it'd take something massive for people to switch back to IRC at this point


The chathistory extension[0] might take care of that problem. If IRC lives that long.

[0] https://ircv3.net/specs/extensions/chathistory


It's the other way around: the phone systems actively block background connections.


I've experimented with this on the pinephone. You can often just get away with leaving TCP connections open while the device is locked (on mine "locked" means something like Android where the device suspends and periodically wakes up so apps can maintain their sockets) as long as you wake up before the keep alive message for the protocol you're using leaving sockets open is fine. That's effectively what the push notification receiver in the OS is doing anyway (although it does something special with the hardware so the incoming packets actually wake up the device for lower latency.)

There's no reason not to allow this for open source apps (commercial ones would obviously abuse it and you would have battery life issues.) Unfortunately it doesn't matter what makes sense on mobile, you're not allowed to tinker with the OS in any way.

EDIT: That's great! I did not know about it. You could probably get around the issue of teaching clients to use it by modifying the BSD socket library to open sockets that way after checking an environment variable. I might mess around with that later.


For the Pinephone, the Quectel firmware supports AT commands for creating a TCP connection through the modem, after which the modem sends wakeups on the bus when it receives data on that socket. So that can be used to implement push notifications without any lag from having to periodically wake up to check.

The problem is that:

a) ... this requires teaching ModemManager about this API since MM is the only thing that talks to the modem.

b) ... this requires teaching clients to talk to MM for a TCP connection, likely using some new dbus-based API to match MM's existing API, instead of just socket() + connect() + read() + write(). So existing TCP-socket using programs will not work without modification. (LD_PRELOAD trickery can work, though ideally only sockets used for push notifications would be routed through MM and the rest use socket(), which can be hard for an LD_PRELOAD'd library to do.)

c) ... one should really be running the OSS firmware instead of Quectel's, and the OSS firmware does not implement those commands.

This was discussed a few months ago in #pinephone. AFAIK no one is working on it.


Thelounge solves it nicely.

Run Thelounge somewhere and it provides a great interface for your phone with chat history storage and other conveniences.


Would QUIC with its connection migration feature help here?


That is a non-issue. That is what bouncers are for. It has been around for over 20 years or something. Personally I run irssi inside screen on a server and I ssh into it using my phone.


Another killer feature IRC is missing is being able to react with a party parrot or other custom emoji.


There's an "idea ticket" for it in IRCv3: https://github.com/ircv3/ircv3-ideas/issues/14


This is sarcasm, right?


No. I think custom emoji and being able to use them as reactions are essential parts of what a chat app should have.


chat chăt intransitive verb

1) To converse in an easy, familiar manner; talk lightly and casually.

2) To participate in a synchronous exchange of remarks with one or more people over a computer network.

No, reactions are not essential part of chat apps.


> 1) To converse in an easy, familiar manner; talk lightly and casually.

30 people leaving a reaction to an announcement is way easier than 30 lines of chat coming in at varying times.

Same goes for things like +1 -1 feedback


I'm not sure why you are giving a definition when it's also missing things like being able to edit or delete a message. In 2022 I have different expectations on what should be included compared to IRC which came out in the 90s.


I consider both anti-features for _instant_ messaging since it's easy to misuse by hitting enter first and then editing their message for half an hour. Which people do a lot and is quite annoying since it breaks the flow of conversation.

Talking to a person also has none of those features, yet it's still as popular today as it was 300 years ago. And I view IRC just as the text-version of talking in person. So my expectations are that it has more or less the same feature set.


What about a compromise? If someone edits or deletes a message, those actions could be pushed to the client which chooses how to display that information


I think there are some IRCv3 extensions in the works for that, but imho it will make it even more confusing since not everyone will be seeing the same thing (at least for the edits), but I guess we'll see how widespread the adoption of those extensions will be.

And even with only partial support the delete function (if it's not limited to the user itself) gives way too much power to the ops/moderator (power corrupts. Absolute power corrupts absolutely.).


How do you do this chăt if there's nobody to talk to? Other users are kinda essential too.

Reactions and images aren't essential for the strict interpretation of the word, but as everyone is used to them now you're not getting very far without them.

Nobody wants to play multiplayer notepad in 2022.


> Nobody wants to play multiplayer notepad in 2022.

The fact IRC is still widely used disproves this quite clearly.

I think the real issue is people who like Discord trying to convince people who like IRC that the Discord method is better, and vice versa.

It's two pretty different demographics for the most part.


I'm not sure it's fair but my understanding is that Libera chat is the biggest network still going, with about 45k users. [1]

Relatively that's not widely used. Back when I used IRC you'd see that many people disconnect from the network during a netsplit if you were a network admin. Honestly if 45k people for the top network is widely used it's just... kinda sad really.

With modern resources you could probably get the the entire top 100 public networks running off a single machine. Look at Undernet, EFNet, DALNet! Those places used to have 100k users each on a slow day, they're barely reaching 10k now.

User counts have halved since I last looked, and have been decimated (literal usage of the word, nice) since the days I actively used IRC. I'll accept that maybe today is a bad day for stats or something, but it doesn't look like there's many good days left.

For clarity's sake I am still in the IRC demographic[2], but that's no use if no bugger else is using it. I'd love to get back into it if there's anywhere not-a-dead-software-support-channel to hang out but every time this comes up the usage stats just get smaller and smaller.

For what it's worth I rarely use Discord and dislike that back-and-forth knowledge for software communities is now locked away behind some rando company's sign-up form. If I ever set up a new community it'll have to be forum based I think.

[1] https://netsplit.de/networks/top100.php

[2] Literally my entire career was born in IRC. Wanted to make an IRC bot, figured that out, some other stuff happened, was seen as a tech type, asked to help admin a network I frequented, learned how to admin a Linux box, time passes, got a job doing sysadmin work.

I do miss IRC, made a whole bunch of internet friends on it and it took me down a career path I only sometimes regret.


Reactions are cancer. If you have something to say send a message.

EDIT: I can't reply to your other message but having to deal with people editing their messages is awful in any real time chat. Once you send a message it's sent and if you want to make changes send a new message. I once had someone gaslight me using message editing in Slack and never ever want to deal with that again.


I want to reach with an emoji. Sure I could reply with a custom emoji, but reactions just is a better way to do it without adding extra noise to the conversation.


:(


Any info on benchmarks ? Purely for curiosity sake ? "Back in my day" - server-overloads were a common thing, and the connection counts were in the low thousands ?

Would love to know the modern day connection-numbers with something like Go+Channels


Unrelated project with the same name (coincidentally written in the same language): https://github.com/ergo-services/ergo

"an actor based Framework for creating microservices using technologies and design patterns of Erlang/OTP in Golang"


What makes this "modern" specifically?


It supports IRCv3, so you may call it modern I guess.


more yaml config files insanity, happy that irc is not dead


God I miss the IRC days. EFnet, DALnet :(


Also EsperNet and Undernet


Surprised that Discord isn't used more in professional settings. Its a great alternative to Slack/Matrix/IRC even if it isn't open source.


Their branding is very "gamer." It's worked out great for them as they have cornered that market, but it doesn't surprised me that they aren't even considered when comparing chat clients in a work environment.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: