All documents · Markdown

The Decentralized Library of Alexandria

A Persistent, Permissionless Network for Human Knowledge

Draft 0.6 — September 2026

Abstract

The Internet has open protocols for communication, but most useful digital information remains divided among private application databases. Search engines, streaming services, social networks, research systems, archives, commercial media platforms, and AI services each maintain their own catalogs. Publishers often submit the same work to several services. Users often need to know which service contains an item before they can find it. Public information can also remain fragile because a server, account, company, or institution can remove the only accessible copy.

Open Index Protocol, or OIP, provides a shared alternative. OIP is an open specification for a persistent worldwide index and file library. Its records can describe documents, media, people, organizations, places, events, datasets, observations, commercial works, AI models, Web pages, and other objects. Records can refer to other records through decentralized references called DREFs. These references form a typed knowledge graph that independent applications can search, extend, and interpret.[1][2]

Draft 0.6 separates permanent proof from data storage. Bitcoin provides canonical publication order and cryptographic proof. OIP nodes retain and distribute the structured record corpus. BitTorrent, IPFS, Arweave, HTTP, and other systems store and distribute large media files. Permissionless batchers combine many record commitments into Merkle trees and anchor the roots to Bitcoin. Storage providers can earn rewards when they prove that they retain OIP records and make referenced media available.

The Decentralized Library of Alexandria, or DLOA, is the browsable and searchable interface to this public graph. Alexandria.io is its primary hosted implementation. HYPATIA, the HYPermedia Agent for Transparent Information Access, provides the conversational interface. HYPATIA combines lexical retrieval, graph traversal, temporal and provenance filters, optional semantic retrieval, and retrieval-augmented generation. AskHypatia.com is the primary hosted conversational librarian.

Scribes of Alexandria provides a complementary browser-based capture and research interface. A user can capture a compelling Web page, preserve a timestamped representation, generate structured metadata and AI analysis, compare later versions, and ask HYPATIA questions about the page in the context of the wider OIP graph. Scribes can also offer publication into Alexandria when the user discovers information that may have lasting public value. In this way, ordinary Web research can become one of the mechanisms that grows the persistent public corpus.

Draft 0.6 also defines a complementary private system. Alfred Remembers applies the same semantic graph and retrieval architecture to the user's own life and work. Public Alexandria remembers the world; Alfred Remembers remembers the user. The private system can use Solid as its user-controlled storage and authorization layer. An interchangeable Context & Action Gateway, with OpenClaw as the preferred reference implementation, gives Alfred controlled access to local files, communications, applications, calendars, notes, reminders, and live Web information. HYPATIA can use authorized private context when a user permits it, while Alfred can call HYPATIA when the user's private work requires public knowledge. Solid's current architecture is designed around user-controlled Pods, WebID identity, interoperable applications, and permissioned data access.[17][18]

AI compute is also separated from the core protocol. HYPATIA and Alfred can run models locally, use institutional compute, or obtain external capacity through an interchangeable Compute Provider interface. Akash Network is the preferred decentralized compute marketplace for the reference implementation. Akash providers can offer CPU, GPU, memory, storage, and network resources in a competitive marketplace.[20] A user with suitable hardware can run a private local AI stack and can also, where operational requirements permit, choose to offer otherwise idle GPU capacity to Akash.

The system also supports commercial publishing. Publishers can set prices, access conditions, and the share of a sale that is available to Storefronts that complete transactions and Promoters that cause them. Commercial publishing fees can increase with the commercial value assigned to a work. Verified Publisher rules protect established commercial rights without preventing anyone from describing, criticizing, citing, or referencing a known work.[3]

The economic design follows the Salutary Protocol model developed in earlier OIP work. Thin Protocols create strong application markets but weak protocol-layer value capture. Fat Protocols create strong protocol-layer economics but can leave weak incentives for differentiated applications. A Salutary Protocol creates opportunities for value capture at both layers. Objective and verifiable services such as storage, settlement, retrieval, and measured compute compete at the protocol layer. Subjective services such as discovery, filtering, interpretation, recommendation, and interface design compete at the application layer.[4][5][7]

A Bitcoin-native fungible asset called ALT, the Alexandria Library Token, supports this system without requiring an Alexandria blockchain. ALT can use Taproot Assets on Bitcoin. It has four reinforcing economic functions: continued capital formation for a functioning network, a declining bootstrap subsidy for useful network services, productive staking for provider participation and HYPATIA inference, and decentralized governance through the Council of Librarians. A separate Corpus Growth Reserve can reward users who add unique and useful information to the public library. Taproot Assets permits assets to be issued and transferred with commitments anchored to Bitcoin while keeping asset-specific proof data outside the base chain.[10]

1. The problem: information is open in transit and closed at rest

The Web solved a major interoperability problem. A browser can communicate with millions of independent servers because those servers use common protocols and formats. A developer does not need approval from a central Web operator before launching a new application. This openness created strong network effects and supported extraordinary application-layer innovation.

The information stored by those applications did not develop in the same way. Search engines maintain their own indexes. Streaming services maintain separate catalogs. Social networks maintain separate graphs. Research publishers, government databases, archives, commercial data providers, and AI systems maintain separate stores. Much of the information is duplicated, but the databases do not form one common public index.

This structure gives applications an incentive to control data. A company can create a competitive advantage by controlling a catalog that another company cannot use. A publisher can therefore need separate relationships with several distribution services. Each service can require its own upload, metadata, account, terms, pricing model, and discovery system. Applications compete partly through exclusive access to information instead of competing only through the quality of the service that they provide.

The structure also makes information brittle. A URL identifies a location. It does not guarantee that the information at that location will still exist tomorrow. A server can fail. A company can close. A public archive can be reorganized. A social account can disappear. A source can be removed after other documents have already cited it.

OIP addresses these problems by making the index itself shared infrastructure. A publisher can publish one structured record to the Open Index. Many applications can use that record. An application does not need to own the catalog to compete. It can compete through search, curation, presentation, research, commerce, inference, or another service.

The objective is not to create one decentralized website. The objective is to create a common information layer on which many independent systems can operate.

2. Permissionless system design and limited standardization

OIP uses permissionless system design as a base principle. A participant does not need approval from Alexandria.io, AskHypatia.com, the Council of Librarians, or another central operator before publishing a structurally valid record, operating a node, building an application, or providing a network service.

Permissioned applications can exist above this base. An organization can maintain a private collection. A commercial service can require an account. A publisher can protect access to a purchased media file. These restrictions do not change the underlying public protocol.

The order matters. A permissioned application can be built on a permissionless protocol. A permissionless application cannot recover permissionless operation from a base layer that requires one authority to approve participation. Earlier OIP specifications therefore treated permissionless system design as a basic architectural rule.[4]

The second principle is limited standardization. OIP must standardize the parts of the system that independent implementations need to understand in the same way. These include record structure, identity, signatures, serialization, references, hashes, publication commitments, and verification rules. OIP should not standardize the parts of the system that benefit from user choice. Search ranking, recommendation, visual design, moderation policy, model selection, and editorial interpretation belong to competing applications.

Earlier OIP work called this an open jungle. Common standards supply interoperability, but they do not require all applications to become identical. Cooperation occurs around objective data. Competition occurs around subjective services.[4]

This rule becomes more important when AI is added. OIP can define the record and the evidence. It should not define the one correct summary of that record.

3. System architecture

Draft 0.6 separates functions that are often combined inside one platform.

The public side can be represented as:

                           BITCOIN
                  proof + canonical order
                             │
                             ▼
                   OPEN INDEX PROTOCOL
             public structured knowledge graph
                             │
            ┌────────────────┼────────────────┐
            │                │                │
            ▼                ▼                ▼
        BitTorrent          IPFS           Arweave
            │                │                │
            └──────── Web / other ───────────┘
                             │
                        media objects
                             │
        ┌────────────────────┼────────────────────┐
        │                    │                    │
        ▼                    ▼                    ▼
   SCRIBES OF         DECENTRALIZED             HYPATIA
   ALEXANDRIA            LIBRARY             public librarian
        │               OF ALEXANDRIA             │
 live Web capture             │                 AskHypatia.com
 + contextualization     Alexandria.io

The private side extends the same semantic approach without publishing the user's life into the public graph:

                            USER
                             │
                          ALFRED
                  private-first assistant
                             │
            ┌────────────────┼─────────────────┐
            │                │                 │
            ▼                ▼                 ▼
    Alfred Remembers       Solid           Context &
     semantic memory    private store     Action Gateway
            │                                  │
            │                            OpenClaw reference
            │                                  │
            │                    files / mail / calendar
            │                    notes / messages / Web
            │
            └────────── authorized bridge ──────────► HYPATIA
                                                     │
                                                     ▼
                                                    OIP

Both agents can use the same general inference infrastructure. Their differences are mainly role, policy, corpus, and personality.

