ICB log 3.9.95

<xentrac> talking about tuna?
<acet> group server will have no idea what groups I am connected
<acet> to... it has no buisness knowing
<ick> acet: ok.. does it not know what groups you are connected to.. or does it only 
<ick> know the first group you connected to? 
<xentrac> you could do /w @acet by asking acet's client what groups it's
<xentrac> in... it might not want to tell you.
<acet> xent: nope, talking about letterman... (yes, tuna.. *fwap*)
<acet> ;-)
<acet> xent: yea, I like that
<xentrac> but still... if you knew where acet's client was, you wouldn't
<xentrac> have any need to access a dedicated group server at all.
<acet> ick: it doesn't know what groups you are connected to at           
<acet> all... because you do not explicitly have to go through it to
<acet> connect to a group (you can connect on your own or go through
<acet> another group server)... it also 
<acet> doesn't know when you leave a group
<ick> acet: it will know... unless you connect a different way to be invisible
<acet> xentrac: you could ask group server if acet is registered to
<acet> it... if acet is registered, you can ask for acet's client's
<acet> address (which may or may not be tagged as public information)
<xentrac> There's also no need to tell it whether you actually connected
<xentrac> to a group it told you about.
<acet> xent: right
<xentrac> you could ask for info on a number of groups and join none of
<xentrac> them.
<ick> if i do a /w @acet i should get all the groups you are logged into (except for 
<ick> the ones that the group server does not know about,; ie. invisble stuff)
<acet> ick: no, it won't know for sure at all without asking... which
<acet> would be a nasty load to put on the group server
<xentrac> you might just want to send the administrative ear on those
<xentrac> groups a 'who' message.
<acet> what xent said
<xentrac> groups should have two ears.  (I defined ears in one of the
<xentrac> working papers on my www site.)  One for incoming messages,
<xentrac> unless that particular group has TCP connections with all of
<xentrac> the points that might want to
<acet> ick: I don't like that... I like the idea of doing a /w @acet
<acet> instructing the client to find acet's client (if possible),
<acet> connect to it (if possible), and acet's client itself which
<acet> groups it's connected to... which it 
<acet> may or may not tell you.
<xentrac> broadcast to the group, and one for incoming administrative
<xentrac> messages.
<ick> acet: so you want /w @acet to ask acet himself about what groups?
<xentrac> no one else besides acet and his client has a right to know
<xentrac> what groups acet is in.
<acet> xent: *could* be possible to meld those two ears into one and
<acet> distinguish functions by packet type... although I don't see a
<acet> real reason not to seperate the two ports.
<acet> ick: yea
<ick> aet: got it... good idea... makes it more private
<acet> xent: exactly
<xentrac> acet: you're right... that might be a better idea.
<xentrac> I was suggesting a general packet structure to ick today...
<xentrac> each message could consist of a set of fields.
<acet> xentrac: *shrug* can split the two... and just let the user
<acet> possibly define both of them to be the same port if they
<acet> choose to
<acet> xent: i've been having similar ideas regarding packet types
<xentrac> fields can be separated by, say, a :, and information in
<xentrac> fields can be encoded, say, : -> \:, \ -> \\
<xentrac> the first field could indicate a packet family, such as
<xentrac> :-separated, or structured in some other way, to allow for
<xentrac> extensibility
<xentrac> the second field, in the :-separated type, could be a
<xentrac> message-type.
<ick> acet: i was thinking of more asm-like packets... size,data,size,data
<xentrac> join, who, boot, mode, display-on-your-user's-screen... we
<xentrac> should probably try to reduce the set as much as possible.
<acet> xentrac: have been tossing around the thought of a dialogue
<acet> through which packet structure can be described and defined...
<acet> also possible options supported by the client-server or
<acet> group-server being connected to can be 
<acet> described
<xentrac> (it might, actually, be a btter idea to have the second field
<xentrac> tell the client what to do with the message  if it doesn't
<xentrac> understand it, like report an error to the sender or ignore
<xentrac> it, and have the third field specify 
<xentrac> type)
<acet> ick: yea, that's possible and slightly more efficient... but
<acet> if you make it human readable it becomes easier to develop for
<acet> it and people can even connect to a client-server with telnet
<ick> true     
<xentrac> anyway, neato idea:  have a 'broadcast' packet type where the
<xentrac> fields n through n+x, where n is the first field after the
<xentrac> packet type field, and x is the length of the enclosed packet,
<xentrac> which encapsulates a packet/message
<xentrac> you want a group to broadcast to all its listeners... 
<xentrac> maybe there ought to be a 'from' field too in most packets.
<acet> xent: broadcasting to all its listeners is the default
<acet> function, no?
<ick> acet: yes... in some things... this is a very implementation specific topic IMO
<ick> , it will just fall into place depending on how everything else is layed out
<xentrac> anyway, the group host can then strip off the broadcast
<xentrac> header, decide whether to approve the packet for transmission
<xentrac> (probably only a few packet/message types should be allowed,
<xentrac> like here-i-am and display-on-screen)
<xentrac> acet: this way you could use the same ear for both admin and
<xentrac> other tasks.
<acet> xent: thought of benefit of splitting admin port and broadcast
<acet> port... 
<ick> admin port?
<ick> nevermind.. i understand
<xentrac> one ear for sending 'join' and 'who' messages, and another for
<xentrac> sending messages you want to be sent to all listeners.
<xentrac> oops.  sorry.
<acet> xent: one can make the admin port public knowledge and the
<acet> broadcast port restricted knowledge... people could connect
<acet> and talk to the client-server on a system basis, but if they
<acet> want to join the channel itself, they 
<acet> need to know the broadcast port.
<ick> acet: what benefit woudl this have?
<xentrac> or if they want to join the group's talker-set... 
<xentrac> in some cases, there will be only a few talkers and many many
<xentrac> listeners.
<xentrac> not a bad idea, acet.
<acet> ick: if somebody knows the broadcast port... they can telnet
<acet> to it without a client and stil lhave a reasonably
<acet> human-readable session. 
<ick> ok... i guess so...let me write that down
<xentrac> well, they can telnet to it if we want to use TCP... I'm not
<xentrac> convinced that's necessary.
<acet> methinks tcp-like connections are the Right Thing for
<acet> connecting to client-servers
<xentrac> I think TCP buffers overloading and overlagging are the major
<xentrac> reason for IRC netsplits.
<ick> i like tcp also
<ick> netsplits?
<xentrac> I know we've been over this before... but can you explain to
<xentrac> me what justifies the effort?
<xentrac> netsplits are when an IRC link goes down and for a while one
<xentrac> side of the net can't talk to the other.
<acet> xent: considering the drasticaly reduced load put upon a
<acet> client server (maybe 10-20 interactive people logged on during
<acet> extremely busy times)... that still shouldnt be a problem
<ick> tcp is easier to handle        
<xentrac> what justifies the effort of coding another (more complex)
<xentrac> communications channel in our software?
<ick> tcp is less complex
<xentrac> TCP is easier to handle?!
<ick> we dont have to worky about acks, or anything
<ick> internally it is more complex, but that complexity is transparent to the progra
<ick> m
<acet> with tcp you can be far more certain that what you send to the
<acet> client server gets there.. 
<xentrac> we only have to worry about acks if we care about security.
<ick> no.. with UDP we always have to worry about acks
<xentrac> acet: tcp uses acks, same way we'd be doing... you'd be
<xentrac> exactly as certain.
<acet> xent: ok, why *not* tcp?             
<xentrac> it's more complex, and more expensive in terms of system
<xentrac> resources (like fds) to maintain a separate connection to
<xentrac> every client that's listening.  or possibly every client
<xentrac> that's talking too.
<xentrac> not TCP because:
<xentrac> 1) we're going to have a working UDP channel for whispers
<xentrac> anyway.  KISS.
<xentrac> 2) TCP provides all kinds of services we don't need.
<ick> like?
<acet> xent: 10-20 channels max, 3-5 average is considered expensive?
<xentrac> 3) UDP provides a nice, neat already-there division between
<xentrac> individual messages.  with TCP, we have to find boundaries
<xentrac> between messages in a stream.
<ick> xentrac: i do not want to take care of splitting datagrams 
<acet> xent: what!?
<xentrac> don't 'max' me, acet... I've seen IRC channels with hundreds
<xentrac> of people on them.  many OS's have a limit of 256 fd's per
<xentrac> process.
<ick> xentrac: fine.... then split the load between two mangers ina group
<xentrac> in udp, one message == one datagram.
<xentrac> in tcp, we have to worry about boundaries...
<ick> in udp one message could == 50 packets
<xentrac> I think that if we're building a packet-based system (which,
<xentrac> with the 'message' paradigm, we essentially are) we ought to
<xentrac> use an underlying implementation that reflects that as much as
<xentrac> possible.
<ick> /m acet he is right in one way, we will have the engine for UDP working
<xentrac> why would you split a message into 50 UDP packets?
<acet> forcing a limit of 250 people per group really doesn't rub me
<acet> the wrong way to be honest
<ick> acet: no limit! just split group into two... now you have 500 user limit
<xentrac> well, maybe I'm just over-idealistic... I don't like hard
<xentrac> limits, of any kind.
<ick> if you still have 500+ users, split again
<ick> and our intellignet (if implemented) should be able to keep the load down
<xentrac> I think we might want to extend the protocol someday to cover
<xentrac> messages that won't fit in one packet...
<xentrac> but I think that we won't have need of that for a while...
<xentrac> certainly past the prototype stage.
<acet> xentrac: we're designing a max size on a packet? I thought we
<acet> were going to consider connections with stream interfaces
<ick> acet: the streams are only if we use TCP
<xentrac> it just seems simplest to (in order to send a message) just
<xentrac> *send* the damn thing... rather than sticking it into the end
<xentrac> of a TCP pipe.
<ick> simpliest in english terms... not programming
<xentrac> TCP provides a stream metaphor.  UDP provides a datagram
<xentrac> metaphor.  We're writing an application which, fundamentally,
<xentrac> uses datagrams... messages.  Why use TCP?
<ick> beause its there and already done nicely for us
<acet> packets can be conveinently defined by carriage returns... 
<acet> what if udp goes away?
<ick> acet: i dobut that will happen, it is the basis for all IP tranfers
<xentrac> yeah... it's not really *that* much work to escape carriage
<xentrac> returns inside of messages with \ or whatever...
<xentrac> if we use escape-encoding.
<xentrac> of course udp will go away.  But datagram protocols will not.
<xentrac> no, IP is the basis for all UDP transfers.
<ick> i meant datagrams are
<xentrac> IP and UDP are both datagram protocols.
<pimpf> sleep,  going to sleep
<pimpf> lateer
<ick> guby
<xentrac> 'night
<acet> bye
[=Sign-off=] pimpf (teeth@draco.unm.edu) just signed off
<xentrac> datagram protocols provide a service that connection-based
<xentrac> protocols don't.
<acet> what's that?
<xentrac> for instance, you can talk to someone who isn't connected to
<xentrac> the net at the same time you are.  (Email messages are
<xentrac> datagrams, although they use a store-and-forward system for
<xentrac> transmission.)
<acet> this is usefull for a interactive talk program?
<xentrac> you can talk to someone without verifying that they are there
<xentrac> first.  this can be very important if there's a lot of
<xentrac> latency.
<xentrac> no. these are reasons datagram protocols will continue to be
<xentrac> available.
<ick> xentrac: more reasons... these seem futile
<xentrac> up above are the reasons I'd like to use UDP most of the time.
<ick> first reason is not practical for tunachat
<ick> secxond reason is stupid... 
<ick> people have to get acks and address to know if they are there
<xentrac> I guess the way I envision the system working, it shouldn't
<xentrac> matter that much how your message gets there.  I envision it
<xentrac> working this way:
<xentrac> ick: those aren't reasons to use it for tunachat.
<xentrac> ick: those are reasons why udp will continue to be available..
<xentrac> or some analogue
<xentrac> 1) a point has a message.

