Nostr Compass Podcast #39
About this episode
<p>Max covers signed Git workflows, browser publishing, Nostr client updates, protocol implementation, and how URI links and event references work.</p><p>Guests: nostr:npub1klkk3vrzme455yh9rl2jshq7rc8dpegj3ndf82c3ks2sk40dxt7qulx3vt</p><p><a href="https://nostrcompass.org/en/newsletters/2026-09-09-newsletter/">Newsletter 39</a> · <a href="https://gitworkshop.dev/npub1wav4fae3gyfy3xj298kxj2mj8phavz7vavps34przq02j7w902qq902923/relay.ngit.dev/nostr-compass-android">Nostr Compass Android source</a></p><h3>0:00 Signed git workflows move CI, private repositories, and releases onto Nostr</h3><p>Max opens this edition’s nine recordings with the ngit v3 launch and its signed Git workflow over Nostr. ngit-grasp v3 adds private repositories through GRASP-08, while ngit-ci 0.1 carries CI instructions and results as signed Nostr events. Max discusses working privately before a public release and considers sharing spare CI capacity.</p><h3>3:13 nsite-clay makes browser publishing recoverable</h3><p>An <a href="https://github.com/jooray/nsite-clay/commit/064a0c5350f1e2b107f7d8f1de00ad75ef2e69d8">August 31 signer-prompt fix</a>, <a href="https://github.com/jooray/nsite-clay/commit/d1ad514f8068eec2e007059dc62a5b6f1d240ae0">publication recovery</a>, and <a href="https://github.com/jooray/nsite-clay/commit/8f9d7d140dd3cd3e1db8726781fcd852041713f7">September 2 editing controls</a> make <a href="https://github.com/jooray/nsite-clay">nsite-clay</a> a browser publishing tool for a single-page site. A user edits the document object model in place, serializes the result, uploads it as a content-addressed <a href="https://nostrcompass.org/en/topics/blossom/">Blossom</a> blob, and republishes the site's <a href="https://nostrcompass.org/en/topics/nip-5a/">NIP-5A</a> manifest. No local build or server is required.</p><h3>4:53 NIP-A3 payment targets reach three clients</h3><p>From September 1–3, <a href="https://github.com/vitorpamplona/amethyst/pull/4041">Amethyst</a>, <a href="https://github.com/purrgrammer/grimoire/commit/54052506f7a0da06dfc4cf7e969331ee61be7851">Grimoire</a>, and <a href="https://github.com/formstr-hq/nostr-polls/commit/5a015f1d17abecd036f3e10c88d493d23928fa98">Pollerama</a> implemented NIP-A3 kind <code>10133</code> 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.</p><h3>5:16 Ditto expands Blossom fallback and mirroring</h3><p>Max explains how Ditto tries fallback Blossom servers when the preferred server is unavailable. He also discusses mirroring uploaded blobs so media can remain available through other servers.</p><h3>5:46 Nostr Implementation Possibilities</h3><p><a href="https://nostrcompass.org/en/topics/nip-01/">NIP-01</a> clarifies <code>limit: 0</code> as a live-only subscription: no stored events, an <code>EOSE</code> message, and continued delivery of matching new events. <a href="https://nostrcompass.org/en/topics/nip-78/">NIP-78</a> recommends NIP-42 authentication and author-only access for app data kinds <code>78</code> and <code>30078</code>; this is not a confidentiality guarantee. The open <a href="https://nostrcompass.org/en/topics/nip-ac/">NIP-AC</a> proposal uses ephemeral WebRTC signaling events and kind <code>30600</code> discovery.</p><h3>8:08 NIP Deep Dive: URI Links and References in Event Text</h3><p>A Nostr identifier needs a transportable meaning before another application can open it. <a href="https://nostrcompass.org/en/topics/nip-21/">NIP-21</a> puts a <a href="https://nostrcompass.org/en/topics/nip-19/">NIP-19</a> identifier after the <code>nostr:</code> URI scheme, giving browsers, operating systems, and applications one dispatchable form. <a href="https://nostrcompass.org/en/topics/nip-27/">NIP-27</a> defines what that same URI means inside readable event <code>content</code>.</p><h3>8:28 URI dispatch and NIP-19 semantics</h3><p><a href="https://github.com/nostr-protocol/nips/blob/master/21.md">NIP-21's grammar</a> is <code>nostr:</code> followed by one NIP-19 bech32 entity. <code>nsec</code> is excluded because it encodes a private key. There is no authority, path, or query component, so a conforming link is <code>nostr:npub1...</code>, not <code>nostr://npub1...</code>. A platform or client may register as the handler; the specification does not choose the installed application or define a web fallback.</p><h3>10:35 NIP-27 rendering and optional tags</h3><p><a href="https://nostrcompass.org/en/topics/nip-27/">NIP-27</a> uses <code>nostr:</code> URIs in readable event content so clients can render profile or event references. Max explains how a mention picker writes those URIs into signed content and how other clients display them. Optional <code>p</code>, <code>e</code> and <code>q</code> tags support indexing and relationships alongside the reference; displaying a mention alone does not require a notification.</p><h3>12:19 Trust, failure behavior, and client implementations</h3><p><code>note</code> and <code>nevent</code> refer to immutable event ids, while <code>naddr</code> resolves an address whose event contents can change. Max discusses client choices for previews, profile metadata and URI handlers. He closes by thanking builders and inviting listeners to contribute through the Nostr Compass Logbook.</p> Originally published by [Nostr Compass](https://nostrcompass.org/)