Too bad XMPP was effectively embraced/extended/extinguished by Google. In no small way thanks to lack of message acknowledgement in the protocol, which translated to lost messages and zombie presence, which was specially bad across servers, so it paid to be in the same server (which became typically google) as the other endpoint.
I did resist that, but unfortunately most of my contacts were in the Google server, and I got isolated from them when Google cut the cord. Ultimately, I never adopted Google Talk (out of principle), but XMPP has never been the same after that.
End to end encryption is also optional and not the default, which makes XMPP not much of an improvement over IRC. My hopes are with Matrix taking off, or a truly better (read: fully distributed) replacement like Tox gaining traction.
Showerthought: decentralised protocols needs to have some kind of antinetwork effects baked into them somehow, where there’s some kind of reward for staying out of the monoculture. I dunno what this actually looks like, though. Feels like the sort of thing some of the blockchain people might have a good answer for.
That’s a fascinating idea and I disagree. :D Network effects are powerful for good reason: centralization and economies of scale are efficient, both in resources like computer power, and in mental resources like “which the heck IRC network do I start a new channel on anyway”. What you do need is ways to avoid lock-in. If big popular network X starts abusing its power, then the reasonable response is to pick up your stakes and go somewhere else. So, that response needs to be as easy as possible. Low barriers to entry for creating new servers, low barriers to moving servers, low barriers to leaving servers.
I expect for any human system your going to result in something like Zipf’s law governing the distribution of who goes where; I don’t have a good reason for saying so, it’s just so damn common. Look at the population of Mastodon servers for example (I saw a really good graphic of sizes of servers and connections between them as a graph of interconnected bubbles once, I wish I could find it again). In my mind a healthy distributed community will probably have a handful of major servers/networks/instances, dozens or hundreds of medium-but-still-significant ones, and innumerable tiny ones.
More and more these days I feel like “efficiency” at a large enough scale is just another way to say “homogeneity”. BBSes and their store-and-forward message networks like FidoNet and RelayNet were certainly less efficient than the present internet, but they were a lot more interesting. Personal webpages at some-isp.com/~whoever might have been less efficient (by whatever metric you choose) than everyone posting on Facebook and Twitter but at least they actually felt personal. Of course I realize to some degree I’m over-romanticizing the past (culturally, BBSes and FidoNet especially, as well as the pre-social-media internet, were a lot more white, male, and cishet than the internet is today; and technologically, I’d gnaw my own arm off to not have to go back to dialup speeds), and having lowered the bar to publish content on the internet has arguably broadened the spectrum of viewpoints that can be expressed, but part of me wonders if the establishment of the internet monoculture we’ve ended up with, where the likes of Facebook basically IS the entire internet to the “average” person, was really necessary to get there.
I think in a capitalist system this is never going to be enough. What we really need is antitrust enforcement to prevent giant corporations from existing / gobbling up 98% of any kind of user.
How is IRC not federated? It’s transparently federated, unlike XMPP/Email/Matrix/ActivityPub/… that require a (user, server) tuple for identification, but it still doesn’t have a central point of failure or just one network.
IRC is not federated because a user is required to have a “nick” on each network they want to participate in. I have identities on at least 4 different disconnected IRC networks.
The IRC server to server protocol that allows networks to scale is very nice, and in an old-internet world of few bad actors having a single global network would have been great. But since we obviously don’t have a single global network, and since the network members cannot communicate with each other, it is not a federated system.
Servers in a network federate, true. But it’s not an open federation like email, where anyone can participate in a network by running their own server.
This! Too bad XMPP never really caught on after the explosion of social media, it’s a (near) perfect protocol for real time text-based communication, and then some.
It didn’t simply “not caught on”, it was deliberately starved by Facebook and Google by disabling federation between their networks and everyone else. There was a brief moment around 2010 when I could talk to all my friends on gTalk and Facebook via an XMPP client, so it did actually work.
(This was my personal moment when I stopped considering Google to be “not evil”.)
It was neat to have federatoion with gtalk, but when that died I finally got a bunch of my contacts off Google’s weak xmpp server and onto a better one, and onto better clients, etc. Was a net win for me
Dino, Gajim, Conversations.
You may want to select a suitable server from (or check your server via) https://compliance.conversations.im/ for the best UX.
Google was playing with Google+ at that moment and wanted to build a walled garden, which included a chat app(s). They even invented some “technical” reasons why XMPP wasn’t at all workable (after it has been working for them for years.)
It was weird ever since Android was released. The server could federate with other servers just fine, but Google Talk for Android spoke a proprietary C2S protocol, because the regular XMPP C2S involves keeping a TCP connection perpetually open, and that can’t be done on a smartphone without unacceptable power consumption.
I’m not sure that truly counts as a “good” technical reason to abandon S2S XMPP, but it meant that the Google Talk server was now privileged above all other XMPP servers in hard-to-resolve ways. It made S2S federation less relevant, because servers were no longer interchangeable.
I’m not sure the way GTalk clients talk to their server had anything to do with how the server talked to others. Even if it was, they could’ve treated as a technical problem needed solving rather than an excuse to drop the whole thing.
Dropping federation was claimed at the time (fully plausibly, imo) to be about spam mitigation. There was certainly a lot of XMPP spam around that time.
I have been using regular XMPP c2s on my phones over mobile data continuously since 2009 when I got my first smartphone. Battery life has never been an issue. I think if you have tonnes of TCPs the batterylife thing can be true, but for one XMPP session the battery impact is a myth
To make sure my memory wasn’t playing any tricks on me I did a quick google search. It did.
To make Facebook Chat available everywhere, we are using the technology Jabber (XMPP), an open messaging protocol supported by most instant messaging software,
That might be your experience but I’m not sure it’s true for the majority.
From my contact list of like 30 people 20 weren’t using GTalk in the first place (and no one use used FB for this, completely separate type of folks) and they all stopped using XMPP independently, not because of anything Google. And yes, there were interop problems with those 5, but overall I see the problem of XMPP’s downfall in popularity kinda orthogonal to Google, not related.
There’s definitely some truth to that, but still, my experience differs greatly. The majority of my contacts used Gtalk back in the day, and once that was off, they simply migrated to more popular, walled garden messaging services. That was the point in time where maintaining my own, self hosted XMPP VPS instance became unjustifiable in terms of the monthly cost and time, simply because there was no one I could talk to anymore.
I often hear this, but I’ve been doing most of my communicating with XMPP continuously for almost 20 years and it just keeps getting better and the community contiues to expand and get work done.
When I first got a JabberID the best I could do was use an MSN gateway to chat with some highschool pals from Gaim and have them complain that my text wasn’t in fun colours.
Now I can chat with most of my friends and family directly to their JabberIDs because it’s “just one more chat app” to them on their Android phone. I can send and receive text and picture messages with the phone network over XMPP, and just this month started receiving all voice calls to my phone number over XMPP. There are decent clients for every non-Apple platform and lots of exciting ecosystem stuff happening.
I think good protocols and free movements are slower because there is so much less money and attention, but there’s also less flash in the pan fad adoption, less being left high and dry by corporate M&A, and over time when the apps you used to compete with are long gone you stand as what is left and still working.
My experience tells me that the biggest obstacle of introducing open and battle-tested protocols to the masses is the insane friction of installing yet another app and opening yet another account. Most people simply can’t be bothered with it.
I used to do a lot of fun stuff with XMPP back in the day, just like you did, but nowadays, it’s extremely hard to make non-geek people around me join the bandwagon of pretty much anything outside the usual FAANG mainstream stuff. The concept of open protocols, federation, etc. is a very foreign concept to many ordinary people, for reasons I could never fully grasp.
Apparently, no one has ever solved that problem, despite many of them trying so hard.
I don’t really use XMPP, but I know that “just one more chat app” never works with almost everyone in my circle of friends. Unfortunately I still have to use Facebook Messenger to communicate with some people.
When I was building stuff with XMPP, I found it a little difficult to grasp. At its core, it was a very good idea and continues to drive how federation works in the modern world. I’m not sure if this has to do with the fact that it used XML and wasn’t capable of being transmitted using JSON, protobuf, or any other lightweight transport medium. Or whether it had to do with an extensive list of proposals/extensions in various states of completion that made the topology of the protocol almost impossible to visualize. But in my opinion, it’s not a “perfect” protocol by any means. There’s a good (technical) reason why most IM service operators moved away from XMPP after a while.
XMPP has gotten a lot better, to be fair – a few years ago, the situation really was dire in terms of having a set of extensions that enabled halfway decent mobile support.
It isn’t a perfect protocol (XML is a bit outdated nowadays, for one) – but crucially, the thing it has shown itself to be really good at is the extensibility aspect: the core is standardized as a set of IETF RFCs, and there are established ways to extend the core that protocols like IRC and Matrix really lack.
IRC has IRCv3 Capability Negotiation, sure, but that’s still geared toward client-server extensibility — XMPP lets you send blobs of XML to other users (or servers) and have the server just forward them, and provides a set of mechanisms to discover what anything you can talk to supports (XEP-0030 Service Discovery). This means, for example, you can develop A/V calls as a client-to-client feature without the server ever having to care about how they work, since you’re building on top of the standard core features that all servers support.
Matrix seems to be denying the idea that extensibility is required, and think they can get away with having One True Protocol. I don’t necessarily think this is a good long-term solution, but we’ll see…
Matrix has the Spec Proposal progress for moving the core spec forward. And it has namespacing (with “m.” reserved as the core prefix, rest should use reverse domain like “rs.lobste.*”) for extension. What do you think is missing?
Okay, this may have improved since I last checked; it looks like they at least have the basics of some kind of dynamic feature / capability discovery stuff down.
IRCv3 has client-to-client tags which can contain up to 4096 bytes per message of arbitrary data, which can be attached to any message, or be sent as standalone TAGMSG.
This is actually how emoji reactions, thread replies, and stuff like read/delivery notifications are implemented, and some clients already made a prototype using it for handshaking WebRTC calls.
Sure. However, message tags are nowhere near ubiquitous; some IRC netadmins / developers even reject the idea that arbitrary client-to-client communication is a good thing (ref).
You can get arbitrary client-to-client communication with ircv3 in some configurations. My point is that XMPP allows it in every configuration; in fact, that’s one of the things that lets you call your implementation XMPP :p
I think an accessible client with sane defaults—especially for mobile—will go a long way in increasing IRC adoption. Something as seamless as WhatsApp or Telegram. And I think the lack of E2EE is fine for the average user’s threat model (my parents, for example).
Accessibility (as in, easy to obtain, install, and start using) and sane defaults are entirely the reason newer (and less open/free) software has historically won with end users. The people who build software like fiddling with settings and exploring, the people who use software do not like that.
Every project that makes you say “why don’t more end users used this instead of [Apple/Google/Facebook/Microsoft/Etc]”, the answer is probably because of accessibility and sane defaults. Even if there are multiple ways to accomplish something, there should be one logical path and the application should noticeably steer you towards that one logical path at every opportunity.
Also, another word for providing “accessibility and sane defaults” is called “design”. Not as in “protocol design” (design for computers), but as in “user interface design” (design for humans). Many projects de-prioritize the latter, due to greater interest in tinkering with the guts of the program than tailoring it to its ostensible audience. I call this phenomenon “hobbyism”, and it’s one of the downsides of projects that provide their contributors freedom, thereby depriving them of structure.
These projects are now dying off, and although I don’t celebrate it, it is a reasonable death.
If centralizing/capitalism-izing chat is what it takes to get halfway-decent designers on board, then I’m signing the deal with the FAANG (+M) devil. The current situation is obscenely Orwellian, and I’d love for us to find another way (and I think Matrix seems promising!), but for now I’ve accepted it and moved onto other projects.
I think IRCCloud is the closest thing to “sane defaults” in the IRC space, messages stay on the server, iOS and Android clients, consistent persistence and lots of other little goodies.
The killer downside is the price, to get the permanently connected account requires a $5 a month subscription (https://www.irccloud.com/pricing) which I happily pay, but most will not stomach.
If IRCCloud would move “Stay connected permanently while inactive” to the free client, I think they would pick up a MASSIVE number of users.
Normies being gone from IRC is literally the best thing that has happened to IRC.
If getting into IRC was “accessible” as you call it, it’d be flooded with bottom-of-the-barrel, clueless users asking dumb questions, posting links to animated emote pictures and the like.
A good portion of the appeal of IRC is not having to deal with any of that.
meh. Setting aside whether dismissing people as “normies” is elitist ($0.02: it is), it’s not just clueless people who leave IRC, it’s useful and important FOSS projects too. I don’t think “accessible” is a great word, since this often has very little to do with usability by people with disabilities, but I also don’t think this is a bad thing. The friendly-to-non-hacker platforms people are moving to don’t seem to be flooded with low-quality questions AFAICT.
The friendly-to-non-hacker platforms people are moving to don’t seem to be flooded with low-quality questions AFAICT.
That’s what happens when you stop limiting these platforms to technical people: you get non-technical people. So if you think have a platform that can survive without non-technical folks—and it probably can’t—then go ahead and use IRC. Just remember that there’s a diversity cost to gatekeeping.
This reads like a reply to the opposite of what I said. I don’t think keeping non-technical people out is a good feature. I do think the barriers seem, for the most part, frustratingly inconsequential (e.g. you have to type a command to register with your email and password instead of typing those things in their own boxes).
It doesn’t seem entirely reasonable to assume that everyone using IRC is gatekeeping.
You’re right, I must have misunderstood; my bad. I will say, though, that even if it isn’t as intentional as “gatekeeping”, using IRC does implicitly limit your peers to the technically-minded, and there should be a similar word for that. For now, I’ll just say “incidental gatekeeping”.
The friendly-to-non-hacker platforms people are moving to don’t seem to be flooded with low-quality questions AFAICT.
Which platforms are you talking about? Discord is the one I see that has truly replaced IRC for group chats on small to medium projects, and in my experience it has been utterly overrun with low quality posting, animated emote pictures, etc. (Though that’s far from my biggest gripe about discord.) It’s especially bad on “servers” where the admin leaves most defaults in place.
I was thinking of Discord and Slack. There are a couple of Discord guilds for FOSS projects that I occasionally drop in on, and the overall quality doesn’t seem—to me—appreciably worse than that of, say, #python. I’m definitely thinking mostly of support channels rather than more generally focused ones; maybe the latter are much worse.
The #clojure IRC channel took a big hit when the unofficial Clojure slack was started. It’s still around, but it’s a pale shadow of what it used to be. Meanwhile the #emacs IRC channel and the #fennel IRC channel are going strong because those folks know better than to depend on Slack or Discord or any such shit.
I find Discord especially annoying, as we’re moving from community-run IRC networks (open protocol with plenty of server and client implementations for pretty much all platforms including anemic and ancient computers) to something that’s commercial and completely centralized (complete with global IDs that make the whole “servers” concept not just completely wrong but also irrelevant) and requires a heavy web browser to access.
Accessibility is consciously a broad term. IRC may be very accessible system to people with visual disabilities, but not to others - e.g. joining an IRC server is very arcane. Translated tutorials are hard to get. This is not a system for people with any kind of cognitive issues or even just language barriers.
I regularly chat with a blind person (my last reason to use IRC) and let’s not kid ourselves: none of the client implementers care. For example, many TUIs use visual bars to highlight a currently active selection (like the channel your selection currently “hovers” over), but no cursor. This is inaccessible - TUIs become completely inaccessible if the cursor position becomes non-sensical. This is essentially their main reason to not drop for example for matrix, using a terminal client for it, because most terminal clients like weechat commit such mistakes.
In the end, this has nothing to do with IRC. It has something to do with how little everyone cares about this. None of the systems discussed here is fundamentally inaccessible.
IRC is simple enough that it would not take much effort to implement a client specifically for a person with a specific disability.
This is not true. It takes substantial effort for a person to implement a full client because other clients don’t care about accessibility. The person themselves is a programmer - they could even implement the client, but that would take a chunk of their own time for something that could rather easily be fixed if client implementors cared. My point is that “plain text is accessible” is often a mistaken assumption, this would e.g. not be an issue if you had a GTK client with standard widgets (accessibility support in GTK is okay).
Also, it’s a fundamentally exclusive stance: those that need it should implement their own clients. weechat is also more than an irc-client: it is a multi-protocol client, which would unlock a lot more options for that person.
Sure, but having loads of clients to choose from and, on top of that, a protocol simple enough to minimize the effort of implementing a disability optimized full client if desired is definitely much better than the alternative.
100% disagree, you get all that on other platforms as well, there are ways to keep them in check. I’ve been part of quite a few non-technical channels and they were a lot better off when they weren’t strictly populated by nerds who were on irc anyway. Those people are now probably on WhatsApp, Telegram or whatever, but not anywhere near where I am.
I think the lack of E2EE is probably the optimal default, tbh. IRC is mostly designed for public or semi-public channels, where it doesn’t make a lot of sense, and we also have open private messaging by default, which means the world where servers can’t see into PMs would be rather spammy. (We didn’t always have a server that could do that, and lots of people complained.) For people who understand the risks, there’s already OTR.
IRC is clearly not good enough. It had the users at some point and network effects should have allowed it to remain on top if it had truly been good enough. My hope is that Matrix will take the top spot. XMPP would be okay as well. But thankfully Matrix and XMPP can be made to bridge to one another. Yay openness, federation and bridging!
In my opinion, Matrix is a very heavy and complex protocol, and it’s getting even more heavy and complex: you can hardly say it’s really an open standard. Element is pretty much the only usable client, Synapse is pretty much the only usable homeserver, and matrix.org—where everyone registers—is always slow and has trouble federating. I think its future depends mainly on New Vector and commercial interests.
Yes, matrix the protocol is complex to implement. But it doesn’t seem needlessly complex when looking at the requirements. And the specification is designed so that clients are easy to implement, the server does most of the work. Here’s a good example of a simple client: https://github.com/ara4n/random/blob/master/bashtrix.sh
There are lots of usable clients, but you’re right that element is probably the only full-featured one. The alternative homeservers are coming along well lately.
Also, there is the matrix foundation, which owns the copyright on most stuff. True, new vector / element (has the company renaming completed yet?) is the major driving force, just as mozilla is to firefox. But there are others working on it as well. Without new vector the progress would be slower, but I doubt it would stop.
Decisions like polling JSON over HTTP instead of working directly with TCP sockets, were intended to make it easier to implement. The protocol is simple, but huge: you have tons of endpoints and JSON objects, that creating a full-featured client is extremely difficult. One of the most difficult aspects is also UI/UX, especially for device verification, cross-signing and encryption keys. It’s a lot of simple things, bundled into a single complex thing.
Clients can be made to be (at least partially) lightweight fairly easily. What I was mostly referring to is the server-side implementation. I was considering running my own Matrix instance for me and my friends, only to discover that we’d need a significant amount of RAM and CPU time since we were planning to subscribe to a bunch of high-traffic rooms and run a few bridges to various other services.
I have an account on matrix.org and it does get slow at times when it tries to fetch new messages after a few hours of inactivity. Not sure if the existing, “primary” Synapse implementation can be optimized significantly, but it could sure use some of it if at all possible.
True, synapse can be a bit heavy. But the matrix people seem to be following the rule “make it work, make it right, make it fast”. Synapse has improved a lot in the past couple of months. And they are focusing on improving synapse further. Memory use can be hard to completely fix in a Python-based project. But Dendrite is also improving. Construct is an independent homeserver that can federate and is fast. I haven’t run in though. And there are some other homeserver projects that seem to be quite fast as well.
I haven’t gone through all the specifics regarding the protocol itself, but I do agree the current implementations of the protocol are pretty taxing in terms of system resource usage, among other things. The problem is, how do you implement a protocol that provides so much functionality and keep it lightweight. Such a task would require a lot of engineering effort and thinking many things through before you touch a keyboard.
If Matrix catches on even more, less heavy implementations will likely appear at some point, but it won’t happen overnight.
How do you implement a protocol that provides so much functionality and keep it lightweight? Don’t. Instead of a huge single protocol, you can use multiple lightweight protocols to achieve the same thing, and you can even glue them together into a single platform. Matrix is, in a sense, a bridging layer that connects multiple different protocols; but it’s so big, that it can also be used standalone. You could easily replace Matrix with XMPP, IRC, ZNC and IPFS; and it would work just fine.
Because IRC is not federated the bridging there is necessarily more ugly and weird. You have to have a nick on the target network in order to speak there, and there’s no obvious nick the bridge can just make up for you that will not look weird to IRC people.
There’s two different kinds of bridging you can do; as a matrix user you can bridge your account to freenode, which mostly works but is a bit flaky and rather difficult to set up. As a channel owner you can bridge the entire channel, and this works great; you only have to do it once and everyone benefits from it. We did this in the #fennel channel and I have no regrets; all the core devs can keep the workflow they’re familiar with, and all the newcomers can come thru Matrix and get the persistent history and other nice features that take more work to set up on IRC.
yeah, not on Freenode, but apart from once-in-a-month “I didn’t get that message” or some formatting messups with certain matrix clients it’s pretty flawless. I love IRC but it’s a pain on mobile, matrix is a lot better there.
Something I like about IRC is also that it just works. When I use Slack, I sometimes don’t get notifications, also it sometimes messes up, compared to it Discord is better, which makes me wonder whether it wouldn’t be the better solution for companies, but that one sometimes takes inserts of text or links twice (both browsers and app, and on multiple OSs) and the voice chat stuff is actually one of the worst I’ve seen in quite some time. Then there is stuff like Telegram and WeChat which could theoretically be used, but people don’t really want to, because it’s more of a private thing. Matrix is too technical and while there are a couple of projects to make XMPP something more fitting for companies I don’t know of any actually succeeding. Mattermost appears to be good, but somehow doesn’t end up being famous enough and while self-hosting is its biggest pro and actually isn’t that big of a deal due to various reasons very few actually want to do that.
So what I am trying to say is that while IRC has its limitations the stuff that is there actually works really well, which cannot be said about most of the others and I say that as someone using most of these other than IRC on a daily basis. But when I go back to IRC, and have times when I use it more regularly the fact that in it’s boundaries it just works makes it a real pleasure to use. I think that that’s someone it has in common with e-mail for example.
One of the problems of this text is the focus on bandwidth and connecting that to areas with low internet infrastructure. Sadly, this is barking up the wrong tree. Bandwidth is rarely the problem for something as simple as chat.
Especially things like emoji reactions and similar are actually bandwidth-saving, as they are a rich visual language included in unicode, which ships with your phone (which is the classic end device in the markets they aim at). Stickers are usually mapped to unicode and can be switched off.
Image transmission is an important component of general chat, as it allows people to exchange visual information quickly. WhatsApp is hugely popular in emerging markets.
For a lot of the tasks that the text gives, bandwidth is available enough.
The problem in many of those markets is uninterrupted connectivity. This means that it’s hard to keep an ongoing connection over a long time. That’s one of the reasons why quite some systems e.g. use SMS as a message exchange method (a field in which I did research). As an example, when I’m travelling in the sourthern parts of Africa (often Botswana), I usually even have problems using git, because git assumes that you can fully upload a pack and breaks and retries if it can’t. I use file syncing tools that allow partial uploads down there. Instagram is actually an unsung hero there :).
Tools and protocols that deal well with those situations work great there.
IRC in particular is not a good protocol for those situations. If it loses connection, you miss messages. If you are offline connection, you are unreachable for DMs in many clients. You need a bouncer, which is outside of the protocol, to get an interaction level that modern chat users assume.
By far the biggest problem I have with IRC is that I can’t just occasionally drop in. Well, you can, but you don’t have any history. I can’t just post a message, go away, and check if there’s a reply 2 hours later, or the next day. Or I can’t respond to questions people asked when I was away.
The last time I used Slack in any sort of serious manner was when I helped maintain vim-go. I would drop in every day or two, see if there are any questions or whatnot in the #vim channel, and reply when appropriate. We also used it as a private communication with the two other maintainers at the time. This worked fairly well since we were in wildly different TZs at the time (US, Turkey, NZ).
I don’t really care much for Slack – I really dislike using it for reasons of UX – but this alone made it infinitely better than IRC. I just don’t want to set up a server with an IRC bouncer and all that shizzle. It’s just too much effort, never mind costs in financial terms (I need to buy/rent a server!) and the time I need to spend (I got a life, and hobbies outside of computers).
I think there are plenty of other areas where IRC could be improved, but they’re comparative details IMO. This is just a giant usability wall. It’s just handwaved away in this article.
As far as I know, the only easy/simple solution for this is a $5/month IRCCloud account. Setting up a community-run free IRCCloud alternative would probably do far more for IRC than these kind of articles (although I don’t know how feasible that would be, and abuse will probably be an issue so it’s probably not a “just do it”-kind of thing).
Here are some modern affordances that I miss in IRC
multiline messages. Being able to express longer sentences, and break them off into paragraphs, is essential to communicate more complex information with text.
Similarly, being able to edit already posted messages aids communication
Being able to format text for emphasis etc also helps, and is it hard on most clients
IRC is not well-served on mobile, unless one pays for IRCloud or sets up a bouncer - something that’s fraught with complexity in its own right
While one can augment the deficiencies of the protocol with 3rd party add-ons like bouncers and bots, the landscape is fragmented. AFAIK there’s no standard interface for bots that allows a user to join a channel, find out the bot name, and then have some PMs with the bot to find out about echoes, tells etc. Each channel does its own thing, and commands begin with . or ! or something else.
Running a bot requires someone hosting it, and if the bots connection is lost one has to find the person responsible and get them to get it up and running.
I don’t know how many of the above deficiencies will be solved by IRCv3. Even if they are, as far as I know there’s no active IRCv3 network up and running.
I’m also surprised to hear that. Unless you explicitly look for troll channels, my experience has either been quiet (but quick to answer) or constantly active, and on topic.
I can’t say I’ve seen the things that the grandparent comment mentioned, but they definitely wouldn’t be on Freenode. If you limit yourself to Freenode, IRC is a very safe and well-moderated experience, especially on some exemplary channels like the Haskell one.
I have accidentally wandered into uncomfortable conversations and much worse things on some of the other popular IRC networks, of which quite a few still exist: https://netsplit.de/networks/top100.php
The same thing is true of sketchy Discord servers as well; it’s not like IRC is unique in this regard.
A year or two back, Supernets was spamming hard on IRC networks. I forgot if Freenode was affected, but I know a lot of the smaller networks I was on were.
Not OP, but I spend my time on IRCnet and EFnet since my IRC use is just to stay in touch with friends. Anyway, last year I was DDoS’d pretty hard because someone wanted my nick on EFnet.
Sometimes I miss #C++ on EFnet, not enough to go back on EFnet, but I do miss it – a lot of wonderful people were there in the late 90s. Freenode feels a lot more sane in terms of management and tools for the system operators. Cloaks and nickname registration go a long way.
It’s not good, it’s just not bad. Especially for simple use cases, it makes simple things easy. Hard things are still pretty damn hard though.
Simplest example I can think of, if I’m remembering it right: Each message includes its length. That is the length of the whole message, not the just the payload; it’s payload+header. So if you want to, say, make sure that a payload is small enough for the server to accept or else split it into multiple messages, your target size varies depending on server and channel.
Close, but no cigar! The actual issue is that you send a message to your IRC server like
PRIVMSG eta :hi there!
but it gets relayed to the other user like
:randomuser!~ident@host PRIVMSG eta :hi there!
Worse, it might get relayed to another server like
:42A00001 PRIVMSG 43A00002 :hi there!
(where 42A00001 and 43A00002 are user UIDs).
And all of these have the same 256-byte-or-whatever length restriction.
So basically, it’s Quite Difficult to determine how long you should make your message. If you figure out what your nick!user@host is and do maths based off that you’re probably fine, but you could not be if the server-to-server link stuffs things up.
Aha, thank you for the correction! It has been a long time, but it was basically that issue that made me give up on writing my own IRC client lib once upon a time.
Even though encryption is not mandated by IRC or enabled by default in many cases, you can still enforce encrypted client-server or server-server connections on your IRC server. This means that all messages in transit between clients and your server would be encrypted (usually with TLS) and the only weakness would be logs on the servers themselves or logs on client machines. If you and your friends like the plain text medium, it’s entirely possible to set up an IRC server which mandates encryption and doesn’t store logs long-term.
Alternately, assuming you trust the server, you can make it so the channel can only be joined by people connecting via ssl.
The article would be better, IMO, if it focused on the things IRC is good at instead of defending areas where it’s not.
IRC’s lack of federation and agreed-upon extensability is what drove me to XMPP over a decade ago. Never looked back.
Too bad XMPP was effectively embraced/extended/extinguished by Google. In no small way thanks to lack of message acknowledgement in the protocol, which translated to lost messages and zombie presence, which was specially bad across servers, so it paid to be in the same server (which became typically google) as the other endpoint.
I did resist that, but unfortunately most of my contacts were in the Google server, and I got isolated from them when Google cut the cord. Ultimately, I never adopted Google Talk (out of principle), but XMPP has never been the same after that.
End to end encryption is also optional and not the default, which makes XMPP not much of an improvement over IRC. My hopes are with Matrix taking off, or a truly better (read: fully distributed) replacement like Tox gaining traction.
Showerthought: decentralised protocols needs to have some kind of antinetwork effects baked into them somehow, where there’s some kind of reward for staying out of the monoculture. I dunno what this actually looks like, though. Feels like the sort of thing some of the blockchain people might have a good answer for.
That’s a fascinating idea and I disagree. :D Network effects are powerful for good reason: centralization and economies of scale are efficient, both in resources like computer power, and in mental resources like “which the heck IRC network do I start a new channel on anyway”. What you do need is ways to avoid lock-in. If big popular network X starts abusing its power, then the reasonable response is to pick up your stakes and go somewhere else. So, that response needs to be as easy as possible. Low barriers to entry for creating new servers, low barriers to moving servers, low barriers to leaving servers.
I expect for any human system your going to result in something like Zipf’s law governing the distribution of who goes where; I don’t have a good reason for saying so, it’s just so damn common. Look at the population of Mastodon servers for example (I saw a really good graphic of sizes of servers and connections between them as a graph of interconnected bubbles once, I wish I could find it again). In my mind a healthy distributed community will probably have a handful of major servers/networks/instances, dozens or hundreds of medium-but-still-significant ones, and innumerable tiny ones.
More and more these days I feel like “efficiency” at a large enough scale is just another way to say “homogeneity”. BBSes and their store-and-forward message networks like FidoNet and RelayNet were certainly less efficient than the present internet, but they were a lot more interesting. Personal webpages at some-isp.com/~whoever might have been less efficient (by whatever metric you choose) than everyone posting on Facebook and Twitter but at least they actually felt personal. Of course I realize to some degree I’m over-romanticizing the past (culturally, BBSes and FidoNet especially, as well as the pre-social-media internet, were a lot more white, male, and cishet than the internet is today; and technologically, I’d gnaw my own arm off to not have to go back to dialup speeds), and having lowered the bar to publish content on the internet has arguably broadened the spectrum of viewpoints that can be expressed, but part of me wonders if the establishment of the internet monoculture we’ve ended up with, where the likes of Facebook basically IS the entire internet to the “average” person, was really necessary to get there.
I think in a capitalist system this is never going to be enough. What we really need is antitrust enforcement to prevent giant corporations from existing / gobbling up 98% of any kind of user.
How is IRC not federated? It’s transparently federated, unlike XMPP/Email/Matrix/ActivityPub/… that require a (user, server) tuple for identification, but it still doesn’t have a central point of failure or just one network.
IRC is not federated because a user is required to have a “nick” on each network they want to participate in. I have identities on at least 4 different disconnected IRC networks.
The IRC server to server protocol that allows networks to scale is very nice, and in an old-internet world of few bad actors having a single global network would have been great. But since we obviously don’t have a single global network, and since the network members cannot communicate with each other, it is not a federated system.
Servers in a network federate, true. But it’s not an open federation like email, where anyone can participate in a network by running their own server.
This! Too bad XMPP never really caught on after the explosion of social media, it’s a (near) perfect protocol for real time text-based communication, and then some.
It didn’t simply “not caught on”, it was deliberately starved by Facebook and Google by disabling federation between their networks and everyone else. There was a brief moment around 2010 when I could talk to all my friends on gTalk and Facebook via an XMPP client, so it did actually work.
(This was my personal moment when I stopped considering Google to be “not evil”.)
It was neat to have federatoion with gtalk, but when that died I finally got a bunch of my contacts off Google’s weak xmpp server and onto a better one, and onto better clients, etc. Was a net win for me
What are “better clients” these days for XMPP? I love the IDEA of XMPP, but I loathe the implementations.
Dino, Gajim, Conversations. You may want to select a suitable server from (or check your server via) https://compliance.conversations.im/ for the best UX.
I don’t have that much influence over my contacts :-)
This.
Network effects win out over the network itself, every time.
I guess neither do I? That’s why it took Google turning off the server to make them switch
IIRC it was Facebook that was a bad actor and started letting the communication go only one way to siphon users from gtalk and forced Google’s hand.
Google was playing with Google+ at that moment and wanted to build a walled garden, which included a chat app(s). They even invented some “technical” reasons why XMPP wasn’t at all workable (after it has been working for them for years.)
It was weird ever since Android was released. The server could federate with other servers just fine, but Google Talk for Android spoke a proprietary C2S protocol, because the regular XMPP C2S involves keeping a TCP connection perpetually open, and that can’t be done on a smartphone without unacceptable power consumption.
I’m not sure that truly counts as a “good” technical reason to abandon S2S XMPP, but it meant that the Google Talk server was now privileged above all other XMPP servers in hard-to-resolve ways. It made S2S federation less relevant, because servers were no longer interchangeable.
I’m not sure the way GTalk clients talk to their server had anything to do with how the server talked to others. Even if it was, they could’ve treated as a technical problem needed solving rather than an excuse to drop the whole thing.
Dropping federation was claimed at the time (fully plausibly, imo) to be about spam mitigation. There was certainly a lot of XMPP spam around that time.
I have been using regular XMPP c2s on my phones over mobile data continuously since 2009 when I got my first smartphone. Battery life has never been an issue. I think if you have tonnes of TCPs the batterylife thing can be true, but for one XMPP session the battery impact is a myth
AFAIK Facebook never had federated XMPP, just a slightly working c2s bridge
To make sure my memory wasn’t playing any tricks on me I did a quick google search. It did.
From: https://www.facebook.com/notes/facebook-app/facebook-chat-now-available-everywhere/297991732130/
I don’t remember the move they did on Google to siphon users though, but I remember thinking it was a scummy move.
That link is talking about their c2s bridge. You still needed a Facebook account to use it. It was not federated.
That might be your experience but I’m not sure it’s true for the majority.
From my contact list of like 30 people 20 weren’t using GTalk in the first place (and no one use used FB for this, completely separate type of folks) and they all stopped using XMPP independently, not because of anything Google. And yes, there were interop problems with those 5, but overall I see the problem of XMPP’s downfall in popularity kinda orthogonal to Google, not related.
There’s definitely some truth to that, but still, my experience differs greatly. The majority of my contacts used Gtalk back in the day, and once that was off, they simply migrated to more popular, walled garden messaging services. That was the point in time where maintaining my own, self hosted XMPP VPS instance became unjustifiable in terms of the monthly cost and time, simply because there was no one I could talk to anymore.
I often hear this, but I’ve been doing most of my communicating with XMPP continuously for almost 20 years and it just keeps getting better and the community contiues to expand and get work done.
When I first got a JabberID the best I could do was use an MSN gateway to chat with some highschool pals from Gaim and have them complain that my text wasn’t in fun colours.
Now I can chat with most of my friends and family directly to their JabberIDs because it’s “just one more chat app” to them on their Android phone. I can send and receive text and picture messages with the phone network over XMPP, and just this month started receiving all voice calls to my phone number over XMPP. There are decent clients for every non-Apple platform and lots of exciting ecosystem stuff happening.
I think good protocols and free movements are slower because there is so much less money and attention, but there’s also less flash in the pan fad adoption, less being left high and dry by corporate M&A, and over time when the apps you used to compete with are long gone you stand as what is left and still working.
My experience tells me that the biggest obstacle of introducing open and battle-tested protocols to the masses is the insane friction of installing yet another app and opening yet another account. Most people simply can’t be bothered with it.
I used to do a lot of fun stuff with XMPP back in the day, just like you did, but nowadays, it’s extremely hard to make non-geek people around me join the bandwagon of pretty much anything outside the usual FAANG mainstream stuff. The concept of open protocols, federation, etc. is a very foreign concept to many ordinary people, for reasons I could never fully grasp.
Apparently, no one has ever solved that problem, despite many of them trying so hard.
I don’t really use XMPP, but I know that “just one more chat app” never works with almost everyone in my circle of friends. Unfortunately I still have to use Facebook Messenger to communicate with some people.
When I was building stuff with XMPP, I found it a little difficult to grasp. At its core, it was a very good idea and continues to drive how federation works in the modern world. I’m not sure if this has to do with the fact that it used XML and wasn’t capable of being transmitted using JSON, protobuf, or any other lightweight transport medium. Or whether it had to do with an extensive list of proposals/extensions in various states of completion that made the topology of the protocol almost impossible to visualize. But in my opinion, it’s not a “perfect” protocol by any means. There’s a good (technical) reason why most IM service operators moved away from XMPP after a while.
I do wish something would take its place, though.
Meanwhile it takes about a page or two of code to make an IRC bot.
XMPP has gotten a lot better, to be fair – a few years ago, the situation really was dire in terms of having a set of extensions that enabled halfway decent mobile support.
It isn’t a perfect protocol (XML is a bit outdated nowadays, for one) – but crucially, the thing it has shown itself to be really good at is the extensibility aspect: the core is standardized as a set of IETF RFCs, and there are established ways to extend the core that protocols like IRC and Matrix really lack.
IRC has IRCv3 Capability Negotiation, sure, but that’s still geared toward client-server extensibility — XMPP lets you send blobs of XML to other users (or servers) and have the server just forward them, and provides a set of mechanisms to discover what anything you can talk to supports (XEP-0030 Service Discovery). This means, for example, you can develop A/V calls as a client-to-client feature without the server ever having to care about how they work, since you’re building on top of the standard core features that all servers support.
Matrix seems to be denying the idea that extensibility is required, and think they can get away with having One True Protocol. I don’t necessarily think this is a good long-term solution, but we’ll see…
Matrix has the Spec Proposal progress for moving the core spec forward. And it has namespacing (with “m.” reserved as the core prefix, rest should use reverse domain like “rs.lobste.*”) for extension. What do you think is missing?
Okay, this may have improved since I last checked; it looks like they at least have the basics of some kind of dynamic feature / capability discovery stuff down.
IRCv3 has client-to-client tags which can contain up to 4096 bytes per message of arbitrary data, which can be attached to any message, or be sent as standalone TAGMSG.
This is actually how emoji reactions, thread replies, and stuff like read/delivery notifications are implemented, and some clients already made a prototype using it for handshaking WebRTC calls.
Sure. However, message tags are nowhere near ubiquitous; some IRC netadmins / developers even reject the idea that arbitrary client-to-client communication is a good thing (ref).
You can get arbitrary client-to-client communication with ircv3 in some configurations. My point is that XMPP allows it in every configuration; in fact, that’s one of the things that lets you call your implementation XMPP :p
I have been using XMPP on mobile without issue since at least 2009
I think an accessible client with sane defaults—especially for mobile—will go a long way in increasing IRC adoption. Something as seamless as WhatsApp or Telegram. And I think the lack of E2EE is fine for the average user’s threat model (my parents, for example).
Accessibility (as in, easy to obtain, install, and start using) and sane defaults are entirely the reason newer (and less open/free) software has historically won with end users. The people who build software like fiddling with settings and exploring, the people who use software do not like that.
Every project that makes you say “why don’t more end users used this instead of [Apple/Google/Facebook/Microsoft/Etc]”, the answer is probably because of accessibility and sane defaults. Even if there are multiple ways to accomplish something, there should be one logical path and the application should noticeably steer you towards that one logical path at every opportunity.
I agree.
Also, another word for providing “accessibility and sane defaults” is called “design”. Not as in “protocol design” (design for computers), but as in “user interface design” (design for humans). Many projects de-prioritize the latter, due to greater interest in tinkering with the guts of the program than tailoring it to its ostensible audience. I call this phenomenon “hobbyism”, and it’s one of the downsides of projects that provide their contributors freedom, thereby depriving them of structure.
These projects are now dying off, and although I don’t celebrate it, it is a reasonable death.
If centralizing/capitalism-izing chat is what it takes to get halfway-decent designers on board, then I’m signing the deal with the FAANG (+M) devil. The current situation is obscenely Orwellian, and I’d love for us to find another way (and I think Matrix seems promising!), but for now I’ve accepted it and moved onto other projects.
I think IRCCloud is the closest thing to “sane defaults” in the IRC space, messages stay on the server, iOS and Android clients, consistent persistence and lots of other little goodies.
The killer downside is the price, to get the permanently connected account requires a $5 a month subscription (https://www.irccloud.com/pricing) which I happily pay, but most will not stomach.
If IRCCloud would move “Stay connected permanently while inactive” to the free client, I think they would pick up a MASSIVE number of users.
Matrix combined with IRC bridging can work as an (free) alternative to IRCCloud.
Normies being gone from IRC is literally the best thing that has happened to IRC.
If getting into IRC was “accessible” as you call it, it’d be flooded with bottom-of-the-barrel, clueless users asking dumb questions, posting links to animated emote pictures and the like.
A good portion of the appeal of IRC is not having to deal with any of that.
meh. Setting aside whether dismissing people as “normies” is elitist ($0.02: it is), it’s not just clueless people who leave IRC, it’s useful and important FOSS projects too. I don’t think “accessible” is a great word, since this often has very little to do with usability by people with disabilities, but I also don’t think this is a bad thing. The friendly-to-non-hacker platforms people are moving to don’t seem to be flooded with low-quality questions AFAICT.
That’s what happens when you stop limiting these platforms to technical people: you get non-technical people. So if you think have a platform that can survive without non-technical folks—and it probably can’t—then go ahead and use IRC. Just remember that there’s a diversity cost to gatekeeping.
This reads like a reply to the opposite of what I said. I don’t think keeping non-technical people out is a good feature. I do think the barriers seem, for the most part, frustratingly inconsequential (e.g. you have to type a command to register with your email and password instead of typing those things in their own boxes).
It doesn’t seem entirely reasonable to assume that everyone using IRC is gatekeeping.
You’re right, I must have misunderstood; my bad. I will say, though, that even if it isn’t as intentional as “gatekeeping”, using IRC does implicitly limit your peers to the technically-minded, and there should be a similar word for that. For now, I’ll just say “incidental gatekeeping”.
Which platforms are you talking about? Discord is the one I see that has truly replaced IRC for group chats on small to medium projects, and in my experience it has been utterly overrun with low quality posting, animated emote pictures, etc. (Though that’s far from my biggest gripe about discord.) It’s especially bad on “servers” where the admin leaves most defaults in place.
I was thinking of Discord and Slack. There are a couple of Discord guilds for FOSS projects that I occasionally drop in on, and the overall quality doesn’t seem—to me—appreciably worse than that of, say, #python. I’m definitely thinking mostly of support channels rather than more generally focused ones; maybe the latter are much worse.
The #clojure IRC channel took a big hit when the unofficial Clojure slack was started. It’s still around, but it’s a pale shadow of what it used to be. Meanwhile the #emacs IRC channel and the #fennel IRC channel are going strong because those folks know better than to depend on Slack or Discord or any such shit.
I find Discord especially annoying, as we’re moving from community-run IRC networks (open protocol with plenty of server and client implementations for pretty much all platforms including anemic and ancient computers) to something that’s commercial and completely centralized (complete with global IDs that make the whole “servers” concept not just completely wrong but also irrelevant) and requires a heavy web browser to access.
That’s why I used the quotes, but I then forgot to clarify. Thanks for cleaning after me :-)
IRC is, as far as I am aware, the most accessible chat system.
Accessibility is consciously a broad term. IRC may be very accessible system to people with visual disabilities, but not to others - e.g. joining an IRC server is very arcane. Translated tutorials are hard to get. This is not a system for people with any kind of cognitive issues or even just language barriers.
I regularly chat with a blind person (my last reason to use IRC) and let’s not kid ourselves: none of the client implementers care. For example, many TUIs use visual bars to highlight a currently active selection (like the channel your selection currently “hovers” over), but no cursor. This is inaccessible - TUIs become completely inaccessible if the cursor position becomes non-sensical. This is essentially their main reason to not drop for example for matrix, using a terminal client for it, because most terminal clients like weechat commit such mistakes.
In the end, this has nothing to do with IRC. It has something to do with how little everyone cares about this. None of the systems discussed here is fundamentally inaccessible.
IRC is simple enough that it would not take much effort to implement a client specifically for a person with a specific disability.
Or use an old/simple enough client. ircII or ii by suckless
You can even connect to matrix using an irc client thanks to matrix-ircd
This is not true. It takes substantial effort for a person to implement a full client because other clients don’t care about accessibility. The person themselves is a programmer - they could even implement the client, but that would take a chunk of their own time for something that could rather easily be fixed if client implementors cared. My point is that “plain text is accessible” is often a mistaken assumption, this would e.g. not be an issue if you had a GTK client with standard widgets (accessibility support in GTK is okay).
Also, it’s a fundamentally exclusive stance: those that need it should implement their own clients. weechat is also more than an irc-client: it is a multi-protocol client, which would unlock a lot more options for that person.
Sure, but having loads of clients to choose from and, on top of that, a protocol simple enough to minimize the effort of implementing a disability optimized full client if desired is definitely much better than the alternative.
100% disagree, you get all that on other platforms as well, there are ways to keep them in check. I’ve been part of quite a few non-technical channels and they were a lot better off when they weren’t strictly populated by nerds who were on irc anyway. Those people are now probably on WhatsApp, Telegram or whatever, but not anywhere near where I am.
hell yea
Please write one!
I think the lack of E2EE is probably the optimal default, tbh. IRC is mostly designed for public or semi-public channels, where it doesn’t make a lot of sense, and we also have open private messaging by default, which means the world where servers can’t see into PMs would be rather spammy. (We didn’t always have a server that could do that, and lots of people complained.) For people who understand the risks, there’s already OTR.
Matrix with IRC bridging can work as a very nice IRC client. But then you also have access to matrix natively…
IRC is clearly not good enough. It had the users at some point and network effects should have allowed it to remain on top if it had truly been good enough. My hope is that Matrix will take the top spot. XMPP would be okay as well. But thankfully Matrix and XMPP can be made to bridge to one another. Yay openness, federation and bridging!
In my opinion, Matrix is a very heavy and complex protocol, and it’s getting even more heavy and complex: you can hardly say it’s really an open standard. Element is pretty much the only usable client, Synapse is pretty much the only usable homeserver, and matrix.org—where everyone registers—is always slow and has trouble federating. I think its future depends mainly on New Vector and commercial interests.
Yes, matrix the protocol is complex to implement. But it doesn’t seem needlessly complex when looking at the requirements. And the specification is designed so that clients are easy to implement, the server does most of the work. Here’s a good example of a simple client: https://github.com/ara4n/random/blob/master/bashtrix.sh
There are lots of usable clients, but you’re right that element is probably the only full-featured one. The alternative homeservers are coming along well lately.
Also, there is the matrix foundation, which owns the copyright on most stuff. True, new vector / element (has the company renaming completed yet?) is the major driving force, just as mozilla is to firefox. But there are others working on it as well. Without new vector the progress would be slower, but I doubt it would stop.
Decisions like polling JSON over HTTP instead of working directly with TCP sockets, were intended to make it easier to implement. The protocol is simple, but huge: you have tons of endpoints and JSON objects, that creating a full-featured client is extremely difficult. One of the most difficult aspects is also UI/UX, especially for device verification, cross-signing and encryption keys. It’s a lot of simple things, bundled into a single complex thing.
Clients can be made to be (at least partially) lightweight fairly easily. What I was mostly referring to is the server-side implementation. I was considering running my own Matrix instance for me and my friends, only to discover that we’d need a significant amount of RAM and CPU time since we were planning to subscribe to a bunch of high-traffic rooms and run a few bridges to various other services.
I have an account on matrix.org and it does get slow at times when it tries to fetch new messages after a few hours of inactivity. Not sure if the existing, “primary” Synapse implementation can be optimized significantly, but it could sure use some of it if at all possible.
True, synapse can be a bit heavy. But the matrix people seem to be following the rule “make it work, make it right, make it fast”. Synapse has improved a lot in the past couple of months. And they are focusing on improving synapse further. Memory use can be hard to completely fix in a Python-based project. But Dendrite is also improving. Construct is an independent homeserver that can federate and is fast. I haven’t run in though. And there are some other homeserver projects that seem to be quite fast as well.
I haven’t gone through all the specifics regarding the protocol itself, but I do agree the current implementations of the protocol are pretty taxing in terms of system resource usage, among other things. The problem is, how do you implement a protocol that provides so much functionality and keep it lightweight. Such a task would require a lot of engineering effort and thinking many things through before you touch a keyboard.
If Matrix catches on even more, less heavy implementations will likely appear at some point, but it won’t happen overnight.
How do you implement a protocol that provides so much functionality and keep it lightweight? Don’t. Instead of a huge single protocol, you can use multiple lightweight protocols to achieve the same thing, and you can even glue them together into a single platform. Matrix is, in a sense, a bridging layer that connects multiple different protocols; but it’s so big, that it can also be used standalone. You could easily replace Matrix with XMPP, IRC, ZNC and IPFS; and it would work just fine.
I think you can bridge IRC and Matrix as well
Because IRC is not federated the bridging there is necessarily more ugly and weird. You have to have a nick on the target network in order to speak there, and there’s no obvious nick the bridge can just make up for you that will not look weird to IRC people.
There’s two different kinds of bridging you can do; as a matrix user you can bridge your account to freenode, which mostly works but is a bit flaky and rather difficult to set up. As a channel owner you can bridge the entire channel, and this works great; you only have to do it once and everyone benefits from it. We did this in the #fennel channel and I have no regrets; all the core devs can keep the workflow they’re familiar with, and all the newcomers can come thru Matrix and get the persistent history and other nice features that take more work to set up on IRC.
yeah, not on Freenode, but apart from once-in-a-month “I didn’t get that message” or some formatting messups with certain matrix clients it’s pretty flawless. I love IRC but it’s a pain on mobile, matrix is a lot better there.
You can. And there’s also matrix-ircd which is a matrix client and irc server. So you can use your irc client to connect to matrix.
Something I like about IRC is also that it just works. When I use Slack, I sometimes don’t get notifications, also it sometimes messes up, compared to it Discord is better, which makes me wonder whether it wouldn’t be the better solution for companies, but that one sometimes takes inserts of text or links twice (both browsers and app, and on multiple OSs) and the voice chat stuff is actually one of the worst I’ve seen in quite some time. Then there is stuff like Telegram and WeChat which could theoretically be used, but people don’t really want to, because it’s more of a private thing. Matrix is too technical and while there are a couple of projects to make XMPP something more fitting for companies I don’t know of any actually succeeding. Mattermost appears to be good, but somehow doesn’t end up being famous enough and while self-hosting is its biggest pro and actually isn’t that big of a deal due to various reasons very few actually want to do that.
So what I am trying to say is that while IRC has its limitations the stuff that is there actually works really well, which cannot be said about most of the others and I say that as someone using most of these other than IRC on a daily basis. But when I go back to IRC, and have times when I use it more regularly the fact that in it’s boundaries it just works makes it a real pleasure to use. I think that that’s someone it has in common with e-mail for example.
One of the problems of this text is the focus on bandwidth and connecting that to areas with low internet infrastructure. Sadly, this is barking up the wrong tree. Bandwidth is rarely the problem for something as simple as chat.
Especially things like emoji reactions and similar are actually bandwidth-saving, as they are a rich visual language included in unicode, which ships with your phone (which is the classic end device in the markets they aim at). Stickers are usually mapped to unicode and can be switched off.
Image transmission is an important component of general chat, as it allows people to exchange visual information quickly. WhatsApp is hugely popular in emerging markets.
For a lot of the tasks that the text gives, bandwidth is available enough.
The problem in many of those markets is uninterrupted connectivity. This means that it’s hard to keep an ongoing connection over a long time. That’s one of the reasons why quite some systems e.g. use SMS as a message exchange method (a field in which I did research). As an example, when I’m travelling in the sourthern parts of Africa (often Botswana), I usually even have problems using git, because git assumes that you can fully upload a pack and breaks and retries if it can’t. I use file syncing tools that allow partial uploads down there. Instagram is actually an unsung hero there :).
Tools and protocols that deal well with those situations work great there.
IRC in particular is not a good protocol for those situations. If it loses connection, you miss messages. If you are offline connection, you are unreachable for DMs in many clients. You need a bouncer, which is outside of the protocol, to get an interaction level that modern chat users assume.
By far the biggest problem I have with IRC is that I can’t just occasionally drop in. Well, you can, but you don’t have any history. I can’t just post a message, go away, and check if there’s a reply 2 hours later, or the next day. Or I can’t respond to questions people asked when I was away.
The last time I used Slack in any sort of serious manner was when I helped maintain vim-go. I would drop in every day or two, see if there are any questions or whatnot in the #vim channel, and reply when appropriate. We also used it as a private communication with the two other maintainers at the time. This worked fairly well since we were in wildly different TZs at the time (US, Turkey, NZ).
I don’t really care much for Slack – I really dislike using it for reasons of UX – but this alone made it infinitely better than IRC. I just don’t want to set up a server with an IRC bouncer and all that shizzle. It’s just too much effort, never mind costs in financial terms (I need to buy/rent a server!) and the time I need to spend (I got a life, and hobbies outside of computers).
I think there are plenty of other areas where IRC could be improved, but they’re comparative details IMO. This is just a giant usability wall. It’s just handwaved away in this article.
As far as I know, the only easy/simple solution for this is a $5/month IRCCloud account. Setting up a community-run free IRCCloud alternative would probably do far more for IRC than these kind of articles (although I don’t know how feasible that would be, and abuse will probably be an issue so it’s probably not a “just do it”-kind of thing).
Plottwist, because twitch chat is based on irc :-)
Here are some modern affordances that I miss in IRC
.or!or something else.I don’t know how many of the above deficiencies will be solved by IRCv3. Even if they are, as far as I know there’s no active IRCv3 network up and running.
IRCv3 has some pretty clear resources: https://ircv3.net/support/networks https://ircv3.net/software/clients
I’m not too familiar with them, but seems to me like multiline messages are a draft and editing doesn’t seem to be on the table yet.
Matrix does a lot of what you want. And there are some really nice proposals for bots on matrix:
Expectation: a pure text-based chat system, from a more enlightened age
Reality: trolls spamming channels with huge ascii-art dildos and/or swastikas, and ddos
Not in my reality.
I’m also surprised to hear that. Unless you explicitly look for troll channels, my experience has either been quiet (but quick to answer) or constantly active, and on topic.
Never saw anything like that on freenode. Mind me asking - what channels do you visit?
I can’t say I’ve seen the things that the grandparent comment mentioned, but they definitely wouldn’t be on Freenode. If you limit yourself to Freenode, IRC is a very safe and well-moderated experience, especially on some exemplary channels like the Haskell one.
I have accidentally wandered into uncomfortable conversations and much worse things on some of the other popular IRC networks, of which quite a few still exist: https://netsplit.de/networks/top100.php
The same thing is true of sketchy Discord servers as well; it’s not like IRC is unique in this regard.
A year or two back, Supernets was spamming hard on IRC networks. I forgot if Freenode was affected, but I know a lot of the smaller networks I was on were.
Not OP, but I spend my time on IRCnet and EFnet since my IRC use is just to stay in touch with friends. Anyway, last year I was DDoS’d pretty hard because someone wanted my nick on EFnet.
Sometimes I miss #C++ on EFnet, not enough to go back on EFnet, but I do miss it – a lot of wonderful people were there in the late 90s. Freenode feels a lot more sane in terms of management and tools for the system operators. Cloaks and nickname registration go a long way.
I’m in, like, 15 networks, and never saw anything like that either.
It’s not good, it’s just not bad. Especially for simple use cases, it makes simple things easy. Hard things are still pretty damn hard though.
Simplest example I can think of, if I’m remembering it right: Each message includes its length. That is the length of the whole message, not the just the payload; it’s payload+header. So if you want to, say, make sure that a payload is small enough for the server to accept or else split it into multiple messages, your target size varies depending on server and channel.
Close, but no cigar! The actual issue is that you send a message to your IRC server like
but it gets relayed to the other user like
Worse, it might get relayed to another server like
(where
42A00001and43A00002are user UIDs).And all of these have the same 256-byte-or-whatever length restriction.
So basically, it’s Quite Difficult to determine how long you should make your message. If you figure out what your nick!user@host is and do maths based off that you’re probably fine, but you could not be if the server-to-server link stuffs things up.
Aha, thank you for the correction! It has been a long time, but it was basically that issue that made me give up on writing my own IRC client lib once upon a time.
[Comment removed by author]
Alternately, assuming you trust the server, you can make it so the channel can only be joined by people connecting via ssl.
I disagree with this. Thanks for sparking an interesting conversation!
Can you elaborate on why?
See my other comments on this page: comment 1, comment 2. I would be interested to know your thoughts!
[Comment removed by moderator pushcx: Please don't post ads.]