The platform

registrar.earth is a federated system for minting, resolving, and managing SF128 cryptographic identifiers. Four domains serve four distinct roles. This page shows what the components are and how they work together.

Four domains, four roles

Four domains serve distinct audiences with distinct purposes. They share the SF128 identifier layer and cross-domain SSO but are otherwise independent.

registrar.earth

The Registrar

The identifier system itself. Mint, resolve, verify, and derive SF128 identifiers. Technical documentation, interactive demos, placement specifications.

fms.sh

The Registry

Consumer-facing lost-and-found service. Owner accounts, physical labels, finder flow, encrypted messaging, token resolution.

  • Owner dashboard & accounts
  • Item registration & labels
  • Finder contact flow
  • Age-encrypted messaging
  • Token resolution & redirect
  • Camera-based scanning

registered-page.com

The Notebook

Physical notebooks with SF128-derived page identifiers. Print-ready PDF generation with Data Matrix barcodes, seals, and checkpoint verification.

  • Notebook generator
  • Client-side PDF with jsPDF
  • SF128 child derivation
  • Dot / lined / ruled / blank
  • Duplex-aware layout
  • Checkpoint anchor pages

livingaudit.com

The Inventory

A living asset inventory. Register everything you own, track item health with breathing pulse animations, and generate SF128 recovery labels.

  • Living dashboard
  • Visual item health & aging
  • Audit pulse scoring
  • SF128 label generation
  • Photo & feature tracking
  • Cross-domain SSO

The SF128 identifier

Every identity in the system is a 128-bit value in the fd53::/16 IPv6 prefix. It encodes provenance, time, and origin into a single globally-routable address.

FD53
RR
SS
PP
HH
Timestamp (48 bit)
Sequence (32 bit)
FD53 — SF128 magic prefix
RR — Region code
SS — Site within region
PP — Purpose code
HH — Host / worker
Timestamp — ms since epoch
Sequence — monotonic counter

Root identifiers are minted by the resolver. Child identifiers are deterministically derived using CRC32 (lineage), FNV-1a 64-bit (proof), and CRC16-CCITT (checksum) — enabling verifiable hierarchies like notebook pages, label batches, and delegation chains without contacting the server.

Root SF128
→
CRC32 lineage
+
FNV-1a proof
+
CRC16 check
=
Child SF128

Interactive tools

Each tool on registrar.earth performs a specific operation on SF128 identifiers. All work client-side with server API fallback.

Mint & Resolve

Create new SF128 root identifiers and resolve existing ones. Step-by-step walkthrough of the full lifecycle.

/do

Verify

Parse any SF128 value — hex, IPv6, token, or short code — and inspect its internal structure, validity, and resolution status.

/verify

Derive

Generate deterministic child identifiers from any root. Verify the derivation chain: lineage, proof, and checksum.

/derive

Marking Formatter

Configure identifier placement for physical objects. Generates printable marking specifications based on placement guidelines.

/format

Placement Guidelines

Reference document synthesising ISO/IEC 15459, GS1, CE marking, and VIN regulations into category-specific guidance.

/placement-guidelines

Resolve

Direct resolution interface. Enter any SF128 token or short code and retrieve its metadata, route targets, and lifecycle events.

/resolve/

Architecture

The system is layered: identifiers at the bottom, services in the middle, products on top.

Products
User-facing sites
registrar.earth Identifier tools
fms.sh Lost & found registry
registered-page.com Notebook generator
livingaudit.com Asset inventory
Services
Backend processes
Resolver Mint, resolve, events
:8080
Backend Accounts, items, labels
:3000
Consort Distributed file storage
:9400
Msg Encrypted messaging
Iroh QUIC
Edge
TLS & routing
HAProxy TLS termination, rate limiting, geo routing
→
Caddy Static files, API proxy, clean URLs, precompression
Data
Persistence
PostgreSQL 18 Append-only events, accounts, objects
SeaweedFS Object/blob storage
Iroh P2P Cross-region replication
Network
Mesh fabric
WireGuard Encrypted tunnels between all nodes
BIRD BGP Route advertisement, private ASNs
PowerDNS Authoritative DNS on ns-01/ns-02.rns.sh

Services

Four backend services run on each node. All are Rust/Axum binaries communicating over the WireGuard mesh.

