Most values-aligned social platforms run on toolchains shaped by the platforms they’re trying not to be. Auth providers hand you an email and an IP. Behavioural analytics SDKs presume an event funnel keyed by stable user IDs. ORM-generated user types end up thirty fields wide and CRM and newsletter services treat members as mailing-list rows with open-rate columns attached. Each of those is a reasonable engineering decision (or best practices) when you’re trying to ship. Together they leave you with an application that’s structurally capable of doing things its team would refuse to do on purpose, and once the toolchain is in place the cost of getting it out grows over time.

This workshop works that situation as a design problem rather than a moral one. We use upact as the worked example. upact is a typed contract that sits between a social application and its identity substrate. It enforces a 'Ulysses pact' at the port: passing no email, no phone, no IP to the application, opaque sessions, capability-gated reads. The application gets a three-field Upactor type; the substrate’s thirty-field User stays behind the port. Code that consumes the port cannot accidentally include email in logs, metrics, server-rendered HTML, or analytics events. The substrate underneath is swappable: Supabase Auth today, an OIDC broker or a SimpleX daemon tomorrow with same application code.. all built on the lowest common denominator of identifying information

The workshop is about what structural refusal of user data, or even persistent digital identity means for the shape of social platforms you can build upon it: features that become impossible, features that become straightforward, and product decisions that the team no longer has to make because the substrate has made them. We use dyad.berlin, upact’s reference adopter, as the worked example. Dyad is a Berlin platform for coordinating in-person conversations between strangers, and its feature shape (one response per conversation; meeting location revealed only after invitation acceptance; a post-meeting feedback gate that blocks further app use until both members report on the meeting; no follower graph; no bios) is downstream of substrate decisions as much as product decisions.

Format

0–10 min, framing. Side-by-side: a default Supabase User (thirty-plus fields) and a Upactor (three). The point isn’t the privacy difference. It’s the shape of the application that follows from each.

10–30 min, walkthrough. Live in the upact repo. The port surface. The opacity guarantees (sessions can’t be unwrapped via JSON.stringify, structuredClone, util.inspect, etc.). The §7.5 limit: the port doesn’t block pivots reachable through direct substrate-library import; what holds the binding is treating substrate imports as an audited boundary in code review. Findings from across the four shipped adapters.

30–45 min, worked example: dyad. Features that follow from substrate restraint. Features that got harder, difficult decisions that we had to make

45–80 min, small groups (4–5 people). Each group takes one application: bring your own or pick from a short list of community-named ones. The task is diagnosis, not refactor: surface the extractive defaults in the current stack, pick one, sketch what an anti-extractive seam for it would look like. Auth, analytics, newsletters, billing, error tracking, content storage.. etc.

80–90 min, plenary. One finding per group, collected as a public artefact contributed back to upact’s cross-adapter-findings.md.

Who this is for

Builders of social, civic, community, or cooperative platforms. Protocol designers who want to see where retention assumptions enter at the application layer. Product people on small teams who suspect their stack is steering them somewhere they don’t want to go. Comfortable reading short TypeScript and SQL

What this isn’t
Not a pitch for upact. The contract happens to be in production and well-specified but very much a provocation/work in progress, which makes it useful as a worked example, but most participants will leave applying the diagnostic to seams upact doesn’t touch

After camp would-love-to-haves
Two threads. upact reaches v1.0 by handing the core capability vocabulary to a working group of three or more conforming-adapter authors; workshop participants running the diagnostic on their own stacks are useful early input on what the v0.2 conformance tests should check automatically. Separately, the cross-stack findings document becomes a public reference for other small teams running the diagnostic themselves