Nostr Compass #39

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: ngit and GitWorkshop move signed git workflows onto Nostr and Blossom, nsite-clay makes browser publishing recoverable, and Wingman App joins browsing, local signing, authentication, and files. Shosho and Livelier connect self-hosted streams to Nostr, Communitator makes relay templates inspectable before signing, cal.emre.xyz publishes appointment slots, and Plektos encrypts private events. Tagged releases add recovery and privacy work in Vector, Primal Android, LibreNostr, and SkateSpots. Development work spans NIP-27 rendering, signed relay preferences in Conduit, NIP-A3 payment targets, and Blossom mirrors. Merged changes in the NIPs repository clarify live-only subscriptions and authenticated application data. Our deep dive explains how NIP-21 links and NIP-27 references carry Nostr profiles and events across applications.

Tagged Releases

Vector 0.4.4 makes encrypted-community recovery safer

Vector 0.4.4 shipped August 31 with community recovery, key-rotation, moderation, and reply-routing fixes. Refounding closes a raided community to the invitation path used by attackers; replacement membership supersedes stale local state; and one unreachable member no longer freezes the roster. Empty rotations are rejected, promotions preserve online members, and operations refuse to run when required members cannot be reached.

The release also persists moderator deletions and bans, re-encrypts the guest book after a password change, binds notification replies to their conversation after restart, and uses only verified multiplayer paths. These are recovery controls, not revocation of keys already obtained.

Primal Android 3.5.27 checks signer and wallet identity

Primal Android 3.5.27 shipped September 3 after the signer identity check and wallet-request authentication merged August 31. Local signing rejects a request whose identity does not match the held account, and incoming NIP-47 requests are authenticated before processing. Zap-poll routing also sends votes to the poll author when the poll appears in a reply.

GRAIN 0.8.0-rc2 closes an acknowledged-but-not-stored path

GRAIN 0.8.0-rc2 shipped September 7 after a storage failure allowed OK before its asynchronous LMDB database writer noticed full storage capacity. The relay now warns at 80 and 95 percent, refuses new events at 97 percent while leaving deletion room, and reports post-acceptance writer failures. Retention walks oldest-first, teardown handles late messages, and invalid filters no longer discard valid siblings.

The release also corroborates kind 10166 monitor announcements and kind 30166 relay reports, evicts stale reports, keeps configured relays as fallback, and reports live limits and authentication in NIP-11 instead of static zeros.

LibreNostr 0.5.0–0.5.2 makes Tor routing fail closed

LibreNostr 0.5.0 shipped September 7 with an Orbot mode routing relays, zaps, uploads, media, playback, and previews through one SOCKS port, plus a repair for a zap-sheet crash. If Orbot or the proxy is unavailable, connections stop instead of leaking onto a direct route. Version 0.5.1 stops slow NIP-50 searches delaying local results; 0.5.2 replaces recursive thread layout and repairs thread ordering.

The fail-closed behavior applies to every network surface listed by the release, and a restart is required because those clients are long lived. The patch releases preserve that choice while limiting unrelated search, stack-depth, and layout failures.

SkateSpots adds an on-device relay path

The signed September 8 Zapstore release adds an optional Citrine relay to SkateSpots. Spots, crews, messages, and map data can load locally; posts queue offline; and the phone keeps a local copy. Existing stash and message content stays end-to-end encrypted. Payment checks require invoice amounts and provider-issued zap receipts before granting access or counting contributions.

The local relay is a storage and continuity option, not a replacement for every remote relay. It lets a skater keep working through a disconnected stretch and then reconcile signed activity later, while the payment changes stop a self-authored receipt from becoming proof of settlement.

Whistle 1.8.15 repairs encrypted-group lifecycle recovery

Whistle 1.8.15 shipped September 3 after an Android lifecycle repair stopped route-level state holders from destroying application-wide relay subscriptions and location updates. Its release notes also describe refreshed connection state after lock or doze and a recovered 501-event backlog in the observed case.

The bug tied ownership of a long-lived service to a short-lived screen. Keeping the activity-scoped instance alive and checking the socket before a one-shot read makes ordinary Android navigation and background suspension less likely to look like an empty group.

TWENTY ONE Companion 1.12.0 separates encrypted DMs from legacy chat

TWENTY ONE Companion 1.12.0 shipped September 5 with NIP-17 gift-wrapped DMs. The encrypted inbox is separate from older space chat, which remains distinct because those messages were never encrypted and cannot be migrated. PDFs and videos are supported subject to relay policy, and personal hides sync without becoming moderator bans.

The visible separation is part of the security model. Calling the old history a secure inbox would misrepresent its provenance, while silently migrating it would suggest encryption that did not exist when it was written.

ZapStore 1.1.2 validates event ids and certificate rotation

ZapStore 1.1.2 shipped September 4 with NIP-01 event-id validation: the client recomputes an incoming event’s id and rejects mismatches before using it. The release also identifies packages installed outside ZapStore. On the server, certificate-hash retention preserves repeated apk_certificate_hash tags so Android signing-key rotation can retain an approved lineage.

The event-id check prevents a relay or cache from changing tags or content while keeping the old id. The installer-source indicator supplies separate provenance when an Android package with the same application id came from another channel.

Amber 6.6.1 keeps signer responses attributable

Amber 6.6.1 shipped September 4 after permission parsing was fixed to tolerate a missing optional kind, and rejected signing requests began returning their original request id. Calling applications can match a rejection to the submitted operation. The release also updates remote-signer defaults and adds an indexer relay.

Together these fixes preserve attribution in both directions: a permission record remains usable when an optional field is absent, and a refusal remains tied to the request that caused it. The relay-default changes affect discovery, but they do not replace the signer’s local authorization decision.

In Development

Zap Cooking renders NIP-27 references with relay hints

The September 4 merge makes Zap Cooking render nostr:npub and nostr:nprofile references in articles, recipes, editor previews, and print views. Invalid identifiers remain text, resolution is non-blocking, and the editor previews the Markdown that will be signed. When relay information exists, a bare npub becomes an nprofile with outbox relays and a matching p tag.

The same week fixed author-scoped kind 30023 reads, added verified NIP-50 search relays with deduplication and stale-query guards, and repaired NIP-47 wallet calls after dependency changes broke balances and history.

Conduit reconciles signed relay and Blossom preferences

Conduit merged Blossom preference editing on September 2 and signed preference reconciliation on September 7. Market and Merchant retain the latest valid kind 10002 relay list and kind 10050 inbox declaration, preserve a usable signed list when a newer event is malformed, distinguish an explicit empty list from an unavailable lookup, and do not replace failed declared relays with code defaults.

The kind 10063 editor lets a user load, reorder, review, externally sign, publish, and read back an ordered HTTPS media-server list without contacting those servers or inserting an undeclared default.

NIP-A3 payment targets reach three clients

From September 1–3, Amethyst, Grimoire, and Pollerama implemented NIP-A3 kind 10133 payment targets. Amethyst offers an opt-in handoff only when a compatible target exists and does not turn it into a zap; Grimoire uses a fixed registry before building wallet URIs; Pollerama validates Monero addresses and fetches the author’s relay list before querying targets. Each client still needs an allowed payment method, a relay route, and an accurate display.

Ditto expands Blossom fallback and live embeds

Ditto merged broad Blossom fallback and mirroring on September 6. Avatars, badges, banners, community images, custom emoji, and application icons now try declared servers with the same blob hash; mirror uploads use a standard BUD-11 authorization token. A September 4 change added compact kind:30311 live-stream embeds.

Protocol and Spec Work

Nostr Implementation Possibilities

NIP-01 now clarifies the limit: 0 filter, merged September 4. A relay MUST return no stored events, MUST send EOSE when initial queries complete, and MUST keep the subscription active for new matching events. Clients can open a live-only subscription with one filter field while retaining local history. The clarification records compatible behavior across several relay implementations and public relays.

NIP-78 gained an authenticated app-data requirement, merged September 3. Relays SHOULD require NIP-42 authentication for kinds 78 and 30078 and SHOULD serve them only to the authenticated event author. That is a SHOULD, not a confidentiality guarantee: clients cannot treat arbitrary relays as private storage. The merge also discourages custom app-data kinds as generic public interchange.

NIP-AC opened September 4 as an explicitly open WebRTC-signaling proposal. It uses provisional ephemeral kinds for ping, connect requests, offers, answers, and ICE candidates, addressed with p and grouped by a session e tag; kind 30600 supports discovery. Relays SHOULD broadcast and MUST NOT store those signaling events while peers connect directly. The numbers remain provisional, clients SHOULD use NIP-65 relay lists, and applications needing confidentiality SHOULD encrypt offer, answer, and candidate content with NIP-44.

NIP Deep Dive: URI Links and References in Event Text

A Nostr identifier needs a transportable meaning before another application can open it. NIP-21 puts a NIP-19 identifier after the nostr: URI scheme, giving browsers, operating systems, and applications one dispatchable form. NIP-27 defines what that same URI means inside readable event content. NIP-21 crosses an application boundary; NIP-27 keeps a profile or event reference in signed prose. Neither creates an event kind or changes relay messages; the two specifications define only linking and rendering behavior.

URI dispatch and NIP-19 semantics

NIP-21’s grammar is nostr: followed by one NIP-19 bech32 entity. nsec is excluded because it encodes a private key. There is no authority, path, or query component, so a conforming link is nostr:npub1..., not nostr://npub1.... A platform or client may register as the handler; the specification does not choose the installed application or define a web fallback.

The prefix tells a client what to decode. npub carries a public key and note an event id. nprofile adds optional relay hints to a profile; nevent adds relays, author, and kind to an event id; and naddr carries the author, kind, and d identifier of an addressable event, with optional relays. These forms use NIP-19 type-length-value fields. Hints narrow discovery but prove neither relay possession nor author control. Every fetched event still needs an id recomputation and signature check.

The profile form in the NIP-21 specification is:

nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9

NIP-21 also defines HTML bridges: a page serving a Nostr event can put its naddr in <link rel="alternate">, and a profile can put an nprofile in <link rel="me"> or <link rel="author">.

NIP-27 rendering and optional tags

NIP-27 applies to readable event content such as kind 1 notes and kind 30023 articles. A composer may display @name, but publishes nostr:nprofile1... in the signed string. A reader scans the URI, decodes its NIP-19 entity, fetches the target, and may render a name, card, preview, or local link. If decoding fails, the URI remains ordinary text. The raw content must not be rewritten: changing it changes the NIP-01 serialization, id, and signature.

Content references and tags have related but distinct jobs. NIP-27 describes optional p and e tags and the NIP-18 q tag. A client may show a reference without creating a notification or thread relationship; quote discovery should write both the URI and a q tag. Zap Cooking’s September 4 implementation follows that split by retaining the URI while adding relay hints and a matching p tag. Adding p or q does not make the URI private, and NIP-27 has no hidden-mention mode.

The following kind 1 event was recovered from wss://nos.lol and verified before inclusion as a concrete NIP-27 reference. Its content contains an naddr for a version-independent addressable event. Decoding yields kind 30402, author 91036d...310a, the workbook’s d identifier, and a wss://nos.lol/ hint. The q, p, t, zap, and client tags are application choices, not NIP-27 requirements.

{
  "id": "cbf64aa95627f3722915e9aad29d905ddac9b09e7a8808a7594732d90deaa6bb",
  "pubkey": "ed1b999da9a434039d22338c276ffd6e338d609b81e6b1c305a120a982df787d",
  "created_at": 1788953511,
  "kind": 1,
  "tags": [
    [
      "p",
      "91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a",
      "wss://multiplexer.huszonegy.world/"
    ],
    [
      "t",
      "archetype"
    ],
    [
      "q",
      "30402:91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a:Archetype-Workbook-Companion-Meet-your-King-Warrioir-Magician-Lover-today-oejbwe",
      "wss://nos.lol/"
    ],
    [
      "zap",
      "91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a",
      "wss://multiplexer.huszonegy.world/",
      "0.9"
    ],
    [
      "zap",
      "ed1b999da9a434039d22338c276ffd6e338d609b81e6b1c305a120a982df787d",
      "wss://relay.nostr.band/",
      "0.1"
    ],
    [
      "client",
      "Amethyst"
    ]
  ],
  "content": "You can check, read and use this Workbook already! You can also support and get it for few sats and support us in this project.\n\nI hope it'll help you in your Archetype Journey :)\n\n#archetype\n\nnostr:naddr1qpgyzunrdpjhg7tsv5k4wmmjdd3x7mmt94pk7mtsv9hxjmmw94xk2et594uk7atj949kjmn894tkzunjd9hkju3df4skw6trd9skut2vdamx2u3dw3hkgcte94hk26nzwajszrnhwden5te0dehhxtnvdakz7q3qjypkmmqcaetrcpld4m27la946cch2hrk7qr8xjehsu5j5h3uxy9qxpqqqpmvyqnrm7n",
  "sig": "aa9592e7c773271b9e9f980c8a7e17fda2ffd5a4483a1789e5dd4c4a83018ac576c5202b21b33b08770dcabe023f93998a41f1a0be4bf00e36cdde611d07915e"
}

Trust, failure behavior, and client implementations

A safe reader finds a complete nostr: token, validates bech32, decodes NIP-19, rejects nsec, ignores unknown TLV types, and leaves malformed or oversized text alone. npub and nprofile lead to profile queries; note and nevent identify immutable events; naddr selects the latest valid addressable event for its kind, author, and d tag. Relay hints reduce search but do not extend trust. Under the NIP-01 event rules, the client verifies a fetched nevent id and checks every naddr candidate signature before applying addressable-event replacement rules.

Inline previews are a client choice with privacy and resource costs. Fetching every reference reveals the reader’s interests and can create a lookup storm, so clients can use a cache, defer fetches until visible, cap concurrency, and require a click for unfamiliar media. Under NIP-27, a preview must remain distinct from the current author’s signed text. Failure should be visible as unresolved text or an unavailable card, not silently treated as verified content.

Trust also changes by identifier type. A nevent names immutable bytes, so a client can reject a fetched event whose serialized id differs from the requested id. An naddr names a replaceable coordinate, so a client must verify each candidate and apply the addressable-event rules before deciding which version to display. A relay hint is useful for the first query in either case, but it is not an endorsement of the relay or of the returned content. NIP-19’s TLV definition supplies the data needed to make those checks explicit.

NIP-21 defines a portable link that can be opened from outside Nostr, while NIP-27 makes the same link durable inside signed text. A client that implements only NIP-21 can open a pasted URI but not render embedded references. Full NIP-27 support adds scanning, safe decoding, fetch policy, local rendering, and an explicit choice about notification and quote tags. The shared URI keeps those layers interoperable without forcing clients to present them identically.

Damus models inline references as typed mentions. Its mention code maps npub and nprofile to profile references, note and nevent to event references, and naddr to address references; NostrLink routes them to the appropriate destination. Primal Android parses the scheme and pasted forms, validates bech32 and extracts relay hints, then maps references into note-content models. Zap Cooking renders the same references in articles, recipes, editor previews, and print views.

Send a NIP-17 DM to share a project or news item through the Nostr Compass project.

Top Stories

Signed git workflows move CI, private repositories, and releases onto Nostr

nsite-clay makes browser publishing recoverable

Wingman App joins browsing, signing, and files

Shosho ships Livelier’s self-hosted streams

Communitator makes relay templates inspectable before signing

cal.emre.xyz publishes NIP-52 appointment availability

Plektos makes private events one encrypted channel