NAOMS · developer preview · alpha release imminent
No servers.
Everything else built in.
NAOMS runs on people's own devices: laptop, desktop, iPhone, Android. Your app gets identity, encrypted storage, sync, self-governing groups, a trust network, tokens and AI agents out of the box, with nothing to host and no account system to build.
Your data stays homeIt lives on your own devices, synced directly between them. No NAOMS server holds it.
Encrypted in layersOn disk on every device, in transit, and end to end, with secrets getting an extra layer.
Groups that govern themselvesConsensus, consent, majority, open or one steward, enforced by the group's own chain.
One identity, many devicesYour key is split across your devices and never held whole in one place.
What's inside
Building blocks you don't have to write
These are the pieces your package builds on. Each one replaces something you would otherwise design, host and secure yourself. The tools for building and shipping are in the next section.
People & identity
Identity
One identity per person, split across their own devices. No login screen, no password database.
Devices
Pair a new phone or laptop to the same identity and keep an inventory of your devices.
Contacts & friendships
A contact list built on real handshakes between people, not imported address books.
Relationship Cards
Profiles people share with the people they meet, with proof attached.
Credentials
Issue, hold and present verifiable credentials in the W3C format.
Trust graph
Typed trust between people: vouch, attest, delegate, endorse.
Groups
Hives
Groups with membership, proposals and their own chain.
Governance
Consensus, consent, majority, open or one steward, with a higher bar for changing the rules.
Group tokens
Tokens a Hive issues and governs, with a shared treasury that spends only when enough stewards co-sign.
Personal tokens
Tokens anyone can issue and use with no setup.
Treasury & payouts
A shared treasury, and value shared out among the people who contributed.
On- and off-ramps
Seven payment integrations wired into the ledger, for bringing value in and taking it out.
Sharing & permissions
Decide who can see and edit what, down to a single item, and share it with a group.
Approvals & consent
People approve what apps and others may do, and every decision is kept on an audit trail.
Your data
Signed storage
Every change is a signed, tamper-evident record, and large files stay on the owner's disk.
Vault
A separate encrypted store for secrets such as keys and passwords.
File storage
Chunked storage with indexing and direct transfer between devices.
Knowledge graph
Everything a person has becomes one graph you can search by meaning.
Import & packs
Bring data in from services like Dropbox, Google Drive and iCloud, and move it in tamper-proof packs.
Intelligence
Agent memory
A personal knowledge graph that agents remember with, encrypted by default.
Local AI models
Pick and run AI models on the person's own devices, with other providers optional.
Speech
Speech recognition and text-to-speech for talking to your app.
Social search
Find the right person or answer through the people you trust. Matchmaking is one example.
Apps
Apps already built on these blocks
The building blocks are for you. These are some of the apps the NAOMS team built with them, and they come with every install.
1 / 17
Chat
People
Hives
Graph
Photos
Files
Memories
Pages
Tasks & Kanban
Calendar
Docs
Spreadsheets
Presentations
PDF
Identity & trust
Trust that comes from real relationships
NAOMS follows the First Person Project standards (Linux Foundation Decentralized Trust, Trust Over IP, the Decentralized Identity Foundation and the OpenWallet Foundation) for proving people and relationships without a central database.
1
Relationship Card
A verified profile you share with someone you meet, like a business card that carries proof of what you did together. Hold one per context.
2
Verifiable Relationship Credential
A signed statement one person makes about their relationship with another. These are the edges of a trust graph, not a single reputation score.
3
Hive
A verifiable community: membership, proposals and governance live in the group's own chain, and the group can grant its members capabilities.
4
Trust flow
How far you can trust someone is worked out from your own relationships every time you ask, and never stored as a number anyone could read or sell.
Pseudonymous by default: wherever other people can read what you write, you sign with a per-relationship pseudonym, and the software refuses to fall back to your real identity rather than risk exposing it.
Build & ship
From first line to other people's devices
The tools for the whole developer lifecycle live inside NAOMS, so building, testing and sharing happen in the same place your users already are.
Build
Write your package against the building blocks. No backend, no database to run, no login screen to design.
Connect by asking
Apps ask for exactly the permissions they need. The user approves on any of their devices and the app receives its own limited key, never the user's own.
Package
A typed manifest declares what your package needs and provides, so it moves as one signed unit.
Test
Continuous integration is built in. Your tests run before anyone installs your package, with no outside CI service to wire up.
Distribute
Upload to your Hive and share it with friends, or list it on a hub where people look for packages. A NAOMS-run hub will add extra validation, and anyone can run a hub.
Work together
Your Hive is also your workspace: chat with other developers, let coding agents join shared channels, and pool resources for CI and agents.
Developer tools
Package manager
Discovery, install, approval gates and dependency resolution for your packages.
Marketplace & hubs
Publish through Hive-run repositories with attestation; anyone can run a hub.
CI
Continuous integration and job scheduling inside the platform.
Coding agents
Agents that follow a staged workflow for the kind of work they are doing.
How NAOMS compares
Next to Nostr, AT Protocol, Holochain, NextGraph, Reticulum and AD4M
Each of these solves part of what NAOMS solves. The table is ordered by layer, network first, and describes what a person using an app would notice. Where others are stronger, it says so.
✓ strength~ partial✗ missing? not yet verifiednot what this protocol is for
Swipe sideways to see every protocol →
| If you use it… | NAOMS | Nostr | AT Protocol | Holochain | NextGraph | Reticulum | AD4M |
|---|---|---|---|---|---|---|---|
| 1. Network | |||||||
| Offline & network — Works without a server; falls back to a relay only when it must. | |||||||
| No internet, same Wi-Fi | ✓Devices find each other on the local network (mDNS) and sync directly | ✗Needs a relay | ✗Needs your server | ~Offline writes locally; syncing to peers still needs network reachability | ~Local daemon writes locally; sync needs a broker | ✓Works over radio/serial with no IP network at all — its whole design point | ✗Built on an internet-oriented transport (Holochain over Iroh); no LAN-only mode described |
| A company or server shuts down | ✓Data and groups live on members' devices; no server holds them | ~Survives on other relays you chose, if any | ~You can move your repo to another server | ✓Held by peers, not a company server | ✗Local copy survives; sync depends on their broker, not practical to self-host today | ✓No company runs it; any node can relay for others | ✓Every node is sovereign; no cloud required, by their own docs |
| 2. Storage | |||||||
| Storage & data — Your data lives on your own devices, with no size ceiling NAOMS imposes. | |||||||
| Where the group's data actually lives | ✓On members' own devices, kept in sync by direct device-to-device messaging; no server involved | ~On whichever relays the group's members chose to publish to | ~Spread in pieces across participants' own devices | ✓Spread in pieces across participants' own devices | ~Local + broker-relayed copies | ~A local graph database (SurrealDB) plus Holochain-synced shared graphs (Neighbourhoods) | |
| Ability to store secrets (keys, credentials) | ✓A dedicated wrapped-secret vault with its own read/write/delete path, not an ad hoc file | ~NIP-49 defines a standard way to encrypt your private key with a password; where that file lives is still up to each app | ~The spec recommends keeping a backup key offline and separate from your server, but doesn't define a storage format | ~A dedicated keystore (Lair) holds keys separately from the app, per their own docs | ~A wallet holds your keys, described in their own docs | ✗No dedicated secrets-storage mechanism described in their docs | |
| Capability to store large files (up to TBs) | ~No ceiling imposed by the software itself — bounded only by your own disk; nothing auto-deletes | ✗Events are tiny by design; large media normally lives elsewhere and is only linked | ~Entries are typically small; large media is atypical | ~Entries are typically small; large media is atypical | ✓Repos designed to carry structured + media data | ✗465-byte payloads per packet; built for small messages, not bulk storage | ✗No large-file storage capability described in their docs |
| Data intake & indexing — A tamper-proof pack format, real importers, and one unified index. | |||||||
| A tamper-proof way to package and move your data (backups, sharing memories, installing features) | ✓Every kind of thing that leaves your device — a backup, a shared memory, an installable feature — travels in the same format that proves where it came from and that it wasn't altered | ✗Not supported | ✗Not supported | ✗Not supported | ✗Not supported | ✗Not supported | |
| Importing your existing data (email, calendar, cloud storage) | ✓Real, non-stub adapters for Dropbox, Google Drive, and iCloud, plus separate calendar/email/local/search adapter packages | ✗Not supported | ✗Not supported | ✗Not supported | ✗Not supported | ✗Not supported | |
| Indexing everything you have (photos, voice, text, documents) into one searchable graph | ✓Notes and photos both read/write the same graph table directly; an embedding provider feeds queries over it | ✗Not supported | ✗Not supported | ~Everything an app defines lives in one shared DHT, but there's no built-in cross-type index spanning photos, voice, and text the way a unified graph would | ~A single, unified data store is the design, per their own docs | ~Their Synergy Engine finds semantic connections across everything shared in a Perspective, though it isn't marketed specifically as a photos/voice/documents index | |
| 3. Identity | |||||||
| Identity & keys — One seed, split across your devices, with trust as a signed graph, not a score. | |||||||
| You lose your phone | ~Recoverable only if you backed up your recovery phrase; the software tracks whether you did | ✗Key is the identity; lose it, lose you | ~Identity recoverable via your PDS account, if it's still up | ✗No shipped recovery mechanism; the key-management system built for this (DeepKey/DPKI) is still unreleased, per their own repository | ?Their wallet model can hold recovery material, per their own docs, but the specific device-loss flow isn't spelled out | ✗No recovery mechanism described; losing the identity file loses the identity, by their own docs | ✗No recovery mechanism described |
| Your key is compromised | ✓Replace it deliberately; the change is recorded as history | ✗No standardised way to rotate | ✓Rotation supported | ~A revocation/replacement design (DeepKey) exists in their repositories but is not yet a shipped, stable feature | ✗Not supported | ✗Changing your key changes your address; no rotation-with-continuity is described | ✗Not supported |
| Give someone access to encrypted data later, without handing over your key | ✓Proxy re-encryption (recrypt/identikey): grant access without exposing your key | ✗Not supported | ✗Not supported | ✗Not supported | ✗Direct key sharing only, by their own design docs | ✗Not supported | ✗Not supported |
| Recovering your identity (the ceremony itself, not just the consequence of losing a phone) | ✓A real, separate verify-backup ceremony function exists in code | ✗Not supported | ~Rotation keys, kept offline and separate from your server, let you regain control if your signing key or server is compromised, per their own spec | ✗Not supported | ✗Not supported | ✗Not supported | ✗Not supported |
| Trust signals between people (like a vouch or endorsement) | ✓A typed, weighted trust edge — vouch, attest, delegate, endorse — not one reputation score | ~Follow graphs and manual web-of-trust scoring, not a protocol primitive | ✓Independent, stackable moderation/trust labelers | ✗No vouch/attest primitive; validation rules are app-defined, not person-to-person trust signals | ✗Not supported | ✗Trust is binary by design — you're in a shared graph or you're not; no vouch, attest, or score, by their own docs | |
| The trust model as a whole — VRCs, web of trust, and the trust-flow score between two people | ✓Signed Verifiable Relationship Credentials form a web-of-trust graph; how much you can trust someone is worked out from your own relationships fresh on every query, and never kept as a stored number anyone could read or sell | ~A social web of trust exists only as client-side follow-graph heuristics, not a protocol-defined score | ~Labelers provide a moderation/trust layer, but there's no person-to-person trust graph or flow score | ✗No trust graph or credential model described; validation is rule-based, not relationship-based | ✗Not supported | ✗No trust graph or credential model — membership in a shared graph is all-or-nothing, by their own docs | |
| Privacy — Layered encryption; pseudonymous identity is the default, not an option. | |||||||
| Who can read your stuff by default | ~Layered: the database is encrypted at rest on every device, plus per-topic data (chat, calls, secrets) has its own additional encryption on top | ✗Public plaintext by default | ✗Public by design | ~Transport encrypted, data signed; app decides content visibility | ✓End-to-end encrypted by default | ✓No unencrypted link is possible at all — a plaintext destination is rejected as invalid, by protocol design | ✗Everything shared to a group is visible to every member of it; no per-item privacy control, by their own docs |
| Can you reach someone without exposing who you are | ?Not verified | ✗Relays see who published to whom | ✗Public by design | ✗No anonymous-initiator feature described | ✗Not supported | ✓The initiator of a link stays anonymous to the network by design; only the destination proves identity | ✗Not supported |
| Use it without revealing who you are to the people you're not talking to | ✓The default: anywhere another person can read what you write (a shared group, a friendship), you sign with a per-relationship pseudonym, never your real identity — and the software refuses to fall back to your real identity rather than risk leaking it | ✗The same public key represents you everywhere you use it, by design — no per-contact pseudonym mechanism | ✗The same DID and handle represent you everywhere, by design — no per-contact pseudonym mechanism | ~Keys are separated per app (per DNA), not per relationship — coarser than a pseudonym-per-contact model, but not one identity everywhere either | ✗Not described; the same wallet identity is presented consistently, per their own docs | ✓The initiator of a connection stays anonymous to the network by design; only the person on the other end proves who they are | ✗One identity spans every group you're in, by design — the opposite of unlinkable-by-default, by their own docs |
| 4. Coding & building apps | |||||||
| App development & distribution — A typed package format, real install/publish code, and an honest ecosystem count. | |||||||
| Building an app/package on top of it | ✓Every package declares itself through one typed manifest contract the platform boots from | ~A set of typed, named data schemas any app can read | ✓A set of typed, named data schemas any app can read | ✓Signed app bundles with network-enforced rules — a real package format | ~Rust/TS SDK exists, still alpha | ✓A pluggable adapter model lets developers add new data/protocol types as signed, distributable units | |
| Distributing what you built to other people | ✓Real, separate install and publish code paths, not a manual file copy | ~No package format; clients just have to recognise the same event kind | ~App bundles install into a local runtime on each participant's device | ~App bundles install into a local runtime on each participant's device | ~An SDK/ORM exists for building on it, but a formal app-distribution or install mechanism isn't described yet, per their own alpha-stage docs | ✓New adapters are published as signed units that other users' software fetches and verifies automatically | |
| App ecosystem — how many distinct apps actually run on it today | ~Third-party packages already exist: Interbrain (a separate package with its own repository), Pathways in active development, and several more underway per the founder; plus 129 core packages to build on | ~140+ clients per the community-run awesome-nostr directory (GitHub, checked 2026) — a directory listing, not an audited count, and mostly alternate clients for the same protocol rather than distinct applications | ✓1,000+ third-party applications, per AT Protocol's own scale indicators (March 2026); named examples beyond Bluesky include Blacksky, Roomy, and Dazzle (TechCrunch, June 2025 / Wikipedia) | ~No single authoritative count found; a curated GitHub directory (holochain/apps) lists a handful of named hApps (Kando, Emergence, Gamez, Talking Stickies, Volla Messages, hREA) — a directory listing, not a count | ✗No named third-party apps found beyond the project's own app and SDK previews | ~A handful of named, interoperable LXMF clients (Sideband, NomadNet, MeshChat/MeshChatX, Retichat) — a small, named ecosystem, not a large directory | ~Small: roughly 80 GitHub stars on the main project; no independent app count found |
| Devices & mobile — The real engine runs natively on iOS and Android. | |||||||
| On your phone | ✓The full engine runs natively on iOS and Android, cross-compiled from the same Rust core | ~Real apps exist (Damus, Amethyst); data still lives on relays | ~The Bluesky app itself runs on iOS/Android; data lives on a server | ✗No mobile support — the runtime is a heavy standalone service, called out in their own docs as "heavy for mobile devices" | ✗No mobile support — the founder's statement; NOTE the project's own release table separately lists an Android build of its desktop app (0.1.2-alpha.1, 2025-11-08), which is not the same as a maintained mobile client — flagged, not resolved | ~Third-party apps (Sideband) run on Android; no first-party iOS client found | ✗Desktop app and command-line tool only, by their own docs — no mobile client found |
| 5. Agentic | |||||||
| Agents — Agents get a real memory layer; a proven learning loop is not yet confirmed. | |||||||
| Agentic memory (agents recalling context across sessions) | ✓A dedicated personal-knowledge-graph package for memory storage, search, consolidation, and encryption | ~Local AI inference and embeddings are built into the runtime, plus a built-in server for AI-agent integration | |||||
| Agentic workflow system (agents follow workflows and improve from past runs) | ~Agents follow a real staged procedure ladder per type of work; no code-level proof found that future runs improve from past ones | ✗No agent-workflow or learning-loop feature described; their MCP server enables AI-agent integration, not a workflow-memory system | |||||
| AI & search — Search and matching work by meaning, powered by the same knowledge graph. | |||||||
| Search your own data by meaning, not just keywords | ✓Search works by meaning, not just exact words — built into the local database | ✗No meaning-based search; NIP-50 defines only relay-side keyword search | ✗No meaning-based search described; search is keyword/hashtag based | ✗No meaning-based search, by their own design docs | ✗No meaning-based search, by their own design docs | ✓Their Synergy Engine searches across shared graphs for related meaning, not just keywords, per their own docs | |
| Finding connected information, not just a single matching file | ✓The whole web of what you know is searchable by meaning, so a search can surface something related even if it doesn't share a keyword | ✗No meaning-based search; NIP-50 defines only relay-side keyword search | ✗No meaning-based search described | ✗No meaning-based search, by their own design docs | ✗No meaning-based search, by their own design docs | ✓The same Synergy Engine spans every graph you've joined, surfacing semantically related ideas across communities | |
| Finding the right person through who you already trust, not a public search box | ✓A dedicated feature for this exists — matching people by what they want, need, or offer is one thing it's used for, not the whole point of it | ✗No trust-weighted people search described | ✗No trust-weighted people search described | ✗No trust-weighted people search described | ✗No trust-weighted people search described | ✗Search is rule-based, not trust-weighted, by their own docs | |
| Groups & governance | |||||||
| Groups & governance — A group picks how it decides, enforced by the chain itself. | |||||||
| How groups actually form | ✓A signed invitation object with its own create/verify/accept/revoke lifecycle | ~Follow lists and relay ACLs; no formal invitation object | ~Lists / starter packs; no formal invitation object | ✓Membrane proofs — a signed record proving permission to join | ~Repo membership list | ~Publish or join a shared graph (a Neighbourhood) by installing its sync method — open access, no formal invitation object, by their own docs | |
| Your group decides together (governance) | ✓Consensus, consent, majority, open, or one steward — enforced by the chain itself; rule changes need a supermajority | ✗Relay admins decide; no protocol-level vote | ✗No native governance primitive | ~Validation rules coded per app; no named decision modes | ~Membership and permissions exist; no named voting modes | ~Rule-based community patterns (“Social DNA”); no named decision modes like consensus/majority | |
| Share with someone you've never connected to | ~Invites can be revoked and expire, but reaching a stranger needs a prior connection | ~Any note or profile can be shared as a link; reaching them still depends on overlapping relays | ~Any profile or post has a public, shareable URL, since everything is public by design | ✗Membrane proofs gate entry; there's no public link that reaches a stranger without one | ✓A read-capability link is itself the key — reaches a stranger, but can't be revoked once shared | ~An announce is public by design; anyone can address a destination once they see it, without a prior handshake | ✗Joining a Neighbourhood requires installing its sync method first; no stranger-reachable link is described |
| Sync | |||||||
| Sync — Devices reconcile deterministically; a live text-editing path exists but isn't fully wired yet. | |||||||
| Two devices disagree | ✓Each device writes to its own lane, so they never collide; on the rare occasion two histories genuinely conflict, the system picks one deterministically and writes down that it happened — it never merges silently | ~Relays may simply miss or drop events | ✓Eventually catches up through background peer-to-peer syncing | ~Automatically merges both sides' changes together, by design | ✓Automatically merges both sides' changes together, by design | ~Resolved through the same Holochain-style gossip its transport is built on | |
| Collaborative editing of the same document | ~Real live co-editing exists for note text, but only the writing side is finished — nothing yet reads a merged result back on the receiving end | ✗No native document-editing model | ✗No native document-editing model | ✗No native document-editing model; conflict handling is validation-rule-based, not live text merging | ✓Built to merge everyone's edits together automatically, by design | ✓A shared graph is explicitly described as a “collaboratively edited graph” in their own docs | |
| Tokens & exchange | |||||||
| Tokens & exchange — Two levels of tokens, from zero-setup to hive-governed. | |||||||
| Tokens — what a community or person can issue and use | ✓Two levels, both real: a token anyone can create with no setup at all (mints by simple agreement between two people), and a group-governed token voted on by the group | ✗No native token-issuance layer of its own (Zaps move Bitcoin Lightning, not a Nostr-native token) | ✗No native token-issuance layer of its own | ~HoloFuel exists, but as a separate app on Holo hosting, not part of Holochain core, by their own docs | ✗No native token-issuance layer of its own | ✗No native token system of its own | |
| On-ramps / off-ramps — moving value in and out | ✓7 named, real rail integrations: Stripe, PayPal, Adyen, Bitcoin, Ethereum, Monerium, and a local-first fallback | ✓Lightning Zaps give any client a real Bitcoin on/off-ramp today, natively, by their own spec | ✗No native on/off-ramp of its own | ~HoloFuel/Holo hosting has its own currency, separate from Holochain core | ✗No native on/off-ramp of its own | ✗A payment integration exists only for an optional paid hosting tier, not a general on/off-ramp | |
| Scaling | |||||||
| SCALING — Real numbers where code states them; honest unknowns where it doesn't. | |||||||
| Members in one group | ~A default of 150 — a setting you can raise yourself, not a limit built into the protocol | ~No size limit specified in the NIPs; constrained only by what a relay allows | ~No fixed number; redundancy is configurable per app instead of a group-size cap — their own network-scale tests reached 5,000-7,500 total participants (not a per-group figure) | ~No fixed headcount cap; app-configurable redundancy (a resilience factor) governs how data spreads, not a member limit | ~No fixed cap described; repo membership is a list without a stated maximum | ~No fixed cap described for Neighbourhood membership | |
| How long until everyone in a group has your message | ~Estimated from how the gossip is built, not measured at scale: roughly 2 hops to reach 10 members, 3 for 100, 5 for 1,000, 6 for 10,000 — by design, online members would typically have it within a second or two even at 10,000, but that has not been tested at that size. The one real measurement is 4 devices converging in just over two minutes, including a deliberate 30-second wait | ?No propagation-time model published; delivery depends entirely on which relays are used | ?No fixed consistency-time bound published for firehose propagation | ~No fixed time is published; their closest citable figure is a 15-minute boundary between “recent” and “historical” gossip scheduling, not a consistency promise | ?No fixed propagation-time bound published for broker-relayed sync | ?No fixed convergence-time model; delivery is opportunistic across whatever links exist | ?Built on Holochain's gossip layer, which itself has no published propagation-time bound |
| Number of groups you can be in | ?No cap found in the code searched — mark unresolved, not "unlimited" | ~No limit specified; a user can join as many NIP-29 groups as they like | ~No limit specified; a user can create any number of lists or starter packs | ~No fixed limit; a user can install as many hApps (DNA networks) as their device can run | ~No fixed limit described; a wallet can hold membership in any number of repos | ~No fixed limit described; an agent can join any number of Neighbourhoods | |
| Devices per identity | ~No cap in the code today — an older limit of 16 was retired. Adding a device re-splits your key among all your devices; nobody has measured how that cost grows yet, but nothing in the code stops you at a small number | ✗No multi-device linking mechanism; the same private key is simply copied between devices manually | ~Multiple rotation keys can be registered and managed across devices, per their own spec | ✗Keys are per-app; no mechanism for one identity spanning multiple devices is described | ~A wallet can be used across devices, per their own docs, though no specific device-count limit is stated | ✗An identity is a keypair file; using it on multiple devices means copying that file, with no linking ceremony described | ✗One DID is used everywhere; no multi-device management is described |
| Low-bandwidth or intermittent links | ?Not verified — the transport (Iroh/QUIC) targets normal internet links; no low-bandwidth mode found in code | ✗Assumes a normal internet connection to a relay | ✗Assumes a normal internet connection to a PDS | ✗Built on a normal internet-oriented networking stack; no low-bandwidth mode described | ✗Built on WebSocket to a broker; no low-bandwidth mode described | ✓Reliable as low as 5 bits per second, by design, on radio/serial links | ✗Built on Holochain and Iroh, an internet-oriented transport; no low-bandwidth mode described |
| Network size today | ✗No public network yet to measure | ~Tens of thousands of active users | ✓Tens of millions of users | ~Small; alpha-stage apps only | ✗Alpha; a handful of contributors | ~A real but niche off-grid/ham-radio and emergency-comms community | ~Roughly 80 GitHub stars; a small, early beta community |
| Cost of running the network / who pays for servers | ~No server required for normal use; a relay is only a NAT-traversal fallback, and which relay you use is configurable, not fixed | ✗95% of relays reportedly can't cover their own running costs, by the inspiration doc's own citation | ~PDS hosting can be self-run or paid; Bluesky itself subsidises many accounts today | ~Each participant's own device does the work; no central server bill | ✗Practical use depends on brokers the project runs; self-hosting one isn't shipped yet | ✓Any participant can relay for others on hardware as cheap as a LoRa radio; no dedicated server role | ~No server required for core use; an optional paid hosting tier exists for multi-user setups |
| Where others are stronger | |||||||
| WHERE OTHERS ARE STRONGER — The honest half of the table — where another protocol is simply better today. | |||||||
| Works with no internet infrastructure at all — LoRa, packet radio, no towers, no ISP | ?No low-bandwidth/radio mode found in code; Iroh/QUIC targets normal IP networks | ✗Assumes a normal internet connection to a relay | ✗Assumes a normal internet connection to a PDS | ✗Built on a normal internet-oriented networking stack; no low-bandwidth or radio mode described | ✗Built on WebSocket to a broker; no low-bandwidth or radio mode described | ✓Reliable as low as 5 bits/second on radio/serial links — the whole design point, by their own spec | ✗Built on an internet-oriented transport; no low-bandwidth or radio mode described |
| How many people you can find and reach today, at scale | ✗No public network yet to measure | ~Tens of thousands of active users | ✓Tens of millions of users, plus public search and discovery at that scale | ~Small; alpha-stage apps only | ✗Alpha; a handful of contributors | ~Real but niche | ~A small, early beta community (roughly 80 GitHub stars) |
| A public, composable moderation ecosystem anyone can subscribe to | ~A content-filter package exists; not verified as a public, third-party-subscribable labeling layer | ~Client-side mute/report lists; no shared labeler ecosystem | ✓Independent labeler services anyone can subscribe to — a first-class, composable moderation layer, by their own spec | ✗No labeler-style composable moderation layer described; validation rules are fixed per app at install time | ✗No composable moderation layer described | ✗No composable moderation layer described | |
| How simple it is to write a new client or relay from scratch | ~A command-line tool, a browser app, and an assistant-tool server already exist as working examples over the same interface, plus a starter library to build from — the founder says a minimal new client takes about 10 minutes; in our own test, writing one against the SDK's approval flow took about 3 minutes (about 20 lines), with the approval-based connect being streamlined now | ✓NIP-01 is the whole base layer: a handful of fields, deliberately minimal, by their own spec | ~A full application framework, more involved to learn than Nostr | ~A full application framework, more involved to learn than Nostr | ~An SDK exists but is alpha and browser-only in places | ~A locked wire format, but still a real protocol to implement | ✗Building it requires Rust, Node.js, and Go toolchains together, by their own docs — a heavier setup than Nostr's |
| Public, censorship-resistant broadcast to anyone listening | ✗No public/anonymous entry point found — invitation or device-pairing only | ✓Anyone can publish a public event to any relay; no signup, no gatekeeper, by design | ~Public by design, but identity/hosting can be deplatformed at the PDS/App View layer | ✗Membrane proofs gate entry to a DNA network; there's no public, ungated broadcast layer | ✗End-to-end encrypted by default; not designed for public broadcast | ~Announces are public, but the ecosystem is niche, not a mass broadcast medium | ✗Sharing requires joining a Neighbourhood first; no public broadcast layer described |
| A payment any client can trigger in one action, with no per-operator setup | ~7 real rails exist, but namespaced per-hive-treasury by an operator, not a bare universal action | ✓Lightning Zaps are a native protocol feature any client can use immediately, by their own spec | ✗No native payment layer of its own | ✗HoloFuel exists only as a separate app on Holo hosting, not a bare universal action | ✗No native payment layer of its own | ✗No native payment layer of its own | |
| A mature, battle-tested app framework with network-enforced validation rules | ✗An alpha release is imminent as of September 2026, by the founder's own statement; not yet reflected in the repository's version tags | ✓A decade of development; every peer enforces the same DNA-defined validation rules on every entry, by their own spec | ✗Alpha stage since inception, per their own release notes; not yet describable as battle-tested | ~Late beta (a named stable version as of March 2025); built on Holochain's validation model beneath it | |||
| Reaching a total stranger with read access, using nothing but a link | ~Invites can be revoked and expire, but reaching someone needs a prior connection first | ~A note or profile link can be opened by anyone with a compatible client, though it's a public broadcast, not a scoped read-grant | ~Any public post or profile has a shareable URL anyone can open, since everything is public by design | ✗No shareable read-capability link; a membrane proof is required to join first | ✓A read-capability link IS the key — works offline, no enrollment, reaches a stranger, by their own spec | ~An announce is public, but establishing a private link still needs the destination to respond | ✗Joining a Neighbourhood requires installing its sync method first; no shareable read-only link is described |
| Encrypted by default, everywhere, out of the box | ~Encrypted in several independent layers — disk, per-data-domain, calls, chat — but not one single blanket guarantee the way NextGraph states theirs is | ✗Public plaintext by default | ✗Public by design | ~Transport encrypted, data signed; content visibility is the app's choice | ✓End-to-end encrypted by default across the whole system, by their own spec | ✓No unencrypted link is even possible, by protocol design | ✗Everything in a shared graph is visible to every member; no per-item encryption control, by their own docs |
| Built on open, shared standards rather than a private format | ✓Feeds a standard linked-data format on every single change (not just sometimes), plus real, standards-based verifiable credentials with a matching cryptographic proof format | ~Uses its own DNA/WASM format rather than an existing open data standard, though the code and spec are fully open-source | ✓A standard linked-data format with a standard query language is the primary way data is stored, by their own spec | ✓Data is stored as standard linked-data triples, with shared community rules written in a real W3C-adjacent constraint language | |||
| Maturity | |||||||
| Maturity — An alpha release is imminent, by the founder's own statement. | |||||||
| How long this has existed and how production-ready it is | ?The founder states an alpha release is imminent (as of September 2026); the repository's own version tags do not yet show a release past v0.1.x, so this is stated as intent, not something the code itself confirms | ~~6 years old, real production use | ✓About 9 years old, still before its 1.0 release | ~About 9 years old, still before its 1.0 release | ✗Alpha since inception | ✓~10 years old, real production deployments in off-grid/emergency comms | ~A named stable release as of March 2025; still described as beta |
Partners
Built with others, not alone
Parts of NAOMS come from partners who did that piece better. That door stays open.
Pathways
In active designVersioned, forkable AI orchestration recipes with provenance anchored on-chain, by David Thomson.
Aqua Protocol by inblockio: the tamper-proof format NAOMS uses for backups, shared memories and installable features.
llama-launcher
In use since June 2026By Lumina Nao: parks idle model sessions on disk so one GPU host serves more agent sessions at once.
recrypt by identikey: re-encrypts data for a new recipient without ever decrypting it in the middle.
greencheck
IntegratedVerification by people, not a company: a random panel of hive members checks a claim such as an email or phone number and co-signs the result.
First Person Project
AdoptedThe open standards NAOMS builds identity on: Relationship Cards, verifiable relationship credentials and personhood.
Trust Tasks
Being worked on nowFrom Trust over IP: NAOMS is expressing its APIs as standard trust tasks, so other trust systems can call them.
Build a better block
Every building block in NAOMS can be replaced by a better implementation. Agent memory is one the team points to first. If you think you can do a piece better, that is the invitation.
Looking for an owner
Packages waiting for someone to run with them
Proof-of-concept work with a design or a partial engine already in place.
Flow Funding
Open · research doneA trust-mediated way of moving capital from abundance to need, based on an existing practice. The research is written; the implementation is yours to start.
Flow Inbox
Open · engine in progressFocused views on top of NAOMS's goal-driven Attention Inbox: important messages, business contacts, and family and friends updates.
How developers earn
A membership, not an app store
Software is cheap to copy and hard to protect, so NAOMS doesn't make you compete on it. People pay one NAOMS membership. Their membership flows to the packages they actually use. Payouts taper off over time and the work becomes part of the commons, until someone makes a real improvement and gets paid for that.
The membership split is design intent, not built yet
✓
Payment rails
Seven payment integrations are already wired into the ledger.
✓
Contributor payouts in a Hive
A working payout game already shares credit among contributors inside a Hive.
~
Storefront pricing
A price list and checkout screen exist in the wallet, waiting for a payment rail to be connected.