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

[David Westley]

>
>
>Hi.
>Thanks for questions and stuff. Here goes reply.
and now for even more rebuttal :)
>
>
>> 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?
Let me see if I understand this...

uk.quakenet.org (a quakenet client server) <---> uk.undernet.org (an
undernet client server)
                                             |
                                             |
                           uk.channels.irc.net (uk channel server)

A user could be on uk.quakenet.org and join #channel_1 on
uk.channels.irc.net and another user could be on uk.undernet.org and also
join #channel_1 on uk.channels.irc.net and they would both be on the same
channel, however, if the user on uk.undernet.org didn't like the politics of
undernet or were banned from the UK undernet server they could move to
uk.quakenet.org and still be on the same channel yeah? That way each network
would have their own politics and rules about users etc.. but channels would
be on a non-politically controlled server? ...... If this is the case then
the channel servers would either have to have no controllers (operators)
which would mean anarchy OR decisions would have to be made by a kinda
committee so that political/religious views don't taint decisions. (I hate
politics!)

As to intra-network bans....I'd say that they would be a very very bad idea.
People would be stepping on other peoples toes and I can see major fights
breaking out!

>
>
>> 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.
This point really needs to be thrashed out alot...maybe once we have a
protocol standard kinda sorted out it might be an idea to approach some of
the current client coders to see if A) they would be willing to change their
codebase and B) if it would be possible for them to support multiple
protocols easily.

>
>
>> 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.
Saying that a channel is local because it resides on a single server isn't
what I'd class as a local channel... local to me would be like the old irc2
local channels, you join it and it only exists on THAT server...so if
general users could run up their own channel server then you could have
#my_private_channel on my.private.channel.server.net but that would need
users to have either a reverse lookup (which not everyone will/can have) or
connect via IP.

on a side note, how does "/join address@hidden" grab
anyone as a way to join channels? and yes if you wanted you could get rid of
the # sign to make it look more like an email address ;)

>
>
>>> [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).
So individual networks could run their own channel servers with
services/registrations of their choice and independent people could run
their own channel servers with their own features yeah?

>
>
>>> [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 brainier 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.
Okay! So we could have DALNet with just client servers with its users using
someone elses channel servers and Quakenet with its own channel servers as
well as client servers yeah? (BTW mail domains can have multiple MX records
which have a priority number and are used in a fashion similar to DNS
round-robin so you could have 5 mail servers for a single domain) :)

>
>
>> 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.
I have an idea about this but it's very.....political! At the end of the day
this is more a network politics issue rather than a protocol design issue.

>* 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.
I agree...this is one aspect that will need an awful lot of discussion and
design work.

>
>
>> 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?
Yeah if you think it'd be better on that list.

>
>
>> 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 explanation.
>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.
>
Personally if this regional index was to be of any use it would have to
contain true information otherwise it's about as useful as /whois and it
would just be a duplicate and waste don't you think unless I've got the
point of this regional index totally wrong? (which is entirely possible!)


Another long ass mail brought to you by your friendly neighbourhood Penguin
;)