Open Letter back to Timo Sirainen's which is stored at http://www.irssi.org/projects/irc+/generic.txt » Here's my thoughts of all possible ways that I know of how to fix IRC, and » at the bottom my preffered way to fix it. Welcome to the club of the people who have ideas on how to fix IRC.. But maybe for once we can get something done! We would be very happy if you liked to join us in this long but soon victorious plan! :) We are the PSYC developers.. a new chat technology which uses a very different approach to all the networking issues involved with chat. We are still in a way IRC-compatible with our interface for IRC client users, you can try that out right-away at /server ve.symlynX.de If you haven't heard of us before is because we are only soon releasing our 0.99 version and have only recently gotten this far. First I will go through your posting on your website and add thoughts to it, partly referring to IRC and partly comparing the problems to the PSYC solutions. » Current IRC » ----------- » » Good things about IRC: » - Lots of clients, lots of users. Lots of users may not be true if compared to IM systems like ICQ or Jabber (at least they claim to have ten millions of users) Webchats also seem to be quite populated, yet their chat culture is radically different from IRC (just take a look at the number of lines written per minute) But for clients this is true and most of them are quite comfortable to use. Especially irssi.. ;)) » - Pretty easy to use, and people are used to how it works. » - As long as servers have good connections between each others (and they » usually do), all users can talk to each others fine even if direct » connection between them would be horribly slow. Direct connections are generally faster than routing through IRC networks who can cause "netlag," but generally it's not a problem - IRC routing does ok fast. Sometimes IRC routing can even help around network problems, but that's rare really. PSYC can route packets around problems, but this will probably rather be used for multicasting. routers are accepted in a web-of-trust fashion and you can still opt for getting everything directly. » Bad things: » - Listed below :) » » Netsplits » --------- » » The most annoying part of IRC is netsplits. Most of them today are probably » because of DDoSing, fixing that would make splits happen a lot less. But » how far should we go to fix that? » » One way would be to just make the netsplits more transparent, so killing » one hub wouldn't yet kill all it's downlinks. This could be done with for » example multiple connections between servers. Would this be enough? Maybe, » but there's still not that many servers that they couldn't all be DoSed if » someone really wants to. PSYC is less "interesting" for DoS since each user and channel can choose its home server and optional routers it has plenty of potential for decentralisation so that a troublemaker would first have to figure out where the stuff is he wants to make trouble to - then he would only be able to knock out a non-redundant channel or one identity of a user. Only if he first had a user's trust, then he can attack his ip directly. » Another way would be to remove the reasons for DoSsing. Usually they're » used to take over some channel, get someone's nick back, as a revenge to » some server's operator, or maybe they just do it to annoy people? Services » can be used to keep nicks and channels, and that works quite well in many » networks. Though they've still been DoSed at times and sometimes for a long » time. The concept of ownership for a specific address seems to work for mail, as you rarely hear about mailservers being DoSed (well... excluding damage by recent worms) ... same goes for channels.. since PSYC channels and nicknames are owned, at least by its server admin if not by users, knocking out a server would only cause a temporary break in communication, never a change in power. » Hub/service hiding. Seems to work quite well I think :) If there's no way » to find them, they can't DoS them. Of course, you could still DoS the » servers separately.. That sounds like an easy and interesting measure to improve IRC stability, given your plan is to apply a quick band-aid to IRC. » Peer to peer networks with hiding everyone's real IPs. I've thought of this » many times, but it's very difficult to design one that would actually work. PSYC can do something in-between.. peer-to-peer between people who *really* know and trust each other, and other communication routes through the person's home server, which then among other features also masquerades the factual ip away. » Nicks » ----- » » There's lots of people in big IRC networks, and so there's lots of nicks. » Quite often you'll find someone else trying to use your nick as well. » There's no good reason why two people who have nothing in common, never see » each other and have no common friends couldn't use the same nick. Works for mail, should work for chat as well. It gets down to being a client issue to resolve nickname conflicts (or in the case of our psyced technology this will soon be done on the "home server" side unless your native psyc client wants to be in control). » IRC networks » ------------ » » There's lots of networks, some public, some private. Finding servers for » those big networks that let you in can sometimes be difficult (ircnet » especially). Big networks have more problems and are usually more slower » and difficult to get any updates done to the network. Smaller networks » usually work better, but then again there's no people either who to talk » to. Best thing is to not have any networks at all and let just people talk to each other... ;) » There's also lots of overlapping channels in different networks. This could » be bad because it divides the people who know about the stuff. A question » asked in one network could easily be answered by someone in another » network. However, sometimes it's good that there's multiple choices to » channels, not everyone agrees how to run a channel. But they could interconnect, even if there are multiple entrance points with different policies.. » It's also a bit annoying that you can't just say "I'm xxx in IRC", you'll » also need to say the IRC network name, and that may still not be enough if » the network isn't one of the big ones. Many clients also don't handle » multiple server connections very easily and even if they do, it's still a » bit annoying to connect to some network just to talk to someone in there. You can't have "I'm xxx in IRC" if you also agree that flat nick-spaces are a problem, but what about I'm psyc://nick@myhome ? This even saves us keeping a global database for the information "messages for nick go to leaf xyz" as we have the routing information via the DNS infrastructure. » Chicken-Egg problem » ------------------- » » The reason why IRC enhancements haven't succeeded so far is because they » always create new networks, and the worst ones would require you to change » your client. Why go through all that trouble just to be in a small network » while everyone you really want to talk to is somewhere else? This » chicken-egg problem needs to be solved if there's ever going to be any » serious competitor to IRC. » » And how to solve it? You could try to get the problems to be fixed in those » big networks. Patch ircd to support multiple connections between servers » and maybe fix some other things, and then just get most servers to run that » great new server code ... As if that could ever happen. Or maybe if you » waited for years and years. For networks who are willing to move to the future you can keep IRC as a Client<->Server protocol. Users will not give up their clients. But then you replace the Interserver-Protocol. This may require some work but is much easier as this is the job of the server admins. And for the networks who are happy sticking to IRC, we have the gateways... :) » Some gateways between old and new networks might work. You'd connect to » only the gateway, and it would transparently handle the connections to old » and new networks. But who would run the gateways? Not the users, they're » too lazy to install it. Gateway admins would need to be people who are » interested about the new network, and would also allow others to use their » servers to connect to other IRC networks - quite possibly abusing them and » getting that gateway k-lined. There goes the support for old networks. » » Even with those problems, I think it might be possible to get it to work » via gateways. If there were many of them and they wouldn't let non-trusted » users connect to the older networks, they wouldn't get k-lined either. But » you'd still need to get lots of gateways and have them configured to » connect to the new network. That wouldn't be too easy either, people would » just think that they'd soon have to be reinstalling/reconfiguring anyway if » this wouldn't work, or if there was a better alternative new network or if » new versions of the gateway came out all the time or whatever.. Our IRC/PSYC gateways are currently implemented as plain IRC users, so they can of course get K-lined, but we hope that irc admins will see the fruit- fulness of the approach and upgrade us to services. Then we can provide a much better integration into the IRC syntax. From PSYCspace all the IRC networks are very comfortably reachable, the update of the gateway software happens with a simple cvs update and it is enough for one gateway to run to serve all of PSYCspace, but you can of course have more than one. http://psyc.pages.de/ircgate.en » Networks this, networks that, what if we just GET RID OF THE NETWORKS ONCE » AND FOR ALL. Do you really care who is running your network and how it's » run? Very likely not, you just want it to work. You do however want to » control your channels, and maybe filter the data that your client receives. » If everyone could run servers, everyone could be admins and control what » their clients get. If you don't like some server, go create your own. » Private messages would be sent directly to the receiver's server, for » channels there'd need to be something more complex (I already have some » ideas). Oh wow.. you're talking about PSYCspace! :°) In PSYC everyone can run his own server or use his friends' and still be an equal part of the PSYCspace. http://psyc.pages.de/intro.en Channels instead are programmable with PSYC. Routing solutions range from unicast via a "unicast to the participants servers, let them be responsible for distributing them to their users" over hybrid router things to pure multicast, should that ever become a realistic option. » If we proved that after installing this thing's server/gateway, you'd never » need to touch it again unless you wanted new features. Everyone would be » using the same "network" because it wouldn't be possible not to do so » unless you used another protocol entirely. The protocol should be as simple » as possible and easy to add extensions so it would last for a long time. If » time comes for a new protocol, it should be easy to be made backwards » compatible with this one. Please look at PSYC syntax. RFC-822-style with some optional goodies as statefulness. Looks strange, works great. http://psyc.pages.de/tech.en You know XML has this ability of being extended by adding some attributes, the PSYC syntax goes beyond by supporting the notion of inheritance. You can take any header variable or message method and make a new "variant" of it. New implementations will handle that accordingly, old implementations will simply use the semantics of the inherited function. for instance an error may look like "eafpt" (long: _error_unavailable_function_place_topic) but if the psyc client doesn't know that, it will just treat it like an "eaf" _error_unavailable_function or just simply like an _error. Yet we are not even making restrictions on the protocol clients use, As long the meaning of what they speak is 'chat'. That's why IRC, telnet, jabber, flash, java.. they're all welcome guests to us. » In short, make everyone love it, don't require any other action from users » than to connect to different server, and don't give any reasons why people » wouldn't want to move to the new server. We're working on it. /server ve.symlynX.de » Roadmap » ------- » » - Design the protocol and the core in general. Make sure people like it. » Have some ideas about what extensions will/might come and how to make » them. http://psyc.pages.de/tech.en » - Start coding the server and IRC-gateway when the protocol looks like » it won't change much. We're planning for a last big protocol messages clean-up before releasing PSYC 1.0.. but that's just an internal issue. ;) » - Put some test servers out, but give IRC-gateway access only to some » trusted users. Make sure everyone knows that it isn't finished yet » and there's no guarantees of backwards compatibility. Protocol may change as soon as we think we have a great new idea. As long as the new protocol is a superset of the old semantics backward compability is easily done by using a generic message element like NOTICE.. » - Start designing extensions, code them when finished. PSYC isn't finished yet, but you can't hold creative motivated hackers back from coding crazy things like rss feeds, jabber gateways, web interfaces, smtp, even gamespy. :)) Such stuff was done on IRC via bots, we do it directly in the "channels" as we can customize them to react on things the way that we want them to. Possible performance losses are easily compensated by using a larger number of servers, as we do not have to keep their number small). In fact if you still insist on implementing your own "bot" with a little rewrite it becomes a psyc server. It's not so hard to do. So bots are welcome on PSYC. » - Lock the core protocol, and start creating hype :) Try to get everyone » to run those servers. Most server admins would give access only to » trusted users, so they may as well enable IRC-gateway for them. We're about to lock, we haven't started the hype yet.. :) » - Now just wait for the masses to grow and keep coding the thing better » and better, but don't require anyone to upgrade unless they want some » new features. » » - Start coding native protocol support for clients to get rid of some » IRC limitations and to enable new features. » » - Everyone uses irc+ protocol enabled clients, backwards compatibility » for IRC protocol can be dropped, IRC-gateways can be dropped. IRC is » dead, long live the irc+ ;) There will always be people out there who want to add C/N-lines to their ircd.confs, but for the rest.. welcome to PSYC :) Oh now I see you have written some more at http://www.irssi.org/projects/irc+/overview.html Nice.. this all sounds like you thought about the same things as we did.. it's all applicable to PSYC.. Just some slight differences in priority.. like "locating channels," we believe it is better to promote channels by web or email or word-by-mouth.. not by some huge database. But psyc doesn't stop you from doing it your way if you want to. » Router network only makes it possible for /JOIN #irssi to work. And we also have a plan on using DNS for "well-known channels" http://psyc.pages.de/news http://psyc.pages.de/94/dns.html but we wouldn't want that to become too important as it is a position of power to own simple channel names. Better to surf for channels freely on people's homepages. Router networks imply quite an amount of trust, psyc can use router networks but i think a small solution will be preferred. In psyc every channel could say which routers it uses. But again, you can do it your way and we'll see what gets more popular. And there are even protocol ideas at http://www.irssi.org/projects/irc+/proto.txt in short, IRC+ vs PSYC: ascii: yes. parametric syntax: no, not flexible enough. tabs: yes record terminator LF: no, we allow multiline messages. escaping: avoidable by length header images, voice, video: doable with length header ERR : not as flexible as _error_tagfamily_tag_tag RPL/ERR essentially looks like PSYC families, but only two? M|ACTION: no, action is an attribute of a message, not a msg type NICK target-specific: hehe, yes, in a way STATUS: yes WHO: just like _request_examine Example: yes