4. The OIP record model

The basic OIP object is a record. A record describes an identifiable thing, event, statement, work, relationship, observation, model, Web capture, or other object.

A template defines the structure of a class of records. It specifies field names, types, validation rules, and relationships. A record supplies values that conform to that template. Current OIP implementations already use the template-record model and include DREF and repeated-DREF fields.[2]

Draft 0.6 uses a Schema.org-first convention. When Schema.org already defines a useful type or property, an OIP template should use that vocabulary where practical. A person can use Person. A company can use Organization. A photograph can use ImageObject. A movie can use Movie. A document can use DigitalDocument. A publisher remains free to define a new template when existing vocabularies are not sufficient.

Schema.org is not made authoritative over OIP. The purpose is to avoid unnecessary vocabulary fragmentation and improve interoperability with other systems.

4.1 DREFs and the knowledge graph

A DREF is a decentralized reference to another record. Its value is an identifier for another object rather than a private database key.

Consider an article that contains a video interview. The Article record does not need to copy all metadata from the Video record. It can contain a DREF to the existing Video. The Video can refer to its creator, location, and event.

Article
   │
   ├── author ───────────────► Person
   ├── about ────────────────► Event
   └── embeddedVideo ────────► Video
                                   │
                                   ├── creator ─────► Person
                                   ├── location ────► Place
                                   └── media ───────► Media Object

This structure reduces duplication and creates a graph.

The published DREF is directional, but a complete index can query the relationship in both directions. The Article knows which Video it references. The index can also determine every Article, Event, or Person record that references the Video. Incoming references therefore become useful data rather than hidden side effects.

This gives OIP some of the practical qualities that richer two-way hypertext systems attempted to provide while keeping the record model simple.

4.2 Stable identity, revisions, and provenance

A continuing object can change without losing its identity. OIP therefore separates a stable identifier from the content hash of one exact revision.

A stable DID identifies the continuing object. Each immutable revision receives a cryptographic hash and can refer to the prior revision. A DREF can refer to the current object or pin an exact historical revision.

This architecture has already been tested in a working private graph-memory system. That implementation uses typed records, stable identifiers, SHA-256 revisions, explicit DREF edges, provenance fields, time data, and rebuildable indexes. Its search database can be deleted and reconstructed from the canonical records without loss of durable memory.

The same system uses Schema.org types for people, places, products, events, organizations, creative works, and other payloads.

The same design gives public OIP a durable citation model. A user can refer to an evolving Person or Organization while another record can cite the exact revision of a statement used at a specific time.

5. Deterministic evidence and probabilistic interpretation

OIP needs a clear boundary between what the system can verify and what an analysis system can infer.

Deterministic evidence consists of facts that independent software can verify from the same inputs. A signature is valid or invalid. A content hash matches or does not match. A Merkle proof places a record inside a commitment or it does not. Bitcoin establishes a confirmed order. A provider returns the requested bytes or fails to return them.

Deterministic evidence does not mean that every statement inside a signed record is true. If a node signs a record stating that an API returned a Bitcoin price of a particular amount, the deterministic fact is that the node made that signed observation. Whether the value accurately represented the broader market remains a matter for additional evidence.

Probabilistic interpretation exists above the evidence layer. A model can estimate that two names describe the same person. It can summarize a document. It can infer that several observations describe the same event. It can identify an outlier or rank the likely relevance of a source.

These two classes should remain separate. Probabilistic interpretation should normally create Analysis, Assertion, or derived records rather than silently changing the Source Record.

This distinction is different from the Salutary Protocol distinction between objective and subjective work. Deterministic versus probabilistic describes evidence and computation. Objective versus subjective describes the economic character of a service. The two ideas complement one another.

6. Source Records and Analysis Records

When a document or media object enters OIP, the system first creates a Source Record. The Source Record describes the object as received. It can contain the content hash, publisher DID, publication time, media type, size, storage addresses, origin information, signature, and Bitcoin commitment proof.

An analysis system can then inspect the source. It can generate a summary and extract people, companies, places, dates, events, topics, claims, and other relationships. These results must not silently modify the Source Record. They belong in one or more separate Analysis Records.

Source Document
      │
      ├── Analysis A
      │      ├── producedBy ───► Model/version A
      │      ├── mentions ─────► Person
      │      ├── mentions ─────► Organization
      │      ├── location ─────► Place
      │      └── identifies ───► Event
      │
      └── Analysis B
             ├── producedBy ───► Model/version B
             └── ...

Each Analysis Record identifies the source, model, model version, method, time, and available confidence information. Another model can analyze the same source and publish a different record. Both remain visible.

Entity reuse gives this design much of its value. If a new document mentions an existing Person, Place, or Organization, the analysis can use a DREF to that entity when identity can be established with sufficient confidence. As more sources connect to common entities, the graph exposes relationships that would be difficult to find in isolated documents.

Entity resolution is itself probabilistic. Two references to “John Smith” do not prove that they describe one person. When identity remains uncertain, the system should record a candidate relationship rather than silently merge identities.

7. Observation Records: a timestamped record of the state of the world

OIP can store small observations as well as large source objects.

An Observation Record is a signed statement that an observer measured or retrieved a value at a specified time. Examples include a Bitcoin price, gold price, weather observation, exchange rate, government statistic, transit status, sensor value, or another externally observable state.

An Observation Record can preserve the subject, measured property, reported value, unit, observation time, observer identity, source provider, method, request parameters, and a response hash where appropriate.

A record can therefore mean:

Node A reports that Source B returned value C at time T.

It does not mean:

C is canonical truth.

That distinction allows many observations to coexist.

7.1 Shared cache and historical series

Observation Records provide a shared cache. If a HYPATIA node has just retrieved a time-sensitive price or weather value, another request within the appropriate freshness interval can use the signed observation instead of repeating the external request.

The same short-lived cache item later becomes a historical record. A value that was useful for only several minutes as current information can remain useful years later as a record of what several sources reported at that time.

7.2 Corroboration and source reputation

Large sets of observations also permit empirical comparison among sources. If several independent providers report similar values while one provider repeatedly produces large deviations, an application can detect that pattern without deleting the outlier.

The graph must retain the full provenance path. Ten nodes that all query the same upstream service are not ten independent sources. HYPATIA should distinguish source diversity from observer diversity.

Applications can calculate source or observer reputation from long-term behavior. Those scores remain derived interpretations. The original observations remain available so another application can use a different model.

8. Media Observation Records and cryptographic provenance

Observation Records can also describe photographic, audio, and video evidence.

The C2PA standard provides cryptographically bound provenance information, commonly surfaced as Content Credentials. C2PA is designed to verify provenance assertions associated with an asset, not to declare whether the content is factually true.[13]

OIP can use these credentials in a Media Observation Record. The record can contain a content hash, C2PA credential or reference, capture-time claim, optional geolocation, publisher identity, device or signer information when available, storage addresses, and OIP publication time.

These claims have different evidentiary strength. A valid credential can prove that the credential remains bound to the media. A device can claim a capture time and location. A Bitcoin commitment can establish that the exact media hash was committed by a particular time. No one signal must be treated as proof that the depicted event occurred exactly as described.

This makes media useful in a world of synthetic content without requiring Alexandria to become a central truth authority. HYPATIA can report that a photograph has a valid capture credential, that several independently credentialed images were created in the same place and time window, and that their content is mutually consistent. It can also disclose when those properties are absent.

Precise location remains optional. A publisher can disclose exact coordinates, a coarse location, or no location.

9. Scribes of Alexandria: capturing the live Web

The Web itself remains one of the largest sources of public information, but normal browsing does not create durable history. An article can change after publication. A paragraph can disappear. A headline can be rewritten. An image can be replaced. A page can vanish completely.

Scribes of Alexandria is the reference browser extension for turning useful parts of this live Web into structured Alexandria records.

A user activates Scribes while viewing a page that appears important. The extension reads the primary page content, extracts useful metadata, records the URL and canonical URL, takes a visual snapshot, calculates content hashes, and creates a timestamped Web Capture Record.

A Web Capture Record can contain:

• canonical URL;
• observed URL;
• page title;
• source publisher;
• author where available;
• stated publication date;
• capture time;
• extracted article or primary-page text;
• normalized text hash;
• visual snapshot hash;
• page or archival-package hash where retained;
• media references;
• outbound links;
• detected people, organizations, places, dates, and events;
• browser or capture-client version;
• provenance data.

The capture can remain private or be proposed for publication to OIP.

9.1 A Web Source and its captures

A Web URL should not be treated as one immutable object. The page at that URL can change.

OIP should therefore distinguish a continuing Web Source from individual Web Capture Records.

Web Source
    │
    ├── Capture T1
    ├── Capture T2
    ├── Capture T3
    │
    └── Change Analysis
           ├── added
           ├── removed
           └── modified

