The Secure Communication Fabric
The Secure Communication Fabric (SCF) facilitates User to User Routing.
The secure communication fabric is composed of multiple layers operating concurrently and utilizing queues and back pressure to maintain flow control.
- The lowest level runs multiple ports on top of TCP, with its main function being the handling of certification, authentication, and encryption/decryption of instruction messages. These encrypted messages, typically less than 200 bytes, carry commands, descriptions, locations, and numerous keys, and besides other things, direct the disposition of information packages among applications and distributed storage facilities. In general the TCP sessions are always a single message long and where necessary contain sufficient data to maintain state.
- The next level up deals with the transmission of packages across applications and secured storage hosts. Utilizing access keys and routing information, packages are transported between agents and various internet storage locations utilizing the HTTP protocol.
- The third level handles the packing/encrypting and decrypting/unpacking of package contents and the interface to surface applications. Any number of files as well as complete directories can be assembled, compressed, and encrypted into a single package.
- The top level is the surface application, and in the case of the Social Media & Email Application, it is divided into two sections.
- The first manages all resident storage, processing, and the custom websocket interface to the local browser. This is also where the dynamically generated HTML code images presented to the browser are produced.
- The second is the browser itself and the application's relevant static HTML and JavaScript code.
All four levels are implemented in the Micro Social Media Agent installed on each of the user machines. The Dispatcher mainly processes instruction messages and either distributes or holds them for pick-up.
The System
The Agent, Dispatcher, and a dispersal of storage locations make up the physical components of the system supporting applications, of which the Social Media & Email App is the first. The block diagram below offers a simplified system view. The particular URL shown is unimportant as it is invisibly accessed to among other things provide load balancing direction. The single Dispatcher illustrated is representative of multiple units arranged to support performance, redundancy, and maintenance.
Direction of arrows indicate initiator of transactions, not flow of content.
Arrow | Description |
---|---|
Red | One-time transaction occurring during power-up |
Blue | Instruction messages |
Black | Information Packages |
Green | Occasional Special Activity |
Agent is coded in C. The Dispatcher, which has little resemblance to a conventional server, is part C and part impenetrable hardware.
The initial design specification was based on support for in excess of 100 million user accounts (PC with Agent), average of 5 thousand new posts per second, and a first response time for new content no longer that 3 seconds. To meet these requirements without the build-out costs, operating overhead, and unpredictability of conventional software solutions, portions of the Dispatcher are implemented in specially designed hardware. (This avoids the unreliable content listing often experienced by users of social media.)
Besides performing high level routing, the distributed architecture means a single request can invoke multipoint responses and thus collaborative contributions.
The Dispatcher
The Dispatcher comprises several main interconnected modules, including a message handler, an account database, and the Composer. It processes a limited set of custom commands riding TCP making it unsusceptible to HTML, PHP, SQL, JavaScript, or the other server code based attacks.
One of the primary activities of the message handler involves decrypting an Instruction Message using the Postkey of the originating Agent and re-encrypt it with the Postkey of the destination Agent. There are others, which are slight variations on the same theme such as PowerUp, Registration, LogIn, and Lobby requests.
The account database maintains all relevant knowledge for registration, LogIn, encryption, and other activities. It was designed to have quick store and retrieval of information by creating key indexes on the fly. Loaded with 100 million accounts, it can retrieve any entry within a maximum of 5 microseconds and learn a new one within 10.
The Composer, specifically architected to be implemented in hardware, creates client lists of post address messages out of originator channel lists. As well as performing very high speed distribution tasks, it prioritizes posts, giving Email status to requests and private communication. The cards, which fit PC backplane slots allow concurrent operation. The system design permits multiple cards in multiple PCs to function in parallel for supporting expansion, redundancy, and maintenance.
The Architecture
Besides security, significant advantages arise out of the architecture in terms reduced operating costs and efficiency. By remoting the server functionality, bandwidth requirements are dynamically reduced. Unlike the conventional client-server model where frequent exchanges can demand more bandwidth and open sessions, this approach does not.
Furthermore, it means less central compute power and storage is needed as client machines are now contributing their power and storage capacity. This reduces the need for a costly massive centralize database as complete information packages are transmitted allowing each individual client to perform their own selective mini-accesses.
Unlike the centralized solutions the need to order lists of posts for millions of clients is now performed by each individual client. Unlike the centralized solutions all major encryption/decryption is performed by each individual client. Unlike the centralized solutions all reminders, filtering, portrait retrieval, friend lists, selections, and on-and-on are performed by each individual client.
The architecture is also impervious to HTTPS/SSL weaknesses such as Fake and Illegal Certificates, Man-in-the-Middle, and persistent keys. There are never any direct connections between the network's members and all are "originate only" with no way to process http requests, preventing the unscrupulous from accessing a member's machine. Content is uniquely encrypted prior to entering the cloud and its constantly changing keys are themselves encrypted and travel at different times through different connections utilizing a different protocol.
Application
The Social Media & Email Application operates on two planes interconnected by websockets; one being the browser and the other the local host (or Agent). The browser runs resident HTML files and through Javascript interfaces with the C based Agent. This avoids some of the exploits leveraged by hackers to seize control of an individual's machine.
The Agent comprises two classes of resources, communication and operational. The communication includes TCP, HTTP, RSA, AES, SHA2, B64, and XML routines used by various procedures to establish and utilize connections with Dispatchers and storage facilities. The operational, or computational, handle dynamic HTML page generation as well as higher level processing.
That processing includes GUI interfaces and execution units for spreadsheets, interactive document editors, Python, BHO, and diagrammatic capability. However, only the spreadsheet is employed in the Social Media & Email application. It is the spreadsheet routines that manages the contact lists, all be it, behind the curtain. Its maximum capacity is 1,000,000 contacts by 4,000 channels, providing sufficient memory is available. To allow more than a million followers, select Unlimited when building the Lobby. (During the beta it will be possible to expose the console GUI shown below by left clicking the Harvester entry, located under the globe, while holding down the control key.)
The embedded resources provide support for among other things, distributed educational applications covering programming, statistics, science, and etc.
Private messages, requests, and allow-responses are considered email and their associated instruction message is given priority when routed through the dispatcher. Private messages can be published (broadcast) to an entire channel of recipients by the channel's owner. Asymmetric encryption can only be used when in direct communication with a single contact and is treated as email. All individual and group communication tagged as email take precedence and are routed ahead of social media type posts.