Seeking developer for Client/Server ''BBS'' for the new millenium.

Greetings, I am a developer myself - but do not have the skills to accomplish what I am looking for. But I think my skills as a developer will assist in painting a clear picture of what I am looking for and how I want it done. I am requesting the development of two pieces of software that will resemble an old school BBS coupled with the modern day client/server internet capable program. ## Deliverables What I am seeking is a cross platform piece of software that will consist of two pieces: Server: The server will accept connections from both the client, as well as web browsers and facilitate communication between the client or web browser to items such as file transfers, group chat, private chat, server to server synchronization and more. The server will basically be a service that runs with very little configuration directly other than to start or stop the service, and maybe configure specific ports for the c/s and web ports to listen on as well as define the root administrator username and password. Client: The client will not only act as the medium for accessing the server and interacting with its various functions - but will also be used to configure server parameters if a user with "Admin" rights is logged in. The client program will somewhat resemble an Instant Messaging program in its foot print on the users screen, but will contain many more options than typical IM programs currently contain. A web user who connects to the IP address that the server is running on and the specified "web port" will receive a dumbed down set of server functionality. Client/Server Functionality currently envisioned: * 100 percent of all communication will be encrypted. If the connection is over the web, encryption will be SSL. If the connection is via the client software it will be at minimum 128bit AES, with the option of 256bit AES. * All data stored on the server will be encrypted. * user account system - will consist of a basic username and password, with the ability for the administrator to force various password restrictions as well as username restrictions. a user with a valid username and password (i.e. the administrator created the user account) will be able to connect and interact based on the user level. If a user connects who does not have a valid username and password, they will be locked out of all functions other than sending the administrator a message requesting access. This will be based on a form that will collect name/handle, desired password, email address, and a note. The message will be sent to the admin and will also contain time/date sent and the IP address logged by the requestor. This will be the case regardless of whether the connection is created via C/S or web. The User Account System will also have an IP Allow/Deny function so that all IP's except those of valid users could be allowed, or if an admin chose all IP's could access the system in the case of new users being welcomed. * In addition to the standard user account access methods outlined above, the administrator will have the option of creating a "System Password" as well as a "New User Password", both of these passwords will be definable by the admin. The "New User Password", also known as the "NUP" will be required if a connection requests to send a note requesting access and the NUP flag has been set. The "System Password" will be required of ANY connection, and will be the first thing required/seen by any incoming connection if the flag is set. * Robust logging of all connections and activities on the system will be definable by the administrator via a series of check boxes either turning on or off certain parts of logging. * Multiple User: The server will allow X number of users to connect. The maximum limit will likely be around 50 users. * File Transfer: The server will provide encrypted file transfers (with the option to allow only file transfers to be non encrypted for performance reasons). The administrator will be able to create any number of "File Categories" that he wishes such as "Public Domain Software", "Internet Utilities", etc.. Depending on the rights a user has he will be able to see all, some or none of the file areas. Also depending on rights he will be able to list the contents of a file area, download, or upload. The file transfer module will determine if the files in the file area (or uploaded) are archives. If they are not archives, they will be placed into a ZIP, 7zip, or RAR archive and a admin definable text file will be inserted into the archive for the purpose of advertising where the file came from if distributed. If the file is already a known archive (zip, rar, 7z, etc..) the server will add the same comment file to the archive. If the archives within the file areas contain a specified text file, that text file will be presented as the description of the file to the user. If not, the description that the user (or the admin) uses for the file will be displayed. * Message Areas: The server will facilitate the storage of both semi-public "forum" type messages, as well as email like user to user messages. Again, message areas will have the ability to be restricted by the access that various users might or might not have. Message areas will use an extensive editor allowing for BOLD, italic, font size, etc... Replies to messages will be placed in a logical "thread" model. Threads will be collapsable. * Random messages: If clients have the permissions required to do so, they will be able to post a "random message" which will be be randomly selected and displayed as the users access the system - rotating as a user switches between the file area, and the message areas for instance. * Public Message "Wall": The system will have functionality to show a "wall" of messages to users shortly after logon. Wall message creation as well as access will be an access flag controlled by the administrator. Wall messages will have a short length and will be pruned after X number of wall messages are reached. * Public Chat: Users, if having the required access, will be able to enter into an IRC type chat room. Various commands will be able to be entered by users such as "/whisper <username> <message>", which will spawn a person to person conversation window within the public chat screen. * Private Chat: Works exactly like standard instant messaging, but also allows a user to invite one or more users to the private chat. * Site Sync: This will for sure apply to the message areas - and possibly other areas such as files... Site Sync will be an option when creating a file area, and will also allow for other sites to be entered into a textbox if the option is selected. As new messages are posted at one site, the messages will be transferred to any number of other sites specified. The remote site will require that the sending parties IP, or other identifier be within their own configuration and set as an "Allowed Site Sync Member". Messages will be Synced to a special message area at the receiving site that will be prepended with the remote site name, followed by the message area name. Replication of Site Sync data will occur in a fairly real time fashion - no less than in hour increments - preferably more like 5-10 minute increments. * Plugin Architecture: A simple plugin architecture or "Script" system will be developed that will allow an admin to create things such as "Link Directories", or other simple multi field lists within his system and then specify which user or user groups can access the newly created plugin. The plugin system would likely be the last item to be developed. * Flag/Strings System: throughout any messages or static text display pages, strings will be able to be used - an example would be "%sitename" - wherever this string was placed, the system would convert the string to whatever was defined as the "Site Name" within the site configuration. Web Access Functionality: * Initially, web access will utilize the login system, and file areas. The ability to access the message system would be something to be added at a later time. File access via the web interface will provide the filename (clickable link to download), file size, date uploaded, and description. Initially only downloads will be possible from the Web Interface - with uploads possibly coming later. This project is based completely on projects such as Haxial KDX, Hotline, and other similar client/server community projects. This project will be considered a "Darknet" as well as it will be encrypted, private, and inaccessible without username/password. While the description above smacks of old school BBS functionality it will be presented in a style very different from the textual nature of old school BBS software. I have the last version of Haxial's KDX software which will be used as a guide to building my project. I look forward to hearing from any and all who would like to take on this project. I am open to the development environment. I would very much like this to either be cross platform or easily ported to Windows, Linux, and OSX. I would also like at least a client version that would run on iphone/ipad and possibly others - but hand held device access will definitely be a back burner requirement. Finally - as a nod to the old school BBS's, I would like to eventually have the ability to create text and static graphics based games that could be imported into the system via the plugin system. Again, this would be a back burner item.