I'm probably wrong, but from what I can tell rasengan was the only person behind this. He nuked channels and then disappeared, leaving his utterly confused staff to listen to the music from all the upset users/chanops.
My impression is that rasengan (Andrew Lee) does really seem to care about IRC, and he does see himself as the 'good guy', but his thoughts on how to make it all work clash with the somewhat more anarchic volunteer-based way Freenode worked, as the most charitable interpretation.
Slightly less charitably, it comes across as a rich dude wanting, expecting, and/or being used to being boss, and being (legitimately) confused as to why this is causing so much trouble from his volunteer underlings. It's hard to be a prince in this world...
Even under the charitable interpretation, he "cares about IRC" in a way very different from how any of the projects that use Freenode care about IRC.
Ask Gentoo or Ubuntu or Wikipedia what they want out of an IRC network, and they'll probably say, hm, more stability and less spam, I guess.
Ask Andrew Lee what he wants abut IRC and this is what he says (from https://irc.com/):
> Refreshed mobile apps, intuitive web apps, friends lists, working team support, video calls and file sharing. All within a few taps of the mobile device as people have come to expect.
I personally wouldn't mind IRC (also) having some of those features, and a client with a more Discord-like UX for those that want it.
But I doubt you'll achieve that by single-handedly destroying one of the biggest IRC networks out there and basically guaranteeing folks won't want to work with you.
To offer a different point of view: If I were to create my own chat protocol, I would actively try to make it next to impossible to implement it on mobile and consider this a feature. Nothing is gained by mobile users. From the features/interfaces they expect, the kind of communication people are accustomed to on mobile, and to them just being idlers 24/7 anyways.
Let people who want smileys, gifs, fancy UI, backlogs upon reconnect, reply features, friend lists, voice features use discord and whatever, and please let IRC be a stream of text messages and old school and a haven from this modern shiny crappy world.
I am not denying they can be useful, I am questioning how this should be achieved. You are connected, you receive the messages, you aren't, you don't. You don't want to miss anything, how about making sure you stay connected?
Is this really something that has to be built into the chat protocol, massively increasing its complexity and just giving headaches, security issues, debug problems, wasting developers' time?
I don't consider IRC a replacement for online boards / stackexchange. Even stopped logging completely, don't use a bouncer. If I am online, I'm there. Actually think it's an improvement.
That's being worked on and there are already irc daemons that support it (but it's all a bit bolted on until the standard for that is ratified).
However it is also a feature that has to be enabled by the server operator and here you may run into different opinions if this should be a thing or not.
> To offer a different point of view: If I were to create my own chat protocol, I would actively try to make it next to impossible to implement it on mobile and consider this a feature. Nothing is gained by mobile users.
I can understand where you're coming from, but it's also important to note that a huge part of this planets population doesn't have access to a computer. Many folks, if they have internet access at all, only have access to it through (cheap) mobile devices. A protocol that's explicitly designed to be impractical/hard/impossible to support on mobile would exclude large swaths of people from ever being able to participate.
So what? How come it should be my concern to include everyone, as if everyone was entitled to use my service?
A russian only IRC channel excludes everyone not speaking the language. A Playstation exclusive game title excludes Xbox owners. An OS only targeting x86_64 excludes people with only ARM and i386 machines. An Android only app excludes iOS users. An OS without certain drivers excludes tons of users and use cases.
If I purposefully want to target Desktop users, so what?
>> If I were to create my own chat protocol, I would actively try to make it next to impossible to implement it on mobile and consider this a feature.
> So what? How come it should be my concern to include everyone, as if everyone was entitled to use my service?
You weren't talking about a service, you were talking about designing a protocol in such a way that it wasn't usable for mobile users. That's a very different thing.
I'm saying we shouldn't be designing protocols in such a way as to ensure folks can't implement it in certain settings. If you want to set up an IRC network with a ToS that says "no mobile users" go right ahead.
Absolutely. Totally up for an IRC-like system with some or all of the feature gap closed compared to systems like Slack or Discord, but this Freenode stuff has nothing to do with that.
And anyway, isn't Matrix trying to be that next-gen IRC?
> Refreshed mobile apps, intuitive web apps, friends lists, working team support, video calls and file sharing. All within a few taps of the mobile device as people have come to expect.
> Refreshed mobile apps, intuitive web apps, friends lists, working team support, video calls and file sharing. All within a few taps of the mobile device as people have come to expect.
i.e. he wants to evolve/transmogrify IRC into a system that is more amenable to centralization, data collection and monetization.
I imagine either Freenode will still end up doing fine, or he'll just conclude that us nerds don't understand the concept of ownership and threw him under the bus after all his donations and hard work, and then he'll move on to the next plaything. He'll probably get his superyacht eventually.
On some Freenode channels I've seen the channel owners effectively ban/block all conversations before leaving. This would mean that even if people chose to stay on Freenode, they wouldn't be able to talk on channels dedicated to some projects at all. A lot of those channels got taken over and bans removed.
On most of those channels, the previous state was that it is an official, supported channel of a given organization (especially if it's a non-grandfathered single-# channel).
The mass bans and such are the only way to mass-notify in reliable way that an official channel moved elsewhere. In all cases I've seen so far, the channel hijacked by new ircops was not a random community channel, and in fact freenode had policy even before that about prioritizing official org ownership.
I find this explanation a bit dishonest - mass ban of people talking about topic to push them to another server is not "the most reliable way" of communicating anything.
The whole point of IRC is that people can create channels and talk about things without those channels being owned by someone. If team members want to go somewhere else that's completely fine - but preventing people from staying and talking about a project goes against core of IRC and IMO Freenode ircops are well within rights to prevent channel squatting and forceful bans.
Sure, but Freenode has a "namespace" system. A channel with a single # is supposed to signify that it's officially affiliated with whatever project it's about, while a channel with a double ## is something community-driven.
It's thus perfectly reasonable to me that, if the project decides to move networks and stop using the official channel, it should shut it down and redirect it. (If for no other reason than because the project won't be moderating that channel any more, and it reflects poorly on the project if something that's flagged as being "official" turns into a cesspool.) It's not stopping people from creating a ## community channel on the old network to keep talking.
That's irrelevant, of course, because Freenode hijacked a lot of channels that weren't doing the full shutdown, and just had a soft "we're moving to X soon" topic set, thus punishing the gentler communications you'd prefer.
reply