IRCv3 2022 Spec round-up
ircv3.net
ircv3.net
That and advent of zero-fuss web clients
https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/net/rc...
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.
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/
Why does open protocol usually mean crippled U/X?
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.
Why do low level engineers work freely on FOSS but designers or UX devs don't is the question.
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?
In fact, they will probably say something like "just use the CLI, it's a superior way anyway".
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.
> 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.
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.
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 use it, but discord’s mobile client is a far better experience.
I’m just pointing out that… well, discord has advantages other than the protocol.
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.
> 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.
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.
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.
[1] - https://github.com/thelounge https://thelounge.chat/
[2] - https://github.com/convos-chat/convos/ https://convos.chat/
I do believe there are TUI clients for Matrix, but I am unsure of their maturity and state, or how they compare to Irssi.
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.
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 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.
Nothing new under the sun.
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 fact IRC might or might not choose to compete doesn't mean it isn't one of choices people wanting chatting app consider.
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.
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.
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.
The servers need to be boosted to keep certain things like extended history preservation and what not available to the users of that server.
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.
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.
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.
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.
The point is more about the possibilities which have been severely muted with chat apps like discord.
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).
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.
That's the difference.
"Your" discord "server" turns out to be neither of those.
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.
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...
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.
[1]: https://revolt.chat
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.
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.
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.
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.
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.
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).