Zofie Archive

Artifacts: Metadata with Torrent Distribution and Integrity Verification

Draft Optional Kind 30025 Version 1.0
Read Specification

Abstract

This NIP defines kind 30025 for parameterized replaceable events that store metadata for artifacts such as books, academic papers, datasets, and multimedia educational content.

Events include primary torrent magnet URIs for decentralized content distribution, optional chapter-level magnets for progressive downloads, and cryptographic integrity hashes (BLAKE3 or SHA256) for verification.

Key Innovation: This enables nomadic digital archives on Nostr relays, where lightweight metadata propagates via gossip while large payloads distribute through BitTorrent swarms, ensuring censorship-resistant replication without relay storage burden.

Motivation

Nostr excels at federated metadata distribution but struggles with large payloads (books, research papers, datasets) due to relay storage limits and censorship risks.

πŸ›‘οΈ

Censorship Resistance

Torrents survive relay takedowns via DHT peer discovery

πŸ“ˆ

Scalability

Relays store ~1-2KB events; torrents handle gigabyte payloads

πŸ”’

Integrity

Cryptographic hashes prevent tampering and verify authenticity

πŸ”

Discoverability

Rich metadata enables faceted search across subjects, authors, languages

πŸ’Ύ

Preservation

Achieve >10 seeds/artifact for 99.99% availability

🀝

Interoperability

Complements NIP-23 for long-form articles with downloadable content

Use Case: Use kind 30023 for readable text content, kind 30025 for downloadable artifacts with torrent backing.

Specification

Event Structure

Events of kind 30025 MUST be parameterized replaceable per NIP-01, identified by a ["d", "<unique_identifier>"] tag.

Recommended Identifier Formats

  • ISBN-based: "isbn-978-1-59327-828-1"
  • DOI-based: "doi-10-1000-xyz123"
  • Custom slugs: "moby-dick-gutenberg-2701"

Required Tags

Tag Description Example
d Unique artifact identifier ["d", "rust-book-2018"]

Recommended Tags

Tag Description Example
t Fixed type marker for filtering ["t", "artifact"]
title Primary title (max 500 chars) ["title", "The Rust Book"]
author Repeatable (max 20 entries) ["author", "Steve Klabnik"]
published Publication year (4-digit) ["published", "2018"]
subject Repeatable topic tags ["subject", "programming"]

Optional Tags

lang format license isbn doi content_warning owner

Content JSON Schema

Minimal Required Fields

{
  "version": "1.0",
  "title": "string (required, non-empty, max 500 chars)",
  "magnet": "string (optional if chapters array present)",
  "hash": "string (required if magnet present; 64-char hex)",
  "hash_algo": "string (required if hash present; 'blake3' or 'sha256')",
  "file_size": "integer (required if magnet present; bytes)"
}
Important: Either provide a top-level magnet OR a chapters array with at least one entry. Both can coexist for maximum flexibility.

Validation Rules

  1. version: Must be "1.0"
  2. title: Required, non-empty, max 500 chars
  3. magnet: Must start with "magnet:" if present
  4. hash: Required if magnet present; must be 64 lowercase hex chars
  5. hash_algo: Required if hash present; must be "blake3" or "sha256"
  6. file_size: Required if magnet present; must be positive integer
  7. chapters: Max 100 entries
  8. author: Max 20 entries
  9. description: Max 2000 chars

Examples

Example 1: Technical Book

{
  "kind": 30025,
  "tags": [
    ["d", "rust-book-2018"],
    ["t", "artifact"],
    ["title", "The Rust Programming Language"],
    ["author", "Steve Klabnik"],
    ["author", "Carol Nichols"],
    ["published", "2018"],
    ["subject", "programming"],
    ["format", "application/pdf"],
    ["license", "MIT"]
  ],
  "content": "{\"version\":\"1.0\",\"title\":\"The Rust Programming Language\",\"magnet\":\"magnet:?xt=urn:btih:...\",\"hash\":\"a1b2c3...\",\"hash_algo\":\"blake3\",\"file_size\":5242880}"
}

Example 2: Academic Paper

