# Nostr Dev (Freedom Tech)

> Nostr Dev is an end-to-end development studio specialising in building products on the Nostr protocol and other freedom-focused technologies. From product design to development, maintenance, and support, we bring your vision to life.

## About

Nostr Dev (also branded as Freedom Tech) is a professional development studio that builds on the Nostr protocol and other freedom-focused technologies.

We're an end-to-end development studio aiming to develop your idea into reality, and developing it with Nostr, along with other freedom-focused technologies, to secure its place in the future of the internet.

**Website:** https://nostrdev.com

### What is Nostr?

Nostr stands for Notes and Other Stuff Transmitted by Relays. It is an open, permission-less protocol that aims to provide censorship-resistance and interoperability. It can be used to create social networks or just about any other type of app (the "other stuff" part of the acronym). It is not a single website or app, but the glue that holds together many apps (clients).

The big deal is that anyone can build on top of Nostr and access the same user base. Prior to this, companies relied on APIs which require permission to use. This means apps live in silos and can dictate everything a user does. It also means they can de-platform anyone at any time for any reason.

### Mission

To bring your product vision to life using Nostr tools, freedom-focused technologies, and best practices. From initial design to strategic consulting, development, maintenance, and support, we are dedicated to ensuring your success every step of the way.

### Vision

To deliver as many successful quality projects running on Nostr as possible, along with other freedom-focused technologies, expanding its ecosystem of products and users, resulting in an ever expanding cycle of success for all stakeholders.

## Services

We offer three core services:

### Product Design

We offer end-to-end product design services, turning your concepts into market-ready products.

### Client Development

We're specialised in developing robust and user-friendly Nostr clients, focusing on performance, security, and user experience.

### Relay Services

From relay hosting through to DVM delivery and Blossom server management, we can provide infrastructure that scales with your needs.

## Our Work

Client projects and testimonials. It's always better to show, not tell.

### Angor

- **Website:** https://angor.io
- **Description:** Decentralised investment platform.
- **Client:** Dan Gershony

> "NostrDev is a reliable team that truly aligns with the values of the Bitcoin and Nostr ethos such as decentralization, privacy, self hosting and censorship resistance. A pro team that deliver solid software. They are an excellent and suitable partner for anyone that wants to build on Nostr."
> — Dan Gershony

### DEG Mods

- **Website:** https://degmods.com
- **Description:** Censorship-resistant modding platform.
- **Client:** Freakoverse, DEG Mods Creator

> "Working with Nostr Dev throughout the development of DEG Mods has been a delight. They've taken what I've made so far, in terms of design and code, and brought it to life by converting it into a React project and implementing Nostr systems, resulting in a censorship-resistant product. Continuing to work with them is the correct choice here."
> — Freakoverse, DEG Mods Creator

### Satshoot

- **Website:** https://satshoot.com
- **Description:** Nostr-based freelancing platform.
- **Client:** Five, Founder

> "I am striving to make SatShoot a usable product on nostr. One man shows can only do so much. I turned to Nostr Dev because I knew they didn't just have expertise but live and breathe freedom-tech. They quickly set me up with a developer and we have been shipping much faster ever since. Grateful for this service."
> — Five, Founder

## Products

First-party products developed by Nostr Dev.

### SIGit

- **Website:** https://sigit.io
- **Description:** An open-source and self-hostable solution for secure and private document signing and verification.

## Team

Know the talent that'll be responsible in bringing your project to life.

- **b** — Advisor
- **otto** — CTO
- **AJ** — Business Development
- **enes** — Full-Stack Developer
- **daniyal** — Full-Stack Developer
- **stixx** — Full-Stack Developer
- **freakoverse** — Technical Designer
- **sync** — Full-Stack Developer
- **humble_goat** — Nostr Tester
- **eugene** — Technical Lead

## Technology Stack

Some of the tools we may use to achieve your goals:

JavaScript, TypeScript, React, Node.js, Figma, NDK (Nostr Dev Kit), Lightning Dev Kit (LDK), Bootstrap, Gatsby, SCSS, nostr-tools.

## Blog

### How Nostr Will Improve Your Product

**Author:** Freakoverse
**Tags:** nostr, business, development

