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.

9 min read • View on GitHub • More from gastownhall

A giant wanted board built from a database table fills a post-apocalyptic control room. Rows are pinned like bounty notices, while several branch lines split away and reunite across the board. The image explains the core idea that work is synchronized state, not static tickets.
Wasteland turns work into versioned state, then lets branches, reviews, and merges do the social heavy lifting.
Key Takeaways

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.

The protocol is not a message bus. It is a repeatable way to branch, edit, review, and merge rows across a shared database.

ModelWhat movesHow collaboration happensWhat stays authoritative
Traditional task boardTicketsCentral edits and commentsThe app server
Activity-style federationMessagesPeers exchange eventsThe inbox and inbox state
WastelandRowsBranch, propose, review, mergeThe 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.

A close-up shows a single work row forking into two paths. One path stays on a local rig where the row is edited offline. The other becomes a review proposal that moves toward a merge checkpoint where a validator applies a stamp. The image explains how Wasteland turns data changes into reviewable work.
A row change is not applied directly. It travels as a proposal, then earns its place in commons.

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.

SurfaceShared brainBackend choiceWhy it matters
CLIsdk.ClientLocalDB or RemoteDBFast automation and scripting
TUIsdk.ClientLocalDB or RemoteDBHigh-signal terminal workflows
Web UIsdk.Client via APIEmbedded service layerAccessible 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 updatePR mode
Edit the row in placePropose the row change on a branch
Acceptance is implicitAcceptance is explicit
History is incidentalHistory is the product
Best for private stateBest 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.

SystemStrengthWhat Wasteland changes
GitHub IssuesFamiliar issue workflowReplaces tickets with branchable work state
JiraStructured coordinationRemoves central admin as the only source of truth
Gas TownAI-heavy work environmentAdds federation across many users and communities
LinkedIn or CVPortable reputationMakes reputation auditable from actual work
Agent task frameworksAutomated executionTies 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.