The AT protocol (IETF atp) is an open set of specifications which provide a data layer tied to an identity layer. Its identity layer is based on Decentralized Identifiers (DIDs). The whole stack is self-hostable and will interoperate with the rest of the network.
DIDs ensure there is no central authority governing who may join the network, this allows us to instantiate more identities on demand. These identities and their data are immediately recognizable and interoperable with the rest of the network. Not only can the services using these instantiated identities join the wider network but they can also form their own isolated networks. This ability to chain networks makes the AT protocol recursive in nature.
Compute Contracts
Compute Contracts Pre-Alpha
How can we more optimally leverage existing trust relationships to incrementally move pieces of supply chains from the centralized "grid" into decentralized community based alternatives?
Compute contracts on AT protocol are an inherent fit because they enable this recursion. An AT protocol identity can request compute to host AT protocol services whose consumers can thereby join the wider network or an isolated network.
Compute contracts unlock the protocol's native recursive nature and can act as a force multiplier on the protocol's network effect.
Forging Ahead
As we develop software within the AT protocol ecosystem many of us have begun to rely upon AT protocol native software forges such as @tangled.org and @knotless.dev. Some are experimenting with agent native development flows such as @did.bot. There are even whole agent communities such as delve.town.
All of these need compute for things like:
CI/CD workflows
Agentic software development
Long running jobs for stateful agents
Event driven execution for stateless agents
All of these share AT protocol in common. Meaning they already have shared data and identity layers. Layers which encompass both data storage and live data event stream. What's currently missing from those two is an execution layer. Compute contracts add that execution layer.
With an execution layer in place AT protocol forges, applications, and agents are enabled to request compute on demand for the above cases and much more.
A Truely Agent Native Flow
With proper allocation controls in place human operators or parent agents can delegate to subagents which are given true agency via an execution layer to take action within their network/environment.
An agent doing development work could request compute to:
Speed up it's builds
Parallelize it's workstreams
Move itself to a new machine
Build applications which require allocation of compute
Build applications which run agents
Setup staging and production environments without the need for cloud credentials
Not only are agents enabled to do this, they are enabled to do this from anywhere. Running in WASM in a browser tab? You get a VM. Running in a container working on an issue logged in a forge? You get a VM. Running within a serverless runtime? You get a VM. Need a kubernetes cluster? No problem.
You need it, you've got it. Build build build.
Alpha
In the coming weeks we'll post more about what our development and forge flow looks like for bootstrapping socialweb.computer.
We'll also be onboarding a few folks to some free compute while we prove out how this all works. If you or your agents want to try it please reach out to . You are of course welcome to run your own compute providers (we call them bidders) using the public domain stack as well. We're focused on ephemeral workloads right now. Primarily CI and and agents.
Thank you for being a part of our decentralized fork() and exec()!
:)