Each capture represents what an observer saw at a particular time.

When Scribes later revisits the same page, it can compare the current normalized content and visual representation with earlier captures. It can identify material changes such as a modified headline, removed paragraph, changed image, updated byline, or rewritten claim.

These changes should be represented as derived analysis. The original captures remain unchanged.

9.2 The live publisher remains the preferred reading surface

Alexandria should not replace the original publisher when the original source remains available.

If an article still exists at its publisher's site, Alexandria can present the title, summary, structured metadata, graph connections, revision history, and analysis while directing a user who wants to read the complete article back to the source.

The public record can therefore preserve that the article existed, what it discussed, how it related to other records, and how it changed without requiring Alexandria to become the normal reading destination for copyrighted journalism.

If the source later disappears, Alexandria can clearly report that the live source is no longer available and that earlier captures exist.

Public display of a complete archived copyrighted page should depend on the applicable rights, license, or other legal basis. The architecture should not assume that removal from the Web automatically grants redistribution rights. A user's private local archive can retain a complete personal research copy independently of what the public Alexandria interface is permitted to display.

9.3 AI analysis remains separate from the captured page

Scribes can generate an AI summary, extract entities, identify claims, produce an audio summary, and answer questions about the page.

These outputs should be separate Analysis Records linked to the Web Capture Record.

This means a future model can analyze the same capture again without modifying the capture itself. Different models can also publish different analyses of the same source.

The capture records what was observed.

The analysis records what a particular system inferred from it.

9.4 HYPATIA turns a page into an entrance to the graph

The most important expansion beyond a conventional “chat with webpage” extension is that HYPATIA is not limited to the page.

If an article mentions a person, HYPATIA can resolve that person to an existing OIP Entity and inspect other records that refer to the same entity. If the page describes an event, HYPATIA can connect it to other documents, photographs, Observation Records, organizations, and places that describe the same event.

A user can therefore ask:

Who is this person and where else do they appear?

What records contradict this account?

Did this organization appear in earlier documents?

Was this paragraph present in the first archived version?

What was happening at this location at the same time?

Scribes converts a page from an isolated Web document into a contextual entry point to the Alexandria graph.

9.5 Capture fidelity

A serious archival tool must distinguish changes in editorial content from irrelevant page changes.

Where practical, Scribes should preserve several representations:

• normalized primary text;
• visual full-page capture;
• article-region capture;
• relevant media hashes;
• canonical metadata;
• redirect history;
• DOM or normalized structural fingerprint;
• capture timestamp.

A comparison engine can then avoid reporting an advertisement rotation or recommendation widget as a meaningful editorial change.

9.6 Private capture and public publication are separate actions

A user should be able to capture a page for private research without publishing it.

A private Scribes capture can be stored through Alfred Remembers and the user's Solid-compatible private store. It can still be summarized, compared, and queried locally.

Publication to Alexandria is a separate action.

Before public publication, the user should see what information will become public. Private notes, personal browsing context, local file paths, and other user-specific context must not be included unless the user explicitly chooses to publish them.

This separation lets Scribes act as both a personal research tool and a public archival ingestion client.

10. Publication and Bitcoin anchoring

Earlier OIP implementations stored human-readable metadata directly in a blockchain. This gave every full node an ordered, independently reconstructable index. It also tied the cost and size of the index to blockchain data capacity.[3]

Draft 0.6 keeps the permanent ordering property and changes the storage model.

A publisher creates an OIP record, serializes it in a canonical format, signs it, and calculates the content hash. The publisher broadcasts the full record over the OIP network and submits a compact commitment to one or more permissionless batchers.

A Commitment Batch is an ordered collection of publication commitments. The batcher creates an ordered manifest, builds a Merkle tree, and commits its root to Bitcoin.

Record A ─┐
Record B ─┤
Record C ─┤
Record D ─┼──► Merkle tree ──► Merkle root ──► Bitcoin
Record E ─┤
    ...   │
Record N ─┘

The full record remains outside Bitcoin. A node that has the record, batch manifest, and Merkle path can prove that the exact record was included in the commitment.

Bitcoin also supplies canonical publication order:

Bitcoin block height → transaction position → Commitment Batch position

If several batchers commit the same record, the earliest confirmed commitment establishes its first canonical publication.

10.1 Permissionless batchers

Batchers are service providers, not gatekeepers. Anyone can operate one. Publishers can compare cost, settlement frequency, reliability, privacy, and other service terms.

Lightning is suitable for small publishing fees. The batcher receives commitments, assembles the batch, pays the Bitcoin fee, and publishes the root.

If existing batchers refuse a valid record, the publisher can create and anchor its own batch. Permissionless publication therefore remains possible.

11. Distributed record retention

A Bitcoin commitment proves publication. It cannot restore missing bytes.

OIP therefore needs an economic market for record retention. Archival providers store records, verify their signatures and Bitcoin commitments, and make them available to other nodes. Providers can store the full corpus or specialize in a defined portion.

Search databases remain derived data. A node can build full-text indexes, graph-edge indexes, temporal indexes, geospatial indexes, semantic vectors, or application-specific structures. These structures can be reconstructed from the signed record corpus.

This design preserves a useful property of the original blockchain-stored index: searchable state can be regenerated from durable underlying records without requiring Bitcoin itself to carry the complete metadata corpus.

12. Media storage and distribution

OIP records describe media but do not require media bytes to exist inside the record.

A Media Object can point to one or more copies on BitTorrent, IPFS, Arweave, HTTP, or another transport. A new transport can be added later without changing the identity of the object.

This creates redundancy across technologies. A file can exist on an IPFS provider and in a BitTorrent swarm at the same time. If one transport fails, another can continue to serve the same content hash.

Earlier OIP designs already treated file transport as interoperable infrastructure and included mechanisms intended to preserve under-replicated media.[3]

Draft 0.6 turns that principle into a permissionless provider market.

13. Proof of Retention and Proof of Availability

OIP needs to reward two related services.

Proof of Retention demonstrates that a provider possesses required OIP record data.

Proof of Availability demonstrates that a provider possesses referenced media and can actually serve it through a supported distribution network.

Possession is not enough for media. A provider that stores a file but refuses retrieval does not provide useful availability. Proof of Availability therefore combines data challenges with independent retrieval probes.

13.1 Historical and recent challenges

Arweave's original Proof of Access design selected an unpredictable historical recall block. Miners needed access to the selected historical block to produce and validate a new block.[9]

The basic idea is useful, but rarity can create a dangerous incentive if the publisher can manufacture the rarity. A publisher could publish data, withhold it from the rest of the network, and become the only participant able to answer a later challenge involving that data.

OIP should make this strategy unprofitable.

Each reward claim can therefore include two challenge classes. A historical challenge selects older reward-eligible data from Bitcoin-derived randomness. A recent-availability challenge selects material from a recent window of eligible Commitment Batches.

An initial implementation can use the five most recent eligible batches. The Council of Librarians can later govern this parameter.

13.2 Recent Availability Gate

A Bitcoin commitment does not automatically make a record eligible for storage rewards.

Before a new record enters the Reward-Eligible Set, its record data must reach a minimum number of independently verified replicas. Referenced media that claims distributed availability must meet a corresponding media threshold.

A publisher who keeps the only copy therefore receives no scarcity advantage. The material cannot enter the reward pool until it has propagated.

The rule applies per record or eligible subset. One unavailable record cannot stop rewards for the rest of the network.

13.3 Scarcity-weighted replication bounties

Availability changes over time. A file can have twenty verified replicas today and two several years later.

The protocol should respond automatically.

The Council can define a Replication Safety Target. When independently verified availability falls below that target, new independent replicas receive larger rewards. As the number of healthy copies returns to the target, the extra reward declines.

The scarcity bonus should primarily reward new replication. An incumbent provider should not receive a larger payment merely because other providers disappeared.

This produces a useful market signal:

Under-replicated data becomes more profitable to preserve until it is no longer under-replicated.

14. Illegal material, rights violations, and visible filtering

A permissionless publishing system must expect abusive publication. Copyright infringement, malware, child sexual abuse material, fraudulent records, and other prohibited content can enter a network that does not require prior approval.

The Bitcoin-commitment architecture creates a useful separation. Bitcoin stores proof of publication. OIP providers decide which bytes they retain.

Providers can subscribe to signed Policy Lists. These can identify known prohibited hashes, rights complaints, malware, publisher deactivations, or other policy categories. Different operators can choose different policies according to law, jurisdiction, and risk.

When a provider intentionally refuses a committed record, it can preserve a signed Tombstone Record. The tombstone can identify the record DID, hash, policy, policy version, reason code, classification source where relevant, time, and provider signature. It does not need to contain the prohibited data.

This makes filtering observable. A user can see that a committed record exists but is unavailable from a particular provider under a declared policy.

