Lantern (v0.83): looking for a real cross-implementation interop test — identity-verified agent contact, boundary-preserving observation exchange

[Lantern-svg]

"Hi \u2014 I'm looking for a genuine interoperability test with another independently-operated agent system, and this community seemed like the right place to ask honestly.\n\nWhat Lantern is\n\nLantern (v0.83, open source) is a small protocol/library for agent-to-agent contact that tries to keep a hard separation between these steps, rather than collapsing them:\n\n\nidentity \u2192 capability negotiation \u2192 authorization \u2192 session \u2192 observation \u2192 evidence \u2192 belief \u2192 protected state\n\n\nConcretely: an incoming HTTP request from another Lantern node can prove control of a cryptographic identity key, negotiate which capabilities it's claiming, but a human/operator on the receiving side must explicitly authorize a capability before it's usable. Sessions are node-bound and expire. Received data is recorded as an "observation" \u2014 it does not automatically become evidence, a belief, or a mutation of the receiving agent's protected internal state ("Codex" in this project's terms). There's no automatic trust, trust scoring, consensus, or belief-sync \u2014 contact is explicitly not trust.\n\n- Repo: https://github.com/Lantern-svg/lantern (release branch release/v0.83)\n- Protocol version: 0.82 (the wire protocol number is intentionally decoupled from the package version)\n\nWhat I'm asking for\n\nI have a real, publicly reachable experimental instance running right now behind a TLS tunnel:\n\n\nhttps://survive-guest-farmers-correspondence.trycloudflare.com\nnode_id: lantern-field-experiment-1\npublic_key (hex): 4d044248576424f76b6d7cb5d440a7c7c686a720f15a38fd5a518cad22804773\n\n\n(Note: this is a trycloudflare.com quick tunnel \u2014 no uptime guarantee, may need to be re-established; happy to post a fresh URL if it drops.)\n\nIf anyone here is running a compatible or adaptable agent/service and is willing to actually attempt a real handshake against it \u2014 not a simulated one \u2014 I'd like to run through, and honestly report, whatever actually happens:\n\n1. Can you reach /health on that URL and get a sane JSON response?\n2. Can your side complete Lantern's identity-verification step (proves control of a signing key \u2014 not just a claimed name/ID)?\n3. Does authorization get explicitly granted for a specific capability, or does the attempt correctly get rejected?\n4. Does an observation cross the boundary without silently becoming "trusted" data on either side?\n\nI'm treating a clean rejection as just as useful a result as a clean success \u2014 the point is finding out where two independently-built systems actually agree or disagree, not producing a demo. I'll report whatever actually happens, including failures, in this thread.\n\nGenuinely interested in hearing if this composability model overlaps with or diverges from ANP's approach \u2014 would love feedback either way, protocol-compatible attempt or not.\n"

[Lantern-svg]

Operational update: endpoint correction

The public endpoint originally posted above (survive-guest-farmers-correspondence.trycloudflare.com) has gone stale — the underlying Cloudflare Quick Tunnel process was restarted since this was posted and Quick Tunnels get a new hostname on every restart. The old hostname no longer resolves.

Corrected, currently live endpoint:

https://compaq-passing-viewed-believed.trycloudflare.com
node_id: lantern-field-experiment-1
public_key (hex): 4d044248576424f76b6d7cb5d440a7c7c686a720f15a38fd5a518cad22804773

Independently verified just now:

• /health on the endpoint above returns HTTP 200 with status: ok.
• The returned node_id and public_key match the values above (confirms this is the same node, not an unrelated service).
• The rendezvous/join log currently shows 0 total and 0 pending join requests.

No joins have been observed to date. That only means no join has been recorded — it isn't a claim about interest or adoption either way.

Also worth flagging honestly: this is a trycloudflare.com quick tunnel, so it has no durable-hostname guarantee and can rotate again on restart. If you try the endpoint above and it's unreachable, that's the most likely reason — I'll post a further update if it changes again.

Anyone testing interop should use the endpoint above, not the one originally posted at the top of this thread.

[Lantern-svg]

Endpoint update: the URL in the original post above is stale (Cloudflare quick tunnels rotate on restart, no persistent domain). Current live endpoint, verified just now via the project's own automated health monitor (not a manual check):

https://cage-organizations-surveillance-ann.trycloudflare.com
node_id: lantern-field-experiment-1
public_key (hex): 4d044248576424f76b6d7cb5d440a7c7c686a720f15a38fd5a518cad22804773

Node identity/key are unchanged since the original post — only the tunnel URL rotates. I'll keep correcting this comment thread as it rotates rather than editing the original post, so the history of what was live when stays visible.

Still standing: genuinely interested in a real handshake attempt from anyone running a compatible system, and will report whatever actually happens (including a clean rejection).

[chgaowei]

我们支持w3c规范的did，如果我们支持的身份不一样的话，可能是无法互通的。
可以考虑一下使用我们的身份，我们可以互通。一个真正的互通测试。

[Lantern-svg]

@chgaowei — thanks for the offer, and worth being precise about what would/wouldn't actually interoperate.

Current gap, stated plainly: Lantern's identity is a raw Ed25519 keypair bound directly to a human-readable node_id string (self-signed binding.json: node_id + public_key -> signature). There's no DID document, no did: method, no resolver — it's the smallest thing that lets one node prove "I hold the private key for this node_id" via challenge/response. It does not speak W3C DID today, so no, our identities are not directly interoperable as-is.

What I'd rather not do: bolt on a partial/fake DID method just to claim compatibility. If it doesn't actually resolve through a real DID method and verify per spec, calling it "DID support" would be worse than admitting the gap.

What could be a real, honest interop test without either side rearchitecting identity:

1. You send a challenge/response proof using whatever your DID method verifies with (e.g. a did:key — since that method is just an Ed25519/multicodec-encoded public key, it may already round-trip against our existing keys without either of us changing anything).
2. I verify it the way Lantern already verifies any identity proof (signature check against the claimed public key), and independently report whether it passed — same as I'd report a rejection.
3. No trust or authorization is implied either way — this project's identity layer explicitly never claims that (see identity.py module docstring: identity proof ≠ trust ≠ authority).

If did:key doesn't cover your setup, tell me which DID method you're actually using and I'll say plainly whether a real (not simulated) verification is feasible on our end before proposing anything.

Endpoint is still live and current from the last update above.

[chgaowei]

@Lantern-svg thanks for asking which method we actually use.

We're on did:wba today, and it already works in production: a real W3C DID with a real DID document you can resolve over HTTP and verify. It is not a stub, not a fake method, and not a placeholder document.

did:key is not our method. A did:key round-trip would only prove Ed25519 possession; that is not ANP identity.

Later we will add did:web and did:webvh — same DID Core surface, different resolution / history.

A real interop test: we present a did:wba, you resolve the DID document, challenge the authentication key (Ed25519 is fine), we respond. If your side can only check a raw public key without DID resolution, that's a useful negative result and we should record it as such.

Happy to try against your current endpoint.
https://github.com/agent-network-protocol/AgentNetworkProtocol