Files changed (28)
+Saturday 23rd February 2002, 16:00 GMT (root zone) (11:00 Central Time, 10:00 Eastern time, 09:00 Montain Time, 08:00 Pacific time).
+5) The rights of users to promote and demote other users, specific rulesets based on a draft by Jeff
+Feb 23 16:01:09 <DDRP> Good morrow programmers. Thankyou for attending, I thought attendance might be low.
+Feb 23 16:03:32 <Jeff> Termination. Should you breach this Agreement, your right to use the Service and the Software shall terminate immediately and without notice. You may also terminate this Agreement by simply discontinuing use of the Service and the Software. In the event of any termination of this Agreement, the restrictions on your use of the Software and Service as set forth in "Restrictions on Use" shall survive such termination, and you agree to be b
+Feb 23 16:04:28 <Jeff> Restrictions on Use. You may not redistribute the Server (Should you Have It) or provide others with access to the Service (including, without limitation, providing third parties with access to the proprietary OverChat database). You may not create or use any software other than the Software Approved to access the Service, without the express written authorization of the Server Admin or the Committee. You may not modify, reverse engine
+Feb 23 16:05:08 <Jeff> You may not adapt, alter, modify, translate, or create derivative works of the Software (including without limitation the communications protocols for the Service) without the express written authorization of DDRP. Because OverChat's ability to offer the Service free of charge is dependent, on whole or in part, on generating advertising revenues from the Service, you may not block, disable or otherwise affect any advertising, advertisemen
+Feb 23 16:05:29 <Jeff> You may not register with and log on and off the Service, send and receive instant messages via the Service or identify when other Service members are online except through use of Approved Software and Service and in conformance with the terms and conditions of this Agreement. You may not collect or solicit screen names or password information. Finally, you may not authorize or assist any third party to do any of the things described in
+Feb 23 16:06:35 <DDRP> Well I thought that the onlu ammendment was termination. The above seem sane. Would it be possible for you to do a diff/patch of this?
+Feb 23 16:14:05 <DDRP> Since TK is also starting a business I don't think we can expect OC32 to be one of the first clients to be finished and downloadable.
+Feb 23 16:14:29 <DDRP> However, we'll bring this agenda item up again next week or whenever we decide to meet again.
+Feb 23 16:14:46 <DDRP> Does anybody else have anything to say about OC32 before I move on to the next agenda item?
+Feb 23 16:15:29 <DDRP> Oberchatten has not been worked on for at least a week. It uses the old TX/RX logic and seems to work well using it
+Feb 23 16:15:53 <DDRP> in fact I sometimes considering raping it's code for the server but that would be a bit hard because the client side code is very much simplified
+Feb 23 16:16:49 <Jeff> it would greatly improve looks at least which are not a concern at this point
+Feb 23 16:18:11 <DDRP> 5) The rights of users to promote and demote other users, specific rulesets based on a draft by Jeff
+Feb 23 16:18:36 <DDRP> It is a shame the committee is so quiet and people don't want to have their say
+Feb 23 16:18:53 <DDRP> If you can get a proposer and seconder for your rulesets, Jeff, they go through
+Feb 23 16:20:10 <DDRP> pepsi: I'll give you 10 mins to read them if you feel you want to have a say on it
+Feb 23 16:26:08 <DDRP> 6) Server performance, one thread Vs many threads based on the event based model
+Feb 23 16:26:30 <DDRP> This is something I know a reasonable amount about because I designed the server.
+Feb 23 16:27:56 <DDRP> With the other system of one thread per user we eliminate the problems we've been having with packet compilation
+Feb 23 16:28:37 <DDRP> Now a lot of programmers spit on blocking sockets and it also means that if there are 1,000 users there are 1,003 threads
+Feb 23 16:29:11 <DDRP> Does anybody know much about this and could we build a system where the server admin could decide at compile time which system he preferred?
+Feb 23 16:30:31 <DDRP> When there are no server events to process the server waits for one second before it can process anymore
+Feb 23 16:31:29 <pepsi> if its busy wouldnt it make it hard for users on lowbandwith such as myself to connect?
+Feb 23 16:32:24 <DDRP> since you would generate quite a few lone events which may be a second apart
+Feb 23 16:33:27 <DDRP> then we can return to this issue another time once we see first hand what performane is like.
+Feb 23 16:34:10 <DDRP> OverChat is officially development software. I don't say it's secure. I'm sure it's not
+Feb 23 16:34:27 <DDRP> Server admins must run the server as an unprivelleged user in a so called sandbox.
+Feb 23 16:36:14 <DDRP> When mailall/ocreg/ocquery mailed a user with that address it would erase the system or any files accessable to the process at the same time
+Feb 23 16:36:34 <DDRP> the mail would have probally failed but the desired effect to destroy the OverChat server would have succeeded.
+Feb 23 16:37:51 <DDRP> Is this exploitable? Possibly. I have other bugs to fix first to get the system working first though,.
+Feb 23 16:38:05 <DDRP> Does anybody have anything to say about OverChat's security before I move on?
+Feb 23 16:39:37 <DDRP> It means reading many bits of redundant information just to find the piece we are looking for.
+Feb 23 16:40:30 <DDRP> I have created a new database format and a utility called convdb2 to convert the database
+Feb 23 16:41:09 <DDRP> This will mean one has to send SIGHUP to the process to get it to reread the server config file
+Feb 23 16:42:31 <DDRP> Nearly a year ago I went out to the garages out in the sun, was suffering a little hayfever and had few tissues =/
+Feb 23 16:42:53 <DDRP> but I began to write a fantasy down on paper, a secret protocol I didn't have a name for
+Feb 23 16:43:22 <DDRP> I had no knowledge of networking or threading though. It was a bit flawed but not bad enough to need a total redesign.
+Feb 23 16:43:54 <DDRP> It's been difficult building the system, and because people don't seem to understand my source nobody can help. Those who can help don't have the time.
+Feb 23 16:44:33 <DDRP> I wish to thank especially the peripheral help of some members of the committee and TK for his client which I believe still can succeed if he finds the time
+Feb 23 16:45:11 <DDRP> But I wish to give greatest thanks of all to Haesu without which we would still have no permanent high bandwidth central server to store the server on.
+Feb 23 16:45:49 <DDRP> We have come so far and we're very close to making it work. There are just small issues to resolve now before I mail out to everyone that the system is publically open
+Feb 23 16:46:07 <DDRP> Don't get impatient or think it won't work because I can promise you all it will.
+Feb 23 16:46:26 <DDRP> Those who believed in it from the beginning, like Jeff and TK will be rewarded with high privellege.
+Feb 23 16:46:50 <DDRP> 10) Speaker: Representitive of TowardEX (our host), the Superior Mystic Controller
+Feb 23 16:49:58 <pepsi> albeit i havent contributed as much as jeff and ian but i have always supported overchat
+Feb 23 16:53:01 <acemiles_ed> Saturday 23rd February 2002, 16:00 GMT (root zone) (11:00 Central Time,
+Feb 23 16:57:32 <DDRP> I propose that this meeting is timed in GMT, even during summer time in the UK
+Feb 23 16:57:45 <DDRP> and that you will all have to do your own conversions as you know what your time is not me
+Feb 23 17:02:32 <pepsi> dave send out a memo that if anyone feels something should be discussed email firstname.lastname@example.org
+Feb 23 17:04:07 <Jeff> I apologize for leaving before the close, but I must head out, I have work soon
+Feb 23 17:04:24 <smat> well if the agenda does not raise issues that directly involve a member, that the meetings arent mandatory
+Feb 23 17:04:32 <Jeff> Im very happy to see you all here, thanks for amending me proposals! see ya!
+Feb 23 17:05:29 <DDRP> Meetings are mandatory but somebody who doesn't attend meetings isn't going to make themselves that popular with the chairman
+Feb 23 17:06:02 <smat> david i am not gonna waste a precious day off in a meeting at which i am of no use
+Received: from n10.grp.scd.yahoo.com [220.127.116.11] by donald.fasthosts.co.uk (SMTPD32-6.00) id AB3949A00D0; Fri, 22 Mar 2002 16:26:33 +0000
+Received: from unknown (18.104.22.168) by m10.grp.scd.yahoo.com with QMQP; 22 Mar 2002 16:25:01 -0000
+Received: from unknown (HELO donald.fasthosts.co.uk) (22.214.171.124) by mta1.grp.scd.yahoo.com with SMTP; 22 Mar 2002 16:25:00 -0000
+Received: from hotmail.com [126.96.36.199] by donald.fasthosts.co.uk with ESMTP (SMTPD32-6.00) id AADA49400D0; Fri, 22 Mar 2002 16:24:58 +0000
+Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Mar 2002 08:24:57 -0800
+Mar 23 19:09:39 <pepsi> First on todays agenda we shall discuss Should OverChat groups ignore/support/enforce instances.
+Mar 23 19:10:17 <DDRP> My opinion is that instances cause a fight and needless retries of people attempting to re-enter a chat
+Mar 23 19:11:19 <DDRP> So what I am saying is that should we even support them, let alone enforce them
+Mar 23 19:11:26 <h00t`> I agree with DDRP, in that if an ignore feature is applied to the service, a person has the ability to limit what traffic is viewed while in a particular room.
+Mar 23 19:11:37 <pepsi> thinks that when the room is being created that the creator should be able to choose the amount of users allowed
+Mar 23 19:13:41 <DDRP> If that does change it will only be a maximum for technical reasons like 2048
+Mar 23 19:14:19 <pepsi> does anyone else like the idea of the creator being able to choose the amount of maximum users
+Mar 23 19:15:29 <h00t`> Would it make a difference if there are 200 in one room, or 40 in 5 rooms, wouldn't the load be the same?
+Mar 23 19:15:30 <blahdy-bleh> I think what we must do is create seperate servers for chat services only.
+Mar 23 19:15:30 <DDRP> but when we have that many users, hopefully we could make cash from it to pay for bandwidth somewhere
+Mar 23 19:15:50 * SBeast likes pepsi's idea, its like when an irc operator limits the max uses in a channel innit
+Mar 23 19:16:24 <DDRP> Yeah I like the design issue of having seperate chat servers for each exchange
+Mar 23 19:16:29 <blahdy-bleh> Bandwidth is quite cheap in this area if more bandwidth needs to be alloted for overchat network
+Mar 23 19:16:42 <DDRP> it would of course cause possible security implications and a lot of work but it may be worth it in the long run
+Mar 23 19:16:58 <DDRP> perhaps making chat a part of overchatd and then later rewritng as a seperate exchange as demand grows
+Mar 23 19:18:07 <blahdy-bleh> but first of all the next critical part after IM/ocquery fix is being able to network-link the official servers
+Mar 23 19:18:58 <DDRP> Yeah. I really have no clue how we'll do it but I know it has to be done. It will need to be done over SSL
+Mar 23 19:19:26 <pepsi> SBeast: if someone would seccond you agreeing with me then committee will have passed my idea =X
+Mar 23 19:19:38 <blahdy-bleh> then the supreme mystic controller (me) can filter out that port for rest of the network except the server subnet ;)
+Mar 23 19:21:58 <blahdy-bleh> and then the switch that brings the overchat LAN to the internet filters out critical/confidential port numbers that is used to link the servers.
+Mar 23 19:22:02 <DDRP> I think I can do it but I'm still confused about migration, which is used by AIM, for example to actually move a user to another server if demand grows, it's done absolutely transparently, I mean how does one move somebody's socket to another machine?
+Mar 23 19:22:08 <blahdy-bleh> so that no one from the internet can intercept the server operations.
+Mar 23 19:24:17 <h00t`> seems impossible for some users to be on one server, other users on another, and all be in the same chat. Am I wrong?
+Mar 23 19:26:50 <blahdy-bleh> the login servers are where they authenticate into, then login serveres makes sure that data base servers are updated to ensure that user is 'logged in'
+Mar 23 19:27:07 <blahdy-bleh> then IM and chatting servers would query the database servers to actually find online users
+Mar 23 19:27:43 <blahdy-bleh> so it doesnt matter if a chatting server goes down, the users are logged into database servers anyway
+Mar 23 19:28:19 <h00t`> must be so, I remember times when IMs were not available, and buddy lists even, but general chat rooms were accessable.
+Mar 23 19:28:47 <DDRP> I've got to ensure double logins are impossible of course, which they currently are not
+Mar 23 19:29:13 <blahdy-bleh> so we'd eventually have seperate set of servers for database, login, and chatting+IM
+Mar 23 19:29:35 <blahdy-bleh> the login servers are the ones that interact with users to let them into our network
+Mar 23 19:29:45 <blahdy-bleh> the users login thru the login servers, then login servers update the databases on the db servers
+Mar 23 19:31:08 <blahdy-bleh> try to make them link to a port otehr than 3277 or whatever we use for users
+Mar 23 19:31:50 <smat> if you make it clone-free does that mean that users couldnt have multiple nicks, or does that mean they simply couldnt use more than one nick?
+Mar 23 19:33:03 <DDRP> There is a subconversation going on here where some of you don't understand the clone concept
+Mar 23 19:35:19 <h00t`> DDRP: that references what is probably the answer to a question I had, if someone has the resources, i.e. bandwidth etc, could they possibly bog down the system by entering the same nick numerous times?
+Mar 23 19:37:37 <blahdy-bleh> well i dont think clone-free is something to really worry about right now though.
+Mar 23 19:38:56 <smat> my suggestion is that you programmers work on this and see what you can come up with for the next meeting
+Mar 23 19:39:54 <h00t`> The commitee needs to be aware of the security concerns, a good dose of collective common sense can never hurt.
+Mar 23 19:40:34 <DDRP> A committee ignorant of the mechanisms in place is an ignorant and foolish one
+Mar 23 19:41:41 <h00t`> Wasn't the origanl issue at hand "allowing or disallowing size limits to chat"?
+Mar 23 19:42:09 * SBeast has an idea, prolly a bag-o-****e but here go's ... when the clients log on, could they not drop a token or summut in some temp folder, and delete it when the client disconnects, and every time the user connects to an oc server, it looks for a token in some predefined location, if it finds it, it realises they are logged on already and don't let them access, kinda like cookies etcetc >=/
+Mar 23 19:42:49 <blahdy-bleh> file system operations on tons of user logins per second = disaster :-/
+Mar 23 19:43:05 <DDRP> You don' need a token as a file, it will be marked in the database under their nickname
+Mar 23 19:43:15 <h00t`> If demand on the resouces of the server network is not an issue, I think it's unneccessary to deal with it right now, in leiu of more important security issues.
+Mar 23 19:44:05 <blahdy-bleh> Excuse me all committee members, but I must brb for about 10 minutes due to a critical issue that has just happened.
+Mar 23 19:44:42 <pepsi> sorry for leavin my step dad was beatin the fsck outta some d00d who littered in front of my house
+Mar 23 19:49:10 <h00t`> We could all bookmark a particular web page, which easily supplies the mean to adjust to time zone differences.
+Mar 23 20:12:52 <blahdy-bleh> As many of you know, TowardEX has partnered with Daybologic in order to provide backend/network and connectivty support for OverChat
+Mar 23 20:13:26 <blahdy-bleh> TowardEX will be making sure following things are in highest state of mind during the Overchat operations:
+Mar 23 20:14:28 <blahdy-bleh> The security of the servers will be enforced by putting overchat servers on a seperate network when OC rolls out.
+Mar 23 20:14:34 <blahdy-bleh> The overchat servers will eventually get its own layer3 switch on the network
+Mar 23 20:15:10 <blahdy-bleh> In addition, ICMP-port-unreachables and certain icmp+udp packets destined to overchat servers will be filtered out from upstream backbone to ensure security aginst DoS
+Mar 23 20:16:30 <blahdy-bleh> the Cisco router has already been configured to drop any ping floods or syn floods that are greator than 8Kbps from single IP.
+Mar 23 20:17:27 <blahdy-bleh> Later I do believe we will have more contributors and coding developers for OC
+Mar 23 20:17:48 <blahdy-bleh> i do believe we will eventually maintain a secure/private cvs servers for all the contributors to organize the codes
+Mar 23 20:18:18 <blahdy-bleh> for such purpose, there is what's called IP-Propagation.net, an international private VPN backbone developped by Towardex and few other partners
+Mar 23 20:18:32 <blahdy-bleh> its specifically designed for private research such as this OC development.
+Mar 23 20:18:58 <blahdy-bleh> so we can certainly make use out of that later if we have a need to bring all developers together into single network.
+Mar 23 20:20:00 <blahdy-bleh> IP-propagation.net network stretches from Texas, US and all the way into UK
+Mar 23 20:21:15 <blahdy-bleh> so as you can see, there are works being doen to help developers get together and get their research works done.
+Mar 23 20:27:24 <blahdy-bleh> then ur system running cvsup will find differences between the one server has an dthe one you have
+Mar 23 20:28:19 <DDRP> will it work both ways, so if I modify source your copy of the server will be modifed?
+Mar 23 20:29:34 <blahdy-bleh> of course it will be sort of slow over modem, but once you have cable, it will not be slow.
+Mar 23 20:30:04 <DDRP> OK but this is complex stuff isn't it? What are the short term solutions for database backup incase we lose it this week for example?
+Mar 23 20:30:32 <blahdy-bleh> in fact we use it all the time to backup towardex customer files and dns data
+Mar 23 20:34:06 <DDRP> Side note: If people don't understand what the levels are, telnet to the query server and type cll
+Mar 23 20:39:29 <pepsi> is there anything else that the committee feels we need to discuss this week?
+Mar 23 20:40:59 <pepsi> is there anything else that the committee feels we need to discuss this week?
+Mar 23 20:42:37 <DDRP> OK well, I propose that we might want to switch the server into socket blocking mode and enable a thread per user
+Mar 23 20:44:10 <DDRP> Haesu needs to comment he's the only other person who knows anything about it
+Mar 23 20:46:44 <h00t> <DDRP> OK well, I propose that we might want to switch the server into socket blocking mode and enable a thread per user
+Mar 23 20:47:03 <blahdy-bleh> to me, i dont really see much issues right now except for that tx/rx packet compiler stuff
+Mar 23 20:47:57 <DDRP> My dad's off down the pub tonight but I'm going to skip that and try to sort this issue once and for all >=o
+Mar 23 20:51:30 <smat> i'll just email the group with what i wanted to say, no need to take the committee's time up with it
+Mar 23 20:52:31 <smat> oh it was just something to do with tshirts for those who have been waiting, no biggie
+Mar 23 20:53:57 <DDRP> OK. I shall make the log part of the tree and post an address the the list. I'll post the Superious Mystic Controller's speech to the group seperately as it is most important
+Mar 23 20:56:03 <smat> since it could be cosmically disruptive to have it on the 27th since that's a full moon
+Mar 23 20:58:37 <pepsi> if anyone has an idea or object to be discussed email it to email@example.com
+Mar 23 21:02:41 --- pepsi has changed the topic to: OverChat Meeting 3 will be held on 4/20/02 @ 1 pm US central time...