🦤 Lazarus — Recuperación de datos de usuario desde el historial de los relays

En el ecosistema de Nostr, clientes y relays pueden hacer un nuke a tus listas de datos — follows, mutes, marcadores — ya sea por negligencia o por malicia. Esto compromete la experiencia de usuario: un ecosistema aún inmaduro, que no prevé este tipo de situaciones molestas, puede hacer creer al usuario que el protocolo está roto, cuando en realidad sus listas siguen ahí — solo hay que rescatarlas de una actualización negligente o malicioso.

Lazarus es una especificación abierta de Nostr para recuperar datos — listas de follows, mutes, perfil, marcadores y más — directamente del historial de los relays, sin necesidad de una copia de seguridad previa.

El problema que resuelve

Los clientes de Nostr sobrescriben los eventos reemplazables sin leerlos primero. Cuando un cliente toca tu lista de follows, mutes, perfil o pins, lo que publica reemplaza lo que había — y si un cliente pícaro (rogue) la vacía, pierdes horas de curación.

La clave: hasta que el relay expira los datos, tu historial es un registro de deshacer completo (undo log). Lazarus es el protocolo para usarlo: escanear el conjunto de relays, clasificar las versiones encontradas y restaurar lo destruido.

Los cuatro invariantes

• Nunca automático. Nada se restaura sin un clic explícito del usuario.
• Mostrar todo. Cada versión encontrada se muestra: conteos, marcas de tiempo, relay de origen y vacíos.
• Las "tumbas" nunca se recomiendan. Una versión vacía de una lista suele ser la huella del cliente que la destruyó: se muestra, pero jamás se recomienda (salvo donde el vacío es un estado definido, como el kind 10044).
• Tus llaves, tu publicación. La restauración usa el firmador propio del usuario. Nunca custodia de llaves.

Fuente: github.com

🦤 PosterChan — Descargas oficiales del cliente

poster.place/releases/ es el directorio web oficial para descargar el cliente de verita84 (PosterChan): el cliente Nostr que combina red social, nube personal cifrada e IA autoalojada.

Qué ofrece la url

• Instaladores oficiales para cada plataforma, firmados y servidos directamente por el desarrollador — evita mirrors de terceros o paquetes manipulados.
• Historial de versiones: cada release como instantánea identificada por su event id, en línea con la filosofía del proyecto de publicar todo como eventos Nostr.
• Notas de versión: qué cambió en cada entrega (nuevas funciones, correcciones, mejoras de seguridad).

Fuente: poster.place

🦤 PosterChan: cliente Nostr, relay de web-of-trust y nube personal autoalojada

PosterChan (poster.place), desarrollado por verita84, es mucho más que un cliente web de Nostr: combina red social, nube personal cifrada e IA autoalojada, todo viviendo como eventos Nostr sobre un relay que tú puedes correr

Qué es

• Cliente Nostr completo: feeds, hilos, perfiles, DMs, comunidades (Concord), mini apps, juegos, streaming en vivo (NIP-53) y llamadas de voz/video por WebRTC zapstore.dev.
• Relay de web-of-trust (wss://relay.poster.place/): solo almacena notas de autores de confianza y de quienes estos siguen — sin spam ni ruido. Lectura abierta para todos; publicación restringida al WoT
• Nube personal: notas, calendario, contactos, archivos, fotos, contraseñas, marcadores, correo y sincronización de carpetas — todo como eventos Nostr cifrados en tu propio relay, sin cuentas con terceros, sin facturación por asiento y sin proveedor custodiando las llaves nostr-proto.org.

Zaps en Monero ⚡ ɱ

Lo más destacable para quien valora la privacidad: propina cualquier publicación o persona en Monero (XMR) con el botón ɱ, desde la micromoneda integrada o desde la wallet que ya uses — "dinero privado para una red privada", justo al lado de los zaps de Lightning

IA y multimedia (con servidor opcional)

• IA autoalojada: chat con LLMs (nativos vía llama.cpp en CPU/CUDA/ROCm o cualquier API compatible con OpenAI), generación de imágenes, música y video en tu propia GPU, metabuscador privado con resúmenes, y bots autónomos en Telegram, Pleroma y Nostr
• Servidor multimedia compatible con Jellyfin: carpetas o NAS convertidos en bibliotecas privadas, con transcodificación NVIDIA, AMD/VA-API o CPU. Los catálogos van cifrados en el relay local; los archivos multimedia no se federan
• Sin servidor, la app sigue funcionando en modo social: mensajes, notificaciones, notas, contraseñas, presupuesto, llamadas y juegos

Modelo de seguridad

• El relay guarda ciphertext: los contenidos se cifran en el dispositivo antes de salir zapstore.dev.
• Autoalojable por diseño: la app apunta a tu propia instancia; poster.place es solo el valor por defecto zapstore.dev.
• Accesible desde navegador, escritorio, Android (Zapstore) y cualquier cliente CalDAV/CardDAV que ya tengas nostr-proto.org.
• Inicio de sesión: extensión NIP-07, Amber, firmador remoto NIP-46 (bunker://), nsec que nunca sale del navegador, o cuenta de Google poster.place.

Fuentes:

• poster.place
• relay.poster.place
• zapstore.dev

🔏 🔏 🔏 NIP-PS: una capa común de información, no un órgano de gobernanza

Acerca de

NIP-PS no establece estándares. Establece una capa común de información a partir de la cual los estándares pueden surgir. El mercado de implementaciones es la evidencia, no el órgano de gobernanza.

Borradores

Un borrador es una propuesta editable con un hilo de discusión. Se aconseja a los autores mantener una propuesta en borrador hasta que haya sido usada en el campo por un tiempo y haya dejado de cambiar. Se esperan implementaciones experimentales contra un borrador; simplemente no pueden presentarse aún como adopción.

Versiones publicadas (releases)

Una versión publicada es una instantánea congelada de un borrador. Es inmutable y se identifica por su event id, de modo que un implementador siempre puede decir exactamente qué implementó. Cualquier cambio es una nueva versión. Solo la primera versión de una propuesta se marca como la original, de manera que los listados piden a los relés un solo evento por propuesta y un largo historial de versiones no le cuesta nada a nadie más. Cualquiera puede publicar una copia de seguridad de una versión para que sobreviva a la pérdida de relés y a las solicitudes de eliminación.

Afirmaciones de adopción

Un implementador publica una afirmación: "implementamos esta versión". Una sola afirmación activa por implementador por propuesta, que se reemplaza cuando pasa a una versión más reciente. Una afirmación es una declaración, no un hecho. Publicar una no la hace verdadera.

Aquí no hay números de NIP, así que decir qué estándar implementas — en un README, un changelog o la descripción de un handler — usa el formato que la especificación de abajo define: título, versión, autor y el event id de la versión publicada. Para una versión ficticia titulada NIP-EXAMPLE, versión 1.2, se lee así:

Implementamos NIP-EXAMPLE v1.2 por npub1qgm4k…sq6wz7c (0000…9f8e)

Esos valores son deliberadamente falsos. El npub, npub1qgm4k3t2z9rfdvxh6yl0cw5ep8ucn7a2s3jd4fvt8xg9mkl5r2hsq6wz7c, no es una clave real y el id no es un evento real, de modo que nada en el ejemplo puede confundirse con una propuesta real. Los ids acortados conservan ambos extremos — los primeros cuatro y los últimos cuatro caracteres — para que nunca se confundan con un prefijo. El evento de la afirmación lleva el id completo de la versión y el id de la especificación.

Revisiones

Cualquiera puede revisar una versión publicada (recomendar, no recomendar, inseguro) o una afirmación de adopción (exacta, inexacta). Los dos vocabularios nunca se mezclan: que una especificación no te guste no dice nada sobre si un implementador existe, y confirmar a un implementador no dice nada sobre si la especificación es buena.

El lente

Cada clasificación es un punto de vista. Las afirmaciones y revisiones se ponderan mediante puntuaciones de confianza de las fuentes que tú elijas: proveedores de aserciones de confianza NIP-85, el grafo de cualquier npub, o el tuyo propio. El lente activo siempre se muestra, puede ser cambiado por cualquiera — con sesión iniciada o no — y puede desactivarse para ver el mercado en crudo. El filtrado degrada y colapsa. Nunca oculta.

Sin autoridad

No hay un conjunto oficial por defecto, no hay numeración global y no existe ningún rol que pueda ocultar una propuesta o una afirmación. El grafo del operador es el punto de vista anónimo por defecto, y es una configuración, no una puerta con cerradura.

Fuente: nostr-ps.top

🍎 Orchard — La tienda Flatpak sin permisos, construida sobre Nostr

geektoshi anuncia su nuevo proyecto al público y suma un aporte más a Nostr, con la calidad y creatividad que lo caracterizan.

El anuncio

Esta noche lanzo la primera versión de Orchard, una tienda Flatpak sin permisos para Linux:

• No hay intermediarios
• No alojo los binarios de nadie
• Nada necesita aprobación

Para desarrolladores

• Publica desde tu propio registry y firma unos cuantos eventos de Nostr describiendo la aplicación
• Un archivo de prueba (proof file) en tu repositorio hace que el enlace sea verificable
• Consulta PUBLISHING.md para una guía paso a paso y un flujo de CI de ejemplo que hace todo facilísimo — tag y push, eso es todo

Para usuarios

• Es una tienda Flatpak real con soporte integrado de Flathub, así que ya hay miles de aplicaciones disponibles
• Todas las apps publicadas en Nostr tienen verificación de publicador, repositorio y digest, para que puedas confiar en que la app es lo que dice ser
• Inicia sesión vía nostrconnect (bunker en la próxima versión)
• Reseña tus aplicaciones favoritas y mira lo que ha dicho la gente de tu red de confianza (web of trust)

Repositorio: https://github.com/Letdown2491/orchard

Este tipo de iniciativas demuestran que Nostr, con su filosofía e implementación, está abierto a cualquier tipo de público que quiera contribuir al protocolo. Este cliente (monostr) viene de la comunidad de Monero, que ha encontrado en Nostr un protocolo con el que comparte los principios informáticos de ambos grupos: descentralización, resistencia a la censura y privacidad

monostr — Cliente de Nostr para Android con propinas en Monero (XMR)

Resumen: monostr es un cliente de Nostr para Android creado por schmidt1024, software libre (AGPL-3.0-or-later) y en beta pública. Su característica distintiva: propinas en Monero sin Lightning, sin custodio y sin billetera dentro de la app — los fondos salen directamente de tu propia billetera XMR.

¿Qué es?

• Cliente de la red social Nostr para Android
• Software libre: AGPL-3.0-or-later, con builds reproducibles
• Sin Lightning, sin custodio, sin billetera interna
• Disponible en Zapstore, GitHub (vía Obtainium) y en revisión para F-Droid
• 8 idiomas: inglés, alemán, español, francés, italiano, portugués, ruso y turco

Funciones

Cliente Nostr completo

• Feed, hilos y perfiles con publicaciones y respuestas
• Me gusta, repost, citar y responder
• Mensajes privados (NIP-17)
• Marcadores y silenciados privados
• Subida de imágenes, búsqueda y notificaciones
• Inicio de sesión con Amber (firma externa) o con clave
• Tema claro/oscuro (incluyendo negro OLED)
• Reacciones con emojis, deshacer likes y reposts
• Soporte de mXMR (millinero) y prueba de trabajo de 8 bits
• Vistas previas de enlaces (desactivadas por defecto — privacidad primero)

Propinas en Monero (XMR)

• Toca el símbolo ɱ debajo de una nota o perfil, elige el monto
• Tu propia app de billetera (Monerujo, Cake Wallet, Feather, Unstoppable, monfluo, etc.) se abre con el pago listo
• La app nunca toca tus fondos

Cómo implementa las propinas en Monero

El diseño aprovecha una característica criptográfica única de Monero: las claves de vista (view keys).

1. Enviar la propina → Tu billetera XMR se abre con el pago listo.
2. Detección del pago → El destinatario registra su dirección XMR y su clave de vista con un servidor watcher (watcher.monostr.com por defecto, cualquiera puede ejecutar el suyo). La clave de vista permite ver pagos entrantes sin poder gastarlos — solo la clave de gasto (nunca compartida) puede mover los fondos.
3. Confirmación en Nostr → El watcher publica un recibo firmado en Nostr (wss://relay.monostr.com), y la propina aparece bajo la nota.

Puntos clave del diseño

• ✅ Sin custodio — nadie más que el destinatario puede gastar los fondos
• ✅ Sin Lightning — todo on-chain en Monero mainnet
• ✅ Propinas anónimas posibles
• ✅ Verificable y auditable — los recibos son eventos firmados publicados en relays de Nostr

⚠️ Advertencia

Es una beta. Las propinas son XMR real en mainnet. Empieza con montos pequeños y verifica la dirección registrada para recibir.

Enlaces: monostr.com · Repositorio en GitHub · Zapstore · Obtainium

Nostr es un protocolo agnóstico, sin ataduras a una sola comunidad ni a una sola criptomoneda, y la llegada de proyectos desde el ecosistema Monero confirma que su diseño abierto y minimalista permite que cualquier grupo con valores afines construya sobre él libremente.