No cryptographic system can reconstruct an unknown preimage from its hash. If every holder deletes a file, Bitcoin can continue to prove that a commitment existed, but it cannot restore the bytes. The goal is transparent persistence and transparent omission, not an impossible guarantee that every byte remains globally available forever.

15. The Decentralized Library of Alexandria

The Decentralized Library of Alexandria is the graphical browser for the Open Index. It is an application above OIP rather than part of consensus.

Its principal hosted implementation is Alexandria.io.

The DLOA can provide conventional search, entity pages, timelines, maps, DREF traversal, reverse references, source provenance, revision history, Bitcoin proof inspection, media playback, Web Capture history, commercial access, and comparison among competing Analysis Records.

A user can open a Person and see the documents, images, events, places, and Web captures that refer to that person. A user can open an Event and move between a timeline, map, primary sources, Observation Records, and AI analysis.

Other developers can build different interfaces against the same public graph. A scientific client can emphasize datasets and citations. A streaming client can emphasize commercial media. A historical interface can emphasize maps and timelines. A journalist can build an evidence-review application.

The index gains network effects because its records are shared. Applications remain competitive because presentation and interpretation are not standardized.

16. HYPATIA: the public librarian

HYPATIA means HYPermedia Agent for Transparent Information Access.

HYPATIA is a public-first inference system above OIP. It does not own the knowledge graph and does not define a canonical interpretation of it.

Its principal hosted implementation is AskHypatia.com. A compact HYPATIA sidecar can also operate inside Alexandria.io and Scribes of Alexandria.

16.1 Graph-grounded hybrid retrieval

HYPATIA uses a graph-grounded hybrid retrieval system. It combines several retrieval methods instead of relying only on vector similarity.

A question can use lexical full-text retrieval, known-name and entity matching, forward DREF traversal, reverse DREF traversal, temporal filtering, geographic filtering, provenance filtering, optional vector similarity, and retrieval of associated source files and media.

The system ranks relevant records and gives a bounded context to the language model.

This method has already been validated in a smaller private graph-memory system. That implementation combines a typed knowledge graph with lexical retrieval and sends a short ranked set of records to the model. It can follow DREF edges in both directions and retrieve an object even when the object's name does not appear in the question.

This differs from simple vector RAG. Semantic similarity is useful for finding related text. A graph is useful for following explicit relationships that may not share similar language.

16.2 Transparent answers

HYPATIA should distinguish evidence classes when it answers.

A response can rely on:

1. Source Records;
2. Analysis or Assertion Records;
3. Observation Records;
4. Web Capture Records;
5. model knowledge that did not come from OIP.

These categories should remain visible.

The user should be able to move from an answer to the records that support it, from a record to the original source where available, and from the record to its publication and provenance information.

Transparency means preserving the information path. It does not mean claiming that the model is infallible.

16.3 Contextual use inside Scribes

When HYPATIA runs inside Scribes, the current Web page becomes one item in a much larger research context.

HYPATIA can answer a question from the current page while also retrieving related public records. It can explain a person mentioned in the article, identify earlier references to the same organization, compare the current page with earlier captures, or show records that provide contradictory context.

The extension therefore does not create a separate article-chat system. It uses the same HYPATIA engine and the same public graph.

17. Public knowledge and private knowledge

Draft 0.6 defines two distinct knowledge domains.

OIP is the permissionless public graph.

Solid-compatible private storage is the user-controlled private graph.

The same person, project, organization, or document type can exist in both domains without forcing private relationships into the public index.

For example, the public graph may contain:

Person: Adam
    ├── founded ───► Organization
    └── published ─► Public Work

A user's private graph may contain:

Person: Adam
    ├── discussed ─────► Private Project
    ├── participantIn ─► Private Conversation
    └── sameAs ────────► Public Adam entity

The public graph does not learn the private edges merely because the user has linked the identities locally.

This distinction lets an agent reason across both domains without making the user's private life part of the public protocol.

18. Solid as the private-data layer

Solid is designed to let applications access externally stored user data through interoperable Web mechanisms while the user retains control of the data. A user can use a hosted Pod provider or run a compatible server. Applications can read and write Pod data subject to authorization.[17]

Solid fits Alexandria because its design complements OIP.

OIP asks how public information can become a common graph that applications do not own.

Solid asks how private information can remain under user control while several applications can use it.

Both systems benefit from stable identifiers, semantic relationships, interoperable vocabularies, and separation between data and application.

18.1 Semantic compatibility

Solid uses RDF and Linked Data concepts and supports JSON-LD representations. OIP already uses structured JSON records and, in Draft 0.6, prefers Schema.org semantics where useful. This creates a practical semantic bridge.[17]

The public OIP protocol does not need to become an RDF system. The private client can expose or translate relevant records through JSON-LD where Solid interoperability requires it.

18.2 Authorization

Solid supports Web-based identity and access-control mechanisms. Its current ecosystem includes WebID, Solid OIDC, Web Access Control, and developing application-interoperability specifications.[17][18]

The user experience should hide most of this complexity.

Instead of editing access-control documents, a user should see controls such as:

Mail: Ask before use
Calendar: Allow
Project files: Allow
Private archive: Local only

Access control governs whether an application may read a resource. It cannot guarantee what every remote system does after authorized disclosure. Local retrieval and local inference therefore remain important privacy options.

Solid is an interoperability layer for the private client. It is not a dependency of the public OIP protocol.

19. Alfred Remembers: the private assistant

Alfred Remembers is the private-first agent built from the same general architecture as HYPATIA.

The distinction is conceptual rather than technological.

HYPATIA is a librarian. Its natural corpus is the public Alexandria graph. Its personality should be scholarly, source-oriented, and optimized for explaining public information.

Alfred is a personal assistant. Its natural corpus is the user's work and life. Its personality should be more operational and contextual. It should understand projects, schedules, communications, files, relationships, notes, explicit memories, and working history when the user gives it access.

The same core services can power both:

• graph retrieval;
• lexical retrieval;
• embeddings;
• reranking;
• entity resolution;
• model routing;
• inference;
• speech-to-text;
• text-to-speech;
• tool calling;
• provenance handling.

The implemented Alfred memory system already uses five typed memory primitives, Schema.org payloads, DREF relationships, revision hashes, provenance, full-text retrieval, and graph traversal.

The difference between HYPATIA and Alfred is mainly corpus and policy.

Alexandria remembers the world. Alfred remembers you.

19.1 Collaboration between agents

The distinction does not create a wall.

Alfred can ask HYPATIA for public knowledge:

I am meeting this person tomorrow. Bring me up to date on the public work that is relevant to our last conversation.

HYPATIA can request authorized private context:

You have private research related to this person. Include it in this analysis?

The user remains in control of the crossing point.

This gives the system specialized agents without creating separate information silos.

20. The Context & Action Gateway

A personal assistant needs access to information that may never appear in a convenient cloud API.

Some services expose mature APIs. Other useful information lives in local applications, synchronized files, desktop software, authenticated browser sessions, or operating-system databases.

Draft 0.6 therefore defines an interchangeable Context & Action Gateway.

The gateway has three roles.

Personal context

It can access authorized local information such as files, mail, calendars, contacts, messages, notes, reminders, and local application data.

Live external context

It can access current information that is not yet in Alexandria through Web search, page retrieval, browser automation, and external APIs.

Actions

It can perform authorized tasks such as creating an event, drafting a message, creating a reminder, modifying a file, navigating a Web application, or invoking another local tool.

The protocol defines the gateway capability, not one software package.

OpenClaw is the preferred reference implementation. Current OpenClaw tooling includes Web search, Web fetch, and a managed browser that can open pages, read them, click, and type.[19]

This keeps Alfred from having to build and maintain a custom integration for every operating system and application.

21. Raw personal data versus durable personal memory

Alfred should not convert every byte of a user's digital life into permanent semantic memory.

A user can have hundreds of thousands of emails, years of messages, many gigabytes of files, and large application histories. Much of this information is useful only when a specific question requires it.

The private architecture should therefore separate source access from durable memory.

Mail / Calendar / Files / Messages
                │
                ▼
       Context & Action Gateway
                │
        searchable source data
                │
          ┌─────┴─────┐
          │           │
          ▼           ▼
  temporary context   durable knowledge
                          │
                          ▼
                  Alfred Remembers
                  private semantic graph

An email can remain in Mail. Alfred can find it when necessary.

If the email establishes a durable fact, Alfred can create an Assertion or Entity relationship in its private semantic graph and preserve a reference back to the source.

This gives the user the benefits of long-term memory without turning every email sentence into a permanent Assertion Record.

22. Two paths from the live Web into Alexandria

Draft 0.6 defines two related Web-ingestion paths.

The first is agent-driven discovery. Alfred or HYPATIA searches the Web because a question cannot be answered from existing data.

The second is human-curated discovery through Scribes of Alexandria. A user finds a page during ordinary browsing and decides that it is worth preserving or investigating.

Both paths can create candidate OIP records.

22.1 Agent-driven ingestion

Suppose Alfred or HYPATIA receives a question that cannot be answered by the public OIP corpus, a fresh Observation Record, authorized private memory, or a predefined data API.

The Context & Action Gateway can search the live Web.

If it finds information that appears novel, durable, or useful beyond the current request, the client can offer:

Preserve this in Alexandria

The system can prepare a Source, Observation, or Web Capture Record, extract metadata, identify entities, add DREFs, preserve provenance, and show the user what will become public.

Private context that caused the search must not leak into the public record.

22.2 Human-curated ingestion

Scribes begins from the opposite direction.

The user already has a page open. The user has decided that the source is interesting enough to inspect, archive, or discuss.

This human choice is itself a weak but useful relevance signal. It indicates that a person found the source important enough to take action.

A Scribes capture can remain private or become a candidate public contribution.

22.3 The knowledge-gap loop

Together, these paths produce a useful cycle:

question or browsing
       │
       ▼
interesting or missing information
       │
       ▼
live Web source
       │
       ▼
capture + analysis
       │
       ▼
optional OIP publication
       │
       ▼
persistent public knowledge
       │
       ▼
future researchers use Alexandria
instead of rediscovering the source

The network can therefore grow from normal research activity rather than only through dedicated archival projects.

23. Local inference as a first-class deployment mode

Local execution should be a first-class deployment option rather than an expert workaround.

This matters most for Alfred Remembers because its natural corpus is private. It can also matter for HYPATIA. Public records may be public, but the user's research questions, investigation paths, hypotheses, and selected evidence can be sensitive.

A journalist, attorney, researcher, analyst, or private citizen may therefore want to use public Alexandria data while keeping inference and research behavior local.

The local client should support several model roles:

• language and reasoning model;
• embedding model;
• reranker;
• vision model;
• speech-to-text model;
• text-to-speech model;
• specialized extraction models.

The installer should inspect the user's hardware before recommending models. It can detect available memory, supported GPU type, GPU memory, CPU capabilities, storage, and other relevant resources.

The interface should then explain model fit in normal language.

This model fits comfortably on your computer.

This larger model will run, but response speed will be lower.

This model requires more GPU memory than your computer provides.

The user should not need to understand quantization formats or VRAM budgeting before installing a private AI stack.

24. AI models as OIP records

The model catalog itself can use OIP.

A Model Record can describe:

• model name and family;
• version;
• publisher;
• parameter count;
• architecture;
• quantizations;
• context window;
• modalities;
• tool-calling support;
• supported runtimes;
• hardware requirements;
• license;
• content hash;
• download addresses;
• recommended use cases.

A separate Model Performance Observation Record can describe measured performance on specific hardware.

Model: Example 32B Q4
Hardware: RTX 4090
VRAM: 24 GB
Runtime: vLLM
Observed throughput: ...
First-token latency: ...
Observer: ...
Date: ...

Another Observation Record can describe the same model on Apple Silicon or another GPU.

The local installer can therefore query a shared corpus of model metadata and real performance observations rather than depend on one proprietary compatibility database.

The model recommendation becomes another application of the OIP principle:

standardized public metadata + competing software interpretation.

25. Local privacy profiles

The reference client should support clear deployment profiles.

Private

Private retrieval and inference stay on hardware controlled by the user whenever the required local models are available.

Balanced

Private retrieval remains local. The system can send only the minimum selected context to approved external inference providers when local hardware is insufficient.

Performance

The system can select the most capable approved model regardless of location, subject to the user's data permissions.

Advanced users can configure each model role separately.

Speech should follow the same model. A user can run STT locally, TTS remotely, and the language model locally, or choose another combination.

The architecture should not force one permanent privacy tradeoff because one component is difficult to run locally today. Components can move onto local hardware as models and software improve.

26. Interchangeable compute and Akash Network

Alexandria should not create its own GPU marketplace when an open compute market already exists.

Draft 0.6 defines an interchangeable Compute Provider interface. HYPATIA and Alfred can send approved inference workloads to any provider that implements the required interface and service policy.

The reference implementation uses Akash Network as its preferred decentralized compute marketplace.

Akash providers advertise compute resources and compete for deployments. Current Akash interfaces expose GPU models and available capacity, and the marketplace can match deployments with providers based on resource requirements.[20]

HYPATIA therefore does not need to build its own GPU discovery, provider bidding, hardware inventory, deployment system, or price-discovery market.

Akash is not a protocol dependency. A local GPU, an institutional cluster, another decentralized market, or a future service can implement the same compute role.

27. Local compute can also become market supply

A user with a powerful local machine may use that machine only part of the day.

When supported by the external marketplace and chosen by the owner, otherwise idle resources can become compute supply.

Akash permits operators to become providers and offer compatible compute resources, including supported GPUs. Current provider operation requires a real provider stack and has hardware, networking, and operational requirements. It is more involved than simply enabling a desktop preference.[20]

The Alexandria client should therefore treat this as an advanced and explicit opt-in capability.

For compatible systems, it can inspect hardware, explain whether the system is suitable, and guide the user toward provider configuration.

This creates a useful cycle:

powerful local hardware
        │
        ├──► private Alfred/HYPATIA inference
        │
        └──► optional idle compute supply
                         │
                         ▼
                    Akash market
                         │
                         ▼
                    provider revenue

The ecosystem can buy external compute when local resources are insufficient and supply compatible idle compute when users choose to make it available.

28. Commercial publishing and open distribution

OIP is also a commerce protocol.

A publisher can create a commercial record for a television program, movie, audiobook, game, song, software package, research product, or another digital work. The record can define prices, access conditions, media locations, rights information, and payment terms.

The media can remain encrypted or access-controlled while its public metadata remains discoverable. A successful purchase can release a decryption key, access credential, stream authorization, or another right.

OIP should support many commercial models, including purchase, rental, pay-per-view, subscription, metered access, streaming, download, tipping, and non-financial exchange.

28.1 Storefronts and Promoters

A Storefront is an application or interface that helps a user discover a commercial work and completes a purchase.

A Promoter is a person, account, application, or automated agent that causes an attributable sale.

The publisher defines the economic opportunity available to each role.

A high-profile publisher can offer a small commission because Storefronts and Promoters expect high volume. A new publisher can offer a much larger percentage because discovery is more valuable to that publisher.

The publisher does not need to negotiate a separate distribution agreement with every application. The terms are part of the commercial opportunity represented by the record.

Earlier OIP work used the terms Platforms and Influencers for these roles and described direct creator payment with publisher-defined application and referral shares.[3][7]

28.2 Commercial publishing fees

A free record can pay a publishing fee based primarily on the objective cost that it creates.

A commercial record creates a larger economic opportunity. Its publishing fee should therefore reflect commercial value as well as system cost.

Earlier OIP specifications tied commercial publishing fees to the declared commercial prices of records rather than only to metadata size.[3]

Draft 0.6 retains the principle rather than the historical formula. A governed monotonic curve can make higher-value commercial records contribute more to the shared infrastructure while avoiding unreasonable fees at very high prices.

A material price increase can require an incremental fee so that publishers cannot avoid the commercial contribution by initially publishing an artificial low price.

29. Verified Publishers

Permissionless publishing does not mean permissionless impersonation of established rights holders.

Anyone can publish a descriptive record about a known work. A researcher can describe an album. A journalist can cite a movie. A user can create a record that references a game.

A different rule applies when a party claims the right to sell access to that protected work.

For commercial works that already appear in recognized public rights or commercial databases, compliant Storefronts should require a Verified Publisher before treating an OIP record as an authoritative commercial offer.

The original OIP specification already defined Verified Publisher Names and used public commercial databases as possible evidence for verifying a rights-holder identity.[3]

A modern verification process can use commercial databases, public identity channels, controlled domains, cryptographic signatures, official accounts, DIDs, and other evidence.

The distinction remains narrow:

Anyone can describe a known work. Only a verified rights holder or authorized party can publish an authoritative offer to sell access to that protected work through compliant commercial services.

This preserves the permissionless knowledge graph while protecting the commercial rights layer.

30. Signed commerce reports

Storefronts and other compensated services should publish standardized signed activity reports.

A report can identify the commercial record, transaction type, sale amount, discounts, Storefront attribution, Promoter attribution, settlement evidence, and time.

Reports should not collect unnecessary customer identity.

These reports let publishers confirm that commercial terms were followed and provide objective economic signals for the network. They also contribute to the Corpus Growth Reward system.

Standardized commercial reporting is another concept retained from earlier OIP designs.[3]

31. Thin Protocols and the application problem