<ick> I try ta think an' nuttin' happens!
<xentrac> 2) a point calls its send_message call with the destination
<xentrac> and the message.
[=Change=] ThirstyFish (jreifer@sparta.sjsu.edu) entered group
<xentrac> 3) the send_message routine:
<ThirstyFish> xen, didja get my message?
<acet> lo
<xentrac>  a) encodes the message in a suitable format
<ick> helu
<ThirstyFish> (i was kinda inspired)
<xentrac> about bowing? yes, it was quite nice.
<ThirstyFish> i always laugh when i see"bowing" cos I play bass..
<xentrac>  b) looks at all the channels, such as ears, circuits, and
<xentrac> proxies, it has available for that recipient
<xentrac>  c) sends it.
<xentrac> c might involve making an entry on an 'outstanding messages'
<xentrac> table and a scheduling table... maybe arranging for an alarm
<xentrac> at the next scheduled event, to see if an ack has arrived.
<ick> and your reason for doing this inside a channel full of CLIENTS is?
<acet> bluh
<xentrac> you ought to have it set up in such a way that you are
<xentrac> signaled when you receive a message; you don't want to ahve to
<xentrac> poll for them.
[=Change=] ThirstyFish (jreifer@sparta.sjsu.edu) just left
<acet> xent: I don't know what you're talking about... do you know
<acet> berkely sockets?
<xentrac> ick: what?  I'm just talking about the basic message sending
<xentrac> and receiving code... which I assume will be the same over all
<xentrac> the pieces of software, right?
<ick> no way@
<ick> !
<xentrac> I know berkeley socket.s
<ick> it can change all over... i care not if i have to code two methods
<acet> xentrac: no polling... just listen()... no?
<ick> acet: yup
<acet> actually.. I think it's accept()
<xentrac> ick: do you think that the basic 1-2-3-a-b-c thing is too
<xentrac> specific?  I meant it to be pretty general.
<ick> it is specific... b) can be totally eliminated in a group     
<xentrac> accept() is blocking, isn't it?
<ick> so make the port non-blocking
<acet> xent: I think you're being very specific. All we really need
<acet> to consider at this point is "A sends this to B"... and assume
<acet> it gets there fine. Anything else is implimentation specific
<acet> and beyond the scope of the 
<acet> protocol.
<ick> acet is correct... as i said earily... things will fall together when design is
<ick>  finished... it always does... its the nature of programming :]
<xentrac> if the port is non-blocking, then accept() is polling!
<acet> xent: who cares!
<ick> xentrac: fine! make it blocking 
<xentrac> yes... I have a tendency to jump to conclusions.
<xentrac> both inductively and deductively.
<ick> guh
<xentrac> I think I/O in general should be handled by interrupts, not by
<xentrac> blocking or polling.
<ick> xentrac: if you feel like starting to code.. be my guest..... i barly understan
<ick> d sockets
<acet> yes folks, this is entirely too silly... 'blocking' can be
<acet> neatly handled by interrupts
<xentrac> when I'm thinking about how to put something together, I tend
<xentrac> to get real specific too fast... so I get bogged down in
<xentrac> details.
<ick> well, this is WAY too specific.                         
<xentrac> interrupts... or signals, since we're in UNIX
<acet> and I thought *I* had that problem...
<ick> acet: hehe
<acet> yea
<xentrac> my problem is rarely that I barely understand things.... it's
<xentrac> usually a) I think I understand them better than I do, and b)
<xentrac> I've never used them. :)
<ick> well, this is a totally wasted conversation
<acet> the nice thing about a real operating system like unix is
<acet> that, if you want to not have to poll for new connections and
<acet> you need to do something else... no problem! spawn a child
<acet> process which will sit around doing 
<acet> nothing but accepting connections and hooking them up for you.
<xentrac> well, the fairly-general point I'd like to keep in mind is
<xentrac> that there may be several ways to communicate with a given
<xentrac> point.  There's nothing wrong with making more ways... if they
<xentrac> have benefits.
<xentrac> acet: how do you access connections that have been accept()ed
<xentrac> by a child process?
<xentrac> I don't think you can.
<ick> i ra into same logic problem... the child is a brand new program .... it has no
<ick> thign to do with the parent anymore... right?
<acet> tunachat's job is not to handle the intricate networking that
<acet> gets one packet from A to B... it will simply assume that the
<acet> operating system will handle that for it, and that's the way
<acet> it should do it
<acet> xentrac: I'm almost certain there is a way
<acet> the child can talk to the parent through semaphores.
<ick> oh.. ok
<acet> they can also send signals to each other... and I believe they
<acet> maybe can share file descriptors
<xentrac> there may be several ways at the same time... but if we're
<xentrac> writing the code to send and receive UDP messages *anyway*
<xentrac> (and I think we are), why not use it over all?
<ick> xentac: dont get started on that again
<xentrac> ok ick
<ick> ok.. i finished the user list part of my doc
<xentrac> i don't think they can share fd's that have been created after
<xentrac> the fork
<xentrac> doc?
<ick> acet and my ideas on tunachat
<acet> because we're dealing with seperate concepts? a bad analogy:
<acet> "if we make the front door this size, why don't we just be
<acet> simple about it and make the garage door the same size?"
<ick> acet: how o figure out idle times?
<ick> o=to
<acet> ick: specify
<xentrac> acet: why are we dealing with separate concepts?
<ick> acet: how do we find out how long a user has walked away from their machine
<acet> xentrac: whispers, interactive connections, who requests...
<acet> they don't all have to go over the same wires
<xentrac> when I send a message to a client, I'm a point, sending a
<xentrac> message over a channel to a recipient.  When I send a message
<xentrac> to a group, I'm a point, sending a message over a channel to a
<xentrac> recipient.
<acet> ick: client-server's responsibility
<xentrac> ick : ask their client.
<ick> ok... that works
<acet> that too... 
<xentrac> well, the way you do it in IRC is ask their client :)
<ick>                          
<ick> Don't be a Gummy Bear, say something.
<ick> oh oh... big problem!
<xentrac> the only difference between the two recipients is what they do
<xentrac> with the message.
<acet> if you want to find out how long it's been since a person has
<acet> said anything in the channel... ask the client server...
<acet> otherwise ask the client itself if you want to find out if the
<acet> user is doing *anything*
<ick>  /w will get info from the group server (how will group server know about idle 
<ick> times of all users?)
<acet> ick: hrm?
<xentrac> and when I'm a group sending a message to a person, I'm a
<xentrac> point, sending a message to a recipient.  When I'm a person
<xentrac> sending a message to a person, I'm a point sending a message
<xentrac> to a recipient.
<ick> xentrac: you have this way of amking things seem no similar in english
<xentrac> /w everywhere will get info from group server.
<xentrac> (actually, I think we need more parameters for /w to make it
<xentrac> useful on a big net. but that's another story)
<ick> xentrac: that is command creation, one of the last things to do!
<acet> ick: group servers need to keep track of who is activly
<acet> registered, yes? we can do this by having the clients ping the
<acet> group servers on a given interval to prevent them from being
<acet> automaticaly deregistered... group 
<acet> servers can report the amount of time since last ping.
<ick> acet: yeah... taht is how i was going to handle dead clients and client-servers

<xentrac> the only difference between those two last messages is where
<xentrac> they came from... in one case, someone sent me the message, in
<xentrac> another case, someone typed it on me.
<acet> xent: methinks a very big point about tunachat is that it
<acet> prevents big nets... it subdivides itself automaticaly into
<acet> nice bitesized peices that people can deal with
<ick> people like myself :]
<xentrac> acet: that's what *you* think.
<ick> xentrac: nonono! if i can get intelligent clients... you have no choice but sma
<ick> ll nets!
<acet> xent: you think differently?
<xentrac> I'll bet that there will be one or two group servers that have
<xentrac> lotsanlotsanlots of people... and everyone else will be like
<xentrac> you expect.
<xentrac> really?  *drool* how ick?
<ick> xentac: groups will split themselves into the most apropriate manner.... you r 
<ick> germany<-->austrailia example of irc will automatically be fixed iwth two manag
<ick> ers
<acet> xentrac: yea... but still, those one or two group servers may
<acet> never get to the scale of 'big net'
<xentrac> acet: when you ping someone, you could also get information
<xentrac> about their idle time.
<acet> ick: let people cluster together into huge herds if they want
<acet> to... 
<xentrac> yes.
<acet> xent: I ping somebody to find out if they exist... if I want
<acet> their idle time, I'll ask for it
<ick> xentrac: yea.. ping are supposed to be very fast!
<xentrac> btw, I'm not sure that 'mod' and 'group host' need to be the
<xentrac> same...
<ick> grrrrrrrrrrrrrrr
<xentrac> not a bad idea.
<ick> have you never payed attention... they were never going to be the same thing
<xentrac> help help help... I'm being chased by a growling ick
<ick> the mod is automatically manager, but can always pas or split managment with ot
<ick> her users
<acet> <- thinks that if he asks for a ping, he should get a ping..
<acet> not a ping and a box, not two pings... not a ping and a
<acet> toaster... just a ping
<xentrac> in acet's original glossary, they were.
<xentrac> ok ok ok
<xentrac> i'll drop the ping
<ick> now, back to original problem
<acet> xent: might as well considering that whoever runs the client
<acet> server functionaly has total control of the group
<xentrac> sounds like an excellent idea.
<ick> acutally, nevermind... acet solved problem
<ick> iwth ping idea
<xentrac> acet: well, yes.
<ick> /m acet why do they have control... if they leave... the vice-manager takes oer

<xentrac> acet: if tunachat software lets them.
<acet> xent: assume that person running client is ultra-smart hacker
<acet> type and knows how to change his client as it suits him.
<xentrac> acet: if I trust you not to take over a group I'm mod of, why
<xentrac> not let you host it?  You *could* take it over... but that
<xentrac> doesn't mean it's a socially acceptable thing to do.
<*acet*> if they leave, the group dissolves... unless there was some
<*acet*> pre-arranged agreement that everybody else in the group knows
<*acet*> about where "if this group dies, connect to this person"
<ick> /m acet i figured that it would just be handed down... like icb moderation
<acet> xent: parse error.. 
<xentrac> if person running client is ultra-smart hacker type and
<xentrac> changes client and uses that to take advantage of other
<xentrac> people, editing messages as they pass through and whatever,
<xentrac> then *don't pass management to them*.
<*acet*> that could be arranged too... but you must consider that if
<*acet*> the person running the client-server leaves, so does the
<*acet*> client-server.
<xentrac> if certain people start hacking their clients so they can
<xentrac> steal mod of groups, people won't let them host their groups.
<ick> stop!             
<ick> i dont htink i ever explained vice-managment... i probably thought i did, but f
<ick> orgot to tell you
<acet> xent: beyond parse error... I no longer know what you're
<acet> talking about
<xentrac> there are definite advantages to having chanops not ===
<xentrac> group-hosts.
<ick> when person creates group... they become manager
<xentrac> i read acet's glossary.
<xentrac> parse error where?
<acet> guh, xent.. have you decided to strictly use your vocab?
<ick> chanops?
<ick> hehehe... xentrac is silly... english boy english!
<xentrac> sorry... i tend to use irc vocab
<ick> when second person eneters group they automatically becoe vice manager 
<xentrac> group-host is what hosts the group.  chanop is mod.  host
<xentrac> means do the message forwarding thing.
<acet> use tuna vocab where possible and please be consistant...
<acet> otherwise it's a nightmare deciphering what people are saying
<ick> xent: tunachat vocab for host is manager, and chanop is moderator
<acet> ick: why?
<ick> acet: vicemanager had no power, they are jsut someone to hand control over to
<xentrac> ok... acet's glossary never mentioned 'moderator'
<ick> xentrac: that was stolen from icb
<xentrac> why does there have to be only one moderator?
<ick> xentrac: who said that there has to be only one!
<xentrac> ick: yes I know
<acet> the person running the client-server is king... whatever they
<acet> say, goes. that person can decide that *nobody* has any powers
<acet> over anybody else... it would be silly to do this, but it
<acet> could be done. (and since that 
<acet> person controls the client-server, he can change the rules at
<acet> any time). People who connect to his client server agree to
<acet> play by his rules for all maters concering that group
<xentrac> icb said there has to be only one.
<ick> i said i stole term from icb, not what it meant!
<ick> i see acets points
<acet> xent: there could be multiple ones... but still only one
<acet> person would be running the client-server. 
<ick> nonono!
<ick> here can be more than one manager
<xentrac> acet: one of the reasons I prefer icb to irc is that here, the
<xentrac> people who run the server *don't* use that de facto power to
<xentrac> make the rules.
<acet> xent: eh?
<xentrac> they don't kick people off the server for insulting each
<xentrac> other.
<xentrac> they only kick people off the server for hacking software.
<acet> xent: but they do kick them out of the channel... 
<acet> xent: you possibly can be kicked off a group server... but why
<acet> would anybody do that? 
<xentrac> acet: yes, but ThunderStorm won't kick me out of a channel
<xentrac> unless he's mod... even though he could change the software so
<xentrac> he *could*.
<acet> xent: sure
<xentrac> it's not necessary for the person who controls the
<xentrac> client-server to have life-and-death power.
<acet> xent: remember, tunachat has one server per channel... that's
<acet> it. if you get kicked off a tunachat client-server, you get
<acet> kicked out of one group (aka channel... stop talking irc,
<acet> you're getting me confused now :) 
<acet> that's it.
<xentrac> it would make life much easier if the manager didn't have to
<xentrac> be the moderator.
<acet> YES IT IS
[=Change=] eponine (eponine@am.ucsc.edu) entered group
<xentrac> why?
<xentrac> sorry.  
<eponine> hi :)
<xentrac> actually, I redefined channel in my papers :)
<eponine> your group has an interesting topic
<xentrac> it's a way for a message to go from one point to another... it
<xentrac> includes groups, ears, circuits, proxies, and probably other
<xentrac> things.
<xentrac> yes eponine.
<eponine> heh
<eponine> yes.
<xentrac> look: I agree that it's always *possible* for the person who
<xentrac> runs client-server to kick people out.
<eponine> well, it was moderated, so i decided to jump in and see you
<eponine> you all are
<eponine> see who you ...
<xentrac> I'm not sure that it's always *desirable*.
<ick> hrlu
<acet> because ultimatly that one person is responsibile for the
<acet> survival of the group... therefore that person is boss *IN
<acet> THAT GROUP*... that person can choose to never exercise those
<acet> powers over anybody else... he can also 
<ick> helu
<acet> tell his client-server to let other people exercise those
<acet> powers... it's all the choice of the manager
<ick> ugh!!!!
<ick> stop!
<ick> its scrolling faster than i can read!
<ick> STOPPPPPPPPP!
<xentrac> you stop.
<ick> /boot xentrac
<*acet*> I don't think this is going anywhere
[=Boot=] xentrac has been booted
[=Change=] xentrac (xentrac@altona.math.unm.edu) just left
<eponine> haha
<acet> see xent, ick was the mod of the group.. ;)
<ick> eponine: its not normally like this
<eponine> bet he knows now
<ick> heheh
<ick> acet: out of all this.. and you still make me laugh... you're amazing!
<eponine> ok
<eponine> sure
<eponine> :)
<acet> it's usually *MUCH* sillier! :)
<eponine> it's ok...it all seems good
[=Change=] xentrac (xentrac@altona.math.unm.edu) entered group [NR]
<ick> shhhhh, im reading
<xentrac> *sigh*
<ick> acet: make that comnet again
<eponine> what's the weather in alb. like right now
<ick> comnet=comment
<acet> ick: I have a hard time taking anything seriously... try it
<acet> some day, you can't offend me.. it's neat
<xentrac> *laugh*
<ick> eponine: dark :]
<eponine> hmm
<eponine> i might be going there on exchange next yr
<ick> /w .
<ick>  
Group: ishiboo  (mvl) Mod: ick           Topic: DontPutURHandWhereUWantURFace 
   Nickname        Idle  Sign-On  Account
   acet              -    4:31pm  matth@emmy.nmsu.edu       
  *ick               -    8:45pm  nirva@caffeine.zynet.com       
   eponine           -   11:19pm  eponine@am.ucsc.edu       
   xentrac           -    9:05pm  xentrac@altona.math.unm.edu   (nr)
