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.