Set up your ID and start your node
One command installs everything — no admin rights needed:
curl -fsSL https://spacedatanetwork.org/install.sh | bashirm https://spacedatanetwork.org/install.ps1 | iexspacedatanetwork init # creates your secure ID
spacedatanetwork start # runs in the background
spacedatanetwork status # confirm it is upThat's it — you're on the network. The init step created your secure ID automatically. There's no account to register and no password to remember. Your ID acts like a tamper-proof signature: everything you share carries it, so anyone can confirm it really came from you and wasn't changed along the way.
The one thing to protect is your recovery phrase — a short list of words the app keeps encrypted on your machine. It can rebuild your ID on a new computer, and anyone who has it can act as you. Back it up somewhere safe, like you would a passport.
Next, tell the network who you are. A short wizard fills in your public listing — organization name, contact info, nothing sensitive:
# fill in your public listing
spacedatanetwork identity wizard
# share it as a contact card or QR code
spacedatanetwork identity export --format text
spacedatanetwork identity export --format qrcodeWhy bother? What running a node gets you:
- People can find you. Your listing shows up when anyone on the network searches for organizations or data like yours — no marketing, no sales calls, no integration contracts.
- You get the data, too. A running node can tune into every open feed on the network — satellite positions, collision warnings, space weather (that's step 2).
- Everything you share builds your reputation. Each record you publish is stamped with your ID, so your track record is provable, portable, and yours alone.
- Your contact card carries proof. Export your listing as a normal contact card or QR code. Scan it at a conference and the other side gets your details plus the built-in proof that the card is genuine.
BEGIN:VCARD
VERSION:3.0
N:Smith;Jane;;Dr.;
FN:Dr. Jane Smith
ORG:Example Space Agency
TITLE:Chief Scientist
EMAIL:jane@example-agency.org
EMAIL;TYPE=INTERNET;TYPE=peerid:
12D3KooWQmVz…@peerid.spacedatanetwork.org
EMAIL;TYPE=INTERNET;TYPE=xpub:
xpub6CExampLe…@xpub.spacedatanetwork.org
END:VCARD
Scan to import
a verified contact
Name, organization, and title import on any phone exactly as written. Only two identity values travel with the card — your network address and your xPub (master public key) — encoded as email addresses at spacedatanetwork.org, a format every contacts app keeps. Everything else derives from the xPub.
Technical details: how your ID works
Your ID is a hierarchical-deterministic (HD) key wallet. spacedatanetwork init generates a BIP-39 mnemonic, encrypts it at rest (XChaCha20-Poly1305), and derives all operational keys from it using BIP-44/SLIP-10 paths:
- Identity:
m/44'/0'/0'→ secp256k1 → PeerID + XPub - Signing:
m/44'/0'/0'/0'/0'→ Ed25519 - Encryption:
m/44'/0'/0'/1'/0'→ X25519
Your public listing is an Entity Profile Message (EPM) — a FlatBuffer record carrying an embedded Ed25519 SIGNATURE and SIGNATURE_TIMESTAMP over its canonical content. When it changes, the node announces the new EPM content ID (CID) to the network with a signed PNM message.
The card does not need to carry individual keys — that is what derivation paths are for. It carries only the xPub and PeerID, encoded as email aliases (<xpub>@xpub.spacedatanetwork.org, <peerid>@peerid.spacedatanetwork.org) because iOS and Android contact apps preserve email fields but silently drop unknown X- extension fields. Role keys derive from the xPub at the SDK-specified BIP-44 paths: buildSigningPath() → m/44'/coinType'/account'/0/index and buildEncryptionPath() → m/44'/coinType'/account'/1/index (hd-wallet-wasm). The full vCard export additionally carries X-SDN-EPM-B64 — the complete signed EPM bytes and the source of truth: SDN importers verify its embedded signature and prefer it over the editable display fields. Inspect your identity anytime with spacedatanetwork show-identity.
Tune into live space data
Your node can now receive live feeds shared across the network — satellite positions, collision warnings, launch events, space weather, and more, in 160+ standardized formats. Open data is free to use, and every record arrives with built-in proof of who published it.
See what's out there:
# what data formats does the network carry?
spacedatanetwork search standards OMM --format json
# who publishes orbit data?
spacedatanetwork search providers celestrak --schema OMM
# pull records
spacedatanetwork search data --schema OMM --format csvOr subscribe from your own software with a few lines of code:
import { SDNNode } from '@spacedatanetwork/sdn-js';
const node = new SDNNode();
await node.start();
// live orbit data, as it is published
node.subscribe('OMM', (data, peer) => {
console.log(`Received from ${peer}`);
});Technical details: verification and the read API
Every message on the network is Ed25519-signed by its publisher. Before your node accepts a record, it verifies the signature against the publisher's EPM — provenance is checked automatically, not on trust.
Useful read endpoints on your local node (default 127.0.0.1:5001):
GET /api/v1/catalog— every schema registered on the node (public)GET /api/v1/data/records/{schema}/{cid}— fetch a specific record by content IDGET /api/v1/log/{schema}— a provider's publication log (public)GET /api/v1/stats— connected peers, record counts, schemas
All on-wire data is FlatBuffers (Space Data Standards schemas); JSON is available on HTTP responses. SQL-style queries over the binary data are available through FlatSQL.
Share your data with the network
Data on the network uses shared, open formats — that's what lets everyone read and verify everyone else's records. Match your data to one of the standard formats:
| Your data | Format |
|---|---|
| TLEs / orbital elements | OMM |
| Ephemerides | OEM |
| Conjunction warnings | CDM |
| Maneuver plans | MPE |
| Object catalogs | CAT |
| Tracking / sensor data | TDM, EOO |
The SDKs include converters for common formats (TLE, CCSDS XML/KVN), and if nothing fits you can propose a new format. Publishing itself is one call:
await node.publish('OMM', ommData);Then confirm it's live — search for yourself the way your customers would:
spacedatanetwork search providers "Example Space Agency" --schema OMM
spacedatanetwork search data --schema OMM --format jsonTechnical details: publishing over the REST API
The REST publish endpoint requires an authenticated session at Standard trust or higher — there is no localhost bypass. Log in once at http://127.0.0.1:5001/login (the first account on a fresh node is bootstrapped as Admin), then use the session token from the sdn_wallet_session cookie:
export SDN_SESSION_TOKEN='<your-session-token>'
curl -X POST http://127.0.0.1:5001/api/v1/data/publish/OMM \
-H "Content-Type: application/octet-stream" \
-H "Accept: application/json" \
--cookie "sdn_wallet_session=${SDN_SESSION_TOKEN}" \
--data-binary @omm.fbsThe session is delivered only as that cookie (bearer headers are not accepted). Automated pipelines can mint one programmatically: POST /api/auth/challenge, Ed25519-sign the challenge with the wallet signing key, then POST /api/auth/verify and capture the Set-Cookie value. CLI commands accept the same token via --session-token or SDN_SESSION_TOKEN.
Technical details: what happens under the hood
Every record is validated against its schema, content-addressed (SHA-256 CID), appended to your node's hash-chained publication log, Ed25519-signed, and announced to subscribers over GossipSub. Consumers can cryptographically verify that the data came from you and was never altered. REST checks: /api/v1/log/{schema} for your publication log, /api/v1/data/records/{schema}/{cid} for any record by content ID.
Software modules
The network doesn't just move data — it runs software. Propagators, conjunction screeners, sensor processing, analytics: all of these ship as modules that plug into any SDN node.
Modules are built on WebAssembly, a portable, sandboxed program format. Portable means you compile your algorithm once and that single file runs everywhere; sandboxed means a module can only touch what the host node explicitly hands it — it can't read files, open connections, or see anything else on the machine.
Because of that, modules are isomorphic: the exact same artifact runs in a web browser, on a server node, or on an edge device, with identical results. A demo running in someone's browser is executing the very same code as a production server — nothing is re-implemented per platform.
The Module SDK handles the whole pipeline — compile, validate, sign, and package:
npx space-data-module compile --manifest ./manifest.json --source ./src/module.c --out ./dist/isomorphic/module.wasm
npx space-data-module check --manifest ./manifest.json --wasm ./dist/isomorphic/module.wasm
npx space-data-module sign --wasm ./dist/isomorphic/module.wasm --key ./keypair.jsonTechnical details: module architecture
A module is a WebAssembly artifact with an embedded FlatBuffer manifest (PLG) declaring its identity, methods, and capability requirements. Host↔module calls use the SDS PIV invoke envelope, so any host runtime — browsers via the JS SDK, servers via WasmEdge — speaks the same contract. The canonical artifact path is dist/isomorphic/module.wasm.
The SDK ships a local module lab for interactive development: npm run start:lab then open http://localhost:4318 to compile, validate, and package in the browser. Encrypt an artifact for protected distribution with npx space-data-module protect.
Decentralized storefront
The network has a built-in storefront for selling both data products and software modules. There is no central store and no middleman between you and your customers — your own node hosts your listings, and buyers purchase directly from you.
- One signed listing per product. Each product and version gets a single listing, published from your node and visible across the entire network.
- Data: field-level access control. Mark each field in a stream as public or restricted — for example, share coarse positions openly while selling the high-precision values.
- Modules: encrypted delivery. Modules ship encrypted, so only paying customers can run them — and they run on the customer's machine, so your source never leaves yours.
- Per-customer keys. Every buyer receives their own key, so purchased content can't be shared or resold.
- Payments are built in. Card, crypto, or prepaid credits, with usage-based billing and enterprise invoicing supported.
Publish your encrypted catalog to your provider node — the request is signed with your ID, and only the node's administrator can publish:
spacedatanetwork plugins publish-orbpro \
--plugin-root ./my-plugins \
--wallet-env ./wallet.env \
--wallet-wasm ./hd-wallet-wasi.wasm \
--target /dns4/<host>/tcp/<port>/wss/p2p/<peer-id>Buyers browse the storefront the same way they find your open data:
spacedatanetwork marketplace list
spacedatanetwork marketplace search <term>
spacedatanetwork marketplace show <listing-id>Technical details: listings, protection, and delivery
Marketplace listings are canonical signed PLG records — exactly one per product ID and version — served from your provider node at GET /api/module-delivery/listings. Field-level data protection uses the SDS FSM record (each field marked Public, Encrypted, Redacted, or Unavailable). Delivery uses per-customer ECIES (X25519 + AES-256-GCM) key wrapping; payments run through Stripe (card), crypto, or credits.
The publish request is Ed25519-signed by your admin HD wallet and sent over the libp2p protocol /space-data-network/module-publish/1.0.0; the receiving node verifies the signer is an admin before accepting. For a single module over HTTP, POST /api/v1/plugins/upload takes a multipart bundle, metadata JSON (id, version), and signature_hex (Ed25519 over the bundle's SHA-256), using the same session cookie as publishing. A complete two-provider reference scenario ships with the repo: npm run demo:hydra-marketplace; buyer-side integration uses createStorefrontClient from @spacedatanetwork/sdn-js/storefront.
Where to next
Onboarding · SDN
Share this guide — the code points straight here.