Evaluate secure cross-instance identity and sharing federation

[Medformatik]

Problem

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.

Current state

• OpenMapX accounts and user data are instance-local.
• No remote actor identifier, discovery endpoint, signed message format, inbox/outbox, or federation policy exists.
• The competitive-analysis note proposed federation, but the local sharing/permission model is not yet established.

Proposed solution

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.

Acceptance criteria

• 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.

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.

Dependencies

Requires the stable local sharing/ACL model from #294 and the user-data trust/E2EE decision from #312.