Nobody has shipped the combination Match Feed proposes: Follow, plus public "Subscribe to taste" lists, plus private, mutual, expiring Matches that exchange encrypted taste sketches and are ranked on-device, all on top of a federated video catalog. Every component has strong precedent, though. Decentralized user-based collaborative filtering ran in production in Tribler's BuddyCast and was later superseded: a 2012 account calls Dispersy "the successor of BuddyCast", and current Tribler no longer mentions it (Tribler; SIGMM Records 2012). Researchers have built "friends plus a few random strangers" recommenders under homomorphic encryption that sit very close to the Match tier (Tang & Wang, ePrint 2015/1152). Centralized consented taste-matching such as Spotify Blend has shown that people want the feature (TechCrunch). DESIGN.md's citations are mostly sound. Five need fixing: the secure-aggregation claim for Circles is overstated, Douceur is miscited as a recommender paper, EigenTrust is described inaccurately, Canny is attached to the wrong sentence, and the "PSI" preview step actually describes PSI-cardinality. The design also lists PeerTube P2P delivery as a censorship mitigation without noting that PeerTube's own docs call it "the main threat to user privacy" (PeerTube privacy guide). The research favors several design moves. Ship Follow plus Subscribe-to-taste with reserved explore slots first, because that is where creator discovery happens. Treat Match as an accurate but low-novelty channel. Use MLS rather than Nostr NIP-17 for Circles. Bound second-degree propagation with a personalized, decaying trust walk. Build on existing open-source pieces (Marmot/MLS, OpenMined PSI, Vertex/MeritRank, Divvi Up/Janus) rather than writing new cryptography.
Seven of ten citations hold; five claims need repair
The verification pass checked each reference in DESIGN.md against primary sources. The privacy-attack citations are accurate. Calandrino et al. show that individual transactions can be inferred from item-to-item recommender outputs, but only with auxiliary knowledge of some of the target's transactions plus observation of how public outputs change over time. They inferred a third of Hunch test users' secret answers with no error, and 4.5% of active users' transactions at 90% accuracy on a simulated Amazon-style engine (Calandrino et al. 2011). Those two conditions are exactly the position of a Circle member who knows a peer's tastes and watches group picks change from round to round, so DESIGN.md should state them. Narayanan and Shmatikov's result is cited correctly: 8 ratings, 2 of which may be wrong, with dates off by up to 14 days, uniquely identify 99% of Netflix Prize records (arXiv cs/0610105). That supports the design's "assume sketches are identifying" rule.
The secure-aggregation citation is where the design overreaches. Bonawitz et al. give a protocol in which a server learns only the sum of user vectors and which tolerates dropouts. It was evaluated at 2^10 to 2^14 users (ePrint 2017/281) and assumes a single server and, against active adversaries, a PKI (CCS '17). SecAgg protects inputs, not the output. In a Circle of k = 5, an item with count 5 attributes the endorsement to everyone, two colluders can subtract their own inputs, and membership changes enable differencing. "Can't be attributed to any one person" is false as written. A Circle also needs someone to play the aggregator role. By the CCS paper's own parameters, n = 5 needs 3 members online through the last round against the aggregator alone, and 4 if the aggregator may collude with members, which tolerates only one colluder and one dropout. That is hard on mobile. Canny's 2002 design is the better precedent here. It is a community aggregate for CF (a partial SVD) computed under homomorphic encryption with threshold decryption and zero-knowledge verification, that the abstract says can run "as a fully peer-to-peer (P2P) system". It assumes more than half of users' machines are uncorrupted (OpenAlex abstract; author PDF). DESIGN.md currently attaches Canny to the personalized-PageRank sentence, where it does not belong.
The Sybil and trust citations are misaligned. Douceur's paper never mentions recommenders. It proves that without a logically centralized identity authority, "Sybil attacks are always possible except under extreme and unrealistic assumptions," and that PGP-style vouching chains do not fix this (Douceur 2002). That result supports the match-only premise, but the claim that Sybils "break open recommenders" needs a recommender source such as Lam and Riedl's shilling study (WWW 2004), the shilling survey by Gunes et al. (Gunes et al. 2014) or DSybil (Yu et al. 2009). EigenTrust computes a global trust vector anchored on pre-trusted peers, and its authors call those peers "essential" (Kamvar et al. 2003). Seeding the walk from your own node turns it into personalized PageRank. That is the right algorithm, but it needs its own citation: Page et al.'s PageRank report, §6 "Personalized PageRank", which tests a jump vector of a single page, and Jeh and Widom for efficient per-user computation (WWW 2003), plus MeritRank for decay-based Sybil tolerance (arXiv 2207.09950).
The protocol citations are accurate but need sharper wording. NIP-71 now defines four video kinds: regular 21 and 22, plus addressable 34235 and 34236, which were re-added in January 2026 after a January 2025 switch to regular events (NIP-71; commit history). A client should read all four. "Encrypted DMs" should name NIP-17 (NIP-44 encryption plus NIP-59 gift wrap), because NIP-04 is deprecated (NIP-04). NIP-17 itself says groups of more than 10 should "find a more suitable messaging scheme" (NIP-17), and NIP-44 lists no forward secrecy and relay-visible IPs among its limitations (NIP-44). The AT Protocol claims hold. Feed-generator requests carry a JWT whose iss is the requesting user's DID (feed-generator README), and repository contents are "entirely public" (repo spec). The current guide says the AppView, not the PDS, hydrates feeds (atproto.com/guides/feeds), and the docs.bsky.app link now redirects to an empty page.
The PeerTube framing is mostly right but internally inconsistent. The built-in "recommended videos" list returns at most 5 videos, chosen by tag overlap sorted by recency, excluding already-watched videos for logged-in users and falling back to recent uploads (PeerTube source). It is not random, despite what the fairkom issue says. DESIGN.md calls community efforts "client-side" and then cites an instance-level plugin, and that fairkom proposal, opened in June 2023 and since labelled "won't fix", specifies no method at all (fairkom #7). Reference [2] labels Lemmy announcement posts as "discussion". Both posts come from the same poster, and the Firefox add-on is listed under the same developer (solidheron, MIT) as the Chromium extension, so they are one effort, not two (PieFed 169216; PieFed 158506; AMO). Better primary links are the solidheron repo and PeerTube issue #6978, which proposes adding description vectors to video JSON for local recommenders (GitHub #6978). The VPPA statement is accurate but narrow. The statute binds only a "video tape service provider" engaged in the business of delivering video. It offers a consent safe harbor (separate, revocable, at most 2 years) that matches Match expiry well. Who counts as a "consumer" is before the Supreme Court in Salazar v. Paramount Global, No. 25-459 (Cornell LII; WilmerHale). The Court granted cert on 26 January 2026 and heard argument on 14 October 2026; the case is undecided as of 19 October 2026 (docket).
Every component exists; the consented combination does not
The closest deployed system is Tribler's BuddyCast. Each peer kept its top-N most similar "taste buddies" with their download histories plus a list of random peers, and gossiped with one or the other to balance exploitation and exploration (Tribler). It was decentralized user-based CF, the same algorithm as Match step 4, but histories traveled in the clear to algorithmically chosen peers. A 2012 column says "Dispersy is the successor of BuddyCast", and the current Tribler README does not mention BuddyCast (SIGMM Records; Tribler/tribler). An earlier forum reply saying the taste-buddy algorithms were removed about a decade ago could not be re-checked, because the forum now redirects to GitHub Discussions. The closest academic design is the friendship-based privacy-preserving recommender line. Jeckmans et al. (ESORICS 2013), as revisited by Tang and Wang, predict a user's ratings from friends plus a few randomly chosen strangers under homomorphic encryption. Tang and Wang found security and usability flaws in the original and published corrected protocols (ePrint 2015/364; ePrint 2015/1152). Match Feed's novelty claim should therefore be scoped to the combination: user-chosen, mutual, expiring matches; public signed taste lists; pooled Circles; bounded second-degree propagation; and a federated video catalog.
The surrounding research supports the core bet. PocketLens ran item-based CF across five P2P architectures, including occasionally connected devices, with accuracy "as good as the best published algorithms to date" (UMN). Gossple showed that nodes can exchange Bloom-filter profile digests to find taste neighbors, and can route profiles through proxies so they are not linked to identities, at PlanetLab scale (Gossple). Groh and Ehmig found that social filtering beat CF in every experimental variant in a taste domain (BibSonomy). Massa and Avesani found that trust-based recommenders on Epinions were most accurate while keeping coverage, especially for users with few ratings, and that a few trust statements are an effective cold-start bootstrap (Massa & Avesani 2007). One warning recurs across this literature. Sinha and Swearingen found friends gave better recommendations than online systems, but systems surfaced more new and unexpected items (Sinha & Swearingen 2001). Match will be accurate and comfortable, not exploratory.
The product landscape divides along the same line. Consented pairwise taste-matching exists only on centralized services. Spotify Blend refreshes a joint playlist daily and shows a match percentage (TechCrunch) and now supports up to 10 people (Engadget). YouTube Music has Taste Match (Android Central). Plex's Discover Together shows the failure mode: category-wide visibility settings and a default-on weekly friends'-activity email led to a backlash and an added opt-out (The Register). On the open protocols, recommendation means public graph trust, not private taste. Nostr's Vertex computes Monte Carlo personalized PageRank over follows and exposes it as data vending machines (DVMs) (No BS Bitcoin). Karma3's OpenRank applied EigenTrust to Farcaster and Lens (Decrypt); secondary sources reported a Karma3 Labs wind-down in June 2026, not confirmed first-hand. Bluesky's spacecowboy "For You" feed runs exactly the co-like user-based CF Match wants, but on a central Go/SQLite server serving about 72K daily users (atproto blog). AT Protocol's permissioned (private) data, proposal 0016, was "in design" on the spring 2026 roadmap (atproto roadmap). It is now "Atproto Spaces", in alpha since August 2026, and the proposal says it provides "access control, not confidentiality": it is not end-to-end encrypted. On the fediverse side, Loops has a For You feed that, by the project's own description, draws on engagement, hashtags and social-graph signals; the formula is not published (joinloops.org), and PeerTube-browser mixes FAISS similarity-to-likes with freshness and popularity "layers" in a crawler-indexer (GitHub). The solidheron extension is the nearest open-source video project. It already builds a local cosine-similarity profile from watch time and likes in IndexedDB and has "no data sharing yet" (GitHub).
| System | Peers chosen by user? | Private exchange? | On-device ranking? | Open/decentralized? | Status |
|---|---|---|---|---|---|
| Tribler BuddyCast | No (similarity gossip) | No (plaintext) | Yes | Yes | Removed |
| Jeckmans / Tang & Wang | Friends + random strangers | Yes (HE) | Partly | Research | Paper only |
| Gossple / WhatsUp | No (anonymous neighbors) | Partly (proxy, Bloom) | Yes | Yes | Research |
| Spotify Blend / YT Taste Match | Yes | Operator sees all | No | No | Shipping |
| Plex Discover Together | Friends | Operator sees all | No | No | Shipping |
| Vertex / OpenRank | Follows (public) | No | No (service) | Yes | Vertex shipping; Karma3 wind-down reported |
| spacecowboy For You | No | No (public likes) | No | ATproto | Shipping |
| solidheron PeerTube extension | n/a (own data only) | n/a | Yes | Yes | Alpha |
| Match Feed | Yes, mutual, expiring | Yes (E2E) | Yes | Yes | Design |
Creators win discovery through lists and reserved slots, not Matches
DESIGN.md asks whether the target is the creator or the viewer. The evidence says the two are best served by different tiers, and the creator side depends on tiers DESIGN.md treats as secondary. Collaborative filtering concentrates attention. Fleder and Hosanagar showed that recommenders can push similar users toward the same products and reinforce blockbusters (UPenn), and Celma and Cano found that CF over Last.fm data "is prone to popularity bias". By contrast, expert and content-based similarity graphs link artists "independently of their popularity", so long-tail artists are two or three clicks from the head (MTG-UPF). Match is CF over a small neighborhood, so it localizes popularity rather than removing it. Cañamares and Castells tie popularity itself to discovery through social communication (CEUR-WS). Bressan et al. show the social graph prevents "large market distortions" globally (arXiv 1607.04263), but attention can still concentrate inside clusters. On Mastodon, those clusters follow instance boundaries (arXiv 2203.15752).
Human-curated lists are the strongest measured bridge. Balduf, Sokoto et al. found that Bluesky starter packs accounted for up to 43% of daily follow operations at their peak and 19.95% of all follow edges (the press release dates the period to June 2024–January 2025). Using propensity-score matching, pack members received 39%, 57%, 71% and 85% more new follows than similar non-members in weeks 1–4 after joining; the widely quoted "85% more followers" is the week-4 figure (ICWSM 2025; arXiv 2501.11605; Lancaster). Spotify's New Music Friday placement "substantially raises the probability of song success, including for new artists" (NBER w24713). The public "Subscribe to taste" tier is therefore the creator-discovery engine, and the strongest argument for shipping it first is that it has no hard cryptography. That same causal value creates payola risk. The FTC's 2023 Endorsement Guides (88 FR 48092) require "clear and conspicuous" disclosure of material connections and count tags in social media posts as endorsements; the FTC's FAQ adds that a like can be one (Venable). Signed list entries should carry a machine-readable sponsorship flag that is shown inline, and clients should be able to filter undisclosed lists. List influence should also be capped or rotated so a few curators do not become the new gatekeepers.
Centralized platforms do something fediverse platforms do not: they reserve exposure for new content. YouTube runs a dedicated multi-funnel fresh-content stack (arXiv 2306.01720) and a real-time bandit because batch models are "limited in their capability to identify high-quality fresh videos" (arXiv 2307.15893). Other systems let new items compete only with each other for reserved traffic (arXiv 2505.09033). TikTok says follower count is not a direct ranking factor (TikTok Newsroom), though that is a platform claim, not an audit. A follow/match graph without a reserved channel locks in early movers. The on-device equivalent is an explore slot: a fixed share of each feed reserved for under-exposed creators, drawn from tag feeds and curator lists, with Singh and Joachims-style exposure constraints or popularity calibration applied at the final ranking step (arXiv 1802.07281; arXiv 2007.12230). The only published production share is YouTube's: Online Matching runs exploration on about 1–2% of user traffic (raised from 1% to 2% as the graph grew), with a 6% slice for corpus exploration, at about 0.2% engagement cost, and shows exploration items at a fixed UI position (arXiv 2307.15893). No other platform publishes a figure, so the slot fraction for a small network was a parameter to tune by simulation (see the Update below). Creators also need feedback. Bluesky feed creators say they lack interaction data (arXiv 2609.12958). The IETF Distributed Aggregation Protocol (DAP), implemented by ISRG's Divvi Up, splits each report between two non-colluding aggregators so that only totals are recoverable (Divvi Up; draft-ietf-ppm-dap). That gives creators per-video reach and "which discovery channel brought this viewer" breakdowns without anyone seeing viewing histories, provided minimum batch sizes protect small audiences.
Matches resist Sybils; second degree and public lists leak
The Match tier gets one important property almost for free. Similarity-based neighbor selection is exactly what shilling exploits, because an attacker builds a profile similar to the target's so as to become their neighbor (Gunes et al.). Explicit, mutual matches remove that attack vector unless a "suggested matches" feature reintroduces similarity-driven selection. An opt-in match graph is a trust graph of the kind SybilGuard and SybilLimit exploit, where few attack edges bound Sybil reach if propagation respects graph structure (SybilLimit). The risk concentrates in two places. The first is second-degree propagation, where one compromised match becomes an amplifier unless decay caps each first-hop peer's total influence. MeritRank-style decay and Web3Recommend's on-device personalized SALSA are ready templates, though Web3Recommend's Sybil-resistance claim comes from an unreviewed preprint (arXiv 2307.01411). TrustWalker's random walk with item-similarity fallback is a published model of "matches of matches with a stopping probability" (KDD 2009). The DSybil approach, which learns per-source trust from whether a source's past recommendations were good, keeps quality high even against a million-node botnet (DSybil). Each device can apply it to its own matches and subscribed lists. The second risk is public taste lists. FedRecAttack shows that public interactions such as likes and follows give attackers the side information they need to poison recommenders with few malicious clients (arXiv 2204.01499). Narayanan and Shmatikov's result means a public list also de-anonymizes its owner's other activity.
The privacy pipeline needs four specific fixes. First, the Preview step as written describes PSI-cardinality, not PSI. Plain PSI reveals the intersection itself, and repeated cardinality queries with crafted sets leak membership (arXiv 1207.7199), so previews need rate limits and minimum set sizes. (The project's later simulation showed that a minimum set size alone buys nothing; see the Update.) TikTok's PETAce work makes the same point the design does: plain SHA-256 cannot protect low-entropy identifiers (DEV). Second, Circles need output protection on top of input protection: minimum reveal counts, differential-privacy noise on sums, fixed membership per round, and k well above 5. McSherry and Mironov show that DP on aggregate statistics costs little accuracy (MSR). Local DP on per-peer sketches is a poor fit, because LDP "causes a substantial decline in recommendation accuracy" (Northumbria) and k peers give no population to average the noise over. Third, Boutet et al. show that sketches can be deliberately coarsened or obfuscated with little accuracy loss (EPFL), which supports the consent step's "endorsements only" default. Fourth, the transport for Circles should be MLS (RFC 9420), which provides forward secrecy and post-compromise security (RFC 9420). The NIP-44 audit flagged its lack of forward secrecy as a medium-severity issue, NOS-01-006 (Cure53), so a relay that keeps ciphertext plus a later key compromise exposes every past sketch.
States squeeze operators, app stores and swarms, not protocols
The documented pressure on decentralized systems lands on chokepoints that DESIGN.md's table mostly anticipates. In May 2023 the FBI seized an unencrypted database backup from a Kolektiva.social admin's home. The instance had about 7,800 members; the backup held email addresses, hashed passwords, IP addresses of users who had logged in within the three days before it, and posts and direct messages. Users were notified on 30 June 2023 (EFF; CyberInsider). Apple pulled the Nostr client Damus from the China App Store about two days after launch at the Cyberspace Administration's demand (RFA). Russian ISPs began blocking Tor in December 2021, including default bridges (OONI). LBRY lost to the SEC over its token (Skadden). After its founder's 2024 arrest, Telegram changed its policy to disclose IPs and phone numbers on a "valid order from the relevant judicial authorities" (Gulf News). Distributed regulation pushes small operators toward geoblocking. Lemmy.zip blocked UK users rather than comply with the Online Safety Act (rblind), and the DSA treats each fediverse instance as a potential "online platform" (CEPS explainer). The common lesson is that censorship resistance depends on what each server holds, not on how many servers exist. Relays should hold only ciphertext and minimal routing metadata, and the project should avoid a token.
The table needs one correction and three additions. PeerTube P2P delivery is a privacy liability. The tracker stores viewer IPs and forwards them to other peers watching the same video, and PeerTube calls this "the main threat to user privacy" (PeerTube privacy guide). Public swarms and DHTs are routinely monitored: Balduf et al. logged about 2.78×10^10 IPFS data-request entries over 15 months from two monitoring nodes (ICDCS 2022, arXiv 2104.09202). P2P and content addressing make content easy to re-host, but they should be off by default for viewers, and Iroh or Hypercore discovery keys should be secret per group. For relay metadata, the cheapest layer is Oblivious HTTP, which splits IP from request across two non-colluding parties (RFC 9458). Sealed-sender-style hiding alone falls to timing-based statistical disclosure (NDSS 2021). Taste exchange tolerates latency, so batching, padding and mixnets such as Loopix are realistic (USENIX Security '17). Apple's private nearest-neighbor search sends a coarse cluster ID in the clear with an encrypted embedding (Apple ML Research), and that is a reusable pattern for private "find taste-similar lists" lookups. Identity is a pressure point the table omits. Nostr keys have no base-protocol rotation or recovery, and did:plc depends on a single directory that is now a Swiss association (atprotocol.dev; manton.org). Keep identity keys separate from per-match encryption keys, and plan for social recovery. On the legal side, EDPB guidance says decentralised governance is "not a reason not to comply" (EDPB 02/2025 draft); the final version 2.0 was adopted on 7 July 2026 (EDPB v2.0). A developer who runs default relays or indexes therefore takes on controller exposure that a pure client does not.
Reusable open-source building blocks
| Need | Reuse | License / activity | Note |
|---|---|---|---|
| Video catalog | Chocobozzz/PeerTube REST + ActivityPub | AGPL-3.0, active | A plugin is the wrong home for private taste; use a client or extension |
| Cross-instance candidates | Sepia search-index; PeerTube-browser (FAISS + layers) | AGPL-3.0 | Candidate generator; device re-ranks |
| Local profile | solidheron extension | MIT (per README) | Has local cosine profile, lacks sharing |
| Nostr SDK | NDK; nostr-tools | MIT / Unlicense | Signed taste lists, NIP-71 read of all four kinds |
| Encrypted Match/Circle groups | marmot-ts; MDK; OpenMLS | MIT | MLS over Nostr. Least Authority reviewed the protocol (7 Nov 2025; MIPs 00–04, MIP-05 excluded; no threat model; plaintext pubkeys and group tags) and audited whitenoise-rs (final report 1 Apr 2026). MDK in scope unconfirmed; marmot-ts alpha, unaudited (review; whitenoise-rs) |
| Match preview | OpenMined/PSI (PSI-cardinality); microsoft/APSI | Apache-2.0 / MIT | OpenMined PSI README states no audit or security model; WASM bindings unverified |
| Trust for hop 2 / list weighting | Vertex crawler; meritrank-python; GrapeRank | MIT / GPL-2.0 / AGPL-3.0 | Personalized PageRank with decay |
| Creator analytics | divviup/janus; libprio-rs | MPL-2.0 | DAP aggregates, no individual histories |
| DP noise | opendp; google/differential-privacy | MIT / Apache-2.0 | For Circle sums and published stats |
| On-device CF | knn-recommender; disco-node | MIT | Or hand-rolled item-kNN in TS/WASM |
| Shared state / transport | Automerge; iroh; hypercore | MIT / Apache-2.0 | Secret per-group discovery keys |
| Feed interface pattern | bluesky-social/feed-generator | MIT | Copy skeleton+hydrate shape, run it locally |
Repo metadata comes from the ecosyste.ms API, queried 2026-10-19.
Concrete corrections to DESIGN.md
All of these were applied in DESIGN.md revisions 2 and 3 (2026-10-19). Row 5's "minimum set size" was later shown not to be a defense (see the Update).
| # | Location | Current text / issue | Correction |
|---|---|---|---|
| 1 | Problem, ¶1 | "Community efforts so far are client-side" then cites an instance plugin | "Mostly client-side". Note that fairkom [1] specifies no method, so "none use other people's taste" is unknown for [1] |
| 2 | Problem, ¶1 | Omits PeerTube's built-in behavior | Add: the built-in list is ≤5 videos by tag overlap and recency, excluding watched (source) |
| 3 | Problem, ¶1 | "None of them use other people's taste" implies no precedent | Add that decentralized peer CF exists (BuddyCast, PocketLens, Gossple, Jeckmans / Tang & Wang). Scope novelty to the combination |
| 4 | Sources [2] | "PeerTube Picks discussion" | Lemmy announcement posts by one author. Add solidheron repo and PeerTube #6978 |
| 5 | Match step 1 | "PSI … learns the overlap count and nothing else" | This is PSI-cardinality (PSI-CA). Add rate limits and minimum set size, since repeated queries leak membership |
| 6 | Match step 5 | "secure aggregation [7] … can't be attributed to any one person" | SecAgg hides inputs from the aggregator, not the output. Add minimum reveal threshold, DP noise, fixed membership, larger k, and an aggregator/dropout plan. Cite Canny [10] here |
| 7 | Match step 3 / Distribution | "encrypted DMs" | Specify NIP-17 (NIP-44 + NIP-59) for 1:1. Use MLS (Marmot) for Circles: NIP-17 advises against groups >10 and NIP-44 lacks forward secrecy. NIP-04 is deprecated |
| 8 | Privacy facts, [5] | "individual transactions can be inferred from outputs" | Add the conditions: auxiliary knowledge plus temporal changes in outputs. Note that this applies to Circle members watching group picks |
| 9 | Manipulation, [8] | "Bot farms and Sybil accounts are what break open recommenders [8]" | "Without a central identity authority, Sybils can't be ruled out [8]. Recommenders are especially exposed to shilling" + cite Lam & Riedl 2004, Gunes et al. 2014 and DSybil 2009 |
| 10 | Manipulation, [9][10] | "seeded from your own node, in the style of EigenTrust or personalized PageRank [9][10]" | EigenTrust is global with pre-trusted peers. Seeding from self = personalized PageRank. Cite Page et al. §6 and Jeh & Widom 2003, plus MeritRank/TrustWalker; remove [10] |
| 11 | Sources [10] | Canny annotated as precedent but cited for trust | Keep the annotation and move the in-text cite to Circles and the core premise |
| 12 | Pressure table, video host row | "P2P delivery" as mitigation | P2P exposes viewer IPs to tracker and peers ("main threat to user privacy"). Off by default for viewers. "Content addressing" is not a verified PeerTube feature |
| 13 | Pressure table, relays row | "many relays; Tor/mixnet" | Add OHTTP, batching/padding/delays, and secret per-group discovery keys. Note sealed sender alone falls to timing attacks |
| 14 | Pressure table | No identity row | Add: key loss/rotation (Nostr), directory chokepoint (did:plc). Separate identity and per-match keys; social recovery |
| 15 | Distribution, Nostr row | "NIP-71 kind numbers differ … check the spec" | State it: kinds 21/22 (regular) and 34235/34236 (addressable); read all four |
| 16 | Distribution, ATproto row / Sources [4] | docs.bsky.app link; PDS hydration implied | Link redirects to empty page; AppView hydrates. Note permissioned data is proposal 0016. "Feed recipes on-device" borrows the idea; it is not interop |
| 17 | Privacy facts, VPPA | "US law treats it specially" | Accurate but narrow: binds providers, consent ≤2 years revocable, Salazar v. Paramount (No. 25-459) argued 14 Oct 2026, undecided. Add GDPR Art. 9 risk for inferences |
| 18 | Privacy facts | Public taste lists not discussed | Public lists de-anonymize owners and supply poisoning side-info (FedRecAttack). Warn curators; weight lists by track record |
| 19 | Open questions | Creator vs viewer; cold start | Answer: Follow + Subscribe-to-taste + explore slots first (creator discovery, cold start); Match second; Circles last. Add sponsorship-disclosure flags and DAP creator analytics |
Annotated bibliography
| Source | Annotation |
|---|---|
| Calandrino et al., "You Might Also Like," IEEE S&P 2011 (PDF) | Passive inference of transactions from temporal changes in item-to-item outputs plus auxiliary knowledge. Threat model for Circles. |
| Narayanan & Shmatikov, IEEE S&P 2008 (arXiv) | 8 ratings with noisy dates identify 99% of Netflix records. Sketches and public lists are identifiers. |
| Bonawitz et al., CCS 2017, pp. 1175–1191 (CCS PDF; ePrint) | Server-mediated SecAgg at 2^10 to 2^14 users. Protects inputs, not outputs. Server–client collusion needs t ≥ ⌊2n/3⌋+1 and tolerates ⌈n/3⌉−1 colluders. |
| Canny, IEEE S&P 2002 (OpenAlex; author PDF) | HE community aggregate (partial SVD) for CF that can run P2P; honest-majority assumption. Correct precedent for Circles. |
| Douceur, IPTPS 2002 (PDF) | Sybils are unavoidable without a central authority, and vouching chains don't fix it. Not about recommenders. |
| Kamvar et al., EigenTrust, WWW 2003 (PDF) | Global trust anchored on pre-trusted peers; robust in simulation with up to 70% malicious peers. |
| Page, Brin, Motwani & Winograd, PageRank, Stanford TR 1999-66, §6 (1998 draft); Jeh & Widom, WWW 2003 (DOI) | Personalized PageRank: the correct citation for a trust walk seeded from your own node. |
| NIP-71 / NIP-17 / NIP-44 (71; 17; 44) | Four video kinds; gift-wrapped DMs capped near 10 participants; no forward secrecy. |
| AT Protocol feeds guide and feed-generator (guide; README) | Feed generators see the requester's DID, and repos are public. Doesn't fit private Match. |
| PeerTube privacy guide (docs) | P2P exposes viewer IPs; the docs call it the main privacy threat. |
| 18 U.S.C. § 2710 (LII); Salazar v. Paramount Global, No. 25-459 (docket) | VPPA: provider disclosure ban, consent and retention rules. Who is a "consumer" is before the Supreme Court (argued 14 Oct 2026, undecided). |
| Tribler BuddyCast (wiki; SIGMM 2012) | Deployed P2P user-based CF with taste buddies plus random peers. Plaintext; superseded by Dispersy and absent from current Tribler. |
| Tang & Wang, ePrint 2015/364 and 2015/1152 (364; 1152) | Friends + random strangers under HE. The closest academic analogue to Match. |
| Miller et al., PocketLens, TOIS 2004 (UMN) | On-device P2P item CF with no accuracy loss on intermittently connected devices. |
| Bertier et al., Gossple, Middleware 2010 (IFIP) | Bloom-filter profile digests and proxy gossip for taste neighbors. |
| Boutet et al., WhatsUp, IPDPS 2013 (EPFL) and privacy-preserving DCF (EPFL) | Multi-hop amplified dissemination; obfuscated profiles keep utility. |
| Madhwal & Pouwelse, Web3Recommend (arXiv); MeritRank (arXiv) | On-device social recommender with decay-based Sybil tolerance (an MSc thesis on arXiv; its Sybil claim rests on MeritRank's decays, not a theorem of its own). |
| Groh & Ehmig, GROUP 2007 (BibSonomy) | Social filtering beats CF in taste domains. |
| Massa & Avesani, RecSys 2007 (PDF) | Trust propagation restores coverage and helps cold-start users. |
| Jamali & Ester, TrustWalker, KDD 2009 (BibSonomy) | Random walk over trust with item fallback; a template for hop 2. |
| Sinha & Swearingen 2001 (PDF) | Friends are more accurate; systems are more novel. |
| Lam & Riedl, WWW 2004 (DOI); Gunes et al., AI Review 2014 (record) | Shilling attacks on CF (study and survey). Replacement cites for the "Sybils break recommenders" claim. |
| Yu et al., DSybil, S&P 2009 (TR); SybilLimit, S&P 2008 (PDF) | Per-source trust learning for recommenders; trust-graph Sybil bounds. |
| Rong et al., FedRecAttack, ICDE 2022 (arXiv) | Public interactions enable poisoning with few clients. |
| McSherry & Mironov, KDD 2009 (MSR) | DP on aggregates keeps most of the accuracy. |
| "Message in a Sealed Bottle" (arXiv) | PSI and PSI-CA profile matching and their leakage. |
| Fleder & Hosanagar 2009 (UPenn); Celma & Cano 2008 (MTG) | CF concentrates attention; curated and content edges reach the tail. |
| Singh & Joachims, KDD 2018 (arXiv) | Exposure-fairness constraints for creators. |
| Balduf, Sokoto et al., "Bootstrapping Social Networks: Lessons from Bluesky Starter Packs," ICWSM 2025, vol. 19, pp. 178–192, doi:10.1609/icwsm.v19i1.35810 (AAAI; arXiv) | Starter packs drove up to 43% of daily follow operations at peak and 19.95% of follow edges; members got up to 85% more new follows than matched controls by week 4. |
| Aguiar & Waldfogel, NBER w24713 (NBER) | Causal value of playlist placement; payola incentive. |
| YouTube fresh-content papers (2306.01720; Yi et al., Online Matching, RecSys 2023, 2307.15893) | Reserved funnels and bandits for new content; exploration on about 1–2% of traffic at about 0.2% engagement cost. |
| Zhou, Wang & Zhang 2026 (arXiv) | Bluesky feed creators lack data and funding. |
| DAP / Divvi Up (draft; Divvi Up) | Two-server private aggregates for creator analytics. |
| RFC 9420 MLS (RFC); Cure53 NIP-44 audit, Nov–Dec 2023 (PDF) | Group E2E with FS/PCS vs. NIP-44's missing forward secrecy (NOS-01-006, Medium); no signing/encryption key separation (NOS-01-007, Low); 10 findings, none exploitable. |
| Least Authority, Marmot protocol review summary, 7 Nov 2025 (PDF); whitenoise-rs audit, 1 Apr 2026 (post) | MLS over Nostr: no threat model yet; plaintext pubkeys and group tags expose membership and timing to relays. |
| RFC 9458 OHTTP (RFC); Loopix (USENIX); Sealed Sender attacks (NDSS) | Metadata protection options and their limits. |
| Balduf, Henningsen, Florian, Rust & Scheuermann, IPFS monitoring, ICDCS 2022 (arXiv) | Content-addressed networks leak who requests what. |
| Kolektiva seizure (EFF; CyberInsider; BHRRC); Damus removal (RFA); Tor blocking (OONI) | Real chokepoints: operators, app stores, network layer. |
| Spotify Blend (TechCrunch); Plex Discover Together (The Register) | Consumer demand for taste-matching; consent-default failures. |
| Vertex (No BS Bitcoin); spacecowboy For You (atproto blog) | Open-protocol personalized PageRank; central co-like CF. |
Conclusion
The research reframes what is novel and what is risky. The novel part is the consent model: mutual, expiring, user-chosen edges. The CF math is twenty years old, and the cryptography exists in audited libraries. Consent is also the main defense. A mutual match graph inherits Sybil and shilling resistance that similarity-gossip systems like BuddyCast and Gossple never had, and it avoids the default-on disclosure that sank Plex's rollout. The risk has therefore moved outward, to the features that extend reach beyond a chosen peer: second-degree picks, pooled Circles, and public lists. Each of these needs its own guard. Hop 2 needs decaying personalized trust, Circles need output privacy rather than just SecAgg, and lists need sponsorship disclosure and per-list track-record weighting.
The creator-versus-viewer question resolves into sequencing. Match serves viewers who already have peers, while creators are discovered through curated lists and reserved exposure, the two channels with the strongest measured effects. Shipping Follow, Subscribe-to-taste, explore slots and DAP-based creator analytics first gives both sides something useful before any private cryptography ships. The Match layer can then be built on Marmot/MLS and PSI-cardinality without new primitives. Three questions remained open and worth answering by simulation before launch: what share of feed slots to reserve for exploration, how creator-exposure concentration under trust-based ranking compares with global CF (no published study measures this), and how much leakage repeated PSI-cardinality previews allow in practice. The project has since simulated all three; see the Update below.
Update (2026-10-19): what the simulation confirmed or refuted
The project built a simulation harness (sim/) and ran five experiments on synthetic data; full method and numbers are in docs/SIMULATION_RESULTS.md. The data is made up, so the results compare mechanisms against each other under stated assumptions and say nothing about absolute quality or real user behaviour.
Confirmed
- Match is about as accurate as centralized CF and spreads attention more. Match-only CF came within 4% of global user-kNN CF on precision@20 (0.287 vs. 0.297), and adding discounted second degree matched it (0.300). Exposure Gini was 0.67 vs. 0.85, catalog coverage 0.78 vs. 0.49. This is the comparison the report said no published study makes; it is now answered, for a synthetic world only.
- New creators need reserved exposure. With no explore slots, 56% of new creators got no in-feed view from a non-follower within 6 weeks. A 5% share put 66% of them in front of a stranger in their first week and 98% within 4 weeks, at no measurable viewer cost when explore candidates were ranked by on-device relevance (random explore cost about 0.7% precision per point of share). The project set 5% as the default, adjustable 2–10%. That is larger than YouTube's published 1–2%, which runs on a far larger audience; in the small simulated network, 1% still left 6.5% of new creators unseen after 6 weeks.
- Calandrino-style differencing is the main Circle risk. A single release leaked little even at k = 5. Collusion (subtracting one's own input) and membership changes did the damage. DP noise at ε ≤ 2 stopped colluders from reaching 90% confidence; sticky noise alone did not stop differencing (15–22% of a leaving member's endorsements exposed at k = 8–12); an epoch freeze did. Showing noisy counts exposed 49–94% of a member's endorsements whatever ε was, so Circles show picks only.
- A bounded, personalized trust walk confines Sybils. Naive 3-hop path counting let 200 attack edges reach 779 bystanders; a row-normalized walk with decay 0.3, 2 hops and a 0.05 per-node cap reached 0–3, and reach did not grow with the number of Sybils.
- Public lists are an attack surface. Weighting lists by subscriber count let a Sybil-inflated list reach 54% of its lured subscribers under a list-heavy mix; capping each list at 2 items per feed and weighting by track record cut that to 2%.
Refuted or revised
- Minimum set sizes do not protect previews. The catalog is open, so a prober pads any probe with its own never-watched uploads. Rate limits slow the attack but do not bound it: a single exact preview answers "did they watch X?". Floors and buckets fail once the prober knows 4 of the target's items. What bounds it is noise (discrete Laplace, ε = 0.5, floor 5) plus a budget of 8 accepted previews per target per year, counted on the target's device: prober AUC then stays ≤ 0.83 with nothing inferred at ≥ 90% confidence.
- "k well above 5" was right, but for a different reason. k = 5 is bad mainly for utility (recall ≤ 0.48 at t ≥ 3) and under collusion; the project set a hard floor of 8 and a recommended 12–30, with thresholds 3 (k = 8–15) and 4 (k ≥ 16) and ε = 1.
- Lists did not carry new-creator discovery in the simulation; explore slots did. At low weight, lists helped newcomers (cold-start viewers with no matches: precision 0.147 → 0.169) and were neutral for others. A list-heavy mix lost 16% precision and concentrated exposure more. The simulated lists were their owners' popularity-biased histories, so hand-curated lists that favour small creators could do better; this is untested.
- The upper half of the draft 5–15% explore range buys little (83% vs. 90% of new creators found in week 1 at 10% vs. 15%).
- A cost the report did not anticipate: new viewers without matches lose quality. Their precision was 0.169, against 0.202 under centralized CF.
Not simulated: relay metadata, real cryptography, secure-aggregation dropouts, multi-epoch DP accounting for Circles, adaptive Sybils, and real behaviour (how people pick matches, accept previews or curate lists). The resulting parameters now ship as defaults in packages/core.
Companion piece: Censorship Resistance, Metadata Privacy and Distribution Infrastructure for a Decentralized Video + P2P Taste-Sharing App