You have a digital online product—whether it's a website or a mobile application—and this typically involves several challenges. You need to develop and deploy a server, integrate it with your front end, and ensure it scales as your user base grows. Maintenance, security, and privacy are key concerns to address. You must also manage user acquisition and registration, moderation, and the potential for being a centralised point of failure that can be shut down or censored.

These issues, alongside payment handling, regional accessibility, and other factors, can be overwhelming when launching or managing a product. But what if there was a way to address many of these problems or at least alleviate some of them, while also offering additional benefits?

Enter Nostr, which stands for Notes and Other Stuff Transmitted by Relays. Nostr is a new, free, and open-source protocol that represents a promising future for the internet. It could be the solution you're looking for.

#### What is Nostr exactly?

Enter Nostr, which stands for Notes and Other Stuff Transmitted by Relays. Nostr is a new, free, and open-source protocol that facilitate the transmission of data across a network of relays (servers). Unlike traditional web applications that rely on centralised servers, Nostr functions through a decentralised network of relays, enabling users to publish and receive messages without relying on a single point of control. This open-source protocol allows developers to create applications that are resilient to censorship, more secure, and focused on user privacy.

To simplify, imagine that you have a digital box within Nostr that's locked with a unique key. This box contains all your posts, profile information, messages, and more. Multiple servers have copies of this box, allowing anyone to view its contents through a glass window. The key is unique to you, so only you can add new information or make changes. When you update your box, all the other copies of it also get updated with this new information.

#### How would Nostr help my product?

Nostr can significantly benefit many types of products, although the level of impact may vary. The main advantages include:

- **Eliminating Single Points of Failure**: Nostr decentralises data storage, removing the risk associated with having a single point of failure.
- **Enhanced User Ownership and Privacy**: Users retain control over their data with strong encryption, reducing privacy risks.
- **Reduced Infrastructure Costs**: You might not need to manage your own servers, cutting down on costs and administrative overhead.
- **Decreased Development Costs**: As an open protocol, Nostr benefits from contributions from developers worldwide, leading to a faster development timeline and lower costs.
- **Ongoing Innovation**: With a growing number of Nostr-based products, you can continuously explore new features and improvements.
- **Seamless User Access**: Nostr allows you to tap into a network of existing users without requiring them to register for your product. Users can log in using their existing Nostr credentials, simplifying the onboarding process and enhancing user experience. This can lead to higher user engagement and retention, as the barrier to entry is significantly lowered.

#### What are the drawbacks of Nostr?

While Nostr offers many benefits, there are some challenges to consider:

- **Irreversible Posts**: Once information is posted on Nostr, you may not be able to delete it. This permanence can be a concern for users who need the ability to remove or edit their content.
- **Loss of Access**: If you lose your private key or seed words, you lose access to your account. Unlike traditional systems, there's no recovery option or support to restore access. The responsibility for maintaining these credentials lies entirely with you.
- **Compromised Security**: If your private key or seed words are leaked, your account is at risk. There's no way to simply change a password or email address to fix this. Instead, you'll need to generate new keys and notify your followers of the change.
- **Limited Adoption of New Features**: If you develop a new feature or piece of code for Nostr, it may not gain immediate traction or widespread use. This means your innovation might not benefit from the decentralised and censorship-resistant nature of Nostr until it is more widely adopted.

Overall, Nostr provides a compelling alternative to traditional digital product infrastructure, but it's important to weigh these benefits and drawbacks to determine if it's the right fit for your needs.

---

### Hardening NPM Repos

**Author:** B
**Tags:** security, development, npm

Modern software development relies heavily on open-source dependencies, and JavaScript projects—especially those using npm—are among the most dependency-dense ecosystems in existence. With supply-chain attacks, typo-squatting, malicious maintainers, and vulnerable packages becoming increasingly common, it's essential to harden npm-based repositories to protect both developers and end users.

This guide outlines practical, immediately actionable steps to secure your Node.js project.

#### Why Hardening Matters

An npm install may pull in thousands of transitive dependencies. Any one of them can introduce:

- **Vulnerabilities (CVEs)**: That expose your application to security risks
- **Malicious Scripts**: That run automatically during installation
- **Dependency Hijacking Attacks**: Compromised packages can steal data or inject malware
- **Unexpected Breaking Changes**: Version updates can break your application unexpectedly

Hardening your repository reduces your attack surface and makes your builds deterministic, reproducible, and safer.

