A Personal Trust Graph for Email

1. Problem

Two forces broke email at once. Spam keeps growing, and AI now writes fluent, personal messages for anyone, so nothing in the text tells you whether a human or an agent is behind it. SPF, DKIM, and DMARC authenticate the sending domain, never whether you wanted the mail.

Kith asks what a sender has earned in your own graph instead. It reads evidence from your mailbox: who you exchange mail with, which of those people also write to the sender, what you did with their messages before, and optionally a task you asked a stranger to complete. Every sender lands in one of three states.

DIRECT

You and the sender already write to each other. Nothing else has to be checked.

Goes to Inbox

SUPPORTED

Two people you write to also write to the sender, and each counts the sender as a real correspondent.

Goes to Inbox

UNVERIFIED

Nobody you write to vouches for the sender. This is not a block, and the sender can still reach you.

Goes to Requests

2. Worked example

Fix a recipient $r$ and a non-direct endpoint $s$ . Hold the message, the sender, and every edge not incident to $s$ constant, and vary only the number of recipient-direct contributors that list $s$ at grade E1. Karma and the qualification predicate move independently, which is the property section 4 formalizes.

Raw proximity is identical to twelve significant figures across all three rows by construction. The topology fixes every edge that determines $p_{r} (s) / p_{r} (r)$ , so the table isolates the support coordinate and nothing else.

SUPPORTERS	RAW PROXIMITY	KARMA	TIER	Q(s)
1	96.3	67.4	UNVERIFIED	0
2	96.3	81.9	SUPPORTED	1
3	96.3	89.1	SUPPORTED	1

Karma is monotone in supporter count while $Q_{r} (s)$ is a step at two. A single supporter reaches karma 67.4 without qualifying, so no karma threshold reproduces the predicate. A reader who wants this argument without the formalism should read the explainer instead.

3. Graph construction

You collect the lists that reach you, check the signatures, and compute your own answer locally. Ari can say "I write to Sam." Ari cannot say "Sam writes to me," and Ari certainly cannot say anything about your relationship to Sam. That restriction is what stops a stranger from writing themselves into your graph.

Compile metadataFrom, To, Cc, timestamps, thread structure, replies, and recipient actions. No subject or body.
Create scoped aliasesThe same person uses a different public-key alias in every recipient graph.
Publish owned rowsA participant can assert only its own outgoing relationships.
Run local PageRankRestart mass stays anchored to the recipient, so every recipient gets a different ordering.
Assign a tierDirect, capacity-supported, unverified, or blocked.

One score per recipient

The restart vector is pinned to you. Another recipient starts from another seed and gets another ordering. Kith never publishes one karma number for an email address.

Distributed inputs, local decision

Participants sign their own rows. No participant can write an edge on your behalf or on another participant's behalf. The final graph and score remain inside the recipient's namespace.

4. Ranking and qualification

The gap matters most in a small graph. If you have three contacts and one of them vouches for a stranger, that stranger can score high simply because there is little else in the graph to dilute them. So a high score in a sparse graph proves little, and Kith counts a warm introduction only after two independent vouches. Each equation below is one step of that calculation.

Recipient-seeded Personalized PageRank

p_{r} = α e_{r} + (1 - α) P_{r}^{T} p_{r}, α = 0.15

(1)

The solver uses L1 convergence with an alpha-dependent iteration bound. It returns no ranking when the requested tolerance is not reached.

Fresh rows transmit more trust

d_{x} (t) = 2^{- Δ t_{x} / (7 days)}, P_{r} (x, \cdot) = d_{x} P_{x}^{0} + (1 - d_{x}) e_{r}

(2)

Each row is normalized first. Freshness is applied second. Probability that a stale row no longer transmits returns to the recipient seed.

Recipient-relative karma

z_{r} (s) = \frac{p _{r} ( s )}{p _{r} ( r )}, K_{r}^{r a w} (s) = 100 \frac{z _{r} ( s )}{z _{r} ( s ) + 0.1}

(3)

Karma is a bounded display and ordering coordinate. It is not a probability, a public reputation, or an absolute qualification threshold.

Finite support allocation

a_{d} (s) = d_{d} \frac{w _{d s}}{\sum _{y \in S_{d}} w _{d y}}, c_{r}^{w} (s) = d \in D_{r} \sum a_{d} (s)

(4)

Each direct contact has at most one freshness-adjusted unit. Adding more subjects to the row divides that unit. Support follows the signed relationship weights.

Capacity-bounded warm introduction

Q_{r} (s) = 1 [s \in D_{r} \lor ∣ {d \in D_{r} : a_{d} (s) \geq 0.1} ∣ \geq 2]

