Spasm Forum
Decentralized Application
Community
Links
Details
License Permissive (MIT) — spasm-forum-web (TypeScript frontend), spasm-forum-server (TypeScript backend), spasm-docker, spasm-ansible. https://github.com/spasm-network, mirrored at git.spasm.network (self-hosted Forgejo) and codeberg.org/spasm-network
Dev Status 🟢 Active
Owner Spasm Network — pseudonymous, principally the contributor known as 'degenrocket'; no public organization members. Individual instances are operated independently by their own admins
Governing Body None (single pseudonymous maintainer; each instance governed independently by its own operator)
Country Unknown — maintainer pseudonymous; instance operators are independent and unlisted
Start Year 2021
Stack TypeScript (frontend and backend); Shell for deployment tooling; spasm.js as the protocol library; database per instance
Funding None disclosed — developed without funding for roughly five years
Last Investigated Jul 1, 2026
Decentralized Application Attributes
Origins Chat / message boards — built to replace account-based forum software (the project names Discourse specifically) with one where every action is a directly signed event and no account exists
Database Per-instance backend database; each operator runs their own. Content is not centrally stored — the same event propagates to other instances that choose to carry it
Query Language REST API per instance, with RSS output filterable by activity, action, category and signer
Data Formats Spasm JSON events; Spasm hashes as content identifiers (spasmid01 for events, spasmvi01/spasmim01/spasmau01/spasmfl01 for media); RSS for outbound feeds
Collaborative Live Editing N/A — asynchronous threaded discussion; no real-time co-editing
Rich Text Editing Basic — posts, comments and media attachments; no rich-text editing environment documented
Mobile Support Web-based — instances are browser-accessible and signing works through mobile web3 browsers; no native mobile app
Web Support Yes — the forum is a web application; this is its only client surface
Native Apps N/A — no native desktop or mobile client
Terms Self-hosting — operators deploy via Docker/Podman on an existing server or an Ansible playbook on a fresh VPS. No hosted service, no fees, no accounts
Funds $0 disclosed
Based On Spasm protocol (see the Spasm entry on the SD Pro tab); spasm.js; Nostr (multi-signing and cross-posting); Ethereum key signing via browser wallets and WalletConnect-style flows; RSS
Use Case Category Communication / Discussion forums; community coordination; also used for hackathons, event announcements, Q&A sessions and long-form media sharing
User Interface Type Timeline/Feed with tree-structured comments — forum categories with threaded replies; multiple UI themes available
Offline Capabilities Online only — instances are server-backed web applications with no documented offline mode
Collaboration Features Threaded comments with tree structure; reactions; cryptocurrency tipping; multi-signing of a single post with several keys; cross-instance propagation; RSS subscription per instance, category or author
Data Portability High — every post is a signed event carrying a content-derived Spasm ID that resolves across independent instances, and full RSS output is available; content is not locked to the instance that received it
Integration Ecosystem Nostr (multi-signed posts appear on both networks); Ethereum wallets and web3 browsers for signing; RSS readers and podcast apps; independent third-party frontends exist, including UBNet profiles which combine ENS for resolution, IPFS for hosting and Spasm for the social layer
Web2 Data Export Import only — instances can ingest RSS feeds to populate topic feeds; no documented export to Web2 platforms
Prosocial Coherence Minimal — instance admins can delete posts and configure the instance, but no reputation system, moderation tooling beyond deletion, or governance mechanism is documented. Each community sets its own norms per instance
Economic Flows Cryptocurrency tipping implemented. A SPASM token exists with an incentivization programme for early adopters, but the project states it is independent of the software and instances can run without it
Governance & Decision Making Per-instance operator control — each admin governs their own instance via a web admin panel authenticated by direct signing. No network-wide governance body, no formal process; protocol direction rests with the pseudonymous maintainer
Media / Publishing Yes — video, image and audio attachments with content-addressed Spasm media hashes; long-form posts and podcast distribution via RSS
Knowledge Management Partial — threaded discussion with persistent content-addressed identifiers provides durable discussion records, but no dedicated knowledge-management tooling
Sensemaking Partial — tree-structured comments are described by the project as aiding comprehension of complex topics; no dedicated sensemaking features
Project Management No
Communication Model Asynchronous — forum posts and threaded comments; store-and-publish rather than real-time
Network Resilience Instance-dependent with network-level redundancy — an individual instance is a conventional server-backed web app and goes down if its host does, but because the same signed event propagates to other instances and carries a content-derived identifier, content survives the loss of any single instance
Discovery Mechanism Direct / out-of-band — users find instances by URL (the project maintains a public instance list); content propagates between instances rather than being discovered through a DHT or global index
Max Participants Unknown — no published limits; instances are individually sized and current deployments are small
Data Sovereignty High — users hold their own signing keys and never create an account; posts are signed client-side and remain verifiable independently of the instance that stored them. Operators control only their own instance, not user identity