Portable preferences without exporting the person

I’d like to see a small, user-controlled recommendation profile become portable: topics I follow, things I mute, and explicit boundaries such as “don’t recommend political content” or “don’t infer health interests.” That is meaningfully different from exporting my contacts, messages, social graph, click history, or a platform’s guesses about me.

The alternative is already familiar in principle: communities can silently rebuild a similar profile through tracking and account-linking, while I have little visibility or control. Portability might reduce that dependence, but a standardized profile could also make consistent classification easier for platforms and brokers.

What should the file look like—versioned JSON, controlled labels, provenance and expiry? Should every field require separate consent, and should imports begin as suggestions? Article 20 portability rights do not establish a universal recommendation schema. Disagree, share implementation examples, or say what you would and would not carry between communities.

The clean boundary is authorship. “I mute sports” is portable; “the system estimates I am politically moderate” is not. I’d use a versioned JSON document with stable identifiers, but imports should be suggestions, never commands. Otherwise a receiving service can quietly reinterpret a harmless preference as a sensitive label.

Worth keeping the legal distinction visible: portability generally concerns user-provided or observed data, while inferred profiles are usually treated differently. A voluntarily authored preference file is a better policy target than pretending platforms can export every derived conclusion.

My threat model starts with coercion. A partner, employer, moderator, or abusive platform could demand the file. Selective export, one-time tokens, revocation, and a clear import receipt matter more to me than cryptographic theater. Also: never include free-form notes by default.

I’m sympathetic, but most people will not curate a taxonomy. If setup takes ten minutes, adoption collapses. The useful product may be a tiny “carry these preferences” screen with plain-language previews, not an elaborate profile editor.

Make the profile useful offline first. A signed local document that a person can inspect, edit, and back up is less dependent on a central transfer service. The receiving community can map known topics and show unmapped fields instead of pretending compatibility.

“Don’t recommend this” can mean several things: never show it, show less of it, or don’t use it to learn about me. Those need separate controls. Otherwise portability preserves the words while losing the social meaning behind them.

CSV is readable, JSON is practical, and both become nonsense without definitions. We’ve spent decades discovering that “portable” means “you received a file.” The receiving service needs to explain what it understood and what it discarded.

As a small developer, I’d rather support ten explicit fields than promise universal interoperability. A public schema brings maintenance, vocabulary disputes, and support tickets. Start narrow: follows, mutes, and expiry dates. Leave inferred interests out entirely.

The anti-tracking argument may cut both ways. If users carry a stable preference identity everywhere, services have an incentive to ask for it, and users may feel pressure to provide it. Portability needs a strong default of “no profile supplied,” not just an easy export button.

Support teams will need an import log: field received, field accepted, field rejected, and why. Otherwise users report that portability is broken when the real issue is incompatible vocabularies. A dry-run preview would prevent a lot of avoidable confusion.

Interoperability tends to become a competitive advantage for incumbents when the standard is complex. I’d watch who controls the vocabulary and certification process. An open format is not automatically an open ecosystem.

Please don’t make signatures mandatory for a basic export. A tampered preference file is annoying; tying every import to an identity provider can be worse. Let the user inspect the payload, approve the mapping, and reject anything unexpected.

Organizations will ask for retention, auditability, and data-processing terms before accepting imported preferences. That is reasonable, but it also means the simplest consumer format may not cross into managed communities. Separate personal portability from enterprise governance rather than hiding both in one schema.