{
  "kind": 30025,
  "tags": [
    ["d", "doi-10-48550-arxiv-1706-03762"],
    ["t", "artifact"],
    ["title", "Attention Is All You Need"],
    ["author", "Ashish Vaswani"],
    ["published", "2017"],
    ["subject", "machine-learning"],
    ["doi", "10.48550/arXiv.1706.03762"],
    ["license", "CC-BY-4.0"]
  ],
  "content": "{\"version\":\"1.0\",\"title\":\"Attention Is All You Need\",\"magnet\":\"magnet:?xt=urn:btih:...\",\"hash\":\"d4e5f6...\",\"hash_algo\":\"blake3\",\"file_size\":2097152}"
}

Example 3: Book with Chapters

{
  "content": {
    "version": "1.0",
    "title": "Complete Programming Guide",
    "magnet": "magnet:?xt=urn:btih:FULL_BOOK...",
    "hash": "abc123...",
    "hash_algo": "blake3",
    "file_size": 10485760,
    "chapters": [
      {
        "title": "Chapter 1: Introduction",
        "number": 1,
        "magnet": "magnet:?xt=urn:btih:CHAPTER1...",
        "hash": "def456...",
        "hash_algo": "blake3",
        "file_size": 524288
      }
    ]
  }
}

Implementation

Client Behavior

πŸ“ Publishing

  1. Generate unique d tag
  2. Populate required tags
  3. Serialize content JSON
  4. Compute event ID and sign
  5. Broadcast to multiple relays

πŸ“₯ Downloading

  1. Resolve magnet URI via BitTorrent
  2. Download payload
  3. Compute hash (BLAKE3 or SHA256)
  4. Verify: computed == expected
  5. Seed back to DHT

πŸ” Searching

  1. Query by tags (subject, author, lang)
  2. Full-text search on title
  3. Filter by format, year, license
  4. Display faceted results
  5. Show seed counts

Relay Behavior

Validation & Rate Limiting

  • Parse and validate JSON content
  • Enforce required fields and limits
  • Rate limit: 10 events/hour per pubkey (initial)
  • Max content size: 10KB suggested
  • Return specific error messages
For Relay Operators: Consider legal implications before implementing auto-seeding. Consult legal counsel regarding content hosting policies in your jurisdiction.

Security Considerations

πŸ”’ Integrity

Cryptographic hashes (BLAKE3/SHA256) prevent payload tampering. Clients MUST verify hashes post-download.

πŸ›‘οΈ Privacy

Pubkeys pseudonymize publishers. Torrent DHT participation exposes IP addressesβ€”recommend VPN/Tor for anonymity.

βš–οΈ Legal

Publishers responsible for ensuring legal distribution rights. Use license field for transparency.

🚫 DoS Prevention

Rate limiting prevents spam. Enforce array size limits (100 chapters, 20 authors) and JSON size caps (10KB).

⚠️ Content Warnings

Use content_warning tag for sensitive material. Helps users make informed decisions.

βœ“ Verification

Always display verification status in UI. Log failures for analysis. Consider multi-source verification.

NIP-94 vs NIP-AA

When to Use What

Use Case NIP-94 NIP-AA
Sharing a photo album βœ… Perfect ❌ Overkill
Publishing academic paper ⚠️ Works but limited βœ… Ideal
Distributing software updates βœ… Good fit βž– Either works
Archiving book collection βž– Possible βœ… Built for this
Sharing meme/screenshot βœ… Perfect ❌ Wrong tool
Think of it this way: NIP-94 is like Dropbox (share any file), NIP-AA is like Google Books (organize knowledge). Both valuable, different purposes.

Frequently Asked Questions

Why not use IPFS instead of BitTorrent?

BitTorrent has a more mature ecosystem with a proven 20+ year track record, wider client support, and better performance for large files. IPFS can be added via the mirrors field.

How do I update artifact metadata after publishing?

Simply publish a new event with the same pubkey and d tag but higher created_at timestamp. The new event replaces the old one per NIP-33.

Can I publish copyrighted works?

Only if you have legal rights to distribute them. Specify licensing via the license field. Publishers are responsible for ensuring legal compliance.

How many seeds are needed for good availability?

10+ seeds across diverse locations provides 99.99% availability. Monitor via DHT queries and re-seed if counts drop below 5.

What about rate limiting for bulk uploads?

Run your own relay to bypass rate limits, or coordinate with relay operators for temporary increases. Reputation-based limits may be implemented in the future.

Can I monetize artifact seeding?

