6.4 KiB

Raw Permalink Blame History

📦 nexus Package Formats and Their Purposes

Let’s clearly and strategically structure the packaging and distribution strategy for NexusOS and the Nexus ecosystem, focusing on a clear, robust, modern, and future-proof format separation.

🎯 Goals

Clear naming & extension conventions
Future-proof design (quantum-resilient hashing, etc.)
Fast, efficient compression & decompression
Logical separation of package concerns

📦 Package Formats and Their Purposes

NexusOS will employ a clear, distinct separation between different packaging artifacts:

Artifact Type	File Extension	Content & Usage	Compression	Integrity
Source Recipes (Fragments, purely declarative)	`.npr` (Nexus Package Recipe)	KDL metadata describing build instructions; minimal logs; no binaries.	None (plain text)	Signed metadata (Ed25519)
Compiled Binary Packages (ready-to-install)	`.npk.zst` (Nexus Package, Zstandard)	Tar archives compressed with zstd containing binaries, manifests, metadata (KDL), build logs.	`zstd --fast`	BLAKE3, Ed25519 signatures
CAS Archive Chunks (Merkle Tree storage)	`.nca` (Nexus Content-Addressable)	Binary blobs stored in CAS with Merkle Trees; content-addressable only.	Optional zstd	BLAKE3 Merkle Tree hashes
System Snapshots (environment reproducibility)	`.nss.zst` (Nexus System Snapshot)	Full reproducible environment snapshots (lockfile, package manifests, build logs, KDL metadata)	`zstd --fast`	BLAKE3, Ed25519 signatures
Overlay Fragments (system modifications for immutable OS)	`.nof` (Nexus Overlay Fragment)	Declarative overlay configurations in KDL	None (plain text)	Signed metadata (Ed25519)

🧠 Reasoning & Justification

Why `.npk.zst` explicitly?

Aligns clearly with Arch Linux conventions, explicitly indicating Zstandard compression.
Immediately recognizable to sysadmins familiar with modern Linux distributions.
Avoids ambiguity and clearly communicates the compression method at a glance.

Example:

neofetch-7.1.0.npk.zst

Why `.npr` (recipe format)?

Clearly distinguishes source-level recipes (KDL) from binary packages.
Explicitly uncompressed for easy human readability, version control (Git-friendly).

Example:

neofetch-7.1.0.npr

Why `.nca` (CAS archives)?

Clearly indicates the file is part of NexusOS’s content-addressable storage.
Binary blobs optimized for high deduplication rates and rapid verification.

Why `.nss.zst` (system snapshots)?

Identifies clearly as a snapshot artifact for reproducible environments.
Explicit Zstandard compression for storage efficiency and decompression speed.

Why `.nof` (Overlay fragments)?

Short, clear, distinctive naming.
Explicitly uncompressed, easily readable and editable in immutable configuration management workflows.

🔐 Future-Proofing & Quantum-Resilience

To ensure long-term future-proofing (quantum-resistant hashing/signatures):

Short Term (now → 2026):
- Standardize BLAKE3 hashing for all integrity checks (currently strongest practical hash).
- Ed25519 for digital signatures (fast, secure, widely used).
Medium Term (2026+ → quantum era):
- Prepare a transparent upgrade path to quantum-resistant algorithms like Dilithium (post-quantum signatures) or similar NIST PQC standards.
- Package format includes a “version field” in KDL metadata, explicitly stating cryptographic algorithms used for hashing and signing, allowing graceful transitions without format breaks.

Example metadata snippet (future-proof):

package "neofetch" {
  version "7.1.0"
  
  integrity {
    hash "blake3-abcdef1234567890..."
    signature "ed25519-abcdef1234567890..."
    algorithm "BLAKE3"
    signingAlgorithm "Ed25519"
  }
}

When transitioning:

integrity {
  hash "sha3-512-abcdef1234567890..."
  signature "dilithium-abcdef1234567890..."
  algorithm "SHA3-512"
  signingAlgorithm "Dilithium"
}

This approach ensures clarity, auditability, and forward compatibility.

📌 Final Recommended Structure

A clearly summarized and recommended standard moving forward:

Type	Extension	Compression	Integrity	Quantum-Ready
Package Recipes	`.npr`	None	Signed metadata (Ed25519)	✅ Yes (metadata upgradable)
Binary Packages	`.npk.zst`	zstd (fast)	BLAKE3, Ed25519	✅ Yes (algorithm metadata)
CAS Archive Chunks	`.nca`	Optional zstd	BLAKE3 Merkle Trees	✅ Yes (algorithm metadata)
System Snapshots	`.nss.zst`	zstd (fast)	BLAKE3, Ed25519	✅ Yes (algorithm metadata)
Overlay Fragments	`.nof`	None	Signed metadata (Ed25519)	✅ Yes (metadata upgradable)

🚩 Next Steps (Practical Implementation)

Implement .npk.zst explicitly:
- Ensure createNpkArchive and loadNpkArchive use .npk.zst.
- Update all documentation, tooling, and repository conventions accordingly.
Formalize .npr, .nof, .nss.zst, and .nca formats:
- Define clear schemas and metadata templates for each type.
Metadata quantum-resilience:
- Begin adding explicit cryptographic algorithm metadata now.
- Prepare and document clear procedures for algorithm migration.
Documentation & Examples:
- Thoroughly document all formats, purposes, and conventions in docs/package_formats.md.
Testing & Validation:
- Comprehensive unit and integration tests validating correctness, speed, compression ratio, and integrity for each format.

6.4 KiB Raw Permalink Blame History Unescape Escape