Operational surfaces

BetterSign™

BetterSign is useful anywhere credentials, public keys, protected metadata, or trust policy need to change without manual redistribution.

Stable identity

A VLAD remains stable while its keys and protected metadata rotate.

Self-verifying history

Every state transition is hash-linked and authorized by the previous log state.

Decentralized discovery

VLADemlia helps peers locate current records without becoming the trust root.

Routine rotation

Key changes become signed updates that followers can verify and apply.

Operational surfaces

Use Cases

Detailed Use Case Pages

The detailed operational pages are grouped here: VLAD-SSH, WireGuard VPN, VLAD-CA and TLS, Plog Watchers, AI Agents, and Blockchain Validators.

Each page remains a standalone route with its own table of contents, but the navigation treats them as the Use Cases section of the site.

Use Case Families

BetterSign uses the same VLAD and plog model across different operational surfaces.

VLAD-SSH
stable SSH user and host identity with verified key distribution
WireGuard VPN
peer identity and PQ or hybrid PSK rotation
VLAD-CA and TLS
short-lived service credentials and CA state from verified plogs
Plog Watchers
local reactions to verified provenance-log changes
AI Agents
agent capabilities, signed work, and auditable rotation history
Blockchain Validators
rotatable validator identity with on-chain, voted config

SSH Access

A server can follow a user’s VLAD and update OpenSSH authorized_keys or use VLAD-SSH policy directly when the user rotates keys.

The stable identity is the VLAD. The accepted login keys are current state derived from the verified plog.

TLS and Service Identity

Services can publish signing keys, encryption keys, certificates, or CA material under plog paths that other systems follow.

Automation can update local TLS assets after a verified plog change instead of relying on a central service as the root of trust.

Secure Messaging

BetterSign messages use the recipient’s current public key from their plog and include sender authentication tied back to a VLAD identity.

This allows encrypted peer-to-peer communication where key changes are discovered through the same provenance mechanism.

Monitoring and Audit

Followers can watch specific plog paths and react when protected state changes. Audit rules can describe expected local state and detect drift.

Monitoring events can be published to a file, a database, or a Web API so teams can feed existing audit, alerting, and operations workflows.

Every accepted update is linked to previous state and remains replayable by peers that have the log.