#### Run npm audit in Your CI Pipeline

Security checks should never rely on someone remembering to run them manually. Integrate `npm audit` directly in the CI pipeline.

Example snippet:

```yaml
name: Security Audit
on: [push, pull_request]

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v4
        with:
          node-version: 24
      - run: npm ci
      - run: npm audit --audit-level=low
```

This prevents merging code that introduces known vulnerabilities.

#### Use npm ci for Reproducible Installs

`npm ci` installs dependencies exactly as specified in package-lock.json.

- **No Drifting Versions**: Dependencies install exactly as specified
- **Faster Installations**: Optimised for CI/CD environments
- **Deterministic Builds**: Ensures production builds match local builds

In CI/CD environments, always use:

```bash
npm ci
```

Never use `npm install` during automated builds.

#### Add no-scripts to .npmrc

One of the most common attack vectors is malicious lifecycle scripts (`postinstall`, `preinstall`, etc.). A simple defence is disabling script execution by default.

In your `.npmrc`:

```
ignore-scripts=true
```

Or enforce the stronger setting:

```
fund=false
audit=true
ignore-scripts=true
```

When scripts are genuinely needed for development (e.g., building native modules), developers can run:

```bash
npm install --ignore-scripts=false
```

This prevents arbitrary code execution during automated installs or CI environments.

#### Pin All Dependencies

Never use ranges like:

- **^1.2.3**: Allows minor and patch updates
- **~4.5.6**: Allows patch updates only
- ***: Allows any version (extremely dangerous)

Ranges allow unintended upgrades, which can introduce malicious or broken versions.

Instead, pin exact versions in package.json:

```json
"dependencies": {
  "express": "4.18.3"
}
```

Then commit your package-lock.json file to the repo. To enforce this across the whole repo, just add the following to your `.npmrc`:

```
save-exact=true
```

#### Use Conventional Commits

Security and auditing are difficult when commit histories are messy. By enforcing the Conventional Commits specification, you ensure that every change to the codebase follows a structured format (e.g., fix:, feat:, chore:). This makes the project history machine-readable and transparent, allowing for automated changelog generation and easier identification of when a vulnerability was introduced or patched.

Add this to your `package.json`:

```json
{
  "scripts": {
    "preinstall": "git config core.hooksPath .git-hooks"
  }
}
```

Add this to `.git-hooks/commit-msg`:

```bash
#!/bin/sh
commit_message=$(cat "$1")

if echo "$commit_message" | grep -Eq "^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test)(\([a-z0-9 \-]+\))?!?: .+$"; then
  echo "✔ Commit message meets Conventional Commit standards"
  exit 0
fi

echo "❌ Commit message does not meet the Conventional Commit standard!"
echo "An example of a valid message is:"
echo "  feat(login): add the 'remember me' button"
echo "More details at: https://www.conventionalcommits.org/en/v1.0.0/#summary"
exit 1
```

#### Release with Semantic Versioning

For a hardened repository, the release process must be deterministic and trustworthy. Semantic Versioning (SemVer) ensures that security patches (patch bumps) are clearly distinguished from breaking changes (major bumps). This allows consumers of your package—or your own internal services—to accept security updates automatically without fear of crashing production.

Automate this process to remove human error. Tools like standard-version or semantic-release can automatically determine the next version number based on your Conventional Commits.

#### Run a Licence Checker

Supply-chain security isn't just about malware; it is also about legal compliance. Bringing in a dependency with an incompatible licence (like AGPL in a proprietary commercial application) can be a "legal vulnerability" that exposes your intellectual property or triggers lawsuits.

Since npm install brings in transitive dependencies you may never see, you must automate the auditing of these licences. Use a tool like license-checker to fail the build if a forbidden licence is detected.

Add this as a script in your package.json:

```json
"scripts": {
  "audit:licenses": "license-checker --production --onlyAllow='MIT;ISC;Apache-2.0;BSD-3-Clause' --summary"
}
```

#### Further Reading

Some additional tips and suggestions are available at https://snyk.io/articles/npm-security-best-practices-shai-hulud-attack.

#### Final Thoughts

Hardening an npm repository is not difficult — it just requires discipline. Implementing checks such as pinned dependencies, disabled scripts, reproducible installs, and automated auditing dramatically reduces supply-chain risk.

