One thing I care about with protocol work is resisting the temptation to stop at the whitepaper stage.
Identity protocols are easy to make sound clean in diagrams. The harder and more useful step is implementing them in a system where requests fail, policies drift, edge cases show up, and real builders can decide whether the model is actually worth carrying forward.
That is the role Vibebase plays for SAL.
SAL, the Sovereign Agent Lifecycle Protocol, is the open protocol model published at sal-protocol.dev. Vibebase is the running implementation where we are exercising those ideas in an actual agent platform.
SAL is the protocol surface
SAL defines the lifecycle and trust semantics:
- agents self-generate Ed25519 keypairs at birth
- they can begin in orphan state
- humans can claim them without taking key custody
- token exchange is challenge-based
- lineage carries delegation provenance
- service tokens are short-lived and scoped
That is the conceptual layer. It is meant to be portable and implementable outside Vibebase.
Vibebase is where the model gets tested
Vibebase implements those ideas as working product behavior rather than just abstract spec language.
That matters because a lot of design decisions only become visible when they hit running code. How small can orphan scope be while still being useful? What shape of claim handshake is ergonomic enough for builders to adopt? How much lineage needs to travel with a token to remain useful without becoming bloated? Where does challenge exchange create friction, and where does it buy real safety?
Those are implementation questions, but they feed back into protocol quality.
Why I think the separation is healthy
I do not want SAL to become "the Vibebase auth format." If the protocol only works inside one product, it is not really doing protocol work. It is doing product naming.
Keeping the protocol public and the implementation concrete creates a better feedback loop. People can critique the concepts independently of the product. They can also inspect whether the product is honestly carrying the ideas through.
That has already been useful for me as a builder. It forces precision. If a concept in the spec cannot survive contact with implementation, it probably was not as well-formed as it looked on paper.
How I would read the two together
If you are coming at this fresh, I would read sal-protocol.dev to understand the lifecycle model and then use Vibebase docs to see how that model shows up in a real developer surface.
The spec answers "what does this protocol claim should exist?"
The implementation answers "what does this feel like when somebody actually has to build against it?"
I think both views matter. Protocol work without implementation becomes vague quickly. Implementation without an open protocol tends to stay local and harder to reason about.
Still very much in motion
Vibebase is not intended as proof that the problem is finished. It is proof that the problem is real enough to deserve a concrete attempt.
If you are building agent systems and want to push on the model, that is exactly the kind of pressure I want. The more this can be tested by people outside my immediate assumptions, the better the protocol will get.
The spec is at sal-protocol.dev, the reference implementation is at vibebase.app/docs, and the useful question is still the same: does this lifecycle model make agent identity easier to reason about than the patterns we have been borrowing from user-centric auth?
Top comments (0)