Matrix is a classic walled garden - it can connect to other systems, but provides no means for users of those other systems to connect to it. Matrix users can join IRC channels, but IRC users cannot join Matrix rooms.
And people wonder why I hate Matrix users on IRC, with all their dumb Matrix square-peg-round-hole nonsense messages
@0orpheus it's rather that Matrix users are themselves shitty IRC users. The client is not well behaved on IRC and does not fit into the IRC model properly, and it makes Matrix users stick out like a sore thing and annoys IRC natives.
If you're gonna interop with something, you should try to avoid annoying the people you're interoping with.
@0orpheus oh, and that it only goes one way says a lot about their priorities for interopability. They're not trying to interoperate with IRC, they're trying to subsume it.
@sir I don't think that's in good faith towards Matrix; no one asked that of XMPP to my knowledge.
@0orpheus XMPP never tried to force itself into the IRC ecosystem as a cancerous extension of it
@sir Fair, I get what you mean, though I'm don't share your sentiment for it.
@sir Yeah no, Matrix users in IRC is definitely an unpleasant experience. It's actually why I specifically don't use an IRC bridge on my server.
On the other hand, I feel like some of that is related to the fact that IRC is an old protocol and system that, like it or not, didn't age quite as well as a lot of people hoped in the sense that it doesn't support many features that "modern synchronous chat systems" support as a base measure. You can see it by comparing the experience of the IRC bridge versus almost any other (double-puppeting) bridge: IRC is shitty for other IRC users, every other bridge the matrix user is entirely unnoticeable.
@0orpheus the features which define a "modern" chat "experience" are not desirable on IRC, and I am glad that they are not present
@sir That's fair, and as someone who uses both I agree that there's reasons to not have those "features". That's why I put "modern synchronous chat systems" in quotes. Unfortunately, pragmatically speaking, those features are what a lot of users expect.
@0orpheus I don't know why people feel that this argument is meaningful or that I should give a fuck about what users expect
@sir Honestly "expect" was probably a bad word choice and "want" is a better one.
But yeah, you don't have to give a shit about what users expect. But software without features users expect or want ends up being a pretty user-less, masturbatory experience. I think the IRC bridge makers should work harder to be better citizens in IRC, but the doesn't make the whole project shitty or a walled-garden.
@0orpheus okay, walled garden has a specific definition and it's questionable to call Matrix one. But Embrace/Extend/Extinguish is very obviously applicable to Matrix
@sir I don't know how applicable it is, but I think yeah if the bridge makers (specifically for bridges like IRC which is Matrix team approved) keep being bad citizens that's getting obviously into EEE territory.
I'll give that I've been comparing it to XMPP but as far as I know XMPP never had a bloody marketing team behind it.
@0orpheus Matrix's behavior and faults make sense if you understand how the organization works. I will probably write up a blog post at some point
@sir I look forward to reading it!
Also looking forward to reading.
In actual fact, a lot of their funding became dependent on growth of the protocol, it grew a client and front end of it's own, developed features that didn't interop with other services, etc.
It says a lot that such a large proportion of their developer effort is spent on the Riot client, and things like voip and video calling that have no plans or roadmap for non-matrix2matrix use.
Matrix went from a servant protocol to considering the others in the ecosystem it meant to bind together as second class.
I don't agree with elsewhere in the thread where it was asserted that IRC hasn't aged well - I think its longevity and staying power past fads like XMPP show the opposite.
That's not to say that IRC isn't lacking in some areas. There is no doubt that clients are still sharp objects - there's no reason for example that most interactions should be through slash-commands rather than sensible gui flows. I should be able to paste an image into my client, and it automatically uploads it to my image host of choice, and then drops the resulting url into my message box. Client understanding of services so people don't have to faff with nickserv, etc.
But none of these things require that the protocol changes, nor the character of IRC use. The issue is that by the time you are capable and qualified to write an IRC client, you've already internalised the sharp edges and don't see why things like Nickserv are challenging to new users.
Assuming other rough edges - file/image, reactions, custom emoji, and such - get smoothed out in the near future, the only issue left will be chat history.
And I've seen some IRC daemons add limited support for room history. Wonder how well that goes in the long term.
Room history (serverside) and out-of-band images (clientside) are fairly easy kills.
Custom emoji/reactions are somewhat more controversial, and also require protocol changes that need agreed upon and then rolled out across both clients and servers.
As for emoji reactions, if the server implements message-tags, and passes through client-only tags intact, clients can go on and implement things like +react
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!