Hacker News Reader

Comment by welterde | Hacker News Reader

I have given it a fair spin a while ago and I wasn't impressed at all (too many problems.. even with simple 2-person chat). Distributed database based chat isn't really the way to go to get something reliable (where nothing gets even close to IRC).

Also there are new modern irc servers around (such as Oragono) that integrate lots of things that are often missed/bolted on externally, like history, bouncer, authentication, etc.

View on HN

Try giving it another spin. Matrix-Synapse is under constant development and lots of bugs have been fixed each release.

I've found the matrix-synapse homeserver I run to be stable. Along with Element-desktop and the Element android app it's been a great experience for me.

With both of those, you don't need to worry about history or bouncers, as history gets synched even if you power down your homeserver and back up again like I do.

And authentication comes as a by-product of matrix-synapse/Element.

I also love url and picture previews displayed directly in Element (and other clients) by way of synapse - far nicer experience than the text-only of IRC in my opinion.

I think IRC has had its day. At least with myself.

How does one moderate a room if there are infinite home servers with infinite identities?

I agree Matrix hasn't seen the level of attacks IRC got. Once it has been through that we will see if it is really a viable alternative.

You can block users or homeservers, or even go allowlist only, I believe.

I think there's work on some sort of reputation based system but afaik it's not there yet.

Disagree. As an open chat platform -- ie. not for private/confidential communications, to me, IRC is still superior to Matrix. We use it at work in parallel to IRC, and it still happens today (at least with elements.io) that a message or two can get lost when you restart your client in an unfortunate moment, and sometimes channel user lists get out of sync, so you're addressing a person that's not there, or suddenly someone replies you don't see in the user list. It's happening rarely, but it does, and it is annoying.

IRC's concept of requiring an active TCP connection for your session is archaic but dead simple, and the only times you have to wonder whether or not someone received your message is if they got a ping timeout shortly after, and the user list might get out of sync once in a honeymoon when there's a net-split. Nothing about IRC changes anymore, so you won't get surprised by regressions and bug fixes every month. I can see how people miss long multi-line messages and animated gifs in IRC, but I just don't. It's straight forward text communications, no bullshit.

I genuinely don't understand how you are concerned about "losing messages" when that is literally the baseline for IRC. Every person needs their own bouncer if they don't want any message to be lost to them when their machine disconnects from the internet. And if your bouncer loses connection you won't get the messages either.

IRC doesn't lose messages. Everyone you see in the channel gets the message, everybody else doesn't. No guessing games. That's what gp meant.

Should be the same for Matrix really, if your client manages to send it to the server.

> and it still happens today (at least with elements.io) that a message or two can get lost when you restart your client in an unfortunate moment

Is that unlucky moment during Element sending/trying to send the message to the server?

In this case Element stores messages now until they are sent (since 1.7.26).

Otherwise, don't see how this could happen.

> I also love url and picture previews displayed directly in Element (and other clients) by way of synapse - far nicer experience than the text-only of IRC in my opinion.

What is the difference with IRC clients showing URL/picture in terms of experience?

Realistically, IRC is far from reliable. Netsplits, messages out of order or getting lost, and so on - these are just the problems of having a distributed system of any kind, whether it's a federated network or just a couple of IRC servers.

The difference is that IRC doesn't try to address these issues and just lets them happen, whereas Matrix does try and sometimes gets it wrong (more due to implementation bugs than protocol issues).

I don't think it's fair to conclude that IRC is "more reliable" on that basis - if anything, I would say that Matrix comes out on top here despite the existing implementation issues. At least it eventually gets things into the right state.

Wholeheartedly agree with the above.

Also remembering IRC's netsplits resulting in IRC Services being split off and resultant and inevitable chaos when the netsplits end.

It's not really as much of an issue these days as it used to be.

And like I said.. you can get that all in a neatly integrated package where you don't have to worry about any of that anymore.

Sure netsplits happen, but at least I can still communicate with people that are on the same side of the split (and know exactly who they are). I never had the same issues as with Slack, Matrix, etc. where I just couldn't communicate at all for > 10 minutes.

And frankly I don't really care about it magically back filling the log later on, since the moment has passed. I value "Availability" above all else. And here IRC is unparalleled.

