conduit VS gomuks

I'd like to suggest Conduit. I found it very easy to install and maintain. https://gitlab.com/famedly/conduit

> "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/).

To start, this will be strictly Non-Federated. Just a few friends will be using this. Here: https://gitlab.com/famedly/conduit/-/blob/next/DEPLOY.md is the documentation I am following. It tells me I must "use my server name", but what is this exactly? What do I put in there? Do I have to go out and buy a domain?

Either Tinode (https://github.com/tinode/chat) or Matrix Protocol (https://gitlab.com/famedly/conduit)

Matrix Protocol: Fractal (Client), Conduit (Server)

If self-hosting is an option then I'd say Matrix, you can try Conduit (server) and Elements(client). To simplify deployment you can refer to this repo.

You can babble on and on about how its not how you do it, no one needs it, etc... But its a demonstrable need in this space and its caused me great pain trying to write applications that would be used by such people. It's even bit Conduit to the point they have 5+ DB backends coded in now that the user can choose between based on their local system setups.

Give Conduit a try. It uses way less memory than Synapse. It is still in early stages but works great. I have been running one on a Pi4 for like a year, going great so far.

There's a Rust implementation of a Matrix server that uses sled: https://gitlab.com/famedly/conduit/

The problem with this is that this is just fundamentally untrue. There are plenty of non-Electron apps that are viable. For core functionality of e2ee, messages, exploring directories, sending images, etc, those are available in multiple alternative apps. If you're talking about other integrations like video calling, plugins, and spaces, then you'd be right as I don't know other clients that have those. But, none of those things are really required in the matrix protocol anyways, and those available features in other clients already far surpasses what IRC can do. You don't need these bleeding edge features to have an enjoyable experience on Element, and given the IRC crowd, I would assume they're adverse to bleeding edge anyways. If you want an experience similar to irssi, then you can use gomuks for a superior experience in a familiar(ish) client. So saying Element is the only suitable client implementation is outright false.

There's also a nice terminal client called gomuks.

gomuks is probably the most feature complete one.

gomuks is a command line-based Matrix chat client

I am running my own home server, everyone in my family has an account they use there (the domain is our surname). Non-techy people use it and like it (past the initial setup, since setting up a custom domain requires a few more clicks than :matrix.org account). I am not waiting for the day, though, when they will need to set up a new device without access to the old one.

> I personally haven't met any "real" people who are even aware of Matrix. When I broached it with a non-IT friend, they were actively uninterested in unifying messaging applications as they had "facebook friends" and "whatsapp friends" and interacted with them differently.

I tried to sell it too with the "unify your messaging apps", but this is a wrong selling point to new users. First they need to start using matrix as their messaging app, realize that it works well, including VoIP and video calls. Once trust is there, only then start thinking about using bridges. Because there will be rough edges (e.g. federated voice/video calls do not work).

Because of the way bridges integrate to third-parties, they are not bug-free. Reliability is just not great yet. Maybe except a hosted service, Beeper[1], which is run by people who know most about these bridges and can provide support.

To sum up, I am using Matrix for my family network, and some bridges personally; I am not yet planning to spread the use of bridges beyond myself. Besides the encryption setup, I like the UI a lot. I also use gomuks[2] from time to time, which is a terminal matrix application. I have not stumped into server-side problems.

I am donating monthly to Tulir[3], the most prolific Matrix bridge developer (and, to my knowledge, co-founder of beeper). Because I started using Matrix because of the bridges.

Oh, and I love the Matrix sms bridge[4]. I set it up to see if it works, and I am not going back. It's great.

[1]: https://www.beeper.com/

[2]: https://github.com/tulir/gomuks

[3]: https://github.com/tulir

[4]: https://github.com/tijder/SmsMatrix