2.9 KiB, 15 runs
created by r2848102244:157, 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 | //! Where an Ore repository's bytes live, and who is allowed to have written |
| 2 | //! them. |
| 3 | //! |
| 4 | //! The engine, `oxedyne_fe2o3_ore`, does no I/O at all: it is meant to run in a |
| 5 | //! browser as readily as on a server, so it holds the operation vocabulary, the |
| 6 | //! log, the sequence structure and the two byte formats, and opens nothing. This |
| 7 | //! crate is the other half of that bargain -- a directory of ORESEG segments, the |
| 8 | //! lock that keeps two writers off one of them, and the Ed25519 material that |
| 9 | //! says who authored what. |
| 10 | //! |
| 11 | //! It is shared because more than one program needs exactly it and nothing above |
| 12 | //! it. The |
| 13 | //! command line tool wraps a working copy around it; the relay does not, holding |
| 14 | //! a bare repository with no working copy, no key and no verb. Putting the shared |
| 15 | //! part upstream in the engine crate was considered and rejected: the engine's |
| 16 | //! guarantee is that it touches no file, and that guarantee is worth more than |
| 17 | //! the convenience of an upstream home. |
| 18 | //! |
| 19 | //! # It is also where the shared answers live |
| 20 | //! |
| 21 | //! Not only bytes. Two policies were being carried in two places at once -- the |
| 22 | //! names a working copy gives files that clash, and the sentence a flag reads as |
| 23 | //! -- and a policy carried twice is a policy that drifts. Both are here now, in |
| 24 | //! [`tree`] and in [`say`], so that a repository read on a page and the same |
| 25 | //! repository checked out on a disk agree by construction rather than by |
| 26 | //! agreement. Neither module opens a file. |
| 27 | //! |
| 28 | //! # Layout |
| 29 | //! |
| 30 | //! - [`keys`] is the signature scheme, the key file, the self-certifying key |
| 31 | //! binding and what a verified signature is worth. |
| 32 | //! - [`store`] is the segment directory: how it is read into a log, how entries |
| 33 | //! are appended to it, and the lock held while that happens. |
| 34 | //! - [`tree`] is the render seen as a working copy: which file sits at which |
| 35 | //! path, and what happens when two files want one path. |
| 36 | //! - [`say`] is the plain language: what a flag the renderer raised means, in a |
| 37 | //! sentence, once. |
| 38 | //! - [`veil`] is the content key: how a repository is handed to a relay that |
| 39 | //! cannot read it, and what the relay holds in place of what it cannot read. |
| 40 | //! - [`veilkey`] is how that content key reaches a second replica: the X25519 |
| 41 | //! key that receives it, the binding its signing key vouches for, and the wrap |
| 42 | //! itself, which is useless to the relay that carries it. |
| 43 | //! - [`verdict`] is what has already been checked here, so that a signature that |
| 44 | //! verified yesterday is not verified again today. |
| 45 | //! - [`repack`] rewrites the container -- the segments, their sizes and their |
| 46 | //! headers -- while every signature in it goes through untouched. |
| 47 | //! - [`sweep`] reads the whole store the slow way on a schedule, which is where |
| 48 | //! the per-record integrity check went when the commands stopped paying it. |
| 49 | |
| 50 | pub mod keys; |
| 51 | pub mod repack; |
| 52 | pub mod say; |
| 53 | pub mod store; |
| 54 | pub mod sweep; |
| 55 | pub mod tree; |
| 56 | pub mod veil; |
| 57 | pub mod veilkey; |
| 58 | pub mod verdict; |