KnightChat

The noble Order of the Knights of Jubal traces its origins back to the Year Two Thousand A.D., when a group of distinguished persons of good and true character, founded the order to promote chivalry and honour. The order takes its name from our leader, Alexander Jubal McRae, who on two (so far) occasions has been seriously injured, in one case fatally, defending an innocent woman from attackers.

Moderators: Jamie, Greg

Postby Greg on Tue Jun 05, 2001 2:54 am

There isn't a link to the program because it doesn't exist yet. Technically speaking, neither does the protocol.<P>I had started developing this a few months ago, designed the protocol, didn't like the architecture of it, scrapped it, started redesigning it and then work started getting busy and I haven't finished it.<P>So, since such a large number of people have expressed interest, I've decided to throw it out as an open protocol. The Order can develop it as a group, and it can be communally owned (in the spirit of Open Source Software).<P>Give me a day or so to collate my notes, and I'll post what I have of the architecture and protocol up here.<P>Regards,
Sir Gregory<P>------------------
-------------
Sir Gregory of Melbourne, KI
Knight of the <A HREF="http://www.ivbalis.org" TARGET=_blank>Order of Jubal</A>
"What I tell you three times is true..." - The Bellman
Greg
Grand Poobah Keenspotter
 
Posts: 368
Joined: Wed Nov 22, 2000 12:00 am
Location: Reservoir, Victoria, Australia

Postby Lothar Sauvage on Tue Jun 05, 2001 5:40 am

Woohoo! Fellow Penguin!!! Gimme some flipper! *ahem*<P>Good to see a fellowman who uses good software and codes it better. On a side note, I have both a Linux coder and a VB coder on staff. We can all hit it and bang out both the Linux and Windows version pretty quick. Does anyone know Java or do Mac?<P>Regards,<P>Lothar Sauvage, CI
Lothar Sauvage
Keenspotter Supreme
 
Posts: 52
Joined: Fri May 18, 2001 11:00 pm
Location: Southern Colorado

Postby Vaughn on Tue Jun 05, 2001 11:32 am

I've seen some references to this program here, although I have so far been unable to procure a link or indeed any further information.
How is multi-platform support going?
If you need help I'm a fair coder, and could code up a Linux client for you.<P>In fact, if someone can give me a link to the protocol description I'll do it wether you want me to or not. (I need the practice!)
User avatar
Vaughn
Grand Poobah Keenspotter
 
Posts: 441
Joined: Sun Apr 01, 2001 12:00 am
Location: Lost in infinite time

Postby Greg on Wed Jun 06, 2001 12:36 am

