Skip to content

Latest commit

 

History

History
146 lines (109 loc) · 5.7 KB

File metadata and controls

146 lines (109 loc) · 5.7 KB

Changelog

All notable changes to the Riff.CC Flagship project will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

0.7.2 - 2025-10-13

Added

Citadel DHT Integration

  • Integrated Citadel DHT for distributed metadata storage with O(1) key lookups
  • Implemented DHTStorage backend replacing centralized storage with fully decentralized DHT
  • Added 2.5D Hexagonal Toroidal Mesh topology with 8-neighbor discovery
  • Implemented greedy routing algorithm with provably optimal paths
  • Added MinimalNode architecture with only 64 bytes of state per node
  • Implemented lazy neighbor discovery - compute neighbors on-demand without routing table storage
  • Added recursive DHT architecture - uses DHT to store its own topology

DHT Encryption & Security

  • Implemented optional ChaCha20-Poly1305 encryption for DHT values
  • Added Site Mode system (Normal vs Enterprise) for encryption policy enforcement
  • Implemented Blake3-based key derivation with salt for encryption keys
  • Added automatic encryption/decryption for all DHT storage operations
  • Implemented backward compatibility with unencrypted data during transition

Performance & Monitoring

  • Added comprehensive DHT metrics tracking (GET/PUT/DELETE operations, latency, errors)
  • Implemented /api/v1/dht/health endpoint for real-time DHT health monitoring
  • Added automatic error tracking and reporting for DHT operations
  • Implemented operation latency measurement for all DHT operations

Documentation

  • Added DHT_INTEGRATION.md with comprehensive technical documentation
  • Created detailed README for lens-v2-node with usage examples
  • Documented hexagonal toroidal mesh topology and routing algorithms
  • Added code examples for all major DHT operations

Changed

  • BREAKING: Lens Node v2 now uses DHT storage by default instead of in-memory storage
  • Updated storage layer to support pluggable backends via LensStorage trait
  • Refactored key generation to use Blake3 with domain separation
  • Enhanced error handling throughout DHT operations with detailed context

Performance Improvements

  • Achieved O(1) key lookups vs O(log N) in traditional DHTs
  • Benchmarked at 1.8-5.6M operations/second (45,000-48,000× faster than Amino DHT)
  • Reduced node memory footprint to 64 bytes per DHT node (vs 100s of KB in traditional DHTs)
  • Optimized routing to use geometric computation instead of routing table lookups

Technical Details

Mesh Topology

  • Default mesh: 120 × 120 × 25 = 360,000 total slots
  • Support for configurable mesh dimensions (width × height × depth)
  • Toroidal wrapping in all three dimensions for optimal routing
  • Average 12-15 hops for key lookups in production configurations

Storage Architecture

Browser Client
    ↓
HTTP/WebSocket API
    ↓
Storage Trait Layer
    ↓
DHTStorage Implementation
    ↓
Local Cache (in-memory + optional RocksDB)
    ↓
Citadel DHT Network

Encryption Format

  • Algorithm: ChaCha20-Poly1305 (authenticated encryption)
  • Key derivation: Blake3(SiteKey || salt || "lens:dht:v1")
  • Nonce: 96-bit random (stored with ciphertext)
  • Format: [nonce:12 bytes][ciphertext][auth tag:16 bytes]

Dependencies

  • Added citadel-core for topology and routing primitives
  • Added citadel-dht for distributed hash table implementation
  • Added chacha20poly1305 for authenticated encryption
  • Added blake3 for fast cryptographic hashing

Testing

  • Added comprehensive test suite for DHTStorage operations
  • Added tests for encryption/decryption roundtrips
  • Added tests for toroidal distance calculations
  • Added tests for greedy routing algorithm
  • Added tests for DHT health endpoint

0.7.1 - 2025-10-XX

Added

  • Initial Lens Node v2 implementation
  • Basic HTTP API for releases and metadata
  • In-memory storage backend
  • WebRTC P2P networking foundation

Release Notes

v0.7.2 Highlights

This release represents a major architectural shift from centralized to fully decentralized storage:

  1. O(1) DHT Performance: Citadel DHT provides constant-time key lookups through geometric routing, compared to O(log N) in traditional DHTs like Kademlia or Chord.

  2. Minimal Memory Footprint: Each DHT node requires only 64 bytes of state. Traditional DHTs store large routing tables (100s of KB per node).

  3. Provable Optimality: Every routing path can be verified as optimal by any observer, enabling cryptographic attestation and fraud detection.

  4. Encryption-Ready: Optional ChaCha20-Poly1305 encryption with configurable site modes enables both public and private deployments.

  5. Production-Ready Performance: Benchmarked at 1.8-5.6M operations/second, making it suitable for high-traffic production deployments.

Migration Guide

Existing Lens Node deployments can migrate to DHT storage:

  1. Parallel Run: Run DHT alongside existing storage, compare results
  2. Gradual Migration: Migrate non-critical data first (peer announcements)
  3. Full Cutover: Disable old storage once DHT is validated
  4. Optimization: Tune cache sizes and replication factors

See crates/lens-v2-node/DHT_INTEGRATION.md for detailed migration instructions.


Links