An app, a keypair, and one link

What it will look like

Four steps. Two of them are things the app does for you; the other two take about a minute.

1. Step 01

   Get the app: your time book

   A time book is the record — what you worked on, for how long, countersigned by whoever received it. QW keeps yours on your phone, because the phone holds the key that signs it.

   It is a time bank in the same breath. Hours flow both ways in open source — you review someone’s patch this month, they maintain the library you depend on next — and the same signed records that document what you gave denominate what you are owed, in Quant, a quarter hour of work. No balance sits on a server; what you hold is your counterparties’ signatures.

   One codebase (Rust + Tauri v2) targets Android, iOS and desktop. The phone is the primary shape because a signing device is something you carry, and because a thin client that syncs when it next wakes is the only realistic model when the counterparty is asleep half the time.

   The client runs no relay and no DHT. It signs what you tell it to, hands the result to whatever server or relay it can reach, and collects what arrived for you. That is the whole job.

2. Step 02

   First launch generates your identity

   One secp256k1 keypair, made on the device. That is the account — there is no email, no password and no server that could issue you one.

   The same key is both a did:key controller id and a Nostr pubkey, so the identity that signs your contracts is the identity that publishes your events.

   It is stored in the app data directory, private to the app, file mode 0600. Back it up. Nobody can reissue it: losing the key is losing every record signed with it, and a client that quietly generated a fresh one instead of reporting a corrupt key file would look like being logged out while abandoning your history. So it reports.

3. Step 03

   Open an invite link — or post your own

   Following knownby.work/i/<npub> exchanges two signed introductions and puts you one hop from the publisher.

   An invite link is just a public key in a URL, so it works anywhere a URL works — a LinkedIn profile, a talk slide, an email signature, a README badge. Whoever publishes it has consented in advance to the introduction, so your client signs your half and the publisher’s client answers with theirs.

   You do not need one to join. A self-introduction to someone you found through a referral query, or a mutual introduction carried by a shared contact, are the other two shapes of the same event. There is no admission step behind any of them — a signed introduction is the membership.

4. Step 04

   Say what you do, then do some of it

   Skill tags are the claim; completed, countersigned contracts are the evidence.

   Publishing a tag costs nothing and proves nothing, by design. Trust is computed from finished work — a hop-1 contact with no contracts counts exactly as much as a stranger four hops out: nothing.

   That is also why an invite link cannot be used to inflate anyone. The link edge makes you reachable, so queries can route to you and offers can arrive. It vouches for no one, and a link you posted publicly is marked as such so it never lends your vouchers to a cascade block.

The event behind step 3 is NIP-QW07 (kind 9060, all three shapes plus the invite-link form); step 4 is NIP-QW03. Why a public link does not propagate a block is in NIP-QW05.

The app, platform by platform

One Rust core, one web frontend, four targets. Where a platform is not there yet, the reason is tooling, not architecture.

What exists today

• Protocol layer

  Identity, the job lifecycle, trust paths, cascade block, referral routing, introductions and invite links — 134 tests pass across the workspace.

• Client core

  On-disk identity, the HTTP mailbox transport, and the invite-link flow — tested against a real server on a real socket.

• Store-and-forward mailbox

  A coordination server holds signed events for a recipient who is offline. Everything delivered is verified on your device, so a hostile cache can withhold mail but cannot inject any. It never requires a login.

• A released app

  Android runs: a signed APK, sideloaded from this page, one architecture, on no store. That is a working build rather than a release — nothing is packaged for iOS or desktop, and nothing has been through a store review.

• Relays and deep links

  No public relay or gateway runs yet, and clicking an invite link does not open the app — the link has to be pasted into it.

Rust stable, no services, no network. These run locally and publish nothing anywhere — there is no relay and no public gateway yet, so this is a developer path rather than a way onto a running network.

git clone https://github.com/DBinvent/qw.git
cd qw

# the protocol, end to end
cargo test --workspace

# greedy referral routing over a synthetic contact graph
cargo run -p qw-node --example referral_demo

# skill tags and co-authorship pairs inferred from a real repo
cargo run -p qw-node --example bootstrap_from_git -- <path/to/a/git/repo>

# the client shell (needs webkit2gtk et al; see app/README.md)
cd app/src-tauri && cargo tauri dev

# the Android build (needs a JDK, the Android SDK and the NDK)
cargo tauri android init && cargo tauri android dev

Exact prerequisites, and which of these has actually been run, are in app/README.md; the rest of the repo is described in the project README.