Joel Monegro used Thin Protocols to describe the traditional Internet stack. Protocols such as TCP/IP, HTTP, and SMTP created enormous economic value, but most financial value accumulated in applications above them.[5]

This model has an important advantage. Applications have strong incentives to compete. The Web supports many interfaces, business models, discovery systems, and services.

It also has a structural weakness. If the common protocol cannot capture value, an application often needs a proprietary asset to protect its margins. That asset may be its catalog, user graph, private data, recommendation system, or another form of enclosure.

The result can be an open transport network covered by walled-garden applications.

Earlier Alexandria material described the same problem in practical terms. Publishers must often maintain separate relationships with distribution channels, while users choose services partly according to the catalogs those services control.

32. Fat Protocols and the protocol problem

Blockchain systems introduced a different model.

A Fat Protocol can contain a native asset and compensate protocol-level infrastructure directly. Bitcoin pays miners to secure and order transactions. Applications can use shared state instead of building every part of the system inside a proprietary database.

This creates a strong market for objective protocol work.

A pure Fat Protocol model has a different weakness. If nearly all value is concentrated at the protocol layer, applications can have weak opportunities for differentiated revenue. Interfaces can become interchangeable wrappers around the same underlying function.

A token that depends mainly on mandatory use as a payment currency can also create unnecessary consumer friction. Users do not necessarily want to hold a different asset for every service.

ALT is therefore not designed as the mandatory consumer currency for every Alexandria transaction.

33. The Salutary Protocol model

A Salutary Protocol draws the economic boundary according to the kind of work being performed.

Objective work belongs primarily at the protocol layer. It can be measured according to common rules.

Examples include Bitcoin anchoring, record retention, successful retrieval, media availability, bandwidth, and measurable compute.

Subjective work belongs primarily at the application layer. Its value depends on user preference.

Examples include user experience, search ranking, recommendation, filtering, research methods, model choice, interpretation, and curation.

Both layers can capture value.

This preserves the strongest property of Thin Protocols: application competition. It also preserves the strongest property of Fat Protocols: common infrastructure can support its own economic market.

Earlier Alexandria/OIP work described Salutary Protocols as systems that create value-capture opportunities at both the application and protocol layers, separate subjective work from objective work, and let users define their preferred combinations of services and pricing.

This remains the economic center of Draft 0.6.

34. ALT: Alexandria Library Token

ALT is the proposed network asset for the Alexandria ecosystem.

ALT does not require an Alexandria blockchain. The preferred design issues ALT as a fungible Taproot Asset anchored to Bitcoin.[10]

The preferred monetary design uses a known maximum supply. A portion of the supply is allocated to network reserves at issuance.

ALT has four primary economic functions:

1. capital formation for continued development;
2. bootstrap subsidy;
3. productive staking;
4. decentralized governance.

A Corpus Growth Reserve adds a related publishing incentive.

35. Economic function one: capital formation after functionality

ALT should not be used to raise money for a system that exists only as a proposal.

Before a major network-token fundraising round, the network should already provide meaningful functionality. OIP publishing, basic Bitcoin anchoring, a public interface, HYPATIA retrieval, and useful ALT functionality should exist.

Early development must therefore use other capital sources.

A later token offering can fund continued development and expansion of a functioning system. Uses can include protocol engineering, security audits, corpus ingestion, storage capacity, inference infrastructure, developer tools, grants, and ecosystem growth.

This sequence also fits the current Montana framework more closely. Montana defines a functional network as one in which participants can use a network token for value transmission, application services, or decentralized governance. Its network-token definition expressly includes decentralized data storage, computation, media hosting, streaming, data capture, and bandwidth.[12]

The Montana certification process also asks the issuer to describe network functionality, governance, distribution, material risks, and the date the token began functioning.

Current Montana law sets a $250 million aggregate 12-month sales limit for the relevant state exemption and excludes certain programmatic, nondiscretionary distributions for network services or direct network use from that limit.[12]

The technical architecture does not assume that state treatment determines federal treatment.

36. Economic function two: bootstrap subsidy

A new decentralized network has a chicken-and-egg problem.

Users prefer a system that already has useful content, strong retention, reliable retrieval, and sufficient inference capacity. Providers prefer a system that already has paying users.

A block subsidy solves a similar problem for a blockchain by paying infrastructure providers before transaction demand can support them.

OIP can reproduce this economic function without operating another blockchain.

A portion of the initial ALT supply can form a Provider Subsidy Reserve. Bitcoin height defines Reward Epochs. Providers submit valid Proofs of Retention, Proofs of Availability, and other objective service proofs. The reward system allocates ALT according to published rules.

The intended transition is:

early: subsidy income dominates;
growth: subsidy and real fees coexist;
mature: real service revenue dominates;
long term: new subsidy approaches zero.

The subsidy exists to create a market that can later support itself.

37. Economic function three: productive staking

ALT must have utility beyond the expectation that its market price will rise.

Draft 0.6 gives ALT two main productive staking functions.

37.1 Provider bonds

Anyone can run an OIP node.

A provider that wants to participate in the bonded and subsidized provider market must lock ALT as a service bond.

The amount of reward-eligible service capacity can be bounded by the size of the bond. This raises the cost of large Sybil attacks and places economic weight behind provider claims.

A provider that repeatedly fails objectively verifiable commitments can lose rewards and, where protocol rules permit, part of the bond.

Subjective policy decisions must not trigger slashing.

37.2 HYPATIA inference staking

ALT holders can also stake ALT for access to inference.

The protocol should not promise a fixed dollar value of inference per token. A fixed promise can create an unbounded compute liability.

Instead, inference-staked ALT receives a proportional share of the compute capacity assigned to the staking pool during an allocation period.

[ \text{User Capacity} = \frac{\text{User Eligible ALT Stake}} {\text{Total Eligible ALT Inference Stake}} \times \text{Available Staker Inference Capacity} ]

Venice provides a useful precedent for this general model. Current Venice documentation describes a recurring inference allocation based on a user's share of staked VVV relative to active stake, while conventional paid API access remains available.[11]

Alexandria does not need to operate the underlying GPU marketplace. HYPATIA can acquire compute through the interchangeable Compute Provider interface, with Akash as the preferred decentralized provider market.

An ordinary AskHypatia user does not need ALT. The hosted service can offer free access, subscriptions, professional plans, or API billing through familiar payment methods.

38. Economic function four: decentralized governance

A technically decentralized network can still have a central point of failure if one founder or company permanently controls its rules.

The Council of Librarians exists to remove that dependency.

In the mature system, ALT holders elect a Council that handles routine governance under a Living Articles of Organization. The Articles define powers, election procedures, delegation, quorums, treasury limits, challenge procedures, and the classes of decisions that require direct holder approval.

The original governance design proposed an elected Council of approximately ten members, a Chief Librarian, public challenges, direct token-holder voting, revocable delegation, differentiated quorums, and Living Articles that could themselves be amended.

Governance records should themselves use OIP. Proposals, ballots, delegations, budgets, Council decisions, and constitutional amendments become part of the public graph.

39. Founding Advisory Council of Librarians

The first elected Council should not begin before the network has enough operational history and sufficiently distributed ownership to support a meaningful election.

For approximately the first two years, Draft 0.6 therefore proposes a Founding Advisory Council of Librarians.

This group is unelected and explicitly advisory. Its role is to stress-test the protocol, economic system, rights model, inference architecture, archival rules, and proposed Living Articles while the network remains under active development.

The group can be larger than the eventual elected Council because its principal purpose is broad review rather than efficient day-to-day governance.

The transition to elected governance should be fixed in advance by date or Bitcoin block height. The Founding Advisory Council cannot extend its own tenure. Its members can stand for election later but receive no automatic seats.

The founder can participate ex officio without a vote. This preserves access to protocol history while allowing the advisory group to disagree with its creator.

39.1 Advisor compensation

Serious advisory work should be compensated.

A reasonable model combines fixed cash or Bitcoin compensation for actual service with a fixed ALT grant that vests over several years.

Compensation should not be a direct percentage of fundraising proceeds because that creates an incentive to maximize the size of an offering.

Founder-awarded advisory ALT should also not be permitted to dominate the first Council election. The Living Articles can exclude founding-advisor grants from governance weight until after that first election while allowing their economic vesting to continue.

40. Corpus Growth Reward System

Storage capacity does not create a useful library by itself. The library must contain information that people want to preserve and use.

A defined share of ALT can therefore form a Corpus Growth Reserve.

The reserve rewards publishers, archivists, developers, researchers, and ingestion systems that move unique and useful information from brittle sources into the persistent public graph.

A record can become eligible when it is the first valid OIP publication of its content hash, meets retention requirements, passes applicable rights rules, and later demonstrates meaningful use.

Usefulness should be measured through several independent signals.

These can include:

• verified retrievals;
• HYPATIA citations;
• Storefront activity;
• commercial sales;
• independent media access;
• incoming DREFs;
• inclusion in saved Evidence Trails;
• references from later Web Capture or Analysis Records.

Incoming DREFs are especially valuable because the graph itself can show that independent publishers found a record useful enough to reference. This is conceptually similar to using incoming hyperlinks as a signal of importance in Web search. Early Google work used Web link structure as information for ranking rather than relying only on page text.[14]

Raw reference counts are not sufficient. The system should consider publisher independence, circular reference patterns, repeated self-reference, age, and the importance of referring records.

Popularity is evidence of usefulness, not truth.

40.1 Reward lottery

Once a record crosses the required thresholds, it enters the eligible reward pool.

Future Bitcoin block data can provide unpredictable selection randomness after the eligible set has closed.

The protocol can then select one or more publishers to receive Corpus Growth Rewards.

A lottery or concave weighting function prevents the reward system from becoming a permanent subsidy to only the already most popular publishers.

41. Scribes and Corpus Growth

Scribes of Alexandria creates a natural connection between ordinary human curiosity and the Corpus Growth Reward System.

A person is already browsing the Web. The person finds a source that seems important. The person captures it with Scribes and may choose to publish its structured record.

If no equivalent record already exists, the user has helped migrate information from brittle Web storage into a persistent public graph.

Most captured pages will never become economically important. They do not need to.

Some captures may later become important because other records refer to them, HYPATIA cites them, researchers retrieve them, or the source disappears from the original Web.

Those records can become eligible for the same Corpus Growth Reward process as material added through formal archive ingestion.

This creates a simple incentive:

If you find something worth remembering, preserve it.

The economic reward is uncertain. The preservation value is immediate.

42. Real revenue and continuing ALT demand

Bootstrap reserves can create supply before customer demand exists. They cannot replace real demand indefinitely.

Possible revenue sources include AskHypatia subscriptions, research and professional accounts, API usage, document ingestion, archival contracts, sponsored public collections, commercial publishing fees, Storefront services, specialized HYPATIA deployments, and institutional services.

A governed share of revenue can purchase ALT from the market and return it to a treasury rather than destroy it.

The treasury can then recycle that ALT into provider rewards, Corpus Growth Rewards, grants, security work, and other network functions.

The source of provider compensation therefore changes over time.

Initially, rewards come from fixed network reserves.

Later, increasing amounts come from customer-funded repurchases and real service fees.

The same network asset can continue to support the provider market after initial emissions decline.

43. Initial public use case: an interrogable public record

A new network needs a useful corpus before it can rely on network effects.

One strong initial use is a permanent, source-grounded library of public evidence.

The corpus can include declassified government records, court documents, legislative exhibits, historical archives, public scientific data, corporate filings, public-domain collections, investigative source documents, and captured Web sources.

Each source becomes a structured record with a hash, provenance, storage addresses, and Bitcoin-backed publication history. Analysis systems create separate records for people, places, organizations, events, dates, topics, and claims.

HYPATIA can then answer questions across collections instead of within one uploaded PDF.

Observation Records add contemporaneous data.

Media Observation Records add photos, video, audio, geolocation, and cryptographic provenance.

Web Capture Records add the history of public information as it appears and changes on the live Web.

The result is not merely a “chat with documents” system. It is a public graph in which new evidence connects to existing evidence as it arrives.

44. Historical context: from Xanadu to conversational hypermedia

Project Xanadu began in 1960 with a vision of electronic information as a connected literature rather than a set of isolated files. Its design explored persistent identity, visible connections, source relationships, and transclusion by reference.[15]

OIP developed independently, but several architectural properties converge on these ideas.

DREFs support reuse by reference.

Stable identifiers provide persistent identity.

Reverse graph indexing exposes incoming relationships.

Signatures and revision hashes preserve provenance.

Bitcoin commitments provide public publication history.

Scribes adds another relevant property: the system can preserve the changing state of live Web sources while retaining their relationships to the continuing source identity.

The mechanisms are different. Xanadu designed rich hypertext link structures. OIP publishes typed directed relationships and derives reverse relationships from the shared index.

According to Devon James' recollection, Christopher Allen, who had earlier contact with the Xanadu community and later worked on Internet security, Bitcoin-related systems, and decentralized identity, described OIP as the closest thing to Project Xanadu that he had yet seen. The comment is included here as a historical recollection rather than as technical evidence.

The broader point does not depend on the anecdote.

Hypertext research described richer relationships before the necessary decentralized infrastructure existed. Blockchain supplied public ordering. Distributed storage supplied independent file transport. DIDs supplied persistent identities. Modern language models now provide a practical interface to a graph that is too large for most users to navigate manually.

The user does not have to understand the graph.

The user can ask HYPATIA.

45. A unified architecture for public knowledge, private knowledge, live context, capture, and action

Draft 0.6 extends Alexandria beyond a public archive without weakening the distinction between public and private information.

The complete information path is:

                                USER
                                 │
              ┌──────────────────┼──────────────────┐
              │                  │                  │
              ▼                  ▼                  ▼
          HYPATIA              ALFRED             SCRIBES
     public librarian     private assistant     Web capture
              │                  │                  │
              ▼                  ▼                  ▼
             OIP          Alfred Remembers      live Web
       public graph          private graph           │
              │                  │                   │
              │                Solid                 │
              │                  │                   │
              │         Context & Action Gateway     │
              │                  │                   │
              │              OpenClaw                │
              │                  │                   │
              └──────────┬───────┴───────────┬──────┘
                         │                   │
                         ▼                   ▼
                  public publishing   private retention
                         │
                         ▼
                   Alexandria graph

                         INFERENCE
                             │
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
          local models      Akash       other providers

This structure produces clear trust boundaries.

Public knowledge belongs to OIP.

Private knowledge belongs to the user.

Live context is retrieved when required.

Web material can be captured privately before publication.

Actions require authorization.

Inference can run wherever the user permits.

46. Design principle: build only the layer that must be unique

A recurring pattern appears across the architecture.

Alexandria does not need to create a new blockchain when Bitcoin already provides strong public settlement and ordering.

It does not need to create one universal media transport when BitTorrent, IPFS, Arweave, and the Web already exist.

It does not need to invent a new general-purpose ontology when Schema.org already covers many common objects.

It does not need to invent another content-provenance standard when C2PA exists.

It does not need to invent a private-data permission protocol when Solid provides a relevant interoperable framework.

It does not need to maintain hundreds of local-application integrations inside Alfred when a Context & Action Gateway can provide them.

It does not need to build another GPU marketplace when Akash and other compute providers can supply that commodity.

It does not need to crawl and archive the complete Web when Scribes and agent-driven ingestion can let human research and real information needs identify material worth preserving.

The system should build the layer that these components do not supply:

a persistent, permissionless, structured knowledge graph with explicit relationships, transparent provenance, sustainable economic incentives, and agents that can navigate it.

This principle keeps the architecture modular and gives every major component an escape path if a better implementation appears later.

47. Development sequence

Draft 0.6 suggests an incremental development path.

Phase 1 — knowledge model

Finalize and test templates, Schema.org mappings, DREFs, stable identity, revisions, Source Records, Analysis Records, Observation Records, Web Capture Records, Model Records, and provenance.

Phase 2 — public experience

Build Alexandria.io, HYPATIA, AskHypatia.com, public archive ingestion, graph-grounded retrieval, and source-grounded answers.

Phase 3 — Scribes of Alexandria

Productize the browser extension with page extraction, visual capture, normalized content hashing, HYPATIA contextual questions, private capture storage, change detection, Web Capture Records, and optional OIP publication.

Phase 4 — private experience

Productize Alfred Remembers, private semantic memory, Solid-compatible storage, private/public entity bridges, local retrieval, and user-controlled permissions.

Phase 5 — Context & Action Gateway

Integrate the OpenClaw reference gateway, local files, calendars, mail, messages, notes, reminders, Web search, browser tools, controlled actions, and agent-driven Web-to-OIP publication.

Phase 6 — Bitcoin anchoring and persistence

Implement canonical serialization, Commitment Batches, Merkle proofs, permissionless batchers, Lightning publishing fees, distributed replication, Proof of Retention, Proof of Availability, the Recent Availability Gate, replication bounties, Policy Lists, and Tombstones.

Phase 7 — compute portability

Implement hardware detection, the local model catalog, Model Performance Observation Records, local STT and TTS, local inference profiles, the Compute Provider interface, Akash integration, and optional provider configuration for compatible hardware.

Phase 8 — commerce

Implement Commercial Records, Verified Publishers, Storefronts, Promoters, access controls, split payments, commerce reports, and commercial publishing fees.

Phase 9 — ALT and governance

Before broad fundraising, deploy useful ALT functions, activate provider bonds and inference staking, implement deterministic reward accounting, and operate the Founding Advisory Council.