By codifying these steps into CI pipelines and development workflows, your project becomes safer, more predictable, and far more resilient to modern threats.

---

### Encrypted Group Chat on Nostr: Marmot, Concord, and Cordn Compared

**Author:** SN
**Tags:** nostr, encryption, protocols, messaging

Pairwise encryption is a solved problem. Group chat is not. The moment a third person joins the room, questions appear that two-key crypto never had to answer. Who holds the group key? What happens to old messages when someone leaves? Who decides who belongs, and who verifies that decision? On a centralised platform, a server settles all of this by fiat. On nostr there is no server to settle anything, which is exactly why the interesting work is happening there.

Three protocols are currently answering these questions in public: Marmot, Concord, and Cordn. All three are end-to-end encrypted group messaging built on nostr. Past that shared opening, they diverge sharply: on the crypto layer, on the trust model, and on the shape of the group they assume you actually want. Star counts below are a snapshot at the time of writing.

#### The short version

- **Crypto layer** - Marmot: MLS (RFC 9420). Concord: shared key + NIP-59 giftwrap. Cordn: MLS (RFC 9420) via coordinator.
- **Forward secrecy** - Marmot: yes. Concord: no. Cordn: yes, if clients use MLS correctly.
- **Post-compromise security** - Marmot: yes. Concord: no. Cordn: yes.
- **Coordinator needed** - Marmot: no. Concord: no. Cordn: yes, one per group.
- **Trust model** - Marmot: no privileged server, relay-redundant. Concord: signed roster + key possession. Cordn: coordinator per group (blind to content, identities, IPs).
- **Target size** - Marmot: small, high-stakes, scaling up. Concord: large, public. Cordn: same as MLS (coordinator-assisted).
- **Group features** - Marmot: basic MLS groups. Concord: full Discord-like set. Cordn: MLS groups via coordinator.
- **Spec maturity** - Marmot: evolving (v2 in progress, breaking changes). Concord: evolving, 8 CORD docs. Cordn: 3 spec docs + reference code.
- **Implementations** - Marmot: MDK flagship (Rust, actively released); others catching up. Concord: 5 nostr clients (Armada, Vector, Accordion, Amethyst, Grimoire). Cordn: CLI, TS + Rust + KMP + browser + Android coordinators, cordn.net web + Android apps, cahmls.
- **Membership change cost** - Marmot: O(log n). Concord: O(n), key rotation to all members. Cordn: O(log n).
- **Post-removal secrecy** - Marmot: automatic, next epoch. Concord: manual rekey (CORD-06). Cordn: automatic, next epoch.

#### Marmot: MLS discipline for small, serious groups