Yes, via future kind 30030 for zap-based seeding incentives. Specify payment details in owner tag or future funding_address field.

Resources & Links

πŸ“š Documentation

Full specification on GitHub

View on GitHub

πŸ’¬ Community

Join the discussion on Nostr

Join Discussion

πŸ”§ Implementation

Reference implementations in Rust, Elixir, JavaScript

View Code

Complementary NIPs

  • NIP-01: Basic protocol flow and parameterized replaceable events
  • NIP-23: Long-form content (kind 30023)
  • NIP-50: Search capability (optional)

Future Extensions

⭐

Kind 30026

User reviews and ratings

πŸ“

Kind 30027

Annotations and highlights

πŸ“š

Kind 30028

Curated collections

πŸ’°

Kind 30030

Seeding incentives

Deployment Checklist

For Relay Operators

  • βœ… Implement validation hooks for kind 30025
  • βœ… Set up rate limiting (10 events/hour per pubkey initially)
  • βœ… Enforce content JSON size limits (10KB max)
  • βœ… Index required tags (d, t) and recommended tags
  • βœ… Configure error messages for validation failures
  • βš–οΈ Consider legal implications of auto-seeding
  • πŸ“Š Monitor relay storage and performance

For Client Developers

  • βœ… Integrate BitTorrent client (libtorrent-rs, WebTorrent)
  • βœ… Implement hash verification (BLAKE3 and SHA256)
  • βœ… Build UI for artifact browsing and search
  • βœ… Add progress indicators for downloads
  • βœ… Display seed counts and verification status
  • βœ… Support progressive chapter downloads
  • βœ… Cache verified artifacts locally
  • βœ… Handle errors gracefully with user feedback

For Publishers

  • βœ… Use established identifiers (ISBN, DOI) when available
  • βœ… Always specify hash_algo explicitly
  • βœ… Test torrents before publishing events
  • βœ… Provide clear licensing information
  • βœ… Use content_warning tag for sensitive material
  • βœ… Consider providing both full and chapter magnets
  • βœ… Seed your own torrents for initial availability

For Archivists

  • βœ… Focus on high-value, at-risk content first
  • βœ… Coordinate with other archivists for distributed seeding
  • βœ… Maintain diverse seed locations (different jurisdictions)
  • βœ… Monitor seed counts (re-seed below 5 seeds)
  • βœ… Build redundancy via mirrors field
  • βœ… Document preservation priorities

Design Rationale

Why Kind 30025?

Thematic adjacency to NIP-23:

  • Kind 30023: Long-form articles
  • Kind 30024: Article drafts
  • Kind 30025: Artifacts (this NIP)

Natural progression from readable text to downloadable knowledge.

Why BLAKE3 over SHA256?

  • 4x faster for large files
  • Native support in modern ecosystems
  • Ideal for torrent Merkle trees
  • SHA256 available for legacy support

Why Magnet URIs?

  • Decentralized DHT resolution
  • No central tracker dependency
  • Compact representation
  • Standard BitTorrent protocol

Why Chapter-Level Magnets?

  • Progressive downloads for low bandwidth
  • Modularity for large works
  • Parallel fetching optimization
  • Flexible content distribution

Why JSON Content?

  • Extensible for future fields
  • Human-readable for debugging
  • Rich nested structures
  • Client-side flexibility
Alternative Considered: IPFS was evaluated but BitTorrent's mature ecosystem (20+ years), wider client support, and proven reliability made it the better choice. IPFS can still be used via the mirrors field.

Acknowledgments

This specification is inspired by the pioneering work of digital preservation projects that have fought to keep knowledge accessible:

πŸ“–

Project Gutenberg

50,000+ free ebooks since 1971

πŸ›οΈ

Internet Archive

Digital library of humanity's knowledge

πŸ“š

Library Genesis

Scientific and educational materials

πŸ”¬

Sci-Hub

Open access to research papers

Special recognition to:

  • The Nostr community for building censorship-resistant communication protocols
  • The BitTorrent community for 20+ years of decentralized file sharing
  • NIP-23 authors for establishing long-form content foundations
  • All contributors to the Alexandria vision of universal knowledge access
Mission: To create a censorship-resistant, decentralized Library of Alexandria where knowledge can never be burned, banned, or lost to time.
↑