Resolver
The SF128 resolution engine. Append-only event sourcing for identifier lifecycle events. Handles minting (POST /mint), resolution (GET /resolve/{id}), metadata events, and host registration. Single-writer primary with read replicas on every node.
Backend
The FMS application server. Owner accounts (WebAuthn, OAuth2), item registration, label management, billing, finder flow, admin operations, and bulk imports. Serves /api/* on fms.sh. Geo-routed: US traffic to US backend, EU traffic to EU backend.
Consort
Distributed object storage. BLAKE3 content-addressed deduplication, SeaweedFS as the volume backend, Iroh QUIC for cross-region replication. Objects are stored locally and asynchronously replicated to peer nodes. Tracks replication state in PostgreSQL.
Msg
Encrypted messaging relay. Store-and-forward architecture over Iroh QUIC. Messages are age-encrypted end-to-end — the relay sees only ciphertext. Powers the finder ↔ owner conversation flow on fms.sh.

The mesh

Seven nodes across two regions, connected by WireGuard tunnels carrying three overlay planes.

us-01
Replica
us-02
Primary writer
us-03
Replica
eu-01
EU edge + replica
eu-02
EU edge + primary
eu-03
EU edge + replica
edge-us
HAProxy TLS edge

Overlay planes

Each WireGuard tunnel carries three /48 IPv6 prefixes. Traffic is separated by function so that resolver queries, database replication, and blob storage never contend on the same path.

PlanePrefixPurposeServices
Application fd53:RRSS:1000::/48 Service-to-service API calls Resolver, Backend, Caddy, HAProxy
Database fd53:RRSS:1100::/48 PostgreSQL replication and queries pg_auto_failover, streaming replication
Storage fd53:RRSS:1200::/48 Object/blob storage traffic SeaweedFS master + volumes, Consort

RRSS = region + site hex codes. Each node has a unique ASN for BIRD BGP route advertisement. Routes are installed via WireGuard PostUp and advertised as static /48s.

How resolution works

When someone scans a label, enters a token, or queries the API, this is the path their request takes.

Scan / Enter Token
→
HAProxy edge
→
Caddy
→
Resolver
Resolver
→
PostgreSQL lookup
→
Route targets + metadata
→
Response

Reads are served by the local node's resolver — every node has a read replica. No cross-region hop needed.

Writes (minting, events) are forwarded to the single-writer primary on us-02 via the application plane.

Token patterns (e.g. XXXXX-XXXXX, XXXX-XXXX-XXXX-XXXX) are matched at the Caddy layer and rewritten to the resolve UI with the token as a query parameter.

Data model

The resolver uses append-only event sourcing. Identifiers are immutable once minted; all changes are recorded as lifecycle events.

sf_objects
The identity registry. Each row is a minted SF128 with its hex value, canonical IPv6, creation timestamp, and origin (region/site/host). Immutable.
route_targets
Where an identifier resolves to. Maps an SF128 to one or more target URLs, types, and priorities. Updated via events.
lifecycle_events
Append-only audit log. Every state change — registration, transfer, dispute, metadata update — is a timestamped event with actor, type, and payload.
consort_objects
Content-addressed file store. BLAKE3 hash, size, SeaweedFS volume reference, owner, replication count. Deduplication is automatic.

Two fully independent PostgreSQL clusters: US (3 nodes, pg_auto_failover) and EU (3 nodes). No cross-region data sharing at the database level — Iroh handles replication for objects that need it.

Resolver API

The resolver exposes a simple HTTP API. All endpoints are available on every node.

POST /mint
Mint a new SF128 root identifier. Accepts {"rr","ss","pp","hh"}. Returns the minted identifier in hex, IPv6, and display token formats. Write — forwarded to primary.
GET /resolve/{id}
Resolve an identifier by hex, IPv6, or short code. Returns metadata, route targets, and lifecycle events. Read — served locally.
POST /event
Append a lifecycle event to an identifier. Supports registration, transfer, metadata updates, and custom event types. Write.
GET /health
Resolver health check. Returns node identity (RR/SS/HH), region, uptime, and database connectivity status. Read.
GET /site/{rr}{ss}
Site-level metadata for a region/site pair. Read.
GET /geo/{rr}
Region-level metadata. Lists sites, node counts, and replication status for a given region code. Read.

Security model

Transit
All inter-node traffic travels over WireGuard (Curve25519, ChaCha20-Poly1305). Public traffic is TLS 1.2+ at the HAProxy edge. Internal Caddy serves plain HTTP on the encrypted mesh — no double encryption overhead.
Messaging
End-to-end age encryption (X25519). The relay infrastructure sees only ciphertext. Key exchange happens client-side. No plaintext message ever touches the server.
Authentication
Owner accounts use WebAuthn (passkeys) as primary factor, with OAuth2 (Google, Apple) as recovery. No passwords stored. Session tokens are httpOnly, SameSite=Strict.
Identifiers
SF128 values are not secret — they are designed to be printed on physical objects. Privacy comes from the resolution layer: only the owner controls what an identifier resolves to.
Edge
HAProxy rate limiting (stick-table, 500k IPs), attack-path tarpitting (/wp-admin, /.env, /.git), and request-rate triggers. Common scanner traffic is absorbed before reaching application logic.