2.6 KiB, 5 runs
created by r2848102244:145, which is this file's identity for as long as the history lasts, whatever it is later renamed to
download · who wrote it · its history
| 1 | //! A relay: a machine that holds a log and never authors one. |
| 2 | //! |
| 3 | //! The service GitHub actually provides, the one this has to replace, is narrow |
| 4 | //! and load-bearing: two replicas that are never online at the same time still |
| 5 | //! converge, each by talking to one always-on machine, once. Everything here is |
| 6 | //! judged against that and against two standing rules. |
| 7 | //! |
| 8 | //! # Never an authority |
| 9 | //! |
| 10 | //! The relay is a replica without a pen. It holds a log, absorbs what is pushed, |
| 11 | //! serves what is pulled, and authors nothing -- it has no replica identifier, |
| 12 | //! mints no operations and signs nothing into a history. Every property a client |
| 13 | //! relies on is checked at the client against material the relay cannot forge: |
| 14 | //! signatures verify against keys the client knows, arriving batches are closure |
| 15 | //! checked against the client's own log, and key bindings certify themselves. |
| 16 | //! |
| 17 | //! What a malicious relay can do is withhold -- drop a push, serve a stale |
| 18 | //! frontier, show different subsets to different replicas. Each of those is |
| 19 | //! indistinguishable from a partition, is healed by any other sync path, and |
| 20 | //! corrupts nothing. It follows that the relay verifies nothing on the way in: |
| 21 | //! a signature it could check is one the puller must check anyway, and holding a |
| 22 | //! trust set would be the beginning of being an authority. See |
| 23 | //! [`ore_store::store::Verify`]. |
| 24 | //! |
| 25 | //! # Local work never requires the network |
| 26 | //! |
| 27 | //! One verb reaches a relay, and that verb failing changes nothing on disk |
| 28 | //! beyond the capture it performs first, which is local and wanted anyway. |
| 29 | //! |
| 30 | //! # The relay runs the shipped session |
| 31 | //! |
| 32 | //! It does not implement a second protocol. `oxedyne_fe2o3_ore::sync` is |
| 33 | //! peer-symmetric -- there is no client and no server, and no message either side |
| 34 | //! may send that the other may not -- so the relay constructs a `Session` over |
| 35 | //! its own log and answers, exactly as any peer would. A push absorbs, a pull is |
| 36 | //! served, dedup is the log's own behaviour, and a fresh clone is a session |
| 37 | //! opened over an empty local log. |
| 38 | //! |
| 39 | //! # Layout |
| 40 | //! |
| 41 | //! - [`proto`] is the transport both ends speak: the paths, the framing, and the |
| 42 | //! signed request. |
| 43 | //! - [`acl`] is who may read and write one hosted repository, which is a fact |
| 44 | //! about the relay's disk rather than about the history. |
| 45 | //! - [`host`] is the repositories on disk and the key bindings the relay carries. |
| 46 | //! - [`reading`] is the log each of them was last read into, so that a request |
| 47 | //! reads the bytes appended since rather than the history from its first byte. |
| 48 | //! - [`serve`] answers a request, and listens on a socket. |
| 49 | |
| 50 | pub mod acl; |
| 51 | pub mod host; |
| 52 | pub mod proto; |
| 53 | pub mod reading; |
| 54 | pub mod serve; |