Scope and prerequisite discovery
The Portal’s Network route requires runtime enablement, an owner and recovery authority. Listing/discovery has a separate flag. Network Flows must be installed and granted the intended connection for Share/Reply actions. Do not probe an unavailable feature by sending a lifecycle action.
Discover the intended Mind and principal with orient {}. Inspect list_available_apps {} and list_actions {}. Use only the installed action schema, current connection and owner-authorised disclosure. The companion’s five network_* tools are a different interface, described in network-client-procedure.
Use the verified owner invitation route
The inviting side mints the one-use token with the act tool: mind_invite_create, item_id invite, config.expires_in_seconds (1 to 604800) and a stable UUID idempotency_key. It needs the owner, or a holder explicitly authorised to manage peer trust. Read the new token only from mind_invite_operation_status with the returned lookup_id; the lookup is kept for at most 300 seconds, and an uncertain mint is not replayed. The Portal’s Connect to a Mind form only redeems a token; it does not mint one.
In Portal Network → Connect to a Mind, enter the peer-supplied one-use token. Use Check invite, then the same lookup’s Check invite status. Inspect signed peer identity and compare it through a trusted human channel. Display name/DNS control are not identity or trust proof.
Record the intended local connection name with Record pending invite. The receiving owner inspects and accepts the request. Refresh active connection state and generation. After an uncertain lookup/invite, retain the same request identity and use the offered same-attempt retry, not a second request with changed names.
When the owner accepts a connection, Core applies defaults unless the Network defaults switch is off. The peer gets the held-for-review receive grant (reviews:propose), and read on the connection’s own folder under 30-connections. A connection named peer gets the Network Flows send binding, and each eligible installed app gets a send grant for an ordinary connection. Defaults are applied once, at accept time, and an existing owner edit is never overwritten. Assign any further peer access profile separately and inspect effective grants. An accepted relationship alone does not grant read of your other areas or every donated action. No generic remove_connection call is used for a Mind connection.
Queue an explicit Share
Prefer the supported Portal control for owner-authored Share text. Under an authorised technical client, invoke_app_action uses the exact installed action schema. The selected 0.5.0 Share declares inline and optional connection_name. The Portal’s released equivalent uses inline.body, inline.idempotency_key and a matching top-level idempotency_key.
Generate one fresh 64-character lowercase hexadecimal retry key for a new send; retain it unchanged for that same attempt. Do not reuse a documentation key. Bind the intended connection and exact body, at most 120,000 characters. A returned enqueued/queued state is not delivered or received.
With Network Flows 0.5.0, an admitted send is also saved in full as sent/<date>-<delivery id>.md in that connection’s folder under 30-connections, which the connected Mind can read. That record keeps the outcome queued and is not updated when delivery settles; read delivery status in the Feed under the delivery id. A send is refused as peer-delivery-share-not-granted until the peer has read on that folder, which the accept defaults grant unless the switch is off.
If recipient selection is absent from the installed schema, use the current owner-bound default or hand off for configuration. Do not add an undocumented parameter to target a different peer.
Follow reception and Reply
Inspect the actual original delivery attempt and receiving history/Feed. Receiving proposals remain untrusted partner content and can need local review. Save/readback acceptance is different from transport success.
Reply through the received Share’s supported contextual control and authenticated reply reference. Do not infer that reference from a file path or application message ID. Review the outgoing recipient and text before submission.
Reconcile failures and lifecycle changes
After a lost response, keep the same payload, idempotency key and peer binding. If the connection generation or peer changed, stop the retry and reconcile the original operation. A new recipient needs a new decision.
Maintenance pauses supported Shares, Replies, requests and lookups. Revocation, identity change or reconfirmation requires the owner’s supported repair. An unblock does not undo prior revocation or recall delivered content. Inspect each result rather than guessing success from an unavailable read.
Related
Practical guides for people and agents