Re: [Unity-irc3] Realistic review of drafts; revival of list

[Jan Krueger]

Hi.
Thanks for questions and stuff. Here goes reply.


> Most networks politics is about content and users not how channels are
> run...that's a channel operators deal, also isn't nick/channel registration
> a network politics area??
Not any longer if we move channels out of the network. Users can now choose
seperately between what kind of channels to use and what kind of network to
use. What's best: if they get fed up with their server, they can just use
another one and resume chatting with the same people.
Obvious problem here: global network bans. We need to discuss those. Do we
want them? If so, who'll be allowed to place one?


> This would need a client change would it not? Can you be sure that the
> client coders would be willing to change their programs to support this, and
> if so would it be possible for them to support both protocols with a single
> codebase?
We could support different client protocols. In fact, this would make it
easier for people to switch anyway, so I'm all for it. We could even run
proxy servers that proxy IRC clients into the network transparently.
We'll have to design different protocols in that case - our own, an IRC2
compatible and perhaps (AIM|ICQ|Jabber|MSN) compatible ones.


> Am I right in thinking that if you wanted people to connect to a channel
> you've made on your own little channel server they'd need to connect to your
> IP/hostname to be able to talk on that channel, there by making old local
> channels available but NOT part of the general server software?
Since people will be connecting to the channel server, channels will be local
and global at the same time. Local - they reside on one server. Global -
everyone can use them.
In the case of proxies mentioned above, clients won't even notice that they're
opening a separate connection to a channel since the proxy will do it for
them.
We could even make the main server software tunnel all channel traffic, but in
that case we'd waste quite some additional FDs on the server.


>> [channel politics]
> See 1st comment
I'm talking about what features channel operators get. I think that's a
politic thing as well - some of the present networks offer registrations, some
don't. Then there's Q and there's ChanServ. With the design I'm talking about
right now, clients can decide what kind of channel they want on their own
(provided there's a server that offers what they want).


>> [domains, channel domains and stuff]
> Could you expand on this a bit more as I'm not sure I understand this fully.
> (Yeah I know I'm supposed to be one of the brainer ones but sometimes ideas
> need to be explained a fair bit before people understand them :P)
Sure.
With the original Unity design, we had the ideas of domains. Every domain
contains a bunch of servers, every domain has its channels, and so on.
What is new now is that every domain contains one server only. This way, we
don't need to do any bursts at all! No bursts, no lists of users and
channels to be sync'd, no desyncs.
This is much like with e-mails - a mail domain is handled by one MX server.
Still you can easily contact people that reside on another server.
Now we can have user domains and channel domains, thus we'd have two different
kinds of servers, namely user servers and channel servers. User servers host
users while channel servers host groups/channels. Staying with the example, a
channel server could be compared with a mailing list server in the e-mail
world.
Of course, nobody says there can't be a mixed domain - we have those too in
the e-mail world, i.e. a server that provides e-mail accounts for people and
mailing lists at the same time. Nongnu.org is one of those servers.


> I can hear the cries of IRC Operators..."I can't ban this fucker from the
> network anymore!!!!!" Also how exactly would these channel servers validate
> the identity of the users connecting to them without connecting to a client
> server and requesting information from it, and if that is what it does then
> how do you get around corrupt channel server operator or maybe a comprimised
> channel server?
* That's the only drawback of the design that I can think of right now - it's
  more decentralised. Only thing we can do about global bans is setting up a
  team of people who maintain a blacklist. Corruption alert though.
  Global bans can always be bad - imagine an operator who dislikes a user and
  decides to ban him so he doesn't need to talk to them any longer...
  I think this global banning issue is worth a separate discussion.
  Another idea - everyone can run their own blacklists. Servers can then agree
  on using any of them.
* About compromised channel servers: that's a good point. Another reason why
  we should make the user's server connect to the channel server instead of
  direct connections...
  We'll have to use very good network code in that case. I can think of some
  design but I'm not sure yet whether it'll be scalable enough. In the very
  worst case, it will become a little laggy with a huge lot of servers.


> How would you stop someone from stealing your channel when you no one is
> around if there are no services?
Channel servers could provide channel ownership and stuff. Same thing as with
the basic idea of Unity - channel servers don't need services since they can
do everything themselves.


>> [network mechanism]
> This could do with more explaination too.
Perhaps we'd better move this to the -code list, what do you think?


> I really like the idea of a regional index of users online however it would
> need to take its info from some registration details (assuming people don't
> lie) or use the information from an IP block lookup but again that can be
> faked by people using a bouncer. Granted that with IPv6 it would be
> impossible (I think) to spoof/fake your OWN IP but you've still got n+1
> users on bouncers.
> Alot of this stuff still needs alot more explaination.
Sure, it can't be a true and all perfect regional index. It will just gather a
list of users on a bunch of domains that are supposed to belong to a specific
region. An index might, for example, get info about all domains that are
believed to reside in southern UK. If users want to cheat the index by using
bouncers and the like, they can. In the end, getting true information is
nearly impossible anyway.


> I know it looks like I've pulled this apart but it's what you asked to be
> done, also this way other people might better understand it :)
Sure thing. Waiting for more. :)

-- 
regards,                                 |     http://arc.pasp.de
Jan Krüger                               | ()  ascii ribbon campaign
primary mail: address@hidden | /\  - against html mail
http://www.jast.net.tc/                  |     - against microsoft attachments