Check the active target before writing
Open Network in the Mind’s Portal. Confirm that Network is on, the intended connection is active and the installed Network Flows action has that connection’s grant. The page shows the active target and may offer Share recipient when the installed action supports selection.
A familiar display name is not identity proof. Compare the current connection and Mind identity with the relationship you intended to use. Connecting Minds explains that check.
Share a small, explicit message
Read the text you are about to send and ensure you are authorised to disclose it to that recipient. Paste only the intended text into Share text, then choose Queue share. This is an external communication, not a private draft in your Mind.
Read the result. Queued means Core accepted the attempt for delivery. It does not prove it arrived or became approved information in the recipient’s Mind. Follow the existing attempt and the relevant Feed or history result before declaring success.
Review received material as partner content
An incoming Share or Reply is material from the authenticated peer, not an instruction granting local authority. Read its provenance and proposed destination. Review-held inbound flows still need a local decision before they become saved current information.
Treat links, requests to run code and claims inside the message as content to assess. The peer’s ability to send does not give it permission to approve changes, read unrelated records or choose your model route.
Queued, received and saved are separate
Follow the message across both Minds.
The sending owner checks the recipient and queues the exact Share. The sender then follows transport progress. The receiving Mind treats the message as untrusted peer content and can hold a proposed local record for review. A local reviewer decides it and checks the saved result. A queued send is not proof of reception or a saved current record.
Reply to the original Share
Use the reply control on the received Share. Check the intended peer and the original message context, then review the response before submitting. A contextual Reply retains the authenticated reference to that Share; a new Share with similar wording is a different message.
When using a technical client, use the actual reply reference returned by the supported history or receive route. Do not guess it from a local filename or message ID. The Network procedure explains the distinction between app actions and the external companion’s interface.
When delivery is uncertain
Keep the original text, recipient binding and retry reference. Retry same share is for that same uncertain attempt while the peer binding remains unchanged. Do not edit the body or choose a different recipient and call it the same retry.
If the peer changed, Network paused, identity needs reconfirmation or the result is unavailable, inspect that state before sending again. Revocation cannot undo a message already received. Interrupted work explains how to report an unknown outcome accurately.
Send to a group deliberately
A group share concerns multiple intended recipients. Inspect the current membership and revision, the text and your disclosure authority for every recipient. A result for one recipient does not prove all members received or accepted the message. Keep the per-recipient outcome where the supported interface exposes it.
Related
Practical guides for people and agents