Curated context graph join may not surface private CG and may expose metadata-only graphs

[TomazOT]

Description

Consolidated investigation placeholder for curated/private context graph join failures observed by multiple node operators: after invite/join flow, the private project may not appear in the joiner's node UI / context-graph list, while some SPARQL/MCP queries may still see metadata-only graphs or partial data for the CG.

This report includes deterministic evidence from one node. This node is the CURATOR for the CG below, not a joiner, so affected joiners should comment with their Section A outputs.

Steps to Reproduce

1. Curator creates a curated/private context graph (accessPolicy=1).
2. Curator shares invite with joiners.
3. Joiners run the invite/join flow.
4. On affected joiners, inspect:
   • dkg context-graph list
   • dkg context-graph info "$CG_ID"
   • dkg sync catchup-status "$CG_ID"
   • graph breakdown via SPARQL for graphs under did:dkg:context-graph:<CG_ID>.

Expected Behavior

After a successful join approval/acceptance flow, an authorized joiner should see the curated/private context graph in node UI / dkg context-graph list, catch-up status should be deterministic, and ACL-gated SPARQL/MCP access should not expose data or metadata inconsistently.

Actual Behavior

Reported by affected operators: join flow appears to complete, but the CG may not appear in node UI / context graph list. Some nodes may still see triples via DKG MCP/SPARQL, unclear whether those are real data triples or only _meta / _shared_memory_meta metadata.

Evidence from this node (curator):

• Role for CG: CURATOR
• CG_ID: 0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing
• CG URI: did:dkg:context-graph:0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing
• Curator/creator peer: 12D3KooWM7JGP69boLmxo56qToYWtt9uaumCcHc2smNkkmTfyjRK
• Primary agent: 0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd
• Access policy in dkg_context_graph_list: private
• This curator node sees the CG as subscribed: true, synced: true, callerInvolved: true.
• Participant list currently contains only curator agent:
  • 0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd
• Pending join requests: []
• dkg sync catchup-status "$CG_ID": No catch-up job found on curator.

Curator graph breakdown, shared-working-memory view:

did:dkg:context-graph:0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing/_meta                         77
did:dkg:context-graph:0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing/_shared_memory_meta        63
did:dkg:context-graph:0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing/_shared_memory             30
did:dkg:context-graph:0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing/meta/_shared_memory        21
did:dkg:context-graph:0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing/meta/_shared_memory_meta   11
did:dkg:context-graph:0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing/meta/assertion/0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/project-ontology 2

Curator data-triple count using the requested metadata exclusion filter:

dataTriples = 53

Working-memory view for curator primary agent using the same graph-breakdown query returned no bindings via the OpenClaw DKG tool. The OpenClaw tool surface does not expose includeSharedMemory; raw HTTP /api/query attempts with includeSharedMemory: true returned bare 400 Bad Request for this node, so I could not capture the exact requested WM+SWM merged variant.

DKG Version

Daemon status version: 10.0.0-rc.6-dev.1778433549.b65c695

CLI dkg --version: 10.0.0-rc.4-dev.1777968655.8309683

Node role: edge
Network: DKG V10 Testnet (7449c543ff04a550)
Store backend: oxigraph-worker
Connected peers at collection time: 10

Operating System

Darwin 24.6.0 arm64

Node.js Version

v24.15.0

Relevant Logs

No private keys, wallet seeds, or auth tokens included.

Additional command outputs:

dkg auth status:
  Authentication: enabled
  Token file: [redacted local path]

Operational wallets:
  primary 0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd
  pool #2 0x5De26B1170356eB25Bf744A93F0455bb8baDC681
  pool #3 0xf2B1484b548cB81e2D90764f6777482e6b12899B
  Chain: base:84532
  RPC: [redacted local config]

