bolt4

Onion routing protocol, per BOLT #4 (docs.ppad.tech/bolt4).
git clone git://git.ppad.tech/bolt4.git
Log | Files | Refs | README | LICENSE

AGENTS.md (2600B)

      1 # ppad-bolt4
      2 
      3 A pure Haskell implementation of BOLT #4 (onion routing) from the
      4 Lightning Network specification, as of lightning/bolts@1aadb719 (copy
      5 in `etc/04-onion-routing.md`).
      6 
      7 The implementation consists of the ppad-bolt4 library (public API:
      8 Lightning.Protocol.BOLT4; the submodules are internal), a test suite
      9 (public API only), and benchmarks (for time and space).
     10 
     11 ## build
     12 
     13 Builds are handled via Nix and Cabal. Enter a development shell via:
     14 
     15     $ nix develop
     16 
     17 and then do Cabal stuff:
     18 
     19     $ cabal build
     20     $ cabal test
     21     $ cabal bench
     22 
     23 ## deps
     24 
     25 The following dependencies are allowed freely:
     26 
     27 * Any GHC boot library or library included with GHC's normal
     28   distribution (e.g. bytestring, primitive, etc.).
     29 * Any 'ppad-' library, as found on github.com/ppad-tech or
     30   git.ppad.tech.
     31 
     32 Any other library requires explicit confirmation before being used.
     33 
     34 Test and benchmark dependencies (e.g. tasty, criterion, QuickCheck,
     35 etc.) are an exception.
     36 
     37 Never use Stack or any non-Nix build or dependency management
     38 tool. Never use 'pip install' or 'npm install' or anything of the
     39 sort. The Nix development environment includes everything one
     40 needs.
     41 
     42 ## style
     43 
     44 Please adhere to the following guidelines:
     45 
     46 * Keep lines at less than 80 characters in length.
     47 * The codebase is Haskell2010.
     48 * LANGUAGE pragmas should be added per-module.
     49 * Haddock documentation where appropriate; use `{-# OPTIONS_HADDOCK
     50   prune #-}` and `-- |`-style comments for public modules.
     51 * Prefer total functions; avoid partial Prelude functions such
     52   as 'head', 'tail', '!!', etc.
     53 * Use strict annotations (bang patterns, etc.) liberally. Add
     54   UNPACK pragmas in data types.
     55 * Use newtypes for type safety.
     56 * Use smart constructors for validation.
     57 * Use Maybe/Either for fallible operations.
     58 * Use MagicHash/UnboxedTuples for hot paths.
     59 * Add INLINE pragmas for small functions.
     60 
     61 ## git
     62 
     63 * Never update the git config.
     64 * Never use destructive git commands (such as push --force, hard reset,
     65   etc.) unless explicitly requested.
     66 * Never skip hooks unless explicitly requested.
     67 * The main branch is `master`, which mostly consists of merge commits.
     68   Feature branches are branched from and merged (with `--no-ff`) back
     69   to master.
     70 
     71 ## misc
     72 
     73 * Be very cautious when suggesting changes to the flake.nix file. You
     74   should fully understand the effect of any change before making it.
     75 * Don't create markdown files, e.g. for documentation purposes.
     76 * When producing plans, highlight any steps that could potentially be
     77   executed by concurrent subagents. Place plans in the `plans/`
     78   directory, e.g. as `plans/IMPL1.md`.