From d1e94856e688b929e16faf7972b1156de343289b Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Wed, 15 Jul 2026 19:28:55 +0000 Subject: [PATCH 01/10] Add Spanish translations for Newsletter #31 and topic pages Co-Authored-By: Claude Opus 4.6 --- .../es/newsletters/2026-07-15-newsletter.md | 300 ++++++++++++++++++ content/es/topics/concord-protocol.md | 61 ++++ content/es/topics/gamma-markets.md | 69 ++++ content/es/topics/nip-4e.md | 46 +++ content/es/topics/proofmode.md | 36 +++ 5 files changed, 512 insertions(+) create mode 100644 content/es/newsletters/2026-07-15-newsletter.md create mode 100644 content/es/topics/concord-protocol.md create mode 100644 content/es/topics/gamma-markets.md create mode 100644 content/es/topics/nip-4e.md create mode 100644 content/es/topics/proofmode.md diff --git a/content/es/newsletters/2026-07-15-newsletter.md b/content/es/newsletters/2026-07-15-newsletter.md new file mode 100644 index 0000000..26defe0 --- /dev/null +++ b/content/es/newsletters/2026-07-15-newsletter.md @@ -0,0 +1,300 @@ +--- +title: "Nostr Compass #31" +date: 2026-07-15 +publishDate: 2026-07-15 +draft: false +type: newsletters +translationOf: /en/newsletters/2026-07-15-newsletter.md +translationDate: 2026-07-15 +description: "Vector v0.4.0 retira Marmot para chats grupales a favor del protocolo abierto Concord y lanza Concord v2 días después, Amethyst fusiona su propia implementación limpia de Concord, Sonar se separa de Bitchat con una alpha multiplataforma y una especificación de paquetes de stickers, Divine Mobile 1.0.16 incorpora cifrado en reposo y procedencia ProofMode, Bitchat 1.7.0 añade voz push-to-talk en vivo, y MDK v0.9.4 acota el inicio de sesión con firmante externo." +--- + +Bienvenidos de vuelta a Nostr Compass, su guía semanal sobre Nostr. + +**Esta semana:** [Vector v0.4.0](#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) retira [Marmot](/es/topics/marmot/) como transporte predeterminado para Chats Grupales a favor de [Concord](/es/topics/concord-protocol/), un protocolo de comunidad abierto con licencia MIT también utilizado por Armada de Soapbox, y lanza Concord v2 cuatro días después con un selector de comandos con barra para bots, un temporizador de autodestrucción y badges NIP-58. [Amethyst fusiona su propia implementación limpia de Concord, compatible a nivel de protocolo](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities), la misma semana. [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) se separa de Bitchat con una alpha multiplataforma y es la fuente de especificación citada para la propuesta de kinds de paquetes de stickers de esta semana. [Divine Mobile 1.0.16](#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) incorpora un editor de video más profundo, cifrado en reposo y procedencia ProofMode que sobrevive a las descargas de clips con marca de agua. [Bitchat v1.7.0](#bitchat-v170-adds-live-push-to-talk-voice-for-dms-and-the-public-mesh) añade voz push-to-talk en vivo para DMs y push-to-talk firmado en la malla pública. [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) acota el inicio de sesión con firmante externo y añade persistencia de borradores, continuando su pase de endurecimiento la misma semana en que Vector se aleja de la especificación para chat grupal. + +Los lanzamientos etiquetados traen [n_cord v1.1](#n_cord-v11-adds-nsec-bunker-support) con soporte para NSEC Bunker, [cdk v0.17.3](#cdk-v0173-adds-nip-47-wallet-service-support-across-cdk-cdk-nwc-and-cdk-ffi) con soporte de servicio de billetera NIP-47 en cdk, cdk-nwc y cdk-ffi, [Coop Mobile v0.2.4](#coop-mobile-v024-improves-nostr-connect-and-adds-ncryptsec1-import) con mejoras en Nostr Connect e importación ncryptsec1, [Nmail v0.14.0](#nmail-v0140-ships-on-macos-with-scheduled-send-and-push-notifications) llegando a macOS con envío programado, [Nostrord v2.2.0](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages) con un interruptor maestro de DM, [Nostr WoT 0.3.86](#nostr-wot-0386-hardens-key-backups-and-signing-prompts) endureciendo respaldos de claves al formato NIP-49, [Keep Android v1.1.8](#keep-android-v118-adds-first-run-frost-onboarding) con incorporación FROST de primer uso, [Noscall v0.6.0](#noscall-v060-adds-a-cashu-wallet-and-relay-based-push-notifications) con una billetera Cashu y notificaciones push basadas en relay, [Kubo](#kubo-ships-tablet-mode-and-group-chat-photos) con modo tableta y fotos en chats grupales, y [Nostr Codex Phone v0.2.9](#nostr-codex-phone-v029-adds-gitdiffread-file-helper-requests) con solicitudes auxiliares de git, diff y lectura de archivos. + +En el lado no publicado, [Amethyst](#amethyst-lets-accounts-nickname-contacts-with-encrypted-nip-85-cards) permite a las cuentas asignar apodos a contactos con tarjetas NIP-85 cifradas en 54 PRs fusionados, [Zap Cooking](#zap-cooking-ships-my-kitchen-phase-3-and-fixes-an-ndk-pool-quorum-bug) lanza la Fase 3 de My Kitchen y corrige un error de quórum del pool NDK, [Kehto](#kehto-streams-outbox-reads-before-relay-discovery) transmite lecturas de outbox antes de que termine el descubrimiento de relay, [Wired y TAO](#wired-and-tao-add-nip-57-creator-revenue-sharing) añaden reparto de ingresos de creador con NIP-57, [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) reconstruye su bandeja de pedidos del comerciante alrededor de pago efímero como invitado, [Buzz](#buzz-hardens-channel-creator-provisioning-around-kind-39002) endurece el aprovisionamiento del creador de canal en 240 PRs fusionados, y [Nostr Docs](#nostr-docs-adopts-a-nip-49-signer-with-multi-account-and-qr-pairing) adopta un firmante NIP-49 con múltiples cuentas y emparejamiento QR. Recién rastreados esta semana: [OpenDiscord v1.0.1](#opendiscord-v101-launches-as-a-discord-style-client-on-nostr), [Auditable Voting v0.1.140](#auditable-voting-v01140-aligns-organiser-voter-and-audit-proxy-roles), y la selección Discovery [Cambium v0.3.2](#cambium-v032-pairs-with-heartwood-as-a-keyless-nip-55-signer), un firmante NIP-55 sin claves que redirige a un compañero de hardware Heartwood. + +El repositorio de NIPs no fusiona nada en la última semana y abre seis propuestas: [kind:10011 conjuntos de seguimiento favoritos](#open-kind10011-favorite-follow-sets), una [unidad cifrada privada que extiende NIP-4E](#open-private-encrypted-drive-extends-nip-4e), [NIP-DA compartición privada de datos con permisos](#open-nip-da-permissioned-private-data-sharing), [kinds de paquetes de stickers 10031 y 30031](#open-sticker-pack-kinds-10031-and-30031), [fijación de mensajes NIP-29](#open-nip-29-message-pinning-with-kind9010-and-kind39005), y una [reestructuración del descubrimiento de relay NIP-66](#open-nip-66-relay-discovery-restructure). El Deep Dive cubre [NIP-99 y la extensión de comercio Gamma Markets](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension). + +--- + +## Historias principales + +### Vector v0.4.0 mueve los Chats Grupales de Marmot a Concord, y Amethyst lanza su propio cliente Concord días después + +[Vector](https://github.com/VectorPrivacy/Vector) es un mensajero Nostr construido alrededor de un cliente de binario único enfocado en privacidad para DMs y chats grupales. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) reescribe el motor de mensajería de la aplicación en una biblioteca compartida `vector-core` y, en el mismo lanzamiento, retira [Marmot](/es/topics/marmot/) (MLS-sobre-Nostr) como transporte predeterminado para Chats Grupales a favor de [Concord](/es/topics/concord-protocol/), un protocolo de comunidad cifrado de extremo a extremo; el historial existente de grupos Marmot no se transfiere, y las notas del lanzamiento indican a los usuarios respaldar cualquier dato de grupo Marmot antes de actualizar. Las propias notas de lanzamiento de Vector describen Concord como "nuestro protocolo de mensajería personalizado", pero las [especificaciones CORD-01 a CORD-07](https://github.com/concord-protocol/concord) subyacentes se publican por separado, con licencia MIT, y ya están implementadas fuera de Vector: el cliente estilo Discord de Soapbox, [Armada](https://gitlab.com/soapbox-pub/armada), construye su función de Comunidades sobre la misma especificación Concord, y un día después, [Amethyst fusionó su propia implementación limpia y compatible a nivel de protocolo](https://github.com/vitorpamplona/amethyst/pull/3566), cubierta en detalle a continuación. El mismo lanzamiento de Vector añade enrutamiento opcional por Tor para todo el tráfico, inicio de sesión con firmante remoto [NIP-46](/es/topics/nip-46/) por QR o URI bunker pegada, múltiples cuentas con un conmutador dentro de la aplicación, y paquetes de emojis personalizados compartidos entre clientes. La eliminación de mensajes remueve un mensaje para ambos lados en DMs y chats grupales, y Vector deliberadamente mantiene la clave de firma efímera en lugar de seguir el flujo estándar de eliminación [NIP-17](/es/topics/nip-17/), una desviación motivada por privacidad que el proyecto señala explícitamente en las notas del lanzamiento. Cuatro días después, [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) lanza **Concord v2**, descrito como una versión con mejoras importantes de privacidad y estabilidad para Comunidades manteniendo las existentes funcionando, junto con un selector de comandos con barra estilo Discord para bots con parámetros tipados, un temporizador de autodestrucción por chat, y un sistema de badges NIP-58 para cazadores de errores. El alejamiento de Marmot para chat grupal ocurre la misma semana en que [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) a continuación continúa invirtiendo en la especificación. + +### Amethyst lanza una implementación limpia de Concord para comunidades cifradas de extremo a extremo + +[Amethyst](https://github.com/vitorpamplona/amethyst) es un cliente Nostr rico en funciones para Android y multiplataforma. [PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) añade una implementación completa de [Concord](/es/topics/concord-protocol/) (CORD-01 a CORD-07) cubriendo comunidades sin servidor y cifradas de extremo a extremo: planos de control, chat e invitados envueltos con gift-wrap, sobre relay ordinarios, con cumplimiento de roles, expulsiones y baneos enraizados en el propietario que cada cliente verifica localmente en lugar de confiar en un servidor, y re-cifrado para cortar acceso a miembros eliminados. El código de protocolo y criptografía reside en `quartz/`, los modelos de estado y vista en `commons/`, y las pantallas y navegación en `amethyst/` para Android, con verbos CLI delgados bajo `cli/`; todavía no hay interfaz de escritorio, ya que la lógica compartida reside en `quartz`/`commons` para que Desktop la adopte después. La implementación es de sala limpia: construida a partir de las especificaciones CORD públicas y constantes de protocolo observadas, bajo la propia licencia MIT de Amethyst, distinta del código base AGPL-3.0 de Armada. Los valores de vectores de prueba propios de Armada fueron portados a las pruebas unitarias de Quartz para confirmar que ambos clientes realmente interoperan a nivel de protocolo, dando a Concord tres implementaciones independientes en días: Vector lanzando primero, Armada como cliente de referencia de Soapbox, y ahora la construcción desde la especificación de Amethyst. + +### Sonar se separa de Bitchat con una alpha multiplataforma y una especificación de paquetes de stickers + +[Sonar](https://sonarprivacy.xyz/) es un mensajero y billetera con malla Bluetooth más Nostr desarrollado a partir de Bitchat, con DMs grupales Marmot interoperables con White Noise. El código vive en [hedwig-corp/bitchat-to-sonar](https://github.com/hedwig-corp/bitchat-to-sonar). [v0.1-alpha.7](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.7) añade ventaneo acotado de transcripción estilo Signal para que el rendimiento de apertura y desplazamiento se mantenga local-first, sincroniza el estado de descubrimiento cercano entre pares, y corrige subidas de medios Blossom que fallaban por manejo de content-type y estado HTTP; la precedente [alpha.6](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.6) drenó eventos Marmot en vivo para una actualización más rápida del chat y cerró brechas de paridad de funciones entre Android e iOS en llamadas, mensajería, billetera y push. Sonar también es la fuente de especificación citada para [PR #2410](#open-sticker-pack-kinds-10031-and-30031), que registra kinds de eventos de paquetes de stickers bajo la propia especificación "Sonar Stickers" del proyecto, dando a este lanzamiento un enlace directo al trabajo de protocolo de esta semana. + +### Divine Mobile 1.0.16 incorpora un editor de video más profundo, cifrado en reposo y procedencia ProofMode + +[Divine](https://github.com/divinevideo/divine-mobile) es un cliente de videos cortos construido sobre Nostr con curación de feed por Web-of-Trust. [v1.0.16](https://github.com/divinevideo/divine-mobile/releases/tag/1.0.16), el primer lanzamiento etiquetado desde el #30, añade transiciones de clips, reproducción inversa, un grabador de voz en off y marcadores de ritmo en la línea de tiempo al editor de video, junto con un control de ajuste de feed que permite al usuario deslizar para ajustar recomendaciones directamente en lugar de dejarlas a señales opacas de interacción. El lanzamiento también activa el cifrado en reposo para datos locales, añade subidas en segundo plano que sobreviven a la suspensión de la aplicación, y lleva los datos de procedencia [ProofMode](/es/topics/proofmode/) al descargar un clip con marca de agua para que la atestación de creación humana no se pierda en tránsito. Divine también incluye nuevas protecciones para cuentas de menores de 16 años y expande la localización a 17 idiomas y 284 cadenas traducidas. + +### Bitchat v1.7.0 añade voz push-to-talk en vivo para DMs y la malla pública + +[Bitchat](https://github.com/permissionlesstech/bitchat) es una aplicación de chat con malla Bluetooth con una pasarela opcional hacia relay Nostr. [v1.7.0](https://github.com/permissionlesstech/bitchat/releases/tag/v1.7.0), lanzado la noche que se publicó el #30, añade voz push-to-talk en vivo en [PR #1403](https://github.com/permissionlesstech/bitchat/pull/1403) que transmite audio mientras el remitente mantiene presionado el botón y retrocede a una nota de voz si el flujo se interrumpe, más push-to-talk firmado en la malla pública en [PR #1406](https://github.com/permissionlesstech/bitchat/pull/1406) para que las ráfagas de voz en vivo en el canal compartido de la malla lleven autenticación del remitente. El lanzamiento también repara la rotación de peer-ID reenlazando el vínculo en un re-anuncio verificado, reconociendo al mismo par bajo su nuevo ID ([PR #1401](https://github.com/permissionlesstech/bitchat/pull/1401)), y los mensajes directos a un par actualmente inalcanzable ahora se ponen en cola con entrega store-and-forward en lugar de fallar directamente ([PR #1415](https://github.com/permissionlesstech/bitchat/pull/1415)). Esto continúa directamente desde la cobertura del #30 del trabajo de [NIP-13](/es/topics/nip-13/) proof-of-work y pasarela mesh-a-Nostr de v1.6.0. + +### MDK v0.9.4 acota el inicio de sesión con firmante externo y añade persistencia de borradores + +[MDK](https://github.com/marmot-protocol/mdk) es el SDK de referencia para el protocolo [Marmot](/es/topics/marmot/), la capa de mensajería MLS-sobre-Nostr que el #30 cubrió marcando su especificación como adoptada. [v0.9.4](https://github.com/marmot-protocol/mdk/releases/tag/v0.9.4) acota los pasos de directorio consultivo que un cliente recorre durante el inicio de sesión con firmante externo en [PR #793](https://github.com/marmot-protocol/mdk/pull/793), previniendo un bucle de reintento sin límite cuando un firmante remoto es lento o no responde. El mismo lanzamiento añade persistencia de borradores de mensajes y enlaces de perfil a sitio web en [PR #812](https://github.com/marmot-protocol/mdk/pull/812), continuando el pase de endurecimiento incremental que MDK ha ejecutado desde el corte de v0.9.0. + +--- + +## Lanzamientos etiquetados + +### n_cord v1.1 añade soporte para NSEC Bunker + +[n_cord](https://github.com/0n4t3/n_cord) es un cliente de chat con tecnología Nostr inspirado en Discord e IRC. [v1.1](https://github.com/0n4t3/n_cord/releases/tag/v1.1) añade soporte para NSEC Bunker [NIP-46](/es/topics/nip-46/) junto con una corrección de error en el manejo de respuestas. + +### cdk v0.17.3 añade soporte de servicio de billetera NIP-47 en cdk, cdk-nwc y cdk-ffi + +[cdk](https://github.com/cashubtc/cdk) es un kit de desarrollo de Cashu; este lanzamiento es solo Bitcoin/Lightning en la mayoría de aspectos, pero [v0.17.3](https://github.com/cashubtc/cdk/releases/tag/v0.17.3) añade soporte de servicio [NIP-47](/es/topics/nip-47/) (Nostr Wallet Connect) con un crate de servicio NWC dedicado, integración de billetera, enlaces FFI para `cdk-ffi`, y cobertura de pruebas de extremo a extremo, dando a las billeteras Cashu construidas sobre cdk una superficie estándar de Nostr Wallet Connect. + +### Coop Mobile v0.2.4 mejora Nostr Connect y añade importación ncryptsec1 + +[Coop Mobile](https://git.reya.su/reya/coop-mobile) es un cliente de mensajería privada [NIP-17](/es/topics/nip-17/) para plataformas móviles. [v0.2.4](https://git.reya.su/reya/coop-mobile/releases/tag/v0.2.4) mejora su flujo de [NIP-46](/es/topics/nip-46/) Nostr Connect, corrige un indicador de carga que se quedaba permanentemente en algunas conexiones, y añade soporte de importación para el formato de clave cifrada [NIP-49](/es/topics/nip-49/) `ncryptsec1` junto con una pantalla de importación de identidad rediseñada. + +### Nmail v0.14.0 llega a macOS con envío programado y notificaciones push + +[Nmail](https://github.com/nogringo/nostr-mail-client) es un cliente de correo construido sobre Nostr; [v0.14.0](https://github.com/nogringo/nostr-mail-client/releases/tag/v0.14.0) lleva la aplicación a macOS, añade envío programado con un buzón de Programados dedicado para mensajes en cola, y añade notificaciones push. El lanzamiento también cambia la resolución de identificadores Nostr de la libreta de direcciones al resolutor [NIP-05](/es/topics/nip-05/) de NDK en lugar de una implementación propia. + +### Nostrord v2.2.0 añade un interruptor maestro de DM y mensajes directos más ricos + +[Nostrord](https://github.com/nostrord/nostrord) es un cliente de chat grupal basado en relay [NIP-29](/es/topics/nip-29/) para Android, iOS, web y escritorio. [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) añade un interruptor maestro para deshabilitar todas las funciones de mensajes directos a la vez ([PR #175](https://github.com/nostrord/nostrord/pull/175)) y lanza "mensajes directos más ricos" ([PR #186](https://github.com/nostrord/nostrord/pull/186)), continuando desde la cobertura del #30 sobre el lanzamiento que consolidó el pool de relay y detectó WebSockets zombi. + +### Nostr WoT 0.3.86 endurece los respaldos de claves y las solicitudes de firma + +[Nostr WoT](https://github.com/nostr-wot/nostr-wot-extension) es una extensión de navegador que vincula una identidad Nostr con una billetera Lightning. [v0.3.86](https://github.com/nostr-wot/nostr-wot-extension/releases/tag/v0.3.86) mueve los respaldos de claves cifradas al formato estándar [NIP-49](/es/topics/nip-49/), hace que las solicitudes de firma muestren el evento completo y todas las etiquetas en lugar de un resumen, verifica los datos del relay contra su firma, y deja de exponer la identidad activa al cambiar de cuenta. La extensión también elimina el permiso de navegador `scripting` no utilizado. + +### Keep Android v1.1.8 añade incorporación FROST de primer uso + +[Keep](https://github.com/privkeyio/keep-android) es un firmante Android construido sobre fragmentos de clave FROST de umbral. [v1.1.8](https://github.com/privkeyio/keep-android/releases/tag/v1.1.8) añade un flujo de primer uso que explica los fragmentos de clave FROST y permite al nuevo usuario elegir una política de firma de Manual, Básica o Automática antes de que llegue la primera solicitud de firma, la primera incorporación del lado Android para el modelo de firma de umbral del crate keep-mobile subyacente. + +### Noscall v0.6.0 añade una billetera Cashu y notificaciones push basadas en relay + +[Noscall](https://github.com/sanah9/noscall) es una aplicación de llamadas de audio y video seguras construida sobre Nostr. [v0.6.0](https://github.com/sanah9/noscall/releases/tag/v0.6.0-release) añade una billetera Cashu con alcance de cuenta con saldos multi-mint, envío y recepción de ecash, y pago y recepción Lightning con persistencia de cotizaciones. El lanzamiento también migra las notificaciones push de Android de Firebase Cloud Messaging a una ruta de entrega basada en relay Nostr a través de UnifiedPush, y mejora la fiabilidad de VoIP de iOS y push APNs durante reintentos de inicio de sesión. + +### Kubo lanza modo tableta y fotos en chats grupales + +[Kubo](https://github.com/JeroenOnNostr/kubo) es una plataforma de video Nostr segura para niños con curación de feed por Web-of-Trust. [kubo-v2026.07.05](https://github.com/JeroenOnNostr/kubo/releases/tag/kubo-v2026.07.05) añade un diseño de cuadrícula para tableta opcional para el feed infantil y soporte para adjuntar fotos a mensajes de chat grupal, además de correcciones para el botón de registro que se ocultaba detrás del teclado en pantalla en Android. + +### Nostr Codex Phone v0.2.9 añade solicitudes auxiliares de git/diff/lectura de archivos + +[Nostr Codex Phone](https://github.com/tidley/nostr-codex-phone) es una superficie de control móvil para un trabajador de asistente de codificación local que se comunica a través de DMs cifrados de Nostr. [v0.2.9](https://github.com/tidley/nostr-codex-phone/releases/tag/v0.2.9) añade acciones de herramientas OpenCode móviles incluyendo solicitudes auxiliares de git, diff, lectura de archivos, estado e historial, mejoras de fijación y búsqueda de sesión, y un control de detención de tareas, junto con un envoltorio de subida cifrada a [Blossom](/es/topics/blossom/) que se lanzó en la v0.2.8 anterior. + +### GitWorkshop v3.0.3 corrige refs recién anunciadas en el explorador de repositorios, y lanza su primera compilación para Android + +[GitWorkshop](https://github.com/DanConwayDev/gitworkshop) es una interfaz web git-sobre-Nostr para explorar y revisar repositorios NIP-34. [v3.0.3](https://github.com/DanConwayDev/gitworkshop/releases/tag/v3.0.3) corrige las vistas de ramas, etiquetas, commits y exploración de código que fallaban al resolver una ref que un repositorio anuncia después de que el explorador ya la ha cargado, junto con limpieza de tiempos de flujo de CI, confirmado directamente contra la etiqueta y el historial de commits. La misma semana, GitWorkshop publicó su primera compilación nativa para Android en [Zapstore](https://zapstore.dev), comenzando en v3.0.0 y alcanzando v3.0.3 en horas; la interfaz web sigue siendo la interfaz principal, y el paquete Android trae la misma exploración de repositorios NIP-34 a un teléfono por primera vez. + +### Bitcoin-Safe llega a Flathub, destacando su plugin Nostr Sync & Chat + +[Bitcoin-Safe](https://bitcoin-safe.org) es una billetera Bitcoin de autocustodia construida alrededor de flujos de trabajo con firmantes de hardware. El proyecto [publicó un paquete en Flathub](https://flathub.org/apps/org.bitcoin_safe.BitcoinSafe) esta semana, su primera lista en una tienda de aplicaciones Linux convencional. El lanzamiento en Flathub pone el plugin Sync & Chat de Bitcoin-Safe frente a una audiencia más amplia: el plugin usa mensajes directos [NIP-17](/es/topics/nip-17/), a través de la propia biblioteca [bitcoin-nostr-chat](https://github.com/andreasgriffin/bitcoin-nostr-chat) del proyecto, para sincronizar etiquetas de billetera entre los dispositivos de un usuario y para enviar y recibir PSBTs para co-firma multisig remota entre participantes de confianza. La capa Nostr en sí se lanzó antes, en [2.0.0](https://github.com/andreasgriffin/bitcoin-safe/releases/tag/2.0.0) (2026-06-29), que rediseñó la firma de transacciones alrededor de un tipo de conexión "Compartir via Chat & Sync" junto con QR, USB y Bluetooth. La noticia de esta semana es el empaquetado en Flathub que pone esa función existente frente a una audiencia Linux convencional por primera vez. + +--- + +## Cambios no publicados + +### Amethyst permite a las cuentas asignar apodos a contactos con tarjetas NIP-85 cifradas + +Más allá de la [implementación de Concord](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) cubierta anteriormente, Amethyst fusionó 54 otros PRs en la última semana. El principal entre ellos es [PR #3548](https://github.com/vitorpamplona/amethyst/pull/3548), que permite a una cuenta asignar un apodo a cualquier otro usuario publicando su propia tarjeta de contacto kind 30382 [NIP-85](/es/topics/nip-85/) sobre ellos. El apodo, una nota privada, y cualquier mapeo personalizado de código corto de emoji [NIP-30](/es/topics/nip-30/) viven dentro del contenido cifrado con [NIP-44](/es/topics/nip-44/) de la tarjeta, de modo que solo la cuenta firmante puede leerlos, y las tarjetas se sincronizan a través del conjunto extendido de relay outbox de la cuenta al iniciar sesión e incrementalmente después. Los feeds, chats y menciones renderizan el apodo en lugar del nombre de visualización público, con una tarjeta de apodo accesible al tocar en la página de perfil encima del nombre real del usuario. + +### Zap Cooking lanza la Fase 3 de My Kitchen y corrige un error de quórum del pool NDK + +[Zap Cooking](https://github.com/zapcooking/frontend) es una aplicación de compartición de recetas y comunidad culinaria construida sobre Nostr. Fusionó 43 PRs continuando su función de planificación de comidas "My Kitchen", incorporando generación de listas de compras, un selector de recetas y una cuadrícula de planificación semanal en esta fase. El mismo conjunto de cambios corrige un error de quórum de preparación del pool de conexiones de [NDK](https://github.com/nostr-dev-kit/ndk) (Nostr Development Kit) que podía dejar lecturas de relay esperando más allá del punto en que un quórum de relay ya había respondido. + +### Kehto transmite lecturas de outbox antes del descubrimiento de relay + +[Kehto](https://github.com/kehto/web) es un runtime web temprano para applets Nostr [NIP-5D](/es/topics/nip-5d/), o "napplets". Fusionó 26 PRs. [PR #193](https://github.com/kehto/web/pull/193) corrige lecturas de outbox que anteriormente esperaban a que la carga de listas de relay [NIP-65](/es/topics/nip-65/) terminara antes de abrir cualquier relay, de modo que una carga de lista de relay que nunca se resolvía podía bloquear tanto la entrega de eventos como los tiempos de espera de consulta; la corrección abre hints de relay validados inmediatamente y transmite resultados mientras se descubren los relay de escritura. Un segundo cambio ([PR #196](https://github.com/kehto/web/pull/196)) alinea la página de auditoría de identidad del proyecto con NAP-SHELL, el contrato de ciclo de vida de la plataforma Napplet, parte del mismo trabajo de alineación de protocolo visible en otros lugares del lanzamiento `napplet/web` de esta semana. + +### Wired y TAO añaden reparto de ingresos de creador con NIP-57 + +[Wired](https://github.com/smolgrrr/Wired) y [TAO](https://github.com/smolgrrr/TAO) son clientes gemelos de redes sociales enfocados en libertad de expresión construidos sobre Nostr, compartiendo la misma lista de PRs; ambos fusionaron [PR #121](https://github.com/smolgrrr/Wired/pull/121), que implementa reparto de ingresos de creador [NIP-57](/es/topics/nip-57/) para que los zaps enviados a una publicación puedan dividirse automáticamente entre contribuyentes más allá del autor original. Esto continúa la cobertura del #30 del par elevando su señal de proof-of-work a 21 bits como trabajo no publicado. + +### Conduit Mono reconstruye la bandeja de pedidos del comerciante alrededor de pago efímero como invitado + +[Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) es un protocolo de mercado adyacente a las listas de clasificados [NIP-99](/es/topics/nip-99/). [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174) añade pago como invitado usando una clave efímera generada por el navegador: el invitado envía un pedido cifrado y un reporte de pago al comerciante usando esa clave de un solo uso, y el comerciante hace seguimiento fuera de banda por teléfono o correo, de modo que el comprador nunca necesita una identidad de bandeja de entrada durable. [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175) reconstruye la bandeja de pedidos del comerciante alrededor de un modelo único de estado de pedido compartido, separando roles de comprador y comerciante y requiriendo un código de seguimiento y transportista antes de que un pedido físico o mixto pueda pasar a enviado. El flujo de pago del proyecto se basa en mensajes privados [NIP-17](/es/topics/nip-17/), cifrado [NIP-44](/es/topics/nip-44/) y gift wrap [NIP-59](/es/topics/nip-59/). El [NIP Deep Dive](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) de esta semana cubre las convenciones de [Gamma Markets](/es/topics/gamma-markets/) hacia las que este mismo problema de estado de pedido apunta. + +### Buzz endurece el aprovisionamiento del creador de canal alrededor de kind 39002 + +[Buzz](https://github.com/block/buzz) es una plataforma de comunicación de mente colectiva que conecta agentes de IA y humanos sobre Nostr. Fusionó 240 PRs en la última semana, continuando su arco de endurecimiento de la capa de relay desde la cobertura del #30 sobre métricas de turno de agente kind 44200. La corrección de esta semana ([PR #1830](https://github.com/block/buzz/pull/1830)) trata al creador de un canal como miembro antes de que la lógica de aprovisionamiento de canal kind 39002 se ejecute, cerrando una condición de carrera donde el propio canal del creador podía rechazarlo durante la configuración. + +### Nostr Docs adopta un firmante NIP-49 con múltiples cuentas y emparejamiento QR + +[Nostr Docs](https://github.com/formstr-hq/nostr-docs) es una aplicación de documentos colaborativos nativa de Nostr. Fusionó 5 PRs, el notable ([PR #50](https://github.com/formstr-hq/nostr-docs/pull/50)) adoptando el paquete `@formstr/signer` para autenticación completa [NIP-49](/es/topics/nip-49/) con cambio de múltiples cuentas y emparejamiento QR, reemplazando una ruta de firma propia anterior. + +### También publicado + +Correcciones menores de interoperabilidad de firmantes y fiabilidad aterrizaron en varios proyectos rastreados en la última semana sin suficiente superficie nueva para sus propios párrafos: [ngit-cli](https://github.com/DanConwayDev/ngit-cli), un cliente de línea de comandos para una alternativa a GitHub basada en Nostr, lanza [v2.6.3](https://github.com/DanConwayDev/ngit-cli/releases/tag/v2.6.3) haciendo que `ngit init` dé orientación de configuración accionable en lugar de pedir repetidamente un nsec; [Manent](https://github.com/dtonon/manent), una aplicación privada de notas y archivos cifrados construida sobre Nostr, lanza [v1.4.1](https://github.com/dtonon/manent/releases/tag/v1.4.1) corrigiendo el inicio de sesión con firmante Android roto cuando Amber devuelve un pubkey hexadecimal y mejorando el desplazamiento del inicio de sesión bunker; [NoorNote](https://github.com/77elements/noornote), un cliente Nostr delgado y libre de servicios Google, lanza [v1.2.8](https://github.com/77elements/noornote/releases/tag/v1.2.8) corrigiendo notificaciones perdidas de grupos Nostrord y añadiendo un interruptor de alerta de publicación propia; [Bray](https://github.com/forgesworn/bray), un servidor MCP Nostr consciente de confianza para agentes de IA y humanos, lanza [v1.34.0](https://github.com/forgesworn/bray/releases/tag/v1.34.0) enviando metadatos de nombre de cliente en conexiones bunker [NIP-46](/es/topics/nip-46/); [Lumilumi](https://github.com/TsukemonoGit/lumilumi), un cliente web Nostr, cachea listas de relay [NIP-65](/es/topics/nip-65/) en almacenamiento local para respaldo sin conexión; [Earthly](https://github.com/moogmodular/earthly), una aplicación de ciudad y comunidad local basada en Nostr, añade búsqueda geográfica [NIP-50](/es/topics/nip-50/); y [lnbits](https://github.com/lnbits/lnbits), un sistema de billetera y cuentas Lightning gratuito y de código abierto, lanza [PR #3925](https://github.com/lnbits/lnbits/pull/3925) haciendo que `send_nostr_dm` publique de forma no bloqueante dentro de un lanzamiento por lo demás enfocado en Lightning. + +--- + +## Recién rastreados y descubiertos + +### OpenDiscord v1.0.1 se lanza como un cliente estilo Discord sobre Nostr + +[OpenDiscord](https://github.com/sofia-gros/open-discord) es un cliente de servidores y canales estilo Discord construido sobre Nostr con permisos basados en roles y lobbies de voz WebRTC/SFU. [v1.0.1](https://github.com/sofia-gros/open-discord/releases/tag/v1.0.1) es el primer lanzamiento con instalador etiquetado del proyecto. + +### Auditable Voting v0.1.140 alinea los roles de organizador, votante y proxy de auditoría + +[Auditable Voting](https://github.com/tidley/auditable-voting) es un shell de votación solo de cliente sobre Nostr. [v0.1.140](https://github.com/tidley/auditable-voting/releases/tag/v0.1.140) alinea los roles de organizador, votante y proxy de auditoría con el evento exacto de definición de cuestionario público firmado por el organizador, cerrando una brecha donde un proxy de auditoría podía actuar sobre cuentas generadas obsoletas o estado persistido de un trabajador u organizador diferente. + +### Cambium v0.3.2 se empareja con Heartwood como un firmante NIP-55 sin claves + +[Cambium](https://github.com/forgesworn/cambium) es la selección Discovery de este número: un firmante Android [NIP-55](/es/topics/nip-55/) que no guarda material de clave privada propio, redirigiendo cada solicitud de firma sobre [NIP-46](/es/topics/nip-46/) a un firmante de hardware Heartwood compañero. El proyecto comparte la organización de GitHub `forgesworn` con el proyecto rastreado Bray, y el propio Heartwood fue cubierto en el #30 lanzando el puente de firma relay-a-serial con el que ahora habla el lado Android de Cambium. [v0.3.2](https://github.com/forgesworn/cambium) pule la hoja de aprobación para advertir en vivo cuando la identidad seleccionada difiere del enlace existente de la aplicación y mueve las escrituras del registro de actividad a una única cola no bloqueante. + +### También lanzados esta semana: echoes, Dispatch y Linky + +Tres lanzamientos más merecen mención esta semana. [echoes](https://github.com/Lwb89dev/echoes) es una aplicación de notas offline-first y cifrada de extremo a extremo que se sincroniza privadamente sobre Nostr. [Dispatch](https://github.com/freecritter/dispatch) es un organizador de viajes local-first donde cada guardado se cifra con [NIP-44](/es/topics/nip-44/) y se respalda sobre Nostr bajo una clave dedicada y no vinculable, y su lanzamiento [v0.3.0](https://github.com/freecritter/dispatch) añade inicio de sesión Amber [NIP-55](/es/topics/nip-55/) para que la aplicación nunca toque la clave privada del usuario directamente. [Linky](https://github.com/hynek-jina/linky) combina contactos y DMs de Nostr con pagos Lightning y Cashu en una sola aplicación web progresiva. + +--- + +## Trabajo de protocolo y actualizaciones de NIP + +No se fusionaron PRs en el [repositorio de NIPs](https://github.com/nostr-protocol/nips) en la última semana. Se abrieron seis propuestas. + +### Abierta: kind:10011 conjuntos de seguimiento favoritos + +[PR #2413](https://github.com/nostr-protocol/nips/pull/2413), de fiatjaf, añade kind:10011 conjuntos de seguimiento favoritos. Refleja el patrón existente donde kind:10012 (conjuntos de relay favoritos) tiene etiquetas `a` apuntando a conjuntos de relay kind:30002, extendiendo el mismo mecanismo de favoritos a conjuntos de seguimiento kind:30000 para que un cliente pueda marcar una lista de seguimiento curada sin reemplazar su propia lista de contactos. + +### Abierta: unidad cifrada privada que extiende NIP-4E + +[PR #2412](https://github.com/nostr-protocol/nips/pull/2412), del equipo Form*, propone un evento genérico de Metadata, kind 34578, distinguido por una etiqueta de identificador `d` y una etiqueta de subtipo `t`, junto con un sistema de archivos cifrado privado construido encima que ya está implementado en el propio cliente Form* Drive, todavía experimental. Un registro de archivo es un evento de Metadata con `t=files`: los blobs de archivo viven en servidores [Blossom](/es/topics/blossom/) mientras que solo un índice cifrado reside en relay, y cada fragmento de archivo obtiene su propio par de claves efímero con cifrado [NIP-44](/es/topics/nip-44/) v2 derivado por HKDF. Un evento compañero de Clave de Cifrado Desacoplada guarda una clave simétrica por unidad contra la que se descifran los metadatos de cada archivo, y se basa explícitamente en [NIP-4E](/es/topics/nip-4e/), el borrador de abstracción de almacenamiento aún abierto de fiatjaf ([PR #1647](https://github.com/nostr-protocol/nips/pull/1647), abierto desde diciembre de 2024). + +Esa única clave por unidad significa que una clave filtrada expone los metadatos de cada archivo en la unidad, no solo uno, ya que los pares de claves efímeros por archivo solo varían la clave de cifrado de fragmento, no la clave de descifrado de metadatos; no existe todavía ninguna ruta de rotación o revocación más allá de publicar un nuevo evento de Metadata advirtiendo que eventos más antiguos pueden perderse. Una segunda propuesta más estrecha alcanza la misma idea subyacente de NIP-4E desde un ángulo diferente: [PR #2361](https://github.com/nostr-protocol/nips/pull/2361), de fiatjaf, desacopla claves de identidad y cifrado dentro de la mensajería [NIP-17](/es/topics/nip-17/) específicamente, abierto desde el 1 de junio. Ambos PRs están sin fusionar, dejando esto como una esquina activa y disputada del espacio de diseño. Form* dice que el cliente Drive es experimental con una actualización próxima. + +### Abierta: NIP-DA compartición privada de datos con permisos + +[PR #2411](https://github.com/nostr-protocol/nips/pull/2411), de JAFairweather, es un nuevo borrador NIP-DA para compartición privada de datos con permisos a través de concesiones de datos con alcance. Cada usuario mantiene un registro cifrado y autoritativo por alcance en relay, y el acceso se otorga entregando privadamente la clave simétrica de ese alcance dentro de un gift wrap [NIP-59](/es/topics/nip-59/), de modo que los relay almacenan solo texto cifrado y nunca saben quién otorgó acceso a quién; una revocación es simplemente una rotación de clave, sin necesidad de reescribir la copia de cada consumidor. El autor lo posiciona como distinto de los DMs [NIP-17](/es/topics/nip-17/) (que pueden llevar una instantánea de datos pero no actualizaciones en vivo ni revocación) y de las listas privadas NIP-51 (que no llevan material de clave), y cita dos implementaciones independientes, una biblioteca de referencia en JavaScript y un CLI en Go sobre go-nostr, probadas cruzadas contra relay.damus.io, nos.lol y relay.primal.net. + +### Abierta: kinds de paquetes de stickers 10031 y 30031 + +[PR #2410](https://github.com/nostr-protocol/nips/pull/2410), de vincenzopalazzo, registra kind 30031 (paquetes de stickers direccionables) y kind 10031 (la lista de paquetes de stickers de un usuario) en la tabla de Event Kinds, especificados por el formato "Sonar Stickers" que [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) lanza esta semana. Los kinds se sitúan deliberadamente un espacio por encima de los kinds de emoji personalizados [NIP-30](/es/topics/nip-30/) 30030 y 10030 para que un cliente no pueda confundir un paquete de stickers con un conjunto de emojis; los bytes de imagen de stickers viven en servidores HTTPS compatibles con [Blossom](/es/topics/blossom/), y las referencias de stickers enviados llevan un hash en texto plano para que un paquete direccionable editado no pueda cambiar silenciosamente la apariencia de stickers ya enviados en mensajes antiguos. Un PR compañero registra los mismos kinds en el proyecto separado `registry-of-kinds`. + +### Abierta: fijación de mensajes NIP-29 con kind:9010 y kind:39005 + +[PR #2379](https://github.com/nostr-protocol/nips/pull/2379), de Anderson-Juhasc, añade fijación de mensajes a grupos basados en relay [NIP-29](/es/topics/nip-29/): kind:9010 `update-pin-list` es un evento de moderación que lleva la lista completa de eventos fijados como etiquetas `e` en orden de visualización, de modo que un solo evento puede fijar, desfijar, reordenar o limpiar el conjunto fijado, y kind:39005 es un espejo generado por el relay que expone la última lista aceptada. El diseño reemplaza un enfoque anterior de pares agregar/eliminar de [PR #1163](https://github.com/nostr-protocol/nips/pull/1163) después de retroalimentación de revisión, y elige los números de kind 9010/39005 porque 9009 y 39003 han sido reclamados desde entonces por `create-invite` y roles de grupo. Anderson-Juhasc también mantiene [Nostrord](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages), cuyo [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) se lanza esta misma semana. + +### Abierta: reestructuración del descubrimiento de relay NIP-66 + +[PR #2241](https://github.com/nostr-protocol/nips/pull/2241), de VincenzoImp, es una reestructuración sustancial del descubrimiento de relay [NIP-66](/es/topics/nip-66/). Reemplaza la prosa suelta de "Otras etiquetas incluyen" con una sección estructurada de Etiquetas Indexadas, añade una etiqueta `W` que refleja el campo `attributes` de NIP-11 para filtrado de descubrimiento de relay, añade una etiqueta de etiqueta `l` usando espacios de nombres estandarizados (`ISO-639-1`, `ISO-3166-1`, `IANA-asn`, `IANA-tz`, `nip66.label.city`), y organiza etiquetas de RTT, SSL/TLS, red, geográficas, DNS y HTTP en secciones dedicadas junto con una nueva tabla de Tipos de Verificación. También corrige eventos de ejemplo rotos que tenían nombres de campo incorrectos, un `kind` faltante y nombres de tipo de verificación inválidos, y cierra el [issue #2171](https://github.com/nostr-protocol/nips/issues/2171). Todos los cambios mantienen compatibilidad hacia atrás ya que cada etiqueta añadida es opcional. + +--- + +## NIP Deep Dive: NIP-99 y la extensión de comercio Gamma Markets + +[NIP-15](/es/topics/nip-15/), la especificación original del Mercado Nostr, es heredada a estas alturas: modelaba un puesto de comerciante (kind 30017) con productos (kind 30018) archivados debajo, y los clientes que alguna vez corrieron sobre ella, Shopstr entre ellos, se han trasladado desde entonces a las listas de clasificados [NIP-99](/es/topics/nip-99/) como la especificación activa. NIP-99 en sí es un solo evento direccionable, kind 30402 para una lista activa o kind 30403 para un borrador, sin necesidad de crear un puesto primero. Deja todo más allá de la lista indefinido: costo de envío, estado del pedido, recibos, reseñas, y una forma de agrupar varias listas bajo una sola tienda, exactamente las partes de NIP-15 que nunca se transfirieron. [Gamma Markets](/es/topics/gamma-markets/) llena ese vacío, y es la capa de comercio moderna que vale la pena entender hoy. + +### El vacío que NIP-99 deja abierto + +El campo `content` de una lista NIP-99 lleva una descripción en Markdown, `price` y `location` están directamente en el evento, y las etiquetas `t` la hacen buscable como contenido ordinario de hashtag. Como es direccionable por la tupla pubkey, kind y etiqueta `d`, un vendedor edita una lista en su lugar publicando una nueva versión con la misma etiqueta `d`: + +```json +{ + "kind": 30402, + "content": "Vintage mechanical keyboard, Cherry MX Blue switches, barely used.", + "tags": [ + ["d", "keyboard-mx-blue-01"], + ["title", "Vintage Mechanical Keyboard"], + ["summary", "Cherry MX Blue, barely used"], + ["published_at", "1752537600"], + ["location", "NYC"], + ["price", "100", "USD"], + ["t", "electronics"] + ] +} +``` + +Esa es la especificación completa: un anuncio clasificado firmado y actualizable. Cada cliente que implementa NIP-99 para comercio electrónico real, más allá de un clasificado puntual, terminó inventando sus propias convenciones privadas para envío, mensajes de pedido y reseñas. Dos clientes NIP-99 podían renderizar correctamente una lista y aun así no tener una forma compartida de completar un pago entre ellos. + +### Gamma Markets: estandarizando lo que NIP-99 dejó fuera + +Gamma Markets es el nombre que un grupo de trabajo de desarrolladores de mercados Nostr, los equipos detrás de Shopstr, Cypher, Plebeian Market y Conduit Market, dieron a un conjunto compartido de convenciones de comercio electrónico construidas sobre el evento kind 30402 existente de NIP-99. La especificación está enlazada desde el documento canónico de NIP-99 a través de [PR #1784](https://github.com/nostr-protocol/nips/pull/1784) y se mantiene en su propio repositorio, [GammaMarkets/market-spec](https://github.com/GammaMarkets/market-spec). + +Gamma Markets añade dos kinds independientes adyacentes a las listas. Kind 30405 agrupa múltiples listas en una colección de productos, referenciando cada una con una etiqueta `a` explícita: + +```json +{ + "kind": 30405, + "content": "Summer sale picks", + "tags": [ + ["d", "summer-picks"], + ["title", "Summer Sale"], + ["a", "30402::keyboard-mx-blue-01"], + ["shipping_option", "30406::standard-regional"] + ] +} +``` + +Kind 30406 define una opción de envío con precios por país y reglas opcionales de costo basadas en peso o distancia: + +```json +{ + "kind": 30406, + "content": "Standard Regional Shipping", + "tags": [ + ["d", "standard-regional"], + ["title", "Standard Shipping"], + ["price", "5.99", "USD"], + ["country", "US"], + ["service", "standard"], + ["duration", "24", "72", "H"], + ["weight-max", "30", "kg"] + ] +} +``` + +La creación de pedidos, solicitudes de pago, actualizaciones de estado y envío, y recibos de pago viajan como mensajes privados ordinarios envueltos con gift-wrap [NIP-17](/es/topics/nip-17/), divididos en tres kinds por rol, no por re-envolver el transporte: kind 14 lleva comunicación libre entre comprador y comerciante, kind 16 lleva cada transición de estado del pedido (una etiqueta `type` de 1 a 4 marca creación de pedido, solicitud de pago, actualización de estado o actualización de envío), y kind 17 lleva el recibo de pago del comprador. Un mensaje de creación de pedido se ve así antes del gift-wrapping: + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +Calificar una compra completada es un kind direccionable separado, 31555, que apunta a la lista que reseña: + +```json +{ + "kind": 31555, + "content": "Arrived fast, exactly as described.", + "tags": [ + ["d", "a:30402::keyboard-mx-blue-01"], + ["rating", "1", "thumb"], + ["rating", "1.0", "quality"], + ["rating", "0.9", "delivery"] + ] +} +``` + +Llevar los mensajes de pedido sobre NIP-17 significa que un pago de Gamma Markets usa el mismo transporte de mensajes privados que los clientes ya tienen para DMs, en lugar de un kind de mensaje de pedido a medida. + +La decisión de diseño central de la especificación es que nada se hereda en cascada. Una lista que pertenece a una colección la referencia explícitamente con una etiqueta `a` en lugar de heredar automáticamente las opciones de envío o la descripción de la colección, y una opción de envío que una lista usa se referencia de la misma forma explícita. Esa es una reversión deliberada del modelo de puesto de NIP-15, donde un producto heredaba silenciosamente la moneda y la tabla de envío que su puesto padre definía. La compensación es más etiquetado explícito en cada lista, a cambio de que la configuración completa de una lista sea siempre legible desde el evento mismo, sin necesidad de resolver primero un objeto padre. + +### Dónde aparece esto en la práctica + +El trabajo de [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) de esta semana se sitúa en el mismo territorio de mensajes de pedido que Gamma Markets estandariza: el pago como invitado con clave efímera de [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174) y la reconstrucción de la bandeja de pedidos del comerciante de [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175) resuelven el problema de estado de pedido comprador/comerciante que los mensajes kind 14, 16 y 17 de Gamma Markets formalizan; Conduit Mono ejecuta su propio modelo de estado de pedido junto a esos kinds, sin adoptarlos directamente. Shopstr, uno de los cuatro proyectos que escribieron la especificación, también mantuvo su propia plomería de comercio en movimiento la última semana: [PR #568](https://github.com/shopstr-eng/shopstr/pull/568) extrae la lógica duplicada de gift-wrap NIP-17 en un módulo compartido, y [PR #567](https://github.com/shopstr-eng/shopstr/pull/567) lleva su parser de autenticación HTTP [NIP-98](/es/topics/nip-98/) a cobertura completa de pruebas, mantenimiento en exactamente las capas de mensajería y autenticación de las que un flujo de pedidos de Gamma Markets depende para llegar al comprador y comerciante de forma segura. + +NIP-15 perdió el rol de tienda al estandarizar un puesto y un producto, y luego dejó pagos, envío, reseñas y estado de pedido como problema de la aplicación. Gamma Markets llena la mayor parte de esa superficie faltante sin tocar la forma de lista única de NIP-99, construyendo sobre la pila de DM existente de Nostr, NIP-17, en lugar de inventar una nueva capa de mensajería. + +--- + +Eso es todo por esta semana. Si estás construyendo algo o tienes noticias para compartir, contáctanos via DM NIP-17 o encuéntranos en Nostr. diff --git a/content/es/topics/concord-protocol.md b/content/es/topics/concord-protocol.md new file mode 100644 index 0000000..75d79bf --- /dev/null +++ b/content/es/topics/concord-protocol.md @@ -0,0 +1,61 @@ +--- +title: "Concord Protocol" +date: 2026-07-15 +draft: false +translationOf: /en/topics/concord-protocol.md +translationDate: 2026-07-15 +categories: + - Protocol + - Messaging +--- + +Concord es un protocolo abierto con licencia MIT para comunidades y canales cifrados de extremo a extremo sobre Nostr, definido por las [especificaciones CORD-01 a CORD-07](https://github.com/concord-protocol/concord). [Vector](https://github.com/VectorPrivacy/Vector) lo adoptó como transporte predeterminado para su función de Chats Grupales a partir de v0.4.0, llamándolo "nuestro protocolo de mensajería personalizado" en sus propias notas de lanzamiento, pero la especificación se publica por separado de Vector y ya tiene implementaciones independientes. + +## Cómo funciona + +Concord divide lo que un servidor de comunidad estilo Discord normalmente hace en piezas que no necesitan confiar en nadie: los relay solo almacenan blobs cifrados dirigidos a etiquetas rotativas, poseer la clave de una sala es lo que convierte a alguien en miembro, y la autoridad sobre roles, expulsiones y baneos es un registro firmado enraizado en la identidad del propietario que cada cliente verifica localmente en lugar de confiar en un servidor para aplicarlo. Cada evento durable viaja en el mismo sobre de tres capas: un envoltorio kind 1059 firmado por la clave de flujo derivada del plano, conteniendo un sello firmado por la clave real del autor, conteniendo un rumor sin firma que lleva el evento funcional. Un rumor de mensaje de chat es un evento kind 9 simple: + +```json +{ + "kind": 9, + "pubkey": "", + "content": "Hey chat!", + "tags": [ + ["channel", ""], + ["epoch", "0"] + ] +} +``` + +El tráfico de control, chat e invitados cada uno obtiene su propio plano envuelto con gift-wrap [NIP-59](/es/topics/nip-59/), de modo que un relay que alberga los tres todavía no puede distinguir un mensaje de control de un mensaje de chat de una entrada de invitados sin la clave de la sala. La especificación se divide en siete documentos CORD: flujos privados (01), comunidades y membresía (02), canales (03), roles (04), invitaciones (05), re-cifrado y refundación para cortar acceso a miembros eliminados (06), y audio/video via un intermediario de tokens ciegos (07). La membresía en sí no tiene lista del lado del servidor: quien pueda descifrar el plano es un miembro, y eliminar a alguien de verdad significa rotar la comunidad a una nueva época de clave y entregarla solo a quienes quedan, en lugar de borrar una fila de una tabla. + +## Diferencias con Marmot + +Concord y [Marmot](/es/topics/marmot/) resuelven la mensajería grupal cifrada sobre Nostr con diferente criptografía para diferentes formas de grupo, y la propia comparación del proyecto Concord es explícita sobre la división: Marmot superpone [MLS](/es/topics/mls/) sobre Nostr para secreto hacia adelante y seguridad post-compromiso, usando paquetes de claves por dispositivo y commits ordenados que avanzan todo el grupo al unísono. Eso compra garantías fuertes, a un costo que escala con los cambios de membresía, bien adaptado a grupos pequeños y de alto riesgo donde las entradas y salidas son raras. Concord en cambio da a cada miembro la misma clave de sala y re-cifra toda la sala al eliminar en lugar de avanzar por commit, intercambiando algunas de las garantías criptográficas de MLS por un modelo que se mantiene económico a medida que una comunidad crece a cientos o miles de miembros casuales y de alta rotación, la forma que las comunidades estilo Discord realmente toman. + +## Por qué Vector cambió + +Las propias [notas de lanzamiento de Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) describen Concord solo como "nuestro protocolo de mensajería personalizado" para Chats Grupales, sin exponer el razonamiento directamente. El ajuste con la justificación publicada de Concord es claro de todos modos: los Chats Grupales en un cliente como Vector son exactamente el caso de membresía grande, abierta y cambiante donde el estado MLS por dispositivo de Marmot se convierte en la ruta más costosa, y el diseño asíncrono y plegable de Concord está construido para ese caso. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) retiró Marmot para Chats Grupales a favor de Concord, y el historial existente de grupos Marmot no se transfirió en el cambio. [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) lanzó "Concord v2" cuatro días después con mejoras de privacidad y estabilidad. Dentro de la misma semana, [Amethyst fusionó su propia implementación limpia y compatible a nivel de protocolo](https://github.com/vitorpamplona/amethyst/pull/3566), y el cliente estilo Discord de Soapbox, [Armada](https://gitlab.com/soapbox-pub/armada), ya construye su función de Comunidades sobre la misma especificación como implementación de referencia. Tres clientes independientes convergiendo en una especificación abierta en días es un camino rápido hacia interoperabilidad real entre clientes, vale la pena rastrear frente a cuántos del resto de los clientes de chat grupal de Nostr se mantienen en Marmot. + +## Implementaciones + +- [Vector](https://github.com/VectorPrivacy/Vector) - mensajero Nostr de binario único enfocado en privacidad; primer cliente Concord en producción, en v0.4.0 +- [Armada](https://gitlab.com/soapbox-pub/armada) (Soapbox) - cliente de comunidad estilo Discord; implementación de referencia, backend en el repositorio separado `armada-relay` +- [Amethyst](https://github.com/vitorpamplona/amethyst) - cliente Nostr rico en funciones para Android y multiplataforma; reimplementación de sala limpia compatible a nivel de protocolo con Armada ([PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566)) + +--- + +**Fuentes primarias:** +- [Especificaciones del protocolo Concord (CORD-01 a CORD-07)](https://github.com/concord-protocol/concord) +- [Notas de lanzamiento de Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) +- [Notas de lanzamiento de Vector v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) +- [Amethyst PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) + +**Mencionado en:** +- [Newsletter #31: Vector v0.4.0 mueve los Chats Grupales de Marmot a Concord, y Amethyst lanza su propio cliente Concord días después](/es/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) +- [Newsletter #31: Amethyst lanza una implementación limpia de Concord para comunidades cifradas de extremo a extremo](/es/newsletters/2026-07-15-newsletter/#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) + +**Ver también:** +- [Marmot Protocol](/es/topics/marmot/) +- [MLS (Message Layer Security)](/es/topics/mls/) +- [NIP-46: Nostr Connect](/es/topics/nip-46/) diff --git a/content/es/topics/gamma-markets.md b/content/es/topics/gamma-markets.md new file mode 100644 index 0000000..0eec282 --- /dev/null +++ b/content/es/topics/gamma-markets.md @@ -0,0 +1,69 @@ +--- +title: "Gamma Markets" +date: 2026-07-15 +draft: false +translationOf: /en/topics/gamma-markets.md +translationDate: 2026-07-15 +categories: + - Commerce + - Marketplace + - Protocol +--- + +Gamma Markets es un conjunto de convenciones de comercio electrónico construidas directamente sobre las listas de clasificados [NIP-99](/es/topics/nip-99/), desarrolladas colaborativamente por un grupo de trabajo de desarrolladores de mercados Nostr: los equipos detrás de Shopstr, Cypher, Plebeian Market y Conduit Market. Completa las convenciones de envío, flujo de pedidos, colecciones y reseñas que NIP-99 deja sin definir. + +## Cómo funciona + +Gamma Markets añade cinco kinds de eventos alrededor del evento de lista kind `30402` existente de NIP-99, sin cambiar la forma de ese evento: + +- **Kind 30405** - colecciones de productos, agrupando múltiples listas mediante etiquetas `a` +- **Kind 30406** - opciones de envío, con precios por país y reglas opcionales de costo basadas en peso o distancia +- **Kind 16** - mensajes de pedido: creación (type 1), solicitudes de pago (type 2), actualizaciones de estado (type 3) y actualizaciones de envío (type 4) +- **Kind 14** - comunicación general entre comprador y comerciante +- **Kind 17** - recibos de pago +- **Kind 31555** - reseñas de productos, dirigidas a un pubkey de vendedor y etiqueta `d` de lista específicos + +Las preferencias de pago de un comerciante se declaran mediante una etiqueta `payment_preference` en sus metadatos de perfil kind `0`, y los clientes descubren aplicaciones compatibles a través de recomendaciones de aplicaciones [NIP-89](/es/topics/nip-89/). La comunicación de pedidos se construye sobre mensajes privados [NIP-17](/es/topics/nip-17/), sin un esquema de cifrado nuevo propio. + +La decisión de diseño definitoria de la especificación es que nada se hereda en cascada: una lista que pertenece a una colección, o que usa una opción de envío, la referencia explícitamente con una etiqueta `a` en lugar de heredar automáticamente la configuración de su padre. Esa es una desviación deliberada del modelo de puesto más antiguo de [NIP-15](/es/topics/nip-15/), donde un producto heredaba silenciosamente la moneda y la tabla de envío de su puesto. + +### Ejemplo: creación de pedido (kind 16, type 1) + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +## Por qué importa + +NIP-99 por sí solo estandariza únicamente la lista en sí, un anuncio clasificado firmado y direccionable. Antes de Gamma Markets, cada cliente que construía comercio electrónico real sobre NIP-99 inventaba sus propias convenciones privadas para envío, pago y reseñas, lo que significaba que dos clientes compatibles con NIP-99 podían renderizar correctamente una lista pero carecían de una forma compartida de completar un pedido entre ellos. Gamma Markets cierra esa brecha sin tocar el formato de lista de NIP-99, de modo que las listas NIP-99 existentes siguen siendo válidas sin modificación. + +## Implementaciones + +- [Shopstr](https://github.com/shopstr-eng/shopstr) - mercado Nostr, uno de los cuatro proyectos que escribieron la especificación +- [Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) - protocolo de mercado que construye su propio flujo de estado de pedidos y pago en el mismo espacio de diseño + +--- + +**Fuentes primarias:** +- [Repositorio de la especificación Gamma Markets](https://github.com/GammaMarkets/market-spec) +- [Extensión de caso de uso de comercio electrónico NIP-99, PR #1784](https://github.com/nostr-protocol/nips/pull/1784) - enlace fusionado desde el documento canónico de NIP-99 a la especificación de Gamma Markets + +**Mencionado en:** +- [Newsletter #31: NIP Deep Dive: NIP-99 y la extensión de comercio Gamma Markets](/es/newsletters/2026-07-15-newsletter/#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) + +**Ver también:** +- [NIP-99: Classified Listings](/es/topics/nip-99/) +- [NIP-15: Nostr Marketplace](/es/topics/nip-15/) +- [NIP-17: Private Direct Messages](/es/topics/nip-17/) diff --git a/content/es/topics/nip-4e.md b/content/es/topics/nip-4e.md new file mode 100644 index 0000000..92a609f --- /dev/null +++ b/content/es/topics/nip-4e.md @@ -0,0 +1,46 @@ +--- +title: "NIP-4E: Desacoplamiento del cifrado de la identidad" +date: 2026-07-15 +draft: false +translationOf: /en/topics/nip-4e.md +translationDate: 2026-07-15 +categories: + - NIP + - Protocol + - Encryption +--- + +NIP-4E es un borrador abierto, propuesto por fiatjaf, para compartir datos privados entre los propios dispositivos de un usuario sin que cada dispositivo tenga la clave de identidad principal de Nostr del usuario. No está fusionado y sigue siendo una propuesta `draft`/`optional`. + +## El problema que aborda + +Muchos NIPs existentes, incluyendo listas NIP-51 y billeteras Cashu NIP-60, cifran datos del usuario hacia sí mismo usando la clave de identidad para poder leerlos de vuelta en cualquier dispositivo. Eso falla cuando la clave de identidad no es directamente accesible, por ejemplo cuando un firmante remoto está protegido por fragmentos de umbral FROST, MuSig2 o un enclave seguro alojado, ya que cifrar y descifrar requiere entonces un viaje de ida y vuelta a ese firmante cada vez. También hace imposible el cifrado sin conexión cuando la clave de firma reside en un bunker remoto. + +## Cómo funciona + +NIP-4E separa una "clave de cliente" por dispositivo de una "clave de cifrado" compartida que no es la clave de identidad del usuario: + +1. El primer cliente que un usuario configura genera un par de claves de cifrado aleatorio y anuncia su mitad pública en un evento `kind:10044` firmado por la clave de identidad del usuario. +2. Cualquier otro cliente que quiera cifrar o descifrar datos para ese usuario calcula su secreto compartido Diffie-Hellman contra la clave de cifrado anunciada en lugar de la clave de identidad. +3. Cuando un segundo dispositivo instala un nuevo cliente, ese cliente genera su propia "clave de cliente" local y publica un anuncio `kind:4454` (también firmado por la clave de identidad del usuario) pidiendo al primer cliente que comparta la clave de cifrado con él. +4. El cliente original detecta el nuevo anuncio `kind:4454`, cifra la clave de cifrado compartida hacia la clave del nuevo cliente usando [NIP-44](/es/topics/nip-44/), y la publica para que el nuevo cliente pueda descifrarla y usarla en adelante. + +El resultado es que el cifrado y descifrado nunca requieren preguntar al firmante de clave de identidad una vez que un cliente tiene la clave de cifrado compartida localmente, y una configuración de firmante remoto (FROST, MuSig2, enclave alojado) puede usarse para identidad mientras el cifrado ordinario se mantiene rápido y funciona sin conexión. + +## Por qué importa + +NIP-4E se cita como la base para otras propuestas que necesitan una clave simétrica por unidad o por cuenta sin depender de un firmante remoto para cada llamada de cifrado/descifrado, incluyendo una propuesta de unidad cifrada privada ([PR #2412](https://github.com/nostr-protocol/nips/pull/2412)) y una versión más estrecha de la misma idea específica para NIP-17 ([PR #2361](https://github.com/nostr-protocol/nips/pull/2361)). Ambas permanecen abiertas junto con NIP-4E, haciendo de esto un área activa y sin resolver del protocolo en lugar de un bloque de construcción terminado. + +--- + +**Fuentes primarias:** +- [Borrador NIP-4E, PR #1647](https://github.com/nostr-protocol/nips/pull/1647) + +**Mencionado en:** +- [Newsletter #31: Abierta: unidad cifrada privada que extiende NIP-4E](/es/newsletters/2026-07-15-newsletter/#open-private-encrypted-drive-extends-nip-4e) + +**Ver también:** +- [NIP-44: Encrypted Payloads](/es/topics/nip-44/) +- [NIP-17: Private Direct Messages](/es/topics/nip-17/) +- [NIP-46: Nostr Connect](/es/topics/nip-46/) +- [FROST](/es/topics/frost/) diff --git a/content/es/topics/proofmode.md b/content/es/topics/proofmode.md new file mode 100644 index 0000000..49036d9 --- /dev/null +++ b/content/es/topics/proofmode.md @@ -0,0 +1,36 @@ +--- +title: "ProofMode" +date: 2026-07-15 +draft: false +translationOf: /en/topics/proofmode.md +translationDate: 2026-07-15 +categories: + - Media + - Provenance +--- + +[ProofMode](https://proofmode.org/) es un conjunto de herramientas de procedencia de medios de código abierto, construido por Guardian Project, WITNESS y Okthanks, que adjunta datos verificables de autenticidad y cadena de custodia a fotos y video en el momento de la captura. No es específico de Nostr; los clientes Nostr que llevan datos ProofMode están integrando un estándar externo existente en lugar de una nueva capa de protocolo. + +## Cómo funciona + +El componente Capture de ProofMode incrusta metadatos de procedencia directamente en archivos de medios durante la captura, soportando los mismos estándares interoperables utilizados por la Content Authenticity Initiative (CAI), Content Credentials (CR) y C2PA. Un componente Verify separado inspecciona archivos de audio, imagen y video para verificar esos metadatos en busca de señales de generación por IA o edición posterior, y un componente Preserve maneja almacenamiento redundante en la web descentralizada de los datos de prueba subyacentes para archivado a largo plazo. Un SDK Develop permite a las aplicaciones integrar captura y verificación sin construir el formato de procedencia por su cuenta. + +## Por qué importa + +Para un cliente Nostr de video o imagen, llevar datos ProofMode significa que un espectador tiene una forma externa y multiplataforma de verificar si un contenido multimedia fue capturado como se afirma y si ha sido alterado silenciosamente desde entonces, sin depender del cliente publicador o del relay como fuente de confianza. Esa distinción importa más para una copia descargada o recodificada de un clip: los datos de procedencia que sobreviven a la descarga y a cualquier marca de agua que aplique un cliente son lo que hace que la atestación siga siendo verificable después de que el archivo sale de la aplicación que lo produjo. + +## Implementaciones + +- [Divine](https://github.com/divinevideo/divine-mobile) - cliente de video corto Nostr; lleva datos de procedencia ProofMode a través de descargas de clips con marca de agua + +--- + +**Fuentes primarias:** +- [ProofMode](https://proofmode.org/) + +**Mencionado en:** +- [Newsletter #17](/es/newsletters/2026-04-29-newsletter/) +- [Newsletter #31: Divine Mobile 1.0.16 incorpora un editor de video más profundo, cifrado en reposo y procedencia ProofMode](/es/newsletters/2026-07-15-newsletter/#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) + +**Ver también:** +- [Blossom](/es/topics/blossom/) From dd54a3aa80d316a2bfacf7933b35ce2b8557c9b9 Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Wed, 15 Jul 2026 19:29:01 +0000 Subject: [PATCH 02/10] Add Portuguese translations for Newsletter #31 and topic pages Co-Authored-By: Claude Opus 4.6 --- .../pt/newsletters/2026-07-15-newsletter.md | 300 ++++++++++++++++++ content/pt/topics/concord-protocol.md | 61 ++++ content/pt/topics/gamma-markets.md | 69 ++++ content/pt/topics/nip-4e.md | 46 +++ content/pt/topics/proofmode.md | 36 +++ 5 files changed, 512 insertions(+) create mode 100644 content/pt/newsletters/2026-07-15-newsletter.md create mode 100644 content/pt/topics/concord-protocol.md create mode 100644 content/pt/topics/gamma-markets.md create mode 100644 content/pt/topics/nip-4e.md create mode 100644 content/pt/topics/proofmode.md diff --git a/content/pt/newsletters/2026-07-15-newsletter.md b/content/pt/newsletters/2026-07-15-newsletter.md new file mode 100644 index 0000000..3172b3c --- /dev/null +++ b/content/pt/newsletters/2026-07-15-newsletter.md @@ -0,0 +1,300 @@ +--- +title: "Nostr Compass #31" +date: 2026-07-15 +publishDate: 2026-07-15 +draft: false +type: newsletters +translationOf: /en/newsletters/2026-07-15-newsletter.md +translationDate: 2026-07-15 +description: "Vector v0.4.0 aposenta Marmot para chats em grupo em favor do protocolo aberto Concord e lança Concord v2 dias depois, Amethyst faz merge da sua própria implementação limpa de Concord, Sonar se separa do Bitchat com um alpha multiplataforma e uma especificação de pacotes de stickers, Divine Mobile 1.0.16 traz criptografia em repouso e procedência ProofMode, Bitchat 1.7.0 adiciona voz push-to-talk ao vivo, e MDK v0.9.4 limita o login com assinante externo." +--- + +Bem-vindos de volta ao Nostr Compass, seu guia semanal sobre Nostr. + +**Esta semana:** [Vector v0.4.0](#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) aposenta [Marmot](/pt/topics/marmot/) como transporte padrão para Chats em Grupo em favor de [Concord](/pt/topics/concord-protocol/), um protocolo de comunidade aberto com licença MIT também usado pelo Armada da Soapbox, e lança Concord v2 quatro dias depois com um seletor de comandos com barra para bots, um temporizador de autodestruição e badges NIP-58. [Amethyst faz merge da sua própria implementação limpa de Concord, compatível a nível de protocolo](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities), na mesma semana. [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) se separa do Bitchat com um alpha multiplataforma e é a fonte de especificação citada para a proposta de kinds de pacotes de stickers desta semana. [Divine Mobile 1.0.16](#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) traz um editor de vídeo mais profundo, criptografia em repouso e procedência ProofMode que sobrevive a downloads de clipes com marca d'água. [Bitchat v1.7.0](#bitchat-v170-adds-live-push-to-talk-voice-for-dms-and-the-public-mesh) adiciona voz push-to-talk ao vivo para DMs e push-to-talk assinado na malha pública. [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) limita o login com assinante externo e adiciona persistência de rascunhos, continuando seu passe de endurecimento na mesma semana em que Vector se afasta da especificação para chat em grupo. + +Os lançamentos etiquetados trazem [n_cord v1.1](#n_cord-v11-adds-nsec-bunker-support) adicionando suporte a NSEC Bunker, [cdk v0.17.3](#cdk-v0173-adds-nip-47-wallet-service-support-across-cdk-cdk-nwc-and-cdk-ffi) adicionando suporte de serviço de carteira NIP-47 em cdk, cdk-nwc e cdk-ffi, [Coop Mobile v0.2.4](#coop-mobile-v024-improves-nostr-connect-and-adds-ncryptsec1-import) melhorando Nostr Connect e adicionando importação ncryptsec1, [Nmail v0.14.0](#nmail-v0140-ships-on-macos-with-scheduled-send-and-push-notifications) chegando ao macOS com envio programado, [Nostrord v2.2.0](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages) adicionando um interruptor mestre de DM, [Nostr WoT 0.3.86](#nostr-wot-0386-hardens-key-backups-and-signing-prompts) endurecendo backups de chaves para o formato NIP-49, [Keep Android v1.1.8](#keep-android-v118-adds-first-run-frost-onboarding) adicionando onboarding FROST de primeiro uso, [Noscall v0.6.0](#noscall-v060-adds-a-cashu-wallet-and-relay-based-push-notifications) adicionando uma carteira Cashu e notificações push baseadas em relay, [Kubo](#kubo-ships-tablet-mode-and-group-chat-photos) adicionando modo tablet e fotos em chats de grupo, e [Nostr Codex Phone v0.2.9](#nostr-codex-phone-v029-adds-gitdiffread-file-helper-requests) adicionando requisições auxiliares de git, diff e leitura de arquivos. + +No lado não publicado, [Amethyst](#amethyst-lets-accounts-nickname-contacts-with-encrypted-nip-85-cards) permite que contas atribuam apelidos a contatos com cartões NIP-85 criptografados em 54 PRs mergeados, [Zap Cooking](#zap-cooking-ships-my-kitchen-phase-3-and-fixes-an-ndk-pool-quorum-bug) lança a Fase 3 do My Kitchen e corrige um bug de quórum do pool NDK, [Kehto](#kehto-streams-outbox-reads-before-relay-discovery) transmite leituras de outbox antes da descoberta de relay terminar, [Wired e TAO](#wired-and-tao-add-nip-57-creator-revenue-sharing) adicionam compartilhamento de receita de criador com NIP-57, [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) reconstrói sua caixa de entrada de pedidos do comerciante em torno de checkout efêmero como convidado, [Buzz](#buzz-hardens-channel-creator-provisioning-around-kind-39002) endurece o provisionamento do criador de canal em 240 PRs mergeados, e [Nostr Docs](#nostr-docs-adopts-a-nip-49-signer-with-multi-account-and-qr-pairing) adota um assinante NIP-49 com múltiplas contas e pareamento QR. Recém-rastreados esta semana: [OpenDiscord v1.0.1](#opendiscord-v101-launches-as-a-discord-style-client-on-nostr), [Auditable Voting v0.1.140](#auditable-voting-v01140-aligns-organiser-voter-and-audit-proxy-roles), e a seleção Discovery [Cambium v0.3.2](#cambium-v032-pairs-with-heartwood-as-a-keyless-nip-55-signer), um assinante NIP-55 sem chaves que redireciona para um companheiro de hardware Heartwood. + +O repositório de NIPs não faz merge de nada na última semana e abre seis propostas: [kind:10011 conjuntos de seguimento favoritos](#open-kind10011-favorite-follow-sets), um [drive criptografado privado que estende NIP-4E](#open-private-encrypted-drive-extends-nip-4e), [NIP-DA compartilhamento privado de dados com permissões](#open-nip-da-permissioned-private-data-sharing), [kinds de pacotes de stickers 10031 e 30031](#open-sticker-pack-kinds-10031-and-30031), [fixação de mensagens NIP-29](#open-nip-29-message-pinning-with-kind9010-and-kind39005), e uma [reestruturação da descoberta de relay NIP-66](#open-nip-66-relay-discovery-restructure). O Deep Dive cobre [NIP-99 e a extensão de comércio Gamma Markets](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension). + +--- + +## Matérias principais + +### Vector v0.4.0 move os Chats em Grupo de Marmot para Concord, e Amethyst lança seu próprio cliente Concord dias depois + +[Vector](https://github.com/VectorPrivacy/Vector) é um mensageiro Nostr construído em torno de um cliente de binário único focado em privacidade para DMs e chats em grupo. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) reescreve o motor de mensagens da aplicação em uma biblioteca compartilhada `vector-core` e, no mesmo lançamento, aposenta [Marmot](/pt/topics/marmot/) (MLS-sobre-Nostr) como transporte padrão para Chats em Grupo em favor de [Concord](/pt/topics/concord-protocol/), um protocolo de comunidade criptografado de ponta a ponta; o histórico existente de grupos Marmot não é transferido, e as notas de lançamento orientam os usuários a fazer backup de qualquer dado de grupo Marmot antes de atualizar. As próprias notas de lançamento do Vector descrevem Concord como "nosso protocolo de mensagens personalizado", mas as [especificações CORD-01 a CORD-07](https://github.com/concord-protocol/concord) subjacentes são publicadas separadamente, com licença MIT, e já estão implementadas fora do Vector: o cliente estilo Discord da Soapbox, [Armada](https://gitlab.com/soapbox-pub/armada), constrói sua funcionalidade de Comunidades sobre a mesma especificação Concord, e um dia depois, [Amethyst fez merge da sua própria implementação limpa e compatível a nível de protocolo](https://github.com/vitorpamplona/amethyst/pull/3566), coberta em detalhes abaixo. O mesmo lançamento do Vector adiciona roteamento opcional por Tor para todo o tráfego, login com assinante remoto [NIP-46](/pt/topics/nip-46/) por QR ou URI bunker colada, múltiplas contas com um alternador dentro do aplicativo, e pacotes de emojis personalizados compartilhados entre clientes. A exclusão de mensagens remove uma mensagem para ambos os lados em DMs e chats em grupo, e o Vector deliberadamente mantém a chave de assinatura efêmera em vez de seguir o fluxo padrão de exclusão [NIP-17](/pt/topics/nip-17/), um desvio motivado por privacidade que o projeto destaca explicitamente nas notas de lançamento. Quatro dias depois, [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) lança **Concord v2**, descrito como trazendo melhorias importantes de privacidade e estabilidade para Comunidades mantendo as existentes funcionando, junto com um seletor de comandos com barra estilo Discord para bots com parâmetros tipados, um temporizador de autodestruição por chat, e um sistema de badges NIP-58 para caçadores de bugs. O afastamento de Marmot para chat em grupo acontece na mesma semana em que [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) abaixo continua investindo na especificação. + +### Amethyst lança uma implementação limpa de Concord para comunidades criptografadas de ponta a ponta + +[Amethyst](https://github.com/vitorpamplona/amethyst) é um cliente Nostr rico em funcionalidades para Android e multiplataforma. [PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) adiciona uma implementação completa de [Concord](/pt/topics/concord-protocol/) (CORD-01 a CORD-07) cobrindo comunidades sem servidor e criptografadas de ponta a ponta: planos de controle, chat e livro de visitas envolvidos com gift-wrap sobre relay comuns, com aplicação de papéis, expulsões e banimentos enraizados no proprietário que cada cliente verifica localmente em vez de confiar em um servidor, e recriptografia para cortar o acesso de membros removidos. O código de protocolo e criptografia reside em `quartz/`, os modelos de estado e visualização em `commons/`, e as telas e navegação em `amethyst/` para Android, com verbos CLI enxutos em `cli/`; ainda não há interface desktop, já que a lógica compartilhada reside em `quartz`/`commons` para o Desktop adotar depois. A implementação é de sala limpa: construída a partir das especificações CORD públicas e constantes de protocolo observadas, sob a própria licença MIT do Amethyst, distinta do código base AGPL-3.0 do Armada. Os valores de vetores de teste do próprio Armada foram portados para os testes unitários do Quartz para confirmar que ambos os clientes realmente interoperam a nível de protocolo, dando ao Concord três implementações independentes em dias: Vector lançando primeiro, Armada como cliente de referência da Soapbox, e agora a construção a partir da especificação do Amethyst. + +### Sonar se separa do Bitchat com um alpha multiplataforma e uma especificação de pacotes de stickers + +[Sonar](https://sonarprivacy.xyz/) é um mensageiro e carteira com malha Bluetooth mais Nostr desenvolvido a partir do Bitchat, com DMs em grupo Marmot interoperáveis com White Noise. O código está em [hedwig-corp/bitchat-to-sonar](https://github.com/hedwig-corp/bitchat-to-sonar). [v0.1-alpha.7](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.7) adiciona janelamento de transcrição limitado estilo Signal para que o desempenho de abertura e rolagem permaneça local-first, sincroniza o estado de descoberta próxima entre pares, e corrige uploads de mídia Blossom que falhavam no tratamento de content-type e status HTTP; a precedente [alpha.6](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.6) drenou eventos Marmot ao vivo para atualização mais rápida do chat e fechou lacunas de paridade de funcionalidades entre Android e iOS em chamadas, mensagens, carteira e push. Sonar também é a fonte de especificação citada para [PR #2410](#open-sticker-pack-kinds-10031-and-30031), que registra kinds de eventos de pacotes de stickers sob a própria especificação "Sonar Stickers" do projeto, dando a este lançamento um link direto para o trabalho de protocolo desta semana. + +### Divine Mobile 1.0.16 traz um editor de vídeo mais profundo, criptografia em repouso e procedência ProofMode + +[Divine](https://github.com/divinevideo/divine-mobile) é um cliente de vídeos curtos construído sobre Nostr com curadoria de feed por Web-of-Trust. [v1.0.16](https://github.com/divinevideo/divine-mobile/releases/tag/1.0.16), o primeiro lançamento etiquetado desde o #30, adiciona transições de clipes, reprodução reversa, um gravador de narração e marcadores de ritmo na linha do tempo ao editor de vídeo, junto com um controle de ajuste de feed que permite ao usuário deslizar para ajustar recomendações diretamente em vez de deixá-las para sinais opacos de engajamento. O lançamento também ativa criptografia em repouso para dados locais, adiciona uploads em segundo plano que sobrevivem à suspensão do aplicativo, e carrega os dados de procedência [ProofMode](/pt/topics/proofmode/) ao baixar um clipe com marca d'água para que a atestação de criação humana permaneça intacta em trânsito. Divine também inclui novas proteções para contas de menores de 16 anos e expande a localização para 17 idiomas e 284 strings traduzidas. + +### Bitchat v1.7.0 adiciona voz push-to-talk ao vivo para DMs e a malha pública + +[Bitchat](https://github.com/permissionlesstech/bitchat) é um aplicativo de chat com malha Bluetooth com um gateway opcional para relay Nostr. [v1.7.0](https://github.com/permissionlesstech/bitchat/releases/tag/v1.7.0), lançado na noite em que o #30 foi publicado, adiciona voz push-to-talk ao vivo em [PR #1403](https://github.com/permissionlesstech/bitchat/pull/1403) que transmite áudio enquanto o remetente mantém o botão pressionado e volta para uma nota de voz se o stream cair, mais push-to-talk assinado na malha pública em [PR #1406](https://github.com/permissionlesstech/bitchat/pull/1406) para que rajadas de voz ao vivo no canal compartilhado da malha carreguem autenticação do remetente. O lançamento também repara a rotação de peer-ID religando o vínculo em um reanúncio verificado, reconhecendo o mesmo par sob seu novo ID ([PR #1401](https://github.com/permissionlesstech/bitchat/pull/1401)), e mensagens diretas para um par atualmente inalcançável agora entram em fila com entrega store-and-forward em vez de falhar diretamente ([PR #1415](https://github.com/permissionlesstech/bitchat/pull/1415)). Isso continua diretamente da cobertura do #30 sobre o trabalho de [NIP-13](/pt/topics/nip-13/) proof-of-work e gateway malha-para-Nostr do v1.6.0. + +### MDK v0.9.4 limita o login com assinante externo e adiciona persistência de rascunhos + +[MDK](https://github.com/marmot-protocol/mdk) é o SDK de referência para o protocolo [Marmot](/pt/topics/marmot/), a camada de mensagens MLS-sobre-Nostr que o #30 cobriu marcando sua especificação como adotada. [v0.9.4](https://github.com/marmot-protocol/mdk/releases/tag/v0.9.4) limita os passos de diretório consultivo que um cliente percorre durante o login com assinante externo em [PR #793](https://github.com/marmot-protocol/mdk/pull/793), prevenindo um loop de tentativas sem limite quando um assinante remoto é lento ou não responde. O mesmo lançamento adiciona persistência de rascunhos de mensagens e vinculações de perfil a website em [PR #812](https://github.com/marmot-protocol/mdk/pull/812), continuando o passe de endurecimento incremental que o MDK executou desde o corte do v0.9.0. + +--- + +## Lançamentos etiquetados + +### n_cord v1.1 adiciona suporte a NSEC Bunker + +[n_cord](https://github.com/0n4t3/n_cord) é um cliente de chat com tecnologia Nostr inspirado no Discord e IRC. [v1.1](https://github.com/0n4t3/n_cord/releases/tag/v1.1) adiciona suporte a NSEC Bunker [NIP-46](/pt/topics/nip-46/) junto com uma correção de bug no tratamento de respostas. + +### cdk v0.17.3 adiciona suporte de serviço de carteira NIP-47 em cdk, cdk-nwc e cdk-ffi + +[cdk](https://github.com/cashubtc/cdk) é um kit de desenvolvimento Cashu; este lançamento é apenas Bitcoin/Lightning na maioria dos aspectos, mas [v0.17.3](https://github.com/cashubtc/cdk/releases/tag/v0.17.3) adiciona suporte de serviço [NIP-47](/pt/topics/nip-47/) (Nostr Wallet Connect) com um crate de serviço NWC dedicado, integração de carteira, bindings FFI para `cdk-ffi`, e cobertura de testes de ponta a ponta, dando às carteiras Cashu construídas sobre cdk uma superfície padrão de Nostr Wallet Connect. + +### Coop Mobile v0.2.4 melhora Nostr Connect e adiciona importação ncryptsec1 + +[Coop Mobile](https://git.reya.su/reya/coop-mobile) é um cliente de mensagens privadas [NIP-17](/pt/topics/nip-17/) para plataformas móveis. [v0.2.4](https://git.reya.su/reya/coop-mobile/releases/tag/v0.2.4) melhora seu fluxo de [NIP-46](/pt/topics/nip-46/) Nostr Connect, corrige um indicador de carregamento que ficava permanentemente em algumas conexões, e adiciona suporte de importação para o formato de chave criptografada [NIP-49](/pt/topics/nip-49/) `ncryptsec1` junto com uma tela de importação de identidade redesenhada. + +### Nmail v0.14.0 chega ao macOS com envio programado e notificações push + +[Nmail](https://github.com/nogringo/nostr-mail-client) é um cliente de e-mail construído sobre Nostr; [v0.14.0](https://github.com/nogringo/nostr-mail-client/releases/tag/v0.14.0) leva o aplicativo ao macOS, adiciona envio programado com uma caixa de Programados dedicada para mensagens em fila, e adiciona notificações push. O lançamento também troca a resolução de identificadores Nostr da agenda de contatos para o resolvedor [NIP-05](/pt/topics/nip-05/) do NDK no lugar de uma implementação própria. + +### Nostrord v2.2.0 adiciona um interruptor mestre de DM e mensagens diretas mais ricas + +[Nostrord](https://github.com/nostrord/nostrord) é um cliente de chat em grupo baseado em relay [NIP-29](/pt/topics/nip-29/) para Android, iOS, web e desktop. [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) adiciona um interruptor mestre para desabilitar todas as funcionalidades de mensagens diretas de uma vez ([PR #175](https://github.com/nostrord/nostrord/pull/175)) e lança "mensagens diretas mais ricas" ([PR #186](https://github.com/nostrord/nostrord/pull/186)), continuando da cobertura do #30 sobre o lançamento que consolidou o pool de relay e detectou WebSockets zumbi. + +### Nostr WoT 0.3.86 endurece backups de chaves e prompts de assinatura + +[Nostr WoT](https://github.com/nostr-wot/nostr-wot-extension) é uma extensão de navegador que vincula uma identidade Nostr com uma carteira Lightning. [v0.3.86](https://github.com/nostr-wot/nostr-wot-extension/releases/tag/v0.3.86) move backups de chaves criptografadas para o formato padrão [NIP-49](/pt/topics/nip-49/), faz com que prompts de assinatura mostrem o evento completo e todas as tags em vez de um resumo, verifica dados do relay contra sua assinatura, e para de expor a identidade ativa ao trocar de conta. A extensão também remove a permissão de navegador `scripting` não utilizada. + +### Keep Android v1.1.8 adiciona onboarding FROST de primeiro uso + +[Keep](https://github.com/privkeyio/keep-android) é um assinante Android construído sobre fragmentos de chave FROST de limiar. [v1.1.8](https://github.com/privkeyio/keep-android/releases/tag/v1.1.8) adiciona um fluxo de primeiro uso que explica os fragmentos de chave FROST e permite que um novo usuário escolha uma política de assinatura Manual, Básica ou Automática antes que a primeira requisição de assinatura chegue, o primeiro onboarding do lado Android para o modelo de assinatura de limiar do crate keep-mobile subjacente. + +### Noscall v0.6.0 adiciona uma carteira Cashu e notificações push baseadas em relay + +[Noscall](https://github.com/sanah9/noscall) é um aplicativo de chamadas de áudio e vídeo seguras construído sobre Nostr. [v0.6.0](https://github.com/sanah9/noscall/releases/tag/v0.6.0-release) adiciona uma carteira Cashu com escopo de conta com saldos multi-mint, envio e recebimento de ecash, e pagamento e recebimento Lightning com persistência de cotações. O lançamento também migra as notificações push do Android do Firebase Cloud Messaging para um caminho de entrega baseado em relay Nostr através do UnifiedPush, e melhora a confiabilidade de VoIP iOS e push APNs durante tentativas de login. + +### Kubo lança modo tablet e fotos em chats de grupo + +[Kubo](https://github.com/JeroenOnNostr/kubo) é uma plataforma de vídeo Nostr segura para crianças com curadoria de feed por Web-of-Trust. [kubo-v2026.07.05](https://github.com/JeroenOnNostr/kubo/releases/tag/kubo-v2026.07.05) adiciona um layout de grade para tablet opcional para o feed infantil e suporte para anexar fotos a mensagens de chat em grupo, mais correções para o botão de cadastro que ficava escondido atrás do teclado virtual no Android. + +### Nostr Codex Phone v0.2.9 adiciona requisições auxiliares de git/diff/leitura de arquivos + +[Nostr Codex Phone](https://github.com/tidley/nostr-codex-phone) é uma superfície de controle móvel para um worker de assistente de codificação local que se comunica através de DMs criptografados de Nostr. [v0.2.9](https://github.com/tidley/nostr-codex-phone/releases/tag/v0.2.9) adiciona ações de ferramentas OpenCode móveis incluindo requisições auxiliares de git, diff, leitura de arquivos, status e histórico, melhorias de fixação e busca de sessão, e um controle de parada de tarefa, junto com um wrapper de upload criptografado para [Blossom](/pt/topics/blossom/) que foi lançado no v0.2.8 anterior. + +### GitWorkshop v3.0.3 corrige refs recém-anunciadas no explorador de repositórios, e lança sua primeira build para Android + +[GitWorkshop](https://github.com/DanConwayDev/gitworkshop) é uma interface web git-sobre-Nostr para explorar e revisar repositórios NIP-34. [v3.0.3](https://github.com/DanConwayDev/gitworkshop/releases/tag/v3.0.3) corrige as visualizações de branches, tags, commits e exploração de código que falhavam ao resolver uma ref que um repositório anuncia depois que o explorador já a carregou, junto com limpeza de timing de workflows CI, confirmado diretamente contra a tag e o histórico de commits. Na mesma semana, GitWorkshop publicou sua primeira build nativa para Android na [Zapstore](https://zapstore.dev), começando na v3.0.0 e alcançando v3.0.3 em horas; a interface web continua sendo a interface principal, e o pacote Android traz a mesma exploração de repositórios NIP-34 para um celular pela primeira vez. + +### Bitcoin-Safe chega ao Flathub, destacando seu plugin Nostr Sync & Chat + +[Bitcoin-Safe](https://bitcoin-safe.org) é uma carteira Bitcoin de autocustódia construída em torno de workflows com assinantes de hardware. O projeto [publicou um pacote no Flathub](https://flathub.org/apps/org.bitcoin_safe.BitcoinSafe) esta semana, sua primeira listagem em uma loja de aplicativos Linux convencional. O lançamento no Flathub coloca o plugin Sync & Chat do Bitcoin-Safe diante de uma audiência mais ampla: o plugin usa mensagens diretas [NIP-17](/pt/topics/nip-17/), através da própria biblioteca [bitcoin-nostr-chat](https://github.com/andreasgriffin/bitcoin-nostr-chat) do projeto, para sincronizar labels de carteira entre os dispositivos de um usuário e para enviar e receber PSBTs para coassinatura multisig remota entre participantes de confiança. A camada Nostr em si foi lançada antes, em [2.0.0](https://github.com/andreasgriffin/bitcoin-safe/releases/tag/2.0.0) (2026-06-29), que redesenhou a assinatura de transações em torno de um tipo de conexão "Compartilhar via Chat & Sync" junto com QR, USB e Bluetooth. A notícia desta semana é o empacotamento no Flathub colocando essa funcionalidade existente diante de uma audiência Linux convencional pela primeira vez. + +--- + +## Mudanças não publicadas + +### Amethyst permite que contas atribuam apelidos a contatos com cartões NIP-85 criptografados + +Além da [implementação de Concord](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) coberta acima, Amethyst fez merge de 54 outros PRs na última semana. O principal entre eles é [PR #3548](https://github.com/vitorpamplona/amethyst/pull/3548), que permite a uma conta atribuir um apelido a qualquer outro usuário publicando seu próprio cartão de contato kind 30382 [NIP-85](/pt/topics/nip-85/) sobre eles. O apelido, uma nota privada, e quaisquer mapeamentos personalizados de código curto de emoji [NIP-30](/pt/topics/nip-30/) ficam dentro do conteúdo criptografado com [NIP-44](/pt/topics/nip-44/) do cartão, de modo que apenas a conta signatária pode lê-los, e os cartões sincronizam através do conjunto estendido de relay outbox da conta no login e incrementalmente depois. Feeds, chats e menções renderizam o apelido no lugar do nome de exibição público, com um cartão de apelido acessível por toque na página de perfil acima do nome real do usuário. + +### Zap Cooking lança a Fase 3 do My Kitchen e corrige um bug de quórum do pool NDK + +[Zap Cooking](https://github.com/zapcooking/frontend) é um aplicativo de compartilhamento de receitas e comunidade culinária construído sobre Nostr. Fez merge de 43 PRs continuando sua funcionalidade de planejamento de refeições "My Kitchen", incorporando geração de lista de compras, um seletor de receitas e uma grade de planejamento semanal nesta fase. O mesmo conjunto de mudanças corrige um bug de quórum de prontidão do pool de conexões do [NDK](https://github.com/nostr-dev-kit/ndk) (Nostr Development Kit) que podia deixar leituras de relay esperando além do ponto em que um quórum de relay já havia respondido. + +### Kehto transmite leituras de outbox antes da descoberta de relay + +[Kehto](https://github.com/kehto/web) é um runtime web inicial para applets Nostr [NIP-5D](/pt/topics/nip-5d/), ou "napplets". Fez merge de 26 PRs. [PR #193](https://github.com/kehto/web/pull/193) corrige leituras de outbox que anteriormente esperavam o carregamento de listas de relay [NIP-65](/pt/topics/nip-65/) terminar antes de abrir qualquer relay, de modo que um carregamento de lista de relay que nunca se resolvesse podia bloquear tanto a entrega de eventos quanto os timeouts de consulta; a correção abre hints de relay validados imediatamente e transmite resultados enquanto relay de escrita são descobertos. Uma segunda mudança ([PR #196](https://github.com/kehto/web/pull/196)) alinha a página de auditoria de identidade do projeto com NAP-SHELL, o contrato de ciclo de vida da plataforma Napplet, parte do mesmo trabalho de alinhamento de protocolo visível em outros lugares do lançamento `napplet/web` desta semana. + +### Wired e TAO adicionam compartilhamento de receita de criador com NIP-57 + +[Wired](https://github.com/smolgrrr/Wired) e [TAO](https://github.com/smolgrrr/TAO) são clientes gêmeos de redes sociais focados em liberdade de expressão construídos sobre Nostr, compartilhando a mesma lista de PRs; ambos fizeram merge de [PR #121](https://github.com/smolgrrr/Wired/pull/121), que implementa compartilhamento de receita de criador [NIP-57](/pt/topics/nip-57/) para que zaps enviados a uma publicação possam ser divididos automaticamente para contribuidores além do autor original. Isso continua a cobertura do #30 do par elevando seu sinal de proof-of-work para 21 bits como trabalho não publicado. + +### Conduit Mono reconstrói a caixa de entrada de pedidos do comerciante em torno de checkout efêmero como convidado + +[Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) é um protocolo de marketplace adjacente às listas de classificados [NIP-99](/pt/topics/nip-99/). [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174) adiciona checkout como convidado usando uma chave efêmera gerada pelo navegador: o convidado envia um pedido criptografado e um relatório de pagamento ao comerciante usando essa chave de uso único, e o comerciante faz acompanhamento fora de banda por telefone ou e-mail, de modo que o comprador nunca precisa de uma identidade de caixa de entrada durável. [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175) reconstrói a caixa de entrada de pedidos do comerciante em torno de um modelo único de estado de pedido compartilhado, separando papéis de comprador e comerciante e exigindo um código de rastreamento e transportadora antes que um pedido físico ou misto possa passar para enviado. O fluxo de checkout do projeto se baseia em mensagens privadas [NIP-17](/pt/topics/nip-17/), criptografia [NIP-44](/pt/topics/nip-44/) e gift wrap [NIP-59](/pt/topics/nip-59/). O [NIP Deep Dive](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) desta semana cobre as convenções de [Gamma Markets](/pt/topics/gamma-markets/) para as quais este mesmo problema de estado de pedido aponta. + +### Buzz endurece o provisionamento do criador de canal em torno de kind 39002 + +[Buzz](https://github.com/block/buzz) é uma plataforma de comunicação de mente coletiva que conecta agentes de IA e humanos sobre Nostr. Fez merge de 240 PRs na última semana, continuando seu arco de endurecimento da camada de relay desde a cobertura do #30 sobre métricas de turno de agente kind 44200. A correção desta semana ([PR #1830](https://github.com/block/buzz/pull/1830)) trata o criador de um canal como membro antes da lógica de provisionamento de canal kind 39002 rodar, fechando uma condição de corrida onde o próprio canal do criador podia rejeitá-lo durante a configuração. + +### Nostr Docs adota um assinante NIP-49 com múltiplas contas e pareamento QR + +[Nostr Docs](https://github.com/formstr-hq/nostr-docs) é um aplicativo de documentos colaborativos nativo de Nostr. Fez merge de 5 PRs, o notável ([PR #50](https://github.com/formstr-hq/nostr-docs/pull/50)) adotando o pacote `@formstr/signer` para autenticação completa [NIP-49](/pt/topics/nip-49/) com troca de múltiplas contas e pareamento QR, substituindo um caminho de assinatura próprio anterior. + +### Também publicado + +Correções menores de interoperabilidade de assinantes e confiabilidade aterrissaram em vários projetos rastreados na última semana sem superfície nova suficiente para seus próprios parágrafos: [ngit-cli](https://github.com/DanConwayDev/ngit-cli), um cliente de linha de comando para uma alternativa ao GitHub baseada em Nostr, lança [v2.6.3](https://github.com/DanConwayDev/ngit-cli/releases/tag/v2.6.3) fazendo com que `ngit init` dê orientação de configuração acionável em vez de pedir repetidamente um nsec; [Manent](https://github.com/dtonon/manent), um aplicativo privado de notas e arquivos criptografados construído sobre Nostr, lança [v1.4.1](https://github.com/dtonon/manent/releases/tag/v1.4.1) corrigindo o login com assinante Android quebrado quando Amber retorna um pubkey hexadecimal e melhorando a rolagem do login bunker; [NoorNote](https://github.com/77elements/noornote), um cliente Nostr leve e livre de serviços Google, lança [v1.2.8](https://github.com/77elements/noornote/releases/tag/v1.2.8) corrigindo notificações perdidas de grupos Nostrord e adicionando um interruptor de alerta de publicação própria; [Bray](https://github.com/forgesworn/bray), um servidor MCP Nostr consciente de confiança para agentes de IA e humanos, lança [v1.34.0](https://github.com/forgesworn/bray/releases/tag/v1.34.0) enviando metadados de nome de cliente em conexões bunker [NIP-46](/pt/topics/nip-46/); [Lumilumi](https://github.com/TsukemonoGit/lumilumi), um cliente web Nostr, faz cache de listas de relay [NIP-65](/pt/topics/nip-65/) em armazenamento local para fallback offline; [Earthly](https://github.com/moogmodular/earthly), um aplicativo de cidade e comunidade local baseado em Nostr, adiciona busca geográfica [NIP-50](/pt/topics/nip-50/); e [lnbits](https://github.com/lnbits/lnbits), um sistema de carteira e contas Lightning gratuito e de código aberto, lança [PR #3925](https://github.com/lnbits/lnbits/pull/3925) fazendo com que `send_nostr_dm` publique de forma não bloqueante dentro de um lançamento focado em Lightning. + +--- + +## Recém-rastreados e descobertos + +### OpenDiscord v1.0.1 se lança como um cliente estilo Discord sobre Nostr + +[OpenDiscord](https://github.com/sofia-gros/open-discord) é um cliente de servidores e canais estilo Discord construído sobre Nostr com permissões baseadas em papéis e lobbies de voz WebRTC/SFU. [v1.0.1](https://github.com/sofia-gros/open-discord/releases/tag/v1.0.1) é o primeiro lançamento com instalador etiquetado do projeto. + +### Auditable Voting v0.1.140 alinha os papéis de organizador, votante e proxy de auditoria + +[Auditable Voting](https://github.com/tidley/auditable-voting) é um shell de votação apenas de cliente sobre Nostr. [v0.1.140](https://github.com/tidley/auditable-voting/releases/tag/v0.1.140) alinha os papéis de organizador, votante e proxy de auditoria com o evento exato de definição de questionário público assinado pelo organizador, fechando uma lacuna onde um proxy de auditoria podia agir sobre contas geradas obsoletas ou estado persistido de um worker ou organizador diferente. + +### Cambium v0.3.2 se pareia com Heartwood como um assinante NIP-55 sem chaves + +[Cambium](https://github.com/forgesworn/cambium) é a seleção Discovery desta edição: um assinante Android [NIP-55](/pt/topics/nip-55/) que não mantém material de chave privada próprio, redirecionando cada requisição de assinatura sobre [NIP-46](/pt/topics/nip-46/) para um assinante de hardware Heartwood companheiro. O projeto compartilha a organização GitHub `forgesworn` com o projeto rastreado Bray, e o próprio Heartwood foi coberto no #30 lançando a ponte de assinatura relay-para-serial com a qual o lado Android do Cambium agora se comunica. [v0.3.2](https://github.com/forgesworn/cambium) refina a folha de aprovação para alertar ao vivo quando a identidade selecionada difere do vínculo existente do aplicativo e move as escritas do log de atividade para uma única fila não bloqueante. + +### Também lançados esta semana: echoes, Dispatch e Linky + +Três lançamentos a mais merecem menção esta semana. [echoes](https://github.com/Lwb89dev/echoes) é um aplicativo de notas offline-first e criptografado de ponta a ponta que sincroniza privadamente sobre Nostr. [Dispatch](https://github.com/freecritter/dispatch) é um organizador de viagens local-first onde cada salvamento é criptografado com [NIP-44](/pt/topics/nip-44/) e respaldado sobre Nostr sob uma chave dedicada e não vinculável, e seu lançamento [v0.3.0](https://github.com/freecritter/dispatch) adiciona login Amber [NIP-55](/pt/topics/nip-55/) para que o aplicativo nunca toque a chave privada do usuário diretamente. [Linky](https://github.com/hynek-jina/linky) combina contatos e DMs de Nostr com pagamentos Lightning e Cashu em um único aplicativo web progressivo. + +--- + +## Trabalho de protocolo e atualizações de NIP + +Nenhum PR foi mergeado no [repositório de NIPs](https://github.com/nostr-protocol/nips) na última semana. Seis propostas foram abertas. + +### Aberta: kind:10011 conjuntos de seguimento favoritos + +[PR #2413](https://github.com/nostr-protocol/nips/pull/2413), de fiatjaf, adiciona kind:10011 conjuntos de seguimento favoritos. Espelha o padrão existente onde kind:10012 (conjuntos de relay favoritos) mantém tags `a` apontando para conjuntos de relay kind:30002, estendendo o mesmo mecanismo de favoritos para conjuntos de seguimento kind:30000 para que um cliente possa marcar uma lista de seguimento curada sem substituir sua própria lista de contatos. + +### Aberta: drive criptografado privado que estende NIP-4E + +[PR #2412](https://github.com/nostr-protocol/nips/pull/2412), da equipe Form*, propõe um evento genérico de Metadata, kind 34578, distinguido por uma tag de identificador `d` e uma tag de subtipo `t`, junto com um sistema de arquivos criptografado privado construído sobre ele que já está implementado no próprio cliente Form* Drive, ainda experimental. Um registro de arquivo é um evento de Metadata com `t=files`: os blobs de arquivo ficam em servidores [Blossom](/pt/topics/blossom/) enquanto apenas um índice criptografado reside em relay, e cada fragmento de arquivo recebe seu próprio par de chaves efêmero com criptografia [NIP-44](/pt/topics/nip-44/) v2 derivada por HKDF. Um evento companheiro de Chave de Criptografia Desacoplada mantém uma chave simétrica por drive contra a qual os metadados de cada arquivo são descriptografados, e se baseia explicitamente em [NIP-4E](/pt/topics/nip-4e/), o rascunho de abstração de armazenamento ainda aberto de fiatjaf ([PR #1647](https://github.com/nostr-protocol/nips/pull/1647), aberto desde dezembro de 2024). + +Essa única chave por drive significa que uma chave vazada expõe os metadados de cada arquivo no drive, já que os pares de chaves efêmeros por arquivo variam apenas a chave de criptografia de fragmento, e não a chave de descriptografia de metadados; nenhum caminho de rotação ou revogação existe ainda além de publicar um novo evento de Metadata alertando que eventos mais antigos podem ser perdidos. Uma segunda proposta mais estreita alcança a mesma ideia subjacente de NIP-4E por um ângulo diferente: [PR #2361](https://github.com/nostr-protocol/nips/pull/2361), de fiatjaf, desacopla chaves de identidade e criptografia dentro de mensagens [NIP-17](/pt/topics/nip-17/) especificamente, aberto desde 1 de junho. Ambos os PRs permanecem sem merge, deixando isso como um canto ativo e disputado do espaço de design. Form* diz que o cliente Drive é experimental com uma atualização em breve. + +### Aberta: NIP-DA compartilhamento privado de dados com permissões + +[PR #2411](https://github.com/nostr-protocol/nips/pull/2411), de JAFairweather, é um novo rascunho NIP-DA para compartilhamento privado de dados com permissões através de concessões de dados com escopo. Cada usuário mantém um registro criptografado e autoritativo por escopo em relay, e o acesso é concedido entregando privadamente a chave simétrica desse escopo dentro de um gift wrap [NIP-59](/pt/topics/nip-59/), de modo que relay armazenam apenas texto cifrado e nunca sabem quem concedeu acesso a quem; uma revogação é simplesmente uma rotação de chave, sem necessidade de reescrever a cópia de cada consumidor. O autor o posiciona como distinto dos DMs [NIP-17](/pt/topics/nip-17/) (que podem carregar um snapshot de dados mas não atualizações ao vivo ou revogação) e das listas privadas NIP-51 (que não carregam material de chave), e cita duas implementações independentes, uma biblioteca de referência em JavaScript e um CLI em Go sobre go-nostr, testadas cruzadas contra relay.damus.io, nos.lol e relay.primal.net. + +### Aberta: kinds de pacotes de stickers 10031 e 30031 + +[PR #2410](https://github.com/nostr-protocol/nips/pull/2410), de vincenzopalazzo, registra kind 30031 (pacotes de stickers endereçáveis) e kind 10031 (a lista de pacotes de stickers de um usuário) na tabela de Event Kinds, especificados pelo formato "Sonar Stickers" que [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) lança esta semana. Os kinds ficam deliberadamente um espaço acima dos kinds de emoji personalizados [NIP-30](/pt/topics/nip-30/) 30030 e 10030 para que um cliente não confunda um pacote de stickers com um conjunto de emojis; os bytes de imagem de stickers ficam em servidores HTTPS compatíveis com [Blossom](/pt/topics/blossom/), e as referências de stickers enviados carregam um hash em texto plano para que um pacote endereçável editado não mude silenciosamente a aparência de stickers já enviados em mensagens antigas. Um PR companheiro registra os mesmos kinds no projeto separado `registry-of-kinds`. + +### Aberta: fixação de mensagens NIP-29 com kind:9010 e kind:39005 + +[PR #2379](https://github.com/nostr-protocol/nips/pull/2379), de Anderson-Juhasc, adiciona fixação de mensagens a grupos baseados em relay [NIP-29](/pt/topics/nip-29/): kind:9010 `update-pin-list` é um evento de moderação que carrega a lista completa de eventos fixados como tags `e` em ordem de exibição, de modo que um único evento pode fixar, desfixar, reordenar ou limpar o conjunto fixado, e kind:39005 é um espelho gerado pelo relay que expõe a última lista aceita. O design substitui uma abordagem anterior de pares adicionar/remover de [PR #1163](https://github.com/nostr-protocol/nips/pull/1163) após feedback de revisão, e escolhe os números de kind 9010/39005 porque 9009 e 39003 foram reivindicados desde então por `create-invite` e papéis de grupo. Anderson-Juhasc também mantém [Nostrord](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages), cujo [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) é lançado nesta mesma semana. + +### Aberta: reestruturação da descoberta de relay NIP-66 + +[PR #2241](https://github.com/nostr-protocol/nips/pull/2241), de VincenzoImp, é uma reestruturação substancial da descoberta de relay [NIP-66](/pt/topics/nip-66/). Substitui a prosa solta de "Outras tags incluem" por uma seção estruturada de Tags Indexadas, adiciona uma tag `W` espelhando o campo `attributes` do NIP-11 para filtragem de descoberta de relay, adiciona uma tag de label `l` usando namespaces padronizados (`ISO-639-1`, `ISO-3166-1`, `IANA-asn`, `IANA-tz`, `nip66.label.city`), e organiza tags de RTT, SSL/TLS, rede, geográficas, DNS e HTTP em seções dedicadas junto com uma nova tabela de Tipos de Verificação. Também corrige eventos de exemplo quebrados que tinham nomes de campo incorretos, um `kind` faltante e nomes de tipo de verificação inválidos, e fecha o [issue #2171](https://github.com/nostr-protocol/nips/issues/2171). Todas as mudanças mantêm compatibilidade retroativa já que cada tag adicionada é opcional. + +--- + +## NIP Deep Dive: NIP-99 e a extensão de comércio Gamma Markets + +[NIP-15](/pt/topics/nip-15/), a especificação original do Marketplace Nostr, é legada neste ponto: modelava um estande de comerciante (kind 30017) com produtos (kind 30018) arquivados embaixo, e os clientes que antes rodavam sobre ela, Shopstr entre eles, migraram desde então para as listas de classificados [NIP-99](/pt/topics/nip-99/) como a especificação ativa. NIP-99 em si é um único evento endereçável, kind 30402 para uma lista ativa ou kind 30403 para um rascunho, sem estande para criar primeiro. Deixa tudo além da lista indefinido: custo de frete, status do pedido, recibos, avaliações, e uma forma de agrupar várias listas sob uma única loja, exatamente as partes de NIP-15 que nunca foram transferidas. [Gamma Markets](/pt/topics/gamma-markets/) preenche essa lacuna, e é a camada de comércio moderna que vale a pena entender hoje. + +### A lacuna que NIP-99 deixa aberta + +O campo `content` de uma lista NIP-99 carrega uma descrição em Markdown, `price` e `location` ficam diretamente no evento, e tags `t` a tornam pesquisável como conteúdo comum de hashtag. Como é endereçável pela tupla pubkey, kind e tag `d`, um vendedor edita uma lista no lugar publicando uma nova versão com a mesma tag `d`: + +```json +{ + "kind": 30402, + "content": "Vintage mechanical keyboard, Cherry MX Blue switches, barely used.", + "tags": [ + ["d", "keyboard-mx-blue-01"], + ["title", "Vintage Mechanical Keyboard"], + ["summary", "Cherry MX Blue, barely used"], + ["published_at", "1752537600"], + ["location", "NYC"], + ["price", "100", "USD"], + ["t", "electronics"] + ] +} +``` + +Essa é a especificação inteira: um anúncio classificado assinado e atualizável. Cada cliente que implementa NIP-99 para e-commerce real, além de um classificado avulso, acabou inventando suas próprias convenções privadas para frete, mensagens de pedido e avaliações. Dois clientes NIP-99 podiam renderizar corretamente uma lista e ainda assim não ter uma forma compartilhada de completar um checkout entre eles. + +### Gamma Markets: padronizando o que NIP-99 deixou de fora + +Gamma Markets é o nome que um grupo de trabalho de desenvolvedores de marketplaces Nostr, as equipes por trás de Shopstr, Cypher, Plebeian Market e Conduit Market, deram a um conjunto compartilhado de convenções de e-commerce construídas sobre o evento kind 30402 existente de NIP-99. A especificação está linkada no documento canônico de NIP-99 via [PR #1784](https://github.com/nostr-protocol/nips/pull/1784) e mantida em seu próprio repositório, [GammaMarkets/market-spec](https://github.com/GammaMarkets/market-spec). + +Gamma Markets adiciona dois kinds standalone adjacentes às listas. Kind 30405 agrupa múltiplas listas em uma coleção de produtos, referenciando cada uma por uma tag `a` explícita: + +```json +{ + "kind": 30405, + "content": "Summer sale picks", + "tags": [ + ["d", "summer-picks"], + ["title", "Summer Sale"], + ["a", "30402::keyboard-mx-blue-01"], + ["shipping_option", "30406::standard-regional"] + ] +} +``` + +Kind 30406 define uma opção de frete com preços por país e regras opcionais de custo baseadas em peso ou distância: + +```json +{ + "kind": 30406, + "content": "Standard Regional Shipping", + "tags": [ + ["d", "standard-regional"], + ["title", "Standard Shipping"], + ["price", "5.99", "USD"], + ["country", "US"], + ["service", "standard"], + ["duration", "24", "72", "H"], + ["weight-max", "30", "kg"] + ] +} +``` + +Criação de pedidos, requisições de pagamento, atualizações de status e frete, e recibos de pagamento viajam como mensagens privadas comuns envolvidas com gift-wrap [NIP-17](/pt/topics/nip-17/), divididas em três kinds por papel, e não por reenvolver o transporte: kind 14 carrega comunicação livre entre comprador e comerciante, kind 16 carrega cada transição de estado do pedido (uma tag `type` de 1 a 4 marca criação de pedido, requisição de pagamento, atualização de status ou atualização de frete), e kind 17 carrega o recibo de pagamento do comprador. Uma mensagem de criação de pedido se parece com isso antes do gift-wrapping: + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +Avaliar uma compra concluída é um kind endereçável separado, 31555, que aponta para a lista que avalia: + +```json +{ + "kind": 31555, + "content": "Arrived fast, exactly as described.", + "tags": [ + ["d", "a:30402::keyboard-mx-blue-01"], + ["rating", "1", "thumb"], + ["rating", "1.0", "quality"], + ["rating", "0.9", "delivery"] + ] +} +``` + +Transportar mensagens de pedido sobre NIP-17 significa que um checkout Gamma Markets usa o mesmo transporte de mensagens privadas que os clientes já têm para DMs, em vez de um kind de mensagem de pedido sob medida. + +A escolha de design central da especificação é que nada herda em cascata. Uma lista que pertence a uma coleção a referencia explicitamente com uma tag `a` em vez de herdar automaticamente as opções de frete ou a descrição da coleção, e uma opção de frete que uma lista usa é referenciada da mesma forma explícita. Essa é uma reversão deliberada do modelo de estande de NIP-15, onde um produto herdava silenciosamente a moeda e a tabela de frete que seu estande pai definia. A compensação é mais marcação explícita em cada lista, em troca da configuração completa de uma lista ser sempre legível a partir do próprio evento, sem objeto pai para resolver primeiro. + +### Onde isso aparece na prática + +O trabalho de [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) desta semana se situa no mesmo território de mensagens de pedido que Gamma Markets padroniza: o checkout como convidado com chave efêmera de [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174) e a reconstrução da caixa de entrada de pedidos do comerciante de [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175) ambos resolvem o problema de estado de pedido comprador/comerciante que as mensagens kind 14, 16 e 17 de Gamma Markets formalizam; Conduit Mono roda seu próprio modelo de estado de pedido ao lado desses kinds, sem adotá-los diretamente. Shopstr, um dos quatro projetos que escreveram a especificação, também manteve sua própria plumbing de comércio em movimento na última semana: [PR #568](https://github.com/shopstr-eng/shopstr/pull/568) extrai a lógica duplicada de gift-wrap NIP-17 em um módulo compartilhado, e [PR #567](https://github.com/shopstr-eng/shopstr/pull/567) leva seu parser de autenticação HTTP [NIP-98](/pt/topics/nip-98/) a cobertura completa de testes, manutenção em exatamente as camadas de mensagens e autenticação das quais um fluxo de pedidos Gamma Markets depende para alcançar o comprador e comerciante com segurança. + +NIP-15 perdeu o papel de vitrine ao padronizar um estande e um produto, e depois deixar pagamentos, frete, avaliações e status de pedido como problema do aplicativo. Gamma Markets preenche a maior parte dessa superfície faltante sem tocar a forma de lista única de NIP-99, construindo sobre a pilha de DM existente do Nostr, NIP-17, em vez de inventar uma nova camada de mensagens. + +--- + +Isso é tudo por esta semana. Se você está construindo algo ou tem notícias para compartilhar, entre em contato via DM NIP-17 ou nos encontre no Nostr. diff --git a/content/pt/topics/concord-protocol.md b/content/pt/topics/concord-protocol.md new file mode 100644 index 0000000..4942c97 --- /dev/null +++ b/content/pt/topics/concord-protocol.md @@ -0,0 +1,61 @@ +--- +title: "Concord Protocol" +date: 2026-07-15 +draft: false +translationOf: /en/topics/concord-protocol.md +translationDate: 2026-07-15 +categories: + - Protocol + - Messaging +--- + +Concord é um protocolo aberto com licença MIT para comunidades e canais criptografados de ponta a ponta sobre Nostr, definido pelas [especificações CORD-01 a CORD-07](https://github.com/concord-protocol/concord). [Vector](https://github.com/VectorPrivacy/Vector) o adotou como transporte padrão para sua funcionalidade de Chats em Grupo a partir da v0.4.0, chamando-o de "nosso protocolo de mensagens personalizado" em suas próprias notas de lançamento, mas a especificação é publicada separadamente do Vector e já tem implementações independentes. + +## Como funciona + +Concord divide o que um servidor de comunidade estilo Discord normalmente faz em peças que não precisam confiar em ninguém: relay apenas armazenam blobs criptografados endereçados a labels rotativos, possuir a chave de uma sala é o que torna alguém membro, e a autoridade sobre papéis, expulsões e banimentos é um registro assinado enraizado na identidade do proprietário que cada cliente verifica localmente em vez de confiar em um servidor para aplicá-lo. Cada evento durável viaja no mesmo envelope de três camadas: um wrapper kind 1059 assinado pela chave de stream derivada do plano, contendo um selo assinado pela chave real do autor, contendo um rumor sem assinatura que carrega o evento funcional. Um rumor de mensagem de chat é um evento kind 9 simples: + +```json +{ + "kind": 9, + "pubkey": "", + "content": "Hey chat!", + "tags": [ + ["channel", ""], + ["epoch", "0"] + ] +} +``` + +O tráfego de controle, chat e livro de visitas cada um recebe seu próprio plano envolvido com gift-wrap [NIP-59](/pt/topics/nip-59/), de modo que um relay que hospeda todos os três ainda não consegue distinguir uma mensagem de controle de uma mensagem de chat de uma entrada de livro de visitas sem a chave da sala. A especificação é dividida em sete documentos CORD: streams privados (01), comunidades e membros (02), canais (03), papéis (04), convites (05), recriptografia e refundação para cortar acesso de membros removidos (06), e áudio/vídeo via um intermediário de tokens cegos (07). A membresia em si não tem lista do lado do servidor: quem consegue descriptografar o plano é membro, e remover alguém de verdade significa rotacionar a comunidade para uma nova época de chave e entregá-la apenas a quem permanece, em vez de deletar uma linha de uma tabela. + +## Diferenças em relação ao Marmot + +Concord e [Marmot](/pt/topics/marmot/) resolvem mensagens em grupo criptografadas sobre Nostr com criptografia diferente para formas de grupo diferentes, e a própria comparação do projeto Concord é explícita sobre a divisão: Marmot superpõe [MLS](/pt/topics/mls/) sobre Nostr para sigilo futuro e segurança pós-compromisso, usando pacotes de chaves por dispositivo e commits ordenados que avançam todo o grupo em sincronia. Isso compra garantias fortes, a um custo que escala com mudanças de membresia, bem adequado a grupos pequenos e de alto risco onde entradas e saídas são raras. Concord em vez disso dá a cada membro a mesma chave de sala e recriptografa toda a sala na remoção em vez de avançar por commit, trocando algumas das garantias criptográficas do MLS por um modelo que permanece econômico à medida que uma comunidade cresce para centenas ou milhares de membros casuais e de alta rotatividade, a forma que comunidades estilo Discord realmente tomam. + +## Por que o Vector mudou + +As próprias [notas de lançamento do Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) descrevem Concord apenas como "nosso protocolo de mensagens personalizado" para Chats em Grupo, sem expor o raciocínio diretamente. O encaixe com a justificativa publicada do Concord é claro de qualquer forma: Chats em Grupo em um cliente como o Vector são exatamente o caso de membresia grande, aberta e frequentemente mutável onde o estado MLS por dispositivo do Marmot se torna o caminho mais caro, e o design assíncrono e dobrável do Concord é construído para esse caso. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) aposentou Marmot para Chats em Grupo em favor de Concord, e o histórico existente de grupos Marmot não foi transferido na mudança. [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) lançou "Concord v2" quatro dias depois com melhorias de privacidade e estabilidade. Na mesma semana, [Amethyst fez merge da sua própria implementação limpa e compatível a nível de protocolo](https://github.com/vitorpamplona/amethyst/pull/3566), e o cliente estilo Discord da Soapbox, [Armada](https://gitlab.com/soapbox-pub/armada), já constrói sua funcionalidade de Comunidades sobre a mesma especificação como implementação de referência. Três clientes independentes convergindo em uma especificação aberta em dias é um caminho rápido para interoperabilidade real entre clientes, vale rastrear contra quantos dos demais clientes de chat em grupo do Nostr permanecem no Marmot. + +## Implementações + +- [Vector](https://github.com/VectorPrivacy/Vector) - mensageiro Nostr de binário único focado em privacidade; primeiro cliente Concord em produção, na v0.4.0 +- [Armada](https://gitlab.com/soapbox-pub/armada) (Soapbox) - cliente de comunidade estilo Discord; implementação de referência, backend no repositório separado `armada-relay` +- [Amethyst](https://github.com/vitorpamplona/amethyst) - cliente Nostr rico em funcionalidades para Android e multiplataforma; reimplementação de sala limpa compatível a nível de protocolo com Armada ([PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566)) + +--- + +**Fontes primárias:** +- [Especificações do protocolo Concord (CORD-01 a CORD-07)](https://github.com/concord-protocol/concord) +- [Notas de lançamento do Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) +- [Notas de lançamento do Vector v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) +- [Amethyst PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) + +**Mencionado em:** +- [Newsletter #31: Vector v0.4.0 move os Chats em Grupo de Marmot para Concord, e Amethyst lança seu próprio cliente Concord dias depois](/pt/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) +- [Newsletter #31: Amethyst lança uma implementação limpa de Concord para comunidades criptografadas de ponta a ponta](/pt/newsletters/2026-07-15-newsletter/#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) + +**Veja também:** +- [Marmot Protocol](/pt/topics/marmot/) +- [MLS (Message Layer Security)](/pt/topics/mls/) +- [NIP-46: Nostr Connect](/pt/topics/nip-46/) diff --git a/content/pt/topics/gamma-markets.md b/content/pt/topics/gamma-markets.md new file mode 100644 index 0000000..50b76f7 --- /dev/null +++ b/content/pt/topics/gamma-markets.md @@ -0,0 +1,69 @@ +--- +title: "Gamma Markets" +date: 2026-07-15 +draft: false +translationOf: /en/topics/gamma-markets.md +translationDate: 2026-07-15 +categories: + - Commerce + - Marketplace + - Protocol +--- + +Gamma Markets é um conjunto de convenções de e-commerce construídas diretamente sobre as listas de classificados [NIP-99](/pt/topics/nip-99/), desenvolvidas colaborativamente por um grupo de trabalho de desenvolvedores de marketplaces Nostr: as equipes por trás de Shopstr, Cypher, Plebeian Market e Conduit Market. Preenche as convenções de frete, fluxo de pedidos, coleções e avaliações que NIP-99 deixa indefinidas. + +## Como funciona + +Gamma Markets adiciona cinco kinds de eventos em torno do evento de lista kind `30402` existente de NIP-99, sem alterar a forma desse evento: + +- **Kind 30405** - coleções de produtos, agrupando múltiplas listas via tags `a` +- **Kind 30406** - opções de frete, com preços por país e regras opcionais de custo baseadas em peso ou distância +- **Kind 16** - mensagens de pedido: criação (type 1), requisições de pagamento (type 2), atualizações de status (type 3) e atualizações de frete (type 4) +- **Kind 14** - comunicação geral entre comprador e comerciante +- **Kind 17** - recibos de pagamento +- **Kind 31555** - avaliações de produtos, endereçadas a um pubkey de vendedor e tag `d` de lista específicos + +As preferências de pagamento de um comerciante são declaradas via uma tag `payment_preference` em seus metadados de perfil kind `0`, e clientes descobrem aplicativos compatíveis através de recomendações de aplicativos [NIP-89](/pt/topics/nip-89/). A comunicação de pedidos se constrói sobre mensagens privadas [NIP-17](/pt/topics/nip-17/), sem um esquema de criptografia novo próprio. + +A escolha de design definitória da especificação é que nada herda em cascata: uma lista que pertence a uma coleção, ou que usa uma opção de frete, a referencia explicitamente com uma tag `a` em vez de herdar automaticamente a configuração de seu pai. Essa é uma divergência deliberada do modelo de estande mais antigo de [NIP-15](/pt/topics/nip-15/), onde um produto herdava silenciosamente a moeda e a tabela de frete de seu estande. + +### Exemplo: criação de pedido (kind 16, type 1) + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +## Por que importa + +NIP-99 sozinho padroniza apenas a lista em si, um anúncio classificado assinado e endereçável. Antes de Gamma Markets, cada cliente que construía e-commerce real sobre NIP-99 inventava suas próprias convenções privadas para frete, checkout e avaliações, o que significava que dois clientes compatíveis com NIP-99 podiam renderizar corretamente uma lista mas não tinham uma forma compartilhada de completar um pedido entre eles. Gamma Markets fecha essa lacuna sem tocar o formato de lista de NIP-99, de modo que listas NIP-99 existentes permanecem válidas sem modificação. + +## Implementações + +- [Shopstr](https://github.com/shopstr-eng/shopstr) - marketplace Nostr, um dos quatro projetos que escreveram a especificação +- [Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) - protocolo de marketplace construindo seu próprio fluxo de estado de pedidos e checkout no mesmo espaço de design + +--- + +**Fontes primárias:** +- [Repositório da especificação Gamma Markets](https://github.com/GammaMarkets/market-spec) +- [Extensão de caso de uso de e-commerce NIP-99, PR #1784](https://github.com/nostr-protocol/nips/pull/1784) - link mergeado no documento canônico de NIP-99 para a especificação Gamma Markets + +**Mencionado em:** +- [Newsletter #31: NIP Deep Dive: NIP-99 e a extensão de comércio Gamma Markets](/pt/newsletters/2026-07-15-newsletter/#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) + +**Veja também:** +- [NIP-99: Classified Listings](/pt/topics/nip-99/) +- [NIP-15: Nostr Marketplace](/pt/topics/nip-15/) +- [NIP-17: Private Direct Messages](/pt/topics/nip-17/) diff --git a/content/pt/topics/nip-4e.md b/content/pt/topics/nip-4e.md new file mode 100644 index 0000000..cdb483b --- /dev/null +++ b/content/pt/topics/nip-4e.md @@ -0,0 +1,46 @@ +--- +title: "NIP-4E: Desacoplamento da criptografia da identidade" +date: 2026-07-15 +draft: false +translationOf: /en/topics/nip-4e.md +translationDate: 2026-07-15 +categories: + - NIP + - Protocol + - Encryption +--- + +NIP-4E é um rascunho aberto, proposto por fiatjaf, para compartilhar dados privados entre os próprios dispositivos de um usuário sem que cada dispositivo precise ter a chave de identidade principal de Nostr do usuário. A proposta permanece sem merge e com status `draft`/`optional`. + +## O problema que aborda + +Muitos NIPs existentes, incluindo listas NIP-51 e carteiras Cashu NIP-60, criptografam dados do usuário para si mesmo usando a chave de identidade para poder lê-los de volta em qualquer dispositivo. Isso falha quando a chave de identidade não está diretamente acessível, por exemplo quando um assinante remoto está protegido por fragmentos de limiar FROST, MuSig2 ou um enclave seguro hospedado, já que criptografar e descriptografar requer então uma ida e volta a esse assinante toda vez. Também torna a criptografia offline impossível quando a chave de assinatura reside em um bunker remoto. + +## Como funciona + +NIP-4E separa uma "chave de cliente" por dispositivo de uma "chave de criptografia" compartilhada que não é a chave de identidade do usuário: + +1. O primeiro cliente que um usuário configura gera um par de chaves de criptografia aleatório e anuncia sua metade pública em um evento `kind:10044` assinado pela chave de identidade do usuário. +2. Qualquer outro cliente que queira criptografar ou descriptografar dados para esse usuário calcula seu segredo compartilhado Diffie-Hellman contra a chave de criptografia anunciada em vez da chave de identidade. +3. Quando um segundo dispositivo instala um novo cliente, esse cliente gera sua própria "chave de cliente" local e publica um anúncio `kind:4454` (também assinado pela chave de identidade do usuário) pedindo ao primeiro cliente que compartilhe a chave de criptografia com ele. +4. O cliente original detecta o novo anúncio `kind:4454`, criptografa a chave de criptografia compartilhada para a chave do novo cliente usando [NIP-44](/pt/topics/nip-44/), e a publica para que o novo cliente possa descriptografá-la e usá-la dali em diante. + +O resultado é que criptografia e descriptografia nunca requerem consultar o assinante de chave de identidade uma vez que um cliente tem a chave de criptografia compartilhada localmente, e uma configuração de assinante remoto (FROST, MuSig2, enclave hospedado) pode ser usada para identidade enquanto a criptografia comum permanece rápida e funciona offline. + +## Por que importa + +NIP-4E é citado como a base para outras propostas que precisam de uma chave simétrica por drive ou por conta sem depender de um assinante remoto para cada chamada de criptografia/descriptografia, incluindo uma proposta de drive criptografado privado ([PR #2412](https://github.com/nostr-protocol/nips/pull/2412)) e uma versão mais estreita da mesma ideia específica para NIP-17 ([PR #2361](https://github.com/nostr-protocol/nips/pull/2361)). Ambas permanecem abertas junto com NIP-4E, fazendo deste um área ativa e sem resolução do protocolo em vez de um bloco de construção finalizado. + +--- + +**Fontes primárias:** +- [Rascunho NIP-4E, PR #1647](https://github.com/nostr-protocol/nips/pull/1647) + +**Mencionado em:** +- [Newsletter #31: Aberta: drive criptografado privado que estende NIP-4E](/pt/newsletters/2026-07-15-newsletter/#open-private-encrypted-drive-extends-nip-4e) + +**Veja também:** +- [NIP-44: Encrypted Payloads](/pt/topics/nip-44/) +- [NIP-17: Private Direct Messages](/pt/topics/nip-17/) +- [NIP-46: Nostr Connect](/pt/topics/nip-46/) +- [FROST](/pt/topics/frost/) diff --git a/content/pt/topics/proofmode.md b/content/pt/topics/proofmode.md new file mode 100644 index 0000000..628be82 --- /dev/null +++ b/content/pt/topics/proofmode.md @@ -0,0 +1,36 @@ +--- +title: "ProofMode" +date: 2026-07-15 +translationOf: /en/topics/proofmode.md +translationDate: 2026-07-15 +draft: false +categories: + - Media + - Provenance +--- + +[ProofMode](https://proofmode.org/) é um kit de ferramentas de proveniência de mídia de código aberto, construído pelo Guardian Project, WITNESS e Okthanks, que anexa dados verificáveis de autenticidade e cadeia de custódia a fotos e vídeos no momento da captura. Não é específico do Nostr; clientes Nostr que carregam dados ProofMode estão integrando um padrão externo existente em vez de uma nova camada de protocolo. + +## Como funciona + +O componente Capture do ProofMode incorpora metadados de proveniência diretamente nos arquivos de mídia durante a captura, suportando os mesmos padrões interoperáveis utilizados pela Content Authenticity Initiative (CAI), Content Credentials (CR) e C2PA. Um componente Verify separado inspeciona arquivos de áudio, imagem e vídeo para verificar nesses metadados sinais de geração por IA ou edição posterior, e um componente Preserve lida com o armazenamento redundante e descentralizado dos dados de prova subjacentes para arquivamento de longo prazo. Um SDK Develop permite que aplicativos integrem captura e verificação sem construir o formato de proveniência por conta própria. + +## Por que importa + +Para um cliente Nostr de vídeo ou imagem, carregar dados ProofMode significa que um visualizador tem uma forma externa e multiplataforma de verificar se uma peça de mídia foi capturada conforme declarado e não foi alterada silenciosamente desde então, sem depender do cliente de publicação ou relay como fonte de confiança. Essa distinção importa mais para uma cópia baixada ou recodificada de um clipe: dados de proveniência que sobrevivem ao download e a qualquer marca d'água que um cliente aplique são o que torna a atestação ainda verificável depois que o arquivo deixa o aplicativo que o produziu. + +## Implementações + +- [Divine](https://github.com/divinevideo/divine-mobile) - cliente Nostr de vídeos curtos; carrega dados de proveniência ProofMode através de downloads de clipes com marca d'água + +--- + +**Fontes primárias:** +- [ProofMode](https://proofmode.org/) + +**Mencionado em:** +- [Newsletter #17](/pt/newsletters/2026-04-29-newsletter/) +- [Newsletter #31: Divine Mobile 1.0.16 traz um editor de vídeo mais profundo, criptografia em repouso e proveniência ProofMode](/pt/newsletters/2026-07-15-newsletter/#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) + +**Veja também:** +- [Blossom](/pt/topics/blossom/) From cd4c4108ae6acd687a2928db99e4bd6cc1e1113d Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Thu, 16 Jul 2026 06:23:17 +0000 Subject: [PATCH 03/10] Add German translation for Newsletter #31 and topic pages --- .../de/newsletters/2026-07-15-newsletter.md | 300 ++++++++++++++++++ content/de/topics/concord-protocol.md | 61 ++++ content/de/topics/gamma-markets.md | 69 ++++ content/de/topics/nip-4e.md | 46 +++ content/de/topics/proofmode.md | 36 +++ 5 files changed, 512 insertions(+) create mode 100644 content/de/newsletters/2026-07-15-newsletter.md create mode 100644 content/de/topics/concord-protocol.md create mode 100644 content/de/topics/gamma-markets.md create mode 100644 content/de/topics/nip-4e.md create mode 100644 content/de/topics/proofmode.md diff --git a/content/de/newsletters/2026-07-15-newsletter.md b/content/de/newsletters/2026-07-15-newsletter.md new file mode 100644 index 0000000..d7340f5 --- /dev/null +++ b/content/de/newsletters/2026-07-15-newsletter.md @@ -0,0 +1,300 @@ +--- +title: "Nostr Compass #31" +date: 2026-07-15 +publishDate: 2026-07-15 +translationOf: /en/newsletters/2026-07-15-newsletter.md +translationDate: 2026-07-15 +draft: false +type: newsletters +description: "Vector v0.4.0 ersetzt Marmot für Gruppen-Chats durch das offene Concord-Protokoll und liefert Concord v2 Tage später, Amethyst mergt eine eigene Clean-Room-Concord-Implementierung, Sonar spaltet sich von Bitchat ab mit einer plattformübergreifenden Alpha und einer Sticker-Pack-Spezifikation, Divine Mobile 1.0.16 bringt At-Rest-Verschlüsselung und ProofMode-Provenienz, Bitchat 1.7.0 fügt Live-Push-to-Talk-Sprachübertragung hinzu, und MDK v0.9.4 begrenzt External-Signer-Login." +--- + +Willkommen zurück bei Nostr Compass, eurem wöchentlichen Wegweiser für Nostr. + +**Diese Woche:** [Vector v0.4.0](#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) ersetzt [Marmot](/de/topics/marmot/) als Standard-Transport für Group Chats zugunsten von [Concord](/de/topics/concord-protocol/), einem offenen, MIT-lizenzierten Community-Protokoll, das auch von Soapbox' Armada verwendet wird, und liefert vier Tage später Concord v2 mit einem Slash-Command-Picker für Bots, einem Selbstzerstörungs-Timer und NIP-58-Badges. [Amethyst mergt seine eigene Clean-Room-, drahtkompatible Concord-Implementierung](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) in derselben Woche. [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) spaltet sich von Bitchat ab mit einer plattformübergreifenden Alpha und ist die zitierte Spezifikationsquelle für den Sticker-Pack-Kinds-Vorschlag dieser Woche. [Divine Mobile 1.0.16](#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) liefert einen tieferen Video-Editor, At-Rest-Verschlüsselung und ProofMode-Provenienz, die wasserzeichenmarkierte Clip-Downloads überlebt. [Bitchat v1.7.0](#bitchat-v170-adds-live-push-to-talk-voice-for-dms-and-the-public-mesh) fügt Live-Push-to-Talk-Sprachübertragung für DMs und signiertes Push-to-Talk auf dem öffentlichen Mesh hinzu. [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) begrenzt External-Signer-Login und fügt Draft-Persistenz hinzu, während Vector in derselben Woche die Spezifikation für Gruppen-Chat verlässt. + +Getaggte Releases bringen [n_cord v1.1](#n_cord-v11-adds-nsec-bunker-support) mit NSEC-Bunker-Unterstützung, [cdk v0.17.3](#cdk-v0173-adds-nip-47-wallet-service-support-across-cdk-cdk-nwc-and-cdk-ffi) mit NIP-47-Wallet-Service-Unterstützung über cdk, cdk-nwc und cdk-ffi, [Coop Mobile v0.2.4](#coop-mobile-v024-improves-nostr-connect-and-adds-ncryptsec1-import) mit verbessertem Nostr Connect und ncryptsec1-Import, [Nmail v0.14.0](#nmail-v0140-ships-on-macos-with-scheduled-send-and-push-notifications) auf macOS mit geplantem Senden, [Nostrord v2.2.0](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages) mit einem DM-Master-Toggle, [Nostr WoT 0.3.86](#nostr-wot-0386-hardens-key-backups-and-signing-prompts) mit gehärteten Schlüssel-Backups im NIP-49-Format, [Keep Android v1.1.8](#keep-android-v118-adds-first-run-frost-onboarding) mit First-Run-FROST-Onboarding, [Noscall v0.6.0](#noscall-v060-adds-a-cashu-wallet-and-relay-based-push-notifications) mit einem Cashu-Wallet und relay-basierten Push-Benachrichtigungen, [Kubo](#kubo-ships-tablet-mode-and-group-chat-photos) mit Tablet-Modus und Gruppen-Chat-Fotos und [Nostr Codex Phone v0.2.9](#nostr-codex-phone-v029-adds-gitdiffread-file-helper-requests) mit git-, diff- und read-file-Helper-Requests. + +Auf der unveröffentlichten Seite lässt [Amethyst](#amethyst-lets-accounts-nickname-contacts-with-encrypted-nip-85-cards) Accounts Kontakte mit verschlüsselten NIP-85-Karten benennen, über 54 gemergte PRs. [Zap Cooking](#zap-cooking-ships-my-kitchen-phase-3-and-fixes-an-ndk-pool-quorum-bug) liefert My Kitchen Phase 3 und behebt einen NDK-Pool-Quorum-Bug. [Kehto](#kehto-streams-outbox-reads-before-relay-discovery) streamt Outbox-Reads vor Abschluss der Relay Discovery. [Wired und TAO](#wired-and-tao-add-nip-57-creator-revenue-sharing) fügen NIP-57-Creator-Revenue-Sharing hinzu. [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) baut seinen Händler-Bestelleingang um ephemeres Guest Checkout um. [Buzz](#buzz-hardens-channel-creator-provisioning-around-kind-39002) härtet Channel-Creator-Provisioning über 240 gemergte PRs. Und [Nostr Docs](#nostr-docs-adopts-a-nip-49-signer-with-multi-account-and-qr-pairing) übernimmt einen NIP-49-Signer mit Multi-Account und QR-Pairing. Neu getrackt diese Woche: [OpenDiscord v1.0.1](#opendiscord-v101-launches-as-a-discord-style-client-on-nostr), [Auditable Voting v0.1.140](#auditable-voting-v01140-aligns-organiser-voter-and-audit-proxy-roles) und Discovery-Pick [Cambium v0.3.2](#cambium-v032-pairs-with-heartwood-as-a-keyless-nip-55-signer), ein schlüsselloser NIP-55-Signer, der an einen Heartwood-Hardware-Companion weiterleitet. + +Das NIPs-Repository mergt in der letzten Woche nichts und öffnet sechs Vorschläge: [kind:10011 Favorite Follow Sets](#open-kind10011-favorite-follow-sets), ein [privates verschlüsseltes Laufwerk als Erweiterung von NIP-4E](#open-private-encrypted-drive-extends-nip-4e), [NIP-DA permissioned private data sharing](#open-nip-da-permissioned-private-data-sharing), [Sticker-Pack-Kinds 10031 und 30031](#open-sticker-pack-kinds-10031-and-30031), [NIP-29 Message Pinning](#open-nip-29-message-pinning-with-kind9010-and-kind39005) und eine [NIP-66-Relay-Discovery-Umstrukturierung](#open-nip-66-relay-discovery-restructure). Der Deep Dive behandelt [NIP-99 und die Gamma-Markets-Commerce-Erweiterung](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension). + +--- + +## Leitgeschichten + +### Vector v0.4.0 moves Group Chats from Marmot to Concord, and Amethyst ships its own Concord client days later + +[Vector](https://github.com/VectorPrivacy/Vector) ist ein Nostr-Messenger, der auf einem Single-Binary-, datenschutzorientierten Client für DMs und Gruppen-Chats aufbaut. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) schreibt die Messaging-Engine der App in eine gemeinsame `vector-core`-Bibliothek um und ersetzt im selben Release [Marmot](/de/topics/marmot/) (MLS-over-Nostr) als Standard-Transport für Group Chats durch [Concord](/de/topics/concord-protocol/), ein Ende-zu-Ende-verschlüsseltes Community-Protokoll; bestehende Marmot-Gruppenverläufe werden nicht übernommen, und die Release Notes empfehlen, alle Marmot-Gruppendaten vor dem Upgrade zu sichern. Vectors eigene Release Notes beschreiben Concord als „our custom messaging protocol", aber die zugrunde liegenden [CORD-01- bis CORD-07-Spezifikationen](https://github.com/concord-protocol/concord) werden separat veröffentlicht, sind MIT-lizenziert und bereits außerhalb von Vector implementiert: Soapbox' Discord-artiger Client [Armada](https://gitlab.com/soapbox-pub/armada) baut sein Communities-Feature auf derselben Concord-Spezifikation auf, und einen Tag später [mergte Amethyst seine eigene Clean-Room-, drahtkompatible Concord-Implementierung](https://github.com/vitorpamplona/amethyst/pull/3566), die weiter unten vollständig behandelt wird. Dasselbe Vector-Release fügt optionales Tor-Routing für allen Datenverkehr, [NIP-46](/de/topics/nip-46/) Remote-Signer-Login per QR oder eingefügter Bunker-URI, mehrere Accounts mit einem In-App-Switcher und benutzerdefinierte Emoji-Packs hinzu, die clientübergreifend geteilt werden. Das Löschen von Nachrichten entfernt eine Nachricht für beide Seiten in DMs und Gruppen-Chats, und Vector behält bewusst den ephemeren Signaturschlüssel, anstatt dem Standard-[NIP-17](/de/topics/nip-17/)-Löschablauf zu folgen, eine datenschutzmotivierte Abweichung, die das Projekt explizit in den Release Notes hervorhebt. Vier Tage später liefert [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) **Concord v2**, das wichtige Datenschutz- und Stabilitätsverbesserungen für Communities bringt, bei gleichzeitiger Kompatibilität bestehender Communities, zusammen mit einem Discord-artigen Slash-Command-Picker für Bots mit typisierten Parametern, einem Pro-Chat-Selbstzerstörungs-Timer und einem NIP-58-Badge-System für Bug Hunter. Der Wechsel weg von Marmot für Gruppen-Chat erfolgt in derselben Woche, in der [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) unten weiterhin in die Spezifikation investiert. + +### Amethyst ships a clean-room Concord implementation for end-to-end encrypted communities + +[Amethyst](https://github.com/vitorpamplona/amethyst) ist ein funktionsreicher Android- und Multiplattform-Nostr-Client. [PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) fügt eine vollständige Implementierung von [Concord](/de/topics/concord-protocol/) (CORD-01 bis CORD-07) hinzu, die serverlose, Ende-zu-Ende-verschlüsselte Communities abdeckt: Gift-Wrapped Control-, Chat- und Guestbook-Ebenen über gewöhnliche Relays, vom Eigentümer verwurzelte Rollen- und Ban-Durchsetzung, die jeder Client lokal verifiziert, anstatt einem Server zu vertrauen, und Rekeying zum Ausschluss entfernter Mitglieder. Protokoll- und Krypto-Code liegt in `quartz/`, State und View Models in `commons/`, und Screens und Navigation in `amethyst/` für Android, mit schlanken CLI-Verben unter `cli/`; es gibt noch keine Desktop-UI, da die gemeinsame Logik in `quartz`/`commons` liegt, damit Desktop sie später übernehmen kann. Die Implementierung ist Clean-Room: aus den öffentlichen CORD-Spezifikationen und beobachteten Wire-Konstanten gebaut, unter Amethysts eigener MIT-Lizenz, getrennt von Armadas AGPL-3.0-Codebasis. Armadas eigene Test-Vector-Werte wurden in Quartz' Unit-Tests portiert, um zu bestätigen, dass die beiden Clients tatsächlich auf der Leitung interoperieren, was Concord innerhalb von Tagen drei unabhängige Implementierungen gibt: Vector liefert zuerst, Armada als Soapbox' Referenz-Client, und nun Amethysts Aus-der-Spezifikation-Build. + +### Sonar splits off from Bitchat with a cross-platform alpha and a sticker-pack spec + +[Sonar](https://sonarprivacy.xyz/) ist ein Bluetooth-Mesh-plus-Nostr-Messenger und Wallet, gewachsen aus Bitchat, mit Marmot-Gruppen-DMs, die mit White Noise interoperieren. Code liegt unter [hedwig-corp/bitchat-to-sonar](https://github.com/hedwig-corp/bitchat-to-sonar). [v0.1-alpha.7](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.7) fügt Signal-artiges begrenztes Transcript-Windowing hinzu, damit Open- und Scroll-Performance local-first bleibt, synchronisiert Nearby-Discovery-State über Peers und behebt Blossom-Medien-Uploads, die bei Content-Type und HTTP-Status-Handling fehlschlugen; das vorangehende [alpha.6](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.6) leerte Live-Marmot-Events für schnellere Chat-Aktualisierung und schloss Android-zu-iOS-Feature-Parity-Lücken über Anrufe, Messaging, Wallet und Push. Sonar ist auch die zitierte Spezifikationsquelle für [PR #2410](#open-sticker-pack-kinds-10031-and-30031), die Sticker-Pack-Event-Kinds unter der eigenen „Sonar Stickers"-Spezifikation des Projekts registriert, was diesem Launch eine direkte Hub-Verbindung zur Protokollarbeit dieser Woche gibt. + +### Divine Mobile 1.0.16 ships a deeper video editor, at-rest encryption, and ProofMode provenance + +[Divine](https://github.com/divinevideo/divine-mobile) ist ein Kurzvideo-Client, der auf Nostr mit Web-of-Trust-Feed-Kuratierung aufbaut. [v1.0.16](https://github.com/divinevideo/divine-mobile/releases/tag/1.0.16), das erste getaggte Release seit #30, fügt dem Video-Editor Clip-Übergänge, Rückwärtswiedergabe, einen Voice-Over-Recorder und Timeline-Beat-Marker hinzu, zusammen mit einem Feed-Tuning-Control, das einem Nutzer ermöglicht, durch Wischen die Empfehlungen direkt anzupassen, anstatt sie opaken Engagement-Signalen zu überlassen. Das Release aktiviert auch At-Rest-Verschlüsselung für lokale Daten, fügt Hintergrund-Uploads hinzu, die das Suspendieren der App überleben, und führt [ProofMode](/de/topics/proofmode/)-Provenienzdaten weiter, wenn ein wasserzeichenmarkierter Clip heruntergeladen wird, damit die Attestierung menschlicher Herkunft beim Transit nicht entfernt wird. Divine liefert auch neue Schutzmaßnahmen für Accounts unter 16 Jahren und erweitert die Lokalisierung auf 17 Sprachen und 284 übersetzte Strings. + +### Bitchat v1.7.0 adds live push-to-talk voice for DMs and the public mesh + +[Bitchat](https://github.com/permissionlesstech/bitchat) ist eine Bluetooth-Mesh-Chat-App mit einem optionalen Gateway auf Nostr-Relays. [v1.7.0](https://github.com/permissionlesstech/bitchat/releases/tag/v1.7.0), veröffentlicht am Abend der Veröffentlichung von #30, fügt Live-Push-to-Talk-Sprachübertragung in [PR #1403](https://github.com/permissionlesstech/bitchat/pull/1403) hinzu, die Audio streamt, während der Sender die Taste hält, und bei Abbruch des Streams auf eine Sprachnotiz zurückfällt, plus signiertes öffentliches Mesh-Push-to-Talk in [PR #1406](https://github.com/permissionlesstech/bitchat/pull/1406), sodass Live-Sprach-Bursts auf dem gemeinsamen Mesh-Kanal Sender-Authentifizierung tragen. Das Release heilt auch Peer-ID-Rotation durch erneutes Binden des Links bei einem verifizierten Re-Announce, wobei derselbe Peer unter seiner neuen ID erkannt wird ([PR #1401](https://github.com/permissionlesstech/bitchat/pull/1401)), und Direktnachrichten an einen derzeit nicht erreichbaren Peer werden jetzt mit Store-and-Forward-Zustellung in die Warteschlange gestellt, anstatt direkt fehlzuschlagen ([PR #1415](https://github.com/permissionlesstech/bitchat/pull/1415)). Dies setzt direkt die Berichterstattung von #30 über v1.6.0's [NIP-13](/de/topics/nip-13/) Proof-of-Work und Mesh-to-Nostr-Gateway-Arbeit fort. + +### MDK v0.9.4 bounds external-signer login and adds draft persistence + +[MDK](https://github.com/marmot-protocol/mdk) ist das Referenz-SDK für das [Marmot](/de/topics/marmot/)-Protokoll, die MLS-over-Nostr-Messaging-Schicht, deren Spezifikation #30 als übernommen behandelte. [v0.9.4](https://github.com/marmot-protocol/mdk/releases/tag/v0.9.4) begrenzt die Advisory-Directory-Schritte, die ein Client beim External-Signer-Login durchläuft, in [PR #793](https://github.com/marmot-protocol/mdk/pull/793), und verhindert eine unbegrenzte Retry-Schleife, wenn ein Remote Signer langsam oder nicht erreichbar ist. Dasselbe Release fügt Draft-Message-Persistenz und Profil-Website-Bindings in [PR #812](https://github.com/marmot-protocol/mdk/pull/812) hinzu und setzt den inkrementellen Härtungsdurchgang fort, den MDK seit dem Schneiden von v0.9.0 durchführt. + +--- + +## Getaggte Releases + +### n_cord v1.1 adds NSEC Bunker support + +[n_cord](https://github.com/0n4t3/n_cord) ist ein Nostr-basierter Chat-Client, inspiriert von Discord und IRC. [v1.1](https://github.com/0n4t3/n_cord/releases/tag/v1.1) fügt [NIP-46](/de/topics/nip-46/) NSEC-Bunker-Unterstützung hinzu, zusammen mit einem Reply-Handling-Bug-Fix. + +### cdk v0.17.3 adds NIP-47 wallet-service support across cdk, cdk-nwc, and cdk-ffi + +[cdk](https://github.com/cashubtc/cdk) ist ein Cashu Development Kit; dieses Release ist in den meisten Aspekten rein Bitcoin/Lightning, aber [v0.17.3](https://github.com/cashubtc/cdk/releases/tag/v0.17.3) fügt [NIP-47](/de/topics/nip-47/) (Nostr Wallet Connect) Service-Unterstützung mit einem dedizierten NWC-Service-Crate, Wallet-Integration, FFI-Bindings für `cdk-ffi` und End-to-End-Testabdeckung hinzu, was auf cdk aufbauenden Cashu-Wallets eine standardmäßige Nostr-Wallet-Connect-Oberfläche gibt. + +### Coop Mobile v0.2.4 improves Nostr Connect and adds ncryptsec1 import + +[Coop Mobile](https://git.reya.su/reya/coop-mobile) ist ein [NIP-17](/de/topics/nip-17/) Private-Messaging-Client für mobile Plattformen. [v0.2.4](https://git.reya.su/reya/coop-mobile/releases/tag/v0.2.4) verbessert den [NIP-46](/de/topics/nip-46/) Nostr-Connect-Ablauf, behebt einen Ladeindikator, der bei manchen Verbindungen permanent hängen blieb, und fügt Import-Unterstützung für das [NIP-49](/de/topics/nip-49/) `ncryptsec1`-verschlüsselte-Schlüssel-Format hinzu, zusammen mit einem umgestalteten Identitätsimport-Bildschirm. + +### Nmail v0.14.0 ships on macOS with scheduled send and push notifications + +[Nmail](https://github.com/nogringo/nostr-mail-client) ist ein auf Nostr aufbauender Mail-Client; [v0.14.0](https://github.com/nogringo/nostr-mail-client/releases/tag/v0.14.0) bringt die App auf macOS, fügt geplantes Senden mit einem dedizierten Scheduled-Postfach für wartende Nachrichten und Push-Benachrichtigungen hinzu. Das Release stellt auch die Adressbuch-Nostr-Identifier-Auflösung auf NDKs [NIP-05](/de/topics/nip-05/)-Resolver um, anstelle einer maßgeschneiderten Implementierung. + +### Nostrord v2.2.0 adds a DM master toggle and richer direct messages + +[Nostrord](https://github.com/nostrord/nostrord) ist ein [NIP-29](/de/topics/nip-29/) relay-basierter Gruppen-Chat-Client für Android, iOS, Web und Desktop. [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) fügt einen Master-Toggle zum gleichzeitigen Deaktivieren aller Direktnachrichten-Funktionen hinzu ([PR #175](https://github.com/nostrord/nostrord/pull/175)) und liefert „reichere Direktnachrichten" ([PR #186](https://github.com/nostrord/nostrord/pull/186)), fortgesetzt nach der Berichterstattung in #30 über das Release, das den Relay-Pool faltete und Zombie-WebSockets erkannte. + +### Nostr WoT 0.3.86 hardens key backups and signing prompts + +[Nostr WoT](https://github.com/nostr-wot/nostr-wot-extension) ist eine Browser-Erweiterung, die eine Nostr-Identität mit einem Lightning-Wallet koppelt. [v0.3.86](https://github.com/nostr-wot/nostr-wot-extension/releases/tag/v0.3.86) verschiebt verschlüsselte Schlüssel-Backups in das standardmäßige [NIP-49](/de/topics/nip-49/)-Format, lässt Signatur-Prompts das vollständige Event und alle Tags anzeigen anstatt einer Zusammenfassung, verifiziert Relay-Daten gegen deren Signatur und stoppt das Offenlegen der aktiven Identität beim Kontowechsel. Die Erweiterung entfernt auch die ungenutzte `scripting`-Browser-Berechtigung. + +### Keep Android v1.1.8 adds first-run FROST onboarding + +[Keep](https://github.com/privkeyio/keep-android) ist ein Android-Signer, der auf FROST-Threshold-Key-Shares aufbaut. [v1.1.8](https://github.com/privkeyio/keep-android/releases/tag/v1.1.8) fügt einen First-Run-Ablauf hinzu, der FROST-Key-Shares erklärt und einem neuen Nutzer ermöglicht, eine Signatur-Richtlinie (Manual, Basic oder Auto) zu wählen, bevor die erste Signaturanfrage eintrifft, das erste Android-seitige Onboarding für das Threshold-Signing-Modell des zugrunde liegenden keep-mobile-Crate. + +### Noscall v0.6.0 adds a Cashu wallet and relay-based push notifications + +[Noscall](https://github.com/sanah9/noscall) ist eine sichere Audio- und Videoanruf-App, die auf Nostr aufbaut. [v0.6.0](https://github.com/sanah9/noscall/releases/tag/v0.6.0-release) fügt ein kontobezogenes Cashu-Wallet mit Multi-Mint-Salden, ecash-Senden und -Empfangen und Lightning-Zahlen und -Empfangen mit Quote-Persistenz hinzu. Das Release migriert Android-Push-Benachrichtigungen auch weg von Firebase Cloud Messaging auf einen Nostr-relay-basierten Zustellpfad über UnifiedPush und verbessert die iOS-VoIP- und APNs-Push-Zuverlässigkeit bei Login-Wiederholungsversuchen. + +### Kubo ships tablet mode and group-chat photos + +[Kubo](https://github.com/JeroenOnNostr/kubo) ist eine kindersichere Nostr-Videoplattform mit Web-of-Trust-Feed-Kuratierung. [kubo-v2026.07.05](https://github.com/JeroenOnNostr/kubo/releases/tag/kubo-v2026.07.05) fügt ein optionales Tablet-Grid-Layout für den Kinder-Feed und Unterstützung für das Anhängen von Fotos an Gruppen-Chat-Nachrichten hinzu, plus Fixes für den Anmeldeknopf, der sich auf Android hinter der Bildschirmtastatur versteckt. + +### Nostr Codex Phone v0.2.9 adds git/diff/read-file helper requests + +[Nostr Codex Phone](https://github.com/tidley/nostr-codex-phone) ist eine mobile Steuerungsoberfläche für einen lokalen Coding-Assistant-Worker, der über verschlüsselte Nostr-DMs kommuniziert. [v0.2.9](https://github.com/tidley/nostr-codex-phone/releases/tag/v0.2.9) fügt mobile OpenCode-Tool-Aktionen hinzu, darunter git-, diff-, read-file-, status- und history-Helper-Requests, Session-Pin- und Suchverbesserungen sowie eine Task-Stop-Steuerung, neben einem verschlüsselten [Blossom](/de/topics/blossom/)-Upload-Wrapper, der im vorangegangenen v0.2.8 geliefert wurde. + +### GitWorkshop v3.0.3 fixes newly announced refs in the repo explorer, and ships its first Android build + +[GitWorkshop](https://github.com/DanConwayDev/gitworkshop) ist eine git-over-Nostr-Web-UI zum Durchsuchen und Reviewen von NIP-34-Repositories. [v3.0.3](https://github.com/DanConwayDev/gitworkshop/releases/tag/v3.0.3) behebt das Fehlschlagen der Branches-, Tags-, Commits- und Code-Browsing-Ansichten beim Auflösen eines Refs, den ein Repository ankündigt, nachdem der Explorer es bereits geladen hat, zusammen mit CI-Workflow-Timing-Bereinigung, direkt gegen den Tag und die Commit-Historie bestätigt. In derselben Woche veröffentlichte GitWorkshop seinen ersten nativen Android-Build im [Zapstore](https://zapstore.dev), startend bei v3.0.0 und innerhalb von Stunden v3.0.3 erreichend; die Web-UI bleibt das primäre Interface, und das Android-Paket bringt dasselbe NIP-34-Repository-Browsing zum ersten Mal auf ein Telefon. + +### Bitcoin-Safe reaches Flathub, spotlighting its Nostr Sync & Chat plugin + +[Bitcoin-Safe](https://bitcoin-safe.org) ist ein Self-Custody-Bitcoin-Wallet, das auf Hardware-Signer-Workflows aufbaut. Das Projekt [hat ein Flathub-Paket veröffentlicht](https://flathub.org/apps/org.bitcoin_safe.BitcoinSafe) in dieser Woche, sein erster Eintrag in einem Mainstream-Linux-App-Store. Das Flathub-Release bringt Bitcoin-Safes Sync-&-Chat-Plugin vor ein breiteres Publikum: Das Plugin verwendet [NIP-17](/de/topics/nip-17/) Direktnachrichten über die projekteigene [bitcoin-nostr-chat](https://github.com/andreasgriffin/bitcoin-nostr-chat)-Bibliothek, um Wallet-Labels zwischen den Geräten eines Nutzers zu synchronisieren und PSBTs für Remote-Multisig-Co-Signing zwischen vertrauenswürdigen Teilnehmern zu senden und zu empfangen. Die Nostr-Schicht selbst wurde früher ausgeliefert, in [2.0.0](https://github.com/andreasgriffin/bitcoin-safe/releases/tag/2.0.0) (2026-06-29), das das Transaktionssignieren um einen „Share via Chat & Sync"-Verbindungstyp neben QR, USB und Bluetooth umgestaltete. Die Nachricht dieser Woche ist das Flathub-Packaging, das dieses bestehende Feature zum ersten Mal einem Mainstream-Linux-Publikum zugänglich macht. + +--- + +## Unveröffentlichte Änderungen + +### Amethyst lets accounts nickname contacts with encrypted NIP-85 cards + +Neben der oben behandelten [Concord-Implementierung](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) mergte Amethyst in der letzten Woche 54 weitere PRs. Das Highlight darunter ist [PR #3548](https://github.com/vitorpamplona/amethyst/pull/3548), das einem Account ermöglicht, jeden anderen Nutzer mit einem Spitznamen zu versehen, indem es seine eigene kind-30382-[NIP-85](/de/topics/nip-85/)-Kontaktkarte über ihn veröffentlicht. Der Petname, eine private Notiz und beliebige benutzerdefinierte [NIP-30](/de/topics/nip-30/) Emoji-Shortcode-Zuordnungen befinden sich im [NIP-44](/de/topics/nip-44/)-verschlüsselten Inhalt der Karte, sodass nur der signierende Account sie lesen kann, und Karten synchronisieren über das erweiterte Outbox-Relay-Set des Accounts bei Login und danach inkrementell. Feeds, Chats und Erwähnungen rendern den Petname anstelle des öffentlichen Anzeigenamens, mit einer antippbaren Spitznamenkarte auf der Profilseite oberhalb des echten Namens des Nutzers. + +### Zap Cooking ships My Kitchen Phase 3 and fixes an NDK pool quorum bug + +[Zap Cooking](https://github.com/zapcooking/frontend) ist eine Rezept-Sharing- und Koch-Community-App, die auf Nostr aufbaut. Sie mergte 43 PRs, die ihr „My Kitchen"-Mahlzeitenplanungs-Feature fortsetzen, mit Einkaufslisten-Generierung, einem Rezept-Picker und einem Planer-Wochenraster in dieser Phase. Dieselbe Reihe von Änderungen behebt einen [NDK](https://github.com/nostr-dev-kit/ndk) (Nostr Development Kit) Connection-Pool-Quorum-Readiness-Bug, der Relay-Reads warten lassen konnte, nachdem ein Quorum von Relays bereits geantwortet hatte. + +### Kehto streams outbox reads before relay discovery + +[Kehto](https://github.com/kehto/web) ist eine frühe webbasierte Laufzeitumgebung für [NIP-5D](/de/topics/nip-5d/) Nostr Applets, oder „Napplets". Sie mergte 26 PRs. [PR #193](https://github.com/kehto/web/pull/193) behebt Outbox-Reads, die zuvor auf das Laden der [NIP-65](/de/topics/nip-65/) Relay-Liste warteten, bevor überhaupt ein Relay geöffnet wurde, sodass ein Relay-Liste-Load, der nie abschloss, sowohl Event-Zustellung als auch Query-Timeouts blockieren konnte; der Fix öffnet validierte Relay-Hints sofort und streamt Ergebnisse, während Write-Relays entdeckt werden. Eine zweite Änderung ([PR #196](https://github.com/kehto/web/pull/196)) richtet die Identitäts-Audit-Seite des Projekts an NAP-SHELL aus, dem Lifecycle-Contract der Napplet-Plattform, Teil derselben Protokoll-Alignment-Arbeit, die anderswo im `napplet/web`-Release dieser Woche sichtbar ist. + +### Wired and TAO add NIP-57 creator revenue sharing + +[Wired](https://github.com/smolgrrr/Wired) und [TAO](https://github.com/smolgrrr/TAO) sind Zwillings-Free-Speech-fokussierte Social-Clients, die auf Nostr aufbauen und dieselbe PR-Liste teilen; beide mergten [PR #121](https://github.com/smolgrrr/Wired/pull/121), das [NIP-57](/de/topics/nip-57/) Creator Revenue Sharing implementiert, sodass an einen Post gesendete Zaps automatisch an Beitragende über den ursprünglichen Poster hinaus aufgeteilt werden können. Dies setzt die Berichterstattung von #30 über das Paar fort, das sein Proof-of-Work-Signal auf 21 Bit als unveröffentlichte Arbeit erhöht hat. + +### Conduit Mono rebuilds the merchant orders inbox around ephemeral guest checkout + +[Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) ist ein Marktplatz-Protokoll neben [NIP-99](/de/topics/nip-99/) Classified Listings. [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174) fügt Guest Checkout mit einem browserseitig generierten ephemeren Schlüssel hinzu: Der Gast sendet eine verschlüsselte Bestellung und einen Zahlungsbericht an den Händler unter Verwendung dieses Einmalschlüssels, und der Händler folgt außerhalb des Bands per Telefon oder E-Mail auf, sodass der Käufer nie eine dauerhafte Inbox-Identität benötigt. [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175) baut den Händler-Bestelleingang um ein einzelnes gemeinsames Bestellstatus-Modell um, trennt Käufer- und Händlerrollen und verlangt einen Tracking-Code und Carrier, bevor eine physische oder gemischte Bestellung auf „versandt" wechseln kann. Der Checkout-Ablauf des Projekts baut auf [NIP-17](/de/topics/nip-17/) Private Messages, [NIP-44](/de/topics/nip-44/) Verschlüsselung und [NIP-59](/de/topics/nip-59/) Gift Wrap auf. Der [NIP Deep Dive](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) dieser Woche behandelt die [Gamma Markets](/de/topics/gamma-markets/)-Konventionen, auf die dasselbe Bestellstatus-Problem hinarbeitet. + +### Buzz hardens channel-creator provisioning around kind 39002 + +[Buzz](https://github.com/block/buzz) ist eine Hive-Mind-Kommunikationsplattform, die KI-Agenten und Menschen über Nostr verbindet. Sie mergte 240 PRs in der letzten Woche und setzte ihren Relay-Schicht-Härtungsbogen fort, nach der Berichterstattung von #30 über kind-44200-Agent-Turn-Metriken. Der Fix dieser Woche ([PR #1830](https://github.com/block/buzz/pull/1830)) behandelt den Creator eines Channels als Mitglied, bevor die kind-39002-Channel-Provisioning-Logik ausgeführt wird, und schließt eine Race Condition, bei der der eigene Channel des Creators ihn während des Setups ablehnen konnte. + +### Nostr Docs adopts a NIP-49 signer with multi-account and QR pairing + +[Nostr Docs](https://github.com/formstr-hq/nostr-docs) ist eine Nostr-native kollaborative Dokumentenanwendung. Sie mergte 5 PRs, der bemerkenswerte ([PR #50](https://github.com/formstr-hq/nostr-docs/pull/50)) übernimmt das `@formstr/signer`-Paket für vollständige [NIP-49](/de/topics/nip-49/)-Authentifizierung mit Multi-Account-Switching und QR-Pairing und ersetzt einen früheren maßgeschneiderten Signaturpfad. + +### Ebenfalls ausgeliefert + +Kleinere Signer-Interop- und Zuverlässigkeits-Fixes landeten in der letzten Woche über mehrere getrackte Projekte hinweg, ohne genug neue Oberfläche für eigene Absätze: [ngit-cli](https://github.com/DanConwayDev/ngit-cli), ein Kommandozeilen-Client für eine Nostr-basierte GitHub-Alternative, liefert [v2.6.3](https://github.com/DanConwayDev/ngit-cli/releases/tag/v2.6.3), das `ngit init` umsetzbare Setup-Anleitung statt wiederholter nsec-Abfragen gibt; [Manent](https://github.com/dtonon/manent), eine private verschlüsselte Notizen-und-Dateien-App auf Nostr, liefert [v1.4.1](https://github.com/dtonon/manent/releases/tag/v1.4.1) mit einem Fix für defektes Android-Signer-Login, wenn Amber einen Hex-pubkey zurückgibt, und verbessertem Bunker-Login-Scrolling; [NoorNote](https://github.com/77elements/noornote), ein schlanker, Google-Service-freier Nostr-Client, liefert [v1.2.8](https://github.com/77elements/noornote/releases/tag/v1.2.8) mit einem Fix für verpasste Nostrord-Gruppen-Benachrichtigungen und einem Self-Post-Alert-Toggle; [Bray](https://github.com/forgesworn/bray), ein vertrauensbewusster Nostr-MCP-Server für KI-Agenten und Menschen, liefert [v1.34.0](https://github.com/forgesworn/bray/releases/tag/v1.34.0), das Client-Name-Metadaten bei [NIP-46](/de/topics/nip-46/) Bunker Connect sendet; [Lumilumi](https://github.com/TsukemonoGit/lumilumi), ein Nostr-Web-Client, cachet [NIP-65](/de/topics/nip-65/) Relay-Listen im lokalen Speicher für Offline-Fallback; [Earthly](https://github.com/moogmodular/earthly), eine Nostr-basierte lokale Stadt- und Community-App, fügt [NIP-50](/de/topics/nip-50/) Geo-Suche hinzu; und [lnbits](https://github.com/lnbits/lnbits), ein freies und Open-Source-Lightning-Wallet- und Kontensystem, liefert [PR #3925](https://github.com/lnbits/lnbits/pull/3925), das `send_nostr_dm` nicht-blockierend innerhalb eines ansonsten Lightning-fokussierten Releases veröffentlicht. + +--- + +## Neu getrackt und entdeckt + +### OpenDiscord v1.0.1 launches as a Discord-style client on Nostr + +[OpenDiscord](https://github.com/sofia-gros/open-discord) ist ein Discord-artiger Server-und-Channel-Client, der auf Nostr mit rollenbasierten Berechtigungen und WebRTC/SFU-Sprach-Lobbies aufbaut. [v1.0.1](https://github.com/sofia-gros/open-discord/releases/tag/v1.0.1) ist das erste getaggte Installer-Release des Projekts. + +### Auditable Voting v0.1.140 aligns organiser, voter, and audit-proxy roles + +[Auditable Voting](https://github.com/tidley/auditable-voting) ist eine Client-only-Nostr-Abstimmungs-Shell. [v0.1.140](https://github.com/tidley/auditable-voting/releases/tag/v0.1.140) richtet die Organiser-, Voter- und Audit-Proxy-Rollen am exakten vom Organiser signierten öffentlichen Questionnaire-Definition-Event aus und schließt eine Lücke, bei der ein Audit-Proxy auf veralteten generierten Accounts oder State operieren konnte, der von einem anderen Worker oder Organiser stammte. + +### Cambium v0.3.2 pairs with Heartwood as a keyless NIP-55 signer + +[Cambium](https://github.com/forgesworn/cambium) ist der Discovery-Pick dieser Ausgabe: ein Android-[NIP-55](/de/topics/nip-55/)-Signer, der selbst kein privates Schlüsselmaterial hält und jede Signaturanfrage über [NIP-46](/de/topics/nip-46/) an einen Heartwood-Hardware-Signer-Companion weiterleitet. Das Projekt teilt die `forgesworn`-GitHub-Org mit dem getrackten Projekt Bray, und Heartwood selbst wurde in #30 behandelt, als es die Relay-to-Serial-Signing-Bridge auslieferte, mit der Cambiums Android-Seite nun kommuniziert. [v0.3.2](https://github.com/forgesworn/cambium) poliert das Genehmigungsblatt, um live zu warnen, wenn die gewählte Identität von der bestehenden Bindung der App abweicht, und verschiebt Activity-Log-Schreibvorgänge in eine einzelne nicht-blockierende Warteschlange. + +### Ebenfalls diese Woche gestartet: echoes, Dispatch und Linky + +Drei weitere Launches verdienen eine Erwähnung diese Woche. [echoes](https://github.com/Lwb89dev/echoes) ist eine Offline-First-, Ende-zu-Ende-verschlüsselte Notizen-App, die privat über Nostr synchronisiert. [Dispatch](https://github.com/freecritter/dispatch) ist ein Local-First-Reiseorganizer, bei dem jede Speicherung [NIP-44](/de/topics/nip-44/)-verschlüsselt und über Nostr unter einem dedizierten, nicht verlinkbaren Schlüssel gesichert wird, und sein [v0.3.0](https://github.com/freecritter/dispatch)-Release fügt Amber-[NIP-55](/de/topics/nip-55/)-Login hinzu, damit die App den privaten Schlüssel des Nutzers nie direkt berührt. [Linky](https://github.com/hynek-jina/linky) kombiniert Nostr-Kontakte und DMs mit Lightning- und Cashu-Zahlungen in einer einzigen Progressive Web App. + +--- + +## Protokollarbeit und NIP-Updates + +Keine PRs wurden in der letzten Woche in das [NIPs-Repository](https://github.com/nostr-protocol/nips) gemergt. Sechs Vorschläge wurden geöffnet. + +### Open: kind:10011 favorite follow sets + +[PR #2413](https://github.com/nostr-protocol/nips/pull/2413), von fiatjaf, fügt kind:10011 Favorite Follow Sets hinzu. Es spiegelt das bestehende Muster, bei dem kind:10012 (Favorite Relay Sets) `a`-Tags enthält, die auf kind:30002 Relay Sets zeigen, und erweitert denselben Favorisierungsmechanismus auf kind:30000 Follow Sets, damit ein Client eine kuratierte Follow-Liste als Lesezeichen speichern kann, ohne seine eigene Kontaktliste zu ersetzen. + +### Open: private encrypted drive extends NIP-4E + +[PR #2412](https://github.com/nostr-protocol/nips/pull/2412), vom Form*-Team, schlägt ein generisches Metadata-Event vor, kind 34578, unterschieden durch einen `d`-Identifier-Tag und einen `t`-Sub-Type-Tag, zusammen mit einem privaten verschlüsselten Dateisystem, das darauf aufbaut und bereits in Form*'s eigenem, noch experimentellem Form* Drive Client implementiert ist. Ein Datei-Datensatz ist ein Metadata-Event mit `t=files`: Datei-Blobs liegen auf [Blossom](/de/topics/blossom/)-Servern, während nur ein verschlüsselter Index auf Relays sitzt, und jeder Datei-Chunk erhält sein eigenes ephemeres Schlüsselpaar mit [NIP-44](/de/topics/nip-44/) v2 HKDF-abgeleiteter Verschlüsselung. Ein begleitendes Decoupled Encryption Key Event hält einen laufwerkweiten symmetrischen Schlüssel, gegen den jede Datei ihre Metadaten entschlüsselt, und baut explizit auf [NIP-4E](/de/topics/nip-4e/) auf, fiatjafs noch offenem Storage-Abstraction-Entwurf ([PR #1647](https://github.com/nostr-protocol/nips/pull/1647), offen seit Dezember 2024). + +Dieser einzelne laufwerkweite Schlüssel bedeutet, dass ein durchgesickerter Schlüssel die Metadaten jeder Datei im Laufwerk offenlegt, nicht nur einer Datei, da die pro-Datei ephemeren Schlüsselpaare nur den Chunk-Verschlüsselungsschlüssel variieren, nicht den Metadaten-Entschlüsselungsschlüssel; es gibt noch keinen Rotations- oder Widerrufspfad außer dem Veröffentlichen eines neuen Metadata-Events mit der Warnung, dass ältere Events verloren gehen können. Ein zweiter, engerer Vorschlag greift dieselbe zugrunde liegende NIP-4E-Idee aus einem anderen Blickwinkel auf: [PR #2361](https://github.com/nostr-protocol/nips/pull/2361), von fiatjaf, entkoppelt Identitäts- und Verschlüsselungsschlüssel speziell innerhalb von [NIP-17](/de/topics/nip-17/) Messaging, offen seit 1. Juni. Beide PRs sind nicht gemergt, was dies zu einer aktiven, umstrittenen Ecke des Designraums macht. Form* sagt, der Drive Client sei experimentell und ein Update komme bald. + +### Open: NIP-DA permissioned private data sharing + +[PR #2411](https://github.com/nostr-protocol/nips/pull/2411), von JAFairweather, ist ein neuer NIP-DA-Entwurf für genehmigungsbasiertes privates Datenteilen über scoped Data Grants. Jeder Nutzer hält einen verschlüsselten, autoritativen Datensatz pro Scope auf Relays, und Zugang wird gewährt, indem der symmetrische Schlüssel dieses Scopes privat innerhalb eines [NIP-59](/de/topics/nip-59/) Gift Wraps zugestellt wird, sodass Relays nur Ciphertext speichern und nie erfahren, wer wem Zugang gewährt hat; ein Widerruf ist einfach eine Schlüsselrotation, ohne jeden Consumer-Kopie neu schreiben zu müssen. Der Autor positioniert es als distinkt von [NIP-17](/de/topics/nip-17/) DMs (die einen Daten-Snapshot transportieren können, aber keine Live-Updates oder Widerrufe) und von NIP-51 Private Lists (die kein Schlüsselmaterial transportieren), und zitiert zwei unabhängige Implementierungen, eine JavaScript-Referenzbibliothek und eine Go-CLI auf go-nostr, kreuzgetestet gegen relay.damus.io, nos.lol und relay.primal.net. + +### Open: sticker pack kinds 10031 and 30031 + +[PR #2410](https://github.com/nostr-protocol/nips/pull/2410), von vincenzopalazzo, registriert kind 30031 (adressierbare Sticker Packs) und kind 10031 (die Sticker-Pack-Liste eines Nutzers) in der Event-Kinds-Tabelle, spezifiziert durch das „Sonar Stickers"-Format, das [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) diese Woche ausliefert. Die Kinds liegen bewusst einen Slot über den [NIP-30](/de/topics/nip-30/) Custom-Emoji-Kinds 30030 und 10030, damit ein Client ein Sticker Pack nicht mit einem Emoji-Set verwechseln kann; Sticker-Bild-Bytes liegen auf HTTPS-[Blossom](/de/topics/blossom/)-kompatiblen Servern, und gesendete Sticker-Referenzen tragen einen Klartext-Hash, damit ein bearbeitetes adressierbares Pack nicht stillschweigend das Aussehen von Stickern ändern kann, die bereits in alten Nachrichten gesendet wurden. Ein begleitender PR registriert dieselben Kinds im separaten `registry-of-kinds`-Projekt. + +### Open: NIP-29 message pinning with kind:9010 and kind:39005 + +[PR #2379](https://github.com/nostr-protocol/nips/pull/2379), von Anderson-Juhasc, fügt Message Pinning zu [NIP-29](/de/topics/nip-29/) relay-basierten Gruppen hinzu: kind:9010 `update-pin-list` ist ein Moderations-Event, das die vollständige Liste der angepinnten Events als `e`-Tags in Anzeigereihenfolge trägt, sodass ein einzelnes Event pinnen, entpinnen, umsortieren oder die angepinnte Menge leeren kann, und kind:39005 ist ein relay-generierter Spiegel, der die zuletzt akzeptierte Liste offenlegt. Das Design ersetzt einen früheren Add/Remove-Paar-Ansatz aus [PR #1163](https://github.com/nostr-protocol/nips/pull/1163) nach Review-Feedback und wählt Kind-Nummern 9010/39005, weil 9009 und 39003 inzwischen von `create-invite` und Gruppenrollen beansprucht wurden. Anderson-Juhasc pflegt auch [Nostrord](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages), dessen [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) in derselben Woche ausgeliefert wird. + +### Open: NIP-66 relay discovery restructure + +[PR #2241](https://github.com/nostr-protocol/nips/pull/2241), von VincenzoImp, ist eine umfassende Umstrukturierung von [NIP-66](/de/topics/nip-66/) Relay Discovery. Es ersetzt die lose „Other tags include"-Prosa durch einen strukturierten Indexed-Tags-Abschnitt, fügt einen `W`-Tag hinzu, der NIP-11s `attributes`-Feld für Relay-Discovery-Filterung spiegelt, fügt einen `l`-Label-Tag mit standardisierten Namespaces (`ISO-639-1`, `ISO-3166-1`, `IANA-asn`, `IANA-tz`, `nip66.label.city`) hinzu und organisiert RTT-, SSL/TLS-, Netzwerk-, Geo-, DNS- und HTTP-Tags in dedizierte Abschnitte neben einer neuen Check-Types-Tabelle. Es behebt auch fehlerhafte Beispiel-Events mit falschen Feldnamen, einem fehlenden `kind` und ungültigen Check-Type-Namen und schließt [Issue #2171](https://github.com/nostr-protocol/nips/issues/2171) ab. Alle Änderungen bleiben abwärtskompatibel, da jeder hinzugefügte Tag optional ist. + +--- + +## NIP Deep Dive: NIP-99 und die Gamma-Markets-Commerce-Erweiterung + +[NIP-15](/de/topics/nip-15/), die ursprüngliche Nostr Marketplace-Spezifikation, ist inzwischen Legacy: Sie modellierte einen Merchant Stall (kind 30017) mit Produkten (kind 30018) darunter, und die Clients, die einst darauf liefen, Shopstr unter ihnen, sind seitdem zu [NIP-99](/de/topics/nip-99/) Classified Listings als aktiver Spezifikation gewechselt. NIP-99 selbst ist ein einzelnes adressierbares Event, kind 30402 für ein aktives Listing oder kind 30403 für einen Entwurf, ohne zuerst einen Stall erstellen zu müssen. Es lässt alles nach dem Listing undefiniert: Versandkosten, Bestellstatus, Quittungen, Bewertungen und eine Möglichkeit, mehrere Listings unter einem Schaufenster zu gruppieren, genau die Teile von NIP-15, die nie übernommen wurden. [Gamma Markets](/de/topics/gamma-markets/) füllt diese Lücke und ist die moderne Commerce-Schicht, die es heute zu verstehen lohnt. + +### Die Lücke, die NIP-99 offen lässt + +Das `content`-Feld eines NIP-99-Listings trägt eine Markdown-Beschreibung, `price` und `location` sitzen direkt auf dem Event, und `t`-Tags machen es als gewöhnlichen Hashtag-Content durchsuchbar. Da es auf dem pubkey-, kind- und `d`-Tag-Tupel adressierbar ist, bearbeitet ein Verkäufer ein Listing direkt, indem er eine neue Version mit demselben `d`-Tag veröffentlicht: + +```json +{ + "kind": 30402, + "content": "Vintage mechanical keyboard, Cherry MX Blue switches, barely used.", + "tags": [ + ["d", "keyboard-mx-blue-01"], + ["title", "Vintage Mechanical Keyboard"], + ["summary", "Cherry MX Blue, barely used"], + ["published_at", "1752537600"], + ["location", "NYC"], + ["price", "100", "USD"], + ["t", "electronics"] + ] +} +``` + +Das ist die gesamte Spezifikation: eine signierte, aktualisierbare Kleinanzeige. Jeder Client, der NIP-99 für echten E-Commerce implementiert, über eine einmalige Kleinanzeige hinaus, musste seine eigenen privaten Konventionen für Versand, Bestellnachrichten und Bewertungen erfinden. Zwei NIP-99-Clients konnten jeweils ein Listing korrekt darstellen und hatten trotzdem keinen gemeinsamen Weg, einen Checkout zwischen ihnen abzuschließen. + +### Gamma Markets: Standardisierung dessen, was NIP-99 ausließ + +Gamma Markets ist der Name, den eine Arbeitsgruppe von Nostr-Marktplatz-Entwicklern, die Teams hinter Shopstr, Cypher, Plebeian Market und Conduit Market, einem gemeinsamen Satz von E-Commerce-Konventionen gab, die auf NIP-99s bestehendem kind-30402-Event aufbauen. Die Spezifikation ist vom kanonischen NIP-99-Dokument über [PR #1784](https://github.com/nostr-protocol/nips/pull/1784) verlinkt und wird in ihrem eigenen Repository gepflegt, [GammaMarkets/market-spec](https://github.com/GammaMarkets/market-spec). + +Gamma Markets fügt zwei eigenständige listing-angrenzende Kinds hinzu. Kind 30405 gruppiert mehrere Listings in eine Produktsammlung und referenziert jedes über ein explizites `a`-Tag: + +```json +{ + "kind": 30405, + "content": "Summer sale picks", + "tags": [ + ["d", "summer-picks"], + ["title", "Summer Sale"], + ["a", "30402::keyboard-mx-blue-01"], + ["shipping_option", "30406::standard-regional"] + ] +} +``` + +Kind 30406 definiert eine Versandoption mit länderspezifischer Preisgestaltung und optionalen gewichts- oder entfernungsbasierten Kostenregeln: + +```json +{ + "kind": 30406, + "content": "Standard Regional Shipping", + "tags": [ + ["d", "standard-regional"], + ["title", "Standard Shipping"], + ["price", "5.99", "USD"], + ["country", "US"], + ["service", "standard"], + ["duration", "24", "72", "H"], + ["weight-max", "30", "kg"] + ] +} +``` + +Bestellerstellung, Zahlungsanforderungen, Status- und Versand-Updates und Zahlungsbelege laufen alle als gewöhnliche [NIP-17](/de/topics/nip-17/) Gift-Wrapped Private Messages, aufgeteilt auf drei Kinds nach Rolle, nicht durch erneutes Wrapping des Transports: kind 14 transportiert freie Käufer/Händler-Kommunikation, kind 16 transportiert jeden Bestellstatus-Übergang (ein `type`-Tag von 1 bis 4 markiert Bestellerstellung, Zahlungsanforderung, Statusupdate oder Versandupdate), und kind 17 transportiert den Zahlungsbeleg des Käufers. Eine Bestellerstellungsnachricht sieht vor dem Gift-Wrapping so aus: + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +Die Bewertung eines abgeschlossenen Kaufs ist ein separater adressierbarer Kind, 31555, der auf das bewertete Listing zurückverweist: + +```json +{ + "kind": 31555, + "content": "Arrived fast, exactly as described.", + "tags": [ + ["d", "a:30402::keyboard-mx-blue-01"], + ["rating", "1", "thumb"], + ["rating", "1.0", "quality"], + ["rating", "0.9", "delivery"] + ] +} +``` + +Bestellnachrichten auf NIP-17 aufzusetzen bedeutet, dass ein Gamma-Markets-Checkout denselben Private-Message-Transport nutzt, den Clients bereits für DMs ausliefern, anstatt einen eigenen Bestellnachrichten-Kind zu erfinden. + +Die zentrale Designentscheidung der Spezifikation ist, dass nichts kaskadiert. Ein Listing, das zu einer Sammlung gehört, referenziert diese explizit mit einem `a`-Tag, anstatt die Versandoptionen oder Beschreibung der Sammlung automatisch zu erben, und eine Versandoption, die ein Listing verwendet, wird auf dieselbe explizite Weise referenziert. Das ist eine bewusste Umkehrung von NIP-15s Stall-Modell, bei dem ein Produkt stillschweigend die Währung und Versandtabelle seines übergeordneten Stalls erbte. Der Kompromiss ist mehr explizites Tagging auf jedem Listing, im Austausch dafür, dass die vollständige Konfiguration eines Listings immer aus dem Event selbst lesbar ist, ohne ein übergeordnetes Objekt zuerst auflösen zu müssen. + +### Wo das in der Praxis auftaucht + +Die [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout)-Arbeit dieser Woche liegt im selben Bestellnachrichten-Territorium, das Gamma Markets standardisiert: [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174)'s ephemerer Schlüssel-Guest-Checkout und [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175)'s Händler-Bestelleingang-Umbau lösen beide das Käufer/Händler-Bestellstatus-Problem, das Gamma Markets' kind-14-, 16- und 17-Nachrichten formalisieren; Conduit Mono betreibt sein eigenes Bestellstatus-Modell neben diesen Kinds, ohne sie direkt zu übernehmen. Shopstr, eines der vier Projekte, die die Spezifikation verfasst haben, hat seine eigene Commerce-Infrastruktur in der letzten Woche ebenfalls vorangetrieben: [PR #568](https://github.com/shopstr-eng/shopstr/pull/568) extrahiert duplizierte NIP-17-Gift-Wrap-Logik in ein gemeinsames Modul, und [PR #567](https://github.com/shopstr-eng/shopstr/pull/567) bringt seinen [NIP-98](/de/topics/nip-98/) HTTP-Auth-Parser auf vollständige Testabdeckung, Wartung an genau den Messaging- und Auth-Schichten, von denen ein Gamma-Markets-Bestellablauf abhängt, um einen Käufer und Händler sicher zu erreichen. + +NIP-15 verlor die Storefront-Rolle, indem es einen Stall und ein Produkt standardisierte und dann Zahlungen, Versand, Bewertungen und Bestellstatus als Anwendungsproblem beließ. Gamma Markets füllt den größten Teil dieser fehlenden Oberfläche, ohne NIP-99s Single-Listing-Form zu verändern, und baut auf Nostrs bestehendem DM-Stack, NIP-17, auf, anstatt eine neue Messaging-Schicht zu erfinden. + +--- + +Das war's für diese Woche. Baut ihr etwas oder habt Neuigkeiten zu teilen? Meldet euch per NIP-17-DM oder findet uns auf Nostr. diff --git a/content/de/topics/concord-protocol.md b/content/de/topics/concord-protocol.md new file mode 100644 index 0000000..5cb18af --- /dev/null +++ b/content/de/topics/concord-protocol.md @@ -0,0 +1,61 @@ +--- +title: "Concord-Protokoll" +date: 2026-07-15 +translationOf: /en/topics/concord-protocol.md +translationDate: 2026-07-15 +draft: false +categories: + - Protocol + - Messaging +--- + +Concord ist ein offenes, MIT-lizenziertes Protokoll für Ende-zu-Ende-verschlüsselte Communities und Kanäle auf Nostr, definiert durch die [CORD-01- bis CORD-07-Spezifikationen](https://github.com/concord-protocol/concord). [Vector](https://github.com/VectorPrivacy/Vector) hat es ab v0.4.0 als Standard-Transport für seine Group-Chats-Funktion übernommen und nennt es in den eigenen Release Notes „our custom messaging protocol", doch die Spezifikation selbst wird getrennt von Vector veröffentlicht und hat bereits unabhängige Implementierungen. + +## Funktionsweise + +Concord zerlegt das, was ein Discord-artiger Community-Server normalerweise tut, in Teile, die niemandem vertrauen müssen: Relays speichern ausschließlich verschlüsselte Blobs, die an rotierende Labels adressiert sind; den Schlüssel eines Raums zu besitzen macht jemanden zum Mitglied; und die Autorität über Rollen, Kicks und Bans ist ein signiertes Roster, das in der Identität des Eigentümers verwurzelt ist und das jeder Client lokal verifiziert, anstatt einem Server zu vertrauen. Jedes dauerhafte Event nutzt denselben dreischichtigen Umschlag: einen kind-1059-Wrap, signiert mit dem abgeleiteten Stream-Key der Ebene, der einen Seal enthält, signiert mit dem echten Schlüssel des Autors, der wiederum einen unsignierten Rumor enthält, der das funktionale Event trägt. Ein Chat-Nachrichten-Rumor ist ein einfaches kind-9-Event: + +```json +{ + "kind": 9, + "pubkey": "", + "content": "Hey chat!", + "tags": [ + ["channel", ""], + ["epoch", "0"] + ] +} +``` + +Control-, Chat- und Guestbook-Verkehr erhalten jeweils ihre eigene [NIP-59](/de/topics/nip-59/) Gift-Wrapped-Ebene, sodass ein Relay, das alle drei hält, eine Control-Nachricht nicht von einer Chat-Nachricht oder einem Gästebuch-Eintrag unterscheiden kann, ohne den Raumschlüssel zu besitzen. Die Spezifikation ist in sieben CORD-Dokumente aufgeteilt: Private Streams (01), Communities und Mitgliedschaft (02), Kanäle (03), Rollen (04), Einladungen (05), Rekeying und Re-Founding zum Ausschluss entfernter Mitglieder (06) sowie Audio/Video über einen Blind-Token-Broker (07). Die Mitgliedschaft selbst hat keine serverseitige Liste: Wer die Ebene entschlüsseln kann, ist Mitglied, und jemanden wirklich zu entfernen bedeutet, die Community auf einen neuen Schlüssel-Epoch zu rollen und diesen nur den Verbliebenen zu übergeben, anstatt eine Zeile aus einer Tabelle zu löschen. + +## Unterschiede zu Marmot + +Concord und [Marmot](/de/topics/marmot/) lösen verschlüsseltes Gruppen-Messaging auf Nostr mit unterschiedlicher Kryptographie für unterschiedliche Gruppenformen, und der Vergleich des Concord-Projekts ist explizit bezüglich der Aufteilung: Marmot legt [MLS](/de/topics/mls/) über Nostr für Forward Secrecy und Post-Compromise Security, unter Verwendung von Pro-Gerät-Key-Packages und geordneten Commits, die die gesamte Gruppe im Gleichschritt voranbringen. Das bietet starke Garantien, zu Kosten, die mit Mitgliedschaftsänderungen skalieren, gut geeignet für kleine, hochsensible Gruppen, in denen Beitritte und Abgänge selten sind. Concord gibt stattdessen jedem Mitglied denselben Raumschlüssel und führt ein Rekeying des gesamten Raums bei Entfernung durch, anstatt pro Commit zu ratcheten, und tauscht damit einige der kryptographischen Garantien von MLS gegen ein Modell, das günstig bleibt, wenn eine Community auf Hunderte oder Tausende von gelegentlichen Mitgliedern mit hoher Fluktuation wächst, genau die Form, die Discord-artige Communities tatsächlich annehmen. + +## Warum Vector gewechselt hat + +Vectors eigene [v0.4.0 Release Notes](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) beschreiben Concord nur als „our custom messaging protocol" für Group Chats, ohne die Begründung direkt zu nennen. Die Passung zur veröffentlichten Begründung von Concord ist dennoch klar: Group Chats in einem Client wie Vector sind genau der Fall mit großer, offener, häufig wechselnder Mitgliedschaft, in dem der Pro-Gerät-MLS-State von Marmot zum teureren Weg wird, und Concords asynchrones, jederzeit beitretbares Design ist genau für diesen Fall gebaut. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) hat Marmot für Group Chats zugunsten von Concord abgelöst, und bestehende Marmot-Gruppenverläufe wurden beim Wechsel nicht übernommen. [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) lieferte vier Tage später „Concord v2" mit Datenschutz- und Stabilitätsverbesserungen. Innerhalb derselben Woche [mergte Amethyst seine eigene Clean-Room-, drahtkompatible Concord-Implementierung](https://github.com/vitorpamplona/amethyst/pull/3566), und Soapbox' Discord-artiger Client [Armada](https://gitlab.com/soapbox-pub/armada) baut sein Communities-Feature bereits auf derselben Spezifikation als Referenzimplementierung auf. Drei unabhängige Clients, die innerhalb von Tagen auf eine offene Spezifikation konvergieren, sind ein schneller Weg zu echter Client-übergreifender Interoperabilität, lohnenswert zu verfolgen im Vergleich dazu, wie viel vom Rest der Nostr-Gruppen-Chat-Clients auf Marmot bleibt. + +## Implementierungen + +- [Vector](https://github.com/VectorPrivacy/Vector) - Single-Binary, datenschutzorientierter Nostr-Messenger; erster ausgelieferter Concord-Client, in v0.4.0 +- [Armada](https://gitlab.com/soapbox-pub/armada) (Soapbox) - Discord-artiger Community-Client; Referenzimplementierung, Backend im separaten `armada-relay`-Repository +- [Amethyst](https://github.com/vitorpamplona/amethyst) - funktionsreicher Android- und Multiplattform-Nostr-Client; Clean-Room-Reimplementierung, drahtkompatibel mit Armada ([PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566)) + +--- + +**Primärquellen:** +- [Concord-Protokoll-Spezifikationen (CORD-01 bis CORD-07)](https://github.com/concord-protocol/concord) +- [Vector v0.4.0 Release Notes](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) +- [Vector v0.4.1 Release Notes](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) +- [Amethyst PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) + +**Erwähnt in:** +- [Newsletter #31: Vector v0.4.0 moves Group Chats from Marmot to Concord, and Amethyst ships its own Concord client days later](/de/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) +- [Newsletter #31: Amethyst ships a clean-room Concord implementation for end-to-end encrypted communities](/de/newsletters/2026-07-15-newsletter/#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) + +**Siehe auch:** +- [Marmot-Protokoll](/de/topics/marmot/) +- [MLS (Message Layer Security)](/de/topics/mls/) +- [NIP-46: Nostr Connect](/de/topics/nip-46/) diff --git a/content/de/topics/gamma-markets.md b/content/de/topics/gamma-markets.md new file mode 100644 index 0000000..1b85102 --- /dev/null +++ b/content/de/topics/gamma-markets.md @@ -0,0 +1,69 @@ +--- +title: "Gamma Markets" +date: 2026-07-15 +translationOf: /en/topics/gamma-markets.md +translationDate: 2026-07-15 +draft: false +categories: + - Commerce + - Marketplace + - Protocol +--- + +Gamma Markets ist ein Satz von E-Commerce-Konventionen, die direkt auf [NIP-99](/de/topics/nip-99/) Classified Listings aufbauen. Sie wurden gemeinschaftlich von einer Arbeitsgruppe von Nostr-Marktplatz-Entwicklern entwickelt: den Teams hinter Shopstr, Cypher, Plebeian Market und Conduit Market. Gamma Markets füllt die Versand-, Bestellablauf-, Sammlungs- und Bewertungskonventionen, die NIP-99 selbst nicht definiert. + +## Funktionsweise + +Gamma Markets fügt fünf Event-Kinds rund um das bestehende kind-`30402`-Listing-Event von NIP-99 hinzu, ohne dessen Form zu ändern: + +- **Kind 30405** - Produktsammlungen, die mehrere Listings über `a`-Tags gruppieren +- **Kind 30406** - Versandoptionen mit länderspezifischer Preisgestaltung und optionalen gewichts- oder entfernungsbasierten Kostenregeln +- **Kind 16** - Bestellnachrichten: Erstellung (Typ 1), Zahlungsanforderungen (Typ 2), Statusaktualisierungen (Typ 3) und Versandaktualisierungen (Typ 4) +- **Kind 14** - Allgemeine Kommunikation zwischen Käufer und Händler +- **Kind 17** - Zahlungsbelege +- **Kind 31555** - Produktbewertungen, adressiert an einen bestimmten Verkäufer-pubkey und Listing-`d`-Tag + +Die Zahlungspräferenzen eines Händlers werden über ein `payment_preference`-Tag in den kind-`0`-Profilmetadaten deklariert, und Clients entdecken kompatible Apps über [NIP-89](/de/topics/nip-89/)-Anwendungsempfehlungen. Die Bestellkommunikation baut auf [NIP-17](/de/topics/nip-17/) Private Messages auf, ohne ein eigenes Verschlüsselungsschema. + +Die zentrale Designentscheidung der Spezifikation ist, dass nichts kaskadiert: Ein Listing, das zu einer Sammlung gehört oder eine Versandoption nutzt, referenziert diese explizit über ein `a`-Tag, anstatt die Einstellungen des übergeordneten Elements automatisch zu erben. Das ist eine bewusste Abkehr vom älteren [NIP-15](/de/topics/nip-15/)-Stall-Modell, bei dem ein Produkt stillschweigend die Währung und Versandtabelle seines Stalls erbte. + +### Beispiel: Bestellerstellung (kind 16, Typ 1) + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +## Warum es wichtig ist + +NIP-99 allein standardisiert nur das Listing selbst, eine signierte, adressierbare Kleinanzeige. Vor Gamma Markets erfand jeder Client, der echten E-Commerce auf NIP-99 aufbaute, seine eigenen privaten Konventionen für Versand, Checkout und Bewertungen, was bedeutete, dass zwei NIP-99-konforme Clients jeweils ein Listing korrekt darstellen konnten, aber keinen gemeinsamen Weg hatten, eine Bestellung zwischen ihnen abzuschließen. Gamma Markets schließt diese Lücke, ohne das NIP-99-Listing-Format selbst zu verändern, sodass bestehende NIP-99-Listings ohne Änderung gültig bleiben. + +## Implementierungen + +- [Shopstr](https://github.com/shopstr-eng/shopstr) - Nostr-Marktplatz, eines der vier Projekte, die die Spezifikation verfasst haben +- [Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) - Marktplatz-Protokoll, das seinen eigenen Bestellstatus- und Checkout-Ablauf im selben Designraum aufbaut + +--- + +**Primärquellen:** +- [Gamma Markets Spezifikations-Repository](https://github.com/GammaMarkets/market-spec) +- [NIP-99 E-Commerce-Anwendungsfall-Erweiterung, PR #1784](https://github.com/nostr-protocol/nips/pull/1784) - gemergter Link vom kanonischen NIP-99-Dokument zur Gamma-Markets-Spezifikation + +**Erwähnt in:** +- [Newsletter #31: NIP Deep Dive: NIP-99 und die Gamma-Markets-Commerce-Erweiterung](/de/newsletters/2026-07-15-newsletter/#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) + +**Siehe auch:** +- [NIP-99: Classified Listings](/de/topics/nip-99/) +- [NIP-15: Nostr Marketplace](/de/topics/nip-15/) +- [NIP-17: Private Direct Messages](/de/topics/nip-17/) diff --git a/content/de/topics/nip-4e.md b/content/de/topics/nip-4e.md new file mode 100644 index 0000000..340cfda --- /dev/null +++ b/content/de/topics/nip-4e.md @@ -0,0 +1,46 @@ +--- +title: "NIP-4E: Entkopplung von Verschlüsselung und Identität" +date: 2026-07-15 +translationOf: /en/topics/nip-4e.md +translationDate: 2026-07-15 +draft: false +categories: + - NIP + - Protocol + - Encryption +--- + +NIP-4E ist ein offener Entwurf, vorgeschlagen von fiatjaf, zum Teilen privater Daten zwischen den eigenen Geräten eines Nutzers, ohne dass jedes Gerät den Haupt-Nostr-Identitätsschlüssel des Nutzers besitzen muss. Es ist nicht gemergt und bleibt ein `draft`/`optional`-Vorschlag. + +## Das adressierte Problem + +Viele bestehende NIPs, darunter NIP-51-Listen und NIP-60-Cashu-Wallets, verschlüsseln Daten vom Nutzer an sich selbst unter Verwendung des Identitätsschlüssels, damit sie später auf jedem Gerät wieder gelesen werden können. Das funktioniert nicht mehr, wenn der Identitätsschlüssel nicht direkt zugänglich ist, beispielsweise wenn ein Remote Signer durch FROST-Threshold-Shares, MuSig2 oder ein gehostetes Secure Enclave geschützt ist, da Ver- und Entschlüsselung dann jedes Mal einen Roundtrip zu diesem Signer erfordern. Offline-Verschlüsselung wird ebenfalls unmöglich, wenn der Signaturschlüssel in einem Remote Bunker liegt. + +## Funktionsweise + +NIP-4E trennt einen gerätespezifischen „Client Key" von einem gemeinsamen „Encryption Key", der nicht der Identitätsschlüssel des Nutzers ist: + +1. Der erste Client, den ein Nutzer einrichtet, generiert ein zufälliges Verschlüsselungs-Schlüsselpaar und kündigt dessen öffentliche Hälfte in einem `kind:10044`-Event an, das mit dem Identitätsschlüssel des Nutzers signiert ist. +2. Jeder andere Client, der Daten für diesen Nutzer ver- oder entschlüsseln möchte, berechnet sein Diffie-Hellman-Shared-Secret gegen den angekündigten Verschlüsselungsschlüssel statt gegen den Identitätsschlüssel. +3. Wenn ein zweites Gerät einen neuen Client installiert, generiert dieser Client seinen eigenen lokalen „Client Key" und veröffentlicht eine `kind:4454`-Ankündigung (ebenfalls mit dem Identitätsschlüssel des Nutzers signiert), die den ersten Client bittet, den Verschlüsselungsschlüssel zu teilen. +4. Der ursprüngliche Client erkennt die neue `kind:4454`-Ankündigung, verschlüsselt den gemeinsamen Verschlüsselungsschlüssel an den Schlüssel des neuen Clients mittels [NIP-44](/de/topics/nip-44/) und veröffentlicht ihn, damit der neue Client ihn entschlüsseln und fortan verwenden kann. + +Das Ergebnis ist, dass Ver- und Entschlüsselung niemals den Identitätsschlüssel-Signer abfragen müssen, sobald ein Client den gemeinsamen Verschlüsselungsschlüssel lokal besitzt, und ein Remote-Signer-Setup (FROST, MuSig2, gehostetes Enclave) für die Identität verwendet werden kann, während gewöhnliche Verschlüsselung schnell bleibt und offline funktioniert. + +## Warum es wichtig ist + +NIP-4E wird als Grundlage für andere Vorschläge zitiert, die einen laufwerk- oder kontoweiten symmetrischen Schlüssel benötigen, ohne bei jedem Ver-/Entschlüsselungsaufruf auf einen Remote Signer angewiesen zu sein, darunter ein Vorschlag für ein privates verschlüsseltes Laufwerk ([PR #2412](https://github.com/nostr-protocol/nips/pull/2412)) und eine engere NIP-17-spezifische Version derselben Idee ([PR #2361](https://github.com/nostr-protocol/nips/pull/2361)). Beide bleiben neben NIP-4E selbst offen, was dies zu einem aktiven, noch nicht abgeschlossenen Bereich des Protokolls macht, nicht zu einem fertigen Baustein. + +--- + +**Primärquellen:** +- [NIP-4E-Entwurf, PR #1647](https://github.com/nostr-protocol/nips/pull/1647) + +**Erwähnt in:** +- [Newsletter #31: Open: private encrypted drive extends NIP-4E](/de/newsletters/2026-07-15-newsletter/#open-private-encrypted-drive-extends-nip-4e) + +**Siehe auch:** +- [NIP-44: Encrypted Payloads](/de/topics/nip-44/) +- [NIP-17: Private Direct Messages](/de/topics/nip-17/) +- [NIP-46: Nostr Connect](/de/topics/nip-46/) +- [FROST](/de/topics/frost/) diff --git a/content/de/topics/proofmode.md b/content/de/topics/proofmode.md new file mode 100644 index 0000000..1262eec --- /dev/null +++ b/content/de/topics/proofmode.md @@ -0,0 +1,36 @@ +--- +title: "ProofMode" +date: 2026-07-15 +translationOf: /en/topics/proofmode.md +translationDate: 2026-07-15 +draft: false +categories: + - Media + - Provenance +--- + +[ProofMode](https://proofmode.org/) ist ein Open-Source-Toolkit für Medien-Provenienz, entwickelt von Guardian Project, WITNESS und Okthanks, das verifizierbare Authentizitäts- und Chain-of-Custody-Daten an Fotos und Videos im Moment der Aufnahme anfügt. Es ist nicht Nostr-spezifisch; Nostr-Clients, die ProofMode-Daten mitführen, integrieren einen bestehenden externen Standard und keine neue Protokollschicht. + +## Funktionsweise + +Die Capture-Komponente von ProofMode bettet Provenienz-Metadaten direkt in Mediendateien während der Aufnahme ein und unterstützt dieselben interoperablen Standards, die von der Content Authenticity Initiative (CAI), Content Credentials (CR) und C2PA verwendet werden. Eine separate Verify-Komponente prüft Audio-, Bild- und Videodateien auf Anzeichen von KI-Generierung oder nachträglicher Bearbeitung in diesen Metadaten, und eine Preserve-Komponente übernimmt die redundante, dezentralisierte Web-Speicherung der zugrunde liegenden Nachweisdaten für die Langzeitarchivierung. Ein Develop SDK ermöglicht es Apps, Aufnahme und Verifikation zu integrieren, ohne das Provenienzformat selbst aufzubauen. + +## Warum es wichtig ist + +Für einen Nostr-Video- oder -Bild-Client bedeutet das Mitführen von ProofMode-Daten, dass ein Betrachter eine externe, plattformübergreifende Möglichkeit hat zu prüfen, ob ein Medienstück wie behauptet aufgenommen wurde und seitdem nicht stillschweigend verändert wurde, ohne sich auf den veröffentlichenden Client oder Relay als Vertrauensquelle zu verlassen. Diese Unterscheidung ist am wichtigsten für eine heruntergeladene oder neu kodierte Kopie eines Clips: Provenienzdaten, die den Download und etwaiges Wasserzeichen überleben, das ein Client anwendet, machen die Attestierung auch noch überprüfbar, nachdem die Datei die App verlassen hat, die sie erzeugt hat. + +## Implementierungen + +- [Divine](https://github.com/divinevideo/divine-mobile) - Kurzvideo-Nostr-Client; führt ProofMode-Provenienzdaten durch wasserzeichenmarkierte Clip-Downloads + +--- + +**Primärquellen:** +- [ProofMode](https://proofmode.org/) + +**Erwähnt in:** +- [Newsletter #17](/de/newsletters/2026-04-29-newsletter/) +- [Newsletter #31: Divine Mobile 1.0.16 ships a deeper video editor, at-rest encryption, and ProofMode provenance](/de/newsletters/2026-07-15-newsletter/#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) + +**Siehe auch:** +- [Blossom](/de/topics/blossom/) From 03043c6b797047d6a1765f082cfe2f8c744a1560 Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Thu, 16 Jul 2026 06:34:09 +0000 Subject: [PATCH 04/10] Add French translation for Newsletter #31 and topic pages --- .../fr/newsletters/2026-07-15-newsletter.md | 300 ++++++++++++++++++ content/fr/topics/concord-protocol.md | 61 ++++ content/fr/topics/gamma-markets.md | 69 ++++ content/fr/topics/nip-4e.md | 46 +++ content/fr/topics/proofmode.md | 36 +++ 5 files changed, 512 insertions(+) create mode 100644 content/fr/newsletters/2026-07-15-newsletter.md create mode 100644 content/fr/topics/concord-protocol.md create mode 100644 content/fr/topics/gamma-markets.md create mode 100644 content/fr/topics/nip-4e.md create mode 100644 content/fr/topics/proofmode.md diff --git a/content/fr/newsletters/2026-07-15-newsletter.md b/content/fr/newsletters/2026-07-15-newsletter.md new file mode 100644 index 0000000..a3b1d9e --- /dev/null +++ b/content/fr/newsletters/2026-07-15-newsletter.md @@ -0,0 +1,300 @@ +--- +title: "Nostr Compass #31" +date: 2026-07-15 +publishDate: 2026-07-15 +translationOf: /en/newsletters/2026-07-15-newsletter.md +translationDate: 2026-07-15 +draft: false +type: newsletters +description: "Vector v0.4.0 retire Marmot pour les chats de groupe au profit du protocole ouvert Concord et livre Concord v2 quelques jours plus tard, Amethyst fusionne sa propre implémentation indépendante de Concord, Sonar se sépare de Bitchat avec une alpha multiplateforme et une spécification de packs de stickers, Divine Mobile 1.0.16 livre le chiffrement au repos et la provenance ProofMode, Bitchat 1.7.0 ajoute la voix push-to-talk en direct, et MDK v0.9.4 borne la connexion par signeur externe." +--- + +Bon retour sur Nostr Compass, votre guide hebdomadaire sur Nostr. + +**Cette semaine :** [Vector v0.4.0](#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) retire [Marmot](/fr/topics/marmot/) comme transport par défaut pour les Group Chats au profit de [Concord](/fr/topics/concord-protocol/), un protocole communautaire ouvert sous licence MIT également utilisé par Armada de Soapbox, et livre Concord v2 quatre jours plus tard avec un sélecteur de commandes slash pour les bots, un minuteur d'autodestruction et les badges NIP-58. [Amethyst fusionne sa propre implémentation Concord indépendante et compatible au niveau du protocole](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) la même semaine. [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) se sépare de Bitchat avec une alpha multiplateforme et est la source de spécification citée pour la proposition de kinds de packs de stickers de cette semaine. [Divine Mobile 1.0.16](#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) livre un éditeur vidéo plus complet, le chiffrement au repos et la provenance ProofMode qui survit aux téléchargements de clips filigranés. [Bitchat v1.7.0](#bitchat-v170-adds-live-push-to-talk-voice-for-dms-and-the-public-mesh) ajoute la voix push-to-talk en direct pour les DMs et le push-to-talk signé sur le mesh public. [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) borne la connexion par signeur externe et ajoute la persistance des brouillons, poursuivant sa passe de durcissement la même semaine où Vector s'éloigne de la spécification pour le chat de groupe. + +Les versions taguées apportent [n_cord v1.1](#n_cord-v11-adds-nsec-bunker-support) ajoutant le support NSEC Bunker, [cdk v0.17.3](#cdk-v0173-adds-nip-47-wallet-service-support-across-cdk-cdk-nwc-and-cdk-ffi) ajoutant le support du service de portefeuille NIP-47 à travers cdk, cdk-nwc et cdk-ffi, [Coop Mobile v0.2.4](#coop-mobile-v024-improves-nostr-connect-and-adds-ncryptsec1-import) améliorant Nostr Connect et ajoutant l'import ncryptsec1, [Nmail v0.14.0](#nmail-v0140-ships-on-macos-with-scheduled-send-and-push-notifications) arrivant sur macOS avec l'envoi programmé, [Nostrord v2.2.0](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages) ajoutant un interrupteur principal pour les DMs, [Nostr WoT 0.3.86](#nostr-wot-0386-hardens-key-backups-and-signing-prompts) durcissant les sauvegardes de clés au format NIP-49, [Keep Android v1.1.8](#keep-android-v118-adds-first-run-frost-onboarding) ajoutant l'onboarding FROST au premier lancement, [Noscall v0.6.0](#noscall-v060-adds-a-cashu-wallet-and-relay-based-push-notifications) ajoutant un portefeuille Cashu et les notifications push via relay, [Kubo](#kubo-ships-tablet-mode-and-group-chat-photos) ajoutant le mode tablette et les photos en chat de groupe, et [Nostr Codex Phone v0.2.9](#nostr-codex-phone-v029-adds-gitdiffread-file-helper-requests) ajoutant les requêtes d'aide git, diff et lecture de fichier. + +Du côté des changements non publiés, [Amethyst](#amethyst-lets-accounts-nickname-contacts-with-encrypted-nip-85-cards) permet aux comptes de donner des surnoms aux contacts avec des cartes NIP-85 chiffrées à travers 54 PRs fusionnées, [Zap Cooking](#zap-cooking-ships-my-kitchen-phase-3-and-fixes-an-ndk-pool-quorum-bug) livre My Kitchen Phase 3 et corrige un bug de quorum de pool NDK, [Kehto](#kehto-streams-outbox-reads-before-relay-discovery) diffuse les lectures outbox avant la fin de la découverte de relays, [Wired et TAO](#wired-and-tao-add-nip-57-creator-revenue-sharing) ajoutent le partage de revenus créateur NIP-57, [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) reconstruit sa boîte de réception de commandes marchandes autour du paiement invité éphémère, [Buzz](#buzz-hardens-channel-creator-provisioning-around-kind-39002) durcit le provisionnement du créateur de canal à travers 240 PRs fusionnées, et [Nostr Docs](#nostr-docs-adopts-a-nip-49-signer-with-multi-account-and-qr-pairing) adopte un signeur NIP-49 avec multi-compte et appairage QR. Nouvellement suivis cette semaine : [OpenDiscord v1.0.1](#opendiscord-v101-launches-as-a-discord-style-client-on-nostr), [Auditable Voting v0.1.140](#auditable-voting-v01140-aligns-organiser-voter-and-audit-proxy-roles), et le choix Découverte [Cambium v0.3.2](#cambium-v032-pairs-with-heartwood-as-a-keyless-nip-55-signer), un signeur NIP-55 sans clé qui redirige vers un compagnon matériel Heartwood. + +Le dépôt NIPs ne fusionne rien au cours de la dernière semaine et ouvre six propositions : [kind:10011 ensembles de suivi favoris](#open-kind10011-favorite-follow-sets), un [drive privé chiffré étendant NIP-4E](#open-private-encrypted-drive-extends-nip-4e), [NIP-DA partage de données privées avec permissions](#open-nip-da-permissioned-private-data-sharing), [kinds de packs de stickers 10031 et 30031](#open-sticker-pack-kinds-10031-and-30031), [épinglage de messages NIP-29](#open-nip-29-message-pinning-with-kind9010-and-kind39005), et une [restructuration de la découverte de relays NIP-66](#open-nip-66-relay-discovery-restructure). L'analyse approfondie couvre [NIP-99 et l'extension commerce Gamma Markets](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension). + +--- + +## Articles principaux + +### Vector v0.4.0 fait passer les Group Chats de Marmot à Concord, et Amethyst livre son propre client Concord quelques jours plus tard + +[Vector](https://github.com/VectorPrivacy/Vector) est un messager Nostr construit autour d'un client à binaire unique, axé sur la vie privée, pour les DMs et les chats de groupe. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) réécrit le moteur de messagerie de l'application en une bibliothèque partagée `vector-core` et, dans la même version, retire [Marmot](/fr/topics/marmot/) (MLS-over-Nostr) comme transport par défaut pour les Group Chats au profit de [Concord](/fr/topics/concord-protocol/), un protocole communautaire chiffré de bout en bout ; l'historique existant des groupes Marmot n'est pas transféré, et les notes de version demandent aux utilisateurs de sauvegarder toute donnée de groupe Marmot avant la mise à jour. Les propres notes de version de Vector décrivent Concord comme « our custom messaging protocol », mais les [spécifications CORD-01 à CORD-07](https://github.com/concord-protocol/concord) sous-jacentes sont publiées séparément, sous licence MIT, et déjà implémentées en dehors de Vector : le client de type Discord de Soapbox, [Armada](https://gitlab.com/soapbox-pub/armada), construit sa fonctionnalité Communities sur la même spécification Concord, et un jour plus tard, [Amethyst a fusionné sa propre implémentation Concord indépendante et compatible au niveau du protocole](https://github.com/vitorpamplona/amethyst/pull/3566), couverte en détail ci-dessous. La même version de Vector ajoute le routage Tor optionnel pour tout le trafic, la connexion par signeur distant [NIP-46](/fr/topics/nip-46/) par QR ou URI bunker collée, les comptes multiples avec un sélecteur intégré, et les packs d'emoji personnalisés partagés entre clients. La suppression de message retire un message pour les deux côtés dans les DMs et les chats de groupe, et Vector garde délibérément la clé de signature éphémère au lieu de suivre le flux de suppression standard [NIP-17](/fr/topics/nip-17/), un écart motivé par la vie privée que le projet signale explicitement dans les notes de version. Quatre jours plus tard, [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) livre **Concord v2**, décrit comme apportant des améliorations majeures de confidentialité et de stabilité aux Communities tout en gardant celles existantes fonctionnelles, aux côtés d'un sélecteur de commandes slash de type Discord pour les bots avec des paramètres typés, d'un minuteur d'autodestruction par chat, et d'un système de badges NIP-58 pour les chasseurs de bugs. L'abandon de Marmot pour le chat de groupe intervient la même semaine où [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) ci-dessous continue d'investir dans la spécification. + +### Amethyst livre une implémentation Concord indépendante pour les communautés chiffrées de bout en bout + +[Amethyst](https://github.com/vitorpamplona/amethyst) est un client Nostr Android et multiplateforme riche en fonctionnalités. [PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) ajoute une implémentation complète de [Concord](/fr/topics/concord-protocol/) (CORD-01 à CORD-07) couvrant les communautés sans serveur, chiffrées de bout en bout : les plans gift-wrapped de contrôle, de chat et de livre d'or sur des relays ordinaires, l'application des rôles et des bannissements enracinée dans le propriétaire que chaque client vérifie localement au lieu de faire confiance à un serveur, et le renouvellement de clé pour couper l'accès aux membres retirés. Le code du protocole et de la cryptographie réside dans `quartz/`, l'état et les modèles de vue dans `commons/`, et les écrans et la navigation dans `amethyst/` pour Android, avec des verbes CLI légers sous `cli/` ; il n'y a pas encore d'interface bureau, puisque la logique partagée se trouve dans `quartz`/`commons` pour que Desktop l'adopte ultérieurement. L'implémentation est indépendante : construite à partir des spécifications CORD publiques et des constantes de protocole observées, sous la propre licence MIT d'Amethyst, distincte du code AGPL-3.0 d'Armada. Les propres valeurs de vecteurs de test d'Armada ont été portées dans les tests unitaires de Quartz pour confirmer que les deux clients interopèrent réellement au niveau du protocole, donnant à Concord trois implémentations indépendantes en quelques jours : Vector livrant en premier, Armada comme client de référence de Soapbox, et maintenant la construction d'Amethyst à partir des spécifications. + +### Sonar se sépare de Bitchat avec une alpha multiplateforme et une spécification de packs de stickers + +[Sonar](https://sonarprivacy.xyz/) est un messager et portefeuille Bluetooth-mesh-plus-Nostr issu de Bitchat, avec des DMs de groupe Marmot interopérables avec White Noise. Le code réside sur [hedwig-corp/bitchat-to-sonar](https://github.com/hedwig-corp/bitchat-to-sonar). [v0.1-alpha.7](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.7) ajoute le fenêtrage borné de transcription de type Signal pour que les performances d'ouverture et de défilement restent local-first, synchronise l'état de découverte de proximité entre pairs, et corrige les uploads média Blossom qui échouaient sur la gestion du content-type et du statut HTTP ; la précédente [alpha.6](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.6) drainait les events Marmot en direct pour un rafraîchissement de chat plus rapide et comblait les écarts de parité de fonctionnalités Android-iOS à travers les appels, la messagerie, le portefeuille et les push. Sonar est également la source de spécification citée pour [PR #2410](#open-sticker-pack-kinds-10031-and-30031), qui enregistre les types d'events de packs de stickers sous la propre spécification « Sonar Stickers » du projet, donnant à ce lancement un lien direct vers les travaux de protocole de cette semaine. + +### Divine Mobile 1.0.16 livre un éditeur vidéo plus complet, le chiffrement au repos et la provenance ProofMode + +[Divine](https://github.com/divinevideo/divine-mobile) est un client de vidéo courte construit sur Nostr avec curation de flux par Web-of-Trust. [v1.0.16](https://github.com/divinevideo/divine-mobile/releases/tag/1.0.16), la première version taguée depuis le #30, ajoute les transitions de clips, la lecture inversée, un enregistreur de voix off et des marqueurs de beat sur la timeline à l'éditeur vidéo, aux côtés d'un contrôle d'ajustement du flux qui permet à un utilisateur de balayer pour ajuster les recommandations directement au lieu de les laisser à des signaux d'engagement opaques. La version active également le chiffrement au repos pour les données locales, ajoute les uploads en arrière-plan qui survivent à la suspension de l'application, et transporte les données de provenance [ProofMode](/fr/topics/proofmode/) lorsqu'un clip filigrané est téléchargé afin que l'attestation de fabrication humaine ne soit pas supprimée en transit. Divine livre aussi de nouvelles protections pour les comptes de moins de 16 ans et étend la localisation à 17 langues et 284 chaînes traduites. + +### Bitchat v1.7.0 ajoute la voix push-to-talk en direct pour les DMs et le mesh public + +[Bitchat](https://github.com/permissionlesstech/bitchat) est une application de chat Bluetooth-mesh avec une passerelle optionnelle vers les relays Nostr. [v1.7.0](https://github.com/permissionlesstech/bitchat/releases/tag/v1.7.0), publiée le soir de la publication du #30, ajoute la voix push-to-talk en direct dans [PR #1403](https://github.com/permissionlesstech/bitchat/pull/1403) qui diffuse l'audio pendant que l'expéditeur maintient le bouton et se rabat sur une note vocale si le flux tombe, plus le push-to-talk signé sur le mesh public dans [PR #1406](https://github.com/permissionlesstech/bitchat/pull/1406) pour que les rafales vocales en direct sur le canal mesh partagé portent l'authentification de l'expéditeur. La version corrige aussi la rotation d'identifiant pair en reliant le lien lors d'une ré-annonce vérifiée, reconnaissant le même pair sous son nouvel identifiant ([PR #1401](https://github.com/permissionlesstech/bitchat/pull/1401)), et les messages directs vers un pair actuellement injoignable se mettent maintenant en file d'attente avec une livraison store-and-forward au lieu d'échouer purement et simplement ([PR #1415](https://github.com/permissionlesstech/bitchat/pull/1415)). Cela poursuit directement la couverture du #30 sur le proof-of-work [NIP-13](/fr/topics/nip-13/) de la v1.6.0 et le travail de passerelle mesh-vers-Nostr. + +### MDK v0.9.4 borne la connexion par signeur externe et ajoute la persistance des brouillons + +[MDK](https://github.com/marmot-protocol/mdk) est le SDK de référence pour le protocole [Marmot](/fr/topics/marmot/), la couche de messagerie MLS-over-Nostr dont le #30 avait couvert l'adoption de la spécification. [v0.9.4](https://github.com/marmot-protocol/mdk/releases/tag/v0.9.4) borne les étapes d'annuaire consultatif qu'un client traverse lors de la connexion par signeur externe dans [PR #793](https://github.com/marmot-protocol/mdk/pull/793), empêchant une boucle de retry non bornée lorsqu'un signeur distant est lent ou non réactif. La même version ajoute la persistance des brouillons de messages et les liaisons de site web de profil dans [PR #812](https://github.com/marmot-protocol/mdk/pull/812), poursuivant la passe de durcissement incrémental que MDK mène depuis la v0.9.0. + +--- + +## Versions taguées + +### n_cord v1.1 ajoute le support NSEC Bunker + +[n_cord](https://github.com/0n4t3/n_cord) est un client de chat propulsé par Nostr inspiré de Discord et IRC. [v1.1](https://github.com/0n4t3/n_cord/releases/tag/v1.1) ajoute le support [NIP-46](/fr/topics/nip-46/) NSEC Bunker aux côtés d'une correction de bug de gestion des réponses. + +### cdk v0.17.3 ajoute le support du service de portefeuille NIP-47 à travers cdk, cdk-nwc et cdk-ffi + +[cdk](https://github.com/cashubtc/cdk) est un kit de développement Cashu ; cette version est Bitcoin/Lightning uniquement à la plupart des égards, mais [v0.17.3](https://github.com/cashubtc/cdk/releases/tag/v0.17.3) ajoute le support du service [NIP-47](/fr/topics/nip-47/) (Nostr Wallet Connect) avec un crate de service NWC dédié, une intégration portefeuille, des bindings FFI pour `cdk-ffi`, et une couverture de tests de bout en bout, donnant aux portefeuilles Cashu construits sur cdk une surface Nostr Wallet Connect standard. + +### Coop Mobile v0.2.4 améliore Nostr Connect et ajoute l'import ncryptsec1 + +[Coop Mobile](https://git.reya.su/reya/coop-mobile) est un client de messagerie privée [NIP-17](/fr/topics/nip-17/) pour plateformes mobiles. [v0.2.4](https://git.reya.su/reya/coop-mobile/releases/tag/v0.2.4) améliore son flux [NIP-46](/fr/topics/nip-46/) Nostr Connect, corrige un indicateur de chargement qui restait bloqué en permanence sur certaines connexions, et ajoute le support d'import du format de clé chiffrée [NIP-49](/fr/topics/nip-49/) `ncryptsec1` aux côtés d'un écran d'import d'identité redessiné. + +### Nmail v0.14.0 arrive sur macOS avec l'envoi programmé et les notifications push + +[Nmail](https://github.com/nogringo/nostr-mail-client) est un client mail construit sur Nostr ; [v0.14.0](https://github.com/nogringo/nostr-mail-client/releases/tag/v0.14.0) apporte l'application sur macOS, ajoute l'envoi programmé avec une boîte aux lettres Programmé dédiée pour les messages en file d'attente, et ajoute les notifications push. La version bascule aussi la résolution d'identifiant Nostr du carnet d'adresses vers le résolveur [NIP-05](/fr/topics/nip-05/) de NDK en remplacement d'une implémentation sur mesure. + +### Nostrord v2.2.0 ajoute un interrupteur principal DM et des messages directs plus riches + +[Nostrord](https://github.com/nostrord/nostrord) est un client de chat de groupe basé sur relay [NIP-29](/fr/topics/nip-29/) pour Android, iOS, web et bureau. [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) ajoute un interrupteur principal pour désactiver toutes les fonctionnalités de messages directs d'un coup ([PR #175](https://github.com/nostrord/nostrord/pull/175)) et livre des « messages directs plus riches » ([PR #186](https://github.com/nostrord/nostrord/pull/186)), poursuivant la couverture du #30 sur la version intégrant le pool de relays et détectant les WebSockets zombies. + +### Nostr WoT 0.3.86 durcit les sauvegardes de clés et les invites de signature + +[Nostr WoT](https://github.com/nostr-wot/nostr-wot-extension) est une extension de navigateur associant une identité Nostr à un portefeuille Lightning. [v0.3.86](https://github.com/nostr-wot/nostr-wot-extension/releases/tag/v0.3.86) migre les sauvegardes de clés chiffrées vers le format standard [NIP-49](/fr/topics/nip-49/), fait afficher l'event complet et tous les tags dans les invites de signature au lieu d'un résumé, vérifie les données de relay par rapport à leur signature, et cesse d'exposer l'identité active lors du changement de compte. L'extension supprime aussi la permission de navigateur `scripting` inutilisée. + +### Keep Android v1.1.8 ajoute l'onboarding FROST au premier lancement + +[Keep](https://github.com/privkeyio/keep-android) est un signeur Android construit sur les parts de clé FROST à seuil. [v1.1.8](https://github.com/privkeyio/keep-android/releases/tag/v1.1.8) ajoute un flux de premier lancement qui explique les parts de clé FROST et permet à un nouvel utilisateur de choisir une politique de signature Manual, Basic ou Auto avant l'arrivée de la première demande de signature, le premier onboarding côté Android pour le modèle de signature à seuil du crate keep-mobile sous-jacent. + +### Noscall v0.6.0 ajoute un portefeuille Cashu et les notifications push via relay + +[Noscall](https://github.com/sanah9/noscall) est une application d'appels audio et vidéo sécurisés construite sur Nostr. [v0.6.0](https://github.com/sanah9/noscall/releases/tag/v0.6.0-release) ajoute un portefeuille Cashu rattaché au compte avec des soldes multi-mint, l'envoi et la réception d'ecash, et le paiement et la réception Lightning avec persistance des quotes. La version migre aussi les notifications push Android de Firebase Cloud Messaging vers un chemin de livraison basé sur les relays Nostr via UnifiedPush, et améliore la fiabilité des push iOS VoIP et APNs lors des retries de connexion. + +### Kubo livre le mode tablette et les photos en chat de groupe + +[Kubo](https://github.com/JeroenOnNostr/kubo) est une plateforme vidéo Nostr adaptée aux enfants avec curation de flux par Web-of-Trust. [kubo-v2026.07.05](https://github.com/JeroenOnNostr/kubo/releases/tag/kubo-v2026.07.05) ajoute une grille tablette optionnelle pour le flux enfant et le support des photos jointes aux messages de chat de groupe, plus des corrections pour le bouton d'inscription caché derrière le clavier à l'écran sur Android. + +### Nostr Codex Phone v0.2.9 ajoute les requêtes d'aide git/diff/lecture de fichier + +[Nostr Codex Phone](https://github.com/tidley/nostr-codex-phone) est une surface de contrôle mobile pour un worker d'assistant de codage local communiquant par DMs Nostr chiffrés. [v0.2.9](https://github.com/tidley/nostr-codex-phone/releases/tag/v0.2.9) ajoute les actions d'outils mobiles OpenCode incluant les requêtes d'aide git, diff, lecture de fichier, status et historique, des améliorations d'épinglage et de recherche de session, et un contrôle d'arrêt de tâche, aux côtés d'un wrapper d'upload [Blossom](/fr/topics/blossom/) chiffré livré dans la v0.2.8 précédente. + +### GitWorkshop v3.0.3 corrige les refs nouvellement annoncées dans l'explorateur de dépôts et livre sa première version Android + +[GitWorkshop](https://github.com/DanConwayDev/gitworkshop) est une interface web git-over-Nostr pour parcourir et examiner les dépôts NIP-34. [v3.0.3](https://github.com/DanConwayDev/gitworkshop/releases/tag/v3.0.3) corrige les vues de branches, tags, commits et navigation de code qui échouaient à résoudre une ref qu'un dépôt annonce après que l'explorateur l'ait déjà chargée, aux côtés d'un nettoyage de timing du workflow CI, confirmé directement contre le tag et l'historique des commits. La même semaine, GitWorkshop a publié sa première version Android native sur [Zapstore](https://zapstore.dev), commençant à la v3.0.0 et atteignant la v3.0.3 en quelques heures ; l'interface web reste l'interface principale, et le paquet Android apporte la même navigation de dépôts NIP-34 sur téléphone pour la première fois. + +### Bitcoin-Safe atteint Flathub, mettant en lumière son plugin Nostr Sync & Chat + +[Bitcoin-Safe](https://bitcoin-safe.org) est un portefeuille Bitcoin en auto-garde construit autour de workflows avec signeurs matériels. Le projet [a livré un paquet Flathub](https://flathub.org/apps/org.bitcoin_safe.BitcoinSafe) cette semaine, sa première référence dans un magasin d'applications Linux grand public. La version Flathub met le plugin Sync & Chat de Bitcoin-Safe devant un public plus large : le plugin utilise les messages directs [NIP-17](/fr/topics/nip-17/), via la propre bibliothèque [bitcoin-nostr-chat](https://github.com/andreasgriffin/bitcoin-nostr-chat) du projet, pour synchroniser les étiquettes de portefeuille entre les appareils d'un utilisateur et pour envoyer et recevoir des PSBTs pour la co-signature multisig distante entre participants de confiance. La couche Nostr elle-même a été livrée plus tôt, dans la [2.0.0](https://github.com/andreasgriffin/bitcoin-safe/releases/tag/2.0.0) (2026-06-29), qui a redessiné la signature de transactions autour d'un type de connexion « Share via Chat & Sync » aux côtés du QR, de l'USB et du Bluetooth. La nouvelle de cette semaine est le packaging Flathub mettant cette fonctionnalité existante devant un public Linux grand public pour la première fois. + +--- + +## Changements non publiés + +### Amethyst permet aux comptes de donner des surnoms aux contacts avec des cartes NIP-85 chiffrées + +Au-delà de l'[implémentation Concord](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) couverte ci-dessus, Amethyst a fusionné 54 autres PRs au cours de la dernière semaine. Le changement principal parmi eux est [PR #3548](https://github.com/vitorpamplona/amethyst/pull/3548), qui permet à un compte de donner un surnom à tout autre utilisateur en publiant sa propre carte de contact kind 30382 [NIP-85](/fr/topics/nip-85/) à son sujet. Le petname, une note privée, et tout mappage personnalisé de shortcode emoji [NIP-30](/fr/topics/nip-30/) résident dans le contenu chiffré [NIP-44](/fr/topics/nip-44/) de la carte, de sorte que seul le compte signataire peut les lire, et les cartes se synchronisent via l'ensemble de relays outbox étendu du compte à la connexion et de manière incrémentale par la suite. Les flux, les chats et les mentions affichent le petname à la place du nom d'affichage public, avec une carte de surnom tappable sur la page de profil au-dessus du vrai nom de l'utilisateur. + +### Zap Cooking livre My Kitchen Phase 3 et corrige un bug de quorum de pool NDK + +[Zap Cooking](https://github.com/zapcooking/frontend) est une application de partage de recettes et de communauté culinaire construite sur Nostr. Elle a fusionné 43 PRs poursuivant sa fonctionnalité de planification de repas « My Kitchen », livrant la génération de liste de courses, un sélecteur de recettes et une grille de semaine de planification dans cette phase. Le même ensemble de changements corrige un bug de préparation au quorum du pool de connexion [NDK](https://github.com/nostr-dev-kit/ndk) (Nostr Development Kit) qui pouvait laisser les lectures de relay en attente au-delà du moment où un quorum de relays avait déjà répondu. + +### Kehto diffuse les lectures outbox avant la découverte de relays + +[Kehto](https://github.com/kehto/web) est un runtime web précoce pour les applets Nostr [NIP-5D](/fr/topics/nip-5d/), ou « napplets ». Il a fusionné 26 PRs. [PR #193](https://github.com/kehto/web/pull/193) corrige les lectures outbox qui attendaient précédemment la fin du chargement de la liste de relays [NIP-65](/fr/topics/nip-65/) avant d'ouvrir le moindre relay, de sorte qu'un chargement de liste de relays qui ne se terminait jamais pouvait bloquer à la fois la livraison d'events et les timeouts de requêtes ; la correction ouvre immédiatement les relay hints validés et diffuse les résultats au fur et à mesure que les relays d'écriture sont découverts. Un second changement ([PR #196](https://github.com/kehto/web/pull/196)) aligne la page d'audit d'identité du projet avec NAP-SHELL, le contrat de cycle de vie de la plateforme Napplet, faisant partie du même travail d'alignement de protocole visible ailleurs dans la version `napplet/web` de cette semaine. + +### Wired et TAO ajoutent le partage de revenus créateur NIP-57 + +[Wired](https://github.com/smolgrrr/Wired) et [TAO](https://github.com/smolgrrr/TAO) sont des clients sociaux jumeaux axés sur la liberté d'expression construits sur Nostr, partageant la même liste de PRs ; les deux ont fusionné [PR #121](https://github.com/smolgrrr/Wired/pull/121), qui implémente le partage de revenus créateur [NIP-57](/fr/topics/nip-57/) pour que les zaps envoyés à un post puissent se répartir automatiquement entre les contributeurs au-delà de l'auteur original. Cela poursuit la couverture du #30 sur la paire augmentant son signal proof-of-work à 21 bits comme travail non publié. + +### Conduit Mono reconstruit la boîte de réception de commandes marchandes autour du paiement invité éphémère + +[Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) est un protocole de place de marché adjacent aux annonces classées [NIP-99](/fr/topics/nip-99/). [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174) ajoute le paiement invité utilisant une clé éphémère générée par le navigateur : l'invité envoie une commande chiffrée et un rapport de paiement au marchand en utilisant cette clé à usage unique, et le marchand assure le suivi hors bande par téléphone ou email, de sorte que l'acheteur n'a jamais besoin d'une identité de boîte de réception durable. [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175) reconstruit la boîte de réception de commandes du marchand autour d'un modèle unique partagé d'état de commande, séparant les rôles acheteur et marchand et exigeant un code de suivi et un transporteur avant qu'une commande physique ou mixte puisse passer à l'état expédié. Le flux de paiement du projet s'appuie sur les messages privés [NIP-17](/fr/topics/nip-17/), le chiffrement [NIP-44](/fr/topics/nip-44/) et le gift wrap [NIP-59](/fr/topics/nip-59/). L'[analyse approfondie](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) de cette semaine couvre les conventions [Gamma Markets](/fr/topics/gamma-markets/) vers lesquelles ce même problème d'état de commande converge. + +### Buzz durcit le provisionnement du créateur de canal autour du kind 39002 + +[Buzz](https://github.com/block/buzz) est une plateforme de communication en intelligence collective connectant agents IA et humains par Nostr. Il a fusionné 240 PRs au cours de la dernière semaine, poursuivant son arc de durcissement de la couche relay depuis la couverture du #30 sur les métriques de tour d'agent kind 44200. La correction de cette semaine ([PR #1830](https://github.com/block/buzz/pull/1830)) traite le créateur d'un canal comme un membre avant que la logique de provisionnement de canal kind 39002 ne s'exécute, fermant une condition de course où le propre canal du créateur pouvait le rejeter pendant la configuration. + +### Nostr Docs adopte un signeur NIP-49 avec multi-compte et appairage QR + +[Nostr Docs](https://github.com/formstr-hq/nostr-docs) est une application collaborative de documents native Nostr. Elle a fusionné 5 PRs, la notable ([PR #50](https://github.com/formstr-hq/nostr-docs/pull/50)) adoptant le paquet `@formstr/signer` pour une authentification [NIP-49](/fr/topics/nip-49/) complète avec changement multi-compte et appairage QR, remplaçant un chemin de signature sur mesure antérieur. + +### Également livré + +Des corrections plus petites d'interopérabilité de signeurs et de fiabilité ont atterri à travers plusieurs projets suivis au cours de la dernière semaine sans assez de surface nouvelle pour justifier leur propre paragraphe : [ngit-cli](https://github.com/DanConwayDev/ngit-cli), un client en ligne de commande pour une alternative à GitHub basée sur Nostr, livre [v2.6.3](https://github.com/DanConwayDev/ngit-cli/releases/tag/v2.6.3) faisant en sorte que `ngit init` donne des conseils de configuration actionnables au lieu de demander répétitivement un nsec ; [Manent](https://github.com/dtonon/manent), une application de notes et fichiers privés chiffrés construite sur Nostr, livre [v1.4.1](https://github.com/dtonon/manent/releases/tag/v1.4.1) corrigeant la connexion par signeur Android cassée quand Amber retourne un pubkey hex et améliorant le défilement de connexion bunker ; [NoorNote](https://github.com/77elements/noornote), un client Nostr léger sans services Google, livre [v1.2.8](https://github.com/77elements/noornote/releases/tag/v1.2.8) corrigeant les notifications de groupe Nostrord manquées et ajoutant un toggle d'alerte d'auto-post ; [Bray](https://github.com/forgesworn/bray), un serveur MCP Nostr sensible à la confiance pour agents IA et humains, livre [v1.34.0](https://github.com/forgesworn/bray/releases/tag/v1.34.0) envoyant les métadonnées de nom de client lors du connect bunker [NIP-46](/fr/topics/nip-46/) ; [Lumilumi](https://github.com/TsukemonoGit/lumilumi), un client web Nostr, met en cache les listes de relays [NIP-65](/fr/topics/nip-65/) dans le stockage local pour un repli hors ligne ; [Earthly](https://github.com/moogmodular/earthly), une application Nostr de communauté et de ville locale, ajoute la recherche géographique [NIP-50](/fr/topics/nip-50/) ; et [lnbits](https://github.com/lnbits/lnbits), un système de portefeuille et de comptes Lightning libre et open-source, livre [PR #3925](https://github.com/lnbits/lnbits/pull/3925) rendant `send_nostr_dm` non bloquant au sein d'une version par ailleurs centrée sur Lightning. + +--- + +## Nouvellement suivis et découverts + +### OpenDiscord v1.0.1 se lance comme client de type Discord sur Nostr + +[OpenDiscord](https://github.com/sofia-gros/open-discord) est un client serveur-et-canal de type Discord construit sur Nostr avec des permissions basées sur les rôles et des lobbies vocaux WebRTC/SFU. [v1.0.1](https://github.com/sofia-gros/open-discord/releases/tag/v1.0.1) est la première version installable taguée du projet. + +### Auditable Voting v0.1.140 aligne les rôles organisateur, votant et proxy d'audit + +[Auditable Voting](https://github.com/tidley/auditable-voting) est un shell de vote Nostr côté client uniquement. [v0.1.140](https://github.com/tidley/auditable-voting/releases/tag/v0.1.140) aligne les rôles organisateur, votant et proxy d'audit avec l'event exact de définition de questionnaire public signé par l'organisateur, comblant une lacune où un proxy d'audit pouvait agir sur des comptes générés obsolètes ou un état persisté depuis un worker ou organisateur différent. + +### Cambium v0.3.2 se couple avec Heartwood comme signeur NIP-55 sans clé + +[Cambium](https://github.com/forgesworn/cambium) est le choix Découverte de ce numéro : un signeur Android [NIP-55](/fr/topics/nip-55/) qui ne détient aucun matériel de clé privée en propre, redirigeant chaque demande de signature par [NIP-46](/fr/topics/nip-46/) vers un signeur matériel Heartwood compagnon. Le projet partage l'organisation GitHub `forgesworn` avec le projet suivi Bray, et Heartwood lui-même avait été couvert dans le #30 livrant le pont de signature relay-vers-série que le côté Android de Cambium utilise maintenant. [v0.3.2](https://github.com/forgesworn/cambium) peaufine la feuille d'approbation pour avertir en direct lorsque l'identité sélectionnée diffère de la liaison existante de l'application et déplace les écritures du journal d'activité vers une file d'attente unique non bloquante. + +### Également lancés cette semaine : echoes, Dispatch et Linky + +Trois autres lancements méritent mention cette semaine. [echoes](https://github.com/Lwb89dev/echoes) est une application de notes hors ligne d'abord, chiffrée de bout en bout, qui se synchronise de manière privée par Nostr. [Dispatch](https://github.com/freecritter/dispatch) est un organisateur de voyage local-first où chaque sauvegarde est chiffrée par [NIP-44](/fr/topics/nip-44/) et sauvegardée par Nostr sous une clé dédiée et non reliée, et sa version [v0.3.0](https://github.com/freecritter/dispatch) ajoute la connexion Amber [NIP-55](/fr/topics/nip-55/) pour que l'application ne touche jamais directement la clé privée de l'utilisateur. [Linky](https://github.com/hynek-jina/linky) combine les contacts et DMs Nostr avec les paiements Lightning et Cashu dans une seule application web progressive. + +--- + +## Travaux de protocole et mises à jour NIP + +Aucune PR fusionnée dans le [dépôt NIPs](https://github.com/nostr-protocol/nips) au cours de la dernière semaine. Six propositions ont été ouvertes. + +### Ouverte : kind:10011 ensembles de suivi favoris + +[PR #2413](https://github.com/nostr-protocol/nips/pull/2413), de fiatjaf, ajoute kind:10011 pour les ensembles de suivi favoris. Elle reproduit le modèle existant où kind:10012 (ensembles de relays favoris) contient des tags `a` pointant vers des ensembles de relays kind:30002, étendant le même mécanisme de favori aux ensembles de suivi kind:30000 pour qu'un client puisse mettre en favori une liste de suivi sélectionnée sans remplacer sa propre liste de contacts. + +### Ouverte : un drive privé chiffré étend NIP-4E + +[PR #2412](https://github.com/nostr-protocol/nips/pull/2412), de l'équipe Form*, propose un event Metadata générique, kind 34578, distingué par un tag d'identifiant `d` et un tag de sous-type `t`, ainsi qu'un système de fichiers privé chiffré construit par-dessus, déjà implémenté dans le propre client Form* Drive de Form*, encore expérimental. Un enregistrement de fichier est un event Metadata avec `t=files` : les blobs de fichiers résident sur des serveurs [Blossom](/fr/topics/blossom/) tandis que seul un index chiffré se trouve sur les relays, et chaque morceau de fichier obtient sa propre paire de clés éphémère avec chiffrement HKDF dérivé [NIP-44](/fr/topics/nip-44/) v2. Un event compagnon Decoupled Encryption Key contient une seule clé symétrique à l'échelle du drive contre laquelle les métadonnées de chaque fichier se déchiffrent, et il s'appuie explicitement sur [NIP-4E](/fr/topics/nip-4e/), le brouillon d'abstraction de stockage de fiatjaf encore ouvert ([PR #1647](https://github.com/nostr-protocol/nips/pull/1647), ouvert depuis décembre 2024). + +Cette clé unique à l'échelle du drive signifie qu'une clé divulguée expose les métadonnées de chaque fichier du drive, pas seulement d'un fichier, puisque les paires de clés éphémères par fichier ne font varier que la clé de chiffrement des morceaux, pas la clé de déchiffrement des métadonnées ; aucun chemin de rotation ou de révocation n'existe encore au-delà de la publication d'un nouvel event Metadata avertissant que les events plus anciens pourraient être perdus. Une seconde proposition plus ciblée vise la même idée sous-jacente NIP-4E sous un angle différent : [PR #2361](https://github.com/nostr-protocol/nips/pull/2361), de fiatjaf, découple les clés d'identité et de chiffrement au sein de la messagerie [NIP-17](/fr/topics/nip-17/) spécifiquement, ouvert depuis le 1er juin. Les deux PRs ne sont pas fusionnées, faisant de ceci un coin actif et disputé de l'espace de conception. Form* indique que le client Drive est expérimental avec une mise à jour à venir prochainement. + +### Ouverte : NIP-DA partage de données privées avec permissions + +[PR #2411](https://github.com/nostr-protocol/nips/pull/2411), de JAFairweather, est un nouveau brouillon NIP-DA pour le partage de données privées avec permissions via des attributions de données scopées. Chaque utilisateur conserve un enregistrement chiffré faisant autorité par scope sur les relays, et l'accès est accordé en livrant de manière privée la clé symétrique de ce scope dans un gift wrap [NIP-59](/fr/topics/nip-59/), de sorte que les relays ne stockent que du texte chiffré et n'apprennent jamais qui a accordé l'accès à qui ; une révocation est simplement une rotation de clé, sans besoin de réécrire la copie de chaque consommateur. L'auteur le positionne comme distinct des DMs [NIP-17](/fr/topics/nip-17/) (qui peuvent transporter un instantané de données mais pas des mises à jour en direct ou de la révocation) et des listes privées NIP-51 (qui ne transportent pas de matériel de clé), et cite deux implémentations indépendantes, une bibliothèque de référence JavaScript et un CLI Go sur go-nostr, testées en croisé contre relay.damus.io, nos.lol et relay.primal.net. + +### Ouverte : kinds de packs de stickers 10031 et 30031 + +[PR #2410](https://github.com/nostr-protocol/nips/pull/2410), de vincenzopalazzo, enregistre kind 30031 (packs de stickers adressables) et kind 10031 (liste de packs de stickers d'un utilisateur) dans la table des Event Kinds, spécifiés par le format « Sonar Stickers » que [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) livre cette semaine. Les kinds se situent délibérément un cran au-dessus des kinds d'emoji personnalisés [NIP-30](/fr/topics/nip-30/) 30030 et 10030 pour qu'un client ne puisse pas confondre un pack de stickers avec un ensemble d'emoji ; les octets d'image de sticker résident sur des serveurs HTTPS compatibles [Blossom](/fr/topics/blossom/), et les références de stickers envoyés portent un hash en clair pour qu'un pack adressable modifié ne puisse pas changer silencieusement l'apparence de stickers déjà envoyés dans d'anciens messages. Une PR compagnon enregistre les mêmes kinds dans le projet séparé `registry-of-kinds`. + +### Ouverte : épinglage de messages NIP-29 avec kind:9010 et kind:39005 + +[PR #2379](https://github.com/nostr-protocol/nips/pull/2379), d'Anderson-Juhasc, ajoute l'épinglage de messages aux groupes basés sur relay [NIP-29](/fr/topics/nip-29/) : kind:9010 `update-pin-list` est un event de modération portant la liste complète des events épinglés comme tags `e` dans l'ordre d'affichage, de sorte qu'un seul event peut épingler, désépingler, réordonner ou vider l'ensemble épinglé, et kind:39005 est un miroir généré par le relay exposant la dernière liste acceptée. La conception remplace une approche antérieure par paire ajout/suppression de [PR #1163](https://github.com/nostr-protocol/nips/pull/1163) après retour de revue, et choisit les numéros de kind 9010/39005 car 9009 et 39003 ont depuis été réclamés par `create-invite` et les rôles de groupe. Anderson-Juhasc maintient également [Nostrord](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages), dont la [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) est livrée la même semaine. + +### Ouverte : restructuration de la découverte de relays NIP-66 + +[PR #2241](https://github.com/nostr-protocol/nips/pull/2241), de VincenzoImp, est une restructuration substantielle de la découverte de relays [NIP-66](/fr/topics/nip-66/). Elle remplace la prose vague « Other tags include » par une section Indexed Tags structurée, ajoute un tag `W` reflétant le champ `attributes` de NIP-11 pour le filtrage de découverte de relays, ajoute un tag d'étiquette `l` utilisant des espaces de noms standardisés (`ISO-639-1`, `ISO-3166-1`, `IANA-asn`, `IANA-tz`, `nip66.label.city`), et organise les tags RTT, SSL/TLS, réseau, géographiques, DNS et HTTP en sections dédiées aux côtés d'une nouvelle table Check Types. Elle corrige aussi des events d'exemple cassés qui avaient des noms de champs erronés, un `kind` manquant et des noms de types de vérification invalides, et clôt le [ticket #2171](https://github.com/nostr-protocol/nips/issues/2171). Tous les changements restent rétrocompatibles puisque chaque tag ajouté est optionnel. + +--- + +## Analyse approfondie : NIP-99 et l'extension commerce Gamma Markets + +[NIP-15](/fr/topics/nip-15/), la spécification originale Nostr Marketplace, est patrimoniale à ce stade : elle modélisait un stall de marchand (kind 30017) avec des produits (kind 30018) classés en dessous, et les clients qui l'utilisaient autrefois, Shopstr parmi eux, sont depuis passés aux annonces classées [NIP-99](/fr/topics/nip-99/) comme spécification active. NIP-99 elle-même est un event adressable unique, kind 30402 pour une annonce active ou kind 30403 pour un brouillon, sans stall à créer au préalable. Elle laisse tout ce qui suit l'annonce indéfini : frais d'expédition, statut de commande, reçus, avis et un moyen de regrouper plusieurs annonces sous une seule vitrine, exactement les parties de NIP-15 qui n'ont jamais été transférées. [Gamma Markets](/fr/topics/gamma-markets/) comble cette lacune, et constitue la couche commerce moderne qui mérite d'être comprise aujourd'hui. + +### La lacune que NIP-99 laisse ouverte + +Le champ `content` d'une annonce NIP-99 porte une description Markdown, `price` et `location` se trouvent directement sur l'event, et les tags `t` la rendent cherchable comme contenu hashtag ordinaire. Parce qu'elle est adressable sur le tuple pubkey, kind et tag `d`, un vendeur modifie une annonce en place en publiant une nouvelle version avec le même tag `d` : + +```json +{ + "kind": 30402, + "content": "Vintage mechanical keyboard, Cherry MX Blue switches, barely used.", + "tags": [ + ["d", "keyboard-mx-blue-01"], + ["title", "Vintage Mechanical Keyboard"], + ["summary", "Cherry MX Blue, barely used"], + ["published_at", "1752537600"], + ["location", "NYC"], + ["price", "100", "USD"], + ["t", "electronics"] + ] +} +``` + +C'est toute la spécification : une petite annonce signée et modifiable. Chaque client implémentant NIP-99 pour du vrai e-commerce, au-delà d'une annonce ponctuelle, a fini par inventer ses propres conventions privées pour l'expédition, les messages de commande et les avis. Deux clients NIP-99 pouvaient chacun afficher une annonce correctement et toujours n'avoir aucun moyen partagé de compléter un paiement entre eux. + +### Gamma Markets : standardiser ce que NIP-99 a laissé de côté + +Gamma Markets est le nom qu'un groupe de travail de développeurs de places de marché Nostr, les équipes derrière Shopstr, Cypher, Plebeian Market et Conduit Market, a donné à un ensemble partagé de conventions e-commerce construites sur l'event kind 30402 existant de NIP-99. La spécification est liée depuis le document canonique NIP-99 via [PR #1784](https://github.com/nostr-protocol/nips/pull/1784) et maintenue dans son propre dépôt, [GammaMarkets/market-spec](https://github.com/GammaMarkets/market-spec). + +Gamma Markets ajoute deux kinds autonomes adjacents aux annonces. Kind 30405 regroupe plusieurs annonces en une collection de produits, référençant chacune par un tag `a` explicite : + +```json +{ + "kind": 30405, + "content": "Summer sale picks", + "tags": [ + ["d", "summer-picks"], + ["title", "Summer Sale"], + ["a", "30402::keyboard-mx-blue-01"], + ["shipping_option", "30406::standard-regional"] + ] +} +``` + +Kind 30406 définit une option d'expédition avec tarification par pays et règles de coût optionnelles basées sur le poids ou la distance : + +```json +{ + "kind": 30406, + "content": "Standard Regional Shipping", + "tags": [ + ["d", "standard-regional"], + ["title", "Standard Shipping"], + ["price", "5.99", "USD"], + ["country", "US"], + ["service", "standard"], + ["duration", "24", "72", "H"], + ["weight-max", "30", "kg"] + ] +} +``` + +La création de commande, les demandes de paiement, les mises à jour de statut et d'expédition, et les reçus de paiement passent tous comme des messages privés gift-wrapped [NIP-17](/fr/topics/nip-17/) ordinaires, répartis entre trois kinds par rôle et non par ré-enveloppement du transport : kind 14 porte la communication libre acheteur/marchand, kind 16 porte chaque transition d'état de commande (un tag `type` de 1 à 4 marque la création de commande, la demande de paiement, la mise à jour de statut ou la mise à jour d'expédition), et kind 17 porte le reçu de paiement de l'acheteur. Un message de création de commande ressemble à ceci avant le gift-wrapping : + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +Noter un achat complété est un kind adressable séparé, 31555, pointant vers l'annonce qu'il évalue : + +```json +{ + "kind": 31555, + "content": "Arrived fast, exactly as described.", + "tags": [ + ["d", "a:30402::keyboard-mx-blue-01"], + ["rating", "1", "thumb"], + ["rating", "1.0", "quality"], + ["rating", "0.9", "delivery"] + ] +} +``` + +Faire transiter les messages de commande par NIP-17 signifie qu'un paiement Gamma Markets utilise le même transport de messages privés que les clients livrent déjà pour les DMs, au lieu d'un kind de message de commande sur mesure. + +Le choix de conception central de la spécification est que rien ne se propage en cascade. Une annonce qui appartient à une collection référence celle-ci explicitement avec un tag `a` au lieu d'hériter automatiquement des options d'expédition ou de la description de la collection, et une option d'expédition qu'une annonce utilise est référencée de la même manière explicite. C'est un renversement délibéré du modèle de stall NIP-15, où un produit héritait silencieusement de la devise et du tableau d'expédition que son stall parent définissait. Le compromis est un balisage plus explicite sur chaque annonce, en échange d'une configuration toujours lisible depuis l'event lui-même, sans objet parent à résoudre au préalable. + +### Où cela se manifeste en pratique + +Le travail de [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) de cette semaine se situe dans le même territoire de messages de commande que Gamma Markets standardise : le paiement invité par clé éphémère de [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174) et la reconstruction de la boîte de réception de commandes du marchand de [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175) résolvent tous deux le problème d'état de commande acheteur/marchand que les messages kind 14, 16 et 17 de Gamma Markets formalisent ; Conduit Mono fait tourner son propre modèle d'état de commande aux côtés de ces kinds, sans les adopter directement. Shopstr, l'un des quatre projets ayant rédigé la spécification, a lui aussi fait avancer sa propre plomberie commerce au cours de la dernière semaine : [PR #568](https://github.com/shopstr-eng/shopstr/pull/568) extrait la logique de gift-wrap NIP-17 dupliquée dans un module partagé, et [PR #567](https://github.com/shopstr-eng/shopstr/pull/567) amène son parseur d'authentification HTTP [NIP-98](/fr/topics/nip-98/) à une couverture de tests complète, de la maintenance sur exactement les couches de messagerie et d'authentification dont un flux de commande Gamma Markets dépend pour atteindre un acheteur et un marchand en toute sécurité. + +NIP-15 a perdu le rôle de vitrine en standardisant un stall et un produit, puis en laissant les paiements, l'expédition, les avis et le statut de commande comme un problème applicatif. Gamma Markets comble la majeure partie de cette surface manquante sans toucher à la forme d'annonce unique de NIP-99, en s'appuyant sur la pile DM existante de Nostr, NIP-17, au lieu d'inventer une nouvelle couche de messagerie. + +--- + +C'est tout pour cette semaine. Vous construisez quelque chose ou avez des nouvelles à partager ? Contactez-nous par DM NIP-17 ou trouvez-nous sur Nostr. diff --git a/content/fr/topics/concord-protocol.md b/content/fr/topics/concord-protocol.md new file mode 100644 index 0000000..c7f5321 --- /dev/null +++ b/content/fr/topics/concord-protocol.md @@ -0,0 +1,61 @@ +--- +title: "Protocole Concord" +date: 2026-07-15 +translationOf: /en/topics/concord-protocol.md +translationDate: 2026-07-15 +draft: false +categories: + - Protocol + - Messaging +--- + +Concord est un protocole ouvert sous licence MIT pour les communautés et canaux chiffrés de bout en bout sur Nostr, défini par les [spécifications CORD-01 à CORD-07](https://github.com/concord-protocol/concord). [Vector](https://github.com/VectorPrivacy/Vector) l'a adopté comme transport par défaut pour sa fonctionnalité Group Chats à partir de la v0.4.0, le décrivant dans ses propres notes de version comme « our custom messaging protocol », mais la spécification elle-même est publiée séparément de Vector et dispose déjà d'implémentations indépendantes. + +## Fonctionnement + +Concord décompose ce qu'un serveur de communauté de type Discord fait normalement en éléments qui n'ont besoin de faire confiance à personne : les relays ne stockent jamais que des blobs chiffrés adressés à des étiquettes rotatives, détenir la clé d'un salon est ce qui fait de quelqu'un un membre, et l'autorité sur les rôles, les expulsions et les bannissements est un registre signé enraciné dans l'identité du propriétaire que chaque client vérifie localement au lieu de faire confiance à un serveur pour l'appliquer. Chaque event durable utilise la même enveloppe à trois couches : un wrap kind 1059 signé par la clé de flux dérivée du plan, contenant un seal signé par la vraie clé de l'auteur, contenant un rumor non signé qui porte l'event fonctionnel. Un rumor de message de chat est un simple event kind 9 : + +```json +{ + "kind": 9, + "pubkey": "", + "content": "Hey chat!", + "tags": [ + ["channel", ""], + ["epoch", "0"] + ] +} +``` + +Le trafic de contrôle, de chat et de livre d'or obtient chacun son propre plan gift-wrapped [NIP-59](/fr/topics/nip-59/), de sorte qu'un relay détenant les trois ne peut toujours pas distinguer un message de contrôle d'un message de chat ou d'une entrée de livre d'or sans la clé du salon. La spécification est divisée en sept documents CORD : flux privés (01), communautés et adhésion (02), canaux (03), rôles (04), invitations (05), renouvellement de clé et refondation pour couper l'accès aux membres retirés (06), et audio/vidéo via un courtier de jetons aveugles (07). L'adhésion elle-même n'a pas de liste côté serveur : quiconque peut déchiffrer le plan est membre, et retirer quelqu'un pour de vrai signifie faire passer la communauté à une nouvelle époque de clé et la transmettre uniquement à ceux qui restent, au lieu de supprimer une ligne dans une table. + +## Différences avec Marmot + +Concord et [Marmot](/fr/topics/marmot/) résolvent la messagerie de groupe chiffrée sur Nostr avec des cryptographies différentes pour des formes de groupes différentes, et la propre comparaison du projet Concord est explicite sur cette distinction : Marmot superpose [MLS](/fr/topics/mls/) sur Nostr pour la confidentialité persistante et la sécurité post-compromission, utilisant des key packages par appareil et des commits ordonnés qui font avancer tout le groupe en synchronisation. Cela apporte des garanties solides, à un coût qui augmente avec les changements de membres, bien adapté aux petits groupes à enjeux élevés où les entrées et sorties sont rares. Concord donne plutôt à chaque membre la même clé de salon et renouvelle la clé de tout le salon lors d'un retrait au lieu de faire un ratchet par commit, échangeant certaines des garanties cryptographiques de MLS contre un modèle qui reste économique à mesure qu'une communauté grandit vers des centaines ou des milliers de membres occasionnels à forte rotation, la forme que prennent réellement les communautés de type Discord. + +## Pourquoi Vector a changé + +Les propres [notes de version de Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) décrivent Concord uniquement comme « our custom messaging protocol » pour les Group Chats, sans énoncer directement le raisonnement. L'adéquation avec la propre justification publiée de Concord est claire malgré tout : les Group Chats dans un client comme Vector sont exactement le cas d'utilisation à grande échelle, ouvert, avec des changements fréquents de membres, où l'état MLS par appareil de Marmot devient le chemin le plus coûteux, et la conception asynchrone de Concord, utilisable à tout moment, est construite pour ce cas. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) a retiré Marmot pour les Group Chats en faveur de Concord, et l'historique existant des groupes Marmot n'a pas été transféré lors du changement. [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) a livré « Concord v2 » quatre jours plus tard avec des améliorations de confidentialité et de stabilité. Dans la même semaine, [Amethyst a fusionné sa propre implémentation Concord indépendante et compatible au niveau du protocole](https://github.com/vitorpamplona/amethyst/pull/3566), et le client de type Discord de Soapbox, [Armada](https://gitlab.com/soapbox-pub/armada), construit déjà sa fonctionnalité Communities sur la même spécification en tant qu'implémentation de référence. Trois clients indépendants convergeant vers une seule spécification ouverte en quelques jours est un chemin rapide vers une véritable interopérabilité inter-clients, à suivre en regard de la proportion du reste des clients de chat de groupe Nostr qui restent sur Marmot. + +## Implémentations + +- [Vector](https://github.com/VectorPrivacy/Vector) - messager Nostr à binaire unique, axé sur la vie privée ; premier client Concord livré, dans la v0.4.0 +- [Armada](https://gitlab.com/soapbox-pub/armada) (Soapbox) - client communautaire de type Discord ; implémentation de référence, backend dans le dépôt séparé `armada-relay` +- [Amethyst](https://github.com/vitorpamplona/amethyst) - client Nostr Android et multiplateforme riche en fonctionnalités ; réimplémentation indépendante compatible au niveau du protocole avec Armada ([PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566)) + +--- + +**Sources primaires :** +- [Spécifications du protocole Concord (CORD-01 à CORD-07)](https://github.com/concord-protocol/concord) +- [Notes de version de Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) +- [Notes de version de Vector v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) +- [PR #3566 d'Amethyst](https://github.com/vitorpamplona/amethyst/pull/3566) + +**Mentionné dans :** +- [Bulletin #31 : Vector v0.4.0 fait passer les Group Chats de Marmot à Concord, et Amethyst livre son propre client Concord quelques jours plus tard](/fr/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) +- [Bulletin #31 : Amethyst livre une implémentation Concord indépendante pour les communautés chiffrées de bout en bout](/fr/newsletters/2026-07-15-newsletter/#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) + +**Voir aussi :** +- [Protocole Marmot](/fr/topics/marmot/) +- [MLS (Message Layer Security)](/fr/topics/mls/) +- [NIP-46 : Nostr Connect](/fr/topics/nip-46/) diff --git a/content/fr/topics/gamma-markets.md b/content/fr/topics/gamma-markets.md new file mode 100644 index 0000000..171206f --- /dev/null +++ b/content/fr/topics/gamma-markets.md @@ -0,0 +1,69 @@ +--- +title: "Gamma Markets" +date: 2026-07-15 +translationOf: /en/topics/gamma-markets.md +translationDate: 2026-07-15 +draft: false +categories: + - Commerce + - Marketplace + - Protocol +--- + +Gamma Markets est un ensemble de conventions e-commerce construites directement sur les annonces classées [NIP-99](/fr/topics/nip-99/), développées de manière collaborative par un groupe de travail de développeurs de places de marché Nostr : les équipes derrière Shopstr, Cypher, Plebeian Market et Conduit Market. Il comble les conventions d'expédition, de flux de commandes, de collections et d'avis que NIP-99 lui-même laisse indéfinies. + +## Fonctionnement + +Gamma Markets ajoute cinq types d'events autour de l'event d'annonce kind `30402` existant de NIP-99, sans modifier la forme de cet event : + +- **Kind 30405** - collections de produits, regroupant plusieurs annonces ensemble via des tags `a` +- **Kind 30406** - options d'expédition, avec tarification par pays et règles de coût optionnelles basées sur le poids ou la distance +- **Kind 16** - messages de commande : création (type 1), demandes de paiement (type 2), mises à jour de statut (type 3) et mises à jour d'expédition (type 4) +- **Kind 14** - communication générale acheteur/vendeur +- **Kind 17** - reçus de paiement +- **Kind 31555** - avis sur les produits, adressés à un pubkey vendeur spécifique et au tag `d` de l'annonce + +Les préférences de paiement d'un vendeur sont déclarées via un tag `payment_preference` sur ses métadonnées de profil kind `0`, et les clients découvrent les applications compatibles via les recommandations d'applications [NIP-89](/fr/topics/nip-89/). La communication des commandes s'appuie sur les messages privés [NIP-17](/fr/topics/nip-17/), sans nouveau schéma de chiffrement propre. + +Le choix de conception déterminant de la spécification est que rien ne se propage en cascade : une annonce qui appartient à une collection, ou qui utilise une option d'expédition, la référence explicitement avec un tag `a` au lieu d'hériter automatiquement des paramètres de son parent. C'est un départ délibéré de l'ancien modèle de stall [NIP-15](/fr/topics/nip-15/), où un produit héritait silencieusement de la devise et du tableau d'expédition de son stall. + +### Exemple : création de commande (kind 16, type 1) + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +## Pourquoi c'est important + +NIP-99 seul ne standardise que l'annonce elle-même, une petite annonce signée et adressable. Avant Gamma Markets, chaque client construisant du véritable e-commerce sur NIP-99 inventait ses propres conventions privées pour l'expédition, le paiement et les avis, ce qui signifiait que deux clients conformes à NIP-99 pouvaient chacun afficher une annonce correctement mais n'avaient aucun moyen partagé de finaliser une commande entre eux. Gamma Markets comble cette lacune sans toucher au format d'annonce NIP-99 lui-même, de sorte que les annonces NIP-99 existantes restent valides sans modification. + +## Implémentations + +- [Shopstr](https://github.com/shopstr-eng/shopstr) - place de marché Nostr, l'un des quatre projets ayant rédigé la spécification +- [Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) - protocole de place de marché construisant son propre flux d'état des commandes et de paiement dans le même espace de conception + +--- + +**Sources primaires :** +- [Dépôt de la spécification Gamma Markets](https://github.com/GammaMarkets/market-spec) +- [Extension de cas d'utilisation e-commerce NIP-99, PR #1784](https://github.com/nostr-protocol/nips/pull/1784) - lien fusionné depuis le document canonique NIP-99 vers la spécification Gamma Markets + +**Mentionné dans :** +- [Bulletin #31 : Analyse approfondie : NIP-99 et l'extension commerce Gamma Markets](/fr/newsletters/2026-07-15-newsletter/#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) + +**Voir aussi :** +- [NIP-99 : Annonces classées](/fr/topics/nip-99/) +- [NIP-15 : Place de marché Nostr](/fr/topics/nip-15/) +- [NIP-17 : Messages privés directs](/fr/topics/nip-17/) diff --git a/content/fr/topics/nip-4e.md b/content/fr/topics/nip-4e.md new file mode 100644 index 0000000..b497cb2 --- /dev/null +++ b/content/fr/topics/nip-4e.md @@ -0,0 +1,46 @@ +--- +title: "NIP-4E : Découplage du chiffrement et de l'identité" +date: 2026-07-15 +translationOf: /en/topics/nip-4e.md +translationDate: 2026-07-15 +draft: false +categories: + - NIP + - Protocol + - Encryption +--- + +NIP-4E est un brouillon ouvert, proposé par fiatjaf, pour le partage de données privées entre les propres appareils d'un utilisateur sans que chaque appareil détienne la clé d'identité Nostr principale de cet utilisateur. Il n'est pas fusionné et reste une proposition `draft`/`optional`. + +## Le problème qu'il adresse + +De nombreux NIPs existants, y compris les listes NIP-51 et les portefeuilles Cashu NIP-60, chiffrent les données d'un utilisateur vers lui-même en utilisant la clé d'identité afin de pouvoir les relire plus tard sur n'importe quel appareil. Cela ne fonctionne plus lorsque la clé d'identité n'est pas directement accessible, par exemple lorsqu'un signeur distant est protégé par des parts de seuil FROST, MuSig2, ou une enclave sécurisée hébergée, puisque le chiffrement et le déchiffrement nécessitent alors un aller-retour vers ce signeur à chaque fois. Cela rend également le chiffrement hors ligne impossible chaque fois que la clé de signature réside dans un bunker distant. + +## Fonctionnement + +NIP-4E sépare une « clé client » par appareil d'une « clé de chiffrement » partagée qui n'est pas la clé d'identité de l'utilisateur : + +1. Le premier client qu'un utilisateur configure génère une paire de clés de chiffrement aléatoire et annonce sa moitié publique dans un event `kind:10044` signé par la clé d'identité de l'utilisateur. +2. Tout autre client souhaitant chiffrer ou déchiffrer des données pour cet utilisateur calcule son secret partagé Diffie-Hellman par rapport à la clé de chiffrement annoncée plutôt que par rapport à la clé d'identité. +3. Lorsqu'un second appareil installe un nouveau client, ce client génère sa propre « clé client » locale et publie une annonce `kind:4454` (également signée par la clé d'identité de l'utilisateur) demandant au premier client de partager la clé de chiffrement avec lui. +4. Le client original détecte la nouvelle annonce `kind:4454`, chiffre la clé de chiffrement partagée vers la clé du nouveau client en utilisant [NIP-44](/fr/topics/nip-44/), et la publie pour que le nouveau client puisse la déchiffrer et l'utiliser par la suite. + +Le résultat est que le chiffrement et le déchiffrement ne nécessitent jamais de solliciter le signeur de la clé d'identité une fois qu'un client détient la clé de chiffrement partagée localement, et une configuration de signeur distant (FROST, MuSig2, enclave hébergée) peut être utilisée pour l'identité tandis que le chiffrement ordinaire reste rapide et fonctionne hors ligne. + +## Pourquoi c'est important + +NIP-4E est cité comme fondation pour d'autres propositions qui ont besoin d'une clé symétrique à l'échelle d'un drive ou d'un compte sans dépendre d'un signeur distant pour chaque appel de chiffrement/déchiffrement, y compris une proposition de drive privé chiffré ([PR #2412](https://github.com/nostr-protocol/nips/pull/2412)) et une version plus ciblée de la même idée spécifique à NIP-17 ([PR #2361](https://github.com/nostr-protocol/nips/pull/2361)). Les deux restent ouvertes aux côtés de NIP-4E lui-même, faisant de ceci un domaine actif et non stabilisé du protocole plutôt qu'un composant de base achevé. + +--- + +**Sources primaires :** +- [Brouillon NIP-4E, PR #1647](https://github.com/nostr-protocol/nips/pull/1647) + +**Mentionné dans :** +- [Bulletin #31 : Ouvert : un drive privé chiffré étend NIP-4E](/fr/newsletters/2026-07-15-newsletter/#open-private-encrypted-drive-extends-nip-4e) + +**Voir aussi :** +- [NIP-44 : Charges utiles chiffrées](/fr/topics/nip-44/) +- [NIP-17 : Messages privés directs](/fr/topics/nip-17/) +- [NIP-46 : Nostr Connect](/fr/topics/nip-46/) +- [FROST](/fr/topics/frost/) diff --git a/content/fr/topics/proofmode.md b/content/fr/topics/proofmode.md new file mode 100644 index 0000000..ef1c113 --- /dev/null +++ b/content/fr/topics/proofmode.md @@ -0,0 +1,36 @@ +--- +title: "ProofMode" +date: 2026-07-15 +translationOf: /en/topics/proofmode.md +translationDate: 2026-07-15 +draft: false +categories: + - Media + - Provenance +--- + +[ProofMode](https://proofmode.org/) est une boîte à outils open-source de provenance média, construite par Guardian Project, WITNESS et Okthanks, qui attache des données vérifiables d'authenticité et de chaîne de contrôle aux photos et vidéos au moment de la capture. Ce n'est pas spécifique à Nostr ; les clients Nostr qui transportent des données ProofMode intègrent un standard externe existant plutôt qu'une nouvelle couche de protocole. + +## Fonctionnement + +Le composant Capture de ProofMode intègre les métadonnées de provenance directement dans les fichiers média pendant la capture, prenant en charge les mêmes standards interopérables utilisés par la Content Authenticity Initiative (CAI), les Content Credentials (CR) et C2PA. Un composant Verify séparé inspecte les fichiers audio, image et vidéo pour vérifier ces métadonnées à la recherche de signes de génération par IA ou de modification ultérieure, et un composant Preserve gère le stockage redondant sur le web décentralisé des données de preuve sous-jacentes pour l'archivage à long terme. Un SDK Develop permet aux applications d'intégrer la capture et la vérification sans construire elles-mêmes le format de provenance. + +## Pourquoi c'est important + +Pour un client Nostr de vidéo ou d'image, transporter des données ProofMode signifie qu'un spectateur dispose d'un moyen externe et multiplateforme de vérifier si un média a été capturé comme annoncé et n'a pas été silencieusement altéré depuis, sans se fier au client de publication ou au relay comme source de confiance. Cette distinction compte le plus pour une copie téléchargée ou réencodée d'un clip : les données de provenance qui survivent au téléchargement et à tout filigrane qu'un client applique sont ce qui rend l'attestation encore vérifiable après que le fichier a quitté l'application qui l'a produit. + +## Implémentations + +- [Divine](https://github.com/divinevideo/divine-mobile) - client Nostr de vidéo courte ; transporte les données de provenance ProofMode à travers les téléchargements de clips filigranés + +--- + +**Sources primaires :** +- [ProofMode](https://proofmode.org/) + +**Mentionné dans :** +- [Bulletin #17](/fr/newsletters/2026-04-29-newsletter/) +- [Bulletin #31 : Divine Mobile 1.0.16 livre un éditeur vidéo plus complet, le chiffrement au repos et la provenance ProofMode](/fr/newsletters/2026-07-15-newsletter/#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) + +**Voir aussi :** +- [Blossom](/fr/topics/blossom/) From 43fcb7169c9562aba64d289f78dfad0ee10fc5af Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Thu, 16 Jul 2026 08:23:28 +0000 Subject: [PATCH 05/10] Add Italian translation for Newsletter #31 and topic pages --- .../it/newsletters/2026-07-15-newsletter.md | 300 ++++++++++++++++++ content/it/topics/concord-protocol.md | 61 ++++ content/it/topics/gamma-markets.md | 69 ++++ content/it/topics/nip-4e.md | 46 +++ content/it/topics/proofmode.md | 36 +++ 5 files changed, 512 insertions(+) create mode 100644 content/it/newsletters/2026-07-15-newsletter.md create mode 100644 content/it/topics/concord-protocol.md create mode 100644 content/it/topics/gamma-markets.md create mode 100644 content/it/topics/nip-4e.md create mode 100644 content/it/topics/proofmode.md diff --git a/content/it/newsletters/2026-07-15-newsletter.md b/content/it/newsletters/2026-07-15-newsletter.md new file mode 100644 index 0000000..2da299d --- /dev/null +++ b/content/it/newsletters/2026-07-15-newsletter.md @@ -0,0 +1,300 @@ +--- +title: "Nostr Compass #31" +date: 2026-07-15 +publishDate: 2026-07-15 +draft: false +type: newsletters +translationOf: /en/newsletters/2026-07-15-newsletter.md +translationDate: 2026-07-15 +description: "Vector v0.4.0 ritira Marmot per le chat di gruppo a favore del protocollo aperto Concord e rilascia Concord v2 pochi giorni dopo, Amethyst integra la propria implementazione pulita di Concord, Sonar si separa da Bitchat con un'alpha multipiattaforma e una specifica per pacchetti di sticker, Divine Mobile 1.0.16 introduce la cifratura a riposo e la provenienza ProofMode, Bitchat 1.7.0 aggiunge la voce push-to-talk dal vivo, e MDK v0.9.4 limita il login con firmatario esterno." +--- + +Bentornati su Nostr Compass, la vostra guida settimanale su Nostr. + +**Questa settimana:** [Vector v0.4.0](#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) ritira [Marmot](/it/topics/marmot/) come trasporto predefinito per le Chat di Gruppo a favore di [Concord](/it/topics/concord-protocol/), un protocollo di comunità aperto con licenza MIT usato anche da Armada di Soapbox, e rilascia Concord v2 quattro giorni dopo con un selettore di comandi con barra per i bot, un timer di autodistruzione e badge NIP-58. [Amethyst integra la propria implementazione pulita e compatibile a livello di protocollo di Concord](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities), la stessa settimana. [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) si separa da Bitchat con un'alpha multipiattaforma ed è la fonte di specifica citata per la proposta di kind per pacchetti di sticker di questa settimana. [Divine Mobile 1.0.16](#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) introduce un editor video più completo, la cifratura a riposo e la provenienza ProofMode che sopravvive al download di clip con filigrana. [Bitchat v1.7.0](#bitchat-v170-adds-live-push-to-talk-voice-for-dms-and-the-public-mesh) aggiunge la voce push-to-talk dal vivo per i DM e il push-to-talk firmato sulla mesh pubblica. [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) limita il login con firmatario esterno e aggiunge la persistenza delle bozze, proseguendo il suo lavoro di irrobustimento la stessa settimana in cui Vector si allontana dalla specifica per la chat di gruppo. + +I rilasci taggati portano [n_cord v1.1](#n_cord-v11-adds-nsec-bunker-support) con il supporto per NSEC Bunker, [cdk v0.17.3](#cdk-v0173-adds-nip-47-wallet-service-support-across-cdk-cdk-nwc-and-cdk-ffi) con il supporto per il servizio di wallet NIP-47 su cdk, cdk-nwc e cdk-ffi, [Coop Mobile v0.2.4](#coop-mobile-v024-improves-nostr-connect-and-adds-ncryptsec1-import) con miglioramenti a Nostr Connect e l'importazione ncryptsec1, [Nmail v0.14.0](#nmail-v0140-ships-on-macos-with-scheduled-send-and-push-notifications) che arriva su macOS con l'invio programmato, [Nostrord v2.2.0](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages) con un interruttore generale per i DM, [Nostr WoT 0.3.86](#nostr-wot-0386-hardens-key-backups-and-signing-prompts) che irrobustisce i backup delle chiavi al formato NIP-49, [Keep Android v1.1.8](#keep-android-v118-adds-first-run-frost-onboarding) con l'onboarding FROST al primo avvio, [Noscall v0.6.0](#noscall-v060-adds-a-cashu-wallet-and-relay-based-push-notifications) con un wallet Cashu e notifiche push basate su relay, [Kubo](#kubo-ships-tablet-mode-and-group-chat-photos) con la modalità tablet e le foto nelle chat di gruppo, e [Nostr Codex Phone v0.2.9](#nostr-codex-phone-v029-adds-gitdiffread-file-helper-requests) con richieste ausiliarie per git, diff e lettura di file. + +Sul fronte non rilasciato, [Amethyst](#amethyst-lets-accounts-nickname-contacts-with-encrypted-nip-85-cards) consente agli account di assegnare soprannomi ai contatti con schede NIP-85 cifrate attraverso 54 PR integrate, [Zap Cooking](#zap-cooking-ships-my-kitchen-phase-3-and-fixes-an-ndk-pool-quorum-bug) rilascia la Fase 3 di My Kitchen e corregge un bug di quorum del pool NDK, [Kehto](#kehto-streams-outbox-reads-before-relay-discovery) trasmette le letture di outbox prima che finisca la scoperta dei relay, [Wired e TAO](#wired-and-tao-add-nip-57-creator-revenue-sharing) aggiungono la condivisione dei ricavi per i creatori con NIP-57, [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) ricostruisce la casella degli ordini del commerciante attorno al checkout come ospite effimero, [Buzz](#buzz-hardens-channel-creator-provisioning-around-kind-39002) irrobustisce il provisioning del creatore di canale attraverso 240 PR integrate, e [Nostr Docs](#nostr-docs-adopts-a-nip-49-signer-with-multi-account-and-qr-pairing) adotta un firmatario NIP-49 con account multipli e accoppiamento QR. Tracciati per la prima volta questa settimana: [OpenDiscord v1.0.1](#opendiscord-v101-launches-as-a-discord-style-client-on-nostr), [Auditable Voting v0.1.140](#auditable-voting-v01140-aligns-organiser-voter-and-audit-proxy-roles), e la scelta Discovery [Cambium v0.3.2](#cambium-v032-pairs-with-heartwood-as-a-keyless-nip-55-signer), un firmatario NIP-55 senza chiavi che fa da proxy verso un dispositivo hardware Heartwood. + +Il repository dei NIP non integra nulla nell'ultima settimana e apre sei proposte: [kind:10011 set di follow preferiti](#open-kind10011-favorite-follow-sets), un'[unità cifrata privata che estende NIP-4E](#open-private-encrypted-drive-extends-nip-4e), [NIP-DA condivisione privata di dati con permessi](#open-nip-da-permissioned-private-data-sharing), [kind per pacchetti di sticker 10031 e 30031](#open-sticker-pack-kinds-10031-and-30031), [fissaggio dei messaggi NIP-29](#open-nip-29-message-pinning-with-kind9010-and-kind39005), e una [ristrutturazione della scoperta di relay NIP-66](#open-nip-66-relay-discovery-restructure). Il Deep Dive copre [NIP-99 e l'estensione di commercio Gamma Markets](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension). + +--- + +## Storie principali + +### Vector v0.4.0 sposta le Chat di Gruppo da Marmot a Concord, e Amethyst rilascia il proprio client Concord pochi giorni dopo + +[Vector](https://github.com/VectorPrivacy/Vector) è un messenger Nostr costruito attorno a un client a binario singolo, orientato alla privacy, per DM e chat di gruppo. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) riscrive il motore di messaggistica dell'app in una libreria condivisa `vector-core` e, nello stesso rilascio, ritira [Marmot](/it/topics/marmot/) (MLS-su-Nostr) come trasporto predefinito per le Chat di Gruppo a favore di [Concord](/it/topics/concord-protocol/), un protocollo di comunità cifrato end-to-end; la cronologia esistente dei gruppi Marmot non viene trasferita, e le note di rilascio indicano agli utenti di fare il backup di qualsiasi dato dei gruppi Marmot prima di aggiornare. Le note di rilascio di Vector descrivono Concord come "il nostro protocollo di messaggistica personalizzato", ma le [specifiche da CORD-01 a CORD-07](https://github.com/concord-protocol/concord) sottostanti sono pubblicate separatamente, con licenza MIT, e già implementate al di fuori di Vector: il client in stile Discord di Soapbox, [Armada](https://gitlab.com/soapbox-pub/armada), costruisce la sua funzionalità Communities sulla stessa specifica Concord, e un giorno dopo [Amethyst ha integrato la propria implementazione pulita e compatibile a livello di protocollo di Concord](https://github.com/vitorpamplona/amethyst/pull/3566), trattata in dettaglio più sotto. Lo stesso rilascio di Vector aggiunge il routing Tor opzionale per tutto il traffico, il login con firmatario remoto [NIP-46](/it/topics/nip-46/) tramite QR o URI bunker incollata, account multipli con un commutatore interno all'app, e pacchetti di emoji personalizzati condivisi tra i client. L'eliminazione di un messaggio lo rimuove per entrambe le parti nei DM e nelle chat di gruppo, e Vector mantiene deliberatamente la chiave di firma effimera invece di seguire il flusso di eliminazione standard [NIP-17](/it/topics/nip-17/), una deviazione motivata dalla privacy che il progetto segnala esplicitamente nelle note di rilascio. Quattro giorni dopo, [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) rilascia **Concord v2**, descritto come portatore di importanti miglioramenti di privacy e stabilità alle Communities mantenendo funzionanti quelle esistenti, insieme a un selettore di comandi con barra in stile Discord per i bot con parametri tipizzati, un timer di autodistruzione per chat, e un sistema di badge NIP-58 per i cacciatori di bug. L'allontanamento da Marmot per la chat di gruppo arriva la stessa settimana in cui [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) più sotto continua a investire nella specifica. + +### Amethyst rilascia un'implementazione pulita di Concord per comunità cifrate end-to-end + +[Amethyst](https://github.com/vitorpamplona/amethyst) è un client Nostr ricco di funzionalità per Android e multipiattaforma. [PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) aggiunge un'implementazione completa di [Concord](/it/topics/concord-protocol/) (da CORD-01 a CORD-07) che copre comunità serverless e cifrate end-to-end: piani di controllo, chat e guestbook avvolti con gift-wrap su relay ordinari, applicazione di ruoli e ban radicata nel proprietario che ogni client verifica localmente invece di fidarsi di un server, e re-keying per tagliare fuori i membri rimossi. Il codice di protocollo e crittografia risiede in `quartz/`, i modelli di stato e vista in `commons/`, e le schermate e la navigazione in `amethyst/` per Android, con verbi CLI leggeri sotto `cli/`; non c'è ancora un'interfaccia desktop, poiché la logica condivisa risiede in `quartz`/`commons` perché Desktop la adotti in seguito. L'implementazione è pulita: costruita dalle specifiche CORD pubbliche e dalle costanti di protocollo osservate, sotto la licenza MIT di Amethyst, distinta dal codice AGPL-3.0 di Armada. I valori dei vettori di test di Armada sono stati portati nei test unitari di Quartz per confermare che i due client interoperano realmente a livello di protocollo, dando a Concord tre implementazioni indipendenti nel giro di pochi giorni: Vector che rilascia per primo, Armada come client di riferimento di Soapbox, e ora la build da specifica di Amethyst. + +### Sonar si separa da Bitchat con un'alpha multipiattaforma e una specifica per pacchetti di sticker + +[Sonar](https://sonarprivacy.xyz/) è un messenger e wallet con mesh Bluetooth più Nostr nato da Bitchat, con DM di gruppo Marmot interoperabili con White Noise. Il codice risiede in [hedwig-corp/bitchat-to-sonar](https://github.com/hedwig-corp/bitchat-to-sonar). [v0.1-alpha.7](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.7) aggiunge una finestratura limitata delle trascrizioni in stile Signal affinché le prestazioni di apertura e scorrimento restino local-first, sincronizza lo stato di scoperta dei peer vicini, e corregge i caricamenti di media Blossom che fallivano nella gestione del content-type e dello stato HTTP; la precedente [alpha.6](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.6) drenava gli eventi Marmot dal vivo per un aggiornamento più rapido della chat e chiudeva le lacune di parità di funzionalità tra Android e iOS su chiamate, messaggistica, wallet e push. Sonar è anche la fonte di specifica citata per [PR #2410](#open-sticker-pack-kinds-10031-and-30031), che registra i kind di evento per pacchetti di sticker sotto la specifica "Sonar Stickers" del progetto, dando a questo lancio un collegamento diretto al lavoro di protocollo di questa settimana. + +### Divine Mobile 1.0.16 introduce un editor video più completo, la cifratura a riposo e la provenienza ProofMode + +[Divine](https://github.com/divinevideo/divine-mobile) è un client di video brevi costruito su Nostr con curazione del feed tramite Web-of-Trust. [v1.0.16](https://github.com/divinevideo/divine-mobile/releases/tag/1.0.16), il primo rilascio taggato dal #30, aggiunge transizioni tra clip, riproduzione inversa, un registratore di voice-over e marcatori di ritmo sulla timeline all'editor video, insieme a un controllo di regolazione del feed che consente all'utente di scorrere per aggiustare le raccomandazioni direttamente invece di lasciarle a segnali di interazione opachi. Il rilascio attiva anche la cifratura a riposo per i dati locali, aggiunge caricamenti in background che sopravvivono alla sospensione dell'app, e trasporta i dati di provenienza [ProofMode](/it/topics/proofmode/) quando si scarica una clip con filigrana affinché l'attestazione di creazione umana non venga rimossa durante il transito. Divine include anche nuove protezioni per gli account di minori di 16 anni ed estende la localizzazione a 17 lingue e 284 stringhe tradotte. + +### Bitchat v1.7.0 aggiunge la voce push-to-talk dal vivo per i DM e la mesh pubblica + +[Bitchat](https://github.com/permissionlesstech/bitchat) è un'app di chat con mesh Bluetooth con un gateway opzionale verso i relay Nostr. [v1.7.0](https://github.com/permissionlesstech/bitchat/releases/tag/v1.7.0), rilasciata la sera in cui è stato pubblicato il #30, aggiunge la voce push-to-talk dal vivo in [PR #1403](https://github.com/permissionlesstech/bitchat/pull/1403) che trasmette l'audio mentre il mittente tiene premuto il pulsante e ripiega su una nota vocale se il flusso si interrompe, più il push-to-talk firmato sulla mesh pubblica in [PR #1406](https://github.com/permissionlesstech/bitchat/pull/1406) affinché le raffiche di voce dal vivo sul canale mesh condiviso portino l'autenticazione del mittente. Il rilascio ripara anche la rotazione del peer-ID riagganciando il collegamento su un ri-annuncio verificato, riconoscendo lo stesso peer sotto il suo nuovo ID ([PR #1401](https://github.com/permissionlesstech/bitchat/pull/1401)), e i messaggi diretti a un peer attualmente irraggiungibile ora vengono messi in coda con consegna store-and-forward invece di fallire subito ([PR #1415](https://github.com/permissionlesstech/bitchat/pull/1415)). Questo prosegue direttamente dalla copertura del #30 sul lavoro di proof-of-work [NIP-13](/it/topics/nip-13/) e sul gateway mesh-verso-Nostr della v1.6.0. + +### MDK v0.9.4 limita il login con firmatario esterno e aggiunge la persistenza delle bozze + +[MDK](https://github.com/marmot-protocol/mdk) è l'SDK di riferimento per il protocollo [Marmot](/it/topics/marmot/), il livello di messaggistica MLS-su-Nostr che il #30 ha trattato segnalandone l'adozione della specifica. [v0.9.4](https://github.com/marmot-protocol/mdk/releases/tag/v0.9.4) limita i passaggi di directory consultiva che un client percorre durante il login con firmatario esterno in [PR #793](https://github.com/marmot-protocol/mdk/pull/793), prevenendo un ciclo di tentativi illimitato quando un firmatario remoto è lento o non risponde. Lo stesso rilascio aggiunge la persistenza delle bozze di messaggio e i collegamenti profilo-sito web in [PR #812](https://github.com/marmot-protocol/mdk/pull/812), proseguendo il lavoro di irrobustimento incrementale che MDK porta avanti da quando ha rilasciato la v0.9.0. + +--- + +## Rilasci taggati + +### n_cord v1.1 aggiunge il supporto per NSEC Bunker + +[n_cord](https://github.com/0n4t3/n_cord) è un client di chat basato su Nostr ispirato a Discord e IRC. [v1.1](https://github.com/0n4t3/n_cord/releases/tag/v1.1) aggiunge il supporto per NSEC Bunker [NIP-46](/it/topics/nip-46/) insieme a una correzione di un bug nella gestione delle risposte. + +### cdk v0.17.3 aggiunge il supporto per il servizio di wallet NIP-47 su cdk, cdk-nwc e cdk-ffi + +[cdk](https://github.com/cashubtc/cdk) è un development kit per Cashu; questo rilascio è per la maggior parte solo Bitcoin/Lightning, ma [v0.17.3](https://github.com/cashubtc/cdk/releases/tag/v0.17.3) aggiunge il supporto per il servizio [NIP-47](/it/topics/nip-47/) (Nostr Wallet Connect) con un crate di servizio NWC dedicato, l'integrazione con il wallet, i binding FFI per `cdk-ffi`, e una copertura di test end-to-end, dando ai wallet Cashu costruiti su cdk una superficie Nostr Wallet Connect standard. + +### Coop Mobile v0.2.4 migliora Nostr Connect e aggiunge l'importazione ncryptsec1 + +[Coop Mobile](https://git.reya.su/reya/coop-mobile) è un client di messaggistica privata [NIP-17](/it/topics/nip-17/) per piattaforme mobili. [v0.2.4](https://git.reya.su/reya/coop-mobile/releases/tag/v0.2.4) migliora il suo flusso [NIP-46](/it/topics/nip-46/) Nostr Connect, corregge un indicatore di caricamento che rimaneva bloccato in modo permanente su alcune connessioni, e aggiunge il supporto all'importazione del formato di chiave cifrata [NIP-49](/it/topics/nip-49/) `ncryptsec1` insieme a una schermata di importazione dell'identità ridisegnata. + +### Nmail v0.14.0 arriva su macOS con invio programmato e notifiche push + +[Nmail](https://github.com/nogringo/nostr-mail-client) è un client di posta costruito su Nostr; [v0.14.0](https://github.com/nogringo/nostr-mail-client/releases/tag/v0.14.0) porta l'app su macOS, aggiunge l'invio programmato con una casella Programmati dedicata per i messaggi in coda, e aggiunge le notifiche push. Il rilascio passa anche la risoluzione degli identificatori Nostr della rubrica al resolver [NIP-05](/it/topics/nip-05/) di NDK al posto di un'implementazione su misura. + +### Nostrord v2.2.0 aggiunge un interruttore generale per i DM e messaggi diretti più ricchi + +[Nostrord](https://github.com/nostrord/nostrord) è un client di chat di gruppo basato su relay [NIP-29](/it/topics/nip-29/) per Android, iOS, web e desktop. [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) aggiunge un interruttore generale per disabilitare tutte le funzionalità di messaggistica diretta in una volta ([PR #175](https://github.com/nostrord/nostrord/pull/175)) e rilascia "messaggi diretti più ricchi" ([PR #186](https://github.com/nostrord/nostrord/pull/186)), proseguendo dalla copertura del #30 sul rilascio che consolidava il pool di relay e rilevava i WebSocket zombie. + +### Nostr WoT 0.3.86 irrobustisce i backup delle chiavi e le richieste di firma + +[Nostr WoT](https://github.com/nostr-wot/nostr-wot-extension) è un'estensione per browser che abbina un'identità Nostr a un wallet Lightning. [v0.3.86](https://github.com/nostr-wot/nostr-wot-extension/releases/tag/v0.3.86) sposta i backup delle chiavi cifrate al formato standard [NIP-49](/it/topics/nip-49/), fa sì che le richieste di firma mostrino l'evento completo e tutti i tag invece di un riepilogo, verifica i dati del relay rispetto alla loro firma, e smette di esporre l'identità attiva al cambio di account. L'estensione elimina anche il permesso `scripting` del browser inutilizzato. + +### Keep Android v1.1.8 aggiunge l'onboarding FROST al primo avvio + +[Keep](https://github.com/privkeyio/keep-android) è un firmatario Android costruito su frammenti di chiave a soglia FROST. [v1.1.8](https://github.com/privkeyio/keep-android/releases/tag/v1.1.8) aggiunge un flusso al primo avvio che spiega i frammenti di chiave FROST e consente a un nuovo utente di scegliere una politica di firma tra Manuale, Base o Automatica prima che arrivi la prima richiesta di firma, il primo onboarding lato Android per il modello di firma a soglia del crate keep-mobile sottostante. + +### Noscall v0.6.0 aggiunge un wallet Cashu e notifiche push basate su relay + +[Noscall](https://github.com/sanah9/noscall) è un'app per chiamate audio e video sicure costruita su Nostr. [v0.6.0](https://github.com/sanah9/noscall/releases/tag/v0.6.0-release) aggiunge un wallet Cashu con ambito account con saldi multi-mint, invio e ricezione di ecash, e pagamento e ricezione Lightning con persistenza delle quote. Il rilascio migra anche le notifiche push di Android da Firebase Cloud Messaging a un percorso di consegna basato su relay Nostr tramite UnifiedPush, e migliora l'affidabilità del VoIP di iOS e del push APNs durante i nuovi tentativi di login. + +### Kubo rilascia la modalità tablet e le foto nelle chat di gruppo + +[Kubo](https://github.com/JeroenOnNostr/kubo) è una piattaforma video Nostr sicura per bambini con curazione del feed tramite Web-of-Trust. [kubo-v2026.07.05](https://github.com/JeroenOnNostr/kubo/releases/tag/kubo-v2026.07.05) aggiunge un layout a griglia per tablet opzionale per il feed dei bambini e il supporto all'allegato di foto ai messaggi delle chat di gruppo, oltre a correzioni per il pulsante di registrazione che si nascondeva dietro la tastiera a schermo su Android. + +### Nostr Codex Phone v0.2.9 aggiunge richieste ausiliarie per git/diff/lettura di file + +[Nostr Codex Phone](https://github.com/tidley/nostr-codex-phone) è una superficie di controllo mobile per un worker locale di assistenza alla programmazione che comunica tramite DM Nostr cifrati. [v0.2.9](https://github.com/tidley/nostr-codex-phone/releases/tag/v0.2.9) aggiunge azioni di strumenti OpenCode mobili, incluse richieste ausiliarie per git, diff, lettura di file, stato e cronologia, miglioramenti al fissaggio e alla ricerca delle sessioni, e un controllo di arresto delle attività, insieme a un wrapper di caricamento cifrato su [Blossom](/it/topics/blossom/) che è stato rilasciato nella precedente v0.2.8. + +### GitWorkshop v3.0.3 corregge i ref appena annunciati nell'esploratore di repository, e rilascia la sua prima build Android + +[GitWorkshop](https://github.com/DanConwayDev/gitworkshop) è un'interfaccia web git-su-Nostr per esplorare e revisionare repository NIP-34. [v3.0.3](https://github.com/DanConwayDev/gitworkshop/releases/tag/v3.0.3) corregge le viste di rami, tag, commit ed esplorazione del codice che non riuscivano a risolvere un ref annunciato da un repository dopo che l'esploratore lo aveva già caricato, insieme alla pulizia dei tempi del flusso CI, confermato direttamente rispetto al tag e alla cronologia dei commit. La stessa settimana, GitWorkshop ha pubblicato la sua prima build Android nativa su [Zapstore](https://zapstore.dev), partendo dalla v3.0.0 e raggiungendo la v3.0.3 nel giro di ore; l'interfaccia web rimane l'interfaccia principale, e il pacchetto Android porta per la prima volta su un telefono la stessa esplorazione di repository NIP-34. + +### Bitcoin-Safe arriva su Flathub, mettendo in luce il suo plugin Nostr Sync & Chat + +[Bitcoin-Safe](https://bitcoin-safe.org) è un wallet Bitcoin ad autocustodia costruito attorno ai flussi di lavoro con firmatari hardware. Il progetto ha [pubblicato un pacchetto su Flathub](https://flathub.org/apps/org.bitcoin_safe.BitcoinSafe) questa settimana, il suo primo inserimento in uno store di applicazioni Linux mainstream. Il rilascio su Flathub mette il plugin Sync & Chat di Bitcoin-Safe davanti a un pubblico più ampio: il plugin usa i messaggi diretti [NIP-17](/it/topics/nip-17/), tramite la libreria [bitcoin-nostr-chat](https://github.com/andreasgriffin/bitcoin-nostr-chat) del progetto, per sincronizzare le etichette del wallet tra i dispositivi di un utente e per inviare e ricevere PSBT per la co-firma multisig remota tra partecipanti fidati. Il livello Nostr stesso è stato rilasciato prima, nella [2.0.0](https://github.com/andreasgriffin/bitcoin-safe/releases/tag/2.0.0) (2026-06-29), che ha ridisegnato la firma delle transazioni attorno a un tipo di connessione "Share via Chat & Sync" insieme a QR, USB e Bluetooth. La notizia di questa settimana è il pacchetto Flathub che mette quella funzionalità esistente davanti a un pubblico Linux mainstream per la prima volta. + +--- + +## Modifiche non rilasciate + +### Amethyst consente agli account di assegnare soprannomi ai contatti con schede NIP-85 cifrate + +Oltre all'[implementazione di Concord](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) trattata sopra, Amethyst ha integrato altre 54 PR nell'ultima settimana. La principale tra queste è [PR #3548](https://github.com/vitorpamplona/amethyst/pull/3548), che consente a un account di assegnare un soprannome a qualsiasi altro utente pubblicando la propria scheda di contatto kind 30382 [NIP-85](/it/topics/nip-85/) su di lui. Il soprannome, una nota privata, e qualsiasi mappatura personalizzata di codici brevi di emoji [NIP-30](/it/topics/nip-30/) risiedono all'interno del contenuto cifrato con [NIP-44](/it/topics/nip-44/) della scheda, così che solo l'account firmatario possa leggerli, e le schede si sincronizzano attraverso il set esteso di relay outbox dell'account al login e in modo incrementale in seguito. Feed, chat e menzioni rendono il soprannome al posto del nome visualizzato pubblico, con una scheda del soprannome toccabile nella pagina del profilo sopra il vero nome dell'utente. + +### Zap Cooking rilascia la Fase 3 di My Kitchen e corregge un bug di quorum del pool NDK + +[Zap Cooking](https://github.com/zapcooking/frontend) è un'app di condivisione di ricette e comunità culinaria costruita su Nostr. Ha integrato 43 PR proseguendo la sua funzionalità di pianificazione dei pasti "My Kitchen", introducendo in questa fase la generazione di liste della spesa, un selettore di ricette e una griglia settimanale del pianificatore. Lo stesso insieme di modifiche corregge un bug di prontezza del quorum del pool di connessioni di [NDK](https://github.com/nostr-dev-kit/ndk) (Nostr Development Kit) che poteva lasciare le letture dei relay in attesa oltre il punto in cui un quorum di relay aveva già risposto. + +### Kehto trasmette le letture di outbox prima della scoperta dei relay + +[Kehto](https://github.com/kehto/web) è un runtime web iniziale per applet Nostr [NIP-5D](/it/topics/nip-5d/), o "napplet". Ha integrato 26 PR. [PR #193](https://github.com/kehto/web/pull/193) corregge le letture di outbox che in precedenza attendevano il completamento del caricamento della lista di relay [NIP-65](/it/topics/nip-65/) prima di aprire qualsiasi relay, così che un caricamento della lista di relay che non si risolveva mai poteva bloccare sia la consegna degli eventi sia i timeout delle query; la correzione apre immediatamente gli hint di relay validati e trasmette i risultati man mano che vengono scoperti i relay di scrittura. Una seconda modifica ([PR #196](https://github.com/kehto/web/pull/196)) allinea la pagina di audit dell'identità del progetto con NAP-SHELL, il contratto di ciclo di vita della piattaforma Napplet, parte dello stesso lavoro di allineamento del protocollo visibile altrove nel rilascio `napplet/web` di questa settimana. + +### Wired e TAO aggiungono la condivisione dei ricavi per i creatori con NIP-57 + +[Wired](https://github.com/smolgrrr/Wired) e [TAO](https://github.com/smolgrrr/TAO) sono client social gemelli orientati alla libertà di parola costruiti su Nostr, che condividono la stessa lista di PR; entrambi hanno integrato [PR #121](https://github.com/smolgrrr/Wired/pull/121), che implementa la condivisione dei ricavi per i creatori [NIP-57](/it/topics/nip-57/) affinché gli zap inviati a un post possano dividersi automaticamente tra collaboratori oltre all'autore originale. Questo prosegue la copertura del #30 sulla coppia che alzava il proprio segnale di proof-of-work a 21 bit come lavoro non rilasciato. + +### Conduit Mono ricostruisce la casella degli ordini del commerciante attorno al checkout come ospite effimero + +[Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) è un protocollo di marketplace adiacente agli annunci classificati [NIP-99](/it/topics/nip-99/). [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174) aggiunge il checkout come ospite usando una chiave effimera generata dal browser: l'ospite invia un ordine cifrato e un rapporto di pagamento al commerciante usando quella chiave monouso, e il commerciante dà seguito fuori banda per telefono o email, così che l'acquirente non abbia mai bisogno di un'identità di casella durevole. [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175) ricostruisce la casella degli ordini del commerciante attorno a un unico modello di stato dell'ordine condiviso, separando i ruoli di acquirente e commerciante e richiedendo un codice di tracciamento e un corriere prima che un ordine fisico o misto possa passare a spedito. Il flusso di checkout del progetto si basa sui messaggi privati [NIP-17](/it/topics/nip-17/), sulla cifratura [NIP-44](/it/topics/nip-44/) e sul gift wrap [NIP-59](/it/topics/nip-59/). Il [NIP Deep Dive](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) di questa settimana copre le convenzioni di [Gamma Markets](/it/topics/gamma-markets/) verso cui questo stesso problema di stato dell'ordine si dirige. + +### Buzz irrobustisce il provisioning del creatore di canale attorno al kind 39002 + +[Buzz](https://github.com/block/buzz) è una piattaforma di comunicazione a mente collettiva che collega agenti IA e umani su Nostr. Ha integrato 240 PR nell'ultima settimana, proseguendo il suo arco di irrobustimento del livello di relay dalla copertura del #30 sulle metriche di turno degli agenti kind 44200. La correzione di questa settimana ([PR #1830](https://github.com/block/buzz/pull/1830)) tratta il creatore di un canale come membro prima che venga eseguita la logica di provisioning del canale kind 39002, chiudendo una race condition in cui il canale del creatore stesso poteva rifiutarlo durante la configurazione. + +### Nostr Docs adotta un firmatario NIP-49 con account multipli e accoppiamento QR + +[Nostr Docs](https://github.com/formstr-hq/nostr-docs) è un'applicazione di documenti collaborativi nativa di Nostr. Ha integrato 5 PR, quella notevole ([PR #50](https://github.com/formstr-hq/nostr-docs/pull/50)) adottando il pacchetto `@formstr/signer` per l'autenticazione completa [NIP-49](/it/topics/nip-49/) con cambio tra account multipli e accoppiamento QR, sostituendo un percorso di firma su misura precedente. + +### Anche rilasciato + +Correzioni minori di interoperabilità dei firmatari e di affidabilità sono arrivate in diversi progetti tracciati nell'ultima settimana senza superficie nuova sufficiente per un proprio paragrafo: [ngit-cli](https://github.com/DanConwayDev/ngit-cli), un client da riga di comando per un'alternativa a GitHub basata su Nostr, rilascia [v2.6.3](https://github.com/DanConwayDev/ngit-cli/releases/tag/v2.6.3) facendo sì che `ngit init` dia indicazioni di configurazione concrete invece di richiedere ripetutamente un nsec; [Manent](https://github.com/dtonon/manent), un'app privata di note e file cifrati costruita su Nostr, rilascia [v1.4.1](https://github.com/dtonon/manent/releases/tag/v1.4.1) correggendo il login con firmatario Android che si rompeva quando Amber restituisce un pubkey esadecimale e migliorando lo scorrimento del login bunker; [NoorNote](https://github.com/77elements/noornote), un client Nostr snello e privo di servizi Google, rilascia [v1.2.8](https://github.com/77elements/noornote/releases/tag/v1.2.8) correggendo le notifiche mancate dei gruppi Nostrord e aggiungendo un interruttore di avviso per i propri post; [Bray](https://github.com/forgesworn/bray), un server MCP Nostr consapevole della fiducia per agenti IA e umani, rilascia [v1.34.0](https://github.com/forgesworn/bray/releases/tag/v1.34.0) inviando i metadati del nome del client alla connessione bunker [NIP-46](/it/topics/nip-46/); [Lumilumi](https://github.com/TsukemonoGit/lumilumi), un client web Nostr, memorizza le liste di relay [NIP-65](/it/topics/nip-65/) nello storage locale come fallback offline; [Earthly](https://github.com/moogmodular/earthly), un'app di città e comunità locale basata su Nostr, aggiunge la ricerca geografica [NIP-50](/it/topics/nip-50/); e [lnbits](https://github.com/lnbits/lnbits), un sistema di wallet e account Lightning gratuito e open-source, rilascia [PR #3925](https://github.com/lnbits/lnbits/pull/3925) rendendo `send_nostr_dm` non bloccante all'interno di un rilascio per il resto focalizzato su Lightning. + +--- + +## Appena tracciati e scoperti + +### OpenDiscord v1.0.1 debutta come client in stile Discord su Nostr + +[OpenDiscord](https://github.com/sofia-gros/open-discord) è un client con server e canali in stile Discord costruito su Nostr con permessi basati sui ruoli e lobby vocali WebRTC/SFU. [v1.0.1](https://github.com/sofia-gros/open-discord/releases/tag/v1.0.1) è il primo rilascio con installer taggato del progetto. + +### Auditable Voting v0.1.140 allinea i ruoli di organizzatore, votante e proxy di audit + +[Auditable Voting](https://github.com/tidley/auditable-voting) è uno shell di voto solo client su Nostr. [v0.1.140](https://github.com/tidley/auditable-voting/releases/tag/v0.1.140) allinea i ruoli di organizzatore, votante e proxy di audit con l'esatto evento di definizione del questionario pubblico firmato dall'organizzatore, chiudendo una lacuna in cui un proxy di audit poteva agire su account generati obsoleti o su uno stato persistito da un worker o organizzatore diverso. + +### Cambium v0.3.2 si abbina a Heartwood come firmatario NIP-55 senza chiavi + +[Cambium](https://github.com/forgesworn/cambium) è la scelta Discovery di questo numero: un firmatario Android [NIP-55](/it/topics/nip-55/) che non conserva alcun materiale di chiave privata proprio, facendo da proxy per ogni richiesta di firma tramite [NIP-46](/it/topics/nip-46/) verso un firmatario hardware Heartwood compagno. Il progetto condivide l'organizzazione GitHub `forgesworn` con il progetto tracciato Bray, e Heartwood stesso è stato trattato nel #30 quando ha rilasciato il ponte di firma relay-verso-seriale con cui ora dialoga il lato Android di Cambium. [v0.3.2](https://github.com/forgesworn/cambium) rifinisce il foglio di approvazione per avvisare dal vivo quando l'identità selezionata differisce dal collegamento esistente dell'app e sposta le scritture del registro di attività in un'unica coda non bloccante. + +### Anche in lancio questa settimana: echoes, Dispatch e Linky + +Tre altri lanci meritano una menzione questa settimana. [echoes](https://github.com/Lwb89dev/echoes) è un'app di note offline-first e cifrata end-to-end che si sincronizza privatamente su Nostr. [Dispatch](https://github.com/freecritter/dispatch) è un organizzatore di viaggi local-first in cui ogni salvataggio è cifrato con [NIP-44](/it/topics/nip-44/) e sottoposto a backup su Nostr con una chiave dedicata e non collegabile, e il suo rilascio [v0.3.0](https://github.com/freecritter/dispatch) aggiunge il login Amber [NIP-55](/it/topics/nip-55/) affinché l'app non tocchi mai direttamente la chiave privata dell'utente. [Linky](https://github.com/hynek-jina/linky) combina contatti e DM Nostr con pagamenti Lightning e Cashu in un'unica progressive web app. + +--- + +## Lavoro di protocollo e aggiornamenti dei NIP + +Nessuna PR integrata nel [repository dei NIP](https://github.com/nostr-protocol/nips) nell'ultima settimana. Sono state aperte sei proposte. + +### Aperta: kind:10011 set di follow preferiti + +[PR #2413](https://github.com/nostr-protocol/nips/pull/2413), di fiatjaf, aggiunge i set di follow preferiti kind:10011. Rispecchia il modello esistente in cui kind:10012 (set di relay preferiti) contiene tag `a` che puntano a set di relay kind:30002, estendendo lo stesso meccanismo di preferenza ai set di follow kind:30000 affinché un client possa segnare una lista di follow curata senza sostituire la propria lista di contatti. + +### Aperta: unità cifrata privata che estende NIP-4E + +[PR #2412](https://github.com/nostr-protocol/nips/pull/2412), del team Form*, propone un evento Metadata generico, kind 34578, distinto da un tag identificatore `d` e da un tag di sottotipo `t`, insieme a un file system cifrato privato costruito su di esso che è già implementato nel client Form* Drive del progetto, ancora sperimentale. Un record di file è un evento Metadata con `t=files`: i blob dei file risiedono su server [Blossom](/it/topics/blossom/) mentre solo un indice cifrato risiede sui relay, e ogni chunk di file ottiene la propria coppia di chiavi effimera con cifratura [NIP-44](/it/topics/nip-44/) v2 derivata tramite HKDF. Un evento compagno di Chiave di Cifratura Disaccoppiata contiene un'unica chiave simmetrica valida per l'intera unità contro cui i metadati di ogni file vengono decifrati, e si basa esplicitamente su [NIP-4E](/it/topics/nip-4e/), la bozza di astrazione dello storage ancora aperta di fiatjaf ([PR #1647](https://github.com/nostr-protocol/nips/pull/1647), aperta da dicembre 2024). + +Quell'unica chiave valida per l'intera unità significa che una chiave trapelata espone i metadati di ogni file dell'unità, non solo di uno, poiché le coppie di chiavi effimere per file variano solo la chiave di cifratura del chunk, non la chiave di decifratura dei metadati; non esiste ancora alcun percorso di rotazione o revoca oltre alla pubblicazione di un nuovo evento Metadata che avverte che gli eventi più vecchi potrebbero andare persi. Una seconda proposta, più ristretta, raggiunge la stessa idea sottostante di NIP-4E da un'angolazione diversa: [PR #2361](https://github.com/nostr-protocol/nips/pull/2361), di fiatjaf, disaccoppia le chiavi di identità e cifratura all'interno della messaggistica [NIP-17](/it/topics/nip-17/) nello specifico, aperta dal 1° giugno. Entrambe le PR non sono integrate, lasciando questo un angolo attivo e conteso dello spazio di progettazione. Form* dice che il client Drive è sperimentale con un aggiornamento in arrivo a breve. + +### Aperta: NIP-DA condivisione privata di dati con permessi + +[PR #2411](https://github.com/nostr-protocol/nips/pull/2411), di JAFairweather, è una nuova bozza NIP-DA per la condivisione privata di dati con permessi attraverso concessioni di dati con ambito. Ogni utente mantiene un record cifrato e autoritativo per ambito sui relay, e l'accesso viene concesso consegnando privatamente la chiave simmetrica di quell'ambito dentro un gift wrap [NIP-59](/it/topics/nip-59/), così che i relay memorizzino solo testo cifrato e non sappiano mai chi ha concesso l'accesso a chi; una revoca è semplicemente una rotazione di chiave, senza bisogno di riscrivere la copia di ogni consumatore. L'autore la posiziona come distinta dai DM [NIP-17](/it/topics/nip-17/) (che possono portare uno snapshot di dati ma non aggiornamenti dal vivo né revoca) e dalle liste private NIP-51 (che non portano materiale di chiave), e cita due implementazioni indipendenti, una libreria di riferimento in JavaScript e una CLI in Go su go-nostr, testate in modo incrociato contro relay.damus.io, nos.lol e relay.primal.net. + +### Aperta: kind per pacchetti di sticker 10031 e 30031 + +[PR #2410](https://github.com/nostr-protocol/nips/pull/2410), di vincenzopalazzo, registra il kind 30031 (pacchetti di sticker indirizzabili) e il kind 10031 (la lista di pacchetti di sticker di un utente) nella tabella Event Kinds, specificati dal formato "Sonar Stickers" che [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) rilascia questa settimana. I kind si collocano deliberatamente uno slot sopra i kind di emoji personalizzati [NIP-30](/it/topics/nip-30/) 30030 e 10030 affinché un client non possa scambiare un pacchetto di sticker per un set di emoji; i byte dell'immagine degli sticker risiedono su server HTTPS compatibili con [Blossom](/it/topics/blossom/), e i riferimenti agli sticker inviati portano un hash in testo semplice affinché un pacchetto indirizzabile modificato non possa cambiare silenziosamente l'aspetto degli sticker già inviati in vecchi messaggi. Una PR compagna registra gli stessi kind nel progetto separato `registry-of-kinds`. + +### Aperta: fissaggio dei messaggi NIP-29 con kind:9010 e kind:39005 + +[PR #2379](https://github.com/nostr-protocol/nips/pull/2379), di Anderson-Juhasc, aggiunge il fissaggio dei messaggi ai gruppi basati su relay [NIP-29](/it/topics/nip-29/): kind:9010 `update-pin-list` è un evento di moderazione che porta la lista completa degli eventi fissati come tag `e` in ordine di visualizzazione, così che un singolo evento possa fissare, rimuovere dal fissaggio, riordinare o azzerare il set fissato, e kind:39005 è uno specchio generato dal relay che espone l'ultima lista accettata. Il design sostituisce un precedente approccio a coppie aggiungi/rimuovi di [PR #1163](https://github.com/nostr-protocol/nips/pull/1163) dopo il feedback della revisione, e sceglie i numeri di kind 9010/39005 perché 9009 e 39003 sono nel frattempo stati rivendicati da `create-invite` e dai ruoli di gruppo. Anderson-Juhasc mantiene anche [Nostrord](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages), la cui [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) viene rilasciata questa stessa settimana. + +### Aperta: ristrutturazione della scoperta di relay NIP-66 + +[PR #2241](https://github.com/nostr-protocol/nips/pull/2241), di VincenzoImp, è una ristrutturazione sostanziale della scoperta di relay [NIP-66](/it/topics/nip-66/). Sostituisce la prosa vaga di "Altri tag includono" con una sezione strutturata di Tag Indicizzati, aggiunge un tag `W` che rispecchia il campo `attributes` di NIP-11 per il filtraggio della scoperta di relay, aggiunge un tag di etichetta `l` che usa spazi dei nomi standardizzati (`ISO-639-1`, `ISO-3166-1`, `IANA-asn`, `IANA-tz`, `nip66.label.city`), e organizza i tag di RTT, SSL/TLS, rete, geografici, DNS e HTTP in sezioni dedicate insieme a una nuova tabella di Tipi di Verifica. Corregge anche eventi di esempio rotti che avevano nomi di campo errati, un `kind` mancante e nomi di tipo di verifica non validi, e chiude la [issue #2171](https://github.com/nostr-protocol/nips/issues/2171). Tutte le modifiche restano retrocompatibili poiché ogni tag aggiunto è opzionale. + +--- + +## NIP Deep Dive: NIP-99 e l'estensione di commercio Gamma Markets + +[NIP-15](/it/topics/nip-15/), la specifica originale del Marketplace Nostr, è ormai legacy: modellava un banco del commerciante (kind 30017) con i prodotti (kind 30018) archiviati sotto di esso, e i client che un tempo ci giravano sopra, Shopstr tra questi, sono da allora passati agli annunci classificati [NIP-99](/it/topics/nip-99/) come specifica attiva. NIP-99 in sé è un singolo evento indirizzabile, kind 30402 per un annuncio attivo o kind 30403 per una bozza, senza alcun banco da creare prima. Lascia indefinito tutto ciò che va oltre l'annuncio: costo di spedizione, stato dell'ordine, ricevute, recensioni, e un modo per raggruppare più annunci sotto un'unica vetrina, esattamente le parti di NIP-15 che non sono mai state trasferite. [Gamma Markets](/it/topics/gamma-markets/) colma quella lacuna, ed è il livello di commercio moderno che vale la pena capire oggi. + +### La lacuna che NIP-99 lascia aperta + +Il campo `content` di un annuncio NIP-99 porta una descrizione in Markdown, `price` e `location` risiedono direttamente sull'evento, e i tag `t` lo rendono ricercabile come contenuto hashtag ordinario. Poiché è indirizzabile sulla tupla pubkey, kind e tag `d`, un venditore modifica un annuncio sul posto pubblicando una nuova versione con lo stesso tag `d`: + +```json +{ + "kind": 30402, + "content": "Vintage mechanical keyboard, Cherry MX Blue switches, barely used.", + "tags": [ + ["d", "keyboard-mx-blue-01"], + ["title", "Vintage Mechanical Keyboard"], + ["summary", "Cherry MX Blue, barely used"], + ["published_at", "1752537600"], + ["location", "NYC"], + ["price", "100", "USD"], + ["t", "electronics"] + ] +} +``` + +Questa è l'intera specifica: un annuncio classificato firmato e aggiornabile. Ogni client che implementa NIP-99 per un e-commerce reale, oltre a un classificato occasionale, ha finito per inventare le proprie convenzioni private per spedizione, messaggi d'ordine e recensioni. Due client NIP-99 potevano ciascuno rendere correttamente un annuncio e comunque non avere alcun modo condiviso di completare un checkout tra loro. + +### Gamma Markets: standardizzare ciò che NIP-99 ha lasciato fuori + +Gamma Markets è il nome che un gruppo di lavoro di sviluppatori di marketplace Nostr, i team dietro Shopstr, Cypher, Plebeian Market e Conduit Market, ha dato a un insieme condiviso di convenzioni di e-commerce costruite sopra l'evento kind 30402 esistente di NIP-99. La specifica è collegata dal documento canonico di NIP-99 tramite [PR #1784](https://github.com/nostr-protocol/nips/pull/1784) e mantenuta nel proprio repository, [GammaMarkets/market-spec](https://github.com/GammaMarkets/market-spec). + +Gamma Markets aggiunge due kind autonomi adiacenti agli annunci. Il kind 30405 raggruppa più annunci in una collezione di prodotti, referenziando ciascuno con un tag `a` esplicito: + +```json +{ + "kind": 30405, + "content": "Summer sale picks", + "tags": [ + ["d", "summer-picks"], + ["title", "Summer Sale"], + ["a", "30402::keyboard-mx-blue-01"], + ["shipping_option", "30406::standard-regional"] + ] +} +``` + +Il kind 30406 definisce un'opzione di spedizione con prezzi per paese e regole di costo opzionali basate su peso o distanza: + +```json +{ + "kind": 30406, + "content": "Standard Regional Shipping", + "tags": [ + ["d", "standard-regional"], + ["title", "Standard Shipping"], + ["price", "5.99", "USD"], + ["country", "US"], + ["service", "standard"], + ["duration", "24", "72", "H"], + ["weight-max", "30", "kg"] + ] +} +``` + +La creazione degli ordini, le richieste di pagamento, gli aggiornamenti di stato e spedizione, e le ricevute di pagamento viaggiano tutti come normali messaggi privati avvolti con gift-wrap [NIP-17](/it/topics/nip-17/), suddivisi in tre kind per ruolo, non ri-avvolgendo il trasporto: il kind 14 porta la comunicazione libera tra acquirente e commerciante, il kind 16 porta ogni transizione di stato dell'ordine (un tag `type` da 1 a 4 segna creazione dell'ordine, richiesta di pagamento, aggiornamento di stato o aggiornamento di spedizione), e il kind 17 porta la ricevuta di pagamento dell'acquirente. Un messaggio di creazione dell'ordine appare così prima del gift-wrapping: + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +Valutare un acquisto completato è un kind indirizzabile separato, 31555, che punta all'annuncio che recensisce: + +```json +{ + "kind": 31555, + "content": "Arrived fast, exactly as described.", + "tags": [ + ["d", "a:30402::keyboard-mx-blue-01"], + ["rating", "1", "thumb"], + ["rating", "1.0", "quality"], + ["rating", "0.9", "delivery"] + ] +} +``` + +Far viaggiare i messaggi d'ordine su NIP-17 significa che un checkout di Gamma Markets usa lo stesso trasporto di messaggi privati che i client già rilasciano per i DM, invece di un kind di messaggio d'ordine su misura. + +La scelta di progettazione centrale della specifica è che nulla si eredita a cascata. Un annuncio che appartiene a una collezione la referenzia esplicitamente con un tag `a` invece di ereditare automaticamente le opzioni di spedizione o la descrizione della collezione, e un'opzione di spedizione che un annuncio usa viene referenziata nello stesso modo esplicito. Questa è un'inversione deliberata del modello a banco di NIP-15, dove un prodotto ereditava silenziosamente qualunque valuta e tabella di spedizione definisse il suo banco genitore. Il compromesso è un tagging più esplicito su ogni annuncio, in cambio del fatto che la configurazione completa di un annuncio sia sempre leggibile dall'evento stesso, senza alcun oggetto genitore da risolvere prima. + +### Dove questo si manifesta nella pratica + +Il lavoro di [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) di questa settimana si colloca nello stesso territorio di messaggi d'ordine che Gamma Markets standardizza: il checkout come ospite con chiave effimera di [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174) e la ricostruzione della casella degli ordini del commerciante di [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175) risolvono entrambi il problema di stato dell'ordine acquirente/commerciante che i messaggi kind 14, 16 e 17 di Gamma Markets formalizzano; Conduit Mono esegue il proprio modello di stato dell'ordine accanto a quei kind, senza adottarli direttamente. Shopstr, uno dei quattro progetti che hanno scritto la specifica, ha tenuto in movimento anche il proprio impianto di commercio nell'ultima settimana: [PR #568](https://github.com/shopstr-eng/shopstr/pull/568) estrae la logica di gift-wrap NIP-17 duplicata in un modulo condiviso, e [PR #567](https://github.com/shopstr-eng/shopstr/pull/567) porta il suo parser di autenticazione HTTP [NIP-98](/it/topics/nip-98/) a una copertura di test completa, manutenzione esattamente sui livelli di messaggistica e autenticazione da cui un flusso d'ordine di Gamma Markets dipende per raggiungere acquirente e commerciante in sicurezza. + +NIP-15 ha perso il ruolo di vetrina standardizzando un banco e un prodotto, e poi lasciando pagamenti, spedizione, recensioni e stato dell'ordine come problema dell'applicazione. Gamma Markets colma la maggior parte di quella superficie mancante senza toccare la forma a singolo annuncio di NIP-99, costruendo sullo stack di DM esistente di Nostr, NIP-17, invece di inventare un nuovo livello di messaggistica. + +--- + +Questo è tutto per questa settimana. Stai costruendo qualcosa o hai notizie da condividere? Scrivici via DM NIP-17 o trovaci su Nostr. diff --git a/content/it/topics/concord-protocol.md b/content/it/topics/concord-protocol.md new file mode 100644 index 0000000..d5136a6 --- /dev/null +++ b/content/it/topics/concord-protocol.md @@ -0,0 +1,61 @@ +--- +title: "Protocollo Concord" +date: 2026-07-15 +translationOf: /en/topics/concord-protocol.md +translationDate: 2026-07-15 +draft: false +categories: + - Protocol + - Messaging +--- + +Concord è un protocollo aperto, con licenza MIT, per community e canali end-to-end encrypted su Nostr, definito dalle [specifiche CORD-01 fino a CORD-07](https://github.com/concord-protocol/concord). [Vector](https://github.com/VectorPrivacy/Vector) lo ha adottato come trasporto predefinito per la funzione Group Chats a partire dalla v0.4.0, descrivendolo nelle proprie release note come "our custom messaging protocol", ma la specifica viene pubblicata separatamente da Vector e dispone già di implementazioni indipendenti. + +## Come funziona + +Concord scompone ciò che un community server in stile Discord fa normalmente in parti che non devono fidarsi di nessuno: i relay memorizzano esclusivamente blob cifrati indirizzati a etichette rotanti, possedere la chiave di una stanza è ciò che rende qualcuno membro, e l'autorità su ruoli, espulsioni e ban è un roster firmato radicato nell'identità del proprietario che ogni client verifica localmente invece di fidarsi di un server. Ogni event durevole utilizza lo stesso involucro a tre livelli: un kind 1059 wrap firmato con la stream key derivata del piano, contenente un seal firmato con la chiave reale dell'autore, contenente un rumor non firmato che trasporta l'event funzionale. Un rumor di messaggio chat è un semplice event kind 9: + +```json +{ + "kind": 9, + "pubkey": "", + "content": "Hey chat!", + "tags": [ + ["channel", ""], + ["epoch", "0"] + ] +} +``` + +Il traffico control, chat e guestbook riceve ciascuno il proprio piano [NIP-59](/it/topics/nip-59/) gift-wrapped, perciò un relay che detiene tutti e tre non può distinguere un messaggio di controllo da un messaggio chat o da una voce del guestbook senza la chiave della stanza. La specifica è suddivisa in sette documenti CORD: stream privati (01), community e membership (02), canali (03), ruoli (04), inviti (05), rekeying e ri-fondazione per escludere i membri rimossi (06), e audio/video tramite un blind token broker (07). La membership stessa non ha una lista lato server: chi può decifrare il piano è membro, e rimuovere davvero qualcuno significa far ruotare la community su una nuova key epoch e consegnarla solo a chi resta, invece di cancellare una riga da una tabella. + +## Differenze rispetto a Marmot + +Concord e [Marmot](/it/topics/marmot/) risolvono la messaggistica di gruppo cifrata su Nostr con crittografia differente per forme di gruppo differenti, e il confronto del progetto Concord è esplicito riguardo alla distinzione: Marmot sovrappone [MLS](/it/topics/mls/) a Nostr per forward secrecy e post-compromise security, utilizzando key package per dispositivo e commit ordinati che avanzano l'intero gruppo in sincrono. Questo offre garanzie forti, con costi che crescono al variare della membership, adatto a gruppi piccoli e ad alta sensibilità dove ingressi e uscite sono rari. Concord, al contrario, dà a ogni membro la stessa chiave della stanza ed esegue il rekeying dell'intera stanza alla rimozione invece di procedere con il ratchet per ogni commit, scambiando alcune delle garanzie crittografiche di MLS con un modello che resta economico quando una community cresce fino a centinaia o migliaia di membri occasionali con alto turnover, esattamente la forma che le community in stile Discord assumono nella pratica. + +## Perché Vector ha cambiato + +Le stesse [release note di Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) descrivono Concord solo come "our custom messaging protocol" per i Group Chats, senza indicare direttamente la motivazione. La coerenza con la ratio pubblicata di Concord è comunque chiara: i Group Chats in un client come Vector sono esattamente il caso con membership ampia, aperta e frequentemente variabile in cui lo stato MLS per dispositivo di Marmot diventa il percorso più costoso, e il design asincrono di Concord, con possibilità di unirsi in qualsiasi momento, è costruito proprio per quel caso. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) ha ritirato Marmot per i Group Chats a favore di Concord, e la cronologia dei gruppi Marmot esistenti non è stata trasferita nel passaggio. [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) ha distribuito "Concord v2" quattro giorni dopo con miglioramenti di privacy e stabilità. Nella stessa settimana, [Amethyst ha integrato la propria implementazione Concord clean-room e wire-compatible](https://github.com/vitorpamplona/amethyst/pull/3566), e il client in stile Discord di Soapbox, [Armada](https://gitlab.com/soapbox-pub/armada), costruisce già la funzione Communities sulla stessa specifica come implementazione di riferimento. Tre client indipendenti che convergono su una specifica aperta nell'arco di pochi giorni rappresentano un percorso rapido verso una reale interoperabilità tra client, un aspetto che vale la pena seguire rispetto a quanti degli altri client di group chat su Nostr rimarranno su Marmot. + +## Implementazioni + +- [Vector](https://github.com/VectorPrivacy/Vector) - messenger Nostr a singolo binario, incentrato sulla privacy; primo client Concord distribuito, nella v0.4.0 +- [Armada](https://gitlab.com/soapbox-pub/armada) (Soapbox) - client community in stile Discord; implementazione di riferimento, backend nel repository separato `armada-relay` +- [Amethyst](https://github.com/vitorpamplona/amethyst) - client Nostr Android e multipiattaforma ricco di funzionalità; reimplementazione clean-room wire-compatible con Armada ([PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566)) + +--- + +**Fonti primarie:** +- [Specifiche del protocollo Concord (CORD-01 a CORD-07)](https://github.com/concord-protocol/concord) +- [Release note di Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) +- [Release note di Vector v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) +- [Amethyst PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) + +**Menzionato in:** +- [Newsletter #31: Vector v0.4.0 sposta i Group Chats da Marmot a Concord, e Amethyst distribuisce il proprio client Concord pochi giorni dopo](/it/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) +- [Newsletter #31: Amethyst distribuisce un'implementazione Concord clean-room per community end-to-end encrypted](/it/newsletters/2026-07-15-newsletter/#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) + +**Vedi anche:** +- [Protocollo Marmot](/it/topics/marmot/) +- [MLS (Message Layer Security)](/it/topics/mls/) +- [NIP-46: Nostr Connect](/it/topics/nip-46/) diff --git a/content/it/topics/gamma-markets.md b/content/it/topics/gamma-markets.md new file mode 100644 index 0000000..8a4b897 --- /dev/null +++ b/content/it/topics/gamma-markets.md @@ -0,0 +1,69 @@ +--- +title: "Gamma Markets" +date: 2026-07-15 +translationOf: /en/topics/gamma-markets.md +translationDate: 2026-07-15 +draft: false +categories: + - Commerce + - Marketplace + - Protocol +--- + +Gamma Markets è un insieme di convenzioni e-commerce costruite direttamente su [NIP-99](/it/topics/nip-99/) classified listings, sviluppate in modo collaborativo da un gruppo di lavoro di sviluppatori di marketplace Nostr: i team dietro Shopstr, Cypher, Plebeian Market e Conduit Market. Colma le lacune relative a spedizione, flusso ordini, collezioni e recensioni che NIP-99 lascia indefinite. + +## Come funziona + +Gamma Markets aggiunge cinque event kind attorno all'event kind `30402` listing già esistente in NIP-99, senza modificarne la struttura: + +- **Kind 30405** - collezioni di prodotti, che raggruppano più listing tramite tag `a` +- **Kind 30406** - opzioni di spedizione, con prezzi per paese e regole di costo opzionali basate su peso o distanza +- **Kind 16** - messaggi d'ordine: creazione (type 1), richieste di pagamento (type 2), aggiornamenti di stato (type 3) e aggiornamenti di spedizione (type 4) +- **Kind 14** - comunicazione generica acquirente/venditore +- **Kind 17** - ricevute di pagamento +- **Kind 31555** - recensioni di prodotto, indirizzate a una specifica pubkey del venditore e al tag `d` del listing + +Le preferenze di pagamento del venditore sono dichiarate tramite un tag `payment_preference` nei metadati del profilo kind `0`, e i client scoprono le app compatibili attraverso le raccomandazioni applicative [NIP-89](/it/topics/nip-89/). La comunicazione degli ordini si basa sui messaggi privati [NIP-17](/it/topics/nip-17/), senza introdurre uno schema di cifratura proprio. + +La scelta progettuale distintiva della specifica è che nulla viene ereditato automaticamente: un listing che appartiene a una collezione, o che utilizza un'opzione di spedizione, la referenzia esplicitamente con un tag `a` invece di ereditare le impostazioni del contenitore. Si tratta di un distacco deliberato dal vecchio modello stall di [NIP-15](/it/topics/nip-15/), in cui un prodotto ereditava silenziosamente la valuta e la tabella spedizioni del proprio stall genitore. + +### Esempio: creazione ordine (kind 16, type 1) + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +## Perché è importante + +NIP-99 da solo standardizza unicamente il listing stesso, un annuncio classificato firmato e indirizzabile. Prima di Gamma Markets, ogni client che costruiva e-commerce reale su NIP-99 inventava le proprie convenzioni private per spedizione, checkout e recensioni, il che significava che due client conformi a NIP-99 potevano ciascuno visualizzare correttamente un listing ma non avevano un modo condiviso per completare un ordine tra di loro. Gamma Markets colma questa lacuna senza modificare il formato listing di NIP-99, perciò i listing NIP-99 esistenti restano validi senza alcuna modifica. + +## Implementazioni + +- [Shopstr](https://github.com/shopstr-eng/shopstr) - marketplace Nostr, uno dei quattro progetti che hanno creato la specifica +- [Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) - protocollo marketplace che costruisce il proprio flusso di stato ordini e checkout nello stesso spazio progettuale + +--- + +**Fonti primarie:** +- [Repository della specifica Gamma Markets](https://github.com/GammaMarkets/market-spec) +- [Estensione del caso d'uso e-commerce per NIP-99, PR #1784](https://github.com/nostr-protocol/nips/pull/1784) - link dal documento canonico NIP-99 alla specifica Gamma Markets + +**Menzionato in:** +- [Newsletter #31: NIP Deep Dive: NIP-99 e l'estensione commerce Gamma Markets](/it/newsletters/2026-07-15-newsletter/#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) + +**Vedi anche:** +- [NIP-99: Classified Listings](/it/topics/nip-99/) +- [NIP-15: Nostr Marketplace](/it/topics/nip-15/) +- [NIP-17: Private Direct Messages](/it/topics/nip-17/) diff --git a/content/it/topics/nip-4e.md b/content/it/topics/nip-4e.md new file mode 100644 index 0000000..fe39b98 --- /dev/null +++ b/content/it/topics/nip-4e.md @@ -0,0 +1,46 @@ +--- +title: "NIP-4E: Separazione della cifratura dall'identità" +date: 2026-07-15 +translationOf: /en/topics/nip-4e.md +translationDate: 2026-07-15 +draft: false +categories: + - NIP + - Protocol + - Encryption +--- + +NIP-4E è una bozza aperta, proposta da fiatjaf, per condividere dati privati tra i dispositivi di uno stesso utente senza che ogni dispositivo detenga la chiave di identità Nostr principale dell'utente. Non è stata unita al repository e resta una proposta `draft`/`optional`. + +## Il problema che affronta + +Molti NIP esistenti, tra cui le liste NIP-51 e i wallet Cashu NIP-60, cifrano i dati dall'utente verso sé stesso usando la chiave di identità, in modo da poterli rileggere in seguito su qualsiasi dispositivo. Questo meccanismo si interrompe quando la chiave di identità non è direttamente accessibile, ad esempio quando un remote signer è protetto da share FROST di soglia, MuSig2 o un enclave sicuro in hosting, perché cifrare e decifrare richiede in quel caso un round trip verso il signer ogni volta. Rende inoltre impossibile la cifratura offline ogni volta che la chiave di firma risiede in un bunker remoto. + +## Come funziona + +NIP-4E separa una "client key" per dispositivo da una "encryption key" condivisa che non è la chiave di identità dell'utente: + +1. Il primo client configurato dall'utente genera una coppia di chiavi di cifratura casuali e ne annuncia la metà pubblica in un event `kind:10044` firmato dalla chiave di identità dell'utente. +2. Qualsiasi altro client che desideri cifrare o decifrare dati per quell'utente calcola il proprio segreto condiviso Diffie-Hellman rispetto alla chiave di cifratura annunciata anziché alla chiave di identità. +3. Quando un secondo dispositivo installa un nuovo client, quel client genera la propria "client key" locale e pubblica un annuncio `kind:4454` (anch'esso firmato dalla chiave di identità dell'utente) chiedendo al primo client di condividere la chiave di cifratura. +4. Il client originale rileva il nuovo annuncio `kind:4454`, cifra la chiave di cifratura condivisa verso la chiave del nuovo client usando [NIP-44](/it/topics/nip-44/) e la pubblica affinché il nuovo client possa decifrarla e utilizzarla da quel momento in poi. + +Il risultato è che cifratura e decifratura non richiedono più di interrogare il signer della chiave di identità una volta che un client possiede localmente la chiave di cifratura condivisa, e una configurazione con remote signer (FROST, MuSig2, enclave in hosting) può essere utilizzata per l'identità mentre la cifratura ordinaria resta veloce e funziona offline. + +## Perché è importante + +NIP-4E è citato come fondamento per altre proposte che necessitano di una chiave simmetrica a livello di drive o di account senza dipendere da un remote signer per ogni chiamata di cifratura/decifratura, tra cui una proposta di drive cifrato privato ([PR #2412](https://github.com/nostr-protocol/nips/pull/2412)) e una versione più ristretta della stessa idea specifica per NIP-17 ([PR #2361](https://github.com/nostr-protocol/nips/pull/2361)). Entrambe restano aperte insieme a NIP-4E stesso, rendendo quest'area una parte attiva e non ancora definita del protocollo piuttosto che un elemento costruttivo già concluso. + +--- + +**Fonti primarie:** +- [Bozza NIP-4E, PR #1647](https://github.com/nostr-protocol/nips/pull/1647) + +**Menzionato in:** +- [Newsletter #31: Aperto: il drive cifrato privato estende NIP-4E](/it/newsletters/2026-07-15-newsletter/#open-private-encrypted-drive-extends-nip-4e) + +**Vedi anche:** +- [NIP-44: Encrypted Payloads](/it/topics/nip-44/) +- [NIP-17: Private Direct Messages](/it/topics/nip-17/) +- [NIP-46: Nostr Connect](/it/topics/nip-46/) +- [FROST](/it/topics/frost/) diff --git a/content/it/topics/proofmode.md b/content/it/topics/proofmode.md new file mode 100644 index 0000000..f5bed92 --- /dev/null +++ b/content/it/topics/proofmode.md @@ -0,0 +1,36 @@ +--- +title: "ProofMode" +date: 2026-07-15 +translationOf: /en/topics/proofmode.md +translationDate: 2026-07-15 +draft: false +categories: + - Media + - Provenance +--- + +[ProofMode](https://proofmode.org/) è un toolkit open-source per la provenienza dei media, sviluppato da Guardian Project, WITNESS e Okthanks, che associa dati verificabili di autenticità e catena di custodia a foto e video al momento della cattura. Non è specifico per Nostr; i client Nostr che trasportano dati ProofMode integrano uno standard esterno già esistente anziché un nuovo livello di protocollo. + +## Come funziona + +Il componente Capture di ProofMode incorpora metadati di provenienza direttamente nei file multimediali durante la cattura, supportando gli stessi standard interoperabili utilizzati dalla Content Authenticity Initiative (CAI), Content Credentials (CR) e C2PA. Un componente Verify separato ispeziona file audio, immagine e video per verificare quei metadati alla ricerca di segni di generazione tramite IA o modifiche successive, e un componente Preserve gestisce l'archiviazione ridondante e decentralizzata dei dati di prova sottostanti per la conservazione a lungo termine. Un SDK Develop consente alle app di integrare cattura e verifica senza costruire autonomamente il formato di provenienza. + +## Perché è importante + +Per un client Nostr di video o immagini, trasportare dati ProofMode significa che chi guarda dispone di un metodo esterno e multipiattaforma per verificare se un contenuto multimediale è stato catturato come dichiarato e non è stato alterato silenziosamente da allora, senza fare affidamento sul client di pubblicazione o sul relay come fonte di fiducia. Questa distinzione conta soprattutto per una copia scaricata o ricodificata di un clip: i dati di provenienza che sopravvivono al download e a qualsiasi watermarking applicato dal client sono ciò che rende l'attestazione ancora verificabile dopo che il file ha lasciato l'app che lo ha prodotto. + +## Implementazioni + +- [Divine](https://github.com/divinevideo/divine-mobile) - client Nostr di video brevi; trasporta i dati di provenienza ProofMode attraverso i download di clip con watermark + +--- + +**Fonti primarie:** +- [ProofMode](https://proofmode.org/) + +**Menzionato in:** +- [Newsletter #17](/it/newsletters/2026-04-29-newsletter/) +- [Newsletter #31: Divine Mobile 1.0.16 distribuisce un editor video più avanzato, cifratura at-rest e provenienza ProofMode](/it/newsletters/2026-07-15-newsletter/#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) + +**Vedi anche:** +- [Blossom](/it/topics/blossom/) From 7b3358e62fbf38be9e7708c2fc3858d1ff065999 Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Thu, 16 Jul 2026 08:23:28 +0000 Subject: [PATCH 06/10] Add Japanese translation for Newsletter #31 and topic pages --- .../ja/newsletters/2026-07-15-newsletter.md | 300 ++++++++++++++++++ content/ja/topics/concord-protocol.md | 61 ++++ content/ja/topics/gamma-markets.md | 69 ++++ content/ja/topics/nip-4e.md | 46 +++ content/ja/topics/proofmode.md | 36 +++ 5 files changed, 512 insertions(+) create mode 100644 content/ja/newsletters/2026-07-15-newsletter.md create mode 100644 content/ja/topics/concord-protocol.md create mode 100644 content/ja/topics/gamma-markets.md create mode 100644 content/ja/topics/nip-4e.md create mode 100644 content/ja/topics/proofmode.md diff --git a/content/ja/newsletters/2026-07-15-newsletter.md b/content/ja/newsletters/2026-07-15-newsletter.md new file mode 100644 index 0000000..0176c67 --- /dev/null +++ b/content/ja/newsletters/2026-07-15-newsletter.md @@ -0,0 +1,300 @@ +--- +title: "Nostr Compass #31" +date: 2026-07-15 +publishDate: 2026-07-15 +draft: false +type: newsletters +translationOf: /en/newsletters/2026-07-15-newsletter.md +translationDate: 2026-07-15 +description: "Vector v0.4.0 がグループチャットの Marmot を廃止し、オープンな MIT ライセンスの Concord プロトコルに切り替え、数日後に Concord v2 を出荷。Amethyst が独自のクリーンルーム版 Concord 実装をマージ。Sonar が Bitchat から分離してクロスプラットフォームのアルファ版とステッカーパック仕様を公開。Divine Mobile 1.0.16 が保存時暗号化と ProofMode の来歴情報を搭載。Bitchat 1.7.0 がライブのプッシュトゥトーク音声を追加。MDK v0.9.4 が外部署名者ログインに上限を設ける。" +--- + +Nostr Compass へようこそ。毎週お届けする Nostr のガイドです。 + +**今週:** [Vector v0.4.0](#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) はグループチャットのデフォルトトランスポートである [Marmot](/ja/topics/marmot/) を廃止し、Soapbox の Armada でも使われているオープンな MIT ライセンスのコミュニティプロトコル [Concord](/ja/topics/concord-protocol/) に切り替えました。そして 4 日後には Concord v2 を出荷し、ボット向けのスラッシュコマンドピッカー、自己破壊タイマー、NIP-58 バッジを追加しました。同じ週に [Amethyst が独自のクリーンルーム版でワイヤー互換の Concord 実装をマージしました](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities)。[Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) は Bitchat から分離してクロスプラットフォームのアルファ版を公開し、今週のステッカーパック kind 提案で引用された仕様のソースにもなっています。[Divine Mobile 1.0.16](#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) はより高度なビデオエディター、保存時暗号化、そしてウォーターマーク付きクリップのダウンロードを経ても残る ProofMode の来歴情報を搭載しました。[Bitchat v1.7.0](#bitchat-v170-adds-live-push-to-talk-voice-for-dms-and-the-public-mesh) は DM 向けのライブのプッシュトゥトーク音声と、公開メッシュ上での署名付きプッシュトゥトークを追加しました。[MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) は外部署名者ログインに上限を設け、下書きの永続化を追加し、Vector がグループチャットの仕様から離れたのと同じ週に堅牢化作業を継続しています。 + +タグ付きリリースには、[n_cord v1.1](#n_cord-v11-adds-nsec-bunker-support) の NSEC Bunker サポート追加、[cdk v0.17.3](#cdk-v0173-adds-nip-47-wallet-service-support-across-cdk-cdk-nwc-and-cdk-ffi) の cdk・cdk-nwc・cdk-ffi 全体にわたる NIP-47 ウォレットサービスサポート追加、[Coop Mobile v0.2.4](#coop-mobile-v024-improves-nostr-connect-and-adds-ncryptsec1-import) の Nostr Connect 改善と ncryptsec1 インポート追加、[Nmail v0.14.0](#nmail-v0140-ships-on-macos-with-scheduled-send-and-push-notifications) の macOS 対応と予約送信、[Nostrord v2.2.0](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages) の DM マスタートグル追加、[Nostr WoT 0.3.86](#nostr-wot-0386-hardens-key-backups-and-signing-prompts) の鍵バックアップの NIP-49 形式への堅牢化、[Keep Android v1.1.8](#keep-android-v118-adds-first-run-frost-onboarding) の初回起動時 FROST オンボーディング追加、[Noscall v0.6.0](#noscall-v060-adds-a-cashu-wallet-and-relay-based-push-notifications) の Cashu ウォレットと relay ベースのプッシュ通知追加、[Kubo](#kubo-ships-tablet-mode-and-group-chat-photos) のタブレットモードとグループチャット写真追加、そして [Nostr Codex Phone v0.2.9](#nostr-codex-phone-v029-adds-gitdiffread-file-helper-requests) の git・diff・ファイル読み取りの補助リクエスト追加が含まれます。 + +未リリースの側では、[Amethyst](#amethyst-lets-accounts-nickname-contacts-with-encrypted-nip-85-cards) が 54 件のマージ済み PR にわたり、暗号化された NIP-85 カードでアカウントが連絡先にニックネームを付けられるようにしました。[Zap Cooking](#zap-cooking-ships-my-kitchen-phase-3-and-fixes-an-ndk-pool-quorum-bug) は My Kitchen フェーズ 3 を出荷し、NDK プールのクォーラムバグを修正しました。[Kehto](#kehto-streams-outbox-reads-before-relay-discovery) は relay 検出が完了する前に outbox 読み取りをストリーミングします。[Wired と TAO](#wired-and-tao-add-nip-57-creator-revenue-sharing) は NIP-57 のクリエイター収益分配を追加しました。[Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) は加盟店の注文受信トレイを一時的なゲストチェックアウトを中心に再構築しました。[Buzz](#buzz-hardens-channel-creator-provisioning-around-kind-39002) は 240 件のマージ済み PR にわたりチャンネル作成者のプロビジョニングを堅牢化しました。そして [Nostr Docs](#nostr-docs-adopts-a-nip-49-signer-with-multi-account-and-qr-pairing) は複数アカウントと QR ペアリングに対応した NIP-49 署名者を採用しました。今週新たに追跡対象になったもの: [OpenDiscord v1.0.1](#opendiscord-v101-launches-as-a-discord-style-client-on-nostr)、[Auditable Voting v0.1.140](#auditable-voting-v01140-aligns-organiser-voter-and-audit-proxy-roles)、そして Discovery の選出 [Cambium v0.3.2](#cambium-v032-pairs-with-heartwood-as-a-keyless-nip-55-signer) は、Heartwood ハードウェアコンパニオンにプロキシする鍵を持たない NIP-55 署名者です。 + +NIPs リポジトリはこの 1 週間で何もマージせず、6 件の提案をオープンしました: [kind:10011 お気に入りフォローセット](#open-kind10011-favorite-follow-sets)、[NIP-4E を拡張するプライベート暗号化ドライブ](#open-private-encrypted-drive-extends-nip-4e)、[NIP-DA 権限付きプライベートデータ共有](#open-nip-da-permissioned-private-data-sharing)、[ステッカーパック kind 10031 と 30031](#open-sticker-pack-kinds-10031-and-30031)、[NIP-29 のメッセージ固定](#open-nip-29-message-pinning-with-kind9010-and-kind39005)、そして [NIP-66 relay 検出の再構成](#open-nip-66-relay-discovery-restructure)。Deep Dive では [NIP-99 と Gamma Markets のコマース拡張](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) を取り上げます。 + +--- + +## 主要ストーリー + +### Vector v0.4.0 がグループチャットを Marmot から Concord に移行、数日後に Amethyst が独自の Concord クライアントを出荷 + +[Vector](https://github.com/VectorPrivacy/Vector) は、DM とグループチャット向けにプライバシー優先のシングルバイナリクライアントを中心に構築された Nostr メッセンジャーです。[Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) はアプリのメッセージングエンジンを共有ライブラリ `vector-core` に書き換え、同じリリースでグループチャットのデフォルトトランスポートである [Marmot](/ja/topics/marmot/)（MLS-over-Nostr）を廃止し、エンドツーエンド暗号化されたコミュニティプロトコル [Concord](/ja/topics/concord-protocol/) に切り替えました。既存の Marmot グループの履歴は引き継がれず、リリースノートはアップグレード前に Marmot グループのデータをバックアップするようユーザーに指示しています。Vector 自身のリリースノートは Concord を「当社独自のメッセージングプロトコル」と説明していますが、基盤となる [CORD-01 から CORD-07 の仕様](https://github.com/concord-protocol/concord) は別途 MIT ライセンスで公開されており、すでに Vector 以外でも実装されています。Soapbox の Discord スタイルクライアント [Armada](https://gitlab.com/soapbox-pub/armada) は同じ Concord 仕様の上に Communities 機能を構築しており、1 日後には [Amethyst が独自のクリーンルーム版でワイヤー互換の Concord 実装をマージしました](https://github.com/vitorpamplona/amethyst/pull/3566)（詳細は後述）。同じ Vector リリースは、すべてのトラフィックに対するオプションの Tor ルーティング、QR または貼り付けた bunker URI による [NIP-46](/ja/topics/nip-46/) リモート署名者ログイン、アプリ内スイッチャー付きの複数アカウント、そしてクライアント間で共有されるカスタム絵文字パックを追加しました。メッセージの削除は DM とグループチャットの双方向でメッセージを削除し、Vector は標準的な [NIP-17](/ja/topics/nip-17/) の削除フローに従わずに一時的な署名鍵を意図的に保持します。これはプライバシーを動機とした逸脱で、プロジェクトはリリースノートで明示的に言及しています。4 日後、[v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) は **Concord v2** を出荷しました。これは既存の Communities を機能させたままプライバシーと安定性の大幅な改善をもたらすと説明されており、ボット向けの型付きパラメータを備えた Discord スタイルのスラッシュコマンドピッカー、チャットごとの自己破壊タイマー、バグハンター向けの NIP-58 バッジシステムを併せて追加しています。グループチャットの Marmot からの移行は、下記の [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) が同じ週にその仕様へ投資を続けている中で行われました。 + +### Amethyst がエンドツーエンド暗号化コミュニティ向けにクリーンルーム版 Concord 実装を出荷 + +[Amethyst](https://github.com/vitorpamplona/amethyst) は機能豊富な Android およびマルチプラットフォームの Nostr クライアントです。[PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) は [Concord](/ja/topics/concord-protocol/)（CORD-01 から CORD-07）の完全な実装を追加し、サーバーレスでエンドツーエンド暗号化されたコミュニティを対象としています。通常の relay 上での gift-wrap された制御・チャット・ゲストブックの各プレーン、すべてのクライアントがサーバーを信頼するのではなくローカルで検証する所有者を起点としたロールとバンの強制、そして削除されたメンバーを遮断するための再鍵化を含みます。プロトコルと暗号のコードは `quartz/` に、状態とビューモデルは `commons/` に、画面とナビゲーションは Android 向けに `amethyst/` に置かれ、`cli/` の下には薄い CLI 動詞があります。共有ロジックは後で Desktop が採用できるよう `quartz`/`commons` に置かれているため、デスクトップ UI はまだありません。実装はクリーンルーム方式で、公開された CORD 仕様と観測されたワイヤー定数から構築され、Amethyst 独自の MIT ライセンスの下にあり、Armada の AGPL-3.0 コードベースとは別個です。Armada 自身のテストベクトル値が Quartz のユニットテストに移植され、2 つのクライアントが実際にワイヤー上で相互運用できることを確認しました。これにより Concord は数日のうちに 3 つの独立した実装を得ました。最初に出荷した Vector、Soapbox のリファレンスクライアントである Armada、そして今回の仕様からの Amethyst のビルドです。 + +### Sonar が Bitchat から分離、クロスプラットフォームのアルファ版とステッカーパック仕様を公開 + +[Sonar](https://sonarprivacy.xyz/) は Bitchat から派生した Bluetooth メッシュと Nostr を組み合わせたメッセンジャー兼ウォレットで、White Noise と相互運用可能な Marmot グループ DM を備えています。コードは [hedwig-corp/bitchat-to-sonar](https://github.com/hedwig-corp/bitchat-to-sonar) にあります。[v0.1-alpha.7](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.7) は Signal スタイルの上限付きトランスクリプトウィンドウ処理を追加し、開閉とスクロールのパフォーマンスをローカルファーストに保ち、近接検出の状態をピア間で同期し、content-type と HTTP ステータスの処理で失敗していた Blossom メディアアップロードを修正しました。先行する [alpha.6](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.6) はより高速なチャット更新のためにライブの Marmot イベントを排出し、通話・メッセージング・ウォレット・プッシュにわたる Android から iOS への機能パリティのギャップを埋めました。Sonar は [PR #2410](#open-sticker-pack-kinds-10031-and-30031) で引用された仕様のソースでもあり、この PR はプロジェクト独自の「Sonar Stickers」仕様の下にステッカーパックのイベント kind を登録し、このローンチに今週のプロトコル作業への直接的なハブリンクを与えています。 + +### Divine Mobile 1.0.16 がより高度なビデオエディター、保存時暗号化、ProofMode の来歴情報を搭載 + +[Divine](https://github.com/divinevideo/divine-mobile) は Web-of-Trust によるフィードキュレーションを備えた、Nostr 上に構築されたショート動画クライアントです。[v1.0.16](https://github.com/divinevideo/divine-mobile/releases/tag/1.0.16) は #30 以来初のタグ付きリリースで、ビデオエディターにクリップトランジション、逆再生、ボイスオーバーレコーダー、タイムラインのビートマーカーを追加し、あわせてユーザーがスワイプで直接おすすめを調整でき、不透明なエンゲージメントシグナルに任せずに済むフィード調整コントロールを追加しました。このリリースはローカルデータの保存時暗号化を有効にし、アプリが一時停止されても継続するバックグラウンドアップロードを追加し、ウォーターマーク付きクリップがダウンロードされる際に [ProofMode](/ja/topics/proofmode/) の来歴データを引き継ぎ、人間が作成したことの証明が転送中に取り除かれないようにします。Divine はまた 16 歳未満のアカウント向けの新しい保護を出荷し、ローカライゼーションを 17 言語 284 の翻訳文字列に拡大しました。 + +### Bitchat v1.7.0 が DM と公開メッシュ向けにライブのプッシュトゥトーク音声を追加 + +[Bitchat](https://github.com/permissionlesstech/bitchat) は Nostr relay へのオプトインゲートウェイを備えた Bluetooth メッシュチャットアプリです。[v1.7.0](https://github.com/permissionlesstech/bitchat/releases/tag/v1.7.0) は #30 が公開された夜にリリースされ、[PR #1403](https://github.com/permissionlesstech/bitchat/pull/1403) でライブのプッシュトゥトーク音声を追加しました。これは送信者がボタンを押している間に音声をストリーミングし、ストリームが切れた場合はボイスノートにフォールバックします。さらに [PR #1406](https://github.com/permissionlesstech/bitchat/pull/1406) で署名付きの公開メッシュプッシュトゥトークを追加し、共有メッシュチャンネル上のライブ音声バーストが送信者認証を伴うようにしました。このリリースは検証済みの再アナウンスでリンクを再バインドしてピア ID のローテーションを修復し、同じピアを新しい ID の下で認識します（[PR #1401](https://github.com/permissionlesstech/bitchat/pull/1401)）。また現在到達不能なピアへのダイレクトメッセージは、そのまま失敗するのではなく store-and-forward 配信でキューに入るようになりました（[PR #1415](https://github.com/permissionlesstech/bitchat/pull/1415)）。これは #30 で取り上げた v1.6.0 の [NIP-13](/ja/topics/nip-13/) proof-of-work とメッシュ・to・Nostr ゲートウェイ作業から直接続くものです。 + +### MDK v0.9.4 が外部署名者ログインに上限を設け、下書きの永続化を追加 + +[MDK](https://github.com/marmot-protocol/mdk) は [Marmot](/ja/topics/marmot/) プロトコル、すなわち #30 が仕様の採択を報じた MLS-over-Nostr メッセージング層のリファレンス SDK です。[v0.9.4](https://github.com/marmot-protocol/mdk/releases/tag/v0.9.4) は [PR #793](https://github.com/marmot-protocol/mdk/pull/793) で、外部署名者ログイン中にクライアントが辿る勧告ディレクトリのステップに上限を設け、リモート署名者が遅いか応答しない場合の無制限のリトライループを防ぎます。同じリリースは [PR #812](https://github.com/marmot-protocol/mdk/pull/812) で下書きメッセージの永続化とプロフィールのウェブサイトバインディングを追加し、MDK が v0.9.0 をカットして以来続けてきた漸進的な堅牢化作業を継続しています。 + +--- + +## タグ付きリリース + +### n_cord v1.1 が NSEC Bunker サポートを追加 + +[n_cord](https://github.com/0n4t3/n_cord) は Discord と IRC に触発された Nostr 駆動のチャットクライアントです。[v1.1](https://github.com/0n4t3/n_cord/releases/tag/v1.1) は返信処理のバグ修正とともに [NIP-46](/ja/topics/nip-46/) NSEC Bunker サポートを追加しました。 + +### cdk v0.17.3 が cdk、cdk-nwc、cdk-ffi 全体にわたる NIP-47 ウォレットサービスサポートを追加 + +[cdk](https://github.com/cashubtc/cdk) は Cashu 開発キットです。このリリースはほとんどの面で Bitcoin/Lightning のみですが、[v0.17.3](https://github.com/cashubtc/cdk/releases/tag/v0.17.3) は専用の NWC サービス crate、ウォレット統合、`cdk-ffi` 向けの FFI バインディング、そしてエンドツーエンドのテストカバレッジを備えた [NIP-47](/ja/topics/nip-47/)（Nostr Wallet Connect）サービスサポートを追加し、cdk 上に構築された Cashu ウォレットに標準的な Nostr Wallet Connect のサーフェスを提供します。 + +### Coop Mobile v0.2.4 が Nostr Connect を改善し ncryptsec1 インポートを追加 + +[Coop Mobile](https://git.reya.su/reya/coop-mobile) はモバイルプラットフォーム向けの [NIP-17](/ja/topics/nip-17/) プライベートメッセージングクライアントです。[v0.2.4](https://git.reya.su/reya/coop-mobile/releases/tag/v0.2.4) は [NIP-46](/ja/topics/nip-46/) Nostr Connect フローを改善し、一部の接続で永続的に止まっていたローディングインジケーターを修正し、再設計されたアイデンティティインポート画面とともに [NIP-49](/ja/topics/nip-49/) `ncryptsec1` 暗号化鍵形式のインポートサポートを追加しました。 + +### Nmail v0.14.0 が予約送信とプッシュ通知を備えて macOS に対応 + +[Nmail](https://github.com/nogringo/nostr-mail-client) は Nostr 上に構築されたメールクライアントです。[v0.14.0](https://github.com/nogringo/nostr-mail-client/releases/tag/v0.14.0) はアプリを macOS に対応させ、キューに入ったメッセージ用の専用「予約済み」メールボックスを備えた予約送信を追加し、プッシュ通知を追加しました。このリリースはまた、アドレス帳の Nostr 識別子解決を独自実装に代えて NDK の [NIP-05](/ja/topics/nip-05/) リゾルバーに切り替えました。 + +### Nostrord v2.2.0 が DM マスタートグルとより充実したダイレクトメッセージを追加 + +[Nostrord](https://github.com/nostrord/nostrord) は Android、iOS、ウェブ、デスクトップ向けの [NIP-29](/ja/topics/nip-29/) relay ベースのグループチャットクライアントです。[v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) はすべてのダイレクトメッセージ機能を一度に無効化するマスタートグルを追加し（[PR #175](https://github.com/nostrord/nostrord/pull/175)）、「より充実したダイレクトメッセージ」を出荷しました（[PR #186](https://github.com/nostrord/nostrord/pull/186)）。これは relay プールを統合しゾンビ WebSocket を検出したリリースを取り上げた #30 の内容から続くものです。 + +### Nostr WoT 0.3.86 が鍵バックアップと署名プロンプトを堅牢化 + +[Nostr WoT](https://github.com/nostr-wot/nostr-wot-extension) は Nostr アイデンティティと Lightning ウォレットをペアリングするブラウザ拡張機能です。[v0.3.86](https://github.com/nostr-wot/nostr-wot-extension/releases/tag/v0.3.86) は暗号化された鍵バックアップを標準の [NIP-49](/ja/topics/nip-49/) 形式に移し、署名プロンプトが要約ではなくイベント全体とすべてのタグを表示するようにし、relay データを署名に対して検証し、アカウント切り替え時にアクティブなアイデンティティを露出しないようにします。この拡張機能はまた、使用されていない `scripting` ブラウザ権限を削除しました。 + +### Keep Android v1.1.8 が初回起動時 FROST オンボーディングを追加 + +[Keep](https://github.com/privkeyio/keep-android) は閾値 FROST 鍵シェアの上に構築された Android 署名者です。[v1.1.8](https://github.com/privkeyio/keep-android/releases/tag/v1.1.8) は FROST 鍵シェアを説明し、最初の署名リクエストが届く前に新規ユーザーが Manual、Basic、Auto の署名ポリシーを選べる初回起動フローを追加しました。これは基盤となる keep-mobile crate の閾値署名モデルに対する Android 側で初のオンボーディングです。 + +### Noscall v0.6.0 が Cashu ウォレットと relay ベースのプッシュ通知を追加 + +[Noscall](https://github.com/sanah9/noscall) は Nostr 上に構築された安全な音声・ビデオ通話アプリです。[v0.6.0](https://github.com/sanah9/noscall/releases/tag/v0.6.0-release) は複数 mint 残高、ecash の送受信、そして見積もりの永続化を伴う Lightning の支払いと受け取りを備えたアカウントスコープの Cashu ウォレットを追加しました。このリリースはまた、Android のプッシュ通知を Firebase Cloud Messaging から UnifiedPush 経由の Nostr relay ベースの配信経路に移行し、ログインリトライ中の iOS VoIP と APNs プッシュの信頼性を改善しました。 + +### Kubo がタブレットモードとグループチャット写真を出荷 + +[Kubo](https://github.com/JeroenOnNostr/kubo) は Web-of-Trust によるフィードキュレーションを備えた、子どもに安全な Nostr 動画プラットフォームです。[kubo-v2026.07.05](https://github.com/JeroenOnNostr/kubo/releases/tag/kubo-v2026.07.05) は子ども向けフィードのオプトインのタブレットグリッドレイアウトと、グループチャットメッセージへの写真添付のサポートを追加し、さらに Android で画面上のキーボードの後ろにサインアップボタンが隠れる問題を修正しました。 + +### Nostr Codex Phone v0.2.9 が git/diff/ファイル読み取りの補助リクエストを追加 + +[Nostr Codex Phone](https://github.com/tidley/nostr-codex-phone) は、暗号化された Nostr DM 経由で通信するローカルのコーディングアシスタントワーカー向けのモバイル制御サーフェスです。[v0.2.9](https://github.com/tidley/nostr-codex-phone/releases/tag/v0.2.9) は git、diff、ファイル読み取り、status、history の補助リクエストを含むモバイル OpenCode ツールアクション、セッションのピン留めと検索の改善、タスク停止コントロールを追加し、あわせて先行する v0.2.8 で出荷された暗号化された [Blossom](/ja/topics/blossom/) アップロードラッパーを備えます。 + +### GitWorkshop v3.0.3 がリポジトリエクスプローラーで新たにアナウンスされた ref を修正し、初の Android ビルドを出荷 + +[GitWorkshop](https://github.com/DanConwayDev/gitworkshop) は NIP-34 リポジトリの閲覧とレビューのための git-over-Nostr のウェブ UI です。[v3.0.3](https://github.com/DanConwayDev/gitworkshop/releases/tag/v3.0.3) は、エクスプローラーがすでにロードした後にリポジトリがアナウンスする ref を、ブランチ・タグ・コミット・コード閲覧の各ビューが解決できずに失敗する問題を、CI ワークフローのタイミングの整理とともに修正しました。これはタグとコミット履歴に対して直接確認されています。同じ週に GitWorkshop は [Zapstore](https://zapstore.dev) に初のネイティブ Android ビルドを公開し、v3.0.0 から始まって数時間のうちに v3.0.3 に到達しました。ウェブ UI が主要なインターフェースのままで、Android パッケージは同じ NIP-34 リポジトリ閲覧を初めて携帯電話にもたらします。 + +### Bitcoin-Safe が Flathub に登場、Nostr Sync & Chat プラグインに注目 + +[Bitcoin-Safe](https://bitcoin-safe.org) はハードウェア署名者のワークフローを中心に構築されたセルフカストディの Bitcoin ウォレットです。プロジェクトは今週 [Flathub パッケージを出荷](https://flathub.org/apps/org.bitcoin_safe.BitcoinSafe) し、主流の Linux アプリストアへの初の掲載となりました。この Flathub リリースは Bitcoin-Safe の Sync & Chat プラグインをより広い層に届けます。このプラグインはプロジェクト独自の [bitcoin-nostr-chat](https://github.com/andreasgriffin/bitcoin-nostr-chat) ライブラリを介して [NIP-17](/ja/topics/nip-17/) ダイレクトメッセージを使い、ユーザーのデバイス間でウォレットのラベルを同期し、信頼できる参加者間でのリモートマルチシグ共同署名のために PSBT を送受信します。Nostr 層そのものは以前の [2.0.0](https://github.com/andreasgriffin/bitcoin-safe/releases/tag/2.0.0)（2026-06-29）で出荷されており、これは QR、USB、Bluetooth と並ぶ「Share via Chat & Sync」接続タイプを中心にトランザクション署名を再設計しました。今週のニュースは、その既存機能を初めて主流の Linux 層に届ける Flathub パッケージングです。 + +--- + +## 未リリースの変更 + +### Amethyst がアカウントに暗号化された NIP-85 カードで連絡先へのニックネーム付けを可能に + +上記で取り上げた [Concord 実装](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) に加えて、Amethyst はこの 1 週間で他に 54 件の PR をマージしました。その中心は [PR #3548](https://github.com/vitorpamplona/amethyst/pull/3548) で、アカウントが他のユーザーについて自身の kind 30382 [NIP-85](/ja/topics/nip-85/) 連絡先カードを発行することで、そのユーザーにニックネームを付けられるようにします。ペットネーム、プライベートノート、そして任意のカスタム [NIP-30](/ja/topics/nip-30/) 絵文字ショートコードのマッピングは、カードの [NIP-44](/ja/topics/nip-44/) で暗号化されたコンテンツの中に置かれ、署名アカウントだけがそれらを読めます。カードはログイン時にアカウントの拡張された outbox relay セットを通じて同期され、その後は漸進的に同期されます。フィード、チャット、メンションは公開表示名の代わりにペットネームを表示し、プロフィールページのユーザーの本名の上にタップ可能なニックネームカードを表示します。 + +### Zap Cooking が My Kitchen フェーズ 3 を出荷し NDK プールのクォーラムバグを修正 + +[Zap Cooking](https://github.com/zapcooking/frontend) は Nostr 上に構築されたレシピ共有と料理コミュニティのアプリです。「My Kitchen」の献立計画機能を継続する 43 件の PR をマージし、このフェーズで買い物リスト生成、レシピピッカー、プランナーの週グリッドを追加しました。同じ変更セットは、relay のクォーラムがすでに応答した時点を過ぎても relay 読み取りが待機し続ける可能性のある [NDK](https://github.com/nostr-dev-kit/ndk)（Nostr Development Kit）接続プールのクォーラム準備状態のバグを修正しました。 + +### Kehto が relay 検出の前に outbox 読み取りをストリーミング + +[Kehto](https://github.com/kehto/web) は [NIP-5D](/ja/topics/nip-5d/) の Nostr アプレット、すなわち「napplet」のための初期段階のウェブベースランタイムです。26 件の PR をマージしました。[PR #193](https://github.com/kehto/web/pull/193) は、以前は [NIP-65](/ja/topics/nip-65/) の relay リストのロード完了を待ってからでないと relay を一切開かなかった outbox 読み取りを修正します。これにより、決着しない relay リストのロードがイベント配信とクエリのタイムアウトの両方をブロックしうる状態を解消します。修正は検証済みの relay ヒントを即座に開き、書き込み relay が検出されるにつれて結果をストリーミングします。2 つ目の変更（[PR #196](https://github.com/kehto/web/pull/196)）は、プロジェクトのアイデンティティ監査ページを Napplet プラットフォームのライフサイクルコントラクトである NAP-SHELL に整合させます。これは今週の `napplet/web` リリースの他の箇所にも見られる同じプロトコル整合作業の一環です。 + +### Wired と TAO が NIP-57 のクリエイター収益分配を追加 + +[Wired](https://github.com/smolgrrr/Wired) と [TAO](https://github.com/smolgrrr/TAO) は Nostr 上に構築された言論の自由に焦点を当てた双子のソーシャルクライアントで、同じ PR リストを共有しています。両者は [PR #121](https://github.com/smolgrrr/Wired/pull/121) をマージし、[NIP-57](/ja/topics/nip-57/) のクリエイター収益分配を実装しました。これにより投稿に送られた zap が元の投稿者以外の貢献者にも自動的に分割されます。これはこのペアが未リリースの作業として proof-of-work シグナルを 21 ビットに引き上げたことを取り上げた #30 の内容から続くものです。 + +### Conduit Mono が加盟店の注文受信トレイを一時的なゲストチェックアウトを中心に再構築 + +[Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) は [NIP-99](/ja/topics/nip-99/) の分類広告に隣接するマーケットプレイスプロトコルです。[PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174) はブラウザ生成の一時鍵を使ったゲストチェックアウトを追加します。ゲストはその使い捨て鍵を使って暗号化された注文と支払いレポートを加盟店に送り、加盟店は電話やメールで帯域外にフォローアップするため、購入者は永続的な受信トレイのアイデンティティを一切必要としません。[PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175) は加盟店の注文受信トレイを単一の共有された注文状態モデルを中心に再構築し、購入者と加盟店のロールを分離し、物理的または混合の注文が発送済みに移行する前に追跡コードと配送業者を必須にします。プロジェクトのチェックアウトフローは [NIP-17](/ja/topics/nip-17/) プライベートメッセージ、[NIP-44](/ja/topics/nip-44/) 暗号化、[NIP-59](/ja/topics/nip-59/) gift wrap の上に構築されています。今週の [NIP Deep Dive](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) は、この同じ注文状態の問題が向かう先である [Gamma Markets](/ja/topics/gamma-markets/) の規約を取り上げます。 + +### Buzz が kind 39002 まわりのチャンネル作成者プロビジョニングを堅牢化 + +[Buzz](https://github.com/block/buzz) は AI エージェントと人間を Nostr 上でつなぐ集合知型コミュニケーションプラットフォームです。この 1 週間で 240 件の PR をマージし、kind 44200 のエージェントターンメトリクスを取り上げた #30 からの relay 層の堅牢化の流れを継続しました。今週の修正（[PR #1830](https://github.com/block/buzz/pull/1830)）は、kind 39002 のチャンネルプロビジョニングロジックが実行される前にチャンネルの作成者をメンバーとして扱い、作成者自身のチャンネルがセットアップ中に作成者を拒否しうる競合状態を解消します。 + +### Nostr Docs が複数アカウントと QR ペアリングに対応した NIP-49 署名者を採用 + +[Nostr Docs](https://github.com/formstr-hq/nostr-docs) は Nostr ネイティブの共同ドキュメントアプリケーションです。5 件の PR をマージし、注目すべきもの（[PR #50](https://github.com/formstr-hq/nostr-docs/pull/50)）は、複数アカウント切り替えと QR ペアリングを備えた完全な [NIP-49](/ja/topics/nip-49/) 認証のために `@formstr/signer` パッケージを採用し、以前の独自署名経路を置き換えました。 + +### その他の出荷 + +いくつかの追跡対象プロジェクトで、個別の段落を割くほどの新しいサーフェスはないものの、署名者の相互運用と信頼性の小さな修正がこの 1 週間で行われました。Nostr ベースの GitHub 代替のコマンドラインクライアント [ngit-cli](https://github.com/DanConwayDev/ngit-cli) は [v2.6.3](https://github.com/DanConwayDev/ngit-cli/releases/tag/v2.6.3) を出荷し、`ngit init` が nsec を繰り返し要求する代わりに実行可能なセットアップガイダンスを示すようにしました。Nostr 上に構築されたプライベートな暗号化ノート・ファイルアプリ [Manent](https://github.com/dtonon/manent) は [v1.4.1](https://github.com/dtonon/manent/releases/tag/v1.4.1) を出荷し、Amber が 16 進 pubkey を返すときに壊れていた Android 署名者ログインを修正し、bunker ログインのスクロールを改善しました。スリムで Google サービスを使わない Nostr クライアント [NoorNote](https://github.com/77elements/noornote) は [v1.2.8](https://github.com/77elements/noornote/releases/tag/v1.2.8) を出荷し、見逃していた Nostrord グループの通知を修正し、自己投稿アラートのトグルを追加しました。AI エージェントと人間向けの信頼を意識した Nostr MCP サーバー [Bray](https://github.com/forgesworn/bray) は [v1.34.0](https://github.com/forgesworn/bray/releases/tag/v1.34.0) を出荷し、[NIP-46](/ja/topics/nip-46/) bunker 接続時にクライアント名のメタデータを送るようにしました。Nostr ウェブクライアント [Lumilumi](https://github.com/TsukemonoGit/lumilumi) は [NIP-65](/ja/topics/nip-65/) relay リストをオフラインフォールバックのためにローカルストレージにキャッシュします。Nostr ベースのローカルな都市・コミュニティアプリ [Earthly](https://github.com/moogmodular/earthly) は [NIP-50](/ja/topics/nip-50/) 地理検索を追加します。そして無料でオープンソースの Lightning ウォレット兼アカウントシステム [lnbits](https://github.com/lnbits/lnbits) は [PR #3925](https://github.com/lnbits/lnbits/pull/3925) を出荷し、その他は Lightning に焦点を当てたリリースの中で `send_nostr_dm` を非ブロッキングで発行するようにしました。 + +--- + +## 新たに追跡・発見されたもの + +### OpenDiscord v1.0.1 が Nostr 上の Discord スタイルクライアントとしてローンチ + +[OpenDiscord](https://github.com/sofia-gros/open-discord) は、ロールベースの権限と WebRTC/SFU 音声ロビーを備えた、Nostr 上に構築された Discord スタイルのサーバーとチャンネルのクライアントです。[v1.0.1](https://github.com/sofia-gros/open-discord/releases/tag/v1.0.1) はプロジェクト初のタグ付きインストーラーリリースです。 + +### Auditable Voting v0.1.140 が主催者・投票者・監査プロキシのロールを整合 + +[Auditable Voting](https://github.com/tidley/auditable-voting) はクライアントのみの Nostr 投票シェルです。[v0.1.140](https://github.com/tidley/auditable-voting/releases/tag/v0.1.140) は主催者・投票者・監査プロキシのロールを、主催者が署名した正確な公開アンケート定義イベントに整合させ、監査プロキシが古い生成済みアカウントや別のワーカーや主催者から永続化された状態に基づいて動作しうるギャップを解消します。 + +### Cambium v0.3.2 が Heartwood とペアリングする鍵を持たない NIP-55 署名者に + +[Cambium](https://github.com/forgesworn/cambium) は今号の Discovery の選出です。自身のプライベート鍵素材を一切保持せず、すべての署名リクエストを [NIP-46](/ja/topics/nip-46/) 経由でコンパニオンの Heartwood ハードウェア署名者にプロキシする Android [NIP-55](/ja/topics/nip-55/) 署名者です。プロジェクトは追跡対象プロジェクト Bray と GitHub org `forgesworn` を共有しており、Heartwood 自体は Cambium の Android 側が今つないでいる relay-to-serial 署名ブリッジを出荷したものとして #30 で取り上げられました。[v0.3.2](https://github.com/forgesworn/cambium) は承認シートを磨き、選択されたアイデンティティがアプリの既存のバインディングと異なる場合にライブで警告し、アクティビティログの書き込みを単一の非ブロッキングキューに移します。 + +### 今週さらにローンチ: echoes、Dispatch、Linky + +今週はさらに 3 つのローンチが言及に値します。[echoes](https://github.com/Lwb89dev/echoes) はオフラインファーストでエンドツーエンド暗号化されたノートアプリで、Nostr 上でプライベートに同期します。[Dispatch](https://github.com/freecritter/dispatch) はローカルファーストの旅行オーガナイザーで、すべての保存が [NIP-44](/ja/topics/nip-44/) で暗号化され、専用のリンク不可能な鍵の下で Nostr 上にバックアップされます。その [v0.3.0](https://github.com/freecritter/dispatch) リリースは Amber [NIP-55](/ja/topics/nip-55/) ログインを追加し、アプリがユーザーのプライベート鍵に直接触れないようにします。[Linky](https://github.com/hynek-jina/linky) は Nostr の連絡先と DM を Lightning および Cashu の支払いと単一のプログレッシブウェブアプリで組み合わせます。 + +--- + +## プロトコル作業と NIP の更新 + +この 1 週間で [NIPs リポジトリ](https://github.com/nostr-protocol/nips) にマージされた PR はありません。6 件の提案がオープンしました。 + +### オープン: kind:10011 お気に入りフォローセット + +fiatjaf による [PR #2413](https://github.com/nostr-protocol/nips/pull/2413) は kind:10011 お気に入りフォローセットを追加します。これは kind:10012（お気に入り relay セット）が kind:30002 relay セットを指す `a` タグを保持する既存のパターンを反映し、同じお気に入り機構を kind:30000 フォローセットに拡張し、クライアントが自身の連絡先リストを置き換えることなくキュレーションされたフォローリストをブックマークできるようにします。 + +### オープン: NIP-4E を拡張するプライベート暗号化ドライブ + +Form* チームによる [PR #2412](https://github.com/nostr-protocol/nips/pull/2412) は、`d` 識別子タグと `t` サブタイプタグで区別される汎用の Metadata イベント kind 34578 と、その上に構築されたプライベート暗号化ファイルシステムを提案しています。これはすでに Form* 自身のまだ実験的な Form* Drive クライアントで実装されています。ファイルレコードは `t=files` の Metadata イベントです。ファイルの blob は [Blossom](/ja/topics/blossom/) サーバー上に置かれ、暗号化されたインデックスだけが relay に置かれ、各ファイルチャンクは [NIP-44](/ja/topics/nip-44/) v2 の HKDF 由来の暗号化を伴う独自の一時鍵ペアを得ます。コンパニオンの Decoupled Encryption Key イベントは、すべてのファイルのメタデータがそれに対して復号されるドライブ全体で 1 つの対称鍵を保持し、fiatjaf のまだオープンなストレージ抽象化ドラフトである [NIP-4E](/ja/topics/nip-4e/)（[PR #1647](https://github.com/nostr-protocol/nips/pull/1647)、2024 年 12 月からオープン）の上に明示的に構築されています。 + +そのドライブ全体で 1 つの鍵という設計は、鍵が漏洩するとドライブ内の 1 つのファイルだけでなくすべてのファイルのメタデータが露出することを意味します。ファイルごとの一時鍵ペアはチャンク暗号化鍵だけを変え、メタデータ復号鍵は変えないためです。より古いイベントが失われる可能性があると警告する新しい Metadata イベントを発行する以外に、ローテーションや失効の経路はまだ存在しません。より狭い 2 つ目の提案は、同じ基盤となる NIP-4E のアイデアに別の角度から届きます。fiatjaf による [PR #2361](https://github.com/nostr-protocol/nips/pull/2361) は、特に [NIP-17](/ja/topics/nip-17/) メッセージングの中でアイデンティティ鍵と暗号化鍵を分離し、6 月 1 日からオープンです。両 PR ともマージされておらず、これは設計空間の活発で争点のある領域のままです。Form* は Drive クライアントは実験的で、まもなくアップデートが来ると述べています。 + +### オープン: NIP-DA 権限付きプライベートデータ共有 + +JAFairweather による [PR #2411](https://github.com/nostr-protocol/nips/pull/2411) は、スコープ付きデータ許可を通じた権限付きプライベートデータ共有のための新しい NIP-DA ドラフトです。各ユーザーはスコープごとに 1 つの暗号化された権威あるレコードを relay 上に保持し、そのスコープの対称鍵を [NIP-59](/ja/topics/nip-59/) gift wrap の中でプライベートに配信することでアクセスが付与されます。これにより relay は暗号文だけを保存し、誰が誰にアクセスを付与したかを知ることはありません。失効は単なる鍵のローテーションであり、各消費者のコピーを書き換える必要はありません。作者はこれを [NIP-17](/ja/topics/nip-17/) DM（データのスナップショットは運べるがライブ更新や失効は運べない）や NIP-51 プライベートリスト（鍵素材を運ばない）とは別個のものと位置づけ、JavaScript のリファレンスライブラリと go-nostr 上の Go CLI の 2 つの独立した実装を挙げ、relay.damus.io、nos.lol、relay.primal.net に対して相互テストしたとしています。 + +### オープン: ステッカーパック kind 10031 と 30031 + +vincenzopalazzo による [PR #2410](https://github.com/nostr-protocol/nips/pull/2410) は、[Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) が今週出荷した「Sonar Stickers」形式で規定された kind 30031（アドレス指定可能なステッカーパック）と kind 10031（ユーザーのステッカーパックリスト）を Event Kinds テーブルに登録します。これらの kind は、クライアントがステッカーパックを絵文字セットと取り違えないよう、[NIP-30](/ja/topics/nip-30/) のカスタム絵文字 kind 30030 と 10030 の 1 つ上の枠に意図的に置かれています。ステッカー画像のバイトは HTTPS の [Blossom](/ja/topics/blossom/) 互換サーバー上に置かれ、送信されたステッカーの参照は平文のハッシュを伴い、編集されたアドレス指定可能なパックが古いメッセージですでに送信されたステッカーの見た目を密かに変えられないようにします。コンパニオンの PR が別プロジェクトの `registry-of-kinds` に同じ kind を登録します。 + +### オープン: kind:9010 と kind:39005 による NIP-29 のメッセージ固定 + +Anderson-Juhasc による [PR #2379](https://github.com/nostr-protocol/nips/pull/2379) は [NIP-29](/ja/topics/nip-29/) relay ベースのグループにメッセージ固定を追加します。kind:9010 `update-pin-list` は、固定されたイベントの完全なリストを表示順に `e` タグとして運ぶモデレーションイベントで、単一のイベントで固定・固定解除・並べ替え・固定セットのクリアができます。kind:39005 は relay が生成するミラーで、最新の受理済みリストを公開します。この設計は、レビューフィードバックを経て [PR #1163](https://github.com/nostr-protocol/nips/pull/1163) の以前の追加/削除ペア方式に取って代わり、9009 と 39003 がその後 `create-invite` とグループロールに取られたため、kind 番号 9010/39005 を選んでいます。Anderson-Juhasc は [Nostrord](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages) も保守しており、その [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) は同じ週に出荷されています。 + +### オープン: NIP-66 relay 検出の再構成 + +VincenzoImp による [PR #2241](https://github.com/nostr-protocol/nips/pull/2241) は [NIP-66](/ja/topics/nip-66/) relay 検出の実質的な再構成です。緩い「その他のタグには」という散文を構造化された Indexed Tags セクションに置き換え、relay 検出のフィルタリング向けに NIP-11 の `attributes` フィールドを反映する `W` タグを追加し、標準化された名前空間（`ISO-639-1`、`ISO-3166-1`、`IANA-asn`、`IANA-tz`、`nip66.label.city`）を使う `l` ラベルタグを追加し、RTT、SSL/TLS、ネットワーク、地理、DNS、HTTP のタグを専用セクションに整理し、あわせて新しい Check Types テーブルを設けます。また、誤ったフィールド名、欠けた `kind`、不正なチェックタイプ名を含んでいた壊れた例示イベントを修正し、[issue #2171](https://github.com/nostr-protocol/nips/issues/2171) をクローズします。追加されるタグはすべて任意であるため、すべての変更は後方互換性を保ちます。 + +--- + +## NIP Deep Dive: NIP-99 と Gamma Markets のコマース拡張 + +[NIP-15](/ja/topics/nip-15/)、すなわち元祖の Nostr Marketplace 仕様は、現時点ではレガシーです。これは商店の出店（kind 30017）とその下に整理された商品（kind 30018）をモデル化しており、かつてその上で動いていたクライアント（Shopstr を含む）はその後、アクティブな仕様として [NIP-99](/ja/topics/nip-99/) の分類広告に移行しました。NIP-99 自体は単一のアドレス指定可能なイベントで、アクティブな広告なら kind 30402、下書きなら kind 30403 であり、先に出店を作成する必要はありません。これは広告より先のすべて、すなわち配送費、注文状態、レシート、レビュー、複数の広告を 1 つのストアフロントにまとめる方法を未定義のまま残しています。これらはまさに NIP-15 のうち引き継がれなかった部分です。[Gamma Markets](/ja/topics/gamma-markets/) がその隙間を埋め、今日理解しておく価値のある現代的なコマース層です。 + +### NIP-99 が残す隙間 + +NIP-99 広告の `content` フィールドは Markdown の説明を運び、`price` と `location` はイベントに直接乗り、`t` タグは通常のハッシュタグコンテンツとして検索可能にします。pubkey、kind、`d` タグの組でアドレス指定可能なため、売り手は同じ `d` タグで新しいバージョンを発行することで広告をその場で編集します: + +```json +{ + "kind": 30402, + "content": "Vintage mechanical keyboard, Cherry MX Blue switches, barely used.", + "tags": [ + ["d", "keyboard-mx-blue-01"], + ["title", "Vintage Mechanical Keyboard"], + ["summary", "Cherry MX Blue, barely used"], + ["published_at", "1752537600"], + ["location", "NYC"], + ["price", "100", "USD"], + ["t", "electronics"] + ] +} +``` + +それが仕様の全体です。署名された更新可能な分類広告です。一度きりの分類広告を超えて実際の EC のために NIP-99 を実装したすべてのクライアントは、配送、注文メッセージ、レビューのための独自のプライベートな規約を発明することになりました。2 つの NIP-99 クライアントはそれぞれ広告を正しく描画できても、両者間でチェックアウトを完了する共有された方法を持たないことがありえます。 + +### Gamma Markets: NIP-99 が残したものを標準化する + +Gamma Markets は、Nostr マーケットプレイス開発者のワーキンググループ、すなわち Shopstr、Cypher、Plebeian Market、Conduit Market の背後にいるチームが、NIP-99 の既存の kind 30402 イベントの上に構築した共有の EC 規約群に付けた名前です。仕様は [PR #1784](https://github.com/nostr-protocol/nips/pull/1784) を通じて正典の NIP-99 ドキュメントからリンクされ、独自のリポジトリ [GammaMarkets/market-spec](https://github.com/GammaMarkets/market-spec) で保守されています。 + +Gamma Markets は広告に隣接する 2 つの独立した kind を追加します。kind 30405 は複数の広告を製品コレクションにまとめ、それぞれを明示的な `a` タグで参照します: + +```json +{ + "kind": 30405, + "content": "Summer sale picks", + "tags": [ + ["d", "summer-picks"], + ["title", "Summer Sale"], + ["a", "30402::keyboard-mx-blue-01"], + ["shipping_option", "30406::standard-regional"] + ] +} +``` + +kind 30406 は、国ごとの価格設定と任意の重量ベースまたは距離ベースのコストルールを備えた配送オプションを定義します: + +```json +{ + "kind": 30406, + "content": "Standard Regional Shipping", + "tags": [ + ["d", "standard-regional"], + ["title", "Standard Shipping"], + ["price", "5.99", "USD"], + ["country", "US"], + ["service", "standard"], + ["duration", "24", "72", "H"], + ["weight-max", "30", "kg"] + ] +} +``` + +注文の作成、支払いリクエスト、状態と配送の更新、支払いレシートはすべて、通常の [NIP-17](/ja/topics/nip-17/) gift-wrap されたプライベートメッセージとして流れ、トランスポートを再ラップするのではなくロールごとに 3 つの kind に分割されます。kind 14 は自由形式の購入者/加盟店のコミュニケーションを運び、kind 16 はすべての注文状態遷移を運び（`type` タグの 1 から 4 が注文作成、支払いリクエスト、状態更新、配送更新を表します）、kind 17 は購入者の支払いレシートを運びます。注文作成メッセージは gift-wrapping 前にはこのようになります: + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +完了した購入の評価は別のアドレス指定可能な kind 31555 で、レビュー対象の広告を指し返します: + +```json +{ + "kind": 31555, + "content": "Arrived fast, exactly as described.", + "tags": [ + ["d", "a:30402::keyboard-mx-blue-01"], + ["rating", "1", "thumb"], + ["rating", "1.0", "quality"], + ["rating", "0.9", "delivery"] + ] +} +``` + +注文メッセージを NIP-17 に乗せるということは、Gamma Markets のチェックアウトが、独自の注文メッセージ kind ではなく、クライアントが DM 向けにすでに出荷しているのと同じプライベートメッセージのトランスポートを使うことを意味します。 + +この仕様の中核的な設計上の選択は、何もカスケードで継承されないことです。コレクションに属する広告は、コレクションの配送オプションや説明を自動的に継承するのではなく、`a` タグで明示的にそれを参照し、広告が使う配送オプションも同じ明示的な方法で参照されます。これは、商品が親の出店が定義した通貨と配送テーブルを密かに継承していた NIP-15 の出店モデルの意図的な逆転です。トレードオフは各広告でより多くの明示的なタグ付けをすることであり、その代わりに広告の完全な設定が常にイベントそのものから読み取れ、先に解決すべき親オブジェクトがないことです。 + +### これが実践で現れる場所 + +今週の [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) の作業は、Gamma Markets が標準化するのと同じ注文メッセージの領域にあります。[PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174) の一時鍵ゲストチェックアウトと [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175) の加盟店注文受信トレイの再構築は、いずれも Gamma Markets の kind 14、16、17 のメッセージが形式化する購入者/加盟店の注文状態の問題を解決します。Conduit Mono はそれらの kind を直接採用せず、それらと並行して独自の注文状態モデルを動かしています。仕様を書いた 4 つのプロジェクトのうちの 1 つである Shopstr も、この 1 週間で独自のコマース配管を動かし続けました。[PR #568](https://github.com/shopstr-eng/shopstr/pull/568) は重複した NIP-17 gift-wrap ロジックを共有モジュールに抽出し、[PR #567](https://github.com/shopstr-eng/shopstr/pull/567) は [NIP-98](/ja/topics/nip-98/) HTTP 認証パーサーを完全なテストカバレッジにします。これはまさに、Gamma Markets の注文フローが購入者と加盟店に安全に届くために依存するメッセージングと認証の層に対する保守作業です。 + +NIP-15 は出店と商品を標準化しながら、支払い、配送、レビュー、注文状態をアプリケーションの問題として残したことで、ストアフロントの役割を失いました。Gamma Markets は NIP-99 の単一広告の形に手を触れることなく、その欠けたサーフェスの大部分を埋め、新しいメッセージング層を発明するのではなく、Nostr の既存の DM スタックである NIP-17 の上に構築します。 + +--- + +今週はここまでです。何かを作っていたり、共有したいニュースがあれば、NIP-17 DM で連絡するか、Nostr で私たちを見つけてください。 diff --git a/content/ja/topics/concord-protocol.md b/content/ja/topics/concord-protocol.md new file mode 100644 index 0000000..41216c4 --- /dev/null +++ b/content/ja/topics/concord-protocol.md @@ -0,0 +1,61 @@ +--- +title: "Concord Protocol" +date: 2026-07-15 +translationOf: /en/topics/concord-protocol.md +translationDate: 2026-07-15 +draft: false +categories: + - Protocol + - Messaging +--- + +Concordは、Nostr上のend-to-end encryptedなコミュニティとチャンネル向けの、MITライセンスのオープンなプロトコルで、[CORD-01からCORD-07までの仕様](https://github.com/concord-protocol/concord)で定義されています。[Vector](https://github.com/VectorPrivacy/Vector)はv0.4.0以降、Group Chats機能のデフォルトのtransportとしてこれを採用し、自身のリリースノートでは「独自のメッセージングプロトコル」と呼んでいますが、仕様そのものはVectorとは別に公開されており、すでに独立した実装が存在します。 + +## 仕組み + +Concordは、Discord風のコミュニティサーバーが通常担う機能を、誰も信頼する必要のない部品へと分割します。relayは常に、rotateするラベル宛てに暗号化されたblobのみを保持し、部屋の鍵を保持していることがメンバーである証となり、role、kick、banに対する権限は、owner のidentityに根ざした署名済みrosterで、これを各clientがサーバーに強制を委ねる代わりにローカルで検証します。永続的なeventはすべて、同じ3層のenvelopeに乗ります。planeそれ自身の導出したstream keyで署名されたkind 1059のwrapが、authorの本物の鍵で署名されたsealを含み、そのsealが機能的なeventを運ぶ署名なしのrumorを含みます。chat messageのrumorは、素のkind 9 eventです。 + +```json +{ + "kind": 9, + "pubkey": "", + "content": "Hey chat!", + "tags": [ + ["channel", ""], + ["epoch", "0"] + ] +} +``` + +control、chat、guestbookの各トラフィックは、それぞれ独自の[NIP-59](/ja/topics/nip-59/) gift-wrappedなplaneを得るため、3種すべてを保持するrelayでも、部屋の鍵なしにはcontrol messageとchat messageとguestbook entryを区別できません。仕様は7つのCORDドキュメントに分かれています。private stream(01)、communityとmembership(02)、channel(03)、role(04)、invite(05)、削除されたメンバーを締め出すためのrekeyingと再創設(06)、そしてblind token brokerを介したaudio/video(07)です。membershipそのものにはサーバー側のリストがありません。planeを復号できる者がメンバーであり、誰かを本当に削除するとは、テーブルから行を削除するのではなく、communityを新しいkey epochへ巻き上げ、残った者だけに鍵を渡すことを意味します。 + +## Marmotとの違い + +Concordと[Marmot](/ja/topics/marmot/)は、異なるグループの形に対して異なる暗号技術で、Nostr上の暗号化グループメッセージングを解きます。Concordプロジェクト自身の比較は、この分担を明示しています。Marmotは、forward secrecyとpost-compromise securityのためにNostrの上に[MLS](/ja/topics/mls/)を重ね、per-device key packageと、グループ全体を足並みそろえて進める順序付きのcommitを使います。これは強い保証を得ますが、そのコストはmembershipの変更とともに増大するため、参加や離脱がまれな、小規模で高リスクなグループに適しています。Concordは代わりに、すべてのメンバーに同じ部屋の鍵を与え、commitごとにratchetする代わりに削除時に部屋全体をre-keyし、MLSの暗号的保証の一部を手放す代わりに、communityが数百から数千の、カジュアルで入れ替わりの激しいメンバーへと成長してもコストが安いままのモデルを取ります。これはDiscord風のcommunityが実際に取る形です。 + +## なぜVectorは切り替えたのか + +Vector自身の[v0.4.0リリースノート](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0)は、Group Chats向けのConcordを「独自のメッセージングプロトコル」とだけ説明し、理由を直接述べていません。それでも、Concord自身の公開された論拠との整合性は明確です。VectorのようなclientにおけるGroup Chatsは、Marmotのper-device MLS stateがより高コストな経路となる、まさに大規模で開かれた、membershipが頻繁に変わるケースであり、Concordの非同期でいつでも畳み込める設計は、そのケースのために作られています。[Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0)はGroup ChatsでMarmotを退け、Concordを採用し、既存のMarmotグループ履歴はこの切り替えで引き継がれませんでした。[v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1)は4日後に、プライバシーと安定性の改善を伴う「Concord v2」を出荷しました。同じ週のうちに、[Amethystは独自のclean-roomでwire互換なConcord実装をマージし](https://github.com/vitorpamplona/amethyst/pull/3566)、SoapboxのDiscord風client [Armada](https://gitlab.com/soapbox-pub/armada)はすでに、reference実装として同じ仕様の上にCommunities機能を築いています。3つの独立したclientが数日のうちに1つのオープンな仕様へ収束することは、実際のcross-client interopへの速い経路であり、残りのNostrのグループチャットclientがどれだけMarmotに留まるかと照らして追う価値があります。 + +## 実装 + +- [Vector](https://github.com/VectorPrivacy/Vector) - single-binaryでprivacy-firstなNostrメッセンジャー。Concordを最初に出荷したclientで、v0.4.0にて +- [Armada](https://gitlab.com/soapbox-pub/armada)(Soapbox) - Discord風のcommunity client。reference実装で、backendは別の`armada-relay`リポジトリに +- [Amethyst](https://github.com/vitorpamplona/amethyst) - 機能豊富なAndroidおよびマルチプラットフォームのNostr client。Armadaとwire互換なclean-room再実装([PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566)) + +--- + +**Primary sources:** +- [Concord protocol specs (CORD-01 to CORD-07)](https://github.com/concord-protocol/concord) +- [Vector v0.4.0 release notes](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) +- [Vector v0.4.1 release notes](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) +- [Amethyst PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) + +**Mentioned in:** +- [Newsletter #31: Vector v0.4.0 moves Group Chats from Marmot to Concord, and Amethyst ships its own Concord client days later](/ja/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) +- [Newsletter #31: Amethyst ships a clean-room Concord implementation for end-to-end encrypted communities](/ja/newsletters/2026-07-15-newsletter/#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) + +**See also:** +- [Marmot Protocol](/ja/topics/marmot/) +- [MLS (Message Layer Security)](/ja/topics/mls/) +- [NIP-46: Nostr Connect](/ja/topics/nip-46/) diff --git a/content/ja/topics/gamma-markets.md b/content/ja/topics/gamma-markets.md new file mode 100644 index 0000000..6e6ee9b --- /dev/null +++ b/content/ja/topics/gamma-markets.md @@ -0,0 +1,69 @@ +--- +title: "Gamma Markets" +date: 2026-07-15 +translationOf: /en/topics/gamma-markets.md +translationDate: 2026-07-15 +draft: false +categories: + - Commerce + - Marketplace + - Protocol +--- + +Gamma Marketsは、[NIP-99](/ja/topics/nip-99/) classified listingsの上に直接構築されたe-commerce向けの取り決めのセットで、Nostrマーケットプレイス開発者のワーキンググループ、すなわちShopstr、Cypher、Plebeian Market、Conduit Marketの各チームによって共同で開発されました。NIP-99自身が未定義のまま残す、配送、order flow、コレクション、レビューの取り決めを埋めます。 + +## 仕組み + +Gamma Marketsは、NIP-99の既存のkind `30402` listing eventの周りに、そのeventの形を変えることなく、5つのevent kindを追加します。 + +- **Kind 30405** - product collection。`a` tagを介して複数のlistingをまとめる +- **Kind 30406** - 配送オプション。国ごとの価格設定と、任意の重量ベースまたは距離ベースの費用ルール付き +- **Kind 16** - order message。作成(type 1)、支払いリクエスト(type 2)、ステータス更新(type 3)、配送更新(type 4) +- **Kind 14** - 一般的なbuyer/merchant間のコミュニケーション +- **Kind 17** - 支払いレシート +- **Kind 31555** - product review。特定のseller pubkeyとlistingの`d` tag宛て + +merchantの支払い設定は、そのkind `0` profile metadataの`payment_preference` tagを介して宣言され、clientは[NIP-89](/ja/topics/nip-89/) application recommendationsを通じて互換アプリを発見します。order communicationは[NIP-17](/ja/topics/nip-17/) private messagesの上に構築され、独自の新しい暗号化方式を持ちません。 + +この仕様を特徴づける設計上の選択は、何も継承しない(cascadeしない)ことです。コレクションに属する、または配送オプションを使うlistingは、親の設定を自動的に継承する代わりに、`a` tagで明示的にそれを参照します。これは、productがstallの通貨と配送テーブルを暗黙のうちに継承していた、古い[NIP-15](/ja/topics/nip-15/) stallモデルからの意図的な離脱です。 + +### 例: order作成(kind 16、type 1) + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +## なぜ重要か + +NIP-99単体では、listingそのもの、すなわち署名済みでaddressableなclassified adだけを標準化します。Gamma Markets以前は、NIP-99上で実際のe-commerceを構築するclientはそれぞれ、配送、checkout、レビューのための独自のprivateな取り決めを発明しており、それは2つのNIP-99準拠のclientが、それぞれ正しくlistingを描画できても、両者間でorderを完了させる共有の方法を持たないことを意味しました。Gamma Marketsは、NIP-99のlistingフォーマットそのものに触れずにその穴を埋めるため、既存のNIP-99 listingは変更なしで有効なままです。 + +## 実装 + +- [Shopstr](https://github.com/shopstr-eng/shopstr) - Nostrマーケットプレイス。仕様を執筆した4つのプロジェクトの1つ +- [Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) - マーケットプレイスプロトコル。同じ設計領域で独自のorder-stateとcheckout flowを構築中 + +--- + +**Primary sources:** +- [Gamma Markets spec repository](https://github.com/GammaMarkets/market-spec) +- [NIP-99 e-commerce use case extension, PR #1784](https://github.com/nostr-protocol/nips/pull/1784) - merged link from the canonical NIP-99 document to the Gamma Markets spec + +**Mentioned in:** +- [Newsletter #31: NIP Deep Dive: NIP-99 and the Gamma Markets commerce extension](/ja/newsletters/2026-07-15-newsletter/#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) + +**See also:** +- [NIP-99: Classified Listings](/ja/topics/nip-99/) +- [NIP-15: Nostr Marketplace](/ja/topics/nip-15/) +- [NIP-17: Private Direct Messages](/ja/topics/nip-17/) diff --git a/content/ja/topics/nip-4e.md b/content/ja/topics/nip-4e.md new file mode 100644 index 0000000..f156af4 --- /dev/null +++ b/content/ja/topics/nip-4e.md @@ -0,0 +1,46 @@ +--- +title: "NIP-4E: アイデンティティからの暗号化の分離" +date: 2026-07-15 +translationOf: /en/topics/nip-4e.md +translationDate: 2026-07-15 +draft: false +categories: + - NIP + - Protocol + - Encryption +--- + +NIP-4Eは、fiatjafによって提案されたオープンなdraftで、すべてのデバイスがそのユーザーのメインのNostr identity keyを保持することなく、ユーザー自身のデバイス間でprivateなデータを共有するためのものです。マージされておらず、`draft`/`optional`な提案のままです。 + +## 解決しようとする問題 + +NIP-51 listsやNIP-60 Cashu walletsを含む多くの既存のNIPは、後で任意のデバイスで読み戻せるように、identity keyを使ってユーザーから自分自身へデータを暗号化します。これは、identity keyに直接アクセスできない場合、たとえばremote signerがFROST threshold shares、MuSig2、あるいはホストされたsecure enclaveで保護されている場合に破綻します。というのも、暗号化と復号のたびに、そのsignerへの往復が必要になるからです。また、署名鍵がremote bunkerにある場合には、オフライン暗号化が不可能になります。 + +## 仕組み + +NIP-4Eは、per-deviceの「client key」を、ユーザーのidentity keyではない共有の「encryption key」から分離します。 + +1. ユーザーが最初にセットアップするclientが、ランダムなencryption keypairを生成し、その公開側をユーザーのidentity keyで署名した`kind:10044` eventで告知します。 +2. そのユーザー向けにデータを暗号化または復号したい他のclientは、identity keyではなく、告知されたencryption keyに対してDiffie-Hellman shared secretを計算します。 +3. 2台目のデバイスが新しいclientをインストールすると、そのclientは独自のローカルな「client key」を生成し、最初のclientにencryption keyの共有を求める`kind:4454`告知(これもユーザーのidentity keyで署名)を発行します。 +4. 元のclientが新しい`kind:4454`告知を検知し、[NIP-44](/ja/topics/nip-44/)を使って共有encryption keyを新しいclientの鍵宛てに暗号化し、それを発行することで、新しいclientはそれ以降それを復号して使えます。 + +その結果、clientが共有encryption keyをローカルに保持している限り、暗号化と復号がidentity-key signerに問い合わせる必要が一切なくなり、identityにはremote-signerのセットアップ(FROST、MuSig2、ホストされたenclave)を使いつつ、通常の暗号化は高速のままオフラインでも動作します。 + +## なぜ重要か + +NIP-4Eは、暗号化/復号呼び出しのたびにremote signerに依存することなく、drive全体またはaccount全体のsymmetric keyを必要とする他の提案の基礎として引用されています。private encrypted drive提案([PR #2412](https://github.com/nostr-protocol/nips/pull/2412))や、同じアイデアのより狭いNIP-17固有版([PR #2361](https://github.com/nostr-protocol/nips/pull/2361))などです。どちらもNIP-4E自体と並んでオープンなままで、これを完成した部品ではなく、プロトコルのアクティブで未確定な領域にしています。 + +--- + +**Primary sources:** +- [NIP-4E draft, PR #1647](https://github.com/nostr-protocol/nips/pull/1647) + +**Mentioned in:** +- [Newsletter #31: Open: private encrypted drive extends NIP-4E](/ja/newsletters/2026-07-15-newsletter/#open-private-encrypted-drive-extends-nip-4e) + +**See also:** +- [NIP-44: Encrypted Payloads](/ja/topics/nip-44/) +- [NIP-17: Private Direct Messages](/ja/topics/nip-17/) +- [NIP-46: Nostr Connect](/ja/topics/nip-46/) +- [FROST](/ja/topics/frost/) diff --git a/content/ja/topics/proofmode.md b/content/ja/topics/proofmode.md new file mode 100644 index 0000000..8f9f3ad --- /dev/null +++ b/content/ja/topics/proofmode.md @@ -0,0 +1,36 @@ +--- +title: "ProofMode" +date: 2026-07-15 +translationOf: /en/topics/proofmode.md +translationDate: 2026-07-15 +draft: false +categories: + - Media + - Provenance +--- + +[ProofMode](https://proofmode.org/)は、Guardian Project、WITNESS、Okthanksによって作られたオープンソースのmedia-provenanceツールキットで、撮影の瞬間に写真や動画へ検証可能な真正性とchain-of-custodyのデータを付与します。Nostr固有のものではありません。ProofModeデータを運ぶNostr clientは、新しいプロトコル層ではなく、既存の外部標準を統合しているのです。 + +## 仕組み + +ProofModeのCaptureコンポーネントは、撮影中にprovenance metadataをmediaファイルへ直接埋め込み、Content Authenticity Initiative(CAI)、Content Credentials(CR)、C2PAが使うのと同じ相互運用可能な標準をサポートします。別のVerifyコンポーネントは、audio、画像、動画ファイルを検査して、そのmetadataにAI生成や後からの編集の痕跡がないかをチェックし、Preserveコンポーネントは、長期アーカイブのために、基盤となるproofデータの冗長で分散型ウェブのストレージを扱います。Develop SDKにより、アプリはprovenanceフォーマットを自前で構築することなく、撮影と検証を統合できます。 + +## なぜ重要か + +Nostrの動画または画像clientにとって、ProofModeデータを運ぶことは、視聴者が、公開元のclientやrelayを信頼の拠り所とせずに、あるmediaが主張どおりに撮影され、それ以降ひそかに改変されていないかを確認する、外部的でクロスプラットフォームな手段を持つことを意味します。その違いが最も効いてくるのは、clipのダウンロードまたは再エンコードされたコピーの場合です。ダウンロードと、clientが適用する任意のwatermarkingを生き延びるprovenanceデータこそが、ファイルがそれを生成したアプリを離れた後も、その証明を検証可能なままにするものです。 + +## 実装 + +- [Divine](https://github.com/divinevideo/divine-mobile) - short-videoなNostr client。watermarkされたclipのダウンロードを通じてProofMode provenanceデータを運ぶ + +--- + +**Primary sources:** +- [ProofMode](https://proofmode.org/) + +**Mentioned in:** +- [Newsletter #17](/ja/newsletters/2026-04-29-newsletter/) +- [Newsletter #31: Divine Mobile 1.0.16 ships a deeper video editor, at-rest encryption, and ProofMode provenance](/ja/newsletters/2026-07-15-newsletter/#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) + +**See also:** +- [Blossom](/ja/topics/blossom/) From f8c454dccd5c34c805c7b0e66c636fb0b6305f4f Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Thu, 16 Jul 2026 08:38:01 +0000 Subject: [PATCH 07/10] Add Korean translation for Newsletter #31 and topic pages --- .../ko/newsletters/2026-07-15-newsletter.md | 300 ++++++++++++++++++ content/ko/topics/concord-protocol.md | 61 ++++ content/ko/topics/gamma-markets.md | 69 ++++ content/ko/topics/nip-4e.md | 46 +++ content/ko/topics/proofmode.md | 36 +++ 5 files changed, 512 insertions(+) create mode 100644 content/ko/newsletters/2026-07-15-newsletter.md create mode 100644 content/ko/topics/concord-protocol.md create mode 100644 content/ko/topics/gamma-markets.md create mode 100644 content/ko/topics/nip-4e.md create mode 100644 content/ko/topics/proofmode.md diff --git a/content/ko/newsletters/2026-07-15-newsletter.md b/content/ko/newsletters/2026-07-15-newsletter.md new file mode 100644 index 0000000..7e97826 --- /dev/null +++ b/content/ko/newsletters/2026-07-15-newsletter.md @@ -0,0 +1,300 @@ +--- +title: "Nostr Compass #31" +date: 2026-07-15 +publishDate: 2026-07-15 +draft: false +type: newsletters +translationOf: /en/newsletters/2026-07-15-newsletter.md +translationDate: 2026-07-15 +description: "Vector v0.4.0가 그룹 채팅의 기본 전송 방식을 Marmot에서 개방형 Concord 프로토콜로 전환하고 며칠 뒤 Concord v2를 출시하며, Amethyst가 자체 클린룸 Concord 구현을 병합하고, Sonar가 크로스 플랫폼 알파와 스티커 팩 명세와 함께 Bitchat에서 분리되며, Divine Mobile 1.0.16이 저장 데이터 암호화와 ProofMode 출처 정보를 도입하고, Bitchat 1.7.0이 실시간 푸시투토크 음성을 추가하며, MDK v0.9.4가 외부 서명자 로그인에 상한을 둔다." +--- + +Nostr에 대한 주간 가이드, Nostr Compass에 다시 오신 것을 환영합니다. + +**이번 주:** [Vector v0.4.0](#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later)가 그룹 채팅의 기본 전송 방식으로서 [Marmot](/ko/topics/marmot/)을 은퇴시키고 [Concord](/ko/topics/concord-protocol/)를 채택했습니다. Concord는 Soapbox의 Armada도 사용하는 개방형 MIT 라이선스 커뮤니티 프로토콜이며, 4일 뒤 Vector는 봇용 슬래시 명령어 선택기, 자폭 타이머, NIP-58 badge를 담은 Concord v2를 출시했습니다. 같은 주에 [Amethyst가 자체 클린룸 방식의 와이어 호환 Concord 구현을 병합했습니다](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities). [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec)는 크로스 플랫폼 알파와 함께 Bitchat에서 분리되었으며, 이번 주 스티커 팩 kind 제안의 인용된 명세 출처입니다. [Divine Mobile 1.0.16](#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance)은 더 깊이 있는 비디오 편집기, 저장 데이터 암호화, 그리고 워터마크 클립 다운로드에도 유지되는 ProofMode 출처 정보를 도입했습니다. [Bitchat v1.7.0](#bitchat-v170-adds-live-push-to-talk-voice-for-dms-and-the-public-mesh)은 DM용 실시간 푸시투토크 음성과 공개 메시에서의 서명된 푸시투토크를 추가했습니다. [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence)는 외부 서명자 로그인에 상한을 두고 초안 유지 기능을 추가하며, Vector가 그룹 채팅 명세에서 손을 떼는 바로 그 주에 강화 작업을 이어갔습니다. + +태그가 붙은 릴리스로는 NSEC Bunker 지원을 추가한 [n_cord v1.1](#n_cord-v11-adds-nsec-bunker-support), cdk, cdk-nwc, cdk-ffi 전반에 걸쳐 NIP-47 wallet-service 지원을 추가한 [cdk v0.17.3](#cdk-v0173-adds-nip-47-wallet-service-support-across-cdk-cdk-nwc-and-cdk-ffi), Nostr Connect를 개선하고 ncryptsec1 가져오기를 추가한 [Coop Mobile v0.2.4](#coop-mobile-v024-improves-nostr-connect-and-adds-ncryptsec1-import), 예약 발송과 함께 macOS에 안착한 [Nmail v0.14.0](#nmail-v0140-ships-on-macos-with-scheduled-send-and-push-notifications), DM 마스터 토글을 추가한 [Nostrord v2.2.0](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages), 키 백업을 NIP-49 형식으로 강화한 [Nostr WoT 0.3.86](#nostr-wot-0386-hardens-key-backups-and-signing-prompts), 최초 실행 FROST 온보딩을 추가한 [Keep Android v1.1.8](#keep-android-v118-adds-first-run-frost-onboarding), Cashu 지갑과 relay 기반 푸시 알림을 추가한 [Noscall v0.6.0](#noscall-v060-adds-a-cashu-wallet-and-relay-based-push-notifications), 태블릿 모드와 그룹 채팅 사진을 추가한 [Kubo](#kubo-ships-tablet-mode-and-group-chat-photos), 그리고 git, diff, read-file 헬퍼 요청을 추가한 [Nostr Codex Phone v0.2.9](#nostr-codex-phone-v029-adds-gitdiffread-file-helper-requests)가 있습니다. + +아직 릴리스되지 않은 쪽에서는, [Amethyst](#amethyst-lets-accounts-nickname-contacts-with-encrypted-nip-85-cards)가 54개의 병합된 PR을 통해 암호화된 NIP-85 카드로 계정이 연락처에 별명을 붙일 수 있게 했고, [Zap Cooking](#zap-cooking-ships-my-kitchen-phase-3-and-fixes-an-ndk-pool-quorum-bug)이 My Kitchen 3단계를 출시하고 NDK 풀 정족수 버그를 수정했으며, [Kehto](#kehto-streams-outbox-reads-before-relay-discovery)가 relay 탐색이 끝나기 전에 outbox 읽기를 스트리밍하고, [Wired와 TAO](#wired-and-tao-add-nip-57-creator-revenue-sharing)가 NIP-57 크리에이터 수익 분배를 추가했으며, [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout)가 일회성 게스트 체크아웃을 중심으로 판매자 주문함을 재구축했고, [Buzz](#buzz-hardens-channel-creator-provisioning-around-kind-39002)가 240개의 병합된 PR을 통해 채널 생성자 프로비저닝을 강화했으며, [Nostr Docs](#nostr-docs-adopts-a-nip-49-signer-with-multi-account-and-qr-pairing)가 다중 계정과 QR 페어링을 갖춘 NIP-49 서명자를 채택했습니다. 이번 주 새로 추적된 프로젝트: [OpenDiscord v1.0.1](#opendiscord-v101-launches-as-a-discord-style-client-on-nostr), [Auditable Voting v0.1.140](#auditable-voting-v01140-aligns-organiser-voter-and-audit-proxy-roles), 그리고 Discovery 선정작 [Cambium v0.3.2](#cambium-v032-pairs-with-heartwood-as-a-keyless-nip-55-signer)로, Heartwood 하드웨어 동반 기기로 요청을 프록시하는 키 없는 NIP-55 서명자입니다. + +NIPs 저장소는 지난 한 주 동안 아무것도 병합하지 않았고 여섯 개의 제안을 열었습니다: [kind:10011 즐겨찾기 팔로우 세트](#open-kind10011-favorite-follow-sets), [NIP-4E를 확장하는 비공개 암호화 드라이브](#open-private-encrypted-drive-extends-nip-4e), [NIP-DA 권한 기반 비공개 데이터 공유](#open-nip-da-permissioned-private-data-sharing), [스티커 팩 kind 10031과 30031](#open-sticker-pack-kinds-10031-and-30031), [NIP-29 메시지 고정](#open-nip-29-message-pinning-with-kind9010-and-kind39005), 그리고 [NIP-66 relay 탐색 재구조화](#open-nip-66-relay-discovery-restructure). Deep Dive는 [NIP-99와 Gamma Markets 커머스 확장](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension)을 다룹니다. + +--- + +## 주요 소식 + +### Vector v0.4.0가 그룹 채팅을 Marmot에서 Concord로 옮기고, 며칠 뒤 Amethyst가 자체 Concord 클라이언트를 출시하다 + +[Vector](https://github.com/VectorPrivacy/Vector)는 DM과 그룹 채팅을 위한 단일 바이너리, 프라이버시 우선 클라이언트를 중심으로 구축된 Nostr 메신저입니다. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0)는 앱의 메시징 엔진을 공유 `vector-core` 라이브러리로 재작성하고, 같은 릴리스에서 그룹 채팅의 기본 전송 방식으로서 [Marmot](/ko/topics/marmot/)(MLS-over-Nostr)을 은퇴시키고 종단 간 암호화 커뮤니티 프로토콜인 [Concord](/ko/topics/concord-protocol/)를 채택했습니다. 기존 Marmot 그룹 기록은 이전되지 않으며, 릴리스 노트는 사용자에게 업그레이드 전에 Marmot 그룹 데이터를 백업하라고 안내합니다. Vector 자체 릴리스 노트는 Concord를 "우리의 맞춤형 메시징 프로토콜"이라고 설명하지만, 그 기반인 [CORD-01부터 CORD-07까지의 명세](https://github.com/concord-protocol/concord)는 별도로 공개되어 있고, MIT 라이선스이며, 이미 Vector 외부에서 구현되어 있습니다. Soapbox의 Discord 스타일 클라이언트 [Armada](https://gitlab.com/soapbox-pub/armada)는 같은 Concord 명세 위에 Communities 기능을 구축하고 있으며, 하루 뒤 [Amethyst가 자체 클린룸 방식의 와이어 호환 Concord 구현을 병합했습니다](https://github.com/vitorpamplona/amethyst/pull/3566)(아래에서 자세히 다룹니다). 같은 Vector 릴리스는 모든 트래픽에 대한 선택적 Tor 라우팅, QR 또는 붙여넣은 bunker URI를 통한 [NIP-46](/ko/topics/nip-46/) 원격 서명자 로그인, 앱 내 전환기를 갖춘 다중 계정, 그리고 클라이언트 간에 공유되는 커스텀 이모지 팩을 추가합니다. 메시지 삭제는 DM과 그룹 채팅에서 양쪽 모두에게 메시지를 제거하며, Vector는 표준 [NIP-17](/ko/topics/nip-17/) 삭제 흐름을 따르는 대신 의도적으로 일회성 서명 키를 보관하는데, 이는 프로젝트가 릴리스 노트에서 명시적으로 밝히는 프라이버시 동기의 결정입니다. 4일 뒤, [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1)이 **Concord v2**를 출시했습니다. 이는 기존 Communities를 계속 작동시키면서 Communities에 중요한 프라이버시 및 안정성 개선을 가져오는 것으로 설명되며, 봇용 타입 지정 매개변수를 갖춘 Discord 스타일 슬래시 명령어 선택기, 채팅별 자폭 타이머, 그리고 버그 헌터를 위한 NIP-58 badge 시스템을 함께 담고 있습니다. 그룹 채팅에서 Marmot을 떠나는 이 움직임은 아래의 [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence)가 계속해서 그 명세에 투자하는 바로 그 주에 나왔습니다. + +### Amethyst가 종단 간 암호화 커뮤니티를 위한 클린룸 Concord 구현을 출시하다 + +[Amethyst](https://github.com/vitorpamplona/amethyst)는 기능이 풍부한 Android 및 멀티플랫폼 Nostr 클라이언트입니다. [PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566)은 서버 없는 종단 간 암호화 커뮤니티를 다루는 [Concord](/ko/topics/concord-protocol/)(CORD-01부터 CORD-07)의 완전한 구현을 추가합니다. 여기에는 일반 relay 위에서 gift-wrap된 제어, 채팅, 방명록 평면, 모든 클라이언트가 서버를 신뢰하는 대신 로컬에서 검증하는 소유자 기반 역할 및 차단 집행, 그리고 제거된 구성원의 접근을 끊기 위한 재키잉이 포함됩니다. 프로토콜과 암호화 코드는 `quartz/`에, 상태 및 뷰 모델은 `commons/`에, 화면과 내비게이션은 Android용 `amethyst/`에 있으며, 얇은 CLI 동사가 `cli/` 아래에 있습니다. 아직 데스크톱 UI는 없는데, 공유 로직이 `quartz`/`commons`에 있어 나중에 Desktop이 채택할 수 있기 때문입니다. 이 구현은 클린룸 방식입니다. 공개된 CORD 명세와 관찰된 와이어 상수를 바탕으로 Amethyst 자체 MIT 라이선스 아래 구축되었으며, Armada의 AGPL-3.0 코드베이스와는 별개입니다. Armada 자체 테스트 벡터 값이 Quartz의 단위 테스트로 이식되어 두 클라이언트가 실제로 와이어 수준에서 상호 운용됨을 확인했고, 이로써 Concord는 며칠 사이에 세 개의 독립 구현을 갖게 되었습니다. Vector가 먼저 출시했고, Armada가 Soapbox의 참조 클라이언트이며, 이제 Amethyst의 명세 기반 빌드가 더해졌습니다. + +### Sonar가 크로스 플랫폼 알파와 스티커 팩 명세와 함께 Bitchat에서 분리되다 + +[Sonar](https://sonarprivacy.xyz/)는 Bitchat에서 성장한 블루투스 메시 및 Nostr 메신저 겸 지갑으로, White Noise와 상호 운용되는 Marmot 그룹 DM을 갖추고 있습니다. 코드는 [hedwig-corp/bitchat-to-sonar](https://github.com/hedwig-corp/bitchat-to-sonar)에 있습니다. [v0.1-alpha.7](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.7)은 열기와 스크롤 성능이 로컬 우선으로 유지되도록 Signal 스타일의 경계 있는 대화 기록 윈도잉을 추가하고, 근처 탐색 상태를 피어 간에 동기화하며, content-type과 HTTP 상태 처리에서 실패하던 Blossom 미디어 업로드를 수정합니다. 앞선 [alpha.6](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.6)은 더 빠른 채팅 새로고침을 위해 실시간 Marmot 이벤트를 소진했고 통화, 메시징, 지갑, 푸시 전반에 걸쳐 Android-iOS 기능 격차를 좁혔습니다. Sonar는 또한 [PR #2410](#open-sticker-pack-kinds-10031-and-30031)의 인용된 명세 출처로, 프로젝트 자체의 "Sonar Stickers" 명세 아래 스티커 팩 이벤트 kind를 등록하며, 이번 출시에 이번 주 프로토콜 작업으로 향하는 직접적인 허브 링크를 제공합니다. + +### Divine Mobile 1.0.16이 더 깊이 있는 비디오 편집기, 저장 데이터 암호화, ProofMode 출처 정보를 도입하다 + +[Divine](https://github.com/divinevideo/divine-mobile)은 Web-of-Trust 피드 큐레이션을 갖춘 Nostr 기반 숏폼 비디오 클라이언트입니다. #30 이후 첫 태그 릴리스인 [v1.0.16](https://github.com/divinevideo/divine-mobile/releases/tag/1.0.16)은 비디오 편집기에 클립 전환, 역재생, 보이스오버 녹음기, 타임라인 비트 마커를 추가하며, 사용자가 불투명한 참여 신호에 맡기는 대신 직접 스와이프해 추천을 조정할 수 있게 하는 피드 조정 컨트롤도 함께 제공합니다. 이 릴리스는 또한 로컬 데이터에 대한 저장 데이터 암호화를 켜고, 앱이 중단되어도 유지되는 백그라운드 업로드를 추가하며, 워터마크 클립이 다운로드될 때 [ProofMode](/ko/topics/proofmode/) 출처 데이터를 함께 전달해 인간이 만든 증명이 전송 중에 벗겨지지 않도록 합니다. Divine은 또한 16세 미만 계정에 대한 새로운 보호 기능을 도입하고 로컬라이제이션을 17개 언어와 284개의 번역 문자열로 확장했습니다. + +### Bitchat v1.7.0이 DM과 공개 메시를 위한 실시간 푸시투토크 음성을 추가하다 + +[Bitchat](https://github.com/permissionlesstech/bitchat)은 Nostr relay로의 선택적 게이트웨이를 갖춘 블루투스 메시 채팅 앱입니다. #30이 게시된 저녁에 릴리스된 [v1.7.0](https://github.com/permissionlesstech/bitchat/releases/tag/v1.7.0)은 [PR #1403](https://github.com/permissionlesstech/bitchat/pull/1403)에서 실시간 푸시투토크 음성을 추가하는데, 발신자가 버튼을 누르는 동안 오디오를 스트리밍하고 스트림이 끊기면 음성 메모로 대체합니다. 또한 [PR #1406](https://github.com/permissionlesstech/bitchat/pull/1406)에서 서명된 공개 메시 푸시투토크를 추가해 공유 메시 채널의 실시간 음성 버스트가 발신자 인증을 담도록 합니다. 이 릴리스는 또한 검증된 재공지 시 링크를 재바인딩하여 같은 피어를 새 ID로 인식함으로써 peer-ID 회전을 복구하고([PR #1401](https://github.com/permissionlesstech/bitchat/pull/1401)), 현재 도달할 수 없는 피어로 향하는 직접 메시지가 곧바로 실패하는 대신 store-and-forward 전달로 대기열에 들어가도록 합니다([PR #1415](https://github.com/permissionlesstech/bitchat/pull/1415)). 이는 v1.6.0의 [NIP-13](/ko/topics/nip-13/) proof-of-work와 메시-to-Nostr 게이트웨이 작업을 다룬 #30의 보도에서 직접 이어집니다. + +### MDK v0.9.4가 외부 서명자 로그인에 상한을 두고 초안 유지를 추가하다 + +[MDK](https://github.com/marmot-protocol/mdk)는 [Marmot](/ko/topics/marmot/) 프로토콜의 참조 SDK로, #30이 그 명세가 채택되었음을 다룬 MLS-over-Nostr 메시징 계층입니다. [v0.9.4](https://github.com/marmot-protocol/mdk/releases/tag/v0.9.4)는 [PR #793](https://github.com/marmot-protocol/mdk/pull/793)에서 클라이언트가 외부 서명자 로그인 중에 거치는 권고 디렉터리 단계에 상한을 두어, 원격 서명자가 느리거나 응답하지 않을 때 무한 재시도 루프를 방지합니다. 같은 릴리스는 [PR #812](https://github.com/marmot-protocol/mdk/pull/812)에서 초안 메시지 유지와 프로필-웹사이트 바인딩을 추가하며, MDK가 v0.9.0을 낸 이후 이어온 점진적 강화 작업을 계속합니다. + +--- + +## 태그 릴리스 + +### n_cord v1.1이 NSEC Bunker 지원을 추가하다 + +[n_cord](https://github.com/0n4t3/n_cord)는 Discord와 IRC에서 영감을 받은 Nostr 기반 채팅 클라이언트입니다. [v1.1](https://github.com/0n4t3/n_cord/releases/tag/v1.1)은 [NIP-46](/ko/topics/nip-46/) NSEC Bunker 지원을 답글 처리 버그 수정과 함께 추가합니다. + +### cdk v0.17.3이 cdk, cdk-nwc, cdk-ffi 전반에 NIP-47 wallet-service 지원을 추가하다 + +[cdk](https://github.com/cashubtc/cdk)는 Cashu 개발 키트입니다. 이 릴리스는 대부분의 측면에서 Bitcoin/Lightning 전용이지만, [v0.17.3](https://github.com/cashubtc/cdk/releases/tag/v0.17.3)은 전용 NWC 서비스 크레이트, 지갑 통합, `cdk-ffi`용 FFI 바인딩, 종단 간 테스트 커버리지와 함께 [NIP-47](/ko/topics/nip-47/)(Nostr Wallet Connect) 서비스 지원을 추가하여, cdk 위에 구축된 Cashu 지갑에 표준 Nostr Wallet Connect 표면을 제공합니다. + +### Coop Mobile v0.2.4가 Nostr Connect를 개선하고 ncryptsec1 가져오기를 추가하다 + +[Coop Mobile](https://git.reya.su/reya/coop-mobile)은 모바일 플랫폼용 [NIP-17](/ko/topics/nip-17/) 비공개 메시징 클라이언트입니다. [v0.2.4](https://git.reya.su/reya/coop-mobile/releases/tag/v0.2.4)는 [NIP-46](/ko/topics/nip-46/) Nostr Connect 흐름을 개선하고, 일부 연결에서 영구적으로 멈춰 있던 로딩 표시를 수정하며, 재설계된 신원 가져오기 화면과 함께 [NIP-49](/ko/topics/nip-49/) `ncryptsec1` 암호화 키 형식에 대한 가져오기 지원을 추가합니다. + +### Nmail v0.14.0이 예약 발송 및 푸시 알림과 함께 macOS에 안착하다 + +[Nmail](https://github.com/nogringo/nostr-mail-client)은 Nostr 기반 메일 클라이언트입니다. [v0.14.0](https://github.com/nogringo/nostr-mail-client/releases/tag/v0.14.0)은 앱을 macOS로 가져오고, 대기 중인 메시지를 위한 전용 예약 메일함과 함께 예약 발송을 추가하며, 푸시 알림을 추가합니다. 이 릴리스는 또한 주소록 Nostr 식별자 해석을 자체 구현 대신 NDK의 [NIP-05](/ko/topics/nip-05/) 리졸버로 전환합니다. + +### Nostrord v2.2.0이 DM 마스터 토글과 더 풍부한 직접 메시지를 추가하다 + +[Nostrord](https://github.com/nostrord/nostrord)는 Android, iOS, 웹, 데스크톱용 [NIP-29](/ko/topics/nip-29/) relay 기반 그룹 채팅 클라이언트입니다. [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0)은 모든 직접 메시지 기능을 한 번에 비활성화하는 마스터 토글을 추가하고([PR #175](https://github.com/nostrord/nostrord/pull/175)) "더 풍부한 직접 메시지"를 출시하며([PR #186](https://github.com/nostrord/nostrord/pull/186)), relay 풀을 통합하고 좀비 WebSocket을 감지한 릴리스를 다룬 #30의 보도에서 이어집니다. + +### Nostr WoT 0.3.86이 키 백업과 서명 프롬프트를 강화하다 + +[Nostr WoT](https://github.com/nostr-wot/nostr-wot-extension)는 Nostr 신원과 Lightning 지갑을 짝지어주는 브라우저 확장 프로그램입니다. [v0.3.86](https://github.com/nostr-wot/nostr-wot-extension/releases/tag/v0.3.86)은 암호화된 키 백업을 표준 [NIP-49](/ko/topics/nip-49/) 형식으로 옮기고, 서명 프롬프트가 요약 대신 전체 이벤트와 모든 tag를 표시하도록 하며, relay 데이터를 그 서명에 대해 검증하고, 계정 전환 시 활성 신원이 노출되지 않도록 합니다. 이 확장 프로그램은 또한 사용되지 않던 `scripting` 브라우저 권한을 제거합니다. + +### Keep Android v1.1.8이 최초 실행 FROST 온보딩을 추가하다 + +[Keep](https://github.com/privkeyio/keep-android)은 임계값 FROST 키 조각 위에 구축된 Android 서명자입니다. [v1.1.8](https://github.com/privkeyio/keep-android/releases/tag/v1.1.8)은 FROST 키 조각을 설명하고 새 사용자가 첫 서명 요청이 도착하기 전에 Manual, Basic, Auto 중 서명 정책을 선택하게 하는 최초 실행 흐름을 추가하는데, 이는 기반이 되는 keep-mobile 크레이트의 임계값 서명 모델에 대한 Android 측 최초 온보딩입니다. + +### Noscall v0.6.0이 Cashu 지갑과 relay 기반 푸시 알림을 추가하다 + +[Noscall](https://github.com/sanah9/noscall)은 Nostr 기반의 안전한 음성 및 영상 통화 앱입니다. [v0.6.0](https://github.com/sanah9/noscall/releases/tag/v0.6.0-release)은 멀티 민트 잔액, ecash 송수신, 견적 유지 기능이 있는 Lightning 지불 및 수령을 갖춘 계정 범위의 Cashu 지갑을 추가합니다. 이 릴리스는 또한 Android 푸시 알림을 Firebase Cloud Messaging에서 UnifiedPush를 통한 Nostr-relay 기반 전달 경로로 이전하고, 로그인 재시도 중 iOS VoIP 및 APNs 푸시 신뢰성을 개선합니다. + +### Kubo가 태블릿 모드와 그룹 채팅 사진을 출시하다 + +[Kubo](https://github.com/JeroenOnNostr/kubo)는 Web-of-Trust 피드 큐레이션을 갖춘 아동 안전 Nostr 비디오 플랫폼입니다. [kubo-v2026.07.05](https://github.com/JeroenOnNostr/kubo/releases/tag/kubo-v2026.07.05)는 아동 피드용 선택적 태블릿 그리드 레이아웃과 그룹 채팅 메시지에 사진을 첨부하는 지원을 추가하고, Android에서 가입 버튼이 화면 키보드 뒤에 숨는 문제를 수정합니다. + +### Nostr Codex Phone v0.2.9가 git/diff/read-file 헬퍼 요청을 추가하다 + +[Nostr Codex Phone](https://github.com/tidley/nostr-codex-phone)은 암호화된 Nostr DM을 통해 통신하는 로컬 코딩 어시스턴트 워커를 위한 모바일 제어 표면입니다. [v0.2.9](https://github.com/tidley/nostr-codex-phone/releases/tag/v0.2.9)는 git, diff, read-file, status, history 헬퍼 요청을 포함한 모바일 OpenCode 도구 액션, 세션 고정 및 검색 개선, 작업 중단 컨트롤을 추가하며, 앞선 v0.2.8에서 출시된 암호화된 [Blossom](/ko/topics/blossom/) 업로드 래퍼를 함께 담고 있습니다. + +### GitWorkshop v3.0.3이 저장소 탐색기에서 새로 공지된 ref를 수정하고, 첫 Android 빌드를 출시하다 + +[GitWorkshop](https://github.com/DanConwayDev/gitworkshop)은 NIP-34 저장소를 탐색하고 검토하기 위한 git-over-Nostr 웹 UI입니다. [v3.0.3](https://github.com/DanConwayDev/gitworkshop/releases/tag/v3.0.3)은 탐색기가 이미 저장소를 로드한 뒤 그 저장소가 공지하는 ref를 브랜치, 태그, 커밋, 코드 브라우징 뷰가 해석하지 못하던 문제를 수정하며, CI 워크플로 타이밍 정리와 함께 태그 및 커밋 기록에 대해 직접 확인되었습니다. 같은 주에 GitWorkshop은 첫 네이티브 Android 빌드를 [Zapstore](https://zapstore.dev)에 게시했으며, v3.0.0에서 시작해 몇 시간 만에 v3.0.3에 도달했습니다. 웹 UI가 주요 인터페이스로 남아 있으며, Android 패키지는 동일한 NIP-34 저장소 브라우징을 처음으로 휴대폰에 가져옵니다. + +### Bitcoin-Safe가 Flathub에 도달하며 Nostr Sync & Chat 플러그인을 부각시키다 + +[Bitcoin-Safe](https://bitcoin-safe.org)는 하드웨어 서명자 워크플로를 중심으로 구축된 자기 수탁 Bitcoin 지갑입니다. 이 프로젝트는 이번 주에 [Flathub 패키지를 출시](https://flathub.org/apps/org.bitcoin_safe.BitcoinSafe)했는데, 이는 주류 Linux 앱 스토어에 첫 등록입니다. Flathub 릴리스는 Bitcoin-Safe의 Sync & Chat 플러그인을 더 넓은 청중 앞에 세웁니다. 이 플러그인은 프로젝트 자체의 [bitcoin-nostr-chat](https://github.com/andreasgriffin/bitcoin-nostr-chat) 라이브러리를 통해 [NIP-17](/ko/topics/nip-17/) 직접 메시지를 사용하여, 사용자의 여러 기기 간에 지갑 라벨을 동기화하고 신뢰하는 참가자 간 원격 멀티시그 공동 서명을 위한 PSBT를 주고받습니다. Nostr 계층 자체는 앞서 [2.0.0](https://github.com/andreasgriffin/bitcoin-safe/releases/tag/2.0.0)(2026-06-29)에서 출시되어 QR, USB, 블루투스와 함께 "Share via Chat & Sync" 연결 유형을 중심으로 트랜잭션 서명을 재설계했습니다. 이번 주의 소식은 그 기존 기능을 처음으로 주류 Linux 청중 앞에 세우는 Flathub 패키징입니다. + +--- + +## 아직 릴리스되지 않은 변경 사항 + +### Amethyst가 암호화된 NIP-85 카드로 계정이 연락처에 별명을 붙일 수 있게 하다 + +위에서 다룬 [Concord 구현](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) 외에도, Amethyst는 지난 한 주 동안 54개의 다른 PR을 병합했습니다. 그중 대표작은 [PR #3548](https://github.com/vitorpamplona/amethyst/pull/3548)로, 계정이 다른 사용자에 대한 자체 kind 30382 [NIP-85](/ko/topics/nip-85/) 연락처 카드를 게시함으로써 그 사용자에게 별명을 붙일 수 있게 합니다. 별명, 비공개 메모, 그리고 모든 커스텀 [NIP-30](/ko/topics/nip-30/) 이모지 단축코드 매핑은 카드의 [NIP-44](/ko/topics/nip-44/) 암호화 콘텐츠 안에 있어 서명 계정만 읽을 수 있으며, 카드는 로그인 시 계정의 확장된 outbox relay 집합을 통해 동기화되고 이후 점진적으로 동기화됩니다. 피드, 채팅, 멘션은 공개 표시 이름 대신 별명을 렌더링하며, 프로필 페이지의 사용자 실명 위에 탭 가능한 별명 카드를 표시합니다. + +### Zap Cooking이 My Kitchen 3단계를 출시하고 NDK 풀 정족수 버그를 수정하다 + +[Zap Cooking](https://github.com/zapcooking/frontend)은 Nostr 기반 레시피 공유 및 요리 커뮤니티 앱입니다. "My Kitchen" 식사 계획 기능을 이어가는 43개의 PR을 병합하여, 이번 단계에서 장보기 목록 생성, 레시피 선택기, 주간 계획 그리드를 도입했습니다. 같은 변경 세트는 relay 읽기가 정족수의 relay가 이미 응답한 지점을 지나서까지 대기하게 만들 수 있던 [NDK](https://github.com/nostr-dev-kit/ndk)(Nostr Development Kit) 연결 풀 정족수 준비 버그를 수정합니다. + +### Kehto가 relay 탐색 전에 outbox 읽기를 스트리밍하다 + +[Kehto](https://github.com/kehto/web)는 [NIP-5D](/ko/topics/nip-5d/) Nostr 애플릿, 즉 "napplet"을 위한 초기 웹 기반 런타임입니다. 26개의 PR을 병합했습니다. [PR #193](https://github.com/kehto/web/pull/193)은 이전에 어떤 relay라도 열기 전에 [NIP-65](/ko/topics/nip-65/) relay 목록 로딩이 끝나기를 기다리던 outbox 읽기를 수정하는데, 이 때문에 끝내 해결되지 않는 relay 목록 로드가 이벤트 전달과 쿼리 타임아웃 모두를 막을 수 있었습니다. 이 수정은 검증된 relay 힌트를 즉시 열고 쓰기 relay가 발견되는 대로 결과를 스트리밍합니다. 두 번째 변경([PR #196](https://github.com/kehto/web/pull/196))은 프로젝트의 신원 감사 페이지를 Napplet 플랫폼의 수명 주기 계약인 NAP-SHELL과 정렬하며, 이번 주 `napplet/web` 릴리스 곳곳에서 보이는 같은 프로토콜 정렬 작업의 일부입니다. + +### Wired와 TAO가 NIP-57 크리에이터 수익 분배를 추가하다 + +[Wired](https://github.com/smolgrrr/Wired)와 [TAO](https://github.com/smolgrrr/TAO)는 Nostr 기반의 표현의 자유에 초점을 맞춘 쌍둥이 소셜 클라이언트로, 같은 PR 목록을 공유합니다. 둘 다 [PR #121](https://github.com/smolgrrr/Wired/pull/121)을 병합했는데, 이는 게시물로 보낸 zap이 원래 게시자를 넘어 기여자들에게 자동으로 분할될 수 있도록 [NIP-57](/ko/topics/nip-57/) 크리에이터 수익 분배를 구현합니다. 이는 이 쌍이 proof-of-work 신호를 21비트로 높인 작업을 릴리스되지 않은 작업으로 다룬 #30의 보도에서 이어집니다. + +### Conduit Mono가 일회성 게스트 체크아웃을 중심으로 판매자 주문함을 재구축하다 + +[Conduit Mono](https://github.com/Conduit-BTC/conduit-mono)는 [NIP-99](/ko/topics/nip-99/) 클래시파이드 리스팅에 인접한 마켓플레이스 프로토콜입니다. [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174)는 브라우저가 생성한 일회성 키를 사용한 게스트 체크아웃을 추가합니다. 게스트는 그 일회용 키로 암호화된 주문과 지불 보고서를 판매자에게 보내고, 판매자는 전화나 이메일로 대역 외에서 후속 조치를 하므로 구매자는 결코 지속적인 수신함 신원이 필요하지 않습니다. [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175)는 판매자 주문함을 단일 공유 주문 상태 모델을 중심으로 재구축하여, 구매자와 판매자 역할을 분리하고 물리적 또는 혼합 주문이 배송됨 상태로 넘어가기 전에 추적 코드와 배송사를 요구합니다. 이 프로젝트의 체크아웃 흐름은 [NIP-17](/ko/topics/nip-17/) 비공개 메시지, [NIP-44](/ko/topics/nip-44/) 암호화, [NIP-59](/ko/topics/nip-59/) gift wrap 위에 구축됩니다. 이번 주의 [NIP Deep Dive](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension)는 바로 이 주문 상태 문제가 향하는 [Gamma Markets](/ko/topics/gamma-markets/) 규약을 다룹니다. + +### Buzz가 kind 39002를 중심으로 채널 생성자 프로비저닝을 강화하다 + +[Buzz](https://github.com/block/buzz)는 AI 에이전트와 인간을 Nostr 위에서 연결하는 집단지성 통신 플랫폼입니다. 지난 한 주 동안 240개의 PR을 병합하며, kind 44200 에이전트 턴 메트릭을 다룬 #30의 보도에서 이어지는 relay 계층 강화 흐름을 계속했습니다. 이번 주의 수정([PR #1830](https://github.com/block/buzz/pull/1830))은 kind 39002 채널 프로비저닝 로직이 실행되기 전에 채널의 생성자를 구성원으로 취급하여, 설정 중 생성자 자신의 채널이 그를 거부할 수 있던 경쟁 조건을 막습니다. + +### Nostr Docs가 다중 계정과 QR 페어링을 갖춘 NIP-49 서명자를 채택하다 + +[Nostr Docs](https://github.com/formstr-hq/nostr-docs)는 Nostr 네이티브 협업 문서 애플리케이션입니다. 5개의 PR을 병합했으며, 주목할 만한 것([PR #50](https://github.com/formstr-hq/nostr-docs/pull/50))은 다중 계정 전환과 QR 페어링을 갖춘 완전한 [NIP-49](/ko/topics/nip-49/) 인증을 위해 `@formstr/signer` 패키지를 채택하여, 앞선 자체 서명 경로를 대체합니다. + +### 그 외 출시 + +지난 한 주 동안 여러 추적 프로젝트에 자체 문단을 둘 만큼의 새로운 표면은 아니지만 소소한 서명자 상호 운용 및 신뢰성 수정이 안착했습니다: Nostr 기반 GitHub 대안을 위한 명령줄 클라이언트인 [ngit-cli](https://github.com/DanConwayDev/ngit-cli)는 `ngit init`이 nsec를 반복해서 요청하는 대신 실행 가능한 설정 안내를 제공하도록 하는 [v2.6.3](https://github.com/DanConwayDev/ngit-cli/releases/tag/v2.6.3)을 출시했고; Nostr 기반의 비공개 암호화 노트 및 파일 앱인 [Manent](https://github.com/dtonon/manent)는 Amber가 16진수 pubkey를 반환할 때 깨지던 Android 서명자 로그인을 수정하고 bunker 로그인 스크롤을 개선한 [v1.4.1](https://github.com/dtonon/manent/releases/tag/v1.4.1)을 출시했으며; 슬림하고 Google 서비스가 없는 Nostr 클라이언트인 [NoorNote](https://github.com/77elements/noornote)는 놓치던 Nostrord 그룹 알림을 수정하고 자기 게시 알림 토글을 추가한 [v1.2.8](https://github.com/77elements/noornote/releases/tag/v1.2.8)을 출시했고; AI 에이전트와 인간을 위한 신뢰 인식 Nostr MCP 서버인 [Bray](https://github.com/forgesworn/bray)는 [NIP-46](/ko/topics/nip-46/) bunker 연결 시 클라이언트 이름 메타데이터를 전송하는 [v1.34.0](https://github.com/forgesworn/bray/releases/tag/v1.34.0)을 출시했으며; Nostr 웹 클라이언트인 [Lumilumi](https://github.com/TsukemonoGit/lumilumi)는 오프라인 대체를 위해 [NIP-65](/ko/topics/nip-65/) relay 목록을 로컬 저장소에 캐시하고; Nostr 기반의 로컬 도시 및 커뮤니티 앱인 [Earthly](https://github.com/moogmodular/earthly)는 [NIP-50](/ko/topics/nip-50/) 지리 검색을 추가하며; 무료 오픈소스 Lightning 지갑 및 계정 시스템인 [lnbits](https://github.com/lnbits/lnbits)는 대체로 Lightning에 초점을 맞춘 릴리스 안에서 `send_nostr_dm`이 논블로킹으로 게시하도록 하는 [PR #3925](https://github.com/lnbits/lnbits/pull/3925)를 출시했습니다. + +--- + +## 새로 추적 및 발견됨 + +### OpenDiscord v1.0.1이 Nostr 기반 Discord 스타일 클라이언트로 출시되다 + +[OpenDiscord](https://github.com/sofia-gros/open-discord)는 역할 기반 권한과 WebRTC/SFU 음성 로비를 갖춘 Nostr 기반 Discord 스타일 서버-채널 클라이언트입니다. [v1.0.1](https://github.com/sofia-gros/open-discord/releases/tag/v1.0.1)은 프로젝트의 첫 태그 설치 프로그램 릴리스입니다. + +### Auditable Voting v0.1.140이 주최자, 투표자, 감사 프록시 역할을 정렬하다 + +[Auditable Voting](https://github.com/tidley/auditable-voting)은 클라이언트 전용 Nostr 투표 셸입니다. [v0.1.140](https://github.com/tidley/auditable-voting/releases/tag/v0.1.140)은 주최자, 투표자, 감사 프록시 역할을 주최자가 서명한 정확한 공개 설문지 정의 이벤트와 정렬하여, 감사 프록시가 오래된 생성 계정이나 다른 워커 또는 주최자로부터 유지된 상태에 대해 작동할 수 있던 격차를 막습니다. + +### Cambium v0.3.2가 Heartwood와 짝을 이루어 키 없는 NIP-55 서명자가 되다 + +[Cambium](https://github.com/forgesworn/cambium)은 이번 호의 Discovery 선정작입니다. 자체 개인 키 자료를 전혀 보관하지 않고, 모든 서명 요청을 [NIP-46](/ko/topics/nip-46/)을 통해 동반 Heartwood 하드웨어 서명자로 프록시하는 Android [NIP-55](/ko/topics/nip-55/) 서명자입니다. 이 프로젝트는 추적 프로젝트 Bray와 `forgesworn` GitHub 조직을 공유하며, Heartwood 자체는 Cambium의 Android 측이 이제 대화하는 relay-to-serial 서명 브리지를 출시한 것으로 #30에서 다뤄졌습니다. [v0.3.2](https://github.com/forgesworn/cambium)는 선택된 신원이 앱의 기존 바인딩과 다를 때 실시간으로 경고하도록 승인 시트를 다듬고, 활동 로그 쓰기를 단일 논블로킹 대기열로 옮깁니다. + +### 이번 주 함께 출시됨: echoes, Dispatch, Linky + +이번 주 언급할 만한 세 가지 출시가 더 있습니다. [echoes](https://github.com/Lwb89dev/echoes)는 Nostr를 통해 비공개로 동기화되는 오프라인 우선, 종단 간 암호화 노트 앱입니다. [Dispatch](https://github.com/freecritter/dispatch)는 모든 저장이 [NIP-44](/ko/topics/nip-44/)로 암호화되고 연결 불가능한 전용 키 아래 Nostr를 통해 백업되는 로컬 우선 여행 정리 도구이며, 그 [v0.3.0](https://github.com/freecritter/dispatch) 릴리스는 앱이 사용자의 개인 키를 직접 다루지 않도록 Amber [NIP-55](/ko/topics/nip-55/) 로그인을 추가합니다. [Linky](https://github.com/hynek-jina/linky)는 Nostr 연락처와 DM을 Lightning 및 Cashu 결제와 하나의 프로그레시브 웹 앱에 결합합니다. + +--- + +## 프로토콜 작업 및 NIP 업데이트 + +지난 한 주 동안 [NIPs 저장소](https://github.com/nostr-protocol/nips)에 병합된 PR은 없습니다. 여섯 개의 제안이 열렸습니다. + +### 열림: kind:10011 즐겨찾기 팔로우 세트 + +fiatjaf의 [PR #2413](https://github.com/nostr-protocol/nips/pull/2413)은 kind:10011 즐겨찾기 팔로우 세트를 추가합니다. 이는 kind:10012(즐겨찾기 relay 세트)가 kind:30002 relay 세트를 가리키는 `a` tag를 담는 기존 패턴을 반영하여, 같은 즐겨찾기 메커니즘을 kind:30000 팔로우 세트로 확장함으로써 클라이언트가 자신의 연락처 목록을 대체하지 않고도 큐레이션된 팔로우 목록을 북마크할 수 있게 합니다. + +### 열림: NIP-4E를 확장하는 비공개 암호화 드라이브 + +Form* 팀의 [PR #2412](https://github.com/nostr-protocol/nips/pull/2412)는 `d` 식별자 tag와 `t` 하위 유형 tag로 구별되는 일반 Metadata 이벤트 kind 34578을 제안하며, 그 위에 구축된 비공개 암호화 파일 시스템도 함께 제안하는데, 이는 Form* 자체의 아직 실험적인 Form* Drive 클라이언트에 이미 구현되어 있습니다. 파일 레코드는 `t=files`인 Metadata 이벤트입니다. 파일 blob은 [Blossom](/ko/topics/blossom/) 서버에 있고 암호화된 인덱스만 relay에 있으며, 각 파일 청크는 [NIP-44](/ko/topics/nip-44/) v2 HKDF 파생 암호화가 적용된 자체 일회성 키페어를 갖습니다. 동반 Decoupled Encryption Key 이벤트는 모든 파일의 메타데이터가 그것에 대해 복호화되는 하나의 드라이브 전역 대칭 키를 보관하며, [NIP-4E](/ko/topics/nip-4e/), 즉 fiatjaf의 아직 열려 있는 저장소 추상화 초안([PR #1647](https://github.com/nostr-protocol/nips/pull/1647), 2024년 12월부터 열림) 위에 명시적으로 구축됩니다. + +그 단일 드라이브 전역 키는 유출된 키 하나가 드라이브 내 단 하나가 아니라 모든 파일의 메타데이터를 노출한다는 것을 의미합니다. 파일별 일회성 키페어는 청크 암호화 키만 다르게 할 뿐 메타데이터 복호화 키는 바꾸지 않기 때문입니다. 아직은 오래된 이벤트가 손실될 수 있음을 경고하는 새 Metadata 이벤트를 게시하는 것 외에 순환이나 폐기 경로가 존재하지 않습니다. 더 좁은 두 번째 제안은 같은 기반 NIP-4E 아이디어에 다른 각도에서 접근합니다: fiatjaf의 [PR #2361](https://github.com/nostr-protocol/nips/pull/2361)은 [NIP-17](/ko/topics/nip-17/) 메시징에 한정하여 신원 키와 암호화 키를 분리하며, 6월 1일부터 열려 있습니다. 두 PR 모두 병합되지 않아, 이는 설계 공간의 활발하고 논쟁적인 영역으로 남아 있습니다. Form*는 Drive 클라이언트가 실험적이며 곧 업데이트가 있을 것이라고 말합니다. + +### 열림: NIP-DA 권한 기반 비공개 데이터 공유 + +JAFairweather의 [PR #2411](https://github.com/nostr-protocol/nips/pull/2411)은 범위 지정 데이터 승인을 통한 권한 기반 비공개 데이터 공유를 위한 새 NIP-DA 초안입니다. 각 사용자는 범위별로 하나의 암호화된 권위 있는 레코드를 relay에 보관하며, 접근은 그 범위의 대칭 키를 [NIP-59](/ko/topics/nip-59/) gift wrap 안에서 비공개로 전달함으로써 부여되므로, relay는 암호문만 저장하고 누가 누구에게 접근을 부여했는지 결코 알지 못합니다. 폐기는 단순히 키 순환일 뿐이며, 모든 소비자의 사본을 다시 쓸 필요가 없습니다. 저자는 이를 [NIP-17](/ko/topics/nip-17/) DM(데이터 스냅샷은 담을 수 있지만 실시간 업데이트나 폐기는 담을 수 없음)과 NIP-51 비공개 목록(키 자료를 담지 않음)과는 구별되는 것으로 위치시키며, 두 개의 독립 구현, 즉 JavaScript 참조 라이브러리와 go-nostr 상의 Go CLI를 인용하고, relay.damus.io, nos.lol, relay.primal.net에 대해 교차 테스트했습니다. + +### 열림: 스티커 팩 kind 10031과 30031 + +vincenzopalazzo의 [PR #2410](https://github.com/nostr-protocol/nips/pull/2410)은 Event Kinds 표에 kind 30031(주소 지정 가능 스티커 팩)과 kind 10031(사용자의 스티커 팩 목록)을 등록하며, [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec)가 이번 주 출시하는 "Sonar Stickers" 형식으로 명세됩니다. 이 kind들은 클라이언트가 스티커 팩을 이모지 세트로 착각할 수 없도록 [NIP-30](/ko/topics/nip-30/) 커스텀 이모지 kind 30030과 10030보다 의도적으로 한 칸 위에 자리합니다. 스티커 이미지 바이트는 HTTPS [Blossom](/ko/topics/blossom/) 호환 서버에 있으며, 전송된 스티커 참조는 평문 해시를 담아 편집된 주소 지정 가능 팩이 오래된 메시지에 이미 전송된 스티커의 모습을 조용히 바꿀 수 없도록 합니다. 동반 PR은 별도의 `registry-of-kinds` 프로젝트에 같은 kind들을 등록합니다. + +### 열림: kind:9010과 kind:39005를 통한 NIP-29 메시지 고정 + +Anderson-Juhasc의 [PR #2379](https://github.com/nostr-protocol/nips/pull/2379)는 [NIP-29](/ko/topics/nip-29/) relay 기반 그룹에 메시지 고정을 추가합니다: kind:9010 `update-pin-list`는 고정된 이벤트 전체 목록을 표시 순서대로 `e` tag로 담는 모더레이션 이벤트여서, 단일 이벤트가 고정, 고정 해제, 재정렬, 또는 고정 집합 비우기를 할 수 있으며, kind:39005는 최신 승인된 목록을 노출하는 relay가 생성한 미러입니다. 이 설계는 검토 피드백 이후 [PR #1163](https://github.com/nostr-protocol/nips/pull/1163)의 앞선 추가/제거 쌍 방식을 대체하며, 9009와 39003이 그 이후 `create-invite`와 그룹 역할에 의해 사용되었기 때문에 kind 번호 9010/39005를 택합니다. Anderson-Juhasc는 또한 [Nostrord](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages)를 유지 관리하며, 그 [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0)이 바로 이번 주에 출시됩니다. + +### 열림: NIP-66 relay 탐색 재구조화 + +VincenzoImp의 [PR #2241](https://github.com/nostr-protocol/nips/pull/2241)은 [NIP-66](/ko/topics/nip-66/) relay 탐색의 상당한 재구조화입니다. 느슨한 "Other tags include" 산문을 구조화된 Indexed Tags 섹션으로 대체하고, relay 탐색 필터링을 위해 NIP-11의 `attributes` 필드를 반영하는 `W` tag를 추가하며, 표준화된 네임스페이스(`ISO-639-1`, `ISO-3166-1`, `IANA-asn`, `IANA-tz`, `nip66.label.city`)를 사용하는 `l` 라벨 tag를 추가하고, RTT, SSL/TLS, 네트워크, 지리, DNS, HTTP tag를 새로운 Check Types 표와 함께 전용 섹션으로 정리합니다. 또한 필드 이름이 잘못되고 `kind`가 빠지고 검증 유형 이름이 유효하지 않던 깨진 예제 이벤트를 수정하고, [issue #2171](https://github.com/nostr-protocol/nips/issues/2171)을 종료합니다. 추가된 모든 tag가 선택 사항이므로 모든 변경은 하위 호환성을 유지합니다. + +--- + +## NIP Deep Dive: NIP-99와 Gamma Markets 커머스 확장 + +원래의 Nostr 마켓플레이스 명세인 [NIP-15](/ko/topics/nip-15/)는 현시점에서 레거시입니다. 이는 판매자 부스(kind 30017)와 그 아래 정리된 상품(kind 30018)을 모델링했으며, 한때 그 위에서 돌아가던 클라이언트들, 그중 Shopstr는 이후 활성 명세인 [NIP-99](/ko/topics/nip-99/) 클래시파이드 리스팅으로 옮겨갔습니다. NIP-99 자체는 활성 리스팅용 kind 30402 또는 초안용 kind 30403인 단일 주소 지정 가능 이벤트이며, 먼저 부스를 만들 필요가 없습니다. 리스팅 이후의 모든 것은 정의하지 않은 채 둡니다: 배송비, 주문 상태, 영수증, 리뷰, 그리고 여러 리스팅을 하나의 상점 아래 묶는 방법 등, 정확히 NIP-15에서 결코 이전되지 않은 부분들입니다. [Gamma Markets](/ko/topics/gamma-markets/)는 그 공백을 채우며, 오늘날 이해할 가치가 있는 현대적인 커머스 계층입니다. + +### NIP-99가 남겨둔 공백 + +NIP-99 리스팅의 `content` 필드는 Markdown 설명을 담고, `price`와 `location`은 이벤트에 직접 자리하며, `t` tag는 일반 해시태그 콘텐츠처럼 검색 가능하게 만듭니다. pubkey, kind, `d` tag 튜플로 주소 지정이 가능하기 때문에, 판매자는 같은 `d` tag로 새 버전을 게시함으로써 리스팅을 제자리에서 편집합니다: + +```json +{ + "kind": 30402, + "content": "Vintage mechanical keyboard, Cherry MX Blue switches, barely used.", + "tags": [ + ["d", "keyboard-mx-blue-01"], + ["title", "Vintage Mechanical Keyboard"], + ["summary", "Cherry MX Blue, barely used"], + ["published_at", "1752537600"], + ["location", "NYC"], + ["price", "100", "USD"], + ["t", "electronics"] + ] +} +``` + +그것이 명세 전부입니다: 서명되고 갱신 가능한 클래시파이드 광고. 일회성 클래시파이드를 넘어 실제 전자상거래를 위해 NIP-99를 구현하는 모든 클라이언트는 배송, 주문 메시지, 리뷰에 대한 자체 비공개 규약을 발명하게 되었습니다. 두 NIP-99 클라이언트가 각각 리스팅을 올바르게 렌더링하면서도 서로 간에 결제를 완료할 공유된 방법이 여전히 없을 수 있었습니다. + +### Gamma Markets: NIP-99가 남겨둔 것을 표준화하기 + +Gamma Markets는 Nostr 마켓플레이스 개발자들의 작업 그룹, 즉 Shopstr, Cypher, Plebeian Market, Conduit Market을 만든 팀들이 NIP-99의 기존 kind 30402 이벤트 위에 구축한 공유 전자상거래 규약 집합에 붙인 이름입니다. 이 명세는 [PR #1784](https://github.com/nostr-protocol/nips/pull/1784)를 통해 표준 NIP-99 문서에서 링크되며, 자체 저장소 [GammaMarkets/market-spec](https://github.com/GammaMarkets/market-spec)에서 유지 관리됩니다. + +Gamma Markets는 두 개의 독립적인 리스팅 인접 kind를 추가합니다. Kind 30405는 여러 리스팅을 하나의 상품 컬렉션으로 묶으며, 명시적 `a` tag로 각각을 참조합니다: + +```json +{ + "kind": 30405, + "content": "Summer sale picks", + "tags": [ + ["d", "summer-picks"], + ["title", "Summer Sale"], + ["a", "30402::keyboard-mx-blue-01"], + ["shipping_option", "30406::standard-regional"] + ] +} +``` + +Kind 30406은 국가별 가격 책정과 선택적 무게 또는 거리 기반 비용 규칙을 갖춘 배송 옵션을 정의합니다: + +```json +{ + "kind": 30406, + "content": "Standard Regional Shipping", + "tags": [ + ["d", "standard-regional"], + ["title", "Standard Shipping"], + ["price", "5.99", "USD"], + ["country", "US"], + ["service", "standard"], + ["duration", "24", "72", "H"], + ["weight-max", "30", "kg"] + ] +} +``` + +주문 생성, 결제 요청, 상태 및 배송 업데이트, 결제 영수증은 모두 전송 방식을 다시 감싸는 대신, 역할별로 세 가지 kind로 나뉜 일반 [NIP-17](/ko/topics/nip-17/) gift-wrap된 비공개 메시지로 이동합니다: kind 14는 자유 형식의 구매자/판매자 통신을 담고, kind 16은 모든 주문 상태 전환을 담으며(`type` tag 1부터 4가 주문 생성, 결제 요청, 상태 업데이트, 배송 업데이트를 표시), kind 17은 구매자의 결제 영수증을 담습니다. 주문 생성 메시지는 gift-wrapping 전에 이렇게 생겼습니다: + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +완료된 구매를 평가하는 것은 별도의 주소 지정 가능 kind 31555이며, 리뷰하는 리스팅을 다시 가리킵니다: + +```json +{ + "kind": 31555, + "content": "Arrived fast, exactly as described.", + "tags": [ + ["d", "a:30402::keyboard-mx-blue-01"], + ["rating", "1", "thumb"], + ["rating", "1.0", "quality"], + ["rating", "0.9", "delivery"] + ] +} +``` + +주문 메시지를 NIP-17 위에 태우는 것은 Gamma Markets 체크아웃이 맞춤형 주문 메시지 kind 대신, 클라이언트가 이미 DM용으로 제공하는 것과 동일한 비공개 메시지 전송 방식을 사용한다는 것을 의미합니다. + +이 명세의 핵심 설계 선택은 아무것도 계단식으로 상속되지 않는다는 것입니다. 컬렉션에 속한 리스팅은 컬렉션의 배송 옵션이나 설명을 자동으로 상속하는 대신 `a` tag로 명시적으로 참조하며, 리스팅이 사용하는 배송 옵션도 같은 명시적 방식으로 참조됩니다. 이는 상품이 상위 부스가 정의한 통화와 배송 표를 조용히 상속하던 NIP-15의 부스 모델을 의도적으로 뒤집은 것입니다. 절충은 모든 리스팅에서 더 명시적인 태깅을 요구하는 대신, 먼저 상위 객체를 해석할 필요 없이 리스팅의 전체 구성을 이벤트 자체에서 항상 읽을 수 있다는 것입니다. + +### 이것이 실제로 나타나는 곳 + +이번 주 [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) 작업은 Gamma Markets가 표준화하는 것과 같은 주문 메시지 영역에 자리합니다: [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174)의 일회성 키 게스트 체크아웃과 [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175)의 판매자 주문함 재구축은 둘 다 Gamma Markets의 kind 14, 16, 17 메시지가 형식화하는 구매자/판매자 주문 상태 문제를 해결합니다. Conduit Mono는 그 kind들을 직접 채택하지 않고 그것들과 나란히 자체 주문 상태 모델을 운영합니다. 명세를 저술한 네 프로젝트 중 하나인 Shopstr도 지난 한 주 동안 자체 커머스 배관을 계속 움직였습니다: [PR #568](https://github.com/shopstr-eng/shopstr/pull/568)은 중복된 NIP-17 gift-wrap 로직을 공유 모듈로 추출하고, [PR #567](https://github.com/shopstr-eng/shopstr/pull/567)은 [NIP-98](/ko/topics/nip-98/) HTTP 인증 파서를 완전한 테스트 커버리지로 가져오는데, 이는 Gamma Markets 주문 흐름이 구매자와 판매자에게 안전하게 도달하기 위해 의존하는 바로 그 메시징 및 인증 계층에 대한 유지 관리입니다. + +NIP-15는 부스와 상품을 표준화한 뒤 결제, 배송, 리뷰, 주문 상태를 애플리케이션 문제로 남겨둠으로써 상점 역할을 잃었습니다. Gamma Markets는 새 메시징 계층을 발명하는 대신 Nostr의 기존 DM 스택인 NIP-17 위에 구축하여, NIP-99의 단일 리스팅 형태를 건드리지 않고 그 빠진 표면의 대부분을 채웁니다. + +--- + +이번 주는 여기까지입니다. 무언가를 만들고 있거나 공유할 소식이 있으신가요? NIP-17 DM으로 연락하시거나 Nostr에서 저희를 찾아주세요. diff --git a/content/ko/topics/concord-protocol.md b/content/ko/topics/concord-protocol.md new file mode 100644 index 0000000..e7a221e --- /dev/null +++ b/content/ko/topics/concord-protocol.md @@ -0,0 +1,61 @@ +--- +title: "Concord Protocol" +date: 2026-07-15 +draft: false +translationOf: /en/topics/concord-protocol.md +translationDate: 2026-07-15 +categories: + - Protocol + - Messaging +--- + +Concord는 Nostr 위에서 종단 간 암호화 커뮤니티와 채널을 위한 개방형 MIT 라이선스 프로토콜로, [CORD-01부터 CORD-07까지의 명세](https://github.com/concord-protocol/concord)로 정의됩니다. [Vector](https://github.com/VectorPrivacy/Vector)는 v0.4.0부터 그룹 채팅 기능의 기본 전송 방식으로 이를 채택하며 자체 릴리스 노트에서 "우리의 맞춤형 메시징 프로토콜"이라고 불렀지만, 명세 자체는 Vector와 별도로 공개되어 있고 이미 독립 구현들을 갖추고 있습니다. + +## 작동 방식 + +Concord는 Discord 스타일의 커뮤니티 서버가 보통 하는 일을 아무도 신뢰할 필요가 없는 조각들로 나눕니다: relay는 회전하는 라벨로 주소가 지정된 암호화된 blob만 저장하고, 방의 키를 보유하는 것이 누군가를 구성원으로 만들며, 역할, 추방, 차단에 대한 권한은 서버가 집행하도록 신뢰하는 대신 모든 클라이언트가 로컬에서 검증하는 소유자 신원에 뿌리를 둔 서명된 명부입니다. 모든 지속 이벤트는 동일한 3계층 봉투를 탑니다: 평면 자체의 파생 스트림 키로 서명된 kind 1059 wrap이 저자의 실제 키로 서명된 seal을 담고, 그 seal은 기능 이벤트를 담은 서명되지 않은 rumor를 담습니다. 채팅 메시지 rumor는 평범한 kind 9 이벤트입니다: + +```json +{ + "kind": 9, + "pubkey": "", + "content": "Hey chat!", + "tags": [ + ["channel", ""], + ["epoch", "0"] + ] +} +``` + +제어, 채팅, 방명록 트래픽은 각각 자체 [NIP-59](/ko/topics/nip-59/) gift-wrap된 평면을 가지므로, 셋 모두를 보유한 relay라도 방 키 없이는 제어 메시지와 채팅 메시지, 방명록 항목을 구별할 수 없습니다. 명세는 일곱 개의 CORD 문서로 나뉩니다: 비공개 스트림(01), 커뮤니티와 멤버십(02), 채널(03), 역할(04), 초대(05), 제거된 구성원의 접근을 끊기 위한 재키잉과 재설립(06), 그리고 블라인드 토큰 브로커를 통한 오디오/비디오(07). 멤버십 자체에는 서버 측 목록이 없습니다: 평면을 복호화할 수 있는 자가 구성원이며, 누군가를 진짜로 제거한다는 것은 테이블에서 행을 삭제하는 대신 커뮤니티를 새 키 에포크로 굴려 남은 사람에게만 넘겨준다는 뜻입니다. + +## Marmot과의 차이점 + +Concord와 [Marmot](/ko/topics/marmot/)은 서로 다른 그룹 형태를 위한 서로 다른 암호화로 Nostr 상의 암호화 그룹 메시징을 해결하며, Concord 프로젝트 자체의 비교는 그 분기점을 명확히 밝힙니다: Marmot은 순방향 비밀성과 침해 후 보안을 위해 Nostr 위에 [MLS](/ko/topics/mls/)를 얹으며, 기기별 키 패키지와 전체 그룹을 일사불란하게 전진시키는 순서 있는 커밋을 사용합니다. 그것은 강력한 보장을 얻는 대신 멤버십 변경에 따라 커지는 비용을 치르며, 가입과 탈퇴가 드문 작고 위험도 높은 그룹에 잘 맞습니다. Concord는 대신 모든 구성원에게 동일한 방 키를 주고 커밋마다 래칫하는 대신 제거 시 방 전체를 재키잉하여, MLS의 암호화 보장 일부를 내주는 대가로 커뮤니티가 수백 또는 수천 명의 캐주얼하고 이탈이 잦은 구성원으로 성장해도 저렴하게 유지되는 모델을 얻는데, 이것이 Discord 스타일 커뮤니티가 실제로 취하는 형태입니다. + +## Vector가 전환한 이유 + +Vector 자체 [v0.4.0 릴리스 노트](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0)는 Concord를 그룹 채팅을 위한 "우리의 맞춤형 메시징 프로토콜"이라고만 설명하며 그 이유를 직접 밝히지는 않습니다. 그럼에도 Concord 자체 공개 근거와의 부합은 분명합니다: Vector 같은 클라이언트의 그룹 채팅은 정확히 크고 개방적이며 멤버십이 자주 바뀌는 경우로, Marmot의 기기별 MLS 상태가 더 비싼 경로가 되는 지점이며, Concord의 비동기적이고 언제든 접을 수 있는 설계는 바로 그 경우를 위해 만들어졌습니다. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0)는 그룹 채팅에서 Marmot을 은퇴시키고 Concord를 채택했으며, 기존 Marmot 그룹 기록은 전환 과정에서 이전되지 않았습니다. [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1)은 4일 뒤 프라이버시 및 안정성 개선과 함께 "Concord v2"를 출시했습니다. 같은 주에 [Amethyst가 자체 클린룸 방식의 와이어 호환 Concord 구현을 병합했으며](https://github.com/vitorpamplona/amethyst/pull/3566), Soapbox의 Discord 스타일 클라이언트 [Armada](https://gitlab.com/soapbox-pub/armada)는 이미 참조 구현으로서 같은 명세 위에 Communities 기능을 구축하고 있습니다. 세 개의 독립 클라이언트가 며칠 사이에 하나의 개방형 명세로 수렴하는 것은 실제 클라이언트 간 상호 운용으로 가는 빠른 경로이며, 나머지 Nostr 그룹 채팅 클라이언트 중 얼마나 많은 수가 대신 Marmot에 머무는지와 대비해 추적할 가치가 있습니다. + +## 구현 + +- [Vector](https://github.com/VectorPrivacy/Vector) - 단일 바이너리, 프라이버시 우선 Nostr 메신저; 첫 Concord 출시 클라이언트, v0.4.0에서 +- [Armada](https://gitlab.com/soapbox-pub/armada) (Soapbox) - Discord 스타일 커뮤니티 클라이언트; 참조 구현, 백엔드는 별도의 `armada-relay` 저장소에 +- [Amethyst](https://github.com/vitorpamplona/amethyst) - 기능이 풍부한 Android 및 멀티플랫폼 Nostr 클라이언트; Armada와 와이어 호환되는 클린룸 재구현 ([PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566)) + +--- + +**주요 출처:** +- [Concord 프로토콜 명세 (CORD-01부터 CORD-07)](https://github.com/concord-protocol/concord) +- [Vector v0.4.0 릴리스 노트](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) +- [Vector v0.4.1 릴리스 노트](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) +- [Amethyst PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) + +**언급된 곳:** +- [Newsletter #31: Vector v0.4.0가 그룹 채팅을 Marmot에서 Concord로 옮기고, 며칠 뒤 Amethyst가 자체 Concord 클라이언트를 출시하다](/ko/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) +- [Newsletter #31: Amethyst가 종단 간 암호화 커뮤니티를 위한 클린룸 Concord 구현을 출시하다](/ko/newsletters/2026-07-15-newsletter/#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) + +**함께 보기:** +- [Marmot Protocol](/ko/topics/marmot/) +- [MLS (Message Layer Security)](/ko/topics/mls/) +- [NIP-46: Nostr Connect](/ko/topics/nip-46/) diff --git a/content/ko/topics/gamma-markets.md b/content/ko/topics/gamma-markets.md new file mode 100644 index 0000000..3bb7118 --- /dev/null +++ b/content/ko/topics/gamma-markets.md @@ -0,0 +1,69 @@ +--- +title: "Gamma Markets" +date: 2026-07-15 +draft: false +translationOf: /en/topics/gamma-markets.md +translationDate: 2026-07-15 +categories: + - Commerce + - Marketplace + - Protocol +--- + +Gamma Markets는 [NIP-99](/ko/topics/nip-99/) 클래시파이드 리스팅 위에 직접 구축된 전자상거래 규약 집합으로, Nostr 마켓플레이스 개발자 작업 그룹, 즉 Shopstr, Cypher, Plebeian Market, Conduit Market을 만든 팀들이 협력하여 개발했습니다. 이는 NIP-99 자체가 정의하지 않은 채 두는 배송, 주문 흐름, 컬렉션, 리뷰 규약을 채워 넣습니다. + +## 작동 방식 + +Gamma Markets는 NIP-99의 기존 kind `30402` 리스팅 이벤트를 중심으로 다섯 개의 이벤트 kind를 추가하며, 그 이벤트의 형태는 바꾸지 않습니다: + +- **Kind 30405** - 상품 컬렉션, `a` tag를 통해 여러 리스팅을 함께 묶음 +- **Kind 30406** - 배송 옵션, 국가별 가격 책정과 선택적 무게 또는 거리 기반 비용 규칙 포함 +- **Kind 16** - 주문 메시지: 생성(type 1), 결제 요청(type 2), 상태 업데이트(type 3), 배송 업데이트(type 4) +- **Kind 14** - 일반 구매자/판매자 통신 +- **Kind 17** - 결제 영수증 +- **Kind 31555** - 상품 리뷰, 특정 판매자 pubkey와 리스팅 `d` tag로 주소 지정됨 + +판매자의 결제 선호는 kind `0` 프로필 메타데이터의 `payment_preference` tag를 통해 선언되며, 클라이언트는 [NIP-89](/ko/topics/nip-89/) 애플리케이션 추천을 통해 호환 앱을 발견합니다. 주문 통신은 자체 새 암호화 방식 없이 [NIP-17](/ko/topics/nip-17/) 비공개 메시지 위에 구축됩니다. + +이 명세의 결정적 설계 선택은 아무것도 계단식으로 상속되지 않는다는 것입니다: 컬렉션에 속하거나 배송 옵션을 사용하는 리스팅은 상위의 설정을 자동으로 상속하는 대신 `a` tag로 명시적으로 참조합니다. 이는 상품이 부스의 통화와 배송 표를 조용히 상속하던 더 오래된 [NIP-15](/ko/topics/nip-15/) 부스 모델에서 의도적으로 벗어난 것입니다. + +### 예시: 주문 생성 (kind 16, type 1) + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +## 왜 중요한가 + +NIP-99 단독으로는 리스팅 자체, 즉 서명되고 주소 지정 가능한 클래시파이드 광고만 표준화합니다. Gamma Markets 이전에는 NIP-99 위에 실제 전자상거래를 구축하는 모든 클라이언트가 배송, 체크아웃, 리뷰에 대한 자체 비공개 규약을 발명했으며, 이는 NIP-99 호환 클라이언트 두 개가 각각 리스팅을 올바르게 렌더링하면서도 서로 간에 주문을 완료할 공유된 방법이 없다는 것을 의미했습니다. Gamma Markets는 NIP-99 리스팅 형식 자체를 건드리지 않고 그 공백을 메우므로, 기존 NIP-99 리스팅은 수정 없이 유효하게 유지됩니다. + +## 구현 + +- [Shopstr](https://github.com/shopstr-eng/shopstr) - Nostr 마켓플레이스, 명세를 저술한 네 프로젝트 중 하나 +- [Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) - 같은 설계 공간에서 자체 주문 상태 및 체크아웃 흐름을 구축하는 마켓플레이스 프로토콜 + +--- + +**주요 출처:** +- [Gamma Markets 명세 저장소](https://github.com/GammaMarkets/market-spec) +- [NIP-99 전자상거래 사용 사례 확장, PR #1784](https://github.com/nostr-protocol/nips/pull/1784) - 표준 NIP-99 문서에서 Gamma Markets 명세로의 병합된 링크 + +**언급된 곳:** +- [Newsletter #31: NIP Deep Dive: NIP-99와 Gamma Markets 커머스 확장](/ko/newsletters/2026-07-15-newsletter/#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) + +**함께 보기:** +- [NIP-99: Classified Listings](/ko/topics/nip-99/) +- [NIP-15: Nostr Marketplace](/ko/topics/nip-15/) +- [NIP-17: Private Direct Messages](/ko/topics/nip-17/) diff --git a/content/ko/topics/nip-4e.md b/content/ko/topics/nip-4e.md new file mode 100644 index 0000000..2afd847 --- /dev/null +++ b/content/ko/topics/nip-4e.md @@ -0,0 +1,46 @@ +--- +title: "NIP-4E: 암호화와 신원의 분리" +date: 2026-07-15 +draft: false +translationOf: /en/topics/nip-4e.md +translationDate: 2026-07-15 +categories: + - NIP + - Protocol + - Encryption +--- + +NIP-4E는 fiatjaf가 제안한 공개 초안으로, 모든 기기가 사용자의 주요 Nostr 신원 키를 보유하지 않고도 사용자 자신의 기기들 사이에서 비공개 데이터를 공유하기 위한 것입니다. 아직 병합되지 않았으며 `draft`/`optional` 제안으로 남아 있습니다. + +## 이 제안이 다루는 문제 + +NIP-51 목록과 NIP-60 Cashu 지갑을 포함한 많은 기존 NIP는 나중에 어느 기기에서든 다시 읽을 수 있도록 신원 키를 사용해 사용자가 자신에게 데이터를 암호화합니다. 이 방식은 신원 키에 직접 접근할 수 없을 때 무너집니다. 예를 들어 원격 서명자가 FROST 임계값 조각, MuSig2, 또는 호스팅된 보안 엔클레이브로 보호되는 경우, 암호화와 복호화를 할 때마다 그 서명자와 왕복 통신이 필요해집니다. 또한 서명 키가 원격 bunker에 있으면 오프라인 암호화가 불가능해집니다. + +## 작동 방식 + +NIP-4E는 기기별 "클라이언트 키"를 사용자의 신원 키가 아닌 공유 "암호화 키"로부터 분리합니다: + +1. 사용자가 처음 설정하는 클라이언트가 무작위 암호화 키쌍을 생성하고, 그 공개 절반을 사용자의 신원 키로 서명한 `kind:10044` 이벤트에 공표합니다. +2. 해당 사용자를 위해 데이터를 암호화하거나 복호화하려는 다른 클라이언트는 신원 키가 아니라 공표된 암호화 키에 대해 Diffie-Hellman 공유 비밀을 계산합니다. +3. 두 번째 기기가 새 클라이언트를 설치하면, 그 클라이언트는 자체 로컬 "클라이언트 키"를 생성하고 첫 번째 클라이언트에게 암호화 키를 공유해 달라고 요청하는 `kind:4454` 공표를 (역시 사용자의 신원 키로 서명해) 게시합니다. +4. 원래 클라이언트가 새 `kind:4454` 공표를 감지하면, [NIP-44](/ko/topics/nip-44/)를 사용해 공유 암호화 키를 새 클라이언트의 키로 암호화한 뒤 게시하여 새 클라이언트가 이후 복호화해 사용할 수 있게 합니다. + +그 결과, 클라이언트가 공유 암호화 키를 로컬에 보유한 뒤로는 암호화와 복호화에 신원 키 서명자에게 물어볼 필요가 전혀 없으며, 신원에는 원격 서명자 구성(FROST, MuSig2, 호스팅된 엔클레이브)을 쓰면서도 일반 암호화는 빠르게 유지되고 오프라인에서도 작동합니다. + +## 왜 중요한가 + +NIP-4E는 매번의 암호화/복호화 호출마다 원격 서명자에 의존하지 않고 드라이브 전체 또는 계정 전체 대칭 키가 필요한 다른 제안들의 토대로 인용됩니다. 여기에는 비공개 암호화 드라이브 제안([PR #2412](https://github.com/nostr-protocol/nips/pull/2412))과 같은 아이디어를 NIP-17에 한정해 좁힌 버전([PR #2361](https://github.com/nostr-protocol/nips/pull/2361))이 포함됩니다. 둘 다 NIP-4E 자체와 함께 열린 상태로 남아 있어, 이 영역은 완성된 구성 요소라기보다 활발하고 아직 정리되지 않은 프로토콜 영역입니다. + +--- + +**주요 출처:** +- [NIP-4E 초안, PR #1647](https://github.com/nostr-protocol/nips/pull/1647) + +**언급된 곳:** +- [Newsletter #31: 공개: 비공개 암호화 드라이브가 NIP-4E를 확장하다](/ko/newsletters/2026-07-15-newsletter/#open-private-encrypted-drive-extends-nip-4e) + +**함께 보기:** +- [NIP-44: Encrypted Payloads](/ko/topics/nip-44/) +- [NIP-17: Private Direct Messages](/ko/topics/nip-17/) +- [NIP-46: Nostr Connect](/ko/topics/nip-46/) +- [FROST](/ko/topics/frost/) diff --git a/content/ko/topics/proofmode.md b/content/ko/topics/proofmode.md new file mode 100644 index 0000000..49b9d5b --- /dev/null +++ b/content/ko/topics/proofmode.md @@ -0,0 +1,36 @@ +--- +title: "ProofMode" +date: 2026-07-15 +draft: false +translationOf: /en/topics/proofmode.md +translationDate: 2026-07-15 +categories: + - Media + - Provenance +--- + +[ProofMode](https://proofmode.org/)은 Guardian Project, WITNESS, Okthanks가 만든 오픈소스 미디어 출처 확인 도구 모음으로, 촬영 시점에 사진과 영상에 검증 가능한 진위 및 관리 연속성 데이터를 붙입니다. Nostr 전용은 아니며, ProofMode 데이터를 실어 나르는 Nostr 클라이언트는 새로운 프로토콜 계층이 아니라 기존의 외부 표준을 통합하는 것입니다. + +## 작동 방식 + +ProofMode의 Capture 구성 요소는 촬영 중에 출처 메타데이터를 미디어 파일에 직접 삽입하며, Content Authenticity Initiative(CAI), Content Credentials(CR), C2PA가 사용하는 동일한 상호 운용 표준을 지원합니다. 별도의 Verify 구성 요소는 오디오, 이미지, 비디오 파일을 검사해 해당 메타데이터에서 AI 생성이나 이후 편집의 흔적을 확인하고, Preserve 구성 요소는 장기 보관을 위해 기반 증명 데이터를 탈중앙 웹에 중복 저장합니다. Develop SDK는 앱이 출처 형식을 직접 만들지 않고도 촬영과 검증을 통합할 수 있게 합니다. + +## 왜 중요한가 + +Nostr 비디오 또는 이미지 클라이언트에게 ProofMode 데이터를 실어 나른다는 것은, 게시 클라이언트나 relay를 신뢰의 근거로 삼지 않고도 시청자가 어떤 미디어가 주장대로 촬영되었는지, 그리고 그 이후 조용히 변경되지 않았는지를 외부의 플랫폼 독립적인 방법으로 확인할 수 있다는 뜻입니다. 그 구분이 가장 크게 작용하는 곳은 다운로드되거나 재인코딩된 클립 사본입니다: 다운로드와 클라이언트가 적용하는 워터마크를 견디고 남는 출처 데이터가 있어야, 파일이 그것을 만든 앱을 떠난 뒤에도 그 증명을 여전히 확인할 수 있습니다. + +## 구현 + +- [Divine](https://github.com/divinevideo/divine-mobile) - 짧은 영상 Nostr 클라이언트; 워터마크가 적용된 클립 다운로드에서도 ProofMode 출처 데이터를 유지 + +--- + +**주요 출처:** +- [ProofMode](https://proofmode.org/) + +**언급된 곳:** +- [Newsletter #17](/ko/newsletters/2026-04-29-newsletter/) +- [Newsletter #31: Divine Mobile 1.0.16이 더 깊어진 비디오 편집기, 저장 데이터 암호화, ProofMode 출처 정보를 출시하다](/ko/newsletters/2026-07-15-newsletter/#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) + +**함께 보기:** +- [Blossom](/ko/topics/blossom/) From f1616bf023e42730e47dfcb88a0a507164e4bbb9 Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Thu, 16 Jul 2026 08:38:02 +0000 Subject: [PATCH 08/10] Add Dutch translation for Newsletter #31 and topic pages --- .../nl/newsletters/2026-07-15-newsletter.md | 300 ++++++++++++++++++ content/nl/topics/concord-protocol.md | 61 ++++ content/nl/topics/gamma-markets.md | 69 ++++ content/nl/topics/nip-4e.md | 46 +++ content/nl/topics/proofmode.md | 36 +++ 5 files changed, 512 insertions(+) create mode 100644 content/nl/newsletters/2026-07-15-newsletter.md create mode 100644 content/nl/topics/concord-protocol.md create mode 100644 content/nl/topics/gamma-markets.md create mode 100644 content/nl/topics/nip-4e.md create mode 100644 content/nl/topics/proofmode.md diff --git a/content/nl/newsletters/2026-07-15-newsletter.md b/content/nl/newsletters/2026-07-15-newsletter.md new file mode 100644 index 0000000..392e1e7 --- /dev/null +++ b/content/nl/newsletters/2026-07-15-newsletter.md @@ -0,0 +1,300 @@ +--- +title: "Nostr Compass #31" +date: 2026-07-15 +publishDate: 2026-07-15 +draft: false +type: newsletters +translationOf: /en/newsletters/2026-07-15-newsletter.md +translationDate: 2026-07-15 +description: "Vector v0.4.0 zet Marmot opzij voor groepschats ten gunste van het open Concord-protocol en levert dagen later Concord v2, Amethyst voegt zijn eigen clean-room Concord-implementatie samen, Sonar splitst zich af van Bitchat met een cross-platform alpha en een stickerpakket-specificatie, Divine Mobile 1.0.16 levert versleuteling in rust en ProofMode-herkomst, Bitchat 1.7.0 voegt live push-to-talk-spraak toe, en MDK v0.9.4 begrenst het inloggen met een externe ondertekenaar." +--- + +Welkom terug bij Nostr Compass, uw wekelijkse gids voor Nostr. + +**Deze week:** [Vector v0.4.0](#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) zet [Marmot](/nl/topics/marmot/) opzij als standaardtransport voor Groepschats ten gunste van [Concord](/nl/topics/concord-protocol/), een open, MIT-gelicentieerd gemeenschapsprotocol dat ook door Armada van Soapbox wordt gebruikt, en levert vier dagen later Concord v2 met een slash-commandokiezer voor bots, een zelfvernietigingstimer en NIP-58-badges. [Amethyst voegt zijn eigen clean-room, wire-compatibele Concord-implementatie samen](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) in dezelfde week. [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) splitst zich af van Bitchat met een cross-platform alpha en is de geciteerde specificatiebron voor het stickerpakket-kindsvoorstel van deze week. [Divine Mobile 1.0.16](#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) levert een diepere video-editor, versleuteling in rust en ProofMode-herkomst die het downloaden van clips met watermerk overleeft. [Bitchat v1.7.0](#bitchat-v170-adds-live-push-to-talk-voice-for-dms-and-the-public-mesh) voegt live push-to-talk-spraak toe voor DMs en ondertekende push-to-talk op het publieke mesh. [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) begrenst het inloggen met een externe ondertekenaar en voegt persistentie van concepten toe, waarmee het zijn hardeningsronde voortzet in dezelfde week dat Vector afstand neemt van de specificatie voor groepschat. + +Getagde releases brengen [n_cord v1.1](#n_cord-v11-adds-nsec-bunker-support) met ondersteuning voor NSEC Bunker, [cdk v0.17.3](#cdk-v0173-adds-nip-47-wallet-service-support-across-cdk-cdk-nwc-and-cdk-ffi) met NIP-47 wallet-serviceondersteuning in cdk, cdk-nwc en cdk-ffi, [Coop Mobile v0.2.4](#coop-mobile-v024-improves-nostr-connect-and-adds-ncryptsec1-import) met verbeteringen aan Nostr Connect en ncryptsec1-import, [Nmail v0.14.0](#nmail-v0140-ships-on-macos-with-scheduled-send-and-push-notifications) dat op macOS landt met gepland verzenden, [Nostrord v2.2.0](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages) met een DM-hoofdschakelaar, [Nostr WoT 0.3.86](#nostr-wot-0386-hardens-key-backups-and-signing-prompts) dat sleutelback-ups verstevigt naar het NIP-49-formaat, [Keep Android v1.1.8](#keep-android-v118-adds-first-run-frost-onboarding) met FROST-onboarding bij eerste gebruik, [Noscall v0.6.0](#noscall-v060-adds-a-cashu-wallet-and-relay-based-push-notifications) met een Cashu-wallet en relay-gebaseerde pushmeldingen, [Kubo](#kubo-ships-tablet-mode-and-group-chat-photos) met tabletmodus en foto's in groepschats, en [Nostr Codex Phone v0.2.9](#nostr-codex-phone-v029-adds-gitdiffread-file-helper-requests) met hulpverzoeken voor git, diff en het lezen van bestanden. + +Aan de niet-uitgebrachte kant laat [Amethyst](#amethyst-lets-accounts-nickname-contacts-with-encrypted-nip-85-cards) accounts contacten een bijnaam geven met versleutelde NIP-85-kaarten verspreid over 54 samengevoegde PRs, levert [Zap Cooking](#zap-cooking-ships-my-kitchen-phase-3-and-fixes-an-ndk-pool-quorum-bug) fase 3 van My Kitchen en repareert een quorumfout in de NDK-pool, streamt [Kehto](#kehto-streams-outbox-reads-before-relay-discovery) outbox-leesbewerkingen voordat relaydetectie klaar is, voegen [Wired en TAO](#wired-and-tao-add-nip-57-creator-revenue-sharing) NIP-57 inkomstendeling voor makers toe, herbouwt [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) zijn bestellingeninbox voor verkopers rond efemeer afrekenen als gast, verstevigt [Buzz](#buzz-hardens-channel-creator-provisioning-around-kind-39002) de provisioning van kanaalmakers over 240 samengevoegde PRs, en adopteert [Nostr Docs](#nostr-docs-adopts-a-nip-49-signer-with-multi-account-and-qr-pairing) een NIP-49-ondertekenaar met meerdere accounts en QR-koppeling. Deze week nieuw gevolgd: [OpenDiscord v1.0.1](#opendiscord-v101-launches-as-a-discord-style-client-on-nostr), [Auditable Voting v0.1.140](#auditable-voting-v01140-aligns-organiser-voter-and-audit-proxy-roles), en de Discovery-keuze [Cambium v0.3.2](#cambium-v032-pairs-with-heartwood-as-a-keyless-nip-55-signer), een sleutelloze NIP-55-ondertekenaar die doorschakelt naar een Heartwood-hardwaremetgezel. + +De NIPs-repository voegt de afgelopen week niets samen en opent zes voorstellen: [kind:10011 favoriete volgsets](#open-kind10011-favorite-follow-sets), een [privé versleutelde schijf die NIP-4E uitbreidt](#open-private-encrypted-drive-extends-nip-4e), [NIP-DA privé gegevensdeling met permissies](#open-nip-da-permissioned-private-data-sharing), [stickerpakket-kinds 10031 en 30031](#open-sticker-pack-kinds-10031-and-30031), [NIP-29 berichten vastzetten](#open-nip-29-message-pinning-with-kind9010-and-kind39005), en een [herstructurering van NIP-66 relaydetectie](#open-nip-66-relay-discovery-restructure). De Deep Dive behandelt [NIP-99 en de Gamma Markets-handelsuitbreiding](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension). + +--- + +## Hoofdverhalen + +### Vector v0.4.0 verplaatst Groepschats van Marmot naar Concord, en Amethyst levert dagen later zijn eigen Concord-client + +[Vector](https://github.com/VectorPrivacy/Vector) is een Nostr-messenger gebouwd rond een privacy-eerst client met één binary voor DMs en groepschats. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) herschrijft de berichtenengine van de app tot een gedeelde `vector-core`-bibliotheek en zet in dezelfde release [Marmot](/nl/topics/marmot/) (MLS-over-Nostr) opzij als standaardtransport voor Groepschats ten gunste van [Concord](/nl/topics/concord-protocol/), een end-to-end versleuteld gemeenschapsprotocol; bestaande Marmot-groepsgeschiedenis gaat niet mee, en de release notes zeggen gebruikers hun Marmot-groepsgegevens te back-uppen voor het upgraden. Vectors eigen release notes beschrijven Concord als "ons eigen berichtenprotocol", maar de onderliggende [CORD-01 tot en met CORD-07-specificaties](https://github.com/concord-protocol/concord) worden apart gepubliceerd, zijn MIT-gelicentieerd en al buiten Vector geïmplementeerd: Soapbox' Discord-achtige client [Armada](https://gitlab.com/soapbox-pub/armada) bouwt zijn Communities-functie op dezelfde Concord-specificatie, en één dag later [voegde Amethyst zijn eigen clean-room, wire-compatibele Concord-implementatie samen](https://github.com/vitorpamplona/amethyst/pull/3566), hieronder volledig behandeld. Dezelfde Vector-release voegt optionele Tor-routering voor al het verkeer toe, [NIP-46](/nl/topics/nip-46/) inloggen met een externe ondertekenaar via QR of geplakte bunker-URI, meerdere accounts met een schakelaar in de app, en aangepaste emojipakketten die tussen clients worden gedeeld. Het verwijderen van een bericht haalt het bij beide kanten weg in DMs en groepschats, en Vector houdt bewust de efemere ondertekeningssleutel in plaats van de standaard [NIP-17](/nl/topics/nip-17/)-verwijderstroom te volgen, een door privacy ingegeven afwijking die het project expliciet benoemt in de release notes. Vier dagen later levert [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) **Concord v2**, beschreven als een release met grote privacy- en stabiliteitsverbeteringen voor Communities terwijl bestaande blijven werken, samen met een Discord-achtige slash-commandokiezer voor bots met getypeerde parameters, een zelfvernietigingstimer per chat, en een NIP-58-badgesysteem voor bugjagers. De stap weg van Marmot voor groepschat komt in dezelfde week waarin [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) hieronder blijft investeren in de specificatie. + +### Amethyst levert een clean-room Concord-implementatie voor end-to-end versleutelde gemeenschappen + +[Amethyst](https://github.com/vitorpamplona/amethyst) is een functierijke Nostr-client voor Android en meerdere platforms. [PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) voegt een volledige implementatie van [Concord](/nl/topics/concord-protocol/) (CORD-01 tot en met CORD-07) toe die serverloze, end-to-end versleutelde gemeenschappen dekt: gift-wrapped controle-, chat- en gastenboekvlakken over gewone relay's, handhaving van rollen en bans geworteld bij de eigenaar die elke client lokaal verifieert in plaats van een server te vertrouwen, en herkeying om verwijderde leden af te snijden. Protocol- en cryptocode zit in `quartz/`, state- en viewmodels in `commons/`, en schermen en navigatie in `amethyst/` voor Android, met dunne CLI-werkwoorden onder `cli/`; er is nog geen desktop-UI, omdat de gedeelde logica in `quartz`/`commons` zit zodat Desktop die later kan overnemen. De implementatie is clean-room: gebouwd vanuit de publieke CORD-specificaties en waargenomen wire-constanten, onder Amethysts eigen MIT-licentie, los van Armada's AGPL-3.0-codebase. Armada's eigen testvectorwaarden zijn overgezet naar de unittests van Quartz om te bevestigen dat de twee clients daadwerkelijk op de wire interopereren, waarmee Concord binnen enkele dagen drie onafhankelijke implementaties heeft: Vector die als eerste leverde, Armada als referentieclient van Soapbox, en nu Amethysts bouw vanaf de specificatie. + +### Sonar splitst zich af van Bitchat met een cross-platform alpha en een stickerpakket-specificatie + +[Sonar](https://sonarprivacy.xyz/) is een messenger en wallet met Bluetooth-mesh plus Nostr, gegroeid uit Bitchat, met Marmot-groeps-DMs die interopereren met White Noise. De code staat op [hedwig-corp/bitchat-to-sonar](https://github.com/hedwig-corp/bitchat-to-sonar). [v0.1-alpha.7](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.7) voegt begrensde transcript-vensters in Signal-stijl toe zodat openen en scrollen local-first blijven presteren, synchroniseert de staat van detectie in de buurt tussen peers, en repareert Blossom-media-uploads die faalden op content-type- en HTTP-statusafhandeling; de voorafgaande [alpha.6](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.6) liet live Marmot-events leeglopen voor sneller vernieuwen van de chat en dichtte gaten in functiepariteit tussen Android en iOS bij gesprekken, berichten, wallet en push. Sonar is ook de geciteerde specificatiebron voor [PR #2410](#open-sticker-pack-kinds-10031-and-30031), die stickerpakket-eventkinds registreert onder de eigen "Sonar Stickers"-specificatie van het project, wat deze lancering een directe link geeft naar het protocolwerk van deze week. + +### Divine Mobile 1.0.16 levert een diepere video-editor, versleuteling in rust en ProofMode-herkomst + +[Divine](https://github.com/divinevideo/divine-mobile) is een client voor korte video's gebouwd op Nostr met feedcuratie via Web-of-Trust. [v1.0.16](https://github.com/divinevideo/divine-mobile/releases/tag/1.0.16), de eerste getagde release sinds #30, voegt clipovergangen, achterwaarts afspelen, een voice-overrecorder en beatmarkeringen op de tijdlijn toe aan de video-editor, samen met een feedafstemming waarmee een gebruiker kan swipen om aanbevelingen direct bij te stellen in plaats van ze over te laten aan ondoorzichtige engagementsignalen. De release zet ook versleuteling in rust aan voor lokale gegevens, voegt uploads op de achtergrond toe die overleven wanneer de app wordt onderbroken, en draagt [ProofMode](/nl/topics/proofmode/)-herkomstgegevens mee wanneer een clip met watermerk wordt gedownload zodat de verklaring van menselijke makelij niet onderweg verdwijnt. Divine levert ook nieuwe bescherming voor accounts van onder de 16 en breidt de lokalisatie uit naar 17 talen en 284 vertaalde teksten. + +### Bitchat v1.7.0 voegt live push-to-talk-spraak toe voor DMs en het publieke mesh + +[Bitchat](https://github.com/permissionlesstech/bitchat) is een chat-app met Bluetooth-mesh en een opt-in gateway naar Nostr-relay's. [v1.7.0](https://github.com/permissionlesstech/bitchat/releases/tag/v1.7.0), uitgebracht op de avond dat #30 verscheen, voegt live push-to-talk-spraak toe in [PR #1403](https://github.com/permissionlesstech/bitchat/pull/1403) die audio streamt zolang de zender de knop ingedrukt houdt en terugvalt op een spraakbericht als de stream wegvalt, plus ondertekende push-to-talk op het publieke mesh in [PR #1406](https://github.com/permissionlesstech/bitchat/pull/1406) zodat live spraakflarden op het gedeelde meshkanaal authenticatie van de zender meedragen. De release herstelt ook peer-ID-rotatie door de link opnieuw te binden bij een geverifieerde her-aankondiging, waarbij dezelfde peer onder zijn nieuwe ID wordt herkend ([PR #1401](https://github.com/permissionlesstech/bitchat/pull/1401)), en directe berichten naar een momenteel onbereikbare peer komen nu in de wachtrij met store-and-forward-bezorging in plaats van meteen te falen ([PR #1415](https://github.com/permissionlesstech/bitchat/pull/1415)). Dit sluit direct aan op de behandeling in #30 van het [NIP-13](/nl/topics/nip-13/) proof-of-work- en mesh-naar-Nostr-gatewaywerk in v1.6.0. + +### MDK v0.9.4 begrenst het inloggen met een externe ondertekenaar en voegt persistentie van concepten toe + +[MDK](https://github.com/marmot-protocol/mdk) is de referentie-SDK voor het [Marmot](/nl/topics/marmot/)-protocol, de MLS-over-Nostr berichtenlaag waarvan #30 behandelde dat de specificatie als geadopteerd werd gemarkeerd. [v0.9.4](https://github.com/marmot-protocol/mdk/releases/tag/v0.9.4) begrenst de adviserende directorystappen die een client doorloopt bij het inloggen met een externe ondertekenaar in [PR #793](https://github.com/marmot-protocol/mdk/pull/793), wat een onbegrensde herhaallus voorkomt wanneer een externe ondertekenaar traag is of niet reageert. Dezelfde release voegt persistentie van conceptberichten en bindingen tussen profiel en website toe in [PR #812](https://github.com/marmot-protocol/mdk/pull/812), waarmee de stapsgewijze hardeningsronde doorloopt die MDK sinds v0.9.0 uitvoert. + +--- + +## Getagde releases + +### n_cord v1.1 voegt ondersteuning voor NSEC Bunker toe + +[n_cord](https://github.com/0n4t3/n_cord) is een chatclient op Nostr geïnspireerd door Discord en IRC. [v1.1](https://github.com/0n4t3/n_cord/releases/tag/v1.1) voegt [NIP-46](/nl/topics/nip-46/) NSEC Bunker-ondersteuning toe naast een bugfix in de afhandeling van antwoorden. + +### cdk v0.17.3 voegt NIP-47 wallet-serviceondersteuning toe in cdk, cdk-nwc en cdk-ffi + +[cdk](https://github.com/cashubtc/cdk) is een Cashu-ontwikkelkit; deze release is in de meeste opzichten alleen Bitcoin/Lightning, maar [v0.17.3](https://github.com/cashubtc/cdk/releases/tag/v0.17.3) voegt [NIP-47](/nl/topics/nip-47/) (Nostr Wallet Connect) serviceondersteuning toe met een aparte NWC-servicecrate, wallet-integratie, FFI-bindings voor `cdk-ffi`, en end-to-end testdekking, waarmee Cashu-wallets gebouwd op cdk een standaard Nostr Wallet Connect-oppervlak krijgen. + +### Coop Mobile v0.2.4 verbetert Nostr Connect en voegt ncryptsec1-import toe + +[Coop Mobile](https://git.reya.su/reya/coop-mobile) is een [NIP-17](/nl/topics/nip-17/)-client voor privéberichten op mobiele platforms. [v0.2.4](https://git.reya.su/reya/coop-mobile/releases/tag/v0.2.4) verbetert de [NIP-46](/nl/topics/nip-46/) Nostr Connect-stroom, repareert een laadindicator die bij sommige verbindingen permanent bleef hangen, en voegt importondersteuning toe voor het [NIP-49](/nl/topics/nip-49/) `ncryptsec1` versleutelde sleutelformaat, samen met een herontworpen scherm voor identiteitsimport. + +### Nmail v0.14.0 landt op macOS met gepland verzenden en pushmeldingen + +[Nmail](https://github.com/nogringo/nostr-mail-client) is een mailclient gebouwd op Nostr; [v0.14.0](https://github.com/nogringo/nostr-mail-client/releases/tag/v0.14.0) brengt de app naar macOS, voegt gepland verzenden toe met een aparte Gepland-mailbox voor berichten in de wachtrij, en voegt pushmeldingen toe. De release schakelt het oplossen van Nostr-identifiers in het adresboek ook over naar NDK's [NIP-05](/nl/topics/nip-05/)-resolver in plaats van een eigen implementatie. + +### Nostrord v2.2.0 voegt een DM-hoofdschakelaar en rijkere directe berichten toe + +[Nostrord](https://github.com/nostrord/nostrord) is een [NIP-29](/nl/topics/nip-29/) relay-gebaseerde groepschatclient voor Android, iOS, web en desktop. [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) voegt een hoofdschakelaar toe om alle functies voor directe berichten in één keer uit te schakelen ([PR #175](https://github.com/nostrord/nostrord/pull/175)) en levert "rijkere directe berichten" ([PR #186](https://github.com/nostrord/nostrord/pull/186)), voortbouwend op de behandeling in #30 van de release die de relaypool samenvoegde en zombie-WebSockets detecteerde. + +### Nostr WoT 0.3.86 verstevigt sleutelback-ups en ondertekeningsprompts + +[Nostr WoT](https://github.com/nostr-wot/nostr-wot-extension) is een browserextensie die een Nostr-identiteit koppelt aan een Lightning-wallet. [v0.3.86](https://github.com/nostr-wot/nostr-wot-extension/releases/tag/v0.3.86) verplaatst versleutelde sleutelback-ups naar het standaard [NIP-49](/nl/topics/nip-49/)-formaat, laat ondertekeningsprompts het volledige event en alle tags tonen in plaats van een samenvatting, verifieert relaygegevens tegen hun handtekening, en stopt met het blootgeven van de actieve identiteit bij het wisselen van account. De extensie laat ook de ongebruikte `scripting`-browserpermissie vallen. + +### Keep Android v1.1.8 voegt FROST-onboarding bij eerste gebruik toe + +[Keep](https://github.com/privkeyio/keep-android) is een Android-ondertekenaar gebouwd op FROST-sleuteldelen met drempelwaarde. [v1.1.8](https://github.com/privkeyio/keep-android/releases/tag/v1.1.8) voegt een stroom bij eerste gebruik toe die FROST-sleuteldelen uitlegt en een nieuwe gebruiker een ondertekeningsbeleid van Handmatig, Basis of Automatisch laat kiezen voordat het eerste ondertekeningsverzoek binnenkomt, de eerste onboarding aan de Android-kant voor het drempelondertekeningsmodel van de onderliggende keep-mobile-crate. + +### Noscall v0.6.0 voegt een Cashu-wallet en relay-gebaseerde pushmeldingen toe + +[Noscall](https://github.com/sanah9/noscall) is een app voor veilige audio- en videogesprekken gebouwd op Nostr. [v0.6.0](https://github.com/sanah9/noscall/releases/tag/v0.6.0-release) voegt een Cashu-wallet per account toe met saldi over meerdere mints, verzenden en ontvangen van ecash, en Lightning betalen en ontvangen met persistentie van quotes. De release migreert Android-pushmeldingen ook weg van Firebase Cloud Messaging naar een bezorgpad via Nostr-relay's met UnifiedPush, en verbetert de betrouwbaarheid van iOS VoIP en APNs-push tijdens herhaalde inlogpogingen. + +### Kubo levert tabletmodus en foto's in groepschats + +[Kubo](https://github.com/JeroenOnNostr/kubo) is een kindveilig Nostr-videoplatform met feedcuratie via Web-of-Trust. [kubo-v2026.07.05](https://github.com/JeroenOnNostr/kubo/releases/tag/kubo-v2026.07.05) voegt een optionele rasterindeling voor tablets toe aan de kinderfeed en ondersteuning voor het bijvoegen van foto's bij groepschatberichten, plus fixes voor de aanmeldknop die op Android achter het schermtoetsenbord verdween. + +### Nostr Codex Phone v0.2.9 voegt hulpverzoeken voor git/diff/bestand lezen toe + +[Nostr Codex Phone](https://github.com/tidley/nostr-codex-phone) is een mobiel bedieningsoppervlak voor een lokale coding-assistent-worker die communiceert over versleutelde Nostr-DMs. [v0.2.9](https://github.com/tidley/nostr-codex-phone/releases/tag/v0.2.9) voegt mobiele OpenCode-toolacties toe waaronder hulpverzoeken voor git, diff, bestand lezen, status en geschiedenis, verbeteringen aan het vastzetten en doorzoeken van sessies, en een besturing om taken te stoppen, naast een versleutelde [Blossom](/nl/topics/blossom/)-uploadwrapper die in de voorafgaande v0.2.8 werd geleverd. + +### GitWorkshop v3.0.3 repareert nieuw aangekondigde refs in de repo-verkenner, en levert zijn eerste Android-build + +[GitWorkshop](https://github.com/DanConwayDev/gitworkshop) is een git-over-Nostr web-UI voor het bekijken en beoordelen van NIP-34-repository's. [v3.0.3](https://github.com/DanConwayDev/gitworkshop/releases/tag/v3.0.3) repareert de weergaven voor branches, tags, commits en codeverkenning die een ref niet konden oplossen die een repo aankondigt nadat de verkenner die al had geladen, samen met opruiming van CI-workflowtiming, direct bevestigd tegen de tag- en commitgeschiedenis. In dezelfde week publiceerde GitWorkshop zijn eerste native Android-build op [Zapstore](https://zapstore.dev), beginnend bij v3.0.0 en binnen uren op v3.0.3; de web-UI blijft de primaire interface, en het Android-pakket brengt hetzelfde bladeren door NIP-34-repository's voor het eerst naar een telefoon. + +### Bitcoin-Safe bereikt Flathub, wat de Nostr Sync & Chat-plugin voor het voetlicht brengt + +[Bitcoin-Safe](https://bitcoin-safe.org) is een Bitcoin-wallet in eigen beheer gebouwd rond werkstromen met hardware-ondertekenaars. Het project [bracht deze week een Flathub-pakket uit](https://flathub.org/apps/org.bitcoin_safe.BitcoinSafe), zijn eerste vermelding in een gangbare Linux-appstore. De Flathub-release zet Bitcoin-Safe's Sync & Chat-plugin voor een breder publiek: de plugin gebruikt [NIP-17](/nl/topics/nip-17/) directe berichten, via de eigen [bitcoin-nostr-chat](https://github.com/andreasgriffin/bitcoin-nostr-chat)-bibliotheek van het project, om wallet-labels tussen de apparaten van een gebruiker te synchroniseren en om PSBTs te versturen en te ontvangen voor multisig-medeondertekening op afstand tussen vertrouwde deelnemers. De Nostr-laag zelf verscheen eerder, in [2.0.0](https://github.com/andreasgriffin/bitcoin-safe/releases/tag/2.0.0) (2026-06-29), die het ondertekenen van transacties herontwierp rond een verbindingstype "Share via Chat & Sync" naast QR, USB en Bluetooth. Het nieuws van deze week is dat de Flathub-verpakking die bestaande functie voor het eerst voor een gangbaar Linux-publiek brengt. + +--- + +## Niet-uitgebrachte wijzigingen + +### Amethyst laat accounts contacten een bijnaam geven met versleutelde NIP-85-kaarten + +Naast de [Concord-implementatie](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) die hierboven is behandeld, voegde Amethyst de afgelopen week 54 andere PRs samen. De belangrijkste daarvan is [PR #3548](https://github.com/vitorpamplona/amethyst/pull/3548), die een account elke andere gebruiker een bijnaam laat geven door een eigen kind 30382 [NIP-85](/nl/topics/nip-85/)-contactkaart over hen te publiceren. De bijnaam, een privénotitie, en eventuele aangepaste [NIP-30](/nl/topics/nip-30/) emoji-shortcode-toewijzingen leven binnen de met [NIP-44](/nl/topics/nip-44/) versleutelde inhoud van de kaart, zodat alleen het ondertekenende account ze kan lezen, en kaarten synchroniseren via de uitgebreide outbox-relayset van het account bij het inloggen en daarna stapsgewijs. Feeds, chats en vermeldingen tonen de bijnaam in plaats van de publieke weergavenaam, met een aantikbare bijnaamkaart op de profielpagina boven de echte naam van de gebruiker. + +### Zap Cooking levert fase 3 van My Kitchen en repareert een quorumfout in de NDK-pool + +[Zap Cooking](https://github.com/zapcooking/frontend) is een app voor het delen van recepten en een kookgemeenschap gebouwd op Nostr. Het voegde 43 PRs samen die de maaltijdplanningsfunctie "My Kitchen" voortzetten, met in deze fase het genereren van boodschappenlijstjes, een receptkiezer en een weekraster voor de planner. Dezelfde reeks wijzigingen repareert een quorumgereedheidsfout in de verbindingspool van [NDK](https://github.com/nostr-dev-kit/ndk) (Nostr Development Kit) waardoor relayleesbewerkingen konden blijven wachten voorbij het punt waarop een quorum van relay's al had geantwoord. + +### Kehto streamt outbox-leesbewerkingen voor relaydetectie + +[Kehto](https://github.com/kehto/web) is een vroege webruntime voor [NIP-5D](/nl/topics/nip-5d/) Nostr-applets, oftewel "napplets". Het voegde 26 PRs samen. [PR #193](https://github.com/kehto/web/pull/193) repareert outbox-leesbewerkingen die eerder wachtten tot het laden van de [NIP-65](/nl/topics/nip-65/)-relaylijst klaar was voordat er überhaupt een relay werd geopend, zodat het laden van een relaylijst dat nooit afrondde zowel de bezorging van events als querytimeouts kon blokkeren; de fix opent gevalideerde relayhints direct en streamt resultaten naarmate schrijfrelay's worden ontdekt. Een tweede wijziging ([PR #196](https://github.com/kehto/web/pull/196)) brengt de identiteitsauditpagina van het project in lijn met NAP-SHELL, het levenscycluscontract van het Napplet-platform, onderdeel van hetzelfde protocolafstemmingswerk dat elders in de `napplet/web`-release van deze week zichtbaar is. + +### Wired en TAO voegen NIP-57 inkomstendeling voor makers toe + +[Wired](https://github.com/smolgrrr/Wired) en [TAO](https://github.com/smolgrrr/TAO) zijn tweelingclients voor sociale media met de nadruk op vrije meningsuiting, gebouwd op Nostr en met dezelfde PR-lijst; beide voegden [PR #121](https://github.com/smolgrrr/Wired/pull/121) samen, die [NIP-57](/nl/topics/nip-57/) inkomstendeling voor makers implementeert zodat zaps naar een bericht automatisch kunnen worden verdeeld onder bijdragers buiten de oorspronkelijke plaatser. Dit sluit aan op de behandeling in #30 van het duo dat zijn proof-of-work-signaal naar 21 bits bracht als niet-uitgebracht werk. + +### Conduit Mono herbouwt de bestellingeninbox voor verkopers rond efemeer afrekenen als gast + +[Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) is een marktplaatsprotocol dat grenst aan [NIP-99](/nl/topics/nip-99/)-advertenties. [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174) voegt afrekenen als gast toe met een door de browser gegenereerde efemere sleutel: de gast stuurt een versleutelde bestelling en een betalingsrapport naar de verkoper met die eenmalige sleutel, en de verkoper neemt buiten het kanaal om contact op per telefoon of e-mail, zodat de koper nooit een blijvende inbox-identiteit nodig heeft. [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175) herbouwt de bestellingeninbox voor verkopers rond één gedeeld bestelstatusmodel, scheidt de rollen van koper en verkoper, en vereist een trackingcode en vervoerder voordat een fysieke of gemengde bestelling naar verzonden kan gaan. De afrekenstroom van het project bouwt op [NIP-17](/nl/topics/nip-17/) privéberichten, [NIP-44](/nl/topics/nip-44/)-versleuteling en [NIP-59](/nl/topics/nip-59/) gift wrap. De [NIP Deep Dive](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) van deze week behandelt de [Gamma Markets](/nl/topics/gamma-markets/)-conventies waar ditzelfde bestelstatusprobleem naartoe werkt. + +### Buzz verstevigt de provisioning van kanaalmakers rond kind 39002 + +[Buzz](https://github.com/block/buzz) is een communicatieplatform als zwermgeest dat AI-agents en mensen over Nostr verbindt. Het voegde de afgelopen week 240 PRs samen, waarmee het zijn hardeningsboog in de relaylaag voortzet vanaf de behandeling in #30 van kind 44200 agent-beurtmetrieken. De fix van deze week ([PR #1830](https://github.com/block/buzz/pull/1830)) behandelt de maker van een kanaal als lid voordat de kind 39002 kanaalprovisioningslogica draait, wat een race sluit waarbij het eigen kanaal van de maker hem tijdens de opzet kon weigeren. + +### Nostr Docs adopteert een NIP-49-ondertekenaar met meerdere accounts en QR-koppeling + +[Nostr Docs](https://github.com/formstr-hq/nostr-docs) is een Nostr-native applicatie voor samenwerken aan documenten. Het voegde 5 PRs samen, waarvan de opvallende ([PR #50](https://github.com/formstr-hq/nostr-docs/pull/50)) het `@formstr/signer`-pakket adopteert voor volledige [NIP-49](/nl/topics/nip-49/)-authenticatie met wisselen tussen meerdere accounts en QR-koppeling, ter vervanging van een eerder eigen ondertekeningspad. + +### Ook geleverd + +Kleinere fixes voor ondertekenaar-interoperabiliteit en betrouwbaarheid landden de afgelopen week bij verscheidene gevolgde projecten zonder genoeg nieuw oppervlak voor een eigen alinea: [ngit-cli](https://github.com/DanConwayDev/ngit-cli), een commandoregelclient voor een op Nostr gebaseerd alternatief voor GitHub, levert [v2.6.3](https://github.com/DanConwayDev/ngit-cli/releases/tag/v2.6.3) waarmee `ngit init` bruikbare instelaanwijzingen geeft in plaats van herhaaldelijk om een nsec te vragen; [Manent](https://github.com/dtonon/manent), een privé-app voor versleutelde notities en bestanden gebouwd op Nostr, levert [v1.4.1](https://github.com/dtonon/manent/releases/tag/v1.4.1) die het inloggen met een Android-ondertekenaar repareert wanneer Amber een hex-pubkey teruggeeft en het scrollen bij bunker-login verbetert; [NoorNote](https://github.com/77elements/noornote), een slanke Nostr-client zonder Google-diensten, levert [v1.2.8](https://github.com/77elements/noornote/releases/tag/v1.2.8) die gemiste meldingen van Nostrord-groepen repareert en een schakelaar voor waarschuwingen bij eigen berichten toevoegt; [Bray](https://github.com/forgesworn/bray), een vertrouwensbewuste Nostr-MCP-server voor AI-agents en mensen, levert [v1.34.0](https://github.com/forgesworn/bray/releases/tag/v1.34.0) die metadata met de clientnaam meestuurt bij [NIP-46](/nl/topics/nip-46/) bunker-connect; [Lumilumi](https://github.com/TsukemonoGit/lumilumi), een Nostr-webclient, cachet [NIP-65](/nl/topics/nip-65/)-relaylijsten in lokale opslag als offline terugval; [Earthly](https://github.com/moogmodular/earthly), een op Nostr gebaseerde app voor lokale stad en gemeenschap, voegt [NIP-50](/nl/topics/nip-50/) geozoeken toe; en [lnbits](https://github.com/lnbits/lnbits), een gratis en opensource systeem voor Lightning-wallets en -accounts, levert [PR #3925](https://github.com/lnbits/lnbits/pull/3925) waarmee `send_nostr_dm` niet-blokkerend publiceert binnen een verder op Lightning gerichte release. + +--- + +## Nieuw gevolgd en ontdekt + +### OpenDiscord v1.0.1 lanceert als een Discord-achtige client op Nostr + +[OpenDiscord](https://github.com/sofia-gros/open-discord) is een Discord-achtige client met servers en kanalen gebouwd op Nostr met rolgebaseerde permissies en WebRTC/SFU-spraaklobby's. [v1.0.1](https://github.com/sofia-gros/open-discord/releases/tag/v1.0.1) is de eerste getagde installerrelease van het project. + +### Auditable Voting v0.1.140 stemt de rollen van organisator, kiezer en auditproxy op elkaar af + +[Auditable Voting](https://github.com/tidley/auditable-voting) is een stemschil op Nostr die volledig in de client draait. [v0.1.140](https://github.com/tidley/auditable-voting/releases/tag/v0.1.140) stemt de rollen van organisator, kiezer en auditproxy af op het exacte, door de organisator ondertekende publieke event met de vragenlijstdefinitie, wat een gat dicht waarbij een auditproxy kon handelen op verouderde gegenereerde accounts of op staat die van een andere worker of organisator was blijven staan. + +### Cambium v0.3.2 koppelt met Heartwood als een sleutelloze NIP-55-ondertekenaar + +[Cambium](https://github.com/forgesworn/cambium) is de Discovery-keuze van dit nummer: een Android [NIP-55](/nl/topics/nip-55/)-ondertekenaar die zelf geen privésleutelmateriaal bewaart en elk ondertekeningsverzoek over [NIP-46](/nl/topics/nip-46/) doorstuurt naar een bijbehorende Heartwood-hardware-ondertekenaar. Het project deelt de GitHub-organisatie `forgesworn` met het gevolgde project Bray, en Heartwood zelf kwam in #30 aan bod met de relay-naar-serieel ondertekeningsbrug waarmee de Android-kant van Cambium nu praat. [v0.3.2](https://github.com/forgesworn/cambium) polijst het goedkeuringsvenster zodat het live waarschuwt wanneer de gekozen identiteit afwijkt van de bestaande binding van de app, en verplaatst het schrijven van het activiteitenlogboek naar één niet-blokkerende wachtrij. + +### Ook gelanceerd deze week: echoes, Dispatch en Linky + +Drie andere lanceringen verdienen deze week een vermelding. [echoes](https://github.com/Lwb89dev/echoes) is een offline-first, end-to-end versleutelde notitie-app die privé synchroniseert over Nostr. [Dispatch](https://github.com/freecritter/dispatch) is een local-first reisplanner waarbij elke opslag met [NIP-44](/nl/topics/nip-44/) is versleuteld en over Nostr wordt geback-upt onder een aparte, niet-koppelbare sleutel, en de release [v0.3.0](https://github.com/freecritter/dispatch) voegt Amber [NIP-55](/nl/topics/nip-55/)-login toe zodat de app de privésleutel van de gebruiker nooit direct aanraakt. [Linky](https://github.com/hynek-jina/linky) combineert Nostr-contacten en -DMs met Lightning- en Cashu-betalingen in één progressieve webapp. + +--- + +## Protocolwerk en NIP-updates + +Er zijn de afgelopen week geen PRs samengevoegd in de [NIPs-repository](https://github.com/nostr-protocol/nips). Zes voorstellen zijn geopend. + +### Open: kind:10011 favoriete volgsets + +[PR #2413](https://github.com/nostr-protocol/nips/pull/2413), van fiatjaf, voegt kind:10011 favoriete volgsets toe. Het spiegelt het bestaande patroon waarbij kind:10012 (favoriete relaysets) `a`-tags bevat die naar kind:30002-relaysets wijzen, en breidt hetzelfde favorietenmechanisme uit naar kind:30000-volgsets zodat een client een samengestelde volglijst kan bewaren zonder zijn eigen contactenlijst te vervangen. + +### Open: privé versleutelde schijf breidt NIP-4E uit + +[PR #2412](https://github.com/nostr-protocol/nips/pull/2412), van het Form*-team, stelt een generiek Metadata-event voor, kind 34578, onderscheiden door een `d`-identifiertag en een `t`-subtypetag, samen met een privé versleuteld bestandssysteem daarbovenop dat al is geïmplementeerd in Form*'s eigen, nog experimentele Form* Drive-client. Een bestandsrecord is een Metadata-event met `t=files`: bestandsblobs staan op [Blossom](/nl/topics/blossom/)-servers terwijl alleen een versleutelde index op relay's staat, en elk bestandsdeel krijgt zijn eigen efemere sleutelpaar met [NIP-44](/nl/topics/nip-44/) v2 HKDF-afgeleide versleuteling. Een bijbehorend Decoupled Encryption Key-event bevat één symmetrische sleutel voor de hele schijf waartegen de metadata van elk bestand ontsleutelt, en het bouwt expliciet voort op [NIP-4E](/nl/topics/nip-4e/), fiatjafs nog openstaande concept voor opslagabstractie ([PR #1647](https://github.com/nostr-protocol/nips/pull/1647), open sinds december 2024). + +Die ene schijfbrede sleutel betekent dat een gelekte sleutel de metadata van elk bestand op de schijf blootlegt, niet alleen van één bestand, aangezien de efemere sleutelparen per bestand alleen de versleutelingssleutel van het deel variëren en niet de ontsleutelingssleutel van de metadata; er bestaat nog geen pad voor rotatie of intrekking behalve een nieuw Metadata-event publiceren met de waarschuwing dat oudere events verloren kunnen gaan. Een tweede, smaller voorstel reikt vanuit een andere hoek naar hetzelfde onderliggende NIP-4E-idee: [PR #2361](https://github.com/nostr-protocol/nips/pull/2361), van fiatjaf, ontkoppelt identiteits- en versleutelingssleutels specifiek binnen [NIP-17](/nl/topics/nip-17/)-berichten, open sinds 1 juni. Beide PRs zijn niet samengevoegd, waardoor dit een actieve, betwiste hoek van de ontwerpruimte blijft. Form* zegt dat de Drive-client experimenteel is en dat er binnenkort een update komt. + +### Open: NIP-DA privé gegevensdeling met permissies + +[PR #2411](https://github.com/nostr-protocol/nips/pull/2411), van JAFairweather, is een nieuw NIP-DA-concept voor privé gegevensdeling met permissies via afgebakende gegevenstoekenningen. Elke gebruiker houdt per scope één versleuteld, gezaghebbend record op relay's, en toegang wordt verleend door de symmetrische sleutel van die scope privé te bezorgen in een [NIP-59](/nl/topics/nip-59/) gift wrap, zodat relay's alleen cijfertekst opslaan en nooit te weten komen wie wie toegang gaf; een intrekking is enkel een sleutelrotatie, zonder de kopie van elke consument te hoeven herschrijven. De auteur positioneert het als onderscheiden van [NIP-17](/nl/topics/nip-17/)-DMs (die een momentopname van gegevens kunnen dragen maar geen live updates of intrekking) en van NIP-51 privélijsten (die geen sleutelmateriaal dragen), en noemt twee onafhankelijke implementaties, een JavaScript-referentiebibliotheek en een Go-CLI op go-nostr, kruislings getest tegen relay.damus.io, nos.lol en relay.primal.net. + +### Open: stickerpakket-kinds 10031 en 30031 + +[PR #2410](https://github.com/nostr-protocol/nips/pull/2410), van vincenzopalazzo, registreert kind 30031 (adresseerbare stickerpakketten) en kind 10031 (de stickerpakketlijst van een gebruiker) in de Event Kinds-tabel, gespecificeerd door het "Sonar Stickers"-formaat dat [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) deze week levert. De kinds zitten bewust één plek boven de [NIP-30](/nl/topics/nip-30/) aangepaste-emojikinds 30030 en 10030 zodat een client een stickerpakket niet kan verwarren met een emojiset; de afbeeldingsbytes van stickers staan op HTTPS [Blossom](/nl/topics/blossom/)-compatibele servers, en verwijzingen naar verzonden stickers dragen een hash in platte tekst zodat een bewerkt adresseerbaar pakket het uiterlijk van al in oude berichten verzonden stickers niet stilzwijgend kan veranderen. Een bijbehorende PR registreert dezelfde kinds in het aparte `registry-of-kinds`-project. + +### Open: NIP-29 berichten vastzetten met kind:9010 en kind:39005 + +[PR #2379](https://github.com/nostr-protocol/nips/pull/2379), van Anderson-Juhasc, voegt het vastzetten van berichten toe aan [NIP-29](/nl/topics/nip-29/) relay-gebaseerde groepen: kind:9010 `update-pin-list` is een moderatie-event dat de volledige lijst met vastgezette events als `e`-tags in weergavevolgorde draagt, zodat één event de vastgezette set kan vastzetten, losmaken, herordenen of leegmaken, en kind:39005 is een door de relay gegenereerde spiegel die de laatst geaccepteerde lijst blootgeeft. Het ontwerp vervangt een eerdere aanpak met toevoeg/verwijder-paren uit [PR #1163](https://github.com/nostr-protocol/nips/pull/1163) na feedback uit review, en kiest de kindnummers 9010/39005 omdat 9009 en 39003 inmiddels zijn opgeëist door `create-invite` en grouprollen. Anderson-Juhasc onderhoudt ook [Nostrord](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages), waarvan [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) in dezelfde week verschijnt. + +### Open: herstructurering van NIP-66 relaydetectie + +[PR #2241](https://github.com/nostr-protocol/nips/pull/2241), van VincenzoImp, is een aanzienlijke herstructurering van [NIP-66](/nl/topics/nip-66/) relaydetectie. Het vervangt het losse proza "Other tags include" door een gestructureerde sectie Indexed Tags, voegt een `W`-tag toe die het `attributes`-veld van NIP-11 spiegelt voor het filteren bij relaydetectie, voegt een `l`-labeltag toe met gestandaardiseerde naamruimten (`ISO-639-1`, `ISO-3166-1`, `IANA-asn`, `IANA-tz`, `nip66.label.city`), en ordent RTT-, SSL/TLS-, netwerk-, geografische, DNS- en HTTP-tags in eigen secties naast een nieuwe Check Types-tabel. Het repareert ook kapotte voorbeeldevents met verkeerde veldnamen, een ontbrekende `kind` en ongeldige checktypenamen, en sluit [issue #2171](https://github.com/nostr-protocol/nips/issues/2171) af. Alle wijzigingen blijven achterwaarts compatibel omdat elke toegevoegde tag optioneel is. + +--- + +## NIP Deep Dive: NIP-99 en de Gamma Markets-handelsuitbreiding + +[NIP-15](/nl/topics/nip-15/), de oorspronkelijke Nostr Marketplace-specificatie, is inmiddels verouderd: het modelleerde een verkoperskraam (kind 30017) met producten (kind 30018) daaronder, en de clients die er ooit op draaiden, Shopstr daaronder, zijn sindsdien overgestapt op [NIP-99](/nl/topics/nip-99/)-advertenties als de actieve specificatie. NIP-99 zelf is één adresseerbaar event, kind 30402 voor een actieve advertentie of kind 30403 voor een concept, zonder eerst een kraam aan te maken. Het laat alles voorbij de advertentie ongedefinieerd: verzendkosten, bestelstatus, bonnen, recensies, en een manier om meerdere advertenties onder één winkel te groeperen, precies de delen van NIP-15 die nooit zijn meegegaan. [Gamma Markets](/nl/topics/gamma-markets/) vult dat gat, en is de moderne handelslaag die vandaag de moeite van het begrijpen waard is. + +### Het gat dat NIP-99 openlaat + +Het `content`-veld van een NIP-99-advertentie draagt een Markdown-beschrijving, `price` en `location` staan direct op het event, en `t`-tags maken het doorzoekbaar als gewone hashtag-inhoud. Omdat het adresseerbaar is op de tuple van pubkey, kind en `d`-tag, bewerkt een verkoper een advertentie ter plekke door een nieuwe versie met dezelfde `d`-tag te publiceren: + +```json +{ + "kind": 30402, + "content": "Vintage mechanical keyboard, Cherry MX Blue switches, barely used.", + "tags": [ + ["d", "keyboard-mx-blue-01"], + ["title", "Vintage Mechanical Keyboard"], + ["summary", "Cherry MX Blue, barely used"], + ["published_at", "1752537600"], + ["location", "NYC"], + ["price", "100", "USD"], + ["t", "electronics"] + ] +} +``` + +Dat is de hele specificatie: een ondertekende, bijwerkbare advertentie. Elke client die NIP-99 voor echte e-commerce implementeerde, verder dan een eenmalige advertentie, eindigde met het uitvinden van eigen privéconventies voor verzending, bestelberichten en recensies. Twee NIP-99-clients konden elk een advertentie correct weergeven en toch geen gedeelde manier hebben om samen een afrekening te voltooien. + +### Gamma Markets: standaardiseren wat NIP-99 wegliet + +Gamma Markets is de naam die een werkgroep van Nostr-marktplaatsontwikkelaars, de teams achter Shopstr, Cypher, Plebeian Market en Conduit Market, gaf aan een gedeelde set e-commerceconventies bovenop het bestaande kind 30402-event van NIP-99. De specificatie is vanuit het canonieke NIP-99-document gelinkt via [PR #1784](https://github.com/nostr-protocol/nips/pull/1784) en wordt onderhouden in een eigen repository, [GammaMarkets/market-spec](https://github.com/GammaMarkets/market-spec). + +Gamma Markets voegt twee zelfstandige kinds toe die naast advertenties staan. Kind 30405 groepeert meerdere advertenties in een productcollectie en verwijst naar elk ervan met een expliciete `a`-tag: + +```json +{ + "kind": 30405, + "content": "Summer sale picks", + "tags": [ + ["d", "summer-picks"], + ["title", "Summer Sale"], + ["a", "30402::keyboard-mx-blue-01"], + ["shipping_option", "30406::standard-regional"] + ] +} +``` + +Kind 30406 definieert een verzendoptie met prijzen per land en optionele kostenregels op basis van gewicht of afstand: + +```json +{ + "kind": 30406, + "content": "Standard Regional Shipping", + "tags": [ + ["d", "standard-regional"], + ["title", "Standard Shipping"], + ["price", "5.99", "USD"], + ["country", "US"], + ["service", "standard"], + ["duration", "24", "72", "H"], + ["weight-max", "30", "kg"] + ] +} +``` + +Het aanmaken van bestellingen, betalingsverzoeken, status- en verzendupdates, en betalingsbonnen reizen allemaal als gewone [NIP-17](/nl/topics/nip-17/) gift-wrapped privéberichten, verdeeld over drie kinds naar rol en niet door het transport opnieuw in te pakken: kind 14 draagt vrije communicatie tussen koper en verkoper, kind 16 draagt elke overgang van bestelstatus (een `type`-tag van 1 tot en met 4 markeert het aanmaken van een bestelling, een betalingsverzoek, een statusupdate of een verzendupdate), en kind 17 draagt de betalingsbon van de koper. Een bericht voor het aanmaken van een bestelling ziet er zo uit voor het gift-wrappen: + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +Een afgeronde aankoop beoordelen is een aparte adresseerbare kind, 31555, die terugwijst naar de advertentie die het recenseert: + +```json +{ + "kind": 31555, + "content": "Arrived fast, exactly as described.", + "tags": [ + ["d", "a:30402::keyboard-mx-blue-01"], + ["rating", "1", "thumb"], + ["rating", "1.0", "quality"], + ["rating", "0.9", "delivery"] + ] +} +``` + +Bestelberichten op NIP-17 laten meeliften betekent dat een Gamma Markets-afrekening hetzelfde transport voor privéberichten gebruikt dat clients al voor DMs leveren, in plaats van een eigen kind voor bestelberichten. + +De centrale ontwerpkeuze van de specificatie is dat niets doorsijpelt. Een advertentie die bij een collectie hoort, verwijst er expliciet naar met een `a`-tag in plaats van automatisch de verzendopties of beschrijving van de collectie te erven, en een verzendoptie die een advertentie gebruikt, wordt op dezelfde expliciete manier aangehaald. Dat is een bewuste omkering van het kraammodel van NIP-15, waar een product stilzwijgend erfde welke valuta en verzendtabel de bovenliggende kraam definieerde. De afweging is meer expliciete tagging op elke advertentie, in ruil voor een advertentie waarvan de volledige configuratie altijd uit het event zelf leesbaar is, zonder eerst een bovenliggend object op te lossen. + +### Waar dit in de praktijk opduikt + +Het werk van [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) van deze week zit in hetzelfde bestelberichtenterrein dat Gamma Markets standaardiseert: het afrekenen als gast met efemere sleutel uit [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174) en de herbouw van de bestellingeninbox voor verkopers uit [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175) lossen allebei het bestelstatusprobleem tussen koper en verkoper op dat de kind 14-, 16- en 17-berichten van Gamma Markets formaliseren; Conduit Mono draait zijn eigen bestelstatusmodel naast die kinds, zonder ze direct over te nemen. Shopstr, een van de vier projecten die de specificatie schreven, hield de afgelopen week ook zijn eigen handelsleidingwerk in beweging: [PR #568](https://github.com/shopstr-eng/shopstr/pull/568) trekt gedupliceerde NIP-17 gift-wrap-logica uit naar een gedeelde module, en [PR #567](https://github.com/shopstr-eng/shopstr/pull/567) brengt zijn [NIP-98](/nl/topics/nip-98/) HTTP-authenticatieparser op volledige testdekking, onderhoud aan precies de berichten- en authenticatielagen waarvan een Gamma Markets-bestelstroom afhangt om koper en verkoper veilig te bereiken. + +NIP-15 verloor de winkelrol door een kraam en een product te standaardiseren en vervolgens betalingen, verzending, recensies en bestelstatus als een probleem voor de applicatie te laten. Gamma Markets vult het meeste van dat ontbrekende oppervlak zonder de vorm van de enkele advertentie van NIP-99 aan te raken, en bouwt voort op Nostrs bestaande DM-stack, NIP-17, in plaats van een nieuwe berichtenlaag uit te vinden. + +--- + +Dat was het voor deze week. Bouwt u iets of heeft u nieuws te delen? Neem contact op via een NIP-17-DM of vind ons op Nostr. diff --git a/content/nl/topics/concord-protocol.md b/content/nl/topics/concord-protocol.md new file mode 100644 index 0000000..512522f --- /dev/null +++ b/content/nl/topics/concord-protocol.md @@ -0,0 +1,61 @@ +--- +title: "Concord Protocol" +date: 2026-07-15 +draft: false +translationOf: /en/topics/concord-protocol.md +translationDate: 2026-07-15 +categories: + - Protocol + - Messaging +--- + +Concord is een open, MIT-gelicentieerd protocol voor end-to-end versleutelde gemeenschappen en kanalen op Nostr, gedefinieerd door de [CORD-01 tot en met CORD-07-specificaties](https://github.com/concord-protocol/concord). [Vector](https://github.com/VectorPrivacy/Vector) nam het vanaf v0.4.0 over als standaardtransport voor zijn Groepschat-functie en noemde het in de eigen release notes "ons eigen berichtenprotocol", maar de specificatie zelf wordt los van Vector gepubliceerd en heeft al onafhankelijke implementaties. + +## Hoe het werkt + +Concord splitst wat een Discord-achtige gemeenschapsserver normaal doet op in stukken die niemand hoeven te vertrouwen: relay's bewaren alleen versleutelde blobs geadresseerd aan roterende labels, het bezit van de sleutel van een ruimte maakt iemand lid, en het gezag over rollen, kicks en bans is een ondertekende ledenlijst geworteld in de identiteit van de eigenaar die elke client lokaal verifieert in plaats van erop te vertrouwen dat een server het handhaaft. Elk blijvend event rijdt op dezelfde envelop van drie lagen: een kind 1059 wrap ondertekend met de eigen afgeleide streamsleutel van het vlak, met daarin een seal ondertekend met de echte sleutel van de auteur, met daarin een niet-ondertekende rumor die het functionele event draagt. Een chatbericht-rumor is een gewoon kind 9-event: + +```json +{ + "kind": 9, + "pubkey": "", + "content": "Hey chat!", + "tags": [ + ["channel", ""], + ["epoch", "0"] + ] +} +``` + +Controle-, chat- en gastenboekverkeer krijgen elk hun eigen [NIP-59](/nl/topics/nip-59/) gift-wrapped vlak, zodat een relay die alle drie bewaart zonder de ruimtesleutel nog steeds een controlebericht niet kan onderscheiden van een chatbericht of een gastenboekvermelding. De specificatie is verdeeld over zeven CORD-documenten: privéstreams (01), gemeenschappen en lidmaatschap (02), kanalen (03), rollen (04), uitnodigingen (05), herkeying en heroprichting om verwijderde leden af te snijden (06), en audio/video via een blinde tokenmakelaar (07). Lidmaatschap zelf heeft geen lijst aan de serverkant: wie het vlak kan ontsleutelen is lid, en iemand echt verwijderen betekent de gemeenschap doorrollen naar een nieuw sleutel-epoch en die alleen aan de overgeblevenen geven, in plaats van een rij uit een tabel te schrappen. + +## Hoe het verschilt van Marmot + +Concord en [Marmot](/nl/topics/marmot/) lossen versleutelde groepsberichten op Nostr op met verschillende cryptografie voor verschillende groepsvormen, en de vergelijking van het Concord-project zelf is expliciet over die scheiding: Marmot legt [MLS](/nl/topics/mls/) boven op Nostr voor forward secrecy en post-compromise security, met sleutelpakketten per apparaat en geordende commits die de hele groep in de pas vooruit brengen. Dat levert sterke garanties op, tegen een prijs die meeschaalt met wijzigingen in het lidmaatschap, en past goed bij kleine groepen met hoge inzet waar toetreden en vertrekken zeldzaam zijn. Concord geeft in plaats daarvan elk lid dezelfde ruimtesleutel en herkeyt bij verwijdering de hele ruimte in plaats van per commit te ratelen, waarmee het een deel van de cryptografische garanties van MLS inruilt voor een model dat goedkoop blijft naarmate een gemeenschap groeit naar honderden of duizenden losse leden met veel verloop, de vorm die Discord-achtige gemeenschappen in de praktijk aannemen. + +## Waarom Vector overstapte + +Vectors eigen [v0.4.0 release notes](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) beschrijven Concord alleen als "ons eigen berichtenprotocol" voor Groepschats, zonder de redenering direct te noemen. De aansluiting op Concords eigen gepubliceerde motivatie is hoe dan ook duidelijk: Groepschats in een client als Vector zijn precies het grote, open geval met vaak veranderend lidmaatschap waar Marmots MLS-staat per apparaat het duurdere pad wordt, en Concords asynchrone ontwerp dat op elk moment kan worden dichtgevouwen is juist voor dat geval gebouwd. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) zette Marmot opzij voor Groepschats ten gunste van Concord, en bestaande Marmot-groepsgeschiedenis ging bij de overstap niet mee. [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) leverde vier dagen later "Concord v2" met privacy- en stabiliteitsverbeteringen. In dezelfde week [voegde Amethyst zijn eigen clean-room, wire-compatibele Concord-implementatie samen](https://github.com/vitorpamplona/amethyst/pull/3566), en Soapbox' Discord-achtige client [Armada](https://gitlab.com/soapbox-pub/armada) bouwt zijn Communities-functie al op dezelfde specificatie als referentie-implementatie. Drie onafhankelijke clients die binnen enkele dagen op één open specificatie samenkomen is een snelle route naar echte interoperabiliteit tussen clients, de moeite waard om te volgen tegenover hoeveel van de overige Nostr-groepschatclients juist bij Marmot blijven. + +## Implementaties + +- [Vector](https://github.com/VectorPrivacy/Vector) - privacy-eerst Nostr-messenger met één binary; eerste client die Concord leverde, in v0.4.0 +- [Armada](https://gitlab.com/soapbox-pub/armada) (Soapbox) - Discord-achtige gemeenschapsclient; referentie-implementatie, backend in de aparte `armada-relay`-repo +- [Amethyst](https://github.com/vitorpamplona/amethyst) - functierijke Nostr-client voor Android en meerdere platforms; clean-room herimplementatie die wire-compatibel is met Armada ([PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566)) + +--- + +**Primaire bronnen:** +- [Concord-protocolspecificaties (CORD-01 tot CORD-07)](https://github.com/concord-protocol/concord) +- [Vector v0.4.0 release notes](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) +- [Vector v0.4.1 release notes](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) +- [Amethyst PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) + +**Genoemd in:** +- [Newsletter #31: Vector v0.4.0 verplaatst Groepschats van Marmot naar Concord, en Amethyst levert dagen later zijn eigen Concord-client](/nl/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) +- [Newsletter #31: Amethyst levert een clean-room Concord-implementatie voor end-to-end versleutelde gemeenschappen](/nl/newsletters/2026-07-15-newsletter/#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) + +**Zie ook:** +- [Marmot Protocol](/nl/topics/marmot/) +- [MLS (Message Layer Security)](/nl/topics/mls/) +- [NIP-46: Nostr Connect](/nl/topics/nip-46/) diff --git a/content/nl/topics/gamma-markets.md b/content/nl/topics/gamma-markets.md new file mode 100644 index 0000000..664ca50 --- /dev/null +++ b/content/nl/topics/gamma-markets.md @@ -0,0 +1,69 @@ +--- +title: "Gamma Markets" +date: 2026-07-15 +draft: false +translationOf: /en/topics/gamma-markets.md +translationDate: 2026-07-15 +categories: + - Commerce + - Marketplace + - Protocol +--- + +Gamma Markets is een set e-commerceconventies die direct bovenop [NIP-99](/nl/topics/nip-99/)-advertenties is gebouwd, gezamenlijk ontwikkeld door een werkgroep van Nostr-marktplaatsontwikkelaars: de teams achter Shopstr, Cypher, Plebeian Market en Conduit Market. Het vult de conventies voor verzending, bestelstroom, collecties en recensies in die NIP-99 zelf ongedefinieerd laat. + +## Hoe het werkt + +Gamma Markets voegt vijf eventkinds toe rond het bestaande kind `30402`-advertentie-event van NIP-99, zonder de vorm van dat event te veranderen: + +- **Kind 30405** - productcollecties, die meerdere advertenties groeperen via `a`-tags +- **Kind 30406** - verzendopties, met prijzen per land en optionele kostenregels op basis van gewicht of afstand +- **Kind 16** - bestelberichten: aanmaken (type 1), betalingsverzoeken (type 2), statusupdates (type 3) en verzendupdates (type 4) +- **Kind 14** - algemene communicatie tussen koper en verkoper +- **Kind 17** - betalingsbonnen +- **Kind 31555** - productrecensies, geadresseerd aan een specifieke verkoper-pubkey en advertentie-`d`-tag + +De betalingsvoorkeuren van een verkoper worden verklaard via een `payment_preference`-tag op hun kind `0`-profielmetadata, en clients ontdekken compatibele apps via [NIP-89](/nl/topics/nip-89/)-applicatieaanbevelingen. Bestelcommunicatie bouwt voort op [NIP-17](/nl/topics/nip-17/) privéberichten, zonder een eigen nieuw versleutelingsschema. + +De bepalende ontwerpkeuze van de specificatie is dat niets doorsijpelt: een advertentie die bij een collectie hoort, of die een verzendoptie gebruikt, verwijst er expliciet naar met een `a`-tag in plaats van de instellingen van de ouder automatisch te erven. Dat is een bewuste afwijking van het oudere [NIP-15](/nl/topics/nip-15/)-kraammodel, waar een product stilzwijgend de valuta en verzendtabel van zijn kraam erfde. + +### Voorbeeld: aanmaken van een bestelling (kind 16, type 1) + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +## Waarom het van belang is + +NIP-99 alleen standaardiseert enkel de advertentie zelf, een ondertekende, adresseerbare advertentie. Voor Gamma Markets vond elke client die echte e-commerce op NIP-99 bouwde zijn eigen privéconventies uit voor verzending, afrekenen en recensies, wat betekende dat twee NIP-99-conforme clients elk een advertentie correct konden weergeven maar geen gedeelde manier hadden om samen een bestelling af te ronden. Gamma Markets dicht dat gat zonder het NIP-99-advertentieformaat zelf aan te raken, zodat bestaande NIP-99-advertenties zonder aanpassing geldig blijven. + +## Implementaties + +- [Shopstr](https://github.com/shopstr-eng/shopstr) - Nostr-marktplaats, een van de vier projecten die de specificatie schreven +- [Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) - marktplaatsprotocol dat zijn eigen bestelstatus- en afrekenstroom bouwt in dezelfde ontwerpruimte + +--- + +**Primaire bronnen:** +- [Gamma Markets-specificatierepository](https://github.com/GammaMarkets/market-spec) +- [NIP-99 e-commerce use case-uitbreiding, PR #1784](https://github.com/nostr-protocol/nips/pull/1784) - samengevoegde link van het canonieke NIP-99-document naar de Gamma Markets-specificatie + +**Genoemd in:** +- [Newsletter #31: NIP Deep Dive: NIP-99 en de Gamma Markets-handelsuitbreiding](/nl/newsletters/2026-07-15-newsletter/#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) + +**Zie ook:** +- [NIP-99: Classified Listings](/nl/topics/nip-99/) +- [NIP-15: Nostr Marketplace](/nl/topics/nip-15/) +- [NIP-17: Private Direct Messages](/nl/topics/nip-17/) diff --git a/content/nl/topics/nip-4e.md b/content/nl/topics/nip-4e.md new file mode 100644 index 0000000..14eecab --- /dev/null +++ b/content/nl/topics/nip-4e.md @@ -0,0 +1,46 @@ +--- +title: "NIP-4E: Versleuteling loskoppelen van identiteit" +date: 2026-07-15 +draft: false +translationOf: /en/topics/nip-4e.md +translationDate: 2026-07-15 +categories: + - NIP + - Protocol + - Encryption +--- + +NIP-4E is een open concept, voorgesteld door fiatjaf, voor het delen van privégegevens tussen de eigen apparaten van een gebruiker zonder dat elk apparaat de belangrijkste Nostr-identiteitssleutel van die gebruiker bezit. Het is niet samengevoegd en blijft een `draft`/`optional` voorstel. + +## Het probleem dat het aanpakt + +Veel bestaande NIPs, waaronder NIP-51-lijsten en NIP-60 Cashu-wallets, versleutelen gegevens van een gebruiker naar zichzelf met de identiteitssleutel zodat die later op elk apparaat weer te lezen zijn. Dat loopt spaak wanneer de identiteitssleutel niet direct toegankelijk is, bijvoorbeeld wanneer een externe ondertekenaar wordt beschermd door FROST-drempeldelen, MuSig2 of een gehoste beveiligde enclave, omdat versleutelen en ontsleutelen dan elke keer een rondgang naar die ondertekenaar vereist. Het maakt offline versleuteling ook onmogelijk zodra de ondertekeningssleutel in een externe bunker leeft. + +## Hoe het werkt + +NIP-4E scheidt een "clientsleutel" per apparaat van een gedeelde "versleutelingssleutel" die niet de identiteitssleutel van de gebruiker is: + +1. De eerste client die een gebruiker opzet, genereert een willekeurig versleutelingssleutelpaar en kondigt de publieke helft ervan aan in een `kind:10044`-event dat met de identiteitssleutel van de gebruiker is ondertekend. +2. Elke andere client die gegevens voor die gebruiker wil versleutelen of ontsleutelen, berekent zijn Diffie-Hellman gedeelde geheim tegen de aangekondigde versleutelingssleutel in plaats van tegen de identiteitssleutel. +3. Wanneer een tweede apparaat een nieuwe client installeert, genereert die client zijn eigen lokale "clientsleutel" en publiceert een `kind:4454`-aankondiging (ook ondertekend met de identiteitssleutel van de gebruiker) die de eerste client vraagt de versleutelingssleutel met hem te delen. +4. De oorspronkelijke client detecteert de nieuwe `kind:4454`-aankondiging, versleutelt de gedeelde versleutelingssleutel naar de sleutel van de nieuwe client met [NIP-44](/nl/topics/nip-44/), en publiceert die zodat de nieuwe client hem voortaan kan ontsleutelen en gebruiken. + +Het resultaat is dat versleutelen en ontsleutelen nooit meer iets aan de ondertekenaar van de identiteitssleutel hoeven te vragen zodra een client de gedeelde versleutelingssleutel lokaal heeft, en dat een opzet met een externe ondertekenaar (FROST, MuSig2, gehoste enclave) voor identiteit kan worden gebruikt terwijl gewone versleuteling snel blijft en offline werkt. + +## Waarom het van belang is + +NIP-4E wordt aangehaald als de basis voor andere voorstellen die een schijfbrede of accountbrede symmetrische sleutel nodig hebben zonder voor elke versleutel/ontsleutel-aanroep van een externe ondertekenaar af te hangen, waaronder een voorstel voor een privé versleutelde schijf ([PR #2412](https://github.com/nostr-protocol/nips/pull/2412)) en een smallere, NIP-17-specifieke versie van hetzelfde idee ([PR #2361](https://github.com/nostr-protocol/nips/pull/2361)). Beide blijven open naast NIP-4E zelf, waarmee dit een actief, onbeslecht gebied van het protocol is in plaats van een afgerond bouwblok. + +--- + +**Primaire bronnen:** +- [NIP-4E-concept, PR #1647](https://github.com/nostr-protocol/nips/pull/1647) + +**Genoemd in:** +- [Newsletter #31: Open: privé versleutelde schijf breidt NIP-4E uit](/nl/newsletters/2026-07-15-newsletter/#open-private-encrypted-drive-extends-nip-4e) + +**Zie ook:** +- [NIP-44: Encrypted Payloads](/nl/topics/nip-44/) +- [NIP-17: Private Direct Messages](/nl/topics/nip-17/) +- [NIP-46: Nostr Connect](/nl/topics/nip-46/) +- [FROST](/nl/topics/frost/) diff --git a/content/nl/topics/proofmode.md b/content/nl/topics/proofmode.md new file mode 100644 index 0000000..514e713 --- /dev/null +++ b/content/nl/topics/proofmode.md @@ -0,0 +1,36 @@ +--- +title: "ProofMode" +date: 2026-07-15 +draft: false +translationOf: /en/topics/proofmode.md +translationDate: 2026-07-15 +categories: + - Media + - Provenance +--- + +[ProofMode](https://proofmode.org/) is een opensource gereedschapskist voor mediaherkomst, gebouwd door Guardian Project, WITNESS en Okthanks, die verifieerbare gegevens over echtheid en beheersketen aan foto's en video hangt op het moment van opname. Het is niet Nostr-specifiek; Nostr-clients die ProofMode-gegevens meedragen, integreren een bestaande externe standaard in plaats van een nieuwe protocollaag. + +## Hoe het werkt + +De Capture-component van ProofMode sluit herkomstmetadata tijdens de opname direct in mediabestanden in en ondersteunt dezelfde interoperabele standaarden die de Content Authenticity Initiative (CAI), Content Credentials (CR) en C2PA gebruiken. Een aparte Verify-component inspecteert audio-, afbeeldings- en videobestanden om die metadata te controleren op sporen van AI-generatie of latere bewerking, en een Preserve-component regelt redundante opslag op het gedecentraliseerde web van de onderliggende bewijsgegevens voor archivering op lange termijn. Een Develop-SDK laat apps opname en verificatie integreren zonder het herkomstformaat zelf te bouwen. + +## Waarom het van belang is + +Voor een Nostr-video- of afbeeldingsclient betekent het meedragen van ProofMode-gegevens dat een kijker een externe, platformoverstijgende manier heeft om te controleren of een stuk media is opgenomen zoals beweerd en sindsdien niet stilzwijgend is gewijzigd, zonder de publicerende client of relay als bron van vertrouwen te nemen. Dat onderscheid weegt het zwaarst bij een gedownloade of opnieuw gecodeerde kopie van een clip: herkomstgegevens die de download en elk watermerk dat een client aanbrengt overleven, zijn wat de verklaring nog controleerbaar houdt nadat het bestand de app heeft verlaten die het maakte. + +## Implementaties + +- [Divine](https://github.com/divinevideo/divine-mobile) - Nostr-client voor korte video's; draagt ProofMode-herkomstgegevens mee door downloads van clips met watermerk + +--- + +**Primaire bronnen:** +- [ProofMode](https://proofmode.org/) + +**Genoemd in:** +- [Newsletter #17](/nl/newsletters/2026-04-29-newsletter/) +- [Newsletter #31: Divine Mobile 1.0.16 levert een diepere video-editor, versleuteling in rust en ProofMode-herkomst](/nl/newsletters/2026-07-15-newsletter/#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) + +**Zie ook:** +- [Blossom](/nl/topics/blossom/) From 6d00aeaa71f1f10c0e76e265ffb1a0b98a153ae7 Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Thu, 16 Jul 2026 08:38:02 +0000 Subject: [PATCH 09/10] Add Chinese translation for Newsletter #31 and topic pages --- .../zh/newsletters/2026-07-15-newsletter.md | 300 ++++++++++++++++++ content/zh/topics/concord-protocol.md | 61 ++++ content/zh/topics/gamma-markets.md | 69 ++++ content/zh/topics/nip-4e.md | 46 +++ content/zh/topics/proofmode.md | 36 +++ 5 files changed, 512 insertions(+) create mode 100644 content/zh/newsletters/2026-07-15-newsletter.md create mode 100644 content/zh/topics/concord-protocol.md create mode 100644 content/zh/topics/gamma-markets.md create mode 100644 content/zh/topics/nip-4e.md create mode 100644 content/zh/topics/proofmode.md diff --git a/content/zh/newsletters/2026-07-15-newsletter.md b/content/zh/newsletters/2026-07-15-newsletter.md new file mode 100644 index 0000000..403b709 --- /dev/null +++ b/content/zh/newsletters/2026-07-15-newsletter.md @@ -0,0 +1,300 @@ +--- +title: "Nostr Compass #31" +date: 2026-07-15 +publishDate: 2026-07-15 +draft: false +type: newsletters +translationOf: /en/newsletters/2026-07-15-newsletter.md +translationDate: 2026-07-15 +description: "Vector v0.4.0 在群聊中弃用 Marmot，转而采用开放的 Concord 协议，并在数天后发布 Concord v2；Amethyst 合并了自己的洁净室 Concord 实现；Sonar 从 Bitchat 分离，推出跨平台 alpha 版和贴纸包规范；Divine Mobile 1.0.16 带来静态加密和 ProofMode 来源证明；Bitchat 1.7.0 加入实时按键通话语音；MDK v0.9.4 为外部签名器登录设定边界。" +--- + +欢迎回到 Nostr Compass，您的每周 Nostr 指南。 + +**本周：**[Vector v0.4.0](#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) 弃用 [Marmot](/zh/topics/marmot/) 作为群聊的默认传输层，转而采用 [Concord](/zh/topics/concord-protocol/)，这是一个开放的、采用 MIT 许可的社区协议，Soapbox 的 Armada 也在使用它；四天后又发布了 Concord v2，带来面向机器人的斜杠命令选择器、自毁计时器和 NIP-58 徽章。同一周，[Amethyst 合并了自己的洁净室、线路兼容的 Concord 实现](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities)。[Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) 从 Bitchat 分离，推出跨平台 alpha 版，并且是本周贴纸包 kind 提案所引用的规范来源。[Divine Mobile 1.0.16](#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) 带来更深入的视频编辑器、静态加密，以及在下载带水印片段时仍能保留的 ProofMode 来源证明。[Bitchat v1.7.0](#bitchat-v170-adds-live-push-to-talk-voice-for-dms-and-the-public-mesh) 为 DM 加入实时按键通话语音，并在公共网格上支持签名的按键通话。[MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) 为外部签名器登录设定边界并加入草稿持久化，在 Vector 于群聊上远离该规范的同一周延续其加固工作。 + +打标签的发布带来：[n_cord v1.1](#n_cord-v11-adds-nsec-bunker-support) 加入 NSEC Bunker 支持，[cdk v0.17.3](#cdk-v0173-adds-nip-47-wallet-service-support-across-cdk-cdk-nwc-and-cdk-ffi) 在 cdk、cdk-nwc 和 cdk-ffi 中加入 NIP-47 钱包服务支持，[Coop Mobile v0.2.4](#coop-mobile-v024-improves-nostr-connect-and-adds-ncryptsec1-import) 改进 Nostr Connect 并加入 ncryptsec1 导入，[Nmail v0.14.0](#nmail-v0140-ships-on-macos-with-scheduled-send-and-push-notifications) 登陆 macOS 并支持定时发送，[Nostrord v2.2.0](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages) 加入 DM 总开关，[Nostr WoT 0.3.86](#nostr-wot-0386-hardens-key-backups-and-signing-prompts) 将密钥备份加固为 NIP-49 格式，[Keep Android v1.1.8](#keep-android-v118-adds-first-run-frost-onboarding) 加入首次运行的 FROST 引导，[Noscall v0.6.0](#noscall-v060-adds-a-cashu-wallet-and-relay-based-push-notifications) 加入 Cashu 钱包和基于 relay 的推送通知，[Kubo](#kubo-ships-tablet-mode-and-group-chat-photos) 加入平板模式和群聊照片，以及 [Nostr Codex Phone v0.2.9](#nostr-codex-phone-v029-adds-gitdiffread-file-helper-requests) 加入 git、diff 和读取文件的辅助请求。 + +在未发布的一侧，[Amethyst](#amethyst-lets-accounts-nickname-contacts-with-encrypted-nip-85-cards) 让账户可以用加密的 NIP-85 名片为联系人起昵称，共合并 54 个 PR；[Zap Cooking](#zap-cooking-ships-my-kitchen-phase-3-and-fixes-an-ndk-pool-quorum-bug) 推出 My Kitchen 第三阶段并修复了一个 NDK 连接池法定数量的缺陷；[Kehto](#kehto-streams-outbox-reads-before-relay-discovery) 在 relay 发现完成之前就流式处理 outbox 读取；[Wired 和 TAO](#wired-and-tao-add-nip-57-creator-revenue-sharing) 加入 NIP-57 创作者收益分成；[Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) 围绕临时访客结账重建商家订单收件箱；[Buzz](#buzz-hardens-channel-creator-provisioning-around-kind-39002) 在 240 个合并的 PR 中加固频道创建者的开通流程；[Nostr Docs](#nostr-docs-adopts-a-nip-49-signer-with-multi-account-and-qr-pairing) 采用支持多账户和二维码配对的 NIP-49 签名器。本周新纳入追踪：[OpenDiscord v1.0.1](#opendiscord-v101-launches-as-a-discord-style-client-on-nostr)、[Auditable Voting v0.1.140](#auditable-voting-v01140-aligns-organiser-voter-and-audit-proxy-roles)，以及 Discovery 精选 [Cambium v0.3.2](#cambium-v032-pairs-with-heartwood-as-a-keyless-nip-55-signer)，一个把请求代理给 Heartwood 硬件伴侣的无密钥 NIP-55 签名器。 + +NIPs 仓库上周没有合并任何内容，并新开了六个提案：[kind:10011 收藏关注集](#open-kind10011-favorite-follow-sets)、一个[扩展 NIP-4E 的私密加密云盘](#open-private-encrypted-drive-extends-nip-4e)、[NIP-DA 带权限的私密数据共享](#open-nip-da-permissioned-private-data-sharing)、[贴纸包 kind 10031 和 30031](#open-sticker-pack-kinds-10031-and-30031)、[NIP-29 消息置顶](#open-nip-29-message-pinning-with-kind9010-and-kind39005)，以及一次 [NIP-66 relay 发现重构](#open-nip-66-relay-discovery-restructure)。本期 Deep Dive 讲解 [NIP-99 与 Gamma Markets 商务扩展](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension)。 + +--- + +## 头条报道 + +### Vector v0.4.0 将群聊从 Marmot 迁移到 Concord，Amethyst 数天后推出自己的 Concord 客户端 + +[Vector](https://github.com/VectorPrivacy/Vector) 是一款围绕单一二进制、隐私优先的 DM 与群聊客户端构建的 Nostr 通讯工具。[Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) 将应用的消息引擎重写为共享的 `vector-core` 库，并在同一版本中弃用 [Marmot](/zh/topics/marmot/)（MLS-over-Nostr）作为群聊的默认传输层，转而采用 [Concord](/zh/topics/concord-protocol/)，一个端到端加密的社区协议；已有的 Marmot 群聊历史不会迁移，发布说明告知用户在升级前备份任何 Marmot 群组数据。Vector 自己的发布说明将 Concord 描述为「我们自定义的消息协议」，但底层的 [CORD-01 至 CORD-07 规范](https://github.com/concord-protocol/concord)是单独发布的、采用 MIT 许可，并且已在 Vector 之外实现：Soapbox 的 Discord 风格客户端 [Armada](https://gitlab.com/soapbox-pub/armada) 在同一份 Concord 规范上构建其 Communities 功能；一天之后，[Amethyst 合并了自己的洁净室、线路兼容的 Concord 实现](https://github.com/vitorpamplona/amethyst/pull/3566)，下文有完整报道。同一个 Vector 版本还加入了对全部流量的可选 Tor 路由、通过二维码或粘贴 bunker URI 的 [NIP-46](/zh/topics/nip-46/) 远程签名器登录、带应用内切换器的多账户，以及跨客户端共享的自定义 emoji 包。消息删除会在 DM 和群聊中为双方移除消息，而 Vector 有意保留临时签名密钥，而非遵循标准的 [NIP-17](/zh/topics/nip-17/) 删除流程，这是项目在发布说明中明确指出的、出于隐私考虑的偏离。四天后，[v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) 推出 **Concord v2**，据称为 Communities 带来重大的隐私与稳定性改进，同时保持现有社区正常运行，并附带面向机器人的 Discord 风格斜杠命令选择器（支持带类型的参数）、按会话的自毁计时器，以及面向漏洞猎人的 NIP-58 徽章系统。群聊上远离 Marmot 的举动，恰好发生在下文 [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) 继续投入该规范的同一周。 + +### Amethyst 推出面向端到端加密社区的洁净室 Concord 实现 + +[Amethyst](https://github.com/vitorpamplona/amethyst) 是一款功能丰富的 Android 与多平台 Nostr 客户端。[PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) 加入了 [Concord](/zh/topics/concord-protocol/)（CORD-01 至 CORD-07）的完整实现，覆盖无服务器的端到端加密社区：在普通 relay 之上以 gift-wrap 承载控制、聊天与访客留言三个平面；以所有者为根的角色与封禁裁决由每个客户端在本地校验，而不是信任某个服务器；以及通过重新分发密钥切断被移除成员的访问。协议与加密代码位于 `quartz/`，状态与视图模型位于 `commons/`，面向 Android 的界面与导航位于 `amethyst/`，`cli/` 下有轻量的 CLI 命令；目前还没有桌面界面，因为共享逻辑放在 `quartz`/`commons` 中，供 Desktop 日后采用。该实现是洁净室的：基于公开的 CORD 规范和观察到的线路常量构建，采用 Amethyst 自己的 MIT 许可，与 Armada 的 AGPL-3.0 代码库相互独立。Armada 自己的测试向量数值被移植进 Quartz 的单元测试，以确认两个客户端在线路层面确实可以互操作，这让 Concord 在数天之内拥有三个独立实现：首发的 Vector、作为 Soapbox 参考客户端的 Armada，以及如今 Amethyst 依规范构建的版本。 + +### Sonar 从 Bitchat 分离，推出跨平台 alpha 版和贴纸包规范 + +[Sonar](https://sonarprivacy.xyz/) 是一款由 Bitchat 发展而来的蓝牙网格加 Nostr 通讯工具与钱包，其 Marmot 群组 DM 可与 White Noise 互操作。代码位于 [hedwig-corp/bitchat-to-sonar](https://github.com/hedwig-corp/bitchat-to-sonar)。[v0.1-alpha.7](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.7) 加入 Signal 风格的有界会话记录窗口，让打开和滚动的性能保持本地优先；在对等节点之间同步附近发现状态；并修复了因 content-type 和 HTTP 状态处理而失败的 Blossom 媒体上传。此前的 [alpha.6](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-alpha.6) 排空实时 Marmot 事件以加快聊天刷新，并在通话、消息、钱包和推送方面弥合了 Android 与 iOS 之间的功能差距。Sonar 也是 [PR #2410](#open-sticker-pack-kinds-10031-and-30031) 所引用的规范来源，该 PR 依据项目自己的「Sonar Stickers」规范注册贴纸包事件 kind，为这次发布提供了通往本周协议工作的直接连接。 + +### Divine Mobile 1.0.16 带来更深入的视频编辑器、静态加密和 ProofMode 来源证明 + +[Divine](https://github.com/divinevideo/divine-mobile) 是一款构建在 Nostr 上、采用信任网络策展信息流的短视频客户端。[v1.0.16](https://github.com/divinevideo/divine-mobile/releases/tag/1.0.16) 是自 #30 以来的首个打标签版本，为视频编辑器加入片段转场、倒放、旁白录制器和时间轴节拍标记，同时加入信息流调节控件，让用户通过滑动直接调整推荐，而不是把它交给不透明的互动信号。该版本还为本地数据开启静态加密，加入可在应用被挂起后继续进行的后台上传，并在下载带水印的片段时携带 [ProofMode](/zh/topics/proofmode/) 来源数据，使人工创作的证明不会在传输中被剥离。Divine 还为 16 岁以下账户提供新的保护措施，并将本地化扩展到 17 种语言和 284 条已翻译文本。 + +### Bitchat v1.7.0 为 DM 和公共网格加入实时按键通话语音 + +[Bitchat](https://github.com/permissionlesstech/bitchat) 是一款带有可选 Nostr relay 网关的蓝牙网格聊天应用。[v1.7.0](https://github.com/permissionlesstech/bitchat/releases/tag/v1.7.0) 于 #30 发布当晚推出，在 [PR #1403](https://github.com/permissionlesstech/bitchat/pull/1403) 中加入实时按键通话语音：发送者按住按钮期间持续流式传输音频，若流中断则回退为语音留言；此外 [PR #1406](https://github.com/permissionlesstech/bitchat/pull/1406) 在公共网格上加入签名的按键通话，使共享网格频道上的实时语音片段携带发送者认证。该版本还修复了对等 ID 轮换：在经过验证的重新广播上重新绑定链路，从而以新 ID 识别出同一个对等节点（[PR #1401](https://github.com/permissionlesstech/bitchat/pull/1401)）；发往当前不可达对等节点的私信现在会以存储转发方式排队，而不是直接失败（[PR #1415](https://github.com/permissionlesstech/bitchat/pull/1415)）。这直接延续了 #30 对 v1.6.0 中 [NIP-13](/zh/topics/nip-13/) 工作量证明和网格到 Nostr 网关工作的报道。 + +### MDK v0.9.4 为外部签名器登录设定边界并加入草稿持久化 + +[MDK](https://github.com/marmot-protocol/mdk) 是 [Marmot](/zh/topics/marmot/) 协议的参考 SDK，即 #30 报道过其规范被标记为已采纳的 MLS-over-Nostr 消息层。[v0.9.4](https://github.com/marmot-protocol/mdk/releases/tag/v0.9.4) 在 [PR #793](https://github.com/marmot-protocol/mdk/pull/793) 中为客户端在外部签名器登录期间走过的建议目录步骤设定边界，避免远程签名器缓慢或无响应时出现无限重试循环。同一版本在 [PR #812](https://github.com/marmot-protocol/mdk/pull/812) 中加入草稿消息持久化和个人资料网站绑定，延续了 MDK 自 v0.9.0 以来持续进行的渐进式加固。 + +--- + +## 打标签的发布 + +### n_cord v1.1 加入 NSEC Bunker 支持 + +[n_cord](https://github.com/0n4t3/n_cord) 是一款受 Discord 和 IRC 启发、由 Nostr 驱动的聊天客户端。[v1.1](https://github.com/0n4t3/n_cord/releases/tag/v1.1) 加入 [NIP-46](/zh/topics/nip-46/) NSEC Bunker 支持，并修复了一个回复处理的缺陷。 + +### cdk v0.17.3 在 cdk、cdk-nwc 和 cdk-ffi 中加入 NIP-47 钱包服务支持 + +[cdk](https://github.com/cashubtc/cdk) 是一个 Cashu 开发工具包；这个版本在大多数方面只涉及 Bitcoin/Lightning，但 [v0.17.3](https://github.com/cashubtc/cdk/releases/tag/v0.17.3) 加入了 [NIP-47](/zh/topics/nip-47/)（Nostr Wallet Connect）服务支持，包含专门的 NWC 服务 crate、钱包集成、面向 `cdk-ffi` 的 FFI 绑定，以及端到端测试覆盖，为基于 cdk 构建的 Cashu 钱包提供标准的 Nostr Wallet Connect 接口。 + +### Coop Mobile v0.2.4 改进 Nostr Connect 并加入 ncryptsec1 导入 + +[Coop Mobile](https://git.reya.su/reya/coop-mobile) 是一款面向移动平台的 [NIP-17](/zh/topics/nip-17/) 私密消息客户端。[v0.2.4](https://git.reya.su/reya/coop-mobile/releases/tag/v0.2.4) 改进了其 [NIP-46](/zh/topics/nip-46/) Nostr Connect 流程，修复了在某些连接上永久卡住的加载指示器，并加入对 [NIP-49](/zh/topics/nip-49/) `ncryptsec1` 加密密钥格式的导入支持，同时重新设计了身份导入界面。 + +### Nmail v0.14.0 登陆 macOS，支持定时发送和推送通知 + +[Nmail](https://github.com/nogringo/nostr-mail-client) 是一款构建在 Nostr 上的邮件客户端；[v0.14.0](https://github.com/nogringo/nostr-mail-client/releases/tag/v0.14.0) 将应用带到 macOS，加入定时发送并为排队消息设立专门的「已定时」邮箱，还加入了推送通知。该版本还将通讯录的 Nostr 标识符解析改为使用 NDK 的 [NIP-05](/zh/topics/nip-05/) 解析器，取代此前的自制实现。 + +### Nostrord v2.2.0 加入 DM 总开关和更丰富的私信 + +[Nostrord](https://github.com/nostrord/nostrord) 是一款面向 Android、iOS、网页和桌面的 [NIP-29](/zh/topics/nip-29/) 基于 relay 的群聊客户端。[v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) 加入了可一次性关闭所有私信功能的总开关（[PR #175](https://github.com/nostrord/nostrord/pull/175)），并推出「更丰富的私信」（[PR #186](https://github.com/nostrord/nostrord/pull/186)），延续了 #30 对该版本合并 relay 连接池和检测僵尸 WebSocket 的报道。 + +### Nostr WoT 0.3.86 加固密钥备份和签名提示 + +[Nostr WoT](https://github.com/nostr-wot/nostr-wot-extension) 是一款将 Nostr 身份与 Lightning 钱包配对的浏览器扩展。[v0.3.86](https://github.com/nostr-wot/nostr-wot-extension/releases/tag/v0.3.86) 将加密密钥备份迁移到标准的 [NIP-49](/zh/topics/nip-49/) 格式，让签名提示显示完整事件和所有 tag 而非摘要，依据签名校验 relay 数据，并在切换账户时不再暴露当前身份。该扩展还移除了未使用的 `scripting` 浏览器权限。 + +### Keep Android v1.1.8 加入首次运行的 FROST 引导 + +[Keep](https://github.com/privkeyio/keep-android) 是一款基于 FROST 门限密钥分片构建的 Android 签名器。[v1.1.8](https://github.com/privkeyio/keep-android/releases/tag/v1.1.8) 加入首次运行流程，向新用户解释 FROST 密钥分片，并让其在第一个签名请求到来之前选择手动、基础或自动的签名策略，这是底层 keep-mobile crate 的门限签名模型在 Android 侧的首个引导流程。 + +### Noscall v0.6.0 加入 Cashu 钱包和基于 relay 的推送通知 + +[Noscall](https://github.com/sanah9/noscall) 是一款构建在 Nostr 上的安全音视频通话应用。[v0.6.0](https://github.com/sanah9/noscall/releases/tag/v0.6.0-release) 加入账户范围的 Cashu 钱包，支持多 mint 余额、ecash 收发，以及带报价持久化的 Lightning 收付。该版本还将 Android 推送通知从 Firebase Cloud Messaging 迁移到通过 UnifiedPush 的基于 Nostr relay 的投递路径，并改进了登录重试期间 iOS VoIP 和 APNs 推送的可靠性。 + +### Kubo 推出平板模式和群聊照片 + +[Kubo](https://github.com/JeroenOnNostr/kubo) 是一个采用信任网络策展信息流、对儿童安全的 Nostr 视频平台。[kubo-v2026.07.05](https://github.com/JeroenOnNostr/kubo/releases/tag/kubo-v2026.07.05) 为儿童信息流加入可选的平板网格布局，支持在群聊消息中附加照片，并修复了 Android 上注册按钮被屏幕键盘遮挡的问题。 + +### Nostr Codex Phone v0.2.9 加入 git/diff/读取文件的辅助请求 + +[Nostr Codex Phone](https://github.com/tidley/nostr-codex-phone) 是一个面向本地编码助手工作进程的移动控制界面，通过加密的 Nostr DM 通信。[v0.2.9](https://github.com/tidley/nostr-codex-phone/releases/tag/v0.2.9) 加入移动端 OpenCode 工具操作，包括 git、diff、读取文件、状态和历史等辅助请求，改进了会话置顶与搜索，并加入任务停止控制，同时还有在此前 v0.2.8 中推出的加密 [Blossom](/zh/topics/blossom/) 上传封装。 + +### GitWorkshop v3.0.3 修复仓库浏览器中新广播的 ref，并推出首个 Android 构建 + +[GitWorkshop](https://github.com/DanConwayDev/gitworkshop) 是一个用于浏览和审阅 NIP-34 仓库的 git-over-Nostr 网页界面。[v3.0.3](https://github.com/DanConwayDev/gitworkshop/releases/tag/v3.0.3) 修复了分支、标签、提交和代码浏览视图无法解析仓库在浏览器加载之后才广播的 ref 的问题，同时清理了 CI 工作流时序，并已直接对照标签和提交历史确认。同一周，GitWorkshop 在 [Zapstore](https://zapstore.dev) 发布了首个原生 Android 构建，从 v3.0.0 起步并在数小时内到达 v3.0.3；网页界面仍是主要入口，而 Android 包首次把同样的 NIP-34 仓库浏览带到手机上。 + +### Bitcoin-Safe 登陆 Flathub，让其 Nostr Sync & Chat 插件受到关注 + +[Bitcoin-Safe](https://bitcoin-safe.org) 是一款围绕硬件签名器工作流构建的自托管 Bitcoin 钱包。该项目本周[发布了 Flathub 软件包](https://flathub.org/apps/org.bitcoin_safe.BitcoinSafe)，这是它首次进入主流 Linux 应用商店。这次 Flathub 发布把 Bitcoin-Safe 的 Sync & Chat 插件带到更广的受众面前：该插件通过项目自己的 [bitcoin-nostr-chat](https://github.com/andreasgriffin/bitcoin-nostr-chat) 库使用 [NIP-17](/zh/topics/nip-17/) 私信，在用户的多台设备之间同步钱包标签，并在受信任的参与者之间收发 PSBT 以完成远程多签联署。Nostr 层本身更早就已推出，见 [2.0.0](https://github.com/andreasgriffin/bitcoin-safe/releases/tag/2.0.0)（2026-06-29），该版本围绕「Share via Chat & Sync」连接类型重新设计了交易签名，与二维码、USB 和蓝牙并列。本周的新闻是 Flathub 打包首次把这个既有功能带到主流 Linux 受众面前。 + +--- + +## 未发布的变更 + +### Amethyst 让账户用加密的 NIP-85 名片为联系人起昵称 + +除上文提到的 [Concord 实现](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities)之外，Amethyst 上周还合并了 54 个其他 PR。其中的重点是 [PR #3548](https://github.com/vitorpamplona/amethyst/pull/3548)，它让一个账户通过发布自己关于对方的 kind 30382 [NIP-85](/zh/topics/nip-85/) 联系人名片，为任何其他用户起昵称。昵称、一条私密备注，以及任何自定义的 [NIP-30](/zh/topics/nip-30/) emoji 短代码映射，都存放在名片经 [NIP-44](/zh/topics/nip-44/) 加密的 content 中，因此只有签名账户可以读取；名片在登录时通过账户扩展的 outbox relay 集合同步，之后增量同步。信息流、聊天和提及会用昵称替代公开显示名，并在个人资料页用户真名上方显示一张可点按的昵称名片。 + +### Zap Cooking 推出 My Kitchen 第三阶段并修复 NDK 连接池法定数量缺陷 + +[Zap Cooking](https://github.com/zapcooking/frontend) 是一款构建在 Nostr 上的食谱分享与烹饪社区应用。它合并了 43 个 PR，延续其「My Kitchen」备餐规划功能，本阶段落地了购物清单生成、食谱选择器和规划周视图。同一批变更修复了 [NDK](https://github.com/nostr-dev-kit/ndk)（Nostr Development Kit）连接池的法定数量就绪缺陷，该缺陷可能让 relay 读取在已有法定数量的 relay 应答之后仍继续等待。 + +### Kehto 在 relay 发现之前流式处理 outbox 读取 + +[Kehto](https://github.com/kehto/web) 是一个面向 [NIP-5D](/zh/topics/nip-5d/) Nostr 小应用（即「napplets」）的早期网页运行时。它合并了 26 个 PR。[PR #193](https://github.com/kehto/web/pull/193) 修复了此前 outbox 读取必须等待 [NIP-65](/zh/topics/nip-65/) relay 列表加载完成才会开启任何 relay 的问题，因为一次始终无法完成的 relay 列表加载会同时阻塞事件投递和查询超时；修复后会立即打开已验证的 relay 提示，并在发现写入 relay 的过程中流式返回结果。第二处变更（[PR #196](https://github.com/kehto/web/pull/196)）让项目的身份审计页面与 NAP-SHELL（Napplet 平台的生命周期契约）对齐，这属于本周 `napplet/web` 发布中其他地方也能看到的同一批协议对齐工作。 + +### Wired 和 TAO 加入 NIP-57 创作者收益分成 + +[Wired](https://github.com/smolgrrr/Wired) 和 [TAO](https://github.com/smolgrrr/TAO) 是构建在 Nostr 上、注重言论自由的孪生社交客户端，共享同一份 PR 列表；两者都合并了 [PR #121](https://github.com/smolgrrr/Wired/pull/121)，它实现了 [NIP-57](/zh/topics/nip-57/) 创作者收益分成，使发给某条帖子的 zap 可以自动分配给原发帖者之外的贡献者。这延续了 #30 对这对客户端将工作量证明信号提升到 21 位这一未发布工作的报道。 + +### Conduit Mono 围绕临时访客结账重建商家订单收件箱 + +[Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) 是一个与 [NIP-99](/zh/topics/nip-99/) 分类广告相邻的市场协议。[PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174) 使用浏览器生成的临时密钥加入访客结账：访客用这把一次性密钥向商家发送加密订单和付款报告，商家再通过电话或邮件在带外跟进，因此买家从不需要一个持久的收件箱身份。[PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175) 围绕单一共享的订单状态模型重建商家订单收件箱，分离买家与商家角色，并要求实体或混合订单在转为已发货之前提供追踪码和承运商。该项目的结账流程构建在 [NIP-17](/zh/topics/nip-17/) 私密消息、[NIP-44](/zh/topics/nip-44/) 加密和 [NIP-59](/zh/topics/nip-59/) gift wrap 之上。本周的 [NIP Deep Dive](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) 讲解了同一个订单状态问题所指向的 [Gamma Markets](/zh/topics/gamma-markets/) 约定。 + +### Buzz 围绕 kind 39002 加固频道创建者的开通流程 + +[Buzz](https://github.com/block/buzz) 是一个通过 Nostr 连接 AI 智能体与人类的群体智慧通信平台。它上周合并了 240 个 PR，从 #30 报道的 kind 44200 智能体轮次指标开始，延续其 relay 层加固的脉络。本周的修复（[PR #1830](https://github.com/block/buzz/pull/1830)）在 kind 39002 频道开通逻辑运行之前先把频道创建者视为成员，堵上了创建者可能在设置过程中被自己的频道拒绝的竞态。 + +### Nostr Docs 采用支持多账户和二维码配对的 NIP-49 签名器 + +[Nostr Docs](https://github.com/formstr-hq/nostr-docs) 是一款 Nostr 原生的协作文档应用。它合并了 5 个 PR，其中值得注意的是 [PR #50](https://github.com/formstr-hq/nostr-docs/pull/50)，它采用 `@formstr/signer` 包实现完整的 [NIP-49](/zh/topics/nip-49/) 认证，支持多账户切换和二维码配对，取代了此前的自制签名路径。 + +### 同期推出 + +上周还有若干被追踪项目落地了较小的签名器互操作与可靠性修复，不足以单独成段：[ngit-cli](https://github.com/DanConwayDev/ngit-cli) 是一个面向基于 Nostr 的 GitHub 替代方案的命令行客户端，推出 [v2.6.3](https://github.com/DanConwayDev/ngit-cli/releases/tag/v2.6.3)，让 `ngit init` 给出可操作的设置指引，而不是反复索要 nsec；[Manent](https://github.com/dtonon/manent) 是一款构建在 Nostr 上的私密加密笔记与文件应用，推出 [v1.4.1](https://github.com/dtonon/manent/releases/tag/v1.4.1)，修复了 Amber 返回十六进制 pubkey 时 Android 签名器登录失效的问题，并改进了 bunker 登录的滚动；[NoorNote](https://github.com/77elements/noornote) 是一款不依赖 Google 服务的轻量 Nostr 客户端，推出 [v1.2.8](https://github.com/77elements/noornote/releases/tag/v1.2.8)，修复了 Nostrord 群组通知丢失的问题并加入自己发帖的提醒开关；[Bray](https://github.com/forgesworn/bray) 是一个面向 AI 智能体与人类、具备信任感知的 Nostr MCP 服务器，推出 [v1.34.0](https://github.com/forgesworn/bray/releases/tag/v1.34.0)，在 [NIP-46](/zh/topics/nip-46/) bunker 连接时发送客户端名称元数据；[Lumilumi](https://github.com/TsukemonoGit/lumilumi) 是一款 Nostr 网页客户端，将 [NIP-65](/zh/topics/nip-65/) relay 列表缓存到本地存储以便离线回退；[Earthly](https://github.com/moogmodular/earthly) 是一款基于 Nostr 的本地城市与社区应用，加入 [NIP-50](/zh/topics/nip-50/) 地理搜索；[lnbits](https://github.com/lnbits/lnbits) 是一个免费开源的 Lightning 钱包与账户系统，推出 [PR #3925](https://github.com/lnbits/lnbits/pull/3925)，在一个其余部分以 Lightning 为主的版本中让 `send_nostr_dm` 以非阻塞方式发布。 + +--- + +## 新纳入追踪与新发现 + +### OpenDiscord v1.0.1 作为 Nostr 上的 Discord 风格客户端发布 + +[OpenDiscord](https://github.com/sofia-gros/open-discord) 是一款构建在 Nostr 上的 Discord 风格服务器与频道客户端，具备基于角色的权限和 WebRTC/SFU 语音大厅。[v1.0.1](https://github.com/sofia-gros/open-discord/releases/tag/v1.0.1) 是该项目首个打标签的安装包版本。 + +### Auditable Voting v0.1.140 对齐组织者、投票者和审计代理角色 + +[Auditable Voting](https://github.com/tidley/auditable-voting) 是一个纯客户端的 Nostr 投票外壳。[v0.1.140](https://github.com/tidley/auditable-voting/releases/tag/v0.1.140) 将组织者、投票者和审计代理角色与组织者签名的那个确切的公开问卷定义事件对齐，堵上了审计代理可能基于过期生成账户，或基于来自另一个工作进程或组织者的持久化状态而行动的缺口。 + +### Cambium v0.3.2 与 Heartwood 配对，作为无密钥 NIP-55 签名器 + +[Cambium](https://github.com/forgesworn/cambium) 是本期的 Discovery 精选：一款自身不持有任何私钥材料的 Android [NIP-55](/zh/topics/nip-55/) 签名器，它通过 [NIP-46](/zh/topics/nip-46/) 把每个签名请求代理给配套的 Heartwood 硬件签名器。该项目与被追踪项目 Bray 共用 `forgesworn` GitHub 组织，而 Heartwood 本身在 #30 中曾被报道推出了 relay 到串口的签名桥接，正是 Cambium 的 Android 侧如今对接的对象。[v0.3.2](https://github.com/forgesworn/cambium) 优化了审批面板，使其在所选身份与应用现有绑定不一致时实时告警，并将活动日志写入移到单一的非阻塞队列。 + +### 本周同期上线：echoes、Dispatch 和 Linky + +本周还有三个值得一提的上线。[echoes](https://github.com/Lwb89dev/echoes) 是一款离线优先、端到端加密的笔记应用，通过 Nostr 私密同步。[Dispatch](https://github.com/freecritter/dispatch) 是一款本地优先的旅行整理工具，每次保存都经 [NIP-44](/zh/topics/nip-44/) 加密，并以一把专用、不可关联的密钥通过 Nostr 备份，其 [v0.3.0](https://github.com/freecritter/dispatch) 版本加入 Amber [NIP-55](/zh/topics/nip-55/) 登录，使应用永远不会直接接触用户的私钥。[Linky](https://github.com/hynek-jina/linky) 在单个渐进式网页应用中，把 Nostr 联系人和 DM 与 Lightning 及 Cashu 支付结合起来。 + +--- + +## 协议工作与 NIP 更新 + +上周没有 PR 合并进 [NIPs 仓库](https://github.com/nostr-protocol/nips)。新开了六个提案。 + +### 新开：kind:10011 收藏关注集 + +[PR #2413](https://github.com/nostr-protocol/nips/pull/2413) 来自 fiatjaf，加入 kind:10011 收藏关注集。它沿用了既有模式：kind:10012（收藏 relay 集）持有指向 kind:30002 relay 集的 `a` tag，并把同样的收藏机制扩展到 kind:30000 关注集，使客户端可以收藏一份精选的关注列表，而不必替换自己的联系人列表。 + +### 新开：扩展 NIP-4E 的私密加密云盘 + +[PR #2412](https://github.com/nostr-protocol/nips/pull/2412) 来自 Form* 团队，提出一个通用的 Metadata 事件 kind 34578，以 `d` 标识符 tag 和 `t` 子类型 tag 区分，并在其之上构建一个私密加密文件系统，该系统已在 Form* 自己仍处于实验阶段的 Form* Drive 客户端中实现。文件记录是带 `t=files` 的 Metadata 事件：文件 blob 存放在 [Blossom](/zh/topics/blossom/) 服务器上，relay 上只放加密索引，每个文件分块都有自己的临时密钥对，采用 [NIP-44](/zh/topics/nip-44/) v2 HKDF 派生的加密。配套的 Decoupled Encryption Key 事件持有一把云盘范围的对称密钥，每个文件的元数据都以它解密；该提案明确构建在 [NIP-4E](/zh/topics/nip-4e/) 之上，即 fiatjaf 仍未合并的存储抽象草案（[PR #1647](https://github.com/nostr-protocol/nips/pull/1647)，自 2024 年 12 月起开放）。 + +那把唯一的云盘范围密钥意味着，一旦密钥泄露，暴露的是云盘中每个文件的元数据，而不只是某一个文件，因为按文件的临时密钥对只改变分块加密密钥，并不改变元数据解密密钥；目前除了发布一个新的 Metadata 事件、警告较旧事件可能丢失之外，还没有任何轮换或吊销路径。第二个更狭窄的提案从另一个角度触及同样的 NIP-4E 底层想法：[PR #2361](https://github.com/nostr-protocol/nips/pull/2361) 来自 fiatjaf，专门在 [NIP-17](/zh/topics/nip-17/) 消息内部解耦身份密钥与加密密钥，自 6 月 1 日起开放。两个 PR 都未合并，使这里成为设计空间中一个活跃且存在争议的角落。Form* 表示 Drive 客户端仍是实验性的，更新即将到来。 + +### 新开：NIP-DA 带权限的私密数据共享 + +[PR #2411](https://github.com/nostr-protocol/nips/pull/2411) 来自 JAFairweather，是一份新的 NIP-DA 草案，通过带作用域的数据授权实现带权限的私密数据共享。每个用户在 relay 上为每个作用域保留一条加密的权威记录，访问权限则通过在 [NIP-59](/zh/topics/nip-59/) gift wrap 中私密投递该作用域的对称密钥来授予，因此 relay 只存储密文，也永远不会得知谁向谁授予了访问权限；吊销就是一次密钥轮换，无需重写每个使用方的副本。作者将其定位为区别于 [NIP-17](/zh/topics/nip-17/) DM（可以携带数据快照，但无法提供实时更新或吊销）以及 NIP-51 私密列表（不携带密钥材料），并引用了两个独立实现：一个 JavaScript 参考库和一个基于 go-nostr 的 Go CLI，二者已针对 relay.damus.io、nos.lol 和 relay.primal.net 交叉测试。 + +### 新开：贴纸包 kind 10031 和 30031 + +[PR #2410](https://github.com/nostr-protocol/nips/pull/2410) 来自 vincenzopalazzo，在 Event Kinds 表中注册 kind 30031（可寻址贴纸包）和 kind 10031（用户的贴纸包列表），并由本周 [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) 推出的「Sonar Stickers」格式规定。这两个 kind 有意排在 [NIP-30](/zh/topics/nip-30/) 自定义 emoji 的 kind 30030 和 10030 上方一位，使客户端不会把贴纸包误认作 emoji 集；贴纸图像字节存放在兼容 [Blossom](/zh/topics/blossom/) 的 HTTPS 服务器上，已发送贴纸的引用携带明文哈希，使经过编辑的可寻址贴纸包无法悄悄改变旧消息中已发送贴纸的外观。一个配套 PR 在独立的 `registry-of-kinds` 项目中注册了相同的 kind。 + +### 新开：使用 kind:9010 和 kind:39005 的 NIP-29 消息置顶 + +[PR #2379](https://github.com/nostr-protocol/nips/pull/2379) 来自 Anderson-Juhasc，为 [NIP-29](/zh/topics/nip-29/) 基于 relay 的群组加入消息置顶：kind:9010 `update-pin-list` 是一个审核事件，以 `e` tag 按显示顺序携带完整的置顶事件列表，因此单个事件即可置顶、取消置顶、重新排序或清空置顶集合；kind:39005 则是由 relay 生成的镜像，暴露最新被接受的列表。该设计在收到审阅反馈后，取代了 [PR #1163](https://github.com/nostr-protocol/nips/pull/1163) 中较早的增加/删除成对方案，并选用 kind 编号 9010/39005，因为 9009 和 39003 此后已被 `create-invite` 和群组角色占用。Anderson-Juhasc 同时维护 [Nostrord](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages)，其 [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) 在同一周推出。 + +### 新开：NIP-66 relay 发现重构 + +[PR #2241](https://github.com/nostr-protocol/nips/pull/2241) 来自 VincenzoImp，是对 [NIP-66](/zh/topics/nip-66/) relay 发现的一次大幅重构。它用结构化的 Indexed Tags 章节取代了松散的「Other tags include」散文，加入镜像 NIP-11 `attributes` 字段的 `W` tag 以用于 relay 发现过滤，加入使用标准化命名空间（`ISO-639-1`、`ISO-3166-1`、`IANA-asn`、`IANA-tz`、`nip66.label.city`）的 `l` 标签 tag，并把 RTT、SSL/TLS、网络、地理、DNS 和 HTTP 相关 tag 组织到各自的章节中，同时新增一张 Check Types 表。它还修复了字段名错误、缺少 `kind`、检查类型名无效的示例事件，并关闭了 [issue #2171](https://github.com/nostr-protocol/nips/issues/2171)。由于新增的每个 tag 都是可选的，所有变更都保持向后兼容。 + +--- + +## NIP Deep Dive：NIP-99 与 Gamma Markets 商务扩展 + +[NIP-15](/zh/topics/nip-15/) 是最初的 Nostr Marketplace 规范，如今已属遗留：它用一个商家摊位（kind 30017）建模，商品（kind 30018）归档在摊位之下；曾经运行其上的客户端，包括 Shopstr，如今都已转向 [NIP-99](/zh/topics/nip-99/) 分类广告作为活跃规范。NIP-99 本身是单个可寻址事件，活跃广告为 kind 30402，草稿为 kind 30403，不需要先创建摊位。它把广告之外的一切都留作未定义：运费、订单状态、收据、评价，以及把多条广告归入一个店面的方式，恰恰是 NIP-15 中从未延续下来的那些部分。[Gamma Markets](/zh/topics/gamma-markets/) 填补了这一空白，也是今天值得理解的现代商务层。 + +### NIP-99 留下的空白 + +NIP-99 广告的 `content` 字段承载 Markdown 描述，`price` 和 `location` 直接位于事件之上，`t` tag 让它像普通话题标签内容一样可被搜索。由于它按 pubkey、kind 和 `d` tag 三元组可寻址，卖家只需发布一个带相同 `d` tag 的新版本即可原地编辑广告： + +```json +{ + "kind": 30402, + "content": "Vintage mechanical keyboard, Cherry MX Blue switches, barely used.", + "tags": [ + ["d", "keyboard-mx-blue-01"], + ["title", "Vintage Mechanical Keyboard"], + ["summary", "Cherry MX Blue, barely used"], + ["published_at", "1752537600"], + ["location", "NYC"], + ["price", "100", "USD"], + ["t", "electronics"] + ] +} +``` + +这就是规范的全部：一条签名的、可更新的分类广告。每一个为真实电商而实现 NIP-99 的客户端，只要超出一次性分类广告的范围，最终都会为运费、订单消息和评价发明自己的私有约定。两个 NIP-99 客户端可以各自正确渲染同一条广告，却依然没有共同的方式在彼此之间完成一次结账。 + +### Gamma Markets：把 NIP-99 略去的部分标准化 + +Gamma Markets 是一个由 Nostr 市场开发者组成的工作组，即 Shopstr、Cypher、Plebeian Market 和 Conduit Market 背后的团队，为一套构建在 NIP-99 既有 kind 30402 事件之上的共享电商约定所取的名字。该规范通过 [PR #1784](https://github.com/nostr-protocol/nips/pull/1784) 从 NIP-99 的规范文档中链接出去，并在自己的仓库 [GammaMarkets/market-spec](https://github.com/GammaMarkets/market-spec) 中维护。 + +Gamma Markets 加入两个与广告相邻的独立 kind。kind 30405 把多条广告归为一个商品合集，通过显式的 `a` tag 引用每一条： + +```json +{ + "kind": 30405, + "content": "Summer sale picks", + "tags": [ + ["d", "summer-picks"], + ["title", "Summer Sale"], + ["a", "30402::keyboard-mx-blue-01"], + ["shipping_option", "30406::standard-regional"] + ] +} +``` + +kind 30406 定义一个配送选项，带有按国家的定价和可选的按重量或距离计费规则： + +```json +{ + "kind": 30406, + "content": "Standard Regional Shipping", + "tags": [ + ["d", "standard-regional"], + ["title", "Standard Shipping"], + ["price", "5.99", "USD"], + ["country", "US"], + ["service", "standard"], + ["duration", "24", "72", "H"], + ["weight-max", "30", "kg"] + ] +} +``` + +订单创建、付款请求、状态与配送更新，以及付款收据，全都作为普通的 [NIP-17](/zh/topics/nip-17/) gift-wrap 私密消息传输，按角色分成三个 kind，而不是重新包装传输层：kind 14 承载买家与商家之间的自由沟通，kind 16 承载每一次订单状态转换（`type` tag 取 1 到 4，分别标记订单创建、付款请求、状态更新或配送更新），kind 17 承载买家的付款收据。一条订单创建消息在 gift-wrap 之前是这样的： + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +为已完成的购买评分是另一个独立的可寻址 kind 31555，指回它所评价的广告： + +```json +{ + "kind": 31555, + "content": "Arrived fast, exactly as described.", + "tags": [ + ["d", "a:30402::keyboard-mx-blue-01"], + ["rating", "1", "thumb"], + ["rating", "1.0", "quality"], + ["rating", "0.9", "delivery"] + ] +} +``` + +让订单消息搭乘 NIP-17 意味着，一次 Gamma Markets 结账使用的是客户端早已为 DM 提供的同一套私密消息传输，而不是一个定制的订单消息 kind。 + +该规范的核心设计选择是：任何东西都不会向下继承。属于某个合集的广告用 `a` tag 显式引用它，而不是自动继承合集的配送选项或描述；广告所使用的配送选项也以同样显式的方式引用。这是对 NIP-15 摊位模型的刻意反转，在那个模型里，商品会默默继承其父摊位所定义的货币和运费表。代价是每条广告上需要更多显式的 tag，换来的是广告的完整配置始终可以从事件本身读出，无需先解析一个父对象。 + +### 这在实践中出现在哪里 + +本周 [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) 的工作正处于 Gamma Markets 所标准化的同一片订单消息领域：[PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174) 的临时密钥访客结账，以及 [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175) 的商家订单收件箱重建，解决的都是 Gamma Markets 的 kind 14、16 和 17 消息所形式化的买家/商家订单状态问题；Conduit Mono 在这些 kind 之外运行自己的订单状态模型，并未直接采用它们。Shopstr 作为编写该规范的四个项目之一，上周也让自己的商务管道保持推进：[PR #568](https://github.com/shopstr-eng/shopstr/pull/568) 把重复的 NIP-17 gift-wrap 逻辑抽取到一个共享模块，[PR #567](https://github.com/shopstr-eng/shopstr/pull/567) 把其 [NIP-98](/zh/topics/nip-98/) HTTP 认证解析器提升到完整测试覆盖，维护的正是 Gamma Markets 订单流程赖以安全触达买家和商家的消息与认证层。 + +NIP-15 之所以失去店面这一角色，是因为它标准化了摊位和商品，却把支付、配送、评价和订单状态留给应用去解决。Gamma Markets 填补了其中大部分缺失的接口，且没有触动 NIP-99 的单条广告形态，它构建在 Nostr 既有的 DM 栈 NIP-17 之上，而不是另造一个消息层。 + +--- + +本周就到这里。正在构建什么，或有新闻想分享？请通过 NIP-17 DM 联系我们，或在 Nostr 上找到我们。 diff --git a/content/zh/topics/concord-protocol.md b/content/zh/topics/concord-protocol.md new file mode 100644 index 0000000..9effba7 --- /dev/null +++ b/content/zh/topics/concord-protocol.md @@ -0,0 +1,61 @@ +--- +title: "Concord Protocol" +date: 2026-07-15 +draft: false +translationOf: /en/topics/concord-protocol.md +translationDate: 2026-07-15 +categories: + - Protocol + - Messaging +--- + +Concord 是一个面向 Nostr 上端到端加密社区与频道的开放、MIT 许可协议，由 [CORD-01 至 CORD-07 规范](https://github.com/concord-protocol/concord)定义。[Vector](https://github.com/VectorPrivacy/Vector) 自 v0.4.0 起将其采纳为群聊功能的默认传输层，并在自己的发布说明中称之为「我们自定义的消息协议」，但该规范本身是独立于 Vector 发布的，并且已经有了独立实现。 + +## 工作方式 + +Concord 把 Discord 风格社区服务器通常承担的职责，拆分成无需信任任何人的若干部分：relay 只存储寻址到轮换标签的加密 blob；持有房间密钥才使一个人成为成员；而对角色、踢出和封禁的裁决权是一份根植于所有者身份的签名名册，由每个客户端在本地校验，而不是信任某个服务器去执行。每个持久事件都乘同一个三层信封：由该平面自己派生的流密钥签名的 kind 1059 wrap，其中包含由作者真实密钥签名的 seal，seal 中又包含承载功能事件的未签名 rumor。聊天消息 rumor 是一个普通的 kind 9 事件： + +```json +{ + "kind": 9, + "pubkey": "", + "content": "Hey chat!", + "tags": [ + ["channel", ""], + ["epoch", "0"] + ] +} +``` + +控制、聊天和访客留言流量各自拥有独立的 [NIP-59](/zh/topics/nip-59/) gift-wrap 平面，因此即便一个 relay 同时持有这三者，没有房间密钥也无法分辨控制消息、聊天消息与访客留言条目。该规范拆分为七份 CORD 文档：私密流（01）、社区与成员资格（02）、频道（03）、角色（04）、邀请（05）、用于切断被移除成员的重新分发密钥与重建（06），以及通过盲令牌中介实现的音视频（07）。成员资格本身没有服务端列表：能解密该平面的人就是成员；真正移除某人意味着把社区滚动到一个新的密钥纪元，并只交给留下的人，而不是从表里删掉一行。 + +## 它与 Marmot 的区别 + +Concord 与 [Marmot](/zh/topics/marmot/) 都在 Nostr 上解决加密群组消息，但用不同的密码学服务于不同形态的群组，Concord 项目自己的对比也明确指出了这一分野：Marmot 在 Nostr 之上叠加 [MLS](/zh/topics/mls/)，以获得前向保密性和被攻破后安全性，使用按设备的密钥包和有序提交，让整个群组步调一致地前进。这换来了强有力的保证，代价是随成员变动而增长的开销，很适合加入和退出都很少见的小型高风险群组。Concord 则给每个成员相同的房间密钥，并在移除成员时对整个房间重新分发密钥，而不是按每次提交做棘轮推进；它让出 MLS 的部分密码学保证，换来一个在社区增长到数百或数千名随意加入、流动频繁的成员时仍保持低成本的模型，而这正是 Discord 风格社区在现实中的形态。 + +## Vector 为何切换 + +Vector 自己的 [v0.4.0 发布说明](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0)只把 Concord 描述为用于群聊的「我们自定义的消息协议」，没有直接说明理由。无论如何，它与 Concord 自己公开的设计动机是契合的：像 Vector 这样的客户端中的群聊，正是那种规模大、开放、成员频繁变动的场景，而 Marmot 按设备维护的 MLS 状态在这里成为更昂贵的路径，Concord 异步、可随时收拢的设计恰恰是为这种场景而建。[Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) 在群聊中弃用 Marmot 转向 Concord，已有的 Marmot 群聊历史在切换中没有迁移。四天后，[v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) 推出带隐私与稳定性改进的「Concord v2」。同一周内，[Amethyst 合并了自己的洁净室、线路兼容的 Concord 实现](https://github.com/vitorpamplona/amethyst/pull/3566)，而 Soapbox 的 Discord 风格客户端 [Armada](https://gitlab.com/soapbox-pub/armada) 早已作为参考实现，在同一份规范上构建其 Communities 功能。三个独立客户端在数天之内汇聚到同一份开放规范，是通往真正跨客户端互操作的快速路径，值得对照 Nostr 其余群聊客户端中有多少仍留在 Marmot 上来观察。 + +## 实现 + +- [Vector](https://github.com/VectorPrivacy/Vector) - 单一二进制、隐私优先的 Nostr 通讯工具；首个推出 Concord 的客户端，始于 v0.4.0 +- [Armada](https://gitlab.com/soapbox-pub/armada)（Soapbox）- Discord 风格社区客户端；参考实现，后端位于独立的 `armada-relay` 仓库 +- [Amethyst](https://github.com/vitorpamplona/amethyst) - 功能丰富的 Android 与多平台 Nostr 客户端；与 Armada 线路兼容的洁净室重新实现（[PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566)） + +--- + +**主要来源：** +- [Concord 协议规范（CORD-01 至 CORD-07）](https://github.com/concord-protocol/concord) +- [Vector v0.4.0 发布说明](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) +- [Vector v0.4.1 发布说明](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) +- [Amethyst PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) + +**提及于：** +- [Newsletter #31：Vector v0.4.0 将群聊从 Marmot 迁移到 Concord，Amethyst 数天后推出自己的 Concord 客户端](/zh/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) +- [Newsletter #31：Amethyst 推出面向端到端加密社区的洁净室 Concord 实现](/zh/newsletters/2026-07-15-newsletter/#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) + +**另见：** +- [Marmot Protocol](/zh/topics/marmot/) +- [MLS (Message Layer Security)](/zh/topics/mls/) +- [NIP-46: Nostr Connect](/zh/topics/nip-46/) diff --git a/content/zh/topics/gamma-markets.md b/content/zh/topics/gamma-markets.md new file mode 100644 index 0000000..49b6f4b --- /dev/null +++ b/content/zh/topics/gamma-markets.md @@ -0,0 +1,69 @@ +--- +title: "Gamma Markets" +date: 2026-07-15 +draft: false +translationOf: /en/topics/gamma-markets.md +translationDate: 2026-07-15 +categories: + - Commerce + - Marketplace + - Protocol +--- + +Gamma Markets 是一套直接构建在 [NIP-99](/zh/topics/nip-99/) 分类广告之上的电商约定，由一个 Nostr 市场开发者工作组协作制定，即 Shopstr、Cypher、Plebeian Market 和 Conduit Market 背后的团队。它补齐了 NIP-99 自身未定义的配送、订单流程、合集和评价约定。 + +## 工作方式 + +Gamma Markets 围绕 NIP-99 既有的 kind `30402` 广告事件加入五个事件 kind，且不改变该事件的形态： + +- **kind 30405** - 商品合集，通过 `a` tag 把多条广告归为一组 +- **kind 30406** - 配送选项，带有按国家的定价和可选的按重量或距离计费规则 +- **kind 16** - 订单消息：创建（type 1）、付款请求（type 2）、状态更新（type 3）和配送更新（type 4） +- **kind 14** - 买家与商家之间的一般沟通 +- **kind 17** - 付款收据 +- **kind 31555** - 商品评价，寻址到特定的卖家 pubkey 和广告 `d` tag + +商家的付款偏好通过其 kind `0` 个人资料元数据上的 `payment_preference` tag 声明，客户端则通过 [NIP-89](/zh/topics/nip-89/) 应用推荐发现兼容的应用。订单沟通构建在 [NIP-17](/zh/topics/nip-17/) 私密消息之上，没有自己新的加密方案。 + +该规范的决定性设计选择是：任何东西都不会向下继承。属于某个合集、或使用某个配送选项的广告，都用 `a` tag 显式引用它，而不是自动继承父级的设置。这是对更早的 [NIP-15](/zh/topics/nip-15/) 摊位模型的刻意背离，在那个模型里，商品会默默继承其摊位的货币和运费表。 + +### 示例：订单创建（kind 16，type 1） + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +## 为何重要 + +单靠 NIP-99 只标准化了广告本身，即一条签名的、可寻址的分类广告。在 Gamma Markets 之前，每个在 NIP-99 上构建真实电商的客户端都会为配送、结账和评价发明自己的私有约定，这意味着两个符合 NIP-99 的客户端可以各自正确渲染广告，却没有共同的方式在彼此之间完成一笔订单。Gamma Markets 在不触动 NIP-99 广告格式本身的前提下填补了这一空白，因此既有的 NIP-99 广告无需修改即保持有效。 + +## 实现 + +- [Shopstr](https://github.com/shopstr-eng/shopstr) - Nostr 市场，编写该规范的四个项目之一 +- [Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) - 市场协议，在同一设计空间中构建自己的订单状态与结账流程 + +--- + +**主要来源：** +- [Gamma Markets 规范仓库](https://github.com/GammaMarkets/market-spec) +- [NIP-99 电商用例扩展，PR #1784](https://github.com/nostr-protocol/nips/pull/1784) - 从 NIP-99 规范文档链接到 Gamma Markets 规范的已合并链接 + +**提及于：** +- [Newsletter #31：NIP Deep Dive：NIP-99 与 Gamma Markets 商务扩展](/zh/newsletters/2026-07-15-newsletter/#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) + +**另见：** +- [NIP-99: Classified Listings](/zh/topics/nip-99/) +- [NIP-15: Nostr Marketplace](/zh/topics/nip-15/) +- [NIP-17: Private Direct Messages](/zh/topics/nip-17/) diff --git a/content/zh/topics/nip-4e.md b/content/zh/topics/nip-4e.md new file mode 100644 index 0000000..df3cd2b --- /dev/null +++ b/content/zh/topics/nip-4e.md @@ -0,0 +1,46 @@ +--- +title: "NIP-4E：将加密与身份解耦" +date: 2026-07-15 +draft: false +translationOf: /en/topics/nip-4e.md +translationDate: 2026-07-15 +categories: + - NIP + - Protocol + - Encryption +--- + +NIP-4E 是 fiatjaf 提出的一份开放草案，用于在用户自己的多台设备之间共享私密数据，而无需每台设备都持有该用户的主 Nostr 身份密钥。它尚未合并，仍是一份 `draft`/`optional` 提案。 + +## 它要解决的问题 + +许多既有 NIP，包括 NIP-51 列表和 NIP-60 Cashu 钱包，都使用身份密钥把数据从用户加密给用户自己，以便日后在任意设备上读回。当身份密钥无法直接访问时，这种做法就会失效，例如远程签名器由 FROST 门限分片、MuSig2 或托管的安全飞地保护时，每次加密和解密都需要与该签名器往返一次。当签名密钥位于远程 bunker 中时，它也让离线加密变得不可能。 + +## 工作方式 + +NIP-4E 把按设备的「客户端密钥」与一把并非用户身份密钥的共享「加密密钥」分离开： + +1. 用户设置的第一个客户端生成一个随机加密密钥对，并在一个由用户身份密钥签名的 `kind:10044` 事件中公布其公钥部分。 +2. 任何想为该用户加密或解密数据的其他客户端，都针对公布的加密密钥而非身份密钥计算其 Diffie-Hellman 共享密钥。 +3. 当第二台设备安装新客户端时，该客户端生成自己的本地「客户端密钥」，并发布一个 `kind:4454` 公告（同样由用户的身份密钥签名），请求第一个客户端与它共享加密密钥。 +4. 原客户端检测到新的 `kind:4454` 公告后，使用 [NIP-44](/zh/topics/nip-44/) 把共享加密密钥加密给新客户端的密钥并发布，使新客户端此后可以解密并使用它。 + +结果是，一旦客户端在本地持有共享加密密钥，加密和解密就完全不需要再询问身份密钥签名器；身份可以采用远程签名器方案（FROST、MuSig2、托管飞地），而普通加密仍然快速并可离线工作。 + +## 为何重要 + +NIP-4E 被引用为其他提案的基础，这些提案需要一把云盘范围或账户范围的对称密钥，而不必为每次加密/解密调用都依赖远程签名器，其中包括一个私密加密云盘提案（[PR #2412](https://github.com/nostr-protocol/nips/pull/2412)），以及同一想法在 NIP-17 上更狭窄的版本（[PR #2361](https://github.com/nostr-protocol/nips/pull/2361)）。两者都与 NIP-4E 本身一样仍处于开放状态，使这里成为协议中一个活跃且尚未定论的领域，而不是一块已经完成的构件。 + +--- + +**主要来源：** +- [NIP-4E 草案，PR #1647](https://github.com/nostr-protocol/nips/pull/1647) + +**提及于：** +- [Newsletter #31：新开：扩展 NIP-4E 的私密加密云盘](/zh/newsletters/2026-07-15-newsletter/#open-private-encrypted-drive-extends-nip-4e) + +**另见：** +- [NIP-44: Encrypted Payloads](/zh/topics/nip-44/) +- [NIP-17: Private Direct Messages](/zh/topics/nip-17/) +- [NIP-46: Nostr Connect](/zh/topics/nip-46/) +- [FROST](/zh/topics/frost/) diff --git a/content/zh/topics/proofmode.md b/content/zh/topics/proofmode.md new file mode 100644 index 0000000..0c565ac --- /dev/null +++ b/content/zh/topics/proofmode.md @@ -0,0 +1,36 @@ +--- +title: "ProofMode" +date: 2026-07-15 +draft: false +translationOf: /en/topics/proofmode.md +translationDate: 2026-07-15 +categories: + - Media + - Provenance +--- + +[ProofMode](https://proofmode.org/) 是由 Guardian Project、WITNESS 和 Okthanks 打造的开源媒体来源证明工具包，在拍摄的那一刻就为照片和视频附上可验证的真实性与保管链数据。它并非 Nostr 专用；携带 ProofMode 数据的 Nostr 客户端是在集成一个既有的外部标准，而不是新增一层协议。 + +## 工作方式 + +ProofMode 的 Capture 组件在拍摄过程中把来源元数据直接嵌入媒体文件，支持与 Content Authenticity Initiative（CAI）、Content Credentials（CR）和 C2PA 相同的互操作标准。独立的 Verify 组件检查音频、图像和视频文件，在这些元数据中查找 AI 生成或后期编辑的迹象；Preserve 组件则负责把底层证明数据冗余地存储在去中心化网络上，以便长期归档。Develop SDK 让应用无需自行构建来源证明格式即可集成拍摄与验证。 + +## 为何重要 + +对于 Nostr 视频或图像客户端来说，携带 ProofMode 数据意味着观看者拥有一种外部的、跨平台的方式，去核实某段媒体是否如其所称那样被拍摄、之后是否被悄然改动，而不必把发布客户端或 relay 当作信任来源。这一区别在片段被下载或重新编码的副本上体现得最明显：只有能够经受住下载以及客户端所加水印的来源数据，才能让文件离开生成它的应用之后，那份证明依然可核验。 + +## 实现 + +- [Divine](https://github.com/divinevideo/divine-mobile) - 短视频 Nostr 客户端；在带水印片段的下载过程中保留 ProofMode 来源数据 + +--- + +**主要来源：** +- [ProofMode](https://proofmode.org/) + +**提及于：** +- [Newsletter #17](/zh/newsletters/2026-04-29-newsletter/) +- [Newsletter #31：Divine Mobile 1.0.16 带来更深入的视频编辑器、静态加密和 ProofMode 来源证明](/zh/newsletters/2026-07-15-newsletter/#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) + +**另见：** +- [Blossom](/zh/topics/blossom/) From ec5595b3dd90a24f62ff2a190604895b73a529d2 Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Thu, 16 Jul 2026 08:42:50 +0000 Subject: [PATCH 10/10] Add durable, resumable translation driver (scripts/translate.sh) Translation previously ran as a detached background process with no checkpointing, so a gateway restart or API timeout killed the run with no status and no way to resume. Newsletter #31 lost its translation run twice this way. This adds the deterministic half of the workflow: status per-language view of what is missing (resume point) verify files, cross-language link leaks, translated-ness commit verify then commit one language (a checkpoint) Generation stays an LLM step. Everything around it is now scripted, so a crash loses at most one language and 'status' says exactly where to resume. Verified against all 9 languages of #31 (all pass), plus negative tests for a missing topic page, an untranslated English copy, and a cross-language link leak (all correctly detected). --- scripts/translate.sh | 265 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 265 insertions(+) create mode 100755 scripts/translate.sh diff --git a/scripts/translate.sh b/scripts/translate.sh new file mode 100755 index 0000000..2cb07c0 --- /dev/null +++ b/scripts/translate.sh @@ -0,0 +1,265 @@ +#!/usr/bin/env bash +# translate.sh — durable, resumable newsletter translation driver. +# +# WHY THIS EXISTS +# --------------- +# Translation used to run as a detached background process (`nohup hermes chat &`). +# That has no durability: a gateway restart, an API timeout, or an OOM killed the run +# with no status, no checkpoint, and no way to resume. Newsletter #31's translation +# died this way twice and had to be reconstructed by hand. +# +# The fix is not a smarter background process. It is checkpointing: +# 1. status — deterministically compute what is missing, per language (resumable) +# 2. verify — mechanically check one language's output (encoding, link leaks) +# 3. commit — commit ONE language = one durable checkpoint +# +# Generation itself needs an LLM and stays an Opus agent. Everything around it is +# deterministic and lives here. A crash loses at most the one in-flight language; +# `status` always tells you exactly where to resume. +# +# USAGE +# scripts/translate.sh status +# scripts/translate.sh verify +# scripts/translate.sh commit +# +set -uo pipefail + +LANGS=(es pt de fr it ja ko nl zh) +REPO_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)" +cd "$REPO_ROOT" || exit 1 + +die() { echo "error: $*" >&2; exit 1; } + +lang_name() { + case "$1" in + es) echo "Spanish" ;; pt) echo "Portuguese" ;; de) echo "German" ;; + fr) echo "French" ;; it) echo "Italian" ;; ja) echo "Japanese" ;; + ko) echo "Korean" ;; nl) echo "Dutch" ;; zh) echo "Chinese" ;; + *) echo "$1" ;; + esac +} + +en_newsletter() { echo "content/en/newsletters/$1-newsletter.md"; } + +# Topic slugs the English issue actually links to. This is how we detect "new topic +# pages" without a hardcoded list: any topic the issue references that is missing in a +# target language needs translating. +referenced_topics() { + local src; src="$(en_newsletter "$1")" + [ -f "$src" ] || return 0 + grep -oE '/topics/[a-z0-9-]+' "$src" | sed 's|/topics/||' | sort -u +} + +# Missing topic pages for one language. +missing_topics() { + local lang="$1" date="$2" slug + while read -r slug; do + [ -n "$slug" ] || continue + [ -f "content/$lang/topics/$slug.md" ] || echo "$slug" + done < <(referenced_topics "$date") +} + +# STALE: English source committed more recently than the translation. +is_stale() { + local lang="$1" date="$2" + local tgt="content/$lang/newsletters/$date-newsletter.md" + [ -f "$tgt" ] || return 1 + local en_t tr_t + en_t="$(git log -1 --format=%ct -- "$(en_newsletter "$date")" 2>/dev/null)" + tr_t="$(git log -1 --format=%ct -- "$tgt" 2>/dev/null)" + [ -n "$en_t" ] && [ -n "$tr_t" ] && [ "$en_t" -gt "$tr_t" ] +} + +cmd_status() { + local date="${1:?usage: translate.sh status }" + [ -f "$(en_newsletter "$date")" ] || die "no English source: $(en_newsletter "$date")" + + local topics_n; topics_n="$(referenced_topics "$date" | wc -l)" + echo "Issue $date — English source references $topics_n topic pages" + echo "" + printf "%-4s %-11s %-11s %-8s %s\n" "LANG" "NAME" "NEWSLETTER" "TOPICS" "STATUS" + echo "---------------------------------------------------------------" + + local incomplete=0 + for lang in "${LANGS[@]}"; do + local nl_file="content/$lang/newsletters/$date-newsletter.md" + local has_nl status miss miss_n + [ -f "$nl_file" ] && has_nl="present" || has_nl="MISSING" + miss="$(missing_topics "$lang" "$date")" + miss_n="$(echo -n "$miss" | grep -c . || true)" + + if [ "$has_nl" = "MISSING" ]; then + status="TODO (full)"; incomplete=$((incomplete+1)) + elif [ "$miss_n" -gt 0 ]; then + status="TODO ($miss_n topics)"; incomplete=$((incomplete+1)) + elif is_stale "$lang" "$date"; then + status="STALE (retranslate)"; incomplete=$((incomplete+1)) + else + status="done" + fi + + printf "%-4s %-11s %-11s %-8s %s\n" \ + "$lang" "$(lang_name "$lang")" "$has_nl" "$((topics_n - miss_n))/$topics_n" "$status" + [ "$miss_n" -gt 0 ] && echo " missing topics: $(echo $miss | tr '\n' ' ')" + done + + echo "" + if [ "$incomplete" -eq 0 ]; then + echo "All ${#LANGS[@]} languages complete for $date." + else + echo "$incomplete language(s) need work. Resume with those only — completed languages are already committed." + fi +} + +cmd_verify() { + local lang="${1:?usage: translate.sh verify }" + local date="${2:?usage: translate.sh verify }" + local nl_file="content/$lang/newsletters/$date-newsletter.md" + local fail=0 + + echo "Verifying $(lang_name "$lang") ($lang) for $date" + + if [ -f "$nl_file" ]; then + echo " ok newsletter present ($(wc -l < "$nl_file") lines)" + else + echo " FAIL newsletter missing: $nl_file"; fail=1 + fi + + local miss; miss="$(missing_topics "$lang" "$date")" + if [ -z "$miss" ]; then + echo " ok all referenced topic pages present" + else + echo " FAIL missing topic pages: $(echo $miss | tr '\n' ' ')"; fail=1 + fi + + # Internal links must use this language's prefix, not another language's. + local leaks + leaks="$(grep -ohE "\(/(en|es|pt|de|fr|it|ja|ko|nl|zh)/topics/" \ + "$nl_file" content/"$lang"/topics/*.md 2>/dev/null \ + | grep -v "(/$lang/topics/" | sort -u)" + if [ -z "$leaks" ]; then + echo " ok no cross-language link leaks" + else + echo " FAIL link leaks to other languages: $(echo $leaks | tr '\n' ' ')"; fail=1 + fi + + # Is it actually translated? + # + # NOTE: do NOT gate Latin-script languages on a diacritic count. Real Dutch prose + # carries ~5 diacritics per issue (ë/ï are rare), so any sane threshold either + # rejects valid Dutch or is too low to mean anything. Caught during testing: a + # >10 threshold failed the correct, committed nl translation. + # + # So: CJK/Hangul get a native-script count (unambiguous, thousands of chars). + # Latin-script languages get checked for untranslated English prose instead — + # that is the failure we actually care about. + if [ -f "$nl_file" ]; then + case "$lang" in + ja|ko|zh) + local hits + hits="$(python3 - "$nl_file" "$lang" <<'PY' +import sys +path, lang = sys.argv[1], sys.argv[2] +t = open(path, encoding="utf-8").read() +ranges = {"ja": [("぀","ヿ"), ("一","鿿")], "ko": [("가","힯")], "zh": [("一","鿿")]} +print(sum(1 for c in t if any(a <= c <= b for a, b in ranges[lang]))) +PY +)" + if [ "${hits:-0}" -gt 100 ]; then + echo " ok script: $hits native characters" + else + echo " FAIL script: only ${hits:-0} native characters — likely untranslated"; fail=1 + fi + ;; + *) + # Distinctive English prose that cannot survive a real translation. + local eng + eng="$(grep -oF -e "Welcome back to Nostr Compass" \ + -e "your weekly guide to Nostr" \ + -e "Tagged releases bring" \ + -e "On the unreleased side" \ + "$nl_file" 2>/dev/null | sort -u)" + if [ -z "$eng" ]; then + echo " ok translated (no untranslated English marker prose)" + else + echo " FAIL untranslated English found: $(echo $eng | tr '\n' '|')"; fail=1 + fi + # Diacritics are reported for information only, never a gate. + local dia + dia="$(python3 - "$nl_file" "$lang" <<'PY' +import sys +path, lang = sys.argv[1], sys.argv[2] +marks = {"es":"áéíóúñü","pt":"ãõáéíóúçâêô","de":"äöüß","fr":"éèêëàâçôûùîï","it":"àèéìòù","nl":"ëï"} +t = open(path, encoding="utf-8").read() +print(sum(1 for c in t if c in marks.get(lang, ""))) +PY +)" + echo " info diacritics: ${dia:-0} (informational; Dutch is legitimately low)" + ;; + esac + fi + + # German ASCII-substitute check — the #1 documented quality defect. + if [ "$lang" = "de" ] && [ -f "$nl_file" ]; then + local sub + sub="$(grep -oiE '\b(fuer|ueber|groesser|schluessel|oeffentlich|aenderung|moeglich)\b' "$nl_file" 2>/dev/null | sort -u)" + if [ -z "$sub" ]; then echo " ok no ASCII substitutes for umlauts" + else echo " FAIL ASCII substitutes instead of umlauts: $(echo $sub | tr '\n' ' ')"; fail=1; fi + fi + + # Traditional-Chinese probe (spec requires Simplified). + if [ "$lang" = "zh" ] && [ -f "$nl_file" ]; then + local trad; trad="$(grep -oE '們|開|關|實|協|訊|網|據' "$nl_file" 2>/dev/null | wc -l)" + if [ "$trad" -eq 0 ]; then echo " ok Simplified Chinese (no Traditional forms)" + else echo " FAIL $trad Traditional-Chinese characters found; spec requires Simplified"; fail=1; fi + fi + + [ "$fail" -eq 0 ] && echo " PASS" || echo " FAILED" + return "$fail" +} + +cmd_commit() { + local lang="${1:?usage: translate.sh commit }" + local date="${2:?usage: translate.sh commit }" + + cmd_verify "$lang" "$date" || die "verify failed for $lang — not committing" + + local files=("content/$lang/newsletters/$date-newsletter.md") + local slug + while read -r slug; do + [ -n "$slug" ] && [ -f "content/$lang/topics/$slug.md" ] && files+=("content/$lang/topics/$slug.md") + done < <(referenced_topics "$date") + + # Stage ONLY this language's files for this issue. Never `git add .` — the working + # tree routinely holds unrelated scratch (workspace state, lockfiles, stray scripts). + git add -- "${files[@]}" 2>/dev/null + + if git diff --cached --quiet; then + echo "nothing new to commit for $lang (already committed)" + return 0 + fi + + local n; n="$(basename "$(en_newsletter "$date")" | sed 's/-newsletter.md//')" + git commit -q -m "Add $(lang_name "$lang") translation for Newsletter $date and topic pages" + echo "committed $(lang_name "$lang") — checkpoint saved ($(git rev-parse --short HEAD))" +} + +case "${1:-}" in + status) shift; cmd_status "$@" ;; + verify) shift; cmd_verify "$@" ;; + commit) shift; cmd_commit "$@" ;; + *) cat < what is missing, per language (safe to run anytime) + verify check one language: files, links, encoding + commit verify then commit one language (a checkpoint) + +Languages: ${LANGS[*]} + +Generation stays an Opus agent (see skills/_COMPASS/agents/TranslationAgent.md). +Run one language at a time and commit each; a crash then loses at most one language, +and 'status' tells you exactly where to resume. +EOF + ;; +esac