This is good stuff. We’ve been working (lightly) with sourcehut for this and it’s in my eyes one of the big steps forward.
IRC might be an old protocol, but the number one issue is purely one of client UX. Better on ramps and clients to get people to the communities where people are is the number one issue. I really strongly believe that this is improvements like this one will keep IRC competitive with proprietary systems like discord and slack.
I’m perfectly happy with paid up services that run entirely and exclusively on Free software. This ends up being a well tested and supported stack that anyone can run themselves, or have sr.ht host it for them.
What matters to me is that there’s a variety of free software tools to compete with proprietary stuff, and this is such an example.
It’s only a paid service if you use the sr.ht instance, sourcehut itself, including the stack that runs chats.sr.ht is entirely open source. You can host it yourself if you want.
rephrasing the title as “company/org X is offering irc bouncers” still would make it “news as in product announcment” for me, so still offtopic, just because many of us use IRC… Same as announcing a new free mail provider. The fact that it is paid is just another category of offtopic.
Had someone posted “Hey here’s an alternative to thelounge and irccloud” and “btw, sr.ht made this and offers this” would’ve been a good comment.
Just from the point of a normal user, I’m not mad at sr.ht or anything.
I know enough of ddevault to understand why he went with IRC instead of Matrix. But I think it is the wrong choice. There’s a reason why sr.ht uses git instead of CVS (or RCS). Similarly IRC should be replaced with Matrix.
I’m not sure Matrix is obviously better than IRC, especially not on a protocol level; it might have more features than IRC right now, but I think half of the point of the project was to try and fix that disparity (?)
We already have lots of Matrix clients that work pretty well; why should people not be allowed to work on IRC clients, too, especially since we don’t have as much development going on there?
I find that a very weird statement. If you’re talking about an org of a certain size you can say it makes sense they choose X over Y. But this is a very small org that provides a service to its paying customers, but most probably because they use IRC themselves. Nothing should be replaced if people are happy to use it.
Matrix is still AFAIK, Not Great™ to operate because the server guzzles resources and lacks a lot of moderation features (which can be hard to implement due to the DAG).
FWIW I’m running Synapse with a ton of open channels across multiple homeservers and I’m not running into any resource issues on a VPS with 2 GB of RAM (previously 1, but it was running a bit tight) and some swap. I expect Dendrite, the new Go homeserver, to cut resource usage down significantly once it stabilizes.
I don’t think this is a relevant critique. I do, personally, think that Matrix is the better protocol and I use it myself, but sr.ht uses IRC themselves and is just offering a service to its paying customers to use IRC. If you find that valuable, you can pay for it or use it along with your existing sr.ht account, and if you don’t, you don’t need to. 🤷 . If they used XMPP instead, they could even offer similar XMPP services.
That makes sense; I’m not sure that alone is an argument that Matrix is an unqualified better choice than IRC though. Matrix is a very heavy ecosystem that has relatively few implementations, actually setting up a homeserver is an arduous process, the homeservers tend to be pretty resource intensive which presents scalability issues, especially for a more “independent” service which is not backed by a cloud monopolist with compute resources coming out the wazoo. IRC is not federated, but the relative ease in which IRC servers are spun up and their undemanding operational requirement smake it far more effectively decentralised as an ecosystem than Matrix.
Matrix also seems not to fit a lot of the ‘ethos’ that sourcehut espouses; in-house developed software that’s for-purpose and aiming to be pragmatic in both terms of use and design, often using technologies and workflows that free software developers already regularly use. IRC fits into this category much neater than Matrix does. It also feels to me personally that the advantages of federation are not as pronounced in real-time (synchronous) chat as source control.
IRC servers must trust each other, so only trusted servers are allowed in the federation. Matrix, thanks to the state resolution protocol, can work without server administrators trusting each other. Much like email. Spam can still be a problem.
So Matrix and SMTP servers are vulnerable to spam attacks if they allow untrusted servers, and IRC servers are vulnerable to more attacks like kills from malicious operators. So yes, IRC requires a higher level of cooperation between servers, but it’s a matter of degree.
Federation between untrusted servers means spam cannot be solved on the server level. Matrix has some plans to solve spam with a reputation-based system.
IRC can be distributed through server-to-server connections, but IRC is not a federated protocol because these networks share a common view of users and channels for as long as they are connected, and there is no way to bridge communications with other networks at the level of the protocol itself.
Compare and contrast with XMPP and Matrix, where it’s perfectly possible to communicate with other on federated servers that have absolutely no relation to your homeserver, and there is clear delineation of the ownership of identities and rooms.
I don’t see any substance to the idea that IRC servers can’t federate with eachother while XMPP/Matrix servers can. All federated protocols form networks which can become fragmented by mismatches between software and policies.
You also contrast “a common view of users and channels” with a “clear delineation of the ownership of identities and rooms.” This arises from a fundamental difference in what the protocols offer, namely that XMPP offers persistent identities while IRC does not, but that has no bearing on whether a protocol supports federation. For a non-federated contrast to IRC/XMPP/Matrix, see ICQ.
perhaps you could lay out why ddevault would disagree, considering that he is unable to respond here (due to a series of incidents that lobste.rs has decided to keep secret)
This is good stuff. We’ve been working (lightly) with sourcehut for this and it’s in my eyes one of the big steps forward.
IRC might be an old protocol, but the number one issue is purely one of client UX. Better on ramps and clients to get people to the communities where people are is the number one issue. I really strongly believe that this is improvements like this one will keep IRC competitive with proprietary systems like discord and slack.
Of course it’s a good thing to have alternatives, but as it is a paid service I still think it’s spam.
I’m perfectly happy with paid up services that run entirely and exclusively on Free software. This ends up being a well tested and supported stack that anyone can run themselves, or have sr.ht host it for them.
What matters to me is that there’s a variety of free software tools to compete with proprietary stuff, and this is such an example.
Yes, I’m sure we all agree on that. :)
But compared to articles about IRCv3, modern-irc, or the internal workings of the service, this announcement is not exactly on-topic.
It’s only a paid service if you use the sr.ht instance, sourcehut itself, including the stack that runs chats.sr.ht is entirely open source. You can host it yourself if you want.
Yes, and still not the 2 application reps were linked but this.
would it be spam if it were a nominally free proprietary service which you pay for in data and attention?
rephrasing the title as “company/org X is offering irc bouncers” still would make it “news as in product announcment” for me, so still offtopic, just because many of us use IRC… Same as announcing a new free mail provider. The fact that it is paid is just another category of offtopic.
Had someone posted “Hey here’s an alternative to thelounge and irccloud” and “btw, sr.ht made this and offers this” would’ve been a good comment.
Just from the point of a normal user, I’m not mad at sr.ht or anything.
I know enough of ddevault to understand why he went with IRC instead of Matrix. But I think it is the wrong choice. There’s a reason why sr.ht uses git instead of CVS (or RCS). Similarly IRC should be replaced with Matrix.
I’m not sure Matrix is obviously better than IRC, especially not on a protocol level; it might have more features than IRC right now, but I think half of the point of the project was to try and fix that disparity (?)
We already have lots of Matrix clients that work pretty well; why should people not be allowed to work on IRC clients, too, especially since we don’t have as much development going on there?
I find that a very weird statement. If you’re talking about an org of a certain size you can say it makes sense they choose X over Y. But this is a very small org that provides a service to its paying customers, but most probably because they use IRC themselves. Nothing should be replaced if people are happy to use it.
Matrix is still AFAIK, Not Great™ to operate because the server guzzles resources and lacks a lot of moderation features (which can be hard to implement due to the DAG).
So on a resource front I think it definitely depends on the server implementation you use.
I’ve moved to using the conduit home server implementation which is using 500MB RES in some high volume channels.
I don’t have numbers on hand but dendrite and synapse both used gigs of RES mem iirc.
Now admittedly compare that to an ircd which is no doubt much lower.
As far as mod features yeah matrix can use more things in the spec, which probably will be hard to implement.
FWIW I’m running Synapse with a ton of open channels across multiple homeservers and I’m not running into any resource issues on a VPS with 2 GB of RAM (previously 1, but it was running a bit tight) and some swap. I expect Dendrite, the new Go homeserver, to cut resource usage down significantly once it stabilizes.
Synapse has improved a lot.
I don’t think this is a relevant critique. I do, personally, think that Matrix is the better protocol and I use it myself, but sr.ht uses IRC themselves and is just offering a service to its paying customers to use IRC. If you find that valuable, you can pay for it or use it along with your existing sr.ht account, and if you don’t, you don’t need to. 🤷 . If they used XMPP instead, they could even offer similar XMPP services.
Do you mind clarifying what parallels you’re drawing between CVS vs Git and IRC vs Matrix?
CVS and IRC are hosted on a central server, Git and Matrix are distributed/federated.
That makes sense; I’m not sure that alone is an argument that Matrix is an unqualified better choice than IRC though. Matrix is a very heavy ecosystem that has relatively few implementations, actually setting up a homeserver is an arduous process, the homeservers tend to be pretty resource intensive which presents scalability issues, especially for a more “independent” service which is not backed by a cloud monopolist with compute resources coming out the wazoo. IRC is not federated, but the relative ease in which IRC servers are spun up and their undemanding operational requirement smake it far more effectively decentralised as an ecosystem than Matrix.
Matrix also seems not to fit a lot of the ‘ethos’ that sourcehut espouses; in-house developed software that’s for-purpose and aiming to be pragmatic in both terms of use and design, often using technologies and workflows that free software developers already regularly use. IRC fits into this category much neater than Matrix does. It also feels to me personally that the advantages of federation are not as pronounced in real-time (synchronous) chat as source control.
what do you mean by this? IRC networks consist of many interconnected servers run by different people
IRC is a closed federation. Matrix/XMPP are open federations (that can be limited by allow/denylists or firewalls)
IRC servers can have allow/denylists and firewalls too. What makes it closed and the others open?
IRC servers must trust each other, so only trusted servers are allowed in the federation. Matrix, thanks to the state resolution protocol, can work without server administrators trusting each other. Much like email. Spam can still be a problem.
So Matrix and SMTP servers are vulnerable to spam attacks if they allow untrusted servers, and IRC servers are vulnerable to more attacks like kills from malicious operators. So yes, IRC requires a higher level of cooperation between servers, but it’s a matter of degree.
Federation between untrusted servers means spam cannot be solved on the server level. Matrix has some plans to solve spam with a reputation-based system.
I don’t know what you mean by “on the server level.”
IRC can be distributed through server-to-server connections, but IRC is not a federated protocol because these networks share a common view of users and channels for as long as they are connected, and there is no way to bridge communications with other networks at the level of the protocol itself.
Compare and contrast with XMPP and Matrix, where it’s perfectly possible to communicate with other on federated servers that have absolutely no relation to your homeserver, and there is clear delineation of the ownership of identities and rooms.
I don’t see any substance to the idea that IRC servers can’t federate with eachother while XMPP/Matrix servers can. All federated protocols form networks which can become fragmented by mismatches between software and policies.
You also contrast “a common view of users and channels” with a “clear delineation of the ownership of identities and rooms.” This arises from a fundamental difference in what the protocols offer, namely that XMPP offers persistent identities while IRC does not, but that has no bearing on whether a protocol supports federation. For a non-federated contrast to IRC/XMPP/Matrix, see ICQ.
A more obvious choice in that case might be XMPP. Or even SMTP (see delta chat)
IRC is federated
perhaps you could lay out why ddevault would disagree, considering that he is unable to respond here (due to a series of incidents that lobste.rs has decided to keep secret)
https://drewdevault.com/2019/07/01/Absence-of-features-in-IRC.html
I connect to #sr.ht on libera using hexchat. Is this just a web frontend for that?
This is a combination two things
It is possible to use either of them, or both.