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 (2444B)


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