And improving upon the netsplits without breaking this aspect is really quite difficult.

The whole point of Matrix is you run your own matrix-synapse homeserver, so if the people you know are also connecting to your homeserver, and there's a matrix equivalent of a netsplit, you'll still be talking to those on yours - with the bonus of history backfill when your server reconnects to some other federated server.

Same happening as IRC - but with a different and more resilient protocol.

I also think including Slack along with Matrix is incorrect, as Slack is - like Discord - a centrally controlled walled garden. Matrix is not like those two at all.

That doesn't really help since the home server more corresponds to my irc client (or something like quassel-core or a bouncer) and not a irc server and will just have me as a user and no one else.

The Matrix architecture is much closer to the one used by Jabber Multi User Chat (with perhaps a fancier MUC protocol) than IRC.

That's not true though - you'll still be talking to everyone on every homeserver that yours can reach (or can be reached transitively)! When matrix.org went down for a bit a few years ago, I could talk in the same rooms with everyone on a homeserver that wasn't matrix.org flawlessly, even though the room was first created on matrix.org. I struggle to see how Matrix could be less available than IRC, where I've experienced many more netsplits.

Yes it is possible to mirror rooms, but last I checked that had to be setup manually? Or does synapse do that automatically now?

In any case that wasn't my point earlier. That was that I never had the issue on IRC that my homeserver somehow got stuck for several minutes while it did "something" in the room resolution protocol before suddenly catching up all of a sudden. And that I'll take netsplits any day over it being stuck.

I'm not sure what you mean by mirroring rooms - rooms don't have any one particular home or special server, they exist across all participating servers always and automatically.

I've never experienced what you're describing with the homeserver getting stuck while it did something, though I have had Element Android time out and seemingly not notice for a while & keep spinning, but that was the client's fault, not the server. My best guess is that whatever you experienced did get fixed!

Yes, but you are not syncing between all of them (since that would scale quite badly), but directed graph like in IRC (if I understand the specs correctly anyway). Edit: Oh.. or does it really sync between all servers (in which case I didn't quite understand the spec I guess)? Then that solves netsplits quite well at the cost of quite poor scalability.

Not sure what the issue was in the end, but I have had it with all clients I had tried (mobile, desktop, ..).

Re: edit, yep I believe it is full mesh sync for homeservers in a room, but if for some reason two can't communicate they can get the graph from other servers. It's eventually consistent if the homeservers are connected through any path, but it tries to be full-mesh. Scalability I think will be tackled to make P2P more practical, though.

Sorry you had that issue!

I agree that full mesh network is bad for scaling, but IRC's directed graph—manually configured even—is bad for availability. There is some talk about making the routing better, but I guess it's not in near future..

In Matrix it could be a problem, but practically it's not a problem even in the largest room #matrix:matrix.org with probably thousands of servers. But it makes joining that room quite slow and resource intensive.

Of course there is no IRC network with thousands of servers, because accepted hosts are well curated by the rules of the IRC network whereas any Matrix server can join the global federation. Granted, you don't need to join a chat network with an IRC server, but then neither does a Matrix server.

Incorrect, as you can configure your homeserver to be a public server or an invite-only server where you can have your chums join your homeserver - and thanks to federation even if there is some break in comms between your homeserver and another federated server - say the matrix.org server (which runs on the same matrix-synapse you'd be running) - it's possible for the federation to route around the problem - which, exactly like IRC's netsplit, will resolve eventually, but with the added advantage of synching history.

We are conflating things here, since the architecture of IRC and Matrix are not the same. Since due to the federated nature each room will be different - like it is in Jabber.

I am not talking about talking to my friends (since that's already solved with a private irc network), but for random people on rather large public rooms, where everyone will be isolated to their homeserver without manual configuration (granted.. since we have some big homeservers like matrix.org probably they'll able to continue chatting in the room).

Edit: Turns out I misremembered the federation algorithm from the spec - seems like it is indeed currently full-mesh and not a directed graph so I retract my remark.

Yeah it's more about user psychology/ergonomy. A Blunt tool that expose its limit can be preferred to a potentially better one that create more unknown failures. (Not thinking about SDV)

Reply on news.ycombinator.com