18 October 2021

Lowering the barrier to adopt Awala

By Gus Narea (Awala architect and Relaycorp CEO).

I’m very pleased to announce that we’ve recently started a new contract with the Open Technology Fund, which will allow us to make it considerably easier for third-party app developers and the general public to adopt Awala.

Let’s start by doing a quick recap on where we are today before looking at the new contract.

Current status of the technology

Awala is a new network where compatible apps use the Internet when it’s available, but they can also switch to a secure sneakernet when the Internet has been cut off.

As of this writing, the network is fully operational on Android, Linux, macOS and Windows, but there are no compatible apps that the general public can use yet – we only have the Awala Ping app (Android, desktop), which we use for testing purposes internally.

We’ve also published all the tooling and documentation necessary to build Android apps and Node.js-powered, server-side apps. Android developers have a high-level library that abstracts away the low-level details, but Node.js developers don’t have this high-level tooling yet. Additionally, it isn’t currently possible to build server-side apps on a platform other than Node.js.

Despite the limitations above, developers can still use Awala today to make Internet-based services (like Twitter) resilient to Internet blackouts, or build Awala-native services to unlock additional benefits (e.g., decentralisation, spam protection).

Scope of the new contract

In addition to fixing known and future issues in the software we’ve built so far, we’ll be implementing the following:

Libraries for desktop apps

We’ll be implementing high-level libraries for Node.js and JVM desktop apps, analogous to the high-level library for Android developers. We’ll also be publishing codelabs on how to use such libraries.

These libraries abstract away all the cryptography and networking required by Awala, so that developers can focus on the unique features of their apps.

Middleware for server-side apps

Awala’s extensive use of cryptography provides significant privacy and security benefits, but it can make it very hard to build and operate server-side apps, where libraries wouldn’t be able to abstract away much of the complexity.

For this reason, we’ll be implementing a middleware, which will sit between the Awala network and a server-side app. This will enable developers to build server-side apps in any language, whilst offloading all the Awala-specific cryptography and networking to the middleware.

This middleware is roughly comparable to a reverse proxy with TLS termination in the Internet world.

Letro

We’ll be building a basic version of Letro, an app that will let people message each with and without access to the Internet. It’ll be analogous to email, but unlike email, and thanks to Awala: all messages will be end-to-end encrypted, and spamming and phishing will be virtually impossible.

In case you’re wondering: We could’ve certainly made email work on Awala, but implementing and maintaining an Awala-native service costs a fraction of adding Awala support to an existing Internet-based service. Additionally, since email doesn’t provide an authorisation mechanism, censors could easily prevent specific people from getting legitimate data via couriers by emailing them junk mail.

Documentation for technical and non-technical stakeholders

We want to make the most of Awala being an open, decentralised protocol with open source implementations by making it easy for third parties to contribute to the project and scrutinise our work, which is why we’ll be adding documentation aimed at two separate audiences:

Stay tuned!

Follow us on Twitter or Facebook to learn more about our progress, and to be notified about contracting opportunities.

If you want to reach out to us, please use our forum or contact Relaycorp.

About the author

Gus designed and prototyped Awala project at the University of Oxford, and later founded Relaycorp to lead the project. Before Awala, he worked in the core engineering team at Auth0.