Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

Open Real Time Messaging System 102

Posted by CmdrTaco from the stuff-to-fart-around-with dept.
Jeremie writes "Jabber is a new project I recently started to create a complete open-source platform for Instant Messaging with transparent communication to other IM systems(ICQ, AIM, etc). Most of the initial design and protocol work is done, as well as a working server and a few test clients."
This discussion has been archived. No new comments can be posted.

Open Real Time Messaging System More

Open Real Time Messaging System

Comments Filter:
  • I really don't like the idea of a corporate company taking care of my server acces. A government a little less, but certainly not the US goverment (way too big and fscked up). And then again, smart cards aren't a real good solution, they always want statistics, and I find that very dangerous.

    So rock-on for cookies, 4000 different passwords, and may I be the only one to grant myself access :]
  • HCP [ml.org] is another interesting project in the works. It lets you simply plug in existing protocols...
  • > If you need to see whether a person you are
    > looking for is currently online, or not, you
    > use finger. If you need "Instant Messaging",
    > there's always ytalk. Chat? IRC, and so on...

    So you're saying I have to always be telnetted into my server, and paying attention to my telnet session to talk to people? Or do I have to make people go to my web site to get my IP, and maybe I'm booted into Linux to answer them, and maybe they have a talk client... and...

    The nice thing about instant messaging is just that. Instant messaging. As a program, ICQ is pretty much a piece of crap, but it has the advantage that a LOT of people use it. You can be fairly sure to get ahold of friends online. Even when your webpage changes, your email address changes, whatever, you always have that "ICQ number", and people can get ahold of you.

    Maybe someday we can "convert" all those ICQ users over to something that works better, but most people are content where they are. Until then, I'll have to live with ICQ when I want to get ahold of my friend from another state easily...
  • I've put great thought into these also, and the Privacy part is going to be addressed via different built in "privacy" levels in the server. One of them will be absolutely invisible, the only way someone would know you existed is if you sent them a message, and then they could only reply...

    The security I'm leaving for version 2, but I'm making sure not to do anything to get in the way of it. Using something like PGP could already be used in the existing architecture, but would have to be supported by the client.

    Jer
  • There will definately also be a command to do this for Jabber, soon probably.

    jwrite user@server.com "message"
    or
    echo "message" | jwrite user@server.com

    Jer
  • I also use talk, finger, etc... and you can count on Jabber working 100% WITH those utilities(if the Jabber server administrator installs translators for those services), and also have alias Jabber functions like jtalk, jwrite, jfinger that work identically but go directly to the jabber server instead of through a translator.

    I live on the CLI, but many/most of my friends do not, and I want to be able to talk to them... hence Jabber :)
  • 1) The links in the Users section going to the overview was an accident, although the overview is really the only data there and yes, way overqualified for most users. It will be "nicer" after a public stable release.

    2) File transfer or anything dealing with big binary chunks isn't going to be part of the main protocol. My current plan is to impliment all of those activities through HTTP/1.1 and WebDAV which is perfectly suited for that application, and just send the startup/location information through Jabber.

    3) Not sure totally what you mean... thinking...

    4) Because tools for manipulating/processing XML are quickly becoming standard and available. Secondly, XML is just a wonderful way to wrap up data, and it's text, easy to deal with in any situation.

    5) Mirabilis uses UDP because ICQ is central-server based, and there is no way that their servers could possibly support a few million TCP connections. Jabber has no central server, so doesn't have that restriction, although very busy Jabber servers will have to deal with some problems because of TCP also, but there are ways of fixing it.

    6) Sorry about the speling :) Will fix!

    Thanks!

    Jer
  • I'll be honest, I'm not a big IRC user, although I admire the architecture.

    I was thinking, though, that a Jabber transport could be used to create seamless communication with IRC users, and vice versa. The Jabber users wouldn't really live in a room or be able to participate in the rooms(use a real IRC client for that) but could send IRC users messages like "user id@EFnet" and the Jabber IRC transport would do the translation.

    The Jabber server is ready, if someone familiar with the IRC protocol wants to code this :)
  • See my reply above to "why not IRC?", I think Jabber and IRC can work together very nicely :)
  • I agree 1000% and this is exactly why I did Jabber. It may also be just another IM client/server system, but it is more. It was _designed_ to be interoperable with all other instant messaging systems from the start, so if you are using a Jabber client, you can talk to anyone else on any other system, and they can talk to you.

    Within a short period of time(months), I expect Jabber to reach the "near-universal" interoperability.
  • Jabber is under the GPL at this point, but if need be, I'm willing to put it under another license to make it compatable.

    Besides, Mozilla would only need a client, and clients are quite easy to write.

    Jer
  • Yes, I'm planning on server file transfers through the server, probably using HTTP(specifically the WebDAV extensions) and letting Jabber communicate the locations/passwords for the files.

    The files don't even need to be stored on the server, it can be a socket-to-socket copy in a server process, but storing them might be a usefull option, especially for broken downloads and group sends.
  • It does determine who is online, providing instant status updates.

    And as far as protocols, it doesn't need to show what they are using(although it can), because anything you send to them via Jabber will be translated on the fly to whatever protocol they are using if they are not Jabber users themselves.

    Yes, everything else is superfluous, that is why Jabber is what it is, exactly what you state(plus the superfluous stuff too :)

    Jer
  • Man, I wish people would just use email addreses for usernames. I mean, who in their right mind wants to remember a 15 char username (what AOL IM makes you use since they have 10 million other people taking anything remotely good), or the massively long number ICQ makes you use.

    It's silly, everyone has an email address... Use it. I mean, one address for everything, email, chat, etc... sure would be nice.
  • One global ID for everything. Combination of letters/numbers. Why hasn't it caught on among the hacker community - too corporate?

    http://www.qdirectory.com

    (Torpor Q = 8008)
  • It even has authentication. And it has ways to reduce network load.

    It's called Zephyr. And it's widely used at a number of universities. The code is freely available, there are even prebuilt RPMs (minus Kerberos authentication support) on RHCN.

    Why invent yet another protocol when we already have one?
  • If someone wrote an IRC client based around watching notifies and sending private messages instead of channels, one could just as easily do the same stuff and more that ICQ does with IRC. IRC is a more mature protocol, more widely used, and isn't proprietary like ICQ. The technology has been around for quite a while, the only difference is that Mirabilis came up with a new user interface that is less intrusive than the average IRC client. Someone want to do this with IRC?

  • IRC is based around the concept of rooms. You can only talk to other users inside that room, and all messages are public (by default) to the room.

    Actually that isn't true. When sending a message over IRC, the command to send to a specific user and to send to a channel are exactly the same. There is no "default" message destination, channels merely exist to facilitate one-to-many and many-to-many communication, as opposed to one-to-one communication, as ICQ does.

    A system like ICQ is based around the concept of lists of people. You can send messages to anyone on your list, and the messages and generally private to that person. Its restricted by its generally centralized and proprietary architecture and protocols.

    The "lists of people" concept in ICQ is entirely client side, and can be done in IRC using NOTIFYs. Client-to-client stuff is handled using CTCP and DCC (Client-To-Client-Protocol and Direct-Client-to-Client respectively).

    What IRC lacks is encrypted communications and established user accounts - at the moment, relatively little data is saved about users, and their nick can often change hands easily, allowing people to pretend to be or me mistaken for others... This is one of the few advantages of the centralization of ICQ and AIM.

  • You can do the exact same thing with IRC. Just get on an IRC server and don't join any channels. If your friends want to contact you, they can /msg you, just like with ICQ or AIM.

    Anyway, the more like a BBS it is, the better. FidoNet is *still* the best messaging system, a LOT better than UseNet, webboards, or mailing lists.
  • What baggage? IRC is a quite simple, well-documented protocol. Everything is in plaintext, and all the commands have numbers assigned to them so a client can just look at the numbers and know what's happening. Hell you can write IRC bots inside of mIRC's pathetic scripting language, so it can't be that hard to write an IRC client that acts like ICQ. All you need to do is take away the ability to /join a #channel and just use /msg instead, and you've got ICQ.

    And IRC is definitely much more firewall friendly than ICQ. ICQ uses tons of different ports, while IRC uses one - 6667. Most clients can even go through a SOCKS firewall if you wish.
  • There's this cool system where you can message people even when their computer is off!

    email.
  • Actually, user-to-user messages on ICQ are TCP sometimes. If it fails to send through TCP directly to the user, and you click on "send through server," then it'll send through the server using UDP.
  • My, aren't we grouchy today.
  • Finger works fine -- unless the person you are looking for happens to be on a Windows box or another machine that isn't running a finger server, or a machine running a finger server but doesn't actually give any useful information (which seems to be the trend these days).

    ytalk works fine -- assuming the person is on a machine with a talk client (and server? I can't remember). And (as you mentioned) is computer literate (or, more precisely, UNIX/command-line literate).

    Instant messaging has its place, as do IRC, talk, etc. It is especially convenient for running in the background while doing other work. Instant messaging doesn't replace these programs...it fills a slightly different need.

  • I really hope this one will go through a pretty secure firewall. Most people have tcp access to port 80/21, unless they are hooked to a proxy. If they can pipe realaudio through port80, then this should be easy.
  • I use AIM & ICQ when I want to talk to certain people; these programs show when these people are online. These systems have a user authentication system so someone can't take someone else's nick like on most servers on IRC (servers like slashnet are an exception).

    I use IRC when I have a quick question about something, and I can't find it in the manual. Then I'm really not interested in who I'm talking too, as long as I get an answer. Then I usually stick around to return the favor to someone else and answer their question.

    I have though about doing something like an Instant Messanger system over IRC. Here's how it would work: the user client would send out a request to the client of each buddy, the buddy clients would sign it, using public key encryption, indicating that they are who they are. This would use DCC to the primary nick. If this is unsuccessful (like someone else happens to be using the same nick instead of the intended buddy), the backup would be communication via a certain channel. The main client would indicate that it has a certain buddy key, and the buddy client would respond returning the request and signature. Thus, the buddy client could change nicks (like the case when someone else is using that nick), but keep the public key, and people can still get a hold of the buddy.

    I have two main problems with this: 1) I live in the US, and thus I wouldn't be able to do the public signature part. 2) This would create a lot of traffic on the designated backup channel, I don't think that the server ops would appreciate this.

    Any thoughts/ideas?
  • It looks as if Jabber's main strength is in any-to-any
    messageing. Frankly, if they develop an addressing
    scheme that allows me to send a message to just about
    anyone, on any protocol (up to and including email)
    then Jabber is the client I'll use.

    And as people realise "Well, with my ICQ program, I can
    message other ICQ users, but this guy can use Jabber to
    message AIM, ICQ, Mail, IETF, etc", one protocol will emerge the victor.
    Think about how many protocols your email (sometimes) goes through. Do you care? No, because gateways make it invisible.
  • There's a few ways to look at this. The first is to compare messages with SMTP mail. Where's the security and authentication in SMTP? Almost none. Do you care? Maybe, but if so you either use PGP to encrypt it, or perhaps you build your own mail network using something like (eek!) Notes, and if
    you really must go over the 'net, use a VPN.
    Most people tolerate the insecurities of SMTP and
    get on with it, without Back Orifice ever getting installed on their machines ;)

    Then there's instant messaging. One comparisom I've heard (thanks Nemo) is "ICQ is like passing notes in class". It's not quite chat, it's not quite mail, but
    for the most part, you take your chances, and if the teacher nabs the note and reads it, well tough.
    Again, if you care, you can use PGP, to build a secure messaging system atop the insecure one -- just as TCP is a reliable network protocol built atop IP's *un*reliable network protocol.
  • I'll agree that the protocol implementation and the UI should be kept seperate. But I'd go further. The UNIX way is to have a small command line program which does the job then exits. cicq is supposedly working towards this:

    $ echo "You there?" | cicq -send slim

    ... a gui should be a wrapper around programs such as these. A "universal" messaging system would also be a wrapper around more specialised programs. i.e. messagesend -send icq:slim would spawn cicq -send slim

    It's the UNIX way. And it's good. Let's not forget it just because some of us feel we're competing against Windows.
  • A couple of thoughts I had on reading this item.
    1. Zephyr

      It works, it scales (somewhat), it supports real authentication, it's open, it presents the right paradigm for instant messaging and online discussion. (Since I used it heavily at CMU, using AOL Instant Messenger, IRC, and ICQ is just painful.)

      Go to ftp://athena-dist.mit.edu/pub/ATHENA/z ephyr/ [mit.edu] to download the source.

    2. IMPP

      There's an effort underway by the IETF to come up with a standard protocol for instant messaging and "presence information" called IMPP. Anyone considering working on a project like this should get in the loop so they can make sure all their bases are covered, and so that they can interoperate with others' servers.

      Go to http://lists.fsck.com/cgi-bin/wilma/pip [fsck.com] for mailing list archives.

  • Unless you REALLY trust the people who are managing your UIN/Username/etc on the server, you don't WAN'T them to share everything between themselves. Besides, in Europe, it's illegal for them to do so.

    A far better notion is to have all that information available to YOU, and YOU decide what to share with them. However, this technology (like a digital wallet) has been around for a really long time in web-world and has been abandoned for now, mostly because people don't want to administer them. You move computers, you have to move the thing. Floppies suck, smart cards aren't everywhere.

    Now once GSM with PID smart-cards come to the US and I can use one card for credit, ATM, computer security and phone.... yum.... pervasive technology with privacy rights...
  • Some web sites do use a centralised user database.

    You create an account on this one site.. and when you want to access any of the sites that support it, it just authenticats you off the first site's server.

    It's called adultcheck :)

    I read somewhere a lot of advances in technology, including eCommerce, have been greatly helped along by the Adult entertainment industry.. I'm begining to believe it.
  • It's worth pointing out the GALE [gale.org] project as well.

  • AIM (Score:1)

    by Troy ( 3118 )
    I'm not sure about anyone else, but I've been using various versions of AIM (even beta) on my Mac and have never had any stability problems with it (the client). The only real problems that I've had have been server side, and even those are minimal and most likely due to the fact that AOL happens to serve millions of people and any line can only take so much.

    Say what you want about certain members of AOL's clientele. Whine about it being an evil, greedy corportation. It's hard to deny that what AOL is doing technically is pretty darn impressive.
  • (hey, if you want feedback, here it is...)

    + All the links in the "Users" column go to the Overview, which claims it's for users but quickly bangs on about distributed servers, XML protocols and other techie stuff.

    + XML sounds very nice for simple messages, but how does it deal with live chat and file transfer?

    + The XML tags and attributes could do with being a bit more apt to the data. (e.g. "jenny" would be better put as "jenny" - at least, that's how it appears)

    + Come to think of it, why use XML rather than something a bit leaner? I wouldn't have thought that the client-server communications had to be human-readable, especially since it sounds like the only things Jabber clients will be talking to are Jabber servers.

    + Do you know why Mirabilis chose UDP for the ICQ transport?

    + Running a spellchecker on your site wouldn't hurt, either...

    Otherwise, very nice, very commendable, good luck with it, etc. etc...
  • Okay, I'm getting annoyed now. I'm trying to use lt and gt entities so that y'all can see the XML tags I'm talking about and I DID hit Preview and they DID show up and I hit Submit and now they're not there.

    Pants.

    I'm going to have one more go at this and if it doesn't work you'll just have to view source to get what I'm talking about.

    + The XML tags and attributes could do with being a bit more apt to the data. (e.g. "<group name='main'>jenny</group>" would be better put as "<user name='main'>jenny</user>" - at least, that's how it appears)

    NOW WORK, YOU BASTARD!

  • Take a look at jwz's posting on the subject in Mozilla.org's "Blue Sky" section.
  • I've looked at alot of ICQish projects around, but Jabber looks like it has some great potential. I especialy like the idea of transports and having an XML based protocol. I added myself to the update list hope it catches on.

    Snoop

  • Don't start a new protocol. The IETF wants instant messaging to be global and standardized; the last thing we need is another duplication of effort. Work with the IETF and end up with something standard.


    Oh and by the way ... KDE sucks.

  • AIM (Score:1)

    by Al Wold ( 5038 )
    What's the point of creating an "open" protocol, when AOL has already opened theirs? ICQ, of course is totally stupid, lagged, and insecure. I was glad to hear that AOL bought them out...maybe it will add some of the AOL stability to it.

  • AIM (Score:1)

    by Al Wold ( 5038 )
    Give me one good reason why you think AOL is unstable (don't forget to take into consideration the fact that they have experienced growth of tremendous levels, and will inevitably experience some growing pains).
  • IRC does different things. The most important point about ICQ is (a) you can see who of your contacts is available (b) you can initiate a conversation without pre-arranging it, like with a phone, since the reciever app is omnipresent.
  • This all comes about because Unix never got instant messaging, rmsg getting sucked into irc.

    It'd be nice if we could get a standard so you could do

    rwrite username@full.host.and.domain.net "Hi there, how's it going?"

  • I wrote the first BuddyList server for AOL several years ago. (see my resume at http://sdw.st).

    I've been watching the evolution of Presence Indicators with a lot of interest, of course, and I like some of the decisions so far here. I have some ideas that I'm thinking of persuing on my own that I may be able to share with everyone soon.

    (Don't ask me about AOL internals because obviously I have a strictly professional and ethical obligation to uphold non-disclosure contracts.)

    sdw
  • I know from past experience that too many hacker wannabees think that stealing accounts or bumping people or other pranks is cool rather than learning to program, which IS cool. Of course /./* is well into the latter category and didn't need the pre-emptive warning. Unfortunately my oldest son falls into the former category for the moment, sadly.

    If you would have looked at the resume, you would have seen at least one huge addition to instant messaging that I came up with, architected and designed, skunk-worked, managed as an early project, implemented, had 25000 beta users, and ultimately watched die because of abuse fears...

    sdw
  • You could easily make it totally transparent to the end user that you were using PGP.
    Just make it a check box in the configuration and have a simple check to see if it is installed and working properly.

    I think its an excellent idea.
  • I admire the attempt. Unlike the above-anonymous cowards...

    It would be nice to make a client that could do AIM, ICQ, dynamic DNS, etc. Put that in a 32x32 icon and stick it in wharf, and you got one kick-ass project.

    Keep up the good work...

    g'luck



    --
  • well, it might be so that they don't have the same problem that AOLIM does -- I have 3 "Dave"s on my list, and it's still fine. also, very easy to change your username.

    yes, I'll agree that that number is a pain in the butt, and only my techie friends know it off the top of their heads, but it has its points.

    you can search for the nickname, or just about any other piece of info -- it's just not the PRIMARY means of identification to the server.
  • and who can beat being able to have your TA's, and even some professors online, easily botherable? no one. that's the problem.

    and as long as I'm stuck with this windoze box (no, I do not feel like writing my own ethernet card drivers, thank you) I'm stuck with ICQ. most people don't use finger, and if you are using dynamic IP (love that MSN when I'm at home!) it's kinda interesting trying to finger someone, even if they are running finger (as I am).

    so, I guess if someone wants to see if I'm online, they'd better call me first to see what my IP is.
  • That's a nice thought, but in pratice, ick. If you do that, then the userdirectory becomes a spammer's paradise: a quick, queryable database of email addresses matched to real names. Ick! Ick! Ick!

    This of course will eventually be the Right Way to do it, once cerificate-signed email becomes the norm and any and all email without at least a Class-2 caliber cert behind it gets discarded.

    But it isn't, so it's not.

  • XML? (Score:1)

    by kebernet ( 8443 )
    Besides, if you have a well designed DTD for chatty stuff, there really wont be that much overhead, and an XML based system gives people the ability to design almost entirely new realtime communication applications ontop of the original code without writing anything but a new doctype.

  • ytalk? (Score:1)

    by TomG ( 9985 )
    for messaging, I've always used write and ytalk

    In my opinion, nothing is simpler and faster.

  • Well, for UNIX, there is a program called mxx [home.com], that does public key signatures, and encryption of messages. It works between systems running the server.

    No reason it couldn't be extended slightly to work on Windows machines, handle a directory lookup, etc...

    Note that the author is avoiding touching the code anymore.

  • I've been following many of the instant messaging projects that are around, but I don't know which one to try.

    I want the one that is closest to ICQ, has a good Windows client, and is fairly mature.

    As a little side note, I think Teaser and Firecat is an important project in this field, mainly becuase it does not attempt to emulate ICQ and therefore is more secure. But we need something that is like ICQ, just because Windows users are more at home with it.
  • I used to work at a company that lets say puts out web browsers and I tried to push them to do this, but they ignored me time and time again.

    O well. If an open source movement picks up in this area we might see some cools things happen. An ideal goal would be to get a windows version up and running so that smaller ISP's can snatch it and possibly force more commercial ISP's to adopt the technology. Then agin AOL paid alot of money for ICQ and would be rather against this I imagine.
  • This brings up another issue I'd like to see resolved. I hate having to create new user accounts on all of these web sites. I'd like one user account so that if I come across a site I'd like to take a look at, I just type in my "universial" username and password and I get instant access.

    As an example, I went to TV guide to see local listings of Nerds 2.01, but they wanted me to create a new user account. So I walked away never to return. More and more sites are doing this and it's extremely aggravating, it takes time, and I bet you they are losing customers because of this policy.
  • In one of those countless "predictions for the coming year" articles the columnists like to write in late December/early January, PC Week's Rob O'Regan says we'll see a new killer Internet app [zdnet.com] which will combine instant messaging with "document sharing and other real-time collaboration."

    Sounds like a cool idea to me. I'm far from an expert, but I wonder if Jabber's XML-based protocol and the open source model in general will make it possible to turn it into this kind of app. If so, it looks like a great chance to show the world (once again) what open source can do!

  • They would still be able to send spam to your
    jabber message thingy.
  • nickserv and all of the other *serv 'bots' don't exist on all IRC networks. For that matter, I've only seen them on dalnet, and when you've got 450 people in #chatzone at once, i can see why it might be neccessary. I don't see any *serv on efnet or undernet. So it's not necessarily true that IRC provides the same features as ICQ or AIM, even if you just sit on the server without joining a channel or anything.

    Hm, and perhaps I should get offline at home once in a while... it's been online since i last restarted it, a little more than a week ago :o)
  • The person who said "There are too many chiefs and not enough indians" is TOTALLY correct. A quick search on freshmeat returns fifteen of these "instant message" projects under development right now that all do pretty much the same things.

    To the programmers working on these projects: It's noble that you are committing your time to cool and open projects like this, but don't you think you could get more done if you all worked together rather than seperately?

    An even more disturbing thing I have noticed about these projects is the fact that many of them are being developed under the Windoze paradigm where the interface is closely tied to the implementation, rather than the unix model where the interface, implementation, and underlying libs are seperate components.

    For instance, download a few of these projects and check them out. All of them include their own implementation of the ICQ protocol. People, the ICQ protocol is the same regardless of whether you are using Qt or GTK! Why can't we develop a libicq and a libaim THAT EVERYONE AGREES ON? This way the protocol and the interface can be worked on in parallel by different teams!

    Am I the only one that feels this way?
  • just create something that works through a firewall. AOL-IM works fine but ICQ dosen't even get close to working through my firewall, all their firewall config doesn't do a thing!
  • i'd really like to see public/private key encryption (and thus authentication) wrapped into the thing.

    an example of the u.i. would be that you can have "authenticated" messages be real-time, and all others go to mail...

    or, authenticated messages are "green" in color, whilst non-authenticated are "red"

    lots of possibilities...

    cool tool indeed.
    i'll need to go help out..

    me
  • "Too many chiefs, and not enough indians" - couldn't agree more ..
  • IRC is a chat protocol. ICQ and AIM are instant messaging protocols. While similar in purpose, they differ greatly in organization.

    IRC is based around the concept of rooms. You can only talk to other users inside that room, and all messages are public (by default) to the room. The IRC protocol works very well, although its restricted by its ASCII-based interface.

    A system like ICQ is based around the concept of lists of people. You can send messages to anyone on your list, and the messages and generally private to that person. Its restricted by its generally centralized and proprietary architecture and protocols.

    ICQ and AIM may do chat too now (I've only used an old ICQ client), but their specialty is one to one communication. IRC's specialty is group-based communication. Both have their own own advantages, and a good general-purpose realtime messaging system should incorporate both schemes.
  • I still don't see the need for "Instant Messaging"-software.

    If you need to see whether a person you are looking for is currently online, or not, you use finger. If you need "Instant Messaging", there's always ytalk. Chat? IRC, and so on...

    "Instant Messaging" is just a way of re-inventing the wheel for the computer illiterate.
  • I'm all for the security aspect as well. One issue you should keep in mind is the export restrictions placed on many types of security measures. It seems to me that you'd like to keep your software available to all types of users, world-wide.
  • IRC uses more bandwidth (unless you're just idling, but then it probably still uses more), and anybody can /whois you and try to hack you. With ICQ only the people on your list can get your IP address, and only if you're visible to them.

Slashdot Top Deals

"Nuclear war can ruin your whole compile." -- Karl Lehenbauer

Close