The ADAM Layer

ADAM

Over the last 3 years, the team behind Coasys has been building the ADAM layer, which is a new interoperable spanning layer that enables people to collaborate independently of specific apps or base-layer technologies. By sitting in between UIs and storage-layer technologies, ADAM unifies both the web2 and web3 ecosystem while simultaneously empowering the end user to retain full ownership of their data, identity, and experience.

Overview

ADAM, an acronym for Agent-centric Distributed Application Meta-Ontology, is a paradigm-shifting innovation designed to transform the way we interact with the digital world by bringing it closer to the natural dynamics of human communication.

In today's software development ecosystem, developers describe certain functions the user interface must understand in order to communicate with it. As a result, UIs become closely coupled with the backend it is built on, as well as the specific use cases of the application itself.

Often, this creates silos where applications become platforms with little maneuverability. Even in the current web3 landscape, apps are married to the tech stack they are using, leaving out the rich possibility of threading together services from different distributed ledger technologies.

The ADAM Layer distills the development of single and multi-user applications into a simple set of root axioms: 1) Agents, 2) Languages, and 3) Perspectives. These broad ontological units can be used to create any application which is modular, interoperable, and sybil protected.

In essence, ADAM serves as a spanning layer where multiple networks are abstracted to a common interface. It is a meta-ontology that does not make any assumptions about the specific implementations, which means all apps are mutually interoperable and carry little constraint as to what integrations can be built.

A Technical Overview

Agents

Agents are users, represented by DIDs (Decentralized Identifiers). DIDs serve as identifiers for agents across networks as well sources for cryptographic signatures that verify provenance.

DID integrations

By default, AD4M creates DID signing keys upon registration. However, it is also possible to use existing cryptographic keys as part of your DID document. This means support can be added for any web3 wallet to serve as the signing keys for an agent. This allows you to use your favorite wallet for key management while keeping your agent connected to any ecosystem it's involved in.

Languages

Languages are pluggable JavaScript modules which encapsulate logic to communicate with some given backend. As a result, a Language is what creates and receives data ("Expressions") from its respective backend, exposed through a common interface. Expressions are referenced via a URL: <language>://<language specific address> and are always cryptographically signed by the agent that is creating them in order to maintain provenance across networks.

Integration Possibilities

Since Languages have no inherent constraints as to what kind of objects they can create and retrieve, it is possible to build integrations to any network. For example, Languages can be created to return NFT meta data, return token balances from an address, call smart contracts, or even fetch data from centralized services.

Perspectives & Neighborhoods

Perspectives are the spaces where associations between expressions live and are described in the form of a semantic triplets (subject-predicate-object). These links are also encapsulated as expressions in AD4M and therefore inherit the provenance we gain from the expression / DID infrastructures. By default, Perspectives are local-only, but can be shared with other agents (users) to create what is called a "Neighborhood" - the basis of community spaces in ADAM.

Link Querying

The use of semantic triplets provides an easy method of association between expressions across networks. The backend for storing & querying these links is theoretically limitless, enabling discovery by any combination of subject, predicate, or object and eventually optional SPARQL as well. With this, your data is accessible via easy to follow primitives which can either be used directly or built upon to provide higher level abstractions such as OOP patterns.

Link Inference

In addition to the standard link querying, we also get a prolog engine built into ADAM. This engine can be used for high level link inference and mutation. With prolog, it is easy to build and run rules that can parse link data and create new links on languages based on the conditions set by your prolog scripts. This is extremely useful for programming highly custom behavior in communities.

Custom Views

ADAM also implements a common spec for UI components called: PerspectiveViews. We imagine these views to be specialized in scope, displaying unique interfaces of group structures found within Neighborhoods. Anyone leveraging ADAM can use them and as the ecosystem matures, many open source views will continued to be developed and accessible.

Summary

ADAM provides a simple meta-ontology that enables integration and interoperability between apps communicating with any backend. In this light, users and developers are able to leverage a variety of powerful infrastructures and services, creating highly flexible spaces that fit their unique needs.