Jack Grigg

Here is how I think I'd like the dependency graph to look after #738 (removing a few of the direct dependencies that can be represented via transitive paths for clarity):...

Some more thinking about this, and how a single `components` repo might not be quite the split we want: https://github.com/zcash/librustzcash/pull/995#issuecomment-1737507355. This comment lines up somewhat nicely with thje diagram in...

So maybe this is the split to go for: ```mermaid graph TD subgraph standalone_components nEqH[equihash] nF4J[f4jumble] end subgraph protocol_components nZEnc[zcash_encoding] nZNE[zcash_note_encryption] end subgraph protocols sapling[sapling-crypto] orchard[orchard] end subgraph main nZAddr[zcash_address]...

Consider also that `zcash_proofs` is basically just the Sprout and Sapling circuits, extracted so that people could depend on `zcash_primitives` without depending on the circuit code. However, the use cases...

In #1041 we moved `zcash_note_encryption` into its own crate, so I think the pattern going forward is likely to be that for protocol components we just create standalone repositories.

@daira thinks we might have fixed this; we should check.

Closing per above.

We did get this right when generating the randomness for `T` [here](https://github.com/zcash-hackworks/sapling-crypto/blob/master/src/redjubjub.rs#L80-L83). If the justification is the same, then we should refactor this so both sources use the same function...

@teh-f00l absolutely! I look forward to seeing your PR :grinning: Feel free to comment here or chat to us in Rocket.Chat if you have any questions.