Nostr notes by VectorPrivacy

Vector is now listed on ...

2026-03-25T14:34:14Z

Vector is now listed on nprofile1qqs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgzqtdq0!

We are grateful and honored to finally be listed and available for the preferred and "go-to" app store for Nostr users. Thanks everyone for your patience, we know a lot of you all kept asking us "wen". Our goal was to optimize and improve a lot of features on Android before publishing, as first impressions can be everything. Probably not as much here on Nostr, as most of us are builders, developers, and used to working with experimental technology in its early stages.

Regardless, it was a seamless experience and one of the best app stores that we have used. The UX/UI is beautiful, intuitive, and just easy to understand and navigate. We are certainly sold on Zapstore.dev and will be promoting and sharing with others to check out.

Check it out yourself:
https://zapstore.dev/apps/io.vectorapp

Feel free to sign in to Zapstore.dev and leave a comment or review for Vector. We'd love to hear your honest feedback and takes. We are still in Open Beta, v0.3.3 just released yesterday, but making great strides... especially with the support from the Nostr community. 💚

We will find good use for that Vector Theme of the Zapstore ...

2026-03-25T13:14:17Z

In reply to nevent1q…hh6m
_________________________

We will find good use for that Vector Theme of the Zapstore badge. Looks great, Bee!

Ah! Thanks for the patience, we will now be reaching out to ...

2026-03-24T20:52:09Z

In reply to nevent1q…70pj
_________________________

Ah! Thanks for the patience, we will now be reaching out to Zapstore (nprofile…tdq0) because we finally released the latest version with some big upgrades. It is also tested on Android and quite challenging to play compared to the PC, but it does indeed work. Hope to get Vector listed soon™

#naddr1qv…w6hm

2026-03-24T20:33:30Z

quoting naddr1qv…w6hm

We've just released the latest version of Vector that primarily covered security upgrades, Android optimizations (resources + preserving battery life), profile URL sharing, and new chat features. So, feel free to update to the latest version and test them out yourself! If you can't find any of the features you want to test or not sure where, just post in chat and the team, developers, and community can assist you. Below is the complete list of improvements and fixes for v0.3.3.

Website:Download Now ⭐Visit GitHub

New Features:

🚫 User Blocking: you can block users from DMs - blocked contacts are hidden from contacts, invites, and notifications

👤 Profile Invites: share your own profile online with a single tap via the new Share button

🔐 Memory-Hardened Key Vault: private keys are XOR-split into 4 shares scattered across 128 indistinguishable decoy arrays — invisible to malware & forensics

📋 Unified Logging: new structured logging system with UTC timestamps, error toasts, and a persistent log file for easier debugging

🪂 Error Logging: errors are now caught and written to a private crash log — with a Copy Logs button in Settings for easy bug reports

Improvements:

🔋 Android Battery Life: background sync now connects to a single relay (with automatic failover) instead of 4-5, eliminating ~75% of radio wakeups

🎮 Mini App Realtime Overhaul: rebuilt WebXDC realtime channels with preconnect, SQLite persistence, message buffering, and bi-directional WebSocket support

🚀 Windows Mini App Performance: dramatically improved WebGL/WASM performance for Mini Apps on Windows

🛡️ Anti-Debug Protections: release builds block debugger attachment, memory inspection, and unsigned DLL injection across macOS, Linux, Android, and Windows

🧹 Zeroize Everywhere: passwords, seeds, nsec strings, and temporary key copies are wiped from memory immediately after use via volatile writes

📡 Scoped MLS Subscriptions: group message subscriptions are now filtered by your group IDs at the relay level

⚡ Instant Background Stop: background sync now uses zero-cost Notify signaling instead of polling every 5 seconds, responding instantly when you open the app

Fixes:

👻 Ghost Messages: MLS group messages no longer visually duplicate — the relay echo is now deduplicated at the backend before reaching the UI

📱 Android Foreground Resume: opening the app after background sync no longer shows an empty UI or login screen — stale relay connections and partial state are cleaned up automatically

🖼️ Preview Image Crash: fixed crash when a link preview's og:image URL fails to load

🎮 Mini App Session Fix: fixed Android Mini App failing to connect on second session open

🔍 GIF Search Safety: GIF search empty state no longer interpolates user input as HTML

📎 Mini App Upload Spinner: fixed duplicate progress spinners and spinner overlapping text in chat bubbles

How's the fragging going? Oops, we mean the stress testing. ...

2026-03-23T15:29:54Z

How's the fragging going?
Oops, we mean the stress testing.

GitHub Repo:
https://github.com/VectorPrivacy/DOOM

quoting naddr1qv…ars5

Open-Source DOOM: How We Brought Real-Time Multiplayer to a 1993 Classic. No Servers Required.

A Breakthrough in Decentralized Gaming by JSKitty (npub16ye…g4wn)

In May 2021, Cloudflare did something wonderful. They took DOOM -the 1993 game that defined an entire genre -compiled it to WebAssembly, wired up WebSocket multiplayer through their Durable Objects edge platform, and wrote a fantastic blog post about it. As Celso Martinho put it: "Running Doom is effectively the new 'Hello, World' in computing."

We loved it. And then we thought: what if we could take it further?

What if multiplayer DOOM didn't need Cloudflare's servers -or anyone's servers? What if it didn't need the internet at all? What if you could send a 4MB file to a friend in a chat message and be fragging each other within seconds, purely peer-to-peer, with the game feeling like a modern real-time shooter instead of a 1994 LAN party?

That's what we built. We call it Open-Source DOOM.

It's powered by a stack of open technologies: Chocolate Doom compiled to WebAssembly via Emscripten, distributed as a WebXDC mini-app, with peer discovery over Nostr, end-to-end encryption via Marmot (MLS over Nostr), and real-time P2P data transport through Iroh (QUIC-based gossip). Every layer is open-source. Every packet is encrypted. No servers required.

What Cloudflare Built (And Why It's Great)

Credit where it's due. Cloudflare's doom-wasm project did the hard work of porting Chocolate Doom -> the faithful open-source recreation of the original DOOM engine -> to WebAssembly using Emscripten. That alone is a serious engineering effort. They then wrote net_websockets.c, a transport adapter that replaced DOOM's original IPX/UDP networking with WebSocket connections routed through Durable Objects on Cloudflare's edge network.

Their architecture looked like this:
Player A (Browser)  ←WebSocket→  Cloudflare Edge (Durable Object)  ←WebSocket→  Player B (Browser)
A Durable Object acted as the game room -maintaining a routing table of connected players and forwarding packets between them. Clean, elegant, and a great demo of edge computing.

But there was a catch.

What they kept the same

Cloudflare didn't modify DOOM's actual netcode. The game still used its original lockstep networking model from 1993 -the same protocol designed for four PCs on a local area network connected by coaxial cable. Every player sends their inputs (which keys they pressed) to every other player, every single frame, and the game freezes until everyone's inputs arrive.

As their blog post acknowledged: "The game only advances when everyone receives the commands from all the other players in the group."

This worked in 1993 when your LAN had sub-millisecond latency. Over the internet, through WebSockets, through a routing layer? It meant choppy gameplay, freezes whenever anyone's connection hiccupped, and a gameplay experience that felt more like a slideshow than a shooter.

The Durable Object was also a single point of failure and a centralised dependency. No Cloudflare, no DOOM.

What We Changed (Everything Except the Game Itself)

We forked Cloudflare's doom-wasm project and rebuilt the entire networking stack from scratch. Not just the transport layer -the fundamental model of how the game synchronises state between players.

Here's the before and after:

Cloudflare's DOOM Open Source DOOM

Transport WebSockets → Cloudflare Edge P2P gossip via Iroh (QUIC)

Server Durable Object (centralised) Auto-elected from players (decentralised)

Sync model Lockstep (1993 original) Real-time hybrid (snapshots + interpolation)

Damage Simulated locally by all clients Host-authoritative events

NPCs/Monsters Simulated locally by all clients Host-authoritative snapshots

Late join Not supported Fully supported

Internet required Yes (Cloudflare Workers) No (works offline, P2P)

Delivery Website (silentspacemarine.com) 4.2MB file in a chat message

Let's break down each piece.

1. No Servers, No Problem

The Simple Version

Cloudflare's DOOM needed their servers to work. Ours doesn't need any servers. When you open the game, your device automatically figures out who should be the "host" --no configuration, no IP addresses, no port forwarding, no sign-ups. It just works.

The game runs inside a .xdc file, essentially a tiny 4.2MB zip archive containing the entire game. You literally send it as a file in a chat message. Your friend opens it. You're playing DOOM together. The data travels directly between your devices through the chat app's peer-to-peer channels.

The Nerdy Version

We replaced net_websockets.c with net_webxdc.c -a transport module that speaks the WebXDC realtime channel protocol instead of WebSockets.

WebXDC is an open standard for sandboxed web apps distributed inside chat messages. The app has zero internet access, no fetch, no XMLHttpRequest, nothing. The only communication channel is webxdc.joinRealtimeChannel(), which gives you an unreliable broadcast pipe to other instances of the same .xdc file in the same chat.

Under the hood (in our primary platform, Vector), this channel is backed by Iroh, a QUIC-based peer-to-peer gossip protocol. Messages travel directly between devices, relayed through lightweight Iroh relay nodes only when direct connections aren't possible. There are no game servers, no routing tables, no Durable Objects.

Peer discovery happens over Nostr, the decentralised social protocol. When you open a game, your Iroh node address is published as a Nostr event so other players can find you and establish a direct connection. The connection itself is encrypted end-to-end via Marmot, which implements the MLS (Messaging Layer Security) protocol over Nostr. So every packet of DOOM multiplayer data, every position snapshot, every damage event, every frag, is encrypted with forward secrecy before it ever leaves your device.

The wire format is minimal:
[to: uint32 LE (4 bytes)][from: uint32 LE (4 bytes)][doom_payload]
JavaScript routes incoming packets by destination UID -only packets addressed to you (or broadcast address 0) get delivered to the WASM engine. Everything else is silently dropped.

For performance, Vector provides a WebSocket fast-path: the app connects to ws://127.0.0.1:{random_port}/{token} -a localhost WebSocket server spun up by the Rust backend -giving near-zero-latency access to the Iroh gossip sender. Binary frames go straight to sender.broadcast() with zero copies. Fallback path uses Tauri invoke with base91 encoding.

2. Who's the Server? Magic.

The Simple Version

In a normal online game, someone runs a server, and everyone connects to it. In Open Source DOOM, there is no predetermined server. When you open the game, all players silently negotiate who becomes the host. The person who opened the game first wins. This happens automatically in about three seconds, and you never even notice it.

The Nerdy Version

Server election uses a dead-simple timestamp protocol over the broadcast channel:

Every instance broadcasts 4 magic bytes ([42, 42, 42, 42]) every 300ms: "I exist, who's the server?"

Every instance responds to discovery requests with: [43, 43, 43, 43][padding(4)][timestamp(8)] -where timestamp is Date.now() from when the app first opened

The instance with the earliest timestamp wins

After 3 seconds with no earlier challenger, you declare yourself server

The elected server re-broadcasts its beacon every 3 seconds so late-joiners can discover it

The server gets instanceUID = 1 (hardcoded). Clients get a random UID in 1–65534. This UID becomes their network address for the entire session -no DNS, no IP addresses, no NAT traversal headaches.

The whole election algorithm is about 80 lines of JavaScript. It works over any broadcast transport. No configuration needed.

3. From Lockstep to Real-Time (The Big One)

The Simple Version

Original DOOM multiplayer works like a group of people writing a letter round-robin. Nobody can write their next line until everyone has received and read the previous line. If one person is slow, everyone waits.

We changed it to work more like a live conversation. Everyone talks at their own pace. If you miss a word, you can still follow along because the speaker periodically summarises where things stand. The result feels like a modern shooter -smooth movement, responsive controls, no freezing.

The Nerdy Version

This was the most fundamental change: replacing DOOM's pure lockstep synchronisation with a hybrid real-time model. The ticcmd backbone remains (it's too deeply embedded in Chocolate Doom's deterministic physics to remove), but we layered three correction systems on top:

a) Position Snapshots + Exponential Smoothing

Every 2 tics (~57ms at 35 FPS), each player broadcasts a snapshot of their state:
int data[9] = {
    mo->x, mo->y, mo->z,        // World position (fixed-point)
    mo->angle,                    // Facing direction
    mo->momx, mo->momy, mo->momz, // Velocity
    attack_weapon,                // 0=idle, 1-9=attacking with weapon N
    latency                       // Round-trip time (ms)
};
Remote players don't run DOOM's physics engine at all. Instead, D_TickPlayerInterp() runs every tic:
Extrapolate the target forward using stored momentum: target_x += momx
Smooth toward the target, closing 60% of the remaining gap each tic:
#define INTERP_FRAC  39322  // 0.6 * 65536 (fixed-point)
mo->x += FixedMul(target_x - mo->x, INTERP_FRAC);
mo->y += FixedMul(target_y - mo->y, INTERP_FRAC);
Teleport detection: if the delta exceeds 128 map units, snap instantly (player respawned or hit a teleporter)
One subtle but critical detail: angle is NOT interpolated. The ticcmd's angleturn field is applied deterministically by P_MovePlayer() and stays in sync across machines. Interpolating angle toward a stale snapshot would fight the ticcmd, causing visible rotation jitter of up to 90 degrees. We learned this the hard way.

b) Attack Animation Sync

Remote players' attacks are driven by snapshot data, not ticcmds. When a snapshot reports attack_weapon > 0, we set the S_PLAY_ATK1 animation state and play the weapon fire sound. An 8-tic animation lock prevents local state transitions from overriding it.

To prevent feedback loops, we track last_received_attack[] -the raw flag as received from the network -and broadcast that, not the lock-modified mobj state. Without this, attack animations would echo infinitely.

4. "I Shot You!" "No You Didn't!"

The Simple Version

In the original DOOM, every computer runs its own copy of the game physics. When you shoot someone, your computer calculates the damage, and their computer calculates the damage, and because the game is in lockstep, they always agree.

With our real-time model, that guarantee vanishes -your screen and theirs might show slightly different positions. So we made one player (the host) the referee. When you shoot someone, you tell the host "I hit Player 2 for 50 damage". The host checks the physics, applies the damage if it's valid, and announces the result to everyone. One truth, no arguments.

The Nerdy Version

We implemented an event-based host-authority model for all game-changing state:

Damage path:
Client A fires weapon → bullet hits Player B locally
  → Client A sends DAMAGE_EVENT to host: {target: B, damage: 50, source: A}
  → Client A applies VISUAL FEEDBACK ONLY (screen flash, attacker tracking)
  → Client A does NOT reduce Player B's health

Host receives DAMAGE_EVENT:
  → Sets damage_from_event = true (bypasses remote-source skip)
  → Calls P_DamageMobj() with full physics simulation
  → New health broadcasted via HEALTH_AUTH packet next snapshot cycle

All clients receive HEALTH_AUTH:
  → Apply as ground truth
  → Host says dead, client says alive? → P_KillMobj()
  → Host says alive, client says dead? → Trigger respawn
  → Health decreased? → Play pain animation
The damage_from_event flag is critical. Without it, the host faces a double-damage problem: it receives both the ticcmd attack (from the lockstep backbone) AND the explicit damage event. The flag ensures only the event path applies.

Other host-authoritative systems: - USE events: Client presses 'E' near a door → sends USE_EVENT → host calls P_UseLines() → door opens for everyone - Respawns: Client dies → sends RESPAWN_REQUEST → host sets playerstate = PST_REBORN - Kill messages: Host broadcasts KILL_MSG when a player dies → displayed on all screens

5. Making Monsters Agree

The Simple Version

DOOM has dozens of monsters per level, each running their own AI -chasing you, shooting fireballs, infighting with each other. In the original game, every computer simulates every monster identically (because lockstep ensures they all see the same inputs). In our version, only the host simulates the monsters. Everyone else just sees the results -like watching a puppet show where only the puppeteer knows the script, but the audience sees the performance in real-time.

The Nerdy Version

We built a full NPC synchronisation system (p_netsync.c/h):

Registry: Every monster and barrel gets a unique net_id via P_NetAssignId():
mobj_t *net_mobj_table[MAX_NET_MOBJS];  // 512 slots
unsigned short net_id_counter;            // Sequential allocator
Host broadcasts (every 2 tics) a compact binary snapshot:
[npc_count: u8][gametic: u16]
Per NPC (20 bytes): net_id(2) x(4) y(4) z(4) angle(1) statenum(2) health(2) flags(1)
[sector_count: u8]
Per changed sector (10 bytes): sector_id(2) ceiling(4) floor(4)
[missile_count: u8]
Per missile (32 bytes): source_net_id(2) type(2) x(4) y(4) z(4) momx(4) momy(4) momz(4) angle(4)
Client-side: In P_MobjThinker(), clients skip physics entirely for any mobj with net_id > 0. Only the animation tic counter runs. State changes use P_SetMobjStateNoAction() -which applies the visual state WITHOUT executing action functions. This prevents clients from independently spawning projectiles, running AI decisions, or playing duplicate sounds.

The sector data keeps doors and lifts in sync. The missile data ensures fireballs and rockets appear on all screens.

6. "Room for One More?" -Mid-Game Joining

The Simple Version

Original DOOM didn't let you join a game already in progress. Everyone had to be there at the start, or too bad. Our version lets players drop in mid-game. You open the .xdc, the game finds the server, and you spawn in -even if everyone else is already knee-deep in the dead.

The Nerdy Version

Late joining required solving several hairy problems:

Tic synchronisation: The late joiner's tic counter is meaningless -they weren't there for tics 0 through N. When the server accepts a late join, it sends settings->start_tic set to the current server tic. The client aligns its recvtic, maketic, and gametic to this value, syncing the 8-bit tic sequence numbers with the server's counter.

Double-slot bug: We found that NET_SV_AssignPlayers() could assign the new client to a slot that was already used, creating a ghost duplicate. The fix: HandleLateJoin() explicitly clears any pre-existing slots for the new client before assigning a fresh one.

Ghost body cleanup: When a player disconnects and reconnects (or the quit/rejoin cycle fires), their old mobj lingers in the world as an invisible collision obstacle. P_SpawnPlayer() now checks for and removes any existing mobj before spawning:
if (p->mo) {
    p->mo->player = NULL;
    P_RemoveMobj(p->mo);
    p->mo = NULL;
}
Name propagation: When a new player joins, every existing player re-broadcasts their name, so the joiner's HUD displays the correct names instead of the defaults ("Green", "Indigo", "Brown", "Red").

7. Fits in a Chat Message

The Simple Version

The entire game -engine, levels, monsters, weapons, networking, touch controls, gamepad support, all of it -fits in a 4.2 megabyte file. That's smaller than most photos your phone takes. You send it in a chat message like you'd send a meme. Your friend taps it, and they're in the game. No app store, no downloads, no accounts, no updates.

The Nerdy Version

The .xdc format is just a ZIP archive with a different extension. Ours contains:

File Size (compressed) Purpose

vector-doom.wasm ~2.7 MB Chocolate Doom engine (Emscripten, -O3)

doom1.wad ~1.7 MB DOOM shareware levels (freely distributable)

vector-doom.js ~160 KB Emscripten runtime (terser-minified, 58% reduction)

index.html ~12 KB UI, touch controls, gamepad support, CRT visual theme

webxdc-net.js ~3 KB Server election + packet routing

icon.png ~90 KB App icon

bg.jpg ~100 KB Background artwork

default.cfg ~2 KB Default key bindings

manifest.toml ~100 B WebXDC metadata

The WASM binary and WAD compress extremely well in ZIP (65% and 58% respectively), bringing the total to 4.2MB.

The build pipeline: 1. Emscripten compiles Chocolate Doom + our modifications to WASM (emmake make -j4) 2. webxdc-net.js is injected as --pre-js (runs before WASM initialises) 3. JS is minified with terser in parallel 4. HTML is minified (strip comments, collapse whitespace) 5. Everything zipped at maximum compression (zip -9)

The game runs on any WebXDC-compatible messenger. We built it for Vector (a Nostr-based messenger), but it works in Delta Chat and potentially any app that implements the WebXDC standard.

The Full Stack, From Keypress to Frag

Here's what happens when you press the fire button on your phone:
1. Your finger hits the Fire button (HTML touch event)
2. JavaScript calls Module._inject_key_event(0, 32)     // keydown, spacebar
3. DOOM's event queue receives ev_keydown
4. D_ProcessEvents() → G_Responder() builds ticcmd with BT_ATTACK
5. TryRunTics() executes the tic -your weapon fires, P_LineAttack() traces a hitscan
6. Bullet hits Player 2 → P_DamageMobj() → instead of applying damage:
   → NET_CL_SendDamageEvent(target=2, damage=50, source=you)
7. Every 2 tics, your position snapshot broadcasts via realtimeChannel:
   → JS encodes [to(4)][from(4)][snapshot] → WebSocket → Iroh gossip → peer devices
