Launch the native app for the current desktop platform:

just run

On macOS this builds and opens the SwiftUI/AppKit app, registers the File Provider domain when signing allows it, and starts the bundled iris-drive daemon. On Linux it starts the GTK/libadwaita shell. Use the platform READMEs for platform-specific signing, packaging, and smoke-test details.

For a terminal-only flow:

just run-cli init --label "Laptop"
just run-cli import /path/to/seed-folder
just run-cli daemon

Fresh clients use the independent authenticated FIPS first-adjacency services on LNVPS (wss://fips1.iris.to/fips) and Osiris (wss://fips2.iris.to/fips) by default. Override or disable them with IRIS_FIPS_WEBSOCKET_SEED_URLS, using a comma-separated list of explicit wss://.../fips URLs or an empty value. Normal Nostr relay settings remain event and discovery/signaling routes; they do not carry FIPS packets.

With mesh pubsub enabled, Drive saves up to 256 signed FIPS peer announcements in fips-peer-announcements/ beside the device key. Each device and discovery scope has its own JSON file. After restart, Drive restores valid announcements for discovery and can answer a connected peer’s Nostr request from disk even when the relays and the original announcing peer are offline.

Mesh peer selection uses the shared FIPS reputation policy and local transport observations. No external rater is trusted by default. Optionally set IRIS_DRIVE_FIPS_TRUSTED_RATERS to comma- or semicolon-separated npub or hex public keys. These identities supply additional initial trust; neither friends nor successful transport peers automatically gain rating authority. Invalid explicit keys fail mesh startup. The shared adapter owns bounded rating exchange and publication; Drive does not run a separate rating loop.

Useful CLI probes:

just run-cli stats
just run-cli status
just run-cli whoami
just run-cli list
just run-cli update --check

Common device-link and backup flows:

just run-cli app-keys invite
just run-cli app-keys request <device-invite-url> --label "Laptop"
just run-cli app-keys request <nostr-identity-uuid> --admin-app-key <admin-device-npub> --label "Laptop"
just run-cli app-keys approve <device-request-url-or-device-npub>
just run-cli app-keys list
just run-cli app-keys repair-wraps
just run-cli shares create "Projects/Alpha" --name "Alpha"
just run-cli shares recipient-evidence --display-name "Alice" > recipient-profile.json
just run-cli shares invite <share-id> --recipient-evidence recipient-profile.json --role reader
just run-cli shares invite <share-id> --profile <nostr-identity-id> --app-key <recipient-device-npub> --role reader
just run-cli shares accept <share-invite-url>
just run-cli shares list
just run-cli shares members <share-id>
just run-cli shares role <share-id> <nostr-identity-id> editor
just run-cli shares revoke <share-id> <nostr-identity-id>
just run-cli shares shortcut <share-id> --parent "Projects"
just run-cli shares repair-wraps <share-id>
just run-cli shares list --diagnostics
just run-cli backups add fs:/path/to/encrypted-backup --label "External disk"
just run-cli backups sync

Native apps expose the same share operations from the Shares tab: create a shared folder, invite a NostrIdentity member, accept an invite, change member roles, revoke a member, add a shortcut, and repair missing key wraps. The UI shows people/profile members first; invite dialogs prefer signed recipient-evidence JSON. idrive shares recipient-evidence or the app-core export_share_recipient_evidence action exports the local NostrIdentity/device proof bundle another user can pass to idrive shares invite --recipient-evidence or invite_share_member_from_evidence; native share screens expose this as Copy my share identity. Direct device-key entry remains an admin fallback.

CLI share JSON follows the same shape by default: members are NostrIdentity entities and repair/revocation output reports counts. Raw device-key lists are available only from explicit diagnostics output such as idrive shares list --diagnostics, idrive shares revoke <share-id> <nostr-identity-id> --diagnostics, and idrive shares repair-wraps <share-id> --diagnostics.

OS share/open integrations do not grant access by themselves. They open the app share dialog for a selected Iris Drive folder using iris-drive://share?path=<folder>&name=<optional-name> or the equivalent https://drive.iris.to/share?... route; the user still confirms through the normal Shares tab create flow. Web/contact handoff may include recipient_npub, recipient_name, and recipient_profile query hints to prefill the invite form, but those hints are display/discovery data only. Signed recipient evidence and roster ops establish the IrisProfile member that receives access.

Share invites include a signed roster checkpoint that summarizes the current entity members, the materialized AppKey-to-IrisProfile participant mapping, co

…