IRCv3 2022 Spec round-up(ircv3.net)
ircv3.net
IRCv3 2022 Spec round-up
https://ircv3.net/2022/11/20/spec-round-up
130 comments
Is there a modern client and server that supports all of these recent additions?
Here are my biased recommendations ;-)
a. Ergo [1] as the server for a greenfield setup
b. Gamja [2] and Goguma [3] ) as clients
c. Soju [4] as a bouncer for non-Ergo networks
[1] https://github.com/ergochat/ergo [2] https://sr.ht/~emersion/gamja/ [3] https://sr.ht/~emersion/goguma/ [4] https://sr.ht/~emersion/soju/
a. Ergo [1] as the server for a greenfield setup
b. Gamja [2] and Goguma [3] ) as clients
c. Soju [4] as a bouncer for non-Ergo networks
[1] https://github.com/ergochat/ergo [2] https://sr.ht/~emersion/gamja/ [3] https://sr.ht/~emersion/goguma/ [4] https://sr.ht/~emersion/soju/
Also throwing a great terminal client in the mix: https://git.sr.ht/~taiite/senpai
They do have pages listing client[1] and server[2] support. (Behind the “Support” button in the navigation bar, which is perfectly logical, but I needed a couple of seconds to overcome my conditioning and convince myself this may really be the kind of “support” they are talking about.)
[1] https://ircv3.net/software/clients
[2] https://ircv3.net/software/servers
[1] https://ircv3.net/software/clients
[2] https://ircv3.net/software/servers
In Emacs-land rcirc supports a bunch of them:
https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/net/rc...
https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/net/rc...
How's rcirc compared to erc?
I think it comes down to personal preferences. rcirc is a single file. ERC is more modular, it has the core in one file and a bunch of modules can be pulled in for extra functionality.
I originally went with rcirc because I preferred the way it handles logging: it maintains a separate log buffer and you can format the local logs separate from the display format. ERC logging works by writing out the recent portions the buffer itself. Both are very customizable though, lots of variables and hooks so it should be possible to tweak either one to your taste.
I originally went with rcirc because I preferred the way it handles logging: it maintains a separate log buffer and you can format the local logs separate from the display format. ERC logging works by writing out the recent portions the buffer itself. Both are very customizable though, lots of variables and hooks so it should be possible to tweak either one to your taste.
Great, cheers
I don't think any client supports them all, but mIRC and Quassel make the best use of them so far in my opinion.
[deleted]
You will find a supported features matrix here for clients : https://ircv3.net/software/clients and here for servers : https://ircv3.net/software/servers
I firmly believe support feature matrix is what ultimately killed XMPP for masses - it always felt like you don't know what you get with given client or server and never quite worked fine.
That and advent of zero-fuss web clients
That and advent of zero-fuss web clients
I played around with Ergo and Kiwi IRC some months ago.
https://github.com/ergochat/ergo
https://github.com/kiwiirc/kiwiirc
https://github.com/ergochat/ergo
https://github.com/kiwiirc/kiwiirc
doublerabbit(1)
Unfortunately IRC has failed to keep up with the U/X of centralized chat services like discord which is a shame because an open protocol chat seems needed for the internet.
Why does open protocol usually mean crippled U/X?
Why does open protocol usually mean crippled U/X?
I would say the opposite rather, the UX of IRC clients (eg, HexChat) is so polished and refined, it puts all the proprietary chat services (and their clients) to shame.
> Why does open protocol usually mean crippled U/X?
Open is entirely unrelated to that, but optional features means crippled UI/UX in the long run. Some server won't support it so users can't use it, or some client won't support it so they will see garbage/nothing when others use that feature.
XMMP showed that well enough and it seems IRCv3 follows suit.
Open is entirely unrelated to that, but optional features means crippled UI/UX in the long run. Some server won't support it so users can't use it, or some client won't support it so they will see garbage/nothing when others use that feature.
XMMP showed that well enough and it seems IRCv3 follows suit.
[deleted]
FWIW TheLounge [1] and Convos [2] can front-end an IRC server giving it much of the look of a modern client and also chat persistence when using TheLounge in private mode. The trade-off in my opinion is scalability. With a bog standard IRCD I can handle tens of thousands of clients per node. Adding web persistent increases memory usage.
[1] - https://github.com/thelounge https://thelounge.chat/
[2] - https://github.com/convos-chat/convos/ https://convos.chat/
[1] - https://github.com/thelounge https://thelounge.chat/
[2] - https://github.com/convos-chat/convos/ https://convos.chat/
Who pays for the UI to be developed?
If open source/community, then chronically starved for resources and contributors have divided directions.
If commercial, then they want to differentiate and do embrace, extend, extinguish, in order to drive everybody to their client.
I have come to believe, that the protocol spec and servers, is just the easy part of chat apps.
If open source/community, then chronically starved for resources and contributors have divided directions.
If commercial, then they want to differentiate and do embrace, extend, extinguish, in order to drive everybody to their client.
I have come to believe, that the protocol spec and servers, is just the easy part of chat apps.
In an ideal (and therefore unrealistic) world, it would be done by the UX designer/dev equivalent counterparts of the ones developing these open source softwares.
Why do low level engineers work freely on FOSS but designers or UX devs don't is the question.
Why do low level engineers work freely on FOSS but designers or UX devs don't is the question.
Proper UX designers would be ridiculed in the FOSS world because everything is bloat or too corporate. If it doesn't look like Windows XP or a 70s terminal it isn't welcome in FOSS.
Gnome is probably the best example of good design in the FOSS space and look how people talk about it. Even in this thread you have people claiming being able to view images and video inline in a chat is an "anti feature". Can you imagine trying to design a product for people so detached from reality?
Gnome is probably the best example of good design in the FOSS space and look how people talk about it. Even in this thread you have people claiming being able to view images and video inline in a chat is an "anti feature". Can you imagine trying to design a product for people so detached from reality?
Because they have different opinions doesn't mean they are detached from reality. IRCCloud shows images in the feed, for instance. I just like the fact that I don't need that overhead in my client if I don't want it.
Because extremely few programmers which are attracted by creating protocols have U/X design skills.
In fact, they will probably say something like "just use the CLI, it's a superior way anyway".
In fact, they will probably say something like "just use the CLI, it's a superior way anyway".
There should be a way to decouple the UX from the program and if people want a Discord “skin” for IRC that looks nearly 1:1 they should be able to have that.
I don't think that would help. The IRC protocol is missing so many messaging features that platforms like Discord have. Just looking like Discord wouldn't fix that.
This very initiative (IRC 3) seems to be trying to fix that. At least parts of it.
What doesnt it have?
This is lipstick on a pig. I'd be perfectly happy with a client that looks like IRC but has the features of Discord. I'd like to be able to chat on my phone without running an external service that provides a modern HTTP based protocol.
Not sure I get your point. Say you use IRCCloud on your phone, you don't need anything else, do you?
IRCCloud is fine, but it's more expensive than Discord, the UX is not quite as nice for reasons inherent to the IRC model, and it's not really more open in any substantive sense (my phone will be running the proprietary IRCCloud application that speaks a proprietary IRCCloud protocol). So why would one bother?
> and it's not really more open in any substantive sense [...]. So why would one bother?
Not for you, because you want to use a turnkey solution, and you don't want to pay for it (instead relying on whatever model they have where you are the product, I guess?). But if you use IRC to talk to me, I can run my own bouncer for free, and I can run the client I want. I can even write my bouncer and my client, and still talk to you.
That's infinitely more open than Discord. It's just that you don't care about others.
Not for you, because you want to use a turnkey solution, and you don't want to pay for it (instead relying on whatever model they have where you are the product, I guess?). But if you use IRC to talk to me, I can run my own bouncer for free, and I can run the client I want. I can even write my bouncer and my client, and still talk to you.
That's infinitely more open than Discord. It's just that you don't care about others.
> Not for you, because you want to use a turnkey solution, and you don't want to pay for it (instead relying on whatever model they have where you are the product, I guess?). But if you use IRC to talk to me, I can run my own bouncer for free, and I can run the client I want. I can even write my bouncer and my client, and still talk to you.
> That's infinitely more open than Discord. It's just that you don't care about others.
I care a bit about whether you can run your bouncer. But I also care about whether non-technical people can talk to me without an unreasonable level of effort. Expecting everyone else to pay extra for a worse experience so that you can use it the way you want seems pretty entitled.
> That's infinitely more open than Discord. It's just that you don't care about others.
I care a bit about whether you can run your bouncer. But I also care about whether non-technical people can talk to me without an unreasonable level of effort. Expecting everyone else to pay extra for a worse experience so that you can use it the way you want seems pretty entitled.
> Expecting everyone else to pay extra for a worse experience so that you can use it the way you want seems pretty entitled.
Yeah, the price is an issue indeed. I guess that's why we keep having monopolies: it's easier to get VC money if you can ensure user lock-in, and it's easier to make a nice UX if you have VC money.
Now, don't think you don't pay those proprietary messengers. You just pay differently.
Yeah, the price is an issue indeed. I guess that's why we keep having monopolies: it's easier to get VC money if you can ensure user lock-in, and it's easier to make a nice UX if you have VC money.
Now, don't think you don't pay those proprietary messengers. You just pay differently.
IRCCloud regularly gets stuck, has to be manually reset, doesn’t cope well with network changes and seems to have database overloads once per day.
I use it, but discord’s mobile client is a far better experience.
I use it, but discord’s mobile client is a far better experience.
But this is not fundamentally a limitation of the IRC protocol, is it?
It’s got nothing to do with the IRC protocol. The mobile application is effectively a remote for a client running in their datacenter.
I’m just pointing out that… well, discord has advantages other than the protocol.
I’m just pointing out that… well, discord has advantages other than the protocol.
Irssi's UX is better than that of any other chat software, though. Why it hasn't been replicated for things like XMPP and Matrix is probably due to the more difficult and featureful state transitions of those protocols.
There are several XMPP clients trying to replicate -more or less freely- the same experiences, such as poezio [1] or profanity [2]. YMMV of course, and nothing will be a carbon copy of irssi, except if you use a plugin (but in my experience bolting another protocol on top of a client for another will result in a poor UX).
I do believe there are TUI clients for Matrix, but I am unsure of their maturity and state, or how they compare to Irssi.
[1] https://poez.io/en/ [2] https://profanity-im.github.io/
I do believe there are TUI clients for Matrix, but I am unsure of their maturity and state, or how they compare to Irssi.
[1] https://poez.io/en/ [2] https://profanity-im.github.io/
I was going to say, "Have you tried poezio?".
I switched over from irssi to poezio a few years ago (with a self-hosted biboumi as XMPP<->IRC gateway) and I don't miss irssi (anymore).
Of course, the transition was a bit bumpy, but I think that'd go both ways. As someone else said, it's not a direct replica. Yet, it feels close enough and not too close for the uncanny valley.
Of course, the transition was a bit bumpy, but I think that'd go both ways. As someone else said, it's not a direct replica. Yet, it feels close enough and not too close for the uncanny valley.
[deleted]
Which alternatives have you tried?
Do any IRC clients support inline media upload/viewing, profile pictures, voice/video calls, or replies/threading? These are the things I would consider the core essentials of IM. Any serious platform has all of this plus a whole lot more.
The web front-ends multi-user clients I linked in this thread support file sharing, image uploading. For voice one could run either uMurmur or Murmur that also provides text and voice chat. People can be given permissions to create channels on Murmur whereas uMurmur you static define the channels as it is meant to run on home routers. There is a phone client for Murmur called Mumla. Murmur also supports file sharing but it was not really optimized for that to be used by a large number of people at once in my opinion. The voice quality of the OPUS codec is incredible. Open source video chat would likely be Jitsi and is a bit more complex.
These are not all-in-one solutions yet and certainly not as low-friction as most would prefer. I expect development to improve in all of these platforms as the centralized platforms go through growing pains and buy-outs.
Even then I would not expect everyone to migrate to these self hosted platforms and in a way I actually hope they do not or those platforms may get the unwanted attention from the powers that aim to protect us from our speech.
These are not all-in-one solutions yet and certainly not as low-friction as most would prefer. I expect development to improve in all of these platforms as the centralized platforms go through growing pains and buy-outs.
Even then I would not expect everyone to migrate to these self hosted platforms and in a way I actually hope they do not or those platforms may get the unwanted attention from the powers that aim to protect us from our speech.
I think I would leave any platform that added most of these and that it is better for IRC to stay as-is so people like me have places to chat. People like you already have Discord/etc.
Have you tried IRCCloud?
So to get all or some of those features you can use IRCCloud. Is it the same as IRC having those features?
I could (and do) access IRC over Matrix and then I also have access to those features. But in this case also users not using the same client or same server as I am get to see those things.
I could (and do) access IRC over Matrix and then I also have access to those features. But in this case also users not using the same client or same server as I am get to see those things.
Ok maybe I should take them separately:
> Do any IRC clients support inline media upload/viewing, profile pictures, voice/video calls, or replies/threading? These are the things I would consider the core essentials of IM. Any serious platform has all of this plus a whole lot more.
Media upload is purely on the client side. If IRCCloud lets you to drag-and-drop an image, uploads it to some server, and then sends the URL, then that's still entirely IRC (I will receive the URL), but IRCCloud is making it easier for you.
Same for viewing content: I send a URL, and your IRCCloud will show a preview (image/video), while my client won't. That's purely on the client side.
For voice and video calls, IMO I don't want it in my messaging app. I can use my browser for that, or a dedicated app. And again, share a link to my videoconference over IRC.
Replies/threading are a tricky one. I hate the replies in Discord, and I don't really get threads. I see Slack channels where the rule is "answer only in threads", which to me says that they want a forum (like Discourse), not an instant messaging app.
> But in this case also users not using the same client or same server as I am get to see those things.
Pretty sure that if you use replies or threads in Matrix when talking in an IRC channel, then people on IRC won't see them as replies or threads.
> Do any IRC clients support inline media upload/viewing, profile pictures, voice/video calls, or replies/threading? These are the things I would consider the core essentials of IM. Any serious platform has all of this plus a whole lot more.
Media upload is purely on the client side. If IRCCloud lets you to drag-and-drop an image, uploads it to some server, and then sends the URL, then that's still entirely IRC (I will receive the URL), but IRCCloud is making it easier for you.
Same for viewing content: I send a URL, and your IRCCloud will show a preview (image/video), while my client won't. That's purely on the client side.
For voice and video calls, IMO I don't want it in my messaging app. I can use my browser for that, or a dedicated app. And again, share a link to my videoconference over IRC.
Replies/threading are a tricky one. I hate the replies in Discord, and I don't really get threads. I see Slack channels where the rule is "answer only in threads", which to me says that they want a forum (like Discourse), not an instant messaging app.
> But in this case also users not using the same client or same server as I am get to see those things.
Pretty sure that if you use replies or threads in Matrix when talking in an IRC channel, then people on IRC won't see them as replies or threads.
> Pretty sure that if you use replies or threads in Matrix when talking in an IRC channel, then people on IRC won't see them as replies or threads.
Replies are rendered to IRC with a prefix indicating what they're responding to, but people from IRC cannot "reply" (though maybe some ad-hoc protocol could be devised for this). I don't know if threads are handled the same way, but I assume they are. Of course you can't really bring either of these features to a platform that doesn't support them without modifying the platform.
By "other servers" I meant other Matrix servers, as it is the system that natively supports the features.
Replies are rendered to IRC with a prefix indicating what they're responding to, but people from IRC cannot "reply" (though maybe some ad-hoc protocol could be devised for this). I don't know if threads are handled the same way, but I assume they are. Of course you can't really bring either of these features to a platform that doesn't support them without modifying the platform.
By "other servers" I meant other Matrix servers, as it is the system that natively supports the features.
Matrix could bridge tem as IRC replies so at least IRCCloud users could see/write them, but are not interested in supporting them for now: https://github.com/matrix-org/matrix-appservice-irc/pull/150...
The issue I have with Matrix/IRC/IRCv3 compared to Discord is that they don't really work well with public communities.
Discord's server/channel/role system is amazing, and I don't know why everyone else isn't replicating it.
For instance, let's take the Pine64 Discord server. It has a grand total of 27 channels split into 10 categories (including top-level). Using Discord's permissions system, some of those channels are read-only like #announcements.
Pine64's server is also bridged to Matrix. Matrix requires every single channel to be bridged individually into their own Matrix chat, just look at this table (https://wiki.pine64.org/wiki/Main_Page#Chat_Platforms)! In fact, some of the channels aren't even bridged at all! Meanwhile on Discord, everything's all in one easy to use place. You just join the server, and that's it.
But what about Matrix spaces? Aren't those the equivalent of Discord servers? The issue is that rather than an integrated experience, Matrix servers are just a built-in version of the table I listed above. You still have to leave/join chats individually and it doesn't even have categories!
But that's all from a user's perspective, what about from a server admin's perspective? Discord's permission system is great and flexible, and Matrix's system is just kind of bad. In case you don't know Matrix's system from what i understand is basically: every user gets a permission level number, and users with certain levels can do certain things. That's it, no flexibility whatsoever.
Meanwhile on Discord, you can create roles which when given to users allow them to do certain things. Like anyone with a "Moderator" role can delete messages or ban people. But you could also make it so "moderators" can't delete messages, only ban people. And you can also make roles behave different on per-channel or per-category basis. You can even make it so users can't see a channel at all without a role (for instance, a server I'm an admin on has a #mod-chat channel and a #admin-chat channel).
Matrix's system just can't do that. And it really doesn't integrate with their Spaces system. There's no way to make it so only certain people can see certain channels in a Matrix Space. In fact, there's no way to manage permissions for an entire Matrix Space at all! It's limited to a per-chat basis.
And that long-winded rant is why I will stick with Discord.
Discord's server/channel/role system is amazing, and I don't know why everyone else isn't replicating it.
For instance, let's take the Pine64 Discord server. It has a grand total of 27 channels split into 10 categories (including top-level). Using Discord's permissions system, some of those channels are read-only like #announcements.
Pine64's server is also bridged to Matrix. Matrix requires every single channel to be bridged individually into their own Matrix chat, just look at this table (https://wiki.pine64.org/wiki/Main_Page#Chat_Platforms)! In fact, some of the channels aren't even bridged at all! Meanwhile on Discord, everything's all in one easy to use place. You just join the server, and that's it.
But what about Matrix spaces? Aren't those the equivalent of Discord servers? The issue is that rather than an integrated experience, Matrix servers are just a built-in version of the table I listed above. You still have to leave/join chats individually and it doesn't even have categories!
But that's all from a user's perspective, what about from a server admin's perspective? Discord's permission system is great and flexible, and Matrix's system is just kind of bad. In case you don't know Matrix's system from what i understand is basically: every user gets a permission level number, and users with certain levels can do certain things. That's it, no flexibility whatsoever.
Meanwhile on Discord, you can create roles which when given to users allow them to do certain things. Like anyone with a "Moderator" role can delete messages or ban people. But you could also make it so "moderators" can't delete messages, only ban people. And you can also make roles behave different on per-channel or per-category basis. You can even make it so users can't see a channel at all without a role (for instance, a server I'm an admin on has a #mod-chat channel and a #admin-chat channel).
Matrix's system just can't do that. And it really doesn't integrate with their Spaces system. There's no way to make it so only certain people can see certain channels in a Matrix Space. In fact, there's no way to manage permissions for an entire Matrix Space at all! It's limited to a per-chat basis.
And that long-winded rant is why I will stick with Discord.
You list out a lot of propositions in your comment about what Matrix's role model can or cannot do compared to Discord's, but only some of them are actually true.
To attempt to distill the real deficiencies:
- Non-monotonic roles. You can't have Deleters (who can only delete things, but not ban) and Banners (who can only ban, but not delete things) in a single channel (room).
- Auto-joining rooms upon joining a space.
- Room roles/permissions inheriting from space roles/permissions.
- A permission to control which members of a space can see a channel.
Luckily all of those except the first one seem easily built upon the current protocol by relatively tame extensions.
The last two in particular stem from the fact that spaces are too "weak" to support this at the moment: unlike in Discord, a room can be in more than one space at once. This means you can use spaces to define your own private categorizations, which is something Discord doesn't support at all. However, to be able to support those last two use cases, we'd need to define a mechanism by which a room could designate one special space as the owning space for that room.
On the other hand, Matrix does have:
- Categories. These are simply modeled with spaces within spaces. Spaces can be infinitely nested.
- The ability to make roles behave differently on a per-channel and per-space basis.
- A role which can only delete things but not ban people, or a role which can ban people but not delete things. You just can't have both at the same time.
To attempt to distill the real deficiencies:
- Non-monotonic roles. You can't have Deleters (who can only delete things, but not ban) and Banners (who can only ban, but not delete things) in a single channel (room).
- Auto-joining rooms upon joining a space.
- Room roles/permissions inheriting from space roles/permissions.
- A permission to control which members of a space can see a channel.
Luckily all of those except the first one seem easily built upon the current protocol by relatively tame extensions.
The last two in particular stem from the fact that spaces are too "weak" to support this at the moment: unlike in Discord, a room can be in more than one space at once. This means you can use spaces to define your own private categorizations, which is something Discord doesn't support at all. However, to be able to support those last two use cases, we'd need to define a mechanism by which a room could designate one special space as the owning space for that room.
On the other hand, Matrix does have:
- Categories. These are simply modeled with spaces within spaces. Spaces can be infinitely nested.
- The ability to make roles behave differently on a per-channel and per-space basis.
- A role which can only delete things but not ban people, or a role which can ban people but not delete things. You just can't have both at the same time.
> However, to be able to support those last two use cases, we'd need to define a mechanism by which a room could designate one special space as the owning space for that room.
This actually exists, so a room knows its canonical parent space, but the feature is not used: https://spec.matrix.org/unstable/client-server-api/#mspacepa...
This actually exists, so a room knows its canonical parent space, but the feature is not used: https://spec.matrix.org/unstable/client-server-api/#mspacepa...
This was a much better (and more accurate) description of my complaints about Matrix's permissions system. Thanks!
Insomuch as this may be an adequate design, for many cases the fact that it’s not open source is a nonstarter. I’d certainly never touch it for my teams and workgroups at work, because we need to be able to host it and isolate and harden.
Discord is also sorta prone to this weird and cringy sort of internet culture which regular people find a little gross, I’d think.
I’m old enough to distinctly remember the rise of IRC and I can’t see a reason aside from better security for it to be reinvented rather than just updating the standard. Emojis and attachments and whatnot.
Discord is also sorta prone to this weird and cringy sort of internet culture which regular people find a little gross, I’d think.
I’m old enough to distinctly remember the rise of IRC and I can’t see a reason aside from better security for it to be reinvented rather than just updating the standard. Emojis and attachments and whatnot.
> [IRC, MSN/ICQ/etc, ...] is also sorta prone to this weird and cringy sort of internet culture which regular people find a little gross, I’d think.
Nothing new under the sun.
Nothing new under the sun.
For irc that just seems like a UI difference. Of course you can have announce only channels in irc, people have been doing that forever.
The big thing is that discord shows you all related channels on the project. If you are on libera, there isn't the same discoverability. So in a sense announcement only channels are much less useful because users cant find them (not to mention lack of history if you dont have a bouncer).
The big thing is that discord shows you all related channels on the project. If you are on libera, there isn't the same discoverability. So in a sense announcement only channels are much less useful because users cant find them (not to mention lack of history if you dont have a bouncer).
When hosting your own IRC server, you can "force-join" users to arbitrary channels to replicate what it's like to join a discord guild. Pine64 does it, for example.
It goes much farther than that I think the most interesting use of its API i've seen was using the dumb little reaction "press icon to add to the counter thing" as a way to opt in or confirm stuff.
I remember one server where the #welcome channel just have a bunch of "categories" to choose from and depending on which one you clicked you got assigned a role that unlocked a bunch of channels related to the topic. Some also used it to the new user onboarding where you got access once you read the rules and accepted it by clicking the reaction.
> So in a sense announcement only channels are much less useful because users cant find them (not to mention lack of history if you dont have a bouncer).
That's my issue with projects or corporations using discord for generic chat - it is entirely undiscoverable to outside world, can't just google a question.
I remember one server where the #welcome channel just have a bunch of "categories" to choose from and depending on which one you clicked you got assigned a role that unlocked a bunch of channels related to the topic. Some also used it to the new user onboarding where you got access once you read the rules and accepted it by clicking the reaction.
> So in a sense announcement only channels are much less useful because users cant find them (not to mention lack of history if you dont have a bouncer).
That's my issue with projects or corporations using discord for generic chat - it is entirely undiscoverable to outside world, can't just google a question.
See, you can decide to stick with discord, and discord can decide to not stick with you.
That's the difference.
"Your" discord "server" turns out to be neither of those.
That's the difference.
"Your" discord "server" turns out to be neither of those.
I agree with the sentiment that Discord is overall much nicer for Discord communities :p
No, but really, Matrix isn't quite there yet in terms of those nice and easy community management features, but what you listed isn't quite accurate, as others have pointed out.
Either way, besides Matrix, I'm also really interested in the development of Revolt[1], and I suspect you will be too :)
[1]: https://revolt.chat
[1]: https://revolt.chat
agree and the issues with IRC are so much more basic. there isn't even a built in history. i could miss DMs directly addressed to me or an important conversation just by being offline and have no way of even knowing. a technical user could set up a bouncer, but just using discord is much easier. for any of the 95% of general non-technical communities discord hosts, IRC is a complete non-starter.
You seem to complain mostly about the bouncer. There are services that will "just work" for you, like IRCCloud or chat.sr.ht (and certainly others). You just will just have history without knowing about what a bouncer is.
It's also difficult to have a good working permalink to Matrix chats that don't throw a bunch of errors for people. Nowhere as seamless as Discord's invite links.
Ask for mercy if you want to do multiple channels invite-only. Need to upgrade rooms first. Then the space is out of sync for some clients, some permalinks to chats break. Maybe it'll work, just maybe.
Ask for mercy if you want to do multiple channels invite-only. Need to upgrade rooms first. Then the space is out of sync for some clients, some permalinks to chats break. Maybe it'll work, just maybe.
Discord and IRC are not competitors. Discord is just a product you choose to use or not. Discord Inc. runs the servers, and you use whatever software they approve to connect. Using unapproved software could result in a ban from the service.
IRC is a set of protocols to enable a federated service. You choose which server implementation you want to host, and your users choose from dozens of available clients, which all work together because of the relevant standards, to which everyone has access.
The rest of your comment seems to be a comparison of Matrix, which is not IRC, and Discord. It's great that you've found a product you like, which suits your needs. Don't make the mistake of thinking IRC is competing with it, though. IRC will still be here long after Discord Inc. exits.
IRC is a set of protocols to enable a federated service. You choose which server implementation you want to host, and your users choose from dozens of available clients, which all work together because of the relevant standards, to which everyone has access.
The rest of your comment seems to be a comparison of Matrix, which is not IRC, and Discord. It's great that you've found a product you like, which suits your needs. Don't make the mistake of thinking IRC is competing with it, though. IRC will still be here long after Discord Inc. exits.
The protocols might not be competitors.
But that doesn't change the fact that Discord has been swallowing up almost every single community that either previously used IRC, or would have used IRC if it was created 10-20 years ago.
The sad fact is that other than openness (in several senses of the word), Discord delivers a much better experience to the communities that use it. It preserves scroll back. It has a proper mobile app that reliably delivers notifications (I'm not aware of anyway to do this with IRC, other than a closed and paid service like IRC cloud). It has moderation tools. It has community building tools and ways to split off sub-conversations. It has platform wide anti-spam. It both embeds images and videos, and stores them.
It is incredibly depressing watching communities die on IRC, either moving to discord, or being replaced by new communities on discord that serve the same role. Most of the ones still holding on are run by older people who have strong views on the importantness of openness.
I actively support those communities staying on IRC. But at the same time, I use discord myself, and I understand why it's winning.
But that doesn't change the fact that Discord has been swallowing up almost every single community that either previously used IRC, or would have used IRC if it was created 10-20 years ago.
The sad fact is that other than openness (in several senses of the word), Discord delivers a much better experience to the communities that use it. It preserves scroll back. It has a proper mobile app that reliably delivers notifications (I'm not aware of anyway to do this with IRC, other than a closed and paid service like IRC cloud). It has moderation tools. It has community building tools and ways to split off sub-conversations. It has platform wide anti-spam. It both embeds images and videos, and stores them.
It is incredibly depressing watching communities die on IRC, either moving to discord, or being replaced by new communities on discord that serve the same role. Most of the ones still holding on are run by older people who have strong views on the importantness of openness.
I actively support those communities staying on IRC. But at the same time, I use discord myself, and I understand why it's winning.
"It preserves scroll back."
For limited definitions of 'preserves' if you aren't a paying user.
"It has a proper mobile app that reliably delivers notifications"
Not really, you can't tell who pinged you half the time (and this is a common complaint from most everyone in a discord server with 70+K members.)
"It has moderation tools."
Limited ones unless you get a bot to add in granularity (such as duration of moderation action.) I can think of a few HTTP chat sites from the late 90s that had better moderation for all users (and a reverse-ignore feature, which seems to have just disappeared from everyone's collective memory.)
"It has platform wide anti-spam."
Which more often than not takes my pictures of rocks and flags them as NSFW. Useless.
"It both embeds images and videos, and stores them."
This is about the one thing it does right.
I should note IRC had video chat functionality with pIRCh98.
For limited definitions of 'preserves' if you aren't a paying user.
"It has a proper mobile app that reliably delivers notifications"
Not really, you can't tell who pinged you half the time (and this is a common complaint from most everyone in a discord server with 70+K members.)
"It has moderation tools."
Limited ones unless you get a bot to add in granularity (such as duration of moderation action.) I can think of a few HTTP chat sites from the late 90s that had better moderation for all users (and a reverse-ignore feature, which seems to have just disappeared from everyone's collective memory.)
"It has platform wide anti-spam."
Which more often than not takes my pictures of rocks and flags them as NSFW. Useless.
"It both embeds images and videos, and stores them."
This is about the one thing it does right.
I should note IRC had video chat functionality with pIRCh98.
> For limited definitions of 'preserves' if you aren't a paying user.
You might be thinking of slack. Discord preserves unlimited scroll back for everyone.
> Not really, you can't tell who pinged you half the time
Which is still an improvement over IRC.
> (and this is a common complaint from most everyone in a discord server with 70+K members.)
And how does a 70K user IRC channel handle this?
> Limited ones unless you get a bot to add in granularity (such as duration of moderation action.)
They recently added "Timeout bans", and other features to reduce the need for bots (regex actions that will auto-filter, flag or timeout on match).
Which is far more than IRC offers without needing a bot.
> can think of a few HTTP chat sites from the late 90s that had better moderation for all users
But discord isn't competing with HTTP chat sites from the late 90s. It's competing with IRC.
> I should note IRC had video chat functionality with pIRCh98.
I don't really think you can use a propriety feature of a single (obsolete) client to defend IRC.
It really doesn't matter what did what first, or what IRC could theoretically do if you extend it. The only thing that matters to users and communities is the that the out-of-the box experience for discord today is far better than the out-of-the box experience for IRC.
You might be thinking of slack. Discord preserves unlimited scroll back for everyone.
> Not really, you can't tell who pinged you half the time
Which is still an improvement over IRC.
> (and this is a common complaint from most everyone in a discord server with 70+K members.)
And how does a 70K user IRC channel handle this?
> Limited ones unless you get a bot to add in granularity (such as duration of moderation action.)
They recently added "Timeout bans", and other features to reduce the need for bots (regex actions that will auto-filter, flag or timeout on match).
Which is far more than IRC offers without needing a bot.
> can think of a few HTTP chat sites from the late 90s that had better moderation for all users
But discord isn't competing with HTTP chat sites from the late 90s. It's competing with IRC.
> I should note IRC had video chat functionality with pIRCh98.
I don't really think you can use a propriety feature of a single (obsolete) client to defend IRC.
It really doesn't matter what did what first, or what IRC could theoretically do if you extend it. The only thing that matters to users and communities is the that the out-of-the box experience for discord today is far better than the out-of-the box experience for IRC.
"You might be thinking of slack. Discord preserves unlimited scroll back for everyone."
Only if the server has been boosted enough to allow for it. Boosts = paying money.
"And how does a 70K user IRC channel handle this?"
It doesn't, the client is usually programmed to notify upon specified trigger words or the user name, and handles that itself.
"I don't really think you can use a propriety feature of a single (obsolete) client to defend IRC."
I'm not defending IRC - I'm simply saying IRC did it first.
Only if the server has been boosted enough to allow for it. Boosts = paying money.
"And how does a 70K user IRC channel handle this?"
It doesn't, the client is usually programmed to notify upon specified trigger words or the user name, and handles that itself.
"I don't really think you can use a propriety feature of a single (obsolete) client to defend IRC."
I'm not defending IRC - I'm simply saying IRC did it first.
> Only if the server has been boosted enough to allow for it. Boosts = paying money.
This just isn't true.
I'm on a server which has never been boosted and I can scroll back all the way to the server's creation with no limits.
This just isn't true.
I'm on a server which has never been boosted and I can scroll back all the way to the server's creation with no limits.
> For limited definitions of 'preserves' if you aren't a paying user.
What do you mean by this? I don't pay for Discord and I have never had any issues scrolling as far back as I want to.
> Not really, you can't tell who pinged you half the time (and this is a common complaint from most everyone in a discord server with 70+K members.)
Personally I have notifications disabled so I can't comment on that, but both the web client and the Android app have a specific view to list all past pings or replies.
> Limited ones unless you get a bot to add in granularity (such as duration of moderation action.) I can think of a few HTTP chat sites from the late 90s that had better moderation for all users (and a reverse-ignore feature, which seems to have just disappeared from everyone's collective memory.)
While limited, they are there by default and pretty convenient. And they're getting better.
What do you mean by this? I don't pay for Discord and I have never had any issues scrolling as far back as I want to.
> Not really, you can't tell who pinged you half the time (and this is a common complaint from most everyone in a discord server with 70+K members.)
Personally I have notifications disabled so I can't comment on that, but both the web client and the Android app have a specific view to list all past pings or replies.
> Limited ones unless you get a bot to add in granularity (such as duration of moderation action.) I can think of a few HTTP chat sites from the late 90s that had better moderation for all users (and a reverse-ignore feature, which seems to have just disappeared from everyone's collective memory.)
While limited, they are there by default and pretty convenient. And they're getting better.
"What do you mean by this? I don't pay for Discord and I have never had any issues scrolling as far back as I want to."
The servers need to be boosted to keep certain things like extended history preservation and what not available to the users of that server.
The servers need to be boosted to keep certain things like extended history preservation and what not available to the users of that server.
This just isn't true.
I'm on a server which has never been boosted and I can scroll back all the way to the server's creation with no limits.
I'm on a server which has never been boosted and I can scroll back all the way to the server's creation with no limits.
After seeing almost every single community I frequented on IRC move to Discord and some to Matrix over the last 10 years, I just don't agree that Discord is not competing. It's captured almost all of the users. IRC will always "exist" in the same way steam powered trains and analogue cameras exist. IRC certainly isn't relevant anymore.
Discord and IRC are competitors. Where do you think the terms servers and channels came from? Just because IRC is losing to Discord badly you can't just retroactively redefine IRC as a chat service for people who want to use something with an open protocol.
Those 3 product fill same function, chatting between people. Of course they are competitors, it's just IRC isn't competitive in normal people space.
The fact IRC might or might not choose to compete doesn't mean it isn't one of choices people wanting chatting app consider.
The fact IRC might or might not choose to compete doesn't mean it isn't one of choices people wanting chatting app consider.
In fact, the Matrix permission system allows for what you describe. For each room, you can define what actions a certain access level can perform.
Ya but there’s little client diversity. I can’t have discord running on a headless dev box and remote in to catch up. This is what irc better for terminal enthusiasts
The only reason you need to do that in the first place is that IRC servers don't save chat history/dms when you're offline. You'd gain no benefit from doing that with Discord.
I use all sorts of computers for personal and professional use. I don’t want to install discord on all those clients.
The point is more about the possibilities which have been severely muted with chat apps like discord.
The point is more about the possibilities which have been severely muted with chat apps like discord.
Quassel does bring an experience very close to that though. Still IRC, but a bit more modern and nice.
Why would you want to do that? You can install Discord on your phone if you want to catch up if you are out somewhere doing something.
Not a fan of being on my phone, especially when I’m already on a device.
Discord is on all major platforms including the web and you also have the option to remote in to another machine that has Discord.
I get it but that’s not how I want to use my chat app. I understand my workflow is unique but that’s why I prefer IRC
works fine with bitlbee
Well, make it a part of the fediverse as a de facto chat/messaging platform? Not big on activitypub and alike, but might that push it a bit further?
Too late.
Matrix ate IRC's lunch, its the future of federated chats.
Not convinced. One could argue that Discord and Slack ate a bigger part of it. And then Matrix is very very heavy as compared to IRC.
Not only is it heavy, it is very complex. If I were to make a Matrix client I would for better or worse be forced to rely on someone else having implemented a library for the protocol or most likely spend months on building one myself. IRC is so simple that it does not get in the way and you can roll a bot in less than 100 lines – protocol included.
Is IRC crufty at times? Yes. Is it arcane at times? Yes. But I personally will take worse being better in this case. In particular, I find the incredible client diversity to showcase the power of a simple, open protocol. You really can find a client that operates the way you want it to operate and if you for some reason can not, it is not daunting to patch or hack one on your own.
Is IRC crufty at times? Yes. Is it arcane at times? Yes. But I personally will take worse being better in this case. In particular, I find the incredible client diversity to showcase the power of a simple, open protocol. You really can find a client that operates the way you want it to operate and if you for some reason can not, it is not daunting to patch or hack one on your own.
>IRC is so simple that it does not get in the way and you can roll a bot in less than 100 lines – protocol included.
I've written a Matrix bot for work that's nice and tidy to alert on certain server issues. Sure, you need a lib - but what the hell do I care? If I was writing an IRC bot I'd scope for an IRC lib as well.
With Matrix I at least have support for images, code blocks, and so on. Give me Matrix any day.
I've written a Matrix bot for work that's nice and tidy to alert on certain server issues. Sure, you need a lib - but what the hell do I care? If I was writing an IRC bot I'd scope for an IRC lib as well.
With Matrix I at least have support for images, code blocks, and so on. Give me Matrix any day.
> Sure, you need a lib - but what the hell do I care?
Well I care, that does not mean that you have to care. Again, look at the lack of client diversity for Matrix and tell me that you do not think that there is at least some correlation in terms of the complexity of the protocol. I sure care that the barriers to entry are significantly higher for Matrix than IRC if you do not have the luxury of having someone else having spent months on a good library for your language of choice (last I checked it meant using either Python or Go). Add to this that the more mandatory features you have and keep adding, the more difficult it will be for clients to keep up.
For what it matters, I use Matrix daily. But I am not going to behave as if images, reactions, code blocks, threads, end-to-end encryption, voice calls, video calls, etc. do not come at a cost.
Well I care, that does not mean that you have to care. Again, look at the lack of client diversity for Matrix and tell me that you do not think that there is at least some correlation in terms of the complexity of the protocol. I sure care that the barriers to entry are significantly higher for Matrix than IRC if you do not have the luxury of having someone else having spent months on a good library for your language of choice (last I checked it meant using either Python or Go). Add to this that the more mandatory features you have and keep adding, the more difficult it will be for clients to keep up.
For what it matters, I use Matrix daily. But I am not going to behave as if images, reactions, code blocks, threads, end-to-end encryption, voice calls, video calls, etc. do not come at a cost.
>Well I care, that does not mean that you have to care.
The point I'm making is that the protocol being implement-able by yourself or grabbing a lib from someone else is moot, since you will 9 times out of 10 use a library.
>Again, look at the lack of client diversity for Matrix and tell me that you do not think that there is at least some correlation in terms of the complexity of the protocol.
The problem is not client diversity for Matrix - there's plenty of them. The problem is that Matrix is more than displaying a log on a screen, and most of the clients are frankly abysmal and could use a trained UI/UX owner.
>last I checked it meant using either Python or Go
The Rust SDK has worked well for me, although I can't state how close it is to Python or Go's libs. That said, I know I'm certainly not the only one using it.
The Rust lib could be wrapped into other languages (e.g, Ruby) if there's not a good SDK for that language. I don't really consider this to be an issue, especially considering the Rust SDK is maintained by the Matrix org themselves.
https://github.com/matrix-org/matrix-rust-sdk
>Add to this that the more mandatory features you have and keep adding
Don't maintain your own bespoke library and you won't have to. :)
>But I am not going to behave as if images, reactions, code blocks, threads, end-to-end encryption, voice calls, video calls, etc. do not come at a cost.
They do come at a cost, but that's the price of admission for what people expect from modern chat systems. I'd rather live in 2022 than 2004, and I grew up on IRC.
The point I'm making is that the protocol being implement-able by yourself or grabbing a lib from someone else is moot, since you will 9 times out of 10 use a library.
>Again, look at the lack of client diversity for Matrix and tell me that you do not think that there is at least some correlation in terms of the complexity of the protocol.
The problem is not client diversity for Matrix - there's plenty of them. The problem is that Matrix is more than displaying a log on a screen, and most of the clients are frankly abysmal and could use a trained UI/UX owner.
>last I checked it meant using either Python or Go
The Rust SDK has worked well for me, although I can't state how close it is to Python or Go's libs. That said, I know I'm certainly not the only one using it.
The Rust lib could be wrapped into other languages (e.g, Ruby) if there's not a good SDK for that language. I don't really consider this to be an issue, especially considering the Rust SDK is maintained by the Matrix org themselves.
https://github.com/matrix-org/matrix-rust-sdk
>Add to this that the more mandatory features you have and keep adding
Don't maintain your own bespoke library and you won't have to. :)
>But I am not going to behave as if images, reactions, code blocks, threads, end-to-end encryption, voice calls, video calls, etc. do not come at a cost.
They do come at a cost, but that's the price of admission for what people expect from modern chat systems. I'd rather live in 2022 than 2004, and I grew up on IRC.
Well, I sure am glad to get told that my concerns and perspectives do not matter because you have different subjective preferences. Despite me being charitable enough to entertain your view on things; especially as I have used and evangelised Matrix for half a decade at this point.
As I am essentially stuck with an argument that boils down to “But I like deep dependency stacks (even with calls across language boundaries) with less than a handful of protocol implementations, there is client diversity (despite the fact that pretty much everyone uses Element despite its glaring UI faults/bugs and no other client seems to keep up feature-wise), and in ${CURRENT_YEAR} I expect these features in a single client/protocol come hell or high water”, I will sign off here as I feel like I am not getting through anyway.
As I am essentially stuck with an argument that boils down to “But I like deep dependency stacks (even with calls across language boundaries) with less than a handful of protocol implementations, there is client diversity (despite the fact that pretty much everyone uses Element despite its glaring UI faults/bugs and no other client seems to keep up feature-wise), and in ${CURRENT_YEAR} I expect these features in a single client/protocol come hell or high water”, I will sign off here as I feel like I am not getting through anyway.
Totally with you on that. I understand that other people don't want the same thing as I do, and I accept it.
But somehow I don't get that they, on their side, cannot understand the reverse (i.e. that I don't necessarily want what they want).
But somehow I don't get that they, on their side, cannot understand the reverse (i.e. that I don't necessarily want what they want).