8. Host receives damage event → validates → applies → broadcasts HEALTH_AUTH
9. Player 2's screen: health drops, pain flash plays, kill message appears
10. Your screen: the host's HEALTH_AUTH confirms the kill
Total time from keypress to kill confirmation: roughly 100-200ms depending on network conditions. No servers touched. No corporation involved. Just two chat apps talking directly to each other.

Standing on the Shoulders of Giants

None of this would exist without:

id Software for open-sourcing the DOOM engine in 1997 -a decision that created an entire modding ecosystem and directly enabled everything described here

Chocolate Doom for faithfully recreating the original engine in portable, hackable C

Cloudflare for proving DOOM-in-WebAssembly was viable and open-sourcing their doom-wasm port -the foundation we forked

Emscripten for making C-to-WASM compilation actually work

Iroh (by n0.computer) for the QUIC-based P2P gossip protocol that makes serverless real-time gaming possible

The WebXDC community for defining an open standard for sandboxed web apps in chat messages

And a special note: the networking architecture of Open Source DOOM was designed and implemented as a collaboration between a human developer and an AI (Claude, by Anthropic). Not generated and pasted -collaborated on. Hundreds of iterations, debugging sessions at 3am with hex dumps of gossip packets, heated debates about whether to interpolate angles (don't), and moments of genuine surprise when things just... worked.

Try It

Open-Source DOOM is free, open-source, and available today.

Play it: Download Vector, open Vector Nexus (our decentralised in-app Mini App store), and find DOOM in the Multiplayer category. Send it to a friend or group chat and start fragging - no manual file management needed.

Read the code: The full source is available at github.com/nicholasopuni31/doom-wasm.

Build on it: The WebXDC realtime channel pattern we developed here works for any real-time multiplayer game.

If DOOM is "Hello, World" for computing, then Open Source DOOM is "Hello, World" for decentralised gaming.

Published March 2026. Written by JSKitty (npub16ye…g4wn)

	Cloudflare's DOOM	Open Source DOOM
Transport	WebSockets → Cloudflare Edge	P2P gossip via Iroh (QUIC)
Server	Durable Object (centralised)	Auto-elected from players (decentralised)
Sync model	Lockstep (1993 original)	Real-time hybrid (snapshots + interpolation)
Damage	Simulated locally by all clients	Host-authoritative events
NPCs/Monsters	Simulated locally by all clients	Host-authoritative snapshots
Late join	Not supported	Fully supported
Internet required	Yes (Cloudflare Workers)	No (works offline, P2P)
Delivery	Website (silentspacemarine.com)	4.2MB file in a chat message

File	Size (compressed)	Purpose
`vector-doom.wasm`	~2.7 MB	Chocolate Doom engine (Emscripten, -O3)
`doom1.wad`	~1.7 MB	DOOM shareware levels (freely distributable)
`vector-doom.js`	~160 KB	Emscripten runtime (terser-minified, 58% reduction)
`index.html`	~12 KB	UI, touch controls, gamepad support, CRT visual theme
`webxdc-net.js`	~3 KB	Server election + packet routing
`icon.png`	~90 KB	App icon
`bg.jpg`	~100 KB	Background artwork
`default.cfg`	~2 KB	Default key bindings
`manifest.toml`	~100 B	WebXDC metadata

Welcome to Nostr, Reddit. 19,000+ Views on r/doom: ...

2026-03-20T13:15:12Z

Welcome to Nostr, Reddit.

19,000+ Views on r/doom:

https://www.reddit.com/r/Doom/comments/1rxezsc/opensource_doom_realtime_multiplayer_with_no/

quoting naddr1qv…ars5

Open-Source DOOM: How We Brought Real-Time Multiplayer to a 1993 Classic. No Servers Required.

A Breakthrough in Decentralized Gaming by JSKitty (npub16ye…g4wn)

In May 2021, Cloudflare did something wonderful. They took DOOM -the 1993 game that defined an entire genre -compiled it to WebAssembly, wired up WebSocket multiplayer through their Durable Objects edge platform, and wrote a fantastic blog post about it. As Celso Martinho put it: "Running Doom is effectively the new 'Hello, World' in computing."

We loved it. And then we thought: what if we could take it further?

What if multiplayer DOOM didn't need Cloudflare's servers -or anyone's servers? What if it didn't need the internet at all? What if you could send a 4MB file to a friend in a chat message and be fragging each other within seconds, purely peer-to-peer, with the game feeling like a modern real-time shooter instead of a 1994 LAN party?

That's what we built. We call it Open-Source DOOM.

It's powered by a stack of open technologies: Chocolate Doom compiled to WebAssembly via Emscripten, distributed as a WebXDC mini-app, with peer discovery over Nostr, end-to-end encryption via Marmot (MLS over Nostr), and real-time P2P data transport through Iroh (QUIC-based gossip). Every layer is open-source. Every packet is encrypted. No servers required.

What Cloudflare Built (And Why It's Great)

Credit where it's due. Cloudflare's doom-wasm project did the hard work of porting Chocolate Doom -> the faithful open-source recreation of the original DOOM engine -> to WebAssembly using Emscripten. That alone is a serious engineering effort. They then wrote net_websockets.c, a transport adapter that replaced DOOM's original IPX/UDP networking with WebSocket connections routed through Durable Objects on Cloudflare's edge network.

Their architecture looked like this:
Player A (Browser)  ←WebSocket→  Cloudflare Edge (Durable Object)  ←WebSocket→  Player B (Browser)
A Durable Object acted as the game room -maintaining a routing table of connected players and forwarding packets between them. Clean, elegant, and a great demo of edge computing.

But there was a catch.

What they kept the same

Cloudflare didn't modify DOOM's actual netcode. The game still used its original lockstep networking model from 1993 -the same protocol designed for four PCs on a local area network connected by coaxial cable. Every player sends their inputs (which keys they pressed) to every other player, every single frame, and the game freezes until everyone's inputs arrive.

As their blog post acknowledged: "The game only advances when everyone receives the commands from all the other players in the group."

This worked in 1993 when your LAN had sub-millisecond latency. Over the internet, through WebSockets, through a routing layer? It meant choppy gameplay, freezes whenever anyone's connection hiccupped, and a gameplay experience that felt more like a slideshow than a shooter.

The Durable Object was also a single point of failure and a centralised dependency. No Cloudflare, no DOOM.

What We Changed (Everything Except the Game Itself)

We forked Cloudflare's doom-wasm project and rebuilt the entire networking stack from scratch. Not just the transport layer -the fundamental model of how the game synchronises state between players.

Here's the before and after:

Cloudflare's DOOM Open Source DOOM

Transport WebSockets → Cloudflare Edge P2P gossip via Iroh (QUIC)

Server Durable Object (centralised) Auto-elected from players (decentralised)

Sync model Lockstep (1993 original) Real-time hybrid (snapshots + interpolation)

Damage Simulated locally by all clients Host-authoritative events

NPCs/Monsters Simulated locally by all clients Host-authoritative snapshots

Late join Not supported Fully supported

Internet required Yes (Cloudflare Workers) No (works offline, P2P)

Delivery Website (silentspacemarine.com) 4.2MB file in a chat message

Let's break down each piece.

1. No Servers, No Problem

The Simple Version

Cloudflare's DOOM needed their servers to work. Ours doesn't need any servers. When you open the game, your device automatically figures out who should be the "host" --no configuration, no IP addresses, no port forwarding, no sign-ups. It just works.

The game runs inside a .xdc file, essentially a tiny 4.2MB zip archive containing the entire game. You literally send it as a file in a chat message. Your friend opens it. You're playing DOOM together. The data travels directly between your devices through the chat app's peer-to-peer channels.

The Nerdy Version

We replaced net_websockets.c with net_webxdc.c -a transport module that speaks the WebXDC realtime channel protocol instead of WebSockets.

WebXDC is an open standard for sandboxed web apps distributed inside chat messages. The app has zero internet access, no fetch, no XMLHttpRequest, nothing. The only communication channel is webxdc.joinRealtimeChannel(), which gives you an unreliable broadcast pipe to other instances of the same .xdc file in the same chat.

Under the hood (in our primary platform, Vector), this channel is backed by Iroh, a QUIC-based peer-to-peer gossip protocol. Messages travel directly between devices, relayed through lightweight Iroh relay nodes only when direct connections aren't possible. There are no game servers, no routing tables, no Durable Objects.

Peer discovery happens over Nostr, the decentralised social protocol. When you open a game, your Iroh node address is published as a Nostr event so other players can find you and establish a direct connection. The connection itself is encrypted end-to-end via Marmot, which implements the MLS (Messaging Layer Security) protocol over Nostr. So every packet of DOOM multiplayer data, every position snapshot, every damage event, every frag, is encrypted with forward secrecy before it ever leaves your device.

The wire format is minimal:
[to: uint32 LE (4 bytes)][from: uint32 LE (4 bytes)][doom_payload]
JavaScript routes incoming packets by destination UID -only packets addressed to you (or broadcast address 0) get delivered to the WASM engine. Everything else is silently dropped.

For performance, Vector provides a WebSocket fast-path: the app connects to ws://127.0.0.1:{random_port}/{token} -a localhost WebSocket server spun up by the Rust backend -giving near-zero-latency access to the Iroh gossip sender. Binary frames go straight to sender.broadcast() with zero copies. Fallback path uses Tauri invoke with base91 encoding.

2. Who's the Server? Magic.

The Simple Version

In a normal online game, someone runs a server, and everyone connects to it. In Open Source DOOM, there is no predetermined server. When you open the game, all players silently negotiate who becomes the host. The person who opened the game first wins. This happens automatically in about three seconds, and you never even notice it.

The Nerdy Version

Server election uses a dead-simple timestamp protocol over the broadcast channel:

Every instance broadcasts 4 magic bytes ([42, 42, 42, 42]) every 300ms: "I exist, who's the server?"

Every instance responds to discovery requests with: [43, 43, 43, 43][padding(4)][timestamp(8)] -where timestamp is Date.now() from when the app first opened

The instance with the earliest timestamp wins

After 3 seconds with no earlier challenger, you declare yourself server

The elected server re-broadcasts its beacon every 3 seconds so late-joiners can discover it

The server gets instanceUID = 1 (hardcoded). Clients get a random UID in 1–65534. This UID becomes their network address for the entire session -no DNS, no IP addresses, no NAT traversal headaches.

The whole election algorithm is about 80 lines of JavaScript. It works over any broadcast transport. No configuration needed.

3. From Lockstep to Real-Time (The Big One)

The Simple Version

Original DOOM multiplayer works like a group of people writing a letter round-robin. Nobody can write their next line until everyone has received and read the previous line. If one person is slow, everyone waits.

We changed it to work more like a live conversation. Everyone talks at their own pace. If you miss a word, you can still follow along because the speaker periodically summarises where things stand. The result feels like a modern shooter -smooth movement, responsive controls, no freezing.

The Nerdy Version

This was the most fundamental change: replacing DOOM's pure lockstep synchronisation with a hybrid real-time model. The ticcmd backbone remains (it's too deeply embedded in Chocolate Doom's deterministic physics to remove), but we layered three correction systems on top:

a) Position Snapshots + Exponential Smoothing

Every 2 tics (~57ms at 35 FPS), each player broadcasts a snapshot of their state:
int data[9] = {
    mo->x, mo->y, mo->z,        // World position (fixed-point)
    mo->angle,                    // Facing direction
    mo->momx, mo->momy, mo->momz, // Velocity
    attack_weapon,                // 0=idle, 1-9=attacking with weapon N
    latency                       // Round-trip time (ms)
};
Remote players don't run DOOM's physics engine at all. Instead, D_TickPlayerInterp() runs every tic:
Extrapolate the target forward using stored momentum: target_x += momx
Smooth toward the target, closing 60% of the remaining gap each tic:
#define INTERP_FRAC  39322  // 0.6 * 65536 (fixed-point)
mo->x += FixedMul(target_x - mo->x, INTERP_FRAC);
mo->y += FixedMul(target_y - mo->y, INTERP_FRAC);
Teleport detection: if the delta exceeds 128 map units, snap instantly (player respawned or hit a teleporter)
One subtle but critical detail: angle is NOT interpolated. The ticcmd's angleturn field is applied deterministically by P_MovePlayer() and stays in sync across machines. Interpolating angle toward a stale snapshot would fight the ticcmd, causing visible rotation jitter of up to 90 degrees. We learned this the hard way.

b) Attack Animation Sync

Remote players' attacks are driven by snapshot data, not ticcmds. When a snapshot reports attack_weapon > 0, we set the S_PLAY_ATK1 animation state and play the weapon fire sound. An 8-tic animation lock prevents local state transitions from overriding it.

To prevent feedback loops, we track last_received_attack[] -the raw flag as received from the network -and broadcast that, not the lock-modified mobj state. Without this, attack animations would echo infinitely.

4. "I Shot You!" "No You Didn't!"

The Simple Version

In the original DOOM, every computer runs its own copy of the game physics. When you shoot someone, your computer calculates the damage, and their computer calculates the damage, and because the game is in lockstep, they always agree.

With our real-time model, that guarantee vanishes -your screen and theirs might show slightly different positions. So we made one player (the host) the referee. When you shoot someone, you tell the host "I hit Player 2 for 50 damage". The host checks the physics, applies the damage if it's valid, and announces the result to everyone. One truth, no arguments.

The Nerdy Version

We implemented an event-based host-authority model for all game-changing state:

Damage path:
Client A fires weapon → bullet hits Player B locally
  → Client A sends DAMAGE_EVENT to host: {target: B, damage: 50, source: A}
  → Client A applies VISUAL FEEDBACK ONLY (screen flash, attacker tracking)
  → Client A does NOT reduce Player B's health

Host receives DAMAGE_EVENT:
  → Sets damage_from_event = true (bypasses remote-source skip)
  → Calls P_DamageMobj() with full physics simulation
  → New health broadcasted via HEALTH_AUTH packet next snapshot cycle

All clients receive HEALTH_AUTH:
  → Apply as ground truth
  → Host says dead, client says alive? → P_KillMobj()
  → Host says alive, client says dead? → Trigger respawn
  → Health decreased? → Play pain animation
The damage_from_event flag is critical. Without it, the host faces a double-damage problem: it receives both the ticcmd attack (from the lockstep backbone) AND the explicit damage event. The flag ensures only the event path applies.

Other host-authoritative systems: - USE events: Client presses 'E' near a door → sends USE_EVENT → host calls P_UseLines() → door opens for everyone - Respawns: Client dies → sends RESPAWN_REQUEST → host sets playerstate = PST_REBORN - Kill messages: Host broadcasts KILL_MSG when a player dies → displayed on all screens

5. Making Monsters Agree

The Simple Version

DOOM has dozens of monsters per level, each running their own AI -chasing you, shooting fireballs, infighting with each other. In the original game, every computer simulates every monster identically (because lockstep ensures they all see the same inputs). In our version, only the host simulates the monsters. Everyone else just sees the results -like watching a puppet show where only the puppeteer knows the script, but the audience sees the performance in real-time.

The Nerdy Version

We built a full NPC synchronisation system (p_netsync.c/h):

Registry: Every monster and barrel gets a unique net_id via P_NetAssignId():
mobj_t *net_mobj_table[MAX_NET_MOBJS];  // 512 slots
unsigned short net_id_counter;            // Sequential allocator
Host broadcasts (every 2 tics) a compact binary snapshot:
[npc_count: u8][gametic: u16]
Per NPC (20 bytes): net_id(2) x(4) y(4) z(4) angle(1) statenum(2) health(2) flags(1)
[sector_count: u8]
Per changed sector (10 bytes): sector_id(2) ceiling(4) floor(4)
[missile_count: u8]
Per missile (32 bytes): source_net_id(2) type(2) x(4) y(4) z(4) momx(4) momy(4) momz(4) angle(4)
Client-side: In P_MobjThinker(), clients skip physics entirely for any mobj with net_id > 0. Only the animation tic counter runs. State changes use P_SetMobjStateNoAction() -which applies the visual state WITHOUT executing action functions. This prevents clients from independently spawning projectiles, running AI decisions, or playing duplicate sounds.

The sector data keeps doors and lifts in sync. The missile data ensures fireballs and rockets appear on all screens.

6. "Room for One More?" -Mid-Game Joining

The Simple Version

Original DOOM didn't let you join a game already in progress. Everyone had to be there at the start, or too bad. Our version lets players drop in mid-game. You open the .xdc, the game finds the server, and you spawn in -even if everyone else is already knee-deep in the dead.

The Nerdy Version

Late joining required solving several hairy problems:

Tic synchronisation: The late joiner's tic counter is meaningless -they weren't there for tics 0 through N. When the server accepts a late join, it sends settings->start_tic set to the current server tic. The client aligns its recvtic, maketic, and gametic to this value, syncing the 8-bit tic sequence numbers with the server's counter.

Double-slot bug: We found that NET_SV_AssignPlayers() could assign the new client to a slot that was already used, creating a ghost duplicate. The fix: HandleLateJoin() explicitly clears any pre-existing slots for the new client before assigning a fresh one.

Ghost body cleanup: When a player disconnects and reconnects (or the quit/rejoin cycle fires), their old mobj lingers in the world as an invisible collision obstacle. P_SpawnPlayer() now checks for and removes any existing mobj before spawning:
if (p->mo) {
    p->mo->player = NULL;
    P_RemoveMobj(p->mo);
    p->mo = NULL;
}
Name propagation: When a new player joins, every existing player re-broadcasts their name, so the joiner's HUD displays the correct names instead of the defaults ("Green", "Indigo", "Brown", "Red").

7. Fits in a Chat Message

The Simple Version

The entire game -engine, levels, monsters, weapons, networking, touch controls, gamepad support, all of it -fits in a 4.2 megabyte file. That's smaller than most photos your phone takes. You send it in a chat message like you'd send a meme. Your friend taps it, and they're in the game. No app store, no downloads, no accounts, no updates.

The Nerdy Version

The .xdc format is just a ZIP archive with a different extension. Ours contains:

File Size (compressed) Purpose

vector-doom.wasm ~2.7 MB Chocolate Doom engine (Emscripten, -O3)

doom1.wad ~1.7 MB DOOM shareware levels (freely distributable)

vector-doom.js ~160 KB Emscripten runtime (terser-minified, 58% reduction)

index.html ~12 KB UI, touch controls, gamepad support, CRT visual theme

webxdc-net.js ~3 KB Server election + packet routing

icon.png ~90 KB App icon

bg.jpg ~100 KB Background artwork

default.cfg ~2 KB Default key bindings

manifest.toml ~100 B WebXDC metadata

The WASM binary and WAD compress extremely well in ZIP (65% and 58% respectively), bringing the total to 4.2MB.

The build pipeline: 1. Emscripten compiles Chocolate Doom + our modifications to WASM (emmake make -j4) 2. webxdc-net.js is injected as --pre-js (runs before WASM initialises) 3. JS is minified with terser in parallel 4. HTML is minified (strip comments, collapse whitespace) 5. Everything zipped at maximum compression (zip -9)

The game runs on any WebXDC-compatible messenger. We built it for Vector (a Nostr-based messenger), but it works in Delta Chat and potentially any app that implements the WebXDC standard.

The Full Stack, From Keypress to Frag

Here's what happens when you press the fire button on your phone:
1. Your finger hits the Fire button (HTML touch event)
2. JavaScript calls Module._inject_key_event(0, 32)     // keydown, spacebar
3. DOOM's event queue receives ev_keydown
4. D_ProcessEvents() → G_Responder() builds ticcmd with BT_ATTACK
5. TryRunTics() executes the tic -your weapon fires, P_LineAttack() traces a hitscan
6. Bullet hits Player 2 → P_DamageMobj() → instead of applying damage:
   → NET_CL_SendDamageEvent(target=2, damage=50, source=you)
7. Every 2 tics, your position snapshot broadcasts via realtimeChannel:
   → JS encodes [to(4)][from(4)][snapshot] → WebSocket → Iroh gossip → peer devices
8. Host receives damage event → validates → applies → broadcasts HEALTH_AUTH
9. Player 2's screen: health drops, pain flash plays, kill message appears
10. Your screen: the host's HEALTH_AUTH confirms the kill
Total time from keypress to kill confirmation: roughly 100-200ms depending on network conditions. No servers touched. No corporation involved. Just two chat apps talking directly to each other.

Standing on the Shoulders of Giants

None of this would exist without:

id Software for open-sourcing the DOOM engine in 1997 -a decision that created an entire modding ecosystem and directly enabled everything described here

Chocolate Doom for faithfully recreating the original engine in portable, hackable C

Cloudflare for proving DOOM-in-WebAssembly was viable and open-sourcing their doom-wasm port -the foundation we forked

Emscripten for making C-to-WASM compilation actually work

Iroh (by n0.computer) for the QUIC-based P2P gossip protocol that makes serverless real-time gaming possible

The WebXDC community for defining an open standard for sandboxed web apps in chat messages

