Nostr uses relays (simple websocket servers) as intermediaries, while P2P social networks have users directly exchange data with each other.
Nostr's Advantages Over P2P
Aspect
Nostr's Approach
Simplicity
"Signed JSON over websockets" - trivially implementable
Reliability
No NAT traversal, no DHT, no gossip protocol complexity
Mobile-friendly
Clients can be thin; no need to run background sync
Discoverability
Relays provide known endpoints; P2P struggles with "how do I find you?"
Offline users
Relays store messages for offline recipients; P2P requires both parties online (or complex pub infrastructure)
P2P's Advantages Over Nostr
Aspect
P2P's Approach
No servers needed
True decentralization; Nostr still requires someone to run relays
Offline-first
Local-first data; works without internet once synced
Censorship resistance
Harder to block gossip than to block known relay servers
No hosting costs
Users bear their own storage/bandwidth
The Tradeoff
The speaker acknowledges: "we're not in the business of selling magic - data has to be hosted, it has to be on a drive somewhere connected to the internet."
Nostr accepts that servers exist but makes users not dependent on any specific server. P2P tries to eliminate servers entirely but introduces complexity that limits adoption ("it works" being the key claim against P2P).
so what does nostr run off? web servers? daemons?built on.
From the transcript, I can pull out:
Relays are websocket servers
The protocol is "signed JSON over websockets"
It mentions you can run a relay on a Raspberry Pi
Relays are just servers that host data
Let me explain this clearly based on what's in the transcript and general knowledge about Nostr.
Based on the transcript, Nostr's infrastructure is straightforward:
Relays
Relays are just websocket servers. The speaker describes the entire protocol as "signed JSON over websockets" - that's literally it.
They can run on:
A VPS or cloud server
A Raspberry Pi (the speaker mentions this as an option)
Any machine that can maintain websocket connections and store JSON
There's no special daemon or complex software stack required. A relay just needs to:
Accept websocket connections
Receive JSON events from clients
Store them (database, files, whatever)
Serve them back to clients who request them
Clients
Clients are regular apps - mobile apps, web apps, desktop apps. They:
Connect to one or more relays via websocket
Publish signed events
Request events (by public key, by kind, etc.)
What's notably absent
No blockchain
No DHT (distributed hash table)
No gossip protocol
No consensus mechanism
No special networking requirements
The speaker emphasizes this simplicity intentionally: "it's just JSON, you'll figure it out." The barrier to entry is low - if you can build anything that talks websockets and handles JSON, you can build a Nostr client or relay.
This is why adoption has been relatively fast compared to earlier decentralized social attempts - the technical lift is minimal.
After connecting, Firebase is out of the picture. All data flows directly between users.
🎬 Demo
Live Demo: [Coming Soon]
Screenshots:
┌─────────────────────────────────────┐
│ P2P Social [⚙️] │
├─────────────────────────────────────┤
│ │
│ 📝 What's on your mind? │
│ ┌─────────────────────────────┐ │
│ │ │ │
│ └─────────────────────────────┘ │
│ [Post] 🔐 Encrypted │
│ │
│ ───────────────────────────────── │
│ │
│ 👤 Alice 2m ago│
│ ┌─────────────────────────────┐ │
│ │ Just set up my node! │ │
│ │ Running purely P2P 🚀 │ │
│ └─────────────────────────────┘ │
│ 💬 3 replies 🔄 12 shares │
│ │
│ 👤 Bob 5m ago│
│ ┌─────────────────────────────┐ │
│ │ No more censorship! 🎉 │ │
│ └─────────────────────────────┘ │
│ │
└─────────────────────────────────────┘
🏗️ Architecture
High Level
┌──────────┐ Signaling ┌──────────┐
│ User A │ ←──────────────→ │ Firebase │
│ (Browser)│ │ │
└────┬─────┘ └────┬─────┘
│ │
│ Signaling │
│ ←──────────────────────────┘
│
│ WebRTC (Direct P2P)
↓
┌──────────┐
│ User B │
│ (Browser)│
└──────────┘
Data Redundancy
Posts are split using Hamming (7,4) codes:
Original Post (1 MB)
↓
Split into 4 chunks (250 KB each)
↓
Generate 3 parity chunks (error correction)
↓
= 7 total chunks distributed across 7 peers
↓
Can lose ANY 2 chunks and still recover the post
This means content survives even if users close their browsers.
🔒 Security & Privacy
Your Identity
Public key = Your username (shareable)
Private key = Your password (never leaves your browser)
No email, no phone number, no real name required
Content Authenticity
Every post is cryptographically signed
Recipients verify signatures before displaying
Impossible to impersonate another user
Optional Encryption
End-to-end encrypted direct messages
Only sender and recipient can read
Network only sees encrypted gibberish
What About Illegal Content?
You control what you store:
Only cache content from users you follow
Block malicious users instantly
You're not a server, you're a peer
Legal precedent: caching != distribution
💻 Getting Started
As a User
Just visit the site:
https://p2p-social.github.io
No installation. No signup. Just start posting.
As a Developer
Clone and run locally:
git clone https://github.com/p2p-social/p2p-social
cd p2p-social
python -m http.server 8000
open http://localhost:8000
Firebase Setup (5 minutes):
# 1. Create Firebase project at console.firebase.google.com# 2. Enable Realtime Database# 3. Copy config to src/firebase-config.js# 4. Done!
Deploy to GitHub Pages:
npm run deploy
# Your site is now live at username.github.io/p2p-social
Censorship - Platforms ban users for arbitrary reasons
Manipulation - Algorithms optimize for engagement, not truth
Privacy violations - Your data is the product
Monopolies - A handful of companies control discourse
Deplatforming - One ban = locked out of digital life
The Solution
Take back control:
Own your data
Own your identity
Own your connections
Own your platform
No company can:
Ban you
Censor you
Mine your data
Manipulate your feed
Sell your attention
🎓 Inspiration
This project stands on the shoulders of giants:
John Sokol - Original vision for P2P social networking
Jack Dorsey - Bluesky initiative
Gun.js - Graph database synchronization
IPFS - Content-addressed storage
WebTorrent - P2P in the browser
Nostr - Minimal censorship-resistant protocol
⚖️ Philosophy
Core Principles
User Sovereignty - You own your data and identity
Simplicity - Technology should be understandable
Openness - Code and protocols are public
Resilience - No single point of failure
Freedom - Communicate without permission
Non-Goals
❌ Anonymity (use Tor for that)
❌ Perfect privacy (use Signal for that)
❌ Scalability to billions (use BitTorrent for that)
❌ Professional polish (we'll get there)
We're building a tool, not a product.
📊 Comparison
Feature
P2P Social
Facebook
Mastodon
Nostr
Censorship Resistant
✅
❌
Partial
✅
No Servers
✅
❌
❌
✅*
Free Hosting
✅
✅
❌
Partial
Open Source
✅
❌
✅
✅
Browser-Only
✅
✅
✅
Partial
Data Redundancy
✅
✅
❌
❌
E2E Encryption
✅
Partial
✅
✅
* Nostr uses relay servers, not fully P2P
🐛 Known Issues
Current Limitations:
⚠️Bootstrap problem - Need seed peers for first users
⚠️NAT traversal - Some networks require TURN servers
⚠️Data persistence - Content disappears if all peers offline
⚠️Discovery - Hard to find new users without directory
⚠️Mobile - WebRTC support varies on mobile browsers
We're working on all of these!
📜 License
MIT License - Do whatever you want with this code.
Copyright (c) 2024 P2P Social Contributors
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software to use, modify, distribute, and sell without restriction.
See LICENSE file for full terms.
"I just want to discuss news articles with my friends without some algorithm deciding what I can see."
The Problem
Modern social platforms have become censorship bottlenecks:
Content filtered by opaque algorithms
Users banned for sharing legitimate content
Platforms prioritize engagement over user intent
Central servers = central points of failure and control
We can do better.
Architecture Overview
This is a serverless peer-to-peer social platform that runs entirely in browser tabs, with zero backend infrastructure costs and zero ability for platforms to censor content.
1. Peer A loads app from GitHub Pages
2. Connects to Firebase for signaling
3. Publishes presence & connection offer
4. Peer B receives offer via Firebase
5. Sends answer back through Firebase
6. WebRTC connection established
7. Firebase no longer involved
8. All data flows directly A ↔ B
// User wants to view a postconstcontentHash="QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG";// Query connected peersconstpeers=getConnectedPeers();for(constpeerofpeers){if(peer.hasContent(contentHash)){constchunks=awaitpeer.requestChunks(contentHash);constcontent=reconstructFromChunks(chunks);displayContent(content);break;}}
// Follow a user (store their public key)constfollowing={"user_alice": "ED25519_PUBLIC_KEY_ALICE","user_bob": "ED25519_PUBLIC_KEY_BOB"};// Only accept content from followed usersfunctionvalidatePost(post){constauthorKey=following[post.author];if(!authorKey)returnfalse;returnverifySignature(post,authorKey);}
// New content propagates through network
GOSSIP {
type: "NEW_POST",
content_hash: "Qm...",
author: "alice_pubkey",
timestamp: 1700000000,
hops: 2
}
// Peers re-broadcast to their connections
// TTL prevents infinite loops
User Experience
First Run
1. Visit: yourproject.github.io
2. App generates keypair
3. Shows "Your ID: alice_abc123"
4. Connects to Firebase for peer discovery
5. Establishes connections to online peers
6. Ready to post/browse
Posting Content
1. User writes post
2. Post signed with private key
3. Split into chunks + Hamming encoding
4. Distributed to connected peers
5. Content hash returned as "permalink"
6. Peers gossip about new content
Browsing Content
1. See post hashes from followed users
2. Request chunks from peers
3. Reconstruct from Hamming codes
4. Verify signature
5. Display content
Following Users
1. Friend shares their public key (QR code, link, etc)
2. You add to "following" list
3. Network prioritizes content from followed users
4. You help distribute their content
Implementation Roadmap
Phase 1: MVP (Weeks 1-4)
Basic WebRTC mesh networking
Firebase signaling setup
Simple text posts
Content-addressed storage
Public key identity
Deliverable: Two users can chat P2P via browser tabs
Users encouraged to export/backup important content
"Pinning" feature for critical content
Browser extensions stay alive in background
Community runs dedicated "archive nodes"
Getting Started
For Users
# Just visit the site
https://yourproject.github.io
# Or run locally
git clone https://github.com/yourproject/p2p-social
cd p2p-social
python -m http.server 8000
# Open http://localhost:8000
For Developers
# Clone repository
git clone https://github.com/yourproject/p2p-social
cd p2p-social
# Install dependencies
npm install
# Set up Firebase# 1. Create Firebase project# 2. Copy config to src/firebase-config.js# 3. Enable Realtime Database# Run development server
npm run dev
# Deploy to GitHub Pages
npm run deploy
Q: Is this like BitTorrent? A: Similar concept, but for social networking. Content is distributed across users instead of centralized servers.
Q: What happens if I close my tab? A: Content you've viewed is cached in other users' browsers. Hamming codes ensure redundancy.
Q: Can content be deleted? A: You can stop distributing it, but others may cache it. This is by design (censorship resistance).
Q: Is this anonymous? A: Pseudonymous. Your public key is your identity, but not linked to real identity unless you share it.
Q: What about illegal content? A: Users control what they store/distribute. You're not legally liable for cached chunks of encrypted data you can't read. Block malicious users via web-of-trust.
Q: How fast is it? A: Initial connection takes 1-2 seconds. After that, direct P2P is often faster than traditional servers.
Q: Mobile support? A: Yes! WebRTC works in mobile browsers. PWA support coming.
Q: Can governments block this? A: They can block Firebase, but the app can use alternative signaling servers. Once connected, traffic is P2P and harder to filter.
Related Projects
Gun.js: Graph database with P2P sync
IPFS: Distributed file system
Nostr: Minimal protocol for censorship-resistant social
Scuttlebutt: Offline-first P2P social network
Matrix: Federated messaging
Mastodon: Federated microblogging
How we're different:
Zero infrastructure (GitHub + Firebase free tiers)