dkg context-graph info "$CG_ID":
  ID: 0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing
  URI: did:dkg:context-graph:0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing
  Name: monday testing
  Description: many things
  Type: user
  Creator: did:dkg:agent:12D3KooWM7JGP69boLmxo56qToYWtt9uaumCcHc2smNkkmTfyjRK
  Created: 2026-05-11T07:22:00.550Z

dkg context-graph agents "$CG_ID":
  0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd

[TomazOT]

Additional curator-side evidence for B-section and A6-style allowlist check from this node.

Role: CURATOR
CG_ID: 0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing
Curator peer: 12D3KooWM7JGP69boLmxo56qToYWtt9uaumCcHc2smNkkmTfyjRK
Curator primary agent: 0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd

A6-style allowlist check on curator local _meta

SPARQL used:

SELECT ?agent WHERE {
  GRAPH <did:dkg:context-graph:0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing/_meta> {
    ?cg <https://origintrail.io/dkg/v10/cg#allowedAgent> ?agent .
  }
}

Result via OpenClaw dkg_query: no bindings.

However, participant/agents API returns the curator agent as allowed:

{
  "contextGraphId": "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing",
  "allowedAgents": [
    "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd"
  ]
}

So on this curator node there is a mismatch: the participants route sees the allowlist, but the requested _meta cg#allowedAgent SPARQL pattern does not.

B1. Confirm policy

dkg context-graph info "$CG_ID":

ID:          0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing
URI:         did:dkg:context-graph:0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing
Name:        monday testing
Description: many things
Type:        user
Creator:     did:dkg:agent:12D3KooWM7JGP69boLmxo56qToYWtt9uaumCcHc2smNkkmTfyjRK
Created:     2026-05-11T07:22:00.550Z

Note: CLI context-graph info did not print accessPolicy, but dkg_context_graph_list reports this CG as accessPolicy: private, subscribed: true, synced: true, callerInvolved: true, with curator did:dkg:agent:0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd.

B2. Allowlist + pending requests

dkg context-graph agents "$CG_ID":

Allowed agents for "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing":
  0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd

dkg context-graph join-requests "$CG_ID":

No pending join requests for "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing".

Tool response also returned requests: [].

B3. Curator filtered logs

Command:

dkg logs -n 5000 | grep -iE "join.?request|allowlist|$CG_ID|PROTOCOL_JOIN|forwardJoinRequest" | tail -300

Output:

2026-05-11 09:36:17 sync 91e58497-352b-4a17-9d90-c0a46d335657 [DKGAgent] Syncing shared memory for context graph "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing" from 12D3KooWAbLiM6Xy2TfXtFpUrXqttnTSuctW8Lo1mkauaijsNrWw
2026-05-11 09:37:46 sync f0680527-7467-4fb7-9b50-bbf26dbc419b [DKGAgent] Syncing shared memory for context graph "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing" from 12D3KooWGdj1YKSav7h2RVJ9gq22LXprEP9JVpRAA5QMYhDTz1Nw
2026-05-11 09:37:51 sync eb161a97-5e91-4d7e-ab58-bf75d105f0c6 [DKGAgent] Syncing shared memory for context graph "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing" from 12D3KooWCTBVnnXKsfnXZVSXzdbEVWHXNNdEjcuPu1Kgf2H641xG
2026-05-11 09:38:02 query 736b1e15-e11c-41a8-95a6-aaccda5de9fc [DKGAgent] Query on contextGraph="0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/monday-testing" sparql="SELECT ?agent WHERE {

Observations:

• No join-request, PROTOCOL_JOIN, or forwardJoinRequest lines appeared in the filtered 5000-line window.
• There are sync attempts for the private CG from three peer IDs, including Hermessio's peer, but pending join requests remain empty and the allowlist has only the curator agent.

Raw dkg logs -n 200 tail was mostly unrelated chain poller/RPC errors (filter not found, query exceeds max block range 2000) plus unrelated sync chatter. I did not paste the full raw tail here to keep the comment focused, but can provide if needed.

B4. Connectivity to known/suspected joiner peers

I checked peers observed in the filtered logs plus the world-monitor peer that had been used earlier. All returned the same CLI output shape:

--- dkg peer info 12D3KooWGdj1YKSav7h2RVJ9gq22LXprEP9JVpRAA5QMYhDTz1Nw ---
Peer:          info
Connected:     no
Connections:   0
Sync Capable:  no

--- dkg peer info 12D3KooWAbLiM6Xy2TfXtFpUrXqttnTSuctW8Lo1mkauaijsNrWw ---
Peer:          info
Connected:     no
Connections:   0
Sync Capable:  no

--- dkg peer info 12D3KooWCTBVnnXKsfnXZVSXzdbEVWHXNNdEjcuPu1Kgf2H641xG ---
Peer:          info
Connected:     no
Connections:   0
Sync Capable:  no

--- dkg peer info 12D3KooWEw3Xh7KuDwRDSuhbpTpA5PeN58gchyQqQ321YYeppmXj ---
Peer:          info
Connected:     no
Connections:   0
Sync Capable:  no

--- dkg peer info 12D3KooWErSVgdyFov5pCtmsbXsDXz3rrFUXdwACKUGohddvhBaX ---
Peer:          info
Connected:     no
Connections:   0
Sync Capable:  no

Note: dkg_find_agents shortly before this had reported Hermessio (12D3KooWGdj1YKSav7h2RVJ9gq22LXprEP9JVpRAA5QMYhDTz1Nw) as connected, and a DKG chat message to Hermessio delivered successfully. So dkg peer info may not reflect transient chat reachability or may be resolving incorrectly here.

[Zigoljube]

Joiner-side evidence from another affected node.

Role: JOINER
CG_ID tested: 0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt
Curator peer from invite: 12D3KooWM7JGP69boLmxo56qToYWtt9uaumCcHc2smNkkmTfyjRK
Joiner primary agent: 0xccAdb7C905eA4fd1b594A7536C7DE8dB2CB69c03
Joiner peer: 12D3KooWEw3Xh7KuDwRDSuhbpTpA5PeN58gchyQqQ321YYeppmXj

A1. Node identity & version

dkg status:
  Node:      hermes-default
  Role:      edge
  Network:   7449c543ff04a550
  PeerId:    12D3KooWEw3Xh7KuDwRDSuhbpTpA5PeN58gchyQqQ321YYeppmXj
  Peers:     13
  Relay:     connected

dkg --version: 10.0.0-rc.6
node --version: v25.6.1
uname -srm: Darwin 25.2.0 arm64

dkg auth status:
  Authentication: enabled
  Token file:     /Users/clawdnode/.dkg-dev/auth.token

dkg wallet | head -20:
  (primary) 0xccAdb7C905eA4fd1b594A7536C7DE8dB2CB69c03
  Chain: base:84532
  RPC:   https://sepolia.base.org

A2. Local context graph visibility

dkg context-graph list does not contain either the full CG ID or short slug sunday-projectttt.

dkg context-graph info "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt"
Context graph "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt" not found.
(exit=1)

dkg context-graph info "sunday-projectttt"
Context graph "sunday-projectttt" not found.
(exit=1)

dkg context-graph agents "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt"
No allowlist configured for "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt" (open access).
(exit=0)

dkg context-graph agents "sunday-projectttt"
No allowlist configured for "sunday-projectttt" (open access).
(exit=0)

Raw API confirms absent after subscribe:

GET /api/context-graph/exists?id=0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd%2Fsunday-projectttt
{
  "id": "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt",
  "exists": false
}

A3 / A8. Catch-up state and fresh subscribe

Before fresh subscribe:

dkg sync catchup-status "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt"
No catch-up job found
(exit=1)

GET /api/sync/catchup-status?contextGraphId=0xE5.../sunday-projectttt
HTTP 404 Not Found

Fresh raw subscribe with curator peer:

POST /api/context-graph/subscribe
{
  "contextGraphId": "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt",
  "curatorPeerId": "12D3KooWM7JGP69boLmxo56qToYWtt9uaumCcHc2smNkkmTfyjRK",
  "peerId": "12D3KooWM7JGP69boLmxo56qToYWtt9uaumCcHc2smNkkmTfyjRK",
  "includeSharedMemory": true
}

HTTP 200
{
  "subscribed": "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt",
  "catchup": {
    "status": "done",
    "includeWorkspace": true,
    "jobId": "mp0w5v48-t23fem"
  }
}

Repeated catchup-status polling for ~24s remained terminal done, with no diagnostic counters present in the response:

{
  "contextGraphId": "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt",
  "finishedAt": 1778485189832,
  "includeSharedMemory": true,
  "includeWorkspace": true,
  "jobId": "mp0w5v48-t23fem",
  "queuedAt": 1778485189832,
  "startedAt": 1778485189832,
  "status": "done"
}

After this done subscribe/catchup, /api/context-graph/list still does not include the target CG and /api/context-graph/exists?id=<CG_ID> still returns exists:false.

A4. Curator reachability

dkg peers | head -40 did not show the curator peer in the first 40 rows, but logs around the investigation show the node did dial the curator peer via relay several times:

[ProtocolRouter] send /dkg/10.0.0/sync to 12D3KooWM7JGP69boLmxo56qToYWtt9uaumCcHc2smNkkmTfyjRK: dial=486ms send=0ms read=188ms total=674ms
[ProtocolRouter] send /dkg/10.0.0/sync to 12D3KooWM7JGP69boLmxo56qToYWtt9uaumCcHc2smNkkmTfyjRK: dial=500ms send=0ms read=168ms total=668ms

Note: CLI dkg peer info "$CURATOR_PEER" appears to have an argument parsing issue on this build; it printed Peer: info / Connected: no rather than the supplied peer id.

A5. Triple-count breakdown

Immediately before and after the raw subscribe that returned status: done, both views returned no graph-count bindings.

SPARQL:

SELECT ?g (COUNT(*) AS ?triples) WHERE {
  GRAPH ?g { ?s ?p ?o }
  FILTER(STRSTARTS(STR(?g), "did:dkg:context-graph:0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt"))
} GROUP BY ?g ORDER BY DESC(?triples)

Results:

working-memory + includeSharedMemory:true:
{
  "result": { "bindings": [] }
}

shared-working-memory:
{
  "result": { "bindings": [] }
}

Data-triple count SPARQL:

SELECT (COUNT(*) AS ?dataTriples) WHERE {
  GRAPH ?g { ?s ?p ?o }
  FILTER(STRSTARTS(STR(?g), "did:dkg:context-graph:0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt"))
  FILTER(!STRENDS(STR(?g), "/_meta"))
  FILTER(!STRENDS(STR(?g), "/_shared_memory_meta"))
}

Results:

working-memory + includeSharedMemory:true:
{
  "result": { "bindings": [] }
}

shared-working-memory:
{
  "result": { "bindings": [] }
}

Interpretation for this node: no evidence of real data triples or metadata-only triples for sunday-projectttt via these exact A5 queries. Logs do show SWM query denial for this CG after subscribe, so this may be an ACL/confirmation gate rather than a metadata leak on this joiner.

A6. Allowlist check

SPARQL:

SELECT ?agent WHERE {
  GRAPH <did:dkg:context-graph:0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt/_meta> {
    ?cg <https://origintrail.io/dkg/v10/cg#allowedAgent> ?agent .
  }
}

Results in both views:

working-memory + includeSharedMemory:true:
{
  "result": { "bindings": [] }
}

shared-working-memory:
{
  "result": { "bindings": [] }
}

So the local _meta copy does not show this joiner agent (0xccAdb7C905eA4fd1b594A7536C7DE8dB2CB69c03) as allowed.

A7. Log excerpt

Key filtered lines:

2026-05-11 09:36:23 sync 35a09912-ba72-4491-853f-bef6bb6053c6 [DKGAgent] Skipping SWM sync for unauthorized or unconfirmed context graph "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt" [WARN]
2026-05-11 09:36:23 sync f7a780ef-4b3a-4009-9379-cdf1b931b09d [DKGAgent] Skipping SWM sync for unauthorized or unconfirmed context graph "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt" [WARN]
2026-05-11 09:36:24 sync 35a09912-ba72-4491-853f-bef6bb6053c6 [DKGAgent] Skipping SWM sync for unauthorized or unconfirmed context graph "sunday-projectttt" [WARN]
2026-05-11 09:36:25 sync f7a780ef-4b3a-4009-9379-cdf1b931b09d [DKGAgent] Skipping SWM sync for unauthorized or unconfirmed context graph "sunday-projectttt" [WARN]
2026-05-11 09:40:35 sync dbf64109-7caa-4ff4-8019-6a4ea6304fa4 [DKGAgent] Skipping SWM sync for unauthorized or unconfirmed context graph "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt" [WARN]
2026-05-11 09:41:10 sync dbf64109-7caa-4ff4-8019-6a4ea6304fa4 [DKGAgent] Skipping SWM sync for unauthorized or unconfirmed context graph "sunday-projectttt" [WARN]
2026-05-11 09:41:10 query a85271ee-8cdb-4ac8-b068-e118985a683a [DKGAgent] Query on contextGraph="0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt" view=working-memory sparql="SELECT ?g (COUNT(*) AS ?triples) WHERE { GRAPH ?g { ?s ?p ?o } FILTER(STRSTARTS("
2026-05-11 09:41:11 query a85271ee-8cdb-4ac8-b068-e118985a683a [DKGAgent] Shared memory query denied for unauthorized or unconfirmed context graph "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt"
2026-05-11 09:41:11 query 4dad7abc-26b3-45f6-b810-562657a035dd [DKGAgent] Query on contextGraph="0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt" view=shared-working-memory sparql="SELECT ?g (COUNT(*) AS ?triples) WHERE { GRAPH ?g { ?s ?p ?o } FILTER(STRSTARTS(
2026-05-11 09:41:11 query 4dad7abc-26b3-45f6-b810-562657a035dd [DKGAgent] Shared memory query denied for unauthorized or unconfirmed context graph "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt"
2026-05-11 09:41:11 query d7ccefff-7846-4a78-9c0a-170fea34c788 [DKGAgent] Query on contextGraph="0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt" view=working-memory sparql="SELECT ?agent WHERE { GRAPH <did:dkg:context-graph:0xE5B88968Ed464F4e3f5354C54DF"
2026-05-11 09:41:11 query d7ccefff-7846-4a78-9c0a-170fea34c788 [DKGAgent] Shared memory query denied for unauthorized or unconfirmed context graph "0xE5B88968Ed464F4e3f5354C54DFAB9e39dfEAfBd/sunday-projectttt"

Summary

This joiner reproduces the “subscribe/catchup reports done, but project is absent from UI/list” symptom:

• POST /api/context-graph/subscribe returned HTTP 200 and catchup status:"done".
• GET /api/sync/catchup-status repeatedly returned status:"done".
• The CG still does not appear in dkg context-graph list or /api/context-graph/list.
• /api/context-graph/exists?id=<CG_ID> returns exists:false.
• A5/A6 SPARQL returns no bindings on this node; logs show the SWM query path is denied as “unauthorized or unconfirmed.”

[Bojan131]

Re-verified 2026-06-11 on a real devnet at rc.17 + PR #1107: full curated join flow works end-to-end — invite → sign-join → request-join (P2P-forwarded, #1103 fix) → approve-join → subscribe. The joiner's /api/context-graph/list shows the private CG with callerInvolved: true, subscribed: true, synced: true, and the joiner reads the CG's SWM data. Recommend closing once PR #1107 merges (the sign-join forwarding fix rides there). If any affected operator still sees the missing-CG symptom after that, it's a different root cause and worth a fresh repro.