ICB logfile, 2.18.95

<acet> multiple servers.
<ick> acet: but what if i want to use silber.ipst.edu and you wnat to use crater
<acet> the clients and group managers register their groups with
<acet> multiple servers. 
<ick> but isn't that a hassle for users?
<acet> then I wont' see you unless I look on sliver. 
<acet> nah, could select which servers to subscribe to much like
<acet> selecting threads in a threaded newsreader
<synk> server subscription.. Hmmmmm
<ick> yeah... ok... i get it.... great idea!
<ick> the servers can have a list of other servers too, and f you want to start a ser
<ick> ver, you can also register your server with other  servers
<acet> danke
<synk> acet: could be subscribed to silver and crater at the same
<synk> time?
<acet> synk: yes
<synk> woo that works
<ick> synk: you  could be subscribed to all servers 
<acet> ick: yea, I guess... but that could cause problem.s
[=Change=] Suzanne (suzdev@carina.unm.edu) entered group [NR]
<synk> hola
<ick> helu
<acet> could have servers maintin lists of other known servers as a
<acet> convienence to clients if you want
<synk> what's new suz?               
<Suzanne> nothing
<Suzanne> absolutely nothing
<acet> lo suz
<Suzanne> loacet
<synk> suz: want to go to cruces :-)
<Suzanne> okay
<synk> ok.. I leave tomorrow
<ick> synk: when you coming back?
<Suzanne> when wwill  you be back?
<synk> sometime monday night
<ick> no school on monday?
<synk> you have class monday don't you?
<Suzanne> great minds think alike
<ick> :]

<ick> I like Ike.
<synk> smile... jesus saves souls... and redemes them for valueable
<synk> cash prizes
<Suzanne> no smiling suicks
<ick> smiles cause wrinkles  
<Suzanne> no typing sucks too
<synk> so do anvils
[=Change=] acet (matth@emmy.nmsu.edu) just left
<Suzanne> zzzzzzzzzzzz
[=Change=] Suzanne (suzdev@carina.unm.edu) just left
<synk> [=Status=] suzanne has just had an anvil fall on 'em.
<ick> synk: i dont think your document is specific enough
<synk> ick: you read all the way through?
[=RSVP=] acet invited you to group sd       (ril)
<ick> /g sd
[=Change=] synk (synk@thelair.zynet.com) just left
[=Status=] You are now in group sd      
<ick> /w .
<ick>  
Group: sd       (ril) Mod: acet          Topic: (None)                        
   Nickname        Idle  Sign-On  Account
  *acet              -    4:10pm  matth@emmy.nmsu.edu       
   synk              -    5:02pm  synk@thelair.zynet.com       
   ick               -    4:47pm  nirva@caffeine.zynet.com   (nr)
<acet> lo
<ick> helu
<synk> "sleep deprivation"  my vote for name of the chat proggy
[=Topic=] acet changed the topic to "RFC in progress?"
<synk> ok talk talk
<acet> heh
<acet> thoughts are still really soupy on this idea... random
<acet> spurtings... ok, brief description of model: MatchMaker...
<acet> servers keep track of clients meeting each other.
<acet> tunachat... hrm
[=Group=] Group name changed to tunachat
<ick> hehe
<ick> liek anyone can see it :]
<ick> /w .
<ick>  
Group: tunachat (ril) Mod: acet          Topic: RFC in progress?              
   Nickname        Idle  Sign-On  Account
  *acet              -    4:10pm  matth@emmy.nmsu.edu       
   synk             1m    5:02pm  synk@thelair.zynet.com       
   ick               -    4:47pm  nirva@caffeine.zynet.com   (nr)
<acet> clients manage the groups their users moderate. 
<*synk*> it has examples for everything it talks about.. your chat
<*synk*> program is practically written in the doc
<ick> parse error on last acet line
<synk> so clients are also servers?
<acet> once somebody subscribes to a group, they are talking on a
<acet> direct link with that group... the main Process(better name
<acet> needed) server can crash and the group will not be affected in
<acet> the slighest
<acet> synk: yes, but only for the groups they are responsible.
<ick> acet: dumb server
<acet> ick: kinda
<ick> acet: or dead server... and clients are alive 
<synk> ok so right now, emmy would be running the server for the
<synk> group tunachat
<acet> synk: exactly
<ick> ahhhhh
<ick> makes sense
<synk> keen
<ick> if i pass moderation... does the server change?
<synk> how does main server keep track of groups?
<acet> and, if you tried to join tunachat... you would have to go
<acet> through the Process server (better name anybody?) I'm
<acet> registered to, and request for the information your client
<acet> will need to connect (i.e. address and port 
<acet> address... possibly a session "password" for that one
<acet> connection).
<acet> synk: that's the responsibility of the clients... to register
<acet> their groups with servers so other people can see thm.
<acet> ick: hrm, very good question
<ick> lets say i wanwted to create a new group now... how would i do it?
<ick> would i have to ask emmy, or crater?
<synk> would inivisible groups make themselves known to servers?
<ick> synk: yes
<ick> synk: so they can send broadcast messages
<acet> also I've been wondering about the irc mechanism for multiple
<acet> operators of a group... was thining of maybe a hierarchial
<acet> system where there is a "main" manager of the group (runs the
<acet> group on his machine) and possibly a 
<acet> designated rank of alternates that the group will go to if,
<acet> for some reason, the manager is unable or unwilling to
<acet> maintain the group. ;-)
<synk> how many "group servers" (I like better than process) would
<synk> there be?
<acet> synk: yes, but they would ask the server not to casually list
<acet> their groups to other clients...
<ick> as many as you can get to use our chat program
<acet> synk: as many as you want. Can be group servers for general
<acet> topics even... say, the Linux server... or the Frisbee server
<synk> would the load on the group server be bad enough taht there
<synk> would need to be two?
<ick> sure... too many people in and out would bog it down
<ick> also.. bad connections from germany to new mexico coudl be a cause for another 
<ick> group server to come up in germany
<acet> people can specify addresses for their groups verbally much
<acet> like host.domain names currently are... "connect to
<acet> Linux.kernel.scheduler" or something... maybe meaning connect
<acet> to the linux server to find out how to 
<acet> connect to the kernel server to find out how to connect to the
<acet> scheduler group (mini-server)
<acet> synk: sure, multiple servers is strongly encouraged.
<synk> Hmmm
<acet> secure communications could be handled on a client-to-client
<acet> basis. Perhaps protocol negotiation handled through
<acet> commuications from the group manager to the client via the
<acet> server... (i.e. "use encrypted packets, here is 
<acet> your key)
<synk> ick and I discussed a way of client-to-client private messages
<ick> synk: its exactly (but alittle better) like your method
<synk> first client sends server a magic number, the server sends the
<synk> second client the magic number and who sent it
<acet> client-client private messages would simply be sent out one
<acet> socket instead of broadcasted to all connected sockets
<acet> (connected to the group)
<synk> first client then sends a direct packet to second client,
<synk> which includes a magic number and who it claims to be from
<synk> second client then compares magic numbers and usernames.. if
<synk> they match, it came from who it said it was from (assuming the
<synk> group server is honest)
<acet> possibly.. or some servers could force clients to prove their
<acet> identity (public key?) when they connect or try to register a
<acet> group... 
<acet> The equivalent to NickServ on IRC would be based at the group
<acet> server. Someone connected to a Honest Server can assume that
<acet> the server will vouch for the identity of everybody else
<acet> registered.
<acet> hello?
<ick> hello...
<ick> thinking..... reading.... making sense of how to implement it
<synk> lo
<synk> processing
<acet> <- going to get a drink... (take a breather in the ideas)...
<acet> say so when ready to start up again.
<ick> /m synk we should have had him this morning...
<*synk*> yes
<synk> Will there be something like /write?
<acet> hahahah... I have to write a 4-6 page concept paper for
<acet> english today, and is the reason I logged on in the first
<acet> place... all week I have been stumped for a concept and, now
<acet> all of a sudden, I have a very good one that 
<acet> would work perfectyl.
<acet> synk: email?
<ick> synk: but what about those who dont have mail
<synk> acet: ok, no /write command then.  what will need to be
<synk> stored?
<synk> ick: me?
<acet> synk: be more specific... what will the clients need to keep
<acet> track of? process servers?
<synk> will nicknames need to be registered?
<ick> YES!
<ick> or actually,they can be
<synk> why register nicknames if there's no /write?
<acet> ick: almost anybody has e-mail. Maybe you can register an
<acet> email address with the Group Server... if you don't have email
<acet> capability, then you don't get /writes
<ick> acet: true..... ok
<synk> I don't believe the group server is the place for data to be
<synk> stored...
<ick> where else?
<synk> ... huge files could start popping up unexpectedly
<ick> synk: you just have info like icb
<acet> synk: assuming that user registration is handled by the Group
<acet> server (this is not manditory, optional only... but probably
<acet> required for the support of the /write function), the Group
<acet> Server can handle sending out /write 
<acet> messages to otehr users assuming they know of a way to do it
<acet> (i.e. email, or some other transport mechanism)
<acet> synk: I don't understand? what would be so huge?
<ick> and also... why cant the group server hold /write messages?
<synk> acet: large group database?  I'd rather not have them popping
<synk> up on my hd, much less everybody else's whose group I enter
<ick> ok.. how about having the group server holding all the databases, and having al
<ick> l nickname changes be authenticated by the group server 
<acet> synk: !?!?! woah.. I don't understand why you think that will
<acet> happen... 
<synk> perhaps there should be a trusted authentication server?
<acet> synk: that's a possibility... and also a possible
<acet> responsibility of the Group Server
<synk> acet: wait, is the group server that which keeps track of all
<synk> the groups, or what which is a group and handles clients?
<acet> synk: the Group Server handles only the groups that have been
<acet> registered to it by the clients... the clients are responsible
<acet> for the bookkeeping and communications required to handle the
<acet> groups themselves. One would 
<acet> connect to a group server primarily to find out which groups
<acet> are available
<acet> (the authentication and other things are possible secondary
<acet> functions of the group server)... 
<synk> ok.. was thinking group server was the server run by the
<synk> moderator of the group
<acet> synk: nonono...
<ick> how would /nick be handled?
<ick> who would authenticate the the name change?
<acet> ick: you could register your nickname along with any other
<acet> information with the Group Server... if that function is
<acet> supported.
<synk> how does group server tell client "this nick is ok"?
<acet> ick: if you try and change the name other people in a group
<acet> see you as, then you will have to take that up with the group
<acet> manager... 
<ick> then will the group moderator check iwth the group server?
<acet> *pain*... ugh, this idea is going in many different directions
<acet>  at once... most of what we're talking about is optional
<synk> lettuce code basic idea?
<synk> acet: how do you handle net breakdowns?  what if nmsu.edu
<synk> suddenly dies off?
<acet> or design it at least... the basic idea should be easily
<acet> extendable.. and I think that the many directions this idea
<acet> has already take is a good indication that it is.
<acet> synk: then, unless there is a mechanism for somebody else to
<acet> take up management (i.e. vice-manager), this group will
<acet> dissolve
<synk> maybe handle moderator logoffs like crater?  pass the buck?
<acet> synk: but, say if I named you as the vice-manager, and
<acet> everybody else in the group knew you were my desginated
<acet> vice-manager, if everybody looses connection with me, then
<acet> they can all try connecting to you and attempt to 
<acet> resume the group 
<synk> perhaps moderator should be able to designate who runs the
<synk> server?
<acet> I see two main protocols that need to be defined... one is the
<acet> communications with the Group server: registering groups,
<acet> getting a list of groups, and any optional features like
<acet> nickname registration and so on. The 
<acet> other is the client-to-group communcations... which can also
<acet> be more elaborate than just sending and receiving "voice"
<acet> packets
<acet> *segmentation fault*... blew my mind with that idea, synk..
<acet> !grok
<synk> there's also the problem of what if there's 3 clusters of
<synk> people in a group, and each is far away from each other. 
<synk> should each have a mini server which talk to other cluster
<synk> servers?
<ick> chatnet :]
<acet> *pain pain pain*... methinks there is a misinterpretation
<synk> person who runs group might be nirva, who is downloading
<synk> descent with ppp.. clearly, the nirva server is going to be
<synk> slow
<acet> if, say, only 5 people are in nirva's group... that's not
<acet> going to take much bandwidth really
<ick> and if it gets too slow... tell me to change moderation and server control to a
<ick>  faster connection
<synk> it won't take much bandwidth, but it will be slow despite
<synk> that.  I deal with 5 second lag at times when downloading. 
<synk> that'd make for a poor server
<ick> synk: really? i only get like 1-3 second lags
<acet> In nirva's group... nirva's little server will be responsible
<acet> for making sure that everybody else that is connected to his
<acet> group sees what other people say... 
<acet> synk: what ick said
<synk> ick: wouldn't you like to keep moderation of teh group though?
<synk>  what if phydeaux was on a fast machine and everybody else was
<synk> on a slow one?
<ick> then we live with slowness and make phydeaux suffer :P
<acet> if performance in a group is slow, that's the responsibility
<acet> of the manager
<synk> if the manager has responsibility, shouldn't he also have
<synk> ability?
<acet> synk: could give vice-managers authority to change the stats
<acet> of the group... but each change would have to be authorized by
<acet> the main-manager.
<synk> perhaps an agreement between moderator and client server
<synk> member... mod offers user rights to be server, user can accept
<synk> or deny offer
<ick> or how about being able to split moderation and server control?
<acet> synk: yes, manager could pass the server responsibilites over
<acet> to someone else and assume the role of vice-manager. The only
<acet> difference between managers and vice-managers is who runs the
<acet> server for the group (there could 
<acet> be other differences)
<acet> no split!
<ick> why not?
<synk> why no split?
<ick> why cant i still be mod and we all suck up phydeaux's resources?
<synk> ick: isn't that what I propposed a few pages up?
<acet> split moderation type powers... that's no problem... but split
<acet> the server duties and you introduce massive race conditions
<acet> and so on... very bad
<ick> not server duties... but moderation of group and server duties...
<acet> ick: yea,that's fine. That's what I've been saying. 
<synk> split server duties? no! just pass server duties
<acet> ick: but everybody still connects to phydeaux.... no having,
<acet> say, 4 people connecting to synk, 2 to me, and 4 to phydeaux
<acet> and having them all appear in the same group... very bad
<acet> synk: right
<ick> acet: no! not like that... the moderator of group and server of group will be t
<ick> wo different things
<acet> all of this is not a problem, the way I see it. i've already
<acet> thought of reasonable mechanisms for handling this
<synk> acet: the splitting of server was just an asside.. I've been
<synk> talking about passing server duties
<ick> servers should be anyone in the group
<acet> synk: yea... methinks that will be easy
<synk> the person should have the option to not accept becoming
<synk> server
<ick> yeah
<acet> <- writing text file in hopes of crystalizing some ideas
<acet> before I forget them.
<ick> good idea
<acet> synk: yea, that ability would be already inherent in the
<acet> design... 
<synk> brb.. I should be on admin line
[=Sign-off=] synk (synk@thelair.zynet.com) just signed off
[=Sign-on=] synk (synk@thelair.zynet.com) just joined
<synk> ok
<ick> /w .
<acet> Guh, must define more vocabulary
<ick>  
Group: tunachat (ril) Mod: acet          Topic: RFC in progress?              
   Nickname        Idle  Sign-On  Account
  *acet              -    4:10pm  matth@emmy.nmsu.edu       
   ick               -    4:47pm  nirva@caffeine.zynet.com   (nr)
   synk              -    6:19pm  synk@thelair.zynet.com       