Hi there!<P>OK - I've got what notes I have together on the KnightChat protocol. I've divided it in to two sections, a statement of requirements, then a technical section. Unless you're programming the system, I suggest you stick with the Statement of Requirements.<P>For the record, I'm a big fan of the penguin myself, but I haven't got around to cutting any code with Tux yet.<P>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
<B>KnightChat Statement of Requirements</B><P>The Knights of Jubal require a piece of real-time messaging in which to hold the Conclave. In keeping with the motto of the Order, "Be virtuous and cool.", we have decided it would be the collest option to develop the software in-house, bearing the E.I. name and logo.<P>The program must provide an authentication service (to keep non-members out), and have a means of restricting a session to Knights only, or All members. The ability to have multiple chat rooms (similar to IRC) is a required function, but may be added later. <P>Additionally, we require the system to be able to tally and record votes on propositions (in the form of an AYE / NAY). <P>Some form of data encryption (probably two-key DIffey-Hellman) may be added as an option later.<P>The server software must produce a full-text log of each session, including each vote and the results of the vote. All votes must be timestamped in UTC (GMT) time using the ISO date format.<P>-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-<P><B><I>WARNING: GEEK STUFF WILL FOLLOW</I></B><P>KnighChat is divided into two modules, a client and server. The working title for the client is, of course, "Knight Chat". The server software is called "Round Table". It is envisaged that the server name will be manually configured by the user.<P>It is important to note that this document defined the messaging protocol between the client software and the server software, not necessarily the commands entered by the user at their terminal. The specifics of the user interface reside in the province of the individual programmer.<P>The messaging protocol is text based, operating on a TCP port somewhere in the 8000s (I haven't picked a specific one yet, but I've been using 8057 for development.) At present, the protocol is based on standad ASCII text. There are no plans to support Unicode at this time.<P>The client initiates a connection on the port and sends a <B>HARK</B> command (in accordance with RFC 2795). The server will respond with <B>HARK <client's IP address></B>, to verify a connection. At this point, the server will also verify that the client's IP address has not been blacklisted. If it has, the server may respond with an <B>ERROR <description></B> and close the connection. (The ERROR response may be sent at any time).<P>The client will then send an <B>INIT <username></B>. Some form of authentication (which I haven't thought about yet) will follow.<P>After the authentication has occurred, the server may send an administrator-defined message of the day using the messaging commands (detailed below). The server will also broadcast a message saying that the user has entered the room.<P>Messaging may be done as a broadcast message (to all logged in users), or to a specific user. Broadcasts are done using the <B>SPEAK <colour> <text></B> command. This speak command is broadcast to all connected users exactly as it was received. Therefore, the implementation of the <colour> attribute is determined the client. However, this should normally be in the hexadecimal format #RRGGBB, as in the HTML standard. Named colours are not supported. <P>Note that the server transmits the response exactly as it is received, without adding an originating username. The responsibility of adding the sender's name is part of the client software. (This is necessary to support usernames that contain spaces and punctuation, and avoid the need for unneccessary delimiters). This will normally take the form of <I>username</I>: message as typed by user<P>User-to-user messaging is done using the format <B>WHISPER <colour> <username> MSG <text></B>. The server (which maintains a dynamic internal table of which users are on which connections) parses this command to determine which connection the destination user is on. It will then send a message in the form:<P> <B>SPEAK <colour> <sending user> (whispered): <text></B><P>Note that the client <I>may</I> allow the user to whisper a message to more than one person. If so, the client must issue separately formed WHISPER commands for each recipient.<P>Also note the <B>MSG</B> operator in the whisper command. This is a kludge, but is required in order to allow the server to cope with usernames that contain spaces. If anyone thinks of a better way of doing this, please speak up.<P>At any time, a client may issue a <B>WHO</B> command. The server will respond with a complete list of all logged in users. Optionally, this response may include an administrator-defined room description, much like a MUD.<P>The client may close the connection at any time with a <B>QUIT</B> command. The server must respond with an <B>OK</B> and then close the TCP connection.<P>Voting is handled through a structured text-based system. A client initiates a vote by using the <B>PROPOSE <text></B> command. The server will respond by broadcasting a command <B>PROPOSE <ID number> <text></B>. The ID number may be sequential, or randomly generated by the server. The only requirement is that it be unique within this session. This number may be hidden from the user, or displayed if necessary/requested. However, on receiving a PROPOSE command the client software must display a message calling for a vote, and the full text of the proposal must be displayed.<P>Optionally, a user may second a motion using the command <B>SECOND <ID number></B> The first response of this type will be deemed to be the seconder.<P>A user may modify the text of a proposition by sending a <B>MODIFY <ID number> <new text></B>. Modifying a proposition will clear the vote tables and the message will be resent as a normal <B>PROPOSE</B> to all the clients, whom will be required to vote again.<P>Once a proposition is discussed, each client will respond is a <B>VOTE <ID number> <AYE or NAY or ABSTAIN></B>.<P>The server must maintain a list of which users have or have not voted on each topic, to ensure that a user cannot votetwice. However, a client may change their vote by sending another VOTE command. Only the most recent vote command will be counted. The method of determining this is up to the server software programmer.<P>However, it is required that the server will never relay (or record in log files) which way a particular user has voted. This is important as it ensures the integrity of a silent ballot. However, nothing will stop a user from volunteering which way they voted in a free-text message.<P>At any time a user may query the results of a vote using: <B>QUERY VOTE <ID></B>. The server will respond (using a WHISPER from the system) giving the text of the proposition, and the number of AYEs, NAYs, ABSTAINs and the number of users that have not yet voted. The server may optionally provide percentages (maximum of two decimal places).<P>Once all active users have voted, the system will broadcast that the vote is complete, and will state the text of the proposition, and the vote counts and percentages. This message will also contain a date and time (UTC) stamp, in ISO format. The full text of this message will be logged in the server log file.<P>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<P>That summarises what I have so far. But since no-one has cut any serious code here, it's open to change and all comments are invited.<P><I>I now declare this protocol to be Open Source. It will be maintained through this message board and any person may implement it, as long as the implementation and any derivative works are in keeping with the goals and principles of the Order of Jubal.</I><P>PIQE,
Sir Gregory of Melbourne.<P>------------------
-------------
Sir Gregory of Melbourne, KI
Knight of the <A HREF="http://www.ivbalis.org" TARGET=_blank>Order of Jubal</A>
"What I tell you three times is true..." - The Bellman<p>[This message has been edited by Greg (edited 06-06-2001).]
Greg
Grand Poobah Keenspotter
 
Posts: 368
Joined: Wed Nov 22, 2000 12:00 am
Location: Reservoir, Victoria, Australia

Postby Vaughn on Wed Jun 06, 2001 12:56 am

But why don't you use both??<P>I've been dual-booting windows for decades... okay, years. Anyway, it's easy.
And I'd get a copy of Mandrake if I were you; it's the easiest to start with.
<P>------------------

I had a .sig, but I lost it.
User avatar
Vaughn
Grand Poobah Keenspotter
 
Posts: 441
Joined: Sun Apr 01, 2001 12:00 am
Location: Lost in infinite time

Postby Greg on Wed Jun 06, 2001 3:04 am

Hi there!<P> <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Vaughn:
<B>At this point we could also set up encrypted communication, but that seems to serve little purpose - after all, we don't have anything to hide. So we'll stick to plaintext.
</B><HR></BLOCKQUOTE><P>Don't be too sure of this...<P>The purpose of the encryption was to guard against either: a) members who reside in countries where their ISP or government may monitor IP traffic, or b) if we are discussing action against someone who may have a reasonable knowledge of the Internet.<P>I beleive we should look at encryption, but perhaps in a leter version of the protocol.<P> <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR><B>
What do you think?
</B><HR></BLOCKQUOTE><P>Wow! You've certainly improved a bit on my work.<P>The core components look good, and I like the "extensions" methods. (I was wondering how to handle that!) I also think a Quake client would be really cool!<P>A couple of notes:
1) The AUTH command takes username, but doesn't have an argument for display name. I'm assuming the server has a table of users with display names pre-configured, does it? Could we add an (optional?) second argument as a display name?<P>2) Conceptually, How does SAY differ from SHOUT?<P>3) Is there a need for a specific AWAY and HOME command set? I had originally thought that the client would generate these items, and simply SHOUT the user's status to other members (with no tracking or flags on the server end - not really needed)<P>4) If we are allowing a GUEST login then we need some way for a moderator-type person to expel a user, or to prevent guest logins. perhaps a CONTROL command would be available, and have a subset of commands for moderation functions. The client may request any command, but use of each command is validated against the user name for security level.<P>5) In the Messaging system, you've removed the ability to display messages in different colours. Any reason for this? (Not that I'm heartbroken about it or anything, just wondering why...)<P>Having said all that (hopefully constructive) criticism, I think you've done a really good job of it.<P>Regards,
Sir Greg<P>
<P>------------------
-------------
Sir Gregory of Melbourne, KI
Knight of the <A HREF="http://www.ivbalis.org" TARGET=_blank>Order of Jubal</A>
"What I tell you three times is true..." - The Bellman
Greg
Grand Poobah Keenspotter
 
Posts: 368
Joined: Wed Nov 22, 2000 12:00 am
Location: Reservoir, Victoria, Australia

Postby TimberBram on Wed Jun 06, 2001 3:47 am

Hmm. I understood everything just fine, I just don't know where to start. I'm an application programmer operating at least one level higher than this stuff.<P>Oh well.<P>For anyone able to do this programming, I am willing and able to help test the client. <P>Email me any time. I live in North America's Pacific Time Zone (currently GMT-07.00 due to daylight savings time). I am usually available all day since I work at home.<P>Contact me at need.<P>Peace,
Sir Timber Bram, KI Eqvites Ivbalis.
User avatar
TimberBram
Keenspot Despot
 
Posts: 1266
Joined: Fri Aug 18, 2000 11:00 pm
Location: Surrey, BC, Canada

Postby Lothar Sauvage on Wed Jun 06, 2001 4:31 am

Hammered out some details over here and we came up with the identical solution. on a lot of issues. We had some minor differences, most of which could be consolidated. I took the relavent bits from both emails and added my comments...<P><B>KnightChat RFC #1 - Core structure<P><B>For the connection, the client connects to an arbitrary port on the server and exchanges handshakes. This will include authenticating themselves to each other using public key encryption (GPG, most likely), and whether or not to use unicode.
Non-unicode capable clients will get their messages converted at the server.</B><P>We weren't even going to worry about unicode until the presentation layer if at all.<P><B>At this point we could also set up encrypted communication, but that seems to serve little purpose - after all, we don't have anything to hide. So we'll stick to plaintext.</B><P>Let's make encryption pluggable, possibly even support for multiple encryption plugins. I agree it's unnecessary in the current form of both the Knights and the program are in, but you never know later or possibly other applications of the program.<P><B>We could also (and almost certainly will) provide a blacklisting mechanism here; however, this should be skipped for authenticated connections.</B><P>Agreed. There should be a general chatroom where anyone can chat without personal authentication, but Ips or personal authentications can be banned from the server. Individual chatrooms should be invite only, based on personal authentication and be entered either manually, or be in a picklist (database) for CI's and Knights, or in groups such as all Knights or all members <P><B>Usernames are required to be alphanumeric, (no spaces), but are separate from display names.</B><P>I had a thought: Server assigns USERID after authentication. It is this USERID that allows access to the secure chat rooms and a vote. The USERID is generated randomly or sequentially with each login to maintain anonymity during a vote. Occasionally the server checks to ensure that multiple instances of the same USERID do not exist.<P>Multiple votes on the same issue are not permitted. This is accomplished by adding the USERID and SCREENID to the vote table on that particular issue's database. While an issue is still open, the person may change their vote, simply by revoting. The SCREENID field is stripped from the database. More details in a bit.<P><B>Okay, enough foreplay; onto the commands.<P><B>The general form of a command will be as follows: (Brackets will be included)
{Clientname:Clientversion:Extensionname:Extensionversion}{Commandname}{Arg1}{Arg2}...{ArgN}{}
This is for ease of debugging; verbose, yes, but that shouldn't be a problem.<P><B>If any argument or similar needs to include a bracket as a part of itself, that will be provided by using double {{ brackets.<P><B>Please note that arguments may include ANY character, up to and including newline; however, a newline after the end of a command (denoted by {}) is strictly optional.<P><B>All the commands described here will use the Core "extension" set; this is required to conform exactly to whatever version of it the client claims to be using.<P><B>Commands may perform different functions depending on number of arguments and whether the client or the server is sending it; discrimination based on type of argument is illegal. (This is to ease debugging)<P><B>This document will describe version 0.1
Description format is such: NAME(s|c)(NUMARGS)
S if server is sending; C if client is sending.
The arguments are specified by (ARGNUMBER).<P><B>HARK(c): Sent by the client to announce its presence; has no other function.<P><B>HARK(s)(1): Sent by the server to confirm connection; (1) is the IP address of the client.</B><P>Recommend the client sends the IP. This can be compared to the IP as received by the server for additional security.<P><B>AUTH(c)(1): Sent by client to initiate authenticated connection; (1) is username.</B><P>Recommend AUTH(c)(2) send (1)requested screen name and (2)password. AUTH(s)(1) returns USERID generated for this login.<P><B>GUEST(c)(2): Sent by client to initiate guest connection; (1) is username, (2) is preferred display name. A guest connection will have very limited functionality.</B><P>Recommend the following:<P>GUEST(c)(1) Sent by client to initiate guest connection; (1) is preferred display name. A guest's requested name would be checked against the list of registered users and not be permitted if a match is found. A guest connection would only be allowed in the main chatroom or in other chatrooms where they have been invited and have very limited functionality.<P><B>QUEMULTICAST(c|s): Sent by the client and server to ask whether the other has multicast; multicast conenctions should not be used unless both have recieved a positive answer to this one; however, asking it is not required. Thus, avoiding multicast can be done by not asking for it.<P><B>ANSMULTICAST(c|s)(1): (1) is a boolean value; true if you have multicast capability and false if you don't.<P><B>HASEXTENSION(c|s)(1): Sent by the client and server to inform each other of their extensions. The list (1) is of the format extension versionnumber|extension versionnumber and so on. This list includes the Core "extension".<P><B>NAME(s)(1): Sent by the server to inform a guest of his assigned name. (1) is the name, and is not required to bear any particular resemblance to what the guest asked for. inserting Guest_ in front of the guests' preferred name is recommended.<P><B>DECRYPT(s|c)(1): Decrypt this! The other end will decrypt the message using his private key; the sender can then authenticate his peer by checking the decrypted response versus the message he encrypted using the peers public key.<P><B>DECRYPTED(s|c)(1): Sends the decrypted message to your peer.<P><B>ERROR(s|c)(1): Breaks the connection with (1) as your reason.<P><B>SHOUT(c)(2): Tells the server to send a message to all currently logged-on users; (1) is a boolean value saying whether or on to include guests and (2) is the actual message in XML or similar. (To be decided)<P><B>WHISPER(c)(2): Tells the server to send a message to (1). (2) is the message in XML or similar. (To be decided)<P><B>SAY is reserved for the 3Dclient extension.<P><B>MCAST(c)(2): Tells the server to send a message to all the users in the |-separated list (1). (2) is the message in XML or similar. (To be decided.) The message will actually be sent using multicast for all capable clients.<P><B>Sending files is not required for the Core "extension", although a supplementary File extension will be provided after Core functionality has been implemented.<P><B>MESSAGE(s)(3): Tells the client that (1) has sent the message (3) to the users in the |-separated list (2), of which you are one. If the message is shouted, (2) will be an empty string, or NOTGUEST if the originator requested that guests shouldn't hear it.<P><B>LOGOUT(c)(1): Tells the server that the client is signing off, with reason (1). The server is encouraged to inform other users.<P><B>AWAY(c)(1): Tells the server that the client is away from keyboard. The server should inform other users.<P><B>HOME(c)(1): Tells the server that the client is back. The server should inform other users.</B><P>Client could AWAY automatically after a predetermined time of no activity and HOME when activity resumes.<P><B>Voting will be implemented in the Voting extension; by the way, extensions are encouraged to be in the shape of shared objects. (.so or .dll)</B><P>Quote from Greg:

<B>Voting is handled through a structured text-based system. A client initiates a vote by using the PROPOSE <text> command. The server will respond by broadcasting a command PROPOSE <ID number> <text>. The ID number may be sequential, or randomly generated by the server. The only requirement is that it be unique within this session. This number may be hidden from the user, or displayed if necessary/requested. However, on receiving a PROPOSE command the client software must display a message calling for a vote, and the full text of the proposal must be displayed.<P><B>Optionally, a user may second a motion using the command SECOND <ID number> The first response of this type will be deemed to be the seconder.</B><P>Recommend that the PROPOSE id be sequential. When PROPOSE is invoked and there is a SECOND, a sequential number is assigned to the issue and a database is created to contain the data. All votes are tallied and logged to a database to retain vote data in it's rawest form.<P><B>A user may modify the text of a proposition by sending a MODIFY <ID number> <new text>. Modifying a proposition will clear the vote tables and the message will be resent as a normal PROPOSE to all the clients, whom will be required to vote again.</B><P>I recommend a set time limit to the vote. Someone could hang a vote simply by showing up and not voting. This would also give folks a set time limit to change their mind.<P>I am not sure about the purpose of the MODIFY. Once a vote is in progress, I don't think it should be modified. If there is a real use for MODIFY, I would also recommend that only the USER Ids of the PROPOSE and SECOND can MODIFY, and that the option DISMISS be lumped along with them. This way if an issue becomes a non-issue, those who brought it up can end the whole thing. <P>Therefore: <P>PROPOSE(c)(1): Tells the server there is an issue to be voted on if there is a second. (1) is a limited text field to describe the issue to be voted on. The server assigns a number to the issue and returns with a SHOUT (2) NOTGUEST to declare the issue open for voting. (1) is the issue number as assigned, and (2) is the issue descriptor.<P>SECOND(c)(1): Tells the server that a second has been obtained. (1) is the issue number as assigned. When a SECOND is received, the database is created using the issue number as part of the filename. The PROPOSEr cannot SECOND. Additional SECONDs are ignored.<P>MODIFY(c)(2): Requests that the server modify the vote issue. (1) is the issue number as assigned. (2) is the new issue descriptor. Only the PROPOSEer or the SECONDer may MODIFY. Once MODIFYed, the votes (if any) are cast out and the issue must receive a SECOND. This is done by deleting the database created using the issue number as part of the filename.<P>DISMISS(c)(2): Requests that the server DISMISS the vote issue. (1) is the issue number as assigned. (2) is the reason for DISMISSing the issue (optional). Only the PROPOSEer or the SECONDer may DISMISS. Once DISMISSed, the votes (if any) are cast out and the issue must be PROPOSEd again. This is done by deleting the vote table in the database created using the issue number as part of the filename and closing the database as if a vote had been cast.<P><B>Once a proposition is discussed, each client will respond is a VOTE <ID number> <AYE or NAY or ABSTAIN>.</B><P>Agreed Greg, to bring it in synch:<P>VOTE(c)(1): where (1) is text in the form of AYE or NAY or ABSTAIN. All other entries are ignored.<P>Vote tally database could be a simple mySQL database where the following info is stored during the vote:<P> SCREENID USERID ccyymmdd hhmmss VOTE<P>Note that when the vote is finalized, duplicate USERIDs and SCREENIDs are deleted (previous iterations, to get the last change of mind) then the SCREENID field is stripped from the database. USERID (which simply the sequential number assigned upon login), the timestamp, and VOTE are retained. Stats are compiled and final results disclosed to all voters, broadcast, or sent to all registered. The following info is stored in the vote tally database after the vote and archived:<P> USERID ccyymmdd hhmmss VOTE<P>The field VOTE is a 2 position Boolean following this truth table<P> 00 No vote yet
01 Nay
10 Aye
11 Abstain<P><B>The server must maintain a list of which users have or have not voted on each topic, to ensure that a user cannot vote twice. However, a client may change their vote by sending another VOTE command. Only the most recent vote command will be counted. The method of determining this is up to the server software programmer.<P><B>However, it is required that the server will never relay (or record in log files) which way a particular user has voted. This is important as it ensures the integrity of a silent ballot. However, nothing will stop a user from volunteering which way they voted in a free-text message.<P><B>At any time a user may query the results of a vote using: QUERY VOTE <ID>. The server will respond (using a WHISPER from the system) giving the text of the proposition, and the number of AYEs, NAYs, ABSTAINs and the number of users that have not yet voted. The server may optionally provide percentages (maximum of two decimal places).<P><B>Once all active users have voted, the system will broadcast that the vote is complete, and will state the text of the proposition, and the vote counts and percentages. This message will also contain a date and time (UTC) stamp, in ISO format. The full text of this message will be logged in the server log file.</B>"<P>No problem, See my notes above. End of Greg's quote<P><B>The 3Dclient extension will probably depend on the File extension; however, I haven't even started thinking about it yet.<P><B>Clients should never be required to have any extensions beyond the Core. (Which isn't an extension)<P><B>All extensions must have corresponding server-side extensions to work, although I may make a DCC extension later; this would invalidate this statement.<P><B>The server will use multicast whenever possible.</B><P>Why use Multicast?<P>I am more of a server oriented person (background in EDI), so I will begin coding the server and see what we come up with.<P>Regards, <P>Lothar Sauvage, CI<P>PS edited for ease of reading, not that I know HTML tags work... (sheepish grin)<p>[This message has been edited by Lothar Sauvage (edited 06-07-2001).]
Lothar Sauvage
Keenspotter Supreme
 
Posts: 52
Joined: Fri May 18, 2001 11:00 pm
Location: Southern Colorado

Postby TimberBram on Wed Jun 06, 2001 6:40 am

Here's a question with respect to the Voting extension.<P>How closely do we want to follow standard parliamentary procedure when it comes to voing?<P>Standard procedure is to propose a motion, acquire a second, discuss the issue, possibly amending the motion. <P>Voting does not actually start until the question is called.<P>Amendments are treated as separate proposals in that an amended motion can be defeated while allowing the original form to pass.<P>So for example, a motion: "To require all Knights to wear a KOJ t-shirt occasionally" could be proposed. If no one seconds, it dies. After being seconded, discussion would ensure, which leads someone to propose to amend the motion to read "To require all Knights to own a KOJ t-shirt." This, too, requires a second. More discussion occurs until someone calls for the question (the vote). Once the question is called, discussion ceases and the motion cannot be amended further. The amended motion is the item before the group at this point. If the amended motion is defeated, then the original motion is up for question. If the amended motion passes, then the orginal motion is ignored.<P>According to usual procedure anyone (which means NONGUEST in our case) can propose a motion except the chair of the meeting, anyone but the proposer (and the chair) can second a motion. Anyone but the chair can propose an amendment. Everyone including the chair can vote. When calling the question, usually a consensus of participants is required to indicate that the discussion is done. Since we won't be meeting face-to-face, this requires a type of shadow-voting system--once enough people have indicated that they think the discussion is over, the system would inform everyone that the question has been called and voting should begin.<P>So, is this all too involved for our purposes? Or should I make the attempt at specifying the client and server messages required to handle this interaction?<P>Opinions? Comments?<P>Peace and PIQE,
Sir Timber Bram.
User avatar
TimberBram
Keenspot Despot
 
Posts: 1266
Joined: Fri Aug 18, 2000 11:00 pm
Location: Surrey, BC, Canada

Postby Vaughn on Wed Jun 06, 2001 6:51 am

That sounds nice.
(Although it would've been good to get a bit more on the technical side, I suppose we can work that out.)<P>Obviously, the voting system should use public key authentication; I propose we build this into the core client, possibly along with encryption.<P>I think I'm going to write a Quake 2 frontend, actually... what with its SO/DLLish interface, it can call any OS function.<P>It would certainly be a nice touch; not to mention it would be rather simple to get interactive.<P>Of course, we should only use our own textures/models, or possibly public domain ones; that way you don't have to buy Q2 to participate in the chat.<P>(Although a 2D/std chat interface will also be provided)<P>What do you think?
Maybe we could get together on IRC sometime soon to plan it out.<P>------------------

I had a .sig, but I lost it.
User avatar
Vaughn
Grand Poobah Keenspotter
 
Posts: 441
Joined: Sun Apr 01, 2001 12:00 am
Location: Lost in infinite time

Postby Vaughn on Wed Jun 06, 2001 8:55 am

Sorry about the 'too few technicalities' part of my last message; my computer didn't load the entire page.<P>Anyway, here is a revised proposal.
It's based on Greg's proposal, but will be (I hope) somewhat more extendable.
You'll be the judge of that, though, so without any further ado:<P>KnightChat RFC #1 - Core structure<P>For the connection, the client connects to an arbitrary port on the server and exchanges handshakes. This will include authenticating themselves to each other using public key encryption (GPG, most likely), and whether or not to use unicode.
Non-unicode capable clients will get their messages converted at the server.<P>At this point we could also set up encrypted communication, but that seems to serve little purpose - after all, we don't have anything to hide. So we'll stick to plaintext.<P>We could also (and almost certainly will) provide a blacklisting mechanism here; however, this should be skipped for authenticated connections.<P>Usernames are required to be alphanumeric, (no spaces), but are separate from display names.<P>Okay, enough foreplay; onto the commands.<P>The general form of a command will be as follows: (Brackets will be included)
{Clientname:Clientversion:Extensionname:Extensionversion}{Commandname}{Arg1}{Arg2}...{ArgN}{}
This is for ease of debugging; verbose, yes, but that shouldn't be a problem.<P>If any argument or similar needs to include a bracket as a part of itself, that will be provided by using double {{ brackets.<P>Please note that arguments may include ANY character, up to and including newline; however, a newline after the end of a command (denoted by {}) is strictly optional.<P>All the commands described here will use the Core "extension" set; this is required to conform exactly to whatever version of it the client claims to be using.<P>Commands may perform different functions depending on number of arguments and whether the client or the server is sending it; discrimination based on type of argument is illegal. (This is to ease debugging)<P>This document will describe version 0.1
Description format is such: NAME(s|c)(NUMARGS)
S if server is sending; C if client is sending.
The arguments are specified by (ARGNUMBER).<P>HARK(c): Sent by the client to announce its presence; has no other function.<P>HARK(s)(1): Sent by the server to confirm connection; (1) is the IP address of the client.<P>AUTH(c)(1): Sent by client to initiate authenticated connection; (1) is username.<P>GUEST(c)(2): Sent by client to initiate guest connection; (1) is username, (2) is preferred display name. A guest connection will have very limited functionality.<P>QUEMULTICAST(c|s): Sent by the client and server to ask whether the other has multicast; multicast conenctions should not be used unless both have recieved a positive answer to this one; however, asking it is not required. Thus, avoiding multicast can be done by not asking for it.<P>ANSMULTICAST(c|s)(1): (1) is a boolean value; true if you have multicast capability and false if you don't.<P>HASEXTENSION(c|s)(1): Sent by the client and server to inform each other of their extensions. The list (1) is of the format extension versionnumber|extension versionnumber and so on. This list includes the Core "extension".<P>NAME(s)(1): Sent by the server to inform a guest of his assigned name. (1) is the name, and is not required to bear any particular resemblance to what the guest asked for. inserting Guest_ in front of the guests' preferred name is recommended.<P>DECRYPT(s|c)(1): Decrypt this! The other end will decrypt the message using his private key; the sender can then authenticate his peer by checking the decrypted response versus the message he encrypted using the peers public key.<P>DECRYPTED(s|c)(1): Sends the decrypted message to your peer.<P>ERROR(s|c)(1): Breaks the connection with (1) as your reason.<P>SHOUT(c)(2): Tells the server to send a message to all currently logged-on users; (1) is a boolean value saying whether or on to include guests and (2) is the actual message in XML or similar. (To be decided)<P>WHISPER(c)(2): Tells the server to send a message to (1). (2) is the message in XML or similar. (To be decided)<P>SAY is reserved for the 3Dclient extension.<P>MCAST(c)(2): Tells the server to send a message to all the users in the |-separated list (1). (2) is the message in XML or similar. (To be decided.) The message will actually be sent using multicast for all capable clients.<P>Sending files is not required for the Core "extension", although a supplementary File extension will be provided after Core functionality has been implemented.<P>MESSAGE(s)(3): Tells the client that (1) has sent the message (3) to the users in the |-separated list (2), of which you are one. If the message is shouted, (2) will be an empty string, or NOTGUEST if the originator requested that guests shouldn't hear it.<P>LOGOUT(c)(1): Tells the server that the client is signing off, with reason (1). The server is encouraged to inform other users.<P>AWAY(c)(1): Tells the server that the client is away from keyboard. The server should inform other users.<P>HOME(c)(1): Tells the server that the client is back. The server should inform other users.<P>Voting will be implemented in the Voting extension; by the way, extensions are encouraged to be in the shape of shared objects. (.so or .dll)<P>The 3Dclient extension will probably depend on the File extension; however, I haven't even started thinking about it yet.<P>Clients should never be required to have any extensions beyond the Core. (Which isn't an extension)<P>All extensions must have corresponding server-side extensions to work, although I may make a DCC extension later; this would invalidate this statement.<P>The server will use multicast whenever possible.<P>Throughout this document I have used client and user interchangeably.<P>----<P>Phew! I didn't think it would be this long; and yet, this is only the core.<P>What do you think?
I've tried to keep it modular, which is important in order to ease upgrading.<P>I'll start coding right away (That is, friday), unless anyone has any objections.<P>Oh, and someone should try writing the Voting and File extensions.
<P>------------------

I had a .sig, but I lost it.
User avatar
Vaughn
Grand Poobah Keenspotter
 
Posts: 441
Joined: Sun Apr 01, 2001 12:00 am
Location: Lost in infinite time

Postby Jim Brockman on Wed Jun 06, 2001 9:54 am

urprising thing is that I understood about half of the geek stuff <IMG SRC="http://www.keenspot.com/KeenBoard/cool.gif"><P>Of course I'm better with hardware.<P>BTW any good sources for a man with little time to learn more about the peguin? I have a copy (Caldera) at home but no time to learn how to use it. Therefore I keep taking it baxck off so I can get some work done in an OS I'm familiar with.<P>------------------
Jim Brockman CI
Jim Brockman
Keenspotter Supreme
 
Posts: 139
Joined: Tue May 29, 2001 11:00 pm
Location: Oklahoma

Postby Vaughn on Thu Jun 07, 2001 1:25 am

Well, I didn't put a screen name in the AUTH command because I didn't think any true Knight would want to conceal their identity, and names and such will be stored on their account on the server.
We can of course add a NICK command; however, it should prepend something to the nickname in order to avoid name stealing.
(Like GUEST_ in the case of guests.)<P>As for color, I decided to follow an XML-like structure for the messages (We could of course write our own, but XML is already there..), so I suppose color will be inserted by use of the color tag.
This can of course be automated by the client. (And should be)<P>------------------

I had a .sig, but I lost it.
User avatar
Vaughn
Grand Poobah Keenspotter
 
Posts: 441
Joined: Sun Apr 01, 2001 12:00 am
Location: Lost in infinite time

Postby Lothar Sauvage on Thu Jun 07, 2001 5:53 am

<B>Well, I didn't put a screen name in the AUTH command because I didn't think any true Knight would want to conceal their identity, and names and such will be stored on their account on the server.</B><P>Common use of the internet dictates that we at least make use of nicks. If the user (knight) chooses their real name for their nick that is their choice, and I'd like the option to be theirs. Once these hit the server, they're just USERIDs anyway to protect their anonymity during and after a vote.<P><B>We can of course add a NICK command; however, it should prepend something to the nickname in order to avoid name stealing.
(Like GUEST_ in the case of guests.)</B><P>Registered users must be in a database anyway for authentication, so nick stealing will be impossible without the password. Guest accounts can be in an online database only, and have any nick they want except those in the registered or online databases. Functionality could be the same as DALnet's services, though more user friendly.<P><B>As for color, I decided to follow an XML-like structure for the messages (We could of course write our own, but XML is already there..), so I suppose color will be inserted by use of the color tag.
This can of course be automated by the client. (And should be)</B><P>Agreed. this will also simplify the logging, archiving, and display functions at the server level.<P>Regards, <P>Lothar Sauvage, CI
Lothar Sauvage
Keenspotter Supreme
 
Posts: 52
Joined: Fri May 18, 2001 11:00 pm
Location: Southern Colorado

Postby Greg on Thu Jun 07, 2001 5:58 am

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Lothar Sauvage:
<B>
Recommend the client sends the IP. This can be compared to the IP as received by the server for additional security.</B><HR></BLOCKQUOTE><P>Agreed, but we also have to allow for people using NAT or through some form of firewall.<P> <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR><B>
Recommend that the PROPOSE id be sequential. When PROPOSE is invoked and there is a SECOND, a sequential number is assigned to the issue and a database is created to contain the data. All votes are tallied and logged to a database to retain vote data in it's rawest form.
</B><HR></BLOCKQUOTE><P>There's certainly no problem with the ID being sequential, and we can run with that as a separate standard, but for the purposes of the messaging protocol, it's irrelevant. As long as we guarentee that it is unique for the current meeting session, how the server assigns the number is up to the server software developer.<P> <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR><B>I am not sure about the purpose of the MODIFY. Once a vote is in progress, I don't think it should be modified. If there is a real use for MODIFY, I would also recommend that only the USER Ids of the PROPOSE and SECOND can MODIFY, and that the option DISMISS be lumped along with them. This way if an issue becomes a non-issue, those who brought it up can end the whole thing.
</B><HR></BLOCKQUOTE><P>The purpose of MODIFY was to allow a motion to be changed without having to DISMISS and re-PROPOSE (and re-issue a number). I've been in meetings where we've spent up to 2 hours refining the text of a proposition. The server would have to do a lot of work issuing and cancelling IDs, when you're essentially working on the same topic.<P>As Sir Timber wrote, a person should PROPOSE the motion, it can be discussed and MODIFIED, and then a vote called.<P>However, it is necessary that a MODIFY command clears the vote tables, to ensure that a user doesn't vote for a topic, only to have it changed and their vote implicitly counted.<P> <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR><B>
Vote tally database could be a simple mySQL database where the following info is stored during the vote:
</B><HR></BLOCKQUOTE><P>If you like, however, server internals are once again up to the conscience and ingenuity of the server programmer. <P>Let's concentrate on getting the messaging protocol defined, and people can then write whatever clients and servers they like, however they like it, in whichever language they want, on whatever platform they like. As long as our messaging protocols are agreed and complied with, it should all be inter-operable.<P> <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR><B>At any time a user may query the results of a vote using: QUERY VOTE <ID>. The server will respond (using a WHISPER from the system) giving the text of the proposition, and the number of AYEs, NAYs, ABSTAINs and the number of users that have not yet voted. The server may optionally provide percentages (maximum of two decimal places).
</B><HR></BLOCKQUOTE>
It just occurred to me that maybe we should prevent people using the QUERY VOTE command until after they have issued a VOTE command themselves? In order to prevent a person's vote being biased by the others.<P>Just something to think on...<P>Regards,
Greg<P>------------------
-------------
Sir Gregory of Melbourne, KI
Knight of the <A HREF="http://www.ivbalis.org" TARGET=_blank>Order of Jubal</A>
"What I tell you three times is true..." - The Bellman
Greg
Grand Poobah Keenspotter
 
Posts: 368
Joined: Wed Nov 22, 2000 12:00 am
Location: Reservoir, Victoria, Australia

Postby TimberBram on Thu Jun 07, 2001 6:21 am

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Greg:
<B>It just occurred to me that maybe we should prevent people using the QUERY VOTE command until after they have issued a VOTE command themselves? In order to prevent a person's vote being biased by the others.</B><HR></BLOCKQUOTE><P>This would be a good idea if the people could not change their votes, having voted. There would be nothing to prevent a person from voting, then querying, and then choosing to change his or her vote.<P>I agree with Sir Greg's comment regarding the time and effort required to get the wording of a motion <I>exactly</I> right. MODIFY is definitely necessary. <P>Can I suggest that SECOND also be necessary, or at least be an administrator configurable option?<P>Peace and PIQE,
Sir Timber Bram, KIEI.
User avatar
TimberBram
Keenspot Despot
 
Posts: 1266
Joined: Fri Aug 18, 2000 11:00 pm
Location: Surrey, BC, Canada

Postby TimberBram on Thu Jun 07, 2001 6:38 am

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Vaughn and Lothar Sauvage said:
<B>As for color, I decided to follow an XML-like structure for the messages (We could of course write our own, but XML is already there..), so I suppose color will be inserted by use of the color tag.
This can of course be automated by the client. (And should be)</B><P>Agreed. this will also simplify the logging, archiving, and display functions at the server level.<HR></BLOCKQUOTE><P>I'll add my C$0.05 here. <P>The company I work for handles development-tools for Internet-distributed dynamic databases. Our experience tells us that using something existing (like XML) to handle messages is <I>much</I> better than rolling your own, and will end up being more maintainable.<P>Peace and PIQE,
Sir Timber Bram, KI.<p>[This message has been edited by TimberBram (edited 06-07-2001).]
User avatar
TimberBram
Keenspot Despot
 
Posts: 1266
Joined: Fri Aug 18, 2000 11:00 pm
Location: Surrey, BC, Canada

Postby Lothar Sauvage on Thu Jun 07, 2001 7:07 am

<B>It just occurred to me that maybe we should prevent people using the QUERY VOTE command until after they have issued a VOTE command themselves? In order to prevent a person's vote being biased by the others.<P>Easily done. Lock the SQL table until the name field is stripped and the stats are generated. This can be done on the server side with no effort on the protocol.<P>Regards,<P>Lothar Sauvage
Lothar Sauvage
Keenspotter Supreme
 
Posts: 52
Joined: Fri May 18, 2001 11:00 pm
Location: Southern Colorado

Postby Vaughn on Thu Jun 07, 2001 10:56 am

When I was talking about nick stealing I was actually worried about someonw doing something like using "Vaughn " as their nick; while preventable, I'd much prefer to avoid it entirely.<P>But whatever.<P>I say, let's make the NICK command available for both guests and registered users in the protocol, and leave the option to turn it on or off to the server administrator.<P>By the way, we need a way to detect error conditions here, like denial of nickname; any ideas?<P>Also, I want to implement multicast early because some of the extensions will involve sending biggish messages to all, or a lot of the, users, and conserving bandwith wherever possible is a good idea.<P><P>------------------

I had a .sig, but I lost it.
User avatar
Vaughn
Grand Poobah Keenspotter
 
Posts: 441
Joined: Sun Apr 01, 2001 12:00 am
Location: Lost in infinite time

Postby Atlas_v1.1 on Thu Jun 07, 2001 11:12 am

I would suggest that the server maintain a user database, where each member gets a user ID when he or she joins the Order. That would also allow keeping stuff like rank and other infos in there. Then, the client authorizes with a userID and pass, and thus uses that ID for the session. Guest login would cause no breach of security, and spoofing would be impossible.
Screen names could thus be arbitrarily spaced etc.<P>------------------
Atlas, <A HREF="http://www.ivbalis.org/" TARGET=_blank>CI</A>
- Striding among Stars
---begin codes ---
CRFH!!! F+ U IRC+ R+ RM- H PSL++++ FW S+ FR WB GN+ AI+ D&M+ BR RPG+++ FDS-- BSL+ N- P+++ W++ I+ E++ <A HREF="http://www.keenspot.com/KeenBoard/Forum21/HTML/002186.html" TARGET=_blank>DOOM+++</A> <A HREF="http://www.keenspot.com/KeenBoard/Forum21/HTML/002392.html" TARGET=_blank>SOC++</A>
Avalon R+ S- F IRC FA- GA- FF SN? LY f{C+ D+} D{T--- A-} PSL+++ P{CJ++ !CI RD+++} a+ d- B[h++ w- r e*g hDBl++] e+ h* y L{DK} W+
---end codes ---
Atlas_v1.1
Keenspot Despot
 
Posts: 1130
Joined: Sun Apr 22, 2001 11:00 pm
Location: Copenhagen, Denmark

Postby Vaughn on Fri Jun 08, 2001 3:45 am

Well, then, without any further ado I hereby announce the creation of the KnightChat Sourceforge project, located at knightchat.sf.net<P>I'll be working on the client library and a curses-based client; it would be nice if someone else would tackle the server and a graphical client.<P>Although I realize we haven't quite completed the protocol, I believe it's close enough now that any changes made will be easy to fold in; and, of course, I'm ready to throw away one (codebase) if need be.<P>Also, please don't start coding another client before my library at least has an interface; I'm trying to make this as modular as possible, which means most of the code will go into the library.<P>On another note, all extensions will be in the form of dynamically loaded .so files.
I don't have the faintest idea of how this would work in Windows, so if anyone can advice me... that would be nice.<P>------------------

I had a .sig, but I lost it.
User avatar
Vaughn
Grand Poobah Keenspotter
 
Posts: 441
Joined: Sun Apr 01, 2001 12:00 am
Location: Lost in infinite time

Postby Vaughn on Fri Jun 08, 2001 3:53 am

Please note that I have registered it under the GPL; I don't think this should be a problem for anyone, but if it is then speak up now or forever hold your silence. <IMG SRC="http://www.keenspot.com/KeenBoard/smile.gif"><P>-- UPDATE --
It may be up to 72 hours before the project goes active, so don't hold your breaths!<P>In the meantime, perhaps someone would like to make a webpage to put there? I'll be too busy to do it. Already programming.<P>------------------<P>I had a .sig, but I lost it.<p>[This message has been edited by Vaughn (edited 06-08-2001).]
User avatar
Vaughn
Grand Poobah Keenspotter
 
Posts: 441
Joined: Sun Apr 01, 2001 12:00 am
Location: Lost in infinite time

Postby Vaughn on Fri Jun 08, 2001 4:45 am

Okay, so Sourceforge were quick about it this time.<P>The project page is <A HREF="http://sourceforge.net/pm/?group_id=28927" TARGET=_blank>here</A>, and the project homepage is <A HREF="http://knightchat.sf.net" TARGET=_blank>here</A>.<P>Anyone who wants to help should register with <A HREF="http://www.sf.net" TARGET=_blank>Sourceforge</A> first, and then just mail me/reply here and I'll add you to the project.<P>The current task list has me taking care of prototyping the KnightChat client library and a text-based (ncurses) client, but positions as head programmer for the server, X client and Win32 client are still available.<P>There will be more in the future, but for now we simply don't have enough of a system to build on.<P>Agreed?
<P>------------------

I had a .sig, but I lost it.
User avatar
Vaughn
Grand Poobah Keenspotter
 
Posts: 441
Joined: Sun Apr 01, 2001 12:00 am
Location: Lost in infinite time

Postby spade78 on Sat Jun 09, 2001 12:16 am

I'd like to help. I'm a student and have done some coding in C but not to this sort of level so I'm not sure how much help I'd be. But hey, I'm on vacation and got lots of spare time floating around and I'm always on the lookout to learn new things.<P>Eugene Cheng, spade78, CI
spade78
Keenspotter Supreme
 
Posts: 39
Joined: Fri May 25, 2001 11:00 pm
Location: Citrus Heights, CA, USA

Postby Lothar Sauvage on Sun Jun 10, 2001 6:15 am

I'll log on to Sourceforge and go for the server portion.<P>Regards,<P>Lothar Sauvage, CI
Lothar Sauvage
Keenspotter Supreme
 
Posts: 52
Joined: Fri May 18, 2001 11:00 pm
Location: Southern Colorado

 
Next

Return to Eqvites Ivbalis, Order of the Knights of Jubal

Who is online

Users browsing this forum: No registered users and 1 guest