> IRC is awesome. The biggest downside is that when you join a channel, you don't get to read all the previous history. In that important feature Twitter/Slack is superior.

I use bip[1], which is an IRC bouncer. I basically connect to networks from a remote machine, and when I hop into IRC, I connect to that machine - which gives me some playback of what's been said beforehand, so I know at least some of the context.

This doesn't solve the 'problem' for joining new channels, but it's nice if you have regular channels you hang out in.

1: https://bip.milkypond.org/ (their cert is broken :/)

ZNC is also a good bouncer (I use it).

I used znc for a bit, and switched to bip for ... some reason that I can't recall, now. I think the configuration for bip was easier than znc?

I don't find it hard. The webadmin module lets you configure everything via a web interface if you're inclined to.

About history: of course you can run your own IRC bouncer if you're willing to host it, but irccloud https://www.irccloud.com/ is such a no-brain solution that more and more IRC users have it.

Yep, I was making my own web based irc bouncer/client until I saw irccloud and my project was instantly dumped and I'm now gladly paying them!

i'm a user... aware of irccloud since the extended beta, but recently a user due to various nesc. evils of corporate networking. except honestly the ui sucks for history and non existent search sucks compared to botbot.me ie. https://botbot.me/freenode/google-containers/

erlang vs python .. connected clients vs historical search.. apples and oranges i guess...

> The biggest downside is that when you join a channel, you don't get to read all the previous history.

In my use of it - primarily social, less technical - this is actually a huge benefit. Whereas things I say on Facebook, on Twitter, even on Skype groups float around forever, this doesn't happen on IRC.

Only the other people in the channel log things, and if someone else turns up, they don't see what I've been talking about - the exact contents of my discussions aren't floating about forever so long as people don't intentionally distribute them.

IRC's one of the only things that makes me feel like the early web did. A bunch of mostly-anonymous people collaborating or just hanging out, and it doesn't seem like everyone's trying to make a buck or polish their "personal brand". Little or no official corporate presence. No one's worried anything they write will ruin their lives, justly or unjustly. It's the "no one knows you're a dog" web of yesteryear.

I miss when more of the web was like that. It's nice.

Well put. It is quite different now.

This is also one of the (original) benefits of 4chan. It's not merely anonymous, but it is also ephemeral.

However, these days there are IRC loggers and 4chan archivers.

There's only IRC loggers that you can see, though - if you know (practically) everyone in a channel at a given point in time, you're reasonably safe - not 100%, but reasonably. Which is about good enough for most things.

You guys know that probably every third person on Freenode has his or her own IRC bot on the channel? ;). Ok, I'm exaggerating, but I'm yet to see a popular channel that isn't logged either publicly or privately.

Most channel bots log, and most channels have bots to provide application services (like history searching). I have 5 continuous years of history for some of the channel bots I run. There used to be a bot that would try and join every public channel and produced a web-searchable archive of transcripts, I don't know if this is still running.

Most channels I'm in don't have channel bots - one XKCD-related subchannel does (and it doesn't log), and the local hackspace's does (and it doesn't log either), but I'm in another half a dozen channels that don't.

I think that comparing Twitter or Slack to IRC in that manner is a broken comparison. Neither of those services can possibly stand up next to IRC, an open protocol with several dozen client and server implementations and millions of users. IRC thrives because it's so open and easy to use from a programmer's point of view. There's no centralized authority or point of failure with IRC.

I consider not seeing the previous history a feature. When I say something to a group of people currently in a room, I only address these people and this message is not necessarily intended for anyone joining later.

I've never implemented one, but surely an ircd could do this if it wanted to? When someone joins a channel, send them a certain number of lines of history straight away, etc?

The protocol provides no way to send a scrollback or a history of messages. Additionally messages have no timestamp, so you don't know when they were written, only when you received them.

I'm no IRC expert, but I do know that some IRCds do support sending a scrollback / channel history. For example, InspIRCd's chanhistory module: https://wiki.inspircd.org/Modules/2.0/chanhistory

How it actually accomplishes that within the framework of the "protocol," I don't know.

The messages are sent as extra messages, duplicating timestamps and faking senders and overall it's pretty ugly.

The Quassel protocol supports this, unfortunately it looks like the quassel team doesn't care about taking it further than where it is.

Full disclosure: I am one of the developers on the aforementioned IRC server.

In a future release InspIRCd will adopt support for the server-time extension which will allow us to get rid of the timestamp duplication if a user's client supports it.

Interesting. Can you tell me what you think of Quassel as a protocol?

It's very specialized and last time I looked at it, it was based on Qt types and other ugly things. It would not be realistic as an alternative protocol for IRC itself.

Just a note that the QDataStream format is documented, and has been implemented in other languages such as Java. That doesn't mean that the Quassel protocol should replace IRC of course. :-)

Timestamps – there's a standard extension for this (see IRCv3 above). ZNC has been using it for maybe a year.

Senders – there's absolutely no reason to fake senders, since it was always valid for messages to come from people not in the channel.

It sends some channel messages after the JOIN. The new IRCv3.2 specification (being formally ratified across vendors soon!) adds a BURST type to make the protocol transactional which will allow displaying the messages in the right order with a little bit of work on the client side.

It could be implemented as an ircv3 capability, ircv3 supports timestamps.