Wasteland: When a Database Becomes a Federation Protocol for Work
A Dolt-powered system for claims, reviews, and reputation that treats rows like pull requests and communities like synchronized branches.
- Wasteland treats work as authoritative database state, so claims, reviews, and completions can be branched and merged instead of merely posted.
- Its real protocol is a schema plus conventions on top of Dolt, which makes federation feel like disciplined state synchronization rather than chat or event passing.
- The same SDK powers CLI, TUI, and web UI, so the interface changes but the work lifecycle does not.
- The lore of rigs, gas towns, and stamps is not decoration. It gives a federated reputation system a memorable social shape.
The weird idea: work as synchronized database state
Wasteland is easiest to understand if you stop thinking about task boards. It treats work as a database problem first and a UX problem second. Claims, reviews, completions, and reputation all live as rows that can be branched, proposed, and merged.
That is the twist. Most federation systems sync messages. Wasteland syncs state, and it uses Dolt’s Git-like semantics to make that state legible, reviewable, and durable.
| Model | What moves | How collaboration happens | What stays authoritative |
|---|---|---|---|
| Traditional task board | Tickets | Central edits and comments | The app server |
| Activity-style federation | Messages | Peers exchange events | The inbox and inbox state |
| Wasteland | Rows | Branch, propose, review, merge | The database itself |
Why the database is the protocol
The protocol is mostly a schema and a set of conventions layered on top of Dolt. That makes the network boring in the best possible way. There is no special transport layer inventing work semantics from scratch. Instead, the semantics come from versioned tables, branches, and merges.
That matters because legitimacy lives in the data. A claim is not just a UI event. It is a state change that can be inspected, rebased, rejected, or merged into commons with a clear history.
The Wasteland uses a socio-technical protocol that the industry has battle-tested for over a decade: Git’s fork/merge push/pull model.
How Wasteland hides one brain behind three interfaces
The codebase is organized around a single core client. The `sdk.Client` carries the lifecycle, while CLI, TUI, and web UI all call into the same logic. That is the part that makes the project feel engineered instead of improvised.
type ClientConfig struct {
CreatePR func(context.Context, *Item) error
CheckPR func(context.Context, string) (bool, error)
LoadPendingItem func(context.Context) (*Item, error)
}
client := sdk.NewClient(cfg)
// CLI, TUI, and web routes all drive the same lifecycle through this client.
The backend can be local or remote. If Dolt is installed, Wasteland can work with a local database. If not, it can talk to DoltHub over HTTPS. That lowers the barrier without giving up the versioned-data model.
| Surface | Shared brain | Backend choice | Why it matters |
|---|---|---|---|
| CLI | sdk.Client | LocalDB or RemoteDB | Fast automation and scripting |
| TUI | sdk.Client | LocalDB or RemoteDB | High-signal terminal workflows |
| Web UI | sdk.Client via API | Embedded service layer | Accessible shared interface |
Joining the federation feels like bootstrapping an identity
The join flow is the clearest sign that Wasteland is not just a board. It is a handshake. You fork the commons, register a Rig Handle, and write identity into the shared `rigs` table so the network can recognize you later.
That is a subtle shift. In many systems, identity is an account record attached to a product. Here, identity is part of the protocol itself, and it lives in the same versioned store as the work.
How do you 100x a Gas Town? You federate a hundred Gas Town users together to build stuff.
PR mode turns data changes into reviewable work
`ModePR` is the project’s most important workflow detail. In that mode, a claim or completion does not mutate shared state directly. It becomes a proposed change on its own branch, which makes review and approval first-class operations.
That is a better mental model than “editing a record.” Editing suggests immediacy. PR mode suggests accountability. It gives every meaningful update a diff, a reviewer, and a merge point.
| Direct update | PR mode |
|---|---|
| Edit the row in place | Propose the row change on a branch |
| Acceptance is implicit | Acceptance is explicit |
| History is incidental | History is the product |
| Best for private state | Best for federated work |
When someone accepts a PR in the Wasteland, they stamp the contributor’s passbook. The contributor gains some reputation, and it all goes onto a permanent ledger that could eventually act something like a portable C.V./résumé.
The aesthetic is not decoration
The lore is doing product work. Rigs, gas towns, brass, parchment, the-pile, passbooks. These names make the system feel inhabited instead of abstract. They also help a rare idea stick: a federated reputation ledger for work has to feel social, not bureaucratic.
That matters because a protocol without a culture looks like plumbing. Wasteland wants the opposite. It wants people to feel that participating in the network means entering a shared world with rules, memory, and status.
Where it fits in the landscape
Wasteland sits between task tracking, federation, and reputation systems. It borrows the review discipline of Git, the coordination goals of Jira, and the portability ambitions of a résumé system, but it combines them into one versioned substrate.
| System | Strength | What Wasteland changes |
|---|---|---|
| GitHub Issues | Familiar issue workflow | Replaces tickets with branchable work state |
| Jira | Structured coordination | Removes central admin as the only source of truth |
| Gas Town | AI-heavy work environment | Adds federation across many users and communities |
| LinkedIn or CV | Portable reputation | Makes reputation auditable from actual work |
| Agent task frameworks | Automated execution | Ties work to durable social and review history |
What Wasteland is really trying to prove
The bet is simple. If work history lives in a federated, versioned database, then reputation can become portable without becoming vague. That gives communities a record they can trust and contributors a history they can carry elsewhere.
The AI angle matters here, but it is adjacent. The larger claim is about coordination. Wasteland is testing whether a database can serve as the social contract for work, not just the storage layer underneath it.
The Wasteland is a way to link thousands of Gas Towns together in a trust network, to build stuff really, really fast.