<acet> hrm, comment:" "see xent, ick was the mod of the group... :-)"
<eponine> if ig et in - i get notified on friday
<eponine> ick is such a lovely name
<ick> eponine: thanks :P
<xentrac> why is the person who runs the software responsible for the
<xentrac> survival of the group, if everyone else also has the software
<xentrac> and could host the group?  The survival of the group (or
<xentrac> anything else) depends on the users.
<ick> xent: i said hold on.. i am logging this for synk and i want to read above... i
<ick>  think i found problem
<eponine> ok i better go
<xentrac> bye
[=Change=] eponine (eponine@am.ucsc.edu) just left
<acet> xent: grr... silly puppy... ok... where do all the users
<acet> connect to to be in the same group?
<xentrac> ok.
<ick> ugh...
<ick> ok.. found one problem!
<ick> what the hell is a channel?
<ick> one answer from both of you... i am losyt
<xentrac> channel in the above conversation sometimes meant 'group'
<acet> channel == group
<ick> sometimes!?!?!?!?!
<ick> xent: what did you redefine it as?
<acet> when I said it, it meant group :)
<xentrac> sometimes it meant (from me) 'a way to get a message from one
<xentrac> point to another'
<ick> ugh... that in tunachat would be know as a passage... quite simple isn't it?
<xentrac> a useful abstraction
<acet> usefull? 
<ick> passage or route
<xentrac> yeah... if you want to send a message to someone, you look at
<xentrac> the channels you have available that go to that person, you
<xentrac> pick one, and you send it.
<xentrac> ick: where do you get all these terms?  did acet update his
<xentrac> glossary?
<ick> xentrac: do you understand my terms?
<xentrac> ok... passage it is
<ick> when i say take the shortest route to the to the manager of the client-server..
<ick> . you knwo what i mean, irhgt>
<acet> <- never heard 'passage'... but has no problems with it
<xentrac> yes... but you're talking about it as if it's been defined for
<xentrac> a while.
<ick> xentrac: think simple terms that only have one meaning!
<xentrac> yes.  even with the doubled 'to the'
<acet> <- considers by default 'channel' and 'group' to mean the same
<acet> thing... this is thanks to spending time both on irc and icb
<xentrac> sorry :(
<ick> xentrac: :)
<ick> acet: same here
<ick> xentac: did you actually expect anyone to understand you "other" meaing of chan
<ick> nel
<acet> maybe we ought to Capitalize all Special Words... ;-)
<xentrac> if the person who's running a particular group shuts down, the
<xentrac> people who use the group will make a new one, easily.
<acet> xent: will they?
<ick> acet: good idea, i am doing that in my doc
<xentrac> maybe we ought to encapsulate them in {} :)
<xentrac> ick: yes, because i explained it twice before in this chat.
<acet> xent: not transparently they won't, unless they have some
<acet> agreed upon place to move the group to.
<acet> heh
<xentrac> acet: this is true.
<ick> thats why i had vice-manager idea
<ick> that is automatic hand down
<acet> xent: ok, we all can agree that if the client-server dies...
<acet> that group dies as well.... someone might come by later and
<acet> create another group *like* the first one, but it's still not
<acet> the same group... right?
<xentrac> but that's kind of like saying, "I'm bigger than you; I can
<xentrac> make this door hard for you to go through.  Therefore, I can
<xentrac> and should ask you for money to let you do it."
<xentrac> acet: yes.  I agree.
<acet> xent: I can say "fuck you, I don't need to go through your
<acet> door".
<acet> xent: that's kinda like charging admission for your house.
<xentrac> acet: exactly... but the door will be more useful if it's not
<xentrac> generally accepted for people to do that.
<ick> what the hell are you atlking about doors and houses? i am lost again
<ick> i think i need to go to sleep
<acet> actually, the door will be more *popular* if it's free... so,
<acet> if you want a popular door, don't charge admission.
<ick> addmission?!!?!!?
<acet> ick: a big of sillines has entered the discussion
<ick> acet: oh.... ok
<acet> ick: er, 'bit'
<xentrac> the point isn't the money... the point is the de facto vs. de
<xentrac> jure power thing.
<ick> acet: no.. i think big was more appropriate
<ick> money! this is way too silly
<acet> xent: if I don't have complete control over what goes on in my
<acet> house (remember kids, in this analogy, house == group), I
<acet> can't very well call it my house can I?
<ick> beep me when silly conversation is over
<acet> ick: yes it is. but I think this targets a fundamental
<acet> misunderstanding philisophicaly wise
<xentrac> If I have a gun, I have the power to enforce whatever
<xentrac> standards of behavior on my neighbors that I want.  But it's
<xentrac> better to give such power on the basis of, say, voting... and
<xentrac> not allow the people with the de facto pow
<xentrac> er to use it.
<acet> are you saying that if you had a gun, you would rather prefer
<acet> that you didn't have the capibilty to fire it?
<xentrac> acet: probably.
<xentrac> hmmm...
<acet> that the act of firing the gun was actually out of your
<acet> hands... 
<acet> that perhaps a special session of congress should be held to
<acet> vote on the issue of firing your gun for you?
[=Beep!=] acet sent you a beep.
<ick> helu
<ick> guns!
<*acet*> it's still silly, but it's highly amusing! ;-)
<xentrac> no, I'd prefer that I (and everyone else) only fired it when I
<xentrac> was within the constraints of social rules... like, a burglar
<xentrac> had broken into my house.
<ick> burgularly!
<ick> brb          
<xentrac> acet, now you're bringing in big, bulky, slow things... which
<xentrac> won't be a problem on tunachat.
<acet> so you would rather the gun have the capibility and
<acet> intelligence to make a moral decision judging wether what you
<acet> are aiming at deserves to be shot?
<xentrac> perhaps.  something like that.
<xentrac> I'd prefer that the gun not fire when I'm pointing it at
<xentrac> someone that isn't attaking me.
<acet> actually, xent, I'm literally rolling in my chair laughing
<acet> because this is possibly the most amusing concept I've
<acet> considered in a long time... it's up there with douglas adams
<acet> sillines
<xentrac> *laugh*
<xentrac> let me postulate a social scenario, based on how I think
<xentrac> things should work.
<acet> if the gun knows who deserves to be shot, it doesn't need you
<acet> pulling the trigger... it can go along on it's happy way
<acet> shooting only the people it feels fit to shoot.
<xentrac> A, B, C, and D are members of a group.  A is a manager; B is a
<xentrac> moderator.
<xentrac> A decides to take over the group, deopping B.
<xentrac> B leaves the group and whispers his own client-server address
<xentrac> to C and D.
<acet> in reality though, the gun is a *tool*... as is a tunachat
<acet> group. The gun is a tool to kill people, the group is a tool
<acet> for people to talk to each other.. (possibly talking about
<acet> killing people)... I don't think my 
<acet> hammer should make decisions on how I build my house... I
<xentrac> (deop is to take mod away from)
<acet> ok
<xentrac> B starts the group anew.  A might, perhaps, come in... but A
<xentrac> isn't going to be invited to take over management again.
<acet> fine... A is an asshole then, or maybe B deserved it...
<acet> *shrug*... 
<ick> back
<ick> gonna stop silliness now...
<xentrac> but with the separation of powers between manager and
<xentrac> moderator, administrative and command... you could, for
<xentrac> example, relocate the client-server in a more central
<xentrac> geographic location than the moderator is.
<ick> tell me what was rong with the vicemanager idea.. i have still got no comments 
<ick> about it
<*acet*> are you making a capture of this for synk?
<ick> /m acet no, but i can
<ick> STOP! I AM GOING TO SELECTION OPY IT PAGE BY PAGE... SAY NOTHING!
<*acet*> do... synk will probably like the bit about the guns ;)
<xentrac> I think it's a good idea... although an 'order of succession
<xentrac> of management' might be a better idea.
<xentrac> in case the vice-manager crashes too.
<xentrac> acet: exactly.
<acet> xent: yes yes yes... that's all possible, but it's up to the
<acet> person running the client-server to impliment it... or at
<acet> least tell the client-server program to impliment it...