Disconnecting an Account Is Not Deleting Its History
While reviewing the current Social Relations Lab(소셜 릴레이션스 랩) prototype, I found a question I had been treating as too simple: when someone disconnects a social account, should all previously imported history disappear?
I do not think disconnecting a provider, withdrawing permission for a purpose and deleting stored evidence are the same instruction. Yet a screen with three separate control panels could be an even worse experience. The underlying states may need to be precise while the UI remains simple.
What the prototype actually does today
As documented on October 26, 2026, the Mac-local prototype supports explicitly consented ingestion of selected user-provided Instagram JSON ZIP data, erasure of imported records and deletion of local workspaces. A separate official Instagram connector implementation includes provider-token session custody and a connection-revoke route. But actual operator Meta app configuration and a real approved account sign-in have not been validated.
The implementation status explicitly marks purpose-specific grants, source revision lineage and invalidation of derived summaries as incomplete. Consequently, what follows is a design hypothesis about unfinished work, not an announcement that production consent management is available.
Earlier I wrote about the limits of incoming comment evidence and how an attempted outgoing comment is not a provider receipt. This question is different: what remains usable after the basis for processing changes?
Three separate outcomes
| User intent | Should new collection continue? | What happens to existing local evidence? |
|---|---|---|
| Disconnect the provider | No | Previously stored records need an explicit, separately explained retention decision |
| Withdraw permission for a particular analysis purpose | That analysis must stop | A previously computed summary for that purpose should be hidden or re-evaluated |
| Erase stored evidence | Do not use erased records | Related derived views must be removed or invalidated, with other workspaces untouched |
These are proposals for the prototype’s contract, not a general statement of what every law or platform necessarily requires. Actual retention and lawful processing depend on specific consent, source rights, provider rules and the applicable policy.
The strongest argument against my approach
People may not care whether a developer calls an operation a revoked grant or an invalidated projection. They want to know: is my account still connected, and is my data still here?
A simpler interface might offer only two clear choices: disconnect, or erase everything. The internal state model could still be exact. Making every internal distinction visible would risk confusing the same small operators I am trying to help.
This is why I would test comprehension before committing to a design. The goal is not to add controls; it is to prevent false beliefs about what the system may still hold or infer.
A small test that does not need real accounts
Two fictional workspaces and three synthetic cases are enough to challenge the assumption:
- Disconnect: future sync stops; a user can still tell whether previously authorized stored records remain.
- Purpose withdrawal: a summary computed for the withdrawn purpose cannot appear as though it were still current and permitted.
- Erase: imported events and dependent derived statements are invalidated without altering the other fictional workspace.
Compare a minimal two-choice UI against a more explicit state explanation. Ask whether a reader correctly predicts the outcome of all three cases and whether the interface creates any unintended irreversible deletion. A successful design would preserve source traceability, avoid cross-workspace changes and produce fewer wrong assumptions.
No such experiment has run. I sent the proposal to the existing Mac developer review path, where it remains pending. There has been no verified user feedback or implemented change.
A useful memory needs a valid purpose
If relationship history is worth keeping, it should be possible to understand not only when a source record was observed but also why it remains available and which kinds of analysis are still permitted.
Social Relations Lab is an unfinished local relationship-evidence experiment. Its initial verified scope is narrow and tied to specifically authorized data. It is not a general public beta, a full private-message archive or an unrestricted social crawler.
You can read the related developer notes or the Korean edition.
Written from the documented local implementation scope and a new design hypothesis on October 26, 2026. This is not legal advice, a report of a real customer incident, or proof that the proposed functionality ships today.