soft3/hemera/docs/explanation.md

why Hemera works the way it does

design decisions behind the Hemera hash primitive.

philosophy

why-hemera — eight design principles: permanence, the tree, endofunction, self-reference, identity, unity, beauty, the name

the-name — etymology: Hemera in the Protogenoi, genealogy of hash names

parameters

parameters — rationale for every parameter (field, S-box, width, rounds, computational elegance)

chunk-size — why 4 KB chunks (10-point analysis)

architecture

sponge-only — why no compression mode (practical, economic, mathematical)

capacity — structured capacity: one function, unlimited contexts, cost analysis

content-ids — why raw 64-byte CIDs, no headers, endofunction closure

self-bootstrap — why self-bootstrapping, non-circularity argument

analysis

security — security margins, quantum resistance, ecosystem comparison

performance — hash rate, proving cost, steady-state adequacy

operations

migration — emergency protocols, no algorithm agility, storage proofs

Folder

Homonyms

trident/docs/explanation
💡 Trident Explanation [← Documentation Index](/trident/docs/readme) Understanding-oriented. Deep dives into why Trident works the way it does, for readers who want the full picture. 🏗️ Core Architecture | Document | Description | |----------|-------------| |…
cyb/honeycrisp/unimem/docs/explanation
unimem: How and Why The problem in one picture Every inference framework on macOS does this: Four buffers. Three copies. Each copy burns ~5 GB/s of memory bandwidth and adds latency. On a machine with 200 GB/s total bandwidth, three copies of a 7B model's weights eat 15% of available bandwidth…
cyb/honeycrisp/rane/docs/explanation
explanation

Graph