Introduction

Conntinuity links multiple computers (regardless of platform) together into one experience by streaming applications between computers and synchronizing files.

Conntinuity sample image: /conntinuity_1.webp

Background

I created Conntinuity so that I could merge the experience of multiple devices into one. As I see it, different devices have different benefits. For example, a laptop is easy to transport because it is thin and light; however, when compared to a desktop or server, these characteristics also limit a laptop as it will be unable to dissipate heat as effectively due to its smaller size. To combat these compromises (and to make life with multiple devices easier), I created Conntinuity. With Conntinuity, I strived to make a seamless experience between devices by synchronizing the files between each device as well as allowing each program to be streamed from one device to another—making it appear as if it was running locally, and allowing for a more dynamic workflow. For example, a developer could be working on an intensive program (such as AI, ML or a large simulation) from a laptop which cannot run the program. By using Conntinuity, this developer could automatically have the program’s files stored on another device (such as a desktop or server) and run the program on the other device, and have all of the results sent back to their laptop as if they were running the program locally.

How it Works

When developing Conntinuity, I attempted to structure it modularly. At a high level, these components could be seen as: the application protocol/backend (the core application), the user interface (UI), the file system, and the remote desktop functionality.

The Core Application (Application Protocol/Backend)

In Conntinuity’s structure, the modular components are managed by and communicate through one core program (which is written in NodeJS). This program is also responsible for Conntinuity’s Application Layer Protocol (or in other words, this program is responsible for managing communicating messages between peers). This protocol manages some of the application’s security, how to break apart messages and files to send them across the network, and more.

The UI

In the most recent version of Conntinuity, the user interface is a Java program which communicates to the “core” application to serve user requests.

The File System

Due to issues with IPFS, I ended up having to write my own system for managing the files that Conntinuity synchronizes. While a complicated system, at a high level, this system indexes the files which Conntinuity is supposed to synchronize. In this process the contents of each file are hashed and new files, changes to files, and file deletions are detected. When a change occurs to a file, this information is then relayed to the peers so that their files can stay synchronized. Instead of sending the contents of files whenever a change is detected, Conntinuity first communicates the new hash of the file. As Conntinuity addresses all files internally by their hash, if two files have the same contents, this allows a local file to be copied instead of requesting the file to be sent across the network.

The Remote Desktop System

The remote desktop system can currently be seen as having two parts: the architecture dependent system and the universal system. As different operating systems manage processes differently, information about them and capturing them must be collected in a system-dependent manner (for example, the Windows version currently uses a C# program to manage this, and the Linux version uses a bash script which leverages other packages). These system dependent programs are responsible for then providing this data to the universal system in a format that Conntinuity understands. At this point, the universal system takes over, and is what the user interacts with.

Language Changes

From the start, I knew Conntinuity had to be cross platform. Because of this, I tried to design Conntinuity in a way that would be easy to port to another operating system—including choosing programming languages that would make this easier. With this in mind along with ColIDE (which also used IPFS/LibP2P), NodeJS and electron seemed to be a logical starting place. While I was able to complete a small proof of concept with NodeJS, I then switched to Java to speed up development. Time permitting, I may add more information may be added to this section.

Security

Conntinuity protects user’s data with several redundant mechanisms:

TLS - All network traffic is encrypted with TLS before being sent across the network.
Connection Protector - Each peer provides a key to the routing server upon connection. The server will only allow peers with the same key to connect.
Peer List - Each peer keeps a list of known peers, and will not respond to any peer not on that list. In addition, unknown peers are shown with a red status indicator (more info on this soon).
End-to-End Encryption: All messages in Conntinuity's application layer protocol are encrypted end-to-end with AES-256-CTR. For two peers to communicate, they both must have the same key.
File Encryption: All files are encrypted before being sent to our hashing library and before being sent over the network with AES-256-CTR. Once again, these keys must match for peers to communicate successfully.

Timeline

2019-8-22
Project Started
2019-10-23
Conntinuity JS Proof of Concept Concluded
2020-6-21
Pre-Alpha Version 0.3.1 finished
2020-7-9
Pre-Alpha Version 0.3.2 finished
2020-10-17
Conntinuity.org setup to host project and route traffic
2021-6-8
Alpha Version 2.0.0 finished
Working on Next Alpha Version

Specifications

Language(s):	Java C# NodeJS C++ More depending on version & platform
Built With:	LibP2P/IPFS
Features:	File Synchronization Remote Desktop/Application Streaming Cross Platform Peer-to-Peer Many more in development
Network/Ports:	Routing Server: Conntinuity.org Port(s): TCP:6570
Security:	TLS 2x AES 256 bit keys Connection Protector Key Local Peer List For more details, see the above security section.