Inspector, Peers & cross-instance sync

Peers are other Neotoma instances you register so this database can replicate structured state with them. Each row is a configuration: remote base URL, sync direction, which entity types participate, authentication (AAuth or shared secret), and how conflicts resolve. Secrets never render in full; the API redacts shared_secret on list and status reads.

Operators use this view to confirm which remotes are trusted, whether push/pull/bidirectional rules match expectations, and when the last sync attempt completed. Programmatic parity lives on GET /peers, POST /peers, GET /peers/:peer_id, and DELETE /peers/:peer_id, the same surface exposed as MCP list_peers, add_peer, get_peer_status, and remove_peer. Inbound replication uses signed POST /sync/webhook on the receiver; see REST API for the full contract.

inspector.neotoma.io/peers

Inspector

Peers

3 configured · 2 active · last probe 12:44

webhook OKGET /peers

Name	Peer ID	URL	Direction	Types	Auth	Conflict	Active	Last sync
Prod mirror	prod-eu-1	https://neotoma.example…	bidirectional	task, contact, event	aauth	source_priority	yes	12:40
Staging ingest	staging-us	https://staging…/api	pull	note, file_asset	shared_secret	manual	yes	11:02
Archived laptop	legacy-mac	http://127.0.0.1:3180	push	all seeded types	shared_secret	last_write_wins	no	none

One row per configured peer: URL, direction, scoped entity types, auth method, conflict strategy, active flag, and last sync metadata.

Columns

Name and Peer ID, human label plus stable identifier used in webhook payloads (sender_peer_id) and subscription loop prevention (sync_peer_id).
URL, the remote Neotoma base used for sync and discovery; must match TLS expectations in production.
Direction, push, pull, or bidirectional, defining which side may originate replication traffic for scoped types.
Types, allowlisted entity_types array; empty interpretations in the API are rejected, so operators always see an explicit scope.
Auth, aauth vs shared_secret; when the secret is generated server-side, the create response is the only place it appears in full.
Conflict, reducer-facing default when both sides emit observations for the same entity field;manual pairs with operator correct flows.
Active and Last sync, operator toggles and telemetry from the most recent successful or failed sync pass (when implemented end-to-end on the instance).

Related surfaces

Peers interact with Connection (which API this Inspector is pinned to) and with substrate subscriptions that opt into sync_peer_id for webhook loop prevention. When debugging replication, start here, then confirm delivery on the receiving instance logs for /sync/webhook.