Moznet IRC is dead; long live Mozilla Matrix
matrix.org
matrix.org
Well done to the Matrix team, The future is here!
Unless they keep a IRC-bridge around and then I will be happy, because then Mozilla is still on IRC and whatever overly complex Matrix-based IRC-backend they have, that’s not really my problem.
Sure. I've been on IRC since the 90s. It's a tool I know and love.
> You may want to give it a try before criticising it as probably less accessible.
OK. What good terminal clients exists which I can run in a screen session on my home server? Are there any which acts more or less like irssi or weechat, which I've developed deep habbits for the last 20+ years? And are any of these packaged by Debian or Ubuntu?
If it's mature tech, like you say, there should be lots of clients and finding one which fits my niche should be simple, right?
It's called weechat.
From Wikipedia:
IRC was created by Jarkko Oikarinen in August 1988
A major, hugely successful product, that is in the market for 32 years, and has seen many implementations, both on client as well as on server side, must be "mature". No?!No. HTTP/HTML are mature; IRC is just old :P
The IRC ecosystem is as if we’d reached HTTP/0.9 + HTML/1.0, and everybody collectively agreed to just stay there forever for some reason. “Mature” to me implies that a product has spent many years iterating on a design to reach, at the very least, a local maxima - ideally getting past that and evolving to keep up with the rest of the industry. IRC on the other hand, seems to have had a couple of years of work at the start, and then remained set in stone for 30 years...
laughs in Simple Mail Transfer Protocol
Imagine that your protocol for choosing dinner with your SO is:
You: What would you like:
Them: I don't care.
There, simple! Getting some useful information out of that is an exercise left for the reader.
It's not really helpful when people try to describe IRC as easy simply because it resembles text based paradigms that developers are familiar with.
i would never recommend vim to a someone that is just beginning when vscode is right there.
Vim is arguably simple in neither of these senses, but most Vi clones are much less complex than Vim or NeoVim.
I made a mistake though, nobody else in the comment chain was talking about Rust or developers. I had read a comment in another part of the thread which linked to Mozilla's forums [0] which mentioned more people in the developers channels on the Matrix instance, which I had mistakenly assumed was part of this comment chain, hence the question relating to developers.
[0] https://discourse.mozilla.org/t/synchronous-messaging-at-moz...
>The number of participants in our primary development channels has already exceeded their counterparts on IRC at their most active [...]
Case in point: virtually no one uses Emacs. Even Vim is diminishing; most devs now use Visual Studio Code.
> most devs now use Visual Studio Code.
You seem to live in some other world than I ...
I work on the East Coast at a company that's over 100 years old -- though they are modernizing their development efforts (something I'm heavily involved with). And literally everyone else in our portfolio uses VSCode to develop with except for legacy Java stuff which is usually manipulated with Eclipse.
A Triplebyte study from two years ago showed that most developers undergoing their interview process used Visual Studio Code: https://triplebyte.com/blog/editor-report-the-rise-of-visual...
While Triplebyte is Silly Valley, presumably they have clients outside the bubble.
I don't think different default functionality fundamentally changes its class.
Around 30% use vim or Emacs. Linux is about as popular as Mac and windows is still as popular as both combined.
Worth noting that simply adding means that yes, Vim+Emacs ~= 30%, but VS.Code + VS ~= 80%
I'm thinking that plenty of users use both an ide and a text editor but few use more than one text editor. For example few use emacs because its required by their job thus emacs + vim probably IS 30% but VS.Code + VS probably has a substantial overlap.
I may or may not be using a Mac at some point during the day (because Apple forces me to, to do iOS development), but usually whether my host is Windows or Mac, I have 3~8 Linux VMs running at any particular time.
Now, I will use SublimeText, instead of vi, from time-to-time (not often), but I don't think I am out of the mainstream...
BTW: I up-voted you because I think you have a point worth discussing, and that's hard to do when you are down-voted to hell, even if I don't agree with you...
t. using vim, tmux, i3 and linux.
connecting to irc.mozilla.org...
/join #channel (or have it set up to auto-join a named channels)bla bla bla
/part (or simply just (Q)uit from the menu)
If you did not (Q)uit from the menu yet, either do it or
/quit
If you preset some autoconnects and autojoins, there is no need to know any of the commands.
You have a list, often preset with all the IRC servers, worldwide. Just choose the one you want and add it to "Favorites".
There, list all channels, search the ones, that cover your topic (via text input box) and add them to "Autojoins" or "Favorites". The preset gets created automatically, either globally or per network. In other lingo, it's called: an application's preferences.
Hickley argues that simple != easy. "Easy" is inherently subjective, and only tells us how easy something is for the actor attempting that thing; if you know more about a domain, things related to that domain become easier. If you knew how to tie knot A and I knew how to tie knot B, we would both find our respective knots easier. "Simple" is more objective, insofar as anything can be. We could judge the complexity of knots in a rope based on how many times the rope turns over on itself, and that complexity would not be dependant on your knowledge of particular knots. In principle we should be able to agree on which knot is more complex even if we still have an easier time tying the ones we are familiar with.
Of course you can mount an argument that simple is used as a synonym of easy, because it often is, but I like the idea of simple being the opposite of "complex" and "complex" meaning "many-folded" rather than "difficult."
> Finally, this is going to be more accessible to more users to Mozilla since now they are using Matrix.
> I disagree, IRC is as simple as it gets. This might discourage some people from joining.
Not to mention IRC has plenty of web UI clients that make usage simple, so that point itself is moot.
Every single thread about this kind of stuff has an IRC devote crawl out of the woodwork. I get it: I grew up on IRC as well.
You gotta accept what people (and organizations, like Mozilla, who clearly outlined their reasoning publicly before doing this) need.
How, with existing IRC networks, and without requiring each user to have their own server somewhere or pay for a third-party service, do you get persistent history and the ability to message people who aren't currently online?
That's table-stakes for chat services; there are many more things where that comes from, but that by itself is enough reason.
Or offer a full hosted bouncer a la IRCCloud (Although their default pricing wouldn't be tenable for this)
What matrix is providing on chat.mozilla.org is an easy to use interface for people who want simple access, but I'm pretty sure it's expected that in the longer term people use their own client on their own homeserver and just connect to mozilla.
I don't see Matrix really solving anything. If anything, the non technical user will sign in and ge greeted with
> Welcome to the Mozilla community Matrix instance. You can sign in to connect directly to this server, or connect from other Matrix instances through federation.
Maybe they select a chat and have to read through the ToS as well?
This is a lot more convoluted than any IRC web-client I've seen the last decade.
And their 1k user chat room has as much activity as the 30 people IRC ones I'm connected to, and is the sahara desert compared to the larger ones. IT doesn't help to have a user list of 1k and no way to show the active users you actually interact with.
> The UI is the easiest thing to fix and as you have shown already has been for some time. What separates IRC and the rest is all the features you would expect by default in a messenger of the 21st century:
- history
- with search
- logins
- simple bots
- automatic content fetching (wiki/youtube Links, pics and gifs)
- file transfers that just work
- image pasting
- message editing
And probably others. Yes, those features exist in one way or another in IRC. The point is not whether you can or not; the point is how much time and energy do I want to spend to install and maintain those. I may have had the patience to do it a few years back, but I value other things now.
For my part, I've gone so far as to write my own custom IRC client from scratch at one point to fix clientside issues I had - and written my share of utility bots - so hopefully I have some credence when I say I've done my part to try and resolve issues. And yet, I've jumped ship to Discord. Single signin, plenty of customization through bots, history, emoji, inline code blocks... sure, these could all theoretically be solved in IRC with infinite time and energy, but in practice they simply haven't been - and based on the trajectory of the past decade, won't be fixed within my lifetime either.
Which leads me to think it's not entirely a technology problem, either. Switching away from the ossified IRC ecosystem may at least partially be a social solution disguised as a technical one. While I'm personally quite skeptical of Matrix as a solution, I applaud the attempt and the experiment. Perhaps I'll be proven wrong.
People also demand the features that modern protocols provide such as image uploading, encryption, profile pictures, etc. While a lot of this stuff can often technically be done on IRC, it never works as well and requires knowledge of how to set it all up.
On matrix with the default client, it all just works. We can repeat the discussion about how dropbox is useless when you could just set up a ftp server on a vps or we could recognize that people like software that does what they want by default.
"The number of participants in our primary development channels [on Matrix] has already exceeded their counterparts on IRC at their most active, and there’s no sign that’s slowing down."
https://discourse.mozilla.org/t/synchronous-messaging-at-moz...
See my other comment in this thread if you disagree but this is making something unnecessarily complicated because... reasons?
I'm not sure what the implication is here.
> The issue around IRC is not a problem that can't be solved and really has been solved with the Web UI clients, for an every day user, to clients that make it simple otherwise.
The issues surrounding IRC are partly because of inconsistent client implementation of features, but I think an even bigger problem is the inconsistent feature set of servers, which end-users have no control over. Sometimes it's because the server simply hasn't implemented a particular feature, other times it's because there is no feature - and if you're lucky, you'll even be told condescendingly that you don't actually need that feature in the first place.
And of course, there's also the stuff that is implemented, but only accessible through bot interfaces that are incompatible between servers. Or the problems that are technically possible but require using a bouncer, and even still, that has inconvenient warts like having to grep through logs to search for stuff that isn't in your backlog, and the seemingly impossible-to-solve issue of persisting private messages across reconnects in a way that's useful in all situations.
In any case, Mozilla has mentioned their intent to make their Matrix server accessible from an IRC bridge in the future, so it really does seem like the best of both worlds - giving Matrix uses the advantages of the platform like editing chats and easy offline channel history, while allowing IRC users to continue using their comfy client. Personally, for me, it's the other way around - Matrix has almost completely supplanted the use of my self-hosted IRC bouncer, and I'm looking forward to the day when I can shut it off for good.
With Matrix, if you just create an account, join a room, and completely forget about it, you're still counted. There must be a bunch of Matrix channels that count me at least three times because of the different accounts/homeservers I used when trying to make something work.
Meanwhile on IRC you (or someone else) needs to have a client running somewhere to be counted.
In this light, the number of users in a Matrix channel hardly ever decreases and is not representative of channel's popularity.
Every project I've seen that's opened up a Slack/Discord/<something like those> alternative to their IRC channel has had much more participation on the Slack/Discord. Elm's Slack is completely bustling.
This is something to take seriously when the goal is to actually build a community instead of hand-wring about IRC technical superiority.
P.S. that post mentions internal engineering/ops teams switching from Slack to Matrix, that'd boost Matrix numbers if they weren't using IRC already. Perhaps that's an accessibility issue if Matrix was offering features that Slack had and IRC was missing.
my point starts here...
> pick another
...continues further...
> some are quite nice looking and don't require memorizing any / commands
...but doesn't end here. how do I paste a screenshot or a photo or an animated cat video meme into an irc conversation?
you might start getting somewhere if you've given me iMessage for IRC preinstalled on iOS. maybe.
It will however encourage way more people.
IRC still suffers from usability issues which WhatsApp, Slack, Discord and Telegram have already solved. However they are closed-source platforms, so Matrix is the best alternative for a truly free, open-source and more accessible platform for the general user to communicate from which should be IRCs successor.
IRC is a protocol, it doesn't have an appearance. And IRC clients can have very "modern" looks. See for example: https://www.irccloud.com/ or https://quasseldroid.info/
> Matrix is the best alternative for a truly free, open-source
While Matrix is certainly more free and open source than the other ones, Matrix clients depend on a non-free bit to work properly, and they don't plan on fixing that: https://github.com/vector-im/riot-web/issues/7757
This is FUD.
a) Integration Managers are optional, and in no way required to "work properly".
b) There's a great FOSS integration manager over at https://dimension.t2bot.io/ if you don't want to use the default one.
Do you have a link to a description of what integration managers do exactly?
> b) There's a great FOSS integration manager over at https://dimension.t2bot.io/ if you don't want to use the default one.
Noted, thanks. My search results for "Matrix integration server" are flooded with irrelevant results
Dimension's page at https://matrix.org/docs/projects/other/dimension gives a simple description.
Beyond that, there's a lot more info buried in:
https://matrix.org/blog/2019/06/30/tightening-up-privacy-in-...
and the subsequent:
https://matrix.org/blog/2019/09/27/privacy-improvements-in-s...
Dimension's description lists: "giving users a way to add bridges, bots, and widgets to their rooms and account"
I can understand widgets (they are iframes to a webpage served by the integration manager, right?), but mentioning bridges and bots confuse me.
My understanding is that bridges (aka. appservices, if I'm understanding this correctly) connect directly to a homeserver.
On IRC, bots connect as any other client to the server. Is this not true on Matrix? (ie. do bots use different APIs/protocols than "user agents"?)
Or are integration managers in charge of running bridge and bot processes, like an init daemon?
EDIT: I just chatted with someone else, and she tells me integration managers provide clients with a list of what bridges and "official" bots are available. And, I assume, links to enable them for a given room. Is that correct?
IRC is quirky and requires either a mentor to teach you the quirks or some study. this is not a deal breaker, as also email is in a similar situation and it works somehow there.
About the experience I expected, tbh.
I'll stick with IRC. Given up on Mozilla long ago.
But this is an absolutely insane way to think about software.
From what little I've tried, Mozilla has way bigger issues with making their projects accessible to new developers than which chat system they use.
I think (2) is already ironed out, but not sure how the protocol spec(1) is doing. How are community-based servers doing? I heard Matrix is intentionally putting implementation ahead of spec, which isn't exactly nice...
In terms of the spec being incomplete a year ago... yes, it was still a WIP and in beta. We exited beta with a complete spec in June 2019, as per https://matrix.org/blog/2019/06/11/introducing-matrix-1-0-an....
Since then, on the server side, development on Dendrite has resumed in earnest - and there is zero overlap between those working on it and the Synapse developers & team. Other community servers are making slower progress, but this is not due to antagonism towards the community, but because it's quite a lot of work. I suspect folks have also been scared off by fear & uncertainty from the kind of threads you linked.
Finally, "intentionally putting implementation ahead of spec" is absolutely critical for Matrix. We draft proposals, we implement them, and only if they are shown to work in the field do we merge them into the spec. We believe this is something that XMPP and others got monumentally wrong, and a very desirable and nice property indeed.
But now I can wholeheartedly say I support Matrix. I’m also glad to hear that there’s the diversity sprouting, since I believe it is the best way to put the specification on test. And I didn’t realized there are proposals openly being worked on[1]. I think I missed it while browsing through the site.
Anyways, thanks for all your hard work. Matrix will surely help a lot of people, including the open source community.
[1]: https://matrix.org/docs/spec/proposals#work-in-progress
Meanwhile gomuks also exists and is usable and not abandoned.
On GUI Desktop, various clients are in active dev - e.g. Fractal for GTK/Rust, Quaternion for Qt/C++, Nheko for Qt/QML, etc. They are not as complete as Riot yet, but I'm sure PRs are welcome...
... although if I'm not mistaken, unfortunately none of them supports Single Sign-On yet, which is required for joining the Mozilla instance.
Also straight from the readme:
"Basic usage is possible, but expect bugs and missing features."
Not very promising.
I thought you said it was web-based?
They mean it when they say "User ID can only contain characters a-z, 0-9, or '=_-./".
Is that really so esoteric?
Cannot reach homeserver Ensure you have a stable internet connection, or get in touch with the server admin
https://chat.mozilla.org/#/register
It's trying to make a GET request to this URL and 404'ing:
https://chat.mozilla.org/config.chat.mozilla.org.json?cacheb...
That brought me to this page:
https://mozilla.modular.im/_matrix/saml2/authn_response
Which only displayed the word
ForbiddenHow much power is needed to comfortably join a massive room?
Is it just the initial sync load or is there constant heavy load for massive rooms?
"At least 1GB of free RAM if you want to join large public rooms like #matrix:matrix.org" https://github.com/matrix-org/synapse/blob/master/INSTALL.md...
The resource requirements of joining a busy room with lots of members is mainly RAM, and it spikes at join and initial sync, but does then occupy room in memory and the DB to maintain state for all the activity in that room. For something like ##rust you should expect to see an initial spike of a few hundred MB of RAM which then dies down again. This can be optimised massively, but we haven't got to it in Synapse yet. (Dendrite is looking way better though).
> Finally, it's worth noting that the matrix-ircd project is seeing some commits again, many thanks to jplatte from the Ruma project - so if you are currently despairing the demise of moznet, never fear: you may yet be able to connect to the Mozilla matrix server via IRC (authing via Mozilla IAM, of course) and pretend that none of this newfangled Matrix stuff exists :D
That sounds good. I’ll keep my irc-client then.
EDIT found it:
> While we’re investigating options for semi-anonymous or pseudonymous connections, we will require authentication, because:
> The Mozilla Community Participation Guidelines will apply, and they’ll be enforced.
http://exple.tive.org/blarg/2019/04/26/synchronous-text/
(Don't ask me why the article seems to pretend IRC has to be unauthenticated)
Besides, you already are a part of Mozilla. Or you can be: check out the bug database, submit a patch, and we'll happily land it. :-) Until you've been around long enough to land it yourself; commit privileges are not tied to employment.
And are there good android apps for it
Yes, that's one of the most important aspects of Matrix.
> And are there good android apps for it
Riot for Android is usable, but has some deficiencies and is in the process of being replaced.
RiotX is the slated replacement (a total rewrite in Kotlin), but it's only available in Early Access right now. It's already usable and works nicely, though.
:(
You mean "Sign in with single sign-on"? Because right now the flow is
- Go to https://chat.mozilla.org/#/welcome
- Click on "Sign in"
- Options are "Sign in with single sign-on" or "Create account"
- "Create account" fails with "Registration has been disabled on this homeserver."
So if I "Sign in with single sign-on", I create an account, but if I "Create account" I can't?