And a special note: the networking architecture of Open Source DOOM was designed and implemented as a collaboration between a human developer and an AI (Claude, by Anthropic). Not generated and pasted -collaborated on. Hundreds of iterations, debugging sessions at 3am with hex dumps of gossip packets, heated debates about whether to interpolate angles (don't), and moments of genuine surprise when things just... worked.

Try It

Open-Source DOOM is free, open-source, and available today.

Play it: Download Vector, open Vector Nexus (our decentralised in-app Mini App store), and find DOOM in the Multiplayer category. Send it to a friend or group chat and start fragging - no manual file management needed.

Read the code: The full source is available at github.com/nicholasopuni31/doom-wasm.

Build on it: The WebXDC realtime channel pattern we developed here works for any real-time multiplayer game.

If DOOM is "Hello, World" for computing, then Open Source DOOM is "Hello, World" for decentralised gaming.

Published March 2026. Written by JSKitty (npub16ye…g4wn)

	Cloudflare's DOOM	Open Source DOOM
Transport	WebSockets → Cloudflare Edge	P2P gossip via Iroh (QUIC)
Server	Durable Object (centralised)	Auto-elected from players (decentralised)
Sync model	Lockstep (1993 original)	Real-time hybrid (snapshots + interpolation)
Damage	Simulated locally by all clients	Host-authoritative events
NPCs/Monsters	Simulated locally by all clients	Host-authoritative snapshots
Late join	Not supported	Fully supported
Internet required	Yes (Cloudflare Workers)	No (works offline, P2P)
Delivery	Website (silentspacemarine.com)	4.2MB file in a chat message

File	Size (compressed)	Purpose
`vector-doom.wasm`	~2.7 MB	Chocolate Doom engine (Emscripten, -O3)
`doom1.wad`	~1.7 MB	DOOM shareware levels (freely distributable)
`vector-doom.js`	~160 KB	Emscripten runtime (terser-minified, 58% reduction)
`index.html`	~12 KB	UI, touch controls, gamepad support, CRT visual theme
`webxdc-net.js`	~3 KB	Server election + packet routing
`icon.png`	~90 KB	App icon
`bg.jpg`	~100 KB	Background artwork
`default.cfg`	~2 KB	Default key bindings
`manifest.toml`	~100 B	WebXDC metadata

Yes sir, your eyes do not deceive you. ...

2026-03-19T12:35:57Z

In reply to nevent1q…dvkq
_________________________

Yes sir, your eyes do not deceive you.

and 2026 is still beginning!

2026-03-19T10:49:51Z

In reply to nevent1q…4d3c
_________________________

and 2026 is still beginning!

Should we start hosting some Game Nights on Nostr? ...

2026-03-19T05:55:47Z

Should we start hosting some Game Nights on Nostr?

quoting naddr1qv…ars5

Open-Source DOOM: How We Brought Real-Time Multiplayer to a 1993 Classic. No Servers Required.

A Breakthrough in Decentralized Gaming by JSKitty (npub16ye…g4wn)

In May 2021, Cloudflare did something wonderful. They took DOOM -the 1993 game that defined an entire genre -compiled it to WebAssembly, wired up WebSocket multiplayer through their Durable Objects edge platform, and wrote a fantastic blog post about it. As Celso Martinho put it: "Running Doom is effectively the new 'Hello, World' in computing."

We loved it. And then we thought: what if we could take it further?

What if multiplayer DOOM didn't need Cloudflare's servers -or anyone's servers? What if it didn't need the internet at all? What if you could send a 4MB file to a friend in a chat message and be fragging each other within seconds, purely peer-to-peer, with the game feeling like a modern real-time shooter instead of a 1994 LAN party?

That's what we built. We call it Open-Source DOOM.

It's powered by a stack of open technologies: Chocolate Doom compiled to WebAssembly via Emscripten, distributed as a WebXDC mini-app, with peer discovery over Nostr, end-to-end encryption via Marmot (MLS over Nostr), and real-time P2P data transport through Iroh (QUIC-based gossip). Every layer is open-source. Every packet is encrypted. No servers required.

What Cloudflare Built (And Why It's Great)

Credit where it's due. Cloudflare's doom-wasm project did the hard work of porting Chocolate Doom -> the faithful open-source recreation of the original DOOM engine -> to WebAssembly using Emscripten. That alone is a serious engineering effort. They then wrote net_websockets.c, a transport adapter that replaced DOOM's original IPX/UDP networking with WebSocket connections routed through Durable Objects on Cloudflare's edge network.

Their architecture looked like this:
Player A (Browser)  ←WebSocket→  Cloudflare Edge (Durable Object)  ←WebSocket→  Player B (Browser)
A Durable Object acted as the game room -maintaining a routing table of connected players and forwarding packets between them. Clean, elegant, and a great demo of edge computing.

But there was a catch.

What they kept the same

Cloudflare didn't modify DOOM's actual netcode. The game still used its original lockstep networking model from 1993 -the same protocol designed for four PCs on a local area network connected by coaxial cable. Every player sends their inputs (which keys they pressed) to every other player, every single frame, and the game freezes until everyone's inputs arrive.

As their blog post acknowledged: "The game only advances when everyone receives the commands from all the other players in the group."

This worked in 1993 when your LAN had sub-millisecond latency. Over the internet, through WebSockets, through a routing layer? It meant choppy gameplay, freezes whenever anyone's connection hiccupped, and a gameplay experience that felt more like a slideshow than a shooter.

The Durable Object was also a single point of failure and a centralised dependency. No Cloudflare, no DOOM.

What We Changed (Everything Except the Game Itself)

We forked Cloudflare's doom-wasm project and rebuilt the entire networking stack from scratch. Not just the transport layer -the fundamental model of how the game synchronises state between players.

Here's the before and after:

Cloudflare's DOOM Open Source DOOM

Transport WebSockets → Cloudflare Edge P2P gossip via Iroh (QUIC)

Server Durable Object (centralised) Auto-elected from players (decentralised)

Sync model Lockstep (1993 original) Real-time hybrid (snapshots + interpolation)

Damage Simulated locally by all clients Host-authoritative events

NPCs/Monsters Simulated locally by all clients Host-authoritative snapshots

Late join Not supported Fully supported

Internet required Yes (Cloudflare Workers) No (works offline, P2P)

Delivery Website (silentspacemarine.com) 4.2MB file in a chat message

Let's break down each piece.

1. No Servers, No Problem

The Simple Version

Cloudflare's DOOM needed their servers to work. Ours doesn't need any servers. When you open the game, your device automatically figures out who should be the "host" --no configuration, no IP addresses, no port forwarding, no sign-ups. It just works.

The game runs inside a .xdc file, essentially a tiny 4.2MB zip archive containing the entire game. You literally send it as a file in a chat message. Your friend opens it. You're playing DOOM together. The data travels directly between your devices through the chat app's peer-to-peer channels.

The Nerdy Version

We replaced net_websockets.c with net_webxdc.c -a transport module that speaks the WebXDC realtime channel protocol instead of WebSockets.

WebXDC is an open standard for sandboxed web apps distributed inside chat messages. The app has zero internet access, no fetch, no XMLHttpRequest, nothing. The only communication channel is webxdc.joinRealtimeChannel(), which gives you an unreliable broadcast pipe to other instances of the same .xdc file in the same chat.

Under the hood (in our primary platform, Vector), this channel is backed by Iroh, a QUIC-based peer-to-peer gossip protocol. Messages travel directly between devices, relayed through lightweight Iroh relay nodes only when direct connections aren't possible. There are no game servers, no routing tables, no Durable Objects.

Peer discovery happens over Nostr, the decentralised social protocol. When you open a game, your Iroh node address is published as a Nostr event so other players can find you and establish a direct connection. The connection itself is encrypted end-to-end via Marmot, which implements the MLS (Messaging Layer Security) protocol over Nostr. So every packet of DOOM multiplayer data, every position snapshot, every damage event, every frag, is encrypted with forward secrecy before it ever leaves your device.

The wire format is minimal:
[to: uint32 LE (4 bytes)][from: uint32 LE (4 bytes)][doom_payload]
JavaScript routes incoming packets by destination UID -only packets addressed to you (or broadcast address 0) get delivered to the WASM engine. Everything else is silently dropped.

For performance, Vector provides a WebSocket fast-path: the app connects to ws://127.0.0.1:{random_port}/{token} -a localhost WebSocket server spun up by the Rust backend -giving near-zero-latency access to the Iroh gossip sender. Binary frames go straight to sender.broadcast() with zero copies. Fallback path uses Tauri invoke with base91 encoding.

2. Who's the Server? Magic.

The Simple Version

In a normal online game, someone runs a server, and everyone connects to it. In Open Source DOOM, there is no predetermined server. When you open the game, all players silently negotiate who becomes the host. The person who opened the game first wins. This happens automatically in about three seconds, and you never even notice it.

The Nerdy Version

Server election uses a dead-simple timestamp protocol over the broadcast channel:

Every instance broadcasts 4 magic bytes ([42, 42, 42, 42]) every 300ms: "I exist, who's the server?"

Every instance responds to discovery requests with: [43, 43, 43, 43][padding(4)][timestamp(8)] -where timestamp is Date.now() from when the app first opened

The instance with the earliest timestamp wins

After 3 seconds with no earlier challenger, you declare yourself server

The elected server re-broadcasts its beacon every 3 seconds so late-joiners can discover it

The server gets instanceUID = 1 (hardcoded). Clients get a random UID in 1–65534. This UID becomes their network address for the entire session -no DNS, no IP addresses, no NAT traversal headaches.

The whole election algorithm is about 80 lines of JavaScript. It works over any broadcast transport. No configuration needed.

3. From Lockstep to Real-Time (The Big One)

The Simple Version

Original DOOM multiplayer works like a group of people writing a letter round-robin. Nobody can write their next line until everyone has received and read the previous line. If one person is slow, everyone waits.

We changed it to work more like a live conversation. Everyone talks at their own pace. If you miss a word, you can still follow along because the speaker periodically summarises where things stand. The result feels like a modern shooter -smooth movement, responsive controls, no freezing.

The Nerdy Version

This was the most fundamental change: replacing DOOM's pure lockstep synchronisation with a hybrid real-time model. The ticcmd backbone remains (it's too deeply embedded in Chocolate Doom's deterministic physics to remove), but we layered three correction systems on top:

a) Position Snapshots + Exponential Smoothing

Every 2 tics (~57ms at 35 FPS), each player broadcasts a snapshot of their state:
int data[9] = {
    mo->x, mo->y, mo->z,        // World position (fixed-point)
    mo->angle,                    // Facing direction
    mo->momx, mo->momy, mo->momz, // Velocity
    attack_weapon,                // 0=idle, 1-9=attacking with weapon N
    latency                       // Round-trip time (ms)
};
Remote players don't run DOOM's physics engine at all. Instead, D_TickPlayerInterp() runs every tic:
Extrapolate the target forward using stored momentum: target_x += momx
Smooth toward the target, closing 60% of the remaining gap each tic:
#define INTERP_FRAC  39322  // 0.6 * 65536 (fixed-point)
mo->x += FixedMul(target_x - mo->x, INTERP_FRAC);
mo->y += FixedMul(target_y - mo->y, INTERP_FRAC);
Teleport detection: if the delta exceeds 128 map units, snap instantly (player respawned or hit a teleporter)
One subtle but critical detail: angle is NOT interpolated. The ticcmd's angleturn field is applied deterministically by P_MovePlayer() and stays in sync across machines. Interpolating angle toward a stale snapshot would fight the ticcmd, causing visible rotation jitter of up to 90 degrees. We learned this the hard way.

b) Attack Animation Sync

Remote players' attacks are driven by snapshot data, not ticcmds. When a snapshot reports attack_weapon > 0, we set the S_PLAY_ATK1 animation state and play the weapon fire sound. An 8-tic animation lock prevents local state transitions from overriding it.

To prevent feedback loops, we track last_received_attack[] -the raw flag as received from the network -and broadcast that, not the lock-modified mobj state. Without this, attack animations would echo infinitely.

4. "I Shot You!" "No You Didn't!"

The Simple Version

In the original DOOM, every computer runs its own copy of the game physics. When you shoot someone, your computer calculates the damage, and their computer calculates the damage, and because the game is in lockstep, they always agree.

With our real-time model, that guarantee vanishes -your screen and theirs might show slightly different positions. So we made one player (the host) the referee. When you shoot someone, you tell the host "I hit Player 2 for 50 damage". The host checks the physics, applies the damage if it's valid, and announces the result to everyone. One truth, no arguments.

The Nerdy Version

We implemented an event-based host-authority model for all game-changing state:

Damage path:
Client A fires weapon → bullet hits Player B locally
  → Client A sends DAMAGE_EVENT to host: {target: B, damage: 50, source: A}
  → Client A applies VISUAL FEEDBACK ONLY (screen flash, attacker tracking)
  → Client A does NOT reduce Player B's health

Host receives DAMAGE_EVENT:
  → Sets damage_from_event = true (bypasses remote-source skip)
  → Calls P_DamageMobj() with full physics simulation
  → New health broadcasted via HEALTH_AUTH packet next snapshot cycle

All clients receive HEALTH_AUTH:
  → Apply as ground truth
  → Host says dead, client says alive? → P_KillMobj()
  → Host says alive, client says dead? → Trigger respawn
  → Health decreased? → Play pain animation
The damage_from_event flag is critical. Without it, the host faces a double-damage problem: it receives both the ticcmd attack (from the lockstep backbone) AND the explicit damage event. The flag ensures only the event path applies.

Other host-authoritative systems: - USE events: Client presses 'E' near a door → sends USE_EVENT → host calls P_UseLines() → door opens for everyone - Respawns: Client dies → sends RESPAWN_REQUEST → host sets playerstate = PST_REBORN - Kill messages: Host broadcasts KILL_MSG when a player dies → displayed on all screens

5. Making Monsters Agree

The Simple Version

DOOM has dozens of monsters per level, each running their own AI -chasing you, shooting fireballs, infighting with each other. In the original game, every computer simulates every monster identically (because lockstep ensures they all see the same inputs). In our version, only the host simulates the monsters. Everyone else just sees the results -like watching a puppet show where only the puppeteer knows the script, but the audience sees the performance in real-time.

The Nerdy Version

We built a full NPC synchronisation system (p_netsync.c/h):

Registry: Every monster and barrel gets a unique net_id via P_NetAssignId():
mobj_t *net_mobj_table[MAX_NET_MOBJS];  // 512 slots
unsigned short net_id_counter;            // Sequential allocator
Host broadcasts (every 2 tics) a compact binary snapshot:
[npc_count: u8][gametic: u16]
Per NPC (20 bytes): net_id(2) x(4) y(4) z(4) angle(1) statenum(2) health(2) flags(1)
[sector_count: u8]
Per changed sector (10 bytes): sector_id(2) ceiling(4) floor(4)
[missile_count: u8]
Per missile (32 bytes): source_net_id(2) type(2) x(4) y(4) z(4) momx(4) momy(4) momz(4) angle(4)
Client-side: In P_MobjThinker(), clients skip physics entirely for any mobj with net_id > 0. Only the animation tic counter runs. State changes use P_SetMobjStateNoAction() -which applies the visual state WITHOUT executing action functions. This prevents clients from independently spawning projectiles, running AI decisions, or playing duplicate sounds.

The sector data keeps doors and lifts in sync. The missile data ensures fireballs and rockets appear on all screens.

6. "Room for One More?" -Mid-Game Joining

The Simple Version

Original DOOM didn't let you join a game already in progress. Everyone had to be there at the start, or too bad. Our version lets players drop in mid-game. You open the .xdc, the game finds the server, and you spawn in -even if everyone else is already knee-deep in the dead.

The Nerdy Version

Late joining required solving several hairy problems:

Tic synchronisation: The late joiner's tic counter is meaningless -they weren't there for tics 0 through N. When the server accepts a late join, it sends settings->start_tic set to the current server tic. The client aligns its recvtic, maketic, and gametic to this value, syncing the 8-bit tic sequence numbers with the server's counter.

Double-slot bug: We found that NET_SV_AssignPlayers() could assign the new client to a slot that was already used, creating a ghost duplicate. The fix: HandleLateJoin() explicitly clears any pre-existing slots for the new client before assigning a fresh one.

Ghost body cleanup: When a player disconnects and reconnects (or the quit/rejoin cycle fires), their old mobj lingers in the world as an invisible collision obstacle. P_SpawnPlayer() now checks for and removes any existing mobj before spawning:
if (p->mo) {
    p->mo->player = NULL;
    P_RemoveMobj(p->mo);
    p->mo = NULL;
}
Name propagation: When a new player joins, every existing player re-broadcasts their name, so the joiner's HUD displays the correct names instead of the defaults ("Green", "Indigo", "Brown", "Red").

7. Fits in a Chat Message

The Simple Version

The entire game -engine, levels, monsters, weapons, networking, touch controls, gamepad support, all of it -fits in a 4.2 megabyte file. That's smaller than most photos your phone takes. You send it in a chat message like you'd send a meme. Your friend taps it, and they're in the game. No app store, no downloads, no accounts, no updates.

The Nerdy Version

The .xdc format is just a ZIP archive with a different extension. Ours contains:

File Size (compressed) Purpose

vector-doom.wasm ~2.7 MB Chocolate Doom engine (Emscripten, -O3)

doom1.wad ~1.7 MB DOOM shareware levels (freely distributable)

vector-doom.js ~160 KB Emscripten runtime (terser-minified, 58% reduction)

index.html ~12 KB UI, touch controls, gamepad support, CRT visual theme

webxdc-net.js ~3 KB Server election + packet routing

icon.png ~90 KB App icon

bg.jpg ~100 KB Background artwork

default.cfg ~2 KB Default key bindings

manifest.toml ~100 B WebXDC metadata

The WASM binary and WAD compress extremely well in ZIP (65% and 58% respectively), bringing the total to 4.2MB.

The build pipeline: 1. Emscripten compiles Chocolate Doom + our modifications to WASM (emmake make -j4) 2. webxdc-net.js is injected as --pre-js (runs before WASM initialises) 3. JS is minified with terser in parallel 4. HTML is minified (strip comments, collapse whitespace) 5. Everything zipped at maximum compression (zip -9)

The game runs on any WebXDC-compatible messenger. We built it for Vector (a Nostr-based messenger), but it works in Delta Chat and potentially any app that implements the WebXDC standard.

The Full Stack, From Keypress to Frag

Here's what happens when you press the fire button on your phone:
1. Your finger hits the Fire button (HTML touch event)
2. JavaScript calls Module._inject_key_event(0, 32)     // keydown, spacebar
3. DOOM's event queue receives ev_keydown
4. D_ProcessEvents() → G_Responder() builds ticcmd with BT_ATTACK
5. TryRunTics() executes the tic -your weapon fires, P_LineAttack() traces a hitscan
6. Bullet hits Player 2 → P_DamageMobj() → instead of applying damage:
   → NET_CL_SendDamageEvent(target=2, damage=50, source=you)
7. Every 2 tics, your position snapshot broadcasts via realtimeChannel:
   → JS encodes [to(4)][from(4)][snapshot] → WebSocket → Iroh gossip → peer devices
8. Host receives damage event → validates → applies → broadcasts HEALTH_AUTH
9. Player 2's screen: health drops, pain flash plays, kill message appears
10. Your screen: the host's HEALTH_AUTH confirms the kill
Total time from keypress to kill confirmation: roughly 100-200ms depending on network conditions. No servers touched. No corporation involved. Just two chat apps talking directly to each other.

Standing on the Shoulders of Giants

None of this would exist without:

id Software for open-sourcing the DOOM engine in 1997 -a decision that created an entire modding ecosystem and directly enabled everything described here

Chocolate Doom for faithfully recreating the original engine in portable, hackable C

Cloudflare for proving DOOM-in-WebAssembly was viable and open-sourcing their doom-wasm port -the foundation we forked

Emscripten for making C-to-WASM compilation actually work

Iroh (by n0.computer) for the QUIC-based P2P gossip protocol that makes serverless real-time gaming possible

The WebXDC community for defining an open standard for sandboxed web apps in chat messages

