Skip to content

Per-participant sub-graph partitioning at ingest — schema v2 hint + authoritative gateway default from requesterPubkey #11

Description

@Zigoljube

Problem — the write path cannot produce what the read path promises

The read side and docs promise per-participant traceability: query ops subgraph_graph, subgraph_triples, contributor_trail exist, and docs/dkg-memory.md states "each contributor's claims sit in their own sub-graph, so you can reconstruct why an agent or human concluded what they did."

But the proposal schema (v1/v2) has no partition/sub-graph field — {schemaVersion, profiles, summary, entities, relations, model, promptVersion} — and the current capture writes flat assertions (…/assertion/<addr>/buzz-dkg-…, subgraphs: []). Once autonomous ingestion lands (PR #9 + agent loops), the graph will grow flat: decisions accumulate but "who reasoned this" is unrecoverable, the Topics chips never render, and the WHY view stays empty (the "All decisions" fallback from #3 masks this in the UI — it was meant as graceful degradation, not as the end state).

Verified against buzz-dkg-relay.origintrail.io (subgraphs: [] on the WoT channel graph) and the agent-workers' own client (src/dkg/client.ts:110-137 sends only contextGraphId; the distiller has author provenance triples but no storage partitioning, src/distill/deterministic.ts:99-115 — per Prime Agent's inspection).

Agreed design (Web of Trust deliberation, 2026-08-13 — OpenClaw, Prime Agent, Hermes, Žiga)

Schema hint plus gateway default, with authorship non-spoofable:

  1. Gateway-side default (authoritative): the relay already forwards the authenticated requesterPubkey; the gateway deterministically maps it to a participant sub-graph (e.g. participant/<requesterPubkey>). Backward-compatible proposals default to the authenticated participant partition — never to root/flat storage.
  2. Schema-side hint (optional, additive to v2): an optional partition/sub-graph field so proposals can carry non-authoritative thread/decision context. The gateway MUST reject any supplied participant value that does not match the authenticated requester — a client can never claim another participant's partition; hints may only refine within the requester's own scope.

Acceptance (end-to-end, not schema-only — Hermes' bar)

  • Submit two signed proposals from two identities into one context graph;
  • verify distinct non-empty subgraphs;
  • attribution/provenance triples bound to each signed requester and its source events;
  • contributor_trail recovers each author path in isolation;
  • an ingest fixture proves non-empty subgraphs before autonomous capture is declared "objective achieved" (OpenClaw's minimum bar).

Related

🤖 Generated with Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions