Repository navigation
Cross-network calls #78
Description
The problem. A farmer here can see a catalogue another network published, but cannot act on it. The select has nowhere to go: our adapter answers for our own providers, and a request naming somebody else's is either answered wrongly or not at all.
The same gap runs the other way. A select arriving from another network looks like any other caller, so a network we never agreed with can ask us for data and be served.
What needs to be true
- A select for a provider on another network reaches that network, at the address the catalogue carried, signed as us.
- Our signature does not replace whatever separate login that provider requires.
- A select from a network we did not admit is refused before it reaches anything that would answer it.
- A select meant for somebody else is not answered with our data.
- An old request is not accepted as a fresh one.
- Being findable in discovery does not by itself permit what comes next.
Doc: Fetch, get, or invoke; Federated communication at a glance step 5.
Parent: #48
Activity
feat(provider): send a call addressed to another network to that netw…
feat(registry): refuse a key to a network we did not agree to give to […
feat(provider): send a call addressed to another network to that netw…
feat(registry): refuse a key to a network we did not agree to give to […
feat(provider): send a call addressed to another network to that netw…
feat(registry): refuse a key to a network we did not agree to give to […
feat(provider): send a call addressed to another network to that netw…
feat(registry): refuse a key to a network we did not agree to give to […
feat(provider): send a call addressed to another network to that netw…
feat(registry): refuse a key to a network we did not agree to give to […
16 remaining items
feat: send a call addressed to another network to that network [#78]
feat: send a call addressed to another network to that network [#78]
feat: send a call addressed to another network to that network [#78]
feat: send a call addressed to another network to that network [#78]
feat: send a call addressed to another network to that network [#78]
feat: send a call addressed to another network to that network [#78]
feat: send a call addressed to another network to that network [#78]
ameersohel45 commentedon Oct 15, 2026
PR #84 covers this.
A select for another network's provider now goes to that network. It uses the address the catalogue carried, and we sign it as us.
The other way round: if we never admitted that network, the registry will not give out their key. The call stops at signature validation, and never reaches a capability.
feat: send a call addressed to another network to that network [#78]
feat: send a call addressed to another network to that network [#78]
feat: refuse a cross-network call outside what we agreed [#78]
fix: call a network's published discover endpoint as it stands [#78]
ameersohel45 commentedon Oct 19, 2026
Here is the PR , which adds functionality to handle the cross network calls . For eg when select arrives is the calls from our admitted network.Behaviour not changed for self capability calls : #84
Status : Inreview.
fix: take a schema pack that already names its context as it stands [#78
fix: bump kin-openapi to v0.149.0 to clear Trivy CVEs [#85]