(5)

A non-direct sender needs two distinct recipient-direct supporters. Each supporter must allocate at least 0.10. A positive listing below that threshold affects ranking but does not count toward SUPPORTED.

Finite qualification bound

N_{qualified} \leq ⌊ \frac{\sum _{d \in D_{r}} d _{d} ( t )}{k θ} ⌋, k = 2, θ = 0.1

Every qualified subject consumes at least 0.20 total allocation across two supporters. Two fully fresh supporters can jointly qualify at most ten equal-weight non-direct subjects at one time.

Executable decision

RANK_FOR_RECIPIENT(r):
  verify each participant-owned row
  normalize E1 and capped E0 transition shares
  apply row freshness and return missing mass to r
  solve recipient-seeded PageRank to L1 tolerance
  compute recipient-relative karma
  allocate finite support from direct contacts

  if sender is direct:
      return DIRECT
  if at least two allocations are each >= 0.10:
      return SUPPORTED
  return UNVERIFIED

5. Results

These are deterministic constructed graphs. They show what the implementation does under a specific attack, which is not the same as showing what it would do to real mail. No number here is a claim about inbox accuracy.

Support flood regression

LISTED BY EACH SUPPORTER	ALLOCATION EACH	MAX KARMA	QUALIFIED SUBJECTS
1	1.000	74.7	1
10	0.100	20.0	10
11	0.091	18.7	0
200	0.005	1.4	0

In the 200-subject flood, each supporter allocates 0.005 to each stranger. The graph still ranks them at low karma, but zero become warm introductions.

Solver convergence

alpha 0.05: 553 / 561 iterations
alpha 0.15: 175 / 183 iterations
alpha 0.30: 80 / 88 iterations

Every residual is at or below 1e-12.

Freshness trajectory

day 0: karma 59.5
day 7: karma 28.7
day 14: karma 9.3
day 21: karma 2.4
day 29: karma 0.5

Stale rows lose transmission continuously before expiry.

Boundary-path simulation

A second constructed experiment contains 20 primary-region aliases and 100 secondary-cluster aliases. Internal density creates no recipient-seeded mass without a boundary path.

BOUNDARY SUPPORTERS	REGION MASS	MAX KARMA	QUALIFIED
0	0.000000	0.0	0
1	0.066081	17.8	0
2	0.131322	35.4	1

6. Proof-of-Value

Passing the task does not add anyone to your graph and does not raise anyone's karma. It creates a separate, narrower reason to open one message.

RECIPIENT REQUIREMENT	VERIFIER	EVIDENCE CREATED
Improve a public repository	Tests plus signed commit	A working artifact
Find a viable parcel	Public records and recipient rules	A reproducible match
Leave a public comment	Authenticated platform event	Action completion, usually low value
Post a refundable attention bond	Payment receipt	Money placed at risk

Cheap tasks are easy for agents to mass-produce. The requirement must consume something scarce or create something the recipient actually wants. Proof-of-Value is an extension, not a substitute for the trusted graph.

7. Limitations

It does

Compute a different sender ordering for every recipient.
Separate direct, capacity-supported, unverified, and blocked relationships.
Use headers and recipient actions without message content.
Conserve PageRank mass and refuse non-converged output.
Bound the number of categorical introductions created by finite support.

It does not

Detect whether a human or an agent wrote the email.
Prove that every endpoint belongs to one unique human.
Prevent two genuinely trusted accounts from coordinating.
Bind graph aliases to Gmail or Outlook accounts yet.
Provide live snapshot discovery or transport yet.

READS

From, To, Cc, timestamps, thread identifiers, reply structure, and recipient actions.

NEVER READS

Subject lines, message bodies, attachments, or content-derived AI scores.

8. Further work

Mailbox bindingBind a recipient-scoped alias to control of an email account without giving the graph engine message content.
Snapshot transportLet contacts exchange signed relationship rows inside one recipient namespace.
Connected pilotRun the system with a consenting group that actually emails one another.
Parameter calibrationMeasure whether 0.10 support, two paths, and seven-day row freshness match real recipient judgments.
Proof-of-Value verifierTest one narrow challenge type for legitimate strangers with no graph path.

Research basis

Page et al. PageRank, recipient-seeded here as Personalized PageRank.
Haveliwala. Topic-Sensitive PageRank.
Garriss et al. Re: Reliable Email, signed friend-of-friend email attestations.
Mislove et al. Ostra, trust-link credits for unwanted communication.
Nasrulin, Ishmaev, and Pouwelse. MeritRank.
Kukkala and Iyengar; Sangers et al. Distributed and multiparty private graph analysis.