ircv3-ideas VS convos

> "At least as standard" how?

There are 8 people who vote on changes to the Matrix spec (the Spec Core Team), 7 of which are Element employees (including Matthew, Element's CEO). Element also controls the development of clients and servers used by the large majority of users in the public federation.

> A substantial portion of the IRC comunity is actively hostile to the IRCv3 extensions, and in some cases prefer incompatible implementations of the same functionality; Matrix has nothing like that going on.

But any IRC client will work fine on any IRC server, and they can connect to various servers with different implementations.

On Matrix, clients (generally) can only connect to one homeserver at a time; which forces them to converge on following exactly the same spec. And if your server differs ever so slightly from the other ones in how it implements some parts of the spec (room consensus), then it can be split-brained from the rest of the federation. Instead, changes to the room consensus are done by pushing new room versions, and each server implementation needs to explicitly support it or they can't join it. This means Synapse devs (which are a majority of Element employees) get to decide what room versions can get traction.

It is not uncommon for people in the Matrix community to complain about this and Element keeping specs in limbo, and PRs to the flagship clients being stuck in "design review tar".

> And there seem to be more visibly independent implementations of Matrix than IRCv3.

Clients, maybe, at least in the number of implementation. It's hard to find stats of this, but I feel that >95% of people in the public federation use Element even in tech-y rooms; IRC has a healthier mix of major clients (weechat, irssi, IRCCloud, Hexchat, KiwiIRC, The Lounge each have >5% of desktop/web users). But I admit that's just my very subjective point of view.

In terms of servers, Matrix has three open source ones as far as I know: Synapse (controlled by Element), Dendrite (controlled by Element, and almost on par with Synapse according to https://arewep2pyet.com/ ), and Conduit. Based on https://gitlab.com/famedly/conduit/-/milestones/3 , Conduit seems to be far from implementing the spec yet (eg. it doesn't seem to support leaving rooms or respecting history visibility).

> things like: server-side history extensions tended to mess up my client's history implementation (I'd end up with multiple copies of the same messages in my local logs, often with the wrong timestamps)

You can use https://ircv3.net/specs/extensions/message-ids to deduplicate them.

> And if you're in a conversation where people are using embedded gifs, then fundamentally you'll always be a second-class citizen if you're trying to participate in that with a client that can't display embedded gifs.

A conversation where people where people are using embedded gifs will exclude me regardless of client, because they are too distracting. At least on IRC I can expect people not to do it too much, and use words or emojis instead of reaction gifs.

> SSO access control; you just can't do that in a nice way if the client doesn't support it

That's a fair point; IRC is made by hobbyists more than companies, so that's not surprising. There is some discussion around it though: https://github.com/ircv3/ircv3-ideas/issues/74 and Sourcehut is sponsoring implementation (https://emersion.fr/blog/2022/irc-and-oauth2/).

Excellent idea! You'll have a mature, open standard protocol under the hood, with no vendor lock-in, excellent extensibility, and great modern frontends like The Lounge (https://thelounge.chat/) or Convos (https://convos.chat/) to choose from (and you can choose).

And UnrealIRCD still rocks. For a quick-and-dirty setup I've deploy ng-ircd but Unreal has always been my go-to for anything serious. If nothing else it can be useful as a backup or internal platform during the rare events that Slack or Discord are having an incident. The common complaint is a lack of channel back-log but it can be front-ended with TheLounge [1] or Convos [2]. I personally prefer to handle that with gnu screen or tmux and WeeChat [3].

[1] - https://github.com/thelounge

[2] - https://github.com/convos-chat/convos/

[3] - https://weechat.org/

For the other layers one can front-end IRC with TheLounge [1][2] or Convos [3][4]. TheLounge only persists history in private mode meaning that users are created in that front-end and chat messages are in Redis. For small networks or groups of friends this is probably fine.

Notably missing is voice chat. I use the Mumble client [5] with the Murmur or uMurmur [6] server which is light-weight enough to run on ones home router. I use it on Alpine Linux, works great. It's not a shiny and attention grabbing as Discord but probably fine for everyone else. For people to create their own voice channels would require the full-blown Murmur server.

[1] - https://github.com/thelounge

[2] - https://thelounge.chat/

[3] - https://github.com/convos-chat/convos/

[4] - https://convos.chat/

[5] - https://www.mumble.info/

[6] - https://github.com/umurmur/umurmur/wiki/Configuration

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 chat adds memory usage.

[1] - https://github.com/thelounge https://thelounge.chat/

[2] - https://github.com/convos-chat/convos/ https://convos.chat/

IRC is a mature, extensible, open protocol, with a wide variety of server and client implementations to suit many use cases, servers can be self-hosted and federated, and modern web-based clients like The Lounge or Convos offer a user experience equivalent to Discord, Slack, etc.

Standard IRC with a web interface like The Lounge or Convos

And there are some great web-based clients like the Lounge and Convos that offer an equivalent UX to Discord or Slack, are open-source, self-hostable, and based on a mature, reliable, and extensible open protocol.

Take a look at convos to see if it fits your needs: https://convos.chat/

There are web front-ends to IRC that can mitigate message loss without having to run bouncers. Convos [1] and TheLounge [2] come to mind but there are others [3]

[1] - https://convos.chat/

[2] - https://thelounge.chat/

[3] - https://www.ilmarilauhakangas.fi/irc_technology_news_from_th...