Privacy at Compile Time

I hate the way most systems handle privacy. You build your data model, expose it through an API, then bolt on access control as an afterthought. Maybe you add middleware. Maybe you scatter if (user.isAdmin()) checks across your codebase. Maybe you write a test that verifies one endpoint and hope the other forty are fine. The result is always the same: bugs, data leaks, and a constant low-grade anxiety about what you might have missed.

After years of building real-time multiplayer systems where privacy is not optional -- card games where each player has a hidden hand, collaborative tools where users see different data -- I built a system where privacy is checked at compile time. If you try to expose private data through a public field, the compiler rejects your code. The data never leaves the server, not because you remembered to check, but because the program cannot compile if you forget.

The Problem with Runtime Privacy

Here is a typical runtime access control pattern:

app.get('/api/cards', (req, res) => {
  const cards = db.getCards(req.gameId);
  const filtered = cards.map(card => {
    if (card.owner === req.userId) {
      return { id: card.id, value: card.value, suit: card.suit };
    } else {
      return { id: card.id }; // hide value from non-owners
    }
  });
  res.json(filtered);
});

This works. Until someone adds a new endpoint and forgets the filter. Or refactors the filter and introduces a bug. Or adds a WebSocket push handler that sends the full card object. Or writes a GraphQL resolver that exposes the raw database record.

Runtime privacy is opt-in. Every new code path that touches sensitive data must remember to apply the filter. The default is exposure. You are one forgotten check away from leaking data.

Compile-time privacy inverts this. The default is private. Exposure requires an explicit declaration. And the compiler verifies that declarations are consistent -- you cannot accidentally route private data through a public channel.

Privacy Modifiers: Declaring Intent in the Schema

In Adama, every field has a privacy modifier:

private int internal_counter = 0;   // No viewer ever sees this
public int score = 0;               // All connected viewers see this
viewer_is<owner> int hand_value;     // Only the principal in 'owner' sees this
use_policy<can_see> int balance;     // Visible when policy function returns true

Fields without an explicit modifier default to private. I made this choice deliberately -- secure-by-default is the only sane option. You have to consciously decide to expose data.

The viewer_is<field> modifier is the workhorse for per-user privacy. It takes a field of type principal (Adama's term for an authenticated identity) and makes the data visible only when the current viewer matches that principal:

record Card {
  public int id;
  private principal owner;
  viewer_is<owner> int value;
}

This is a complete privacy specification. The value field is visible to the card's owner and invisible to everyone else. Not hidden behind a null. Not redacted. Simply absent from the JSON that non-owners receive.

The privacy filter runs during delta computation. When Alice's card value changes from 7 to 9, Alice receives {"cards": {"1": {"value": 9}}}. Bob receives {} -- an empty delta. Nothing changed in Bob's view because Bob never had access to that field. The system leaks zero information about state changes that a viewer cannot see.

The @who Constant and Policy Functions

The @who constant represents the currently viewing principal. It is the foundation of every privacy decision:

policy is_owner {
  return @who == owner;
}

For more complex rules, use_policy attaches a named policy function to a field:

record BankAccount {
  private principal owner;
  private bool account_public = false;
  private int balance;

  use_policy<can_view_balance> int visible_balance;

  policy can_view_balance {
    if (@who == owner) {
      return true;
    }
    return account_public && balance > 0;
  }
}

The owner always sees the balance. Others see it only if the account is public and has a positive balance. This logic is evaluated per-viewer during delta computation. Different viewers get different results.

Record-Level Privacy with require

Field-level privacy hides individual values. But sometimes you want to hide the existence of an entire record. The require keyword does this:

record PrivateNote {
  private principal owner;
  public string content;

  policy is_owner {
    return @who == owner;
  }

  require is_owner;
}

table<PrivateNote> notes;

When Alice queries the notes table, she only sees her own notes. Bob's notes are not hidden or redacted -- they are genuinely absent from her view. She cannot even determine how many notes exist for other users.

This is different from hiding field values. With require, the record does not appear in @o ordering arrays or table iteration results. The viewer's JSON has no trace of the record.

Compile-Time Enforcement: What the Compiler Catches

The compiler prevents the most common class of privacy bugs: accidentally exposing private data through public channels.

private int secret = 42;
public int exposed = secret;  // COMPILE ERROR

This fails at compile time. You cannot assign a private value to a public field. The data flow analysis tracks privacy modifiers through expressions, assignments, and function calls. If private data could reach a public output, the compiler rejects the program.

Every code path must remember to apply privacy checks.

bubble myCards = iterate deck where owner == @who;

policy is_admin {
  if ((iterate _people where account == @who)[0] as person) {
    return person.is_admin;
  }
  return false;
}

bubble<is_admin> all_people = iterate _people;

policy is_admin {
  return (iterate _admins where account == @who).size() > 0;
}

channel<requires<is_admin>> reset_scores(ResetMsg msg) {
  (iterate _scores).delete();
}