Define the private sharing foundation for friends, live location, and collections

[Medformatik]

Problem

OpenMapX has accounts and client-side location sharing, but no relationship, access-control, or real-time presence model for sharing collections or live location with trusted people. Adding those piecemeal would make consent, revocation, blocking, and future federation difficult to reason about.

Current state

• Better Auth provides users, sessions, linked accounts, and passkeys.
• Locations and current map state can be shared through client-side deep links.
• There is no friend/contact domain, collection ACL, live-location session, presence channel, or server-side sharing audit.
• Cross-instance federation and end-to-end encryption are separate architectural decisions and should not be assumed by the first implementation.

Proposed solution

Define the single-instance social/sharing foundation and implement the smallest vertical slice needed to prove it. Cover invitations and relationship semantics, reusable collection roles, explicit live-location sessions, authorized real-time delivery, abuse controls, privacy, retention, and stable extension points for future federation.

Acceptance criteria

• An ADR defines identity, relationship, invitation, blocking, ACL, and live-session semantics.
• Database constraints prevent duplicate/conflicting relationships and unauthorized membership changes.
• Permission checks are centralized and covered by negative authorization tests.
• A collection can be shared read-only with another user and access can be revoked immediately.
• A live-location session requires explicit consent, has a bounded lifetime and selectable precision, and can be stopped immediately.
• Subscribers cannot infer metadata after removal, blocking, expiry, or logout.
• Rate limits, audit events, retention/deletion, reporting, and blocking behavior are documented.
• Account deletion cleans up or transfers shared resources according to an explicit policy.
• Threat-model and integration tests cover invitation abuse, ID enumeration, replay, stale subscriptions, and revocation races.

Alternatives considered

• Public opaque links do not provide durable membership, blocking, or live authorization.
• Starting with a federation protocol adds identity, moderation, and delivery complexity before the local permission model is proven.

Area

Authentication, accounts, saved data, real-time services, web/mobile UI.

Dependencies and non-goals

Coordinate with the E2EE trust-model (#312) and federation (#313) issues. Cross-instance delivery and background location collection are out of scope for the first vertical slice.

Reference

Originated from the Copper product notes and docs/plans/2026-07-31-parchment-competitive-analysis.md.