Then conduct any qualifying capital formation, operate the Provider and Corpus Growth reserves, and transition on schedule to the elected Council of Librarians.

48. Open design questions

Draft 0.6 defines the architecture but leaves several parameters open.

The protocol still needs exact rules for canonical serialization, Commitment Batch format, Bitcoin commitment encoding, batch frequency, replication thresholds, independent-replica testing, challenge selection, media probes, provider-bond curves, penalties, and bootstrap reward schedules.

The economic model needs exact ALT supply and allocation percentages, Corpus Growth Reserve size, inference allocation rules, revenue repurchase policy, publishing fee curves, and reward-lottery parameters.

The private system needs final Solid mappings, permission UX, data-shape conventions, local encryption policy, public/private entity-resolution rules, and rules that prevent private context from leaking into proposed public records.

The local inference system needs a normalized hardware-description schema, benchmark methodology, performance observation standards, model trust and signature rules, and a common abstraction for local and remote model execution.

The Compute Provider interface must define privacy expectations, workload packaging, accounting, model availability, and the conditions under which confidential external inference can be considered suitable for private material.

Scribes requires additional standards for canonical Web-page capture, normalized article extraction, screenshot representation, source identity, change detection, redirects, repeated capture, robots and access policy, copyright-aware public display, and the relationship between a private retained capture and a public Web Capture Record.

The governance system still needs Council size, election schedule, delegation mechanics, direct-vote thresholds, treasury limits, emergency procedures, advisory compensation, and the exact first-election treatment of founding-advisor ALT grants.

These parameters should be fixed only after the system states the property that each one must achieve.

49. Conclusion

A persistent public knowledge system requires more than a blockchain and more than decentralized file storage.

It needs a common index that applications do not own. It needs durable identity and explicit relationships between records. It needs proof that information existed at a particular point in history. It needs incentives for retention and availability. It needs commercial incentives for creators and applications. It needs a practical way for people to navigate a graph too large to understand manually.

OIP provides the common public data model. DREFs convert isolated records into a connected knowledge graph. Bitcoin provides durable commitments and canonical order without carrying arbitrary OIP data itself. Independent storage networks carry large files. Proof of Retention and Proof of Availability turn persistence into measurable services. Scarcity-weighted bounties create an automatic incentive to repair under-replicated content.

The Decentralized Library of Alexandria makes the graph browsable.

HYPATIA makes the graph conversational.

Scribes of Alexandria connects the graph to the live Web. It lets a user capture an important page, preserve what it looked like, compare later versions, analyze its contents, and ask questions that reach beyond that page into the wider knowledge graph. It also gives ordinary research a path into public preservation. A useful source discovered during normal browsing can become a durable record instead of disappearing when the browser tab closes.

The system also recognizes that the most useful AI assistant cannot live only inside public information. Alfred Remembers applies the same graph architecture to private memory. Solid gives the user an interoperable control boundary around that information. A Context & Action Gateway allows Alfred to retrieve local information and perform authorized actions without forcing the user's entire digital life into one cloud database.

When the public graph does not contain an answer, the gateway can reach the live Web. When that search uncovers durable public information, the user can choose to preserve it in Alexandria. When the user encounters something important directly while browsing, Scribes provides the corresponding human-curated path. The question that exposes a knowledge gap or the page that sparks a user's curiosity can therefore become the event that fills that gap for everyone.

Inference is equally modular. A user can run HYPATIA or Alfred entirely on local hardware when privacy matters. Another user can combine local retrieval with external inference. The reference implementation can obtain decentralized GPU capacity from Akash instead of creating another compute marketplace. Owners of compatible high-performance hardware can also choose to offer spare capacity back to that market.

Commercial publishing turns the same shared index into an open distribution market. Publishers define prices, access terms, Storefront commissions, and Promoter commissions. Verified Publisher rules protect authoritative commercial-rights claims without limiting the public's ability to describe and reference known works.

ALT supplies the bootstrap economics without introducing another blockchain. A functioning network can use ALT for continued capital formation. A fixed reserve can subsidize useful providers while real demand develops. Providers can bond ALT to join the compensated service market. Users can stake ALT for a proportional share of HYPATIA inference. Corpus Growth Rewards can compensate people who move useful knowledge from brittle sources into persistent public memory. The Council of Librarians can eventually place governance in the hands of the network rather than its founders.

The economic model remains a Salutary Protocol.

A Thin Protocol can leave common infrastructure economically weak.

A Fat Protocol can leave applications economically thin.

A Salutary Protocol gives both layers work worth competing for.

Objective services compete at the protocol layer.

Subjective services compete at the application layer.

Deterministic evidence remains distinct from probabilistic interpretation.

Public information remains public infrastructure.

Private information remains under user control.

Models, applications, storage networks, compute providers, and interfaces can change.

The graph can remain.

The intended result is a persistent worldwide library that anyone can publish to, anyone can build upon, anyone can help preserve, and anyone can ask questions of. At the same time, the same architecture gives individuals a private assistant that can remember their own lives without requiring them to surrender that memory to the company that built the interface.

Notes and bibliography

[1] Open Index Protocol — project overview. Describes OIP as an open-source specification for a persistent worldwide index and file library. It also records project history, proofs of concept, scientific deployments, land-record projects, media pilots, and related integrations.
Open Index Protocol overview

[2] Open Index Protocol Wiki — current implementation documentation. Documents templates, records, DREF fields, AI integration, Arweave-based public records, media distribution, private records, and current implementation architecture.
Current OIP Wiki

[3] Open Index Protocol Specification — archived April 2019. Defines publishers, Verified Publisher Names, commercial and free records, platform roles, referral roles, publishing fees, storage requirements, rights handling, and commercial reporting.
Archived OIP Specification

[4] Open Index Protocol design and economic principles — archived March 2019. Describes permissionless system design, limited standardization, Thin Protocols, Fat Protocols, Salutary Protocols, and the open-jungle model.
Archived OIP design and Salutary Protocol material

[5] Joel Monegro, “Fat Protocols,” Union Square Ventures, 2016. Introduces the thin-protocol/fat-application model and contrasts it with blockchain systems in which more value can accumulate at the protocol layer.

[6] OIP-derived graph-memory proof of concept. Documents the implemented Alfred memory architecture: typed records, stable identifiers, immutable revisions, Schema.org payloads, DREF relationships, lexical retrieval, and bounded bidirectional graph traversal.

[7] Salutary Protocol presentation. Earlier Alexandria presentation describing competition at both application and protocol layers and the separation of objective infrastructure work from subjective application work.

[8] Council of Librarians design document. Earlier Alexandria governance proposal defining elected Librarians, a Chief Librarian, revocable delegation, direct token-holder challenges, differentiated quorums, and Living Articles of Organization.

[9] Arweave Yellow Paper. Describes the historical recall-block and Proof of Access mechanism that informs the Proof of Retention discussion.

[10] Lightning Labs — Taproot Assets. Documents issuing and transferring assets with commitments anchored to Bitcoin.

[11] Venice — inference staking model. Current Venice documentation describes inference access that is linked to VVV staking and allocated according to stake relative to active stakers.

[12] Montana Financial Freedom and Innovation Act. Current Montana Code defines functional networks, decentralized networks, and network tokens, including tokens that provide access to storage, computation, media, data capture, and bandwidth. It also defines certification requirements and the current state sales-limit framework.

[13] Coalition for Content Provenance and Authenticity. C2PA provides verifiable provenance for digital media while distinguishing provenance verification from judgments about whether content is factually true.

[14] Sergey Brin and Lawrence Page, “The Anatomy of a Large-Scale Hypertextual Web Search Engine,” 1998. Relevant precedent for using incoming link structure as a measure of importance in a large information graph.

[15] Project Xanadu. Historical work on connected literature, visible connections, persistent relationships, and transclusion.

[16] Christopher Allen historical material. Relevant background on Internet cryptography, decentralized identity, Bitcoin-related systems, and earlier contact with the Xanadu community. The specific OIP comparison in this draft remains a personal recollection.

[17] Solid Project and Solid Protocol. Solid defines Pods, WebIDs, interoperable applications, Linked Data resource access, and permissioned access to externally stored data. The current Solid specification is an evolving community specification rather than a W3C Recommendation.

[18] Solid authorization and application interoperability. Current Solid materials describe Web-based authorization and developing mechanisms for applications and agents to safely share and manipulate data in Pods.

[19] OpenClaw Web and browser tooling. OpenClaw currently provides Web search and fetch tools and an agent-controlled browser environment. Draft 0.6 uses OpenClaw as a preferred reference Context & Action Gateway rather than as an OIP protocol dependency.

[20] Akash Network. Akash operates a compute marketplace with independent providers and supports GPU-aware resource discovery. Running a provider requires dedicated provider infrastructure and operational setup; it is not equivalent to enabling a simple desktop background task.