Skip to content

001.md

Latest commit

 

History

History
90 lines (57 loc) · 5.2 KB

001.md

File metadata and controls

90 lines (57 loc) · 5.2 KB

SRM-001

General Protocol Overview

draft optional meta guardian:spasm-core

This SRM defines the high-level architectural overview of the Spasm ecosystem. It describes the core mechanism by which Spasm acts as an abstract layer, encapsulating different event sources (web3 and web2) into a unified format for storage, retrieval, and optional federation.

Note: The examples provided in this SRM represent the foundational design philosophy. As the ecosystem evolves to integrate more networks (e.g., additional signing keys) and refine implementation details, specific data structures or filtering behaviors may change while maintaining backwards compatibility where possible.

Abstract

This SRM establishes the fundamental rules for how the Spasm ecosystem handles events. Unlike specific feature modules, this document explains the wrapper logic that allows heterogeneous data sources to coexist within a single instance.

It defines:

  1. The two primary categories of events supported: web3 signed events and web2 unsigned events.
  2. The structure of the SpasmEvent wrapper that unifies these types.
  3. The networking model of the Spasm network (multi-instance, optional federation).

Motivation

The future of social media aims to be agnostic to signing keys, messaging formats, and storage infrastructure. However, current decentralized solutions (Nostr, Bluesky, Lens, Fediverse) are often siloed. They require users to stay within a specific protocol, they lack interoperability and native integration with legacy content (RSS, blogs) or modern on-chain identity features (ENS, tokens). Some solutions support certain blockchain-based features, but they are confined to one specific blockchain.

Spasm solves this by introducing an abstraction layer. Instead of forcing developers to maintain separate databases for Spasm events, Dmp events, Nostr events, and RSS feeds, Spasm encapsulates all these sources into one SpasmEventV2 object. This allows a single instance to:

  • Accept content from multiple protocols.
  • Provide a unified API for consumers.
  • Enable cross-protocol interactions (e.g., replying to a Nostr note with an Ethereum-signed Spasm comment).
  • Support federated networking where multiple independent instances share the same data.

Specification

Event Classification

All events entering the Spasm ecosystem are classified into two distinct types based on their provenance and signature status. Both types are wrapped in the standard SpasmEventV2 structure.

Type Description Signature Example Sources
Web3 (signed) Events generated by a specific cryptographic key and protocol. Protocol-specific private key (e.g., Ethereum, Nostr). Spasm, Nostr, DMP.
Web2 (unsigned) Events fetched from external sources without cryptographic signatures. None RSS feeds, Static blogs, Posts from legacy forums.

The Spasm Event Wrapper

Regardless of the source type, the event is converted into a unified object (SpasmEventV2). This wrapper contains metadata that describes the origin and validation status.

Core Fields:

  • id: Spasm event can have multiple ids. For example, a protocol-native ID and a Spasm ID.
    • Spasm ID (any event)
    • Dmp ID (web3 signed events)
    • Nostr ID (web3 signed events)
    • GUID (web2 unsigned events)
    • URL (web2 unsigned events)
  • type: Event type (e.g., SpasmEventV2, SpasmEventEnvelopeV2)
  • protocol: Protocol name (e.g., spasm | dmp | nostr | web2)
  • source: The origin of the event, which might be another Spasm instance or a website with the RSS feed.
  • title: Title of the event.
  • content: The raw content of the event.
  • signers: Public keys associated with the event (e.g., Ethereum addr, Nostr pubkey)
  • timestamp: Timestamp of creation

Networks

Spasm has agnostic architecture, so it supports different networks.

Spasm Network

Spasm network consists of instances that can optionally federate with each other.

  • Federation: Instances can exchange events with each other to increase visibility.
    • Option A (Standalone): An instance only serves content it has ingested locally.
    • Option B (Federated): An instance pulls events from other instances (e.g., pulling unsigned web2 events from a dedicated RSS aggregator instance or signed web3 events from a social instance).

Multi-Signing Events

A single Spasm event can be multi-signed with different protocols (e.g., Spasm, Dmp, Nostr) and carry multiple signatures made by different types of private keys (e.g., Ethereum, Nostr). Original objects are stored as siblings of the event and can be utilized when necessary, e.g., to send a Nostr sibling into the Nostr network.

Censorship-resistance

Users keep custody over their identities because operators of Spasm instances cannot seize users' keys, which are used for signing events. If a user is banned on one instance, he can submit his messages to another instance or run his own instance.

Freedom of association

Spasm instances allow operators to tailor moderation rules to their needs, anywhere from highly restrictive whitelist-only setups to completely open free-for-all environments.