An irc bouncer is a middleman between you and an irc network. It connects to a network like a normal client and instead of connecting directly to an irc network you connect to it. Usually you would set it up to log for you and show you some or all of the messages it received while you were disconnected. In this way your nick is always present in your channels and you can see what was talked about while you were away.
In addition to the above. Both matrix and discord can provide IRC bridges which provide the same "always-on with history" functionality. I have been using the matrix.org bridge to libera.chat for a few weeks. One can join any libera.chat channel this way. Other matrix server might configure a more limited room-to-channel setup where not all channels are bridged.
You shouldn't use IRC for low-traffic communications, or more precisely it shouldn't be used in the scenario where you want people to be able to receive messages while not connected to the channel. Email is the appropriate tool for these cases.
I don't control the message frequency or member timezone/presence of existing channels that I didn't create in the first place. Also switching back and forth between email and IRC depending on frequency sounds cumbersome to me. Some niche channels can have busy weeks while being silent on others. I like how bouncers improve the UX for that situation.
I don't think IRC ever had much of an expectation of privacy. Just because you didn't keep logs yourself does not mean the IRC server didn't. Using a bouncer does nothing for that.
Most IRC networks are relatively small and/or are/were run by techies with no real incentive to log everything. Also, almost everything culturally about IRC relies on trusting the IRC operators to keep things running smoothly and moderate appropriately.
UnrealIRCd (a popular IRC server implementation) have actively refused to add features in to the code-base that allow IRC operators to snoop on private messages or covertly on channels, for example.
Slack, Facebook, Reddit, and whoever else we all use these days, keep every private message ever sent logged for all time and this is just accepted.
> UnrealIRCd (a popular IRC server implementation) have actively refused
That's really moot because operators can certainly and easily snoop the traffic on the wire. Therefore I agree with the statement above that one should take IRC for what it is: lightweight, convenient, but don't assume any privacy - and it can be perfectly fine.
> UnrealIRCd (a popular IRC server implementation) have actively refused to add features in to the code-base that allow IRC operators to snoop on private messages or covertly on channels, for example.
Someone should have told Angrywolf. This module was on every "we used to be on BigNet but we split off because reasons" UnrealIRCd network for a while, haha
I always saw it as a bug tbh, but reading drew's footnote on that right now, I am starting to think you and he are right!
But I think it is more complicated, because it also makes clear that IRC is not an ideal medium for many forms of messaging. It works great for free for all chat, where the discussion happens right now. But it is not great for group chats with friends or when information needs to be disseminated across a community, but I have both of these seen used often.
It just not asynchronous, while at the same time, because of the constant open connection, also not great to use on the go.
It's somehow nice to have a medium for "right here and now", but it sucks to not be able to answer a question or miss important conversation because you didn't look for 10 minutes.
Of course, multi-tier conversation options have helped traditionally, but I think that's also why i never bothered with IRC much, because it was always 3 dozen people idling who always seemed to burst in conversation once you got disconnected.
To add to this: I think IRC strikes an interesting balance between async and sync conversations -- Schrödinger's synchronization, in a sense. In public conversations, there's no expectation that anyone will be present for anything and no expectation that they should read the things they missed, which is good. However, among mutual bouncer users there's a culture of sending messages you expect to be read later, in their own time. We essentially get the best of both worlds.
I wrote a little bit about this facet of IRC culture in this article:
> because it also makes clear that IRC is not an ideal medium for many forms of messaging.
Back in the day where people used to differentiate between IRC and IMs (more importantly, chat vs messaging), I don't really think this is correct. In today's era of Discord/Slack/SMS though, it certainly would seem like a detriment. I do agree with those other people, though. What was nice about IRC (to me) was how imperative it was. You could post a cool thing, question or discussion topic in a channel and have responses coming through within the minute. When you're done, you just close the window and it's like it was never there. I remember feeling like I was using a secret spy communicator when I had IRC downloaded in middle school, the whole ephemeral nature of it was the coolest to me back then.
Exactly. You don't want to know everything that's ever happened in the history of the channel, there's way too much. Even on Discord the client can't handle it so you won't know anyway.
If is a feature in many ways, however there are usecases where it isn't applicable. If I got such a usecases the question is whether I pick a completely different chat system or use some form of bouncer as workaround.
I don't like the framing on feature vs bug. I think it's a characteristic of IRC that made it nice in some ways, and impractical in other ways. The fact that you knew that people were "on" when they were in the channel, and see exactly how many people where "on" at some point in time was really interesting. Right now all your chat apps are persistent chats so you don't really have that feeling of really being in a "chat room" anymore.
If someone is looking for an ephemeral side-project to work on, it'd be interesting to have something like twitter that works in a similar way: you only see tweets posted when you're online on the page.
Like shipping channels in the ocean. You can't see them until a boat cuts through the water leaving a wake. There's no evidence left behind. https://www.youtube.com/watch?v=O2rGTXHvPCQ&t=18s (gibberish warning)
You're only online on IRC while you're connected to it. When you disconnect your client, your username disappears from the list and you cannot receive private messages or see conversations in IRC channels. One user == one open TCP connection.
A bouncer holds that TCP connection for you and you connect to it instead of directly to the server. It will store messages received while you were away, automatically log conversations to disk, and allow you to connect to the same user with multiple devices, among other features.
I never understood why IRC servers don't just store history and let clients query for it. This seems like a small addition to the protocol that would have made it a lot more pleasant to use. You could always turn the feature off in your channel/server if you want ephemerality.
Because it's firmly in the category of easier said than done.
For starters, it would mean logging every message in every channel. IRC servers are (traditionally) relatively stateless and adding a database for logs is a very nontrivial ask.
Server-side logs are a non-starter for many server ops due to exposure to the legal system (dealing with warrants, subpoenas, DMCA, "right to be forgotten", etc). Way easier to say, sorry, we don't have any logs.
It doesn't take a whole lot of active channels to start eating up serious disk space. And of course for every user connection, you incur a complex db query, the results of which need to get sent back to the client, meaning every new connection is expensive in all of disk, cpu, sand network at a minimum. Most IRC servers are run by volunteers who aren't looking to beef up their server specs by an order of magnitude for one convenient feature. This is more doable now than a decade or two ago but it's still a big ask.
You would need to convince all client authors to support server-side logging. Some will, some won't.
Last I knew, most IRC servers didn't support authentication directly. If you wanted to "own" your nick, you had to register with a bot-like service. This means you can't get your logs until after you've authenticated to NameServ or whatever.
Channels are ephemeral. Unless registered with services, a channel does not exist until a user joins it. Once the last user leaves, the channel doesn't exist anymore. Logging would mean channels are no longer ephemeral.
Traditionally, the IRC networks and server authors have responded to these kind of feature requests by saying they should be done by the client, not the server. And I think I have to agree. There's nothing that Slack does (for instance) that can't be done with a sufficiently advanced IRC client.
Keep the server as a relatively dumb message broker and put all the smarts in the client. If the features are useful enough, other clients will implement them too.
> Last I knew, most IRC servers didn't support authentication directly.
That's not quite true anymore. While many IRC servers don't directly talk with the user database, but indirectly to the services daemon (which provides the mentioned NickServ, etc.), most support SASL authentication these days (one of the more widely adopted IRCv3 extensions on the client and server side).
So you can directly authenticate yourself right at the start of the connection without having to talk to any special services.
I remember getting an offer for a bouncer for $1 for life. I presume the company shut down and my bouncer doesn't exist anymore, but at the time I was like "WHAT A FUCKING DEAL".
(Yeah people would usually buy a bouncer, or perhaps several ones)
An IRC bouncer will fit nicely in the "Free tier" EC2 or GCE instances, with gobs of room to spare (even the 1GB bandwidth tier is plenty for a month of IRC bouncer use). I ran one in there for a long while until I moved back to my own server.
That will work for a year, right? Most free tiers expire after a year. I wish IRC would just include the bouncer functionality. It would make things a lot easier, instead of having to get a free tier and then install ZNC on it (or some other bouncer).
1 non-preemptible e2-micro VM instance per month in one of the following US regions...
30 GB-months standard persistent disk
5 GB-month snapshot storage in the following regions...
1 GB network egress from North America to all region destinations (excluding China and Australia) per month
The reason IRC can't have a bouncer capability is that you're then unbounded in terms of storage and memory requirements. IRC, as implemented, is an insanely light server to implement. I ran a college IRC network with a few dozen users on a pair of Mac SE/30s back in the 2002-2004 era - 12MB and 16MB RAM.
If you want something persistent, run your own bouncer, or use Matrix or something.
Message comes in, message goes out. You don't need much of any actual storage, it's mostly in the network buffers, and IRC tends pretty aggressive about killing off clients that aren't taking traffic.
If you go over on bandwidth, you do get billed for it.
I assume the CC requirement is mostly anti-fraud. Easy(ish) to create thousands of Google accounts and abuse the free tier, harder when you can start correlating credit card numbers.
The biggest benefit of a bouncer is that it keeps you from getting banned from channels for join/quit cycling too much when your machine goes to sleep.
Last time I checked, Synapse was the only usable homeserver implementation. Has this changed yet? It's not that big of an issue, but it doesn't seem much of an open protocol if everyone is just running the same implementation.
Yes, depending on your needs Dendrite (Go impl, written by Element team (mostly Neil?)) works well (I've heard) and some people are even running Conduit (Rust impl, independent) as their main.
Reminds me of the short time when everyone used trillian or miranda to have ICQ, MSN and whatever else at once. Guess what, these protocols are all gone know, along with these multi-clients. Why keep stuff alive that's on the way out? Just move on.
I can understand not wanting to use a proprietary platform for communications about a FOSS project, but why does it have to be IRC? The world is moving on. I like being able to paste code into chat and have it syntax highlighted. I like being able to ping people so that they get a notification on their phone, and likewise, I like people to be able to ping me. Occasionally, I like to send a GIF.
I imagine IRC people will just call all of these distractions. They are in a shrinking minority of people.
Regardless of there being a better tool for syntax highlighting and holding small linkable snippets of code (so that logic doesn't need to be more to download when opening your chat) it also keeps it _out_ of the chat so it's not polluted. People not being able to instantly insert 20 lines of text is a _good_ thing. So, link to the resource don't embed it.
> I like being able to ping people so that they get a notification on their phone, and likewise, I like people to be able to ping me
In the article you're responding to Drew directly mentions their suggestions for Push Notifications. I don't mean to sound facetious but, did you read this (article) in it's entirety?
That's not a solution, that's a bad and inconvenient workaround. Having to use an external service just to share a couple lines of code is horrible for usability. Funnily enough, its also exactly the thing that IRC users complain about when the matrix bridge converts multi-line messages to links.
>Funnily enough, its also exactly the thing that IRC users complain about when the matrix bridge converts multi-line messages to links.
I assume you're trying to say this is hypocritical, but it isn't.
The problem with multi-line messages becoming links is that the message is the context of the question. You have to reach for a browser just to read what the other person wanted to say.
Things like images and pastebins are ancillary to the message. You read the text part, decide whether you want to engage with it further, and then if you do you reach for a browser to see the image or pastebin.
Compare:
<h> hey guys im trying to install blub on ubuntu but it keeps complaining that my splines aren't reticulated. full error here: https://paste.rs/id123
with:
<h[m]> hey guys... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/id123)
That last one is an actual example from an OFTC channel that's bridged to Matrix. It truncated at just two words because the original message had a newline after "guys".
Oh yeah, that's indeed not great. For messages with up to ~5 lines, the bridge actually just sends several messages, but as soon as the message has more lines than that, it only shows the first line as a preview. I could've sworn it actually sends the first couple lines, then a "(full message at ...)" message, but apparently not (anymore) - would probably be worth opening an issue for :)
There's nothing to file a bug about. The bridge does not (and can not without some AI or heuristics which are both fallible) know where the relevant part of the message ends and the log spew begins, so a message with a one-line description and fifty lines of logs is treated the same as a message with fifty-one lines.
> People not being able to instantly insert 20 lines of text is a _good_ thing.
Element (Matrix) and Slack will render something like this as 3-5 lines with the expansion option to see all of it. I'm sure discord will eventually do the same too.
This is clearly preferable to using a different application entirely to view the snippet.
It's only IRC where some naive clients expand this out into 20 something messages where this is a problem. And since it's not part of the protocol, you're at the whims of the sender's client for how it's handled, so it's not like you can install a sufficiently smart client to render it how you like in all cases.
I'd also suggest your perspective of how much a problem even that 20 lines of text is is distorted by being in fast moving public chatrooms, like your typical Linux distro channel. In my small team or friends chat, it's perfectly fine
The same also applies to the gif. If this one bothers you, most clients even have the options to disable inline images, so the sender gets to choose. Also it means you just get the image file, and not whatever cruft the popular image host of this 5 year period is doing to monetise.
Image hosts and pastebins also seem more fragile than chat services. I've occasionally gone through old messages that link to pastie or similar and the context is gone.
I think your expectations can easily be alleviated with the right IRC client. Most pastebins and image hosts use some form of markup so that if your IRC client was set to preview those links then it could, or even potentially cache those resources as well.
So what is this magical sufficiently smart client that can embed images from all major image hosts, code snippets from all major pastebins and also configures a bouncer for me and also lets me see messages on my phone without missing some as the phone OS killed it's network socket as it put the app to sleep?
I'm no stranger to the IRC protocol (in fact one of my first submissions to this site 12 years ago in 2010 was an introduction to the protocol written as part of building an Android client that was my side project at the time), but I have no interest in putting in the time to make an IRC client with the experience I'd like in 2022, which is clearly a much lower bar on matrix when Element, nheko, Cinny, FluffyChat and Fractal have all managed it.
To be fair IRCCloud is not free nor open source. I believe there are other clients that offer similar functionality but it would be good to have something easy that does this readily available within open source
> Image hosts and pastebins also seem more fragile than chat services.
Sadly true. While I don't use IRC much, looking at older posts from fora without on-forum file storage and I just see photos roughly like this Imgur example (https://imgur.com/NOnf.jpg). Heck, even older HN posts suffer from the same problem.
For me it's not really about fast moving rooms or not, but that I want to see a bit of context to what was said.
In IRC it's easy to see more than 60 lines back without having to scroll, but all modern alternatives don't have that as a concern at all. Have a few people paste code, liberal use of quoting for messages that are less than 10 lines up (so you are seeing the same message 3 times repeated on the screen), people posting images and you'll be lucky to even have a tiny fraction visible compared to the IRC view.
I can of course see the appeal of all those features, but at least for me it translates into a much worse UX in the end.
The users still on IRC have their heads stuck in the sand and insist every feature irc is missing is actually a good thing and that the users are wrong.
The users then use other services which have these features and the irc users claim some grand conspiracy to kill open protocols.
is it not weird that you're responding to people who obviously know how to use irc and say "this is why i don't use it anymore" by trying to teach them how to do what everyone already knows how to do?
did you feel that you were offering solutions or something?
You might like pinging people so they get a notification on their phone, but they might not like being on the other end of your ping :)
IRC has been around a lot longer than most of the projects which have sprung up in the same space, and IRC views their features with skepticism rather than being the eternal trend-follower. If IRC had followed every trendy chat feature for the past 34 years then it would be a hulking monstrosity by now.
There is wisdom in moderation. A communication method can be effective without facilitating every style of communication -- often moreso. I'll note that you're unable to embed a GIF or highlight code or send an emoji reaction on your Hacker News comments, but we seem to be having this conversation in relative ease despite that.
Different people value different things. Matrix is there if you want a more "modern" option.
If IRC had followed every trendy chat feature it might not be 10x smaller than it was when I last used it too, in fairness
Not even using comical exaggeration either, I'd say the user counts are pretty dead on 10x less now, give or take a few thou. Back then EFNet, Undernet, DALNet had like 100k users each. Barely getting over the 10k hump these days.
> You might like pinging people so they get a notification on their phone, but they might not like being on the other end of your ping :)
Notification settings aren't stuck in 1988 too, if you don't want to be pinged in 2022 that's on you :P
It's not humanly possible to talk to 100k or 10k people anyway, so what does it matter? It's not Twitter. If the hundred or ten people you want to talk to are there, that's enough, eh?
> If you go on IRC now every channel is idle, no chat, just joins quits and parts, boring, dead.
Not my experience at all. The channels I'm in have had a fairly stable number of users for at least the last decade. These are channels with hundreds or even thousands of users. There is lots of discussion in these channels every day. Sometimes so much I can't keep up with it if I'm there participating. I'm in mostly tech related channels, though.
Libera is still quite active, just hop on and onto your favorite programming language channels there (or science or news or ..) and chances are you'll see plenty of chat activity instead of only joins and quits.
> You might like pinging people so they get a notification on their phone, but they might not like being on the other end of your ping :)
This is a false dichotomy between "you have to receive annoying pings" and "there's no notification system in your chat system".
What actually happens in real life is that chat systems, even proprietary ones, give you control over what notifications you receive (and when you receive them). Discord, in particular, gives you significantly more fine-grained control than any FLOSS tool that I've ever seen.
If only I had a fraction of a Bitcoin for every time someone said "Why IRC and not Google talk? The world is moving on."
The world is not moving on, IRC is very much here to stay. It works way too well for this sort of thing and people like being able to have their client set up exactly right. It's just heavy iPhone users that left and once Apple allows web push iPhone users will be back on IRC again.
I think a large issue might be the fact that nobody runs their own bouncers, and the idea of paying a subscription for such a thing is not something people are comfortable with.
I run ZNC+Palaver and get push notifications on my iPhone; but I also run ZNC on my own machine somewhere, which is a cost and a setup most people don't usually have to bother with.
One solution for casuals is probably IRCCloud; since IRCCloud will give you the same experience as mine for free, but will disconnect you if you're inactive (unless you're paying).
Irccloud also precludes all of the nice features you might get if you're running your own clients... so, YMMV.
> The world is not moving on, IRC is very much here to stay
I don't doubt that IRC is here to stay, but I've noticed more and more people moving from IRC to Matrix. Nix, the wgpu-rs guys, I believe the blender devs, and I believe the GHC devs are all on Matrix now.
Nix, Blender and GHC all have IRC channels on Libera, with a few hundred members each. I didn't join them but I assume they're bridged to Matrix via EMS.
What percentage of internet users not using IRC would we have to reach for you to say that the world has moved on? 99%? 99.9%? 99.99%? Since it seems all those thresholds have already been passed…
Because IRC works. It's open, battle tested and has huge support by an endless amount of tools and documentation. There is not much reason to not use if all you wanna do is chat.
> I like being able to paste code into chat and have it syntax highlighted
> I like being able to ping people so that they get a notification on their phone
> Occasionally, I like to send a GIF.
That's the job of your client, not the communication-protocol.
> Because IRC works. It's open, battle tested and has huge support by an endless amount of tools and documentation. There is not much reason to not use if all you wanna do is chat.
TLS is accepted, since you implicitly trust the server when using chatrooms in most cases.
for everything else there are plugins in your client for OMEMO (what signal is based on) and OTR (which is purely session based).
Handling this as a third-party implementation for E2EE is probably the only true way to gain trust anyway. If your provider provides the infrastructure and the client then how can you really trust it?
I believe it is hard to get right, and only worthwhile on 1:1 communication, it doesn't work well at all on large chat rooms, which is what IRC is.
Regardless, if you don't want E2EE to be handled by a plugin- it is possible to make a client with it baked in.
There is no company that will stop you creating a third-party client unlike slack/discord which are extremely hostile to those endeavors by comparison.
EDIT: If you downvote without replying I'm just going to assume you're ideologically opposed to open standards, because I'm not sure what else I can take from it.
Ah, I wasn't accusing you of downvoting, just the community.
You can't downvote direct replies.
---
Speaking about standards; have you looked at IRCv3? Is there anything specific that you feel is not being addressed?
Encryption (to my mind) is better handled outside of the spec itself, just like HTTP vs TLS wrapped HTTP (HTTPS) where the "TLS" has no bearing at all on how HTTP is implemented.
IRCv3 is attempting to address the persistence issues, though many people like the lack of persistence in general.
I don't want to guess at what your concerns are, but more generally; have you looked at the spec?
It's not really a green flag when values offered by major commercial alternatives seems like then-experimental client features of existing thing(cf. Twitter, Slack, Discord)
If IRC were designed today, it would probably be with E2EE. But it's not the end of the world that it wasn't, it just limits what use-cases it's appropriate for. Asking about kernel config options in #linux does not really demand particularly high privacy, and TLS between you and the server is generally sufficient. E2EE is also pretty difficult to get right and dramatically increases the complexity of the system -- Matrix's third-party client ecosystem is hamstrung by this requirement and very poor compared to IRC as a result. E2EE is nice to have and essential for some use-cases, but I don't think that IRC is invalid because it lacks it.
When a platform does not guarantees secrecy you just avoid holding private conversations on it. In my opinion, that's the spirit of IRC, a public place to discuss, because often channels are logged and the logs are accessible for anyone from the web. If not, just about anyone on a channel can do it without your consent. That's also true I think with other "secure" chat platforms because that's the nature of any-to-any chat protocols.
Then you use private messages as a way to talk to someone without disturbing, or away from the noise, of the channel - still not for really private conversations ; for this you don't need encryption, you need end-to-end encryption, but at this point you'd rather use a messaging platform rather than a chat platform.
Encryption makes more sense for small or one on one chats with people you know, the sorts of things people use XMPP for (which has OMEMO: signal style encryption.) In large public chat rooms being able to use a pseudonym is much more important than encryption.
There are OTR / OMEMO implementations out there for private queries. For rooms, I'm not convinced that we need full Olm / Megolm style encryption in most wider chats - encrypting messages across 200 individual parties with a magnitude more individual clients is perhaps just yak-shaving.
I even learned today that irssi has an OTR module by default! On Debian systems you have to install irssi-plugin-otr but once you have that and irssi you can just `/load otr` and `/otr init` in a query and that's it, you have E2EE.
This is handled client side though, so I suppose if your clients cannot agree on a protocol you'll be left with nothing. I'm not sure that's really the responsibility of the server though, since we're talking E2E after all.
IRC works... if all you want to do is send basic text messages back and forth like it's still 1995.
That's not what I want. I want modern features like text formatting, links, images, file sharing (don't mention DCC), threads, linking to messages, persistent history, and even emoji reactions.
And when I say "modern" I mean "modern relative 1995 which is where IRC proponents are still stuck".
Man, I use Mattermost at work and I don't like any of those things. I've managed to hide all the emoji with a CSS rule, inline images are at least collapsed by default, and thankfully no-one is using it for file sharing.
It allows you to disable threads in your UI but that's useless since then you can't reply to people by posting after them since for them it goes to main chat instead of the thread (instead of, y'know, just being the next message).
I think we need to separate IRC the client from IRC the protocol. Everything you just described is possible with a sufficiently advanced client without any changes to the protocol. In fact, some clients already do what you describe.
"A client could do that" is true. It's also unhelpful. They don't all, or even most, do that. Consistency is valuable, and trying to coach people to switch IRC clients (assuming one exists that ticks the right boxes on their platform) is, to me, a pretty poor use of my limited time on this planet.
I don't love Discord or Slack and there are a lot of things I miss about IRC, but the amount of sandpaper around getting people who are less than extremely forgiving of Computer Stuff to use it adroitly is one. Two chat platforms is already one too many for me, and IRC doesn't really make the cut for a third anymore because I too am becoming less forgiving of Computer Stuff as I get older, too.
Part of the problem is though that there people (like myself) that simply don't want any of those features. If everyone agreed that these features are worth having then there would be no problem, since then every client would get them eventually.
People have different needs and expectations, so why shouldn't different clients for different people exist?
TBH? Because the expectation for a communications platform is that you want people to communicate with you, and imposing the need to keep a set of caps in my head for your client is grating and annoying. "I only accept text-based email" would be the closest equivalent I can think of, and I don't think I'd go out of my way to write a text-based email to you because you choose not to parse `<ul>`.
I'm not saying somebody who only accepts text-based email is wrong, mind--do as thou wilt and all. I am saying that the more barriers you present to being communicated with, the less reasonable it is to expect people to communicate with you. IRC makes it too difficult to communicate in modes I've come to expect as normal, so I'm just not gonna do that these days.
What do you mean with keeping caps in your head for my client? Capabilities? Why would you need to keep those in mind?
One doesn't need to keep anything in mind if one just has two different clients for the two user groups. And there are IRC clients, such as thelounge or irccloud (ok.. more than just a client), that offer things like inline images/audio, link preview, etc. (and wouldn't be hard to add missing things there).
On the protocol level they just send urls in the irc messages, which falls back nicely for the other user group. I send images, pastes, etc. all the time on IRC it's just I don't want my client to render any of them inline - I want to decide if I look at something or not, while you want a client that does render everything inline for the most part.
PS: My spam filter judges html emails rather harshly :P
> What do you mean with keeping caps in your head for my client? Capabilities? Why would you need to keep those in mind?
Because the point of a conversation is to communicate. Your client is changing the meaning of what I am sending to you, and I have to know that to effectively communicate with you. I value clarity, and IRC doesn't offer me this without knowing what the other client is doing. I do not trust a normal, representative user to click on every relevant link and internalize it from there, because my experience is that people don't. On the other hand, being able to post a snippet makes it part of the conversation and not a reference, and in my experience means people are more likely to actually read the thing. The assumption that I should just throw URLs at you and you will parse them, either through a computer or mentally, and do the right thing with them increases the lossiness of communication, and adds to my mental stack. My mental stack is tall enough already for me.
In my experience from platform to platform it's a difference of kind, and frankly? It's also not one I really want to be dealing with myself on the sending end more generally. I don't like the bouncer paradigm and I'm not paying irccloud to host one for me when I can do so myself but doing so myself is annoying and work that other platforms do not demand of me. And I'm not going to a pastebin website when I can literally drag a code file in and click "post as snippet". It's slower and it's unpleasant. A sufficiently smart client could solve these things, sure--but Slack and Discord already do them, and the 99% case are there and not on IRC.
I am not, to be totally clear, saying you're wrong to like what you like. I've run IRC servers many times and I used them steadily for about fifteen years. But I have learned, personally and for me, that the things users seem to value on IRC makes those folks harder for me to communicate with as we've normed (for lack of a better term) rich experiences in group conversations. And if you're cool with that, that's totally fine. It's a tradeoff, not a moral thing. It does also means that (not that you're doing it, but some IRC defenders in this thread have definitely logged on) incredulity that Nobody Wants To Use IRC just isn't reasonable. It's not a friendly platform unless your values are its values. Mine aren't anymore, so I don't use it.
I don't think the argument that the mere existence of clients that work differently ruin the modern features somehow is really that fair (see below). The bouncer argument is kinda fair, but if you also don't like to live in a walled gardens (slack or discord), it limits the options a lot (although there are IRC servers that have integrated bouncers! Matrix is kinda like running your own bouncer again, unless you are ok with a third-party running it for you).
I can also accept that there are many more non-modern IRC clients than modern ones that work the way you would expect, so the overall expectation would be biased.
And that probably it was too little too late.
But I think you are overthinking it by a lot. If you were to use IRC, you should just use a modern "magical" IRC clients and not worry about what happens in the background (and btw it's not just "could" but "does".. there are clients that do all that already - where you can just drag and drop stuff in and it will magically do the right thing). And I am willing to bet that in other instances you already do operate that way. Unless your mail client is very broken it will send a plain text version of your email along with the html email. Do you worry there too that I am actually just looking at the plain text version of your email and not with the intended html formatting?
Or do you worry that the person you are talking to on slack might just be connected via matterircd via IRC (or directly via IRC back before slack did the bait 'n switch) and not see any of your snippets, images, etc.? Which btw. I am totally doing despite how much it butchers everything - I just cannot stand that UI (and neither can my rather old laptop).
> I don't think the argument that the mere existence of clients that work differently ruin the modern features somehow is really that fair (see below).
It totally does, though. If I write an emoji thumbsup, and the recipient only sees a tofu box, they won't know if I'm agreeing, disagreeing, or saying something else.
If I'm participating in a heterogeneous environment, I need to refrain from including any mission-critical information in a form that can't be read by all of the participants. And since writing the same information twice is usually too much work, the extended functionality winds up completely unused, or at least only gets used for low-value spam.
> Or do you worry that the person you are talking to on slack might just be connected via matterircd via IRC
Yes, I do worry about that. If I find out that one of my coworkers is using a Slack client that doesn't implement all the functionality in the reference client, and can't just talk them out of it, then I'll have to make sure not to use anything that they can't see.
I might even start doing an IRC bridge myself, in fact, since at that point there's really no actual purpose in running a chat client with a bunch of functionality that I cannot use.
A major part of Slack's value is that this is very rare. Almost everyone just uses the reference implementation.
> "A client could do that" is true. It's also unhelpful.
That's a fundamental disagreement. I know some people like tightly walled gardens where there can only be one client and you're stuck with its limitations. Personally, I despise those systems and will do everything to avoid them.
> Consistency is valuable
Consistency is not valuable in this context, it is a straightjacket. I want a client which works exactly the way I want, which is likely different from what you want. So we need probably different clients, or at least an extremely configurable one.
This is why email is so wonderful and I use it above all else. I can have my client which I love and others can have their clients which they love and I find unusable but we can all be happy.
I completely agree--it absolutely is a fundamental disagreement! It's also why "but why won't people use IRC?" is misguided. I won't use IRC because I don't value what it does anymore. I valued it a lot more when almost everyone I talked to was as much of a computer nerd as I am--that's no longer the case and the computer-nerdy parts of my life are complementary pieces rather than core ones now, so I want different things.
The idea that IRC might be better was why I clicked on this thread in the first place, before I really parsed the srht part of it, 'cause my values absolutely do not overlap with theirs. (Which is fine. Like what you like!)
This is even worse because you have no idea what other clients support. The best part of modern IM is that you know what you see is pretty much what they see. Tiny differences in presentation make a huge difference on the message.
Another way to say that is IRC helps filter out the worst of Eternal Eternal September. (Meaning nothing against you personally! No disrespect intended.)
"Growing". I doubt it. New developers are not jumping on IRC channels and mailing lists, they're going to Discord servers and Reddit, sorry to break it to you. Nobody below the age of thirty is using these old tools unless they're specifically working in spaces where they're used such as kernel dev or they want to be a hipster. I imagine the count of developers on Discord already outnumbers IRC 100:1.
Say what you want about these services being privacy infringing and proprietary (trust me, I don't like them either) but let's not be deluded. Their predecessors will die.
> "Growing". I doubt it. New developers are not jumping on IRC channels and mailing lists,
I am :) . I've found that the discussions I've had on IRC or read on mailing lists are typically higher quality, and more interesting than anywhere else.
The people/projects that care about an open ecosystem but want more than IRC are moving to Matrix, and those that don't are moving to Discord. In particularly basically every gaming community that used to be on IRC seems to be a discord now.
The world has been "moving on" from IRC for approximately thirty years, just like it's been "moving on" from email and phone calls and so on. Somehow, all these tools remain.
An IRC bouncer does what you're wanting in terms of offline notification, they're just hard to configure. The problem with IRC is largely it's structure. Huge networks don't really merge anymore, channel owners stay in their seats for very long periods of time, and the network operators largely run on a very libertarian ideology of non-interference. Discord solves that, and many people moved because of that before Discord had all the novel features it has. The people that stick around on IRC usually have gripes about the networks they're on, but the gripes are tolerable enough.
I can think of many situations where I'd rather have an image that explains something much more clearly than a wall of text on my screen, and other situations where it's perfectly possible to send large blocks of useless non-syntax-highlighted text over IRC.
Don't try to solve social problems by removing useful technical features from tools.
IRC does support sending URLs just fine. The key point here is though, do I want those images to be displayed inline among the text or not. And there are IRC clients (such as thelounge) that will just display those images inline (which is what you would want) and some where you can just drag some image/file and will upload it to some file/image host and then just send the url in the chat.
So options for people that have different usage patterns do exist.
I think Drew and Simon represent a good case for IRC modernisation _without_ it devolving into Slack or Discord. Notification fatigue, endless automated bots, and the expectation to read channel history _sucks_ and IRC keeps the opt-in liveness and culture that fosters jump-in and jump-out chats which is kind of how it works face-to-face in the real world anyway.
There are absolutely others doing good work here too but Simon and Drew are the most visible (to me).
With (good) forums non-existent now I spend almost all of my tech/programming/misc talking on IRC and have since 2011. I'm 27, this isn't technology for "boomers" or "die hard oldies" which is the general tone against "just use Discord or Slack" I see in response to any kind of IRC discussion online.
OT but wanted to share (quoting some of the people here ^^):
'In public conversations, there's no expectation that everyone will be present and no expectation that those "not there" should view the things they missed.' -Not even with the same eye. P-:
Freedom!?
It certainly gets around some of the privacy concerns. (-:
Wanting to have a "session" on IRC 24/7 in order to stop missing messages and conversations, introduced me to UNIX-like systems.
In the late 90s I've purchased a "shell account" from a guy who was working for a local uni. Had some trouble understanding how the hell `screen` makes programs like ircII stay alive when I'm logging out.
in reality, everyone use some kind of irssi or whatever, to replicate slack etc, so everyone is there and “active” but nobody really is. Hugely annoying.
Yes IRC came first. The point is that every sufficiently experienced IRC user is running an ad-hoc, informally-specified, bug-ridden implementation of half of slack, via their bouncers/bots/etc.
I hear you. IRC is a mess for anything other than ephemeral text-based communication. (Which I only say because I'm sticking to running irssi in a terminal window. I imagine there are clients that work better for other use cases, like inlining gifs, etc.)
But bouncers and bots have been around since the 1990s. There's nothing particularly ad hoc, informally specified, or bug-ridden about them. They are open source and they've been around for longer than some of their users. Slack, by contrast, is proprietary software used for corporate communication, which comes with its upsides and downsides. IRC is just a different tool to solve a different problem.
> But bouncers and bots have been around since the 1990s. There's nothing particularly ad hoc, informally specified, or bug-ridden about them.
The protocol for actually controlling the bouncer or bot is always ad-hoc. Whether client X will have support for bouncer Y or bot Z is a crapshoot, and whether such integration will keep working is even more so (of course you can generally fall back to doing it manually, but that's a serious downgrade in usability). As for bug-ridden, well, all I can say is that that's been my experience.
IRC is extremely accessible. Sure, you can't send gifs without modifying your client... but you can modify your client (or write your own)! Confused about how something works? Read the RFC! Quit selling pre-packaged experiences; your opsec sucks regardless of your use of Matrix/Telegram/Signal and it doesn't hurt to shepherd people into an environment where knowing a bit about how the underlying technology functions in necessary for participation.
Even when I'm not a heavy IRC user any more I'm excited that they are pushing IRCv3. It's a smaller spec where a two people team can already make a dent.
I genuinely cannot tell if you're being sarcastic or not, and I'd rather not listen to a long rambling podcast to find out. Could you elaborate or summarize?
One of the points that Aurynn Shaw makes is that federation hampers the addition of protocol features because new features have to be agreed upon by all participants in the federated network. This adds friction to the evolution of protocols, and results in the phenomenon wherein Slack runs halfway around the world while IRC is still putting on its shoes.
She also makes some excellent points about the social characteristics of federated networks. In a federated environment, each node sets their own policy, which meant there was no single point of responsibility for onboarding new users, setting standards of behavior, or filtering out trolling and harassment. Often, as on USENET and IRC, it is the user's own responsibility to filter out content and users they don't want to see -- and there was no authoritative source for new users to determine who/what should be filtered. Some USENET groups were moderated, and on IRC, channel ops can monitor and ban users for in-channel behavior, but if someone is harassing you in PRIVMSG there's often nothing you can do -- and channel bans can be circumvented and enforcement bots subverted fairly easily. And no one takes responsibility to communicate which instance of a federated network to join if they don't want to see particular kinds of content.
So federated networks quickly become cesspools of the worst forms of communication because they're optimized to promote all forms of communication -- "freedom of speech at all costs" as Aurynn says (and, as she points out, is actually a US-chauvinistic perspective on speech and runs contrary to the laws on speech even in most democratic countries -- hate speech being an offense is the norm). This tends to make them grognard-friendly, but hostile to new users and to users of marginalized communities, as well as potentially illegal to participate in in countries not called the USA. And that was accepted in the 90s internet because that's how the 90s internet was. But standards have changed and this is no longer acceptable. "Me too" has gone from the mark of a clueless n00b to a rallying cry against harassment. And people like Aurynn Shaw and Coraline Ada Ehmke have been leading the way in terms of calling out and removing the negativity, exclusion, and sometimes outright hate, from open source development communities with things like Coraline's code of conduct and Aurynn's efforts to highlight contempt culture -- the "PHP sucks" and "Micro$oft sucks" culture that prevailed in technical circles in the 90s and early 00s whose toxicity is something we still deal with today.
Times have changed since federation came out and was promoted as a wonderful thing. Back in the 90s, we thought that building the technology itself was sufficient to change the world for the better. Today we understand better the social costs that mentality has unleashed. We optimize for creating safe, welcoming communities and promoting voices that are usually silenced, rather than allowing everyone to communicate anything at any time. Unfortunately, federated technologies as we understand them today still come from that 90s mentality, and without broader conversations about the social impacts -- as well as establishing some sort of standards for mitigating those impacts -- it's simply better to not federate. Slack and Discord are easier to get started with, offer more features, and promote a safer and more welcoming environment than does IRC.
I agree that federation is bad, but "Just use [two awful proprietary services, one owned partially by the unethical Chinese conglomerate Tencent and the other owned by a terrible American company]" isn't a good alternative.
> but if someone is harassing you in PRIVMSG there's often nothing you can do
The large majority of IRC networks are centrally managed these days, so you can talk to the network operators so they ban the person from the network.
> channel bans can be circumvented and enforcement bots subverted fairly easily
Disallow unregistered users on your channel, and it becomes as hard to circumvent as registering on any other platform; assuming the network uses standard blocklists like DroneBL
>One of the points that Aurynn Shaw makes is that federation hampers the addition of protocol features because new features have to be agreed upon by all participants in the federated network. This adds friction to the evolution of protocols, and results in the phenomenon wherein Slack runs halfway around the world while IRC is still putting on its shoes.
This is effectively the point Moxie was making with Signal ("the ecosystem is moving").
I don't think that this means decentralized services (IRC or Matrix or insert-your-thing-here) shouldn't exist, but it's pretty much proven at this point that centralized services will always gain the lions share.
If the problem with federated networks is that they can't be globally censored to your (and Coraline Ehmke's) standards, I think I will continue to use them.
> One of the points that Aurynn Shaw makes is that federation hampers the addition of protocol features because new features have to be agreed upon by all participants in the federated network. This adds friction to the evolution of protocols, and results in the phenomenon wherein Slack runs halfway around the world while IRC is still putting on its shoes.
This is true in the case of a fragmented specification, however there is a neat middle-ground that has been observed recently in the case of the Matrix specification, in which a single team has been setting the spec that many clients implement much quicker than would occur in the environment of IRC. The spec's movement will eventually become much more solid than its current liquid-ish state, but by that point it, the specification itself, the set of implementations, and the collective network effect will be quite valuable.
> ... each node sets their own policy, which meant there was no single point of responsibility for onboarding new users, setting standards of behavior, or filtering out trolling and harassment. . . .no authoritative source for new users to determine who/what should be filtered. . . . behavior, but if someone is harassing you in PRIVMSG there's often nothing you can do -- and channel bans can be circumvented and enforcement bots subverted fairly easily. . . .
This is not an issue, as long as the user is told the ramifications of federation, that curation of what they can see is done either by themselves or by the particular server they use. Not to mention that it is just as difficult to subvert bans on a network like Matrix, or a registered-user-only chan on IRC, as it is on the likes of Discord.
> So federated networks quickly become cesspools of the worst forms of communication because they're optimized to promote all forms of communication -- "freedom of speech at all costs" as [. . .] This tends to make them grognard-friendly, but hostile to new users and to users of marginalized communities, as well as potentially illegal to participate in in countries not called the USA.
If some speech is illegal to in your country and you also do not think it is moral, you should not speak it. Otherwise, why do we need some central authority to micromanage us and determine what types of speech are to be blacklisted? Even pretending that such a thing could be accomplished in a scalable way, and pretending that the codification of 'illegal numbers' is a good idea, why is it necessary to introduce such a vulnerability into communication software? The admins of a server may curate as they wish and users may choose which communities they wish to engage in by virtue of their choice of server and subscriptions to preferred data.
> Today we understand better the social costs that mentality has unleashed. We optimize for creating safe, welcoming communities and promoting voices that are usually silenced, rather than allowing everyone to communicate anything at any time.
If anything, I wager it is the opposite. The current model in which the position of censor is centrally held is far more prone to abuse than its predecessor, considering the impossibility of that authority to reconcile with the unlimited number of complaints various groups will have with its decisions. Things are far more toxic and unwelcoming today under this model than they have ever been before, with more innocent voices silenced than ever were before, precisely because the typical user no longer controls their subjective flow of information. People should have the capacity to curate for themselves, to control the machine and not be controlled by it and the whims of vendors, to control both what they wish to say and what they wish to hear. If that were still the case today, we would never have gotten ourselves into this mess.
I'd take all the spam, trolling and harassment in the world over letting some would-be censors decide what I can and cannot see, or say to others who want to hear it.
We should all be thankful that so far neither corporate nor authoritarian have managed to completely kill the biggest federated service we have: EMail.
That federation makes authoritarian goals harder is a problem for authoritarians, not a problem with federation.
> the "PHP sucks" and "Micro$oft sucks" culture that prevailed in technical circles in the 90s and early 00s whose toxicity is something we still deal with today.
Both of these have been righly criticized for many reasons and trying to frame that as some kind of bad thing does not invalidate the criticism.
I used to be a big fan of IRC, but I'm not so much anymore. The reason IRC tends to suck is channel operators and network operators that enable them. No amount of technical advancement will solve that problem. Channels on IRC are unique, and much like domains, so there's not much community competition to sack bad channel operators while network operators are very hands off.
What I'd love to see is an open source version of discord take off. Especially if there's a discovery mechanism built in.
That very much depends on the network and the channels how well things work or not.
And other than having no moderators/channel operators at all, I don't see how it can be a problem that can even be solved? People can always get drunk on power and go completely crazy.
What would be your proposal to solve this?
It can be, but not in a place like IRC. The problem is that if a channel operator over a large channel gets to tripping your only option is to move networks if you'd like to chat on the same topic with less abusive operators, which ignores the value that people add to communities.
On Discord, all communities are created equal, and are discoverable. When you go to the discovery mechanism you can search for many similarly purposed communities.
Fair point (especially for super generic things like "#science" or similar) - that could sometimes be handled better. However sometimes there are multiple rooms discussing the same thing on the same network, so it's not always necessary to jump ship completely.
But not sure I buy that the communities are that different. I would rather view them as different networks in IRC terms. You'll have a completely different set of people from one to the next, so how is it any different to joining a different network on IRC?
> You'll have a completely different set of people from one to the next
Yeah, sometimes, other times there's overlap. That is kind of my point, they're encouraging chasing people off to new places because their channel operators could be worse.
I quite frankly hate discord, the model of "servers" is one of communities and although its nice for gaming, not quite so technical discussions. Currently I'm in a bunch of servers, notifications everywhere, did anyone actually talk to me? no. do people talk to each other? barely. From what I can see, discord is made for communities, and communities tend to die. zulip on the other hand? That's exactly how a project based communications platform should be.
That's a fair point, Discord I feel addresses the issue of fiefdoms in IRC, but meaningful engagement is lesser and more sporadic. I'm not sure what's worse, tbh.
Discord is definitely worse. at least for technical communities. There's no need for a project or a technical community to have many channels. you need #project-support and #project-development that's basically it, having an entire server for that is way overkill, and whoever wants more, there's always email or a forum (Hell, you can just run host a fossil server which has a forum/chat now). I understand easy phone access, but discord is not it, if anything, Telegram, offer a IRC+ for the modern era.
Personally, I'd be happy if they let you turn of the "Sohcahtoa82 is typing..." status messages. Those are really engrossing, but I also don't necessarily want my attention drawn away from the chat log if I am just casually catching up on reading the channel.
It seems to me that most UX choices these days are designed to increase engagement.
> What I'd love to see is an open source version of discord take off
Isn't this basically the matrix protocol? It already has millions of users (mostly in the french and german governments, I think) and they're pretty serious about UX and security.
Anyone can run a server, and there's no issue with messaging someone who uses a different server than you use. Messages and private channels are e2e encrypted, so even the server operator can't see them, and it supports modern features like editing/deleting messages, file sharing, messaging from more than one device, seeing messages that were sent when you were offline, and things like that.
To your specific complaint with IRC, matrix also has a pretty innovative feature that I like called "spaces", which are groupings of channels (with a many-to-many relation between spaces and channels). So I can make a "best functional programming channels" space that can have many channels with different moderation teams, etc.
I don't think it is their goal to become another GitHub or Gitlab. Both of those are bloated and focus on centralization. I like that Sourcehut takes a more traditional approach to Git SCM, like mailing lists. I think Sourcehut has a ways to go to really compete directly, but I also believe they are targeting a different audience that have different values.
Am I the only person that doesn't want IRCv3? I don't find the new features important or compelling (telling others when I am typing is creepy!) and I see v3's rise as only leading to some sort of schism.
There are some good ideas and some bad ones. Part of our work is to argue against the bad ones. I don't think that the contentious ones are likely to get much traction, but some of the more obvious ones, like account-registration, are making their way into the ecosystem.
My _opinion_ is that whatever really replaces / evolves existing commonly used communications protocols already has an uphill battle. Further, as Gchat / XMPP based chats showed (opinion observations): federation without a sufficiently rich baseline to ensure a basic user experience leads to fragmentation, silo-ing, and eventual death.
It has to fulfill the need of a common space for public discourse.
The specification must be open and free for all to use. There should be no artificial restrictions on who is able to develop tools including servers, clients, intermediary or subsystems, or provide a service to host any of them. Federation also introduces a higher risk of spam and bad actors; it's part of the price of freedom so the protocol should have an intended use pattern that addresses that type of issue; ideally without forcing the association of a 'real identity' to all use of the system. That won't solve all of the problems, and it adds a bunch of other problems. However a system of the commons may see users such as government organizations or heavily regulated industries where endpoints agree to use such an identity in some way.
You're not alone - IRC is precious as one of the last places where one can still avoid exactly these kind of features! It looks/fits/feels more or less the same today as it was when I started using it in 1996, and I have never felt it needs improvement.
"Weechat in a terminal on my other monitor" feels like home to me. I'm hoping we can opt-out, but in my opinion it will be a dark and dogless day when we cannot.
Yeah before even looking at the article I had the sinking feeling I always get when some corporation wants to "improve" anything that already works perfectly well.
This. There's really too much configuration overhead for new people to get started with IRC: registering a nick. Setting up your scripts. Setting up a bouncer. Etc.
I wish they would concentrate on sane defaults so that more new users could easily be onboarded. Otherwise those people are just going to use Slack or Discord, which is a shame.
I like my Quassel bouncer because it gives me a multi-network synced experience between multiple computers and mobiles. I don't really like the way irssi does multi-server support.
However I do really miss a text client for quassel. There is an irssi plugin for it, but unfortunately it's unmaintained, and it was never that great.
Will using `/away` on irssi in tmux prevent join/quit cycling when the laptop goes to sleep? I got banned from a popular channel recently for that. I had irssi open and I myself fell asleep without quitting.
Clearly a lot of people do like the features, hence some of the popularity of discord. But at its heart it seems like discord has one over general users by having a generally easier interface - from a non technical users point of view.
At some point I stopped using IRC or similar style communication (group iMessage worked), and then suddenly work stuff was all Slack, which is obviously a better service for businesses I guess?
I find a bunch of the discord and slack things more annoying than not, but I can understand their appeal to the wider market.
Both have their merits - though I see a winnowing. My connections in IRC are generally deeper, more durable, and more often result in some creation or production.
I have random friends in IRC with whom I've been chatting casually for 26 years now. Perhaps newer tools will also endure!
I feel like the IRC thing might be a product of how long it's been used - there are plenty of people I know from IRC that I still know today, but there are many many more that I "knew" but no longer do, and even more that appeared and disappeared.
But that's over a time frame that is still longer than discord has really been around, or at least around in my life - so much so that I certainly would take the longevity of knowing people on discord as a measure of long term result.
The other obvious factor is that discord is more popular for many more people, which means you get many more people coming and going. It's much like when starcraft2 P2P became free to play, there were vastly more players (at least initially) but I found it intolerable due to the huge increase in assholes - presumably account creation being free meant there were no longer any consequences for such - and just stopped playing. Maybe it's changed since, but I don't know as I have no desire to play anymore. :-/
I'm already benefiting from IRCv3's server time extension [1], since I use ZNC and get the actual timestamps for each message that I get from its buffer that way. You have capability negotiation [2] at the core of it all, anyway. So even if you end up not liking some of the new features, your client should ideally allow you to just turn them off.
I didn’t find this article super useful, I ended up going over to the specs themselves and I was kind of disappointed.
The default non-TLS with whatever that standard is to say “always use TLS in future” is boneheaded. Not supporting TLS at this point is inexcusable for any client or server. I couldn’t work out whether they’d actually made DMs private yet or whether it was still plain text.
Those are things I’d consider baseline expectations for a specification 10 years ago, let alone today.
Low volume irc channels are useless because of all the join quit spam. As well as username spam where bouncers will auto change the username based on away status.
It felt like basically all of them even 5 years ago. I can only imagine by now it’s a completely barren wasteland apart from a few scattered private survivors at this point.
First thing I configure is to hide part join. I’ve been wanting for a long time to write a plug-in for irssi to hide it for all but those who recently spoke.
To be fair, https://dontasktoask.com/ should be basic etiquette on any chat platform at this point. I understand that some people may not be familiar with this etiquette but I won't be surprised if someone doesn't receive a response to "Hello anyone here?". What does one expect in this case? If there are 13 people online, all of them should reply "Yes, I'm here"?
Ah, yes, smaller channels can certainly seem that way and the join leave logs are basically spam.
For what it's worth, I've been active on three channels in the past few months — #openwrt on OFTC, #vim and #neovim on Libera. I've always got responses fairly quickly on #openwrt and #vim.
An irc bouncer is a middleman between you and an irc network. It connects to a network like a normal client and instead of connecting directly to an irc network you connect to it. Usually you would set it up to log for you and show you some or all of the messages it received while you were disconnected. In this way your nick is always present in your channels and you can see what was talked about while you were away.
source: https://www.reddit.com/r/irc/comments/35vcth/comment/cr86hcs...
reply