Acking Log
ICB log 3.11.95
Nirva == Ick
<ick> /m acet helu
<ick> /m acet i have questions about your tunachat documentation
<*acet*> hola
[=Change=] acet (matth@emmy.nmsu.edu) entered group
<acet> boing
<ick> helu
<acet> shoot
<ick> in your doc, you said that you would have to talk to the client to get info for
<ick> /w @synk, no the group server because the group server should not know about t
<ick> he groups that the client is connected to
<acet> right
<ick> if you do a /w, the group server returns info about all the users in all the gr
<ick> oups it knows about
<acet> nope
<ick> how does /w owrk?
<acet> group server doesn't know what groups people are in.
<acet> /w can return information about all the registered groups..
<acet> or all the registered users who are considered "online" as far
<acet> as the server is concerned (ie, they send pings to it)
<acet> those two functions should probably be split into seperate
<acet> commands though
<ick> ick! that would be a ton of pings!
<ick> i thought the group server would know about all elements of groups, users in th
<ick> em being one of the elements (that does not mean that we can not have users who
<ick> go into groups without telling the group server)
<acet> boink?
[=Change=] Flac (falcon@198.59.146.69) entered group [NR]
<Flac> Hey
<acet> a ping every 90 seconds? 5 minutes maybe?
<ick> helu
<ick> flac: not gotton dns to work yet?
<acet> any request or communications to the group server would also
<acet> be counted as a 'ping'... just something to let the server
<acet> know who's still connected and who isn't
<Flac> DNS works fine... it's the US doamin people that are slow.
<ick> hehe
<ick> acet: if we have the group server know about users, i see nothing wrong iwth th
<ick> at... can you explain why you would rather it not be that way?
<Flac> TVI is just fine, it's internic problem.
<acet> group server can tell client how to find out who is in a
<acet> group... from the user's point of view, it would still be
<acet> transparent actually.
<ick> but if the group server always knows about all users, then /m 's will not have
<ick> to go through client servers at all, and /w would be easier to do
<acet> ick: it would know about users... it wouldn't know who is
<acet> connected to which groups though. Why? It has no reason
<acet> knowing that... and if it tried to maintain an accurate
<acet> database it would have to poll the various groups
<ick> nono, no polling needed if the client servers notify the group server about log
<ick> offs
<ick> and the group server can ping client servers every hour to see if they are dead
<ick> (just like idling xentrac)
<ick> /w @xentrac
Group: xentrac (mvl) Mod: xentrac Topic: (None)
Nickname Idle Sign-On Account
*xentrac 18m 4:38pm xentrac@altona.math.unm.edu (nr)
<ick> (xentrac has a bot or something to keep him to not idle forever, he is in ohio
<ick> right now, without computer)
<Flac> But what if it's not a "clean" logout?
<Flac> or is the clients dies.
<acet> ick: ok, compromise: still do it my way, the group server
<acet> doesn't know about who is in a group.. but add the option for
<acet> a registered client server to set a text file that will be
<acet> seen when people see the group in /w
<acet> lists... if the client server wants the list of people in a
<acet> group to show on /w listings, it can set that field and
<acet> maintain it itself.
<ick> hmmmm
<ick> flac: dead client-server problem has been fixed
<ick> flac: i will send you my doc as soon as iadd this little deal
<ick> acet: why not just let the group-server know about all users that do not stop i
<ick> t
<acet> ick: you forget that the group server has no guaranteed way of
<acet> knowing as people connect or leave a group... a group can be
<acet> registered on multiple group servers, another group server can
<acet> handle the login and logout and
<acet> the original grou p server wouldn't see it.
<ick> acet: but all interactions on one group server would be told to other groupserv
<ick> ers
<acet> "all users that do not stop it"?
<ick> if i login, i want it konw, but i i login and dont want it to know, i tell the
<ick> client-server to whom i connect, not to send the info to the group-server
<ick> (i act as an invisible-user to that clientserver)
<ick> when i log out, client notifies the group server, when i login to client server
<ick> (unless told not to) it also notifies groupserver
<Flac> Sounds to easy to hack
<acet> ick: ugh, I don't like that... having all the group servers
<acet> talking to each other defeats the purpose of having them
<acet> isolated entities
<ick> acet: i forgot that... oops... throw away my idea... *slap myself*
<acet> ick: you could let users tell the group server what groups
<acet> they belong to
<ick> acet: ok.. so when i do /w, what would exactly happen
<acet> ick: the user would get a list of registered groups. By each
<acet> group, the user would also see an optional text field set by
<acet> the client server of that group... that text file could be
<acet> configured to have a list of current
<acet> users.
<ick> acet: ok, adn how would client-servers setup the file
<ick> acet: also, then how would /m work? (to get recipient's name?)
<acet> ick: in human readable format. It would be a simple text
<acet> field... could have anything in it, could have a list of
<acet> users, could have "This space for rent", could have a bitmap
<acet> of an icon for the group (if this ever goes
<acet> into multimedia type things :)
<ick> nono, thats not what i meant, i meant; where would the file be held (group serv
<ick> er or clientserver that it belongs to)
<acet> eh? not sure what you mean "to get recipient's name"... isn't
<acet> recipients name supplied as second argument to /m command?
<ick> acet: i meant address, not name
<acet> ick: would be held by group server... probably held in memory
<acet> (size limits would most likely be needed). The client server
<acet> would tell the group server when to change it and what to
<acet> change it with.
<acet> ick: /m qwibble would work by asking the group server (that
<acet> command would be directed at a specified group server) for
<acet> info on how to send a message to qwibble... qwibble would give
<acet> the group server that information
<acet> when he registers.
<ick> acet: ok.. but when qwibble loggs out uncleany, how to find out?
<ick> acet: how would the groupserver know qwibble is gone
<ick> He's dead, Jim. I'll get his wallet, you grab the tricorder.
<acet> ick: group server would notice qwibble's absence when it
<acet> doesn't recieve any transmissions or pings from qwibble after
<acet> a period of time.
<ick> acet: what if qwibble decides to just talk within his own group for 6 hours
<ick> acet: without ever talking to groupserver
<acet> actually, would probably be better to let the group server
<acet> ping clients instead of requiring the clients to ping the
<acet> group server.... that way the group server can make sure the
<acet> client is connected when answering a /m
<acet> request.
<Flac> brb
[=Sign-off=] Flac (falcon@198.59.146.69) just signed off
<ick> acet: ugh... slow slow... imagine 1000 pings!
<acet> ick: then nobody will be able to use a group server to send a
<acet> message to him.
<ick> acet: that is bad... sometimes i go for hours wihtout /w or /m, but i still wan
<ick> t messages
<acet> ick: ok ok... have group server ping clients *only* when it
<acet> needs to know they are there..
<acet> ick: then register with a group server.
<ick> acet: i will register... but i will not tlak to the group-server for 6 hours...
<ick> the next day, i will also resgister, but i will hang up phone line after 3 hou
<ick> rs
<ick> i still do not understand why group server kows not of who is in the groups, ex
<ick> plain that again... its just not sticking to my teflon brain :)
<acet> ick: hrm, waitaminute... *recompiling idea with concept of
<acet> having group server pinging clients only when it needs to know
<ick> acet> they are there*
<ick> waiting.............
<ick> .
<ick> .
<ick> .
<ick> /w .
Group: ishiboo (mvl) Mod: ick Topic: DontPutURHandWhereUWantURFace
Nickname Idle Sign-On Account
*ick - 4:48pm nirva@caffeine.zynet.com
acet - 4:44pm matth@emmy.nmsu.edu
<acet> ick: because group server should not have to care... group
<acet> server is merely a place for people to advertise groups and
<acet> their own existance, right?
<acet> afk
<ick> yeah... but groups have properties, such as users in them
<ick> also, there is a given option of withholding info from groupserver, but IMO it
<ick> makes life much easier to let group server know about users
<ick> the client servers can be smart enough to keep the group server updated correct
<ick> ly
<ick> with group-servers knowing about users, it is only one transmission to get user
<ick> name, of one, two, or all users
<ick> but that includes only the users that did not withhold info
<ick> by default, i should be able to say that I am a part of ishiboo and m0o and gua
<ick> camol, buti should also be able to say that i will be a part of helu, wihtout e
<ick> veryone knowing about it
<ick> this way... group server knows about everyone that let it know, and doesn't knw
<ick> o about users that do not want to be known
<ick> the great thing is that they can still talk to groupservers without the groupse
<ick> rver ever putting them into the log of total users
<ick> /d 10
<ick> Nickname Idle Sign-On Account
[=Replaying last 10 messages=]
<acet> their own existance, right?
<acet> afk
<ick> yeah... but groups have properties, such as users in them
<ick> also, there is a given option of withholding info from groupserver, but IMO it makes life much easier to let group server know about users
<ick> the client servers can be smart enough to keep the group server updated correctly
<ick> with group-servers knowing about users, it is only one transmission to get username, of one, two, or all users
<ick> but that includes only the users that did not withhold info
<ick> by default, i should be able to say that I am a part of ishiboo and m0o and guacamol, buti should also be able to say that i will be a part of helu, wihtout everyone knowing about it
<ick> this way... group server knows about everyone that let it know, and doesn't knwo about users that do not want to be known
<ick> the great thing is that they can still talk to groupservers without the groupserver ever putting them into the log of total users
[=End of review buffer=]
<acet> unga bunga! (back,btw)... got shifted philosophy for
<acet> groupservers... and I kinda like it because it makes lots of
<acet> things simpler.
<ick> which way do you like? this way? or other way?
<acet> want to hear? (not sure it's airtight.. could use feedback)
<ick> sure.. gimmei new idea
<acet> new philosophy supports what you were saying
<ick> sorry about going on an on while you were gone :]
<acet> new philosophy: groupservers are passive databases. They are
<acet> places for clients and groups to deposit information about
<acet> themselves and places for clients and groups to query for
<acet> information about others. *Thats IT*
<acet> no prob, you cleared something up for me
<ick> yeah... thats all i thought they were
<acet> ick: (turns out we had similar ideas, just different ways of
<acet> looking at them :)
<ick> yeah... ok!
<ick> i guess this would be much clearer if we were in person :]
<ick> i should transfer to NMSU
<acet> passive databases do not go out and ping people though.. they
<acet> do not connect to anybody else.. they do not serve as proxies
<acet> for certain services
<ick> acet: correct, they only tell people about other people
<acet> hrm, snazoo idea :)
<ick> their only purpose is to connect a group of people
<ick> this was the only reson i was sticking to group-server idea instead of synk's i
<ick> dea
<ick> and make that group of people into group of groups
<acet> yea, here is outlook on (optional of course) user
<acet> authentication: There are two kinds of servers (in this
<acet> context at least): authenticating, non authenticating... for
<acet> authenticating servers, you have to register
<acet> yourself and log in before you can ask it for any
<acet> information... non-authenticating servers will give out
<acet> information to anybody.
<ick> ummmmm, that will not make xentrac happy
<ick> i liek it tho :]
<ick> he wants to be able to do tunachat -w without ever connecting
<ick> but i like your idea because this way group-servers can lock out trouble makers
<acet> ick: I think there should be flexible types of data people can
<acet> deposit though... some kind of simple language that can be
<acet> used which will tell other clients "I have information
<acet> available on: Real Name, Phone, groups
<acet> connected to, happy quote of the day"... and then clients can
<acet> say: "gimme Real name and happy quote"
<ick> acet: packet types are just a matter of implimentation
<ick> but a flexible packet type is cool
<acet> ick: xent can do that... it just won't be guaranteed to be
<acet> correct. Registered groups are responsible for maintaining
<acet> that information on the group server... their information
<acet> field (describes in previously mentioned
<acet> "language" what info is available) could have things like
<acet> "Name Of Group, Manager of group, Connection Address, List of
<acet> Current Users of Group"
<ick> ok.. that works
<ick> and dont forget about flags of user
<ick> (moderator, manager)
<acet> ick: (re: information field)... with the use of a field like
<acet> this, we can make the only thing that group servers are
<acet> *required* to keep track of be this field... every thing else
<acet> can be left to the user to choose to
<acet> give or withold
<acet> sure
<acet> if a client doesn't understand a field entry in the
<acet> information field, the client simply won't ask the group
<acet> server for that information.
<ick> good... can make for different kinds of clients
<acet> with information field, people can register data like
<acet> "Picture" or "Voice Sample"... anything they want.. "Home page
<acet> URL"..
<acet> aye
<ick> I try ta think an' nuttin' happens!
<ick> cool! great for up and coming ISDN lines (multimedia chat!)
<acet> would probably want a standard "version" entry in the info
<acet> field... in case the language used in the info field ever
<acet> chages so that old clients can read the verison entry and know
<acet> that they will have no idea how to
<acet> parse the new language
<acet> yah yah
<ick> i logged this all for synk
<ick> one more thing... altho the groupserver is only info, i still would like it to
<ick> ping client servers every hour or so to find dead client-servers
<acet> lotsa new ideas and perspectives
[=Change=] Flac (falcon@thelair.zynet.com) entered group [NR]
<Flac> Hey
<acet> ick: might also want it to ping a client-server before
<acet> releasing any information about how to connect to it or it's
<acet> existance as well...
<ick> flac: geeeez, you always miss the most important stuff :]
<acet> ick: standard /w lists could have dead client-servers listed..
<acet> that's not a big priority
<Flac> figures.
<Flac> Right now I'm working on UUCP.
<Flac> I hate uucp.
<acet> eek
<Flac> *nod*
<Flac> and my computer is freeking.. think I have a bad simm
<ick> acet: we could make /w ping only if it has been like 30 minutes after last ping
<ick> ... because many people will do /w often (that would be way too many pings!)
<acet> ick: ooh, extension of info field idea....
<acet> ick: yea, that's what I meant
<Flac> ick: have you anyluck with rsh on thelair?
<acet> ick: no, wait, no it's not.. sorry, yea, that's a good idea
<ick> flac: nope
<ick> flac: i have never had luck iewth rsh on anything but draco
<Flac> Permission denied?
<ick> flac: yup
<Flac> hmmm
<Flac> and the NAG doesn't help much
<Flac> ick: OH, need command finished and alias for DOS, may I leech
<Flac> them?
<ick> flac: login to caffeine.. they are called dosed.* and alias.* in /dosc/public
<ick> acet: nifty nifty! you can grab nifty dos utils from me now... like the two lis
<ick> ted above, filename completion and aliases for DOS!
<acet> ick: factor in info-fields idea to /w queries... : /w queries
<acet> can specify which fields they are interested in... they can
<acet> say things like "give me a list of the names of all groups" or
<acet> "give me a list of names of groups
<acet> who's CountOfUsers field is greater than 10 (if they don't
<acet> have a CountOfUsers field, they don't get listed)"
<acet> ick: 4DOS?
<ick> acet: no.. just two tiny utils... incase you dont like 4dos
<Flac> damn, lots of sttuff in there.
<ick> flac: yeah... all my utils that i cant live with
<acet> 4dos has those features... also has lots and lots of other
<acet> features... closest thing to a unix-like shell I've seen for
<acet> dos
<ick> flac: also.. check out /dosc/bat for my batch files and /dosd/mods for 30+ megs
<ick> of mods that i happen to just have around, nd /dosd/pictures... has friends, s
<ick> ick, giger, and other
<Flac> KEwl...
<ick> acet: that would be like sorting by certain fields of each group
<acet> ick: yea
<ick> flac: sitll having trouble with config.emu
<ick> acet: do you have dosemu?
<ick> flac: do you have config.emu or dos 6 multiple configs
<acet> ick: nada
<Flac> ick: No, never had... you were the one.
<Flac> :)
<Flac> geeez, got enough alias for hdir ick:
<Flac> ?
<Flac> ugh
<acet> hdir dhir hidr hrid :)
<ick> hehe... dont want to make any typos
<Flac> alias IHDR hdir
<Flac> alias IHRD hdir
<Flac> alias IRDH hdir
<acet> <- seems to type dhir more times than hdir...
<Flac> alias IRHD hdir
<Flac> alias JDIR hdir
<-- types hidr a lot!
<Flac> alias JDOR hdir
<Flac> alias JFOT hdir
<Flac> alias JOFT hdir
<ick> flac: all common combinations of hdir, along with combos with either or both ha
<ick> nds shifted over on the keyboard
<Flac> alias R hdir
<Flac> alias RDHI hdir
<Flac> alias RDIH hdir
<Flac> alias RHDI hdir
<Flac> and that's only a 3rd of them
<ick> flac: but check out paths.bat and map.bat... nifty way to do paths
<ick> acet: you heard of subst method of paths?
<--- cant remember if i stole it or came up with it
<acet> subst method of paths?
<ick> acet: i subst all my drives up to Z so they all point to c:\
<ick> acet: then i cd each drive to the directory that i want in my path
<acet> using SUBST? nada.. haven't heard of it
<ick> acet: then i use a path=c:;d:;e:;...z:
<ick> acet: i also wrote a map.bat that makes it so i can add paths jusyt like at cec
<ick> with novell 3.11
<acet> cool.. how many drives do you have?
<acet> (like the idea, never thought of it)
<ick> acet: if i want to change a path, i just switch drives and cd
<ick> acetL i have 26-5=21 dirves (a:,b:,c:,d:,e: [cdrom and two HD partitions)
<Flac> Looks really messy
<acet> can you subst a drive multiple times?
<ick> acet: i have a batch file that does subst f: c:\; subst g: c:\ ...subst z: c:\
<ick> i can subst one drive once, but i can subst multiple drives to one drive
<acet> cool
<ick> acet: but it poses one prolem, programs that search your path work, program tha
<ick> t like to navigate through path dont, because they dont like c: (with no direct
<ick> ory name)
<Flac> is there a better site then nic.funet.fi to get kernals?
<acet> sunsite in incoming...
<Flac> sunsite is just as slo.w
<Flac> :)
<ick> flac: actually sunsite is goig to speed up soon, they are getting a fast er lin
<ick> e
<acet> foo
<ick> flac: ftp.cdrom.com?
<ick> flac: caffeine.zynet.com? :]
<acet> yay
<ick> sunsite is limiting anon ftp users to 350
<Flac> whacha got?
<Flac> 1.2.0? is it out?
<Flac> hmmmm
<ick> flac: its been out
<ick> check out /tmp
<ick> wait!
<ick> get it from ~nirva/linux-1.2.0.tar.gz on thelair
<ick> fuck... i deleted it
<ick> BUT! i did copy it to ~ftp/incoming on thelair
<Flac> Owell, it would have laged you really bad.
<Flac> kewl...
<Flac> better.
<Flac> maybe
<Flac> brb
[=Sign-off=] Flac (falcon@thelair.zynet.com) just signed off
<acet> <- updating glossary definition of group server
<ick> writing in my own
<ick> synk an i decided that idle times will not be given if you request entire user
<ick> list
<ick> an=and
<ick> idle times would only be told if the user requests user list from CLIENT-SERVER
<ick> S
<acet> ick: could be an info field if you change your mind.. the
<acet> group server will probably keep track of that info anyways.
<ick> acet: how?
<ick> how=how owuld it know about my idle time
<ick> at least, how would it kow of an accurate time
<acet> ick: hrm.. wait
<ick> it can ask all client-servers, but i wanted to eliminate that iwth the group se
<ick> rver
<acet> ick: yea, good point...
<ick> plus... if you relaly want to knwo idle time... do a /w and then /w m0o
<acet> had thought that client-servers can use an information field
<acet> to describe data in a listing of users... (this would
<acet> sacrifice the human-readable simple text fields mentioned
<acet> earlier)
<ick> acet: hwy cant client-servers keep basic info for themselves, and let big info
<ick> go to groupserver
<acet> having a UsersConnected field for a group would allow icb type
<acet> /w functionality... would basicaly allow almost any type of /w
<acet> functionality actually.
<acet> define big-info
<ick> big-info? huh? i think you got wrong window
<acet> "and let big info go to groupserver"
<acet> (sorry, no hypen)
<acet> hyphen even
<ick> oh... big info such as gifs, and voice samples, and other multimedia type thing
<ick> ies
<acet> ick: got a problem... what if asshole client-server tries to
<acet> stuff 80 megs of 'big-info' into the group server?
<ick> thats why we give 100k quotas
<acet> ! hrm
<ick> i have anohter idea!
<ick> we can store big things on CLIENT's own machine, and the group server will give
<ick> little info and if i do /m server whois ick, it will come to me and get big in
<ick> fo
<acet> proposed solution: set a limit on each field, but also include
<acet> the ability to replace data with a URL pointer or something so
<acet> other clients can get as much information they want, but they
<acet> have to connect to the
<acet> client-server themselves if it's too big
<acet> hrm, almost same idea... eerie :)
<ick> have info about people (like icb info) on group server, also have pointer to UR
<ick> L on CLIENTS site
<acet> methinks groupserver should not make any connections or data
<acet> retrieval though...
<ick> acet: no, it wont have to, if will just give info, then user can connect to URL
<ick> if we relaly want to get complicated adn competitive, we can make tunabrowserfo
<ick> rWWW
<ick> :]
<ick> ]=P
<ick> /w .
Group: ishiboo (mvl) Mod: ick Topic: DontPutURHandWhereUWantURFace
Nickname Idle Sign-On Account
*ick - 4:48pm nirva@caffeine.zynet.com
acet 2m 4:44pm matth@emmy.nmsu.edu
<ick> /rtopic
[=Topic=] ick changed the topic to "Fools -- your god is dead"
<ick> /rtopic
[=Topic=] ick changed the topic to "DontPutURHandWhereUWantURFace"
<ick> ugh
<ick> /rtopic
[=Topic=] ick changed the topic to "DontPutURHandWhereUWantURFace"
<ick> /rtopic
<acet> sample dialogue between clientserver and groupserver.. (client
<acet> server is trying to register data): "Hi, create field BigStuff
<acet> for this group" -- "Ok, done" -- "put this info into BigStuff
<acet> field... it's 1024k in length,
<acet> acknowledge" -- "1024k? fuck you.. I'm not holding 1024k of
<acet> your crap" -- "ok, how about I set up a port on my machine
<acet> where people can get the info for themselves and you simply
<acet> tell them where to go" -- "yeh, ok"
[=Topic=] ick changed the topic to "My spleen is yellow and green"
<ick> ok.. that works
<acet> methinks it's ok for groupserver to hold some data... would
<acet> speed things up considerably
<ick> yea.. it should hold stuff like crater holds stuff
<acet> but whoever sets up the groupserver will have the flexibility
<acet> to set a maximum that data
<ick> the server should be able to set addtional info length, it should be requierd t
<ick> o hold IP address, full name, etc...
<acet> max # of fields per group... max length per field.
<ick> the TEXT: hsould be optional length
<acet> so a seperate set of required fields and optional fields?
<ick> yeah... i think that would be good, because i want to be sure that i can place
<ick> my username and fullname, and address, etc... registered
<ick> /m server whois ick
<ick>
<ick> ick is logged on and registered
<ick> Nickname: ick Address: nirva@caffeine.zynet.com
<ick> Phone number: 1-505-866-0654 Real Name: Danny Dulai
<ick> Last signoff: 11-MAR-1995 17:26 (MST)
<ick> Text: OH MY GOD! Kennedy's been shot! I hate when that happens.
<ick> i also would like the last signoff time
<acet> ick: can give users and groups a quota....
<acet> "you have 64k of additional info... do with it as you please"
<acet> hrm, if you give quota, you might not have to split into
<acet> seperate sets of fields...
<ick> ok
<ick> yeah.. just require quota to be big enough for average data size
<acet> after all, if somebody doesn't want to give their real name,
<acet> don't keep that in memory
<ick> acet: oh i planned on all data for all users being dynamic
<acet> aye, Big Servers<tm> ;) can feature larger data blocks
<acet> ick: yea, that works...
<acet> gadzooks
<ick> what?
<acet> just had vision of extending this all further to the point of
<acet> just giving users a small filesystem... limited quota but
<acet> otherwise similar to unix directory... fields designated by
<acet> files by the field's names... i.e.
<acet> Somebody would search RealName.txt or something for the string
<acet> of their real name..
<acet> half of me thinks this is rediculously silly, the other half
<acet> thinks this is what we're talking about anyways
<ick> ok.. my problem with that is that searching through 1000 files is slow, but ope
<ick> ning just one is fast
<acet> if you want to see what fields are available (ala "information
<acet> field").. just get a directory listing
<ick> oh.. nevermind... thought you were saying something lese
<acet> ick: it could all be virtual... it's just a means to visualize
<acet> the data
<acet> wouldn't need file perimssions.. wouldn't need
<acet> subdirectories... would need filesizes though. File sizes and
<acet> filenames... can't think of anything else
<ick> i thought the idea for this is that since the groupserver would take up so many
<ick> resources like irc and icb and all other chat programs, but this would just ma
<ick> ke setting up a group-server a more complicated thing
<acet> (or would subdirectories actually be usefull?)
<acet> guh, I'm getting rediculous... sorry
<ick> i think one subdirecty per user would work... then have files inside
<acet> eh? howzat?
<acet> ick: yea, you *could* use the operating system's file system
<acet> to describe the info... or you can just keep it all in a
<acet> database file with a FAT like thing on it
<acet> it's just a way to visualize the data
[=Change=] jess (jess@freedom.nmsu.edu) entered group
<jess> bork
<ick> ok
<ick> helu
<jess> hola
<ick> whawt takes up more diskspace, one file or one directory with 5 files inside? (
<ick> all files in second condition's total size equals first file)
<acet> lo
<acet> ick: intelligent servers can remember which fields are most
<acet> commonly accessed and keep those loaded in memory... leaving
<acet> the less popular ones on disk. That would just be a
<acet> performance gain, stupid servers could handle
<acet> it just fine
<acet> ick: think about it... to support different kinds of fields
<acet> you need to have flexible names for those fields... and you're
<acet> going to have to keep track of how much data are in those
<acet> fields anyways. I'm just saying that
<acet> it sounds like a simple filesystem
<ick> if it is going to be expandable, then i think that it should be stored with a d
<ick> irectory with the nickname, then have the rest of the info as files inside that
<ick> direcotory, with names like: address signoff phone text ipaddress
<ick> that way if we decide to add more fields, we can just add more files
<acet> ick: yea... but when you do that, the operating system is
<acet> going to keep track of much more information about those files
<acet> than you need (who needs file permissions? it's a public
<acet> server, no?)
<ick> i dont userstand the first staement about OS's (i figured that anyone could acc
<ick> ess the group-server, but the drive wouldonly be able to be accessed by group-s
<ick> erver, that way, anyone (even myself) could start a group-server
<ick> )
<jess> *head spins*
[=Change=] jess (jess@freedom.nmsu.edu) just left
<acet> ick: the file analogy was just a way of visualizing data split
<acet> up into different peices... the OS puts a lot more work into
<acet> splitting up those peices than what would be required in, say,
<acet> a structure in memory for
<acet> instance
<ick> ok... understood, how about having a line in a file that holds the entire field
<ick> ?
<ick> one line=one field
<ick> and line dont have to be seperated by "\n"
<ick> but each line can have its own header
<acet> ick: could... I was just thinking that the file contains every
<acet> byte of information in the field... to read the entire field
<acet> you just read the entire file
<acet> ick: unga, this is getting messy... bad bad
<ick> yeah
<ick> so when we store databases.... first, do you think that it shouldbe one file or
<ick> directory per user
<ick> ?
<ick> (side question for my file
<ick> group-server pings client-servers every hour, how often should client-servers p
<ick> ing clients?)
<acet> I think they should be seperated into a block of fields.. one
<acet> block per user... each field in that block given a unique name
<acet> and seperated from the other fields in the block.
<ick> i was thinking that client-servers should ping idling users maybe every 10 minu
<ick> tes (5?)
<acet> hrm, dunno.. it's pretty low bandwidth though... a ping every
<acet> 3 minutes if the client-server hasn't heard anything from
<acet> them?
<ick> ok.. that works... 3 minutes for users that have not talked to client-server
<ick> unm machines relaly speed up over spring break L)
<acet> yea, depends on the implimentation though... protocols used to
<acet> connect with the client-server might already have means to
<acet> detect when a connection has been broken
<acet> :-0
<acet> :)
<acet> afk
<acet> back
<---- still confused about /m's
<acet> ugh, body is falling apart.. probably should eat something
<ick> acet: yeah... even i ate today :]
<acet> heh
<ick> synk and i talked about this yesterday at the "almost-meeting"
<ick> i think we we wanted the magic number thingie
<acet> the /m's?
<ick> yeah.. the /m's (not your eating habits :)
<acet> through client-servers?
<ick> no! no client servers!
<ick> cleintserver could easily hack messages
<acet> "hrm, I wonder what matt ate last night" 8-)
<acet> yah, that's what I thought
<ick> when ick types /m acet helu it shoudl go:
<ick> ick (magic number) --> groupserver&acet
<ick> groupserver (magic number) --> acet
<ick> ick (message) --> acet
<ick> acet checks to see if magic number and message match
<ick> if so, displays, if not, displays with warning
<ick> ?
<acet> hrm, I take it ick sends magic number right before meessage...
<acet> the same connection?
<ick> yah.. same packet
<ick> the magic number will consist of 8 bits random, 8 bits are checksum
<ick> altho, 8 bit random might work alone
<acet> when groupserver sends magic number to acet... does it send
<acet> acet information on who is sending the message? "ick is
<acet> sending message with magic number: xxxxx"
<ick> acet: yeah... that way acet can tell it was icks magic number and not synks mgi
<ick> c numner (synk sent message at almost same time)
<acet> hrm.. works, but rubs against passive database philosophy
<ick> oh yeah, i forgot
<ick> got it!
<ick> forget magic number
<acet> ?
<ick> ick sends message to acet
<acet> ok
<ick> acet sends magic number (totally random) to ick
<ick> ick sends it back
<ick> if match... we get real message!
<ick> that way, acet MUST know who the message is coming from
<acet> hrm.. yah, works (complex though)
<ick> its just an ack for an ack
<ick> good?
<ick> (i like it)
<acet> yah, good... want to hear my idea just for shits and grins?
<ick> yeah... gimmie new idea
<acet> ick -> groupserver: "Gimmie 8byte message cookie"..
<acet> groupserver->ick: "your cookie is: 5FA3-103B-15CD-9938"
<acet> (groupserver keeps track of ick's cookie).. ick->acet:
<acet> "(mycookie) BLah blah blah blah"... acet->groupserver:
<acet> "Who's cookie is this: <cookie>".. groupserver->acet: "that's
<acet> icks cookie"
<acet> (group server then forgets that the cookie belonged to ick...
<acet> groupserver also expires cookies that nobody have asked about
<acet> for a long period of time)
<ick> good idea (very secure) but my idea is only 3 transfers, where yours is 5
<acet> ugh, bad bad... cookie doesn't identify what groupserver has a
<acet> register for that cookie
<acet> forget the idea
<ick> (just for grins, no shits, cookies can be totally random)
<acet> hrm, true... *ponder ponder ponder*
<acet> you're solution works... but can authentication be factored
<acet> into it?
<ick> yea.... acet has to know who ick is to send the magic number
<ick> ick can be faked ick, but ick cannot be synk sending message (with hacked up cl
<ick> ient server that converts outgoing /m's to be by ick)
<ick> if ick is just another person being me while i am not lgged in, then it is perf
<ick> ectly acceptable
<acet> ok
<ick> because the user can see that my last signoff was earlier than the nasty messag
<ick> e
<acet> yah
<acet> question: do clients maintain an open connection to the
<acet> groupserver?
<ick> no
<ick> the groupserver is in lala land, only knwing about users and client-servers
<ick> one idea was to keep tcp connection with client servers, but that is stupid now
<ick> , since we have solved almost all the problem wihtout needing that connection
<acet> do clients have to register each time they want to talk to the
<acet> groupserver?
<ick> no.. clients will register when they login, and will stay registered until they
<ick> logout or thye get noticed by a 3 minute ping
<ick> ok.. done writing about /m's, are you finished on this topic? (can i move on?)
<acet> clients can be logged in without holding open a connection?
<acet> Say user logs in to groupserver, then closes connection but
<acet> doesn't log out.. now, user wants to ask groupserver a
<acet> question, how does it reconnect to the
<acet> groupserver and say "i'm acet, I logged on earlier"
<acet> yah
<ick> joining multiple groups is easy by just making more tcp connections, but how to
<ick> sho this to the user? (interface-wise)
<ick> acet: with authenticating group-servers, acet is not allowed to ask questions,
<ick> but with non-auth. groupserver, anyone can just ask
<acet> irc does it... can also have split windows or virtual screens.
<acet> client dependant
<ick> acet: how about a speical key to change the focus of the group that you are tal
<ick> king to?
<acet> ick: eek, so on authenticating groupservers acet has to
<acet> register himself everytime he makes a query?
<ick> acet: sorta, i figured that with invisible users, they would ask the client-ser
<ick> vers to ask the gorupserver
<acet> ick: yea, in irc that's just handled under the /join command
<acet> methinks... you just /join a group you never left to make it
<acet> the current
<ick> ok
<acet> invisible users? why can't invisible users just say to the
<acet> group-server "Hi, I'm invisible..."
<ick> i thought we wanted to make invisible users never notify the gorupserver about
<ick> their existence
<acet> that's silly though... if they want to get services from the
<acet> groupserver, they register with the groupserver... but they
<acet> can tell the groupserver never to tell anybody else they're
<acet> there
<acet> otherwise "true invisibility" can be achived by simply logging
<acet> in, making a request, then logging right back out again
<ick> well, i wanted it to be the first way... invisible users tell group-servers abo
<ick> ut their existence but say "shhhhhh, i am invisible", but i got the idea that s
<ick> ynk and you and xentrac thought it was bad that way
<acet> *shrug*.. only reason one would want to be completely
<acet> invisible is if they are trying to work on a 'hacked
<acet> groupserver'... in which case only the person running the
<acet> groupserver would know they are really there.
<acet> Otherwise just set a flag on the groupserver and trust it not
<acet> to release information on you
<ick> i think that groupservers should be trusted, but xentrac threw a fit about that
<acet> in irc, something like /whois foo* would not find invisible
<acet> user 'foobar'... but /whois foobar would... gotta get the
<acet> handle exactly right
<acet> basicaly, they are invisible unless you look right at them...
<acet> (that's irc)
<ick> that is also icb
<ick> kinda... i dont know about gorups
<acet> you can't do /w invisiblegroup and see it in icb unless you
<acet> are part of that group already methinks
<ick> in icb.. you are not logged in to anyone outside your invisible group and the g
<ick> roup does not exist unless you are in the group ( i just checked)
<ick> but i found a loophole!
<ick> ifyou do /w helu (helu is invisible), its says: [=Error=] Group doesn't exist
<acet> ?
<ick> if you type /status name helu:[=Error=] Group already exists
<ick> :]
<acet> :-)
<ick> i liked the trusted groupserver idea, mainly because i cant see a way to do hid
<ick> den groups without it (users are easy)
<ick> especially with auth. groupservers
<acet> yeh... not much for omnicient groupserver people to gain
<ick> parse error
<acet> er...
<acet> forget it (couldn't rephrase)
<ick> do we wait for the rest of the people, or do you have some revolutionary idea t
<ick> o pick one of the other way?
[=Sign-on=] Flac (falcon@198.59.146.118) just joined [NR]
<Flac> Hey
<ick> hehe... you missed another HUGE part!
<acet> "wait for the rest of the people?" (xent & synk?)
<ick> acet: yup, and flac
<ick> flac: which do you want? trusted groupservers? or no trusted group-servers?
<Flac> *sigh*
<acet> <- no revolutionary ideas at the moment
<Flac> define trusted.
<ick> i say to groupserver that i am invisible... i trust the gorupserver that it wil
<ick> l not give out my info
<Flac> That's it?
<ick> yup
<ick> thats all there is to a trusted groupserver... we worked around every other pro
<ick> belm
<Flac> I like the idea.
<ick> or if we have untrusted ones:
<Flac> But it has to be restricted to cretain users.
<ick> (what has to be restricted?)
<ick> the users login to group server which tlel them client-servers to go to, but th
<ick> en client server sends back fake log off to gorup server
<Flac> the ability of being invisible.
<ick> flac: WHY?
<ick> !
<Flac> Geee, what if someone if invislble and drops in a group, NO
<Flac> ONE WILL KNOW the person is there.
<acet> Flac: the client-server will.
<Flac> but will the people in the group know?
<ick> acet: hes right... others will see that he is invisible and follow him when he
<ick> goes out
<acet> Flac: That's not what we're talking about.
<ick> sorta, i think
<acet> eh? no idea what you're talking about
<ick> nevermind.. they cant follow
<Flac> great way of eves dropping.
<ick> flac: clientserver of your group will tell everyone that he is coming into your
<ick> group
<acet> nono... invisible users are relative to the groupserver they
<acet> register on... they aren't *truly* invisible..
<Flac> Then what's the point?
<ick> acet: no.. i meant for the kind of invisible that only connects to client-serve
<ick> r m0o, and nver tells anyone but people in m0o
<acet> Flac: the point is that if I'm invisible on a groupserver, I
<acet> don't want people who ask the groupserver for a list of all
<acet> people connected to report my name.
<acet> ick: oh, that... yeah, you have to tell the client-server not
<acet> to release your name as part of the "who's in this group" list
<acet> then.
<Flac> The only reason I can see to make a user invisable, say if the
<Flac> user joined a hiddin group?
<ick> forget it! flac is right... hidden users are a pain to handel.. i just want hid
<ick> den groups!
<acet> falc: eh? methinks you have the wrong idea
<Flac> acet : I bet I do.
<acet> or, more probably, the ideas you had were changed while you
<acet> weren't here :)
<ick> hidden groups make sense... if a hidden user leaves the client-servr he is conn
<ick> ected to, 1) how is he going to leave if it is an auth. groupserver, 2) how is
<ick> /w goign to work when he joins anoter gorup
<Flac> Ok, define Group server for me.
<Flac> and then define the clinet.
<acet> ugh, not in x.. I'll mail it to you, gimmie an email address
<Flac> client
<Flac> No, just give me a quick overview.
<Flac> falcon@zynet.com
<acet> I don't want to give you a quicko overview when I spent time
<acet> rewriting the glossary.
<ick> hehehe... flac: and with his glossary and my theory file, you hsould have more
<ick> knowledge than synk or xentrac right now
<Flac> ahhh ok
<Flac> anyone here use procmail?
<ick> nope... no need to... i have different accounts for different mail :]
<acet> <- uses rocmail.
<acet> procmail
<Flac> mail me you're .procmailrc if you would
<Flac> I have serval mailing lists I read, and I can't figure out how
<Flac> to make if use diffenet mail boxes.
<ick> acet: so we must have trusted groupserver to have invisible groups, it logicall
<ick> y makes sense
<acet> flac: only entry that has changed significantly in
<acet> tunachat.gloss is groupservers.
<acet> aye
<ick> acet: mail me glossary
<ick> nirva@caffeine
<acet> ick :done
<Flac> small promailrc file.
<ick> acet: i thought that maybe all users in group would have a number assigned to t
<ick> hem, depending on when they got there (manager=0, second person=1, thrid=2,etc.
<ick> ..) and these numbers would be passed along iwth everyoe in groups info to all
<ick> the clients
<acet> *shrug* you didn't ask if it was big.
<Flac> Do you know how to sort mail from mailing lists?
<Flac> :)
<acet> not offhand, no
<Flac> Ok.
<ick> when the client-server died, they would all connect to number 1 and all numbers
<ick> be decremented
<ick> this way, there is no need to vice-manager
<ick> also, hte group server would keep track of these numbers, so it can redirect us
<ick> ers to the #1
<acet> ick: could do that.
<ick> acet: that wya, there is always a predecided client-server
<acet> what if I, the manager of the group, want a vice-manager?
<ick> acet: that will be involved with splitting the group
<acet> grr... why would the groupserver keep track of those numbers?
<acet> why not the new client-server (after a move) re-inform the
<acet> groupserver?
<ick> ok... that works... and since the group naem would already exist, the groupserv
<ick> er would ping the #0 and see that it is dead, the group is gone, and the name n
<ick> o longerexists
<acet> ick: that's a config option really... there can be people who
<acet> would like the group to die completely if they go (ego :).
<acet> They can configre it to pass moderation along to the next
<acet> person in the group, or only to
<acet> specified people, or none at all
<ick> i dont want to encourage big egos :)
<acet> question, what advantage is there for mapping names to
<acet> numbers?
<ick> that is just implied, actually with implementaion, it would jsut be the order t
<ick> hat all users are kept in memory of the groupserver
<ick> and client-server, and clients for that matter
<acet> hrm, would probably be good to keep the "in case of fire, go
<acet> to -> blah@foo" data on the group server...
<ick> ok
<ick> let me work out some plan, then i will type it out here
<acet> wait, no.. scratch that
<acet> I forgot the case where there are groups with no groupserver
<acet> involved
<ick> give ideas here
<ick> i like the ordering because that works in all cases
<acet> ?
<ick> if all other members of the group knwo where to go, they do it, then the new cl
<ick> ient-server notifies the group server that it wants to create a group
<ick> with the same name
<acet> methinks there probably only needs to be a way to ask the
<acet> client-server who they should go to if the client-server
<acet> dies... client programs would probably ask that automaticaly
<acet> upon entering the group. There also needs
<acet> to be a way for the client-server to change that info and
<acet> inform everybody that it has changed.
<ick> ok.. so that would be the vice-manager
<ick> but give this person now rights to group.. they are just backup
<acet> it would be the vice-manager, the next person in line,
<acet> blank... could be anything
<ick> the other mangers in the groups can be called joint-managers
<acet> that person has to agree on that though...
<ick> good
<ick> but by default, you have to accept the job if you are the only other person in
<ick> the group
<acet> not really, the group can die
<ick> but that would be horrible, i wnat to be able to switch groups without having t
<ick> o reconnect
<acet> eh?
<ick> if gorup dies, i will be of in lalaland, with no group
<acet> ick: yea, right... unless you know in-advance what to do in
<acet> case the group dies.. (which would be info given by the
<acet> client-server back when it was still up)
<ick> i am lost
<ick> let me see if i get this right
<acet> if you don't know where to go when the group dies, you're left
<acet> floating in space...
<ick> but i dont want to make that decision before hand, i want see my choices afterw
<ick> ards and then make a choice
<ick> the client-server picks another person in the group to be client-server in case
<ick> of fire, if they ok it, all users are notified about the vice-manager being ch
<ick> osen
<Flac> *idel*
<Flac> idle
<Flac> ugh
<acet> flac: oh, really?
<acet> ick: ugh, not sure that's clean
<acet> right
<ick> but if i am the only other person in the group, and the first person decides to
<ick> leave (by their own choice or by case of fire), then i should take overa ll ri
<ick> ghts
<acet> all the other users then know whom to try and connect to if
<acet> the current client-server dies... (the client program would
<acet> handle this transparently if it can)
<ick> acet: yes
<ick> i shoudl have these rights mainly because they left me with htem
<ick> i like this part of icb
<acet> ick: you should *if* you know to go to yourself when the
<acet> client-server dies (yes, it's silly). It's a matter of wether
<acet> or not you accept to take over the responsibilites of the
<acet> group when it dies or not.. if you do, you
<acet> become the group, otherwise the group dies.
<ick> but i thikn that it should be built-in to the client to assume that ou are assu
<ick> meing responsibilty (its not like its any extra load)
<acet> ick: that's an option of the client-server to do.. I'm just
<acet> thinking of ways to enable the client-server to employ such
<acet> functionality...
<acet> yea, I think it should be a config option though...
<ick> what would the other optoin be? death in lalaland?
<ick> hey... what about a default land!
<ick> like a grop actually called lalaland, which is wehre all lost users go
<ick> if in lalland for over 5 minutes, then you get logged off
<acet> yep. The client-server can be configed so that if it dies,
<acet> somebody is going to have to manually rebuild the group,
<acet> re-register it, etc.. if you are the only other person left in
<acet> such a group, it dies, and you want to
<acet> be the mod of the group, then you can recreate the group with
<acet> no problems..
<acet> !? eh? that makes no sence to me
<ick> forget it ... it was a silly idea
<acet> the 'default' place to be is unconnected to any groups
<acet> whatsoever
<ick> acet: but what if you are not connected and someone does /w @acet
<ick> you are logged in, but they cant reach you
<acet> why not? they can't connect to any group, but they can connect
<acet> to your client, right?
<ick> Don't be a Gummy Bear, say something.
<ick> oh yeah
<ick> nevermind...i thought tthat they would have to go through a client-server *fwap
<ick> *
<acet> alternatly, I was thinking of having a data field on the
<acet> groupservers where clients can put a list of groups they are a
<acet> part of. /w @acet would then be asked of the groupserver to
<acet> check to see if acet has defined such a
<acet> field.
<ick> acet: actually, since the group server knows about all the people, and it konws
<ick> about invisible groups and IS trusted, why doesn't the groupserver sort out al
<ick> l the gorups that acet is in, and tell those clientservers to send info to synk
<ick> (woh typed /w @acet)
<acet> unga, then the groupserver would have to search to see, out of
<acet> all the groups which have even defined a UsersOn type field in
<acet> the first place, does acet occur in any of them. Methinks it
<acet> would be easier to have a
<acet> GroupsImOn field in the user data.
<ick> ok.. then if then why not define that field always?
<acet> besides, with the other way, somebody could create a group
<acet> called happy_christians and tell the groupserver that I'm in
<acet> that group when I'm not.
<ick> hehe.... nice example
<acet> ick: I wouldn't define that field if I didn't want people
<acet> knowing what groups I was in.
<ick> ok
<ick> makes sense
<ick> if you did not define that field, then do they come and ask your CLIENT?
<Flac> Ok, back
<acet> ick: also... I *could* define that field to say something
<acet> semi-clever like YellowSubmarine or spam-tin or somethingg
<acet> else that is obviously bogus :)
<ick> oh no, i dont want bogus things
<acet> ick: I think we should debate the entire "go ask the client"
<acet> bit on that...
<acet> er, I change 'debate' to 'drop'
<Flac> Joy, I get to play with TIA
<ick> flac: gimmie copy
<acet> ick: it could be fun :-)
<ick> acet: yeah... but a /w @acet with bogus names would return me somthing like:
<acet> ick: default clients could be configured to automaticaly
<acet> update that field as acet joins and leaves groups... so the
<acet> user doesn't worry about it.
<ick> Yeallow submarine: non-existant group
<ick> ok
<acet> ick: I was thinking of a /w @acet returning a list somewhat
<acet> like: Acet is located in: #linux #guacamol LittlePinkPussycat
<ick> hmmmmm
<ick> i thought it was going to do what icb's /w @acet would do
<acet> methinks a /g @acet would be out of the question.
<acet> espeicaly considering that with tunachat I can be in multiple
<acet> groups.
<ick> i thought that /g @acet would ask you which group you wanted to be in
<acet> ick: there could be a command in the client which does that...
<acet> does a /w acet groups type thing (to get that list of groups)
<acet> and then tries to see what people are in those groups.
<acet> ugh
<ick> ok... or maybe even /w @acet returns group names, /wg @acet returns those group
<ick> s contents
<acet> no, can't say I like that. /whereis acet could, if desired,
<acet> return stuff like LinuxServer:kernel (groupserver:group)
<acet> we would have to standardize how that kind of thing would be
<acet> handled for clients to be able to parse that information
<acet> consistantly... I don't want to do that
<ick> ok... so drop the enire /w @acet for now
<acet> ick: that works... but /wg would be a client command that
<acet> would execute multiple groupserver commands.
<ick> yeha.. but drop it all now... the enire @ deal is way to specific
<acet> <- likes the idea of a GroupsImOn type field.
<ick> i liek that too
<acet> ok
<ick> ok.. im kinda done with the very basic chat now...
<ick> wanta see doc?
<Flac> coded?
<acet> also, lets people see stuff like '/whereis acet' -- 'Acet is
<acet> on: none of you buisness"
<acet> sure
<ick> flac: HAHAHHAHAHAHHAHAHAHAHAH!
<Flac> yes
<ick> ok.. sent off
<ick> i accidentally sent it to acet@emmy.nmsu.edu
<acet> gotit
<ick> i left my notes at the end
<acet> oops :)
<acet> unga
<acet> oh,btw, as a feature I like the idea of doing something like
<acet> /m! falc unga bung which would tell the client-server to
<acet> rebroadcast that message to everybody *but* falc.
<acet> just a thought
<ick> ok, i like that
<ick> gimmie feedback after you guys are done reading
<acet> that would be weird though... since /m's don't go through a
<acet> client-server but /m!'s would
<ick> :]
<acet> oh well, I code in perl for crying out loud... I should be
<acet> used to helpfull inconsistancies. :-)
<acet> "do what I mean, not what I say"
<ick> i wonder where synk is
<Flac> Brenda's?
<acet> brenda's home?
<acet> or different brenda?
<acet> nevermind
<Flac> *shrug* we was saying something about going htere today.
<acet> probably different brenda
<ick> nicole?
<Flac> Was is nicole?
<Flac> *shurg*
<acet> ick: yea, that's what I thought
<ick> dont know, i talked to him for a few hours this afternoon