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.
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