atlas-keygen

Summary

atlas-keygen is a very small operational CLI for inspecting libp2p node keypair files. Today it is effectively an extraction tool, not a full key-management suite.

The package has no library target and no runtime integration with the rest of the application layer. It exists as a standalone helper binary for operators working with node identity files.

Why This Crate Exists

• inspect an existing libp2p keypair file on disk
• print the public-key material in human-usable formats
• derive the peer id from the stored keypair
• provide a future home for keypair generation

Current Role In The Workspace

atlas-keygen currently owns just two concerns:

1. parse CLI arguments for key-inspection operations
2. decode a protobuf-encoded libp2p Ed25519 keypair and print derived identifiers

This is one of the narrowest crates in the workspace.

Public Surface

Package Targets

• binary target atlas-keygen
• no library target

Internal Modules

• cli
• operations

CLI Commands

• extract <FILE>
• generate [--out <OUT>]

Key Modules

• `main.rs`: parses the CLI and dispatches to the requested operation
• `cli.rs`: clap command model for extract and generate
• `operations.rs`: file decoding, Ed25519 extraction, peer-id derivation, and the current generate stub

Inputs And Outputs

Inputs

• a filesystem path to a protobuf-encoded libp2p keypair
• optionally an output path for future key generation

Outputs

• a base58-encoded public-key string printed as Address
• the same public key printed as hex
• the derived libp2p PeerId
• the peer id bytes printed as hex

Internal Dependencies

Workspace Dependencies

• atlas-common

atlas-common is only used here for the shared AtlasError and Result types.

External Dependencies That Shape The Design

• libp2p for protobuf keypair decoding and peer-id derivation
• clap for CLI parsing
• bs58 and hex for output formatting

Used By

No Rust crate depends on atlas-keygen, and no startup script currently shells out to it.

This is an operator-facing tool intended for manual use.

Command Model

`extract`

extract_key_info(...) in `operations.rs`:

1. reads the keypair file from disk
2. decodes the libp2p protobuf payload
3. requires that the keypair is Ed25519
4. prints four values:

• public key in base58
• public key in hex
• peer id
• peer id in hex

This is the only fully implemented command today.

`generate`

generate_keypair(...) is currently a placeholder that just prints a message saying generation is not implemented yet.

That means the crate name is slightly ahead of the implementation: it can inspect keys, but it does not actually generate or persist them yet.

Testing

The crate includes focused unit coverage for:

• CLI parsing
• missing-file behavior
• invalid-key-file handling
• valid Ed25519 protobuf decoding
• the current no-op stability of generate

For such a small binary, that is enough to describe the real behavior confidently.

Risks Or Design Tension

The Main Feature Is Still Missing

The generate subcommand exists in the CLI surface, but it does not create or save anything yet. So the package is more accurately a key-inspection tool than a key-generation tool.

Output Naming Is Slightly Ambiguous

The extract command prints a base58-encoded public key as Address, but that value is not an Atlas account address like nbex.... It is closer to a libp2p identity string.

Ed25519-Only Scope

The tool explicitly requires an Ed25519 libp2p keypair. That matches current node expectations, but it keeps the crate narrowly tied to the present networking identity model.