Skip to content

SPEC.md

Latest commit

 

History

History
160 lines (86 loc) · 5.56 KB

SPEC.md

File metadata and controls

160 lines (86 loc) · 5.56 KB
Raw

Daena Protocol — Editor's Draft v0

Status: Editor's Draft Editor: Pouyan Ahmadpour Latest revision: Unreleased

This is a working draft. The Daena Protocol is not yet stable; section numbering, normative requirements, and the data model are all subject to change until v1.0. Comments and proposals are welcomed in the issue tracker and as DPIPs.

Abstract

Daena is an open protocol for publishing verifiable, agent-native information on the internet. A Daena document is a structured, cryptographically signed expression of a publisher's facts, capabilities, and presentation hints — designed to be consumed natively by software agents and optionally rendered for humans.

This document specifies the data model, addressing scheme, protocol verbs, signing and verification, and human-rendering conventions of Daena Protocol v0.

1. Introduction

1.1 Motivation

The web was designed for human consumption. AI agents operating on behalf of humans must currently scrape, parse, and infer their way through HTML pages, producing results that are lossy at best and hallucinated at worst.

Daena defines a parallel, machine-native layer of the internet: a layer where every publisher exposes a signed source of truth that agents read directly, and from which human-readable views are derived rather than the other way around.

1.2 Design principles

  1. Source-of-truth inversion. The agent layer is canonical; the human layer is derived.
  2. Verifiability by default. Every fact carries a cryptographic signature from its publisher.
  3. Human interface preserved. Daena documents are always renderable to a human view.
  4. Open by specification. The protocol is governed openly under the Daena Foundation (forthcoming).
  5. Composable and minimal. v0 specifies the smallest viable surface; complexity is opt-in.

1.3 Conformance

The keywords MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in RFC 2119 when, and only when, they appear in all capitals.

1.4 Terminology

Defined terms appear in italics on first use and are normatively defined in GLOSSARY.md.

2. The Daena document

2.1 Document structure

A Daena document is a JSON-encoded object with the following top-level fields:

  • daena — protocol version string (e.g. "0")
  • publisher — publisher identity (a DID)
  • facts — array of signed fact objects
  • capabilities — array of capability objects
  • render — optional render hints
  • signature — document-level signature over the above

Normative schema and JSON examples to be specified.

2.2 Identity

Each Daena document is published under a publisher identity, expressed as a Decentralized Identifier (DID).

DID methods supported by v0 to be specified.

2.3 Versioning

The daena top-level field declares the protocol version. Consumers MUST refuse to process documents whose version they do not support.

Version negotiation rules to be specified.

3. Facts

3.1 The fact object

A fact is a typed, dated, signed statement made by a publisher about a subject.

Fields and schema to be specified.

3.2 Typing and vocabulary

Facts carry a type URI that identifies the vocabulary under which the fact is interpreted.

v0 reserved vocabularies and extension mechanism to be specified.

3.3 Signing

Each fact is signed by its publisher such that any party may verify authorship and integrity without contacting the publisher.

Signature algorithm and canonicalization rules to be specified.

4. Capabilities

4.1 The capability object

A capability is a named action a publisher offers to agents, with typed parameters and optional authentication and payment requirements.

Fields and schema to be specified.

4.2 Authentication

Authentication mechanisms to be specified.

4.3 Payment

Capabilities MAY declare a price. v0 specifies an optional payment binding compatible with existing payment networks.

Payment binding to be specified.

5. Render hints

Render hints are optional metadata that guide a renderer in generating a human-readable view. Render hints MUST NOT affect the semantic meaning of facts or capabilities.

Render-hint vocabulary to be specified.

6. Protocol verbs

Daena defines four verbs over HTTPS:

6.1 QUERY

Returns the subset of a Daena document matching a structured query.

6.2 ACT

Invokes a capability with parameters, authentication, and (optionally) payment.

6.3 SUBSCRIBE

Establishes a live connection that pushes updates as facts change.

6.4 VERIFY

Returns the publisher's current signing keys and revocation state, enabling third-party verification.

Wire format, transport bindings, and error model to be specified.

7. Discovery

How agents find the Daena document for a given entity.

Discovery mechanisms (DNS, well-known URI, registry) to be specified.

8. Security considerations

To be specified — key management, replay, downgrade attacks, signature stripping, malicious render hints, etc.

9. Privacy considerations

To be specified — publisher pseudonymity, query telemetry, consent for personally identifying facts, etc.

Appendix A. Examples

See github.com/daena-protocol/examples for runnable Daena documents across multiple verticals.

Appendix B. Change log

See CHANGELOG.md.

Appendix C. Acknowledgements

To be added.