Evaluate identity and private sharing between OpenMapX instances #313

What needs to be done, and why?

Cross-instance friends, collection sharing, or live-location delivery requires more than discovering another server. It introduces remote identity, key rotation, authenticated delivery, replay protection, version negotiation, retries, blocking/moderation, abuse, and an interaction with any E2EE design.

Scope and open questions

Reported starting point

• OpenMapX accounts and user data are instance-local.
• No remote actor identifier, discovery endpoint, signed message format, inbox/outbox, or federation policy exists.
• Server-backed public bearer links exist for saved lists and route snapshots, but they do not establish remote identity, recipient membership, or cross-instance delivery.
• The competitive-analysis note proposed federation, but the local recipient-based sharing/permission model in Share a saved list read-only with another account on the same instance #294 is not yet established.
• Document user-data trust boundaries and decide the E2EE architecture #312 is complete: the accepted confidentiality architecture defines selective, staged protection and defers encrypted sharing between accounts/deployments. It does not implement E2EE or a federation protocol.

Write and validate a federation RFC after defining local sharing semantics. Compare adapting a mature protocol with a minimal OpenMapX-specific protocol, then prototype the narrowest useful operation between two test instances, preferably a share/invitation rather than continuous live location.

Alternatives considered

Centralized hosted sharing is much simpler but does not support independent instances. A new custom protocol can be narrower but carries long-term interoperability and security costs.

Area

Federation, identity, sharing, security, operations.

What would show that this is complete?

• The RFC defines canonical instance/user/resource identifiers and .well-known discovery.
• Protocol evaluation covers ActivityPub/ActivityStreams, Matrix-style rooms/events, and a narrowly scoped custom design with explicit trade-offs.
• Authentication specifies key discovery, algorithm/version negotiation, rotation, pinning/cache behavior, and compromised-key recovery.
• Messages have canonical serialization, signatures/MACs as appropriate, timestamps, nonces/event IDs, replay windows, and size limits.
• Delivery defines inbox/outbox semantics, idempotency, ordering, retries/backoff, dead letters, deletion/tombstones, and partial failure.
• Remote invitation, accept/reject, revoke, block, and instance-domain blocking map cleanly to local authorization.
• Abuse controls cover spam, amplification, SSRF, malicious media/URLs, resource exhaustion, reports, and operator moderation.
• Privacy analysis covers metadata, address probing, presence, live location, and instance-level observability.
• The RFC states how payload-level E2EE and remote key-directory authenticity would integrate or why they are deferred.
• Compatibility/version negotiation and conformance fixtures allow independent implementations.
• A two-instance prototype proves one bounded workflow plus revoke/block and failure recovery.
• A go/no-go decision and phased rollout/operational cost are recorded before product implementation.

Dependencies

Requires the stable local sharing/ACL model from #294. The trust-model decision from #312 is complete; use docs/docs/developer/user-data-confidentiality-architecture.md as the accepted baseline rather than treating that decision as pending. Remote identity, key-directory authenticity, recovery, deployment binding, and any payload-level E2EE still require federation-specific design and the applicable security-review gates before implementation.