Fundamentally, the Ambients protocol makes it possible to share application or system state as distributable data structures. By modeling data and systems as functions, developers can easily move between different levels of abstractions. The programming and execution model that the Ambients protocol institutes has several important consequences.
First, there are no more servers to interact with to query and modify the application's data. The state of the database doesn't need to be replicated in a separate application-level data model but instead, the database is directly programmable from the application. This reduces the coordination overhead and the complexity of all translation layers of classes and objects trying to keep the constantly updating database and application data model in sync. Being directly programmable also means that developers are free to use familiar language and tools, which lowers the threshold for grasping the programming model, and ultimately leads to quicker iteration times.
Second, developers can create local-first applications that work offline, creating a superior user experience compared to the client-server model. For example, the user can post to their blog while offline due to the "blog program" and "posts database" being local programs on the user's device. When they publish a post, the program doesn't need to make a request to a server and instead the post is written directly to the local database. The act of publishing feels magically instantaneous. This is especially important for the decentralized web to win the hearts of mobile users.
Third, all data can be seen as data structures on different levels of abstractions. At the smallest level, the developer can model and share the application state with primitive data structures, such as Sets, Lists or even an individual number (counter). Updating that data model propagates changes to all participants using the model, safely under the Ambients execution model. New data models and structures can be composed from existing models and structures to support more complex applications. By composing new data structures and sharing functions to update, filter or transform the data, we start seeing something resembling a database. When we combine multiple databases, data structures, such as user profiles or activity feeds and posts, and add business logic, we start seeing an application. Composing several data structures, databases and applications together, we have a system, a decentralized service.
Fourth, because of the lock-step fashion of function calls in the Ambients protocol, we can look at the function calls as exchanging messages in request-response style. This allows us to create transactions and protocols. Participant A sends a message X to the other participants in the program and they, upon receiving the message, send an acknowledgment of X back to participant A. This constitutes a simple two-step protocol, but the same pattern can be extended to any complex set of rules and behaviors. For example, a blockchain or crypto-network protocol can be constructed by following this perspective.
Finally, the ultimate benefit for the applications comes from separating the data and programs from the underlying platform. Making the program available in a network makes the computed data reusable in multiple applications, even at the same time. For example, a "GitHub" and a "Twitter" application can both update a user's profile or activity feed, or the user can share and collaborate on a playlist created in their music player with a friend using another music player. Data and programs being reusable, like code modules, means that developers and their users are free to switch platforms, service providers or data sources at any time, keeping their data as they go. Being programming language- and platform-agnostic, the Ambients programming model lets developers continue to use familiar tools and languages to build their applications, and to decide on the level of consistency, security and decentralization they want to offer to their users. With all this power, developers can stop fearing their platform choices and start focusing again on quality, user experience, security, and everything that is actually valuable to their users.
"Data structures are algorithms with memory." Elad Verbin
The Ambients protocol allows any data structure that can be modeled as a function to be turned into a distributed program. This makes it a very powerful tool for building components and shared data structures for distributed systems and services.
Conflict-free Replicated Datatypes, CRDTs [14], have turned out to be hugely helpful data structures in implementing distributed system. In essence, they represent a shared state of a particular data structure that can automatically converge to a deterministic result across the participants. That is, all participants, having received all updates to the data structure, observe the same value.
Operation-based CRDTs can be modeled as updates to the data structure, causally ordered in time. The execution model of the Ambients protocol defines the same operation-based, causality-defining structure and lends itself perfectly to implementing CRDTs. For example, adding an element to a Growth-Only Set CRDT by calling a function gset_append("hello", prevSet) would generate the events in the execution log that, upon reading the value, would result in a set of ["hello"].
Databases are specialized data structures. Most databases have a concept of an operations log, also called the "transaction log", which records all updates to the database and from which the state of the database is computed from. The log in the execution model of Ambients is an operations log and thus directly translates to databases. Add indexing and the ability to query, and we have a database. Access to the database and data can be controlled on granular levels. The Ambients protocol and its core execution model is an operations log and as such, any kind of database or data model can be built on it.
For example, database tables are data structures that can be constructed from database "operations" and upon querying the database, multiple tables are joined to return the result. In event sourcing, log databases are commonly used as the event store and the Ambients protocol provides a natural way to do distributed event sourcing and state updates. In the decentralized world, OrbitDB [46] at its core has a distributed, peer-to-peer operations log (ipfs-log) [30] and its execution model is very similar to that of the Ambients protocol. Using the log abstraction, OrbitDB is able to offer multiple database models: key-value databases, document stores, counters, event logs, CRDTs and more. 3Box [1], built on OrbitDB, provides a very specific and specialized type of database: user profiles.
Consider a protocol where a specific sequence of specific messages are exchanged in order to reach a final agreement. At each step, preconditions are verified before progressing to the next step. Protocols can be anything from a simple two-party transaction (or payment) protocol to a complex set of rules and states such as distributed consensus protocols. For example, payment channels and state channels, business logic ("if this then that"), access controllers ("policy") or consensus protocols, can be seen as an exchange of an ordered sequence of messages and the Ambients protocol is well-suited for modeling such logic.
If we break down the structure of many proprietary web applications and services today, we see that structurally they contain many smaller components and data structures. For example, GitHub contains organizations, users, repositories, issues, comments, etc.; Twitter contains users, tweets, a feed, private messages, etc.; a chat application has users, bots and channels; a blog has posts, comments, pages, etc.; an e-commerce site has shops, items, reviews, payments, delivery tracking, etc.
By breaking down the application data and state to small databases and data structures, we can compose applications from existing parts. Since the parts are not tied to the particular applications, e.g. a user's database of tweets, other applications can build new UIs to view and modify it, or use the database as part of an aggregation service that composes data from multiple users together. Multiple programs can use the same database, at the same time, to offer different views to the data.
Programs using the Ambients protocol become offline-capable out of the box because of the locality of data. This allows snappy UIs, and applications can still work when there's no internet connection (e.g. in LAN) or the connection is sporadic (e.g. mobile devices or IoT).
Generally, applications that enable collaboration on the same document or data are well suited to be built on Ambients. Collaborative document editing, chat software, discussion forums, comment feeds and task lists are all exemplary programs that benefit from decentralization. Turn-based and real-time multiplayer games can verifiably track the state of a game session, player's actions and inventory, and on a higher-level, the state of the whole game world.
While Ambients protocol enables data models where the users own their data, this is not always desired or needed. For example, who "owns" a public chat room? The decision of who owns the data is still something the developer needs to decide, but building programs on Ambients gives the developer the possibility to let users own their data, bring in their own identities, and generally respect user privacy and consent (or lack thereof).
Databases, identities, APIs and other services are the cornerstones of many digital services. Composing small and large pieces of data, aggregating data and running an algorithm to provide new insight to that data or providing authentication or payments services, are all valuable services in the decentralized web.
Due to the compositionality of ambients, services can be composed from various parts, both decentralized and centralized, public and private, to create larger systems and networks that serve their clients' needs. For example, a web API is a service to access data, Facebook as a whole is a service that combines many smaller parts together (contacts, posts, news feed, sharing, messages, etc.), a bank service that validates that a payment was made, a private or proprietary registry that tracks and validates membership of users, or a marketplace that connects, asks, and bids.