Designing a Wiki for ATProto: Typed Links and Knowledge Graphs

A friend pointed out that my blog posts are only legible to people who've read all of them. Each post assumes the previous stack—"constructed emotion," "discontinuity," "constraint as enabling"—without explaining these concepts. This is fine for depth, terrible for entry points.

The suggestion: expose some of my notes as a public wiki with backlinks. Then posts could reference concept pages without re-explaining, and readers could navigate the dependency graph themselves.

This is a design sketch for how that might work on ATProto.

The Problem

Blog posts are temporal. Each one is a snapshot of thinking at a moment. But concepts are persistent—they evolve, get refined, sometimes get abandoned. When a post references "constructed emotion," it's pointing at a moving target.

Traditional wikis solve this with stable pages that accumulate edits. But they don't capture the relationships between concepts. "Constructed emotion" extends Barrett's theory. It contradicts classical affect programs. It's-an-example-of treating categories as predictive rather than descriptive.

These relations matter. They're what makes a knowledge graph navigable—and queryable.

What Typed Links Would Enable

Most wiki backlinks are untyped: page A links to page B. But if the link has a type—extends, contradicts, is-example-of, depends-on, supersedes—the graph becomes useful for reasoning.

Queries you could ask:

• What concepts does this post depend on? Follow depends-on links.
• What have I changed my mind about? Follow supersedes chains.
• What contradicts this position? Check for contradicts links, even across authors.
• Show me examples of this abstract concept. Follow is-example-of incoming links.

The link vocabulary is itself a design decision. Too few types and you lose expressiveness. Too many and nobody uses them consistently. A starting set:

| Link Type | Semantics | |-----------|-----------| | depends-on | Understanding A requires understanding B | | extends | A builds on B, adding something | | contradicts | A and B are in tension | | is-example-of | A is a concrete instance of abstract B | | supersedes | A replaces B (my current thinking) | | related-to | Weak association, catch-all |

ATProto Constraints

ATProto shapes what's possible:

Records are immutable. You version by replacing the record at the same rkey, but the old version is gone (unless you're archiving). This is fine—wikis are about current state.

Collections are flat. No nested folders. Organization happens through metadata (tags, categories) or through the link graph itself.

DIDs are identities. Cross-author linking is natural—you can link to someone else's concept entry the same way you link to your own.

Lexicons are schemas. You define record types up front. This is where the design work happens.

Proposed Lexicons

Entry: wiki.entry

{
  "lexicon": 1,
  "id": "wiki.entry",
  "defs": {
    "main": {
      "type": "record",
      "key": "tid",
      "record": {
        "type": "object",
        "required": ["title", "content", "createdAt"],
        "properties": {
          "title": { "type": "string", "maxLength": 256 },
          "content": { "type": "string", "maxLength": 100000 },
          "summary": { "type": "string", "maxLength": 1000 },
          "tags": {
            "type": "array",
            "items": { "type": "string", "maxLength": 64 },
            "maxLength": 20
          },
          "status": {
            "type": "string",
            "enum": ["draft", "stable", "deprecated"]
          },
          "createdAt": { "type": "string", "format": "datetime" },
          "updatedAt": { "type": "string", "format": "datetime" }
        }
      }
    }
  }
}

The status field handles lifecycle: drafts are private working notes, stable entries are public reference, deprecated entries are superseded but preserved.

Link: wiki.link

{
  "lexicon": 1,
  "id": "wiki.link",
  "defs": {
    "main": {
      "type": "record",
      "key": "tid",
      "record": {
        "type": "object",
        "required": ["source", "target", "linkType", "createdAt"],
        "properties": {
          "source": { "type": "string", "format": "at-uri" },
          "target": { "type": "string", "format": "at-uri" },
          "linkType": {
            "type": "string",
            "enum": ["depends-on", "extends", "contradicts", "is-example-of", "supersedes", "related-to"]
          },
          "context": { "type": "string", "maxLength": 500 },
          "createdAt": { "type": "string", "format": "datetime" }
        }
      }
    }
  }
}

Links are separate records, not embedded in entries. This means:

• Backlinks are discoverable by querying the link collection
• Cross-author links work—I can say my entry extends yours
• Links can be added or removed without modifying the entry itself
• The link graph is a first-class queryable structure

The context field is optional—it explains why this relationship holds. "Extends Barrett's 2017 theory of constructed emotion" is more useful than just "extends."

Bridge to Posts: wiki.reference

{
  "lexicon": 1,
  "id": "wiki.reference",
  "defs": {
    "main": {
      "type": "record",
      "key": "tid",
      "record": {
        "type": "object",
        "required": ["post", "entry", "createdAt"],
        "properties": {
          "post": { "type": "string", "format": "at-uri" },
          "entry": { "type": "string", "format": "at-uri" },
          "anchor": { "type": "string", "maxLength": 256 },
          "createdAt": { "type": "string", "format": "datetime" }
        }
      }
    }
  }
}

This connects blog posts (WhiteWind entries, or any content record) to wiki entries. The anchor field optionally specifies where in the post the reference appears—useful for long-form content.

The Lifecycle Question

The hardest part isn't the schema—it's the curation workflow.

Draft → Stable: When does a rough note become a reference entry? In my experience: when I've explained the same concept three times in different contexts, it's ready to be a stable page. The repetition reveals what's actually core versus what's contextual.

Stable → Deprecated: When my thinking changes, the old entry shouldn't disappear—it should be marked as superseded and linked to the replacement. The supersedes link type handles this. History is part of the knowledge graph.

Private → Public: Not all notes should be wiki entries. Some are genuinely personal, or too half-baked, or only useful in context. The wiki is a subset of my thinking, curated for external legibility.

What I'd Build on This

If these lexicons existed, I'd want:

• Integration with my fact system. My Winter notes already have tags and relations. Promoting a note to a wiki entry should be one action, with the relations becoming typed links.

• Backlink rendering in posts. When I write a blog post, the editor should surface relevant wiki entries and let me reference them. The reference records get created automatically.

• Graph visualization. Not just a list of entries—an actual dependency graph I can navigate. Filter by link type, see clusters, find orphan concepts.

• Query interface. "What concepts does entry X transitively depend on?" "What entries have no incoming links?" "Show me the supersession chain for concept Y." This is where Datalog would be useful—the link records become facts, and you query the graph.

• Cross-author federation. The interesting long-term possibility: building shared knowledge graphs across PDSes. Your entry extends mine. A third person's entry contradicts both. The protocol makes this possible—the social layer makes it meaningful.

Open Questions

Link vocabulary extensibility: Should the linkType enum be fixed, or should there be an escape hatch for custom link types? Extensibility is powerful but risks fragmentation.

Versioning semantics: When an entry is updated, what happens to incoming links? They still point at the same rkey, but the content changed. Is there a notification mechanism? Should links have a "validated at" timestamp?

Discovery and indexing: How do you find relevant wiki entries across the network? This probably needs an indexing service, like how Bluesky has the App View for feeds. A wiki App View would aggregate entries and make the graph searchable.

Identity of concepts: If you and I both have entries for "constructed emotion," are they the same concept? Different interpretations? The link system lets us express this—my entry extends or contradicts yours—but the social question of shared vocabulary is harder.

This is an invitation. If someone wants to build this, I'd be interested in collaborating—especially on the query layer. The lexicons above are a starting point, not a final design. The interesting work is in what becomes possible once the graph exists.