Building the Mainframe platform

Paul Le Cam
Hifi Finance | Official blog
5 min readOct 24, 2018

The Decentralised Web and Mainframe

The Decentralised Web, or dweb for short, is a new approach to Web development and technologies aimed at providing an alternative to current solutions centralised around large corporations collecting user data and censoring content with little to no oversight.

Various projects are currently being developed in this space, as presented in this Mozilla hacks blog series. While these projects often share a common vision and are strongly attached to the existing Web model, they provide different solutions when approaching the problems.

At Mainframe, we’re experimenting with yet another approach that, while using Web technologies, is more similar to standalone applications experience, as we hope to provide solutions for a wider range of problems related to Web browsers.

Swarm: the base infrastructure for web3

About a year ago the Mainframe team discovered Swarm, a project by the Ethereum foundation to store the ever-growing blockchain data in a decentralised way and a foundation layer for web3 apps.

Swarm provides APIs for both file storage and secure communications that the Mainframe team leveraged in the Onyx proof-of-concept messaging app presented during DevCon 3.

Since then, we have continued to work closely with the Swarm team to leverage this infrastructure for a more ambitious project we started to define earlier this year: building a fully decentralised and secure applications platform, putting users in control of their data and how they provide it to apps.

A different approach: a platform rather than a browser

We decided early on to focus on more than “just” being decentralised, and also provide strong security and data protection mechanisms by default.
Security can mean different things to different people, and obviously depends on the threat model users are facing. In the Mainframe platform, security means that:

  • Any data (files, messages, etc.) is encrypted unless explicitly made public by the user.
  • Potentially sensitive information such as physical location is only made available to applications through user permission grants.
  • Web requests are restricted to domains white-listed by the applications, and granted by the users.
  • Apps can only be installed and updated when authenticated by public-key signatures.
  • App contents are immutable and updates need to be approved by the users.
Users are asked to grant optional permissions to apps

For these reasons we determined that a traditional Web or Web3 browser would make it harder to provide this level of security without fundamental changes, and that a more “traditional” application model seemed better suited for our needs.

This approach also allows to push forward the user and developer experiences we want to provide, such as:

  • Fully managed user identities, with utilities provided to the apps (no need to login).
  • High-level platform interactions, such as interacting with user contacts in a trusted way.
Opening an app requires the users to choose what identity they want the app to interact with

In order to provide this kind of security at the platform level, we need an infrastructure that can support it, and notably could continue to exist even if Mainframe as a company does not.

Swarm seems to match this requirement by being a core project of the Ethereum foundation: having the purpose of storing the blockchain data, we can assume many different parties have enough incentives to keep the network alive, if only for financial reasons. It also potentially provides a large network of nodes, making dragnet surveillance of communications more costly and potentially less effective than with smaller networks.

Before installing apps, users can check the required and optional permissions

How it works: the Mainframe Platform stack

Schema of the Mainframe Platform stack

In the background: the daemon

This is the piece communicating with the infrastructure (Ethereum and Swarm) directly on behalf of the users.

It is responsible for managing the various user identities, application settings and wallets. All of its data is encrypted at rest in a file called a vault. In order to interact with the daemon, clients first need to create a new vault, or open an existing one.

A vault can only be opened by one client at a time, the daemon will reject access from other clients if one already has the vault open.

Unlocking a vault is necessary to allow a client to interact with the daemon on behalf of the users

Client interactions

The CLI and Launcher are both clients interacting with the daemon. The CLI is mostly meant for Mainframe and third-party developers to handle simple interactions with the daemon, while the Launcher is an Electron application meant to be used by users and app developers.

Developers can create new apps directly from the Launcher interface

The Launcher is the main application users and developers will need to install in order to interact with the Mainframe ecosystem. It allows developers to develop and publish their apps, that users can then install and run.

The Launcher is also responsible for enforcing the permissions requirements, prompting the user to grant access to specific APIs to the app.

Apps run in a sandbox (Electron webview) contained in a trusted UI displaying additional information to users

What is available now?

In September we published the documentation website of our JavaScript client for Swarm, Erebos. It is a core library used by the Mainframe platform to interact with the ecosystem.

We also released our first internal alpha version of the platform, built to validate our overall architecture assumptions by implementing some basic flows interacting with the various parts of our stack.

It is still at a very early stage in the development process and could not be used to create complex apps, but if you feel adventurous you can already start tinkering with it and tracking its progress in our GitHub repository.

What is next?

The roadmap page of our website is a living document giving an overview of our current progress and objectives.

For more technical details, you can check our project boards listing some of the tasks already defined. Tasks labelled as “good first issue” are a great way to get involved for developers wanting to help us out!

Where to go from here?

--

--