Archipel Milestone 2: shipped and berthed

Archipel is a high availability solution for running services on decentralized federated hardware at home

Francois Branciard
Lugus Labs
5 min readApr 16, 2020

--

Archipel Milestone 2 shipped and berthed

TL:DR : In this Milestone 2 release, we improved security, UI/UX and added many new features to Archipel. The first service targeted by Archipel is a Polkadot validator service. We want to thank the Web3 Foundation for its grant program that allowed us to bootstrap this project.

Previously… on Archipel

In the previous post we introduced the emergence of the Archipel project: why and how it was done.

We have also presented Archipel and base layer technology used at P2P Paris Festival #0.

In the first Milestone, the following components were developed :

  • Chain is a component responsible for Archipel state synchronization between participants. Its goal is to provide a shared state for the federation and synchronize Archipel orchestrators. Archipel Chain is based on the Parity Substrate framework.
  • Orchestrator is the decision-making component of Archipel solution. It analyses federation node metrics and elects one leader node. Then it manages service by switching between active and passive service modes. This is the core component that ensures the high availability feature.
  • UI is a Web Interface to visualize Archipel chain state.
  • DAppNode package: DAppNode package wrapping Archipel stack. It allows installing Archipel from the DAppNode interface in one click.

To achieve Milestone 2, we focused on security improvements for a highly-available validator setup and improved UX/UI.

Security improvements

Our goal in this Milestone 2 was to leverage Archipel default security to comply with most of the best practices of running a secure validator setup.

For instance for a Polkadot validator, Sentry Nodes and VPN support are highly encouraged in the official documentation.

That is why we integrated the builtin support of Sentry Nodes, reserved peers, and WireGuard tunneling by default.

  • Sentry Nodes: the 2 passive nodes in the Archipel act automatically as Sentry nodes for the active validator node.
  • Reserved peers: the current validator node is only connected to the 2 passive, sentry nodes.
  • WireGuard: WireGuard VPN tunneling is used to establish an encrypted and secured connection between the validator node and the 2 sentry nodes.

WireGuard is a free and open-source software application and communication protocol that implements virtual private network techniques to create secure point-to-point connections in routed or bridged configurations.

WireGuard is not only used between the Polkadot validator node and Sentry nodes but also used to secure all connections within the Archipel stack.

Thanks to this secure WireGuard setup, we are creating private secure network access between remote DAppNodes.

Your setup is now :

  • Secured, with VPN tunneling.
  • Redundant, with 2 backup passive nodes.
  • Resilient, with different ISP and home hardware.
  • Trusted, within your family or friends.

Hourra!

Archipel CLI

UX improvements : One-click configuration

The Archipel CLI was created to simplify the configuration process. This improved significantly the ease of use of the Archipel solution.

Archipel CLI generates all necessary keys and configurations for you and provides, as a result, a config zip file ready to use and secured with an optional password.

The complex configuration friction is reduced by automatically creating, linking keys together and generating configuration data.

Those keys and configuration are needed to interconnect all components: Archipel nodes, Polkadot nodes, WireGuard VPN nodes, etc…

When the config archive file is generated, you just need to securely exchange the config zip between all Archipel participants.

Then, the DAppNode user installs the Archipel package, selects a node number and loads the zip config file.

After that, all Archipel components will be bootstrapped automatically.

UI improvements: Brand new Web interface and more

In addition to the smoother configuration, we have completely reworked the Archipel UI component.

In Milestone 1, the UI was a front-end connected to the local Archipel node rendering some data.

In Milestone 2, we took a different approach. Now Archipel UI is connecting to Archipel Orchestrator that exposes an API. It exposes all necessary metrics, states and allows us to perform some administrative actions:

  • disable/enable orchestration daemon
  • disable/enable metrics send daemon
  • stop/start( in active or passive mode) service container

This is how it looks :

Archipel UI

We also created 2 new DappNode packages:

  • Archipel UI package is automatically installed as a dependency of the main Archipel DAppNode Package. To retrieve data, the Archipel API local instance is automatically targeted by default.
  • Substrate Telemetry package is a wrapper package of the Parity Substrate telemetry frontend that you can install to bootstrap a private telemetry instance directly on your DappNode.

Last but not least,

The Archipel UI front-end is decentralized !!

Published and stored on IPFS, you can directly access it from ENS (Ethereum Name Service) : http://archipel.eth .

You have to configure the API endpoint to target one node of your Archipel to retrieve data. (You can not use a https IPFS gateway, if you want to target HTTP Archipel API, it will not work. Please use your local DAppNode IPFS provider, resolver and ENS forwarder).

Archipel v1.0 (Milestone 2) Release

Want to try it?

Your feedback is welcome!

What next we see from our lookout tower

Canary testing

In the following weeks, we will launch our Archipel federation on Kusama canary network.

That will allow us to gather feedback data, test more intensively and make more optimizations to the Archipel solution.

Of course, our project is open source so you can bootstrap your own federation. We will be happy to see your feedback and contributions.

But remember running your own infrastructure is also running your own responsibility.

Support others services

We plan to continue improving the solution and add more supported services. It can be other PoA or PoS blockchains and even any other P2P software.

Do not hesitate to contact us if you want to add high availability to your decentralized service.

Conclusion

We hope to transform this project into a community driven solution helping to bootstrap high availability setup everywhere it is needed.

Welcome aboard to all cloud shipwrecked and see you later as Archipel buccaneers !

--

--