Engineering

SolarNET.HuB (SNH) uses for the project network a distributed architecture that takes care of three principal viewpoints of methods with huge networks. With distributed network architecture a separate basic control system can be managed, but the load can be allocated among various local sites. These sites can be physically segregated from each other but combined via the internet and, if one system breaks, the others can remain to work without being influenced. With separate servers, there is constantly the feasibility of overload as the network expands. Single servers are also likely to the entire network running down if the server is affected. With a distributed method the data amount is distributed among the diverse systems which make networking more active and more productive. There is no lack of configuration if the central server encounters any difficulties because it is shared among the secondary systems. Despite, the basic system also has the benefit of remaining capable to manage all operations, address security reforms, and observe the situation of the additional sites. Updates and modifications performed on the central server can seamlessly be combined with the entire distributed network without difficulty. The twofold benefit of having a central place of power but sharing a load of decision making with local sites goes for an extra reliable and effective system.

How does Distributed Network Architecture work?

There are various systems in distributed network architecture that all communicate with each other but are also able to function on their own. There is one central system that is related to the others, and that system can hold command over the others. However, each system also owns the liberty to be capable to run autonomously of the other systems of the network. Each link on the system as an administrator and the responsibilities that each administrator has command over can be arranged by the central node. Each of the places on the distributed network can differ in size, and some could have thousands of devices attached to the network while some might only hold a less. Despite the area of each place, all the devices can eventually be correlated following to the center.

What are the benefits of Distributed Network Architecture?

• Scalable: Distributed network architecture offers scalability much easier than particular networks. Because the load is shared, new devices can be attached and configured to the network without serious interruption to the entire network. In case of a particular network, too numerous devices can reduce the system performance down and freeze the server. This will not occur with a distributed network.

• More effective: The administrator of the central network can hold as full or as limited control as needed at every moment. This administrator can assign duties to node administrators and focus on additional responsibilities at hand. Though, as soon as a test or upgrade of the whole distributed network is needed, the central administrator can get command of that. The central administrator, holds access, to all the links, from the one system, and does not need many logins to reach them all.

• More secure: Because of the way the shared network design is set up the system is much stable and secure. It practices more limited bandwidth and can allow hardware or network malfunctions extremely better than a particular system. Also, if data on one system gets infected, it does not impact the whole system. With a distributed network structure in site organizations that possess networks of a huge quantity of devices, can be more reliable and sophisticated to delays.

Comparison (schema): Distributed vs Centralized vs Decentralized

SolarNET.HuB (SNH) uses for the project network a Gossip protocol.

A gossip protocol or epidemic protocol is a procedure or process of computer peer-to peer communication that is based on the way epidemics spread. Indeed, the mathematics of epidemics are often used to model the mathematics of gossip communication. The term epidemic algorithm is sometimes employed when describing a software system in which this kind of gossip-based information propagation is employed.

This means that information is able to distribute across multiple machines, without requiring direct connections between them.

Even though Alice and Dan lack a direct connection, they can still exchange feeds:

This is because gossip creates “transitive” connections between computers. Dan's messages travel through Carla and the PUB to reach Alice, and visa-versa.

SolarNET.HuB (SNH) uses for the project network a mesh network, and self-hosted social media ecosystem called Secure Scuttlebutt (SSB).

SSB uses a blockchain like append-only data structure and a fully decentralized P2P network. There are no servers or authorities of any kind. Like a crypto transaction, SSB posts are censorship-resistant and are replicated to the entire network.

In SSB each user hosts their own content and the content of the peers they follow, which provides fault tolerance and eventual consistency.

Partial replication

Traditionally, SSB replicates feeds by fetching the whole feed starting from their initial message. This is a major friction point for onboarding new users into the platform due to the huge amount of data the client needs to download before a feed is up to date, and the associated computing cost for indexing the new data.

Partial replication allows a client to selectively fetch slices of data starting from the most recent message instead. This allows the user to be able to see recent messages -without their client freezing up- as a result of smaller data transfers and with minimal indexing time.

Stream

You can think of an array as a structure that you move past like one of those fancy old libraries with the moving ladder. You move to the position the data is in, and the data stays put. A stream is more like a conveyer belt. You stay in one place, and the data comes to you. You just control fast it comes. It's a more restricted idea than the array, because with an array you can move backwards and forwards, but a stream can only pause or move forward (or abort).

Feed

A feed is a signed append-only sequence of messages. Each identity has exactly one feed.

Note that append-only means you cannot delete an existing message, or change your history. This is enforced by a per-feed blockchain. This is to ensure the entire network converges on the same state.

Secure Scuttlebutt (SSB) does not use “Proof of Work” to choose the next valid block for a global blockchain. Instead, each identity gets their own personal blockchain (a “sigchain”).

So bitcoin is 1 blockchain, SSB is many sigchains.

Cryptography

SSB operates as a database of immutable append-only feeds, which allows resilient replication over the Internet, local area networks, and sneakernets. Messages are hashed with SHA256 and verified with an Ed25519 signature; this makes it impossible to forge a message without the private key of the author.

Users only download messages from peers that they follow (and optionally friends of friends), which prevents harassment and spam. This makes the network invite-only, meaning that new peers who join the network aren't visible until someone follows them.

Messages are digitally signed and added to an append-only list of messages published by an author.

User content in SSB is organized as an append-only sequence of immutable messages, where messages cryptographically sign adjacent messages for the purpose of guaranteeing unforgeabilitity of the sequences as they are replicated to other peers.

SSB peers exchange asymmetric keys and establish authenticated connections between each other using an Authenticated Key Exchange protocol: Secret Handshake.

SolarNET.HuB (SNH) uses for the project network a free, open-source, peer-to-peer application and ecosystem that helps you follow content and discover new ones, called: “SNH-Oasis”.

Main features

• No browser JavaScript!. Just pure HTML+CSS.

• Use your favorite web browser to read and write messages to the people you care about.

• Strong cryptography in every single point of the network.

• You are the center of your own distributed network. Online or offline, it works anywhere that you are.

• Initial identities are randomnly generated (no username or password required).

• No personal profile generated (no questions about gender, age, location, etc …).

• No email or associated mobile phone required.

• Automatic exif stripping (such as GPS coordinates) on images for better privacy.

GUI

Roadmap

You can visit the roadmap to see what state is the current development and what are the future implementations that are desired to achieve.

A PUB is a relayer that is always online and relays messages between peers for cases when there are requests for feeds but their respective peers are offline. Also, if you have just reached our network and you have no one to add to start exchanging messages, this place will provide you invitations to see the inhabitants who, like you, want to expand their contact circle.

You can create your own PUB following this guide.

PUBs can easily be configured as Tor hidden services, as you can see in this other guide.

To join a public PUB all you need is an invite code. The invite code contains the PUB’s domain name, port, and public key.

SolarNET.HuB (SNH) has deployed for the project network a Public Server (PUB) called: “La Plaza”.

A ROOM server is an SSB peer with privileged internet presence (for instance, not behind a NAT layer) which allows its clients to perform tunneled connections wich each other. Connections between server and client are end-to-end encrypted via secret-handshake, as well as in tunneled connections between room clients, so that the room server cannot eavesdrop on the payloads in the tunneled connections.

You can have more information in the following paper.

SolarNET.HuB (SNH) has deployed for the project network a Room server (ROOM) called: “#SNH”.

“From small rules, it is possible to generate tremendously complex structures, as in Game of Life…”