The child protocol of IRC protocol

Question

We're all so used to the IRC, maybe using BitchX if our favourite OS is UNIX based, or mIRC if we prefer the MS solution. We've all been chatting using under this protocol for quite some time. Actually, this year is IRC's 10th aniversary (or actually it was, in May, according to RFC1459). But my question to you is: haven't you ever felt that sometimes communicating through simple text just isn't enough??? Sure, maybe we can use Yahoo! messanger and add some voice to it... But why the need for registration? The question that drives many of us forward is: Why not? Yes, why not make it better? Why not add some more fun to it... Alright, maybe it's not always related to fun but... you get the idea. I know, I know, I've been mumbling around here without actually saying what I want. So, the idea is, why not add some more fun to IRC protocol. Let's say a protocol was creating with IRC in mind, but without limitating it to text. Audio and video streaming does sound nice, doesn't it? So add 'em to the shopping cart. Add some more security around there since by now we all now the "exploits" which can be used to play around with some new person joining the IRC community for the first time. Maybe add some more speed, by simplifying the protocol a little: we all hate those net splits because of which we can no longer talk to our friend since (s)he's on another server... The net split is a great idea, but on big IRC networks it is far too common. Add some other nice capabilities, which many users just love (customizable environments in channels, add an icon next to a user which might describe him/her better bla bla bla - these little things which may sound silly but I'm telling ya that many love 'em). Ya, not much I could think of for now, but I really hope some other ideas will come to me and others. So back to the original question: Is it a nice idea, nice enough to think about spending time elaborating a protocol and building an application on it, or did I just drink to much beer??? Your opinion would be really appreciated: tell me that I'm an idiot, a complete loser, or whatever you wish; bring me back to Earth, or lift me higher in the sky (damn... I really did have to much beer...).

Answer 1

I think that making it backwards compatible is not desirable. If
you need to serve older clients create a module for your server to
talk to just them. With a little consideration as to how your new
protocol works it should be easy enough to strip the aduio/video/pretty
features from the streams and forward text only.
Also make sure you keep it extensible (ie arbirary data-types
can be used). If you do this it should not be too difficult to add
features such as information requests (who can recieve audio/video data
what quality. is it streamed or a mail drop type delivery), pictures, video, vector animations etc.
And ensure that all data transfered can easily and efficiently be stripped/filtered by the server and clients. If so your server could
perhaps start dropping extra information when under load rather then
splitting groups. Or split rather then drop extra info (depends on what
you want I suppose)
A final useful feature to include would be some method of allowing
data for multiple users on a proxied domain to be forwarded just once.
This could allow people to set up their own proxy type servers to handle their local domain with minimal external traffic
some rather incoherent random thoughts
matfud