You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: packages/das-client/README.md
+20-3Lines changed: 20 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,11 +12,28 @@ Distributed AtomSpace (DAS) as a pluggable `Space` backend for MeTTa TS.
12
12
-**`das.metta`** — the vendored DAS module type declarations (`new-das!`, `das-evolution!`, …).
13
13
- The bus command vocabulary (`BusCommand`) read from the Python `service_bus`.
14
14
15
-
## The one remaining boundary (needs a live DAS to validate)
15
+
## Validated against a live DAS ✅
16
16
17
-
What's left is the **streaming pattern-matching choreography**: the proxy joins the network, issues a `PATTERN_MATCHING_QUERY` over `bus_command_proxy`, and assembles the streamed `query_answer_tokens_flow` — specifically the `ANSWER_BUNDLE`/`COUNT` token decoding into `QueryAnswer` bindings (`hyperon_das/service_clients/pattern_matching_query.py`).
17
+
A real DAS cluster was stood up and the TypeScript client called it over gRPC end-to-end:
18
18
19
-
This is intentionally **not** shipped as an unverified best-guess. Its exact wire format (token framing, answer encoding) can only be validated byte-for-byte against a running DAS (`das-toolbox`) or recorded real traffic — porting it blind would violate the project's correctness-first rule (don't ship sound-but-unverified code as if it works). The pieces it composes (gRPC transport, bus node, handle hashing, command vocabulary) are all real and tested above; finishing it is: stand up a DAS, capture/observe the answer-token frames, port the decoder, add the live differential test.
19
+
```bash
20
+
# 1.0.0 das-cli matches the released agent image; MongoDB 7.0 avoids the 8.x kernel guard.
DAS_LIVE=1 pnpm vitest run packages/das-client/src/live-das.test.ts
29
+
# LIVE DAS AtomSpaceNode.ping -> {"error":false,"msg":"PING"}
30
+
```
31
+
32
+
**Version-matching is the catch.** The released 1.0.0 Query Agent serves the `dasproto.AtomSpaceNode` service; `das-proto` HEAD later renamed it to `DistributedAlgorithmNode`. Calling HEAD's contract returns gRPC `UNIMPLEMENTED`; generating from the pre-rename `atom_space_node.proto` makes the call land (`ping` → `PING`). So the client carries both generated contracts and the live test uses the one the running agent actually serves.
33
+
34
+
## The one remaining boundary (the query-token protocol)
35
+
36
+
With gRPC connectivity to a live agent now proven, what's left is the **DAS query-token language + answer decode**: turn a MeTTa pattern into DAS query tokens (`LINK_TEMPLATE`/`NODE`/`VARIABLE` + handles), issue it via the proxy's `execute_message`, and decode the streamed `ANSWER_BUNDLE` tokens (`QueryAnswer.untokenize`, then resolve handles against the atomdb). The Python reference is `hyperon_das/service_clients/pattern_matching_query.py` + `query_answer.py`. This is now **unblocked** — a live DAS is the oracle — but it is a substantial, version-sensitive port (DAS's query path is itself marked *Under Construction* upstream), so it is built incrementally against the live agent rather than shipped as an unverified best-guess.
20
37
21
38
**Node-only:** a participant hosts an inbound bus node, which a browser cannot do — the browser reaches DAS through [`@metta-ts/das-gateway`](../das-gateway).
0 commit comments