Skip to content

Accept hexadecimal key format (hex) in addition to npub/nsec #57

@mostronatorcoder

Description

@mostronatorcoder

Problem

Currently Mostrix only accepts bech32-encoded Nostr keys:

  • Add Solver (Settings) → only accepts npub1... format
  • Setup Admin Key → only accepts nsec1... format

However, operators often have hex-encoded keys from:

  • rana output
  • Mostro config files (config.toml, config.sample.toml)
  • Raw Nostr tooling

Having to manually convert hex → bech32 to use Mostrix adds friction and causes errors.

Proposal

Accept both formats in all key input fields:

  • npub1... (bech32) — current behavior
  • nsec1... (bech32) — current behavior
  • 64-char hex string — new

Scope

Two main input paths:

  1. Add Solver (AdminMode::AddSolver)

    • Input: solver public key (hex or npub)
    • Validation: validate_npub() → try PublicKey::from_bech32(), fall back to PublicKey::from_hex()
    • Wire format: normalize to npub before sending AdminAddSolver to Mostro (so the node always receives bech32)
  2. Setup Admin Key (AdminMode::SetupAdminKey)

    • Input: admin private key (hex or nsec)
    • Validation: validate_nsec() → try SecretKey::from_bech32(), fall back to SecretKey::from_str() (or equivalent hex parser)

UX

  • Update placeholders in the input popup:
    • Add Solver: "npub... / hex..."
    • Setup Admin Key: "nsec... / hex..."
  • Error messages should guide users: "expected npub1... (bech32) or 64-char hex string"

Context

This complements Mostro node's solver permission levels (PR #708), making it easier for operators to register AI agents (read-only) and human solvers (read-write) through Mostrix.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions