Actor Protection Commitment (APC) protocol, is an API-compatible approximation of the Actor Protection (AP) protocol, which mako is presently developing. AP will be decentralized, but AP will also be complicated and may take a few years to emerge, and mako wants to explore/demonstrate UX right now, so a much simpler centralized placeholder called APC will be used in the meantime. If the time comes to register an organization, we will put in place legal commitments to switch away from the centralized placeholder protocol by a certain time.
Why not federated? APC and its apps are open source, and the data is all self-verifying and either public or user-managed, so if we ever fail to host it responsibly, anyone else will be able to take over. We also think that once an AP-complete protocol emerges, federated protocols will stop making sense in general. Federation generally doesn't line up very well with the data caching needs.
APC
Features:
- Content-addressed distributed type system for defining schemas/API/mesa-standards in a resilient yet permissionless way. And it's a strong type system.
- Ability to express cyclical structure within content-addressed data. You might not think you need it, but we needed it for the type system, and we're guessing you'll need it too one day.
- First class support from the neschat browser.
AP
Today's decentralized protocols have been unable to circle the triangle of Fast, Reliable, and Cheap. Holochain and Freenet are Cheap and Reliable but not Fast; activitypub and atproto are Fast and Cheap but they lack verifiable finality of mutation; distributed ledger protocols like Convex or Solana are Fast and Reliable but not Cheap (or, they're cheap until they see mainstream adoption, at which point they will certainly no longer be cheap and might also no longer be fast). We believe that it's very likely that this tradeoff will be broken by ZKVMs by encoding the peering logic and network routing optimization into the core contract.
As soon as we can create or identify a protocol that circles the triangle in a way that can be abstracted well and made ergonomic, we will call that protocol "AP" and we will bless it with ports of our software.
The AP protocol is named after Actors (units of code that can send and receive messages to each other over the network) and the robust Protection of Actors. As long as the protocol can guarantee the safety and integrity of any actor who anyone is willing to pay the hosting costs of, then we'll have decentralized finality of mutation. You need finality of mutation for sovereign recoverable identities, or stuff where people can vote and decisions are made in the real world on the basis of the votes, or any civic mechanism that requires a lot of verifiable information from the public, for instance, an approach to ensuring that public journalism funding stays fair by allocating according to public appreciation surveys. But AP will also encompass usecases that don't require this kind of reliability, such as social media and chat applications. It's important that actors or indexes can be migrated to and from different hosting layers.
