Before: Alice sent /network.send-request to Bob, Bob accepted via
/network.accept-request and gained Alice in his peers list, but Alice
was never notified — her pending row sat there and she had to
manually add Bob separately. User complaint: "it's strange you have
to do it both ways."
Fix — the accept now fires a best-effort connection_accepted message
back to the requester:
- handle_network_accept_request: after writing the local peer record,
assembles a `{type: "connection_accepted", request_id, from_did,
from_onion, from_pubkey}` JSON, signs + encrypts + POSTs it to the
requester via node_message::send_to_peer. Uses PeerRequest internally
so it prefers FIPS and falls back to Tor.
- handle_node_message: parses incoming plaintext as JSON; on a match
for type=connection_accepted, auto-adds the sender to peers.json
(the existing self-pubkey guard in add_peer still applies) and
short-circuits the normal store_received path so the acceptance
doesn't also land as a chat message in Alice's inbox.
Offline handling: if Alice is offline when Bob accepts, the notify
warns and the local accept still succeeds. Alice will receive any
subsequent message from Bob normally; future iteration could
retry on reconnect.
Federation-invite flow (federation.accept-invite → notify_join) was
already bidirectional; this closes the gap for the peer flow.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2d78c2ef2b