YAP - Yet Another Protocol Written by Lonny Pursell Version 0.75 - 12/25/2004 Or rather a chat protocol within a protocol. It occurred to me that we are re-inventing the wheel so to speak. There exists this program called StringServer (SS for short) which it's sole purpose is to send strings from one app to another. So why not use it?! ;o) The concept is simple. SS looks for specific strings (sequences of characters) defined by the user and forwards such matches to specific applications. All that is needed to get SS to handle our message protocol is a unique string identifier at the start of our string to be passed. This protocol is designed to be simple. It is aimed at making sure one does not miss and incoming message. It is not really meant to initiate chats as it only notes nicks that have been sent across at least once. Currently there are only 2 chat services and I don't see the need to buffer entire contact lists. The new ground rules would be: This concept will work with more than 2 chat applications at once. No longer limited to just communication between aIRC and aICQ. The user must install SS if they want full 2-way app to app chatting. All communication takes place through SS. The user must decide which app is to be the default destination app. Basically which app do you prefer the most? All msg's from hidden/iconified clients will be routed to this one app. There is no easy way to determine which apps are hidden/iconified and which are not, so this seems to be the best option here. I prefer using aIRC, ok I'm bias, but you get the picture. :o) All configuration is done through SS, is that cool or what? Down the road, only tweaks to the SS config need be done for new chat apps. Also SS is always there, once installed you never know it's there. SS is based on the AV_Protocol, thus we are using a standard protocol. This protocol uses an ack/nak scheme so that requirement is also met. SS sends strings as VA_START messages. It's possible some apps already react to such messages. In the case of aIRC that is true, as aIRC reacts to chat files (*.cha/*.chat), irc urls (irc://server#channel), and paths dropped on the window via Thing desktop. Therefore, it would be best if the message format started with a unique char. One that is not valid in any form of URL. This way it can be easily detected. Application ID: ID's will be 4 chars long. "apid" (cast in stone) ID Description Program info "$IRC" Internet Relay Chat AtarIRC "$ICQ" ICQ AtarICQ "$GIM" GEM Instant Messenger piku's project/not finished As other apps become available they will be issued ID's. It's possible to run more than one chat client so ID's will have to be unique per application. ID's will be issued on a first come first serve basis, meaning if the ID is already in use by some other app, then you will have to pick a new one. The leading char "$" is unique enough that an app can do a sanity check on just the first char and decided if it's a chat message or not. File names and URL's should never start with "$", so it should be safe. NOTES: Should we reserve some extra space in the message for future expansion? Message encoding: Format: "$aid"+"op"+"nl"+"msgl"+"nick"+"message" Item Offset Length Description $aid 01 4 application id op 05 2 option in hex (0-255) nl 07 2 nick length in hex (1-30) msgl 09 4 message length in hex (1-450) nick 13 1-30 nick name message ?? 1-450 message See file YAP.LST for further details. All HEX values will be stored as 2 or 4 character ASCII values. This allows a range of 0-255 or 0-32767 and at the same time overcomes the problem of placing nulls within the string itself. It is also more compact than base 10 decimals depending on the values used. Message decoding: See file YAP.LST for further details. Option parameter: Code Description 000 reserved 001 informational message - dump in current window suitable for popgem for example, the nick should be replaced by the app name 002 private message - 2 way communication expected (app should note senders name) 003 user no longer available? 004 app terminated? 005-255 reserved There is no GIM client, but for the sake of clarity and to prove this could work with multiple clients I have included it. First thing one needs to do is configure SS as follows: String mask Destination [$icq|$gim]* f:\atarirc\atarirc.app $ICQ* e:\ataricq\ataricq.prg $GIM* e:\gim\gim.prg Note that the 'string mask' is case sensitive! The 'precedence' and 'filter' entries in SS should be left blank. A null cannot be used as a separator since it terminates the entire string for SS. The first configuration line is used to route all msgs from any hidden/iconified apps to aIRC. Your favorite app. These should simply be echoed to the screen. The following 2 lines are used to route replies back to the proper app. These should be sent out over the network, and optionally echoed to the screen. An example session with this configuration would look something like this: aICQ is iconified, a message appears from ozk aICQ sends SS this: "$icq02030003ozkHi!" SS gets the message and routes it to aIRC aIRC displays the message locally and notes internally that ozk is actually on ICQ Using the Tab key I reply to ozk aIRC sends SS this: "$ICQ02030003ozkYo!" SS gets the message and routes it to aICQ aICQ displays/sends the reply message to ozk Rules: iconified app (incoming msg) -> favorite app -- $id = local messge echo (buffer sender) favorite app (reply msg) -> iconified app -- $ID = local echo, network echo SS will need a buffer large enough for 4+2+2+4+30+450+1 bytes of data, worst case scenario. The last +1 would be the null terminator. The methods for storing which nick is on what chat service is up to the coder. For proper routing of replies this information needs to be buffered. How that app presents this information to the end user is up to the coder. Could appear as a fake contact, a nick in a fake channel, a nick in a Tab key buffer. Also the internal handling of nick names is up to the coder. There are issues with this, but they need to be passed app to app as is. ------------------------------------------------------------------------------ Is there any drawbacks to this scheme? Only one that I can think of since it's not really been put to a test. I've only run the code in my head thus far. ;o) If the default app is iconified then it too will start echoing msg's to SS. The reason is simple, it has no way of knowing it is set as the default app in the SS config. As long as SS is configured correctly, SS should not find a match, thus SS will silently ignore the msg's. This should not be a problem. ------------------------------------------------------------------------------ How will aIRC present this information to the user? What you are about to read is only a visual description of what the end user might see in aIRC. Internally, aIRC will follow the specs as described above. Here I will attempt to describe how I intend to handle this in aIRC. First it must be stated that since these messages are originating from other chat services, these users are not really on IRC. Since they are not really on the IRC network, none of the normal IRC options or commands will work on that nick. This includes such things as bans, whois info, ip lookup, and many more. Originally, creating a fake channel was my idea, however a channel is represented in such a way that all IRC commands would be be accessible, and all of them would generate errors. That situation seems unacceptable, and perhaps would be very confusing to the end user. I decided it would be much easier and more straight forward if the nicks from external messages appeared only in the the Tab key buffer. The end user can reply easily, and the nick remains buffered. The end user can also manually type '/msg ' if they so desire. To further clarify, let's say a message from ozk arrives in ICQ but I have ICQ iconified. Suddenly a message appears in aIRC like this: pmsg Hi! a reply would look like this: pmsg[ozk{ICQ}] >>Hey dude! aIRC is going to append the name of the chat service for which the message originated to the nick, wrapped in curly brackets. This will be a clear indicator to the end user where the message came from. This way if the end user would rather go to that app, they can. This also means the fake nick will be put into the Tab key buffer as 'ozk{ICQ}'. Again the end user will be able to see where the message is headed if they reply to that nick. This scheme also keeps the fake nicks unique, so they do not conflict with real nicks possibly already in the Tab key buffer. For example if you had IRC, ICQ, and GIM all running and ozk was on all 3 chat services the nicks would appear in aIRC as: ozk, ozk{ICQ}, and ozk{GIM}. -------------------------------------------------------------------------- Internal name storage: Different chat service have different user name rules. The plan with aIRC would be to store the names unchanged. Since the name is not a valid IRC nick name, and should not be used on the IRC network anyway, it makes sense to leave them AS IS. -------------------------------------------------------------------------- There is an older protocol already built into aIRC which allowed for simple one way communication. It was designed to simply dump msgs on the display. This old msg format is currently supported by: AtarIRC PopGEM AtarIQC Meg Initially it was planned to drop this old format, and actually remove it from aIRC and aICQ, but that plan has now changed and this old msg format will remain "as is" for backward compatibility. eof