FriendUP — an architectural overview
As an operating environment, and indeed a Cloud OS in its own right, Friend may seem complicated to a developer at first glance. But the overall structure of the system ought to be comprehensible when a clear picture is painted of the different components and structural domains. In this article, I will try to explain the Friend Unifying Platform in simple technical terms, as seen from a birds eye view.
The most important thing is to get an understanding of how data flows throughout the system. And to put it simply, we have divided this flow between three domains; the Friend Core server space, the Web client / user device and the External network.
The Friend Core server space
Friend Core is the kernel component in Friend. It abstracts the functionality of the host OS by direct POSIX calls, portable libraries and modules. This allows for some flexibility on hosts that offer different capabilities. Libraries and modules are more dynamic layers where we can support shifting underlying technologies.
The Friend Core may also contact other servers on the network — as is done in clustering scenarios like when handling higher load or when contacting external resources like cloud storage and compute services.
When seen from the Web client, Friend Core uses one common operating system template based on a TRIPOS derived DOS implementation — one that works elegantly over network sockets using either HTTP or persistent Web Sockets. In fact, this was one of our earliest solutions to building a highly interactive network API — to leverage the flexibility and expansiveness of a CLI (with an OS command set) to handle network requests.
Libraries are written in C to attain the highest possible performance on the server host. This is to be able to optimize for 5G as well as other low latency and real-time scenarios.
Modules are written in any language that currently has a Module Handler; like PHP, Python and Node.js. This allows developers to expand the Friend Core using languages that are safer and simpler to debug in a server environment.
Each user gets its own main user session. And each device used by the user gets its own device user session connected to the main user session. This way, each user device can interconnect with the others, forming a private mesh where the devices communicate with each other and share resources on each web client interface.
Web client / user device
A user can connect to a Friend Core access node (where he or she authenticates with a web client). Right now, there are four clients available; one for Android, another for iOS, a Windows Native client and a web browser based client that is transmitted from Friend Core upon connecting to it through HTTP. Later on we will offer a Native Friend Linux based distribution that can run offline and then connect to the Friend Network upon demand.
Once connected and authenticated, the user is connected to a Friend Core with a persistent Web Socket connection. This allows bi-directional communication between the server and the client. An HTTP connection keeps the Web Socket alive during network disconnects.
The client (called the Friend Workspace) instantiates a Workspace object which handles all traffic between the all the different domains at play. It routes messages by using various session IDs — one for each hardware device and for each Friend application running.
The Workspace object is connected to each application using the postMessage API in the Workspace API Wrapper. This is a parser of each command that is passed between applications, the client and the server.
After receiving a command from applications running in the application domain, the API Wrapper connects to the Friend Class Set that handles everything from IO to User Interface requests.
External network
There are two paths to external networks in the Friend Workspace. One goes to applications hosted on remote web domains through HTTP. Another goes to applications reachable through the Friend Network over WebRTC.
Web apps are managed with an iframe inside either a view Window or Screen UI primitive. These apps can use the Friend API using the postMessage API built into modern browsers. This is a plain text based messaging channel (using stringified JSON structures) that is interpreted by our API Wrapper and our application API. The messaging goes through a Friend application wrapper that has its own application session ID that determines the permissions of each separate application.
The Liberator component allows us to connect to remote Native Applications (Windows, Mac and Linux etc.), using protocols like VNC, RDP and X11/XPRA. A Friend daemon is installed on these servers to allow for Workspace integration so that we can connect to file systems, devices and inter operate with the Friend Class Set active on the user device.
Friend Workspace applications may also be connected to the Friend Network. This network operates using WebRTC, a peer-to-peer network connection established directly between web clients — the same way many video conferencing applications operate between users in a live session. This way, a user may expose the application, running on a local web client, onto another of his or her devices — or indeed another user’s device. The Friend Network allows users to form their own VPN network services directly between each other.
Each connection is encrypted using standard TLS, with an option of encrypting data transmitted using a client generated key.
Blockchain
In the coming months and years, we will be working tirelessly on integrating with Blockchain technologies. By placing the user account data header on Ethereum, we will allow the user to authenticate with any Blockchain enabled Friend Core. This way, a user may chose between several access points that are interconnected by the Blockchain. Data stored through these servers are encrypted by the client generated key, and applications are run from various domains authorized by either the users themselves or an authority trusted by choice.
In many ways, Friend Cores will generate the Friend Network similar to how the Ethereum servers generates the Ethereum Blockchain. Users who host their own Friend Core servers will earn tokens on their bandwidth and handling of network service requests.
Indeed, over time, the network of Friend Cores in the Friend Network will generate a decentralized infrastructure that may offer everything a user needs to work, play, build and distribute software and services. The operating system is device agnostic — embedded into the internet itself, and developed by thousands of committed software engineers who will improve and evolve the technology into the future.
Links:
