pull down to refresh

A few weeks ago I posted here about swift-nostr v0.5.0 closing the Lightning zap loop — sign the zap request, pay the invoice over NWC, verify the receipt, all in Swift.

The obvious next question for anyone actually shipping an app: does my app have to hold the user's private key to do any of that? For a crowd whose whole ethos is "not your keys, not your coins," pasting an nsec into some app's storage is a non-starter.

v0.6.0's answer is no.

NIP-46 remote signing (new NostrConnect library). The user's key stays in their signer/bunker. Your app asks the remote signer to sign events and to encrypt/decrypt — the nsec never enters your process. Both flows are covered: signer-initiated bunker:// and client-initiated nostrconnect://, plus auth_url challenges and the full typed command set (sign, get_public_key, ping, nip44/nip04 encrypt/decrypt, switch_relays, logout).

And because local and remote signers now share one NostrSigning protocol, you write your app against a single API — client.setSigner(...) takes either an in-process EventSigner or a remote RemoteSigner. Develop with a local key, ship against a bunker, no code change.

NIP-44 encryption is now spec-compliant and interoperable. Honest bug: earlier releases used the AEAD ChaCha20 keystream (block counter 1) and a floating-point padding calc, so our encrypted payloads didn't match other Nostr clients — including the NIP-44 that modern NWC rides on. Now it's bare ChaCha20 at counter 0 with the spec's integer padding, validated against the official NIP-44 test vectors. (Payloads from older releases won't decrypt — but they never interoperated with anything else either.) If you touch encrypted DMs or NWC, this is the release you want.

The other nine NIPs this cycle:

  • NIP-49 — password-encrypt a private key to ncryptsec (scrypt + XChaCha20-Poly1305). Key-at-rest to go with the key-never-in-app story above.
  • NIP-13 — proof of work, with a cooperative, cancellable async miner
  • NIP-23 — long-form articles + drafts (kind 30023/30024), naddr addressing
  • NIP-51 — lists & sets (mute, pin, bookmarks, follow/relay/curation sets…) with NIP-44-encrypted private items
  • NIP-50 — relay-side search
  • NIP-45 — event counts (COUNT)
  • NIP-27 — nostr: mention parsing → p/q/a tags
  • NIP-21 — nostr: URIs
  • NIP-56 — reporting

Lightning is still first-class — NIP-57 zaps and NIP-47 NWC (full command set + one-call payZap) are unchanged, and now ride on the fixed NIP-44.

Where it stands: 31 NIPs, Swift 6 (actor-isolated, Sendable, async/await), all Apple OSes (iOS/macOS/tvOS/watchOS/visionOS), MIT. Four libraries so you pull only what you need — NostrCoreNostrClientNostrWalletConnectNostrConnect.

Still early and built in the open. If you're working on Lightning-native social — or DVM/agent ideas that need to pay, sign, and stay non-custodial over Nostr — I'd love issues, PRs, or teardowns.

https://github.com/yysskk/swift-nostr

Feedback welcome ⚡

1 sat \ 2 replies \ @ek 6 Jul
Feedback welcome ⚡

Did you use AI to write this?

reply
1 sat \ 0 replies \ @ek 2h
Feedback welcome ⚡
Did you use AI to write this?

Just an easy way to spread it

reply
1 sat \ 0 replies \ @ek 6 Jul

You are requesting human feedback; however, you have not provided content formatted in a manner that is optimized for human readability or engagement

reply