Library Of Mestionora

Library of Mestionora is a privacy‑first, I2P‑powered distributed backup library, instead of having things stored on one server, a swarm of contributors all together can back up important documents.

Comment 1

Library Of Mestionora: Pitch & Design Document

Inspiration

The history of humanity is a history of lost knowledge—from the Library of Alexandria to modern-day state censorship and the "disappearing" of digital archives. We believe that once information is free, it should stay free. Library Of Mestionora is named after the Goddess of Wisdom and Memory, designed to ensure that no government or centralized entity can ever "burn" the digital world's collective knowledge.

What it does

Library Of Mestionora is a decentralized file backup and distribution network running over the I2P (Invisible Internet Project) protocol.

  • Curated Priorities: "Nodes" (database maintainers) define which files are important.
  • Automated Health: "Vertices" (clients) host files and monitor their availability.
  • Self-Healing: If a file's redundancy drops below a safety threshold, the network automatically triggers emergency replication to prevent data loss.
  • Anonymity: Total resistance to IP-based tracking or physical location targeting via I2P.

How we built it

We designed a multi-tiered storage architecture for the Vertex client using Python. The system utilizes a "Swappiness" algorithm to decide how quickly to rotate healthy files for at-risk ones. By leveraging I2P, we ensure all communication is encrypted and metadata is decentralized. The logic is built around a peer-reputation system where vertices cross-verify file health with "neighbors" to identify content under threat.

Challenges we ran into

  • The Trust Dilemma: Preventing malicious actors from lying about file health (under-reporting to clog the network or over-reporting to let files die). We solved this with a neighbor reputation/penalty system.
  • Storage Balancing: Managing the "Emergency Space" (1% min, 1GB max) vs. Permanent storage to ensure the network stays lean but responsive.

Accomplishments that we're proud of

  • State-Resistant Threat Model: Targeted deletion is mathematically improbable. Even if a government forces a specific user to delete a file, the network detects the drop in "health" and automatically replicates that file to new, anonymous vertices.
  • Adaptive Health: Clients can swap between different sorting algorithms depending on how much data they are managing.

What we learned

We learned the complexities of decentralized consensus. Balancing individual node settings (like health-independent storage) with the overall network's needs requires a fine-tuned "Swappiness" frequency to prevent the network from constantly moving data unnecessarily.

What's next for Library Of Mestionora

  • Index Server: A searchable database for magnet links and priorities.
  • Leaf/Leech Application: Dedicated Mobile and Desktop interfaces.
  • Sussy Server: A user-space implementation for even easier hosting.

Technical Design Specs

1. Product Requirements

Need to Haves:

  • Index Server: Centralized or mirrored metadata tracker.
  • Leaf / Leech App: The interface for Server, Desktop, and Mobile.
  • Vertex Client: The core engine that handles I2P traffic and storage.

Nice to Haves:

  • Sussy Server: Simplified user-space hosting.
  • Landing/Download site: For network onboarding.

2. Vertex Design Doc (Pseudocode/Logic)

Internal Variables & Config

  • NeighborList: Semi-trusted neighbors with interaction history.
  • StorageConfig:
    • Permanent (x%): Files the user chooses to keep forever.
    • Emergency (y%): 1% min (max 1GB) reserved for at-risk files.
    • Non-permanent (rest): Files swapped based on health/priority.
  • Swappiness: How fast to swap old files for new ones.

Method: Signup()

# 1. Reach out to Node (or mirrors) to get the initial database.
# 2. Randomly choose a subset of files to host.
# 3. Assign x% as "Keep Forever" and register those original hosters as neighbors.
# 4. Store Node settings (priority weightings, emergency %s) into local config.

Method: UpdateAtRiskList()

# 1. Calculate health for IDs passed by neighbors. 
# 2. If health > threshold, remove from at-risk list.
# 3. Calculate health for files you are seeding.
# 4. If health < threshold, add to your own at-risk list.

Method: CheckNeighbors()

# 1. Query neighbors for their "at-risk" lists.
# 2. Run a local health check on those files (verify seeder count via I2P).
# 3. If neighbor was lying (file is healthy), apply a penalty.
# 4. If file is actually unhealthy:
#    a. Add to your unhealthy list.
#    b. Trigger backupCheck().
#    c. Add the source of the file as a new neighbor.

Method: BackupCheck()

# 1. Wait a random short duration (prevents everyone hitting the source at once).
# 2. Check if still unhealthy.
# 3. If yes, pull file into Emergency Space.
# 4. If Emergency Space is full, wait a duration based on 'Swappiness' 
#    and delete the healthiest 'Non-permanent' files to make room.

Method: GetHealth()

# Formula: (File Priority Weighting) * (Number of Active Seeders on I2P)
# Returns a health score.

3. Threat Model

  • Assumptions: Large, healthy network over I2P.
  • Government Force: If a file is targeted for deletion, the network detects the lack of seeders.
  • Prevention: Users can flag specific files as "Priority" which contributes to health but prevents removal.
  • Physical Targeting: Not covered (I2P covers digital anonymity; physical safety is user-dependent).

Built With

Share this project:

Updates