I love IRC but it is clearly not "as simple as it gets". Every non-technical person I've tried to introduce it to glazes over by the second or third /command, if they even get past "you need to pick an IRC network". Meanwhile they're all happily chatting away on WhatsApp.
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."
Fair point, but in this case it's really easy that users want, not necessarily "simple". Going back to the points made earlier in this thread, IRC is a lot simpler than WhatsApp, but WhatsApp has a much larger user base because it's easier to use.
Is somebody that is taking the time to learn Rust really going to struggle with a handful of commands though? Day to day I never need more than /join, /part, /msg, or the occasional /quit, and I'm using a terminal based client, some phone/web clients I've used don't require any commands.
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.
Professional developers mostly use Macs these days, and won't touch anything that doesn't have a nice UI that does exactly what they expect. Anything that looks too textual or "computer-code-y" that's not related to what they're working on, they will stay away from.
Case in point: virtually no one uses Emacs. Even Vim is diminishing; most devs now use Visual Studio Code.
I'm guessing that overlap between different options might be hard to predict in some situations but easier in others. If raw data is available you could of course answer more precisely.
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.
No they don't. The stack overflow survey shows that the highest number of developers use Windows at 47.5% followed by Mac at 26.8% and Linux at 25.6%
https://insights.stackoverflow.com/survey/2019
This is Hackernews. What's outside the Valley bubble besides desert and the occasional poor soul who undergoes the indignity of growing old rather than Renewing through Carousel? :)
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.
Any half-decent VIM user knows that there are no good vim emulators, only ones which do the absolute basics right. That includes vim mode for vscode which last time I used it even lagged when using it.
The only vim mode that didn't make me rage quit was evil mode in emacs. I use mostly vanilla vim, and there's always something that isn't implemented or isn't implemented properly.
Well, yeah, not sure why you even wrote this except to get some snark in. The point is the trade off of having the basic if imperfect operation of vi/vim, along with what vscode offers. That includes connecting with the large community of vscode users.
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...
Virtually no one uses Emacs because 1) Lisps are out of favor (excepting Clojure, which has excellent support with Calva), 2) the out of the box experience is bad and customization is not simple at all, and imo 3) chording as the primary means of operation is outdated.
Evil mode is easy to set up and org-mode is almost enough to get someone to move to emacs. I don't know tht numbers, but I wouldn't be surprised if emacs was roughly as popular as vim.
Just try a modern graphical IRC client. It's all menu/GUI driven.
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.
Mozilla's Matrix numbers disagree. Riot/Matrix is much more accessible than IRC.
"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."
There's no info on how the numbers were compared, but Matrix and IRC have a different approach to counting "present" users. On IRC, a user closing the client gets subtracted from active users count, on Matrix they don't. Thay may never even come back to Matrix ever again, but they will still bloat the number of users.
In this light, the number of users in a Matrix channel hardly ever decreases and is not representative of channel's popularity.
This may be true, but you can also just sit in the room and compare actual activity levels.
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.
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.
Keeping in mind that generally technical people will join this server and may have a vested interest in the move from IRC? 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.
See my other comment in this thread if you disagree but this is making something unnecessarily complicated because... reasons?
> Keeping in mind that generally technical people will join this server and may have a vested interest in the move from IRC?
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.
More numbers doesn't necessarily mean that it's more accessible though. I'm not trying to say that IRC is the most user friendly or accessible and I have no doubts Matrix wins on this front, but consider that the IRC server was just sitting there for years not getting that much attention, I only learned of its existence through Rust for instance. The switch to Matrix caused huge amounts of advertising for both the IRC server and the upcoming replacement and I saw articles and discussions on this way outside the normal Rust/Firefox/Mozilla circles, and it didn't just come at once either, as once Mozilla decided on Matrix as a replacement there was another set of articles hitting the rounds.
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.
IRC just isn't user-friendly to most internet users these days and its arcane prehistoric appearance is enough to spook them off to use something easier.
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.
> 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
The blog posts don't really address what integration managers are (other than stating they are "the mechanism for adding hosted bots/bridges/widgets into rooms") only identity service (which I just learned about, though)
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?
An integration manager is just a webapp which spins up and adds bots/bridges/widgets (collectively, 'integrations') for a given room - like a small appstore from which you can add extensions into a room. The available bots/bridges/widgets depend on the integration manager; i guess you could call the ones it chooses to provide "official" ones.
IRC is as simple as it gets for people who are familiar with IRC. New users expect certain UI features for chat apps anymore, and people able to connect via a browser without needing to worry about /commands is the way the world works these days.
That is a client/software problem, not a problem that needs to be replaced with complicated solutions. You're fixing the wrong problem and then shitting on the previous implementation without taking the effort to resolve the issues there.
Not to mention IRC has plenty of web UI clients that make usage simple, so that point itself is moot.
Basic auth processes varying wildly by server is a server/protocol problem, not a client problem, that also manifests itself as /command spam, even if IRC3 theoretically solves some of that. Web UIs don't fix that. It also doesn't terribly matter where in the IRC ecosystem the problems lie - the problems exist in said ecosystem, and they've not been effectively fixed. I've tried plenty of web UI clients, and have found them all quite unfortunately mediocre at best.
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.
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.
By hosting a web client for free? Just like Mozilla contracts the Matrix folks (at least I think Modular.im is closely connected to core devs) to host a web matrix client at https://chat.mozilla.org/.
Or offer a full hosted bouncer a la IRCCloud (Although their default pricing wouldn't be tenable for this)
So it wouldn't be IRC anymore, it would be MozillaChat whose backend happens to be IRC, but that is irrelevant. If the functionality is only available in a single client, might as well use a proprietary protocol and client.
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.
It is amazing that we are still having this conversation, after all the posts about IM softwares and protocols. I'll just post an older comment I made because I believe the arguments are still valid (https://news.ycombinator.com/item?id=17833409):
> 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.
IRC has far more problems than just ugly clients. The largest one is that it requires holding open a connection constantly to work. This is fine in the age of desktop computers but totally unacceptable in the age of laptops and mobile.
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.
That's not my experience as a mentor (over IRC, Matrix and other communication channels). The experience getting started with Matrix removes one pointless barrier.
What's wrong with the UX? If you don't like the client you're using, pick another, some are quite nice looking and don't require memorizing any / commands.
also an hammer is simple, this does not extend to being useful for your job.
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.
The only way IRC could be considered simple is if you are talking about the entire stack without any abstractions. You can technically open a connection to an irc server with NC and just type the IRC protocol by hand. You can't do that with Matrix because it sits on top of HTTP.
But this is an absolutely insane way to think about software.
I dunno. As someone who gets IRC and consider it proper mature, and thinks Matrix sounds like a mess I’d rather not have to look into, it probably means Mozilla will be less accessible to me.
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.
There's a lot of bias here. You consider something you use mature. On the other hand what you don't use only "sounds like a mess". You may want to give it a try before criticising it as probably less accessible.
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?!
> 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...
You can semi-productively talk to IRC over Telnet and it's been around basically forever in Internet time. Anything's going to be an immature mess by comparison—whether the mess is justified by improved functionality, and whether the new kid'll be around long enough to care about (say, is it likely to still be alive and kickin' in 20 years), are the important questions.
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?
Just out of curiosity: there was a thread on Matrix, started by a dev of an alternate homeserver implementation[1] (also covered later by [2]). He pointed out (1) incomplete spec preventing 3rd party implementations, and forces reverse-enginerring of the reference (2) project/spec ownership problem.
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...
Speaking as project lead for Matrix, we of course encourage as many implementations as possible of all parts of the ecosystem, including servers. The issues raised by that developer are entirely due to their destructive behaviour rather than any illwill towards community developers, as per the thread at https://news.ycombinator.com/item?id=19418111.
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.
Thanks for the reply, and sorry if I reminded you of bad memories.
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.
np. btw, we publish a test suite (which is now approaching a full compliance test suite) at http://github.com/matrix-org/sytest for anyone in the community wanting to implement servers, as another way to try to support & accelerate server dev. Diversity ftw (when it's not destructive).
While I commend Mozilla for embracing Matrix, I do think it would've been worthwhile to set up an IRC bridge (I don't use IRC personally) before deprecating their IRC server.
I disagree. It's just more infrastructure to maintain and would allow for anonymous harassment which is what caused mozilla to move away from IRC to begin with.
hm, this may be stale info - we've worked loads on moderation recently: https://matrix.org/docs/guides/moderation/ etc. If there's stuff missing for your use cases please let us know (perhaps to security@matrix.org)
This (and previously, https://github.com/torhve/weechat-matrix-protocol-script) has been my primary way of accessing Matrix for well over a year on PC-esque setups. It's amazing as long as you don't care about the video/call functionality. Much, much lighter than Riot yet more feature-full than most of the native GUI clients (nheko, fractal, etc.) IMO.
It's unclear to me whether any command-line based Matrix clients are in major package managers, for one thing. Going by Github the only one that looks like it's active is written in Python. Other, non-CLI desktop clients look variously half-finished or abandoned. Looks like mobile and web get all the attention.
weechat-matrix gets a lot of attention, works really well, has full E2EE support, and weechat at least is in major package managers. Matrix is evolving pretty fast though, so you'll probably have to install your own matrix plugin from https://github.com/poljar/weechat-matrix.
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...
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
> 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
No. There's an internal Slack for that, which I avoid as much as I can. (Mozilla dev here.) Matrix just requires you to create an account, not be part of Mozilla somehow.
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.
> is matrix persistent, like, will the server send backlog when you come back online?
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.
It actually is enabled, just a bug with the single sign-on which should be worked out soon. For now, click on Sign in and then you will be able to create an account.
Well done to the Matrix team, The future is here!