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

[Jan Krueger]

Hi everyone,

I've been thinking about our stuff again. First of all, I wondered if you're
all still alive. If you are but ceased to be interested in this projects - no
problem. Just let me know; I don't want to talk to e-mail filters all the
time. ;)

Ok, here are my new ideas. Comment and questonise as much as you can.
For a start: this design is much more simple (read: easier to code ;)).

* Separation of one-to-one and one-to-many (channels)
  - by moving the responsibility for managing channels to different servers,
    we get rid of the question of domains and politics. Since most of a
    network's politics are about channels, this would be really useful.
    People could just choose where they get their account from and then
    where they get their channel from. Again, this design would require most
    of the servers to require account registrations. Of course, traditional
    IRCNet-style non-owned nicks and channels are possible as well. But
    who'd want that. ;)
  - we'd have the usual network of servers which clients can connect to. But
    in order to join a channel, they'd have to establish another connection
    to the server that runs a channel. They can then exchange all information
    via that server - including state information and stuff. No impact on the
    network any longer - everything would remain on the channel server.
  - another beauty: everyone could run their own channel server for temporary
    channels without having to register one.
  - channel politics are decided one by the channel server - it's the absolute
    authority of the channels it manages.
  - can't stress it enough ;) - no desyncs, no impact on the network when
    channels get spammed. The network itself wouldn't even have to provide
    channel servers - other providers could do that.
* Less network, more server
  - that's quite the opposite of what we thought about before. Server have
    their own domain each, registrations are only local as well.
    On a server called server1.quackweb.org, a user can register an account
    called address@hidden
    On a channel server called cs.quackweb.org, a user can register a channel
    called address@hidden (FIXME: do we still want '#'? looks ugly).
  - network-wide bans are no longer possible. I suggest a central blacklist
    that considers a user blacklisted if a certain percentage of all known
    servers have added a complaint about the user. To be decided on.
    This mechanism might also be used for badly behaving servers.
    Channel servers, however, don't need to be banned since they are passive.
    Well, mostly. Of course they have to validate the identity of users
    connecting to them and stuff.
  - here's the real beauty: Server operators don't have any noticable power
    whatsoever! Only things they can do is place a local ban/jupe, complain to
    a blacklist server, disconnect users, delete accounts. Welcome back.
  - channel server operators, however, have some more power. Anyway, since
    channel servers don't require any kind of IRC services, everyone should
    have the same rights for a full-featured channel, so the operators don't
    really have an advantage. Of course, they can badchan, unregister/close
    channels and stuff. They could even take control on a channel they don't
    own. But then again, nobody would use a channel server with corrupted
    opers, would they? ;)
  - here's an idea about the network mechanism. To keep the routing algorithm
    simple (read: avoid writing one at all), how about directly connecting to
    remote servers? We could reserve a couple of FDs to connecting to other
    servers, then keeping connections open after sending something to another
    server. When we get an overflow, throw out the less-used connection and
    connect to the new server instead.
    Obvious advantages: no routing algorithm needed (i.e. routing mechanisms
    of The Internet are used), should still be pretty fast.
  - now it's scalable like hell. Everything can be torn apart without any
    problems. Just add a server here and another one there and we have
    sufficient capacity again.
  - again, we'd want to make it easy for people to contribute a server.
    I hear the SAuth ringing. ;)
* Obvious changes
  - no network-wide index of people online. It's no problem to list other
    users within the same domain, but it's just impossible to do that for
    the entire network. What do we do?
    We add some kind of directory server.
    We add an ICQ-style notify list.
    We could even add a regional index of people that's updated automatically,
       i.e. a Really Useful directory of people that live in the same region
       as the one who asks for info. This would require one directory server
       per region, obviously.
    Note that directories are some kind of luxury. People can spread their
    personal chat address (why not URL style?
    greatchat://server.domain.org:port/username - or e-mail style?
    address@hidden:port) in whatever way they want.
    Let the WWW be our directory. Saves us a lot of trouble. ;)
  - same for index of channels. Every channel server could supply a detailed
    description of the channels registered with it, however. Their choice,
    not ours.
* Benefits for users
  - they can choose a domain (remember, domains are l33t)
  - they can register an account
  - it'll be easy for them to remember the server to connect to since it will
    be the same as the domain part of their chat ID
  - they can register channels with different domains
  - they have full control over their channels (we could even build a nice web
    interface into the channel server software)
  - they can provide their own channel server without having to run their own
    network (expansion!).
  - people can still decide whether they want registrations or not (servers
    that don't support/allow registration should tell the other servers so
    users (and channel servers) don't get confused if the person behind an
    ID changes).


Questions? Suggestions? Flames? Eager to hear whatever you can come up with.
And now:
__      __    _                   _
\ \    / /_ _| |_____   _  _ _ __| |
 \ \/\/ / _` | / / -_) | || | '_ \_|
  \_/\_/\__,_|_\_\___|  \_,_| .__( )  ;)
                            |_|
--
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