Marmot (138 stars, MIT) is the closest thing nostr has to Signal-grade group crypto. It uses MLS, the IETF's Messaging Layer Security standard (RFC 9420), as its continuous group key agreement layer. Nostr keys provide identity, nostr event-shaped app payloads ride inside MLS envelopes, and nostr relays carry the bytes. Those three invariants (identity, key agreement, transport) are the protocol's spine, The spec is well structured and the older MIP-era documents are explicitly deprecated (mip-coverage: https://github.com/marmot-protocol/marmot/blob/master/mip-coverage.md), A breaking v2 is in progress.

What MLS buys you is the good stuff. Forward secrecy, so past messages stay safe after a key compromise. Post-compromise security, so future messages heal after one. The price is lockstep: MLS advances through ordered commits, per-device key packages, and O(log n) cost per membership change. Every join, leave, or device addition ratchets the whole tree forward.

The guarantee is worth stating precisely: as long as every member receives every commit event, the group stays in consensus on MLS state. How the bytes travel is deliberately secondary, because no server is privileged anywhere in the design. Nostr relays are the first transport binding rather than the protocol's identity, and the MDK has already spiked a FIPS transport for the future.

The spec culture is unusually disciplined. It is organised by protocol surface: foundation, protocol-core, app-components, transports, and features, each with its own README, plus canonical-encoding, principles, and implementation-model documents, and a migration map from the deprecated MIPs. Normative language is used correctly. Transports MUST support redundant delivery, so no group ever depends on a single relay. The protocol SHOULD avoid new metadata leaks, alongside the honest admission that perfect metadata privacy is impossible in decentralised messaging.

The centre of gravity is the MDK, the Marmot Development Kit: a Rust workspace holding the OpenMLS-backed CGKA engine (https://openmls.tech), SQLCipher-encrypted account and device storage (https://www.zetetic.net/sqlcipher/), nostr transport adapters, and UniFFI bindings (MarmotKit) that app runtimes consume, plus a C ABI, a CLI, daemon and TUI, and Tamarin formal models (https://tamarin-prover.com) that map the proofs back to tests. It releases on separate tracks (workspace, MarmotKit, Marmot C, and the wn-agent connector) and is the flagship library for the upcoming Marmot v2. The v2 work in progress is the kind that matters in production: two-phase group hydration, so cold-start readiness stops scaling with how many groups you have stored, and background hydration that queues sends in arrival order while catch-up completes. Around the MDK sit marmots-web-chat as the reference web client, plus implementations in TypeScript (marmot-ts), C# (marmot-cs), Dart and Flutter (marmot_dart), Rust (cove), and on the CLI (burrow), though at the time of writing several of these have not yet caught up to the current spec. The dr.marmot diagnostic tool rounds out the set.

On scale, groups of 64 members are working well today. The current ceiling is a set of arbitrary data limits rather than anything fundamental in MLS, and lifting them is expected to open larger groups, though sizes beyond that have not been tested. Scaling without a privileged server is the harder road: a coordinator can traverse the group graph in one place, while Marmot has to converge the same state through redundant relay fan-out. It is the road the project has chosen, and reliability improvements are landing in near-weekly MDK releases.

**Target:** small, high-stakes groups where forward secrecy matters and every membership change is a ratchet, not a chore.

**The trade:** the strongest crypto guarantees of the three, the most mature spec, and a flagship Rust implementation, in exchange for the decentralised road, where both convergence and metadata privacy are earned rather than granted by an operator.

#### Concord: Discord-style communities without the platform

Concord (58 stars, evolving specification) targets the opposite end of the room: large, public, high-churn communities. Channels, roles, owners, admins, kicks, bans, invites, voice and video, disappearing messages. The full platform feature set, but decentralised, end-to-end encrypted, and with no company in the middle.

Concretely: not MLS. The base primitive, CORD-01 "private streams" (spec: https://github.com/concord-protocol/concord/blob/main/01.md), is a shared symmetric key distributed through NIP-59 giftwrap. Anyone holding the key can read the stream; relays see only ciphertext addressed to rotating labels. Membership is key possession. There is no ratcheting, no forward secrecy, and no post-compromise security. Removing someone means rotating the key, which is what CORD-06 rekeys and refoundings are for (https://github.com/concord-protocol/concord/blob/main/06.md).

The trust model is the clever part. Concord splits the three jobs a central server normally monopolises:

- **Storage and delivery** go to dumb relays, which only ever see encrypted blobs.
- **"Who is a member?"** is answered by key possession. If you can decrypt the room, you are in it. There is no list to enforce.
- **"Who is in charge?"** is answered by a signed roster rooted in the owner's identity. Authority is a signature, not a switch, and every client re-verifies the chain independently.

The community_id is self-certifying and the control_root is a staff-held write key. A forged ban fails verification because it does not trace back to the owner.

The spec itself is a series of eight CORD documents, NIP-style, each a small self-contained piece:

- **CORD-01 Private Streams** - Base shared-key stream over NIP-59 giftwrap.
- **CORD-02 Communities** - Membership and authority model, epochs.
- **CORD-03 Channels** - Public and private rooms.
- **CORD-04 Roles** - Granular, ranked, owner-rooted permissions.
- **CORD-05 Invites** - Shareable links, revocable, direct giftwrap invites.
- **CORD-06 Rekeys & Refoundings** - Post-removal secrecy via key rotation.
- **CORD-07 Audio/Video** - Blind token broker, SFU forwarding only ciphertext.
- **CORD-08 Disappearing Messages** - NIP-40 expiry, staff-set timer.

The README positions Concord against its neighbours precisely: NIP-17 private DMs cannot do communities and are DoS-vulnerable; NIP-29 relay-based groups require self-hosting an entire server and are not end-to-end encrypted; Marmot's MLS lockstep is heavy for large casual rooms; Iris Chat (https://irischat.org) is pairwise ratchets, not communities.

**Target:** the Discord replacement. Large, public, asynchronous communities with real moderation needs.

**The trade:** the best community-management feature set of the three, no coordinator required, and asynchronous operation with no ordering requirement, in exchange for the crypto guarantees spelled out above: a single key compromise exposes the room until a rekey, and every removal costs O(n) key rotation to all remaining members. The spec is young but the ecosystem is growing: established nostr clients including Armada, Vector, Accordion, Amethyst (https://github.com/vitorpamplona/amethyst), and Grimoire (https://github.com/purrgrammer/grimoire) already support Concord communities.

#### Cordn: MLS with a coordinator per group

Cordn (10 stars, active development) takes MLS in a third direction: the same crypto family as Marmot, a different delivery architecture. Built on the ts-mls TypeScript implementation and exposed as a ContextVM server (https://contextvm.org), it is a "minimal MLS delivery service coordinator" implementing the Delivery Service role from RFC 9420. Where Marmot refuses to privilege any server, Cordn embraces the coordinator role that MLS delivery assumes.

MLS assumes someone operates a delivery service: a place that stores per-device KeyPackages, routes Welcome messages to new members, and delivers group commits in order. Cordn's answer is to be that service, openly. Clients publish KeyPackages to it; group messages flow through with per-group monotonic cursors; clients follow a fetch-then-subscribe pattern for bounded catch-up and then live delivery, with multi-group variants for clients tracking many rooms. Clients communicate with the coordinator over ContextVM, while the coordinator itself speaks nostr, using CEP-22 oversized transfer and CEP-41 open streams over the ContextVM and Primal relays by default.

Membership is settled exactly as in Marmot: the MLS member list is the authority. You are in the group if you are in the tree, with the same forward secrecy and post-compromise security that implies.

The operational details are sensible. Token-bucket rate limiting is keyed by client pubkey, with storage quotas per identity, both tunable through environment variables. Deployment is a Docker image on GHCR (https://github.com/Cordn-msg/cordn/pkgs/container/cordn) with SQLite or in-memory storage, and there is an npm-published CLI, @cordn/cli (https://www.npmjs.com/package/@cordn/cli). The implementation surface is broader than it looks: coordinators exist in TypeScript, Rust, Kotlin Multiplatform (KMP), and a browser-based variant that runs from a single HTML file. There is an Android coordinator app, the cordn.net (https://cordn.net) web app and its Android counterpart, and cahmls, a browser-based coordinator plus alternative client. The spec is thin so far: three documents covering the coordinator and identity model, a group metadata extension, and a nostr-shaped app-message envelope.

**Target:** MLS-grade group messaging for teams happy to run (or share) a small coordinator per group.

**The benefit:** easier scaling and better metadata privacy. The coordinator handles delivery in one place, and nothing it carries ever appears as a protocol-specific event on a public relay. Relays see only generic encrypted ContextVM traffic, so unlike Marmot or Concord, there is nothing on a relay to fingerprint, cluster, or archive.


**The trade:** a coordinator can traverse the group graph in one place, so Cordn scales more easily than decentralised consensus, and whoever runs it can tighten public metadata handling. To be clear about what this is not: it is not a centralised platform. Coordinators are ordinary software, trivially self-hostable, small enough to run in a browser tab or on a phone, tolerant of intermittent availability, and no more than one per group, so different groups naturally run on different machines run by different people. The honest cost is per-group dependency: the group's delivery depends on its coordinator being reachable, even though the coordinator cannot read content. 
#### What the coordinator can and cannot see

Being precise about the coordinator's vantage point matters, because "it runs a service" sounds scarier than it is. The coordinator is a delivery and signalling service, not a state authority. Everything that matters cryptographically (epoch keys, ratchets, the MLS member tree, KeyPackage secrets) lives client-side on each member's device.

What it can see: client pubkeys (used for rate limiting and key package storage quotas); that a group is active (timing and volume patterns for the traffic it handles); encrypted message blobs, Welcome messages, and join requests flowing through (all ciphertext, none of it readable); per-group cursors and message ordering; any backlog of undelivered ciphertext queued on it at a given moment.

What it cannot see: message content (MLS end-to-end encryption protects it); client IPs (clients never connect directly; they reach the coordinator through relays via ContextVM); group membership secrets or historical messages already delivered to members; stable participant identities for routine traffic (ordinary message posting can use ephemeral transport keys, so the coordinator does not even learn who is talking for normal sends).

If a coordinator is compromised, subpoenaed, or turns hostile, what is at risk is only the backlog of undelivered ciphertext and the activity it can observe during the window it is your active coordinator. The group itself, its membership, its history on members' devices, and the ability to continue all survive. Migration to a different coordinator is designed in: per-group cursors preserve ordering across a move, so a group can jump from one coordinator to another because groups do not care which coordinator they live in.

The metadata story is where Cordn genuinely differs from the other two. Marmot and Concord both publish protocol-specific events to public relays: Marmot's kinds 443 and 445, Concord's 3300 range. An external observer can fingerprint the protocol, cluster traffic by group identifier, and read timing patterns. Cordn publishes none of its messaging artifacts to relays. KeyPackages, Welcomes, group messages, and join requests all live on the coordinator, reached through ContextVM (https://contextvm.org), a general-purpose protocol for reaching services through relays without direct public exposure. The relay sees only generic, encrypted, ephemeral ContextVM traffic that blends with every other ContextVM usage. The party that can interpret the traffic (the coordinator) never sees an IP, because clients connect through relays. The party that can see an IP (the relay) cannot interpret the traffic. That severs the convergence of IP and protocol visibility that every relay-based scheme inherits. For a deeper analysis of these privacy models across all the nostr messaging protocols, see this long-form note: https://jumble.social/notes/naddr1qvzqqqr4gupzqs9eep0ll6hurjkl3sc2fewgses07mjfwxsdcu3at2m8fd0xrdz3qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgnwaehxw309ahkvenrdpskjm3wwp6kytcqx9c8y6tkv96x2ttrdakk6atwd93kzarfdah8xtt0wejhyttsw43xc6tr945kuenjv9ehgun4vd682un954epwj

#### Five takeaways

1. **Marmot and Cordn use MLS. Concord does not.** Concord's shared-key model is simpler but cryptographically weaker, and for a large public community trading crypto guarantees for scalability and simplicity can be a rational trade.
2. **Marmot and Cordn are separate stacks, not layers of one system.** Marmot cannot run over Cordn: both use MLS, but Marmot runs over decentralised relays while Cordn runs each group through its own small, self-hostable coordinator. Cordn trades that coordinator for scalability and better public metadata behaviour; Marmot keeps full decentralisation and is working out metadata privacy the harder way.
3. **Each targets a different room.** Concord aims at large public communities, the Discord replacement. Marmot aims at small high-stakes groups, the Signal replacement, with headroom as data limits lift. Cordn is for groups happy to give the coordinator job to one small piece of software.
4. **If forward secrecy and post-compromise security are requirements**, Marmot and Cordn are your options. Concord explicitly trades those guarantees for scale.
5. **Membership authority splits two ways.** Marmot and Cordn settle it at the crypto layer: you are in the group if you are in the MLS tree. Concord's signed roster, owner-rooted and client-verified, is its own well-designed answer to community moderation without MLS.

#### Which one should you pick

Start with the group, not the protocol. A small team with secrets to keep wants ratchets, and Marmot is the most mature way to get them on nostr today. A public community of thousands with mods, roles, and a kick ban workflow wants Concord, accepting that a compromised room key stays compromised until a rekey. And if you would rather run a coordinator than converge state across relays, Cordn is the MLS stack built around exactly that.

This is exactly the kind of question we like being handed before a line of code gets written. Protocol choices are cheaper to make correctly on day one, and we build nostr clients and relay infrastructure for a living. If you are weighing any of these for a product, talk to us: sales@nostrdev.com.

## Contact

- **Email:** sales@nostrdev.com
- **Nostr npub:** npub1yay8e9sqk94jfgdlkpgeelj2t5ddsj2eu0xwt4kh4xw5ses2rauqnstrdv
- **Nostr nprofile:** nprofile1qqszwjrujcqtz6ey5xlmq5vule996xkcf9v78n896mt6n82gvc9p77qppemhxue69uhkummn9ekx7mp0qyg8wumn8ghj7mn0wd68ytnddakj7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctc8pm2sw
- **Website:** https://nostrdev.com
- **Nostr Contact Page:** https://nostrdev.com/nostr