And a special note: the networking architecture of Open Source DOOM was designed and implemented as a collaboration between a human developer and an AI (Claude, by Anthropic). Not generated and pasted -collaborated on. Hundreds of iterations, debugging sessions at 3am with hex dumps of gossip packets, heated debates about whether to interpolate angles (don't), and moments of genuine surprise when things just... worked.

Try It

Open-Source DOOM is free, open-source, and available today.

Play it: Download Vector, open Vector Nexus (our decentralised in-app Mini App store), and find DOOM in the Multiplayer category. Send it to a friend or group chat and start fragging - no manual file management needed.

Read the code: The full source is available at github.com/nicholasopuni31/doom-wasm.

Build on it: The WebXDC realtime channel pattern we developed here works for any real-time multiplayer game.

If DOOM is "Hello, World" for computing, then Open Source DOOM is "Hello, World" for decentralised gaming.

Published March 2026. Written by JSKitty (npub16ye…g4wn)

	Cloudflare's DOOM	Open Source DOOM
Transport	WebSockets → Cloudflare Edge	P2P gossip via Iroh (QUIC)
Server	Durable Object (centralised)	Auto-elected from players (decentralised)
Sync model	Lockstep (1993 original)	Real-time hybrid (snapshots + interpolation)
Damage	Simulated locally by all clients	Host-authoritative events
NPCs/Monsters	Simulated locally by all clients	Host-authoritative snapshots
Late join	Not supported	Fully supported
Internet required	Yes (Cloudflare Workers)	No (works offline, P2P)
Delivery	Website (silentspacemarine.com)	4.2MB file in a chat message

File	Size (compressed)	Purpose
`vector-doom.wasm`	~2.7 MB	Chocolate Doom engine (Emscripten, -O3)
`doom1.wad`	~1.7 MB	DOOM shareware levels (freely distributable)
`vector-doom.js`	~160 KB	Emscripten runtime (terser-minified, 58% reduction)
`index.html`	~12 KB	UI, touch controls, gamepad support, CRT visual theme
`webxdc-net.js`	~3 KB	Server election + packet routing
`icon.png`	~90 KB	App icon
`bg.jpg`	~100 KB	Background artwork
`default.cfg`	~2 KB	Default key bindings
`manifest.toml`	~100 B	WebXDC metadata

Absolutely! It has been on our agenda for a while, but we wanted ...

2026-03-14T09:47:39Z

In reply to nevent1q…rxa7
_________________________

Absolutely! It has been on our agenda for a while, but we wanted to really polish up the Android release before applying. We are quite happy with the latest release v0.3.2 and look forward to listing Vector on Zapstore. We will be in touch this week. Thank you all 🙏

Nostr event nevent1qqsxl2xql995hrfsqvhggppd5wq97zl63c537ak4sdfrq427uj4zhpgzyzu0jtnpuuw5tp4wdlnfwrmnm58ahzgpp9vfut6p00h5gkam4ykg66ew3rk

2026-03-12T10:18:56Z

Many people fall under the illusion that because a company markets their app as "private" or uses fancy buzzwords like "end-to-end encryption" or "secure" that it is what was promised. We have found time and time again that these are blatant lies to ultimately and immorally grow their userbase and hopes at quicker financial success.

Understand some of the degrees of privacy that actually make apps private. There are degrees of privacy as there are degrees of decentralization and just about everything. In this infographic by Formless Labs it breaks down degrees of privacy for messenger apps on each column:

- Decentralized
- Metadata Privacy
- No KYC
- Group E2EE
- Self Hosting

Obvious benefits many people enjoy are also no advertisements and the fact that apps are free (and hopefully open-source).

Any suggestions on other fields or degrees of privacy that should be added? Let us know!

Noted. Thanks again for your feedback. You have valid points, UX ...

2026-03-12T10:11:51Z

In reply to nevent1q…xq64
_________________________

Noted. Thanks again for your feedback.

You have valid points, UX is everything. Unfortunately Telegram is not a privacy-focused app, though it may be marketed that way. It has also been around since 2013, making it about 13 years old, where Vector is roughly 1.2 years old. In the meantime, we will steadily work to improve Vector.

Enjoy this infographic from Formless Labs:

Wonderful! As you can tell Vector is still in Beta and we are ...

2026-03-12T10:08:43Z

In reply to nevent1q…g5v7
_________________________

Wonderful! As you can tell Vector is still in Beta and we are working daily to make improvements. If you have any other suggestions bulbrigertin (nprofile…3qse) let us know, we are happy to hear honest feedback like yours and what all we can improve. We have quite the list of features to add and things to improve, but broken up into stages. If we get a lot of negative feedback on something or a bug is found, we shift our priority to handle it to make our community's experience better.

Vector supports 4 other themes besides the default Vector theme. ...

2026-03-12T02:07:46Z

Vector supports 4 other themes besides the default Vector theme. Several of them include "Chatstr", which is an ode to Nostr and "サトシ", which is an ode to Satoshi and Bitcoin.

Try them out yourself in the Settings and see which one you like best!

Learn more on our GitBook:
https://vector-privacy.gitbook.io/vector-privacy/vector-messenger/features/themes

Nostr event nevent1qqsvh60srs6vf8erd9d0gt3c56lwzevyzsqqk4fkhjmvjekecfyrs0czyzu0jtnpuuw5tp4wdlnfwrmnm58ahzgpp9vfut6p00h5gkam4ykg6vn79ck

2026-03-12T01:54:48Z

Thank you for the feature in Nomishka (nprofile…24h8) 's Substack!

Many other great developments in the Nostr ecosystem that are covered in this weekly update. Vector is already on v0.3.2, so be sure to update if you are currently on v0.3.1.

Download The Latest:
https://github.com/VectorPrivacy/Vector/releases/tag/v0.3.2

https://nomishka.substack.com/i/189590414/7-vector-v031

This is what happens with you let @npub12w7…ktz3 ride without a ...

2026-03-10T09:02:00Z

In reply to nevent1q…mv35
_________________________

This is what happens with you let YuurinBee (npub12w7…ktz3) ride without a saddle and give him no limitations? Absolute BANGER.

Have you met our designer ...

2026-03-10T09:00:23Z

Have you met our designer nprofile1qqs980g43vqyq34quz2ul6rd8k4vau7x6uzvu7jzf3qqy9yu53yz97s7mhh2y?

quoting nevent1q…6486

⚠️PRIVACY NOT FOR COMPROMISE⚠️
// Evangelion-Inspired Art & Design

I see a lot of people sharing today about Evangelion Interfaces, really some of the most inspiring and timeless designs. I still watch classic anime like Neon Genesis: Evangelion and Ghost in the Shell and pause to take stills when I see some unique design inspiration.

This afternoon I just enjoyed spending some time to create a similar feeling (not necessarily the look) that I get from these classic terminal interfaces. It also allows me to be a bit more abstract and really do things I wouldn't traditionally do in design > minimalism + simplicity for one. Instead I enjoyed making this collage of the Privacy by Principle philosophy with VectorPrivacy (nprofile…5jp4) theme. Yes, this is a real app btw and now I'm thinking about making an EVA-01 theme for it.

For me, one of the most classic visuals that stands out in these types of series are the "Caution" or "Warning" bars that often use a broken horizontal line with 45/60 degree diagonal cuts. It reminds me of industrial buildings or construction where they would have these bright yellow warning signs not to enter or wear a hardhat, etc. Whoever really popularized this design has silently won countless awards and well deserved, they really set the standard and feel for many generations to come. This is about as universal as you can get for design in my opinion.

Anyways, hope you all enjoy it and excited to see more original work and not getting Claude or AI to design for you. Yep, I said it. Stand by everything that I say. For implementation? Great, but be creative and take time to work on your own designs and not just rely on AI to give you everything. That is where in lies the true joy of creativity and design, enjoying the process...

The confusion, the clarity. The disarray, the synergy.

🟢 Vector Music Upload Demo: ID3 Music Tag Support Added for ...

2026-03-10T05:58:14Z

🟢 Vector Music Upload Demo:
ID3 Music Tag Support Added for Audio Files
*Support since v0.3.2

What are ID3 Music Tags?
ID3 tags are metadata embedded directly inside audio files (primarily MP3s) that store information about the track. Think of them as a little data packet attached to the file itself. Common fields include things like:

Title — song name
Artist — performer
Album — album name
Year — release year
Track number — position on the album
Genre — music genre
Album art — the cover image embedded in the file
Lyrics — sometimes embedded too
Comment — freeform notes

🎵Test it out: vectorapp.io

Video shared by YuurinBee (nprofile…hh2y)

Wonderful, so your biggest feedback is about Audio playback not ...

2026-03-10T01:59:33Z

In reply to nevent1q…xu66
_________________________

Wonderful, so your biggest feedback is about Audio playback not being comparable to migrate millions to Nostr? We appreciate the feedback and will also work on the Audio UX. There are titles now when you upload music or audio files if you are on the latest v0.3.2. Any other key points you'd like to see Vector improve?

We are going to make this happen on both White Noise + Vector for ...

2026-03-10T01:35:37Z

In reply to nevent1q…x8my
_________________________

We are going to make this happen on both White Noise + Vector for our teams to chat + Marmot development. It's a great first stepping stone to understand the UX better.

We've sent our first Pull Request to NostrApps.com using ...

2026-03-10T00:04:41Z

We've sent our first Pull Request to NostrApps.com using GitWorkshop.Dev! Nostr is the way. fiatjaf (nprofile…cy6q)

https://gitworkshop.dev/npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6/nostrapps-com/prs/note1lm8yutcssrshnt5tm7dt6aehe5j9pzvflg93gl7zx50tr9gf7wysx7t708

Our team has started to use Vector daily and slowly progressing ...

2026-03-09T23:58:00Z

In reply to nevent1q…g7ls
_________________________

Our team has started to use Vector daily and slowly progressing to replace both Discord and Telegram in their personal lives first. We're not claiming that it is anywhere near that level for adoption yet, but simply that it is our goal to have a true privacy messenger app that has all the features you would expect of mainstream messengers + more, without complicating or slowing down the UX. We welcome any honest critique and feedback.

If you'd like to just dig around a little more without downloading it first, you're welcome to check out our GitBook which has most of Vector Privacy's ecosystem documented: https://docs.vectorapp.io

We are also more than happy to address any questions you may have.

Thank you! We couldn't achieve the results we seek without ...

2026-03-09T21:54:14Z

In reply to nevent1q…37wa
_________________________

Thank you! We couldn't achieve the results we seek without Marmot. It's also amazing seeing the community growing around Marmot and more developers, projects, and peer review to further solidify the protocol. Now is a bad time to be sleeping on Marmot 🫡

Thanks for the shoutout and absolutely nailed it 🙏 the Era of ...

2026-03-08T17:58:06Z

In reply to nevent1q…ytvk
_________________________

Thanks for the shoutout and absolutely nailed it 🙏 the Era of Permissionless Privacy has begun

Nostr event nevent1qqs9k4g74afl7crv95qjm5ah2vkfwtawclfd0sv0uj3fp3n60ym83tszyzu0jtnpuuw5tp4wdlnfwrmnm58ahzgpp9vfut6p00h5gkam4ykg6gugd38

2026-03-06T16:34:47Z

Have you tested out this Nostr-inspired theme?

Settings > Theme > Chatstr

Learn More About Vector Themes:
https://vector-privacy.gitbook.io/vector-privacy/vector-messenger/features/themes

#naddr1qv…jmfg

2026-03-04T18:10:43Z

quoting naddr1qv…jmfg

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: The Marmot Development Kit (White Noise (npub1wht…r3ec)) ships its first public release with encrypted media and multi-language bindings. Nostrability (elsat (npub1zaf…26k5)) publishes outbox model benchmarks across 14 relay selection algorithms. Wisp (utxo the webmaster 🧑‍💻 (npub1utx…50e8)) goes from first alpha to beta in eight days with Tor and NIP-55 (Android Signer Application) signing. NIP-91 (AND filters) merges. Vector v0.3.1 delivers negentropy sync with 15x performance gains. This issue also includes the Five Years of Nostr Februaries retrospective, tracing the protocol from a spec rewrite serving three relays through the Damus App Store explosion to mesh networking and AI agent proposals.

News

Outbox Model Under the Microscope

Nostrability published a series of outbox model benchmarks testing how well different relay selection algorithms retrieve events from the decentralized relay network. The project merged 16 PRs and 76 commits in ten days, producing what may be the most thorough empirical analysis of NIP-65 (Relay List Metadata) implementation strategies to date.

The benchmarks test 14 relay selection algorithms against real-world follow lists across 15 clients and libraries in five languages. A baseline approach of querying only popular relays retrieves roughly 26% of events. Greedy set-cover with Thompson Sampling reaches 80-90% recall. Adding a latency-aware variant using hyperbolic discounting and EWMA relay latency tracking pushed completeness from 62-80% to 72-96% at the 2-second mark across six test profiles.

NIP-66 (Relay Monitoring) dead relay filtering proved consequential. Pre-filtering relay candidates against nostr.watch (sandwich (npub1uac…99rx)) liveness data removed 40-64% of dead relays and doubled relay success rates from 30% to 75-85%. Feed load times dropped 39% (from 40 seconds to 24 seconds across 10 profiles). An EOSE-race simulation found that waiting for EOSE plus a 200ms grace period improved completeness over stopping at the first relay to finish.

For clients that cannot fully rewrite their relay routing, a "hybrid outbox enrichment" approach adds per-author outbox queries on top of existing hardcoded app relays. This hybrid achieved 80% one-year event recall versus the 26% baseline, offering a migration path for clients with legacy relay architectures.

ContextVM Opens MCP NIP and Ships Ephemeral Gift Wraps

ContextVM (ContextVM (npub1dvm…3jdm)), the protocol bridging Nostr with the Model Context Protocol, opened two proposals in the NIPs repository this week. PR #2246 formalizes CVM as a convention for transporting MCP JSON-RPC messages over Nostr using ephemeral kind 25910 events. PR #2245 extends NIP-59 (Gift Wrap) with an ephemeral kind (21059) that follows NIP-01 (Basic Protocol Flow) ephemeral semantics, letting relays discard wrapped messages after delivery.

The ephemeral gift wrap convention shipped as CEP-19 in the ContextVM SDK v0.6.x release family. The SDK implementation adds a GiftWrapMode enum with three settings: OPTIONAL (accept both kinds and auto-detect peer capability), EPHEMERAL (kind 21059 only), and PERSISTENT (kind 1059 only). For AI tool calls, ephemeral mode avoids storing intermediate request-response traffic on relays, reducing both storage costs and privacy exposure.

New public MCP servers appeared on the network from independent operators, including a Wolfram Alpha query server. The ContextVM team published CEP-15 (common tools schema) and CEP-17 (server relay list publication) alongside the v0.6.x release cycle.

Marmot Development Kit Ships First Public Release

MDK (White Noise (npub1wht…r3ec), Marmot Development Kit), the Rust library powering Marmot-encrypted messaging across Pika (justinmoon (npub1zxu…cx2y)) and White Noise, shipped v0.6.0 as its first public release. Over 200 PRs merged into this version, with six new contributors.

The release includes encrypted media support (MIP-04) with HKDF seed derivation (MIP-01 v2), deterministic commit race resolution (MIP-03), encrypted local storage, admin authorization validation for Marmot commits and proposals, and GREASE support for protocol extensibility. Bindings ship for Kotlin, Python, Ruby, and Windows alongside Android cross-compilation. The library upgrades to OpenMLS 0.8.0 with security advisory fixes and a Secret<T> type that zeroizes sensitive values in memory.

A companion protocol change (MIP-03) replaced NIP-44 (Encrypted Payloads) encryption with ChaCha20-Poly1305 for kind 445 messages. NIP-44 required UTF-8 string input per its specification, making it impossible to pass raw Marmot message bytes through standard TypeScript Nostr libraries. The replacement derives keys directly from the Marmot exporter secret. This breaking change required coordinated updates across the core spec, MDK, and TypeScript SDK.

marmot-ts (White Noise (npub1wht…r3ec)), the TypeScript implementation maintained by hzrd149, merged four PRs with breaking API changes in its own right. An omnibus update added a key package manager for create/publish/rotate lifecycle, a sendChatMessage convenience method, invite preview without joining (readInviteGroupInfo), self-update for forward-secrecy rotations, and structured debug logging. Group decryption APIs were renamed from readGroupMessage to decryptGroupMessage with richer result variants (processed/skipped/rejected/unreadable). gzuuus contributed example cleanup with NIP-65 relay support and last-resort key package handling per MIP-00.

The White Noise CLI (wn), the Rust backend powering both the mobile app and the new TUI, merged 16 PRs in ten days. Signer lifecycle handling gained cancellation safety through an RAII scope guard (PR #538), fixing a class of bugs where aborted operations could leak signer state. Login now blocks when required relay lists (kind 10002/10050/10051) are missing (PR #515), and giftwrap subscriptions fall back to NIP-65 relays when inbox lists are absent (PR #518). A debug mode (PR #528) exposes database queries and MLS ratchet-tree inspection as JSON output. Other fixes addressed subscription recovery after signer re-registration, welcome message catch-up timing, relay filter validation, and user search radius limits.

Marmot saw significant expansion beyond the core Rust stack this week. White Noise TUI, a terminal-based interface to the White Noise messaging stack, launched March 3. It wraps the wn CLI as a subprocess and renders its JSON output through an Elm-inspired unidirectional architecture, providing multi-conversation navigation with unread indicators, group creation and member search, real-time message streaming, and emoji reactions from the terminal.

DavidGershony published a complete C# Marmot stack mirroring the Rust toolchain's layered architecture. dotnet-mls implements MLS RFC 9420 cryptographic primitives in C#. marmot-cs builds on it to add Nostr relay transport, functioning as a C# equivalent of MDK. OpenChat (npub1nwt2g6fkshuj4udrs9zxr8992dyp75s9qx647kxaue98trzqqmssrxx05y (npub1nwt…x05y)), a cross-platform desktop app built with .NET 9 and Avalonia UI, ties both together into a working chat client with NIP-44 DMs, Marmot group encryption, NIP-46 (Nostr Connect) remote signing, and multi-relay status indicators.

MDK PWA Reference provides a Progressive Web App template for building Marmot-encrypted applications, with experimental support for AI agent participation in group chats and Bitcoin payments via Arkade wallet infrastructure.

Wisp Ships from Alpha to Beta

Wisp is a new Android Nostr client that went from first alpha on February 24 to v0.3.4-beta on March 3, producing 19 releases, 115 merged PRs, and 276 commits in eight days.

The feature trajectory covers ground that most clients take months to reach. v0.1.0 shipped with outbox/inbox relay model support and onboarding flows. By v0.1.3, the client had NIP-55 intent-based signing for Amber, an embedded Tor SOCKS5 proxy for .onion relay connectivity, and NIP-47 (Nostr Wallet Connect). v0.2.0 graduated to beta with mute list filtering and custom emoji support, while v0.2.4 added content warning overlays. The v0.3.x series introduced NIP-13 proof-of-work for notes, background PoW mining with persistent settings, .onion relay storage, and mute thread notifications.

On-device translation via Google ML Kit runs locally without network access after the initial model download. An interactive social graph visualization uses a velocity Verlet physics simulation at approximately 30fps with pinch-to-zoom navigation and profile inspection.

Releases

Vector v0.3.1

Vector (VectorPrivacy (npub1hru…f3yh)), the Marmot-encrypted messaging app, shipped v0.3.1 with group management improvements and performance work. Multi-admin groups, bulk invites, invite-by-npub, and group avatars expand the collaboration features. Android background notifications now support inline Reply and Mark Read actions.

Negentropy-based deterministic sync retrieves full conversation history including messages that were missed during offline periods. Voice-to-text rebuilt with GPU acceleration on Android. File attachment handling was overhauled with download progress, retry states, directory zip-and-send, and live progress indicators throughout. Performance improved over 15x across boot time, image processing, audio playback, and general UI responsiveness. App install size dropped by more than a third, with the frontend reduced by roughly half. 32-bit ARM Android support was added.

Alby Hub v1.21.5

Alby Hub (Alby (npub1get…0nfm)), the self-custodial Lightning node with Nostr Wallet Connect (NIP-47) support, shipped v1.21.5. A second relay was added to the default NWC configuration, improving reliability during relay restarts. A fix for invalid zap data in the transaction list resolves a display issue with malformed NIP-57 (Lightning Zaps) events. New app store entries include Alby CLI and LNVPS.

nospeak v0.12.x

nospeak (psic4t (npub174t…mqm6)), the text-based Nostr messaging client, shipped three releases across the period. v0.12.0 added a PIN app lock with 4-digit keypad and over 15 new language translations including Bengali, Thai, Vietnamese, Hindi, Arabic, Hebrew, Urdu, Turkish, Japanese, Chinese, Korean, Dutch, Polish, Russian, and Persian with RTL support. v0.12.1 introduced a Cypher theme with pure black backgrounds and cyan accents, plus Android video poster generation. v0.12.2 added chat export and View Profile in contact menus.

Citrine v2.0.0-pre2

Citrine (greenart7c3 (npub1w4u…0jr5)), the Android personal relay by greenart7c3, shipped v2.0.0-pre2 with relay performance improvements through new database indexes and restructured Kotlin coroutines. Each hosted web app now starts on its own port. Full-text search and a redesigned events screen with event expansion round out the changes.

NoorNote v0.5.x

NoorNote (alp (npub175n…g6w0)), a Nostr-based note-taking application, shipped 8 releases from v0.5.0 through v0.5.7. The v0.5.0 launch on Android added NIP-55 Amber signer support and NIP-71 (Video Events) note publishing. A redesigned welcome page in v0.5.1 included public timeline previews and reduced the APK to 15 MB. The Relay Browser in v0.5.2 lets users browse public relay timelines via shareable URLs, alongside media download and NIP-30 custom emoji reactions. Subsequent releases through v0.5.7 addressed sync race conditions in the collaborative "tribes" note-sharing system.

NosCall v0.5.1

NosCall (sana (npub1qn6…xsha)), the Nostr voice and video calling app, shipped v0.5.1 with voice message support, an optimized desktop experience with group entry, contact favorites on desktop, contact notes and filtering, data export and cleanup options, and system font size accessibility support.

Shosho v0.13.0

Shosho (Shosho – Live Stream on Nostr (npub1sh0…q2xa)), the Nostr live streaming app, shipped v0.13.0 with MP4 replay downloads from stream card menus and NIP-05 (DNS-Based Verification) for profiles. The RTMP publisher migrated to Expo Modules API. Streaming performance on lower-bandwidth connections improved, and crashes on older devices and iOS streaming to Zap.Stream are fixed.

nostr-java v2.0.0

nostr-java shipped v2.0.0 with configurable WebSocket buffer sizes, allowing applications to handle larger Nostr events without truncation. The major version bump reflects breaking changes to the connection API.

Prism 1.1.0

Prism shipped 1.1.0 with long-form content support (kind 30023 articles) and a Markdown editor for composing directly in the app, followed by a 1.1.1 bug fix release.

Angor v0.2.6

Angor (Angor (npub1wrz…cm02)), the Bitcoin crowdfunding platform, shipped v0.2.6 with Boltz integration and a 1-click invest flow. Both invest and fund project types work end-to-end on testnet. The team notes the UI is approximately 70% complete.

NIP Updates

Recent changes to the NIPs repository:

Merged:

NIP-91: AND Operator for Filters: Adds AND filter semantics for tag arrays in relay subscriptions. Currently, specifying multiple values in a tag filter (e.g., multiple p tags) matches events containing any of them. NIP-91 lets clients require events matching all specified tag values simultaneously, reducing bandwidth and enabling faster index operations. Multiple relay implementations already exist including nostr-rs-relay, satellite-node, worker-relay, and applesauce. Formerly numbered NIP-119.

NIP-30: Emoji Set Address in Tags: Custom emoji tags in NIP-30 can now include an optional emoji set address. Clicking an emoji in a client can open the set it belongs to for bookmarking or browsing. Originated from the Chachi (chachi (npub1gm7…0fte)) client.

NIP-29: Add unallowpubkey and unbanpubkey: Two new admin commands for NIP-29 group chat. unallowpubkey removes a pubkey from the allowed list without banning them. unbanpubkey lifts a ban without re-adding the pubkey to the member list. Previously, the only way to remove someone from the allowed list also banned them, and unbanning required re-adding the user as a member.

Open PRs and Discussions:

NIP-A7: Spells (opened Feb 27): Proposed by purrgrammer, spells are portable saved Nostr queries published as kind 777 events. A spell encodes a REQ or COUNT filter in structured tags (k for kinds, authors for pubkeys, tag for arbitrary tag filters) with runtime variables: $me resolves to the logged-in user's pubkey, $contacts expands to the user's kind 3 follow list. Relative timestamps (7d, 2w, 1mo) let spells define rolling time windows without hardcoded dates. Already implemented in nak (fiatjaf (npub180c…h6w6)) and Grimoire (grimoire (npub1era…skz0)), spells let users create, share, and subscribe to curated feeds that travel across clients.

NIP-59: Ephemeral Gift Wrap (kind 21059) (opened Feb 27): Adds an ephemeral variant of NIP-59 gift wraps. Kind 21059 follows NIP-01 ephemeral semantics, so relays discard events after delivery. Proposed by ContextVM for MCP transport where message persistence is unnecessary.

ContextVM: MCP JSON-RPC over Nostr (opened Feb 27): Specifies how to transport Model Context Protocol messages over Nostr using ephemeral kind 25910 events with p and e tags for addressing and correlation. Intentionally thin, deferring protocol detail to the ContextVM spec.

NIP-29: Audio/Video Live Spaces (opened Feb 25, draft): fiatjaf's draft extending NIP-29 groups with live audio and video. The proposal adds optional livekit and no-text tags to group metadata events. When a user wants to join a voice space, the client requests a JWT from the relay at /.well-known/nip29/livekit/{groupId}. The relay checks group membership and issues a token with the user's hex pubkey as the sub claim, which is passed to LiveKit for media transport. Voice room access inherits the group's existing permission model, so relay-side membership rules govern who can speak. Being tested in Pyramid and Chachi.

Collaborative Event Ownership (opened Feb 24): pablof7z proposes a pointer event (kind 39382) that declares a collaborative space by listing co-owner pubkeys in p tags and a target event kind in a k tag. Any listed owner can publish events of that kind with the same d tag, and clients resolve the current state by querying all owners and taking the most recent event. Co-authorship attribution only displays when a verifiable a tag back-references the pointer and the author appears in its p tags, preventing spoofed claims. This enables shared wiki pages and co-authored resources without assigning control to a single keypair.

NIP-09: Cascading Deletion of Reposts (opened Feb 24): When an original author deletes a note, relays should also delete any kind 6 or kind 16 reposts referencing it. Motivated by privacy concerns: reposts can preserve accidentally leaked information after the author deletes the source. The change is relay-side only, requiring no client modifications.

NIP-07: peekPublicKey (opened Feb 23): Adds a peekPublicKey() method to NIP-07 browser extensions. Unlike getPublicKey(), it returns the current pubkey without prompting for user confirmation, enabling silent auto-login when the user has auto-login enabled.

NIP-BB: Book (opened Feb 28, draft): Defines four addressable event kinds (30300-30303) for structured book publishing on Nostr. A Cover event holds root metadata including title, cover image, license via NIP-32 (Labeling) labels, and language code. An Index event maps each chapter to its position using base62 fractional indexing, which lets authors insert new chapters between existing ones without renumbering. Chapter events act as structural headers with optional images, while Episode events carry the actual prose capped at 30,000 characters with positioned image tags. Reviews use Zaps on Cover events with the Zap description as review text.

NIP-54: Switch from Asciidoc to Djot (opened Feb 26): Following the d-tag internationalization fix in December, this PR proposes replacing NIP-54 wiki's Asciidoc markup format with Djot, adding a rationale section and wikilink examples for non-Latin scripts.

NIP-66: Defensive Measures (opened Feb 26): Based on learnings from the nostrability/outbox benchmarks, adds explicit callouts for NIP-66 edge cases. A companion PR #2241 defines output tags for SSL, geolocation, network, and connectivity checks.

NIP-C1: Cryptographic Identity Proofs (wiki entry, kind 30817): Proposes kind 30509 events that cryptographically link APK signing certificates to Nostr profiles. The proof works by signing a canonical message containing the Nostr pubkey with the certificate's private key (supporting ECDSA, RSA PKCS1v15, Ed25519, and other standard algorithms), then publishing the signature in a kind 30509 event signed with the Nostr key. Verifiers can confirm that the person who controls an app's Android signing certificate also controls the Nostr pubkey claiming to publish it. Proofs expire after one year by default and can be explicitly revoked. Implemented in the Zapstore (Zapstore (npub10r8…t2p8)) toolchain.

NIP-31402: SARA Revenue Share Offering Registry (wiki entry, kind 30817): Defines kind 31402 addressable events for publishing Simple Autonomous Revenue Agreement (SARA) offerings on Nostr relays. Issuers advertise Lightning-settled revenue share terms including pool share percentage, payout trigger, threshold in sats, term length, and tiered pricing. Agents and humans can discover offerings across relays and subscribe autonomously without a central platform. The kind number mirrors kind 30402 (L402 Service Registry, published by the same author as a companion wiki entry) since SARA represents the return leg of the L402 payment relationship.

Open PRs and Project Updates

Damus: NIP-89 (Recommended Application Handlers)

PR #3337 implements NIP-89 client tag support for Damus (damus (npub18m7…q955)). The app now emits a client tag on all posting paths (main app, share extension, highlighter, drafts) and displays "via ClientName" beside timestamps when other apps include their tags. A Privacy toggle in Appearance settings lets users disable tag emission. PR #3652 adds a Storage section in Settings with an interactive pie chart breaking down NostrDB and Kingfisher cache disk usage with export support.

Open: PR #3657 adds NIP-65 relay fallback for quoted notes. When an inline nevent includes an author pubkey but no relay hints and the note is missing from the user's pool, Damus fetches the author's kind 10002 relay list and retries from their write relays.

Amethyst: NIP-39 (External Identities), NIP-C0, NIP-66

Amethyst (Amethyst (npub142g…xrj0)) merged a wave of NIP implementations across 28 PRs. External identity claims now publish as dedicated kind 10011 events under NIP-39 (PR #1747), separating social identity from kind 0 metadata with backward-compatible fallback. Code snippet support via NIP-C0 (PR #1744) adds kind 1337 events with accessors for language, extension, runtime, license, and dependencies. The NIP-66 relay monitoring implementation (PR #1742) covers both event kinds with full tag parsing for RTT metrics, network type, supported NIPs, and geohash.

Encrypted DMs arrived on Amethyst Desktop (PR #1710) with a split-pane chat layout supporting both NIP-04 (Encrypted Direct Messages) and NIP-17 (Private Direct Messages). A new relay feed screen (PR #1733) lets users browse posts from a specific relay with follow/unfollow functionality. Open: censorship-resistant NIP-05 verification (PR #1734) adds a parallel verification path for .bit identifiers that resolves against the Namecoin blockchain instead of HTTP DNS. When Amethyst detects a .bit suffix in a NIP-05 field, it queries an ElectrumX-NMC server for the name's transaction history, parses the NAME_UPDATE script from the latest output to extract the Nostr pubkey, and rejects names older than 36,000 blocks (Namecoin's expiry window). ElectrumX connections route through SOCKS5 when Tor is enabled, with dynamic server selection between clearnet and .onion endpoints. An LRU cache with a one-hour TTL prevents repeated blockchain queries.

Notedeck: Outbox Architecture

PR #1303 migrates Notedeck (damus (npub18m7…q955)) from ad-hoc relay pool management to a centralized outbox model with account-scoped subscriptions. The Messages module now publishes a default DM relay list if none exists and routes DMs to recipients' preferred relays per kind 10050.

Pika: Per-Group Profiles and Tutorial Feed

Pika, the Marmot-encrypted messaging app available on iOS and Android with a desktop build, gained per-group profiles (PR #368). Users can now set a separate display name and picture for each group chat, along with a custom bio. These profiles publish as encrypted kind 0 events inside the Marmot group, invisible to anyone outside it, with a fallback to the user's global Nostr profile when no group-specific profile is set. When new members join, the admin rebroadcasts all stored group profiles and each member republishes their own on commit. Profile pictures are Marmot-media-encrypted before Blossom upload. The PR includes 16 new unit tests and exposes the feature both through a CLI command (update-group-profile) and the UI.

A new pika-news web app (PR #401) monitors Pika's own GitHub PRs and auto-generates step-by-step tutorial walkthroughs from PR diffs, publishing them as server-rendered pages with NIP-07 authentication. Users can discuss specific tutorials in real time through Nostr-authenticated chat.

diVine: Embeddable Widgets and Video Replies

diVine (rabble (npub1wmr…g240)), the Nostr-native video sharing platform, merged 132 PRs in ten days. Embeddable iframe widgets (PR #1843) provide a self-contained /embed?npub=... page that renders a user's profile and latest videos. Video reply functionality (PR #1915), gated behind a feature flag, uses Kind 1111 comments (NIP-22) with NIP-92 (Media Attachments) imeta metadata. Bluesky-inspired three-way content filters (PR #1797) offer Show/Warn/Hide controls across 17 NIP-32 content warning categories.

strfry: REQ Filter Validation

PR #163 adds configurable REQ filter validation to strfry (Doug Hoyte (npub1yxp…qud4)), the C++ Nostr relay. Operators can set maximum filters per REQ, required author or tag presence, allowed kind whitelists, and per-filter kind limits. The feature targets NWC relay deployments that need strict filter enforcement. Open: PR #173 adds optional zstd compression for event payloads at ingest time.

rust-nostr: NIP-62 Request to Vanish

rust-nostr (Yuki Kishimoto (npub1drv…seet)), the Rust Nostr protocol library, added NIP-62 (Request to Vanish) support across all three database backends: LMDB, SQLite, and in-memory. The LMDB implementation includes configurable options to enable or disable NIP-09 and NIP-62 enforcement per deployment.

NDK: Collaborative Events and NIP-46 Timeout

NDK (PABLOF7z (npub1l2v…ajft)), the Nostr Development Kit for JavaScript/TypeScript, merged PR #380 introducing NDKCollaborativeEvent for multi-author collaborative documents using an addressable pointer event (kind 39382) that defines authorized authors. A configurable timeout for NDKNip46Signer (PR #381) prevents NIP-46 remote signing operations from hanging indefinitely when a bunker does not respond.

TENEX: Agent Categorization and Pubkey Gating

TENEX (PABLOF7z (npub1l2v…ajft)), the Nostr-native AI agent orchestration platform, merged two security-related PRs. TIP-01 role-based agent categorization (PR #91) maps agent categories (principal, orchestrator, worker, advisor, auditor) to automated tool restrictions via a denied-tools map. Front-door pubkey gating (PR #87) ensures only events from whitelisted or backend-signed pubkeys are routed alongside known agents; unknown pubkeys are silently dropped with OpenTelemetry spans for audit.

Zap Cooking: Membership Dashboard

Zap Cooking (ZapCooking (npub1xxd…kt7a)), the Nostr-based recipe sharing platform, merged 25 PRs and 85 commits in ten days. A membership dashboard (PR #228) shows subscription status with expiration dates and manage/upgrade options, re-enables feature gates for Sous Chef and Zappy tiers with both client-side and server-side checks, and standardizes tier naming across 26 files. Two-phase group message loading (PR #227) provides a fast 3-day initial fetch for instant display followed by a background 40-day backfill.

Wallet mnemonic storage moved from pubkey-derived encryption to NIP-44 encrypt-to-self (PR #224), fixing a vulnerability where the old scheme derived its key from SHA-256(pubkey), which is effectively unencrypted since pubkeys are public. Existing wallets are silently migrated on first load. NIP-29 group chat gained unread indicators with red dot badges and invite-only access with kind 9009 invite codes (PR #213). Link previews and Nostr event embeds now render in DMs and group messages (PR #218). A Nostr backup section in Settings (PR #210) stores follows and mute lists via NIP-78 (Application-specific Data) encrypted storage with rotating 3-slot versioning. Startup performance improved through deferred notification services, lazy DOM rendering via IntersectionObserver (reducing DOM nodes from ~15,000 to ~3,000 on a 200-event feed), and extended outbox cache TTLs (PR #208). A customizable print recipe modal (PR #205) lets users toggle which sections to include with a live preview. Branta SDK integration (PR #222) adds verification guardrails for POST and GET requests.

Keep: Rust-Driven State Migration

Keep (williamk⚡santiago🔑☢️ (npub1h3f…96sj)), the Nostr-based private key manager for Android, merged PR #178, deleting four Kotlin configuration stores in favor of Rust-driven shared state from the keep-mobile layer. A 10-second polling loop was replaced with push-based KeepStateCallback from Rust. PR #179 adds encrypted backup and restore with passphrase protection.

Mostro Mobile: Dispute Chat Encryption

Mostro Mobile (Mostro (npub1m0s…40un)), the mobile client for the Mostro P2P Bitcoin trading platform, shipped a two-phase migration of dispute chat encryption. The first step (PR #495) switches from mostro-specific wrapping to shared key encryption derived from the admin's pubkey. Building on that, PR #501 unifies the message model with NostrEvent and stores gift wrap events encrypted on disk, consistent with the peer-to-peer chat pattern. A BIP-340 signature fix (PR #496) overrides the bip340 dependency to 0.2.0, resolving a bigToBytes() padding bug that caused 1-2% of Schnorr signatures to be invalid and 100% failure for keys whose public key starts with 0x00. Order Details now shows human-readable status labels instead of raw protocol values, localized across English, Spanish, Italian, and French (PR #502). HalCash was added and SEPA removed as a payment method (PR #493), since SEPA transfers can exceed 24 hours (SEPA Instant remains).

On the server side, Mostro (Mostro (npub1m0s…40un)) fixed dispute session restore to include the initiator field (PR #599) and now automatically closes active disputes when a seller releases funds, publishing a settled Nostr event so admin clients see the resolution (PR #606).

Five Years of Nostr Februaries

Last month's newsletter traced Nostr's January milestones from early development through the Damus breakout to security infrastructure in 2026. This retrospective covers what happened each February from 2021 through 2026.

February 2021: The Rewrite

Three months into its existence, Nostr's February produced the protocol's most consequential early change. On February 14-15, fiatjaf rewrote NIP-01, replacing the original message format with the EVENT/REQ/CLOSE model that the protocol still uses. Before this rewrite, clients and relays communicated through a simpler structure. Separating event publishing (EVENT) from subscription management (REQ/CLOSE) enabled relay-side filtering that would prove essential for scaling.

NIP-04 arrived the same month, adding encrypted direct messages using shared secrets derived from Diffie-Hellman key exchange over secp256k1. Its encryption was basic (AES-256-CBC) and would later be replaced by NIP-44's audited cryptography, but it gave the handful of early users their first private communication channel on the protocol.

Tooling expanded with noscl (fiatjaf (npub180c…h6w6)), a Go command-line client for terminal-based relay interaction, and futurepaul started nostr-rs, an early Rust implementation. The entire network ran on two or three relays, coordinated through a Telegram group, with roughly seven active contributors.

February 2022: Building Momentum

The Hacker News post from December 31, 2021 continued to draw developers into February. The nostr-protocol/nostr repository (the formal NIPs repository would not exist until May 2022) received six pull requests in February, including NIP-13 (Proof of Work) from vinliao, NIP-14 (Reputation) from fiatjaf, NIP-15 (Resource Relations) from Cameri, and NIP-17 (Git Updates Over Nostr) from melvincarvalho. The NIP number was later reassigned to Private Direct Messages; git collaboration on Nostr continued separately through what became gitworkshop.dev.

Greg Heartsfield's nostr-rs-relay was the month's workhorse with 34 commits and three releases. Version 0.5.0 on February 12 added NIP-05 verified user publishing limits. Versions 0.5.1 and 0.5.2 followed over the next two weeks, and the relay handled the bulk of the network's traffic alone.

Robert C. Martin (Uncle Bob) was building more-speech (unclebobmartin (npub19mu…jnft)), a Clojure desktop client, logging 69 commits between January 18 and the end of February. His involvement brought attention from the broader software engineering community. fiatjaf's nos2x browser extension shipped NIP-04 decrypt support and relay preference policies in February, implementing the window.nostr interface (NIP-07) that web clients still use for key delegation.

Branle (fiatjaf (npub180c…h6w6)), still the primary web client, gained web+nostr protocol handler registration on February 13, an early attempt at deep linking between Nostr applications. nostr-tools (fiatjaf (npub180c…h6w6)) tightened NIP-05 validation. go-nostr (mattn (npub1937…haj6)) added NIP-04 encrypted DM support and NIP-12 (Generic Tag Queries) parsing across 11 commits. The network operated on roughly 7-15 relays with an active user base likely in the low hundreds. Damus and Nostream did not yet exist and would not appear until April 2022.

February 2023: International Attention

February 2023 brought Nostr its largest wave of public attention. Damus, the iOS client by William Casarin, had been approved on Apple's App Store on January 31 after repeated rejections. By February 1 it reached the top 10 in U.S. Social Networking. Two days later, on February 2, Apple pulled Damus from China's App Store reportedly at the request of the Cyberspace Administration of China.

Major outlets including TechCrunch and CoinDesk covered the removal, amplifying awareness of both the app and the protocol. Unique public keys with metadata on nostr.directory crossed 300,000 by February 3. All relays were operated by enthusiasts paying out-of-pocket, and infrastructure scrambled to handle the load. Approximately 289 relays were tracked by early February, a number that continued to climb.

The NIPs repository logged 29 merged pull requests that month, the highest single-month count in the protocol's history to that point. NIP-57 (Lightning Zaps) and NIP-23 (Long-form Content) both merged on February 13, adding Bitcoin micropayments and expanding Nostr beyond short posts in a single day. NIP-65 (Relay List Metadata) had merged a week earlier on February 7, enabling the outbox model that followed. NIP-46 (Nostr Connect) and NIP-58 (Badges) also landed before month's end.

The Human Rights Foundation granted $50,000 to William Casarin for Nostr and Damus development on February 21, one of the first institutional grants to a Nostr project. OpenSats had not yet launched its Nostr fund (that would come in July 2023).

February 2024: Protocol Durability

February 2024 shifted focus from growth to protocol durability. NIP-17 (Private Direct Messages), open since the previous July, was working toward a replacement for the aging NIP-04 encryption using NIP-44's audited cryptography and NIP-59 gift wrapping. NIP-04 leaked metadata to relay operators, who could see sender-recipient pairs. NIP-17 hides sender identity behind disposable keypairs and merged that spring after a final round of review in March.

NIP-29 (Simple Groups) merged February 28 after months of discussion, defining how relays can host moderated group chats with admin roles and access control. NIP-92 (imeta tags) merged February 1, standardizing how clients attach image dimensions and blurhash previews to media events.

On February 16, the NIPs repository added BREAKING.md, a file tracking backward-incompatible changes to the protocol specification. Its creation acknowledged that Nostr had reached a maturity level where breaking changes needed formal documentation.

Twenty-two pull requests merged that month. npub.cash (npubcash (npub1s4m…pz6a)) launched as a Lightning address service letting any npub receive payments without running a server. An academic paper published February 8 found that 95% of free-to-use relays could not cover operational costs through donations, with 35% of paid relays charging admission fees below 1,000 sats (roughly $0.45 at the time).

February 2025: Infrastructure Growth

February 2025 produced 28 merged pull requests to the NIPs repository. A Right to Vanish NIP merged February 19, defining how users can request deletion of their data from relays in response to regulatory questions around data portability and user control.

NIP-60 (Cashu Wallet) and NIP-61 (Nutzaps) received simplification updates, streamlining the ecash token storage format. A q-tag (quote tag) rollout continued across multiple NIPs, standardizing how events reference other events for quoting and threading.

Client releases marked steady progress. Notedeck v0.3.0 alpha shipped on the last day of January, with adoption continuing into February. Primal v2.1 followed on February 7, and GRAIN (OceanSlim (npub1zmc…7f60)) v0.3.0, a Go relay implementation, released on February 21.

NOSTRLDN v5 brought the London Nostr community together for its fifth meetup. A DVMCP bridge connected Nostr's Data Vending Machines (NIP-90) with the Model Context Protocol, prefiguring the AI agent integration work that arrived the following month.

February 2026: Beyond Social Media

February 2026 activity is drawn from Nostr Compass issues #8 through #11.

February 2026 produced the broadest range of application-layer development in any single Nostr month. Mostro shipped its first public beta for decentralized peer-to-peer Bitcoin trading, and Zapstore reached 1.0 stable after months in release candidate testing. White Noise v0.3.0 delivered real-time Marmot-encrypted messaging with Amber signer support and over 160 merged improvements.

Competing AI agent proposals from pablof7z (NIP-AE for agent workflows, NIP-AD for MCP server announcements) and joelklabo (AI Agent Messages) arrived alongside a DVM Agent Coordination proposal extending NIP-90. ContextVM shipped SDK improvements connecting the Model Context Protocol to Nostr transport. Burrow (Derek Ross (npub18am…p424)) added Marmot-encrypted messaging for both AI agents and humans, extending Nostr's identity and relay infrastructure into machine-to-machine communication.

FIPS (jcorgan (npub19wa…8p6k)) shipped a working Rust implementation of Nostr-native mesh networking, using secp256k1 keypairs as node identities with transport-agnostic routing over UDP, Ethernet, Bluetooth, or LoRa radio. Its design showed that Nostr's key model extends beyond social media into physical network infrastructure.

OpenSats announced its fifteenth wave of Nostr grants, funding projects including ContextVM and Nostube. Protocol changes included NIP-47 hold invoice support for Nostr Wallet Connect and NIP-45 (Counting Results) HyperLogLog for relay-side count estimation. NIP-85 (Trusted Assertions) service provider discoverability for Web of Trust scoring also merged. rust-nostr began a full API redesign while Nostria 3.0 and Frostr (Frostr (npub17uv…8tr4), iOS TestFlight) both shipped. Blossom's local cache layer addressed media availability across relays.

Looking Ahead

Five Februaries of protocol history show a consistent progression from foundational work to application-layer diversification, with the 2023 user influx as the turning point. In 2021, seven contributors worked across three relays. By 2026, the same protocol supported mesh networking and autonomous agent proposals running on production infrastructure.

That's it for this week. Building something or have news to share? DM us on Nostr.

Amazing progress, especially for Marmot Protocol! We are happy to ...

2026-03-04T18:00:35Z

In reply to naddr1qq…3n2q
_________________________

Amazing progress, especially for Marmot Protocol! We are happy to see the growth and adoption of such needed technology. We will be there with you all to help bring it to the world. Thanks for the shoutout and coverage of Vector's latest v0.3.1 release! ❤️

So many great builders in the Nostr ecosystem we are truly just learning about.

Love to see the explosive growth and adoption. Honored to share ...

2026-03-04T12:42:38Z

In reply to nevent1q…ecc0
_________________________

Love to see the explosive growth and adoption. Honored to share the experience 🙏

🟢 [ V E C T O R ] Open Beta v0.3.1 ...

2026-03-01T17:44:18Z

🟢 [ V E C T O R ] Open Beta v0.3.1

We've just rolled out the latest version of Vector, including a lot of UX optimizations for group chats, performance, file sharing, emojis, and many improvements for Android (notifications fixed).

Check it out on GitHub or read more below:
https://github.com/VectorPrivacy/Vector/releases/tag/v0.3.1

New:

👥 Group Management: multi-admin, edit group info, bulk invites, invite-by-npub, group avatars, and many fixes
🔔 Android Notifications: background message sync with Mark Read and inline Reply actions
📡 Multiplayer Networking Upgrade: faster connections, seamless WiFi + cellular switching, and Android connectivity fixes
🎙️ Voice-to-Text AI: rebuilt speech-to-text with GPU acceleration on Android
📁 File Attachment Overhaul: styled download boxes with progress spinners and retry states
📦 Directory Zip & Send: compress and send entire folders with live progress and file tree preview
🔒 Customizable Encryption: encrypt Vector with a PIN, Password, or go passwordless with instant logins
🔄 Deterministic Sync: Vector now syncs your entire history, including missing messages, at ultrafast speeds (negentropy!)
😀 Emoji Upgrade: Vector supports the very latest Unicode, with a library of over 2,000 emojis
📬 Smarter DM Delivery: messages now route to the recipient's preferred relays, for those with custom relay setups
🤖 32-bit ARM on Android: added support for older Android devices (typically 32-bit ARM)
🎮 Mini App Update Badges: one-tap in-panel updating when newer versions are available

Improvements:

⚡ Performance Overhaul: faster boot, image processing, and audio - up to >15x speedup across the board
🗜️ Smaller & Faster App: >33% smaller install size and ~50% smaller frontend (we shrunk!)
🖼️ New Image Placeholders: sharper, faster (12x) previews while photos load - powered by our custom Thumbhash library
🧠 Memory Optimizations: lower RAM usage across the board (especially for high message & contact counts)
🏗️ Background Sync: restructured backend enables reliable background sync on Android
🎨 UI Polish: updated themes, chat backgrounds, settings layout, popup styling, and profile display

Fixes:

🔄 Group Reliability: improved message delivery with smarter relay handling, retry logic, and safer commit handling
🤙 Emoji Panel Performance: fixed freezing and jitter when opening the emoji panel
🍎 macOS White Flash: no more white flash on app startup (we improved Tauri to do this!)
📱 Android Media: video and audio seeking now works correctly, with stream-based seeking in a custom media backend
🔧 Upgrade Safety: fixed migration bug affecting some users upgrading from v0.2.3, extending backward-compat

We need your help, Nostr fam! Claude is now offering unlimited ...

2026-02-27T06:55:04Z

We need your help, Nostr fam!

Claude is now offering unlimited access for Open-Source projects that have 5,000 stars on GitHub.

If you could support with a star ⭐ on the official Vector Privacy repo, it would be a huge help:
https://github.com/VectorPrivacy/Vector

Learn More:
https://claude.com/contact-sales/claude-for-oss

Optimizers gonna optimize. Want faster audio transcriptions? You ...

2026-02-23T02:02:17Z

Optimizers gonna optimize.

Want faster audio transcriptions? You got it. ✅

We've now been able to improve the transcription time by approximately 500%. The most important factor is that people who are using slower and older devices still have access to the same resources and features on Vector.

You can expect these optimizations and features available on the next release for v0.3.1 and that includes you, Android users.

We have just open-sourced "fast-thumbhash", a library ...

2026-02-21T19:29:54Z

We have just open-sourced "fast-thumbhash", a library that produces beautiful image preview thumbnails with significant advantages over BlurHash; more detail, 12x faster, 10% smaller. More data in fewer characters.

fast-thumbhash is a from-scratch ThumbHash encoder/decoder that beats BlurHash on every axis. Below are 4 key points that compare this release of ThumbHash compared to its predecessor, BlurHash.

🟢 12x faster encoding and decoding (14 µs vs 180 µs)
🟢 Smaller on the wire: 26 chars base91 vs BlurHash's 28 chars base83
🟢 Richer data: alpha channel, embedded aspect ratio, full DCT L/P/Q/A vs BlurHash's 4x3 RGB grid
🟢 Better visual fidelity: more detail, better color accuracy, transparency support

Over 10,000 images sent on Nostr:

- BlurHash: 28 chars × 10k = 280 KB of placeholder data
- ThumbHash (base91): 26 chars × 10k = 260 KB of placeholder data
- 7.1% reduction (20 KB saved) — while encoding strictly more information per hash (alpha, aspect ratio, full DCT channels)

This will also be integrated and available in Vector Messenger. You will be able to test it out yourself in the next release, v0.3.1. Attached is an image preview of what it will look like inside of the Vector GUI.

We encourage transitioning to fast-thumbhash to maintain full unanimity of Marmot clients on our provably higher fidelity, faster and Nostr-optimised library JeffG (nprofile…mgxf)
https://github.com/marmot-protocol/mdk/pull/195

Everyday, the Nostr network is expanding 🙏

2026-02-16T23:25:18Z

In reply to nevent1q…ypm0
_________________________

Everyday, the Nostr network is expanding 🙏

> Rescanning system for $200m from the US government. > No ...

2026-02-16T19:20:19Z

In reply to nevent1q…25r8
_________________________

> Rescanning system for $200m from the US government.

> No such file or directory.

We have confirmed the authenticity of this comment.

Vector is now listed on the UP Phone (Unplugged)! Are there any ...

2026-02-16T19:17:53Z

Vector is now listed on the UP Phone (Unplugged)!

Are there any other Nostr-based apps on the UP Phone App Store?

Unplugged (UP Phone) is a privacy-focused smart phone that provides a bunch of features to protect their users from unwanted and unsolicited surveillance.

If you'd like to learn more about them, check out http://unplugged.com.

Waiting patiently for this... 👀

2026-02-16T19:14:56Z

In reply to nevent1q…lglw
_________________________

Waiting patiently for this... 👀

Hey @nprofile…vgpv in full transparency, there are a lot of ...

2026-02-16T16:27:27Z

In reply to nevent1q…lerc
_________________________

Hey xt0f (nprofile…vgpv) in full transparency, there are a lot of features and UX/UI improvements that Vector still requires to operate on the same level, as we are still in Open Beta... but you can see this infographic that breaks down degrees of privacy by Formless Labs for more information.

We'd like to take a moment and thank @nprofile…fdyh for ...

2026-02-11T14:54:07Z

We'd like to take a moment and thank elsat (nprofile…fdyh) for their latest PR for the Vector Privacy codebase to improve Nostr-based communications with NIP-17 kind 10050. It has been merged.

You are what makes open-source culture what it is and why it is so amazing. There is nothing that can compare to the power of people united around the world and contributing towards the same vision and values. Thank you, truly. Your GitHub is insane by the way, in the best possible way.

This PR adds NIP-17 inbox relay support so DMs are now sent to the recipient's preferred inbox relays (kind 10050 lists) instead of broadcasting to every relay in the pool — with caching, fallback, and stampede prevention. It also auto-publishes and updates your own inbox relay list whenever you connect or change relay config.

Before This PR:

When you sent a DM, Vector just threw it at all your relays and hoped the other person would see it. Now it asks "hey, where does this person actually want their messages?" and sends it there specifically like mailing a letter to someone's actual address instead of dropping copies at every post office in town. It also tells other people where your mailbox is, automatically.

GitHub PR #44:
https://github.com/VectorPrivacy/Vector/pull/44

💚

2026-02-09T14:20:54Z

In reply to nevent1q…sf9z
_________________________

💚

🟢Feature Highlight (Privacy) ⛔Prevent URL Tracking What is ...

2026-02-07T04:24:25Z

🟢Feature Highlight (Privacy)

⛔Prevent URL Tracking

What is URL Tracking?

Link tracking or URL tracking is primarily a marketing and advertising tool for companies to learn more about their users. Examples are where a user shared a link from, who they shared it with, who clicked/engaged with the link, and so on. Affiliate links are one of the most common examples of URL Tracking. They are more or less undesired cookies that we didn't ask for or sign up for.

Another common example is UTM (Urchin Tracking Module) and it is designed to track and analyze the performance of marketing campaigns by identifying traffic sources. Surely, you have seen the super long URLs with snippets added like utm_source, utm_medium, utm_campaign, and so on.

Example:
website.com/?utm_source=facebook&utm_medium=social&utm_campaign=sale

✅Vector Fixes This
As soon as you paste a link with the URL tracking on it you copied from somewhere online, it is automatically detected and stripped so the tracking stops there. You are no longer passing along unwanted trackers on yourself and to your contacts.

+1 Arrow

2026-02-06T13:22:03Z

In reply to nevent1q…fder
_________________________

+1 Arrow

Censorship-Resistance is the key to Freedom. ...

2026-02-05T16:20:24Z

Censorship-Resistance is the key to Freedom.

Nostr event nevent1qqs8mxtg3du2nxlhhdw5h7t4zhdas2vqnlx30w33sru5qz9jx003n4gzyzu0jtnpuuw5tp4wdlnfwrmnm58ahzgpp9vfut6p00h5gkam4ykg6ca0es7

2026-02-05T11:46:00Z

Pushing The Envelope — Privacy Messaging & Communication

Vector Privacy Interview with Co-Founder YuurinBee

1. The Origin Story

"What was the exact moment you realized the world needed Vector Privacy? Was there a specific incident or realization that made you say 'enough is enough' with existing messaging platforms?"

Personally, I first realized the world needed “privacy by default” (as many people like to use the term now) a handful of years ago. Society and the world has blindly trusted these large, tech corporations that just say “private” or “encrypted” being nothing but marketing buzzwords and sadly lacking any bit of truth and substance. That is when I truly saw the need, not demand, but need for privacy in communication—not just with messenger apps, but really extending towards all digital services, platforms, and mediums. As long time Discord users, especially being gamers and shared interests in blockchain and crypto, both JSKitty and I had loved the UX and the communities that had formed on Discord over the past 8 years. During that time, we had created and managed many communities of our own. As time progressed and with more experience, we had noticed very poor security practices, no encryption for messages, and overall growing concerns for Discord’s privacy. Afterwards, it became normal to read about data breaches and personal identities leaked with Discord, as well as many other top social media and messenger platforms. Going back about 5-6 years, we first wanted to create a privacy messenger app called “Hawkie”, but we lacked the technical stack and infrastructure needed, not to mention the knowledge and skill we had back then truly pales in comparison to now. Therefore, it was put on the shelf with many other fun and unique ideas to develop until we discovered Nostr. Nostr (Notes and Other Stuff Transmitted by Relays) is an open, decentralized protocol that supports many of the foundational principles that we required both philosophically and technically.

2. The Privacy Crisis

"Most people think 'I have nothing to hide, so why should I care about privacy?' How do you respond to that, and what are the hidden costs of surrendering our digital privacy that people don't realize?"

This is a splendid question and there’s quite a bit to say. It depends on the person I am talking to because I look for specific ways to relate to their potential problems that could follow based on their life and lifestyle practices.

I respond to this comment almost everyday or at least every week, if not from the very people we built Vector for, but also while developing Vector I get this question relentlessly. One of the biggest takeaways in life I can share with you in the modern world, we often compromise security for convenience. We are so used to wanting everything so easy, just one click, login with one account and do a million things, save my passwords so I don’t have to remember, backup to iCloud so I can access my files and photos anywhere. There is nothing wrong with wanting simplicity and a universally convenient user experience, but most of us are unaware of the unforeseen consequences and you really have to ask yourself “is it really that much more effort”?. What is the trade off? What is the opportunity cost here? It is simply evaluating the risks and hopefully choosing the choice that ensures the highest level of risk mitigation. Is it that much more effort to safely store your seed phrase or private key somewhere offline than it is to drive to a bank, wait for a teller, express your want to open an account, then spend 15-30 minutes divulging all of your personal information and putting it into their database, then being told you’ll get a card in 3-5 business days before you can really even fully utilize the account and system. Oops, I forgot to tell you they are closed after 5pm and not open on the weekends. Is it really more convenient? We have been conditioned this way because of the systems society has adopted for many years. It does not imply that they are optimal or even efficient at all… quite the contrary most people would argue.

To the world famous question “I have nothing to hide, so why should I care about privacy?”... I would respond by asking people questions to make them think and reevaluate what privacy means (some better than others lol). If you have nothing to hide, why not keep your windows open and your blinds open all the time? Why even bother putting walls up? I guess if you don’t care about privacy, there’s no need for clothes right? Why even bother putting up doors if you don’t mind people walking into your house and taking a look around, you’ve got nothing to hide right? Why don’t you put your phone on speaker while you’re in public and let everyone in on your conversation if you’ve really got nothing to hide? As silly and ridiculous as these questions are, it is about changing the mindset of how we view privacy. There has been a negative and a dark connotation around privacy that it’s only for people who have things to hide. Privacy is about security, not about hiding.

3. The Metadata Problem

"Vector emphasizes 'No Metadata.' Can you explain what metadata is, why it's arguably more dangerous than the actual message content, and how Vector solves this?"

Metadata is like digital bread crumbs. Metadata is simply additional data that can be viewed like online identifiers, whether you want to share them or not. Everything digital has some form of an identity and from that identity is how you interact with the digital world online. Your phone has an IMEI number, which is like a serial number. It even has hardware, firmware, and software information like which operating system are you using, which software version, what type of camera, and much more. This information is potentially exposed when you communicate online. When you login to a website, your IP address is tracked, which is like your personal serial number from your internet provider. This can tell where exactly in the world you viewed the website (it could even be pinpointed to your exact block, house, room). That is why many people have recently started to use VPNs (Virtual Private Networks), to mask this connection and make it more secure as nobody wants to be communicating to the world where exactly they live. It is an irrelevant bit of information that comes with many risks and zero real benefits.

The more information that nefarious, bad actors have on you makes it easier for them to infiltrate your life and cause a whole world of chaos and pain. This ranges from identity theft to stealing your bank account information, leading to a loss of money or assets, to committing crimes on your behalf, you name it.How does Vector solve this? By design. It does not collect this information as it has no need for it. Private messages should be only between two parties or any amount of disclosed members, consensually. Most companies, especially that offer “free” services, really are collecting your metadata and personal information in order to monetize it. They want to understand you, your behavior, and exploit your own psychology and patterns to try and sell you things. These companies can sell this information to third party marketing and advertisement brokers, if they don’t run a similar service internally. Information is digital gold, but it is not rocks they are mining, but people.

4. Decentralization vs. Corporate Control

"Signal, WhatsApp, Telegram—they all claim to be secure. What's fundamentally different about Vector's decentralized approach, and why does centralization make those platforms vulnerable no matter how good their encryption is?"

None of those apps can prove they are, except for Signal, which invented the Signal Protocol. This was groundbreaking at the time for end-to-end encrypted messaging and used for many years by many apps, until more advanced protocols came about. The issue with data centralization, as the name implies, is a centralized unit—a central point of attack could wipe out or simply compromise an entire network. Decentralization makes this astronomically more difficult, depending on the levels of decentralization and method. For the record, I would like to share with readers that just because something says “decentralized” does not really mean it is or that it is secure. There are many blockchain projects that claim to be decentralized and have 11 nodes, which they control a majority of. You must always do your own research to study the degrees of decentralization, privacy, and security.

Centralization also means single point of failure in terms of continuity.Centralization indeed makes those platforms more vulnerable, regardless of how good your encryption is. Encryption alone is not enough, but only one element. Just like decentralization, it is not enough on its own, but one important element. Here is a great infographic, research by Formless Labs, that covers this subject a bit more in detail, along with privacy.

5. Real-World Use Cases

"Beyond activists and journalists, who should be using Vector Privacy? Can you share why someone might consider using Vector instead of WhatsApp for example?

Wonderful question. Vector is designed for everyone. This is our intention, from the first foundational pillar laid. Understand that Vector is currently only in Open Beta and has a very unique branding and style, but will be modular and customizable so that people can truly create their ideal setup for communication, whatever the use case. We want to normalize privacy and have it so people don’t even have to know or care about privacy, just simply loving the Vector Privacy UX is enough. Their privacy is protected and our job is complete.

As a UX/UI developer, it is my personal goal to make it universal, but to dig deeper than that is really to make it fun, make it enjoyable. In the modern world, most of us communicate online because our networks are so big and vast. We have friends, family, and colleagues all over the world. This is the future of communication, it will mostly be digital. So, there needs to be a lot of emphasis and focus on the detail, the how. That is where my interests and knowledge in psychology hopefully comes in handy, not to exploit the human mind for dopamine traps and quick fixes to monetize actions, but to design in a way that is synchronistic, fluid, and feels natural with people.Messenger apps are often so limiting, we have barely scratched the surface. Especially with privacy messenger apps, most of them have a horrible UX that feels slow, unintuitive, and clunky… lacking any soul and void of anything that resembles humanity. We want to reinvent digital communication so that it feels effortless to truly express what is on your mind and heart. Let the end user focus on how good it feels to communicate and use Vector. Let us celebrate and sleep easy at night knowing that their privacy is protected.

6. The No-KYC Philosophy

“Vector requires no phone number, no email, and no KYC which is rare. Vector has made anonymity at signup a critical feature. Why?"

You will hear me say this on repeat, if you haven’t already. KYC is the greatest threat to privacy and the worst design for privacy. In a high-trust society, exactly how we grew up thinking (naive), but that when companies collected our data, we trusted them because we thought it made logical sense to provide this information in order for them to do their jobs more efficiently. There is still some truth to that. The general concept of KYC is not bad, but implementing it into the modern world with digital, online systems is a horrible idea as we have witnessed time and time again. It does not matter how great your security is or how big your company is, how much money they make, how many B’s in their total market cap, how many people in the cybersecurity department, but they are exposed to the same threats as every other entity operating online. The worst part about it? It is our data, the customer’s data, that is compromised and exposed online and to the dark web.There needs to be a redesign of this traditional model and I think there are a lot of great minds and developers working on alternatives, but for now KYC is a major threat to security and privacy. Never give more information than you have to. If it feels too intrusive, stop and look for other alternatives. I can assure you there are many great alternatives out there. Simply removing the need for KYC or any form of alternative identity linking already makes the experience objectively more secure. If there is no data, then what?Vector is a standalone, open-source privacy protocol that doesn’t have an interest or use for a user’s personal data. Therefore, it doesn’t collect it.

7. Open Source Trust

"Vector is open source. Why is that non-negotiable for a privacy tool, and what would you say to someone who asks 'Why should I trust Vector more than a closed-source app from a big company?'"

Why would you trust something created by humans that you can’t see and verify in some way or form? Would you trust test results from a pharmaceutical company telling you how their new product is better and safer without seeing the results yourself? …especially being able to see what scientists signed off on the reports publicly. Then, you can do a deeper background check on these scientists to see if they are credible or are bought out and make your own conclusion. That is precisely how open source works. You can see the current state of the codebase, what changes were made by who and when, and you can even look deeper into those contributors to see what else they work on and virtually do a whole background check online. Furthermore, look at open source as the best way to get international peer review from people whether you want it or not. It is the true test of time. The best protocols are open source and I am more aligned with the philosophy and culture of open-source than anything. Most business models actually benefit off of their customers not knowing, being in the dark. For example, they don’t know their recipe, their trade secrets, etc. That is how they profit almost inexorably. Well, how do open-source projects make money? Many of them can still operate a for-profit model, while the codebase is open-source, but a lot of open-source projects choose the non-profit route and accept donations and grants. If there is a will, there is a way. 9/10 I will always trust and have more respect for open-source projects than not. For the record, just because something is open-source doesn’t not implicitly imply that it is safe nor secure. It only implies that the codebase is transparent and under the premise of it being accessible to everyone, it has a higher chance of other developers or contributors potentially identifying bugs, critical issues, or even suggesting improvements and optimizations. The odds are certainly higher. As the saying goes "If you have an apple and I have an apple and we exchange these apples, then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.".

8. The Surveillance Economy

"Tech giants make billions selling user data and attention. Vector is free and doesn't monetize user data. How is that sustainable, and why should users trust that Vector won't 'pivot' to ads or data sales later?"

Absolutely, that is precisely what these tech conglomerates do and have been doing for decades, mostly unknown to the general public. There is indeed no such thing as a free lunch, energy has to always come from somewhere. Vector is sustainable simply for the fact that it is built on a robust and decentralized network out of any single individual’s control and power. It will survive, whether we want it to or not. The biggest threats, which are temporary, are really just internet outages more than anything. Why users should trust Vector? Don’t trust, verify. There is always a chance that anything could happen with any project. Even Bitcoin’s network was attacked by bad actors, years ago and even recently lol. Things don’t stay the same forever, but what’s important to know is that for the simple fact Vector is open-source, it could be forked and modified by anyone. If it had ads that someone didn’t like, they could fork the Vector Privacy repository and recreate it without ads for their own personal preference and even launch their own chat app. We encourage people to peer review and share feedback. Those are the basics for any true open-source app.Vector cannot pivot to data sales simply for the fact it doesn’t collect personal user data. It cannot and will not, by its protocol functionality and limitations alone. What data could be sold and who on earth would buy it?Fun Fact: The core contributors and founders of Vector Privacy cannot stand ads.

9. Network Effects & Adoption

"The hardest part of any messaging app is getting people to switch. Everyone is already on WhatsApp, Telegram, Discord, and Facebook Messenger. How do you convince someone to move their entire social circle to Vector, and what's your strategy for overcoming the network effect?"

100% legitimate question and no doubt, one of the biggest challenges. Part of our strategy is really to focus on the user experience. For future reference, let’s assume privacy is always a core focus for Vector and doesn’t need to always be mentioned. As I was sharing above, most messenger apps are not what people want or enjoy, they just don’t know any alternatives or like you shared, that’s where their entire social circles are.

I foresee the growth of Vector being steady and organic. The best thing we can do is work with our community and the users to optimize their experience and also allow for high-level customization. We don’t want to force anything on anyone, that is one of the biggest things that prompted us to build our own app. So many apps force you to use their trash UX and do actions that you really don’t agree with or want to do, but have to in order to execute your intended goal.

Once people have had enough with their privacy being completely invaded and compromised on these other apps, they will abruptly leave and say if you want to message me, you can message me on Vector. How do I know? because I’ve already watched it happen both with Vector and other messenger apps. Once Vector is further along the development pipeline and distributed through the most popular app stores, I think it will be much easier and the user experience will speak for itself. I am not under the impression that people will immediately think Vector is better and more fun, but I will be putting in my blood, sweat, and tears to make that a reality.

Retention is one of the biggest key factors of success for any and all applications. Why are people coming back? They have no other options, they love it, or it simply solves the problem(s) they have. I think one strategy is to focus on group chats and larger social networks, so that people don’t just log on to message their one friend privately. They can join other social groups, meet, interact, learn, and have fun like they would anywhere else online. Vector needs to be a home for people.

10. The Future of Privacy

"If Vector achieves mass adoption, what does the world look like in 5-10 years? What changes when billions of people have access to truly private, decentralized communication?"

It is insane to imagine, honestly. With the rapid development of AI and technology we have already crossed the threshold of there being more AI-generated content on the internet than actual content generated by people for the past few decades. Yes, insane is the correct word. Terrifying as well knowing that if humanity itself doesn’t evolve to a higher standard of living, one with shared moral values, the technology we invent will continue to evolve and we will repeat the same cycles of suffering, but much quicker and more powerful. What I’m hoping happens is that society comes to a consensus on privacy being a basic, fundamental human right and there will be laws implemented that protect, rather than destroy. To be clear, I am certainly not under the illusion that this will or is likely to happen, but I remain confident in the resiliency of the human spirit and fight for freedom. Free, open-source, and permissionless technology will thrive.

TLDR: Nothing new under the sun, but at least we have more privacy. :kek:

11. The Call to Action

"If someone is reading this interview and thinking 'this sounds great, but I'll switch later,' what would you say to them? Why should they download Vector today instead of waiting?"

"If you don't believe me or don't get it, I don't have time to try to convince you, sorry." Lol, jk. I spent an hour typing up this response to answer all of these questions so you could understand… but really “there's a difference between knowing the path and walking the path.” and I look forward to seeing you on the other side. Don’t act like you don’t download new apps every week or so. You don’t have to convert, it’s not a cult, it’s a privacy messenger app. Add me on Vector:https://vectorapp.io/profile/npub12w73tzcqgpr2pcy4el5x60d2emeud4cyeeayynzqqg2fefzgytaqm4ktz3

Additional Questions

"How do you view Signal/Telegram/Session as competitors vs. allies in the broader privacy movement?"

Great, love it. Give people options. These organizations and apps you listed have achieved great tasks and nothing but respect for them overall. You simply cannot deny the good and for the most part what it has done for the public’s perception of privacy. I like to see people as advocates of privacy, then in some way shape or form, we are on the same team. We are after all open-source, there are no trade secrets we need to protect in order to stay financially solvent lol. People using these apps does Vector no harm whatsoever, in fact they could even be a gateway into privacy for many… eventually leading them to test out Vector. Win, win.

"What happens if a government demands user data or tries to shut Vector down?"

What user data? There is no user data collected nor do founders, contributors, or users have access to other user’s data. As for “shutting down Vector”, it is an open-source, decentralized protocol. So, I guess shut down the internet and that’s a good place to start.

"Vector seems technical. How do you make it accessible to non-technical users who just want to chat with friends?"

It may appear technical, but really it shouldn’t be. Log on to Vector like you would any other messenger app, but with less steps. Yes, there are a few things to learn along the way like your private key and seed phrase, but we aim to make this more simple with each release. A great place to reference is the official docs on docs.vectorapp.io. We have a Beginner’s Guide, as well as each aspect of the app broken down to make it easier to understand if there is any confusion. Furthermore, join our community of people around the world who would love to help you get setup and learn more. For the time being, join the Vector Community Discord.

Interview conducted by Sir Clodsworth III — Vector Privacy 2026

Vector 💚 Marmot

2026-02-05T11:04:47Z

In reply to nevent1q…ng0p
_________________________

Vector 💚 Marmot

Glad you asked, 100% relevant of a question anyways. Just more ...

2026-02-05T02:12:14Z

In reply to nevent1q…xn6p
_________________________

Glad you asked, 100% relevant of a question anyways. Just more love for the craft.

Great projects you mentioned, we're really hoping this becomes the standard. Decentralized data and personalize your own privacy.

Let us check it out. Saw this circulating on social media, but haven't read it yet.

Woah, thank you for the zaps! 🙏 ❤️

2026-02-05T02:10:39Z

In reply to nevent1q…7df5
_________________________

Woah, thank you for the zaps! 🙏 ❤️

Wow! These look great on Nostr, Bee!

2026-02-04T13:03:05Z

In reply to nevent1q…czuv
_________________________

Wow! These look great on Nostr, Bee!

Not sure 100% the implications of levels of security judging ...

2026-02-04T13:01:45Z

In reply to nevent1q…0htz
_________________________

Not sure 100% the implications of levels of security judging purely from app size alone, it can be quite subjective. Just because an app is smaller in size doesn't mean it is less vulnerable, but more importantly just because an app is larger in size certainly doesn't imply there are more security measures in place.

Our whole take is just minimalism and efficiency, which ultimately affects the end user. Something taking 5 seconds more to load could be the difference of someone switching to a less private app, simply due to convenience and UX. With privacy as our foundation, UX now becomes one of the biggest focuses.

We would really recommend checking out the Vector Privacy Policy if you're interested to learn more in detail, it is both on our website and Gitbook. To summarize, we don't collect nor have access to anyone's data simply by architectural design. How can we give data that we ourselves don't possess or have access to? ;)

https://vectorapp.io/privacy-policy/
https://vector-privacy.gitbook.io/vector-privacy/help-center/privacy-policy

Will be looking for more opportunities and ways to contribute, ...

2026-02-04T12:51:32Z

In reply to nevent1q…fxwg
_________________________

Will be looking for more opportunities and ways to contribute, however we can. 🙏

🟢 [ V E C T O R ] Open Beta v0.3.0 The first release of 2026 ...

2026-01-31T18:01:30Z

🟢 [ V E C T O R ] Open Beta v0.3.0

The first release of 2026 and it's going to be a difficult one to match. This is by far the biggest Vector release to date and we couldn't be more excited to share it with you all.

🔰 https://vectorapp.io

Important:
Group Chats have undergone several breaking-changes, due to the lack of stability in our previous Alpha Group Chats implementation, and thereby their lack of usage; Group Chats will be reset when you download v0.3.0, please re-create any Groups you previously owned.

New:
🧩 Mini Apps Platform: WebXDC-based games & apps within Vector with P2P Multiplayer (Yes, it plays DOOM!)
🏪 The Nexus: discover and install Mini Apps from a secure, decentralized App Store, built for Vector
🌐 Custom Relays: configure your own preferred relays for personalized connectivity
🎨 New Themes: three additional themes, each with their own exotic takes, Keep it Purple, people
🔔 Notification Sounds: audio notifications, with our homemade Prélude sound, custom sounds, and smart caching
🖼️ GIF Picker & Inline Images: search and send GIFs directly from the chatbox, powered by GIFverse
👋 Leave Group: ability to leave groups, with proper system event notifications for everyone else
✏️ Message Editing: edit sent messages with full history tracking
⌨️ Popup Shortcuts: Enter to confirm, Escape to close popups; ESC to cancel Reply/Edit

Improved:
🔐 MLS Overhaul: major messaging protocol improvements for reliability and security, based on the latest MDK
📂 MIP-04 File Sharing: imeta attachment handling for MLS groups, built for compatibility with White Noise
⚡ Memory Optimizations: reduced memory usage during image uploads (around 4x less!)
🗄️ Database Performance: migration system overhaul with improved stability, safety and performance
💬 Message Bubbles: refined corner rounding, grouping and a new "Sending/Sent" status
🖼️ SVG Optimization: optimized vector graphics across the app (reduced app size!)

Fixed:
🖼️ Profile Sync: avatars and banners now update correctly
⏱️ Chat Timestamps: fixed timestamps disrupting avatar/message streaking
💬 Typing Indicators: deduplicated indicators and optimized performance
🔄 Reply Context: replies now display the latest edited content
🔍 Search Box: fixed styling and typing indicator expiries

This is what the video looks like in Vector. Somehow it got ...

2026-01-28T21:45:36Z

In reply to nevent1q…z0um
_________________________

This is what the video looks like in Vector.
Somehow it got absolutely rekt here on Nostr (uploaded from Damus).

but thank you all at WhiteNoise and Marmot 🙏

OxChat is great. 0xChat: - iOS (App Store): ~196 MB - Android : ...

2026-01-28T10:35:07Z

In reply to nevent1q…8xna
_________________________

OxChat is great.

0xChat:
- iOS (App Store): ~196 MB
- Android : ~85–103 MB
- Desktop: ~54.82 MB (Based on latest v1.5.3)

Keychat:
- iOS: ~93.5 MB
- Desktop: ~29.25 MB

Always nice to be aware of these matters.
If you have any findings that show different data, please let us know.

The Ancient Art of Optimization™ After doing some research and ...

2026-01-27T21:23:13Z

The Ancient Art of Optimization™

After doing some research and comparison with other messenger apps, both private and not, we wanted to share with you all our findings. On average as it varies across different operating systems, Vector's app size is ~25 MB. To compare it with the other apps out there, we have used one "Vector Floppy Disk" for you to visualize how many "Vectors per x app". For starters, you can see there are about 17 Vectors per Signal (Signal is 17x the size of Vector). Let the numbers speak for themselves. This is reasonable and likely to change and grow with time, but many apps get stuck in this data drain and fail to optimize their codebase, which negatively affects the end user. Vector is intended and designed for every OS and platform out there, to reach the hands of everyone on the planet. If we can't get it working how we want the first time, keep optimizing...

Vector Privacy — Privacy Policy Updated (January 21, 2026) As ...

2026-01-22T14:22:00Z

Vector Privacy — Privacy Policy Updated
(January 21, 2026)

As of January 21, 2026, we have officially published the Vector Privacy Policy, which is available on the official website as well as the Vector Privacy Gitbook. For those that are interested, we recommend checking out and reading the latest Privacy Policy to clearly understand about Vector Privacy and how we operate. We have done our best to be as transparent as possible and will always update the community as frequently as possible. If you all have any questions or suggestions, please feel free to comment.

Privacy Policy (Website):
https://vectorapp.io/privacy-policy/

Privacy Policy (Gitbook):
https://vector-privacy.gitbook.io/vector-privacy/guides/guides/vector-node-setup-nostr

11.2 — Never Forget. Thanks for sharing this and glad you took ...

2026-01-22T14:03:35Z

In reply to nevent1q…f93v
_________________________

11.2 — Never Forget. Thanks for sharing this and glad you took a moment to read the details and fine print.

Full Nostr Relay Node Guide (Linux - Ubuntu 22 + Strfry) Adding ...

2026-01-06T11:12:12Z

Full Nostr Relay Node Guide
(Linux - Ubuntu 22 + Strfry)

Adding to the last announcement, we wanted to share a bit more about what it means and extend the opportunity to all those who are interested in supporting data decentralization by self-hosting a Full Vector Node on the relay network Nostr.

We have just published a full guide on GitBook for Linux (Ubuntu 22) that gives you a step-by-step process on how to host your own node. The spec requirements are listed in the GitBook documentation. If anyone is interested or has any questions, just ask in ⁠the Vector Discord and the community will help you get set up!

Vector Node Setup Guide:
https://vector-privacy.gitbook.io/vector-privacy/guides/guides/vector-node-setup-nostr

#nostr #nostrdevs #grownostr #decentralization

Vector Privacy on the rise.

2026-01-06T11:04:48Z

In reply to nevent1q…wd33
_________________________

Vector Privacy on the rise.

We've Added a New Nostr Node for Asia! ...

2026-01-05T14:42:39Z

We've Added a New Nostr Node for Asia!

wss://asia.vectorapp.io/nostr

To help support the resiliency of the decentralized relay network, we have added a new node in 🇭🇰 Hong Kong to support users in Asia with a better relay time and connectivity. In the near future, Vector will be adding support to allow users to add their own desired relays in the Settings. If you'd like to learn how to setup a Vector Node on the Nostr Network, please check out the guide below.

Learn how to setup a Nostr Node:
https://vector-privacy.gitbook.io/vector-privacy/guides/guides/vector-node-setup-nostr

You will like what's cooking for this year ;) Will most ...

2026-01-01T13:20:16Z

In reply to nevent1q…j0ry
_________________________

You will like what's cooking for this year ;) Will most likely organize some game nights for the community.

We're on the lookout for stable Blossom servers that allow ...

2026-01-01T13:19:26Z

In reply to nevent1q…q2zk
_________________________

We're on the lookout for stable Blossom servers that allow for Encrypted Blobs and any Mime Types to upgrade performance and stability for 2026. Feel free to connect us with anyone who may know. Thanks!

Thanks for sharing this with us @nprofile…7ysa Our team will ...

2025-12-23T13:29:59Z

In reply to nevent1q…prg5
_________________________

Thanks for sharing this with us Keychat (nprofile…7ysa) Our team will look more into what you have shared to dive deeper into the protocols' pros and cons.

Decentralized Quake III? Where nostalgia meets privacy tech. ...

2025-12-23T13:28:43Z

Decentralized Quake III?

Where nostalgia meets privacy tech.

Decentralized gaming now being tested on Vector. No blockchain, no servers, no bullshit.... well lag, that's still bullshit. Local/Regional gameplay is perfect. Playing halfway around the world is not optimal, but still playable. Ping obviously offers massive advantages in fast-paced FPS games.

If anyone is interested in testing the limits with us, download the Pre-Release (v0.3.0):
https://github.com/VectorPrivacy/Vector/releases/tag/v0.3.0

🟢 [ V E C T O R ] Open Beta v0.2.3 Behold, the latest release ...

2025-12-15T13:33:55Z

🟢 [ V E C T O R ] Open Beta v0.2.3

Behold, the latest release of Vector Beta in 2025! Additional overhaul of UX improvements, added features, and the first iteration of Vector Web Profiles that function like contact cards via the web.

🔰 https://vectorapp.io

🧵Updates Below

New:
- 🪪 Vector Web Profiles: you can now share your profile "Contact Card" over the web, with one‑click adding, try this! https://vectorapp.io/profile/npub1gwfpm6l8fhn6rs83j8rjjnjgkdqv89chd2fdhy6zc2uvpuwf39vsfuxxee
- 🎤 Overhauled Voice Messaging: a completely new Voice Messaging experience, with intuitive gestures & sleek UI.
- 📁 Upload Previews: files are now previewed prior to uploading, giving you a chance to review and confirm.
- 🗂️ Image Compression: images are now intelligently compressed before uploading; full‑quality is just a switch!
- 🖼️ Window Persistence: Vector now remembers how you size and position your app.

Improved:
- 🖌️ UI Revamp: a glassy, animated header, redesigned popups, mini‑avatars, group creator UI, and more.
- 💬 Expanding Chatbox: the real OG of this update; your chatbox finally expands to the size of your yap.
- ⚡️ On‑Demand Decryption: Vector no longer decrypts fully at boot, but on‑demand, vastly reducing RAM & CPU use.

Fixed:
- ⚡️ Flashbang: Vector had a brief "white flash" at startup, nicknamed “the flashbang”, this has been resolved.
- 🪵 Fixed Logouts: on some systems, particularly Windows, logouts were failing; this is now fixed.
- 📨 Several Unread‑System Bugs: more reliable read markers and better cross‑device compatibility.
- 📥 Improved Download Stability: attachment downloads are more stable and less resource‑wasteful.
- ⌨️ Removed Search OS Autocorrect: the Emoji Search was often interrupted by OS autocorrect, now disabled.

🙏💚

2025-12-14T03:24:09Z

In reply to nevent1q…psy4
_________________________

🙏💚

Welcome aboard, friend. 🫡💚

2025-12-07T20:30:05Z

In reply to nevent1q…j4g3
_________________________

Welcome aboard, friend. 🫡💚

Sending safe wishes your way, friend. (Late appreciation for your ...

2025-12-07T13:59:44Z

In reply to nevent1q…z26r
_________________________

Sending safe wishes your way, friend.

(Late appreciation for your mention of Vector in Nostr Recap, too! 🙏💚)

Vector Privacy is now on GitBook! The past couple of weeks, we ...

2025-12-04T09:34:24Z

Vector Privacy is now on GitBook!

The past couple of weeks, we have been working to populate the GitBook documentation where everyone can learn more about Vector, from novices to experts. GitBook is designed for your average person to be able to read and understand, along with more specific documentation for developers.

We have begun to outline the entire Vector Privacy ecosystem, as well as breaking down specifics about Vector Messenger. Visit either link below and you can go from top to bottom with the pagination feature or you can click on specific pages that interest you.

If privacy interests you, be sure to visit the Privacy page.

Visit the GitBook:
https://docs.vectorapp.io

🟢 [ V E C T O R ] Open Beta v0.2.2 >>> ...

2025-11-30T16:05:39Z

🟢 [ V E C T O R ] Open Beta v0.2.2
>>> https://vectorapp.io <<<

We are happy to share with you all the latest release—weeks worth of polish, updates, and improvements. From a complete database rewrite, to new features, bug fixes, and a smoother user experience. It will be a significant and noticeable change, especially for Group Chats and visiting the Settings tab.

💡 Feature Spotlight: Android Support

We have now released the public Android APK that has been officially published on GitHub. There is also mobile support via the website (listed above), where you’ll find a download button for your Android device.

Development Updates:

New:
📲 Android APK: the first public Android APK is now available for Vector!

📦 Storage Manager: a Settings section that gives a glance-able breakdown of Vector's storage usage.

👥 Primary Device Setting: a new setting that allows you to set a device to receive future Group Invites.

💽 New Database: Vector now uses SQLite (w/ encryption layer) for ultra-fast, reliable, compact persistence.

Improved:
🛜 Faster Synchronization: parallel processing enables Vector's syncing to be noticeably faster.

📂 New File Attachment Design: a significant design overhaul when transferring non-media files.

👤 Profile Shortcuts: in the Group Overview, you can now click on anyone to visit their profile.

📨 Profile Message Shortcut: you can now hit "Message" on anyone's profile to jump straight in their DMs.

⚙️ Settings Dangerzone Redesign: a beautiful Settings polish, along with a redesign of The Dangerzone.

💌 New Invite Design: incoming invitations look significantly nicer. (and the 'Notif Dot' displays on Pending Invites!).

🖼️ Improved Popup UI Design: a well-needed polish to an old UI flow.

📝 Improved Selection Highlights: a Vector-esque Gray is now used for the Selection Highlight colour.

Fixed:
📨 Fixed 'slow/stuck' Group Chat messages: a race condition, plus many inefficiencies, were resolved in Group Chat messaging, making it feel significantly smoother and snappier.

📪 Fixed automatic 'Mark as Read': on Windows particularly, 'auto-Mark-as-Read' now works consistently.

🐧 Fixed potential Linux Media crashes: on Linux, playable media is now displayed as regular File Attachments, preventing a crash when Videos or Audio cannot be loaded.

🐱 Fixed 'jitter' on first Emoji Panel open: the Emoji Panel rendering has been optimised, removing 'jitter' when first opened.

📺 Fixed intense "UI Flickering" in the Chatlist during sync: no more login seizures.

👍 Fixed Reactions in Group Chats: for spamming 🍆 on every post until you're inevitably banned.

👥 Fixed newly-joined Group Chat bugs: they no longer drop to the bottom of your chatlist on join, and the "Header" is now clickable even if no messages were sent in the group yet.

🎆 Fixed 'PNG-Pill' on tiny images: Emoji-sized images now hide the File Extension Tag, a.k.a, the "PNG Pill".

🟢 Removed 'Status Dot' from Group Chats: this is meant for people, not rooms.

🖥️ Fixed excessive Group Chat re-renders: shaves some CPU usage from Group Chat UI.

🖥️ Fixed excessive Typing Indicator events: shaves some CPU usage from Typing Indicators.

🖥️ Fixed excessive Chat Timestamp re-renders: shaves some CPU usage from 'last message' timestamp updates.

🖱️ Fixed "Double Scrollbar" at startup: rarely, a "double" scrollbar displayed while Vector was booting.

Learn More:
https://github.com/VectorPrivacy/Vector/releases/tag/v0.2.2

Congratulations on the latest release! 🥳 Thanks for fighting ...

2025-11-23T21:18:29Z

In reply to nevent1q…c8sg
_________________________

Congratulations on the latest release! 🥳 Thanks for fighting for the right to free speech and privacy. FOSS is the way. 💪

Nostr event nevent1qqswmefyllweh9ffra2qxj7zy6gpxantk9793lhhdh27uea9f3njcgszyzu0jtnpuuw5tp4wdlnfwrmnm58ahzgpp9vfut6p00h5gkam4ykg659qda3

2025-11-22T18:23:44Z

Another good day to choose private, encrypted messaging. ✅ ...

2025-11-15T13:10:01Z

Another good day to choose private, encrypted messaging.

✅ Nostr accounts are supported

https://vectorapp.io

"My North Star on the topic remains that all humans flourish ...

2025-11-14T08:43:33Z

"My North Star on the topic remains that all humans flourish under the protection of privacy; it creates a space for reflection and action which invariably leads to stronger personal conviction and the development of true identity. That's what guides us, internally and alongside others, not the piece of plastic a government tosses at us."
—nprofile1qqsv7xnxmvek9q98l86qckdrnal6jmpsj3t2xxnu2038j5lrgcqsm5gu2ge59

Always a good day to revisit A Cypherpunk's Manifesto ...

2025-11-13T04:36:29Z

Always a good day to revisit A Cypherpunk's Manifesto
https://www.activism.net/cypherpunk/manifesto.html

"Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know, but a secret matter is something one doesn't want anybody to know. Privacy is the power to selectively reveal oneself to the world.

If two parties have some sort of dealings, then each has a memory of their interaction. Each party can speak about their own memory of this; how could anyone prevent it? One could pass laws against it, but the freedom of speech, even more than privacy, is fundamental to an open society; we seek not to restrict any speech at all. If many parties speak together in the same forum, each can speak to all the others and aggregate together knowledge about individuals and other parties. The power of electronic communications has enabled such group speech, and it will not go away merely because we might want it to.

Since we desire privacy, we must ensure that each party to a transaction have knowledge only of that which is directly necessary for that transaction. Since any information can be spoken of, we must ensure that we reveal as little as possible. In most cases personal identity is not salient. When I purchase a magazine at a store and hand cash to the clerk, there is no need to know who I am. When I ask my electronic mail provider to send and receive messages, my provider need not know to whom I am speaking or what I am saying or what others are saying to me; my provider only need know how to get the message there and how much I owe them in fees. When my identity is revealed by the underlying mechanism of the transaction, I have no privacy. I cannot here selectively reveal myself; I must always reveal myself.

Therefore, privacy in an open society requires anonymous transaction systems. Until now, cash has been the primary such system. An anonymous transaction system is not a secret transaction system. An anonymous system empowers individuals to reveal their identity when desired and only when desired; this is the essence of privacy.

Privacy in an open society also requires cryptography. If I say something, I want it heard only by those for whom I intend it. If the content of my speech is available to the world, I have no privacy. To encrypt is to indicate the desire for privacy, and to encrypt with weak cryptography is to indicate not too much desire for privacy. Furthermore, to reveal one's identity with assurance when the default is anonymity requires the cryptographic signature.

We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence. It is to their advantage to speak of us, and we should expect that they will speak. To try to prevent their speech is to fight against the realities of information. Information does not just want to be free, it longs to be free. Information expands to fill the available storage space. Information is Rumor's younger, stronger cousin; Information is fleeter of foot, has more eyes, knows more, and understands less than Rumor.

We must defend our own privacy if we expect to have any. We must come together and create systems which allow anonymous transactions to take place. People have been defending their own privacy for centuries with whispers, darkness, envelopes, closed doors, secret handshakes, and couriers. The technologies of the past did not allow for strong privacy, but electronic technologies do.

We the Cypherpunks are dedicated to building anonymous systems. We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money.

Cypherpunks write code. We know that someone has to write software to defend privacy, and since we can't get privacy unless we all do, we're going to write it. We publish our code so that our fellow Cypherpunks may practice and play with it. Our code is free for all to use, worldwide. We don't much care if you don't approve of the software we write. We know that software can't be destroyed and that a widely dispersed system can't be shut down.

Cypherpunks deplore regulations on cryptography, for encryption is fundamentally a private act. The act of encryption, in fact, removes information from the public realm. Even laws against cryptography reach only so far as a nation's border and the arm of its violence. Cryptography will ineluctably spread over the whole globe, and with it the anonymous transactions systems that it makes possible.

For privacy to be widespread it must be part of a social contract. People must come and together deploy these systems for the common good. Privacy only extends so far as the cooperation of one's fellows in society. We the Cypherpunks seek your questions and your concerns and hope we may engage you so that we do not deceive ourselves. We will not, however, be moved out of our course because some may disagree with our goals.

The Cypherpunks are actively engaged in making the networks safer for privacy. Let us proceed together apace.

Onward."

Eric Hughes
March 9, 1993

Thank you for mentioning @nprofile…5jp4 in your writeup! 🙏 ...

2025-11-10T02:32:39Z

In reply to naddr1qq…g0ns
_________________________

Thank you for mentioning VectorPrivacy (nprofile…5jp4) in your writeup! 🙏 Stay tuned for more updates and be sure to follow JSKitty (nprofile…tsc6) & YuurinBee (nprofile…hh2y) for more in regards to Vector's development

Thank you for mentioning @nprofile…5jp4 in your writeup! 🙏 ...

2025-11-10T02:32:21Z

Remember, remember the 5th of November... Vector Open Beta ...

2025-11-05T14:30:38Z

Remember, remember the 5th of November...

Vector Open Beta (v0.2.1) Release

>> 1 Click Login with Nostr

We are happy to announce our official release of Vector Open Beta that now supports fully end-to-end encrypted Group Chats. Nostr users can login with their `nsec` keys, as Vector is built on the decentralized relay network known as Nostr. Thanks to Nostr protocol and community for making this technology possible and publicly available. Vector is happy to share that it ascribes to the same open-source philosophy and aligning with like-minded people and communities.

- Free, Open-Source
- No KYC (No Email, Phone, oAuth, etc.)
- No Data Collection
- No Ads/Spam
- Local Device Data Storage (P2P)
- Decentralized Relay Network (Nostr)

Official Website:
https://vectorapp.io

Official GitHub:
https://github.com/VectorPrivacy/Vector

Counting down... ...

2025-11-04T16:31:50Z

Counting down...

Remember, remember... ...

2025-11-03T23:09:24Z

Remember, remember...

👁‍🗨Privacy Messengers ⚠️Not all "Privacy" ...

2025-10-31T20:33:32Z

👁‍🗨Privacy Messengers
⚠️Not all "Privacy" apps were created equally

There are degrees of privacy, as there are degrees of decentralization. Let's explore what exactly privacy is when it comes to messenger apps. Vector is honored to be building on the Nostr protocol and along with the Nostr community. Check out our research below and comparison of different privacy messenger apps.

Special thanks to JeffG (nprofile…slk3) with White Noise (nprofile…9puf) for their development of Marmot protocol, which we have recently integrated as our Group Chat protocol for sleek, highly-secure, scalable groups and communities.

If you want to show some love for Nostr-based apps, give us a share!

Congratulations, Odell! Homegrown is the way 🙇 🌱 Onwards ...

2025-10-31T20:22:21Z

In reply to nevent1q…v73j
_________________________

Congratulations, Odell! Homegrown is the way 🙇 🌱 Onwards and upwards!

◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢ Vector ...

2025-10-13T01:42:54Z

◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢
Vector Beta available on GitHub!
◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢
⚠️Privacy is a basic human right.
◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢

#Nostr community, enjoy a simple login with your Nostr Account (nsec) and treat yourself to the Vector experience.

◤◢ D O W N L O A D ◤◢ 【 v0.1.9 】
https://github.com/VectorPrivacy/Vector/releases/tag/v0.1.9

#OpenSource #E2E #Privacy

This is precisely why Vector Privacy is built on #Nostr ...

2025-10-08T18:09:14Z

This is precisely why Vector Privacy is built on #Nostr

"We never wanted any humans, any employees (to) have access to private messaging data."

— Pavel Durov, Founder of Telegram

Vector Bot SDK has been released! ...

2025-09-04T16:27:20Z

Vector Bot SDK has been released!
https://github.com/VectorPrivacy/Vector-SDK

The Vector Bot Library is a Rust-based library for creating and managing vector bots that can send and receive private messages using the Nostr protocol. This library provides a structured and modular approach to building bots with configurable metadata and client settings.

Features:
- Create vector bots with customizable metadata
- Send and receive private messages
- Handle notifications for gift wrap events
- Configure proxy settings for .onion relays
- Add and manage relays
- Modular architecture for easy extension and maintenance

Special thanks to Luke Larsen at PIVX Labs for this Vector ecosystem contribution!

Nostr event nevent1qqs98f9tr8mkdkgm42h5cqg9led9t7k9n0c8m9e7trjppm869y8h2hszyzu0jtnpuuw5tp4wdlnfwrmnm58ahzgpp9vfut6p00h5gkam4ykg6wkl5vf

2025-08-27T06:07:03Z

⚠️KYC = Know You're Compromised

Privacy for Protection.

>>> Download Vector Beta <<<
http://vectorapp.io

Good afternoon, Nostr. Among all of the turmoil in the world, ...

2025-08-18T18:33:55Z

Good afternoon, Nostr.

Among all of the turmoil in the world, stay positive. Be a beacon of hope for humanity. We leave you with this quote by Buckminster Fuller...

"You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete."

Thank you, Nostr! Check out our Open-Source Privacy Messenger App ...

2025-08-14T14:03:16Z

In reply to nevent1q…6dla
_________________________

Thank you, Nostr!

Check out our Open-Source Privacy Messenger App built on Nostr:
https://vectorapp.io

Beta Invite Code: B4TZJAUV

Invite Code: B4TZJAUV Thank you for sharing this. We have it ...

2025-08-14T14:00:22Z

In reply to nevent1q…kmwf
_________________________

Invite Code: B4TZJAUV

Thank you for sharing this. We have it pinned on our social media, but will update our Nostr profile to help reflect this as well. We are testing out an invite system in Beta and working on a badge system. Would love to have your honest feedback!

The link above is not working, the correct link is: ...

2025-08-11T23:58:03Z

In reply to nevent1q…w7n5
_________________________

The link above is not working, the correct link is:
https://vectorapp.io

The new privacy standard emerges, thanks to Nostr. Test out ...

2025-08-11T23:31:33Z

The new privacy standard emerges, thanks to Nostr.

Test out Vector (Beta), our privacy messenger app:
-> https://www.vectorapp.io

⚠️#PrivacyisaBasicHumanRight

◤◢◤◢◤◢◤◢◤◢ E R R O R ...

2025-08-06T20:36:58Z

◤◢◤◢◤◢◤◢◤◢ E R R O R ◤◢◤◢◤◢◤◢◤◢
————————————————————————
█▒▒▒▒▒▒▒▒▒ Human Rights failed to load.
————————————————————————
>> Please download [vectorapp.io] and try again...

⚠️Privacy is a basic human right.

💯 Permissionless Tech + Permissionless Design

2025-08-06T05:26:58Z

In reply to nevent1q…ergr
_________________________

💯 Permissionless Tech + Permissionless Design

Thanks for reporting, we have redirected it to our GitHub for the ...

2025-07-26T21:46:48Z

In reply to nevent1q…ps5a
_________________________

Thanks for reporting, we have redirected it to our GitHub for the time being.

"Just feels like freedom" - @npub1uvx…ttjz ...

2025-07-25T20:25:25Z

"Just feels like freedom" - russfranky (npub1uvx…ttjz)

◤◢◤◢◤◢◤◢◤◢ VectorPrivacy (nprofile…5jp4) ◤◢◤◢◤◢◤◢◤◢

We'd love to hear the community's feedback so far on #VectorBeta and what all you all like, don't like, what you'd like to see improved, new features (non-stop development), and more.

Comment below and let us know!

◤◢◤◢◤◢◤◢ V E C T O R ◤◢◤◢◤◢◤◢ ...

2025-07-17T22:08:49Z

◤◢◤◢◤◢◤◢ V E C T O R ◤◢◤◢◤◢◤◢
“No–Compromise Encryption”

In an era where data breaches and privacy violations are rampant, the Vector Privacy app emerges as a vital tool to empower individuals to protect their personal information. With massive data leaks exposing billions of records—such as the 2024 breach of 2.9 billion records from National Public Data or the 16 billion credentials leak involving major platforms like Google and Facebook. Every day, citizens face unprecedented risks from identity theft, phishing, and surveillance by nefarious actors and this only grows worse with time. Vector Privacy addresses these threats with a user-centric approach to privacy and security, offering robust features to help users reclaim control over their digital lives.

Proactive Privacy Protection

Vector Privacy prioritizes user empowerment and freedom through accessible and open-source technology, aligning with Edward Snowden’s assertion that “privacy is not about something to hide. It’s about something to protect.” The app employs end-to-end encryption for data both in transit and at rest, addressing the gap highlighted in recent studies where only 10% of organizations encrypt at least 80% of their cloud-stored data. By encrypting user communications and stored information, Vector Privacy ensures that even if a breach occurs, intercepted data remains unreadable to unauthorized parties.

Nostr Protocol & Encryption

Vector utilizes Nostr Protocol and specifically the NIP-17 Standard, which enables secure and private direct messaging by using NIP-44 encryption and NIP-59 seals and gift wraps. This means that chat messages are sent as plain text tagged with the receiver’s public key and optional relay URLs, while enhancing privacy through sender verification, randomized timestamps, and kind 10050 events to specify preferred message-receiving relays, ensuring lightweight and secure communication. In layman’s terms, this means the message is encrypted from A to B, then put through an obfuscation layer to mask the metadata, and finally it goes through the last layer of the protocol which is called “gift wrapping”.

Combating Data Leaks and Breaches

Data leaks, often caused by human error or misconfigured systems like AWS S3 buckets, can expose sensitive information such as names, addresses, financial information, biometric data, and virtually everything there is to know about a person. Vector Privacy mitigates these risks by offering tools to minimize data exposure. Since sensitive information including chat logs are not stored on a centralized server, there is no single point of attack that can compromise the user’s data and privacy. The power solely relies in the hands of the user, taking secure and intelligent security measures to store their private key(s).

Thwarting Nefarious Actors

Nefarious actors exploit stolen credentials for phishing, account takeovers, and identity theft, as seen in the 2024 Snowflake attack affecting over half a billion Ticketmaster users. Vector Privacy counters these threats with multifactor authentication (MFA), which significantly reduces the risk of unauthorized access, even if passwords are compromised. Snowden’s warning that “under observation, we act less free” resonates here. By utilizing the Vector No-Compromise Encryption protocol, no third party can see or have access to a user’s files, unless their individual device is compromised. Even if a user’s device is compromised, Vector’s database is locally encrypted and completely unreadable unless unlocked, which requires the user’s pin code.

User-Friendly Security for All

Unlike complex cybersecurity solutions, Vector Privacy is designed for everyday users, not just tech experts. Its intuitive interface guides users through setting up secure communication channels and easily managing custom preferences and settings. By fostering awareness and providing actionable tools, the app aligns with Snowden’s call to “take privacy back,” empowering citizens to protect their digital identities without needing advanced technical knowledge. No longer do you have to compromise security for convenience. One of the biggest issues with high-level encryption is that your ordinary user has no understanding or technical knowledge to be able to setup a secure system and that is why Vector exists, to remove that barrier entry.

A Step Toward Digital Freedom

In a world where a single breach can expose billions of records, Vector Privacy stands out as a beacon of user empowerment and digital aegis of protection. By combining a decentralized network with peer-to-peer encryption, it directly addresses the privacy and security issues that threaten citizens daily. Vector Privacy helps ensure that this fundamental right is not just preserved but actively defended, giving users the tools to safeguard their data from leaks, breaches, and nefarious actors. For more technical details, check Vector Privacy’s official documentation at https://github.com/VectorPrivacy.

🔰Vector v0.1.7 - ᛒeta
Invite Code: B4TZJAUV
https://github.com/VectorPrivacy/Vector/releases/tag/v0.1.7

#VectorPrivacy #Vector #Nostr

“It seemed so obvious to me: Here we are faced with the ...

2025-07-14T22:42:34Z

“It seemed so obvious to me: Here we are faced with the problems of loss of privacy, creeping computerization, massive databases, more centralization—and [David] Chaum offers a completely different direction to go in, one which puts power into the hands of individuals rather than governments and corporations. The computer can be used as a tool to liberate and protect people, rather than to control them.”

—Hal Finney, Cypherpunks Mailing List, 1992

://VectorBeta.exe Installing... █████████▒░ ...

2025-07-14T17:13:43Z

://VectorBeta.exe

Installing...
█████████▒░