Overview

The ADAPT toolkit is designed to enable easily building a distributed secure data fabric (data layer) underlying internet applications. The data fabric is a replacement for a traditional application backend. In contrast to typical backends that reside within a centrally-managed server-side or cloud-hosted infrastructure, data fabrics are distributed data storage and processing networks that span both server and client environments and can include nodes belonging to multiple entities.

ADAPT Application Construction

An ADAPT data fabric is constructed out of ADAPT nodes, each of which hosts an ADAPT packet. Each ADAPT packet is a deterministic and portable data storage and processing environment. ADAPT nodes can reside as embedded components within the front-end software of an application or as server-side, cloud-based nodes.

ADAPT nodes communicate via a message broker.

Each ADAPT node is a request-response server. Workflows related to multiple nodes within the application must be constructed out of such request-response building blocks.

Identifying Node Categories

As a developer of the distributed data layer for a specific network application, you must first and foremost envision the types of nodes from which the data layer is constructed. Currently, the following categories are available:

• Front-end embedded node (mobile, desktop)
• Backend Linux server
• Backend AWS Nitro Enclaves

Choosing the best category for your use case requires understanding the threat model in your application.

Identifying Node Roles

It is possible within your application’s data layer to have nodes that play different roles. For example, you might need storage nodes that securely store customer’s data and also aggregator nodes that securely process information coming from multiple storage nodes. It is possible that both of these types must reside inside a secure enclave (Nitro node category) or that the storage nodes reside only on the front end of your application.

In either case, the role (function) of the node determines how it is programmed. The programming of a node is its request-response API consisting of transactions.

Identifying Counterparty Discovery Process

In order for nodes to form a cohesive network, they must discover each other’s addresses and public keys. Is there a role within your data fabric for an orchestrator node that introduces ADAPT nodes and provides a secure counterparty-discovery protocol?

Alternatively, counterparty discovery can happen through a secure channel, such as a QR code (much like additional chat application front-ends register themselves with existing ones, e.g. for WhatsApp and Signal).

Implementing MUFL Applications for each Node Role

To build your data fabric, you must implement the transaction API (packet interface) for each type of node in the form of a MUFL application. You can test your application using a Javascript test driver provided by the framework.

For front-end-embedded nodes, MUFL applications may contain transactions that arrive from other nodes, as well as those that process requests coming from the user of the application front end.

Embedding

Once all your node logic is implemented in the form of MUFL applications, the nodes should be embedded into your internet application. ADAPT nodes can be embedded into UI/UX front ends, Node.js backend software, and as standalone request-response servers.

Connecting

In order to complete the data fabric implementation, you need to deploy the ADAPT message broker and backup storage utilities (if needed). Click Contact Us in the top navigation bar of this page to reach out to the ADAPT team to get the necessary details on this process.