AD4M
Agent-Centric Distributed Application Meta-Ontology
To deliver on the full potential of new social, it's important to us that Flux remains open to any infrastructure. This is made possible by the Agent-Centric Distributed Application Meta-Ontology (AD4M) created by Nicolas Luck and co-developed by Flux.
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.
AD4M 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, AD4M 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.
Here's how it works:
Agents
Agents are the entities, represented by DIDs (Decentralized Identifiers), that create and communicate using various backends via AD4M. DIDs serve as identifiers for agents across networks as well sources for cryptographic signatures that verify provenance.
DID integrations
By default, AD4M creates & manages 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 / DID. 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 on Flux.
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 AD4M. 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.
For example: rule that searches for N post + donation links for a given agent, once this condition is met, it automatically authors a link on behalf of this agent making an admin role claim. This gives a small insight into how scripting can be used on neighbourhoods to program highly complex and multistep permission rules and reputation systems.
Custom views
AD4M 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. Right now in Flux, we have PerspectiveViews that show both group chat and documentation-style interfaces. Anyone leveraging AD4M can use them and as the ecosystem matures, many open source views will continued to be developed and accessible.
Incentives
AD4M incentives the onboarding of new users & developers through its token. Developers that develop custom Languages or PerspectiveViews get rewarded by the AD4M network through proportional usage of their software. Money enters the AD4M ecosystem through crypto deposits that serve as an alternative to KYC in public networks. This is meant to negate sybil attacks and the value is recirculated towards incentivizing developers to build on its open ecosystem.
Summary
AD4M provides a simple meta-ontology that enables integration between apps communicating with any backend. In this light, we are able to leverage a variety of powerful infrastructures and services, without needing to roll out and maintain our own solutions. Some include Holochain, IPFS, Ethereum, and more.
Most importantly, AD4M also provides a critical layer of flexibility in adopting or migrating to different backends with ease and without needing to rewrite many lines of code.
Last updated