Agents, ai code executions are a very good use case.
I think anyone looking to use infra that needs below properties are well served by this project:
1. subsecond vm cold starts
2. kernel isolation (vs containers)
3. consistent local <-> remote environment
4. elastic cpu, memory.
5. ease to setup.
I am designing it as a infra primitive on purpose for general workloads as opposed to others in the microvm space i.e. firecracker was designed for lambda/serverless workloads.
It's (mostly) not the networking layer where people pay to target us. It's the application layer that would most benefit from being forked.
Of course the problem is that what can be forked already has been. Federated social media. Distributed git hosting. However most "essential" uses are centralized and often also commercial in nature. If you fork Amazon you're ... still Amazon. That sort of thing.
Hey, I'm one of the developers at Tempo. We're working on an extension type for subscriptions to propose being added to the spec as well! We're starting with the simple types, but subscriptions are a natural extension. The subscription intent will work similarly to a one-time charge—the server returns a 402 with intent="subscription", and the client signs a recurring authorization.
> MPP provides a specification for agents and services to coordinate payments programmatically, enabling microtransactions, *recurring payments*, and more.
I believe the Shared Payment Token is interchangeable with a payment method id that you attach to a customer object, but that link has very sparse information about how things actually work end to end and what objects mean what.
The irony that this was very clearly written by an LLM, double negation always the simplest and clearest tell.
reply