-
Notifications
You must be signed in to change notification settings - Fork 0
3. Whitepaper π
This sections explains the inner workings of the project.
This project using the following languages / frameworks:
It also uses the following NuGet packages:
- Json.NET - fast and reliable JSON serialization
- sqlite-net - a simple, cross platform ORM for SQLite
Many thanks to the library maintainers for making this project possible!
As mentioned earlier, there are two classes of device on the Hosta network.
- Nodes - always-on servers, responsible for controlling the data of a user
- Clients - user interfaces, responsible for fetching and displaying data from nodes
A sample architecture is shown below, with each user having a node and a single client.
Each user is identified by a unique hex ID, generated from the hash of their public key.
Identity Address Resolver
Responsible for finding the node address of a given ID (a replacement for traditional DNS)
As nodes have a high uptime, they help power the IDAR service. When a client wishes to get the location of a friend's node, they will ask their own node for the address. Their own node will then resolve the query, returning the address to the client.
There are five main mechanisms that IDAR could use, in order of increasing complexity:
- Manual IP entry (impractical)
- Full mesh broadcasting (heavy on storage)
- Friend broadcasting w/ crash-recovery (light on storage, but very vulnerable to partitions)
- Blockchain (less vulnerable to partitions, but heavy on the CPU)
- Distributed hash table (light on storage, efficient queries, but hard to implement)
The ones that have been implemented have been ticked off.
The solution is divided into 3 main projects - a client application, a node program, and a core library (used by both the client and the node).
Note: Consider "x->y" to mean "x is dependant on y and y is not dependant on x".
"x->y->z" => "x->z"
The core library is responsible for definining the communication between devices on the network. Using it, anyone can create their own node or client!
Below is a diagram that outlines the structure:
Note: The diagram has simplifications to prevent visual clutter - the actual workings are a little less nice to look at!
The Hosta.Crypto
sub-namespace handles the common cryptographic operations across the namespace. It uses the following primitives from System.Security.Cryptography
:
- AesGcm - symmetric encryption
- RandomNumberGenerator - CSPRNG
- ECDH - key exchanging
- ECDsa - digital signatures
- HMACSHA512 - symmetric ratcheting
- SHA256 - hashing
The Hosta.API
sub-namespace provides commonly used tools. At the moment, these include:
-
AccessQueue
- an asynchronous queue, used to control access to a resource
-
Transcoder
- provides text encoding / decoding functionality
The Hosta.Net
sub-namespace builds upon System.Net.Sockets
to allow secure, authenticated, message-based (as opposed to stream-based) communication.
It uses a "layer" structure:
-
Socket[Client/Server/Messenger]
- wraps the default
Socket
APM functions with TAP functions - splits the socket stream into messages (using length prefixing)
- wraps the default
-
Protected[Client/Server/Messenger]
- performs an ECDH key exchange
- encrypts the connection using AES GCM
- provides backwards secrecy with KDF Ratchets (forwards secrecy may yet be implemented)
-
Authenticated[Client/Server/Messenger]
- allows a client and server to authenticate each other
- translates between strings and byte arrays
This layer structure allows resilient and reliable communications, without relying on tradional methods (such as certificate authorities or 2WSSL).
Disclaimer: Don't use the Protected or Authenticated classes for anything serious. I understand enough about cryptography to realise I know nothing :)
The Hosta.RPC
sub-namespace builds upon Hosta.NET
to allow for remote procedure calls in the form of Call(string proc, string args)
.
It consists of two main classes:
-
RPServer
- receives
RPCall
s and forwards them to a given ICallable - sends back an
RPResponse
when the call has finished
- receives
-
RPClient
- allows a client to send an
RPCall
to the server - returns the result from an
RPResponse
when the call has finished (or throws an exception if remote execution failed)
- allows a client to send an
The Hosta.API
sub-namespace provides the main functionality for the library, by building off Hosta.RPC
.
There are three main classes:
-
API
- an abstract class which acts specifies the remote procedures which can be called on the node
-
RemoteAPIGateway
- translates any incoming
RPCall
into anAPI
function call - returns the result to the
RPServer
- translates any incoming
-
LocalAPIGateway
- translates
API
function calls intoRPClient
calls - translates the response from the
RPClient
into meaningful data
- translates
There is also a Hosta.API.Data
sub-namespace which specifies the data structures for API requests and responses.