Skip to main content
Chapter 8

The Federation

DAP, Daphne, and why your private data never needs to leave your lab

“Centralized learns from you because it takes your data. Federated learns with you without taking it. This is not a technical detail. It is a shift in power.”

Narrative

The problem we are trying to avoid

Every “cloud” scientific platform works on the same model. Your data travels to the central server. The operator processes it. Any trained models belong to the operator. Your data remains—often perpetually, sometimes resold—in someone else’s database.

For public scientific data (UniProt, AlphaFold, PDB), there are no stakes. They are already public by definition. For internal screening data from an academic or biotech lab, it is a major problem. Unpublished bioactivity datasets are the bargaining chip of scientific collaborations. Exposing them in plaintext on a foreign cloud is often legally prohibited (patient cells, intellectual property of an ongoing thesis, industrial agreements).

The practical consequence: the most interesting labs are also the ones that cannot contribute to a centralized platform. Bactaegion would then be limited to what is already published—meaning what no longer has competitive value. It would miss precisely the high scientific value contributions.

Federated learning completely reverses this mechanic.

How it works, in broad strokes

In classical centralized learning:

  1. The lab sends its data to the central server.
  2. The server trains a model on this data.
  3. The trained model is usable.

In federated learning (FL):

  1. The lab receives the current model from the server.
  2. The lab locally trains the model on its private data—which never leaves its network.
  3. The lab sends back to the server only the model’s weight updates (the gradients), not the data.
  4. The server aggregates the updates from all labs and produces a new current model.
  5. We start again.

The data stays in each lab. The global model learns from all the data without any of it ever being transmitted.

The natural question is: do weight updates indirectly leak data? The answer, since 2017, is mathematically precise. Yes, a little, but we can quantify and bound this leak. This is the contribution of differential privacy.

Differential Privacy and the DAP spec

Differential privacy adds calibrated random noise to weight updates before they leave the lab. The noise is scaled to mathematically guarantee that an observer, even a malicious one, cannot infer whether a given patient/sample was in the training dataset.

In 2023-2024, the IETF standardized the DAP (Distributed Aggregation Protocol). It formalizes this mechanic for real use cases (typically anonymous browser statistics). Mozilla, Google, Cloudflare, and the ISRG (Let’s Encrypt) deployed public aggregators operable without depending on a single company.

The reference implementation on Cloudflare’s side is called Daphne—a DAP server in Rust. It was designed to scale (millions of contributors) without exorbitant marginal costs.

For Bactaegion, this means: if we ever have 50+ contributing labs, we can train an embedding model on their private screening datasets without any of them revealing their molecules.

Why Phase 4 and not earlier

Three reasons why Bactaegion does not activate FL in V1.

First, we do not yet have 50 contributors. An FL with 3 nodes is statistically unrepresentative. It provides almost illusory privacy (the operator can often infer who contributed which update). DAP is designed for hundreds to thousands of contributors.

Second, the aggregation server has a non-zero operational cost. Daphne runs on Cloudflare Workers + R2. However, the pace of aggregations + gradient storage + threshold verification consumes resources. As long as we lack volume, this cost is unjustified.

Third, embedding models relevant for bacterial defenses are rapidly evolving (2024-2026: ESM2, ESM3, ProteinMPNN, RFdiffusion). Adopting a federated architecture too early would lock us into a model family already obsolete in 18 months.

The wait is therefore deliberate, not a lack of ambition.

What is delivered today

V1 delivers a compatible architectural foundation. Everything visitor-related remains local (IndexedDB). Everything public (UniProt, AlphaFold, PDB) is fetched live without duplication. No sensitive data is ever transmitted to Bactaegion in V1—not even BYOK keys, not even passphrases, not even review verdicts.

This same doctrine will enable FL in Phase 4. We have nothing to remove. Private data never entered. It can simply start participating in training when the day comes, without a painful migration.

This doctrinal continuity distinguishes Bactaegion from platforms trying to retrofit privacy after the fact.

The Federation Hub page

The /federation/ page explains the current state. No federation is active yet. The technical conditions are set. The Phase 4 schedule will depend on contributor volume throughout 2026-2027. We also publish the scientific references there:

  • IETF DAP draft v07 (April 2024)
  • ISRG Prio3 reference implementation
  • Daphne (Cloudflare, MIT)
  • Apple-Google COVID exposure notification (first large-scale deployment of FL in public health, 2020)
  • FedScale benchmark (2022)

It is a long-term public commitment. If you work on FL in biology and want to contribute to the Phase 4 Bactaegion architecture, now is the time to join the conversation.

To go further

All chapters Annotate a protein now Read the leads