@ ec965405:63996966

Me gusta cocinar y bailar!

@ 3bf0c63f:aefa459d

Nostr is not decentralized nor censorship-resistant

Peter Todd has been saying this for a long time and all the time I've been thinking he is misunderstanding everything, but I guess a more charitable interpretation is that he is right.

Nostr today is indeed centralized.

Yesterday I published two harmless notes with the exact same content at the same time. In two minutes the notes had a noticeable difference in responses:

The top one was published to wss://nostr.wine, wss://nos.lol, wss://pyramid.fiatjaf.com. The second was published to the relay where I generally publish all my notes to, wss://pyramid.fiatjaf.com, and that is announced on my NIP-05 file and on my NIP-65 relay list.

A few minutes later I published that screenshot again in two identical notes to the same sets of relays, asking if people understood the implications. The difference in quantity of responses can still be seen today:

These results are skewed now by the fact that the two notes got rebroadcasted to multiple relays after some time, but the fundamental point remains.

What happened was that a huge lot more of people saw the first note compared to the second, and if Nostr was really censorship-resistant that shouldn't have happened at all.

Some people implied in the comments, with an air of obviousness, that publishing the note to "more relays" should have predictably resulted in more replies, which, again, shouldn't be the case if Nostr is really censorship-resistant.

What happens is that most people who engaged with the note are following me, in the sense that they have instructed their clients to fetch my notes on their behalf and present them in the UI, and clients are failing to do that despite me making it clear in multiple ways that my notes are to be found on wss://pyramid.fiatjaf.com.

If we were talking not about me, but about some public figure that was being censored by the State and got banned (or shadowbanned) by the 3 biggest public relays, the sad reality would be that the person would immediately get his reach reduced to ~10% of what they had before. This is not at all unlike what happened to dozens of personalities that were banned from the corporate social media platforms and then moved to other platforms -- how many of their original followers switched to these other platforms? Probably some small percentage close to 10%. In that sense Nostr today is similar to what we had before.

Peter Todd is right that if the way Nostr works is that you just subscribe to a small set of relays and expect to get everything from them then it tends to get very centralized very fast, and this is the reality today.

Peter Todd is wrong that Nostr is inherently centralized or that it needs a protocol change to become what it has always purported to be. He is in fact wrong today, because what is written above is not valid for all clients of today, and if we drive in the right direction we can successfully make Peter Todd be more and more wrong as time passes, instead of the contrary.

---

See also:

• Censorship-resistant relay discovery in Nostr
• A vision for content discovery and relay usage for basic social-networking in Nostr

@ ec965405:63996966

The homie and tech mentor, Iris, ispired me to write this with their recent blog about the intersection of politics and technology.We're heeding Tim Berner Lee's call to "demand higher standards and greater accountability for our online experiences"from the powers at be by being creators and collaborators on the Internet in accordance with the 7th principle of the Contract for the Web.If my readers ever need any tech support, be sure to hit up Iris and check out Light Crystal Systemsfor your freedom tech needs.

Mi amigx y mentorx tecnológica, Iris, me inspiró a escribir esto con su reciente blog sobre la intersección de la política y la tecnología.Estamos atendiendo el llamado de Tim Berners-Lee de "exigir mayores estándares y mayor responsabilidad para nuestras experiencias en línea" por parte de los poderes establecidos, siendo creadores y colaboradores en el Internet de acuerdo con el séptimo principio del Contrato para la Web.Si mis lectores alguna vez necesitan soporte técnico, asegúrense de contactar a Iris y revisar Light Crystal Systems para sus necesidades de tecnología para la libertad.

---

"The fight for the web is one of the most important causes of our time." - Tim Berners Lee, 2018 - 30 years on, what’s next #ForTheWeb?

"La pelea por la web es una de las causas mas importantes de nuestro epoca." - Tim Berners Lee, 2018 - 30 años después, qué sigue #ForTheWeb?

Do you remember how liberating it felt to customize your Myspace with HTML, CSS,and embeded playlists? I miss that feeling. I'm blown away by the power of the web browser to facilitate meaningful connections with other humans across long distances over cable. Did you every flash a custom operating system on a device to unlock endless possibilities? Modding a jigkick battery to install custom firmwareon my God of War Edition PlayStation Portable enabled me to emulate Super Mario and customize the layout of the home screen. It added my own seasoning salt to the device and instilled confidence in my ability to mess with a computer's guts without bricking it. I fondly remember these early years of my relationship with technology that provided me with an escape from bullying at school and an abusive household while empowering me to navigate a rapidly digitizing world.

¿Te acuerdas de lo liberador que era personalizar tu Myspace con HTML, CSS y listas de reproducción integradas?Extraño esa sensación. Me sorprende el poder del navegador web para facilitar conexiones significativas con otras personas a largas distancias a través de cable. ¿Alguna vez instalaste un sistema operativo personalizado en un dispositivo para desbloquear infinitas posibilidades? Modificar una batería jigkick para instalar firmware personalizado en mi PlayStation Portable Edición God of War me permitió emular Super Mario y personalizar el diseño de la pantalla de inicio. Le añadí mi propio sazón al dispositivo y fortaleció mi confianza en mi habilidad para manipular las entrañas de un computador sin dañarlo. Recuerdo con cariño esos primeros años de mi relación con la tecnología que me proporcionaron un escape del acoso escolar y un ambiente abusivo en casa, mientras me empoderaban para navegar en un mundo que se digitalizaba rápidamente.

When Facebook and Twitter dethroned Myspace in the early 2010s as the mainstream social media platforms, however, technology started to affect my life in less liberating ways. The monetization of my attention span ruined real life relationships and probably prevented me from getting hired. I was cyberbullied and even doxed in a Facebook group on one occassion. These are humiliating experiences that I imagine some of my Millenial and Gen Z readers can relate to as being the first generations to grow up with the Internet. As much as these corporations market their software as giving people "the power to build community and bring the world closer together",the lack of accountability for their role in aiding and abetting genocide, destroying marriages, or in fueling the youth behavioral and mental health crisis(which I would argue extends to adult users of these platforms as well) are examples of the "unintended consequences of benevolent design" that Tim Berner's Lee and the Web Foundation aim to address in their movement.

Cuando Facebook y Twitter destronaron a Myspace a principios de los años 2010 como las plataformas sociales principales, la tecnología empezó a afectar mi vida de formas menos liberadoras. La monetización de mi atención arruinó relaciones en mi vida real y probablemente me impidió conseguir empleo. Fui acosado cibernéticamente e incluso expuesto públicamente en un grupo de Facebook en una ocasión. Son experiencias humillantes que imagino que algunos de mis lectores Millennials y Gen Z pueden entender, siendo las primeras generaciones criadas con Internet. Aunque estas corporaciones promocionan su software como una manera de dar a las personas "el poder de construir comunidad y acercar el mundo,"la falta de responsabilidad por su rol en ayudar y fomentar genocidios, destruir matrimonioso alimentar la crisis de salud mental y conductual de los jóvenes (lo cual, argüiría, también se extiende a los usuarios adultos de estas plataformas) son ejemplos de las "consecuencias no intencionadas de un diseño benevolente" que Tim Berners-Lee y la Fundación Webbuscan abordar en su movimiento.

A genocidal blockade by washington forces Cubans to jump through hoops to access Internet services that the Global North take for granted.Though amendments have been made to allow for a handful of personal communication services like WhatsApp to be accessed by Cuban IP addresses, the majority of Cuban citizens have to spend their salaries on costly VPNs to surf the web.These economic sanctions shed light on the lack of technical understanding in washington of how the Internet works and run afoul of the second principle of the Contract for the Web; keep all of the Internet available all of the time.

Un bloqueo genocida por parte de washington obliga a los Cubanos a saltar obstáculos para acceder a servicios de Internetque en el Norte se dan por sentados. Aunque se han hecho enmiendas para permitir el acceso a algunos servicios de comunicación personal como WhatsApp desde direcciones IP cubanas, la mayoría de los ciudadanos cubanos deben gastan sus salarios en VPNs costosas para navegar en la web.Estas sanciones económicas evidencian la falta de comprensión técnica en Washington sobre cómo funciona el Internet y contravienen el segundo principio del Contrato para la Web: mantener todo el Internet disponible todo el tiempo.

“It would be interesting to know how it is possible that the us is so interested in a free access internet for Cubans but prevents us from accessing digital platforms such as WeTransfer, OpenSea, Adobe and dozens of others that are accessed by the rest of the world, adding obstacles to our human development.” - Rubén Martínez Rojas, Havana Resident

"Sería interesante saber cómo es posible que los estados unidos esté tan interesado en un acceso libre a internet para los cubanos, pero al mismo tiempo nos impida acceder a plataformas digitales como WeTransfer, OpenSea, Adobe y docenas de otras que están disponibles para el resto del mundo, añadiendo obstáculos a nuestro desarrollo humano." - Rubén Martínez Rojas, Resident de La Habana

When you juxtapose cruel sanctions with the recent pushes to pass the Protecting Americans from Foreign Adversary Controlled Applications Act(PAFACAA) and the Kids Online Safety Act(KOSA), the united states increasingly seems less like the "land of the free" and more like Soviet Russia. The Electronic Fronteir Foundation found that KOSA "empowers state officials to target services and online content they do not like" and will unfairly endanger activists and other groups.If passed in the Senate, the PAFACAA would ban Tik Tok from devices and app stores in the united states if its China-based owner, ByteDance, doesn't sell its stake to a us-based company. Former united states Treasury Secretary steve mnuchin, a close friend of former mossad chief yossi cohen, whom he previously invited to join his investment fund, has already mobilized potential buyers.This is no doubt to squash political dissent on a platform that has mobilized and educated millions on the ongoing genocide in Gaza. The us empire is throwing the weight of its bloated aparatus around to maintain a waning political and cultural hegemony and blatantly violating our our civil liberties in the process.

Cuando juxtapones las sanciones crueles con los intentos recientes de aprobar la Ley de Protección de los Americanos contra Aplicaciones Controladas por Adversarios Extranjeros (Protecting Americans from Foreign Adversary Controlled Applications Act) y la Ley de Seguridad en Línea para Niños (Kids Online Safety Act),los estados unidos cada vez parece menos como la "tierra de los libres" y más como la Unión Soviética. La Fundación de la Frontera Electrónica (Electronic Frontier Foundation) encontró que KOSA "otorga poder a los funcionarios estatales para atacar servicios y contenidos en línea que no les gustan" y pondrá en peligro injustamente a activistas y otros grupos. Si se aprueba en el Senado, PAFACAA prohibirá TikTok en dispositivos y tiendas de aplicaciones en los estados unidos si su propietario Chino, ByteDance, no la vende a una compañía estadounidense. El exsecretario del Tesoro de estados unidos, steve mnuchin, amigo cercano del exjefe del Mossad, yossi cohen, a quien previamente invitó a unirse a su fondo de inversión, ya ha movilizado a posibles compradores. Esto es, sin duda, para suprimir la disidencia política en una plataforma que ha movilizado y educado a millones sobre el genocidio en curso en Gaza. El imperio estadounidense está utilizando el peso de su aparato inflado para mantener una hegemonía política y cultural en declive y, en el proceso, violando descaradamente nuestras libertades civiles.

"Imagine something similar happening in another country, where its former finance minister ended up as the buyer." - Robert Weissman, president of the watchdog group Public Citizen

"Imagina algo similar ocurriendo en otro país, donde su exministro de finanzas termina siendo el comprador."- Robert Weissman, presidente del grupo Public Citizen

Yes, Iris, technology is political AF. Each corporate tech acquisition and authoritative legislation passed is a nontechnical factor in technology-policy decisions as outlined in Kranzberg's 4th Law.The World Wide Web just turned 35 years old and it's power has concentrated in the hands of a few corporations and an authoritarian regimethat are working in tandem to erode our civil liberties and keep us from building the world we want. How do we achieve Tim Berner Lee's original vision for an open, decentralized information sharing network that empowers humanity?

Sí, Iris, la tecnología es política. Cada adquisición corporativa tecnológica y legislación autoritaria que se aprueba es un factor no técnico en las decisiones de política-tecnológica, como se describe en la cuarta ley de Kranzberg.La World Wide Web acaba de cumplir 35 años y su poder se ha concentrado en las manos de unas pocas corporaciones y un régimen autoritario que están trabajando juntos para erosionar nuestras libertades civiles y evitar que construyamos el mundo que queremos. ¿Cómo logramos la visión original de Tim Berners-Lee para una red de intercambio de información abierta y descentralizada que empodere a la humanidad?

"A new paradigm is emerging, one that places individuals’ intention rather than attention at the heart of business models, freeing us from the constraints of the established order and returning control over our data."- Tim Berners Lee, Marking the Web’s 35th Birthday: An Open Letter

"Está emergiendo un nuevo paradigma, uno que sitúa la intención de los individuos en lugar de la atención en el centro de los modelos de negocio, liberándonos de las restricciones del orden establecido y devolviendo el control sobre nuestros datos." - Tim Berners Lee, Con motivo del 35.º aniversario de la Web: Una Carta Abierta

We can siphon power out from the tentacles of the evil tech lords and politicians back into the hands of the people by wielding the power of open source technology. We have to be better consumers of tech and the Internet and think critically about our digital presences if we want to have a chance at disabling the lying machine. Protocols like Nostr create digital spheres that facilitate this power exchange and give us the means to govern our online spaces, free from the influence of corporate greed. That's why I'm following your lead in this fight for digital democracy. Hasta la victoria siempre!!

Podemos sustraer el poder de las tentáculos de los malvados corporaciones tecnológicos y políticos para devolverlo a manos de la gente mediante el uso del poder de la tecnología de código abierto. Tenemos que ser mejores consumidores de tecnología e Internet y pensar críticamente sobre nuestras presencias digitales si queremos tener una oportunidad de deshabilitar la máquina de mentiras. Protocolos como Nostr crean esferas digitales que facilitan este intercambio de poder y nos dan los medios para gobernar nuestros espacios en línea, libres de la influencia de la codicia corporativa. Por eso estoy siguiendo tu ejemplo en esta lucha por la democracia digital. Hasta la victoria, siempre!!!

"The web is for everyone and collectively we hold the power to change it. It won’t be easy. But if we dream a little and work a lot, we can get the web we want." - Tim Berners Lee, Marking the Web’s 35th Birthday: An Open Letter "La web es para todos y colectivamente tenemos el poder de cambiarla. No será fácil. Pero si soñamos un poco y trabajamos mucho, podemos conseguir la web que queremos." - Tim Berners Lee, Con motivo del 35.º aniversario de la Web: Una Carta Abierta

@ 266815e0:6cd408a5

While I was in Mediera with all the other awesome people at the first SEC cohort there where a lot of discussions around data storage on nostr and if it could be made censorship-resistent

I remember lots of discussions about torrents, hypercore, nostr relays, and of course IPFS

There were a few things I learned from all these conversations:

1. All the existing solutions have one thing in common. A universal ID of some kind for files
2. HTTP is still good. we don't have to throw the baby out with the bath water
3. nostr could fix this... somehow

Some of the existing solutions work well for large files, and all of them are decentralization in some way. However none of them seem capable of serving up cat pictures for social media clients. they all have something missing...

An Identity system

An identity system would allow files to be "owned" by users. and once files have owners servers could start grouping files into a single thing instead of a 1000+ loose files

This can also greatly simplify the question of "what is spam" for a server hosting (or seeding) these files. since it could simply have a whitelist of owners (and maybe their friends)

What is blossom?

Blossom is a set of HTTP endpoints that allow nostr users to store and retrieve binary data on public servers using the sha256 hash as a universal id

What are Blobs?

blobs are chunks of binary data. they are similar to files but with one key difference, they don't have names

Instead blobs have a sha256 hash (like b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553) as an ID

These IDs are universal since they can be computed from the file itself using the sha256 hashing algorithm ( you can a files hashing on linux using: sha256sum bitcoin.pdf )

How do the servers work?

Blossom servers expose four endpoints to let clients and users upload and manage blobs

• GET /<sha256> (optional file .ext)
• PUT /upload
• Authentication: Signed nostr event
• Returns a blob descriptor
• GET /list/<pubkey>
• Returns an array of blob descriptors
• Authentication (optional): Signed nostr event
• DELETE /<sha256>
• Authentication: Signed nostr event

What is Blossom Drive?

Blossom Drive is a nostr app built on top of blossom servers and allows users to create and manage folders of blobs

What are Drives

Drives are just nostr events (kind 30563) that store a map of blobs and what filename they should have along with some extra metadata

An example drive event would be json { "pubkey": "266815e0c9210dfa324c6cba3573b14bee49da4209a9456f9484e5106cd408a5", "created_at": 1710773987, "content": "", "kind": 30563, "tags": [ [ "name", "Emojis" ], [ "description", "nostr emojis" ], [ "d", "emojis" ], [ "r", "https://cdn.hzrd149.com/" ], [ "x", "303f018e613f29e3e43264529903b7c8c84debbd475f89368cb293ec23938981", "/noStrudel.png", "15161", "image/png" ], [ "x", "a0e2b39975c8da1702374b3eed6f4c6c7333e6ae0008dadafe93bd34bfb2ca78", "/satellite.png", "6853", "image/png" ], [ "x", "e8f3fae0f4a43a88eae235a8b79794d72e8f14b0e103a0fed1e073d8fb53d51f", "/amethyst.png", "20487", "image/png" ], [ "x", "70bd5836807b916d79e9c4e67e8b07e3e3b53f4acbb95c7521b11039a3c975c6", "/nos.png", "36521", "image/png" ], [ "x", "0fc304630279e0c5ab2da9c2769e3a3178c47b8609b447a30916244e89abbc52", "/primal.png", "29343", "image/png" ], [ "x", "9a03824a73d4af192d893329bbc04cd3798542ee87af15051aaf9376b74b25d4", "/coracle.png", "18300", "image/png" ], [ "x", "accdc0cdc048f4719bb5e1da4ff4c6ffc1a4dbb7cf3afbd19b86940c01111568", "/iris.png", "24070", "image/png" ], [ "x", "2e740f2514d6188e350d95cf4756bbf455d2f95e6a09bc64e94f5031bc4bba8f", "/damus.png", "32758", "image/png" ], [ "x", "2e019f08da0c75fb9c40d81947e511c8f0554763bffb6d23a7b9b8c9e8c84abb", "/old emojis/astral.png", "29365", "image/png" ], [ "x", "d97f842f2511ce0491fe0de208c6135b762f494a48da59926ce15acfdb6ac17e", "/other/rabbit.png", "19803", "image/png" ], [ "x", "72cb99b689b4cfe1a9fb6937f779f3f9c65094bf0e6ac72a8f8261efa96653f5", "/blossom.png", "4393", "image/png" ] ] }

There is a lot going on but the main thing is the list of "x" tags and the path that describes the folder and filename the blob should live at

If your interested, the full event definition is at github.com/hzrd149/blossom-drive

Getting started

Like every good nostr client it takes a small instruction manual in order to use it properly. so here are the steps for getting started

1. Open the app

Open https://blossom.hzrd149.com

2. Login using extension

You can also login using any of the following methods using the input - NIP-46 with your https://nsec.app or https://flare.pub account - a NIP-46 connection string - an ncryptsec password protected private key - a nsec unprotected private key (please don't) - bunker:// URI from nsecbunker

3. Add a blossom server

Right now https://cdn.satellite.earth is the only public server that is compatible with blossom drive. If you want to host your own I've written a basic implementation in TypeScript github.com/hzrd149/blossom-server

4. Start uploading your files

NOTE: All files upload to blossom drive are public by default. DO NOT upload private files

5. Manage files

Encrypted drives

There is also the option to encrypt drives using NIP-49 password encryption. although its not tested at all so don't trust it, verify

Whats next?

I don't know, but Im excited to see what everyone else on nostr builds with this. I'm only one developer at the end of the day and I can't think of everything

also all the images in this article are stored in one of my blossom drives here

nostr:naddr1qvzqqqrhvvpzqfngzhsvjggdlgeycm96x4emzjlwf8dyyzdfg4hefp89zpkdgz99qq8xzun5d93kcefdd9kkzem9wvr46jka

@ 3bf0c63f:aefa459d

Censorship-resistant relay discovery in Nostr

In Nostr is not decentralized nor censorship-resistant I said Nostr is centralized. Peter Todd thinks it is centralized by design, but I disagree.

Nostr wasn't designed to be centralized. The idea was always that clients would follow people in the relays they decided to publish to, even if it was a single-user relay hosted in an island in the middle of the Pacific ocean.

But the Nostr explanations never had any guidance about how to do this, and the protocol itself never had any enforcement mechanisms for any of this (because it would be impossible).

My original idea was that clients would use some undefined combination of relay hints in reply tags and the (now defunct) kind:2 relay-recommendation events plus some form of manual action ("it looks like Bob is publishing on relay X, do you want to follow him there?") to accomplish this. With the expectation that we would have a better idea of how to properly implement all this with more experience, Branle, my first working client didn't have any of that implemented, instead it used a stupid static list of relays with read/write toggle -- although it did publish relay hints and kept track of those internally and supported kind:2 events, these things were not really useful.

Gossip was the first client to implement a truly censorship-resistant relay discovery mechanism that used NIP-05 hints (originally proposed by Mike Dilger) relay hints and kind:3 relay lists, and then with the simple insight of NIP-65 that got much better. After seeing it in more concrete terms, it became simpler to reason about it and the approach got popularized as the "gossip model", then implemented in clients like Coracle and Snort.

Today when people mention the "gossip model" (or "outbox model") they simply think about NIP-65 though. Which I think is ok, but too restrictive. I still think there is a place for the NIP-05 hints, nprofile and nevent relay hints and specially relay hints in event tags. All these mechanisms are used together in ZBD Social, for example, but I believe also in the clients listed above.

I don't think we should stop here, though. I think there are other ways, perhaps drastically different ways, to approach content propagation and relay discovery. I think manual action by users is underrated and could go a long way if presented in a nice UX (not conceived by people that think users are dumb animals), and who knows what. Reliance on third-parties, hardcoded values, social graph, and specially a mix of multiple approaches, is what Nostr needs to be censorship-resistant and what I hope to see in the future.

@ 266815e0:6cd408a5

Not much going on in this release, just a lot of cleanup under the hood and a few new tools

Minor Changes

• Add "open in" modal (NIP-89)
• Add event publisher tool
• Added Event Console tool
• Add option to automatically decrypt DMs

Patch Changes

• Rebuild observable class
• Add UI tab to relays
• Fix custom emoji reactions having multiple colons
• Fix jsonl database export format
• Fix auto-playing blurred videos
• Fix bunker://pubkey connect URIs
• Fix profile form removing unknown metadata fields
• Unblur all images when clicking on a note
• Update emojilib ( thanks nostr:npub168ghgug469n4r2tuyw05dmqhqv5jcwm7nxytn67afmz8qkc4a4zqsu2dlc PR )

Event Console

A handy tool I built to explore that raw nostr events from nostr relays (or the local cache) It supports auto-completion for the REQ fields and @

Event Publisher

Similar to the event console the event publisher tool lets you write any kind of nostr event, sign, and publish it to your relays

Auto Decrypt DMs

While I'm not a fan of nostr apps prompting the user to sign or decrypt things automatically. in this case it dose make the user experience better.

If your tired of clicking "decrypt" on each message you can turn on the "Auto Decrypt DMs" in the "Performance" settings

As always you can run the app locally using docker docker run --rm -p 8080:80 ghcr.io/hzrd149/nostrudel:0.39.0

@ ec965405:63996966

I'm finally getting around to sharing this note after Aaron Bushnell, a 25 year old united states service member streamed a video of his self immolation in front of an israeli embassy on Twitch last weekend in protest of the ongoing Palestinian genocide. He's the second in recent months to do so and the first to lose his life in the process. This note is for the martyrs.

Finalmente estoy compartiendo esta nota después de que Aaron Bushnell, un miembro de 25 años de las fuerzas armadas de Estados Unidos, transmitiera en vivo su autoinmolación frente a una embajada israelí en Twitch el fin de semana pasado en protesta por el genocidio palestino en curso. Es el segundo que lo hace en los últimos meses y el primero en perder la vida en el proceso. Esta nota es para los mártires.

---

I woke up feeling sick to my stomach in the middle of the night during my recent delgation to Cuba; probably a side effect of mixing 3 plates of Ropa Vieja at dinner with cigars and beer at La Fabrica the night before. Chastising myself for hitting my body with 3 things I normally avoid at home (tobacco, alcohol, and meat), I wasn't able to make it downstairs to the cafeteria for breakfast or the day trip with the group. I was allowed to stay and rest at the center in the morning while they checked out El Rincón de los Milagros,where they learned about the impact of the Haitian revolution on Cuban society. Everyone said I would have loved it. After looking through their pictures and videos of the drum sessions,I'm certain I would have. I'm going to prioritize visiting this spot next time I'm in Cuba.

Me desperté sintiéndome mal del estómago en medio de la noche, durante mi reciente delegación a Cuba; probablemente un efecto secundario de mezclar 3 platos de Ropa Vieja en la cena, con cigarros y cerveza en La Fábrica la noche anterior. Regañándome a mí mismo por someter mi cuerpo a 3 cosas que normalmente evito en casa (tabaco, alcohol y carne), no logré bajar a la cafetería para desayunar ni unirme al viaje del día con el grupo. Me permitieron quedarme a descansar en el centro durante la mañana mientras ellos visitaban El Rincón de los Milagros, donde aprendieron sobre el impacto de la revolución haitiana en la sociedad cubana. Todos dijeron que me hubiera encantado. Después de ver sus fotos y videos de las sesiones de tambores, estoy seguro de que así hubiera sido. Voy a hacer de visitar este lugar una prioridad la próxima vez que esté en Cuba.

On the flip side, I was deficient in sleep hours, so catching up on rest put me in a better position to participate in the evening social at El Sauce. El Sauce is a smaller venue that wasn't nearly as packed as La Fabrica the previous evening. I enjoyed down time with my fellow delegates, happy to get to know them in an intimate space and eventualy joining them on the dance floor for an electric slide.

Por otro lado, me faltaban horas de sueño, así que ponerme al día con el descanso me colocó en una mejor posición para participar en el evento social de la noche en El Sauce. El Sauce es un lugar más pequeño que no estaba tan lleno como La Fábrica la noche anterior. Disfruté del tiempo libre con mis compañeros delegados, contento de llegar a conocerlos en un espacio íntimo y finalmente uniéndome a ellos en la pista de baile para un electric slide.

I watched a man dressed in plain shorts and a red shirt dance enthusiastically with at least 5 separate partners of varying ages and genders throughout the night, radiating joy with each graceful spin as if he hadn't a care in the world. His magnetic energy drew everyone around him into his orbit despite coming to El Sauce alone that night. The circumstances of an inhumane blockade on his country did not seem to phase him as he laughed and sang along to the music, his humanity on full display for us to see.

Observé a un hombre vestido con shorts sencillos y una camisa roja bailar entusiasmado con al menos 5 parejas distintas de variadas edades y géneros a lo largo de la noche, irradiando alegría con cada giro elegante como si no tuviera ninguna preocupación en el mundo. Su energía magnética atraía a todos a su alrededor a pesar de haber llegado solo a El Sauce esa noche. Las circunstancias de un bloqueo inhumano sobre su país parecían no afectarle mientras reía y cantaba junto a la música, mostrando su humanidad para que todos la viéramos

Before dinner the next evening, the group gathered in the cafeteria for a reflection activity about our first few days in Cuba where we broke the ice by sharing an African word that we were familiar with and its significance to us. My mind instantly snapped to "Ubuntu", a word that represents the inception of my programming journey and my intentions with what comes from it. From the African Journal of Social Work,

Antes de la cena la siguiente noche, el grupo se reunió en la cafetería para una actividad reflexiva sobre nuestros primeros días en Cuba, donde rompimos el hielo compartiendo una palabra africana con la que estuviéramos familiarizados y su significado para nosotros. Mi mente se dirigió instantáneamente a 'Ubuntu', una palabra que representa el inicio de mi carrera en la programación y mis intenciones con lo que resulte de ello. Según el Journal Africano de Trabajo Social:

Ubuntu refers to a collection of values and practices that Black people of Africa or of African origin view as making people authentic human beings. While the nuances of these values and practices vary across different ethnic groups, they all point to one thing – an authentic individual human being is part of a larger and more significant relational, communal, societal, environmental and spiritual world. Ubuntu se refiere a un conjunto de valores y prácticas que las personas negras de África o de origen africano consideran que hacen a los seres humanos auténticos. Aunque los matices de estos valores y prácticas varían entre los distintos grupos étnicos, todos apuntan a lo mismo: un ser humano auténtico es parte de un mundo más amplio y significativo que incluye lo relacional, lo comunal, la sociedad, el medio ambiente y lo espiritual.

I explained my philosophy around the use of open sourced software and a healthier relationship with the Internet highlighting the need to boycot corporate tech platforms that inflict irreparable harm on the massses. The constant bombardment of corporate advertising guided by antagonizing algorithms fuel a dire behavioral health crisis that's actively destroying the fabric of our society and disconnecting us from our humanity. Open source software is my weapon in this war against the tech corporations that dominate our dystopic digital lives that I will leverage to center humanity and dignity in communications.

Expliqué mi filosofía sobre el uso de software de código abierto y una relación más saludable con internet, resaltando la necesidad de boicotear las plataformas tecnológicas corporativas que infligen un daño irreparable a las masas. El constante bombardeo de publicidad corporativa, guiado por algoritmos antagonistas, alimenta una grave crisis de salud conductual que está destruyendo activamente el tejido de nuestra sociedad y desconectándonos de nuestra humanidad. El software de código abierto es mi arma en esta guerra contra las corporaciones tecnológicas que dominan nuestras vidas digitales distópicas, el cual utilizaré para centrar la humanidad y la dignidad en nuestras comunicaciones.

I shared this with the group, happy to look over at a fellow delegate and see her point to the bracelet on her wrist with the letters U-B-U-N-T-U spelled out. I felt right at home with this crew.

Compartí esto con el grupo, contento de mirar a una compañera delegada y verla señalar hacia la pulsera en su muñeca con las letras U-B-U-N-T-U. Me sentí como en casa con este equipo.

@ fa984bd7:58018f52

I have recently launched Wikifreedia, which is a different take on how Wikipedia-style systems can work.

Yes, it's built on nostr, but that's not the most interesting part.

The fascinating aspect is that there is no "official" entry on any topic. Anyone can create or edit any entry and build their own take about what they care about.

Think the entry about Mao is missing something? Go ahead and edit it, you don't need to ask for permission from anyone.

Stuart Bowman put it best on a #SovEng hike:

The path to truth is in the integration of opposites.

Since launching Wikifreedia, less than a week ago, quite a few people asked me if it would be possible to import ALL of wikipedia into it.

Yes. Yes it would.

I initially started looking into it to make it happen as I am often quick to jump into action.

But, after thinking about it, I am not convinced importing all of Wikipedia is the way to go.

The magical thing about building an encyclopedia with no canonical entry on any topic is that each individual can bring to light the part they are interested the most about a certain topic, it can be dozens or hundreds, or perhaps more, entries that focus on the edges of a topic.

Whereas, Wikipedia, in their Quijotean approach to truth, have focused on the impossible path of seeking neutrality.

Humans can't be neutral, we have biases.

Show me an unbiased human and I'll show you a lifeless human.

Biases are good. Having an opinion is good. Seeking neutrality is seeking to devoid our views and opinions of humanity.

Importing Wikipedia would mean importing a massive amount of colorless trivia, a few interesting tidbits, but, more important than anything, a vast amount of watered-down useless information.

All edges of the truth having been neutered by a democratic process that searches for a single truth via consensus.

"What's the worst that could happen?"

Sure, importing wikipedia would simply be one more entry on each topic.

Yes.

But culture has incredibly strong momentum.

And if the culture that develops in this type of media is that of exclusively watered-down comfortable truths, then some magic could be lost.

If people who are passionate or have a unique perspective about a topic feel like the "right approach" is to use the wikipedia-based article then I would see this as an extremely negative action.

An alternative

An idea we discussed on the #SovEng hike was, what if the wikipedia entry is processed by different "AI agents" with different perspectives.

Perhaps instead of blankly importing the "Napoleon" article, an LLM trained to behave as a 1850s russian peasant could be asked to write a wiki about Napoleon. And then an agent tried to behave like Margaret Thatcher could write one.

Etc, etc.

Embrace the chaos. Embrace the bias.

@ 3f770d65:7a745b24

February 24, 2024 - Nostr Nests, the premier decentralized audio platform powered by the Nostr protocol, announces the launch of its highly anticipated version 2.0 beta release. This major update brings complete integration with Nostr, a redesigned user interface, and a host of powerful features, making it easier than ever to connect, collaborate, and create in an open and censorship-resistant environment.

Originally launched in January 2023 as Nostr Plebs Spaces, Nostr Nests quickly gained traction as a haven for audio-based interactions across the Nostr protocol. The official rebrand to Nostr Nests in February 2023 further solidified its position as the go-to platform for chatting, jamming, micro-conferences, live podcast recordings, and more with the onboarding of users, shows, and content from around the globe.

Version 2.0 marks a significant leap forward:

Seamless Nostr Integration: Nostr Nests 2.0 was built from the ground up to be a full fledged Nostr client, enabling a truly decentralized experience with direct Nostr authentication. No need for separate accounts, logins, or verification posts. Login with your current Nostr keys via nsecBunker or NIP-07 extensions such as Alby, Nostr Connect, or Nostore for iOS.

Discoverability and User Choice: Find your favorite live audio events like never before, not only on NostrNests.com, but also via a variety of Nostr clients that support live events such as Amethyst, Snort, Iris, Flockstr, Nostrudel, Wherostr and more. Install Nostr Nests as a PWA on Android, iOS, or your favorite desktop operating system.

Redesigned Interface: Navigate with ease thanks to a streamlined and intuitive layout. Find scheduled events, discover communities, and manage your interactions effortlessly.

Enhanced Functionality: Host events with flexible permission settings, record and store audio directly from your Nest, be in charge of your data while you chat on your customized relays, leverage advanced moderation tools for a smooth and secure experience, and broadcast it all across the Nostr protocol. Experience value for value with Zap enabled profiles and chat announcements.

Multi-lingual: Access Nostr Nests in your native language. Nostr Nests supports over a dozen languages, making Nostr Nests a truly global platform for our users. Open Source: The platform's code is fully open-source under the MIT license, welcoming community contributions and fostering transparency. Submit issues and pull requests on GitHub to shape the future of Nostr Nests.

Nostr Nests 2.0 empowers individuals and communities to:

Connect: Host and attend audio events with like-minded people based on shared interests, making new friends along the way or reconnecting with old ones.

Collaborate: Jam with musicians, brainstorm with colleagues, or conduct insightful interviews in a live audio setting.

Express Yourself: Share your voice, thoughts, and ideas with the world in an uncensored and secure environment via text chats as well as audio conversations.

Build Communities: Foster vibrant, customizable communities around shared passions, hobbies, or professional pursuits.

Whether you're a musician, podcaster, entrepreneur, or simply someone who enjoys meaningful audio interactions, Nostr Nests 2.0 invites you to join the conversation. Visit NostrNests.com today and experience the future of social audio.

Join and contribute to the Nostr Nests community:

Website: https://NostrNests.com

GitHub: https://github.com/nostrnests/nests

Current Features:

Nostr Integration: * Sign-in * Live events * Scheduled events * Zaps * Public chat * Reactions * Room presence * Relays (default or custom) * Social sharing * Follow/Unfollow * Profile creation * Profile Editing * Lobby filtering

Lobby: * Active rooms * Scheduled rooms * Filter by global or following * Create new room * View profile

Create room: * Create custom room * Customizable banner * Preselected colors * Custom image (static or animated) * Schedule room * Use default relays or custom relays

Rooms: * Stage and audience * Add/Remove people to/from stage * Public chat (ability to hide/view on mobile) * Raise hand * Mute/Unmute own mic * Mute others (Mod or Host) * Zap * Reactions * Edit profile * View profile * Share to Nostr * Stream audio (coming soon) (Mod or Host) * Record audio (Mod or Host) * Access room recordings (Mod or Host)

Sign-in: * Sign-in as guest to listen only * Create new Nostr profile * Use existing Nostr profile

Future Features:

• Chat zaps, chat reactions, mutes, etc.
• Support additional nsecBunkers
• More room customization options
• Monetization options for creators
• And more!

Please note: While Nostr Nests 2.0 marks a significant step forward, this release should be considered beta software. Users may encounter occasional bugs or unforeseen issues as we continue to refine and optimize the platform. We appreciate your understanding and patience as we work towards a fully polished experience.

Known Issues:

• A lot! It's very new and very beta!
• Sign-in user flow for direct links to rooms
• Mobile UI alignment
• Mobile UI chat bar

@ 2d5b6404:d4b500b0

1. アンフィールドでリバプールの試合を観戦する
2. イタリアでピザ食べたりエスプレッソ飲む
3. じゅりよんやラルフ、ewelina、マルティン、jefgとか𓆏に会いにヨーロッパ旅行行く
4. 長崎ぺんぎん水族館に行く
5. 九十九里で貝を食べる
6. 奄美大島でクジラの鳴き声を聞く
7. 蒸気機関車に乗る
8. 台湾旅行に行く
9. 韓国旅行に行く
10. 船で東京か大阪、四国に行く
11. Punkt. MP02を買い替える
12. ベトナムに住んでる友達に会いに行く
13. ホームベースとなる共同体を見つける。もしくは作る
14. 収入の10分の１を寄付する
15. ~~デスストランディングをクリアする~~
16. ブレワイ、ティアキンをクリアする
17. べランピングする
18. 冷蔵庫を伊良コーラでいっぱいにする
19. 友達とこたつでゲームする

@ 7fa56f5d:751ac194

I'm happy to announce a new release of Habla.

Nostr connect

Users can now login via Nostr Connect remote signers. Both bunker:// URLs and NIP-46 compatible nostr addresses (NIP-05) are supported.

Local drafts

nostr:nevent1qqs2jfpse4akde0w2ljq0n8sytp7pmnrqj943ymyw5kets45ftvv5qspzpmhxue69uhkummnw3ezuamfdejsygyhcu9ygdn2v56uz3dnx0uh865xmlwz675emfsccsxxguz6mx8rygq4xs2f

Some users have reported Habla eating their blog posts. To avoid the issue Habla will now automatically save the post you are editing in local storage. The option to store drafts on nostr still exists if you want to continue editing from another client or device.

RTL languages

Habla is now translated to Hebrew. The translator was kind enough to review the RTL compatibility of the site and we have fixed multiple layout and text direction issues for RTL language users.

Extracting Habla core code

The core Habla code has been extracted to a library called ngine and I have ported several apps to it. These apps are currently using it:

nostr:naddr1qqxnzdesxvungvecxsungdpkqgs8lft0t45k92c78n2zfe6ccvqzhpn977cd3h8wnl579zxhw5dvr9qrqsqqql8kqf6n74

nostr:naddr1qqxnzdesxgunqvpexuersvp3qgs8lft0t45k92c78n2zfe6ccvqzhpn977cd3h8wnl579zxhw5dvr9qrqsqqql8k6zxwng

nostr:naddr1qqxnzd3exgmrsveh8yerqdfcqgsrx4k7vxeev3unrn5ty9qt9w4cxlsgzrqw752mh6fduqjgqs9chhgrqsqqql8kaulu0l

The next step is to start using it from Habla and document it so other nostr devs can leverage it for building apps quicker. The library has similar scope as Osty so will probably join forces with nostr:nprofile1qqsru22d9lfnnwck54qr4phrvey50h2q33xc0gqxv5j03ftn4efu4rspr9mhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmd9uq3gamnwvaz7tmjv4kxz7tpvfkx2tn0wfnj7qgewaehxw309aex2mrp0yhxummnw3exzarf9e3k7mf0y2nv4h, expect some news about this soon.

---

Happy curating, reading and writing!

@ b3e43e8c:e3068b5f

ああテストだよテストだよ

@ 3bf0c63f:aefa459d

Pequenos problemas que o Estado cria para a sociedade e que não são sempre lembrados

- **vale-transporte**: transferir o custo com o transporte do funcionário para um terceiro o estimula a morar longe de onde trabalha, já que morar perto é normalmente mais caro e a economia com transporte é inexistente.
- **atestado médico**: o direito a faltar o trabalho com atestado médico cria a exigência desse atestado para todas as situações, substituindo o livre acordo entre patrão e empregado e sobrecarregando os médicos e postos de saúde com visitas desnecessárias de assalariados resfriados.
- **prisões**: com dinheiro mal-administrado, burocracia e péssima alocação de recursos -- problemas que empresas privadas em competição (ou mesmo sem qualquer competição) saberiam resolver muito melhor -- o Estado fica sem presídios, com os poucos existentes entupidos, muito acima de sua alocação máxima, e com isto, segundo a bizarra corrente de responsabilidades que culpa o juiz que condenou o criminoso por sua morte na cadeia, juízes deixam de condenar à prisão os bandidos, soltando-os na rua.
- **justiça**: entrar com processos é grátis e isto faz proliferar a atividade dos advogados que se dedicam a criar problemas judiciais onde não seria necessário e a entupir os tribunais, impedindo-os de fazer o que mais deveriam fazer.
- **justiça**: como a justiça só obedece às leis e ignora acordos pessoais, escritos ou não, as pessoas não fazem acordos, recorrem sempre à justiça estatal, e entopem-na de assuntos que seriam muito melhor resolvidos entre vizinhos.
- **leis civis**: as leis criadas pelos parlamentares ignoram os costumes da sociedade e são um incentivo a que as pessoas não respeitem nem criem normas sociais -- que seriam maneiras mais rápidas, baratas e satisfatórias de resolver problemas.
- **leis de trãnsito**: quanto mais leis de trânsito, mais serviço de fiscalização são delegados aos policiais, que deixam de combater crimes por isto (afinal de contas, eles não querem de fato arriscar suas vidas combatendo o crime, a fiscalização é uma excelente desculpa para se esquivarem a esta responsabilidade).
- **financiamento educacional**: é uma espécie de subsídio às faculdades privadas que faz com que se criem cursos e mais cursos que são cada vez menos recheados de algum conhecimento ou técnica útil e cada vez mais inúteis.
- **leis de tombamento**: são um incentivo a que o dono de qualquer área ou construção "histórica" destrua todo e qualquer vestígio de história que houver nele antes que as autoridades descubram, o que poderia não acontecer se ele pudesse, por exemplo, usar, mostrar e se beneficiar da história daquele local sem correr o risco de perder, de fato, a sua propriedade.
- **zoneamento urbano**: torna as cidades mais espalhadas, criando uma necessidade gigantesca de carros, ônibus e outros meios de transporte para as pessoas se locomoverem das zonas de moradia para as zonas de trabalho.
- **zoneamento urbano**: faz com que as pessoas percam horas no trânsito todos os dias, o que é, além de um desperdício, um atentado contra a sua saúde, que estaria muito melhor servida numa caminhada diária entre a casa e o trabalho.
- **zoneamento urbano**: torna ruas e as casas menos seguras criando zonas enormes, tanto de residências quanto de indústrias, onde não há movimento de gente alguma.
- **escola obrigatória + currículo escolar nacional**: emburrece todas as crianças.
- **leis contra trabalho infantil**: tira das crianças a oportunidade de aprender ofícios úteis e levar um dinheiro para ajudar a família.
- **licitações**: como não existem os critérios do mercado para decidir qual é o melhor prestador de serviço, criam-se comissões de pessoas que vão decidir coisas. isto incentiva os prestadores de serviço que estão concorrendo na licitação a tentar comprar os membros dessas comissões. isto, fora a corrupção, gera problemas reais: __(i)__ a escolha dos serviços acaba sendo a pior possível, já que a empresa prestadora que vence está claramente mais dedicada a comprar comissões do que a fazer um bom trabalho (este problema afeta tantas áreas, desde a construção de estradas até a qualidade da merenda escolar, que é impossível listar aqui); __(ii)__ o processo corruptor acaba, no longo prazo, eliminando as empresas que prestavam e deixando para competir apenas as corruptas, e a qualidade tende a piorar progressivamente.
- **cartéis**: o Estado em geral cria e depois fica refém de vários grupos de interesse. o caso dos taxistas contra o Uber é o que está na moda hoje (e o que mostra como os Estados se comportam da mesma forma no mundo todo).
- **multas**: quando algum indivíduo ou empresa comete uma fraude financeira, ou causa algum dano material involuntário, as vítimas do caso são as pessoas que sofreram o dano ou perderam dinheiro, mas o Estado tem sempre leis que prevêem multas para os responsáveis. A justiça estatal é sempre muito rígida e rápida na aplicação dessas multas, mas relapsa e vaga no que diz respeito à indenização das vítimas. O que em geral acontece é que o Estado aplica uma enorme multa ao responsável pelo mal, retirando deste os recursos que dispunha para indenizar as vítimas, e se retira do caso, deixando estas desamparadas.
- **desapropriação**: o Estado pode pegar qualquer propriedade de qualquer pessoa mediante uma indenização que é necessariamente inferior ao valor da propriedade para o seu presente dono (caso contrário ele a teria vendido voluntariamente).
- **seguro-desemprego**: se há, por exemplo, um prazo mínimo de 1 ano para o sujeito ter direito a receber seguro-desemprego, isto o incentiva a planejar ficar apenas 1 ano em cada emprego (ano este que será sucedido por um período de desemprego remunerado), matando todas as possibilidades de aprendizado ou aquisição de experiência naquela empresa específica ou ascensão hierárquica.
- **previdência**: a previdência social tem todos os defeitos de cálculo do mundo, e não importa muito ela ser uma forma horrível de poupar dinheiro, porque ela tem garantias bizarras de longevidade fornecidas pelo Estado, além de ser compulsória. Isso serve para criar no imaginário geral a idéia da __aposentadoria__, uma época mágica em que todos os dias serão finais de semana. A idéia da aposentadoria influencia o sujeito a não se preocupar em ter um emprego que faça sentido, mas sim em ter um trabalho qualquer, que o permita se aposentar.
- **regulamentação impossível**: milhares de coisas são proibidas, há regulamentações sobre os aspectos mais mínimos de cada empreendimento ou construção ou espaço. se todas essas regulamentações fossem exigidas não haveria condições de produção e todos morreriam. portanto, elas não são exigidas. porém, o Estado, ou um agente individual imbuído do poder estatal pode, se desejar, exigi-las todas de um cidadão inimigo seu. qualquer pessoa pode viver a vida inteira sem cumprir nem 10% das regulamentações estatais, mas viverá também todo esse tempo com medo de se tornar um alvo de sua exigência, num estado de terror psicológico.
- **perversão de critérios**: para muitas coisas sobre as quais a sociedade normalmente chegaria a um valor ou comportamento "razoável" espontaneamente, o Estado dita regras. estas regras muitas vezes não são obrigatórias, são mais "sugestões" ou limites, como o salário mínimo, ou as 44 horas semanais de trabalho. a sociedade, porém, passa a usar esses valores como se fossem o normal. são raras, por exemplo, as ofertas de emprego que fogem à regra das 44h semanais.
- **inflação**: subir os preços é difícil e constrangedor para as empresas, pedir aumento de salário é difícil e constrangedor para o funcionário. a inflação força as pessoas a fazer isso, mas o aumento não é automático, como alguns economistas podem pensar (enquanto alguns outros ficam muito satisfeitos de que esse processo seja demorado e difícil).
- **inflação**: a inflação destrói a capacidade das pessoas de julgar preços entre concorrentes usando a própria memória.
- **inflação**: a inflação destrói os cálculos de lucro/prejuízo das empresas e prejudica enormemente as decisões empresariais que seriam baseadas neles.
- **inflação**: a inflação redistribui a riqueza dos mais pobres e mais afastados do sistema financeiro para os mais ricos, os bancos e as megaempresas.
- **inflação**: a inflação estimula o endividamento e o consumismo.
- **lixo:** ao prover coleta e armazenamento de lixo "grátis para todos" o Estado incentiva a criação de lixo. se tivessem que pagar para que recolhessem o seu lixo, as pessoas (e conseqüentemente as empresas) se empenhariam mais em produzir coisas usando menos plástico, menos embalagens, menos sacolas.
- **leis contra crimes financeiros:** ao criar legislação para dificultar acesso ao sistema financeiro por parte de criminosos a dificuldade e os custos para acesso a esse mesmo sistema pelas pessoas de bem cresce absurdamente, levando a um percentual enorme de gente incapaz de usá-lo, para detrimento de todos -- e no final das contas os grandes criminosos ainda conseguem burlar tudo.

@ 3bf0c63f:aefa459d

Drivechain

Understanding Drivechain requires a shift from the paradigm most bitcoiners are used to. It is not about "trustlessness" or "mathematical certainty", but game theory and incentives. (Well, Bitcoin in general is also that, but people prefer to ignore it and focus on some illusion of trustlessness provided by mathematics.)

Here we will describe the basic mechanism (simple) and incentives (complex) of "hashrate escrow" and how it enables a 2-way peg between the mainchain (Bitcoin) and various sidechains.

The full concept of "Drivechain" also involves blind merged mining (i.e., the sidechains mine themselves by publishing their block hashes to the mainchain without the miners having to run the sidechain software), but this is much easier to understand and can be accomplished either by the BIP-301 mechanism or by the Spacechains mechanism.

How does hashrate escrow work from the point of view of Bitcoin?

A new address type is created. Anything that goes in that is locked and can only be spent if all miners agree on the Withdrawal Transaction (WT^) that will spend it for 6 months. There is one of these special addresses for each sidechain.

To gather miners' agreement bitcoind keeps track of the "score" of all transactions that could possibly spend from that address. On every block mined, for each sidechain, the miner can use a portion of their coinbase to either increase the score of one WT^ by 1 while decreasing the score of all others by 1; or they can decrease the score of all WT^s by 1; or they can do nothing.

Once a transaction has gotten a score high enough, it is published and funds are effectively transferred from the sidechain to the withdrawing users.

If a timeout of 6 months passes and the score doesn't meet the threshold, that WT^ is discarded.

What does the above procedure mean?

It means that people can transfer coins from the mainchain to a sidechain by depositing to the special address. Then they can withdraw from the sidechain by making a special withdraw transaction in the sidechain.

The special transaction somehow freezes funds in the sidechain while a transaction that aggregates all withdrawals into a single mainchain WT^, which is then submitted to the mainchain miners so they can start voting on it and finally after some months it is published.

Now the crucial part: the validity of the WT^ is not verified by the Bitcoin mainchain rules, i.e., if Bob has requested a withdraw from the sidechain to his mainchain address, but someone publishes a wrong WT^ that instead takes Bob's funds and sends them to Alice's main address there is no way the mainchain will know that. What determines the "validity" of the WT^ is the miner vote score and only that. It is the job of miners to vote correctly -- and for that they may want to run the sidechain node in SPV mode so they can attest for the existence of a reference to the WT^ transaction in the sidechain blockchain (which then ensures it is ok) or do these checks by some other means.

What? 6 months to get my money back?

Yes. But no, in practice anyone who wants their money back will be able to use an atomic swap, submarine swap or other similar service to transfer funds from the sidechain to the mainchain and vice-versa. The long delayed withdraw costs would be incurred by few liquidity providers that would gain some small profit from it.

Why bother with this at all?

Drivechains solve many different problems:

It enables experimentation and new use cases for Bitcoin

Issued assets, fully private transactions, stateful blockchain contracts, turing-completeness, decentralized games, some "DeFi" aspects, prediction markets, futarchy, decentralized and yet meaningful human-readable names, big blocks with a ton of normal transactions on them, a chain optimized only for Lighting-style networks to be built on top of it.

These are some ideas that may have merit to them, but were never actually tried because they couldn't be tried with real Bitcoin or inferfacing with real bitcoins. They were either relegated to the shitcoin territory or to custodial solutions like Liquid or RSK that may have failed to gain network effect because of that.

It solves conflicts and infighting

Some people want fully private transactions in a UTXO model, others want "accounts" they can tie to their name and build reputation on top; some people want simple multisig solutions, others want complex code that reads a ton of variables; some people want to put all the transactions on a global chain in batches every 10 minutes, others want off-chain instant transactions backed by funds previously locked in channels; some want to spend, others want to just hold; some want to use blockchain technology to solve all the problems in the world, others just want to solve money.

With Drivechain-based sidechains all these groups can be happy simultaneously and don't fight. Meanwhile they will all be using the same money and contributing to each other's ecosystem even unwillingly, it's also easy and free for them to change their group affiliation later, which reduces cognitive dissonance.

It solves "scaling"

Multiple chains like the ones described above would certainly do a lot to accomodate many more transactions that the current Bitcoin chain can. One could have special Lightning Network chains, but even just big block chains or big-block-mimblewimble chains or whatnot could probably do a good job. Or even something less cool like 200 independent chains just like Bitcoin is today, no extra features (and you can call it "sharding"), just that would already multiply the current total capacity by 200.

Use your imagination.

It solves the blockchain security budget issue

The calculation is simple: you imagine what security budget is reasonable for each block in a world without block subsidy and divide that for the amount of bytes you can fit in a single block: that is the price to be paid in satoshis per byte. In reasonable estimative, the price necessary for every Bitcoin transaction goes to very large amounts, such that not only any day-to-day transaction has insanely prohibitive costs, but also Lightning channel opens and closes are impracticable.

So without a solution like Drivechain you'll be left with only one alternative: pushing Bitcoin usage to trusted services like Liquid and RSK or custodial Lightning wallets. With Drivechain, though, there could be thousands of transactions happening in sidechains and being all aggregated into a sidechain block that would then pay a very large fee to be published (via blind merged mining) to the mainchain. Bitcoin security guaranteed.

It keeps Bitcoin decentralized

Once we have sidechains to accomodate the normal transactions, the mainchain functionality can be reduced to be only a "hub" for the sidechains' comings and goings, and then the maximum block size for the mainchain can be reduced to, say, 100kb, which would make running a full node very very easy.

Can miners steal?

Yes. If a group of coordinated miners are able to secure the majority of the hashpower and keep their coordination for 6 months, they can publish a WT^ that takes the money from the sidechains and pays to themselves.

Will miners steal?

No, because the incentives are such that they won't.

Although it may look at first that stealing is an obvious strategy for miners as it is free money, there are many costs involved:

1. The cost of ceasing blind-merged mining returns -- as stealing will kill a sidechain, all the fees from it that miners would be expected to earn for the next years are gone;
2. The cost of Bitcoin price going down: If a steal is successful that will mean Drivechains are not safe, therefore Bitcoin is less useful, and miner credibility will also be hurt, which are likely to cause the Bitcoin price to go down, which in turn may kill the miners' businesses and savings;
3. The cost of coordination -- assuming miners are just normal businesses, they just want to do their work and get paid, but stealing from a Drivechain will require coordination with other miners to conduct an immoral act in a way that has many pitfalls and is likely to be broken over the months;
4. The cost of miners leaving your mining pool: when we talked about "miners" above we were actually talking about mining pools operators, so they must also consider the risk of miners migrating from their mining pool to others as they begin the process of stealing;
5. The cost of community goodwill -- when participating in a steal operation, a miner will suffer a ton of backlash from the community. Even if the attempt fails at the end, the fact that it was attempted will contribute to growing concerns over exaggerated miners power over the Bitcoin ecosystem, which may end up causing the community to agree on a hard-fork to change the mining algorithm in the future, or to do something to increase participation of more entities in the mining process (such as development or cheapment of new ASICs), which have a chance of decreasing the profits of current miners.

Another point to take in consideration is that one may be inclined to think a newly-created sidechain or a sidechain with relatively low usage may be more easily stolen from, since the blind merged mining returns from it (point 1 above) are going to be small -- but the fact is also that a sidechain with small usage will also have less money to be stolen from, and since the other costs besides 1 are less elastic at the end it will not be worth stealing from these too.

All of the above consideration are valid only if miners are stealing from good sidechains. If there is a sidechain that is doing things wrong, scamming people, not being used at all, or is full of bugs, for example, that will be perceived as a bad sidechain, and then miners can and will safely steal from it and kill it, which will be perceived as a good thing by everybody.

What do we do if miners steal?

Paul Sztorc has suggested in the past that a user-activated soft-fork could prevent miners from stealing, i.e., most Bitcoin users and nodes issue a rule similar to this one to invalidate the inclusion of a faulty WT^ and thus cause any miner that includes it in a block to be relegated to their own Bitcoin fork that other nodes won't accept.

This suggestion has made people think Drivechain is a sidechain solution backed by user-actived soft-forks for safety, which is very far from the truth. Drivechains must not and will not rely on this kind of soft-fork, although they are possible, as the coordination costs are too high and no one should ever expect these things to happen.

If even with all the incentives against them (see above) miners do still steal from a good sidechain that will mean the failure of the Drivechain experiment. It will very likely also mean the failure of the Bitcoin experiment too, as it will be proven that miners can coordinate to act maliciously over a prolonged period of time regardless of economic and social incentives, meaning they are probably in it just for attacking Bitcoin, backed by nation-states or something else, and therefore no Bitcoin transaction in the mainchain is to be expected to be safe ever again.

Why use this and not a full-blown trustless and open sidechain technology?

Because it is impossible.

If you ever heard someone saying "just use a sidechain", "do this in a sidechain" or anything like that, be aware that these people are either talking about "federated" sidechains (i.e., funds are kept in custody by a group of entities) or they are talking about Drivechain, or they are disillusioned and think it is possible to do sidechains in any other manner.

No, I mean a trustless 2-way peg with correctness of the withdrawals verified by the Bitcoin protocol!

That is not possible unless Bitcoin verifies all transactions that happen in all the sidechains, which would be akin to drastically increasing the blocksize and expanding the Bitcoin rules in tons of ways, i.e., a terrible idea that no one wants.

What about the Blockstream sidechains whitepaper?

Yes, that was a way to do it. The Drivechain hashrate escrow is a conceptually simpler way to achieve the same thing with improved incentives, less junk in the chain, more safety.

Isn't the hashrate escrow a very complex soft-fork?

Yes, but it is much simpler than SegWit. And, unlike SegWit, it doesn't force anything on users, i.e., it isn't a mandatory blocksize increase.

Why should we expect miners to care enough to participate in the voting mechanism?

Because it's in their own self-interest to do it, and it costs very little. Today over half of the miners mine RSK. It's not blind merged mining, it's a very convoluted process that requires them to run a RSK full node. For the Drivechain sidechains, an SPV node would be enough, or maybe just getting data from a block explorer API, so much much simpler.

What if I still don't like Drivechain even after reading this?

That is the entire point! You don't have to like it or use it as long as you're fine with other people using it. The hashrate escrow special addresses will not impact you at all, validation cost is minimal, and you get the benefit of people who want to use Drivechain migrating to their own sidechains and freeing up space for you in the mainchain. See also the point above about infighting.

See also

• Podcast episode with Ruben Somsen and Aaron van Wirdum explaining Drivechain
• Alternatives to Drivechain
• Drivechain comparison with Ethereum

@ 3bf0c63f:aefa459d

Bluesky is a scam

Bluesky advertises itself as an open network, they say people won't lose followers or their identity, they advertise themselves as a protocol ("atproto") and because of that they are tricking a lot of people into using them. These three claims are false.

protocolness

Bluesky is a company. "atproto" is the protocol. Supposedly they are two different things, right? Bluesky just releases software that implements the protocol, but others can also do that, it's open!

And yet, the protocol has an official webpage with a waitlist and a private beta? Why is the protocol advertised as a company product? Because it is. The "protocol" is just a description of whatever the Bluesky app and servers do, it can and does change anytime the Bluesky developers decide they want to change it, and it will keep changing for as long as Bluesky apps and servers control the biggest part of the network.

Oh, so there is the possibility of other players stepping in and then it becomes an actual interoperable open protocol? Yes, but what is the likelihood of that happening? It is very low. No serious competitor is likely to step in and build serious apps using a protocol that is directly controlled by Bluesky. All we will ever see are small "community" apps made by users and small satellite small businesses -- not unlike the people and companies that write plugins, addons and alternative clients for popular third-party centralized platforms.

And last, even if it happens that someone makes an app so good that it displaces the canonical official Bluesky app, then that company may overtake the protocol itself -- not because they're evil, but because there is no way it cannot be like this.

identity

According to their own documentation, the Bluesky people were looking for an identity system that provided global ids, key rotation and human-readable names.

They must have realized that such properties are not possible in an open and decentralized system, but instead of accepting a tradeoff they decided they wanted all their desired features and threw away the "decentralized" part, quite literally and explicitly (although they make sure to hide that piece in the middle of a bunch of code and text that very few will read).

The "DID Placeholder" method they decided to use for their global identities is nothing more than a normal old boring trusted server controlled by Bluesky that keeps track of who is who and can, at all times, decide to ban a person and deprive them from their identity (they dismissively call a "denial of service attack").

They decided to adopt this method as a placeholder until someone else doesn't invent the impossible alternative that would provide all their desired properties in a decentralized manner -- which is nothing more than a very good excuse: "yes, it's not great now, but it will improve!".

openness

Months after launching their product with an aura of decentralization and openness and getting a bunch of people inside that believed, falsely, they were joining an actually open network, Bluesky has decided to publish a part of their idea of how other people will be able to join their open network.

When I first saw their app and how they were very prominently things like follower counts, like counts and other things that are typical of centralized networks and can't be reliable or exact on truly open networks (like Nostr), I asked myself how were they going to do that once they became and open "federated" network as they were expected to be.

Turns out their decentralization plan is to just allow you, as a writer, to host your own posts on "personal data stores", but not really have any control over the distribution of the posts. All posts go through the Bluesky central server, called BGS, and they decide what to do with it. And you, as a reader, doesn't have any control of what you're reading from either, all you can do is connect to the BGS and ask for posts. If the BGS decides to ban, shadow ban, reorder, miscount, hide, deprioritize, trick or maybe even to serve ads, then you are out of luck.

Oh, but anyone can run their own BGS!, they will say. Even in their own blog post announcing the architecture they assert that "it’s a fairly resource-demanding service" and "there may be a few large full-network providers". But I fail to see why even more than one network provider will exist, if Bluesky is already doing that job, and considering the fact there are very little incentives for anyone to switch providers -- because the app does not seem to be at all made to talk to multiple providers, one would have to stop using the reliable, fast and beefy official BGS and start using some half-baked alternative and risk losing access to things.

When asked about the possibility of switching, one of Bluesky overlords said: "it would look something like this: bluesky has gone evil. there's a new alternative called freesky that people are rushing to. I'm switching to freesky".

The quote is very naïve and sounds like something that could be said about Twitter itself: "if Twitter is evil you can just run your own social network". Both are fallacies because they ignore the network-effect and the fact that people will never fully agree that something is "evil". In fact these two are the fundamental reasons why -- for social networks specifically (and not for other things like commerce) -- we need truly open protocols with no owners and no committees.

@ 3bf0c63f:aefa459d

A Lightning penalty transaction

It was a cold day and I remembered that this lightningd node I was running on my local desktop to work on poncho actually had mainnet channels in it. Two channels, both private, bought on https://lnbig.com/ a while ago when I was trying to conduct an anonymous griefing attack on big nodes of the network just to prove it was possible (the attempts proved unsuccessful after some hours and I gave up).

It is always painful to close channels because paying fees hurts me psychologically, and then it hurts even more to be left with a new small UTXO that will had to be spent to somewhere but that can barely pay for itself, but it also didn't make sense to just leave the channels there and risk forgetting them and losing them forever, so I had to do something.

One of the channels had 0 satoshis on my side, so that was easy. Mutually closed and I don't have to think anymore about it.

The other one had 10145 satoshis on my side -- out of a total of 100000 satoshis. Why can't I take my part all over over Lightning and leave the full channel UTXO to LNBIG? I wish I could do that, I don't want a small UTXO. I was not sure about it, but if the penalty reserve was 1% maybe I could take out abou 9000 satoshis and then close it with 1000 on my side? But then what would I do with this 1000 sat UTXO that would remain? Can't I donate it to miners or something?

I was in the middle of this thoughts stream when it came to me the idea of causing a penalty transaction to give those abundant 1000 sat to Mr. LNBIG as a donation for his excellent services to the network and the cause of Bitcoin, and for having supported the development of https://sbw.app/ and the hosted channels protocol.

Unfortunately lightningd doesn't have a command triggerpenaltytransaction or trytostealusingoldstate, so what I did was:

First I stopped lightningd then copied the database to elsewhere: cp ~/.lightningd/bitcoin/lightningd.sqlite3 ~/.lightning/bitcoin/lightningd.sqlite3.bak then I restarted lightningd and fighted against the way-too-aggressive MPP splitting algorithm the pay command uses to pay invoices, but finally managed to pull about 9000 satoshis to my Z Bot that lives on the terrible (but still infinitely better than Twitter DMs) "webk" flavor of the Telegram web application and which is linked to my against-bitcoin-ethos-country-censoring ZEBEDEE Wallet. The operation wasn't smooth but it didn't take more than 10 invoices and pay commands.

With the money out and safe elsewhere, I stopped the node again, moved the database back with a reckless mv ~/.lightning/bitcoin/lightningd.sqlite3.bak ~/.lightningd/bitcoin/lightningd.sqlite3 and restarted it, but to prevent my lightningd from being super naïve and telling LNBIG that it had an old state (I don't know if this would happen) which would cause LNBIG to close the channel in a boring way, I used the --offline flag which apparently causes the node to not do any external connections.

Finally I checked my balance using lightning-cli listfunds and there it was, again, the 10145 satoshis I had at the start! A fantastic money creation trick, comparable to the ones central banks execute daily.

I was ready to close the channel now, but the lightning-cli close command had an option for specifying how many seconds I would wait for a mutual close before proceeding to a unilateral close. There is no forceclose command like Éclair hasor anything like that. I was afraid that even if I gave LNBIG one second it would try to do boring things, so I paused to consider how could I just broadcast the commitment transaction manually, looked inside the SQLite database and the channels table with its millions of columns with cryptic names in the unbearable .schema output, imagined that lightningd maybe wouldn't know how to proceed to take the money from the to-local output if I managed to broadcast it manually (and in the unlikely event that LNBIG wouldn't broadcast the penalty transaction), so I decided to just accept the risk and call lightning-cli close 706327x1588x0 1

But it went well. The --offline flag apparently really works, as it just considered LNBIG to be offline and 1 second later I got the desired result.

My happiness was complete when I saw the commitment transaction with my output for 10145 satoshis published on the central database of Bitcoin, blockstream.info.

Then I went to eat something and it seems LNBIG wasn't offline or sleeping, he was certainly looking at all the logs from his 274 nodes in a big room full of monitors, very alert and eating an apple while drinking coffee, ready to take action, for when I came back, minutes later, I could see it, again on the single source of truth for the Bitcoin blockchain, the Blockstream explorer. I've refreshed the page and there it was, a small blue link right inside the little box that showed my to-local output, a notice saying it had been spent -- not by my lightningd since that would have to wait 9000 blocks, but by the same transaction that spent the other output, from which I could be very sure it was it, the glorious, mighty, unforgiving penalty transaction, splitting the earth, showing itself in all its power, and taking my 10145 satoshis to their rightful owner.

@ 3bf0c63f:aefa459d

The unit test bubble

Look at the following piece of Go code:

func NewQuery(query []rune) *Query { q := &Query{ query: &[]rune{}, complete: &[]rune{}, } _ = q.Set(query) return q } func NewQueryWithString(query string) *Query { return NewQuery([]rune(query)) }

It is taken from a GitHub project with over 2000 stars.

Now take a look at these unit tests for the same package:

``` func TestNewQuery(t *testing.T) { var assert = assert.New(t)

v := []rune(".name")
q := NewQuery(v)

assert.Equal(*q.query, []rune(".name"))
assert.Equal(*q.complete, []rune(""))

}

func TestNewQueryWithString(t *testing.T) { var assert = assert.New(t)

q := NewQueryWithString(".name")

assert.Equal(*q.query, []rune(".name"))
assert.Equal(*q.complete, []rune(""))

} ```

Now be honest: what are these for? Is this part of an attack to eat all GitHub storage and head them to bankruptcy?

Also

• my personal approach on using let, const and var in javascript

@ 3bf0c63f:aefa459d

A estrutura lógica do livro didático

Todos os livros didáticos e cursos expõem seus conteúdos a partir de uma organização lógica prévia, um esquema de todo o conteúdo que julgam relevante, tudo muito organizadinho em tópicos e subtópicos segundo a ordem lógica que mais se aproxima da ordem natural das coisas. Imagine um sumário de um manual ou livro didático.

A minha experiência é a de que esse método serve muito bem para ninguém entender nada. A organização lógica perfeita de um campo de conhecimento é o resultado final de um estudo, não o seu início. As pessoas que escrevem esses manuais e dão esses cursos, mesmo quando sabem do que estão falando (um acontecimento aparentemente raro), o fazem a partir do seu próprio ponto de vista, atingido após uma vida de dedicação ao assunto (ou então copiando outros manuais e livros didáticos, o que eu chutaria que é o método mais comum).

Para o neófito, a melhor maneira de entender algo é através de imersões em micro-tópicos, sem muita noção da posição daquele tópico na hierarquia geral da ciência.

• Revista Educativa, um exemplo de como não ensinar nada às crianças.
• Zettelkasten, a ordem surgindo do caos, ao invés de temas se encaixando numa ordem preexistentes.

@ 3bf0c63f:aefa459d

Boardthreads

This was a very badly done service for turning a Trello list into a helpdesk UI.

Surprisingly, it had more paying users than Websites For Trello, which I was working on simultaneously and dedicating much more time to it.

The Neo4j database I used for this was a very poor choice, it was probably the cause of all the bugs.

-https://github.com/fiatjaf/boardthreads

@ 3bf0c63f:aefa459d

Personagens de jogos e símbolos

A sensação de "ser" um personagem em um jogo ou uma brincadeira talvez seja o mais próximo que eu tenha conseguido chegar do entendimento de um símbolo religioso.

A hóstia consagrada é, segundo a religião, o corpo de Cristo, mas nossa mente moderna só consegue concebê-la como sendo uma representação do corpo de Cristo. Da mesma forma outras culturas e outras religiões têm símbolos parecidos, inclusive nos quais o próprio participante do ritual faz o papel de um deus ou de qualquer coisa parecida.

"Faz o papel" é de novo a interpretação da mente moderna. O sujeito ali é a coisa, mas ele ao mesmo tempo que é também sabe que não é, que continua sendo ele mesmo.

Nos jogos de videogame e brincadeiras infantis em que se encarna um personagem o jogador é o personagem. não se diz, entre os jogadores, que alguém está "encenando", mas que ele é e pronto. nem há outra denominação ou outro verbo. No máximo "encarnando", mas já aí já é vocabulário jornalístico feito para facilitar a compreensão de quem está de fora do jogo.

@ 3bf0c63f:aefa459d

bolt12 problems

• clients can't programatically build new offers by changing a path or query params (services like zbd.gg or lnurl-pay.me won't work)
• impossible to use in a load-balanced custodian way -- since offers would have to be pregenerated and tied to a specific lightning node.
• the existence of fiat currency fields makes it so wallets have to fetch exchange rates from somewhere on the internet (or offer a bad user experience), using HTTP which hurts user privacy.
• the vendor field is misleading, can be phished very easily, not as safe as a domain name.
• onion messages are an improvement over fake HTLC-based payments as a way of transmitting data, for sure. but we must decide if they are (i) suitable for transmitting all kinds of data over the internet, a replacement for tor; or (ii) not something that will scale well or on which we can count on for the future. if there was proper incentivization for data transmission it could end up being (i), the holy grail of p2p communication over the internet, but that is a very hard problem to solve and not guaranteed to yield the desired scalability results. since not even hints of attempting to solve that are being made, it's safer to conclude it is (ii).

bolt12 limitations

• not flexible enough. there are some interesting fields defined in the spec, but who gets to add more fields later if necessary? very unclear.
• services can't return any actionable data to the users who paid for something. it's unclear how business can be conducted without an extra communication channel.

bolt12 illusions

• recurring payments is not really solved, it is just a spec that defines intervals. the actual implementation must still be done by each wallet and service. the recurring payment cannot be enforced, the wallet must still initiate the payment. even if the wallet is evil and is willing to initiate a payment without the user knowing it still needs to have funds, channels, be online, connected etc., so it's not as if the services could rely on the payments being delivered in time.
• people seem to think it will enable pushing payments to mobile wallets, which it does not and cannot.
• there is a confusion of contexts: it looks like offers are superior to lnurl-pay, for example, because they don't require domain names. domain names, though, are common and well-established among internet services and stores, because these services have websites, so this is not really an issue. it is an issue, though, for people that want to receive payments in their homes. for these, indeed, bolt12 offers a superior solution -- but at the same time bolt12 seems to be selling itself as a tool for merchants and service providers when it includes and highlights features as recurring payments and refunds.
• the privacy gains for the receiver that are promoted as being part of bolt12 in fact come from a separate proposal, blinded paths, which should work for all normal lightning payments and indeed are a very nice solution. they are (or at least were, and should be) independent from the bolt12 proposal. a separate proposal, which can be (and already is being) used right now, also improves privacy for the receiver very much anway, it's called trampoline routing.

@ 3bf0c63f:aefa459d

WelcomeBot

The first bot ever created for Trello.

It invited to a public board automatically anyone who commented on a card he was added to.

• https://github.com/fiatjaf/welcomebot
• https://trello.com/welcomebot

@ 3bf0c63f:aefa459d

Sol e Terra

A Terra não gira em torno do Sol. Tudo depende do ponto de referência e não existe um ponto de referência absoluto. Só é melhor dizer que a Terra gira em torno do Sol porque há outros planetas fazendo movimentos análogos e aí fica mais fácil para todo mundo entender os movimentos tomando o Sol como ponto de referência.

@ 3bf0c63f:aefa459d

Rede Relâmpago

Ao se referir à Lightning Network do O que é Bitcoin?, nós, brasileiros e portugueses, devemos usar o termo "Relâmpago" ou "Rede Relâmpago". "Relâmpago" é uma palavra bonita e apropriada, e fácil de pronunciar por todos os nossos compatriotas. Chega de anglicismos desnecessários.

Exemplo de uma conversa hipotética no Brasil usando esta nomenclatura:

– Posso pagar com Relâmpago?

– Opa, claro! Vou gerar um boleto aqui pra você.

Repare que é bem mais natural e fácil do que a outra alternativa:

– Posso pagar com láitenim?

– Leite ninho?

@ 3bf0c63f:aefa459d

The Lightning Network solves the problem of the decentralized commit

Before reading this, see Ripple and the problem of the decentralized commit.

The Bitcoin Lightning Network can be thought as a system similar to Ripple: there are conditional IOUs (HTLCs) that are sent in "prepare"-like messages across a route, and a secret p that must travel from the final receiver backwards through the route until it reaches the initial sender and possession of that secret serves to prove the payment as well as to make the IOU hold true.

The difference is that if one of the parties don't send the "acknowledge" in time, the other has a trusted third-party with its own clock (that is the clock that is valid for everybody involved) to complain immediately at the timeout: the Bitcoin blockchain. If C has p and B isn't acknowleding it, C tells the Bitcoin blockchain and it will force the transfer of the amount from B to C.

Differences (or 1 upside and 3 downside)

1. The Lightning Network differs from a "pure" Ripple network in that when we send a "prepare" message on the Lightning Network, unlike on a pure Ripple network we're not just promising we will owe something -- instead we are putting the money on the table already for the other to get if we are not responsive.

2. The feature above removes the trust element from the equation. We can now have relationships with people we don't trust, as the Bitcoin blockchain will serve as an automated escrow for our conditional payments and no one will be harmed. Therefore it is much easier to build networks and route payments if you don't always require trust relationships.

3. However it introduces the cost of the capital. A ton of capital must be made available in channels and locked in HTLCs so payments can be routed. This leads to potential issues like the ones described in https://twitter.com/joostjgr/status/1308414364911841281.

4. Another issue that comes with the necessity of using the Bitcoin blockchain as an arbiter is that it may cost a lot in fees -- much more than the value of the payment that is being disputed -- to enforce it on the blockchain.[^closing-channels-for-nothing]

Solutions

Because the downsides listed above are so real and problematic -- and much more so when attacks from malicious peers are taken into account --, some have argued that the Lightning Network must rely on at least some trust between peers, which partly negate the benefit.

The introduction of purely trust-backend channels is the next step in the reasoning: if we are trusting already, why not make channels that don't touch the blockchain and don't require peers to commit large amounts of capital?

The reason is, again, the ambiguity that comes from the problem of the decentralized commit. Therefore hosted channels can be good when trust is required only from one side, like in the final hops of payments, but they cannot work in the middle of routes without eroding trust relationships between peers (however they can be useful if employed as channels between two nodes ran by the same person).

The next solution is a revamped pure Ripple network, one that solves the problem of the decentralized commit in a different way.

[^closing-channels-for-nothing]: That is even true when, for reasons of the payment being so small that it doesn't even deserve an actual HTLC that can be enforced on the chain (as per the protocol), even then the channel between the two nodes will be closed, only to make it very clear that there was a disagreement. Leaving it online would be harmful as one of the peers could repeat the attack again and again. This is a proof that ambiguity, in case of the pure Ripple network, is a very important issue.

@ 3bf0c63f:aefa459d

Liquidificador

A fragilidade da comunicação humana fica clara quando alguém liga o liquidificador.

@ 3bf0c63f:aefa459d

A Causa

o Princípios de Economia Política de Menger é o único livro que enfatiza a CAUSA o tempo todo. os cientistas todos parecem não saber, ou se esquecer sempre, que as coisas têm causa, e que o conhecimento verdadeiro é o conhecimento da causa das coisas.

a causa é uma categoria metafísica muito superior a qualquer correlação ou resultado de teste de hipótese, ela não pode ser descoberta por nenhum artifício econométrico ou reduzida à simples antecedência temporal estatística. a causa dos fenômenos não pode ser provada cientificamente, mas pode ser conhecida.

o livro de Menger conta para o leitor as causas de vários fenômenos econômicos e as interliga de forma que o mundo caótico da economia parece adquirir uma ordem no momento em que você lê. é uma sensação mágica e indescritível.

quando eu te o recomendei, queria é te imbuir com o espírito da busca pela causa das coisas. depois de ler aquilo, você está apto a perceber continuidade causal nos fenômenos mais complexos da economia atual, enxergar as causas entre toda a ação governamental e as suas várias consequências na vida humana. eu faço isso todos os dias e é a melhor sensação do mundo quando o caos das notícias do caderno de Economia do jornal -- que para o próprio jornalista que as escreveu não têm nenhum sentido (tanto é que ele escreve tudo errado) -- se incluem num sistema ordenado de causas e consequências.

provavelmente eu sempre erro em alguns ou vários pontos, mas ainda assim é maravilhoso. ou então é mais maravilhoso ainda quando eu descubro o erro e reinsiro o acerto naquela racionalização bela da ordem do mundo econômico que é a ordem de Deus.

em scrap para T.P.

@ 3bf0c63f:aefa459d

Método científico

o método científico não pode ser aplicado senão numa meia dúzia de casos, e no entanto ei-nos aqui, pensando nele para tudo.

"formule hipóteses e teste-as independentemente", "obtenha uma quantidade de dados estatisticamente significante", teste, colete dados, mensure.

não é que de repente todo mundo resolveu calcular desvios-padrão, mas sim que é comum, para as pessoas mais cultas, nível Freakonomics, acharem que têm que testar e coletar dados, e nunca jamais confiar na sua "intuição" ou, pior, num raciocínio que pode parecer certo, mas na verdade é enormemente enganador.

sim, é verdade que raciocínios com explicações aparentemente sensatas nos são apresentados todos os dias -- para um exemplo fácil é só imaginar um comentarista de jornal, ou até uma matéria inocente de jornal, aliás, melhor pensar num comentarista da GloboNews --, e sim, é verdade que a maioria dessas explicações é falsa.

o que está errado é achar que só o que vale é testar hipóteses. você não pode testar a explicação aparentemente sensata que o taxista te fornece sobre a crise brasileira, deve então anotá-la para testar depois? mantê-la para sempre no cabedal das teorias ainda por testar?

e a explicação das redinhas que economizam água quando instaladas na torneira? essa dá pra testar, então você vai comprar um relógio de água e deixar a torneira ligada lá 5 horas com a redinha, depois 5 horas sem a redinha? obviamente não vai funcionar se você abrir o mesmo tanto, você vai precisar de um critério melhor: a satisfação da pessoa que está lavando as mãos com o resultado final versus a quantidade de água gasta. daí você precisaria de muitas pessoas, mas satisfação é uma coisa imensurável, nem adianta tentar fazer entrevistas antes e depois com as pessoas. o certo então, é o quê? procurar um estudo científico publicado numa revista de qualidade (porque tem aquelas revistas que aceitam estudos gerados por computador, então é melhor tomar cuidado) que fala sobre redinhas? como saber se a redinha é a mesma que você comprou? e agora que você já comprou, o resultado do experimento importa? (claro: pode ser que a redinha faça gastar mais água, você nunca saberá até que faça o experimento).

por que não, ao invés de condenar todos os raciocínios como enganadores e mandar que as pessoas façam experimentos científicos, ensinar a fazer raciocínios certos?

@ 3bf0c63f:aefa459d

Processos Antifrágeis

Há esse conceito, criado pelo genial Nassim Nicholas Taleb, que diz respeito a processos nos quais a curva de retorno em relação a uma variável aleatória é convexa, ou seja, o retorno tende a ser maior quanto mais aleatoriedade for adicionada ao processo.

Disso aí, o próprio Taleb tira uma conclusão que resolve a questão da pesquisa científica propositada contra a sorte, sobre quais levam a melhores resultados práticos e invenções. Escreve ele:

A história da sorte versus conhecimento é a seguinte: Ironicamente, temos imensamente mais evidência de resultados (descobertas úteis) ligados à sorte do que de resultados vindos da prática teleológica (de telos, “objetivo”), exceto na física — mesmo depois de descontarmos o sensacionalismo. Em alguns campos opacos e não-lineares, como a medicina ou a engenharia, as exceções teleológicas são a minoria, assim como são um pequeno número de remédios projetados. Isto nos deixa numa contradição de que chegamos até aqui graças ao puro acaso não-direcionado, mas ao mesmo tempo criamos programas de pesquisa que miram num progresso com direção definida, baseado em narrativas sobre o passado. E, o que é pior, estamos totalmente conscientes desta inconsistência.

Por outro lado, pura sorte não poderia produzir melhorias sempre. Processos de tentativa e erro (que são os que produzem as descobertas “por sorte”) têm um elemento erro, e erros, diz Taleb, causam explosões de avião, quedas de edifícios e perda de conhecimento.

A resposta, portanto, está na antifragilidade: as áreas onde a sorte vence a teleologia são as áreas onde estão em jogo sistemas complexos, onde os nexos causais são desconhecidos ou obscuros — e são as áreas onde a curva de retornos é convexa.

Vejamos a mais sombria de todas, a culinária, que depende inteiramente da heurística da tentativa e erro, já que ainda não nos foi possível projetar um prato direto de equações químicas ou descobrir, por engenharia reversa, gostos a partir de tabelas nutricionais. Pega-se o hummus, adiciona-se um ingrediente, digamos, uma pimenta, prova-se para ver se há uma melhora no gosto e guarda-se a receita, se o gosto for bom, ou descarta-se-á. Imprescindivelmente temos a opção, e não a obrigação, de guardar o resultado, o que nos deixa reter a parte superior da curva e nos impede de sermos lesados pelos retornos adversos.

A conclusão geral é que, para obter os melhores resultados na invenção de tecnologias, deve-se usar a experimentação sem exageros e cálculos quando se identificar uma área antifrágil, e usar a pesquisa rígida e cheia de provas matemáticas (ou o equivalente) quando a área for frágil.

A inovação capitalista

Um processo antifrágil importantíssimo deste mundo é a inovação capitalista (dói-me usar este termo já tão mal-gasto e mal-definido por aí). Não falo, como alguns, da invenção de novas tecnologias, mas, como outros, da invenção de novas formas de usar as coisas (qualquer coisa) para melhorar a vida de alguém, de alguma forma — e aqui incluem-se pequenas adaptações de tecnologias antigas que dão origem a novas tecnologias não muito diferentes das antigas, e incluem-se também o oferecimento de algum serviço, trabalho ou produto já existente, mas de uma nova forma, possivelmente melhor para seu provável consumidor. Este tipo de inovação é, segundo me parece, o poder mais subestimado dos mercados livres, é irreplicável em laboratórios de pesquisa tecnológica (só pode surgir mesmo na vida real, da cabeça de quem está envolvido com o problema real que a inovação soluciona), e é o que gerou idéias como o restaurante self-service, a terceirização dos serviços de construção civil ou o Google.

Esse tipo de inovação (ao contrário do sentido de inovação ligado a pesquisas caríssimas em universidades ou megaempresas, identificada pela famigerada sigla P&D) é antifrágil porque não custa muito ao indivíduo, não requer investimentos gigantescos ou qualquer coisa assim, porque é normalmente apenas uma adaptação do que ele próprio já faz.

Para a sociedade, não representa custo algum: o serviço novo é oferecido paralelamente ao serviço antigo, seus consumidores potenciais podem escolher o que mais lhes agrada, e rejeitar o outro. Se a nova solução não for satisfatória os mecanismos automáticos do mercado (o prejuízo simples) encarregam-se automaticamente de remover aquela novidade — e, automaticamente, o indivíduo que a criou pode se voltar ao seu processo antigo, ou a uma nova invenção.

Ao mesmo tempo em que cometer um erro numa tentativa de inovação é barato e não atrapalha ninguém, um acerto pode ter conseqüências que melhoram enormemente a vida de muita gente. O restaurante self-service, por exemplo, provavelmente teve sua implementação tentada por restaurantes de serviço à la carte várias vezes, em vários formatos diferentes, sem muito prejuízo para o restaurante, que podia continuar com seu serviço à la carte (no Brasil, senão o inventor dessa modalidade de restaurante ao menos um dos seus grandes expoentes, estas tentativas ocorreram durante a década de 80). Mas, quando enfim deu certo, promoveu melhoras enormes na qualidade de vida de milhares de pessoas — que podem pagar mais barato e comer apenas o que querem e quanto querem, dentro de uma gama maior de opções, o que permite que trabalhadores de todos os tipos comam melhor todos os dias, fiquem mais felizes e gastem menos.

@ 3bf0c63f:aefa459d

Veterano não é dono de bixete

"VETERANO NÃO É DONO DE BIXETE". A frase em letras garrafais chama a atenção dos transeuntes neófitos. Paira sobre um cartaz amarelo que lista várias reclamações contra os "trotes machistas", que, na opinião do responsável pelo cartaz, "não é brincadeira, é opressão".

Eis aí um bizarro exemplo de como são as coisas: primeiro todos os universitários aprovam a idéia do trote, apoiam sua realização e até mesmo desejam sofrer o trote -- com a condição de o poderem aplicar eles mesmos depois --, louvam as maravilhas do mundo universitário, onde a suprema sabedoria se esconde atrás de rituais iniciáticos fora do alcance da imaginação do homem comum e rude, do pobre e do filhinho-de-papai das faculdades privadas; em suma: fomentam os mais baixos, os mais animalescos instintos, a crueldade primordial, destroem em si mesmos e nos colegas quaisquer valores civilizatórios que tivessem sobrado ali, ficando todos indistingüíveis de macacos agressivos e tarados.

Depois vêm aí com um cartaz protestar contra os assédios -- que sem dúvida acontecem em larguíssima escala -- sofridos pelas calouras de 17 anos e que, sendo também novatas no mundo universitário, ainda conservam um pouco de discernimento e pudor.

A incompreensão do fenômeno, porém, é tão grande, que os trotes não são identificados como um problema mental, uma doença que deve ser tratada e eliminada, mas como um sintoma da opressão machista dos homens às mulheres, um produto desta civilização paternalista que, desde que Deus é chamado "o Pai" e não "a Mãe", corrompe a benéfica, pura e angélica natureza do homem primitivo e o torna esta tão torpe criatura.

Na opinião dos autores desse cartaz é preciso, pois, continuar a destruir o que resta da cultura ocidental, e então esperar que haja trotes menos opressores.

@ 3bf0c63f:aefa459d

sitio

A static site generator that works with imperative code instead of declarative templates and directory structures. It assumes nothing and can be used to transform anything into HTML pages.

It uses React so it can be used to generate single-page apps too if you want -- and normal sites that work like single-page apps.

It also provides helpers for reading Markdown files, like all static site generator does.

A long time after creating this and breaking it while trying to add too many features at once I realized Gatsby also had an imperative engine underlying the default declarative interface that could be used and it was pretty similar to sitio. That both made me happy to have arrived at the same results of such an acclaimed tool and sad for the same reason, as Gatsby is the worse static site generator ever created considering user experience.

• https://github.com/fiatjaf/sitio

@ 3bf0c63f:aefa459d

neuron.vim

I started using this neuron thing to create an update this same zettelkasten, but the existing vim plugin had too many problems, so I forked it and ended up changing almost everything.

Since the upstream repository was somewhat abandoned, most users and people who were trying to contribute upstream migrate to my fork too.

• https://github.com/fiatjaf/neuron.vim

@ 3bf0c63f:aefa459d

IPFS problems: Too much immutability

Content-addressing is unusable with an index or database that describes each piece of content. Since IPFS is fully content-addressable, nothing can be done with it unless you have a non-IPFS index or database, or an internal protocol for dynamic and updateable links.

The IPFS conceit made then go with the with the second option, which proved to be a failure. They even incentivized the creation of a database powered by IPFS, which couldn't be more misguided.

@ 3bf0c63f:aefa459d

Cultura Inglesa e aprendizado extra-escolar

Em 2005 a Cultura Inglesa me classificou como nível 2 em proficiência de inglês, numa escala de 1 a 14 ou coisa parecida. De modo que eu precisaria de 6 anos de aulas com eles pra ficar bom. 2 anos depois, sem fazer nenhuma aula ou ter qualquer tipo de treinamento intensivo eu era capaz de compreender textos técnicos em inglês sem nenhuma dificuldade. Mais 2 anos e eu era capaz de compreender qualquer coisa e me expressar com razoável qualidade.

Tudo isso pra documentar mais um exemplo, que poderia passar despercebido, de aprendizado de tipo escolar que se deu fora de uma escola.

@ 3bf0c63f:aefa459d

Scala is such a great language

Scala is amazing. The type system has the perfect balance between flexibility and powerfulness. match statements are great. You can write imperative code that looks very nice and expressive (and I haven't tried writing purely functional things yet). Everything is easy to write and cheap and neovim integration works great.

But Java is not great. And the fact that Scala is a JVM language doesn't help because over the years people have written stuff that depends on Java libraries -- and these Java libraries are not as safe as the Scala libraries, they contain reflection, slowness, runtime errors, all kinds of horrors.

Scala is also very tightly associated with Akka, the actor framework, and Akka is a giant collection of anti-patterns. Untyped stuff, reflection, dependency on JVM, basically a lot of javisms. I just arrived and I don't know anything about the Scala history or ecosystem or community, but I have the impression that Akka has prevent more adoption of Scala from decent people that aren't Java programmers.

But luckily there is a solution -- or two solutions: ScalaJS is a great thing that exists. It transpiles Scala code into JavaScript and it runs on NodeJS or in a browser!

Scala Native is a much better deal, though, it compiles to LLVM and then to binary code and you can have single binaries that run directly without a JVM -- not that the single JARs are that bad though, they are great and everybody has Java so I'll take that anytime over C libraries or NPM-distributed software, but direct executables even better. Scala Native just needs a little more love and some libraries and it will be the greatest thing in a couple of years.

@ 3bf0c63f:aefa459d

Webvatar

Like Gravatar, but using profile images from websites tagged with "microformats-2" tags, like people from the indiewebcamp movement liked. It falled back to favicon, gravatar and procedural avatar generators.

No one really used this, despite people saying they liked it. Since I was desperate to getting some of my programs appreciated by someone I even bought a domain. It was sad, but an enriching experience.

• https://github.com/fiatjaf/webvatar.com
• http://webvatar.com

See also

• jekmentions
• questo.email

@ 3bf0c63f:aefa459d

Per Bylund's insight

The firm doesn't exist because, like Coase said, it is inefficient to operate in a fully open-market and production processes need some bubbles of central planning.

Instead, what happens is that a firm is created because an entrepreneur is doing a new thing (and here I imagine that doing an old thing in a new context also counts as doing a new thing, but I didn't read his book), and for that new thing there is no market, there are no specialized workers offering the services needed, nor other businesses offering the higher-order goods that entrepreneur wants, so he must do all by himself.

So the entrepreneur goes and hires workers and buys materials more generic than he wanted and commands these to build what he wants exactly. It is less efficient than if he could buy the precise services and goods he wanted and combine those to yield the product he envisaged, but it accomplishes the goal.

Later, when that specific market evolves, it's natural that specialized workers and producers of the specific factors begin to appear, and the market gets decentralized.

@ 3bf0c63f:aefa459d

Obra aqui do lado

Tem quase um ano que estão fazendo uma obra aqui do lado e eu não ganhei nenhuma indenização. Numa sociedade sem Estado isso jamais teria acontecido.

@ 3bf0c63f:aefa459d

On "zk-rollups" applied to Bitcoin

ZK rollups make no sense in bitcoin because there is no "cheap calldata". all data is already ~~cheap~~ expensive calldata.

There could be an onchain zk verification that allows succinct signatures maybe, but never a rollup.

What happens is: you can have one UTXO that contains multiple balances on it and in each transaction you can recreate that UTXOs but alter its state using a zk to compress all internal transactions that took place.

The blockchain must be aware of all these new things, so it is in no way "L2".

And you must have an entity responsible for that UTXO and for conjuring the state changes and zk proofs.

But on bitcoin you also must keep the data necessary to rebuild the proofs somewhere else, I'm not sure how can the third party responsible for that UTXO ensure that happens.

I think such a construct is similar to a credit card corporation: one central party upon which everybody depends, zero interoperability with external entities, every vendor must have an account on each credit card company to be able to charge customers, therefore it is not clear that such a thing is more desirable than solutions that are truly open and interoperable like Lightning, which may have its defects but at least fosters a much better environment, bringing together different conflicting parties, custodians, anyone.

@ 3bf0c63f:aefa459d

Eltoo

Read the paper, it's actually nice and small. You can read only everything up to section 4.2 and it will be enough. Done.

Ok, you don't want to. Or you tried but still want to read here.

Eltoo is a way of keeping payment channel state that works better than the original scheme used in Lightning. Since Lightning is a bunch of different protocols glued together, it can It replace just the part the previously dealed with keeping the payment channel.

Eltoo works like this: A and B want a payment channel, so they create a multisig transaction with deposits from both -- or from just one, doesn't matter. That transaction is only spendable if both cooperate. So if one of them is unresponsive or non-cooperative the other must have a way to get his funds back, so they also create an update transaction but don't publish it to the blockchain. That update transaction spends to a settlement transaction that then distributes the money back to A and B as their balances say.

If they are cooperative they can change the balances of the channel by just creating new update transactions and settlement transactions and number them like 1, 2, 3, 4 etc.

Solid arrows means a transaction is presigned to spend only that previous other transaction; dotted arrows mean it's a floating transaction that can spend any of the previous.

Why do they need and update and a settlement transaction?

Because if B publishes update2 (in which his balances were greater) A needs some time to publish update4 (the latest, which holds correct state of balances).

Each update transaction can be spent by any newer update transaction immediately or by its own specific settlement transaction only after some time -- or some blocks.

Hopefully you got that.

How do they close the channel?

If they're cooperative they can just agree to spend the funding transaction, that first multisig transaction I mentioned, to whatever destinations they want. If one party isn't cooperating the other can just publish the latest update transaction, wait a while, then publish its settlement transaction.

How is this better than the previous way of keeping channel states?

Eltoo is better because nodes only have to keep the last set of update and settlement transactions. Before they had to keep all intermediate state updates.

If it is so better why didn't they do it first?

Because they didn't have the idea. And also because they needed an update to the Bitcoin protocol that allowed the presigned update transactions to spend any of the previous update transactions. This protocol update is called SIGHASH_NOINPUT[^anyprevout], you've seen this name out there. By marking a transaction with SIGHASH_NOINPUT it enters a mystical state and becomes a floating transaction that can be bound to any other transaction as long as its unlocking script matches the locking script.

Why can't update2 bind itself to update4 and spend that?

Good question. It can. But then it can't anymore, because Eltoo uses OP_CHECKLOCKTIMEVERIFY to ensure that doesn't actually check not a locktime, but a sequence. It's all arcane stuff.

And then Eltoo update transactions are numbered and their lock/unlock scripts will only match if a transaction is being spent by another one that's greater than it.

Do Eltoo channels expire?

No.

What is that "on-chain protocol" they talk about in the paper?

That's just an example to guide you through how the off-chain protocol works. Read carefully or don't read it at all. The off-chain mechanics is different from the on-chain mechanics. Repeating: the on-chain protocol is useless in the real world, it's just a didactic tool.

[^anyprevout]: Later SIGHASH_NOINPUT was modified to fit better with Taproot and Schnorr signatures and renamed to SIGHASH_ANYPREVOUT.

@ 3bf0c63f:aefa459d

Truthcoin as a spacechain

To be clear, the term "spacechain" here refers only to the general concept of blindly merge-mined (BMM) chains without a native money-token, not including the "spacecoins".

The basic idea is that for Truthcoin/Hivemind to work we need

1. Balances of Votecoin tokens, i.e. a way to keep track of who owns how much of the oracle corporation;
2. Bitcoin tokens to be used for buying and selling prediction market shares, i.e. money to gamble;
3. A blockchain, i.e. some timestamping service that emits blocks ordered with transactions and can keep track of internal state and change the state -- including the balances of the Votecoin tokens and of the Bitcoin tokens that are assigned to individual prediction markets according to predefined rules;

A spacechain, i.e. a blindly merge-mined chain, gives us 1 and 3. We can just write any logic for that and that should be very easy. It doesn't give us 2, and it also has the problem of how the spacechain users can pay the spacechain miners (which is why the spacecoins were envisioned in the first place, but we don't have spacecoins here).

But remember we have votecoins already. Votecoins (VTC) should represent a share in the oracle corporation, which means they entitle their holders to some revenue -- even though they also burden their holders with the duty to vote in event outcomes (at the risk of losing part of their own votecoin balance) --, and they can be exchanged, so we can assume they will have some value.

So we could in theory use these valuable tokens to pay the spacechain miners. That wouldn't be great because it pervert their original purpose and wouldn't solve the problem 2 from above -- unless we also used the votecoins to bet in which case they wouldn't be just another shitcoin in the planet with no network effect competing against Bitcoin and would just cause harm to humanity.

What we can do instead is to create a native mechanism for issuing virtual Bitcoin tokens (vBTC) in this chain, collaterized by votecoins, then we can use these vBTC to both gamble (solve problem 2) and pay miners (fix the hole in the spacechain BMM design).

For example, considering the VTC to be worth 0.001 BTC, any VTC holder could put 0.005 VTC and get 0.001 vBTC, then use to gamble or sell to others who want to gamble. The VTC holder still technically owns the VTC and can and must still participate in the oracle decisions. They just have to pay the BTC back before they can claim their VTC back if they want to send it elsewhere.

They stand to gain by selling vBTC if there is a premium for vBTC over BTC (i.e. people want to gamble) and then rebuying vBTC back once that premium goes away or reverts itself.

For this scheme to work the chain must know the exchange rate between VTC and BTC, which can be provided by the oracle corporation itself.

@ 3bf0c63f:aefa459d

Splitpages

The simplest possible service: it splitted PDF pages in half.

Created specially to solve the problem of those scanned books that come with two pages side-by-side as if they were a single page and are much harder to read on Kindle because of that.

It required me to learn about Heroku Buildpacks though, and fork or contribute to a Heroku Buildpack that embedded a mupdf binary.

• https://github.com/fiatjaf/splitpages
• https://splitpages.herokuapp.com/

@ 3bf0c63f:aefa459d

idea: Hosted-channels Lightning wallet that runs in the browser

Communicates over HTTP with a server that is actually connected to the Lightning Network, but generates preimages and onions locally, doing everything like the Hosted Channels protocol says. Just the communication method changes.

Could use this library: https://www.npmjs.com/package/bolt04

@ 3bf0c63f:aefa459d

tempreites

My first library to get stars on GitHub, was a very stupid templating library that used just HTML and HTML attributes ("DSL-free"). I was inspired by http://microjs.com/ at the time and ended up not using the library. Probably no one ever did.

• https://github.com/fiatjaf/tempreites

@ 3bf0c63f:aefa459d

litepub

A Go library that abstracts all the burdensome ActivityPub things and provides just the right amount of helpers necessary to integrate an existing website into the "fediverse" (what an odious name). Made for the gravity integration.

• https://godoc.org/github.com/fiatjaf/litepub

See also

-

@ 3bf0c63f:aefa459d

The problem with ION

ION is a DID method based on a thing called "Sidetree".

I can't say for sure what is the problem with ION, because I don't understand the design, even though I have read all I could and asked everybody I knew. All available information only touches on the high-level aspects of it (and of course its amazing wonders) and no one has ever bothered to explain the details. I've also asked the main designer of the protocol, Daniel Buchner, but he may have thought I was trolling him on Twitter and refused to answer, instead pointing me to an incomplete spec on the Decentralized Identity Foundation website that I had already read before. I even tried to join the DIF as a member so I could join their closed community calls and hear what they say, maybe eventually ask a question, so I could understand it, but my entrance was ignored, then after many months and a nudge from another member I was told I had to do a KYC process to be admitted, which I refused.

One thing I know is:

• ION is supposed to provide a way to rotate keys seamlessly and automatically without losing the main identity (and the ION proponents also claim there are no "master" keys because these can also be rotated).
• ION is also not a blockchain, i.e. it doesn't have a deterministic consensus mechanism and it is decentralized, i.e. anyone can publish data to it, doesn't have to be a single central server, there may be holes in the available data and the protocol doesn't treat that as a problem.
• From all we know about years of attempts to scale Bitcoins and develop offchain protocols it is clear that you can't solve the double-spend problem without a central authority or a kind of blockchain (i.e. a decentralized system with deterministic consensus).
• Rotating keys also suffer from the double-spend problem: whenever you rotate a key it is as if it was "spent", you aren't supposed to be able to use it again.

The logic conclusion of the 4 assumptions above is that ION is flawed: it can't provide the key rotation it says it can if it is not a blockchain.

See also

• Excerpt of discussion about DIDs and ION

@ 3bf0c63f:aefa459d

As estrelas

As estrelas são buracos nas esferas celestiais, buracos através dos quais nos é permitido ver a brilhante luz dos céus.

(Rome, a série.)

@ 3bf0c63f:aefa459d

UBI calculations

The United States population (counting only people more than 25 years old) is 222098080 people, the United States GDP is 20807000000000 USD. The Federal government has received 5845968000000 in taxes in 2019.

The standard UBI plan (from Andrew Yang) is to give $1000 to each person every month, which means a total annual expenditure of 2665176960000 USD, or 12.81% of the GDP and 45.59% of all tax money received from the federal government.

Mandatory spending (which includes healthcare and social security) corresponds to $2.7 trillion, or 46.18% of annual receipts. Discretionary spending (which includes education and military stuff) corresponds to $1.3 trillion, or 22.23% of annual receipts.

Does it fit?

If you are capable of cutting more-or-less all spending in social security (17.10% of federal receipts), all military (11.56%), all education, transportation, housing, veterans benefits and most other things the federal government does (11.30%) and parts of Medicare and Medicaid (26.17%) then it will be possible to fit UBI.

Welcome to the leftist paradise, one in which the government budget has to be drastically cut in every possible (cruel?) way.

Data sources

• https://en.wikipedia.org/wiki/United_States
• https://en.wikipedia.org/wiki/Demographics_of_the_United_States#Structure
• https://en.wikipedia.org/wiki/Government_spending_in_the_United_States
• https://www.bea.gov/tools/
• https://www.pbs.org/newshour/politics/how-would-andrew-yang-give-americans-1000-per-month-with-this-tax

@ 3bf0c63f:aefa459d

Lagoa Santa: como chegar -- partindo da rodoviária de Belo Horizonte

Ao descer de seu ônibus na rodoviária de Belo Horizonte às 4 e pouco da manhã, darás de frente para um caubói que toma cerveja em seus trajes típicos em um bar no setor mesmo de desembarque. Suba a escada à direita que dá no estacionamento da rodoviária. Vire à esquerda e caminhe por mais ou menos 400 metros, atravessando uma área onde pessoas suspeitas -- mas provavelmente dormindo em pé -- lhe observam, e então uma pracinha ocupada por um clã de mendigos. Ao avistar um enorme obelisco no meio de um cruzamento de duas avenidas, vire à esquerda e caminhe por mais 400 metros. Você verá uma enorme, antiga e bela estação com uma praça em frente, com belas fontes aqüáticas. Corra dali e dirija-se a um pedaço de rua à direita dessa praça. Um velho palco de antigos carnavais estará colocado mais ou menos no meio da simpática ruazinha de parelepípedos: é onde você pegará seu próximo ônibus.

Para entrar na estação é necessário ter um cartão com créditos recarregáveis. Um viajante prudente deixa sempre um pouco de créditos em seu cartão a fim de evitar filas e outros problemas de indisponibilidade quando chega cansado de viagem, com pressa ou em horários incomuns. Esse tipo de pessoa perceberá que foi totalmente ludibriado ao perceber que que os créditos do seu cartão, abastecido quando de sua última vinda a Belo Horizonte, há três meses, pereceram de prazo de validade e foram absorvidos pelos cofre públicos. Terá, portanto, que comprar mais créditos. O guichê onde os cartões são abastecidos abre às 5h, mas não se espante caso ele não tenha sido aberto ainda quando o primeiro ônibus chegar, às 5h10.

Com alguma sorte, um jovem de moletom, autorizado por dois ou três fiscais do sistema de ônibus que conversam alegremente, será o operador da catraca. Ele deixa entrar sem pagar os bêbados, os malandros, os pivetes. Bastante empático e perceptivo do desespero dos outros, esse bom rapaz provavelmente também lhe deixará entrar sem pagar.

Uma vez dentro do ônibus, não se intimide com os gritalhões e valentões que, ofendidíssimos com o motorista por ele ter parado nas estações, depois dos ônibus anteriores terem ignorado esses excelsos passageiros que nelas aguardavam, vão aos berros tirar satisfação.

O ponto final do ônibus, 40 minutos depois, é o terminal Morro Alto. Lá você verá, se procurar bem entre vários ônibus e pessoas que despertam a sua mais honesta suspeita, um veículo escuro, apagado, numerado 5882 e que abrigará em seu interior um motorista e um cobrador que descansam o sono dos justos.

Aguarde na porta por mais uns vinte minutos até que, repentinamente desperto, o motorista ligue o ônibus, abra as portas e já comece, de leve, a arrancar. Entre correndo, mas espere mais um tempo, enquanto as pessoas que têm o cartão carregado passem e peguem os melhores lugares, até que o cobrador acorde e resolva te cobrar a passagem nesse velho meio de pagamento, outrora o mais líqüído, o dinheiro.

Este último ônibus deverá levar-lhe, enfim, a Lagoa Santa.

@ 3bf0c63f:aefa459d

P2P reputation thing

Each node shares a blob of the reputations they have, which includes a confidence number. The number comes from the fact that reputations are inherited from other nodes they trust and averaged by their confidence in these. Everything is mixed for plausible deniability. By default a node only shares their stuff with people they manually add, to prevent government from crawling everybody's database. Also to each added friend nodes share a different identity/pubkey (like giving a new Bitcoin address for every transaction) (derived from hip32) (and since each identity can only be contacted by one other entity the node filters incoming connections to download their database: "this identity already been used? no, yes, used with which peer?").

Network protocol

Maybe the data uploader/offerer initiates connection to the receiver over Tor so there's only a Tor address for incoming data, never an address for a data source, i.e. everybody has an address, but only for requesting data.

How to request? Post an encrypted message in an IRC room or something similar (better if messages are stored for a while) targeted to the node/identity you want to download from, along with your Tor address. Once the node sees that it checks if you can download and contacts you.

The encrypted messages could have the target identity pubkey prefix such that the receiving node could try to decrypt only some if those with some probability of success.

Nodes can choose to share with anyone, share only with pre-approved people, share only with people who know one of their addresses/entities (works like a PIN, you give the address to someone in the street, that person can reach you, to the next person you give another address etc., you can even have a public address and share limited data with that).

Data model

Each entry in a database should be in the following format:

internal_id : real_world_identifier [, real_world_identifier...] : tag

Which means you can either associate one or multiple real world identifier with an internal id and associate the real person designated by these identifiers with a tag. the tag should be part of the standard or maybe negotiated between peers. it can be things like scammer, thief, tax collector etc., or honest, good dentist etc. defining good enough labels may be tricky.

internal_id should be created by the user who made the record about the person.

At first this is not necessary, but additional bloat can be added to the protocol if the federated automated message posting boards are working in the sense that each user can ask for more information about a given id and the author of that record can contact the person asking for information and deliver free text to them with the given information. For this to work the internal id must be a public key and the information delivered must be signed with the correspondent private key, so the receiver of the information will know it's not just some spammer inventing stuff, but actually the person who originated that record.

@ 3bf0c63f:aefa459d

Replacing the web with something saner

This is a simplification, but let's say that basically there are just 3 kinds of websites:

1. Websites with content: text, images, videos;
2. Websites that run full apps that do a ton of interactive stuff;
3. Websites with some interactive content that uses JavaScript, or "mini-apps";

In a saner world we would have 3 different ways of serving and using these. 1 would be "the web" (and it was for a while, although I'm not claiming here that the past is always better and wanting to get back to the glorious old days).

1 would stay as "the web", just static sites, styled with CSS, no JavaScript whatsoever, but designers can still thrive and make they look pretty. Or it could also be something like Gemini. Maybe the two protocols could coexist.

2 would be downloadable native apps, much easier to write and maintain for developers (considering that multi-platform and cross-compilation is easy today and getting easier), faster, more polished experience for users, more powerful, integrates better with the computer.

(Remember that since no one would be striving to make the same app run both on browsers and natively no one would have any need for Electron or other inefficient bloated solutions, just pure native UI, like the Telegram app, have you seen that? It's fast.)

But 2 is mostly for apps that people use every day, something like Google Docs, email (although email is also broken technology), Netflix, Twitter, Trello and so on, and all those hundreds of niche SaaS that people pay monthly fees to use, each tailored to a different industry (although most of functions they all implement are the same everywhere). What do we do with dynamic open websites like StackOverflow, for example, where one needs to not only read, but also search and interact in multiple ways? What about that website that asks you a bunch of questions and then discovers the name of the person you're thinking about? What about that mini-app that calculates the hash of your provided content or shrinks your video, or that one that hosts your image without asking any questions?

All these and tons of others would fall into category 3, that of instantly loaded apps that you don't have to install, and yet they run in a sandbox.

The key for making category 3 worth investing time into is coming up with some solid grounds, simple enough that anyone can implement in multiple different ways, but not giving the app too much choices.

Telegram or Discord bots are super powerful platforms that can accomodate most kinds of app in them. They can't beat a native app specifically made with one purpose, but they allow anyone to provide instantly usable apps with very low overhead, and since the experience is so simple, intuitive and fast, users tend to like it and sometimes even pay for their services. There could exist a protocol that brings apps like that to the open world of (I won't say "web") domains and the websockets protocol -- with multiple different clients, each making their own decisions on how to display the content sent by the servers that are powering these apps.

Another idea is that of Alan Kay: to design a nice little OS/virtual machine that can load these apps and run them. Kinda like browsers are today, but providing a more well-thought, native-like experience and framework, but still sandboxed. And I add: abstracting away details about design, content disposition and so on.

---

These 3 kinds of programs could coexist peacefully. 2 are just standalone programs, they can do anything and each will be its own thing. 1 and 3, however, are still similar to browsers of today in the sense that you need clients to interact with servers and show to the user what they are asking. But by simplifying everything and separating the scopes properly these clients would be easy to write, efficient, small, the environment would be open and the internet would be saved.

See also

• On the state of programs and browsers

@ 3bf0c63f:aefa459d

The monolithic approach to CouchDB views

Imagine you have an app that created one document for each day. The docs ids are easily "2015-02-05", "2015-02-06" and so on. Nothing could be more simple. Let's say each day you record "sales", "expenses" and "events", so this a document for a typical day for the retail management Couchapp for an orchid shop:

{ "_id": "2015-02-04", "sales": [{ "what": "A blue orchid", "price": 50000 }, { "what": "A red orchid", "price": 3500 }, { "what": "A yellow orchid", "price": 11500 }], "expenses": [{ "what": "A new bucket", "how much": 300 },{ "what": "The afternoon snack", "how much": "1200" }], "events": [ "Bob opened the store", "Lisa arrived", "Bob went home", "Lisa closed the store" ] }

Now when you want to know what happened in a specific day, you know where to look at.

But you don't want only that, you want profit reports, cash flows, day profitability, a complete log of the events et cetera. Then you create one view to turn this mess into something more useful:

``` function (doc) { var spldate = doc._id.split("-") var year = parseInt(spldate[0]) var month = parseInt(spldate[1]) var day = parseInt(spldate[2])

doc.sales.forEach(function (sale, i) { emit(["sale", sale.what], sale.price) emit(["cashflow", year, month, day, i], sale.price) }) doc.expenses.forEach(function (exp, i) { emit(["expense", exp.what], exp.price) emit(["cashflow", year, month, day, i], -exp.price) }) doc.events.forEach(function (ev, i) { emit(["log", year, month, day, i], ev) }) } ```

Then you add a reduce function with the value of _sum and you get a bunch of useful query endpoints. For example, you can request

/_design/orchids/_view/main?startkey=["cashflow", "2014", "12"]&endkey=["cashflow", "2014", "12", {}]

@ 3bf0c63f:aefa459d

questo.email

This was a thing done in a brief period I liked the idea of "indiewebcamp", a stupid movement of people saying everybody should have their site and post their lives in it.

From the GitHub postmortem:

questo.email was a service that integrated email addresses into the indieweb ecosystem by providing email-to-note and email-to-webmention triggers, which could be used for people to comment through webmention using their email addresses, and be replied, and also for people to send messages from their sites directly to the email addresses of people they knew; Questo also worked as an IndieAuth provider that used people's email addresses and Mozilla Persona.

It was live from December 2014 through December 2015.

Here's how the home page looked:

• https://github.com/fiatjaf/questo.email

See also

• jekmentions, another thing related to "indieweb"

@ 3bf0c63f:aefa459d

Washer

A CLI tool for generating fulltext indexes and using them to query files later based on a library called whoosh^whoosh.

I made this to help me search my git-annex files, but never really used it.

• https://github.com/fiatjaf/washer

@ 3bf0c63f:aefa459d

Setting up a handler for nostr: links on your Desktop, even if you don't use a native client

This is the most barebones possible, it will just open a web browser at https://nostr.guru/ with the contents of the nostr: link.

Create this file at ~/.local/share/applications/nostr-opener.desktop:

[Desktop Entry] Exec=/home/youruser/nostr-opener %u Name=Nostr Browser Type=Application StartupNotify=false MimeType=x-scheme-handler/nostr;

(Replace "youruser" with your username above.)

This will create a default handler for nostr: links. It will be called with the link as its first argument.

Now you can create the actual program at ~/nostr-opener. For example:

```python

!/usr/bin/env python

import sys import webbrowser

nip19 = sys.argv[1][len('nostr:'):] webbrowser.open(f'https://nostr.guru/{nip19}') ```

Remember to make it executable with chmod +x ~/nostr-opener.

@ 3bf0c63f:aefa459d

On the state of programs and browsers

Basically, there are basically (not exhaustively) 2 kinds of programs one can run in a computer nowadays:

1.1. A program that is installed, permanent, has direct access to the Operating System, can draw whatever it wants, modify files, interact with other programs and so on; 1.2. A program that is transient, fetched from someone else's server at run time, interpreted, rendered and executed by another program that bridges the access of that transient program to the OS and other things.

Meanwhile, web browsers have basically (not exhaustively) two use cases:

2.1. Display text, pictures, videos hosted on someone else's computer; 2.2. Execute incredibly complex programs that are fetched at run time, executed and so on -- you get it, it's the same 1.2.

These two use cases for browsers are at big odds with one another. While stretching itsel f to become more and more a platform for programs that can do basically anything (in the 1.1 sense) they are still restricted to being an 1.2 platform. At the same time, websites that were supposed to be on 2.1 sometimes get confused and start acting as if they were 2.2 -- and other confusing mixed up stuff.

I could go hours in philosophical inquiries on the nature of browsers, how rewriting everything in JavaScript is not healthy or where everything went wrong, but I think other people have done this already.

One thing that bothers me a lot, though, is that computers can do a lot of things, and with the internet and in the current state of the technology it's fairly easy to implement tools that would help in many aspects of human existence and provide high-quality, useful programs, with the help of a server to coordinate access, store data, authenticate users and so on many things are possible. However, due to the nature of UI in the browser, it's very hard to get any useful tool to users.

Writing a UI, even the most basic UI imaginable (some text input boxes and some buttons, or a table) can take a long time, always more than the time necessary to code the actual core features of whatever program is being developed -- and that is considering that the person capable of writing interesting programs that do the functionality in the backend are also capable of interacting with JavaScript and the giant amount of frameworks, transpilers, styling stuff, CSS, the fact that all this is built on top of HTML and so on.

This is not good.

@ 3bf0c63f:aefa459d

O voto negativo

É simples: Você pode escolher entre votar em um candidato qualquer, como todos fazemos normalmente, ou tirar um voto de um político que não quer que seja eleito de jeito nenhum. A possibilidade de votarmos negativamente duas vezes é muito interessante também.

Outro motivo para implementar essa inovação na democracia: é muito mais divertido que o voto nulo.

@ 3bf0c63f:aefa459d

fieldbook-to-sql

This used to turn books from the late multi-things-manager (or tridimensional spreadsheets provider) fieldbook.com into complete SQLite3 databases.

It was referenced in their official shutdown message and helped people move data off (it would have been better if they had open-sourced the entire site, I don't understand why they haven't).

• https://github.com/fiatjaf/fieldbook-to-sql

@ 3bf0c63f:aefa459d

doulas.club

A full catalog of all Brazilian doulas with data carefully scrapped from many websites that contained partial catalogs and some data manually included. All this packaged as a Couchapp and served directly from Cloudant.

This was done because the idea of doulas was good, but I spotted an issue: pregnant womwn should know many doulas before choosing one that would match well, therefore a full catalog with a lot of information was necessary.

This was a huge amount of work mostly wasted.

Many doulas who knew about this didn't like it and sent angry and offensive emails telling me to remove them. This was information one should know before choosing a doula.

See also

• About CouchDB

@ 3bf0c63f:aefa459d

idea: Rumple

a payments network based on trust channels

This is the description of a Lightning-like network that will work only with credit or trust-based channels and exist alongside the normal Lightning Network. I imagine some people will think this is undesirable and at the same time very easy to do (such that if it doesn't exist yet it must be because no one cares), but in fact it is a very desirable thing -- which I hope I can establish below -- and at the same time a very non-trivial problem to solve, as the history of Ryan Fugger's Ripple project and posterior copies of it show.

Read these first to get the full context:

1. Ryan Fugger's Ripple
2. Ripple and the problem of the decentralized commit
3. The Lightning Network solves the problem of the decentralized commit
4. Parallel Chains

Explanation about the name

Since we're copying the fundamental Ripple idea from Ryan Fugger and since the name "Ripple" is now associated with a scam coin called XRP, and since Ryan Fugger has changed the name of his old website "Ripplepay" to "Rumplepay", we will follow his lead here. If "Ripplepay" was the name of a centralized prototype to the open peer-to-peer network "Ripple", now that the centralized version is called "Rumplepay" the peer-to-peer version must be called "Rumple".

Now the idea

Basically we copy the Lightning Network, but without HTLCs or channels being opened and closed with funds committed to them on multisig Bitcoin transactions published to the blockchain. Instead we use pure trust relationships like the original Ripple concept.

And we use the blockchain commit method, but instead of spending an absurd amount of money to use the actual Bitcoin blockchain instead we use a parallel chain.

How exactly -- a protocol proposal attempt

It could work like this:

The parallel chain, or "Rumple Chain"

1. We define a parallel chain with a genesis block;
2. Following blocks must contain a. the ID of the previous block; b. a list of up to 32768 entries of arbitrary 32-byte values; c. an ID constituted by sha256(the previous block ID + the merkle root of all the entries)
3. To be mined, each parallel block must be included in the Bitcoin chain according as explained above.

Now that we have a structure for a simple "blockchain" that is completely useless, just blocks over blocks of meaningless values, we proceed to the next step of assigning meaning to these values.

The off-chain payments network, or "Rumple Network"

1. We create a network of nodes that can talk to each other via TCP messages (all details are the same as the Lightning Network, except where mentioned otherwise);
2. These nodes can create trust channels to each other. These channels are backed by nothing except the willingness of one peer to pay the other what is owed.
3. When Alice creates a trust channel with Bob (Alice trusts Bob), contrary to what happens in the Lightning Network, it's A that can immediately receive payments through that channel, and everything A receives will be an IOU from Bob to Alice. So Alice should never open a channel to Bob unless Alice trusts Bob. But also Alice can choose the amount of trust it has in Bob, she can, for example, open a very small channel with Bob, which means she will only lose a few satoshis if Bob decides to exit scam her. (in the original Ripple examples these channels were always depicted as friend relationships, and they can continue being that, but it's expected -- given the experience of the Lightning Network -- that the bulk of the channels will exist between users and wallet provider nodes that will act as hubs).
4. As Alice receive a payment through her channel with Bob, she becomes a creditor and Bob a debtor, i.e., the balance of the channel moves a little to her side. Now she can use these funds to make payments over that channel (or make a payment that combines funds from multiple channels using MPP).
5. If at any time Alice decides to close her channel with Bob, she can send all the funds she has standing there to somewhere else (for example, another channel she has with someone else, another wallet somewhere else, a shop that is selling some good or service, or a service that will aggregate all funds from all her channels and send a transaction to the Bitcoin chain on her behalf).
6. If at any time Bob leaves the network Alice is entitled by Bob's cryptographic signatures to knock on his door and demand payment, or go to a judge and ask him to force Bob to pay, or share the signatures and commitments online and hurt Bob's reputation with the rest of the network (but yes, none of these things is good enough and if Bob is a very dishonest person none of these things is likely to save Alice's funds).

The payment flow

1. Suppose there exists a route Alice->Bob->Carol and Alice wants to send a payment to Carol.
2. First Alice reads an invoice she received from Carol. The invoice (which can be pretty similar or maybe even the same as BOLT11) contains a payment hash h and information about how to reach Carol's node, optionally an amount. Let's say it's 100 satoshis.
3. Using the routing information she gathered, Alice builds an onion and sends it to Bob, at the same time she offers to Bob a "conditional IOU". That stands for a signed commitment that Alice will owe Bob an 100 satoshis if in the next 50 blocks of the Rumple Chain there appears a block containing the preimage p such that sha256(p) == h.
4. Bob peels the onion and discovers that he must forward that payment to Carol, so he forwards the peeled onion and offers a conditional IOU to Carol with the same h. Bob doesn't know Carol is the final recipient of the payment, it could potentially go on and on.
5. When Carol gets the conditional IOU from Bob, she makes a list of all the nodes who have announced themselves as miners (which is not something I have mentioned before, but nodes that are acting as miners will must announce themselves somehow) and are online and bidding for the next Rumple block. Each of these miners will have previously published a random 32-byte value v they they intend to include in their next block.
6. Carol sends payments through routes to all (or a big number) of these miners, but this time the conditional IOU contains two conditions (values that must appear in a block for the IOU to be valid): p such that sha256(p) == h (the same that featured in the invoice) and v (which must be unique and constant for each miner, something that is easily verifiable by Carol beforehand). Also, instead of these conditions being valid for the next 50 blocks they are valid only for the single next block.
7. Now Carol broadcasts p to the mempool and hopes one of the miners to which she sent conditional payments sees it and, allured by the possibility of cashing in Carol's payment, includes p in the next block. If that does not happen, Carol can try again in the next block.

Why bother with this at all?

1. The biggest advantage of Lightning is its openness

   It has been said multiple times that if trust is involved then we don't need Lightning, we can use Coinbase, or worse, Paypal. This is very wrong. Lightning is good specially because it serves as a bridge between Coinbase, Paypal, other custodial provider and someone running their own node. All these can transact freely across the network and pay each other without worrying about who is in which provider or setup.

   Rumple inherits that openness. In a Rumple Network anyone is free to open new trust channels and immediately route payments to anyone else.

   Also, since Rumple payments are also based on the reveal of a preimage it can do swaps with Lightning inside a payment route from day one (by which I mean one can pay from Rumple to Lightning and vice-versa).

2. Rumple fixes Lightning's fragility

   Lightning is too fragile.

   It's known that Lightning is vulnerable to multiple attacks -- like the flood-and-loot attack, for example, although not an attack that's easy to execute, it's still dangerous even if failed. Given the existence of these attacks, it's important to not ever open channels with random anonymous people. Some degree of trust must exist between peers.

   But one does not even have to consider attacks. The creation of HTLCs is a liability that every node has to do multiple times during its life. Every initiated, received or forwarded payment require adding one HTLC then removing it from the commitment transaction.

   Another issue that makes trust needed between peers is the fact that channels can be closed unilaterally. Although this is a feature, it is also a bug when considering high-fee environments. Imagine you pay $2 in fees to open a channel, your peer may close that unilaterally in the next second and then you have to pay another $15 to close the channel. The opener pays (this is also a feature that can double as a bug by itself). Even if it's not you opening the channel, a peer can open a channel with you, make a payment, then clone the channel, and now you're left with, say, an output of 800 satoshis, which is equal to zero if network fees are high.

   So you should only open channels with people you know and know aren't going to actively try to hack you and people who are not going to close channels and impose unnecessary costs on you. But even considering a fully trusted Lightning Network, even if -- to be extreme -- you only opened channels with yourself, these channels would still be fragile. If some HTLC gets stuck for any reason (peer offline or some weird small incompatibility between node softwares) and you're forced to close the channel because of that, there are the extra costs of sweeping these UTXO outputs plus the total costs of closing and reopening a channel that shouldn't have been closed in the first place. Even if HTLCs don't get stuck, a fee renegotiation event during a mempool spike may cause channels to force-close, become valueless or settle for very high closing fee.

   Some of these issues are mitigated by Eltoo, others by only having channels with people you trust. Others referenced above, plus the the griefing attack and in general the ability of anyone to spam the network for free with payments that can be pending forever or a lot of payments fail repeatedly makes it very fragile.

   Rumple solves most of these problems by not having to touch the blockchain at all. Fee negotiation makes no sense. Opening and closing channels is free. Flood-and-loot is a non-issue. The griefing attack can be still attempted as funds in trust channels must be reserved like on Lightning, but since there should be no theoretical limit to the number of prepared payments a channel can have, the griefing must rely on actual amounts being committed, which prevents large attacks from being performed easily.

3. Rumple fixes Lightning's unsolvable reputation issues

   In the Lightning Conference 2019, Rusty Russell promised there would be pre-payments on Lightning someday, since everybody was aware of potential spam issues and pre-payments would be the way to solve that. Fast-forward to November 2020 and these pre-payments have become an apparently unsolvable problem[^thread-402]: no one knows how to implement them reliably without destroying privacy completely or introducing worse problems.

   Replacing these payments with tables of reputation between peers is also an unsolved problem[^reputation-lightning], for the same reasons explained in the thread above.

4. Rumple solves the hot wallet problem

   Since you don't have to use Bitcoin keys or sign transactions with a Rumple node, only your channel trust is at risk at any time.

5. Rumple ends custodianship

   Since no one is storing other people's funds, a big hub or wallet provider can be used in multiple payment routes, but it cannot be immediately classified as a "custodian". At best, it will be a big debtor.

6. Rumple is fun

   Opening channels with strangers is boring. Opening channels with friends and people you trust even a little makes that relationship grow stronger and the trust be reinforced. (But of course, like it happens in the Lightning Network today, if Rumple is successful the bulk of trust will be from isolated users to big reliable hubs.)

Questions or potential issues

1. So many advantages, yes, but trusted? Custodial? That's easy and stupid!

   Well, an enormous part of the current Lightning Network (and also onchain Bitcoin wallets) already rests on trust, mainly trust between users and custodial wallet providers like ZEBEDEE, Alby, Wallet-of-Satoshi and others. Worse: on the current Lightning Network users not only trust, they also expose their entire transaction history to these providers[^hosted-channels].

   Besides that, as detailed in point 3 of the previous section, there are many unsolvable issues on the Lightning protocol that make each sovereign node dependent on some level of trust in its peers (and the network in general dependent on trusting that no one else will spam it to death).

   So, given the current state of the Lightning Network, to trust peers like Rumple requires is not a giant change -- but it is still a significant change: in Rumple you shouldn't open a large trust channel with someone just because it looks trustworthy, you must personally know that person and only put in what you're willing to lose. In known brands that have reputation to lose you can probably deposit more trust, same for long-term friends, and that's all. Still it is probably good enough, given the existence of MPP payments and the fact that the purpose of Rumple is to be a payments network for day-to-day purchases and not a way to buy real estate.

2. Why would anyone run a node in this parallel chain?

   I don't know. Ideally every server running a Rumple Network node will be running a Bitcoin node and a Rumple chain node. Besides using it to confirm and publish your own Rumple Network transactions it can be set to do BMM mining automatically and maybe earn some small fees comparable to running a Lightning routing node or a JoinMarket yield generator.

   Also it will probably be very lightweight, as pruning is completely free and no verification-since-the-genesis-block will take place.

3. What is the maturity of the debt that exists in the Rumple Network or its legal status?

   By default it is to be understood as being payable on demand for payments occurring inside the network (as credit can be used to forward or initiate payments by the creditor using that channel). But details of settlement outside the network or what happens if one of the peers disappears cannot be enforced or specified by the network.

   Perhaps some standard optional settlement methods (like a Bitcoin address) can be announced and negotiated upon channel creation inside the protocol, but nothing more than that.

[^thread-402]: Read at least the first 10 messages of the thread to see how naïve proposals like you and me could have thought about are brought up and then dismantled very carefully by the group of people most committed to getting Lightning to work properly. [^reputation-lightning]: See also the footnote at Ripple and the problem of the decentralized commit. [^hosted-channels]: Although that second part can be solved by hosted channels.

@ 3bf0c63f:aefa459d

Soft-forks on Bitcoin

A traditional soft-fork activation plays out like this:

1. someone makes a proposal
2. if half-dozen respected Core developers like that, they implement it and talk about it
3. everybody loves the idea
4. they ship it in Bitcoin Core
5. miners turn it onA traditional soft-fork activation plays out like this:

A traditional soft-fork failure plays out like this:

1. someone makes a proposal
2. if half-dozen respected Core developers do not care much about the idea, they don't do anything
3. people fight on Twitter about the merits of the idea forever

A sidechain activation within BIP-300 plays out like this:

1. someone writes the sidechain software
2. if a bunch of people are interested in that, they start playing with it in test mode
3. if it is really good people launch a proposal to miners
4. miners vote yes or no

@ 3bf0c63f:aefa459d

Uma boa margem

• No primeiro semestre da faculdade de Economia nós, os alunos, fomos guiados por um livro imbecil chamado "Introdução à Economia". O livro listava lá trocentas coisas que economistas supostamente faziam como parte da sua natureza de economistas. Uma delas era, lembro-me desta frase, "economistas pensam na margem".
• De início eu não entendi onde era essa margem, mas a professora passou quase uma aula inteira explicando (isto é, lendo o capítulo) que "pensar na margem" era considerar que pequenas mudanças nas condições de qualquer coisa causariam mudanças em pequenos grupos de pessoas: as pessoas que estavam na margem da mudança.
• Por exemplo, se um limão custa 5 reais e 100.000 pessoas compram limão todo dia, se aumentamos o preço para 5,05 pode ser que, sei lá, só 99.873 continuem comprando. Faz sentido, não faz? Isto era tão óbvio para mim no primeiro período de faculdade que não imaginei que alguém precisasse explicar, por isso não percebi qual era a da margem.
• Até hoje, porém, vejo pessoas o tempo todo afirmarem categoricamente que o "cinco centavos não vão fazer diferença nenhuma, as pessoas vão continuar comprando o limão como sempre compraram" e invocando em defesa desta tese argumentos perfeitamente lógicos como "até parece que você ia deixar de comprar seu limão por causa de 5 centavos", "eu nem olho o preço das coisas no supermercado" e "as pessoas precisam do limão, então elas vão ter que comprar, não importa o preço".
• Muitas destas pessoas entenderão a explicação sobre a margem, mas na próxima oportunidade que tiverem falharão em perceber a analogia ou em se lembrarem da margem e novamente evocarão os seus chavões. Para outras pessoas, porém, o pensamento na margem faz parte do bom senso habitual.
• Tirando fora a inútil conclusão de que a maior parte das pessoas é burra, sobra-nos um problema.
• Discussão
  • Estaria o autor do livro, contra sua própria vontade, enunciando uma verdade acerca dos tipos de pessoas que povoam a sociedade, "os economistas", que são economistas desde o berço, e que "pensam na margem" por natureza, contra "o resto", os não-economistas, que não pensam na margem, não importa o que se faça?
  • Esta é uma solução bem mixuruca. Nem é uma solução, na verdade, além disto ela deixa escapar um outro problema: por que diabos um sujeito que não consegue entender o problema do limão se candidata a um diploma de economista?
    • Bom, talvez aqui a hipótese da burrice generalizada explique bem as coisas: aparentemente a burrice que há nas universidades, no valor dos diplomas, na natureza da escola e em sua relação com as universidades faça com que jovens sejam despejados em qualquer curso sem terem noção nenhuma do que eles mesmos esperam que se dê lá. Ei-lo.
  • Há algum outro mistério aqui? O bom senso (enquanto um conhecimento apreendido dos meus vizinhos de sociedade) me ensinou a pensar na margem, ou não? Onde eu aprendi isso? Por que eu penso assim e o meu vizinho não?
  • Imagino que Bernard Lonergan responderia dizendo que os economistas são pessoas que tiveram esse insight e as outras pessoas não. Para as que tiveram o insight ele aparece já como uma obviedade, para os que não tiveram ele não é nem percebido como possibilidade (do contrário ele se efetuaria automaticamente como insight).
    • Neste caso, o que explica que pessoas entendam o caso do limão, caso se lhas explique com calma, mas falhem em aplicá-lo, minutos depois, a laranjas?
    • Há casos de economistas famosos e premiados que não conseguem conceber, por exemplo, que o aumento do salário mínimo possa fazer com que menos pessoas contratem funcionários -- na margem. Estes mesmos economistas passariam facilmente no teste do limão. Paul Krugman é um exemplo clássico de pessoa definitivamente "economista" (pelo critério do limão), mas que falha na aplicação do mesmo princípio a situações em que ele tem interesse político.
    • Aqui caímos num outro problema totalmente diferente, mas talvez a dissonância cognitiva explique.
    • Falha na aplicação de analogias não é um defeito, segundo me parece. Afinal de contas cada nova aplicação de uma analogia ou de relação previamente conhecida é, em si, um novo insight. O insight pode não ocorrer facilmente em certas condições. Mas, nestes casos, imagino que com algum auxílio (alguém que te lembre da analogia correta a ser aplicada ali, fazendo com que você a teste por si mesmo) o insight ocorra.
  • Também posso considerar que eu estou errado e que é ilógico pensar que cinco centavos farão com que menos pessoas comprem o limão. Há centenas de estudos "empíricos" que mostram como "pensar na margem" é correto, mas estes estudos são todos inconclusivos, ou afetados por dissonância cognitiva por parte dos autores, economistas, que já começaram a fazer o estudo sabendo da conclusão. Tudo isto parece razoável. Tenho para mim, no entando, que não é nada razoável, mas um absurdo louco.

@ 3bf0c63f:aefa459d

sitios.xyz

Based on sitio, this was supposed to be the successor of Websites For Trello.

From the old landing page:

sítios.xyz is a hosted static site generator based on sitio. It is capable of building websites by fetching content from other services and arranging them in pages. It can be used to build any sort of blog or site.

It supports fetching content from Trello, Dropbox, Evernote and arbitrary URLs. You can use just one of these providers, or mix them all in your site.

How it works

Basically, you just have to point to an URL of the site, like /posts, for example, and assign a provider to it. The trello:list provider, for example, will fetch all cards on a Trello list and create a page for each of them under /posts/:card-name and finish with an index, optionally paginated, on /posts itself.

You can repeat this process for other content from other sources, or even just point the root URL, / to some provider and be done with it.

Fast

The generated websites are super fast, as they're served as HTML files directly, no server-rendering involved. Also, due to sitio capabilities, they have instant navigation enabled by default, which uses JavaScript to fetch just the content of the pages, instead of performing a full reload.

Customization

Since the way pages are rendered -- their HTML structure -- is standardized by classless, custom theming and styling is simple to do using just CSS and JavaScript, and there are some themes available already for you to choose.

If you want custom HTML or a provider for which we don't have support yet, that's easy to add. Please let's us know using the chat below! No lock-in

The code that renders the sites is just a very minimal sitio script with the plugins you choose. These are all open-source and you can export your site and render it by yourself if you don't want to use sítios.xyz anymore.

• http://web.archive.org/web/20180416143134/https://sitios.xyz/
• https://github.com/fiatjaf/sitios.xyz

@ e1ff3bfd:341be1af

Over the last few months it feels the bitcoin community has gotten more and more jaded on lightning. To be honest, this is for good reason, back in 2017 we were promised a decentralized payment network that would always have cheap payments and everyone would be able to run their own node. Nowadays, the average lightning user actually isn't using lightning, they are just using a custodial wallet and the few of that do run lightning nodes often find it a burdensome task. For us at Mutiny Wallet, we are trying to make this better by creating a lightweight self-custodial wallet and in my opinion we have been executing on that dream fairly well. In this post, I'll analyze these issues and present a new way to view lightning and what that means for bitcoin going forward.

First and foremost one of the hardest UX challenges of lightning is channel liquidity. No other payment system has these problems today besides lightning so this often confuses lots of users. To make matters worse, there aren't any practical hacks that we can do to get around this. Muun Wallet used an on-chain wallet + submarine swaps to get around the channel liquidity problem, this worked very well until fees went up and everyone realized it wasn't actually a lightning wallet. The better solution is JIT liquidity like we do in Mutiny or splicing like that is done in Phoenix. These solutions abstract some of it away but not enough, we often get support questions confused on why some payments have fees and others do not. The fact is channel liquidity is not a usable UX for most end users.

The other major pain point of lightning is the offline receive problem. Inherently, you must be online with your private keys to sign and claim a payment. There is technically an ongoing spec proposal to be able to work around this (essentially creating a notification system of when people are online to receive payments), but it doesn't solve the fundamental problem and still has limitations. There has been a few attempts to get around this, most notably was Zeus Pay lightning addresses. These essentially worked by just creating stuck payments and waited for the user to come online to claim, this caused a ton of problems for people and even forced us at Mutiny to block users from paying them because it caused so many force closures. This is a hard problem because the entire rest of the bitcoin/crypto ecosystem works by just copy-paste an address and you can send to it whenever, there isn't caveats around asking your friend to open their wallet. This is further exacerbated by things like lightning address that requires a webserver to even get an invoice in the first place.

Channel liquidity and offline receives in my opinion are the two most obvious reasons why self-custodial lightning is not popular. When most users hear about any of these, they just think screw that and move to a custodial wallet because it is so much easier. If these were our only two problems, I think self-custodial lightning would be fine, it may never be the predominant way people use lightning, but we could get the UX good enough that we have a significant portion of people using lightning in a sovereign way. However, there are more problems under the surface.

Channel liquidity is a problem, but it is also deceptive. When you have 100k sats of inbound liquidity you would think you could receive up to 100k sats, but this isn't the case, often you can't actually receive any. This is because of on-chain fees, when a payment is being made in lightning you are creating pre-signed transactions that have outputs for every in-flight payment, these outputs cost potential on-chain fees and the high on-chain fees go the more it eats into your liquidity. After we've solved most of our force close issues Mutiny this has been number one support request. Even if you do everything right, understand liquidity and have enough for your payment, sometimes it still won't work because on-chain fees are too high. This is always really discouraging because isn't the whole point of lightning to not have to pay on-chain fees? Fundamentally, all current lightning channels could become entirely useless if on-chain fees went high enough because a single payment would require too many reserves. Obviously this is hyperbolic, but I hope I am getting the point across that on-chain fees don't just effect the opening and closing costs of channels, even if you are a diligent node runner that only opens channels when fees are low, that is not enough, your channels need to be large enough to pay for the on-chain fees of each HTLC at any future on-chain fee rate. As on-chain fees go up and up this problem will only get worse.

The proposed solution to these reserve issues are things like anchor channels, package relay, ephemeral anchors, etc. These are all well and good but kind of just mask the problem. They do solve it so the fee reserve can be much lower and possibly zero, however with the tradeoff that you need on-chain funds available to fee-bump your force closes so they can actually get into a block. This again breaks the UX for self-custodial users because they have hold on-chain funds alongside their lightning funds so they can do those on-chain fee bumps. The size requirements for their on-chain funds is still dynamically based on how high on-chain fees can spike. Solutions for this can include having someone else bump your transaction fees but this brings basically a trusted 3rd party into the mix and isn't ideal.

When you lay out all the different tradeoffs a lightning node needs to make, especially in a high fee environment, it makes me think, what are we doing here, are we going down the wrong path? Lightning is still fundamentally a fantastic payment protocol but its limitation is that it requires scale. Basically every problem I've outlined goes away when you have a large lightning node with lots of liquidity and high uptime so many we should optimize for that. The market has been telling us this for years already, +90% of lightning users are using custodial wallets because it works so much better at scale. So how can we use large scale lightning nodes without custodial wallets?

Combining existing large scale lightning infrastructure with self-custodial solutions sadly, isn't totally possible. The only real way to do that as of now is Muun Wallet which as we talked about earlier, doesn't really solve the problem because everything is just an on-chain transaction. However, Muun was onto something. The architecture of having a simpler protocol interface with lightning is genius and gives us the best of both worlds. We can make fast cheap payments and let the big boys collect fees for running the lightning node. Aqua Wallet just launched which is essentially a Muun Wallet but on top of Liquid, this is a good bandaid fix but doesn't get to the root of the problem.

Before we go further we should take a step back and break down what problems we are trying to solve. Bitcoin has a fundamental scaling limitation through the block size, if we could make infinite, then we wouldn't necessarily need any layer 2s because we could just make on-chain payments. However, we live in the real world and have a 1mb block size limit, and this limits the number of transactions we can make on-chain. Lightning is a huge improvement to bitcoin because we don't need to put every transaction on-chain, we just need to open a channel and can make seemingly countless payments. So why isn't lightning the silver bullet? Lightning lets us move payments off-chain but what it doesn't do is let us move ownership off-chain. Fundamentally lightning still relies on that, at the end of the day, a utxo goes to single user. So even if every on-chain transaction was a lightning channel, we still run into the limit of how many people can actually own those channels. What we need is another layer 2 that can scale utxo ownership and caninterop with lightning, that way we have a way to scale ownership combined with scaling payments.

So how do we scale ownership? Simply put, the answer today is custody, whether that is pure custodial like a Wallet of Satoshi or in the grey area like fedimints and liquid, the only way to do it today is through custody or federated bridges. In bitcoin, the only way to delegate ownership of a utxo to multiple parties is through multisig, however, that requires every user to be online when anyone wants to transact, and when you take go down this path far enough you end up just reinventing lightning.

Are we doomed then? Is there no way to scale bitcoin in a self-sovereign way? Luckily, the answer is no, but we need some soft-forks. Covenants are the way to scale bitcoin ownership. There are a bunch of covenant proposals but at their core what they propose to do is to add a way, so you can have a bitcoin address that limits where and how the coins in it can be spent. This can seem scary, but we already have these in bitcoin today, OP_CTLV (Check LockTime Verify), which was soft forked in 2016, only allows you to spend from a bitcoin address if the transaction has a given locktime, this lets you gate when a utxo can be spent. What the current covenant proposals do is let you gate where a utxo can be spent. With that simple primitive many different protocols can be built that allow for scaling ownership.

There are a lot of current covenant proposals, the main ones being: OP_CTV, OP_VAULT, OP_CSFS, OP_TXHASH, OP_CAT, and APO. They all have different functionality and tradeoffs but in my opinion we should be looking towards activating a form of covenants because otherwise we will likely be moving towards a future of less sovereign bitcoin users.

The future is not bleak however, even without covenants we can still scale bitcoin for the world, just not in the ideal way. At Mutiny, we are full steam ahead on implementing fedimint into the wallet, in my opinion (and the rest of the team's) it looks like the best current scaling solution for bitcoin. Fedimints give us the ability to dynamically share ownership over a group of utxos and is able to interop with lightning through gateways. It is the pinnacle of the scaling dream for bitcoin with current technology and I can't wait to help make it reality while we can.

@ 97c70a44:ad98e322

Today marks the biggest release so far in Coracle's history. There have been many good days, like when I introduced Coracle to the nostr telegram group, or when I got my fellowship with FUTO, or when I got my grant from OpenSats, or when I got to speak at Nostrasia. But in terms of realizing the vision I've had for the software - for over two years - today is the day.

Coracle now has private groups.

This means you can now send almost any nostr event over an encrypted channel to the rest of the group's members. This is substantially different from group chats, in that it uses rotating shared keys to provide weak forward secrecy, better scaling, and dynamic member access. This more closely approximates one of the most popular social media products in existence - The Nostr is now a direct competitor of The Facebook.

I built this for my community. I wanted something "good enough" to entice people to leave the advertising-fueled surveillance honeypot that is Facebook. In order to work, it needed to at least support notes, events, and marketplace listings. Although support is still quite basic, Coracle has checked all three of these boxes.

Before I get into the details though, it's important to mention that these groups should not be considered "private" any more than Facebook groups or Mastodon servers are (although privacy is substantially better). A better analog might be WeChat, which uses encryption with the same set of trade-offs. So don't post anything to private groups that might get you in trouble!

With that said, it's possible to run a highly private group. The backbone of this spec is e2e encryption, but relay selection can play an important part in hiding metadata from the rest of the network. If you have a relay you trust to protect notes and not share metadata, your security is significantly increased.

Prior art

Nostr-compatible group products aren't a totally novel thing, as it turns out. In fact draft NIP 112 has been around since June, and is already implemented in ArcadeCity. So why am I creating a new standard? I'l get into the positive benefits of my approach more below, but the quick answers are:

• The new encryption standard is going to break compatibility anyway. If we can end up with a better spec, now is the time.
• ArcadeCity development seems to have stalled.
• NIP-72 communities already have a ton of traction, and match what I'm trying to achieve with encrypted channels.

Of course I'm highly indebted to the project, the design of which is still visible in my final design.

Another product that exists to do something similar in a nostr-compatible way is Soapbox by Alex Gleason. This is a great project, particularly since his Mostr project bridges the ActivityPub world and Nostr. ActivityPub works well for highly centralized communities, but the architecture suffers from this centralization too. In particular, not even DMs are e2e encrypted, and just like regular notes are protected only by authentication enforced by servers.

Finally, there's NIP 29, which is fiatjaf's competing groups project. This has some interesting properties, for example the ability to "fork" a group by linking events together. However, similar to ActivityPub it relies exclusively on relays to protect user privacy, and in a fairly non-standard way. You do get to take advantage of nostr's multi-master architecture though, and signatures are also stripped from events in order to discourage propagation through the network.

None of these solutions quite satisfied me, so I built my own.

How it works

One of the coolest things about a NIP 72 community-based group spec is that is supports a spectrum of privacy requirements. A group admin might choose to publish group metadata privately so that it's only visible to the group, publicly so that other people can find the group and ask to join, or leave off a private component entirely.

Likewise, since private groups are backwards-compatible with public communities, it's easy to add a private component to existing groups. This can be useful especially for groups run by a business or content publisher, since public exposure is a good thing but certain group members might have more or less access. This could be used to support a patreon-type model, automating group membership based on subscription tier, for example.

An important aspect of the design that makes automation possible is the concept of a dedicated administration key. By decoupling this key from the original creator of the group, ownership can be shared as simply as sharing the key. This allows multiple admins to manage the group simultaneously either manually or using automations built into the group relays or special purpose bot-clients.

This of course raises the issue of admin access revocation, which isn't possible - that is, until we have a solution for key rotation for normal accounts. Once that's in place, the same process can be used to rotate group admin keys.

In the meantime, it's also trivial to reduce the exposure an admin key gets. You wouldn't generally want to simply paste the key wherever it's needed, but luckily that problem has already been solved as well. Instead of giving every admin or admin bot the key, it's trivial to set up an nsecbunker that authorizes each admin client - and can revoke access as needed.

This level of administration is of course fairly complex, but I think it's important to think through the requirements businesses and other advanced users will eventually impose and anticipate them as we're able, not through over-engineering, but through simple concepts that can be reused.

One other neat feature of this NIP is the definition of invite codes, which are essential for running a private group at any kind of scale. When requesting access to a group, a user can send along a "claim", which can be anything - for example a static invite code, a payment receipt, or an explanation of why they want to join. This claim can be validated by hand by a human, or processed by a bot to instantly admit the new member to the group.

When a new member is admitted to the group, the admin can either share an existing access key with them, or they can rotate the key for the entire group. If relays expire access keys after a certain amount of time, this can create a weak form of forward secrecy, where attackers won't be able to access old content, even if they gain access to the admin key.

Limitations and Future Work

The bar for new nostr clients has risen significantly since I first put Coracle out there. The new groups component is far more mature than Coracle was for much of its early life, but it has its rough edges. Many of these just need to be smoothed out through further UX work, but some are more technical in nature.

• The groups spec relies on NIP 44, which isn't yet available in most signer extensions. That means that unless you log in with your private key (please don't), you won't be able to create or gain access to any private groups.
• Hybrid groups (public groups with a private area) aren't really tested yet, or fully supported in Coracle's UI. It's an open question whether this is even a good idea, since it becomes pretty hard for users to know if they're posting publicly or privately in every context.
• Moderation is not implemented, so if you're creating a public group there is currently no way in Coracle to approve posts. Also, groups created in Coracle don't show up in Satellite for some reason — this is something I'll be working on improving.
• Whether this approach actually scales is another question. It's very hard to build member lists of hundreds of thousands of people, and without a relay helping to filter events, it might become prohibitively expensive to download and analyze all the events posted to a group. We'll see what develops as the design matures and the implementation undergoes stress testing.

Conclusion

Something I like about both nostr and bitcoin is that it empowers the users of the software. The corollary of this of course is that it's important to exercise this power with care - real damage can be done with this group spec, just as real damage can be done to bitcoin holders through low entropy key generation or poor key handling practices. So please, if you're going to implement this spec, communicate clearly with your users its limitations, and encourage them to run their own relays.

Nevertheless, I am stoked to be another 1% closer to my goal of helping my community - and anyone else who uses nostr - to exercise individual sovereignty and protect their freedom and privacy. Let's keep at it.

@ fa984bd7:58018f52

The new version of nsecBunker represents a significant increase on what is possible with regards to onboarding new users to Nostr.

With this new release, I added the possibility of running bunker in a way that allows new users to create their account remotely from any compatible client.

This new release also connects nsecBunker with LNBits, so that new users immediately get a LN wallet AND zapping capabilities!

🤯

@ d7c6d014:a6abb6b8

WASSUP, NOSTRICHES!?

というわけで、ノス民の皆様いかがお過ごしでしょうか。

Nostrは、その性質上、既存のSNSのようなEメールアドレスや電話番号などを使ったいわゆる「アカウント」的な概念が存在しておらず、SSL/TLSやビットコインなどのように公開鍵暗号方式を取っています。 そのため、秘密鍵 (nsec) さえ一つあれば、Nostrプロトコルに準じた様々な種類のクライアントにアクセスすることができます。 (例えるなら、Twitterのアカウント1個で、YouTube、Instagram、Medium、Misskey全てのサービスにアクセスできるようなイメージ)

今回はそんな多種多様なNostrのクライアントたちをジャンル別に可能な限り網羅して紹介していきたいと思います。

SNS系 (Twitterライク)

nostter

nostterは、雪猫さん制作の動作が非常に軽いTwitterライクなWebクライアントです。

kaiji君制作のUIもマットで見やすく、Web版Twitterに慣れている人でNostrの世界に初めて足を踏み入れる人におすすめのWebクライアントです。

Snort

Snortは、主に日本国外で人気なTwitterライクなWebクライアントです。

特徴的な機能としては:

バズり具合がサマリーとして可視化できたり...

開発者にzap (ビットコインの投げ銭のこと) したり...

ビットコインライトニングのウォレットと紐付けたりできます⚡️

質問系 (Quoraライク)

swarmstr

swarmstrは、Quoraライクなクライアントです。

asknostr のハッシュタグをつけると自動的にキュレーションされて表示されます。

動画配信 (YouTube, Twitchライク)

zap.stream

zap.streamは動画配信クライアントです。

チャットしたり...

zapしたり...

Stream Forwarding機能があるので、他の動画プラットフォームに同時配信もできます🙃

リンク集約 (Linktreeライク)

Nostree

Nostreeは、Linktreeの様に様々なSNSなどのリンクを集約できるツールです。

zapしたり...

リンクをシェアしたり...

Nostrに新しいリストのシェアをしたりできます🙃

また、プロフィールのみならず、好きな本のリストを作ってみたり使い方はあなた次第です🚀

エントリ / 長文記事投稿 (Medium, noteライク)

habla.news

habla.newsは、Mediumのような長文記事投稿用クライアントです。 記事をブクマ、拡散できるのはもちろんのこと、お気に入りの記事に対してzapすることができます。

YakiHonne

YakiHonneは、キュレーション型の分散型メディアプロトコルです。

Mediumのように長文投稿ができるのはもちろんのこと、記事自体をキュレーションしてまとめてpublishすることができます。

もちろんブクマや記事のシェア、ビットコインの投げ銭もできます⚡️

Bounty

nostrbounties

nostrbountiesは、タスクをこなすとビットコインで報酬がもらえるBounty型のWebクライアントです。

Wikipediaライク

wikistr

wikistr は読んで字のごとくWikipediaのようなクライアントです。

通常のWikipedia的な機能に加え、投稿したウィキ情報をフォークしてオリジナルの文章を追加したり、パロディネタにしたりして遊べるのが特徴です。

フリマ

Shopstr

shopstrは、メルカリのようなフリマクライアントです。 メルカリのようなアプリ内通貨などは使わずに、ビットコインで直接商品の売買をすることができます。 フィジカルな商品のみならず、デジタル商品のやり取りもできます。

料理レシピ共有 (クックパッドライク)

NOSTR.COOKING

NOSTR.COOKINGは、料理レシピの共有ができるクライアントです。
Nostrユーザーは世界中にたくさん存在しているため、クックパッドとは違い日本料理を含めた世界中のレシピが集まっているのが個人的には好きです。 レシピをフォークしてアレンジレシピを作ったり、マークダウンファイルをダウンロードしたり、zapできたりします。

いかがでしたでしょうか。 今回は、計9種類のトピックに分けてWebクライアントをメインに紹介してきましたが、これでもまだまだほんの一部です。

そして何より、これまで取り上げてきた機能全てがNostrの秘密鍵一つで利用できるのがNostrの素晴らしいところです。煩わしいサービスごとのアカウント登録は一切必要ありません。

次回はモバイルクライアントをメインにキュレーションして紹介しようと思います♡

今回の記事が良いな〜と思ったら是非ZAP ME⚡️⚡️⚡️

@ 84b0c46a:417782f5

2/4 初めてのポスト nostr:note1hv00jpz4n26utseh3e9zck8xcdzkt8k5kp0da75v6ck4sn3gzausc85h5z

Twitter のAPIで遊び始めた矢先にAPI規制、凍結まつりなどがあり、Twitterからの移住先を探していたときにDamusの記事を見つけてNostrを始めた。

ということでNostrで遊ぶ気持ちで始めている。

じほうちゃん作成

2/17 ボットを作ってみたい nostr:note108txn4w69u4nezn533n7lkyxc68x5lyvqceuvxrmlvjfp2j75gjsyq2x6r

nostr:note13pjshjngkurjh33h8skj3p4mp37kmt3axmq4quedccrkjpfxcq8sf7t9xz

nostr:note1ajlaqjxk027mnzhtj6f4p2cungp0lnepwywad7jrynhsnl9dndpsz7pegy

ということを教えてもらったのでじほうちゃんを作りました(Oracle Cloud登録できてません)

nostr:note1l932yh5kezjly64rfc87kmhphy7ltmxwh4cpvy6sd8kru0f3s0pstjzr4x

自然とじほうちゃんが発見されていき色んな意見をもらいました

nostr:nevent1qqs0ptx5jf0f5004nh26n6km5hmtvllhhadvkwcf8k5rj32k5q39xeql4yze6

nostr:nevent1qqstqzxund58kc6y3dxcw3nzd3pxq7vlxul56xr4m5huzeztpmz56kche2fqq

nostr:nevent1qqs0msepzv9g8jhggzu3twwsplyxa5a5agmjpezmgjufwkgctrgyelqx0sc5z

nostr:nevent1qqsqa954gkzt8agl80pcnjudcchhd532qes4dpklkaclnr0wv7sru2sn8fl40

nostr:nevent1qqsd40fs0th53pgq5hrqst86grkgrr6x6an9lm784myaup6l43w0slcq8e5n0

nostr:nevent1qqsvgelkudh2pphsnsqkdk5xa6daana8gejhp3w5uqugsf5yfm6uq8cclpg37

nostr:nevent1qqsf39w7narx4npreeh44tqmr8kgasgenx8wn9ckrtgcyktctlhzwsqyxzxkd

nostr:nevent1qqs8gvlkjmhds3cgxhnhf0kepv60xj8ssxe35yx6mh5jh5xkzhgvggcv3tgd6

nostr:nevent1qqsx934lvcw86htrvrf0va3zrgftzwdv0d8fr9sd47jwlk0l9ch065qlrzs7a

nostr:nevent1qqs085agj6ht6nyldkrffn3fk0rxnwrq5tv9tkfmtrs3jptq0qa2geswljn8k

nostr:nevent1qqs907r00k4rycr6v9yp9wgnjgxgwnqqqp8ek7l20dg7l9ccx9dxdtq2r98lx

nostr:nevent1qqsp4hmucrxtll5uyv65jse36nqfcacd2eq62agph72t5hwh06a5ztqcwqjrq

わかりません

nostr:nevent1qqs09rwseaslpxm94ud99mvlx034trajcu0he6khg5znsyk6z5k82pqprztvl

nostr:nevent1qqsqsppggh2lxn3al924dfgmev9euxla6gvgezfq3fcz3ee2k8dteeqv5nr5w

nostr:nevent1qqsvmfz7qh9e233ktk2p7h8whmgxa0r8jph5gp95hzpsd8clktrn4tcslldt4

nostr:nevent1qqst8f5t5k5hk6a8wj2k9gk8j5z9nq7ncdp587aw5hsnnpl3f9jyy8gjlpq69

ということでセカンドを作った

じほうちゃんたちのgithub

アイコン用の画像たちはここに

nostr:note146ya8pva2e8hhffz9rq8n2gzgfgm0ezt2wv95ay4nwqgsgkhpwxq7w38wk

頑張ってセカンドを作ったもののクライアントのキャッシュの問題でアイコンが変わったり変わらなかったりするしなんやかんやでじほうちゃんだけでよくないかということになり今はセカンドは動いてません

(アカウントはこちら nostr:npub16n4x0pvu38xw9ghjt3qlpm7grk5zn8cgdc6wlaravcvq0hxgaxpq7f06cx)

じほうちゃんの今の姿

nostr:note1lj539f8x6gsmppta93rmedska35a7ujfg6754wt2nv9c8ujhnw0sc5fw0s

（動作環境履歴：自分ちのUbuntuのcrontab→CloudflareでTrigger Github Acrionsで実行→Google Coud Platform→自分ちのRaspberry piでcrontab）

githubリンク

ぶるすこ潜入ミッション

3/3 Blueskyの招待コードがNostrに降ってくる中、iPhoneを持たぬものはアカウントを作ることもできませんでした。 しかし、 nostr:note1plu6maqeswegctc6ddlca72s0h9v4gtd7zu8tfpq93epx9emdpds99fddz 様々のお陰でアカウント確保に成功 nostr:nevent1qqsr8l0pjh6dmvz8374lqerk2cd7cqdllk7ss4g28khshm0vrdtv46c2dnyv3

更に救いの手が

nostr:note1ngkxmswls0qwyw4lwt6aul9vmydt257l46m573ymzuaqw0gu4n3q8pltma

nostr:note1g86p77n5f0vsq0laeh62dlks0t4yvwndwpmh7kqcm3uvxca7drqqkx6uh9

しかしこの時点での私はじゃばすくりぷとなんもわからんです。

nostr:nevent1qqsxlwfwj9ld55haq4u8u20sgzhle0shpwshzxu0aw04tl07vm76d7gfhyd52

nostr:nevent1qqsze7w2l2a5ygq283snl03kf8wp8xpurqmfke29xzzk708lcyq3sccfn0czd

nostr:nevent1qqsvj9eek9nn0yxhy2kel37rq4qz9mdalatx62nckm6sakk8nfnm29gffzdj7

nostr:nevent1qqsxghqng5wpcurztlc9evhaqhvpkjlzvmlsr30xhu9ms28geppw48sr5u3n5

nostr:nevent1qqspyqw835ky62kn80eqduxeya87l9vnv228exwm6pgdf5q9lw7498snj0t3g

nostr:nevent1qqszwxf9vlxh8l9zd2gvjqe69lnfqaqwf7mvujhvy8mnpz7yr3tm4qsjz6n05

nostr:nevent1qqszrj7v46x0006447kalfwnet22r84tuqq0ml2rcztwl4x8v8wh8wg87t9nj

nostr:nevent1qqsgfy3fwmw5f9ku2pqemau3dx3sxuq46x73tndnuq67z4f93fek4vccex559

nostr:nevent1qqs05mvxqdzvxa3hrvdzrmxzslklac26zevza5nawqeaes58lrg079skl8y45

nostr:nevent1qqsdluhre3mhchxfls65y88vvawh8tkrqkzj4w62y6gnwerpkdff3jsjdfcza

nostr:nevent1qqsqvt8qkghp4hvw36ewfau0gkvadtsrgkpuqm7a04gk9ytefc5j2us3ylkjy

nostr:nevent1qqst0aggwjk6zndk5eacpcm8demfzv0gwp4taxa2vvrle4jhfldu30qj8md26

nostr:nevent1qqsqmncren4svvkjjts47m6kgydxwdjc0w2e37grjsvspvy0nysea2cy9lt7a

nostr:nevent1qqsyueexjutkw3meh338h28l8nq9wgzrpu7nzfatas4z52ch78uck6sajycwr

nostr:nevent1qqsrzmyy8de9xjnegnzeuudy98glf865jea7w9uzldcczc3de7uvtaq0vpkcd

わいわい

nostr:nevent1qqsr6pccncwtrw60042pudhh8a4gnzk5heg3284d8d48peqmvewa8pge6sdmn

神に感謝

ぶくまでやんや

3/30 ブクマ消失 nostr:note1h0shkw8rg0vrec9gvptrhefrj82ja7n52pmvp9jgmql8f2sxmdgqfwfsj3

nostr:nevent1qqsdtfupyndt3ztdks0qjhkxtqln3384xyhttlhcpg365y5gm47tm2sqy04up

nostr:nevent1qqs27uw84s8yk40c0qrh78um5tvtwrspq23qsfem3sgsgfa8gj6llus8k4708

nostr:nevent1qqszydtymyt0dhnnlngc7hkz3l3rtsykaxfy4h6pcu874jtmzqvyk9qeq3q5v

nostr:nevent1qqsyp8mknpkmrpjfjap7taqrtseepm768gv3kffe00ya73z0k2r0waclqhwts

nostr:nevent1qqsxhqkq9fa4x98y59y2p7vhqw9dhxxtrgjq8nqxurz73s4cj7hpxpqdgp7nx

ぶくまをやんやするテスト用にローカルでリレーを建てたりもした nostr:nevent1qqsdklfx6dmaak33de3afpwdjl7uesthvjwjrnjjq7lewcjuj8aavrgmqw2j9

4/2 初めてのWebアプリ？完成？ nostr:nevent1qqswxqrncr2m7w7tmykhkvwp2dqzmr8eh0ems6nrlec72n3ju3ee5dgsn3qma (github)

ちなみに2/18からSvelteのチュートリアルやろうとしてたらしい nostr:note1z8r03k7jjanydhqrc5ysj8rtlegrav5ap5yevk7dfmzz65cx5wdq4w2e86

このあとぶくまびうあをつくりはじめ、新しいこと学ぶたびに、修正するより作り直す方が楽！ということで4,5回ゼロから作り直し

レビューもらったり nostr:note1g556ddz5h0zqmcwec4974vlmc9t72vhgrzwypslu7jy5t07cpesqxxanfc nostr:note1yt49rk4elvzlm85k8anc20hpz7hhhyjxmrk77g4ux5z0m6adamzqdnu49f nostr:note1nrc7zhx26dzepcllh4d7t73f2ypecjnd6hz7srn3dze8m03s9unsat8vxp nostr:note1zv558xku652sx26svxetal5p538val42zes4ylfg5jvw5v6k90rsjarh9m

typo 三銃士に来てもらったり nostr:note1423lveuk6sdkksv67pcfqh4p5n9z6se8lechr92kqmszzz7x3gcqvtxdn8

nostr:note1r5smuugvrv5r5kwny3n5vczcu88xzxn56wzldmgmu3uvntc7vfvsjm603w

XSSチャンスを与えてしまったり nostr:note1j9zsqv5rz6z4tghaf6vuvnngz7jq2apjkszdyj2lmcctm7lh3sfs8ajfwk

nostr:note1m4shluwuuhl2zkfqnd4xx3n2qeqtf4gd8727d7y2zz790y3wa2hscsudhh

色々教えてもらったり

nostr:note1fc7w8sc9vjgl763lml9d9hxgyhlf6v7s8nr2gsn4yntat64l5j5s2yja43

nostr:note12v2qp9fd66n37qyvgj73jww97tax89ccwezp22cv7zdarjfjlqgqyrht5u

nostr:note1955ec692wu6makszz2rjtfxlhlnap9ue7vpy3wzm3dmqwz3mqjxsugeasd

nostr:note1jvevzdv0zs8jjswsjejn236tdtk3upfax707jmaxmy7xrul453mqmmj80s

nostr:note1ma84jdpnand6km3qq5up6k4ephudzmdlaz0d80r30mpr39gk2g8qc0sjh5

nostr:note1ys0vdjweesy4d0qapved5a5st3f40066krjw62j4tpudatymg26sfpm8cq

他にもいっぱい教えてもらいました。ありがとうありがとう

無限に増えたり nostr:note1a8l5k78lay4hdewv7wtlq02kgt2x9vhnlqsyr7xppv8t5vrurufsp480m9

bookmark以外も少しずつ見たり編集したりできるようになりながら

nostr:note154gcvyfj8m3fmqrjcvs4706jtfpfa3ylquf75h4nf4e060v2yjrqkutc7h

12/7 nostr:note15u54xj8uxm09lyq9mnhdlf5t7e64l509qp6092ys66nevvhsyscq29jjjz

のすとびうあ（nostviewstr） (githubリンク )

いろんなリストを見れるツールができました。わあい！

あとびうあを作る過程でできた副産物 ( 兼SolidJSの勉強 ) も

dupstr ( github )

(すでにあるイベントを別のリレーにブロードキャストするツール)

この記事作るときもちょっと役に立った

もの画像

8/4頃？

もの₍ ･ᴗ･ ₎のイラストをかいていただいたりしたので、ロクヨウ画像(ぬるぽ・ｶﾞｯ)(nostr:npub1f6rvmwc76arl7sxx2vparlzx8cg2ajc3xpymqh7yx97znccue2hs5mkavc)、うにゅう(nostr:npub19we2h0793y4hhk500r2ndqkez0xf53rtghs3j20sjdwclh7tgz7s36kl6t)を参考にもの画像Botを作った

もの画像アカウント ( nostr:npub1lxrlhyrfdl9sjdvx9xhwhag4d6s95sz3q8z09kgzp0cz73l2ffys9p726u )

githubリンク

あとせっかくだからギャラリーも作りたくてSolidJSで作った

https://tsukemonogit.github.io/nostr-monoGazo-bot/

コントリビュート

markostrにコントリビュートした！

nostr:note1x2v4rxj2w478kjy5tut24hnurxhssjs8l37flvrn3u7m7qwzac6qeta040

njumpにもコントリビュートした！わあい

nostr:note19rxj9325xuma8r8rwyx7kmvnu0qy5zt3z8z5fuvnwydq4gnk8u2schltcq nostr:note1ugq90nufjc2w798fm37ynjegpjaptshdf534kstl87kzrrp44fsquzktq4

おわりに

わからんわからん言ってる私に手を差し伸べてくださるみなさまに感謝！

Nostrをはじめて草も増えました

nostr:note12nuus6xs558l2p3tzf4g5tpel6qyyu0jmch7yxevw8ary30u9uasksgjrj

当記事作成に当たり大変お世話になったサイト

Nosaray

Advanced Nostr Search

@ 1a35b54e:1879ce71

[3]

[4]

[5]

[6]

[7]

[8]

[9]

@ d1d17471:5b15ed44

本稿はNostr(1) Advent Calendarの17日目の記事です。

前日の記事はmattnさんの Nostrの面白さをエンジニア目線で解説してみると kotaroさんの『のすた/のすとら/のすととと』 の2本でした。第2会場の本日の記事はおだらさんの NIP-04は危ない です。

---

かすてらふぃと申します。今年2月にNostrにはじめて触れて以降、しがないソフトウェアエンジニアとして生きつつ、自分のできることをもってNostrという場に貢献してきました。思えば遠くへ来たものだということで、今回はNostrに出会ってから10ヶ月の間にやってきたことを振り返ってみようと思います。

2月~3月: はじまり

Nostrの名前をはじめて目にしたのは2022年末のことでした。Twitterが競合SNSへのリンクを禁止したというニュース。FacebookやMastodonといった錚々たる顔ぶれの中に、Nostrという何やら見慣れない名前が紛れ込んでいるのを見つけ、「なんだこれ…？」と思った記憶があります。しかしこの段階ではNostrを始めるにまでは至りませんでした。

Nostrをはじめとする分散型SNSに手を出すきっかけになったのは、2023年2月3日頃のTwitterアカウント凍結祭りでした。幸い、自分のTwitterアカウントが凍結されることはなかったものの、イーロン・マスク体制に移ってからのサービスに対する不満や、ごく個人的な「Twitterで何を言っても誰も聞く耳を持ってくれない…」という感情が手伝って、ここらで外に飛び出してみるのも悪くないと思ったのです。しかし、早速秘密鍵を作ってみるも眼前に現れるのは中国語スパムの嵐か、よくて英語のつぶやきばかり。ちょっとこれは厳しいなと感じて一旦Misskey.ioに浮気。

Misskey.ioのキラキラ感に若干飽きが来はじめた3日後の2月6日、ふと思い出してNostrのほうに目をやると、「#japanタグで日本人同士つながろう！」というムーブメントが起きていました。これをきっかけに、同じタイミングでNostrにやってきた多くの日本人の皆さんとつながることができました。そして、他愛のない発言にも反応をもらえる嬉しさや、この人たちといるとなんだか面白そうなことができそう！という不思議な予感から、SNSとしてのNostrにのめり込んでいくのでした。

最初の頃は、他の開発者の面々の興味がオリジナルクライアントの開発に向く中、なんとなくちょっと違うこと、具体的にはリレーの実装をしてみたいな、というモチベーションがあってNIPsを読んでいました。Nostrの情報を集積するScrapboxが立ち上がり、そこにNIPsの日本語訳をまとめている方がいるのを見て、せっかくなら自分も協力しようと仕事中の暇な時間まで費やして翻訳を進めてみたところ、多くの人に感謝の言葉やZapをいただきました。今日までこの場で貢献を続けてこられたのは、このときの嬉しさがあったからこそだと思っています。

そんなこんなしているうちに2月22日、初回のNostr勉強会(#0)が開催されました。コミュニティが形成されてからわずか2週間ちょっとしか経っていないにもかかわらず、たくさんの面白いアイディアが生み出されているのを目の当たりにし、こうしてはいられない、自分もなにか面白いものを作りたいという思いが高まります。このとき最初に頭に浮かんだのはフォロー整理ツールの構想でした^why-follow-list-cleaner。フォロー整理の参考情報として各フォロイーの最終投稿日時や過去数日間の投稿数を出せると面白いと思い、実装に取りかかったところ、指定したとおりにリレーからイベントが取得できないことがあるのに気づきました。取得条件に合致するイベントが多数ある場合、そのうちの一部しか返ってこないのです。実験をしたりソースコードを読んだりしながらさまざまなリレーの挙動を追ううちに、リレーに保存済みの過去のイベントを思い通りに取得するのは見た目よりもずっと大変で、これを上手く解決するライブラリがあれば自分も他の開発者もハッピーなのでは…? と思い至ります。

こうして生まれたのが、今や自分のNostrにおけるOSS活動の代表作ともなった nostr-fetch です。過去のタイムラインを遡れるWebクライアント Nosaray や、リレーに保存されている過去のイベントを余すことなく取得できるCLIツール nosdump といった自分製のアプリケーションはもちろん、全世界のNostrリレー情報を総覧できるサイトであるnostr.watchの裏側で使われていたり、こじらさんのNostrデータ分析やきりのさんが運営するリレーのデータ移行に一役買ったりと、地味ながらも着実に活躍する縁の下の力持ち的存在になりました。

その後、前回からたった2週間後の3月10日に開催されることとなった Nostr勉強会#1 で、意を決してこの成果を発表してみることに。これが人生初の技術勉強会登壇でした。スライドの準備がギリギリになったり、いざ実際に発表してみると全然時間枠に収まらず、会のスケジュールを崩壊させてしまったりと至らない点ばかりでしたが、自分が考えたこと・作ったものについて多くの人に聞いてもらう楽しさに気づくことができました。

4月~5月: 初の技術書寄稿

勉強会の後しばらくはNIPs[^nips]の翻訳に勤しんだり、訳す途中で気になったNIPsの重箱の隅をつついてみたり、nostr-fetchに機能を追加したり、ちょっとBlueskyに浮気してみたりといった日々を過ごしていました。

[^nips]: Nostr Implementation Possibilitiesの略で、簡単に言えばNostrプロトコルの仕様書の集まり。

(NIPsのコントリビュータ一覧に食い込む自分の図)

ある日、5月に開催の技術書典14でNostrの合同技術同人誌を出そう！という声が上がり、そこからあれよあれよと話が進んでいきます。数年前に技術書典に一般参加してからというもの、技術書典で何かを書き物を発表することに漠然とした憧れがあった自分は、即座に寄稿を決意しました。いわずもがな、人生初の経験です。

さて、何を書いたものか。技術書典は「新しい技術に出会えるお祭り」。こちらとしてはNostrのことを幅広い技術者に知ってもらえる絶好の機会。ならば、実際に動くモノ(bot)を作りつつNostrプロトコルの基本を押さえられる演習問題を作れば、Nostrコミュニティの開発者の裾野が広がってもっと面白い場所になっていくんじゃないか?と考えました。そうして書き上がったのが 「Hello, Nostr!」内の一記事「手を動かして学ぶ Nostrプロトコル」と演習問題 です。

(Hello, Nostr! 書影。Nostrちゃん(by 青ぎさん)かわいい!)

結局当初の目論見は外れ、むしろ「既にNostrをやっている、普段はあまりプログラムを書かない層」に届く結果となりました。しかし、これを個性豊かなbotがたくさん生まれTLが今まで以上ににぎやかになったり、これをきっかけとしてNostr上で自分の作りたいものを実現する方が出てきたりと、コミュニティに良い影響を与えることができました。

6月~7月: かすてらリレー建立

ふと疑問が浮かびます。「Raspberry Piベースの趣味で動かしているような自宅サーバでも、Nostrリレーを立ててみんなに使ってもらうことはできるだろうか?」

時を同じくしてrnostrという新しいリレー実装が発表されたので、せっかくだからと最初はその実装を動かしていました。しかし当時はリリース直後とあってなんとも挙動が怪しく、クライアントが求めていないイベントを返してみんなのタイムラインを崩壊させてしまうようなこともありました。これでは流石に迷惑なので、結局より実績のあるリレー実装strfryに移行することにしました。

ここで少し工夫して、既存の日本人向けリレーと同様にアクセス元を日本国内のみに限定したリレーに加えて、リレー管理者である私をフォローしているアカウントからの投稿のみを受け付ける「フォロワー限定リレー」を用意してみました。海外在住だったり一時的に海外に出ていたりする日本人Nostrich^nostrichの皆さんにも、ある程度スパムが排除されたタイムラインをお届けできるという、他にはない価値を生み出すことができました。

ちなみに、このとき得られた知見については11月の技術書典15で出た「Hello Nostr! Yo Bluesky! 分散SNSの最前線」内の記事「ラズパイで簡単！ 一家に一台 おうちNostrリレー」にまとめてありますので、興味のある方はぜひお読みください。

(Hello Nostr! Yo Bluesky! 書影。のすちゃん空ちゃん(by 崇徳さん)かわいい!)

8月~9月: 王道からちょっと外れたクライアント開発

この文章をここまで読んできた方は薄々感づかれているかと思いますが、自分はどうやら「王道から少し逸れたこと」をやるのに価値を感じる^off-the-rail-iowタイプの人間のようで、この時期になると開発活動の方針にもこの性向が表れてきます。

vscode-nostr-client

テキストエディタの拡張機能としてのNostrクライアントがあれば、仕事をしているふりをしながらNostrできるのでは…? という声に応えて作ってみたのが、Visual Studio Code拡張機能としてのNostrクライアント、 vscode-nostr-client です。今のところ投稿機能とステータス(後述)変更機能しかありませんが、人の目を盗んでNostrするには十分でしょう(?) これまた人生初のVSCode拡張機能開発で、刺激的な経験になりました。

nostatus

同時期に、言わずと知れたiOS向けNostrクライアントDamusの開発者であるWillさんの提案により、SlackやDiscordにあるような、自分の現在のステータス(「仕事中」「外出中」など)を設定・表示するための仕様がNIPsに盛り込まれました。普通のクライアントでは名前の下にさりげなく表示されるだけですが、ステータスだけを並べたタイムラインというのもそれはそれで面白いのではないか…? この発想から生まれたのが nostatus です。

(nostatusのロゴ。Figmaで丸と四角しか描けなかった自分に、線を曲げる方法を教えてくれたあんずさんに感謝!)

このnostatus、実は最初はWebフロントエンド技術のお試し用プロジェクトでしかなく、あまり作り込む予定はありませんでした。しかしいざリリースしてみると思いの外反響が大きく、Habla.news開発者のverbirichaさん、Amethyst開発者のVitorさん、そしてステータスの仕様考案者であるWillさんといったビッグフェイスたちからも好反応を得られ、これは真面目に作り込まねばなるまいと気持ちを新たにしたのでした。

Software Design誌への寄稿

日本のソフトウェアエンジニアであれば誰もが知っているソフトウェア技術の総合誌、Software Design。そこへの寄稿記事を執筆していたのもこの時期です。

mattnさんを中心に、Nostrをテーマとする連載の企画が立ち上がったのは3月のことでした。 興味はあったものの話題に乗り遅れ、後塵を拝する結果に… と思いきや、ある日寄稿予定だった方のひとりが執筆を辞退。もう二度とやってこないかもしれないチャンス、逃すわけにはいかない…！ との思いで代筆を名乗り出ました。こうして、初の技術同人誌への寄稿から数ヶ月でまさかの商業誌デビューが決まったのです。

担当記事のテーマは「Nostrプロトコル」。先の技術書典で執筆経験のあるテーマではありましたが、読者層の違いや文字数の制約などを意識しながらの執筆は一筋縄では行きませんでした。しかしその分、完成した本をめくって自分の書いた文章が印刷されているところを観測したときの喜びは、言葉で語り尽くせないほどのものでした。

(SD誌への寄稿の大見出しショット)

10月~12月: さらなるニッチへ、そして苦悩

この時期は技術的興味に駆られて思いついたものをどんどん作るようなことをしていましたが、一方で本当にこれは人の役に立つのだろうか…? という悩むこともしばしばありました。

hono-nostr-auth

https://github.com/jiftechnify/hono-nostr-auth

NIP-98という、NostrのしくみをHTTP認証に応用するための仕様があります。これを、Honoという最近話題のWebサーバフレームワークで1行で実装できるようにしたらCOOLなんじゃないか、と思って作ったものです。しかしそもそもNIP-98認証の使いどころが難しく、上手い応用方法が見つけられずにいます…

strfrui

https://github.com/jiftechnify/strfrui

先述のかすてらリレーでも利用しているstrfryには、リレーに入ってくるイベントひとつひとつに対し所定の条件を満たしているかをチェックし、条件を満たすイベントだけを通すevent-sifter(イベントふるい)という機能があります。この条件チェックでは好きなプログラムを実行できるため、他のリレー実装に比べて非常に柔軟なフィルタリングが可能です。この条件チェック用のプログラムをもっと手軽に実装できるようにしたらCOOLなんじゃないか、と思って作ったものです。

リリース直後は主に海外のNostrリレー運用者の皆さんから反響があり、Nostrコミュニティ上で起きたできごとを日ごと・週ごとにまとめるNostr Reportにも取り上げられました。しかし、モノの特性上どうしてもNostrをSNSとして使っている「一般の人」には響かず。このとき、自分が思っていたよりも、技術的興味を満たすことより自分の作ったものを多くの人に使ってもらえることの方に喜びを感じる人間なんだな、と気づくのでした。

しりとリレー

https://srtrelay.c-stellar.net/

直前の投稿に対してしりとりが成立していないと投稿できない特殊なリレーです。strfryのevent-sifter機能を応用してなんか面白いことがしたいという単純な動機からできあがりました。

最初のころは、終わりのないしりとりをわざわざNostr上でやる意味もなく、あまり盛り上がりませんでしたが、漢字やアルファベットなどの読みにも対応した上で他のリレーから投稿を輸入するようにしたところ、偶然繋がるしりとりを愉しむ奇妙ながらもなんだか面白い場になりました。

(しりとリレーの番人、りとりん。かわいい！ Special Thanks to たーごいるさん)

おわりに

こうして振り返ってみると、この10ヶ月間いろいろなこと、たくさんの「人生初」をやってきたものだなと思います。ここまで精力的に活動してこれたのは、間違いなくNostrコミュニティの皆さんから温かい言葉やリアクション、そしてZapのおかげです。この場をお借りして感謝いたします。心から、ありがとうございました！

来年以降Nostrというものがどう発展していくかは未知数ですが、その発展の一端を自分が担えるのであれば、それ以上に嬉しいことはありません。

---

付録: かすてらふぃによる2023年のNostrへの全貢献リスト

Nostrクライアント

| 名前 | アプリURL | リポジトリURL | 概要 | | ------------------- | ---------------------------------------------------------------------------- | -------------------------------------------------- | ------------------------------------------------------ | | Nosaray | https://nosaray.vercel.app/ | https://github.com/jiftechnify/nosaray | 過去のTLを遡れるクライアント | | nostatus | https://nostatus.vercel.app/ | https://github.com/jiftechnify/nostatus | フォローしている人のステータスを一覧できるクライアント | | vscode-nostr-client | https://marketplace.visualstudio.com/items?itemName=jiftechnify.nostr-client | https://github.com/jiftechnify/vscode-nostr-client | VSCodeから投稿できるクライアント |

Nostr関連ライブラリ/ツール

| 名前 | リポジトリURL | 概要 | | --------------- | ---------------------------------------------- | ---------------------------------------------------------------- | | nostr-fetch | https://github.com/jiftechnify/nostr-fetch | 複数のリレーから過去のイベントを簡単に取得するためのライブラリ | | nosdump | https://github.com/jiftechnify/nosdump | 複数のリレーから過去のイベントをまとめて取得するCLIツール | | hono-nostr-auth | https://github.com/jiftechnify/hono-nostr-auth | Hono用のNostr HTTP認証ミドルウェア | | strfrui | https://github.com/jiftechnify/strfrui | Go言語でstrfryのevent-sifterプラグインを書くためのフレームワーク |

Nostrリレー

| リレーURL | 概要 | | ----------------------------- | -------------------------------------------------- | | wss://nrelay.c-stellar.net | リレー管理者のフォロワーのみ書き込みできるリレー | | wss://nrelay-jp.c-stellar.net | 日本国内からのみアクセス可能なリレー | | wss://srtrelay.c-stellar.net | しりとりが成立していないと書き込めない特殊なリレー |

LT

| 会場 | 配信アーカイブURL | スライドURL | 概要 | | -------------- | ---------------------------------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------- | | Nostr勉強会 #1 | https://www.youtube.com/live/J6wgG4epGK0 | https://speakerdeck.com/jiftechnify/nostrnorirekaralou-renakusubetenoibentowoqu-tutekuruji-shu | nostr-fetchの概要 | | Nostr勉強会 #2 | https://www.youtube.com/live/j7IZeAzL67M | https://speakerdeck.com/jiftechnify/think-about-feasibility-of-scheduled-posts-on-nostr | Nostrで予約投稿を実現する方法について | | Nostr勉強会 #3 | https://www.youtube.com/live/t3VkJpr1_sA | https://speakerdeck.com/jiftechnify/cryptography-101-for-understanding-nostr | Nostrを支える暗号技術に関する解説 |

執筆活動

| 書名 | URL | 寄稿タイトル | 概要 | | ---------------------------------------- | ------------------------------------------------ | --------------------------------------------- | ---------------------------------------------------- | | Hello Nostr! 先住民が教えるNostrの歩き方 | https://nip-book.nostr-jp.org/book/1/ | 手を動かして学ぶ Nostrプロトコル | botの実装を通してNostrプロトコルを理解するハンズオン | | Hello Nostr! Yo Bluesky! 分散SNSの最前線 | https://nip-book.nostr-jp.org/book/2/ | ラズパイで簡単！ 一家に一台 おうちNostrリレー | Raspberry PiでNostrリレーを運用する方法 | | Software Design 2023年10月号 | https://gihyo.jp/magazine/SD/archive/2023/202310 | 詳説 Nostrプロトコル | NIP-01をはじめとする主要なNIPsに関する解説 |

@ 97c70a44:ad98e322

By this time, many of you may have either given up on a new standard for encrypting notes to emerge, or entirely forgotten that there was one. Well, I have good news — we've received the audit report from Cure53 on the NIP 44 encryption spec, and the results are good! This post will be a summary of the findings, and some hints on what lies ahead.

The results

The assets in scope for the audit can be found on Paul Miller's NIP 44 repository. Included is the full text of the spec, as well as implementations in Typescript, Rust, and Go.

Overall, here's what Cure53 had to say:

The Cure53 team succeeded in achieving very good coverage of the WP1-WP4 targets. All ten findings spotted by the testers were classified as general weaknesses with limited exploitation potential. In other words, no vulnerabilities were detected within the inspected components.

In other words, no vulnerabilities were found, but there are things we can do to harden the implementations. Cure53 elaborates:

The fact that Cure53 was not able to identify any exploitable vulnerabilities can be interpreted as a positive sign in regard to the security of the NIP44 specification and implementations. Nevertheless, even though the spotted problem can all be seen as general weaknesses and hardening advice, they should not be ignored. It is known that weaknesses may serve as entry points for more severe vulnerabilities in the future. Cure53 strongly recommends swift resolution of all reported flaws.

These weaknesses and recommendations each have their own code, prefixed by "NOS-01", which is our audit number. Here's a quick summary of the individual points:

• NOS-01-001 describes a weakness related to naive secp256k1 implementations, which may accept public keys with both x and y coordinates instead of just x and a sign-bit. This can result in the compromise of a sender's private key if the sender can be tricked into encrypting a message with an invalid public key. This is known as a "twist attack". Cure53 recommends some additional test vectors to make sure that uncompressed keys are not accepted.
• NOS-01-002 includes a handful of minor recommendations, including specifying the initial counter for ChaCha20, nailing down key formats, and a few other things which they go into more depth on elsewhere.
• NOS-01-003 provides some additional test vectors to prevent twist attacks and out of bound errors.
• NOS-01-004 suggests using a constant time equality function to prevent timing side-channel attacks, along with some code samples.
• NOS-01-005 identifies missing range checks in the Go implementation which should be addressed in order to avoid crashes.
• NOS-01-006 addresses the lack of provisions for forward secrecy in the NIP 44 spec. They suggest introducing sender-side forward secrecy by deriving the session key using ephemeral keys and a KDF.
• NOS-01-007 explains that using the same key for multiple purposes can lead to unexpected compromises when taken together. Best practice is to use a different key for signing and for encryption, which nostr violates. While the particular curves we use aren't vulnerable to this exploit, Cure53 recommends deriving an encryption key from a user's main key using a KDF in order to reduce the impact of a leaked encryption key.
• NOS-01-008 identifies an incorrect use of the salt parameter in calls to HKDF (an HMAC-based Key Derivation Function allows us to prove that an encrypted payload was not forged). Currently, the salt is generated randomly every time, but the security definition of HKDF specifies that it be static. This is likely not exploitable, but should be fixed. Cure53 suggests switching the nonce and salt when calling the HKDF, and deriving a static salt using something like SHA256(pubA, pubB, "nip-44-v2").
• NOS-01-009 demonstrates that the Message Authentication Code (MAC) tag is currently computed without a nonce. This doesn't compromise the encryption, and authentication is covered by event signatures as specified in NIP 01, but it does prevent the MAC from being useful on its own.
• NOS-01-010 suggests using clearer boundaries when constructing the HMAC payload.

The takeaway here is that with a few minor changes, the spec itself is sufficient to "provide a simple way for the users to communicate privately". There are, however, a number of edge cases which can compromise implementations, so for any developers out there porting the spec to new languages, be sure to take a look at Paul's test vectors.

In the end, the NIP44 specification and implementations appear to have already achieved the security goal of providing users with a way to communicate privately. Miscellaneous issues identified by Cure53 during NOS-01 correspond to further hardening of the current version and/or suggestions for future versions. Following these suggestions could provide more advanced security guarantees.

They also clarify that:

Importantly, the lack of certain security guarantees, such as forward secrecy, post-compromise security, deniability, and post-quantum, had been known to the development team prior to NOS-01.

Since this is the case, it's important that client developers be absolutely clear with their users about what NIP 44 is good for, and what it's not. This is a "simple" way to communicate privately — users with more advanced privacy requirements should use something like MLS or SimpleX.

What's next?

NIP 44 isn't quite ready for widespread use just yet, but it shouldn't take long to incorporate all the adjustments mentioned in the audit. Then there are several NIPs which rely on the encryption in NIP 04 which should eventually be migrated individually. Beyond that, a whole world of affordances for encrypted data becomes available on nostr.

First and most anticipated, we can finally deprecate NIP 04 and stop leaking DM metadata. Vitor's Sealed Gift Wraps are an excellent alternative to NIP 04 DMs, and add support for small group chats, which will be a big improvement to client UX.

Other more ambitious specifications targeting larger groups exist as well, including my Closed Communities draft spec. This NIP makes it possible to extend NIP 72 communities with a private component, which can be useful for publishers or real-life communities.

There are lots of other things NIP 44 might be used for as well, for example:

• The ability to share your location only with certain people
• Private calendar events, product listings, or streams
• Private tags — instead of encrypting an entire event, it should be possible to encrypt only a single tag's value. This allows senders to attach private data to public events.

Conclusion

There's lots of work still to be done, but I think this marks a huge milestone for nostr. So thank you to Paul Miller for his work on the spec and the audit, and to OpenSats for funding the audit!

@ 26bb2ebe:70530958

この記事はNostr (2) Advent Calendar 2023 13日目の記事です。

概要

ノーコードツールのn8nでNostrのボットを作ることができるノード（ノーコードツールの部品のようなもの）を作ったので使い方を解説します。

n8n-nodes-nostrobots

• MIT Licenseで公開しています
• はじめて作って公開したのは半年以上前です

https://github.com/ocknamo/n8n-nodes-nostrobots

n8nとは

ノーコードツールです。ノーコードツールといえば有名どころにZapierやIFTTTなどがありますがそういう感じのワークフロー自動化ツールです。

公式の説明を引用します。

n8n - ワークフロー自動化ツール n8n は、拡張可能なワークフロー自動化ツールです。 フェアコード配布モデルにより、n8n は常にソース コードが表示され、セルフホストで利用でき、独自のカスタム関数、ロジック、アプリを追加できます。 n8n のノードベースのアプローチにより、汎用性が高く、あらゆるものをあらゆるものに接続できます。 (機械翻訳)

https://github.com/n8n-io/n8n

n8nで組み合わせて使用できるワークフローの部品を"ノード"と呼びます。

コミュニティノードとは

だれでも自由に作成できてみんなに共有できるノードです。Node.jsで作成することができます。

作成方法はこちら。 - https://docs.n8n.io/integrations/creating-nodes/

雛形やチュートリアルがあるのでそこまで難しくありません。今回は作成方法などは紹介しません。

n8nの準備

n8nはコードが公開されておりセルフホストも可能です。

利用する簡単な方法としてはお金を払うか、セルフホストする方法があります。

お金を払う

月20ユーロでプラットフォームを使用できまるようです。

https://n8n.io/pricing/

セルフホスト

DockerもしくはNode.jsを扱えるエンジニアであれば簡単にセルフホストできます。

https://docs.n8n.io/hosting/

またUmbrelを運用している人であればアプリがストアにあるのでワンクリックでインストールできます。

https://apps.umbrel.com/app/n8n

コミュニティノードのインストール方法

コミュニティノードの利用はリスクもあるため必ず公式のドキュメントを読んでから自己責任でインストールしてください。

https://docs.n8n.io/integrations/community-nodes/

ここではn8n-nostrobotsのインストール方法だけ解説します。

サイドメニューのSettingsからCommunity nodesをページに移動し、インストールします

npm Package Nameにn8n-nodes-nostrobotsと入力してインストールを実行します

しばらく待つとCommunity nodes一覧に追加されるのでこれでインストール完了です。

RSS Feed ボットの作成

簡単なチュートリアルとしてRSS Feed ボットを作成してみましょう。

準備

先程説明した方法でn8n-nodes-rss-feed-triggerというコミュニティノードをインストールしてください。

https://github.com/joffcom/n8n-nodes-rss-feed-trigger

（一応実装を見たかったので私はコードもかるく確認していますが自己責任でお願いします）

ワークフロー作成

Workflows画面のAdd Workflowからワークフローを追加できます。

トリガーノードの作成

はじめにトリガーとなるノードを設定します。（n8n-nostrobotsにはまだトリガーノードは実装されていません） "+"をクリックして追加メニューを開きます。

トリガーノードとしてn8n-nodes-rss-feed-triggerを使用したいので"rss"と入力するとRSS Feed Triggerが選択肢に現れるので選択してください。

とりあえずPollタイムをデフォルト値のままにしておきます。

FeedURLはLorem RSSがテストとして使用できます。

Feed URLに以下のURLを設定してください。 - https://lorem-rss.herokuapp.com/feed?unit=second&interval=30（30秒間隔でテスト用のFeedを取得できる設定）

設定できたらFetch test Eventボタンでテスト実行を行います。

画像のようにテスト用のRSS Feedのデータが取得できます。

クレデンシャルの作成

サイドメニューからCredentialsを選択します。'Add Credential' ボタンで作成モーダルを開きます。 フォームに"nostr"と入力すると"Nostrobots API"がサジェストされるので選択してください。ちなみに表示されない場合はコミュニティノードのインストールが完了していない可能性があります。

クレデンシャルの作成画面が開くのでSecretKeyを入力してください。HEXでもbech32(nsecで始まる形式)どちらでも大丈夫です。

ワークフローの作成途中は使い捨て可能なテストアカウントを作成して使用することをおすすめします。

Nostrへの投稿の実行

RssFeedTriggerノードの右側に出ている"+"をクリックして後に続くノードを追加します。

nostrで検索するとNostr ReadとNostr Writeの2つのノードが表示されるのでNostr Writeを選んでください。

選択肢が表示されたら（どれでもいいですが）Basic Noteactionsを選ぶとノードが追加されます。

ノードの設定画面が開くので以下のように値を設定します。'Credential to connect with'には先程自分が作成したクレデンシャルを設定します。

設定値は以下です。 - Resource: BasicNote - Operation: Send - Content: Hello nostr - Custom Relay: wss://nostr.mom

Custom Relayはテスト用に一つだけに設定しました。デフォルトに戻したい場合、項目のメニューからReset Valueを実行してください。

設定が完了したらExecute nodeボタンをクリックしてノードを実行します。

実行が完了するとOUTPUTに実行結果が表示されます。

content:Hello nostrを含むイベントが作成されており、sendResultが0:[accepted]: wss://nostr.momになっていれば成功です。

他のクライアントからも確認できます。（Custom Relayに設定したリレーをクライアントに設定する必要があります）

RSSとの接続

INPUTにRSS Feed Triggerの結果がSchema形式で表示されていると思います。A contenという項目をドラッグしてNostr Writeの'Content'のフォームドロップしてください。

これだけで実行済みのノードの結果のデータをコンテントに埋め込んで渡すことができます。

この状態でテスト実行して確かめてみましょう。

RSS Feedの内容を投稿できました。

有効化

あと有効化して実行するだけです。

右上の赤いSaveボタンをクリックして保存したら、その左のInactiveと書かれたトグルボタンを有効化してください。確認モーダルが表示されるので確認してGot itを選択します。

以上で完了です。

クライアントから投稿ができているか見てみましょう。

1分ごとに投稿ができており、一度に2投稿できているので成功です！

お疲れ様でした。これでRSS Feedボットの作成完了です。

機能の解説

以下は細かい機能解説になります。ドキュメント用に書いたものなので、興味がなければ読みとばしていただいで必要なときに参照してください。

Nostr Read

'Strategy'

• type: セレクトボックス

リレーからイベントを取得する方法を指定します。以下の２つのオプションを選ぶことができます。 リレーに送るフィルタとしてなにを設定するかを選んでいるだけです。

• UserPublickey
• EventId

UserPublickey

対象のユーザを示す公開鍵文字列を指定できます。HEXでもbech32(npub)方式でもどちらでも指定できます。

EventId

対象のイベントのeventIdです。eventIdにリレーの情報が含まれる場合、指定したリレーに加えてそのリレーにも取得リクエストを送ります。

HEXでもbech32(nevent)方式でもどちらでも指定できます。

期間の範囲指定

イベントの取得対象期間を指定します。StrategyがUserPublickeyの場合のみ指定できます。 以下のオプションを指定できます。

• 'Relative'
• 'From'
• 'Unit'
• 'Since'
• 'Until'

'Relative'

• type: トグルスイッチ

期間の指定方法です。Relativeがオンの場合は過去に遡っていつから取得するかを相対的に指定することができます。（もちろん現在まで取得します）

'From'

• type: 数字

現在から遡っていつから取得範囲にするかを指定することができます。Relativeが有効な場合のみ指定できます。

'Unit'

• type: セレクトボックス

単位を選択肢から選ぶことができます。Relativeが有効な場合のみ指定できます。

• 'Day'
• 'Hour'
• 'Minute'

NOTE: 例えばFromを"1"に設定してUnitを"day"に設定した場合取得範囲は、”1日前からノードの実行時刻”までのイベントが対象になります。

'Since', 'Until'

• type: 日時

Relativeを無効にした場合期間範囲指定は'Since', 'Until'を使用します。 その名の通り'Since'の日時から'Until'日時までの期間指定でイベントを取得することができます。

'Custom Relay'

• type: テキスト

問い合わせ先のリレーを指定します。リレーのURLを入力してください。複数を指定する場合はカンマ(,)でつなげて書いてください。 デフォルト値としてリレーを8件設定しているため、ここは修正しないでそのまま使用してもらって構いません。ただし、当たり前ですがデフォルトリレーが正常に動いていることは保証できません。

• デフォルトリレー

wss://relay.damus.io,wss://relay-jp.nostr.wirednet.jp,wss://nostr-relay.nokotaro.com,wss://nostr.fediverse.jp,wss://nostr.holybea.com,wss://nos.lol,wss://relay.snort.social,wss://nostr.mom

'Error With Empty Result'

• type: トグルスイッチ

有効にした場合取得イベントが存在しない場合はエラーになってワークフローを停止することができます。無効の場合はイベントがなくても、エラーにはならず空配列を次のノードに実行結果として送ります。

Sample

jackの直近１時間のイベントを取得してみた実行結果です。３件のイベントを配列で取得できました。

• 設定値
  • Strategy: 'UserPublickey'
  • Pubkey: 'npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m'
  • Relative: True
  • From: 1
  • Unit: Hour
  • Custom Relay: <デフォルト>
  • Error With Empty Result: False

[ { "id": "6c1428c9afdd315f07a9b6e22118ce45c31b2a8de12ef694121ae1cfd06ee2df", "kind": 1, "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2", "created_at": 1702389559, "content": "Only for you. Of course", "tags": [ [ "e", "4e222fdb7edb65172f85f262eff95a53132bcac6ccd2842b23c79f8bc0872e15" ], [ "e", "9295e82f3b802728dc18ef888bad81b3110711679982dc94e719f5a20e7e2528" ], [ "p", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411" ] ], "sig": "ad3b4873c8c4103555f5bdec4ad39cc0b029f000d88e67964a72e41359981440b776aea6e3758257346ae8c5efde6efe8cda2490abdfc3d0b02f675f06c9bada" }, { "content": "สวัสดีชาว bitcoiners ชาวไทย", "created_at": 1702388695, "id": "309dea1a6e298fe3b591e8c4f87736528ee867a94ffa820b3225aa9169c6a009", "kind": 1, "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2", "sig": "e113577b3281eb6637abf5ee60aef6b7a0dd700bf6254196e862fee96d4806eefa80c37292919f4e38dedbdc2f1d2a16d58c4d3c1a7d1dab40514868f48d3277", "tags": [ [ "e", "4e222fdb7edb65172f85f262eff95a53132bcac6ccd2842b23c79f8bc0872e15", "", "reply" ], [ "p", "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2" ] ] }, { "id": "4e222fdb7edb65172f85f262eff95a53132bcac6ccd2842b23c79f8bc0872e15", "kind": 1, "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2", "created_at": 1702388333, "content": "nostr:naddr1qq9rzdesxgensvpnxuusygxv5lh4g8dcx6y5z0vht38k5d0ya3eezk39jmrhqsfdj2rwwv33wcpsgqqqwens60xga9", "tags": [], "sig": "7f5d80867650d5fa2a7da55d20fd604423a785e028595d0c9fb56b80a2be0d555997e06e4f3a2d9930c183122fafa51bd8035e8eb9fe83d3cc47b13e040b29d8" } ]

Nostr Write

Nostrのリレーにイベントの書き込みを行うノードです。 このノードを使用する前に書き込みを行いたいアカウントの秘密鍵をn8nにクレデンシャル情報として登録する必要があります。

'Credential to connect with'

• type: セレクトボックス

作成したクレデンシャル情報を選択して投稿するアカウントを決めます。クレデンシャルを複数作成すると複数のアカウントが選択肢に追加されます。 ワークフローの作成途中は使い捨て可能なテストアカウントを作成して使用することをおすすめします。

'Resource'

• type: セレクトボックス

どのような方法でイベントを作成するか選択することができます。以下の３つのオプションがあります。

• 'BasicNote'
• 'Event(advanced)'
• 'Raw Json Event(advanced)'

'BasicNote'

一番単純なノートイベント(kind1)です。SNS用のクライアントで見ることができるイベントです。'Content'に本文を設定すれば使用できるため使い方も一番簡単で、おそらくNostrプロトコルをあまり理解していなくても利用可能です。

'Event(advanced)'

BasicNoteと異なりkindやtagsを設定することができます。利用するには少なくともNIP-01を理解する必要があると思われます。

BasicNoteから追加になるメニュー項目がかなりたくさんあります。以下に箇条書します。

• Kind
• Tags
• ShowOtherOption
  • EventId
  • Pubkey
  • Sig
  • CreatedAt

ShowOtherOptionを有効にするとEventId以下のメニューを表示できます。これらを使う機会はかなり限られるためデフォルトで非表示にしています。

注意点としてShowOtherOptionが有効な場合Sig(署名)が必須となるため'Credential to connect with'で選択したアカウントでは署名を行いません。自力で署名する必要があります。

Kind

• type: 数字

イベントのkindナンバーを設定できます。 詳しくはNIPを確認してください。 - Event Kinds https://github.com/nostr-protocol/nips#event-kinds'

Tags

• type: json

イベントに追加するタグを設定できます。jsonを入力する必要があります。jsonでパースできない場合やタグの配列形式ではない場合、実行時エラーとなることに注意してください。設定時にはバリデーションされません。

タグの指定方法はクライアントでまちまちだったりして結構難しいです。これも基本的にNIPを確認してください。 - Tags https://github.com/nostr-protocol/nips#standardized-tags

FYI. メンションを行う場合のタグのサンプル

[["e","dad5a4164747e4d88a45635c27a8b4ef632ebdb78dcd6ef3d12202edcabe1592","","root"], ["e","dad5a4164747e4d88a45635c27a8b4ef632ebdb78dcd6ef3d12202edcabe1592","","reply"], ["p","26bb2ebed6c552d670c804b0d655267b3c662b21e026d6e48ac93a6070530958"], ["p","26bb2ebed6c552d670c804b0d655267b3c662b21e026d6e48ac93a6070530958"]]

otherOption

これは細かく説明する必要もないかと思います。名前の通りの項目です。

• EventId
  • type: テキスト
• Pubkey
  • type: テキスト
• Sig
• type: テキスト
• CreatedAt
• type: 数字
  • unixtimeです

'Raw Json Event(advanced)'

生のjsonをそのまま設定できるオプションです。使い方は限られますが、Nostr Readで取得したイベントをそのままパブリッシュしたい場合などが考えられます。

json

• type: テキスト

'Raw Json Event(advanced)'の場合のみ表示されます。jsonには完全な署名済みイベントのjsonを入力してください。したがって'Credential to connect with'で選択したアカウントで署名しません。

'Content'

• type: テキスト

イベントの本文です。Resourceの選択肢で'BasicNote'か'Event(advanced)'を選択した場合に利用できます。

'Operation'

• type: セレクトボックス

実行するオペレーションを選択します。いまは作成したイベントをリレーにパブリッシュするSendしかありません。

Custom Relay

• type: テキスト

イベントを送信するリレーを指定します。スキーマやデフォルトリレーはNostr Readと同じです。

実行時の挙動について

• イベント投稿時のタイムアウトは10秒です。そのためノードの実行に10秒以上かかる場合があります。
• 投稿が正常に完了すると結果をノードが出力します。
  • [<statu:s>]: <Relay URL>
  • 例（成功）: [accepted]: wss://nos.lol
  • 例（失敗）: [failed]: wss://nos.lol
  • 例（タイムアウト）: [timeout]: wss://nos.lol

まとめ

網羅的にn8n-nostrobotsの利用方法について書きました。チュートリアルもやってみていただけると嬉しいです。

個人的にNostr関係では一番ドッグフーディングしているプロジェクトなので、欲しい機能があればこれからもちょくちょくアップデートを続けようと思います。おかしなところがあったらissueで報告していただけると助かります。

https://github.com/ocknamo/n8n-nodes-nostrobots/issues

他の人みたいに英語化もして書こうと思いましたが時間がないので諦めました。正月の宿題にします。

さてあしたのアドベントカレンダーは

• sinnchan: Nostrとの出会いから、SNS放浪生活？になった１年について https://adventar.org/calendars/8880
• hikari.huang: 新時代のSNS Nostrで小泉進次郎botを作った話 https://adventar.org/calendars/8794

の2本立てです。楽しみですね。

@ 8c592393:5c132608

日本語の記事は後ろにあります。

The article in Japanese follows after in English.

Introduction to rx-nostr (without RxJS)

This article is for Day 11 of Nostr Advent Calendar 2023 (Venue 1, Venue 2). Yesterday's articles were "Math for Schnorr signature - elliptic curve" by Jun-san and "Review of Gijutsu Shoten 15 from the perspective of a sales" by Rira-san.

---

Hello, Nostr. I'm poman (ぽーまん).

Recently, new major version of my library "rx-nostr" was released. Since this is a good opportunity, I'd like to talk about what rx-nostr is or is not. I hope that this entry let you use my library.

rx-nostr is a library for Nostr client to communicate with relays. In other words, what rx-nostr essentially does is just following:

• It takes filters, then send them to relays, and return EVENT message subscription.
• It takes events, then send them to relays, and return OK message subscrition.

rx-nostr doesn't care about kind of events. It doesn't wrap the content of events, just provide messages as-is to users.

It doesn't provide fetch()-like Promise-based handy API. rx-nostr handles communication between client and relays as Observable, not Promise. (If you are familiar with RxJS, you can handle Observable at will. This is a part of the value of the library, but this article talks about the other part.)

Would a library that could do only this be considered useless? The value of rx-nostr lies in the "carefulness" with which these communications are conducted.

"Carefully" communications with relays

The most part of specification about communication on Nostr is in NIP-01. The specification is very simple as summarized into the two sentences:

• Clients packs what it wants to send into an EVENT, and then sends it.
• Clients packs what it wants to receive into an REQ, and then sends it.

It is very easy to naively implement the process based on the few rules. This is a short example of REQ:

```js const ws = new WebSocket("wss://example.com");

ws.onopen = () => { ws.send(JSON.stringify(["REQ", { kinds: [1] }])); }; ws.onmessage = (ev) => { console.log(JSON.parse(ev.data)); }; ```

So, is it easy to implement this carefully? No. There are many trivial (but taking time and effort) points in real applications. Does your application do the followings?

• Does it verify the signatures?
• Does it ensure that REQ'd events really match the filters' condition?
• Does it ignore expired events based on NIP-40?
• Assume there is a REQ that is listening a timeline. When an end-user adds/removes relay config, does your application reflect it to the timeline immediately?
• Relays have max_subscriptions. When it tries to make REQ subscription more than this, does it queue them?
• Even if each relay has different max_subscriptions?
• In addition to relays configured by end-user, your application may access temporary relays, for example to fetch nevent1. In that case...
• Does it keep only one WebSocket connection even if the temporary relays overlap with the default relays? (NIP-01 says that clients should do so.)
• When communication on the temporary relays is finished, does your application closes the WebSocket connection?
• Does it try to reconnect?
• As RFC says, does it use some form of backoff when trying to reconnect?
• As NIP-01 says, does it stop reconnection if the close code is 4000.
• After reconnection, does it send EVENT that was about to be issued during the reconnection attempt?
• After reconnection, does it (re)construct REQ that was ongoing before reconnection or was about to be issued during the reconnection attempt?
  • If does so, is since/until of reconstructed REQ based on relative time of origin at reconnection?
• Does it monitor the status of connections?

rx-nostr does all of those automatically!

"Carefully" communications by rx-nostr

All you need to know to use rx-nostr is about Backward and Forward. (Being familiar with RxJS helps you use rx-nostr more useful, but it is not required.) These are rx-nostr's unique but not hard concept. Backward is to CLOSE on receiving EOSE, and Forward is not to CLOSE and to keep REQ permanently. That is all. These distinctions allow rx-nostr to optimize communication.

The example of naive REQ implementation described above is Forward. Let's implement the same with rx-nostr. First of all, we create a RxNostr instance, which manages connections and communications with relays:

js const rxNostr = createRxNostr(); rxNostr.setDefaultRelays(["wss://example.com"]);

Next, we create a Forward RxReq, connect it to RxNostr, and define a listener:

```js const rxReq = createRxForwardReq();

rxNostr .use(rxReq) .subscribe((packet) => { console.log(packet.message); }); ```

Finally, we issue REQ through RxReq:

js rxReq.emit({ kinds: [1] });

emit() can be called any number of times. Forward RxReq overwrites previous REQ, and Backward RxReq keeps all old REQs and add new one.

The complete code is now as follows:

```js import { createRxForwardReq, createRxNostr } from "rx-nostr";

const rxNostr = createRxNostr(); rxNostr.setDefaultRelays(["wss://example.com"]);

const rxReq = createRxForwardReq();

rxNostr .use(rxReq) .subscribe((packet) => { console.log(packet.message); });

rxReq.emit({ kinds: [1] }); ```

Now we resolve all trivial points described above. For instance, when end-user changes default relay configuration, we do:

js rxNostr.setDefaultRelays(["wss://example.com", "wss://second.example.com"]);

It will update the ongoing { kinds: [1] } subscription, and we will get events on wss://second.example.com.

We can use use()'s option for temporary relays. Use Backward RxReq to get some events from temporary relay as following:

```js const rxReq = createRxBackwardReq();

rxNostr .use(rxReq, { relays: "wss://temp.example.com" }) .subscribe((packet) => { console.log(packet.message); });

rxReq.emit({ ids: [EVENT_ID] }); ```

It will get EVENT_ID event from wss://temp.example.com and close the WebSocket connection automatically. (I know that relays option should be available in emit(). Please wait for future updates.)

In truth, you can do much more. For more detailed usage, plese see the official documentation... ah sorry, documentation for v2.x is not yet.

Summary

I explained what rx-nostr can do without assuming knowledge of RxJS. If I have a chance, I would like to write about what can be achieved by combining it with RxJS.

Tomorrow's article is by クリプト彼氏@仮想通貨擬人化-san and Lokuyow-san! Foo!

(The following is a Japanese article of the same.)

RxJS を学ばずに使う rx-nostr

この記事は Nostr Advent Calendar 2023 (第一会場, 第二会場) の第一会場 11 日目の記事です。昨日 10 日目の記事は Jun さんの『Schnorr 署名に使われる数学 - 楕円曲線』と りらさんの『営業目線で振り返る技術書典15』でした。

---

はろー Nostr、ぽーまんです

先日、拙作ライブラリ rx-nostr の 2.0.0 がリリースされました。いい機会なので、rx-nostr とは何であるのか、あるいは何ではないのかという話をしようと思います。あわよくばこれを読んだ皆様に使って頂こうという魂胆でございます。

rx-nostr はクライアントがリレー群と通信するためのライブラリです。言い換えると、rx-nostr が本質的に行うことはたったこれだけです:

• フィルターを受け取ると、それをリレーに送信し、EVENT の購読を返します。
• イベントを受け取ると、それをリレーに送信し、OK の購読を返します。

実際に送受信されている情報の種類 (kind) には頓着しません。つまり rx-nostr は受信したコンテンツを何かでラップすることはなく、送られてきたものをただただそのままユーザに提示するだけです。

fetch() のような Promise ベースの手軽な API の提供もしません。rx-nostr は通信をあるがままに扱うので、返されるものは扱いやすい Promise ではなく Observable です。(RxJS と連携すれば Observable も自由自在に取り回せるようになります。これが rx-nostr が提供する価値のうちの半分ですが、この記事で主張したいのはもう半分の方です。)

たったこれだけのライブラリは無用なものだと思われるでしょうか？ rx-nostr の価値はこれらの通信が「丁寧に」行われることにこそあります。

リレーと「丁寧」に通信する

リレーとの通信にかかる仕様はそのほとんどすべてが NIP-01 に記述されています。その仕様はいたってシンプルで、要旨は次の 2 点に集約されると言ってもいいでしょう:

• クライアントは情報を送信したければ、送信したいものに EVENT と書いてリレーに送信せよ。
• クライアントは情報を受信したければ、受信したいものに REQ と書いてリレーに送信せよ。

このわずかな規約に基づく送受信処理を素朴に実装するのは実に簡単です。受信処理に限って例を挙げると、次のようにたった数行で書くことができます。

```js const ws = new WebSocket("wss://example.com");

ws.onopen = () => { ws.send(JSON.stringify(["REQ", { kinds: [1] }])); }; ws.onmessage = (ev) => { console.log(JSON.parse(ev.data)); }; ```

ではこの送受信処理を丁寧に実装するのは簡単でしょうか？答えは No です。現実のアプリケーションには考慮しなければならない些事 (ただし大変に面倒くさい些事) が実に多くつきまといます。例えばあなたのアプリケーションは……

• 署名の検証はしていますか？
• REQ の結果リレーから返されたイベントが本当にフィルターの条件に合致するか確認していますか？
• NIP-40 に基づいて期限切れのイベントは無視していますか？
• タイムラインを取得している REQ があったとして、エンドユーザが途中でリレーを追加・削除したとき、タイムラインはそれを即座に反映できますか？
• リレーには max_subscriptions が定められています。これを超える量の REQ を発行しようとするとき、キューイングはされますか？
• リレーごとに max_subscriptions の値が異なるとしても、それは動作しますか？
• エンドユーザがクライアントに設定しているデフォルトのリレーに加えて、一時的なリレーにアクセスする必要に迫られることがあります (nevent1 を取得するときなど)。
• 一時的なリレーがデフォルトのリレーと重複するとしても WebSocket 接続は 1 つに抑えられていますか？ (NIP-01 はすべての通信を単一の WebSocket 接続の上で行うよう定めています。)
• 一時的なリレーとの通信が終了したとき、WebSocket を切断していますか？
• WebSocket が瞬断したとき、再接続していますか？
• 再接続は RFC が定めるように バックオフ戦略を採用していますか？
• NIP-01 が定めるように、コード 4000 で終了した場合には再接続を行わないよう実装していますか？
• 再接続試行中に送信されようとしていた EVENT を再接続成功時に送信していますか？
• 再接続前に発行されていた、あるいは再接続試行中に発行しようとしていた REQ を再接続成功時に復元していますか？
  • 復元していたとして、復元後の REQ の since/until は再接続時起点の相対時刻に基づくことができますか？
• 各リレーとの WebSocket の接続状況をモニタリングしていますか？

rx-nostr はこれらのすべてを肩代わりします！

rx-nostr で「丁寧に」通信する

rx-nostr を使う際に覚えておかなければならないのは Backward と Forward の概念だけです (RxJS についても詳しい方が便利ではありますが、必須ではないです)。これは rx-nostr 独自の概念ですがさほど難しくはありません。EOSE を受信したときに自動で CLOSE するべき REQ のことを Backward、EOSE を無視して永続する REQ のことを Forward と呼んでいるだけです。これらの使い分けは rx-nostr が通信を最適化するために利用されます。

先程の素朴な REQ の実装は Forward です。これと同じコードを rx-nostr で書いてみましょう。まずは RxNostr インスタンスを用意します。これはリレーとの通信を管理してくれるオブジェクトです。

js const rxNostr = createRxNostr(); rxNostr.setDefaultRelays(["wss://example.com"]);

次に Forward な RxReq を用意して RxNostr につなげると同時に、メッセージがやってきたときに何をするのかを定義します。

```js const rxReq = createRxForwardReq();

rxNostr .use(rxReq) .subscribe((packet) => { console.log(packet.message); }); ```

最後に RxReq を通じて REQ を発行します。

js rxReq.emit({ kinds: [1] });

emit() は何回でも呼び出すことができます。Forward な RxReq では以前に emit() した REQ を上書きしますが、Backward な RxReq では前回までの REQ を保ったまま新しい REQ を加えます。

完全なコードは次の通りになりました:

```js import { createRxForwardReq, createRxNostr } from "rx-nostr";

const rxNostr = createRxNostr(); rxNostr.setDefaultRelays(["wss://example.com"]);

const rxReq = createRxForwardReq();

rxNostr .use(rxReq) .subscribe((packet) => { console.log(packet.message); });

rxReq.emit({ kinds: [1] }); ```

これだけで前節であげた「些事」はすべて解決されています。例えば、エンドユーザがデフォルトのリレーを追加した場合には次のようにします:

js rxNostr.setDefaultRelays(["wss://example.com", "wss://second.example.com"]);

すると既に発行されて継続中の { kinds: [1] } は wss://second.example.com の上でも購読されるようになります。

一時的なリレーを使いたい場合は use() のオプションが利用できます。例えば、ある event を特定のリレーから取得したくなった場合、Backward な RxReq とともに次のように書きます:

```js const rxReq = createRxBackwardReq();

rxNostr .use(rxReq, { relays: "wss://temp.example.com" }) .subscribe((packet) => { console.log(packet.message); });

rxReq.emit({ ids: [EVENT_ID] }); ```

すると { ids: [EVENT_ID] } は wss://temp.example.com から取得され、取得され次第 WebSocket 接続は自動で閉じられます。 (本当は relays オプションが emit() の中で利用できた方がいいと思っています。今後のアップデートをお待ち下さい。)

実際にはもっと色々なことができます。より詳しい使い方は公式ドキュメントをご覧ください……と言いたいところなのですが、v2.x に対応するドキュメントはまだありません。書きます……。

おわりに

RxJS の知識を前提としない範囲で rx-nostr に何ができるのかを解説しました。今度機会があれば RxJS と組み合わせることで何が実現できるかも書けたらいいと思っています。

明日 12 日のアドベントカレンダーは クリプト彼氏@仮想通貨擬人化 さんと Lokuyow さんの記事です！わいわい！

@ 20986fb8:cdac21b3

YakiHonne コミュニティはノストラシアに興奮しており、ノストラシアの感動的なスピーチを熱心に文字に起こしています。 追加のスピーチトランスクリプトは、今後公開される予定です。 日本語版とスペイン語版は、最初にコミュニティ メンバーによって AI ツールの助けを借りて翻訳および校正されます。 YakiHonneユーザーの皆様はぜひレビューにご参加ください。 無事にレビューを完了した方には特別報酬として3000Satが付与されます。 まずはご連絡ください (ここにコメントしてください、DM、または TG)。 連絡してレビューを送信した人が、幸運な特典の受け取り者となります。 もしよろしければ、これらのスピーチをさらに多くの言語に翻訳していただければ幸いです。 参加しませんか！

🌟English: Snowden & Jack on Nostr 🌟中文版: Jack 对话斯诺登 🌟Español: Snowden y Jack en Nostr

ジャック: ノストラを奇妙にさせない精神でみんなはどうやってる？私はこのインタビューを裸足で行うつもりです、エドワード。靴を履いているかどうかはわかりませんが、快適に過ごせることを願っています。

エドワード: 君たちの姿は全く見えないけど、スリッパを履いていて、えっと、パンツは履いていないから、これで大丈夫だよ。

ジャック: 完璧です。さて、始めます。ありがとう、エドワード！そこで、皆さんからのいくつかの質問を交えながら会話をしていきたいと思います。それでは、呼びかけますので、質問のある方は手を挙げてください。マイクを持って走り回る人は他にもたくさんいます。エドワード、まず最初に言っておきたいのですが、聴衆の前であなたと実際に会話するのはこれが 2 回目です。 1回目はTwitterをやっていた時でした。似たような会話になると思うが、それが非常に企業的な文脈で行われ、今度はプロトコルの文脈で行われ、それによって何が可能になり、何が可能になるのかを知ることができるのは、今となっては本当に素晴らしいことだ。それで、私は、ええと、あなたの前にいるときはいつもとても素晴らしいと光栄に感じます。しかし、あなたの姿がスクリーンに映るたびに、あなたが私たち全員のために払った犠牲のせいで、私は寒気がします。私はただ、あなたたちを認め、感謝し、私たちの感謝の気持ちを示すことからこの会話を始めたいと思います。私たちは、世界がどのように機能しているのか、そして私たちがお互いにどのように改善できるのかを世界に示すために、あなたたちが犠牲にしたすべてのものにとても感謝しています。そこに到達するには構築する必要があります。それでは、まず最初にありがとうございます。

エドワード: そうですね、ありがとう。つまり、この部屋にいる全員をとても温かく歓迎しているということです。ありがとう。実際、10年経った今、それは面白いことです。ご存知のとおり、世界はさまざまな形で進歩してきました。覚えてもらえるのは嬉しいですね。私個人としては、10 年前、そしてその飛躍がどのようなものだったのかを思い出すのが難しいことがあります。これは、まず第一に自分自身だと思います。私は今もここにいます、そして個人的には多くの方法で成功しました。勝った。私はそれで済んだ。大きな代償が課せられました。私は今、亡命生活を送っています。しかし、それは私にとってかなり良い仲間でもあると思います。だから、あまり自分の感情を傷つけないようにしているんです。アリストテレスは亡命先で亡くなった。シセロは亡命していました。彼は結局戻ってきた。エマ・ゴールドマン、もっと最近では、彼らは亡命を余儀なくされました。つまり、そこには長い歴史があります。そして、彼らをそこに送り込んだすべての事件で彼らが何をしていたのかを考えてみると、彼らが人民の敵だったわけではなく、彼らの見解が彼らを国家の敵に仕立て上げていたのです。それで、実際、ジャック、あなたへの最初の質問になります。なぜなら、現代社会、特に企業レベルで成功している人々は、アプローチを受けているからです。特に通信プラットフォームや金融プラットフォームの場合、それらは政府と相互接続されています。あなたは現代世界において、Twitter と Block の両方のベン図のスイート スポットに実際に座った数少ない人の 1 人です。つまり、財務面とコミュニケーション面の両方からの定期的なプレッシャーを見てきたことになります。それは主にインターネット上のあらゆる場所で起こっていることだと思います。私が成長していたとき、あなたが成長していたとき、聴衆の多くの人が成長していたとき、聴衆の一部の若いメンバーには当てはまりませんでした。彼らは、これが常にそうであったことを見てきました。しかし、インターネットはすごかったです。それは特別なものでした。それは政府もよく理解していないことでした。彼らは実際に侵入することはできませんでした。彼らはただ座って何が起こったのか見守っているだけでした。そして突然、インターネットは素晴らしいものからそうでないものへと変わりました。そしてツイッターも同じように感じた。それは驚くべきことでしたが、突然そうではなくなりました。世界は、率直に言って、近年、若い頃に戻ると、バラ色のメガネとノスタルジーなのかもしれませんが、それにはもう少しあると思います。すべてが素晴らしかったのに、突然そうではなくなりました。言葉遣いを許していただければ、コーリー・ドクトロウはエンシッティフィケーションの理論について話しましたが、これはもう少し形式的ではありません。そこで私たちは、クリエイティブな世代と共有文化のインターネットに無料で乗ることができました。そして今、暴利を貪る人々が参入してきた。プレッシャーと受託者責任はある意味克服された。そして今、状態は変わりつつあります。しかし、変化しているのはネットワークの状態だけではないと思います。サービスの状態だけでなく、世界の状態も同様です。私はただ、広い視野で考えていますが、何が起こっているのかをどう理解していますか？あなたが歩んできた旅、これらのことへのあなたの関与、そしてあなたの視点から世界がどのように見えるかについて、私たちに何を教えていただけますか?

ジャック: あなたもそうだと思います。私も初期のインターネットを初めて発見したとき、あなたが説明したのと同じような感覚を抱きました。そして私はつい最近、あなたの著書『Permanent Record』を読み返しました。私はそれを再読しませんでした。聴き直しました。ところで、あなたのナレーターは素晴らしいです。あなたがインターネットの感覚に何よりも興味を持ち、駆り立てられ、インターネットが人々をどのように感じさせ、自分をどのように感じさせたかを知るのは、ただただ驚くべきことです。この部屋にいる誰もがそのような感情を抱いたことがあると思います。開放的な気分になります。それは許可されていないように感じます。ほとんどすべての点で、ワイルドで奇妙で予想外の感じがします。これまでの人生で、実際に CEO になることや、ビジネスを始めることさえ計画したことはありませんでしたが、たまたまアイデアを広めるのに最も効果的な方法であり、この場合は Twitter でした。

しかし、私がその中にいたときに学んだのは、こうした単一障害点が増えていくということであり、最大の単一障害点は私自身であり、何億人もの人々と政策のために、この問題に関して主導し、意思決定を行っていたという点です。次に、あなたが言及した、収益に関するインセンティブについてです。 Twitter は初期の頃は素晴らしく、Rabble はこれについて、非常に多くの開発者が実験を行ったほど非常にオープンな API だったと話しました。実は日本にもたくさんいるんです。日本は私たちの最大の市場でした。なぜなら、非常に多くの開発者が API を使用して、餌をあげたり、亡くなったり、生きて笑顔になったりできるたまごっちのようなものを作ったからです。それは驚くべきことでしたが、実際にはサイトが常にダウンしてしまい、このような問題が発生しました。しかし、それが最もプロトコルのように感じられたときであり、それが最も特別に感じられたときです。私たちが成長するにつれて、私たちはそのような気持ちで始めましたが、その後、ベンチャーキャピタルから資金を受け取り、私たちが彼らに与えるこれらの株式は現在よりもある程度の価値があるものになると雇用した人々に約束させました。そして、それが私たちを上場させる一連の出来事を引き起こし、その前に広告などのビジネスモデルを生み出しましたが、それが広告圧力と収益モデルという別の単一障害点となりました。

私は過去に、Twitter が始まる前にビットコインが存在していれば、より良い選択肢とより良い道があり、単一障害点の少なくとも 1 つが取り除かれていただろうと述べました。それが私が Nostr にとても興奮している理由です。マイクロペイメントもあります。本物だ。これは実際に学ぶことができる大規模な実験です。そして私にとって、それはとても珍しくて驚くべきことであり、それが今実際に存在し、人々がそれを使って遊ぶことができ、そして最も重要なことにそれを感じることができます。そして、意味のある最後の単一障害点は、政府や規制当局の観点からあなたが言及したものです。明らかに、その多くは Twitter ファイルで暴露されており、政府や政府がドアをノックしてきたとき、個人としても社内の人間としても非常に困難です。あなたがとった立場を取るのは非常に難しいことです。なぜなら、私たちは Facebook や Google、その他すべてのものに対して最も小規模な巨大企業であるため、収益や会社が消滅することについて懸念を抱いているからです。以上のことを言いますが、私が思うことは変化しており、これらはすべて振り子の揺れであり、ビットコインのようなものがあるため、実際によりオープンなプロトコルを維持できる世界に振り子が戻りつつあると思います。

開発の観点、マーケティングの観点、政策の観点からビットコインに貢献する人は皆、同じことをする他の人たちにとってビットコインをより良いものにします。そして、非常に興味深い好循環が生まれています。そして、同じことがノストラにも当てはまると思います。そして、私にとって最も強力なアイデアは、Twitter のようなものを再作成したり、ソーシャル メディアのユースケースを処理したりすることではなく、オープンで許可のないアプリのエコシステムであり、それらのいずれかを作成する人は誰でもそれが実際に全体に利益をもたらすのは素晴らしいことです生態系。つまり、この協力こそが非常にユニークな方法で構築され続けているのです。以前にそれを行うためのツールがあったのかどうかはわかりませんが、おそらくインターネット上ではあったかもしれません。失敗したのは、検出メカニズムが集中化されていることです。そこに Google が登場し、Facebook が登場し、Twitter が登場しました。UseNet から離れ、IRC から離れ、Gopher から離れ、これらすべてのテクノロジーは真に分散化されていましたが、何かを見つけるのは非常に困難でした。では、発見についてはどのように考えていますか?

エドワード: ああ、あのね、今おっしゃったのは本当に興味深いですね。というのも、ここ 2 か月間ずっと思っていたのですが、今、検索エンジンを使うと、結果はひどいものになるんです。彼らは役に立たない。ご存知かどうかわかりませんが、私は複数の検索エンジンを使用しました。私は Google を使用しましたが、これが最高だと思われます。ビングを使ったことがある。私は DuckDuckGo を使用しました。どのページから始めても、その他すべてのページでも、同じような結果が得られます。そして、必要なものをまったく見つけることができなくなりました。それは、インターネットから特定のものを発見することはできません。一般的なものが必要な場合は、一般的なものが必要な場合は、確かにそうです。しかし、特に技術的なコンテンツや専門的なコンテンツを探している場合、検索エンジンを入手して必要なものを絞り込むのは非常に困難です。

そして、たとえば、インターネットに対して正規表現を実行できれば、必要なものを正確に取得できるでしょう。しかし、検索エンジンでは、このような操作はもうできません。 Google でさえ、10 年前には大量の検索エンジン オペレーターを抱えていました。そうですね、Google のハッキングはありましたね。そして今、すべてが非常に閉鎖され、ロックダウンされているので、もうこれらのことは何もできません。それは実に興味深いことです。これは、あなたが Twitter の API について思い出していたことと似ていると思います。 Elon が引き継いだ今では、snscrape またはソーシャル ネットワーク クラバー用の snscrape という素晴らしいコマンド ツールがあったように、多くの基本的な機能が失われています。そして、資格情報は必要ありませんでした。 Twitter にはそのようなものは必要ありませんでした。そして、タグとこれを行っている人を調べたい場合は、何万ものツイートを取得して、時間を計測したりフィルタリングしたりすることができます。これは驚くべきことでした。ネットワークから得られる洞察のようなものは、無料で入手できました。唯一の負担は知識でした。知識と対話する方法を理解していれば、それを行うことができます。 Twitter 検索は他の多くの検索よりもはるかに優れていました。 Twitter の小さなボックスに、「リツイート列」のようなものを入れて、それから、つまり、事実上人気のあるツイートだけを見たいというものを入れることができます。そして、そう、すべてのものは消え始めます。そのレベルの制御が失われます。そして、これらのネットワーク上で許容されるコンテンツの種類や言論の種類が狭まり始めていることがわかります。

私たちは YouTube が今、大きなスプリントを進めているのを見ています。彼らは長い間、本当に過酷なコンテンツ ID システムを導入して以来、それを続けてきました。ビデオ内の音楽が著作権で保護された曲のように聞こえる場合でも、完全にリストから除外するか、申し立てを行った人にある種の収益力を再割り当てするだけです。そして、ご存知のとおり、これらの詐欺師やボット業者は、サウンドが似ている曲を作成し、著作権で保護されていない音楽を使用できることに気づきましたが、その音楽に対して著作権を主張することができ、その後、広告収入を得ることができるようになります。この著作権のない無料の音楽を使用する人々の巨大なネットワーク全体が。そしてそれは延々と続きます。屋外のオープンな生活に存在するオープンネットワークには、このレベルの反社会的活動が存在します。社会には犯罪者や非協力的な要素が常に存在します。理論的には、政府の役割の 1 つは、政府が政府を管理しようとして、他の人々の足元をあまりにも強く踏まないようにすることです。問題は、彼らが「ああ、これは排除できる」と考えたときに始まります。そして、政府や組織がどのようなものになり得るかについて、救世主のようなビジョンを得ることができます。そして実際、最近、このことが大手メディア機関にさらに強く感染し始めているのがわかりますが、これは非常に困難です、彼らが行くところ、特定の種類の言論は許可されません、私たちがここに掲載しない場所、ここに表示しない場所、そして私たちが掲載しない場所ここで公開します。議論の幅は狭まっています。古いタイプのミームバフの犬対チェーンのようなものとは対照的に、昔のやり方をジャックしたものと、今日存在する少し悲しいずんぐりしたものがあります。以前は、悪い言論に対処する方法はもっと言論を増やすことだと言われていました。あなたは悪い議論を白日の下に引きずり出します。あなたはそれを信用しません。なぜそれが説得力がないのかを示すと、人々はその考えに固執しなくなります。まあ、最近では、「まあ、隠しておこう、闇の中に置いておこう」ということになります。そうですね、悪いアイデアは暗闇の中で、異議を唱えられたり、対立されたりしない場所で最もよく成長します。そこからコミュニティが発展し、そこから問題が発生します。

しかし、私が話を戻したかったのは、あなたがこの API や他のすべてのことに夢中になっていたことですが、Twitter が小規模でオーガニックだった頃、率直に言って信頼性が低く、失敗が多かった頃、あなたはどのように話していたかについて話していました。小さなコミュニティ、興味のあるコミュニティ、創造的なコミュニティがたくさんあり、皆さんが予想していなかったようなことをやっていたのです。たとえば、私も何度か日本語でツイートしたとき、だって、私は何年も前に日本に住んでいて、当時NSAで働いていたんです。日本語でのツイートでは、ほとんどすべてのツイートよりもはるかに多くの情報を伝えることができます。私が今まで見たことのある他の言語。これは私にとって驚きだったのですが、日本語はツイート形式に非常によく圧縮されることがわかりました。それはある意味驚くべきことではありませんが、私が言いたかったのは、小さなコミュニティはより良く管理される傾向があり、大きくなればなるほどそれは無秩序に拡散するということです。ある意味ますます悪化します。競争が激化すればするほど、派閥争いが激しくなり、征服をめぐる争いとなる、勝敗を争うような行動が多くなります。私が思うに、そしてこれが私を憂慮させる理由なのですが、これが言論界で起こっているのを見ると、ご存知の通り、Twitter は現在新しい管理下にあります。イーロンの時代が到来しており、率直に言って、彼は当時もできる限りのことをしようとしていたと思います。私たちがこれまで見てきたいくつかの決定、特に API などを閉鎖することでボットの問題が解決されることにはあまり感心しませんが、暗号化に隣接する単語さえ含まれるツイートはすべて解決されます。その下には同じ返信が 700 件ほどあります。特に、そのツイートやその他のアカウントを作成するために彼らに 1 ドルを請求している場合、それを修正するのはそれほど難しいことではないことはわかっています。誤った合意が形成されるリスクがあります。実際、私はここで 5 分ほど続けて話してきたので、あまりとりとめのない話はしたくありません。

しかし、私たちが政策について話すとき、政府について話すとき、規制当局について話すとき、現在権力を握っている人々が今頭の中で考えていること、ニューヨーク・タイムズで何が人気なのか、何が人気なのかという考えがあります。ワシントン・ポスト、それは人気がありませんが、それは正しいことであり、すべての正しい考えを持つ人はその信念を共有しており、それは推定された信念です。彼らは説得するという仕事をしていない。彼らは説得するという仕事をしていない。彼らは、他の誰もがなぜこれが正しいのか、それが正しいこと、異議を唱えるべきではないことを当然理解しているはずだと単純に思い込み、この信念からある程度逸脱する人は偽情報を広めていることになります。彼らは人々に誤った情報を伝えています。ご存知のとおり、それらはネットワークの脅威になっています。彼らは市民的または公共の脅威となっており、締め出す必要があります。それは私が本当に感銘を受けたことの一つです。率直に言って、あなたがトップに上り詰め、Twitter などで何億ドルも稼いだ人であるとき、「まあ、うまくいかなかったけど、私は私のものを手に入れた」と言って、夕焼けに向かって走り去ったようなものでした。世界中で多くの人がそうしていますが、代わりに、ここでは再びそれに戻ります。そして、あなたが公に発言したことで私が衝撃を受けたのは、Twitter の基本的な間違いはそれをプロトコルにしなかったことだと考えていたということです。あなたは、Twitter をプロトコルベースにするようイーロンに何度も公に圧力をかけ、少なくとも招待しました。そして、ここであなたは Nostr と一緒に、所有されていないプロトコルである必要があると言っています。そして、私たちが基本的に独立した言論を持っており、独立した支払いのためのフックが少なくともここにあるという事実は、私にとって真のゲームチェンジャーです。つまり、それが政府の規制や制度上の発言が公衆衛生に及ぼす損害を基本的に制限するものなのですよね？なぜなら、それらは健康を守るものであるはずであり、率直に言って、政府は、必要な場所のすぐ近くに留めておけば、最も過激な人々にとっても、政府が前向きな役割を果たすことができることを、率直に言って、私たち最悪の人間でも理解しているからです。その箱から這い出し始めたとき、それが事態が危険になるときです。したがって、かなり強力なボックスが必要です。かなり強力な境界線が必要です。そして、コンピューティング時代の法的または政策的問題に対して私たちが見つけた唯一の技術的解決策は、暗号化やこれがプロトコルであるという事実のような強固なものでした。そして、ただ誰かのところに行って「これを撤去してください」と言うわけにはいきません。ノード所有者にアクセスできます。リレーのオーナーのところに行って上手に頼むことはできるが、「これをしなければ刑務所に行く」とだけ言って、それで消えてしまったというわけにはいかない。今の世界は、本当に振り回されるべきではない。インド政府が「ああ、これを削除してください。これらは明らかに削除されるべきではないものです。」と言ったように。彼はこう言いました、「ああ、それは法律だ」、ほら、もう、もう終わってしまった。それで長々と言い過ぎたが、ただ言いたいのは、単に荷造りをするだけでなく、あなたが果たしている役割に本当に感謝しているということだ順調に進んでいますが、反復しようとしているのは、そうすることで物事が良くなるからですよね? このようなことを一度に完璧にする人はいません。率直に言って、Nostr ではまったく機能しない可能性があり、拡張できない可能性があります。以前は、今 Nostr を使用しているときと同様に、Tor 経由で接続するのに非常に問題があります。10 回再接続しなければならないものが表示されないなど、何でもあります。しかし、これは初期段階であり、状況は改善されていますが、それは通信であれ、支払いであれ、私は以前、国立後初の銀行が必要だというこの考えについて話しましたよね?ご存知のとおり、アメリカ銀行は必要ありません、ロシア銀行も必要ありません。中国銀行は必要ありません。私たちにはポスト国家的なものが必要です。外的な国家だけでなく、ポスト国家的なものでもあります。それは、国家が誰に報酬を受け取り、誰に支払わないかを決める最上位ではない世界を想像しているのです給料をもらえない。音声にも同じことが必要です。プロトコルベースの通信はインターネットに似ていると思います。私たちが今やっていることはすべて、基本的には TCP/IP です。ですから、たとえ間違ったとしても、暗い点があっても、努力し続ける限り、そこから抜け出すことができ、物事は好転する可能性があります。そして、率直に言って、インターネットの方向性、プライバシー法の方向性、この種の民事の衰退、言論と衰退を見て、私はこの数年間大変な日々を過ごしてきましたが、あなたがまだ楽観的だと聞いて、ここに来ている群衆の中の全員を見て、まだ前向きだと聞いていますよね？すでに外れ値でなかったら、あなたたちはここにはいないでしょう。素晴らしいものを構築するために世界中の誰もが参加する必要はありません。私たちはただ気にして努力するだけでいいのです。だから今度は私がお礼を言う番だと思います。

ジャック: ああ、確かに。ありがとう。私が学んだすべてを知り、あなたが私たちに与えてくれたものをもう一度知り、私たちがそれを修正できることを知り、ビットコインのようなものとその背後にいる人物、そして彼らが再び奪おうとする彼らの意図を見て立ち去るのは非常に難しいと思います学び、今後の世代のためにより良いものを構築しようと努めています。そして、ノストラやフィアチャフのような企業が、本当に許可のない方法で協力し、誰もが素晴らしいアイデアを持っていて、あなたのような人々からのフィードバックを取り入れているのを見ることができます。そして私は、自分自身を表現し、共感を呼ぶ表現を見つけようとしている世界中の普通の人々がもっと増えることを願っています。発見の問題は依然として Nostr にとって非常に難しく、不器用であり、間違いなく人々を遠ざけています。しかし、私たちは今、自分たちでたくさんのことをテストできる、非常にアーリーアダプターの集団の恩恵を受けています。そして、私たちは幸運にもあなたのような人をユーザーに抱えています。私からあなたへの質問の 1 つであり、聴衆からも何人か質問をする必要があります。なぜ Nostr を使い始めたのか、そしてなぜ使い続けているのですか?なぜなら、あなたが現在世界にもたらしているものの多くは、大勢の聴衆を必要としている、あるいはその恩恵を受けているからであり、現時点では Nostr の聴衆はおそらく可能な限り少ないからです。それで、なぜここにいるのですか？

エドワード: ありがとう。でも、そうです、つまり、私の Twitter アカウントを見てみると面白いのですが、私はもうほとんどツイートしません。わかりませんが、そのアカウントには 500 万から 600 万人のフォロワーがいるのですから、これは大きなメガホンです。 1 つ目は、Twitter でのエンゲージメントが予想よりもはるかに少ないことがわかります。それが私がアルゴリズムの恩恵を受けなくなったため Twitter でのエンゲージメントが低下したのか、それとも 1,000 億またはそれ以上の増幅が得られるという考えが必ずしも厳密に真実であるとは限らないのかはわかりません。 500 万人がこのアカウントをフォローしているということは、500 万人にこのツイートが配信されるというわけではないので、それが真実であるはずだと思われる場合。そうあるべきですが、それは正しくありません。つまり、白か黒かだけではありません。しかし、より直接的に言えば、Twitter の人々は聞くのをやめました。そしてそれは私にとってではありません。彼らは誰の言うことも聞かなくなったのです。そして、これは特定の Twitter ソーシャル ネットワークの問題というよりも、むしろ世界的な問題です。しかし、具体的にはソーシャルネットワークのソーシャルメディアやTwitterがこれを象徴していると思います。誰もが叫んでいますが、誰も聞いていません。売却や譲渡に伴って混乱が生じ、すべてが変わりつつあるのを見て、Twitter が永遠ではないかもしれないことを実感させられます。そして、私のような人間にとって、Twitter は期待するほど信頼できません。そして、あなたは本当にこれを自分のメガホンとして依存しているのです。なぜなら、私は Instagram や Facebook をやっていないからです。私はTikTokに参加していませんし、参加したこともありません。

私にとって、Nostr は、特に所有されていないプロトコルであるという考えから、単なる大きなメディア資産以上のもののように思えます。そしてそれが私にとって魅力的です。それは私が成功するのを見たいものです。私は、人々が自分のフィードで見るものに対する一種の権限を、アグリゲーターからユーザーへと移したいと考えています。さて、それは極端である必要はありません。どちらかの方向に固定する必要があるダイヤルのようなものではありません。ユーザーは手動で「ブロック、ブロック、これを表示しないでください」をクリックするだけです。 100億件のツイートに対してそれを行う必要はありません。これらは良いアカウントであり、これらは悪いアカウントであるため、コンテンツ タイプ リストなど、またはコミュニティ ソース リストを選択できる必要があります。早速始めましょう。これらすべての人をフォローしていないと、スパムやギャンブルなど、あなたが気に入らないアカウントからのツイートが表示されなくなります。でも、それは人間の決断ですよね？これらは個人的な決定です。これらは個人の決定であり、場合によっては集団的な決定ですが、企業の決定ではありません。それらは政府の決定ではありません。それらは規制上の決定ではありません。スピーチに関しては、それがとても重要だと思います。 2 つ目は、Nostr が今より快適になったことです。つまり、ビットコイナーではない場合、一般の人にとっては無味乾燥だと思われるコンテンツがたくさんあります。ネットワークを成長させたいのであれば、その段階を超えて、より魅力的なものにする必要があります。

しかし、ビットコインに興味がある人にとって、それは単なるオーガニックであり、小さなコミュニティであり、ほんの始まりに過ぎませんが、可能性を見て、熱意を見て、そしてもう一度、真の優しさを見てください。基本的なレベル、それはいいですね。世界の歴史を見てみると、小さな政府はより良い政府になる傾向があり、小さなコミュニティはより親切なコミュニティになる傾向があり、彼らはこの小さな志を同じくするコミュニティから超国家の実現への旅に向けて出発するのです。世界的な力。それらの理想やビジョンの多くは、道路上の塵のように振り落とされてしまいますが、それはそうしなければならないからです。その方向に進むのであれば、征服の名の下に犠牲を払わなければなりません。しかし、初期の頃、初期のネットワーク、アイデア、夢には魔法があります。そして率直に言って、私が理想主義者でなかったら、楽観主義者でなかったら、2013 年にやったことはしなかっただろう。私と同じものを見て、それを集合的に、あるいは全体として見ることができた人のほとんどは、かなり少数の人々だったでしょう。しかし、部分的に見ると、そこで間違ったことが起こっていることを知っている人がたくさんいて、誰も何も言わず、人々は「なぜ？」と言っていました。そして、それを自己保存だとか卑怯だとか考える人もいますが、それはある程度は正しいのです。しかし、もっと寛容な見方もあると思います。それは、人々はそれが何の違いも生むとは考えていなかったということであり、現実的に考えて、私はどのような変化をもたらしたのでしょうか？それは世界を救ったわけではありません。ドラゴンを倒すことはできませんでしたが、その結果は甚大でした。最も可能性の高い結果は、私が今もスーパーマックスの状態で座り続けること、そして残りの人生もそうすることだろう。

しかし、私たちは今、米国だけでなく世界中で、ある種の共通のレベル、共通のイメージ、共通の認識をテーブルにもたらしたことを知っています。そしてそれは何かです。構築を始める場所です。それは前進すべき場所であり、それがリスクを認識する基本的な人間の衝動だと思います、ほら、草の上に虎の尾が見えますが、行きなさい、私はここに座ってそうでないことを祈るつもりはありません」私に会いません。もしかしたら、他の誰かが手に入れるかもしれない。トラの問題を解決することに少し取り組んで、もしかしたらあなたにはそれができないかもしれないし、トラに捕まるかもしれないと認識できるかもしれません。しかし、十分な数の人々が努力し、私たちが十分長く努力すれば、トラの問題は解決されるでしょう。それでとにかく石を投げました。しかし、これについてはもう一つ触れておきたいことがあります。それは、政府とは、現在私たちが実際に意味のある制御を持っていないことで私たちに行われているという感覚です。政府が自然災害であるのと同じように、政府は実際にそれを好みます。どこの国にいてもそうですよね？彼らは、統治し、決定を下し、命令し、規制するために放っておいてもらいたいと思っており、あまり裏話をしたくないのです。彼らは動揺を望んでいません。彼らは反対意見を望んでいません。彼らは意見の相違を望んでいません。支配層の間には、自分たちを放っておいて仕事をすれば事態は良くなるという考えがあります。心地よい沈黙があり、もしあなたたちが黙ってこの問題を解決してくれれば、私たちが問題を解決してあげます。心配しないで。しかし、それもまた、問題が何であり、どのように解決されるべきかについての誤った共通認識から来ています。しかし、言論の自由と民主主義一般の考え方で最も重要な点は、そもそも何が問題なのかについて議論できるようになるということだ。今日、その点で合意が得られていないことは私にとって非常に明らかですが、組織内では政府が答えであるという合意はあります。そしてそれは危険だと思います。したがって、言論の自由が増えれば増えるほど、より自由なプロトコルが増え、よりクリエイティブな人々が別の対話方法を生み出そうと努力するほど、より良いことになります。なぜなら、そうでなければ、これらの問題は私たちのために解決され、歴史的に有害な方法で考えられるからです。すでにそうなっていると思いますし、さらに悪化すると思います。

ジャック: もちろんです。聴衆からの質問を受け付けてみませんか?

聴衆 1: まず最初に、あなたとして生きてくれて、これまでの人生を生きてくれてありがとうと言いたいです。私がここにいる理由の大きな部分を占めているのはあなたの存在であり、それは私たちの多くにとっても真実であると確信しています。

私たちはここ数日間、鍵管理についてよく話してきましたが、公開鍵暗号化に依存しなければならなかった者として、そして今は家族を持つ者として、その課題や抱えていることについて何か考えがあるかどうか知りたいと思っています。構築されるのを待っています。公開鍵暗号を一般の人が利用できるようにする場合、どこに焦点を当てるべきだと思いますか?

エドワード: ああ、それは良い質問ですが、難しい質問ですね。あなたが「私には家族がいる」と言った瞬間、私はこう思いました。「そうそう、私の鍵は私と一緒に死ぬだろう、なぜなら私には後継計画など何もないから、少なくとも私の美しいカスタム総力に関しては。」しかし、これは特に Nostr の場合、困難の 1 つです。ここで批判したり石を投げたりするなど、もっと良いアイデアがあると言っているわけではありませんが、一般の人にとって、ユーザー名が消えてこれほど長い、32〜64文字の文字列に置き換えられるのは、「おい、何だ」というようなものです。それはどうすれば抽象化された方法で象徴的に表現できるでしょうか？」ノストラの成功にはそれが重要になると思います。 GPG が長年にわたって機能してきた方法による生の公開鍵と秘密鍵のモデルでの鍵管理は、基本的に通常の人間には適していないことが示されていると思います。 2013年の暴露時にも使用しました。 PGP が機能することがわかっていたので、すべてのレイヤーとして PGP を使用していました。それがうまくいくとわかった理由は、私が NSA で働いていて、前の職で生のトラフィックを調べ、私が引き出してきたもの、中国から出てくるサイバー対策活動を調べていたからです。 PGP ではそれほど大したことはありませんでした。しかし、電子メールやストリームなどから送信されるものを見てきましたが、それは PGP で暗号化された電子メールであり、基本的に復号化が提供されずに返されますが、暗号化システムなどを使用すると、他の特定のものについては平文が提供されることがあります。 SSLエラーか何かでした。それは時々起こりました。結論から言えば、それはうまくいきました。歴史がそれがうまくいったことを証明しています。それは古いプロトコルでしたが、間違いを犯しやすかったです。一般に、公開鍵を送信する必要があるときに秘密鍵を送信することがあります。そのような基本的なことです。あなたはこれを技術的な背景がまったくないジャーナリストに説明しようとします。彼らはあなたが誰であるかを知らないので、あなたをあまり真剣に受け止めません。グレン グリーンウォルドが、私が文字通り彼のために PGP の使用方法に関する説明ビデオ全体を録画したため、この話をほとんど聞き逃しそうになったことは有名ですが、彼は「ああ、忙しすぎる」という感じでした。そして、これは私たちが理解しなければならない種類のことです。一般の人にとって、専門家にとって、技術者にとって、聖職者にとって、親しみやすいものは何でしょうか？これについては理解できます。これらの概念の一部は私たちにとって馴染みのあるものであり、それは素晴らしいことですが、それは隠す必要があります。これは抽象化する必要があり、なりすましの問題などを回避するなど、衝突が起こらない方法でユーザー名を組み合わせる方法を見つける必要があります。そして、私たちが Nostr でそれをやろうとしているのは知っています。分散型であるため、70 の異なるプロバイダーが存在します。あなたにはそれができるはずです。しかし、発見しやすさとは何なのか、ということも考えられます。真実の情報源は何ですか?ビットコインの場合と同じように、ほとんどの分散型プロバイダーが、たとえば、ジャックはジャックであり、正しい最終の子犬を提供することに同意するしきい値を設定する方法はあるのでしょうか?おそらくそれはうまくいくでしょう。それが解決策かもしれません。わかりませんが、一般的に結論としては、私たちはこれらの形式の暗号化の仕組みを知っている、ということです。彼らは信頼できます。それはすごいですね。それは素晴らしいことです。なぜなら、それを基にして構築できるものだからです。しかし、それらが一般の人には理解できないことも私たちは知っています。問題はそのギャップをどう埋めるかということです。私は答えを持っている人になりたいと思っていますが、そうではありません。

ジャック: エドワード、あなたは報道の自由財団の理事を務めています。その財団の任務の 1 つは、活動家、内部告発者、ジャーナリストのためのテクノロジーの構築を支援することです。 Nostr や Bitcoin とは関係なく、今最も大きなニーズをランク付けすると、そのリストはどのようになりますか?

エドワード: そうですね、つまり、私たちがずっと続けてきた目玉プロジェクトは SecureDrop です。なぜなら、詳しくない人のために説明すると、SecureDrop はニューヨーク タイムズのような主要なニュースルームが利用できるシステムだからです。ワシントン・ポストは、世界の主要なニュースルームと同様に、かなり強力に強化されたシステムを取得するための匿名のヒントを処理します。 Tor を介して任意のソースから匿名で接続でき、身元を明らかにすることなくヒントを提供できます。これは 2013 年の私に欠けていたものでしたね。私はココナッツと接着剤で独自のシステムを作成し、ジャーナリストに私が誰であるかを知られずに何が起こっているのかを明らかにし、何らかの方法で彼らに動機を納得させ、同時に意図的または意図的に動機を持たせないようにするにはどうすればよいかを考え出す必要がありました。意図せずして、それが本当の恐怖でしたが、基本的にすべての証拠を入手して逃げる前に、私の身元を政府に明らかにしてしまいました。問題は、彼らの誰もその種の問題を処理するのに有効な資格を持っていないことだからです。インターネット上のコミュニケーションなどに関しては、平均的なジャーナリストを NSA と戦わせて勝利を期待することはできません。

SecureDrop は、基本的に人々が 2 台のラップトップを入手できるようにするための方法であり、そこにキューブとその上に重ねられたようなプログラムのスタックがあり、これをすべてアプリケーションで処理できるようになります。彼らのために。そして、私たちはそれが機能すること、そしてそれが信頼できるものであることを知っています。そして実際に、皆さんがこのシステムを通じて体験した最大のストーリーのいくつかでそれが機能していることを私たちは知っています。それを明らかにするのはニュース編集室の責任であるため、実際にはどれがそうでないかは明らかにされていません。多くの場合、トラブルに巻き込まれたくないため、そのことを公開したくないのですが、それでも問題はありません。

さて、今考えてみると、興味深いことの 1 つは、人々が名乗り出て、何が起こっているのかをメディアに知らせるための良い解決策が私たちにはあるということだと思います。しかし、率直に言って、メディアという組織に対する信頼は今ではそれほど低くありません。非常に有名な話ですが、2013 年に私はニューヨーク タイムズ紙に行かなかったのです。それは、彼らがニューヨーク・タイムズ紙の編集長ビル・ケラーを殺害し、ブッシュ政権による令状なしの盗聴に関する記事を殺害し、彼の再選の一か月前に掲載されるはずだったからだ。そうなれば選挙は大きく動いただろう。あの選挙はほんのわずかな差で決まり、この男が憲法に違反してアメリカ国民や世界中の人々をスパイしていると知っていたら、違う歴史があっただろう。その結果はニューヨーク・タイムズにある。今日は彼らがもっとうまくやってくれることを願っていますが、私は必ずしもそうなるとは確信していませんし、多くの人がそれに直面しています。

そこで今日の質問は、ニーズは何かということです。私たちは何ができる？その代わりに、報道の自由財団が満たされていないニーズを満たすためにやっているのは、Open Broadcaster のような、現在既存のオープンソース パッケージに注目しているような気がします。カメラを自分のものに取り込んで、基本的に、人々が自己出版する方法、場合によっては匿名で行う方法についての命令スタックのようなものを作成します。信じられないことに、インターネット上にはあまりにも多くのコンテンツがあり、非常に多くの贅沢な主張があることが問題なのですが、どうやって正真正銘の主張を確立するのでしょうか?私がジャーナリストと話している場合、「ねえ、私はここで働いています。私はこれです。私は政府関係者です。でも、あれこれの理由で私の身元を話すことはできません」のように言えるかもしれません。 、でも、このプログラムとこのプログラムとこのプログラムとこのプログラムについては話すことができます。」そして、あなたが政府にコメントを求めに行くと、彼らの髪は抜け落ちるでしょう、そしてそれは、少なくともそこにいる人だけが知っているはずのことを私が知っているということをある程度確立するでしょう。しかし、専門的な検証者なしでこれを一般向けに再現するにはどうすればよいでしょうか?最近、バリデーターについて話すとき、ファクトチェッカーの概念が取り上げられ始めていますが、ファクトチェッカーも栄光を誇示していません。つまり、これは面白くもあり、難しい種類の問題空間でもあります。

しかし、これには2つの見方があると思います。 1 つは、伝統的な古典的なジャーナリズム、その最良の形をどのように実現するかということであり、Source が本当に多くのことを取り組んでいるのはそこです。ジャーナリストに国民に情報を伝えるために知っておくべきことを伝えます。実際、私たちはそれに対して良い解決策を持っており、ここ数年で改善されてきました。しかし今、これらの古典的な機関がどのように行動すべきかという私たちのプラトニックな理想に沿って行動すると必ずしも信頼できない場合、情報源に名乗り出て、それらのリスクを負担してもらうにはどうすればよいでしょうか?これはテクノロジーの問題というよりは、むしろメディアの問題です。テクノロジーですべての問題を解決することはできませんが、独自の解決策を考え出すことはできるかもしれません。つまり、この問題に対する古い独立した解決策はウィキリークスでした。そこでは、「ほら、あなたはニューヨーク・タイムズには行きたくないのです。あなたは、ニューヨーク・タイムズに行く他の人のところに行きたいのです。」人々はこれを忘れています。人々はウィキリークスがすべてをインターネット上に放り投げただけだと思っているが、実際には、彼らは世界最大の新聞社と協力し、新聞社が組織的に裏切るまで働いていた。問題は、その結果としてジュリアン・アサンジに何が起こったかを我々が見ていることだ。

これがアイデアです。私たちは地球の反対側で座って会話し、これらの問題に対して思いつくことができる解決策を夢見ています。しかし、反対側の立場から考える必要があります。政府があり、単数形ではなく複数形で、私たちはこの会話を聞いており、彼らは私たちが解決策を生み出すのではなく、問題を作り出しているのを聞いています。彼らはウィキリークスを見ています。彼らは世間の知識を解決すべき問題だと考えています。そして、世界が中国モデルに向かって進んでいるという現実を、私たちはただ鋭く認識する必要があると思います。私は以前、国防情報局の統合対諜報訓練アカデミーで、いわゆる中国のサイバー対諜報活動について説明していました。それはばかばかしい種類の政府ブランドでしたが、ここでの考えは、中国政府とその運営について私たちが知っているすべてのことを新しいアナリストに教えるためだけに年に数回開催される会議であるということでした。私はこの小さなテクノロジーの部分を担当していましたが、そこで他の講師と議論した理論は、人々が常に推測しようとしているため、私たちが見ているものは、5 年に中国がどのようになるかであるというものでした。何年後、10年後、次の首相は誰になるかなど。これには重心があったと私は主張します。人々は、我々は中国になるだろうと、あるいは中国はアメリカになるだろうと言いましたが、基本的には我々は他のモデルを採用するつもりだと言いましたが、私は実際には違うと思います。

権威主義的な重心があり、あらゆる種類の政府をそこに引き寄せていると思います。中国政府は非常に権威主義的です。世界中の多くの政府は非常に権威主義的です。しかし興味深いのは、リベラルな政府がより権威主義的になっているのが見られることです。新型コロナウイルスは、パニックや緊急事態の感覚をそれほど必要としないという、まさに真っ赤な危険信号でした。私たちは今、どこへ行ってもイスラエルとハマスで同じことを目の当たりにしていますが、ご存知のとおり、誰かが一線を越えました。 911 の瞬間があり、古いルールはもう適用されません。クラシックの権利は保護されなくなります。世界は変わりました。したがって、組織としての私たちは変わります。ロジスティック的には投票する時間がありません。会話する時間がありません。これは緊急事態だ、理解できないのか？したがって、私たちは自分たちの能力、テクノロジーを最大限に活用して脅威に立ち向かう必要があります。そして、一歩ずつ、少しずつ、中国と米国がより似てきていることがわかります。ヨーロッパと中国がますます似てきていることが分かります。それらは依然として異なります。二人の間には距離がありますが、その距離は狭いです。そして、それは本当に私たちを警戒すべきものです、特に能力に注目し始めるとき、監視に注目するとき、QRコードに注目するとき、資金の流れの制御に注目するとき、通信の制御に注目するとき、そして、実名ポリシーとアイデンティティに関して言えば、中国には決済、チャット、アイデンティティ、ソーシャルメディア、旅行、チケットなどを行う WeChat のようなすべてのアプリがあるという事実を見ると、しかし、中国政府はアカウントを有効にするためにオフィスに出向いて身分証明書を発送することを要求しています。そして、イーロン・マスクが「ああ、X はすべてのアプリになるだろう」と言っているのが聞こえます。彼は人々にお金を払い始めていますが、その場合、お金を受け取るためにはそれを自分のアイデンティティと結び付ける必要があります。これらは私たちにとって本当に憂慮すべき事柄です。

とにかく、ここでの報道の自由財団というテーマから大きく逸れていることはわかっていますが、ここでの考え方は、どのような問題が技術的に対処できるのか、ここのイデオロギー空間における私たちの敵は誰なのかを理解する必要があるということだと思います。そして、問題を直接解決できない場合、おそらく解決できる人々に問題の認識を高めることはできるでしょうか?そして、それが私たちの管轄内で不可能な場合、そうです、私たちの一連の法律の下で不可能な場合、あなたの言語、文化、地域、政府の下でそれが不可能な場合、新しい管轄区域を作成できますか?これは古い種類のサイバースペース独立宣言であり、今日多くの人がそれを鵜呑みにしています。ジョン・ペリー・バーロウは、「ああ、肉と鋼の疲れた巨人たちよ、ここではあなたたちに力はない」と言いましたが、これは基本的に心の新しい領域においてです。これが私たちの世界です。それは私たちの空間です。私たちが望むようにそれを作ります。あなたはゲストです。あなたは訪問者です。あなたが決定を下すのではありません。そして率直に言って、それは真実ではありません。主な理由は、インセンティブ、企業の金銭構造、支払いの流れ、規制、顧客の把握などです。しかし、それはインフラが所有されているからでもあると思います。私たちは他人のケーブルに乗っています。私たちは他の人のデータセンターや道を横切っています。メッシュ ネットワーキングのアイデアがすべてうまくいったわけではありません。彼らは規模を拡大していません。彼らは問題を抱えていた。しかし、過去に働いていないからといって、今後も働かないということでしょうか？そして、それが実際には真実ではないと思います。私は、オプトイン型の友愛ネットワークや、携帯電話がすぐそこにあるコミュニティのアイデアが好きです。携帯電話を持ち歩いている場合、それはすでに追跡デバイスです。すでにネットワークに自分自身を報告しています。しかし、これが、何が起きているかを追跡するすべての新型コロナウイルスの Bluetooth と同じ方法でビーコンを発信するのであれば、実際には、同じ考えを持つ他の人々へのビーコンになります。そして、あなたが通過すると、それは簡単なネットワーク接続を確立し、あなたたちは一種の「いいね！」を共有し、識別子を渡したり、ファイルを渡したりすることになります。そしてそれは意識的な決定ではありません。ボタンをクリックしませんでした。それはただ、「ああ、誰かがいるね」というだけです。彼らが誰であるかはわかりません。 ID を共有する必要はありません。ネットワーク上では暗い存在になる可能性があります。あなたはダーク ノードである可能性がありますが、Nostr タイムラインまたはその人の小さなコミュニティの更新情報を効果的に取得しているだけです。今、あなたはこのコミュニティが存在することに気づきました。今では、バスに座っているだけで、以前思っていたよりも少しだけ孤独ではなくなったことに気づきます。そしておそらく、あなたたちを失っただけなのかどうかはわかりませんが、それについて話しているのかもしれません。私たちはあなたの声を聞いています。カメラを紛失したようです?

ジャック: あなたの声は聞こえますが、ビデオは見えませんが、はっきりと聞こえます。

エドワード: ビデオを紛失してしまいました。すぐに再開します。カメラが過熱したのかもしれないと思います。でも、そう、プレス側の話に戻ろうと思っていたのですが、これをひっくり返して、ちょっとだけ離れます。おそらくジャック、私がこれに取り組んでいる間、聴衆に質問してください。ニュースルームの前を通り過ぎて、同じことができるでしょうか?これはデッドドロップの古典的な古いスパイテクニックのようなものですよね?冷戦時代のテクノロジーのように。しかし、想像してみてください。インターネットが監視されすぎていることを私たちは知っています。たとえば、フローを解読できる世界規模の受動的な敵対者が存在するため、Tor は通信の保護においてもはや信頼できなくなりましたが、それが今日真実であるかどうかは明らかではありません。誰もが「ああ、Tor は壊れている。Tor は機能しない」という感じです。私はいつも Tor を使用しており、それに依存していますが、それは私にとって非常に良いものです。だからといって、そのように機能するシステムは存在しないため、これが絶対に自分の人生を賭けることができるものの 1 つだというわけではありません。しかし、そうではなかったと仮定し、そのようなネットワーク通信は不可能だと仮定してください。そうですね、実際にニュースルームの外にデバイスを置くと、誰かがオフィスの前を通り過ぎて、チップやファイルを落としてそのまま通り過ぎていくようなものになるかもしれません。そして、厳密にタイムスタンプが押され、屋外の監視カメラに対してインデックスが付けられていない限り、ジャーナリストが知っているのは、自分が密告を受けたということだけであり、知らないためその人物の身元を明らかにすることはできません。でも、分かった、ちょっと離れて、このカメラを修理してみよう。

ジャック: 100%。すべてのアプリが私たちの未来になるように、私たちは動いているように感じます。そして、中国政府と世界中の自由主義政府がより似てきており、その差が縮まっているというあなたの発言がとても気に入りました。これらすべてのアプリが存在し、おそらく文字通りの州境を超えて競合することを知っているので、私たちができる最善のことは、Nostrのようなものとビットコインのようなものである3番目の選択肢を持つことであるように感じます。これらすべてのアプリは、使用する個人がアプリ間の切り替え方法を考慮することなく、非常にシームレスな方法で連携して動作します。初めて Nostr に出会ったとき、私にとって最も強力だったことの 1 つは、文字通り秘密鍵を持って別のクライアントに行くことができ、すべてがうまくいったことです。そして、これをこれらすべてのマイクロアプリとマイクロアプリの世界に拡張すると、基本的にはすべてのアプリが手に入りますが、それは誰もが構築できるオープンプロトコル上にあり、それは中国が何であるかについての真の競争力のある答えになります。米国および西側諸国の企業が構築しているもの、そしてその方向性を考慮すると、おそらく私たち全員を魅了するものとなるでしょう。そこで私たちには選択肢があり、幸いなことにそれはこの部屋にあります。それを構築するのに協力してくれた皆さんに感謝したいと思います。それでは、別の質問をさせていただきます。

聴衆 2: こんにちは、Tor 経由でアクセスできないこと以外に、Nostr の使用中に発生したスケーリングの問題はありますか? または、Nostr を有効にしてほしいことはありますか?

ジャック: エドワード、まだそこにいるなら、それがあなたのためだと思います。

エドワード: ええ、ごめんなさい、みんな、変な話にしてるんですよね？ええ、実際のところ、ノストルは今本当に有能だと思います。重要なのは、人々に使ってもらうことです。 Lightning に対して批判的な意見があるため、Lightning Network と Lightning Network の統合についていくつかの批判を見てきました。ライトニングは私にとってかなりうまくいきました。つまり、私は興奮してきました。ザパソンとかそういうものは全部見ています。私が気に入っているのは、一般の人でもアクセスしやすいということです。私が気に入らないのは、誰も独自の種類の Lightning ノードを実行していないという点で、集中型ゲートウェイのセットを別のセットに置き換えることです。ノードが実行されていないため、誰もが Alby または他の集中プロバイダーのように使用しています。そして、オフラインの場合、Lightning などは機能しません。これらは私には解決方法がわからない問題ですが、重要なのは、多くの人々のユースケースで非常に人気のあるビデオ公開などについて話すとき、それをどのようにホストするのかということです。画像ホスティングは高価です。ビデオのホスティングと配信にははるかに費用がかかることはご存知でしょう。そして、インターネットの多くが私たちが理解できるように機能してきた理由は、ジャックが言ったように、背景の倉庫で静かに燃えているVCの資金があったからです。 Googleが現在YouTubeで行っていることはその最良の例だ。そして、その点で彼らと競争することの妥当性について私が心配しているのは、彼らがすべてを同時に収益化しようとしているということです。彼らは広告ブロックに対して非常に攻撃的になっています。彼らはさらに多くの広告を掲載しています。広告ブロッカーを実行しない場合、サービスに登録するまで、広告ブロッカーはますます多くの広告を実行します。そして、それはすべて同時に起こっています。一方、長い間、YouTube は無料のものであり、YouTube にあるコンテンツのほとんどは、お金を払うようなものではありませんでした。そして今、突然、彼らは状況を変え、YouTube にはインターネット上のあらゆるビデオが掲載されており、たとえ彼らに属していないものであっても、どこかからリッピングされ、再アップロードされただけです。しかし、もしあなたが Nostr のようなことを話しているのであれば、ご存知のように、私たちはどうやってビデオをアップし、ミサなどでそれらをホストするにはどうすればよいでしょうか？人々が今やっていることを埋め込むことができることは知っています、そしてそれは実際に美しいことです。それは素晴らしく機能します。接続できたときはまた良い経験ができました。しかし、考えてみると、ノストラ版のホイルクジラに参加している多くの人々は、私たちがこれらすべてのリレーを持っていて、これらのリレーすべてに、基本的にこれらの他のサイトにリンクするメモが書かれているようなものです。そのようなリポジトリが 1 つあり、そのリポジトリがダウンしたり、先手者が取り除くことができない神聖な牛になったりした場合、ビットの腐敗にどう対処するのでしょうか。なぜなら、彼らが落ちたら中心部分を失うことになるからです。ネットワークが壊れて、それに付随する履歴が失われますか?これらは難しい質問だと思います。しかし、Nostr の基本的な機能について考えると、それが Twitter に似ているという考えだけで興奮します。人々はTwitterが好きです。彼らは企業の門などを一切持たずに Twitter を楽しんでいます。人々が必要としているのは、あなたが言ったような発見可能性の問題だと思います。コミュニティ リストかそのようなものがあるかどうかわかりませんが、UI のオンボーディングのためにどこに行くのか、何に興味がありますか?そして、これが行っているすべてのことと同様に、これを開始するために人気のあるアカウントやトレンドのアカウントなどを追加しているだけであると説明されています。まだ変更できます。何でもできます。それらを取り出すことができます。これをブロック リストと交差させたり、リストやその他のリストを無視したりすることができます。そのため、人々はすぐに、Nostr で興味深いことについて話しているのは誰なのかを言い始めることができます。彼らはやって来て、アカウントを持っていて、面白いことが起こっているのを見て、そして去っていきます、どうすればいいでしょうか？そして彼らはメモを出しました。誰もがそれを見て、レースに出発します。実は、そこに疑問があります。フォローしている人がいない場合、それはどのように表示されるのでしょうか? Damus であろうと、Amethyst であろうと、さまざまな Nostr アプリのようなものはありますか。彼らには、さまざまなネットワークをキュレーションする人がいます。これらはリレーのような真新しいアカウントであり、基本的に、これらのユーザーがこれまでに何らかのアクティビティを行ったのが初めてであることを示すフラグがあり、その 99% が中国のスパムかその類のものであることはわかっています。しかし、それを見て、ああ、これは実際の人物である、または実際の人物のように見える、と思います。彼らは何か面白いことか何かを言っています。そして、それは、あなたがアプリに入ると、この人を最初の 10 人のフォロワーにしようとする呼びかけやショーケース、またはそのようなものを知っているのと同じです。オンボーディングプロセスを容易にする、成長するコミュニティを歓迎するこれらの方法は、本当に重要だと思います。しかし、重要なことは、私は今、実際に少し心配しているということです。私たちは、何億もの新規ユーザーが今すぐに流入して押し寄せるのを望んでいません。なぜなら、Nostr がゴールデンタイムに向けて準備ができているかどうか確信が持てないからです。キー管理の問題は解決されていません。そして、1,000 人、100 万人が参加するなら、最初から良い体験をしてもらいたいと思うでしょう。そうしないと、彼らは戻ってこないかもしれません。しかし、もし彼らが戻ってきたら、友達全員に、あなたがすでに使っているものよりも優れたものがあること、TikTokビデオを作成できることはわかっていること、しかし、それに対処する必要はないことを伝えることになるでしょう。 AIや機械学習などを使ってあなたの話を聞くTikTok。そして、間違った言葉を使用すると、動画などのランクが下がってしまいます。代わりに、友達と何かを共有したり、友達と何かを共有したりすることができます。あなたの友達はあなたの友達と交流しており、それが強力である、これが面白い、これが違う、といった中間は存在しません。そして、ご存知のとおり、今後は対処しなければならない問題がたくさんあるでしょうが、重要なことは、それをうまく機能させること、簡単にすること、フレンドリーにすること、面白くすることです。実際にそうする必要はありません。それは興味深いです。何が興味深いのかに注意を喚起する必要がありますが、どのアカウントをフォローすればよいのかさえ知らない人が、その作業の一部を自分のために行わなければならないのと同様です。

ジャック: ああ、いい思い出だね。いくつかの会話の中で、現時点では検閲への抵抗と分散化に魅力を感じていない人々を惹きつけていないため、この可能性があると考えられるほどのユーザー数を獲得できないのではないかという話が出てきました。そしてそれは実際には問題ありません。意図的でゆっくりとした道が、最終的には最後まで続くのです。そして、私たちはこの時間をかけて、人々にとって本当に正しいものを理解して学び、永続的で、これから来るすべての敵に対して回復力のあるものを確実に提供できるようにすることができます。そして、それを急ぎすぎようとすればするほど、それらの問題は私たちから隠される可能性が高くなります。残念ながら、そうではありません、ご存知のとおり、私たちにはそれらを修正する時間がありません。時間どおりに着きます、エドワード。最後に2つだけ質問したいと思います。 Nostr と初期の Twitter について私が最も感謝していることの 1 つは、それがどれほど現実的で、どれほど本物であるかということです。そして、私はあなたとのインタビューをすべて見たと思います。あまり聞いたことがないのですが、最初の質問は、あなたの人生がどのようなものなのか、一日のこと、現在の一日に喜びをもたらすような細かいことについてあまり聞いたことがないということです。それから 2 番目の質問は、これに関連するものですが、家での詳細は何ですか?しかし、2番目の質問のように、あなたを家に連れ戻すために、私たちが個人として集団として何かできることはありますか？

エドワード: ありがとう。 2番目については、より安定した政府ができるまでは本当にそうなのかわかりません。つまり、バイデン政権は事実上オバマ政権だ。彼らは全員残留者であり、以前そこにいた人々であり、そして彼らはあなたが期待しない方法で本当に筋金入りのイデオローグです。これは人々が実際にトランプ政権について語った方法でしたが、率直に言って、トランプ政権は本当に多くの失態を犯し、無能でした。彼らが共通のイデオロギーを持っていたかどうかは明らかではありません。そこにはジョン・ボルトンのような完全に狂った人々を含む多くのイデオローグがいたが、ご存知のとおり、彼らは共通の統一ビジョンを共有していなかった。実際のところ、それは基本的に、喜んで現れる人が誰であれ、彼らは一日政府のようになろうとしましたが、そのために惨めに失敗しました。バイデン・オバマ政権、彼らは政府がやろうとしていることを長期的にやっている政府職員です、だからゲイリー・ゲンスラーがそこにいるのはわかります、彼らは政府機関を利用し、手続きを利用しています立法する必要すらないルール。彼らはただこう言っているのです、「私たちは世界の運営に干渉するつもりです。私たちは強制されるまで、できる限り法律を作らずに法律を作るつもりです。私たちはあなたたちが法に行くことができることを知っています」自分たちがやっていることは違法であることを知っているので裁判所に訴えるのですが、裁判所がそれを強制できるようになるまでには10年、20年かかります。それを十分に押し戻すことができれば、それは私たちにとって勝利のようなものです。」帰国するということになると、政府がやったことは間違っていたと喜んで認識してくれる人々を集めなければなりません。それについてはすでに裁判所が判決を下しているので、これは興味深いことです。あまり物議を醸す発言であってはなりません。オバマ政権の司法長官エリック・ホルダーでさえ、私のしたことは公共奉仕だと信じていると述べた。彼は私が刑務所に行くべきだと今でも思っていますが、それは公共サービスだと喜んで言います。そしてもちろん、彼は当時司法長官だったという事実により、これらの計画に個人的に関与していましたが、これらの人たちは引退し、これらの人たちは死に、これらの人たちは前に進みますよね？それらは老化し、コンベヤーは継続します。もし私たちが健全で合理的な政府を手に入れれば、それがどのように進むかについて話し合うことができる可能性がありますが、現実的には近い将来にそれが実現するとは思いません。はるかに重要で、はるかに緊急で、はるかに近いのはジュリアン・アサンジの事件です。つまり、この男は長い間、劣悪な刑務所に入れられていたのです。彼は真実、不快な真実、これらの政府にとっては真実ですが、真実を公表したとしてテロリストレベルの拘留を受けています。そしてこれはまさに、米国だけでなく西側諸国全体における私たちの社会に対する告発です。これが間違っていることは誰もが理解していますが、誰もそれについて何もしません。そして実際、これを変える発言力を持っている大手のレガシーメディア機関の多くは、ほとんど沈黙している。彼らの名誉のために言っておきますが、彼らはそれをやるべきではないと言いましたが、彼らは扇動しているわけではありません。彼らは政治的な影響を懸念しているため、これを続けていません。彼らは皆、理論的にはドナルド・トランプの再来を心配しているので、国務長官トニー・ブリンケンがこう言ったとき、率直に言ってバイデン政権の偽善を非難するようなことは何もしないだろう。エジプトを好きにしたり、偽善を暴露したりするのはひどい言論の自由です、真実を報道するジャーナリストを弾圧しないでください。そして、例えば、この声明を発表するとき、彼はジュリアン・アサンジの縛られた体の上に演台として立っていますが、それについては誰も何も言いません。それはひどいことだ。したがって、そこには何らかのつながりが必要です。

そして、そうですね、私はインタビューで自分の私生活については話しません。それは実際、私がプライバシー擁護者として常にそうしてきたことなのです。でも、私が言いたいのは、私は親になったということです、ボーイ。この2年半は本当に本当に大変でした。それが私のツイート頻度が下がったもう一つの理由です。以前はとても自由な時間がありました。今は何も持っていません。しかし、価値がないと言っているわけではありません。私は再び書き始めようとしています。また制作を始めようと思っています。それはゆっくりです、そして、ご存知のとおり、私の子供たちはこの年齢で長く続くだけなので、大丈夫です。私はそれを憤慨しているわけではありません。後悔はしていません。素晴らしいです。しかし、素敵な瞬間は毎晩あります。長男、私は彼に本を読んで寝てもらいました。今、私はアダム・スミスの『国富論』を読んでいます。彼はファンではありません。彼は本当はくまのプーさんの方が好きなのですが、私はそれを変えようとしています。私は彼に『不思議の国のアリス』を読んだ。私は彼に児童書をたくさん読んでもらいました。私はヘンリー・デイヴィッド・ソローの『市民的不服従』を読みました。私は彼の言葉を全部読みました。短かったので彼はそれほど気にしませんでした。私がそれを Nostr に載せたとき、それは私が息子にそれを読み聞かせていたからで、引用文を再認識したからです。人々が読書の提案を探している場合、あまり馴染みがなく、ありふれたものではありますが、非常に興味深いものです。これはエティエンヌ・ド・ラ・ボエティによる「自発的隷属に関する談話」と呼ばれるものだと思います。これはタイプするのが不可能のようですが、「自発的隷属に関する談話」だけを探してみると、ノストラの精神に非常に一致していると思います。皆さんもチェックしてみてください。これもそのうちの 1 つです。実際にはかなり短いので、『国富論』のように読み進めるのは難しくありません。でも、そうですね、何が私に喜びをもたらすかと問われれば、それは子供たちの成長を見ることができるという事実です。彼らは、音を出すだけの小さなジャガイモから、行動的で、意見が合わない推論をする思考存在になりました。なんとまあ、私の子供たちはとても従順ではありませんが、ご存知のとおり、それは遺伝子の中にあると思います、そしてそれは何も悪いことではありません。それは大好きです;私は必要な範囲で規律主義者、権威主義者になることを学ばなければなりません。

しかし、これは私たち全員が実際に直面する必要があることであり、この聴衆にとっては非常に重要なことだと思います。なぜなら、ジャックや私のような一定の年齢の人たちにとって、インターネットを理解していれば、それがどのように組み合わされるのかを理解していれば、プロトコルを理解していれば、テクノロジーを理解していれば、インターフェースを理解していれば、ゴイを理解していれば、プログラムが何であるかは分からないが、それを手に取ることができれば、あなたはあなたはそれを理解することができます、あなたはそれを理解することができます、あなたは知っている、おそらくそれを作ることさえできます、あなたは平均ではありません。これらのシステムを初めて体験し、日々成長している子供たちがいることを覚えておく必要があります。彼らは自分たちがどのように機能するのか知りません。現在、高校を卒業しているほとんどの人でさえ、コンピューターを使用していません。彼らは電話を使います。彼らは電話がどのように機能するのか知りません。彼らは App Store に行くことを知っています。彼らは App Store にアプリを要求します。彼らはアプリをインストールします。このアプリにはチュートリアルのスワイプが 3 つあり、それだけです。残りは魔法です。これらのアプリの使い方だけでなく、それらを制御する方法も理解してもらう必要があると思います。システムを構築するとき、プロトコルを構築するときは、それらがアクセス可能であることを確認する必要があります。ビットコインであれイーサリアムであれ、より広範な暗号通貨に関して私が心配していることの 1 つは、難解なものを受け入れようとする衝動のようなものがあるのではないかということです。そこでは、これらすべての改善プロトコルなどがあって、彼らはすべてを思いつきます。これらの新しい名前や新しい用語は、学術読者向けの学術論文のように書き始めており、アクセスしやすくはありません。つまり、新しい聖職者を生み出すことになります。あなたは新しい神権を創造しています。新しい特別なクラスを作成しています。そして、私たちが望んでいないのは、専門機関の間で専門家の会話があり、それがすべてロビイストと利害関係者であり、一般の人は自分自身が専門家にならない限り、これを理解することさえ想像できないという昔の問題を再現することです。私たちは、一般の人々がこれを見て、それがどのように機能するかを理解できるようにしたいと考えています。リレーやノードの移動などの接続を理解できるようにしたいと考えています。かわいい小さな地図かそのようなもの、アニメーション、インフォグラフィックか、何が起こっているかを表示するだけのものがあるだけで、人々がそれを見ることができます。これは、自分の子供たちを見て、自分の人生の今後数年間をどのように過ごすかについて考えるときに思うことの一つです。人々にそれを説明するには、世界中でもっと教育が必要です。デバイス、システムの仕組み、私たちが依存している私たちを取り囲むネットワークの仕組み、それらがどのように機能するか、どのように相互作用するか、どのように制御できるか、ドライな状態にならずにどのように指示できるか。プログラミングのチュートリアルとか。そのような象徴的な理解が欠けています。それはギャップです。私たちには知っている人もいますし、知らない人もいます。ご存知のとおり、ノストラという名前は、グノーシス主義とグノーシス主義のようなものです。明らかにされた真実を持っている人とそうでない人がいます。しかし、それは理想ではありません。物事を良くしたいのであれば、宗教を作る必要はありません。私たちは科学を創造する必要があり、それは私たち全員が参加できる市民科学者の時代に近いものである必要があります。それでは、皆さんに感謝の意を表したいと思います。ジャック、招待してくれてありがとう。これは素晴らしかったです。このコミュニティ、報道の自由財団、そしてあなた個人に対する、率直に言って、先ほども言ったように、ただリラックスしているだけではなく、ただそこに留まり、状況を改善しようとしてくれたことに対する皆さんのサポートに本当に感謝しています。このコミュニティに参加し、インターネットが進む方向や政治が進む方向を理解している多くの人々にとって、この時期はかなり憂鬱な時期だったと思います。彼らはこの重力が起こっているのを見ていて、あなたのような人が私たちの側にいることは避けられないと感じています。それは背筋を引き締め、私たちに希望を与えてくれると思います。ですから、皆さんが私たちのためにここにいて、私たちと一緒にこの問題に参加してくれることを願っています。そして、私たちが本当により良いシステムとより良い世界への道を一緒に導くことができることを願っています。ありがとう。

ジャック: そうします。私たち Nostr はハグが大好きです。今日は物理的にハグをすることはできませんが、将来はそうするでしょう。しかしそれまでの間、皆さんにお願いしたいのは、自分が選んだクライアントとデバイスを取り出して、投稿やメモを通じてスノーデンにハグを送ってほしいということです。私たちの賞賛と愛と感謝の気持ちを感じていただければ幸いです。あなたのために。またお会いできることを楽しみにしています。ありがとう。

エドワード: 本当に感謝しています。素晴らしいです。私達はします。ありがとう。皆さん、ありがとうございました。

---

About YakiHonne:

YakiHonne is a Nostr-based decentralized content media protocol, which supports free curation, creation, publishing, and reporting by various media. Try YakiHonne.com Now!

Follow us

• Telegram: http://t.me/YakiHonne_Daily_Featured
• Twitter: @YakiHonne
• Nostr pubkey: npub1yzvxlwp7wawed5vgefwfmugvumtp8c8t0etk3g8sky4n0ndvyxesnxrf8q
• Facebook Profile: https://www.facebook.com/profile.php?id=61551715056704
• Facebook Page: https://www.facebook.com/profile.php?id=61552076811240
• Facebook Group: https://www.facebook.com/groups/720824539860115
• Youtube: https://www.youtube.com/channel/UCyjDDtWFCntGvf4EyFJ7BlA

@ 97c70a44:ad98e322

As everyone knows by now, I am working on adding private groups to Coracle using the new NIP-44 encryption standard currently being audited. I wanted to share why I think this is a viable approach, and how combining relays and encryption can help make it happen.

This discussion gets complicated very quickly, so to begin, I thought I'd cover the two components that everyone thinks they understand first (relays and encryption), and move on to the one that combines the existing primitives in new and exciting ways (groups).

What even are relays, anyway?

If you saw my talk at Nostrasia, this section is just a re-iteration of it. In fact, I wrote this blog post before the conference to help me with my presentation. So hello, from the past.

Relays are dumb. They're just servers, which speak a particular protocol, and which implement some minimal logic to support that protocol. Relays have to be interoperable, which is why it's important to design new parts of the nostr protocol in such a way as to be backwards-compatible, and simple to implement.

As a result, relay development has historically focused on performance to the exclusion of new functionality. You can see this with the success of strfry and Will's adaptation of the underlying technique to nostrdb.

One of my favorite programming talks is Simple Made Easy by Rich Hickey, the author of Clojure. One of the points he makes in that talk is that object-oriented programming is such a mess because it "complects" behavior and state. Hickey's solution to this problem is to use functions and values rather than methods and state.

I think that this same mistake is one we are at risk of making with nostr relays. I'll come back to this in a bit, but keep that distinction in the back of your mind: separating data and behavior can lead to a much simpler and more robust system.

Despite the emphasis on interoperability, relays shouldn't all be exact clones. There are a few different ways relays can differentiate themselves, either by providing specific functionality, by storing different sets of events, or by exposing a different interface.

Added functionality

Some implementations have pushed features forward, for example rbr.bio which implemented the COUNT verb from NIP 45 early on. However, these efforts are usually either supported by special clients (like nostr.band or primal's caching service), or fail to gain wide adoption and are eventually abandoned. The result is that NIPs specifying optional functionality tend to die without sufficient user demand.

The reason for this is that if you're building a client that selects relays based on user preferences, it can't rely on functionality that doesn't exist on the majority of relays. Without widespread support, search results or feeds requested based on Primal's special syntax will be incomplete or fail entirely. As a result, clients often build proprietary solutions to these problems, increasing centralization risk.

Subtracted functionality

Relays are able to helpfully differentiate themselves however, by offering a subset of protocol functionality. For example, purplepag.es is a reliable source for profile data and relay preferences, but it doesn't require clients to do anything different in order to be useful. Instead, users can simply add purplepag.es to their relay list and instantly get a better experience. A similar approach many commodity relays take is blocking certain event kinds, for example 1059 gift wraps or NIP 94 image headers. This fortifies their particular purpose, which is to not support more exotic protocol features.

Other kinds of relays don't support this guarantee, for example relay.noswhere.com only supports search if the search term is not accompanied by a filter, responding to standard requests with "filters: not planned (non-search queries)". This can still be useful, but it is not a relay, because it requires clients to special case how it's used.

Data relevance

There is a different kind of differentiation relays can implement, based not on functionality, but on content. This is what I mean when I talk about "relay de-commodification". The value proposition this type of relay offers is not "we can do something no one else does", but "we have the information you're looking for".

There are two ways to accomplish this: content curation and access controls. The difference being that content curation is context-independent, and might be based on topic, keyword, or LLM analysis, while access controls only accepts content published by certain accounts. Several relay implementations and hosting providers (for example relay.tools) support both of these approaches, and of course it's easy to combine them.

Likewise, there are two ways for a relay to gain access to the desired data, leading to two different value propositions.

A relay that focuses on topical data might scrape the wider nostr network in order to ensure it is able to reliably serve everything relevant to its niche. This might be done using any number of heuristics, including filtering by pubkey, topic, or sentiment, but in any case the relay is not intended primarily to be written to, but to be read from. This is primarily an additive model, focusing on offering a complete view of the given topic.

Another approach is to let the data come to you instead of scraping it from the wider network by only accepting events published by certain people, or being the go-to relay for a certain topic. In order for this model to work though, there needs to be some way for the relay to keep this data to itself by preventing scraper-powered relays from harvesting its data. This effectively means that these relays will not only have policies for who can write to them, but also who can read from them. These might be the same set of people (for example with a community relay), or more people might be allowed to read from the relay than are able to write to it, as in the case of content producers who want a paywalled private social media enclave.

Keep relays weird

Most relay implementations expose their data over websockets in line with the spec, but this isn't actually inherent to the function of a relay. We've already seen several projects implement relays in-app for caching purposes. These relays don't usually go through the ceremony of spec adherence, but some (e.g. nostrdb) do.

Different transport mechanisms and hosting options are possible for relays, and would only require clients to use a specific adapter to get at them. Some examples:

• A relay running on your phone as a service that other nostr clients can share to reduce data storage requirements
• A relay running on a LAN, only accessible from a particular location
• A relay running via any other transport, for example radio or carrier pigeon

The idea I'm trying to get across here is that relays aren't necessarily websocket servers. More abstractly, they are a name attached to a set of events that can be accessed in a standard way.

So, what are relays?

To recap, here's my definition of a relay:

1. They correctly support standard functionality
2. They should only support additional functionality related to curating their data set
3. They may restrict the data types they accept and serve
4. They may restrict the data they accept and serve based on content or pubkey

One additional feature that isn't currently standard but ought to be is strfry's negentropy synchronization feature. This is the opposite of AUTH, which protects a relay's own dataset, in that it allows relays to more efficiently share their data with peers. A nice bonus is that it also allows clients to use their local cache more effectively as well.

Simple Made Easy

Going back to Rich Hickey's talk, separating behavior and state allows you to work directly with your data, freely implementing new behavior whenever you need to. This applies to sets of events stored on relays just as much as it applies to in-memory data.

One thing that makes this possible is cryptographic hash functions, which cleanly transform state into values - the difference being that "state" couples a name with data that may change, while a hash is a compact representation of immutable data. If two hashes of event ids don't match, they're not the same set of events.

How does this apply to relays? Instead of adding new behavior to relays directly ("methods"), we can instead call "functions" on a relay's data.

This function can be anything - a centralized server, client code, or a DVM - that takes REQ filters as input. The function gathers the needed data (maybe from a cache, maybe using a sync command, maybe from multiple relays for completeness), performs the transformation, and returns it. The result is that relays become simple, interoperable repositories for data, without limiting what server-side computation can be applied to events.

While huge search indexes and centralized servers have a cost in terms of centralization, I think DVMs solve this problem brilliantly - the common interface for this augmented behavior is open, and can admit anyone who wants to start competing for search, counting, recommendations, or anything else you might want to do with events.

As Alan Perlis said, "It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures."

Encrypted Messages

Nostr DMs were a huge mistake, and I want to do it again.

NIP 04 has some obvious problems, most notably metadata leakage. The cryptography also hasn't been audited, and has some potential theoretical attack vectors. I've been working with some other nostr devs on a new cryptographic primitive, which will be audited and hopefully result in a better foundation for future work.

But fixing the cryptography still doesn't fix DMs. Nostr is not really the right architecture for secure private messaging, because ratchets require state. Nostr is designed such that there are no hard dependencies between events, which are replicated across multiple relays. This makes it very hard to manage the kind of state that protocols like SimpleX or Signal require.

Even apart from the difficulty of implementing stateful messaging protocols on nostr, we have two other problems to contend with: metadata leaks and spotty deliverability. Both of these problems come from the reliance of nostr on relays, which generally are not trustworthy or reliable.

Metadata Leakage

NIP 04 is really bad. Anyone can see who you corresponded with, when, how frequently, and how much you said just by looking at the event. Vitor's NIP 24 chat proposal aims to fix this with gift wraps, which use ephemeral keys to obscure the sender, padding to obscure message size, timestamp randomization to obscure timing, and double-wrapping to prevent leakage of the signed message.

This is a big improvement, but there are other forms of metadata that are still visible. To start, the recipient is still visible, along with how many messages they have received and their general size. So you can tell if someone sends lots of messages, or not a lot, but that's about it.

If we don't assume relays are trustworthy though, there are all kinds of implicit metadata that can be used to infer information about the sender, including:

• Client fingerprinting
• Relay selection for publishing and queries
• IP address collection
• First seen timestamp
• Identification of users by AUTH
• Correlation of the event with other messages sent/received during a session

These issues are much harder to solve, because they are part of the process of delivering the message, rather than just constructing it.

Transport and deliverability

The key feature of nostr that makes it work is relays. Relays provide storage redundancy and heterogeneity of purpose with a common interface shared by all instances. This is great for censorship resistance, but everything comes with a tradeoff.

Completeness and consistency are not guaranteed on nostr. This is ok in a social media context, because there's no way to keep up with everything everyone you follow says anyway, and you can rely on interactions and algorithmic tools to catch you up on anything important you missed.

But with private messages, every payload counts. Receiving messages out of order, with a delay, or not at all can severely disrupt conversations between two people, leading to misunderstandings and worse. This is a common experience on nostr; even fiatjaf has expressed skepticism about the viability of private messages on nostr.

This flakiness comes from a combination of low relay quality and poor relay selection on the part of clients. Relays can't deliver messages if they can't keep up with clients, go offline, or drop messages (accidentally or deliberately). Likewise, clients can't find messages if they look for them in the wrong place.

Relays fixes this

Let me just put things into perspective really quick. Twitter DMs are not e2e encrypted, and weren't encrypted at all until earlier this year. Mastodon messages are not encrypted - instance admins can read everything. Facebook has e2ee messages, but only between normal users, not in communities, groups, business chats, or marketplace chats.

So while nostr's architecture is not sufficient to make secure encrypted communication a value proposition of the protocol in itself, there is a lot we can do to improve on the status quo. Because nostr has no admins, the only option for privacy of any kind is end-to-end encryption. Metadata leakage notwithstanding, nostr messages can be "good enough" for some definition of that phrase.

It's important to not just punt on making DMs available in a standard way, because there is an expectation that a complete social media solution will have a way to establish a private communication channel with someone else in the network. Otherwise you're stuck with public correspondence and link sharing in order to hop to another protocol.

Let's just assume that you agree with me at this point, and that until there is a javascript SDK for SimpleX or MLS, we're stuck with nostr DMs of some kind. So how can we reduce metadata leakage and improve deliverability?

Fixing Flakiness

Let's start with deliverability first. NIP 65's inbox/outbox model is great. While it doesn't fix deliverability on its own, if every relay recommended was in fact reliable, and reliably followed by clients, there would be a very clear indication of where a particular user's messages could be found. Neither of these things is really true right now, but I do think clients are moving in this direction. Hopefully we can educate users better on how to pick good relays.

There are some limits to this model of course. For example, if you want to read notes from 1000 pubkeys at once, your client will likely end up connecting to hundreds of relays unless it has a cap, in which case it will miss a lot of notes.

One clean solution to this problem is relay proxies. There are a few implementations, but the one I run at mux.coracle.social is a stateless proxy that uses a wrapper protocol so clients can still select and dispatch to relays. I originally built this to improve mobile data use by deduplicating events on the server, and it does that pretty well, although it currently does it in the most naive way possible.

Multiplextr currently does not qualify as a "real" relay based on my four rules, since it uses a wrapper protocol. However, a smarter implementation would be able to route requests and events effectively by relying on client authentication and filter analysis, without changing the protocol. This would also allow clients to completely offload the complex business of relay selection to its proxy. Clients would also be able to combine multiple proxies just like they combine relays - because proxies are relays!

Proxying Privacy

Another downside of NIP 65 is that it encourages clients to connect indiscriminately to hundreds of different relays based on tag hints, other users' preferences, and relays baked into bech32 identifiers. This is not only bad for battery life and performance, but also allows attackers to easily trick your client into to connecting to their relay so they can start analyzing your traffic.

The best way to defend yourself against nosy relays is to not connect to them at all. And the easiest way to do that is to only connect to relays you control (or trust), and let them do the dirty work for you.

With a proxy, even if you don't control it, you can reduce the number of parties who can snoop on your traffic by orders of magnitude. And since other people use the proxy too, your traffic gets mixed with theirs, making it much harder to analyze. Of course, the downside of using a public proxy is that the proxy sees all messages you send and receive, and the relays you select for each request. Even worse, an untrusted multiplexer can hijack an authenticated session, exfiltrating private data from protected relays.

A proxy you control (or trust, either via social relationships or economic ones) is the best of both worlds. This proxy could also do some smart things for you to improve privacy as well, for example:

• Delayed publishing of gift wrapped messages so relays can't guess as easily when the event was first seen.
• Closing and re-opening connections to reduce the number of messages sent over an AUTH'd session.
• It could block suspicious messages on the fly, for example spam or notes with phishing links.
• If an abundance of options are available for relay selections, it could randomize which relays are used, or avoid using less reputable ones.

So I guess what I'm saying here, is "run a node". But not just any node - in the early days of nostr there were a lot of people spinning up relays because they thought it helped decentralization. Well, as it turns out, just like in bitcoin you have to use your node in order for it to be useful.

Beyond DMs

I'm not done yet, though. What's the point of all this? Why put all this effort into "good enough" DMs when we could spend the effort adopting SimpleX or MLS (said Semisol, who lives rent free in my head)?

Well, because there isn't a single "best" DM option. As I've dug into the topic, I've discovered that a ton of tradeoffs exist between complexity, privacy, and scale. The way I understand it, there are three basic options here:

• One-to-one encryption. This is how both SimpleX and Vitor's group message draft works. It allows for things like ratchets to be added on top, and is fairly simple - but fails to scale because every message has to be encrypted separately for every group member, resulting in n*m messages, where n is the number of group members, and m is the number of messages sent.
• Encryption via shared key. This is how WhatsApp works, and it scales really well because messages don't have to be duplicated. And while it does support forward secrecy, it does not support post-compromise security, so it is significantly less secure.
• MLS has a unique hierarchical approach to managing keys, which improves the complexity of one-to-one encryption so that it's logarithmic rather than exponential. However, MLS is highly stateful and still has scaling limitations.

My takeaway is that there is no perfect solution. Ratchets are the gold standard, but can't really be implemented using nostr relays, since they frequently require servers to have very specific characteristics, like the ability to deliver messages in order.

The fact remains though, that social media needs encrypted messaging of some kind, even if we encourage users to bail to a more complete solution if they want to be truly private. And encryption is useful beyond small group chats - think of Facebook groups, which scale to millions of people and whose users have a much lower expectation of privacy. This is what nostr is good at - social data, whether encrypted or in plaintext.

Belt and Suspenders

For a long time I have waffled between two visions of how private groups ought to work. Should they be encrypted messages sprinkled across the nostr network like confetti? Or should they live on one or two relays in plaintext, protected by AUTH?

Both of these options have issues. Sprinkling encrypted messages across the network almost guarantees deliverability problems, since already many commodity relays block gift wraps. And that's ok! They have no obligation to store your encrypted messages.

Storing group messages in plaintext is also sub-optimal, even if it's on a dedicated relay. Of course we're not going for military-grade secrecy here, but it would be trivially easy through a bug, or even a client that doesn't know how to deal with groups, to re-broadcast events that should stay private. We could do something wacky, like strip the signature from events hosted on a relay, but if we're going to do something non-standard, we might as well do the best we can.

So why not both? Group messages should be encrypted, and they should be stored on a particular set of relays. Again, assuming the relays used are trustworthy, this fixes both privacy and deliverability problems, because it's very clear where messages posted to the group should go.

Promoting relays to trusted status has some nice, unintended benefits too. One common objection to using encrypted content is that it becomes hard to filter. But if a relay is trusted to store a group's messages, it can also be trusted to be admitted as a member to the group. This would allow the relay to decrypt events and filter them to respond to requests by authenticated group members.

Of course, this would violate rule #1 for relays, since they would no longer be supporting standard functionality, but a guy can dream, can't he?

Conclusion

When I started working on nostr I had no idea it would end up being this complex to accomplish what I set out to do. Building a twitter clone was only a first step to an MVP, but I always had my eye on the prize of serving my local church community, which doesn't give a sat about social media per se.

Private groups are important to me not because I'm setting out to support political dissidents or journalists (although I hope they find nostr useful too), but because I want to get my friends off of Facebook, and the only way to do that is to create private marketplaces, calendars, communties, and more.

@ 2d417bce:f56911ac

Nostrで自分または共同で開発したものを時系列順でまとめたものです。

作ったもの

nostr-rorubakku

GitHub

NostrのFollowingリストが飛ぶ問題を解決するために、GitでFollowingリストのイベントを管理しようというプロジェクトです。

Gitの使い方として合ってるのかも怪しい仕組みですが、Nostr日本語界隈は当時この問題の解決策を模索していた時期だったのもあり、盛んに議論や開発が行われていたを覚えています。(2023年11月現在で、この時からもう9ヶ月以上経過していることに驚いている…)

Nothello( nostr-revers)

GitHub

Nostrのリレー上でリバーシができるWebアプリです。現在はリレーサーバーの維持コストの都合でサービスを一時停止しています。

当時、Nostrには娯楽が少ない（今でもそうかもしれない…）という話題が出ていました。「クライアントの開発は面倒だけど、ゲームなら作れるかも」という考えから始めたこのプロジェクトでは、初期にいくつかの大きなバグがあり、リリース後しばらくはその修正に追われていました…。

これははじめて自分が、誰でも使えるWebアプリとしてリリースしたプロダクトで、今でもたまに話題に上げてくださる方がいるプロジェクトです。ありがたい…🙏

login-with-nostr-app

GitHub

NIP-98のテストプロジェクトとして作ったものです。

ブロックチェーン系の開発をしていた時に、最も興味があった分野が分散型ID（DID）でした。Nostrをそのようなソリューションとして使用できることを実感し、Nostrが秘めるプロトコルとしての可能性にワクワクしました。

nostr-icon-changer

GitHub

特定の単語を投稿したら、kind: 0イベントのアイコンを一定期間変えるというジョークプログラムです。実際に稼働していたのは1日だけでしたが、少しだけ話題になったので満足しています。

Hostr(nostr-webhost)

Web

GitHub

Nostr上でSPAサイトをホスティングができるCLIツールです。

国内外の方に認知・使っていただけるように、LPを作ってみたり、コードをかなり丁寧に書いてみるなど、さまざまな試行錯誤をしたおかげか、fiatjafさんやVitorさんをはじめとした多くの開発者の方からコメントをいただいたり、実際にいくつものサイトが立ち上がったりと、個人で開発したプロジェクトの中では、現状で一番規模の大きいものになりました。

また、Hostrの仕様をNIPsに採用してもらうために、PRを出してみたり、Nostrasia Hackathonに出場してみたりと、初めて経験することばかりでとても楽しかったです。

Hostr Note

GitHub

Hostrをプログラマー以外の方でも使えるようにとつくったWebアプリです。

Nostter

Web

雪猫さんが作られている、NostrのウェブクライアントのUIデザインと実装をさせていただきました。

最近正式版(v1)がリリースされ、Nostr以外にX上でも話題になったようで、多くの方に使われるクライアントになりつつあり、プロジェクトに関わらせていただいた身としてはとても嬉しいです！

個性がありつつもシンプルで、初めてNostrを使う方から、既に様々なクライアントを使っている方まで、どんな方でも満足して使っていただけるようなクライアントになっていると思います！

N Raw Writer

Web

NostrイベントをJSON形式で作成し、NIP-07拡張機能で署名して、リレーにpublishできるツールです。

開発中のもの

NostrCMS

GitHub

Nostr上で動作するWordPressのようなCMSで、Nostr上のLong Form ContentとHostrサイトを一括で管理できます。

ノーコードでLong Form Contentが参照可能なHostrサイトをデプロイでき、パブリックなNoSQLデータベースを構築するなど、CMSの枠を超えた、Nostrを活用したスーパーアプリ開発の基盤にしたいと考えています。

Nostinder

名前の通り、Nostrを使用したマッチングアプリです。ジョークアプリとして空いた時間に少しずつ開発していますが、思いの外本格的なアプリになりそうで、「どうしようかな…」と少し困惑しています。

さいごに

こう見返してみると、Nostrの技術的な面白さに加え、コミュニティとの相互作用の重要性も再認識させられます。

実際、多くの方からリアクションやフィードバックをいただき、それを励みにしながら開発を進めてきたのもあり、このコミュニティがなければ、ここまで様々なプロジェクトを作ることはできませんでした。

これからも開発を続けて、Nostrコミュニティやエコシステムに少しでも貢献することができれば嬉しいなと思っています。

最後まで読んでいただきありがとうございました！

@ cc33d933:0347fdcc

Day 1, Yang - Main Stage

| Video | Speaker | | --- | --- | | Opening Remarks | nostr:npub16vrkgd28wq6n0h77lqgu8h4fdu0eapxgyj0zqq6ngfvjf2vs3nuq5mp2va | | Marketing on Nostr | nostr:npub1h50pnxqw9jg7dhr906fvy4mze2yzawf895jhnc3p7qmljdugm6gsrurqev nostr:npub17plqkxhsv66g8quxxc9p5t9mxazzn20m426exqnl8lxnh5a4cdns7jezx0 | | The Carribean | nostr:npub1qqqqqq0u2gj96tdfvqymdqn739k4s0h9rzdwyegfmalv28j7a5ssh5ntu2 | | The Future of Nostr | nostr:npub1j8y6tcdfw3q3f3h794s6un0gyc5742s0k5h5s2yqj0r70cpklqeqjavrvg nostr:npub1c878wu04lfqcl5avfy3p5x83ndpvedaxv0dg7pxthakq3jqdyzcs2n8avm | | Nostr Discoverability Doesn’t Suck | nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft | https://youtu.be/gOIZMMvHSZw?t=7992 | | Satslink Project Announcement | nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 | | HRF Nostr Funding | nostr:npub1szpa7cypmyd59083qs3pte9lez22lzfu6pl2guhgqx7q09x68y6qquh3td | | Client Censorship & Paths Forward | nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 nostr:npub16c0nh3dnadzqpm76uctf5hqhe2lny344zsmpm6feee9p5rdxaa9q586nvr | | Nostr for Normies | nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240 | | Nostr in Japanese Communities | kojira nostr:npub147ccm75um0zkn0lr9fg9wrag2g6yxfw234fpmhdwuvaqjyegrhgs46t2td nostr:npub1pjd3a8l0wmygkclcvezacvamwamlqfv7cs0xwjmp7n7920mdkrsq9hpeqp | | Nostr for Content Creators | nostr:npub107jk7htfv243u0x5ynn43scq9wrxtaasmrwwa8lfu2ydwag6cx2quqncxg | | How Nostr Wins | nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft | | Closing Remarks, Day 1 | nostr:npub16vrkgd28wq6n0h77lqgu8h4fdu0eapxgyj0zqq6ngfvjf2vs3nuq5mp2va |

Day 1, Yin - Workshop Stage

| Video | Speaker | | --- | --- | | Opening Remarks - not available | nostr:npub16vrkgd28wq6n0h77lqgu8h4fdu0eapxgyj0zqq6ngfvjf2vs3nuq5mp2va | | Nostr Hardware - not available | nostr:npub1matmfxr293jejewrm72u50l2x5e6ypasn0ev2kns6srv05zfzf8s0z6fsr | | Building the other Stuff - not available | nostr:npub1alpha9l6f7kk08jxfdaxrpqqnd7vwcz6e6cvtattgexjhxr2vrcqk86dsn | | Everyone is a Designer - How to contribute to grow Nostr | nostr:npub1uapy44zhu5f0markfftt7m2z3gr2zwssq6h3lw8qlce0d5pjvhrs3q9pmv) | | Pair-Programming Nostr | nostr:npub15f3wjlgdpgz7rfs3kqqmarm3z63jcqq8xnrvt6py5jyzmhwru6tqrcqrap nostr:npub1afne208f0mlwl9aktfkss0xs6zd7ga6w4e5hx3dh3lg24vfl8ddswzqdtu | | How to Contribute to Nostr Code | nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc | | Nostr 101 App Review | nostr:npub1nxy4qpqnld6kmpphjykvx2lqwvxmuxluddwjamm4nc29ds3elyzsm5avr7 | | Keep the Nostr Weird | nostr:npub1a7n2h5y3gt90y00mwrknhx74fyzzjqw25ehkscje58x9tfyhqd5snyvfnu nostr:npub1t3ggcd843pnwcu6p4tcsesd02t5jx2aelpvusypu5hk0925nhauqjjl5g4 | | Nsec Bunker | nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc| | Nostr, the Missing Part of Decentralization | nostr:npub1dww6jgxykmkt7tqjqx985tg58dxlm7v83sa743578xa4j7zpe3hql6pdnf | | Building a Bitcoin-Based Civilization with Other Stuff | nostr:npub1mygerccwqpzyh9pvp6pv44rskv40zutkfs38t0hqhkvnwlhagp6s3psn5p nostr:npub1arkn0xxxll4llgy9qxkrncn3vc4l69s0dz8ef3zadykcwe7ax3dqrrh43w | | Build Your Own Relay | nostr:npub1g5pm4gf8hh7skp2rsnw9h2pvkr32sdnuhkcx9yte7qxmrg6v4txqqudjqv | | Unlocking Economic Opportinities - not held | | | H.O.R.N.E.T. Sorage: Multimedia Nostr Relays | nostr:npub1t89vhkp66hz54kga4n635jwqdc977uc2crnuyddx7maznwfrpupqwra5h9 |

@ cd408a69:797e8162

Railway transfer guide app

Japan has many public transportation systems, making it convenient to get around. 🚅 🚃 🚌 But it's also so complicated because there are really so many...especially in Tokyo 😵🌀

The quickest way is to use the Google Maps application to view directions, but there are also other applications for international travelers.

Japan Travel by NAVITIME

NAVITIME is also used by many Japanese people as a transit guide app. The app below was created by its developer for foreign tourists. In addition to railway information, they also provide useful information for traveling.

Japan Travel by NAVITIME [ iPhone / Android ]

---

Prepaid IC Cards in Japan

Transportation IC cards are rechargeable cards that can be used to conveniently pay fares on public transportation 🚆

It can be used on many modes of transportation such as trains, subways, and buses. Having one is convenient because you don't have to worry about looking at the fare list every time. And there are also many convenience stores and other shops that you can use for shopping 🏪

Various names are sold by railway companies, but they can all be used interchangeably.

There are also transportation IC cards for foreign tourists. Please check it 🌸

For those arriving at Haneda (HND) and Narita (NRT)

Welcome Suica

PASMO PASSPORT

For those arriving at Kansai International Airport (KIX)

kANSAI ONE PASS

---

Japan Rail Pass

If you want to travel by train in Japan before or after Nostrasia, the Japan Rail Pass is also a great option.

It can be used for long-distance rail travel throughout Japan. There are three types depending on the usage period: 7 days, 14 days, and 21 days.

JAPAN RAIL PASS

---

There are many other famous places in Japan besides Tokyo. Please visit each place and find many good things about Japan. We hope you have a fun time on your trip 🫂💜

@ 7f5c2b4e:a818d75d

What is Obsidian?

Obsidian.md is a versatile and powerful note-taking and knowledge management application that's gained immense popularity among users seeking a robust digital tool for organizing their thoughts, ideas, and information.

Obsidian boasts an array of features and benefits that can't all be covered in a single article. Instead, this #guide focuses on a unique, yet potent use case that has recently emerged - the ability to publish #Nostr notes and long-form posts directly from the app.

This capability has been made feasible through the complementary nature of Obsidian and Nostr. Obsidian is an open-source software with a thriving community and extensive support for custom plugins. On the other hand, Nostr is an open protocol with a rapidly expanding suite of tools, simplifying the integration of Nostr across various corners of the Internet. The plugin I will cover in this guide is called Nostr Writer.

Obsidian link: obsidian://show-plugin?id=nostr-writer

GitHub: https://github.com/jamesmagoo/nostr-writer

Developer: nostr:npub10a8kw2hsevhfycl4yhtg7vzrcpwpu7s6med27juf4lzqpsvy270qrh8zkw

But before we dive in, let me share some thoughts on why should one use Obsidian to publish long-form posts (and potentially even short notes) on Nostr.

Why post with Obsidian?

This is a question that naturally comes to mind: "Why use Obsidian to publish on Nostr when the legendary Nostr developers have already set up all the necessary infrastructure for browser-based publishing?" Well, there are several reasons:

1. Native Markdown Support: To begin, Obsidian employs plain text Markdown formatting for notes, just like all Nostr-based blogging platforms. This makes it an ideal choice for creating, formatting, and editing Nostr posts.

2. Illustrative Preview: While other blogging platforms offer preview tools, Obsidian has perfected this feature. It provides a beautifully customizable preview window that can be positioned anywhere in your workspace, allowing you to visualize how formatting, media, and embeds will appear in the published post[^1].

3. State-of-the-Art Flexibility: Since 2020, Obsidian has continuously improved the way writers interact with it. What sets it apart is not only the dedicated team but also its thriving community, all contributing to its refinement. Obsidian supports an extensive array of plugins, shortcuts, and hotkeys, offering unparalleled flexibility and customization. Comprehensive documentation and a ton of videos and even courses on YouTube provide a wealth of information to tailor Obsidian to your preferences.

4. Boosted Productivity: The Nostr Writer plugin is a game-changer for power users of Obsidian. If you're already using Obsidian for note-taking, employing this tool to publish your notes on Nostr is a no-brainer. If you haven't explored it yet, I strongly recommend giving it a try. It has the potential to transform how you think, plan, and structure your ideas for the better. Trying it for broader objectives will help you appreciate how well it complements Nostr.

5. Distraction-Free Composition: While you may disagree, browsers can be a significant source of distraction, with constant alerts, notifications, and blinking extensions. Composing within Obsidian offers a tranquil, clutter-free experience, fostering focus and productivity.

6. Local Record Keeping: Thanks to Nostr Writer, Obsidian keeps a local record of events you published to Nostr in a JSON file on your computer. Your long-form posts are also securely stored in the .md format on your machine, just like all the Obsidian notes you create. On top of that a separate tab holding all of your long-form posts posted via Obsidian is created.

nostr: note1z70v5fsty7v7kaaslsv3ckru50nxym32a62kgx0z7cjdure39hps363sh7

1. Drafts You Can Count On: Drafts are often a weak point in long-form platforms. Even though Nostr developers have addressed some of these concerns, the "vanishing drafts problem" still lingers. Obsidian, designed with data safety in mind, stores all your notes locally on your device. Whether you open your laptop tomorrow or in a year, your files will be there, safe from external disruptions. For added redundancy, consider using Obsidian Sync, which encrypts and synchronizes your notes across your chosen devices.

While there are more benefits to utilizing Obsidian for both Nostr publishing and in your general workflow, these reasons should provide a solid understanding. Now, let's shed some light on the Nostr Writer plugin.

Nostr Writer

I stumbled upon Obsidian not too long ago, all thanks to nostr:npub1zvvv8fm7w2ngwdyszg3y6zgp6vwqlht8zrr8wcmjaxjecrvpjfwsd0zs7w. He's also the one who introduced me to the Nostr Writer plugin. Until recently, I primarily used Obsidian "as intended" - for documenting my thoughts and writing articles. What I found especially convenient was using it to compose long-form Nostr posts. And then, the revelation came when I discovered the Nostr Writer plugin - it transformed the experience. No more copy-pasting and meticulous adjustments were required; I can simply compose, add a cover image and description, and publish - it's as straightforward as that.

As I mentioned earlier, Obsidian boasts a vast library of community-driven plugins. To begin using Nostr Writer, simply install the plugin from the "Community plugins" section and navigate to the plugin settings to set up your publishing workflow.

You can install the plugin by clicking this link while having Obsidian open on your device, or by going to the "Community plugins" tab in the settings and typing "Nostr" in the search field.

Once the plugin is installed, you'll need to customize it to enable publishing your Obsidian notes to Nostr.

Primarily, you'll need to paste your private key (nsec) into the corresponding field. Additionally, I recommend configuring your relays to ensure the widest reach for your posts. If you're unfamiliar with Nostr relays or wish to enhance your understanding, you can explore my relay guide here.

Many Nostr users naturally have concerns about sharing their private keys with apps. In this case, worry not. Your private key is stored exclusively on your local device and never leaves it. More details can be found here. Even if you use Obsidian sync to keep your notes updated across multiple devices, all information is locally encrypted and safeguarded by the password of your choice. Neither the Obsidian developers nor the plugin developer have access to your files. For additional information, you can refer to the "Security and privacy" section of the Obsidian documentation.

As you can see in the screenshot above, Nostr Writer also provides the option to post short notes. By toggling the corresponding slider, a pencil icon will appear on the sidebar, allowing you to post short notes without leaving Obsidian:

While I wouldn't claim that the plugin surpasses any of the "Twitter-like" Nostr clients, it can prove handy if you're already working within Obsidian and wish to share a quote or any other snippet of information you've come across in your notes.

Publishing

Publishing posts with Nostr Writer is straightforward. If you're already familiar with Obsidian, composing and formatting will be a total breeze, and the actual posting process is no different from posting with Habla, or any other Nostr-native blogging platform.

The only thing that may differ from some Nostr platforms is that Nostr Writer does not provide a specific field for adding hashtags when publishing. Instead, you should incorporate them directly into your text.

Once you've finished crafting your blog post, simply click on the upload icon in the side menu to specify the title, add a summary, and attach a cover image.

When you're ready, click "Confirm and Publish."

Another point to note is the relays indicator in the bottom-left corner. Relay connection may get interrupted if left inactive for a while, but a simple click on the widget will reconnect you to Nostr in no time.

Practice makes perfect

As I mentioned earlier, I find this approach to publishing long-form posts on Nostr the most efficient and convenient. Moreover, there are numerous improvements in the pipeline for the plugin, which is nothing short of exciting.

With that said, it's worth visiting Habla after publishing your post to double-check that everything appears as intended. Initially, you might encounter some formatting peculiarities that you'll need to get accustomed to, but with practice, you'll effortlessly master them. Soon, you won't even have to worry about how the article looks in Nostr clients because you'll be able to visualize every single aspect of your post in your mind.

---

I hope you found this guide useful and consider utilizing Obsidian for both publishing Nostr posts and elevating your overall productivity. If that's the case, please show your support for nostr:npub10a8kw2hsevhfycl4yhtg7vzrcpwpu7s6med27juf4lzqpsvy270qrh8zkw' work.

Please feel free to share your thoughts and suggestions—I'm always eager to hear from you! Don't forget that my Habla blog page contains a ton of Nostr guides, so you can find answers to almost any Nostr-related questions. If there are specific topics you believe I should cover, do let me know.

See you on the other side of the Nostr rabbit hole.

Tony

---

P.S. This post was composed, formatted and published to Nostr from Obsidian. No Nostr-related blogging platform was used.

[^1]: Nostr-native syntax, including tagging and Nostr-events embeds, is an exception here. Not all platforms on the Internet currently support Nostr syntax standards like tagging users with their npub, as in nostr:npub10awzknjg5r5lajnr53438ndcyjylgqsrnrtq5grs495v42qc6awsj45ys7, so it may not be available for preview. However, tags and embeds will be displayed on Habla. You can learn more about Habla's features in my previous guide here.

@ 6e75f797:a8eee74e

It's been a busy month for the ZapStream developers and it's a good time to post a small update on all the new features and toys we've received from nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49, nostr:npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac and nostr:npub107jk7htfv243u0x5ynn43scq9wrxtaasmrwwa8lfu2ydwag6cx2quqncxg (and all the other contributors). So let's get to it.

New stream option!

ZapStream now has three different streaming options for creators. * Basic: 2.5 sat/min offers only source encoding * Good: 10 sats/min offers source, 720, 480 or 240 * Best 21 sats/min offers all of the above encoding plus VOD storage

Widgets & Zap Alerts

Earlier this month the team added the first iteration of widgets to ZapStream. Those can be found at zap.stream/widgets.

To add any of the widgets to your stream simply copy the code above the desired widget and add it to OBS as a browser source. Pro tip: set the browser source to refresh when it becomes active and tick the box to disable the source when it's not showing.

verbiricha also released an update for zap alerts adding TTS (text to speech) to the alerts. TTS currently supports English, German and Spanish.

The setup is pretty straight forward. Enable TTS, set the minimum zap amount to trigger TTS, select language and speaker and then copy the link into a new browser source in OBS. You can also test the alert on the widget page or change the voice volume. Values are 0-1 in 0.1 increments.

NIP-75 for goals

NIP-75 was recently written by verbiricha and is replacing the previous metadata kind event used for zap goals on ZapStream. NIP-75 is now fully implemented in ZapStream. With this creators may now create new goals, reuse previous goals or use long-term goals during their streams.

Goals were also moved to the STREAM settings, accessed from the top-right of website.

To create a new goal simply click on add stream goal.

To reuse a previous goal select your goal from the dropdown menu.

If you'd like to see your previous goals or create a goal with more than one beneficiary head over to vercel.app. There you'll find a list of all your goals.

Settings Page

The settings page is a contribution from nostr:npub1zk6u7mxlflguqteghn8q7xtu47hyerruv6379c36l8lxzzr4x90q0gl6ef and can be accessed by clicking on your profile image on the top-right of the page.

New login design allowing for NIP-07 authentication. In addition ZapStream now also supports authentication via nsec (prompts a warning). WebLN functionality has been added too allowing viewers to zap creators without having to switch apps.

Languages

ZapStream now also supports 17 different display languages. Thanks to a long list of Nostriches who've contributed to the ZapStream translation project.

Check out Kieran's recent note for a full list of all contributors. nostr:note19rxd3shktqad9fv4a6x6dhzj5qwhm899zspjcqn52q5xpl58vwpsd5wupc

Known issues

• popped out chat doesn't display direct GOAL chats
• ALL chat, badges next to user names is currently broken.

Done! :)

This concludes the community update. I hope you'll find it helpful and if you have any question or need help getting setup, don't hesitate to jump into one of my streams or check out the Getting started on ZapStream Guide.

Your fellow Nostrich, nostr:npub1de6l09erjl9r990q7n9ql0rwh8x8n059ht7a267n0q3qe28wua8q20q0sd

@ ec42c765:328c0600

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

@ f40832e2:bcbf511e

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

@ 97c70a44:ad98e322

By an accident of history, I have been knee-deep for the last week or two in several NIPs related to encrypted DMs and group chat. The accident is my proposal for encrypted groups — which will help me turn Coracle into something approximating a replacement for Facebook, rather than Twitter.

In order to make that happen though, a few things need to happen first. I need a better way to encrypt messages without leaking metadata, and (un)fortunately I'm no cryptographer. It's well known that NIP 04 has a number of issues, and there have been several proposals to fix it since as early as October 2022. Building on that foundation would be a waste of time.

My purpose in this post is to outline the problems with NIP 04 as it stands, and sketch out for you some possible solutions applicable not only to DMs, but to other encrypted use cases.

NIP 04 Considered Harmful

It's pretty well-known that nostr DMs leak metadata. What this means is that when you send a DM to someone else, anyone can see:

• Who you are
• Who you sent a message to
• When you sent the message
• How big the message was

And, of course, vice versa. Now, I personally don't take the cyanide pill on this like some do. DMs in centralized social platforms are far less private even than this, since the platform can read them anytime they want, share them with law enforcement, and potentially leak them to the entire world. It's my opinion that if applications were designed with the above properties in mind, it would be possible to gamify DMs, making metadata leakage a feature rather than a bug. Of course, no one has designed such a thing, so maybe it's a moot point.

The much bigger problem, as I learned last week, has to do with the cryptography used in NIP 04 (and several other places, including private mute lists and app-specific data). Here's a quote from Paul Miller's very helpful explanation:

1. Unhashed ECDH exposes some curves to Cheon's attack 1, which allows an attacker to learn private key structure when doing continuous diffie-hellman operations. Hashing converts decisional oracle into a computational oracle, which is harder.
2. CBC IVs should not only be unrepeatable, they must be unpredictable. Predictable IV leads to Chosen Plaintext Attack. There are real exploits.
3. CBC with reused key has 96-bit nonces and loses 6 bits of security for every magnitude. 10**4 (10K) messages would bring archive security of the scheme to 72 bits. 72 bits is very low. For example, BTC has been doing 2^67 hashes/sec as per early 2023. Advanced adversaries have a lot of resources to break the scheme
4. CBC has continuously been exploited by Padding Oracle attack. We can't expect all implementations to have proper padding check
5. AES was modeled as ideal cipher. Ideal ciphers don't care about non-random keys. However, AES is not an ideal cipher. Having a non-IND key, as in NIP4, exposes it to all kinds of unknown attacks, and reducing security of overall scheme

There is a lot going on here, very little of which I (and likely you) understand. But the really horrifying takeaway for me is in items 1 and 3. If you read it carefully, you'll notice that the more times you use your private key to encrypt data using NIP 04's encryption scheme, the easier it is for an attacker to brute-force your key.

I want to be careful not to overstate this — I don't think this means that everyone's private key is compromised; it would require many thousands of signatures to meaningfully reduce the security of your key. But it does mean that NIP 04's days are numbered — and if we don't replace it, we have a real existential threat to the entire protocol on our hands.

So much for motivation to put NIP 04 to rest. Where do we go from here?

The lay of the land

There are a few different components to making private messages work (whether we're talking about DMs or encrypted groups).

• Encryption scheme
• Explicit metadata hiding
• Implicit metadata hiding
• Transport and deliverability
• Identity and key exchange

Each of these components needs to be solved in order to create a robust messaging system on nostr.

Encryption scheme

As mentioned above, NIP 04 is borked. Luckily, there are a few folks in the nostr dev community who know a thing or two about encryption, most notably Paul Miller. Way back in May, Paul proposed a new encryption scheme based on his implementation of XChaCha20, which is the same algorithm used by SMP (more on that below).

To move the proposal forward, I created a different PR with some edits and adjustments, which is very near to being merged. The implementation already exists in nostr-tools, and there are PRs out for nos2x and Alby as well.

Explicit metadata hiding

As mentioned above, normal nostr messages share lots of information publicly, even if the content is encrypted, including:

• Kind
• Created timestamp
• Tags (topics, mentions, recipients, etc)
• Message size
• Author

Private messages have to hide this information, at the very minimum.

Implicit metadata hiding

The above level of security should be enough for most use cases. But it definitely doesn't get us to total secrecy yet. Some additional metadata includes:

• Client fingerprinting
• Relay selection for publishing and queries
• IP address collection
• First seen timestamp
• Identification of users by AUTH
• Correlation of the event with other messages sent/received during a session

These issues are much harder to solve, because they are part of the process of delivering the message, rather than just constructing it. These issues can be mitigated to some extent by using TOR, proxying connections with relays, using short-lived connections, randomizing publish time, and careful selection of trusted relays. But all of these are only techniques to reduce exposure, and require a prescriptive protocol to wrap them all up into a cohesive whole.

Transport and deliverability

In my view, the key feature of nostr that makes it work is relays. Relays provide storage redundancy and heterogeneity of purpose with a common interface shared by all instances. This is great for censorship resistance, but everything comes with a tradeoff.

Publishing notes is sort of like hiding easter eggs. If you want a kid to be able to find an egg, you have to put it somewhere they'll look for it. Putting an egg on the roof does not constitute "hiding" it, at least in a way consistent with the spirit of the game.

Historically, notes have been broadcast to whatever relays the user or client selects, without regard with someone else's preferences, resulting in apparently missing notes when author and recipient don't share a relay.

This problem has been partly solved by NIP 65, which encourages clients to publish notes where the recipient will look for them. There is some guesswork involved in selecting good relays, but the process is fairly straightforward for direct messages and group chats.

The situation can be improved further by DM-specific signaling, like what @fiatjaf has suggested as an addition to NIP 65. A user could then run his own relay that accepts messages from anyone, but only serves messages to himself. This would be the only relay well-behaved clients would ever write encrypted messages to, improving both privacy and deliverability.

Variants of this could also work for encrypted groups. For small groups, the same relay hints could be used as with DMs, and for larger groups with key sharing the admin could set up a dedicated relay for the group which members would write to.

This also creates a potential affordance for querying of encrypted events. If a relay is highly trusted, it could be added as a member to an encrypted group, gaining the ability to decrypt events. It could then receive REQ messages for those events, filter based on the encrypted content, and serve the encrypted version. This could greatly improve performance for larger groups where downloading all events isn't feasible.

Identity and key exchange

One dimension of privacy that deserves its own section is identity and key exchange. In nostr, this is simpler than in other protocols because in nostr your pubkey is your username. Arguably, this is a flaw that will need to be solved at some point, but for now it means that we get to skip a lot of the complexity involved with binding a name to a key.

However, the problem is still relevant, because one effective way to improve privacy is through key exchange. In the case of DMs, it would be nice to be able to request an alias key from someone you want to communicate with in order to hide the only piece of metadata that has to remain on a message in order to deliver it, that is, the recipient.

There's a lot of good stuff about this problem in the Messaging Layer Security protocol. The author of 0xChat has also put together a draft spec for executing simple key exchange, albeit with less information hiding than in the MLS protocol.

Key exchange between individual users can be considered an optional privacy enhancement, but is required for group chat based on a shared key. In either case, exchanging keys is fairly straightforward — the real challenge is achieving forward secrecy.

By default, if at any point a user's private key is compromised, any messages that were retained by an attacker can then be decrypted. This is a major vulnerability, and solving it requires key exchange messages to be reliably discarded.

What's cooking

So that's an overview of the problems that need to be solved for private DMs and group chats. Not all of these problems will be solved right away, just because the bar for creating a decentralized encrypted chat system on par (or better than) Signal is the kind of thing you get venture capital for.

So the question becomes, should we build a sub-par messaging system that is tightly integrated with nostr, or refer users to a better option for encrypted communication?

Well, why did Twitter create its own DM solution rather than integrating email? Was it to harvest user data, or to provide additional utility to their users by allowing the social graph to inform messaging? Native features simply create a better UX.

On the other hand, in Paul Miller's words:

I would like to remind that nostr DMs, if nostr gets a traction, would be used by all kinds of people, including dissidents in dangerous places. Would you be willing to risk someone getting killed just because you want to keep backwards compatibility with bad encryption?

There is no easy answer, but it's clear that as we continue to work on this problem it is very important that applications communicate clearly the privacy implications of all "private" features built on nostr.

So, assuming we can pull off an appropriate balance between privacy and convenience, let me outline three new developments in this area that I'm excited about.

Gift wrap

Way back in April, Kieran proposed a dumb, but effective, way of hiding metadata on DMs. The technique involved simply encrypting a regular nostr event and putting that in another event's content field. The neat thing about this is that not only does this hide some of the most revealing event metadata, it's not tied to a particular event kind — anything can be wrapped.

What this means is that we can build entire "nostr within nostr" sub-networks based on encryption — some between two users, others based on a shared group key. This is much more powerful than a messaging-specific encryption schema. Now we can make private reactions, private calendars, private client recommendations, private reviews. I find this very exciting!

This proposal was further developed by Vitor — the current version can be found here. The latest version introduces double-wrapping, which can help prevent the wrapped event from being leaked by stripping its signature — that "draft" event is encrypted, wrapped, and signed to verify authorship without revealing contents, and then that wrapper is in turn wrapped and signed with a burner key to avoid revealing the author.

Wrapping also makes it possible to randomize the created timestamp to avoid timing analysis, as well as to add padding to a message, reducing the possibility of payload size analysis.

New DMs and small groups

The main subject of Vitor's proposal was a new way to do DMs and small groups using double-wrapping to hide metadata. This works basically the same way NIP 04 did — a shared key is derived and the message is encrypted for the recipient, whose pubkey is revealed publicly so that it can be delivered.

However, Vitor was able to extend this to multiple recipients simply by wrapping the message multiple times, with multiple shared secrets. With the addition of some metadata on the inner event, this makes it possible to define a group where the members know who each other member is, but no one else does.

Large groups

This proposal has one important limitation though — the number of events that need to be signed and broadcast is equal to number of messages * number of members. This is fine with 5, 10, or even 100 members, but becomes infeasible when you reach groups of 1000+ members.

For that, we have two similar proposals, one by @simulx, and one by myself. The differences between the two are not important for this discussion — both use gift wrap as a way to exchange and rotate shared group keys, and both support a weak form of forward secrecy.

As a side note, this is the proposal I'm most excited about, and why I got into nostr in the first place. Private community groups which can support shared calendars, marketplaces, notes, etc., are what I'm most excited to see on nostr.

Shortcomings

The above proposals are great, but of course leave much to be desired. If these are built, nostr will be hugely improved in both security and functionality, with the following weaknesses:

• Deliverability is still an open question — are relay selections enough to ensure recipients get their messages, and no one else does?
• There is no way to create a group whose members cannot dox each other. You must always be able to trust the people you share a group with, and of course, the larger the group, the more people there are that can betray you.
• Content can always be shared outside a group, although in Vitor's small group proposal, the only way to verifiably leak messages would be to reveal your private key.
• Key rotation is not supported by the small groups proposal, but it may be possible to solve it for the entire protocol by building out a name resolution system for nostr.
• Forward secrecy for large groups is weak at best. A key rotation can be triggered at any time, including when a member leaves the group, but unless all relays and all members destroy the key rotation events, it may be possible to decrypt messages after the fact.
• Credential sharing still has to be bootstrapped, meaning at least one encrypted message for each participant may be publicly seen. Of course, credential sharing could also be done out of band, which would largely solve this problem.

What about SimpleX?

Lots of people, including Semisol and Will, have expressed interest in integrating nostr with SimpleX and using their cryptography and transport instead of nostr's.

The first question to answer though, is which protocol should we use? SimpleX is split into a few different pieces: there's the SimpleX Messaging Protocol, which describes setting up unidirectional channels, the SMP Agent Protocol which describes how to convert two unidirectional channels into a bidirectional channel, and the SimpleX Chat Protocol which describes a standard way to send chat messages across a bidirectional channel.

SimpleX Chat Protocol

So far, most proposals to fix messaging have focused simply on DMs, and sometimes on group chat. This is SimpleX's wheelhouse, so it could definitely make sense to communicate that kind of information over SimpleX's top-level chat protocol, and leave nostr out of it entirely.

The downside of this is that it requires clients to support two different protocols, and connect users to two categories of servers. This isn't a deal breaker, but it does increase the complexity involved in writing a full-featured nostr client, especially since there are no implementations of the SimpleX protocol other than (17k lines of) Haskell.

Using SimpleX's chat protocol would also limit the message types we'd be able to encrypt. Anything outside SimpleX's protocol (like zaps for example) would have to be sent using a custom namespace like nostr.kind.1234, which wouldn't be recognized by normal SimpleX clients. There are also areas of overlap where both protocols describe how to do something, for example profile data, requiring clients to choose which kind to support, or send both.

Another wrinkle is that the SimpleX protocol is AGPL v3 licensed, meaning proprietary software would not be able to interoperate, and MIT licensed products would have to abide by their license's terms.

SMP and Agent Protocols

The lower-level SMP and Agent protocols are more promising however, since their scope is narrower, and doesn't overlap as much with nostr's own core competencies. Both are quite simple, and very prescriptive, which should make it easy to create an implementation.

SMP is actually quite similar to some of the proposals mentioned above. Some of the same primitives are used (including XChaCha20 for encryption), and SMP is transport agnostic meaning it could be implemented over websockets and supported by nostr relays. The network topology is basically the same as nostr, except SimpleX doesn't make any assumptions about which servers should be selected, so in that regard nostr actually has an advantage.

The main incompatibility is that SimpleX requires the use of ed25519 and ed448 EdDSA algorithms for signatures, which means nostr's native secp256k1 signature scheme wouldn't be compatible. But this could be ok, since keys shouldn't be re-used anyway, and there are other ways to share a nostr identity.

Forward secrecy?

Whenever a server is involved, several attack vectors inherently exist that would not in peer-to-peer systems. Servers can threaten user privacy by storing messages that should be deleted, analyzing user behavior to infer identity, and leaking messages that should otherwise be kept secret.

This has been used by some to suggest that nostr relays are not a good way to transport messages from one user to another. However, SMP has the same attack vector:

Simplex messaging server implementations MUST NOT create, store or send to any other servers: - Logs of the client commands and transport connections in the production environment. - History of deleted queues, retrieved or acknowledged messages (deleted queues MAY be stored temporarily as part of the queue persistence implementation). - Snapshots of the database they use to store queues and messages (instead simplex messaging clients must manage redundancy by using more than one simplex messaging server). In-memory persistence is recommended. - Any other information that may compromise privacy or forward secrecy of communication between clients using simplex messaging servers.

So whether SimpleX servers or nostr relays are used, privacy guarantees are severely weakened if the server is not trustworthy. To maintain complete privacy in either scheme, users have to deploy their own servers.

Relays to the rescue

Because nostr servers are currently more commonly self-hosted, and more configurable, this makes nostr the better candidate for channel hosting. Users can choose which relays they send messages to, and relay admins can tune relays to only accept messages from and serve messages to certain parties, delete messages after a certain time, and implement policies for what kinds of messages they decide to relay.

All that to say, SMP itself or a similar protocol could easily be built into nostr relays. Relays are not the wrong tool for the job, in fact they're exactly the right tool! This is great news for us, since it means SMP is applicable to our problem, and we can learn from it, even if we don't strictly implement the protocol.

Bootstrapping over nostr

One assumption SMP makes is that channels will be bootstrapped out of band, and provides no mechanism for an initial connection. This is to ensure that channels can't be correlated with user identities. Out of band coordination is definitely the gold standard here, but coordination could also be done over the public nostr network with minimal metadata leakage — only that "someone sent {pubkey} something".

Unidirectional channels

Unidirectional channels are a great primitive, which can be composed to solve various problems. Direct messages between two parties are an obvious use case, but the SimpleX Chat Protocol also includes an extension for groups, defined as a set of bi-directional SimpleX connections with other group members.

This is similar to Vitor's small-group model, and likewise isn't conducive to supporting very large groups, since a copy of every message has to be sent to each group member.

However, it's possible to build large groups on top of unidirectional channels by sharing receiver information within the group and having all participants read from and write to a single channel. In fact, this is very similar to how our large group proposals work.

Conclusion

So, the takeaway here is that SimpleX's lower level protocols are great, and we should learn from them. It may be worth creating a NIP that describes the implementation of their unidirectional channels on nostr, and re-using that primitive in DM/group implementations, or simply following the same general process adapted to nostr.

I'm personally encouraged by reading SimpleX to see that we are headed in the right direction — although many of the details of our proposals have not been fully hammered out in the way SimpleX's has.

As for what the future holds, that's up to the builders. If you want to see tighter SimpleX integration, write a NIP and a reference implementation! I'll continue learning and fold in everything I can into my work going forward.

@ ec42c765:328c0600

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

@ 82b30d30:40c6c003

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

@ 75656740:dbc8f92a

"Who do you say that I am?"

In Matthew 16 Jesus cut to the heart of what defines identity. First he asked what other people said about him, then he asked what the disciples thought, finally he gave his own take by agreeing with the disciples. In trying to understand who someone is, we have three and only three possible sources of information.

1. Who they tell us they are.
2. Who others say about them.
3. What we observe for ourselves.

Putting these three together constitutes identity. Identity is always unique for each connection in the social graph. Who you are to me is always different than who you are to anyone else. As such identity is largely out of our direct control. We can influence others perception of ourselves by comporting ourselves in a certain way, but we cannot compel it.

With this in mind, it is imperative to build protocols that mirror this reality as closely as possible. The problem is largely one of UI. How can we simultaneously display all three aspects of identity in a clear and uncluttered way?

The default has always been to just display an individual's claim to identity. Each user gets to choose a name and an avatar. This generally works in small communities with low rates of change both in who the members are and in how they present themselves. In these cases, each user can keep a mental map of what to expect from each name and avatar. "Oh that is just keyHammer24 doing his thing." Note that even if KeyHammer24 decides to change their nickname the mental map in the other users won't change instantly, if ever.

This falls apart in larger communities, where each user cannot maintain a mental model of who is who. Impersonation and collisions become a problem, so we add some "What others say about them" information such as blue check-marks or what "what we observe for ourselves" information like pet-names in a phone contact list or a note that we follow that account.

I don't personally have a final solution for this, I only know that we should be collecting and displaying all three sources of information from the outset. Perhaps we could do something like... * Default to showing a users preferred identifiers, but switch to the avatar and handle we self-assign them on hover. * Display a percentage of confidence that we know who the person is and that they are presenting themselves as who we expect them to be. You probably aren't the Elon Musk that I expect if you recently had different names / aren't the one I follow / none of my network follows / have been reported as misleading. * Reserve check-marks for keys that each user has signed in person. Only we can be the arbiter of who gets a check-mark in our own feed. * Maintain a list of past aliases along with a "Community Notes" like description of an account brought up by clicking on a ⓘ icon. * Have a full pet-names override.

I think Nostr already have much of this built into the protocol, it just needs to be standardized into the interface of various application. This is something on which I am very interested in hearing other ideas.

A note on anonymity

Real world identities should always be preferred. It allows for building real relationships and treating each other with real world respect. The real you is far more fascinating than a curated persona. Real identities should also never be enforced at a protocol level. Some people will be in real circumstances that preclude honest engagement without threat to their safety.

If you found this engaging I also wrote about why Social Network companies have an unsolvable problem here. and why we have to design for finite reach here

@ 75da9402:77a65b5c

---

### BIENVENID@ A NOSTR

Queridos amigos que desean unirse a Nostr, sé que para todos ustedes es nuevo este camino, pero créanme que vale la pena experimentar y conocer una nueva forma de conectar y comunicarse con personas en otras partes del mundo. Varias de las mentes mas brillantes y apasionadas por dejar una huella diferente en las comunicaciones humanas han puesto alma, mente, corazón y hasta sus propios fondos para desarrollar y aportar a nostr.

QUE ES NOSTR? ¿COMO EMPIEZO?

Nostr es un protocolo de comunicación que está diseñado para que las personas se conecten entre si de forma rápida, segura y divertida. No es una empresa de RRSS como Twitter, FB u otras, tampoco existe un dueño, CEO o accionistas ni moderadores ni administradores de contenido, tampoco pertenece algún país en específico. Dicho esto, si aún no sabes cómo empezar aquí vamos. Para conectarte a Nostr vas a usar aplicaciones llamadas también clientes, te sugiero empieces en tu móvil y estas son algunas de las que puedes descargar y probar para empezar, luego puedes buscar otros clientes de tu agrado:

Damus para usuarios de IPhone https://apps.apple.com/app/damus/id1628663131

Amethyst para usuarios de Android https://play.google.com/store/apps/details?id=com.vitorpamplona.amethyst

PASOS IMPORTANTES A SEGUIR

Vamos a realizar estos pasos con el cliente Damus pero en Amethyst funciona igual:

1.- Una vez que instalaste la aplicación cliente ábrela y vas a ir a la opción Crear Cuenta

2.- Te aparecera una pantalla que dice EULA, dale aceptar sin miedo como en todas tus RRSS jaja, tranquil@ no pasa nada.

3.- En la siguiente pantalla deberás: Subir foto de perfil (si lo deseas), Nombre de usuario (nick que te guste el mio jp ), Mostrar nombre (como quieres llamarte el mio johnny ), Informacion (una breve biografía tuya ) presiona Crear y listo ya puedes usar Nostr como un Sayayin :-P

4.- Antes de empezar a escribir tu primer post vamos a dar 2 pasos más que son fundamentales y algún día me lo agradecerás (pero si a ti nadie te dice que hacer jajaja, ya puedes empezar a usar Nostr y saltarte estos pasos). Ve a la parte superior izquierda de Damus y presiona en la foto de tu perfil, deberá aparecer un menú que dice Configuración presiónalo y debe llevarte a algunas opciones, entre ellas escoges la que dice Keys

5.- Este es el último paso y es EXTREMADAMENTE IMPORTANTE que lo sigas al pie de la letra por que vamos a guardar tus llaves (usuario y contraseña) de forma segura. Aquí debo informarte que en Nostr no usaras ni correo ni número de móvil ni otro dato personal que te identifique para poder acceder a tu cuenta y por lo tanto debes guardar tú mismo las llaves de acceso ya que si las pierdes NO HAY FORMA DE RECUPERAR, las perderás para siempre y deberás volver a iniciar de nuevo.

Dentro de la opción Keys encontraras dos identificadores el primero que empieza por npub... es tu clave publica (tu usuario) que todos ven en la red y más abajo encontraras tu llave secreta (tu contraseña) esta es la más importante y al activar el botón Mostrar aparecerá y empieza con nsec.... estas dos claves debes copiarlas y guardarlas con total seguridad NO LAS PIERDAS de preferencia para guardarlas usa un administrador de contraseña como Bitwarden o tu propio llavero de ICloud en tu IPhone.

Bien si ya hiciste estos 5 pasos en menos de 5 minutos ya estarás listo para navegar e interactuar con otras personas en #nostr. Existen otros conceptos dentro de la red que ya te explicare en otra guía, por ejemplo, los relés que son los que se encargan de trasmitir tus posts (en forma de notas) a todo el mundo, pero con los que vienen preconfigurados los clientes es suficiente por ahora.

DIVIERTETE NUEVO NOSTRICH

Es momento de lanzarte al universo de Nostr, publica tu primer post Hola Mundo y empieza hacer amigos y te aseguro que muchas buenas personas te responderán para darte la bienvenida, como sugerencia si hablas español o quieres conocer gente de este idioma: ve a la opción UNIVERSO (lupa de buscar) de tu cliente, aquí encontraras el feed global donde aparece todos los posts a nivel mundial donde también puedes conocer gente. Ahí escribes Seguidor Hispano le das seguir a todos los que sigue esa cuenta y puedes empezar a seguir a otros en tu idioma.

---

Si te ha gustado y servido este minitutorial, compártelo a otros y si quieres puedes también seguirme a veces comparto buenos memes :-) Copia mi usuario en el buscador y me sigues:

npub1whdfgqn66sytcta0l6c7vlt3h2lg67xcnsmzpk3pyvpmsaaxtdwqr8vs60

By Johnny

@ 2d5b6404:d4b500b0

nostr streamからzap streamにタイトルも変更し大幅なアップデートがされました。 今までは自分でcloudflare streamに月額課金してマニュアル設定しなければなりませんでしたが、zap streamとOBSを紐づけてSATS(21 sats/min)を支払うだけで簡単にlive配信を開始することができるようになりました。

必要なものは3つだけです。zap streamとalby(アルビー)とOBSです。

はじめにzap streamにログインするためalbyのアカウント作成が必要になります。別の記事でalbyの登録方法をまとめたのでそちらを参考にしてみてください。

→alby(アルビー)の使い方

→primalが作成したalby(アルビー)の使い方ショート動画

OBSに関しては多くの解説動画がでていますのでそちらを参考に設定してみてください。 ぼくが参考にした動画です。→ https://youtu.be/ZQjsPJpMLiQ

最後にzap streamとOBSを紐づけるだけです。 zap streamのページを開いてalbyでログインします。 ログインしたら右上のアイコンの横のStreamを押します。

Stream Providers

API.ZAP.STREAM

Stream Url

rtmp://in.zap.stream/liveをコピーして、OBSの設定→配信のサーバーの欄に貼り付けます。

Stream Key

・・・・・・・・・をコピーして、OBSの設定→配信のストリームキーに貼り付けます。

次にBalanceのTOPUPを押してSATSを支払います。21 sats/min 1分21satsなので1時間だと1260satsを先に支払います。長時間配信する場合は多めに入金しておきましょう。

あとはEdit Streamでタイトルやサムネイルを設定してSAVEします。 アダルトコンテンツの場合NSFW Contentにチェックをいれてください。

zap streamとOBSの設定が完了したら、OBSで配信開始すれば勝手にzap streamでlive配信が開始されます。

以上がzap streamでlive配信する方法です。

ライブコーディングやゲーム配信をしているユーザーがすでにいますのでVtuderの方などどんどん配信してみてください。

@ 97c70a44:ad98e322

First, a product announcement.

Coracle now supports connection multiplexing, which can reduce bandwidth usage by over 90% depending on how many relays you use. It's opt-in for now, but you can set it up by going to Settings and entering wss://multiplextr.coracle.social as your "Multiplextr URL".

You can check out the source code and self-host the library using this link. If you're a dev and want to add client support for multiplextr, the library I built to support this use case might be of use.

Now, on to your regularly scheduled blog post.

The above announcement isn't irrelevant to what I want to talk about in this post, which is (broadly) the question of "how can Nostr remain decentralized and still support advanced functionality?"

This is probably the most common question articulated among devs and enthusiasts - is search centralizing? What about recommendation engines? COUNT? Analytics? The answer is yes, and responses range from "it'll be fine" to "nostr is already captured".

For my part, I'm not sure if this problem can be solved. Already we have a browser wars dynamic emerging among clients, and business models based on proprietary services and advertising have been publicly considered. For the record, I don't think conventional business models are necessarily bad. The world works this way for a reason and Nostr isn't going to change that by default.

Nevertheless, I want to see a new internet emerge where my attention belongs to me, and I'm not beholden to massive companies who don't give a rip about me. As a result, much of the work I've put into Coracle hasn't gone into fun features, but into things I think will help realize the vision of Nostr. This gives me FOMO as I watch others' progress, but if I don't stay focused on my vision for Nostr, what am I even doing?

I should be clear that this is not a judgment on the motivations of others, building for fun and profit is just as legitimate as building to idealistically realize the best of all Nostrs. However, I would say that it is every developer's duty to keep in mind that what we're trying to accomplish here is not a web2 clone.

Two, and only two options

With all that said, let's get into the meat of the problem. There's a false dichotomy floating around out there that we have two options for adding server-side functionality to the nostr ecosystem. Option 1: pack all required functionality into relays, eliminating the "dumb relay" model, and making it extremely difficult to run a relay. Option 2: keep relays dumb and the protocol minimal, allowing indexers, search engines, and recommendation services (which I'll collectively call "extensions" here) to profit by solving advanced use cases.

Both alternatives are obviously deficient. Relays need to be something hobbyists can run; requiring relays to fold in a recommendation engine or search index makes that much harder, and for every feature required, proprietary solutions will be able to build a bigger moat.

On the other hand, proprietary extensions will not bother to interoperate. This will result in an app-store-like landscape of competing extensions, which will redirect developer and user attention away from relays to extensions. If nostr is to succeed, relays must remain an important first-class concept. Aggregators and indexers that gloss over the differences between relays destroy much of the value an individual relay has to offer.

In either case, some components of the network will become too sophisticated for a layman to deploy. The only alternative is for a few professionals to take up the slack and grow their service as a business. But I think there's a way to squeeze between the horns of the dilemma.

It's all about routing

It seems to me that most people prefer the "extension" model of scaling functionality of Nostr as a pragmatic, market-driven alternative to the impossibility of requiring all relays to support all possible features. And I agree, the folks developing and operating more sophisticated tools should be compensated for their hard work.

The real problem with this approach is that not that extensions are competitive and specialized, but that they obscure the importance of relays by becoming gatekeepers for data by providing additional functionality. If a client or user has to select a search engine and ask it to return results for a given relay, they have given that search engine control over their results, when their trust really should be placed in the relay itself.

(I will say as an aside, that there are scenarios when the gatekeeper approach does make sense, like when a user wants to "bring his own algorithm". But this should be something a user can opt-in to, not a default requirement for accessing the underlying protocol.)

Here's my proposal: instead of requiring users to trust some non-standard extension to make decisions for them, flip the script and make relays the gatekeepers instead. With this approach, the addition of a single feature can open the door for relays to support any extension at no additional cost.

One of the most exciting aspects of Nostr is the redundancy relays provide. With Nostr, you don't need to trust a single entity to store your data for you! Why should you trust a single gatekeeper to route you to that data? Relays don't need to provide search or recommendations or indexing functionality directly, they can simply send you to a third-party extension they deem trustworthy.

This approach allows extensions to piggy-back on the trust already endowed in relays by end users. By allowing relays that are already aligned with end users to broker connections with extensions, they form a circuit breaker for delegated trust. This is more convenient for end users, and makes it easier to switch extensions if needed, since relay operators are more likely to have their finger on the pulse than end users.

It also enables cleaner business relationships. Instead of asking clients to create custom integrations with particular extensions leading to vendor lock-in, an extension provider can implement a common interface and sell to relays instead by offering to index their particular data set.

With this model, relays have the flexibility to either provide their own advanced functionality or delegate it to someone else, reducing the functionality gap that would otherwise emerge with thick relays without removing the ability for extension service providers to run a business, all the while keeping users and clients focused on interacting with relay operators rather than non-standard extensions.

Making it happen

The difficulty with this of course is that add-on services need to be identifiable based on functionality, and they must be interoperable. This means that their functionality must be described by some protocol (whether the core Nostr protocol or an addition to it), rather than by proprietary extensions. There will be extensions that are too complex or special-purpose to fit into this model, or for whom interoperability doesn't matter. That's ok. But for the rest, the work of specifying extensions will pay off in the long run.

This routing layer might take a variety of forms - I've already proposed an addition to to NIP 11 for service recommendations. Clients would look up what add-ons their relays recommend, then follow those recommendations to find a service that supports their requirements.

It also occurs to me having written my multiplexer relay this week (and here we come full circle) that it would be trivially easy for relays to proxy certain types of requests. So for example, a relay might fulfill REQs itself, but pass SEARCH requests on to a third-party extension and relay the result to the end user.

In either case though, a well-behaved client could get all the functionality desired, for all of the data required, without compomising the brilliant trust model fiatjaf came up with.

Conclusion

I think this is a very important problem to solve, and I think relay-sponsored extension recommendations/routing is a very good way to do it. So, please comment with criticisms! And if you agree with me, and want to see something like this become the standard, comment on my pull request.

@ 97c70a44:ad98e322

I think I cracked the code on private groups.

Instead of relying on relays to implement access control as in this PR, we could combine the Gift Wrap proposal with @PABLOF7z​'s nsec bunker to create private groups with easy administration and moderation!

Gift wrap fixes DM metadata leakage by using a temporary private key to send a DM to a recipient. The recipient decrypts the wrapper to find a regular nostr event inside. This could be another kind 4 as in the proposal, or anything else. Which means you can send kind 1's or anything else in a wrapped event.

Now suppose you had a pubkey that you wanted to represent a group instead of a person. Put its nsec in a (modified) nsec bunker, and now you can allow other people than yourself to request signatures. A shared private key! Anyone who has access to this nsec bunker could also de-crypt any gift wrapped note sent to it. Relay-free read access control!

There are lots of ways you could manage this access list, but I think a compelling one would be to create a NIP 51 list (public or private!) of group members and set up the nsec bunker to authenticate using that list. Boom, dynamic member lists!

You could also create a NIP 51 list for admins, and pre-configure which event kinds each list is allowed to post using the group's nsec. So maybe members could only publish wrapped kind-1's, but admins could publish wrapped kind-0's (you can now zap a group!), kind 9's for moderation, updated member and moderator lists, normal kind 1's for public information about the group, etc.

Gift wrap would support:

• Leak-free DMs
• Fully private groups
• Public-read groups (nsec bunker would allow for admin, but everyone would publish regular instead of wrapped events).
• Organizations and other shared accounts, with role-based authorization (list/kind mappings)!

Of course, no clients currently support this kind of thing, but support would not be hard to add, and it creates an entirely new set of affordances with two very simple applications of the core protocol.

There are a few drawbacks I can think of, of course. Gift wrap makes it harder to search notes by tag. You could:

• Leave all tags off (other than for DM recipient as in the proposal)
• Selectively keep tags that aren't revealing of identity
• Encrypt tag values. When a client wants to query a tag, it must encrypt the value using the same pubkey and include that in the filter. This, I think, is ok for the group use case above.

There are also a number of proposals in the works to fix NIP 04 DMs which are apparently broken from a cryptographic standpoint, so implementing this should probably wait until that stuff is sorted out. But it should be possible however that ends up materializing.

So am I nuts? Or is this a galaxy brain solution?

@ 76c71aae:3e29cafa

Joining a new digital community can be an exhilarating and empowering experience. This has been observed on numerous occasions when people join new platforms such as Nostr, BlueSky, Farcaster, Post.news, Tribel, and many others, as well as older social media platforms such as blogs, Usenet, LiveJournal, Xanga, AOL, Flickr, Facebook, Instagram, and TikTok.

Initially, these spaces create an idealistic environment where individuals are eager to connect, share, and participate in a virtual gathering that resembles a festival. However, it is worth examining what it is about these new social spaces that generates such a euphoric atmosphere, and whether it is feasible to sustain this utopian sentiment as communities expand and develop.

The Magic of Connection:

Joining a new digital community can be a transformative experience. In her book "Paradise Built in Hell," Rebecca Solnit argues that when people are taken out of their familiar routines and confronted with real human needs, the best aspects of human nature come to the forefront. This disproves the negative assumption that humans are inherently selfish and demonstrates our natural ability to empathize and connect with one another. The sense of community and collaboration that we feel in emerging social spaces, patticipatory festivals such as 'Burningman', are a great example of this phenomenon.

Utopias Form Where They Shouldn’t Exist:

The concept of "Paradise Built in Hell" becomes evident during natural and economic disasters. I personally witnessed this idea during Argentina's economic crisis in the early 2000s. Despite the difficulties, people came together and collaborated in new ways to support each other, as the collapsing economy demanded it. This same phenomenon is observed following earthquakes and other natural disasters, where people often speak of those days with a magical, almost reverential tone.

Rebecca Solnit argues that "Disaster is when the shackles of conventional belief and role fall away and the possibilities open up; people rise to the occasion or sink to the level of their fears and prejudices." In these challenging moments, we see the true nature of humanity: our ability to show compassion, resilience, and unity in the face of adversity.

Social Media and All Digital Spaces Have Physical Analogues:

The similarities between digital and physical communities are rooted in the fact that each has its own distinct set of unspoken rules and social norms. Just as we know to be quiet in a library, loud at a concert, social at a cocktail party, and anti-social on the subway, we also understand the unique dynamics of different digital platforms. Twitter resembles a bustling dive bar, Instagram an art gallery, TikTok an amusement park hall of mirrors, and Facebook a community hall rented for a retirement party. Every new digital space has its analogues in the physical world because human interaction remains consistent, even if the medium differs. As we navigate the ever-changing landscape of digital communities, we are reminded of our innate ability to adapt, connect, and thrive in the face of adversity. This adaptability empowers us to form new connections and rediscover the power of community, whether in the digital or physical realm.

The Small Community Paradox:

To maintain the utopian atmosphere of new digital communities, one effective approach is to keep them small or create numerous smaller sub-communities. In these sub-communities, people can engage in the social labor of connection and conflict resolution.

It is important to note, however, that this approach may conflict with the network effect principle. This principle states that each new member joining the community increases its overall value for all participants. As communities grow and the network effect takes hold, the utopian feeling may often fade, giving way to sub-tribes and conflict.

Nevertheless, with a confident approach, the community can adapt and navigate these challenges to foster a positive environment for all members.

The Fleeting Nature of Utopia:

The fleeting utopian sensation experienced within new digital communities is inevitable. Although it is not the design or coding of platforms such as BlueSky, Nostr, Mastodon, or Scuttlebutt that generates this feeling of euphoria, it is instead the human dynamics of joining something novel and building a community that cultivates this enchanting ambiance. Hakim Bey's concept of Temporary Autonomous Zones (TAZs) endorses this notion, demonstrating how short-lived spaces of freedom and interaction can emerge within established social structures. As communities expand and progress, the real challenge lies in sustaining the initial energy and sense of connection that made them so desirable in the first place.

Parallel to Protests and Uprisings:

This utopian sentiment is not limited to digital communities; it is also present during times of revolution, protests, and uprisings. There is a profoundly human element to the sense of love, connection, solidarity, and community that arises during these moments.

The most impactful moments of my life have been when I participated in protests that were met with repression. These protests ranged from tree-sits to protect old-growth redwoods in the forests where I grew up, to large convergences of the anti-globalization and anti-war movements, to Occupy's reclamation of public spaces, and to recent Black Lives Matter protests. All of these protests were scenes of anguish, repression, and, in some cases, violence, especially from the police. However, they were also places where I experienced the most love, connection, humanity, and common purpose. We were all individuals, together, living and breathing solidarity.

Cultivating and Sustaining Utopian Energy:

To preserve the utopian essence of new digital communities as they grow, one approach is to foster a culture of empathy, connection, and inclusiveness from the very beginning. Prioritizing these values and actively engaging in conflict resolution can help communities maintain that special feeling.

Another way to preserve the utopian essence of digital communities is to focus on building tools for the construction and maintenance of these digital public spaces. Unlike corporate social media platforms that only provide an illusion of public space while actually being privately owned, like a shopping mall, we need to create spaces that are community-controlled and collectively owned as a commons with confidence.

Understanding the Commons:

The concept of the commons offers a compelling alternative to traditional models of state or private ownership. Elinor Ostrom, the first woman to win the Nobel Prize in Economics, conducted extensive research on this topic, and her findings are truly remarkable. Through her work, she proved that commons can be effectively managed and maintained, debunking the misguided belief that these resources are doomed to fail and end in tragedy.

Designing for Digital Commons:

To design digital commons, we must prioritize transparency, decentralization, and participatory governance. By empowering users to make decisions about the direction and rules of their digital communities, we ensure that the spaces remain truly public and that the needs and desires of the community are at the forefront.

Open-source technology and decentralized protocols can play a vital role in the development of these digital commons. By allowing users to maintain control over their data and ensuring that no single entity has a monopoly over the platform, we create an environment that fosters collaboration, creativity, and innovation.

The Characteristics of a Well-Functioning Digital Commons:

1. Clearly defined boundaries: Members and their rights are easily identifiable, and access to the shared digital resources is well-regulated.
2. Proportional equivalence between benefits and costs: Users contribute to the commons according to their capabilities, and benefits are distributed fairly among members.
3. Collective decision-making: Users have a say in shaping the rules and policies that govern their digital communities, promoting a sense of ownership and accountability.
4. Monitoring: Transparent systems are in place to track the usage and management of shared resources, ensuring that members adhere to established rules.
5. Graduated sanctions: Penalties for rule violations are proportional and escalate based on the severity and frequency of the transgressions.
6. Conflict resolution mechanisms: Efficient and fair processes are in place to address disputes among members, promoting harmony and trust within the community.
7. Minimal recognition of rights to organize: Users have the autonomy to self-organize and make decisions about their digital commons without excessive interference from external authorities.
8. Nested enterprises: Digital commons are organized into multiple, interconnected layers of governance, with smaller communities operating within the context of larger ones, fostering collaboration and coordination.

By incorporating these principles into the design of digital commons, we can create spaces that are robust, sustainable, and equitable. This, in turn, fosters innovation, collaboration, and genuine community engagement.

Developing Community-Driven Tools:

To create and maintain digital public spaces, we need tools that empower communities to effectively manage their digital commons. These tools should facilitate communication, conflict resolution, and decision-making while promoting inclusiveness, empathy, and shared values. By empowering communities to shape their digital spaces and collaboratively resolve issues, we can help preserve the utopian essence that initially attracted people to these platforms.

Adapting to Growth and Change:

As digital communities continue to grow, it's crucial to acknowledge that their needs and challenges will inevitably change over time. To maintain a utopian atmosphere, we must be willing to adapt and consistently improve the tools and processes that sustain these digital public spaces. By promoting continuous feedback and collaboration among community members, we can ensure that the platform remains responsive to the needs of its users, fostering an environment of connection and belonging with conviction.

Conclusion:

Joining a new digital community can be a thrilling experience, but maintaining that sense of euphoria as the community grows can be difficult. To achieve this, we must design and construct digital commons that prioritize community control, collective ownership, and participatory governance. With the appropriate tools and a dedication to adapting to the evolving needs of the community, we can create spaces that continue to foster the magic of connection even as they transform. In doing so, we can nurture and sustain the utopian energy that makes these digital spaces so unique.

Post Script:

Since the completion of this essay, Bluesky has evolved from its initial utopian stage to a phase grappling with context, norms, and scalability. With an increasing user base, the once agreed-upon behavioral norms began to crumble. The initial playfulness, while staying within the community's value constraints, took a disturbing turn when individuals started posting racist and homophobic content. The situation deteriorated rapidly, escalating to the point of issuing death threats. Inspired by the "Nazi bar" parable, the community demanded urgent action to outline acceptable behavior and remove those who couldn't comply.

Bluesky, currently hosted on a single server, possesses the capability to enforce a unified set of community guidelines and terms of service. The creators of Bluesky, much like any other social media platform's developers, aimed for a laissez-faire approach. However, they eventually had to revise the terms of service and ban the trolls. This action was chaotic and resulted in significant loss of trust and goodwill.

Additionally, this did not aid the community in establishing governance for the burgeoning social media commons. Protocols such as Bluesky, Nostr, DSNP, Scuttlebutt, Farcaster, and Lens are not designed to operate in isolation. Among these, only ActivityPub and Mastodon have successfully implemented a model to manage abuse and community moderation at scale. Nonetheless, potential solutions are under development. I've personally contributed to proposals for specifications, codes, and norms on Nostr and know that Bluesky's team is making similar strides.

It is essential that the user community actively participate in this process. The Design Justice movement provides a valuable blueprint and strategies for achieving this. By applying principles of co-design and design justice, we can collaboratively build solutions. The stakes are too high to leave this endeavor to a small group of technologists alone.

@ 82341f88:fbfbe6a2

There’s a lot of conversation around the #TwitterFiles. Here’s my take, and thoughts on how to fix the issues identified.

I’ll start with the principles I’ve come to believe…based on everything I’ve learned and experienced through my past actions as a Twitter co-founder and lead:

1. Social media must be resilient to corporate and government control.
2. Only the original author may remove content they produce.
3. Moderation is best implemented by algorithmic choice.

The Twitter when I led it and the Twitter of today do not meet any of these principles. This is my fault alone, as I completely gave up pushing for them when an activist entered our stock in 2020. I no longer had hope of achieving any of it as a public company with no defense mechanisms (lack of dual-class shares being a key one). I planned my exit at that moment knowing I was no longer right for the company.

The biggest mistake I made was continuing to invest in building tools for us to manage the public conversation, versus building tools for the people using Twitter to easily manage it for themselves. This burdened the company with too much power, and opened us to significant outside pressure (such as advertising budgets). I generally think companies have become far too powerful, and that became completely clear to me with our suspension of Trump’s account. As I’ve said before, we did the right thing for the public company business at the time, but the wrong thing for the internet and society. Much more about this here: https://twitter.com/jack/status/1349510769268850690

I continue to believe there was no ill intent or hidden agendas, and everyone acted according to the best information we had at the time. Of course mistakes were made. But if we had focused more on tools for the people using the service rather than tools for us, and moved much faster towards absolute transparency, we probably wouldn’t be in this situation of needing a fresh reset (which I am supportive of). Again, I own all of this and our actions, and all I can do is work to make it right.

Back to the principles. Of course governments want to shape and control the public conversation, and will use every method at their disposal to do so, including the media. And the power a corporation wields to do the same is only growing. It’s critical that the people have tools to resist this, and that those tools are ultimately owned by the people. Allowing a government or a few corporations to own the public conversation is a path towards centralized control.

I’m a strong believer that any content produced by someone for the internet should be permanent until the original author chooses to delete it. It should be always available and addressable. Content takedowns and suspensions should not be possible. Doing so complicates important context, learning, and enforcement of illegal activity. There are significant issues with this stance of course, but starting with this principle will allow for far better solutions than we have today. The internet is trending towards a world were storage is “free” and infinite, which places all the actual value on how to discover and see content.

Which brings me to the last principle: moderation. I don’t believe a centralized system can do content moderation globally. It can only be done through ranking and relevance algorithms, the more localized the better. But instead of a company or government building and controlling these solely, people should be able to build and choose from algorithms that best match their criteria, or not have to use any at all. A “follow” action should always deliver every bit of content from the corresponding account, and the algorithms should be able to comb through everything else through a relevance lens that an individual determines. There’s a default “G-rated” algorithm, and then there’s everything else one can imagine.

The only way I know of to truly live up to these 3 principles is a free and open protocol for social media, that is not owned by a single company or group of companies, and is resilient to corporate and government influence. The problem today is that we have companies who own both the protocol and discovery of content. Which ultimately puts one person in charge of what’s available and seen, or not. This is by definition a single point of failure, no matter how great the person, and over time will fracture the public conversation, and may lead to more control by governments and corporations around the world.

I believe many companies can build a phenomenal business off an open protocol. For proof, look at both the web and email. The biggest problem with these models however is that the discovery mechanisms are far too proprietary and fixed instead of open or extendable. Companies can build many profitable services that complement rather than lock down how we access this massive collection of conversation. There is no need to own or host it themselves.

Many of you won’t trust this solution just because it’s me stating it. I get it, but that’s exactly the point. Trusting any one individual with this comes with compromises, not to mention being way too heavy a burden for the individual. It has to be something akin to what bitcoin has shown to be possible. If you want proof of this, get out of the US and European bubble of the bitcoin price fluctuations and learn how real people are using it for censorship resistance in Africa and Central/South America.

I do still wish for Twitter, and every company, to become uncomfortably transparent in all their actions, and I wish I forced more of that years ago. I do believe absolute transparency builds trust. As for the files, I wish they were released Wikileaks-style, with many more eyes and interpretations to consider. And along with that, commitments of transparency for present and future actions. I’m hopeful all of this will happen. There’s nothing to hide…only a lot to learn from. The current attacks on my former colleagues could be dangerous and doesn’t solve anything. If you want to blame, direct it at me and my actions, or lack thereof.

As far as the free and open social media protocol goes, there are many competing projects: @bluesky is one with the AT Protocol, nostr another, Mastodon yet another, Matrix yet another…and there will be many more. One will have a chance at becoming a standard like HTTP or SMTP. This isn’t about a “decentralized Twitter.” This is a focused and urgent push for a foundational core technology standard to make social media a native part of the internet. I believe this is critical both to Twitter’s future, and the public conversation’s ability to truly serve the people, which helps hold governments and corporations accountable. And hopefully makes it all a lot more fun and informative again.

💸🛠️🌐 To accelerate open internet and protocol work, I’m going to open a new category of #startsmall grants: “open internet development.” It will start with a focus of giving cash and equity grants to engineering teams working on social media and private communication protocols, bitcoin, and a web-only mobile OS. I’ll make some grants next week, starting with $1mm/yr to Signal. Please let me know other great candidates for this money.

@ 3bf0c63f:aefa459d

Nostr is not decentralized nor censorship-resistant

Peter Todd has been saying this for a long time and all the time I've been thinking he is misunderstanding everything, but I guess a more charitable interpretation is that he is right.

Nostr today is indeed centralized.

Yesterday I published two harmless notes with the exact same content at the same time. In two minutes the notes had a noticeable difference in responses:

The top one was published to wss://nostr.wine, wss://nos.lol, wss://pyramid.fiatjaf.com. The second was published to the relay where I generally publish all my notes to, wss://pyramid.fiatjaf.com, and that is announced on my NIP-05 file and on my NIP-65 relay list.

A few minutes later I published that screenshot again in two identical notes to the same sets of relays, asking if people understood the implications. The difference in quantity of responses can still be seen today:

These results are skewed now by the fact that the two notes got rebroadcasted to multiple relays after some time, but the fundamental point remains.

What happened was that a huge lot more of people saw the first note compared to the second, and if Nostr was really censorship-resistant that shouldn't have happened at all.

Some people implied in the comments, with an air of obviousness, that publishing the note to "more relays" should have predictably resulted in more replies, which, again, shouldn't be the case if Nostr is really censorship-resistant.

What happens is that most people who engaged with the note are following me, in the sense that they have instructed their clients to fetch my notes on their behalf and present them in the UI, and clients are failing to do that despite me making it clear in multiple ways that my notes are to be found on wss://pyramid.fiatjaf.com.

If we were talking not about me, but about some public figure that was being censored by the State and got banned (or shadowbanned) by the 3 biggest public relays, the sad reality would be that the person would immediately get his reach reduced to ~10% of what they had before. This is not at all unlike what happened to dozens of personalities that were banned from the corporate social media platforms and then moved to other platforms -- how many of their original followers switched to these other platforms? Probably some small percentage close to 10%. In that sense Nostr today is similar to what we had before.

Peter Todd is right that if the way Nostr works is that you just subscribe to a small set of relays and expect to get everything from them then it tends to get very centralized very fast, and this is the reality today.

Peter Todd is wrong that Nostr is inherently centralized or that it needs a protocol change to become what it has always purported to be. He is in fact wrong today, because what is written above is not valid for all clients of today, and if we drive in the right direction we can successfully make Peter Todd be more and more wrong as time passes, instead of the contrary.

---

See also:

• Censorship-resistant relay discovery in Nostr
• A vision for content discovery and relay usage for basic social-networking in Nostr

@ 6871d8df:4a9396c1

In an era where data seems to be as valuable as currency, the prevailing trend in AI starkly contrasts with the concept of personal data ownership. The explosion of AI and the ensuing race have made it easy to overlook where the data is coming from. The current model, dominated by big tech players, involves collecting vast amounts of user data and selling it to AI companies for training LLMs. Reddit recently penned a 60 million dollar deal, Google guards and mines Youtube, and more are going this direction. But is that their data to sell? Yes, it's on their platforms, but without the users to generate it, what would they monetize? To me, this practice raises significant ethical questions, as it assumes that user data is a commodity that companies can exploit at will.

The heart of the issue lies in the ownership of data. Why, in today's digital age, do we not retain ownership of our data? Why can't our data follow us, under our control, to wherever we want to go? These questions echo the broader sentiment that while some in the tech industry — such as the blockchain-first crypto bros — recognize the importance of data ownership, their "blockchain for everything solutions," to me, fall significantly short in execution.

Reddit further complicates this with its current move to IPO, which, on the heels of the large data deal, might reinforce the mistaken belief that user-generated data is a corporate asset. Others, no doubt, will follow suit. This underscores the urgent need for a paradigm shift towards recognizing and respecting user data as personal property.

In my perfect world, the digital landscape would undergo a revolutionary transformation centered around the empowerment and sovereignty of individual data ownership. Platforms like Twitter, Reddit, Yelp, YouTube, and Stack Overflow, integral to our digital lives, would operate on a fundamentally different premise: user-owned data.

In this envisioned future, data ownership would not just be a concept but a practice, with public and private keys ensuring the authenticity and privacy of individual identities. This model would eliminate the private data silos that currently dominate, where companies profit from selling user data without consent. Instead, data would traverse a decentralized protocol akin to the internet, prioritizing user control and transparency.

The cornerstone of this world would be a meritocratic digital ecosystem. Success for companies would hinge on their ability to leverage user-owned data to deliver unparalleled value rather than their capacity to gatekeep and monetize information. If a company breaks my trust, I can move to a competitor, and my data, connections, and followers will come with me. This shift would herald an era where consent, privacy, and utility define the digital experience, ensuring that the benefits of technology are equitably distributed and aligned with the users' interests and rights.

The conversation needs to shift fundamentally. We must challenge this trajectory and advocate for a future where data ownership and privacy are not just ideals but realities. If we continue on our current path without prioritizing individual data rights, the future of digital privacy and autonomy is bleak. Big tech's dominance allows them to treat user data as a commodity, potentially selling and exploiting it without consent. This imbalance has already led to users being cut off from their digital identities and connections when platforms terminate accounts, underscoring the need for a digital ecosystem that empowers user control over data. Without changing direction, we risk a future where our content — and our freedoms by consequence — are controlled by a few powerful entities, threatening our rights and the democratic essence of the digital realm. We must advocate for a shift towards data ownership by individuals to preserve our digital freedoms and democracy.

@ 3bf0c63f:aefa459d

Parallel Chains

We want merged-mined blockchains. We want them because it is possible to do things in them that aren't doable in the normal Bitcoin blockchain because it is rightfully too expensive, but there are other things beside the world money that could benefit from a "distributed ledger" -- just like people believed in 2013 --, like issued assets and domain names (just the most obvious examples).

On the other hand we can't have -- like people believed in 2013 -- a copy of Bitcoin for every little idea with its own native token that is mined by proof-of-work and must get off the ground from being completely valueless into having some value by way of a miracle that operated only once with Bitcoin.

It's also not a good idea to have blockchains with custom merged-mining protocol (like Namecoin and Rootstock) that require Bitcoin miners to run their software and be an active participant and miner for that other network besides Bitcoin, because it's too cumbersome for everybody.

Luckily Ruben Somsen invented this protocol for blind merged-mining that solves the issue above. Although it doesn't solve the fact that each parallel chain still needs some form of "native" token to pay miners -- or it must use another method that doesn't use a native token, such as trusted payments outside the chain.

How does it work

With the SIGHASH_NOINPUT/SIGHASH_ANYPREVOUT soft-fork[^eltoo] it becomes possible to create presigned transactions that aren't related to any previous UTXO.

Then you create a long sequence of transactions (sufficient to last for many many years), each with an nLockTime of 1 and each spending the next (you create them from the last to the first). Since their scriptSig (the unlocking script) will use SIGHASH_ANYPREVOUT you can obtain a transaction id/hash that doesn't include the previous TXO, you can, for example, in a sequence of transactions A0-->B (B spends output 0 from A), include the signature for "spending A0 on B" inside the scriptPubKey (the locking script) of "A0".

With the contraption described above it is possible to make that long string of transactions everybody will know (and know how to generate) but each transaction can only be spent by the next previously decided transaction, no matter what anyone does, and there always must be at least one block of difference between them.

Then you combine it with RBF, SIGHASH_SINGLE and SIGHASH_ANYONECANPAY so parallel chain miners can add inputs and outputs to be able to compete on fees by including their own outputs and getting change back while at the same time writing a hash of the parallel block in the change output and you get everything working perfectly: everybody trying to spend the same output from the long string, each with a different parallel block hash, only the highest bidder will get the transaction included on the Bitcoin chain and thus only one parallel block will be mined.

See also

• Drivechain

[^eltoo]: The same thing used in Eltoo.

@ 3bf0c63f:aefa459d

Timeu

Os quatro elementos, a esfera como a forma mais perfeita, os cinco sentidos, a dor como perturbação e o prazer como retorno, o demiurgo que cria da melhor maneira possível com a matéria que tem, o conceito de duro e mole, todas essas coisas que ensinam nas escolas e nos desenhos animados ou sei lá como entram na nossa consciência como se fossem uma verdade, mas sempre uma verdade provisória, infantil -- como os nomes infantis dos dedos (mata-piolho, fura-bolo etc.) --, que mesmo as crianças sabem que não é verdade mesmo.

Parece que todas essas coisas estão nesse livro. Talvez até mesmo a classificação dos cinco dedos como mata-piolho e tal, mas talvez eu tenha dormido nessa parte.

Me pergunto se essas coisas não eram ensinadas tradicionalmente na idade média como sendo verdade absoluta (pois afinal estava lá o Platão dizendo, em sua única obra) e persistiram até hoje numa tradição que se mantém aos trancos e barrancos, contra tudo e contra todos, sem ninguém saber como, um conhecimento em que ninguém acredita mas acha bonito mesmo assim, harmonioso, e vem despida de suas origens e fontes primárias e de todo o seu contexto perturbar o entendimento do mundo pelas crianças.

@ 3bf0c63f:aefa459d

Blockchains are not decentralized data storage

People are used to saying and thinking that blockchains provide immutable data storage. Then many times they add a caveat that says blockchains are very expensive, so we can't really store too much data on them, but we can still store some data if we really want and are ok with paying for it.

But the fact is that blockchains cannot ever be used to store anything. The purpose of blockchains is to keep track of some state that everybody must agree upon at all times, and arbitrary data that anyone may have wanted to backup there is not relevant to anyone else[^relevant] and thus there are no incentives for anyone else to keep track of that. In other words: if you backup your personal pictures as OP_RETURN outputs on Bitcoin, people may delete that and your backup will be void[^op-return-invalid-outputs].

Another thing blockchains supposedly do is to "broadcast" something. For example, nodes may delete the OP_RETURN outputs, but at least they have to verify these first, and spread they over the network, so you can broadcast your data and be sure everybody will get it. About this we can say two things: 1, if this happens, it's not a property of blockchains, but of the Bitcoin transaction sharing network that operates outside of the blockchain. 2, if you try to use that network for purposes that are irrelevant for the functioning of the Bitcoin protocol there is no incentive for other nodes to cooperate and they may ignore you.

The above points may sound weird and you may be prompted to answer: but you can do all that today and there is no actual mechanism to stop anyone from broadcasting irrelevant crap!, and that is true. My point here is only that if you're thinking about blockchains as being this data-broadcast-storage mechanism you're thinking about them wrong, that is not an essential part of any blockchain. In other words: the incentives are not aligned for blockchains to be used like that (unless you come up with a scheme that makes data from everyone else to be relevant to everybody), in the long term such things are not expected to work and insisting on doing them will result in either your application or protocol that stores data on the blockchain to crash or in the death of the given blockchain (I hope Bitcoin haters don't read this).

(This is a counterpoint to myself on idea: Rumple, which was a protocol idea that relied on a blockchain storing irrelevant data.)

[^relevant]: For example, all Bitcoin transactions are relevant to all Bitcoin users because as a user the total supply and the ausence of double-spends are relevant, and also the fact that any of these transactions may end up being ancestors of transactions that you might receive in the future. [^op-return-invalid-outputs]: Of course you can still backup your pictures as invalid P2PKH outputs or something like that, then it will be harder for people to spot your data as irrelevant, but this is not a feature, it's a bug of Bitcoin that enables someone to spam other nodes in a way they can't detect it. If people started doing this a lot it would break Bitcoin.

@ 3bf0c63f:aefa459d

Programming quibbles

• About CouchDB
• my personal approach on using let, const and var in javascript
• A crappy course on torrents
• Multi-service Graph Reputation protocol
• The monolithic approach to CouchDB views
• My stupid introduction to Haskell
• The unit test bubble
• There's a problem with using Git concepts for everything
• On the state of programs and browsers
• Rust's .into() is a strictly bad thing

@ 3bf0c63f:aefa459d

Trello Attachment Editor

A static JS app that allowed you to authorize with your Trello account, fetch the board structure, find attachments, edit them in the browser then replace them in the cards.

Quite a nice thing. I believe it was done to help with Websites For Trello attached scripts and CSS files.

• https://github.com/fiatjaf/trello-attachments
• https://fiatjaf.github.io/trello-attachments/#/login

See also

• Temperos

@ 3bf0c63f:aefa459d

A flexibilidade da doutrina socialista

Os fatos da revolução russa mostram que Lênin e seus amigos bolcheviques não eram só psicopatas assassinos: eles realmente acreditavam que estavam fazendo o certo.

Talvez depois de um tempo o foco deles tenha mudado mais para o lado de se preocuparem menos com a vida e o bem-estar dos outros do que com eles mesmos, mas não houve uma mudança fundamental.

Ao mesmo tempo, a doutrina socialista na qual eles acreditavam era enormemente flexível, assim como a dos esquerdistas de hoje. É a mesma doutrina: uma coleção de slogans que pode ser adaptada para apoiar ou ir contra qualquer outra tese ou ação.

Me parece que a justificativa que eles encontraram para fazer tantas coisas claramente ruins vem dessas mesma flexibilidade. Os atos cruéis estavam todos justificados pela mesma coleção de slogans socialistas de sempre, apenas adaptados às circunstâncias.

Será que uma doutrina mais sólida se prestaria a essas atrocidades? Se concluirmos que a flexibilidade vem da mente e não da doutrina em si, sim, mas não acho que venha daí, porque é sempre o socialismo que é flexível, nunca nenhuma outra doutrina. Ou, na verdade, o socialismo é tão flexível que ele envolve e integra qualquer outra doutrina que seja minimamente compatível.

Talvez a flexibilidade esteja mesmo na mente, mas existe alguma relação entre a mente que desconhece a coerência e a lógica e a mente que se deixa atrair pelos slogans socialistas.

@ 3bf0c63f:aefa459d

microanalytics

A replacement for Google Analytics that run inside a CouchDB, when CouchDB still was a potential platform for hosting of simple apps and easily distribution of apps with data.

It also had a CLI app for browsing the data with nice CLI charts.

• https://github.com/fiatjaf/microanalytics
• https://github.com/fiatjaf/microanalytics-cli

See also

• About CouchDB
• trackingco.de