Skip to content

Cross-Plug entity reconciliation spike — same human, multiple PERSON projections #666

Description

@wow-miley

Context

Noted as separate in #640 and re-deferred in socket-link/socket#1122's out-of-scope; filed early by request. Multiple Plugs will project the same human: Contacts emits a PERSON, Calendar embeds the same human as an attendee, Mail (post-launch) as a sender. Each projection gets its own canonId from its own Link, so today "the same human" is not a fact the system can state — an Arc asking "everything involving Alex this week" gets three disjoint identities.

The same structure applies beyond people (the same place from Location vs. a calendar event's venue), but PERSON is where it bites first and hardest.

Gate: opens once two or more live Plugs are actually producing PERSON at once (P0 wave shipped) — the analysis needs real collision data, not hypotheticals.

Objective

A recorded verdict on the reconciliation model: no reconciliation (Arc-level heuristics only), a match hint on entities (e.g. normalized-handle keys computed at the adapter edge), or a first-class identity graph mapping canon ids to a person cluster.

Expected Outcomes

  • Analysis of the three models with the privacy surface named per model — a cross-source identity graph is the single most sensitive structure Socket could hold, and the consent ledger's per-(Plug, Link) grants do not obviously cover cross-Link joins; whatever wins must state where reconciliation data lives, how it is consented, and how it is revoked
  • Collision study from real usage: how often the same handle appears across Links, and what match precision handle-normalization alone achieves
  • Trace/replay implications stated (reconciliation must be deterministic under PlaybackRelay or excluded from traces entirely)
  • Verdict recorded; implementation tickets only after

Tasks

  1. Instrument (behind existing observability, no new data stores) a count of cross-Link handle collisions in real usage
  2. Analyze the three models against: consent coverage, revocation story, replay determinism, and Arc ergonomics
  3. Survey precedent (CNContact unification, Android ContactsContract aggregation) for the platform-native prior art
  4. STOP — verdict recorded before anything is drafted

Technical Constraints

canonId stability rules are untouchable — reconciliation layers over identities, never rewrites them; nothing may create a persistent cross-Link store before the consent question has a recorded answer.

Out of Scope

Implementation; PLACE reconciliation (same framework applies later); any UI.

Agent: Opus (analysis spike)

Metadata

Metadata

Assignees

Type

No type

Projects

Status
Backlog

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions