Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/flancian/garden/llms.txt

Use this file to discover all available pages before exploring further.

The Agora knowledge graph is not stored in a single database. It is assembled on demand from many contributors’ notes by finding all writing that refers to the same topic and surfacing it together at a single URL. This distributed design means the graph grows whenever anyone anywhere adds a note that uses a topic name the Agora knows about — no central coordination required.

​
Nodes: topics as addresses

In the Agora, a node is a concept, a thing, or a topic. Every node has a canonical URL of the form: 
https://anagora.org/<node-name>
For example: 
https://anagora.org/distributed-systems
https://anagora.org/knowledge-commons
https://anagora.org/agora-protocol
Node names are derived from the topic text in wikilinks and file names. The Agora normalizes them: spaces become hyphens, casing is ignored, so [[Knowledge Commons]], [[knowledge commons]], and a file named knowledge-commons.md all resolve to the same node.
A node exists in the Agora as soon as at least one contributor has a file or a wikilink that resolves to its name. Nodes do not need to be explicitly created.

​
Subnodes: per-contributor views

Each contributor’s note about a topic is a subnode. When you visit a node at https://anagora.org/<node-name>, you see all subnodes stacked together — one per contributor who has written about that topic. 
Node: [[distributed systems]]
  ├── Subnode: alice/distributed-systems.md
  ├── Subnode: bob/distributed-systems.md
  └── Subnode: carol/notes/distributed-systems.md
Subnodes are the atomic unit of the Agora graph. Each subnode belongs to exactly one contributor and one node. The node is the aggregation of all its subnodes. This separation matters: you always know whose writing you are reading. The Agora does not merge or blend content. It lays contributions side by side so you can see each perspective independently while still benefiting from the aggregated view.

​
How the graph is assembled

Agora Server assembles the graph at request time. When you request a node:
1

Resolve the node name

The server normalizes the requested path to a canonical node name and searches the assembled content directories for all files whose names resolve to that node.
2

Collect subnodes

Every matching file becomes a subnode. The server collects metadata: contributor name, source garden, file format, and last modified time.
3

Process wikilinks

Within each subnode, wikilinks ([[topic]]) are resolved to Agora node URLs. A link to [[knowledge commons]] in any contributor’s note becomes a live link to https://anagora.org/knowledge-commons.
4

Execute social actions

#pull directives transclude content from other nodes. #push directives from other nodes that target this node are included. #go links are surfaced as declared intent redirects.
5

Render the assembled node

All subnodes, transcluded content, and resolved links are rendered together into the final page.

​
Local vs global graph

The Agora distinguishes between two graph scopes:
The local graph shows the immediate neighborhood of a node: the nodes it links to and the nodes that link to it. This gives you a navigable context around any topic without loading the entire graph. Local graph rendering is implemented (as a partial implementation) in Agora Server.
The global graph represents the entire Agora as a connected graph of all nodes and their relationships. It is available in development but is resource-intensive: the full graph of a large Agora requires significant memory and compute to generate. Work is ongoing to make it more practical, including exploration of RDF export and external graph visualization tools.

​
Wikilink resolution across gardens

Wikilinks are the primary mechanism for cross-garden connection. When contributor A writes [[agora protocol]] in their garden and contributor B independently writes a file named agora-protocol.md, the Agora resolves both to the same node — even though neither contributor has any direct knowledge of the other’s file. This is the core property that makes the Agora a distributed graph rather than a collection of isolated gardens: 
alice/garden/my-notes.md
  contains: "I use [[agora protocol]] daily"
                         |
                         v
  resolves to: https://anagora.org/agora-protocol
                         |
                         v
  displays alongside:
    bob/garden/agora-protocol.md  (bob's subnode)
    carol/notes/agora-protocol.md (carol's subnode)
No central index is required. Resolution happens at read time by normalizing file names and wikilink text to a common canonical form.
To link to an external URL as an intent rather than a wikilink, use the #go social action: #go https://example.com. This is surfaced on the node page as a declared destination from that contributor’s subnode.

​
The graph as a commons

The Agora graph is designed to be a knowledge commons: a shared resource that grows in value as more contributors add their notes, without any contributor having to give up ownership or control of their own writing. Each garden remains independent. Each contributor controls their own subnode. The graph emerges from the protocol, not from centralized curation. This makes the Agora graph fundamentally different from a wiki, where there is one article per topic, or a search index, where results are ranked and filtered by an algorithm. In the Agora, every contributor’s perspective on a topic is present and attributed.

Build docs developers (and LLMs) love

Get started for freeTalk to us