I'm really bummed about the negativity in the comments. I for one have high hopes for this as the current generation of web powered chats are huge pain for me. Maybe open protocols can take the lead again, at least for a while. It has happened before. Let other people work for our benefit with a bit of encouragement, it costs very little and an eventual failure will do you no harm.
The cost is that it is fragmenting the already fragmented scene of open protocols with an inferior solution. Now I will have to install a 5th chat client in order to talk with the few people that will move to it.
Note that IRCv3 is backward-compatible, so you don't need a new client. Any existing IRC client can connect to it just fine; including multi-protocol clients like Pidgin. And if you do want a client with all the new IRCv3 features, that client can still connect to old IRC servers.
The beauty of an open protocol is that you probably won't need a new client -- all the existing clients will just add it as another network to connect to.
Remember back in the day when everything was an open protocol? We didn't use five chat clients -- we used Trillian to connect to all the different networks.
All of the chat protocols that I use are open actually, yet neither I nor you use a client that supports matrix, irc, xmpp, etc at the same time. Clients that supported multiple protocols died for a reason. These were "jack of all traded but madter of none", extremely buggy and lacking in features.
I do. It's called Beeper. Also, I didn't care that they were "master of none". I just wanted to talk to all my friends on all the networks without having to use a ton of memory running multiple apps, which was more important back then, when the cost of multiple apps was higher.
> Clients that supported multiple protocols died for a reason.
"Master of none" includes crashing every few minutes, dropping messages, lacking critical features, etc.
As for beeper it seems to lack xmpp support (despite some of the services that they support using it internally). Although I will say that it looks cool.
"Yeah, because everyone moved to closed networks."
This is not how I remember it but let's agree to disagree :p
The main question remains though, what does irc3 offers over xmpp and matrix?
I don't remember Trillian having any of those problems. I remember loving it and using it constantly, but having to stop using it when my friends started moving to closed networks so I had to run a bunch of other clients.
irc3 brings irc up to modern standards so that when are using a combo client, the features you have on the other networks work on IRC too.
> I remember loving it and using it constantly, but having to stop using it when my friends started moving to closed networks so I had to run a bunch of other clients.
This seems backwards, didn't you use Trillian _because_ your friends were using closed networks and you didn't want to run a bunch of clients? I don't really remember anyone rushing to Trillian because it was the best XMPP client it was because it could speak to multiple closed networks. It died because trying to keep up with reliably doing so was a pain, particularly when the normal user moved past only needing plain text IM to work reliably.
I'm defining closed networks as ones like Facebook Messenger and iMessage and such. The "closed" networks that Trillian accessed still used open protocols. But my progression was AIM, then ICQ at the same time, then Trillian which could do both plus the few people on Yahoo messenger and GTalk and IRC, and then I had to drop it when too many people moved off of those networks onto the really closed networks.
> I'm defining closed networks as ones like Facebook Messenger and iMessage and such.
It's odd you put Facebook Messenger in the protocol group that killed off Trillian as it has always supported that. When Facebook Messenger launched it was XMPP compatible and nowadays when it has moved to be fully proprietary it has remained supported through reverse engineering (just like most protocols Trillian supports).
That example aside your further examples of "open protocols" Trillian supported are even less open and more hostile to 3rd party clients than Facebook Messenger:
> The "closed" networks that Trillian accessed still used open protocols. But my progression was AIM, then ICQ at the same time, then Trillian which could do both plus the few people on Yahoo messenger and GTalk and IRC
AIM used their proprietary OSCAR protocol, which ironically the "O" stood for "Open" but they never actually distributed a spec/standard and actually went through great effort to prevent other reverse engineered 3rd party clients from being compatible over time. OSCAR had to be reverse engineered no different than (newer) Facebook Messenger or Discord or so on today.
ICQ was where OSCAR was developed (under ownership of AOL). All of the above applies and it intentionally broke unauthorized 3rd party clients many times.
Yahoo Messenger used their proprietary YMSG, had to be reverse engineered, and was often hostilely changed to shake 3rd party clients.
GTalk was better but that's because it was intentionally XMPP compatible. Like I said though "I don't really remember anyone rushing to Trillian because it was the best XMPP client it was because it could speak to multiple closed networks.".
I guess you could throw IRC in as a non XMPP open protocol but, ignoring that these were normally just gatewayed, it doesn't explain either the success or decline of Trillian. All of the supported 3rd party chat clients do.
.
Since the internet became consumer towards the end of the 90s there hasn't been a time the majority of people were on open protocol chat networks or a multiprotocol client got popular without support for popular closed protocols of the day. Many clients and bridges have come but they have all eventually run out of steam trying to catch up to the latest hostile changes or the latest proprietary protocol that is taking off while none have ever supported more than the basic feature set like plain text and maybe images across multiple platforms reliably. Not saying it's impossible or people should be using closed protocols just that's how it's been.
To say closed protocols and clients are a new thing that killed the old multiprotocol apps is false, they started to solve exactly that probably but just ran out of steam. Now Matrix has some of us nerdy folks exited about an easy way to glue such networks together via an open federated protocol (which XMPP folks never really liked doing for some reason) and 3rd party integrations are being maintained again. They are still going to run into hostility and lack of feature parity but as we know from the ~2000-~2010 era it can work okay for plain text if you're fine with the occasional missed message or temporary protocol outages from upstream changes.
Yikes, Pidgin was nothing like this in my experience. Rock solid for months at a time. Maybe you pushed the wrong button? What are the details of the platform you were trying to run it on?
Ideally ALL protocol (by the definition of it) ought to be openly defined. The authentication to use the protocol is another thing. Of course, security by obscurity is how the banks talk to each other.
There's no reason that a web-based chat cannot also have a "thick" client which works as IRC currently does.
We can do both with a single service...
the true problem here is that IRC is long-forgotten by many, completely unknown by most, and those that remain remain because they have a strong attachment to IRC. That strong attachment will make driving a standard forward very difficult, because no two true IRC fans are going to have the same opinions on what a new version should look like.
It's the true fans of open source stuff that hold open source stuff back the most.
I once implemented in a dead chat-app a "typing notification" by sending both the `isTyping` flag, along with the length of the unsent message. On the clients side it was displayed as a blurred lorem-ipsum of the correct length.
It was the nicest form of instant conversation I've ever had. Watching the blurred text become a message was lovely and every conversation felt snapper rather than anxiety-inducing as you start at the "x is typing" message, instead you just watch the sentance grow, then materialise.
Yikes. The amount of times I type a message only to delete it, people I'm talking to will probably be horrified if they saw me give a wall of text to be replaced with "cool".
The amount of times I do the same, only to think that everything I've written sounds so self centred that it's not worth posting, so then I think to myself "there's my therapy on the subject, delete."
Sometimes just the writing is cathartic enough that once you've gotten it off your chest, you don't really need to hit submit.
While I applaud the technical implementation, as someone who needs to e to compose their thoughts and often drafts in the input box of chat apps, with the final messages usually winding up shorter.... That's a fucking terrifying feature.
Same here. This sounds far worse than just the normal typing notification. If I was using an application that did this preview, I would type up messages in a text editor and paste them in. There's so many times where I have a massive block of text that I'm not satisfied with as communicating my thoughts properly and I don't want to expand it out to an essay (no one will read that in a chat application), so I just delete it and replace it with an acknowledgement of the message I'm responding to. That would look ridiculous to other people in the chat!
For what it's worth, it sounds like a pretty useful signal to others in the chat to know you have a lot to say on the matter, but have actively chosen to say little. The ledger would show a simple message, but ephemerally you and your colleagues would have gotten to know each other slightly more than the otherwise dead-air.
I also had a limit over 52 chars with elipses to stop walls of text.
I endlessly revise outgoing messages, often rearranging parts of my sentences to ensure what I'm saying is clear (enough). After mistakenly hitting Send enough times, especially when there's an apostrophe in the text, if the message is at all important or complex enough, I drop into a text editor first, then paste and send. This also skips the "X is typing" problems you describe.
So I'm the complete same, but have you ever thought about how that might impact the way you communicate? I've found I've got worse at talking (verbally) compared to typing, because of how many cruxes I'd started relying on over the pandemic (along with other reasons of course).
I'm normally opposed to typing notifications, but I really like this idea for certain channels. How did you handle the case where many people are typing at once? >5 might get noisy if they all had their own lines.
I think I had it so the first three typing would be shown sorted by whoever typed first, but then ellipsis the rest. The app was designed to be a more conversation-based app with things like a room being opened with an objective and closed then they were complete, so it favoured slower conversations.
Though I suppose you could visualize it in the nickname somehow. But I hate the current retrieve trend of "and 3 others". It didn't really tell you anything if one of the other participants is someone you want to know about. Because you still don't know if any of them is typing or not.
If it's important, show it for everyone. Otherwise don't bother showing it at all. But showing it for some randomly picked users makes no sense.
It tells you there's an increased interest in participating to the current topic, that multiple messages from different people will appear concurrently and split the topic. It's an indication you should probably stop typing, as your message will get lost in the noise.
You are correct. I've seen this kind of notification used together with small avatar pictures of users who are typing - I think it was in Element.
Then again, in practice I found that if more than two or three people are typing at a given moment, it's probably a conversation that's lively enough already, and I'd usually just wait to see what the participants end up writing regardless of who it is. So the value of such a notification is about the same as if the all the typing users were named in it explicitly. :)
Yes, it's certainly different from what you see on today's most popular platforms, and if done visually right (a big "if"), I think it could be very nice.
There was a mode in ICQ long ago where the person you were messaging could see everything you typed, as you typed it. A friend of mine always wanted to use it and it was mildly terrifying.
There is no reference to it on the internet, and I'm fairly sure no bit survives. Which is sad when I think I worked 6 months on it, but someone paid me to do it, so that's nice.
An old ICQ chat window had two text areas: one for each user. The text was updated as you type. IIRC you could change font, color and other text properties.
Official motivation/anti-motivation: 'Conversations can have an increased sense of immediacy when participants are aware that others are in the process of replying.' https://ircv3.net/specs/client-tags/typing#motivation ... I need less 'sense of immediacy' in my life.
I really like Discord's implementation of threads as ad-hoc lightweight temporary channels. Putting them in the sidebar is a great idea, at least for how we use them.
Same. I'm concerned that a leading IRC client that for its own growth reasons doesn't allow opting out of sending the beacon. Then you're left with an otherwise inferior client in order to participate. Or worse, a server that kicks you out if your client doesn't send the beacon.
I'm the parent and yes like the other reply here I do the same. I keep a bouncer (Quassel in my case) connected 24/7 on a VPS.
Quassel is really nice, it's got infinite scrollback, multi-network, GUI configuration that is stored on the server, logs go into a database, and the desktop and mobile clients (QuasselDroid!) are really good. It brings IRC into this century without giving up what makes it so good. Unlike Matrix which is aiming more at the Whatsapp/Telegram/Discord community.
I use both mind you, but I don't integrate IRC into Matrix for this reason. I use Matrix just for the individual and small group chats and Quassel for IRC. Matrix gets too messy when you're on tens of different group chats.
Yes, you just stay connected for a long time (idling). I run a bouncer (forward proxy for IRC, basically) on a server so I effectively stay connected 24/7 to all the channels I'm in, so asking a question, waiting a few minutes to see if someone answers immediately, and then leaving and coming back an hour or two later is totally normal (you could of course just keep your client connected, but my internet's not quite that reliable).
I don't really think it matters what the spec says anyway. Who's going to enforce that? Like if it was required, would the server automatically reject messages if it didn't get a typing notification for an amount of time that's proportional to the length of the message?
Man i miss my IRC Days ! Still have real life friends from that. Also got my fist MP3 'file-send' to me..Lol anyone remembers the wareZz-IRC-Bots/channels. Lol apart from competing in content they also competed in terms of colors/ascii graphics.
Still thinks its miles better than slack/skype for inter-office communication(Notice i said communication not app/task-tracking/1001-Things our over-engineered 'chat-programs' provide today).
XChat - Good times :)
PS. Would love to see some benchmarking for a modern-irc-daemon written in say Go or something else with good concurrency primatives. Was quite a issue 'back in the day' the max clients per server.
Bah, PeeZee! Nothing could ever beat AmIRC2[1] on Amiga!
Especially when you were running "Kuang 11"[2], which developed from a client script into a shared library, written in some compiler language and offering, itself, a script API, in addition to the client's :-)
I don't know how many times some idiots tried to take over a channel and Kuang 11 (or a sister project, it was, I think, which used the K11 API) reacted so fast, that our clients stood rock solid and could not be flooded, etc.
Haha ja linux had this nice ping-flood capability ! Lol come to think of it. It was prob the "first" DDoS attack of the day :D Except you mostly knew your "co-conspirators"
I'm still not entirely sure on the point of IRCv3, it seems to me that the main draw of IRC in current times is the simplicity of the protocol, losing that by adding a whole bunch of new features, I don't see what niche IRC fills anymore.
If you read the XMPP discussion from the other day, one of the points highlighted was that there's no common spec for modern features so it's really hard to know if a given client<->server combo supports newer features. IRCv3 is the same idea. Some of it is stuff that's been around for ages so clients just assume it's there like SASL and capability negotiation - these are much more specifying what servers/clients already do, IRCv3 is not adding to complexity here because the complexity already exists.
The second is more green field projects, like the stuff to allow a more web client friendly protocol compared to IRC currently by defining how to use web sockets avoiding the need for stuff like IRCCloud or Mibbit proxying their user's connections. Or chathistory to make it more mobile/not permanently attached friendly.
Slack, Teams, and Discord are proof that there are serious demands to have a chat system. It's just IRC as it is, is clearly outdated for the current market.
It's niche is as simple as it was way back when, you can create your own chat server for your community. Instead of having to use Discord, Slack, etc you can create your own and control it fully. While it's possible to do that to this day it's not to the same level it was back in the late 90s for example.
Damn, this makes me drool over an alternate universe where discord, slack, and teams are just competing irc clients. Unfortunately I can't imagine anything like that ever happening
Won't happen until grabbing everyone's data isn't a top priority for tech companies. They don't want you to be able to do stuff that they can't observe.
IOW we're stuck with a decaying protocol ecosystem—for messaging, and everything else—until we outlaw surveillance capitalism, which we probably won't do. Email wouldn't be able to take off if it were invented today, because it lets you use it without one company seeing everything. The state of things is really bad. It's a drag on productivity, with endless wheel-reinventing and deliberately-bad interoperability.
Minimalist and full-featured implementations can coexist and talk to each other, as all specs are designed with graceful degradation in mind.
Minimalist implementations can also cherry-pick newer features they want. For example, this IRC client explicitly says it in its "non-features" section: https://git.causal.agency/catgirl/about/
Almost everything in IRCv3 is opt-in. If you want to use netcat to access a modern IRC server you can still do it and it looks just the same as it looked in the 90s.
I hate to say this, but even as an old IRC diehard, I have to admit I gave up a year ago or so.
The new IRC is Matrix, or at least for now. For me at least, it fullfills the same needs:
- deploy your choice of server-software on your preferred server.
- use your preferred client to connect to your preferred server.
- allow communities to manage themselves in a decentralized manner, without any San Fransisco-based big-tech company imposing their CoC, ToS or view of "diversity" upon them.
And it does so in a way which is mobile-friendly and supports all the "modern" additions to IM which normal people have come to expect. I can't see how IRCv3, if it ever lands, can compete with this. It's years (decades?) behind at this point.
And if it lands a spec which is equally capable as Matrix, how can it ever be compatible with "the old IRC"? Myself, I'm still running my IRC network and servers, but they are bridged to Matrix and I encourage the community to move there too. And thus ends my interest in IRCv3.
All in all, this seems like a lot of spec-work going into a what is surely going to be a doomed venture.
> - use your preferred client to connect to your preferred server.
I want to like Matrix, but this is currently the most painful point, for me. There are very few mature clients, so they don't serve as many niches or specific tastes as IRC clients.
> I can't see how IRCv3, if it ever lands, can compete with this. It's years (decades?) behind at this point.
Not sure what you mean by "landing". Many specs are already implemented, deployed, and used in the wild.
> And if it lands a spec which is equally capable as Matrix, how can it ever be compatible with "the old IRC"?
Every IRCv3 spec is designed with backward compatibility in mind, so old clients are not left behind, they just don't benefit from the new features. The main mechanism for this is a capability negotiation when clients connect.
I tried Matrix a few months ago, but the clients were pretty horrible compared to irssi. The only functional one was the ugly GUI one with emojis and all that.
I've tried a lot of very functional clients. I suppose you think of Element? There's also Cinny, Hydrogen (both web), Fluffychat, Nheko, gomuks. Maybe quaternion is more to your taste? Not sure if it supports E2EE.
Weechat-matrix-rs[1] is the fix for that, but it's not currently usable (I tried it yesterday, hard crashes trying to log in to a local homeserver). Maybe in a few more years.........
>- allow communities to manage themselves in a decentralized manner, without any San Fransisco-based big-tech company imposing their CoC, ToS or view of "diversity" upon them.
the main matrix homeserver blocks you from federating with them if you violate their CoC and kicks all matrix users from your room
> the main matrix homeserver blocks you from federating with them if you violate their CoC and kicks all matrix users from your room
In my opinion that doesn't really matter. matrix.org is "just another homeserver" - it just happens to be one with a large amount of Spaces and rooms, and thankfully federation doesn't orbit around matrix.org nor does it depend on that.
There are plenty of other homeservers which federate with each other quite happily. I've seen some rooms which have a policy of not allowing users with a matrix.org account, because they disagree with the matrix.org CoC/policies/actions, and that's also fine, because the nature of the matrix protocol allows that freedom. If a person wishes to stick with matrix.org, well, they have that choice. If a person has a homeserver which gets booted from federating with matrix.org, that's also fine - the problem will eventually be routed around by federating with plenty of other homeservers. This happens already.
What is the user experience like when that happens?
If you use the main Matrix homeserver and you're in a room hosted on another server when this happens, does your client show a helpful message like: "Sorry, you're not allowed to be in this room any more, because the people hosting the room committed the following thoughtcrime: $REASON"?
I worry that it will instead just look like some generic network error message, with the remote server being tacitly deemed an un-place full of unpersons. Down the memoryhole it goes.
It gives you a generic error message and doesn't describe the block. And it happens quite frequently, whoever administrates the Matrix main homeserver is very ban happy.
And so users can move to another homeserver with different standards, or run their own. This isn't possible if Discord or Skype or Telegram block your users.
All those points apply to XMPP too, and it's way easier to set up Prosody on a server. Are there any specific reasons why you think Matrix is the next IRC and not XMPP?
Federating is one goal but is useless without mainstream adoption.
Success is adoption. Enough users to break the network effect.
Signal is currently a good example of roughly the amount of users you need to start breaking the effect. So that's what success looks like. A very low bar version of it.
I wonder if there is any impedance-mismatch between communicating on mobile and on desktop. On mobile it's kind of difficult to see more than the last few messages in a channel and quoting becomes somewhat more important to be able to follow the conversation.
But on desktop it's completely irrelevant and only distracts by showing the same message multiple times (since I can usually still see the first message).
Quoting to me is for fast running rooms to avoid confusion about which conversation a message is in response to. Or for context when replying to something hours old in a smaller room. It's not really a mobile/desktop distinction.
> - allow communities to manage themselves in a decentralized manner, without any San Fransisco-based big-tech company imposing their CoC, ToS or view of "diversity" upon them.
Darn hippies with their inclusivity and community standards!
People like you is why I long left this forum and IRC servers in general. You give the tech industry a bad name.
can we not be looking for fights please? We are assuming a lot from a fragment of prose and I think would be better if we afforded one another the kindest interpretation of their prose that we can.
not everyone has a positive relationship with the HR department of their work place. Ergo one can be cynical of any practices or policies they put forward thus leading towards a mistrust of the term.
You might be assuming everyone else has the same relationship with the words that you do and this could be a mistake.
How people dare to have different worldviews. People in other countries love so much when a Californian lands from heaven to tell them how they should behave, communicate and be offended.
And yet almost nobody who uses irc uses it, unlike omemo (xmpp) and olm (matrix). Its encryption also predates matrix by a decade, its dh prime is only 1.5k bits big.
Is anyone using IRC for private conversations? I only see it being used for public chat rooms where every message is even getting recorded to a public archive; it's one of the rare cases of a messaging system where people have nearly zero concern for privacy. (I'm all for having the option of course, just pointing out a cultural reason why e2ee wouldn't have much uptake since nobody cares)
True, people on IRC usually don't mind conversations being public. Check out OTRv4 though, they are working on modernizing the encryption: https://bugs.otr.im/otrv4/otrv4
e2ee is a challenge for any system that did not have it built-in in the first place, and even more so when the system is open (in the sense of anyone being able to implement their own client/server, and server federation). At the end of the day we will probably not be able to do much better than using TLS to secure IRC, and will just have to trust the server. OTR is OK for those who choose to use it, but it is not universal and requires too much coordination with whoever you are trying to chat with (you have to answer challenges like, "I like my IRC client, I do not care that it doesn't support OTR, we are just chatting about TV shows so who cares?").
Dunno about that. XMPP and Matrix seem to have solved this issue. Plus implementing TLS is much more difficult than implementing e2ee so I do not get the argument.
TLS is widely supported with dozens of available implementations ready-to-use in many different programming languages and on many different platforms, and it basically comes free for any browser-based implementation. Those implementations also receive a lot of attention, and because of that library support it is much easier to update an application that uses TLS than some purpose-built chat protocol. For example, let's say a new EC attack is discovered and we have to move everyone to a different set of curves (e.g. maybe P256 is found to be insecure and we all have to switch to P521). An OpenSSL update will be pushed out a lot sooner, and will be used by far more client applications, than the updates to all of the hundreds of chat clients that need whatever chat-specific e2ee protocol updated.
At the end of the day, even with all problems that exist in TLS implementations, I have a lot more faith in TLS than I do in some college student's hacked together web chat client's e2ee implementation. As for XMPP, just how widely available is OMEMO in XMPP client software? The last time I tried to deal with XMPP and e2ee I was constantly confronted with clients that did not support this or that protocol. I can't speak for Matrix, maybe it "solved" the problem, but as I said if e2ee was not part of the standard from the beginning it is going to be hard to push it out as an afterthought.
Solution: use a library for the e2ee, multiple clients and even the group that makes the standard could contribute. This is what matrix did. On the other hand Dino (xmpp) uses vala bindings for the official "libsignal-protocol-c".
Your favorite curve is suddenly vulnerable? Use a library like libsodium which has a solid track record and will be updated to replace the default algorithm if there is a need.
I will take signal's "hacked together" e2ee implementation over openssl.
As for clients without omemo support, I did not have any issue so far.
As an EFnet admin: EFnet ;-) IRCnet is still around too with some very active chat channels (e.g. #worldchat). The networks are much smaller nowadays though.
Want to talk about a FLOSS project? Libera.Chat, OFTC, GIMPNet.
Want to just chat? Snoonet, Slashnet, Quakenet.
Want to just chat but want it to be technology focused? Darkscience, 2600net.
This is a shortlist of public networks I can recommend to a new/returning user; there are many smaller networks out there that you might discover organically with time.
So,a basic standard web chat spec. I am good with that.
Didn't see anything about WebRTC, so no multimedia? I'm fine with that, too. Basic is good.
Now, I am not up to date with modern chat apps, but I'd imagine most of what is out there has everything in this draft and then some. So, why would anyone commit to the protocol besides nostalgia. Not saying it's bad, just wondering
> In a corporate environment lack of e2ee is a deal breaker
Not in my experience. I would want a new hire to be able to search past history for context and to many businesses like to monitor the chats.
Keep in mind, IRC would generally be hosted by the business themselves so they’d have full access to the data. Why would that business want to hide their employees messages from themselves?
It is rare these days that company actually has their own physical server room and "cloud" by default is not secure - you have to rely on cloud company security and integrity.
I am thinking of that kind of scenario, however if you control who can access the servers then it may not be necessary.
Even still, e2ee isn’t desirable in the industry. See Slack and Teams, the most popular IRC replacements used in the corporate world. Neither are e2ee.
I doubt he's interested in this kind of stuff at all.
Myself I wanted to stay, but he kinda "closed" freenode - you need to register using a web form and access using SASL. Since he dropped the old nick database, you can't use your old nick anymore. I doubt there are many people online there at this point.
I was sad at the commotion in the community but at least he did it with so much passion that everyone left for Libera and the community wasn't split at all :) A few projects remained at first but when he wiped the database and they lost their op rights to random people (whoever happened to join back first) the last ones moved over.
So now Libera is what Freenode used to be, nothing more nothing less, only with more well-defined management that learned their lessons about vetting contracts. They're doing a great job at continuing the Freenode spirit and everything is settled back to normal.
Pretty much the best outcome possible from all this IMO.
Ps the sign up form is so un-irc. The great thing about IRC is that you don't need any identity.
> everyone left for Libera and the community wasn't split at all
Sadly Libera.Chat is only at about half the size [0] that Freenode was. Sure, a lot of those lost will not have been active participants anymore (just keeping their bouncer/client running) but all of them?
Yeah I have a strong feeling a lot of those are just bouncers that are running on some old VPS, totally forgotten.
I also think this would have triggered people to think "do I actually still want to be on IRC"? Rather than just idling for years.
However I didn't know it was still only half the size. That is much worse than I expected.
I know some of them have moved to other networks, for example the alpine linux team went to OFTC. So part of it is explained by that. Still a split of the community but OFTC is a very similar type of community.
True, I forgot about that. Like alpine. Probably because I was always both on Freenode and OFTC so I didn't consider them 'lost'. But this is a personal thing, good point.
For me it's the inverse, I am having a real hard time with threads on slack. But no issue following discussions on busy IRC channels. It's probably just a matter of getting used to it one way or the other.
Slack's implementation of threads is really weird, it almost feels like they're trying to hide them. If I get replied to in a thread I almost certainly lose it.
On the other hand, Discord's UI treats threads as temporary channels, and that works way better because you can actually see the thread as unread or not in the channel and server lists. I really wish Slack would steal this.
I haven't used Discord too much, but my main gripe (apart from calling communities "servers") was that most communities had way too many channels already, but haven't seen them in action, so maybe that strategy works better in practice.
YMMV, I've been checking out discord and I don't really like threads much. It feels like the discussion is stashed away semi-hidden in a corner which sort of discourages casual / intermittent participation and you easily miss the whole thread. It's like I have to go out of my way and butt into someone's discussion whereas the chatter on an IRC channel feels open to every participant.
