IDEAS

This is just a file for future ideas, features, etc

So far the plugins have worked quite well for the OmniBot.main() features. But I'm thinking some 
standards are in order. First of all there should be initial and ending plugins that either
hook into parts of the end of the Category/module they are enhancing or the beginning. In this
way the return values can be manipulated OR the initial settings can be modified. We're considering
to extend this to classes but I'm looking into this as python isn't my first language. So essentially
what we have seen for main() so far is:
    PLUGINS_OMNIBOT_MAIN[0:x].main() functions
    but then we should also see something like
    PLUGINS_OMNIBOT_MAIN[0:x].end() functions checked upon? 

I'm not sure this is my first time extending plugin functionality to a program but we'll see how it goes


Source code / program structure:
    *OmniLib/Comm - will store all connection methods (IRC/AIM/HTTP/Etc) - Each Comm/*/ will contain the initial
    connection methods as well as 
    *OmniLib/Auth - will store all user Authentication shits, it provides a common interface so that protocols dont
    have to worry about the details of matters like loading keys and such. Ideall the Config module should interface
    with the Auth module upon startup and add the required users/keys/etc
    *OmniLib/plugins - This is self explanatory and has been described to a little length above, this is a work
    in progress..
    *OmniLib/Config - This is responsible for handling all things related to configuration of the program, this
    includes loading from configuration files, loading from command line, and perhaps distrubuted/remote configging
    (for large nets of bots)
    
Perhaps I am getting too far ahead of myself... for now the TODO is pointing for a functional IRC portion, we'll work
on that then work our way back thru

Ideas for auth:
    keyexchange can take place over email. for example: '!authorize --request_key' would email a key back to a
    pre-specified account in the config file then give it a short timeout value for the end user to !authorize <key>
    optionally only a portion of the key should be sent while the rest is used for encryption. maybe the first 4 bytes?
    so we've got this model for auth:
	Bot: starts->reads config file->adds email to nick/user pairing->waits for !authorize
	User: sends-PM->!authorize --request_key
	Bot: checks against nick/host-> generates random key -> gives it a timeout value-> sends it to email addr
	User: sends-PM->!authorize <first-4bytes of key>
	Bot: adds nick/host to authorized list
    Also we may want multiple authorization levels: Admin, Power, Friend, Etc.
    
    Another note for security: I want each user to have a private key for the keygen in addition to the auth library checking 
    their user string. eventually we can progress on to having individual send/recv wrappers for each user that handle with
    encryption going both ways. Each user will have their own key. the key exchange will most likely also happen over email
    at the time of the keygeni


Update:
So I realized I have been doing it wrong up until this point. Having protocol specific plugins is cool but what the original
goal of OmniBot was to have a cross-protocol layer to build applications upon. So what I need is a very well defined API
before I even begin developing the code. The protocol specific plugins can stay for now, IRC is mostly working, the next
will most likely be Twitter. The idea of this API to Omnibot will be message passing through several layers:
(from top to bottom, input to process and eventually application):
 
In to bot:
/ \
|  |
|M |
|E |   Application: The application will only receive the decrypted message along with flags confirming the authenticity of
|S |		   the user (their priv level, etc) and do whatever processing the plugin's function requires.
|S |   Authentication: Handles authentication on a per protocol basis. If the user is authenticated and encrypion enabled
|A |   		       it will perform the necessary decryption routines based on the user's key
|G |   Protocol: Handles connections and protocol specific identifiers + the input and passes it up to Auth ^
|E |
|  |

Out from bot:

|  |
|M |
|E |   Application: After recieving a message from the above process, it can send messages back to that user without needing 
|S |		    to know what protocol it was handling (although the data is available in the message)
|S |   Authentication: This will then encrypt (based on option) the message sent back to the user and send it down to protocol level
|A |
|G |   Protocol: The protocol level deals with the socket level sending similarly as the above except in reverse for send. 
|E |
\ /
 V

So what it comes down to is I need a very useful message object that supports multiple protocols, encorporates auth options (
hosts, private keys, encryption flags, priv level), channel options (like a protocol flag), and finally the data to be sent
down and up the stack.

first mock up of the object would look something like this:
class MessageObj(object):
    def __init__(self):
        # protocol specifics
	self.protocol = ''
	self.protocol_obj = none
	# is authenticated?
	self.is_auth = False
	self.auth_obj = none
	# channel -perhaps this should just go inside either auth or protocol... it is kind of specific in of itself tho
	self.channel_obj = none # for IRC this would be the nickname/channel, for AIM this would be the SN, for HTTP the cookie, for twitter the user
	

Also to note: the omnibot irssi plugin seems to be buggy, :| still working on it.

--testing commit with pydev here--