Prismas de lightning
Un aspecto que aún está tremendamente poco utilizado es la programabilidad de bitcoin. Existen cosas simples como las transacciones programadas (agendadas, temporizadas) y los pagos múltiples automatizados, pero indudablemente seguimos atrapados en el pensamiento convencional acerca del flujo de los sats.
Quisiera proponer una idea simple que fue compartida conmigo hace unos meses, con la esperanza de que se distribuya ampliamente y, en el mejor de los casos, alguien la implemente. (O una mejor versión de ella).
Es la siguiente:
Todo el crédito a Mr. Kukks, quien está oficialmente sin tiempo[^1] para implementarla él mismo.
Prismas de lightning
Un prisma de lightning es un constructo que permite "flujos de división de valor entre direcciones de lightning", parafraseando al autor.
Básicamente, sus características son: - un prisma se identifica con una dirección de lightning (o algo similar) - un prisma tiene un o múltiples receptores - un prisma puede ser receptor de otro, es decir, formar una "cadena de prismas" - las divisiones se definen programáticamente, esto es, con código
Este constructo simple permite todo tipo de casos de uso y puede ser implementado en la capa de las aplicaciones, sin ningún cambio en los protocolos de Bitcoin o Lightning.
Un ejemplo obvio es la división de valor para artículos de blogs y formas similares de escritura de extensión considerable. Imagina si cada artículo (o capítulo de un libro) tuviera su propia dirección de Lightning, repartiendo valor entre autor, editor, ilustrador y revisores del texto automáticamente.
El concepto de esas divisiones de valor ya existe en el podcasting 2.0, donde se aplica ampliamente a podcasts y episodios. Podría argumentarse que tener un identificador separado para el constructo es la evolución natural de esa forma de compartir valor, ya que sería más fácil conceptualizarlos y encadenarlos entre sí.
Otro caso de uso obvio es compartir los zaps de Nostr. Imagina que cada tweet citado que es zappeado se divide automáticamente, pasando el 50% (o el monto configurado por el usuario) a la nota original. O imagina un prisma creado ad-hoc, repartiendo los zaps equitativamente para todos los etiquetados en una nota.
¡Splits de sats para nostr! ¿acaso hay algo mejor?
Como los pagos son redirigidos, cada prisma actúa como una especie de proxy. Esto puede ser útil tanto para organizaciones como para individuos, ya que tu identificador de pago permanece igual incluso si tu infraestructura subyacente o proveedor de billetera cambian.
Problemas y mejoras
Existen dos preocupaciones centrales: comisiones y privacidad. No sólo hay que tener en cuenta las comisiones derivadas de la división y redirección de los pagos, sino también el hecho de que las direcciones ligthning se basan en IP, lo que tiene ciertas implicaciones de privacidad. Podríamos usar LNURL sobre nostr -de nuevo, créditos para Kukks- que trae a colación la siguiente pregunta: ¿son las direcciones lightning (Lightning Addresses) el nivel de abstracción correcto para los prismas de lightning?
Al fin y al cabo, no queremos enviar sats a direcciones sino a personas. Si nostr continua tomando vuelo, podría convertirse en sí mismo en la libreta de direcciones global para ese tipo de cosas, en otras palabras, el lugar al que se acude para buscar información de pago de personas, organizaciones y otras entidades. En el futuro, un prisma podría tener múltiples identificadores nprofile o npub como destinos, detrás de los cuales está la información de pago concreta.
Los identificadores no tienen que ser necesariamente direcciones lightning (Lightning Addresses). ¡Npubs o similares también pueden funcionar!
En cualquier caso, en este punto, no estoy demasiado preocupado por los detalles de la implementación. Estoy preocupado por una falta de imaginación, que es a lo que este post intenta responder.
Hablando de imaginación: ¿Por qué no tenemos ninguna billetera que automáticamente mueva sats a otra a partir de un cierto umbral? Estoy más que feliz de tener dinero para el almuerzo en una billetera custodial (delegada, controlada por terceros), pero una vez que alcanza tres meses de renta ya no estoy tan cómodo. ¿Por qué no puede la billetera automáticamente enviar el excedente de sats a mi dirección lightning soberana una vez que contiene más que el monto de una cena? O hacer un loop-out mensualmente para mover mis sats a almacenamiento frío?
Bueno, divago.
Una mejora que me gustaría ver es que se provean los prismas de forma transparente. En el mejor caso, los usuarios deberían poder ver cómo los pagos se reparten, de una forma fácil de entender y verificar. Una posibilidad es transmitir un evento reemplazable parametrizado (definido por el NIP-33) cada vez que un prisma se crea o actualiza. Claro que, dependiendo del caso de uso, puede tener sentido mantener el/los lugar/es finales ocultos del público.
Estoy seguro de que existen más problemas y muchas otras mejoras, pero, como siempre, lo perfecto es enemigo de lo bueno, así que hablemos sobre soluciones prácticas que pueden ser implementadas y usadas ahora mismo.
Implementación
Los prismas basados en direcciones lightning pueden ser construidos hoy sin demasiado esfuerzo. Podrías incluso construirlo tu mismo sin ninguna experiencia programando utilizando dos extensiones de LNbits: scrub y split. Agrega satdress encima para darle a cada billetera su propia dirección lightning y ¡voilà!, tienes un prisma de lightning. Puedes incluso construir una buena interfaz sobre él, ya que todo lo anterior puede ser creado programáticamente con simples llamadas de API.
Hice todo eso (excepto el "construir una buena interfaz sobre él) para juguetear con la idea. Sí, es algo precaria y probablemente no sea la solución más estable o elegante, pero más o menos funciona y puede ser utilizada hoy.
La dirección [email protected] mostrada arriba es un ejemplo en funcionamiento[^2]. Va a dividir los pagos 50/50 entre Kukks y yo (Gigi), dirigiendo los sats a nuestras respectivas direcciones lightning soberanas, provistas por nuestras instancias de BTCPay Server.
Imagino múltiples servicios siendo creados con una correcta implementación, cargando una pequeña comisión por dicho servicio (sic). (Tal como fue mencionado anteriormente, alguna especie de comisión será requerida por las comisiones de enrutado, ya que los pagos son redirigidos a direcciones externas).
Mi esperanza es que ese tipo de ideas y constructos novedosos se vuelvan más prevalentes mientras se van volviendo más prevalentes los zaps y pagos V4V similares, como también la red lightning en general. Claro que, en el mejor escenario, tendremos esas herramientas integradas nativamente a nivel del protocolo, pero no veo razón por la que no deberíamos experimentar un poco con lo que tenemos hoy, incluso si las soluciones son imperfectas. Hasta que el Bolt12 y similares sean ubicuos, ensamblar algo que simplemente funcione no es una idea tan terrible[^3].
Palabras finales
Espero que esta idea encuentre adopción amplia entre escritores y otros creadores de contenido, tal como la idea de "streaming sats" -y los splits de esos streams de valor- encontraron amplia adopción entre podcasters.
Lo que aún falta es adjuntar información de pago a eventos individuales (en lugar de a perfiles) para que cada contenido tenga su propia información de pago. Tal vez sea tan simple como extender la metadata del NIP-23, o tal vez tendría sentido tener este tipo de metadata para otros kinds también.
Ya veremos, y por "veremos", me refiero a ustedes: los desarrolladores que se sientan a diseñar y construir cosas.
Estaré alentándolos mientras hago shitpost en nostr</a></span>).
Nota del traductor:
Todas las direcciones lightning, prismas y demás se mantuvieron fieles al post original. Si quieres colaborar conmigo, puedes hacerlo a mi lnaddres: [email protected].
Traducciones
- Alemán por HiP0</a></span>) [^1]: Le prometí a Kukks no hablar sobre ello por un par de semanas para que él pudiera adelantarse e implementarlo, pero estaba preocupado en mejorar la privacidad de todos, lo que también es muy importante. [^2]: Todos los prismas mostrados en este post son ejemplos funcionales: [email protected] hace un split en partes iguales a todos los devs mencionatos en la nota de Quiet Warrior, y [email protected] es un split entre el robot y yo. También me tomé la libertad de crear [email protected], que hace un split entre Marty y Matt, y también [email protected] para los hablantes de alemán. [^3]: Creé los prismas de ejemplo de forma manual, así que me temo que, hasta que alguien construya una buena interfaz que permita a los usuarios crearlos por sí mismos, no habrá una explosión de prismas. Me gusta crear un montón de billeteras lnbits como a cualquiera, pero crear los splits y redirecciones es cansador después de un rato.
¿Te interesa ayudar? ¡Agrega una traducción!
Este trabajo de traducción, al igual que su fuente original tienen la licencia CC BY-SA 4.0, y se espera lo mismo de sus eventuales derivados.