ISO 646[0] was a 7-bit character encoding, of which ASCII is a superset. It defined a common subset of characters that would always be available, leaving a few codepoints for local supersets to fill in. ASCII used some of those for punctuation, but Scandinavian character sets[1] filled them with extra lowercase and uppercase letters with diacritics.
IRC came from Finland, so it was designed for those charsets.
But the standard for the Internet is supposed to be ASCII, so what happens when you use those codes from ASCII that correspond to extra letters in the Scandinavian character sets? Take a look at RFC 1459:[2]
Because of IRC's scandanavian origin, the characters {}| are
considered to be the lower case equivalents of the characters []\,
respectively. This is a critical issue when determining the
equivalence of two nicknames.
Cute, right? Try it, it actually works (at least on Freenode!).
There's even an example of this code page in the article - it mentions the name "Markku J{rvinen", which is presumably intended to be "Markku Järvinen". This is probably accidental, as the page is served with charset=iso-8859-1.
I wonder how they used programming languages which assign special meaning to those characters; use ASCII and the code looks fine but string constants with those characters will be very odd, use the local variant and the string constants look better but the code worse.
foo[1] = "\r\n";
fooÄ1Å = "ÖrÖn";
Perhaps it's something you just get used to after a while. The standard QWERTY keyboard has a reversed form of this "caseness" , with lowercase being []\ and their "uppercase" shifted versions {}|.
BTW, the cases are other way round: {|} are lower case äåö and [\] are upper case ÄÖÅ. That is important for sorting order in strings.
The sorting wasn't flawless though, because in ASCII these are ordered {, | and } but the proper (Swedish and Finnish) collation of the end of alphabet is ...xyzåäö. So unless you specifically programmed around it, you'd get slightly incorrect sorting.
Yes, you would get used to having ÄÅ and äå as brackets and braces in programming. If this thing came back I'd be in an hour happily saying things like:
while(<¤fh>) ä
Él=split ' ';
print "¤lÄ0Å, ¤lÄ3ÅÖn";
å
I was using MS-DOS back then. It had a command for changing the "code page", which would determine the appearance of special characters. (I imagine it was technically switching between preset character sets on the video card's character generator.)
So when you wanted to do word processing, you would first switch to the code page that has the Nordic characters. For programming, you'd switch to the US code page.
I don't know how real operating systems handled it :)
> I was using MS-DOS back then. It had a command for changing the "code page", which would determine the appearance of special characters. (I imagine it was technically switching between preset character sets on the video card's character generator.)
I think C89 introduced 'trigraphs' for exactly that reason: so people using non-ASCII ISO646 systems could have symbols that at least vaguely resembled the ones Ritchie and Kernighan intended:
IRC's longevity and appeal is fascinating - it seems like that the more constrained the bandwidth of communication, the more compact the configuration, and the more quirky and charismatic everyone's favourite clients (be they irssi, weechat, mIRC, xchat...) the more staying power a comms medium has. My workplace started off life ~15 years ago as a channel on a small student IRC network - the company effectively evolved out of IRC. The importance of IRC bots (be they eggdrops, or pircbot, or whatever) also seems to have become core to IRC culture - a well implemented IRC bot can be an incredibly powerful tool for glueing a community together.
All this makes it incredibly hard when considering what could come after IRC, if anything. XMPP's MUCs just don't seem to have the same sticking power, and meanwhile things like Slack and HipChat come along and risk hijacking all our comms into closed silos rather than the relative openness of IRC and XMPP.
Regardless, after 15 years of addiction to IRC we're having a go at coming up with something better that still has some of the same appeal. The project is called Matrix.org, and the main differences to IRC are:
* Open federation; anyone can spin up a server and join in.
* Conversation history (i.e. scrollback) is the main building block - a room's history is stored (partially or completely) over all the servers who are participating in a room. So there's no single point of control or failure.
* Compulsory cryptographically signed message history (necessary due to the open federation)
* Simple HTTP/JSON client-server API. (Server-server API is also HTTPS/JSON)
* Store arbitrary structured data in the room - not just text messages. So you can use it for setting up VoIP calls; whiteboarding info; random device telemetry, or whatever.
* Built-in distributed file storage (no more DCC, for better or worse)
* Strong identity and end-to-end encryption (via a variant of Axolotl; currently in dev)
* Support for 3rd party IDs - contact people based on their mail address, phone number, or whatever details folks chose to identify themselves by.
So if you like IRC and are interested in a fairly radical alternative, please drop by http://matrix.org/beta and say hi. It's in early beta, but it's fairly usable - we have Android and iOS clients and SDKs for python, perl, iOS, Android and an increasingly active dev community. Also, it's not frozen yet, so now is a great chance to get involved and make sure we get it right :)
The signed messages history and end-to-end encryption sounds interesting, but largely from a "how is this going to work in public rooms" perspective.
IRC is largely a broadcast tool in the same sense that many social networks are. With IRC, you generally chat in open channels where anybody can join. While encryption protects against MITM, the privacy arguments are moot given the broadcast nature of public chat rooms. So to combine that with server-held scrollbacks, and I'm left really curious about your intended usage / benefits of end-to-end encryption.
So if you would you mind discussing a little more detail about that aspect of your chat protocol, I'd certainly be very interested in reading it :)
So, signed-message history is purely for integrity, not privacy. The problem is that if all your rooms are completely decentralised, how do you stop a rogue server injecting false information about the past? All servers have a keypair that they use to sign messages they originate, and this signature includes pointers to the 'parent' message(s) that immediately precede them in the conversation. Thus every message asserts the integrity of the graph of messages in a room up to that point, and means that a rogue server can't start censoring history, or claiming its users have privileges, or whatever in retrospect. The full details for signing message history can be found at https://github.com/matrix-org/matrix-doc/blob/master/specifi....
End-to-end crypto is another matter. It can make sense both for private and public chat rooms (if you define public rooms as ones which any member of the public can be invited into by an existing member), as if you use perfectly forward secrecy even a public room ends up being a secure distribution channel for the members - each message has a unique key which can be discarded by the clients after that message is downloaded and decrypted, meaning that the history cannot be replayed by an attacker. However, there's obviously a compromise between deliberately replayable history (after all, Matrix is all about synchronised conversation history) and PFS. So we've tried to be pragmatic and give the user a choice per-room to decide how secure the history should be.
At one end of the spectrum, you can pick a single key for the room which never changes - killing any PFS but meaning that any new client or device can read infinite scrollback for the room. At the other end of the spectrum you have pure PFS. In the middle, you have the ability to re-key the room for different criteria - e.g. changing the key whenever the membership state of a room changes, or applying different keys for different types of messages. This allows clients to cache as many keys as they need in order to replay the different classes of data (and for PFS, a client could chose to cache keys too to allow limited re-synchronisation from the server). The actual ratchet we're using to evolve the keys is a axolotl. All of the end-to-end crypto is currently in development, but we're just finishing the C++ axolotl implementation currently which will then be the reference implementation for all the various Matrix clients out there. And all of end-to-end crypto is optional: you can't join an encrypted room if your client doesn't do encryption, but we don't force clients or rooms to be encrypted if their users don't want them to be. There's a longer (high level) explanation of all this on http://lwn.net/Articles/634144/.
Interesting - this is new to me (and ironic, given Aether was a candidate name for Matrix!). The projects seem very similar in some ways - both python/twisted/sqlite server stacks + angular frontend. The big differences seem to be that Aether is using AMP as its federation protocol rather than Matrix's HTTP/JSON federated DAGs, and is focused initially on forums rather than IM/VoIP. It's a bit strange that it advertises itself as entirely peer-to-peer though, when seemingly it is very much a client-server model (with server/server federation) just like Matrix, SMTP or XMPP. It's also slightly strange that the github repo is only showing certain drops from a private repo - I wonder why the dev isn't happening in the open. It's also hard to see what the actual decentralisation algorithm is, beyond replication. It doesn't seem to be using DAGs for eventual consistency or signing forum history.
In terms of anti-spam proof-of-work stuff, identity, sybil attacks and all the good stuff mentioned at http://blog.getaether.net/post/101566226287/a-few-updates-ab... it sounds like Aether & Matrix are at a fairly similar point. It would be super-cool to chat to Burak and get the two federated together (after all, Matrix is all about being glue between other communication media) - will ping him :)
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.
By the way, #startups on freenode seems to have the most HN users on it.
> 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.
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.
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.
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.
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.
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. :-)
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.
I was a little late to the irc game... Only started at 12.... 18 years ago.
Loved mirc... Made tones of custom scripts
I loved serving and getting files using xdcc from my fansubbing days. I dabbled in some warez, stayed strong when irc.cjb.net came under fire of massive ddos, and jumped many nodes... Always with trusty xdcc to serve our releases before bittorent (was hosting server since initial python torrent server release too)
Wow, nice! Never used ircII but used BitchX (famous spin-off)! Today I use "weechat", an enhanced version of 'irssi' while usually lagging on Freenode :-)
1991 here too. I'm 36. I'm still on pretty much all day, every day, in a very large (private) irc channel that all my friends hang out in; same group of about 15 people for the last decade or so.
Same here, although I was 11. 7 is damn impressive given access means back then (I SLIP'd my Slackware box into Rutgers Camden). My IRC story linking in Finland -- I sought out Purple Motion and Skaven on an IRC server in .fi in 94 to be a fanboy and tell them how much I loved their music. Little did I know they were only a few years older than me. I dreamt of convincing my parents I needed to go to Assembly.. :)
I've only been on IRC for 4 years and I can't imagine life without it. For me, it's become one of those constants I can rely on that's just always there wherever I go.
Similarly, I remember using (PJIRC? ParrotIRC? Something like that from ~2000) to get on trivia game channels when I was in elementary school. Then, years later when I was getting into programming, I found out that this thing I've been using all along is a great resource for connecting with like minded people! The internet has been a social playground to me for almost as long as I've been exposed to it.
The IRCv3 working group (http://ircv3.org), comprising server and client developers, continues to work on new features. The latest update is expected to be finalized around the end of March.
We are planning to bring some experimental JSON-based transport for 3.3 which will allow us to eventually start transitioning to considering IRC events in an intermediate representation. The key thing is going to be getting the client authors to understand the benefits of this approach, as well as providing implementation of both the extended RFC1459 payload format and the JSON format.
The eventual end game is to have a flag day and deprecate the legacy format, but this will probably take a few years to do.
I wrote an Irc script called TextBox as a teenager. Among other things it was one of the first that could implement Irc bots via DCC RAW tcp connections from the script itself, allowing you to martial armies of channel takeover bots. Seemed cool when I was 15, and it was actually through Irc channel wars that I learned the basics of network protocol design.
Lol. Yeah, those were fun times. Old school IRC was basically a non stop CTF tournament. I wrote TextBox on a Linux 486 with kernel 0.99.15 I think, or maybe 1.0.x, and a shell account on a Sun SparcStation via a local ISP.
Anyone else has the issue that every IRC channel seems dead? If I'm very lucky, I'll find an active channel, but it will die in about a month. Perhaps I am simply not looking in the right places.
There are many large Freenode channels that don't appear to be dying any time soon, like #bash, #archlinux, ##linux, etc. (Though, just because they're large and not dying doesn't mean they're worth hanging out in. :) )
As a tip, on Freenode, you can message the Alis bot to list channels:
/msg alis list *linux*
The reply from Alis will include how many users are in channels whose names match linux. If it has >500 users, it probably isn't going anywhere any time soon. (You can do this for other topics that interest you, of course.)
It seems that many subreddits also have thriving IRC communities. See: #boardgames on Freenode, which probably has ~150 connected at any given time. So it's not only the big channels!
These days, I only go to IRC when I have a specific purpose in mind. Some online groups [still] use it almost as a support channel. It [the way I use it now] is not like my days in uni when it was a popular form of "casual chat."
I'm still in many casual chat channels. The general topic ones are the best for this, not ones with a strict "Support/Devel for $PROJECT" mentality that shut down offtopic conversation immediately. It's also a matter of finding like minded individuals to chat with, which does seem harder than it was when I was in highschool a decade ago. Of course, I don't spend much time off of Freenode, for all I know, other networks are the equivalent of crossroads chat or an IRC version of /b/!
I'm not on freenode or any of the main IRC servers very often, so I can't comment there, but there's a bit of a resurgence of IRC for me via http://tilde.town, one of the many tilde servers that sprung up after http://tilde.club went viral. The server runs a local IRC instance and there's usually a few of us on there chatting during NA daytime during the week (at least, that's when I'm on, usually).
Sadly, I was slightly too late to join the original, but there are now a number of similar clubs with available space. Tilde Town is where I spend my time, and it seems to be a nice, friendly place.
The channel for my local hackerspace is quite active, but not so busy that you can't keep track of what is going on. I also loiter in some bsd channels that are reasonably active as well.
It probably helps to find channels that have a purpose behind them.
If I recall correctly, a few PC games used irc code as the basis of there networking stack.
irc2 script was what really got me into programming all those years ago. At one point I had VT100 codes spammed to the status line in order to draw blocks on the screen for an in chat tetris game drawn in ascii. I also managed to hack out of the sandbox the client was running in by setting the ENCRYPT_PROGRAM feature to /bin/sh. Good times.
Twitch chat is also running on top of IRC. You can connect to their irc servers and use the twitch chat from your irc client. With limited capabilities I might add (no private messages for one). More info: http://help.twitch.tv/customer/portal/articles/1302780-twitc...
Here is a small list of famous projects from the common developer tools and their corresponding contact web pages that mention IRC plus where to find help and/or core developers of such projects.
ISO 646[0] was a 7-bit character encoding, of which ASCII is a superset. It defined a common subset of characters that would always be available, leaving a few codepoints for local supersets to fill in. ASCII used some of those for punctuation, but Scandinavian character sets[1] filled them with extra lowercase and uppercase letters with diacritics.
IRC came from Finland, so it was designed for those charsets.
But the standard for the Internet is supposed to be ASCII, so what happens when you use those codes from ASCII that correspond to extra letters in the Scandinavian character sets? Take a look at RFC 1459:[2]
Cute, right? Try it, it actually works (at least on Freenode!).[0] https://en.wikipedia.org/wiki/ISO/IEC_646
[1] https://en.wikipedia.org/wiki/ISO/IEC_646#National_variants
[2] http://tools.ietf.org/html/rfc1459 § 2.3