<synk> I miss anything?
<ick> nope
<acet> no... writing text file.
<ick> write C program
<ick> writing...
<ick> brb  
<ick> helu
<synk> helu
<acet> right now we use "Group Server" to specify the server which
<acet> people go register themselves and groups too... methinks Group
<acet> Server would be better name for the little mini-server run by
<acet> the manager of a group... any 
<acet> better names for what we currently call "Group Server"?
<ick> tuna server
<acet> ugh, too confusing (amusing, but confusing)
<ick> if it is tuna chat, then they would be main servers (tuna servers :)
<synk> List Server?  Authentication Server?  OverServer?
<acet> Authentication Server kinda fits it best methinks... slightly
<acet> misleading in one way or another, but will work for now. 
<acet> so.. Group Server == little server run by manager of a group
<acet> that clients who want to join that group must connect to.
<acet> Authentication Server == big brother server thingy.
<synk> Or Group Server and Client Server?
<synk> makes sense
<synk> not misleading
<ick> tastes great
<synk> (as)
<acet> Client Server? heh, paradoxial... I like... ok
<ick> less filling
<synk> :-)
<synk> low sodium
<ick> high salt!
<acet> Client Server = mini-server... Group Server = big-brother
<acet> server.
<ick> yeah!
<synk> jah
<synk> less sodium, more chlorine!
<acet> heh
<synk> authentication can come later
<acet> yea, it's optional
<ick> just like in icb
<acet> (an extension)
<acet> yup
<acet> anybody thinking that this idea may not be the Right Thing?
<acet> curious... 
<ick> i like it  
<synk> it's a good thing.. won't be the right thing until it's "the
<synk> chat program" or something of the sort :-)
<acet> wanna develop it?
<acet> full-scale develop it type thingy?
<ick> acet: tuna chat? or the chat?
<synk> sd! sd!
<acet> tunachat thingy... what we've been desigining
<ick> yeah!
<acet> why sd?
<ick> i dont like sd
<synk> because sd will cause us and its users much sd
<acet> what is sd?
<synk> sleep deprivation
<acet> ah, sleep deprivation?
<acet> :-)
<acet> hrm, Official Name to be resolved later... ;)
<ick> yeah
<ick> will just call main program main.c and the output file can be a.out
<synk> tc is a registered trademark of borland :-)
<ick> synk: it is not!
<synk> ok, it's an impilied trademark of borland :-P
<ick> not really... no one but us know of it as tc, every body calls it Turbo C, or T
<ick> urbo C++
<synk> unregistered
<acet> typing all special names for this design in ALLCAPS... 
<synk> you are quickly disolving comic value
<ick> i know... :]
<acet> (for text file... allows for easy search-replacements)
<synk> tunachat, if good enough, will cause civil war you see,
<synk> whereas sd will not
<ick> what kind of civil war?
<synk> mobs of angry liberal freaks will scream that it is sexist and
<synk> demand it be removed.  meanwhile, kitiara and such folks will
<synk> buy sniper rifles and head for the mountain... the rest is in
<synk> a movie called "wolverine"
<acet> heh
<ick> sexist?
<ick> :]
<acet> (I don't suppose anybody in here has all of the previous
<acet> conversation in scrollback do they? If so, mind sending me a
<acet> raw copy of it?)
<synk> try /d
<acet> will /d get it al?
<acet> all?
<ick> i got almost all... since : "can we connect to silver.ipst.edu and crater.unm.e
<ick> du at the sma eitme?:
<synk> maybe
<synk> depends on your history size
<synk> I acn't do it since I logged on and off
<acet> ok, done. Everything is being appended to the log file.
<synk> ok so tunachat client contacts group server, it then either
<synk> asks if it can create a group or for what groups are
<synk> available?
<ick> hold on.. dont type i am copying from scroll back
<acet> <- trying to dump ideas to text file... which is a difficult
<acet> and painfully slow process (can't type fast enough to dump
<acet> brain contents)
<synk> need one of those brainwave readers
<acet> definatly
<synk> I can't gosh I'd like a tuna sandwich type fast enough lemon
<synk> curry? to get it all down
<ick> i had it all... since we started in m0o