Secp256k1
An Elixir NIF library around Bitcoin Core's libsecp256k1, the small but
extremely important C library behind much of the cryptography used in Bitcoin, Ethereum,
Nostr, and related systems. The curve itself is a narrow domain, but it sits under
signatures, public keys, key agreement, Taproot-style Schnorr signatures, and many
identity schemes in decentralized software.
The library exposes the upstream C implementation from Elixir and keeps the API close to
the underlying cryptographic operations. It covers key generation, ECDSA, BIP-340 Schnorr
signatures, ECDH, serialization formats, and experimental MuSig2 support. I built it
because I wanted to work with Nostr in Elixir, and the available native crypto libraries
did not expose everything I needed. It later became a way to understand the technical
details behind multisig, Taproot, and related Bitcoin primitives.
Elixir Astro
A domain-specific Elixir library bringing professional astronomy tooling into the BEAM. It
wraps
NASA's SPICE (CSPICE)
toolkit from NAIF and the
ERFA (Essential Routines for Fundamental Astronomy)
to expose celestial computation functions directly within Elixir.
I originally built it because I wanted to work with
Barycentric Coordinate Time
in Elixir, and there was no library that exposed the time functions I needed. The broader
SPICE-backed geometry functions grew from a more speculative idea: one day I would like
to build a Solar System map that can be used to plan travel across it, in the spirit of
The Expanse. And because I am that kind of nerd.
SpaceBoy
Implements the Gemini
protocol inside Elixir. Gemini sits somewhere between Gopher and the modern web: simple
request/response semantics, mandatory TLS, a small text-first document format, and a
strong bias against the complexity of JavaScript-heavy, tracking-heavy pages.
SpaceBoy is my attempt to treat that small-web idea as a real application framework. It
brings Phoenix-like ergonomics to Gemini: routing, TLS communication, middleware, static
files, common response helpers, templates, telemetry, and client-certificate-oriented
session ideas. Philosophically, it is about seeing how much useful internet software can
be built when the protocol starts from restraint rather than maximal extensibility.
Reticulum
Elixir implementation of the
Reticulum protocol
,
a cryptography-based networking stack designed for local and wide-area networks that may
need to survive low bandwidth, high latency, intermittent links, or unusual transport
media. Reticulum is interesting because it treats identity, routing, encryption, and
delivery proofs as first-class concerns rather than bolt-ons.
My implementation currently covers the core roadmap through a runtime shell, UDP
transport, announce/path discovery, messaging APIs, and proof/receipt handling. I got
interested in Reticulum while thinking about decentralized communication that does not
depend on any one network. The version in my head has to tolerate ad-hoc infrastructure,
long delays, and strange routes: minutes of light-speed delay across the Solar System, or
bouncing a signal through a ship in orbit to reach the far side of Titan. Reticulum is not
built exactly for that, but it is the closest practical system I have found, so I wanted
to study it first by re-implementing it.
Noise Protocol
An Elixir implementation of the
Noise Protocol Framework
,
a compact framework for building authenticated encrypted channels from named handshake
patterns. Noise is not a single protocol so much as a careful language for describing how
peers exchange static and ephemeral keys, derive shared secrets, and then transition into
encrypted transport.
The implementation supports standard handshake patterns and multiple primitive families,
including AES-GCM, ChaChaPoly, X25519, X448, secp256k1, SHA-2, and BLAKE2 variants. This
project is one of the clearest examples of the kind of work I enjoy: translating a precise
security specification into executable state machines, where the interesting part is not
just making bytes move, but preserving the invariants the protocol depends on.
Nostr ecosystem
Nostr Lib
Low-level Nostr protocol library for events, tags, signing, parsing, encoding, and NIP
helpers. Nostr's core idea is intentionally small: signed events identified by public
keys, distributed through relays, with interoperability growing through NIPs. This
library is the foundation layer that keeps those primitives explicit and reusable for
clients, relays, auth flows, and experiments.
Nostr Client
OTP WebSocket client for talking to Nostr relays. It handles the operational side of
the protocol: opening relay connections, publishing events, sending subscriptions,
applying filters, receiving relay messages, and surfacing events back to Elixir
processes. The point is to make Nostr feel native on the BEAM, where long-lived
connections and supervised processes are already natural building blocks.
Nostr Relay
Nostr relay implementation in Elixir with an HTTP/WebSocket entrypoint and persistent
storage. Relays are the pressure point of Nostr: they are deliberately simple, but
they carry the practical work of accepting events, serving subscriptions, enforcing
local policy, and staying fast enough to be useful. Building one is a good way to
understand what decentralization looks like when it becomes running infrastructure.