@ fd06f542:8d6d54cd

今天介绍一个 long-form 项目，源代码在：

https://github.com/dhalsim/nostr-static

从项目的介绍看也是为了展示kind 30023 long-form的。

Demo

https://blog.nostrize.me

界面还可以： {.user-img}

1. 支持多个tags
2. 支持评论

下面看他自己的介绍： nostr-static 是一个开源项目，其主要目的是将 Nostr 网络上的长文内容转化为静态博客。下面从多个方面对该项目进行分析：

1. 项目概述

nostr-static 是一个静态网站生成器（SSG）工具，它可以从 Nostr 网络中获取长文内容，并生成可在任何地方托管的 HTML 页面。这使得用户能够轻松地创建和维护由 Nostr 内容驱动的博客，同时结合了去中心化内容和传统网站托管的优点。

2. 功能特性

• 内容转换：能够将 Nostr 上的长文内容转化为美观的静态博客页面，博客加载速度快。
• 去中心化与传统结合：文章存储在 Nostr 网络上，保证了内容的去中心化，同时为读者提供了熟悉的博客界面。
• 易于维护：通过简单的配置和自动更新功能，降低了博客的维护成本。
• 灵活的托管方式：支持多种静态网站托管服务，如 Netlify、Vercel、Cloudflare Pages、Amazon S3 以及传统的 Web 托管服务。
• 社交互动：可以利用 Nostr 进行评论等社交互动。

3. 技术实现

• 前端：从代码片段可以看出，项目使用了 HTML 和 CSS 来构建页面布局和样式，同时支持明暗两种主题模式。页面包含文章卡片、标签、作者信息等常见博客元素。
• 后端：项目使用 Go 语言编写，通过 go build -o nostr-static ./src && ./nostr-static 命令进行构建和运行。
• 数据获取：从 Nostr 网络中获取文章内容，需要提供 Nostr naddr 信息。

4. 使用步骤

根据 README.md 文件，使用该项目的步骤如下： 1. Fork 项目仓库。 2. 将项目克隆到本地或使用 GitHub Codespaces。 3. 修改 config.yaml 文件进行配置。 4. 在 articles 列表中添加要展示的 Nostr naddr。 5. 将 logo.png 文件放入项目文件夹（如果文件名不同，需要在 config.yaml 中更新）。 6. 构建并运行项目。 7. 提交并推送更改。

5. 项目优势

• 创新性：结合了 Nostr 的去中心化特性和传统博客的易用性，为博主提供了一种新的博客创建方式。
• 简单易用：通过简单的配置和命令即可完成博客的创建和部署，降低了技术门槛。
• 社区支持：开源项目可以吸引更多开发者参与贡献，不断完善功能和修复问题。

nostr-static 是一个有创新性和潜力的项目，为 Nostr 用户提供了一种将长文内容转化为传统博客的有效方式。随着项目的不断发展和完善，有望在博客领域获得更多的关注和应用。

@ 3bf0c63f:aefa459d

Nostr: a quick introduction, attempt #2

Nostr doesn't subscribe to any ideals of "free speech" as these belong to the realm of politics and assume a big powerful government that enforces a common ruleupon everybody else.

Nostr instead is much simpler, it simply says that servers are private property and establishes a generalized framework for people to connect to all these servers, creating a true free market in the process. In other words, Nostr is the public road that each market participant can use to build their own store or visit others and use their services.

(Of course a road is never truly public, in normal cases it's ran by the government, in this case it relies upon the previous existence of the internet with all its quirks and chaos plus a hand of government control, but none of that matters for this explanation).

More concretely speaking, Nostr is just a set of definitions of the formats of the data that can be passed between participants and their expected order, i.e. messages between clients (i.e. the program that runs on a user computer) and relays (i.e. the program that runs on a publicly accessible computer, a "server", generally with a domain-name associated) over a type of TCP connection (WebSocket) with cryptographic signatures. This is what is called a "protocol" in this context, and upon that simple base multiple kinds of sub-protocols can be added, like a protocol for "public-square style microblogging", "semi-closed group chat" or, I don't know, "recipe sharing and feedback".

@ 502ab02a:a2860397

50by40 คืออีกโครงการนึงที่ขยายภาพรวมขึ้นมาอีก recap กันครับ (ใครที่มาเจอกลางทาง อาจต้องย้อนเยอะครับ ย้อนไปสัก ปลายเดือน มีนาคม 2025) หลังจากที่เราได้ดูส่วนเล็กกันมาหลายตอน ตั้งแต่เรื่องเล็กๆอย่าง น้ำมันมะกอกปลอม ซึ่งตอนนั้นหลายคนที่อ่านอาจคิดว่า ไกลตัวส่วนใหญ่ยังดีพอ แต่ความนัยที่ซ่อนไว้ในบทนั้นคือ จุดเริ่มของการทำลายความเชื่อใจในอาหาร , ที่มาของบรอกโคลีเพื่อให้รู้ว่า สิ่งที่คิดว่าธรรมชาติ มันไม่ธรรมชาติ, นมโอ้ต นมประดิษฐ์ที่เป็นจุดที่เราคิดว่ามันคือการพลิกวงการแล้ว, การแอบจดสิทธิบัตรเมล็ดพันธุ์ที่เคยปลูกกินอย่างอิสระ, การพัฒนา GMO 2.0 ที่ไม่ต้องเรียกว่า GMO, โปรตีนจากแลป มาจนถึงเวย์ที่ไม่มีวัว แล้วเราก็ขยายภาพขึ้นกับข้อกำหนดการควบคุมการปลูกพืช UPOV1991/CPTPP, การเข้าสู่โรงเรียน, การกำเนิดของ ProVeg แล้วเราก็ได้รู้จักกับ Sebastian Joy ก็ถือว่าเดินทางมา 1 ด่านแล้วครับ หนทางเรื่องนี้ยังอีกยาวไกล วันนี้เราก็มาคุยกันถึงเรื่อง

โครงการ 50by40

โครงการนี้เริ่มต้นขึ้นในเดือนเมษายน ปี 2018 โดยมีการจัดการประชุม "50by40 Corporate Outreach Summit" ระหว่างวันที่ 27–29 เมษายน 2018 ที่กรุงเบอร์ลิน ประเทศเยอรมนี ซึ่งจัดโดย ProVeg International ร่วมกับ Humane Society of the United States การประชุมนี้ถือเป็นจุดเริ่มต้นของพันธมิตรระดับโลกที่มีเป้าหมายร่วมกันในการลดการผลิตและบริโภคผลิตภัณฑ์จากสัตว์ลง 50% ภายในปี 2040​

Sebastian Joy ผู้ก่อตั้งและประธานของ ProVeg International มีบทบาทสำคัญในการริเริ่มโครงการ 50by40 โดยเขาได้ช่วยก่อตั้งพันธมิตรนี้เพื่อส่งเสริมการเปลี่ยนแปลงระบบอาหารโลก นอกจากนี้ ProVeg International ยังมีบทบาทในการสนับสนุนองค์กรและสตาร์ทอัพที่มุ่งเน้นการเปลี่ยนแปลงระบบอาหารผ่านโปรแกรมต่างๆ

แม้ว่าโครงการ 50by40 จะประกาศเป้าหมายในการลดการบริโภคผลิตภัณฑ์จากสัตว์เพื่อสุขภาพและสิ่งแวดล้อม แต่เบื้องหลังยังมีการดำเนินงานที่มุ่งเน้นการเปลี่ยนแปลงระบบอาหารโลก โดยการส่งเสริม "อาหารที่เพาะเลี้ยงในห้องปฏิบัติการเป็นหลัก​"

โครงการนี้ยังมีการจัดกิจกรรมเพื่อดึงดูดนักลงทุนและผู้สนับสนุนทางการเงิน เช่น การจัดงาน Food Funders Circle ซึ่งเป็นเวทีสำหรับนักลงทุนที่สนใจในอาหารทางเลือก นอกจากนี้ โครงการ 50by40 ยังมีความสัมพันธ์กับองค์กรต่างๆ ทั้งภาครัฐและเอกชน รวมถึงองค์กรระดับนานาชาติ เช่น Greenpeace, WWF และ Compassion in World Farming ซึ่งมีเป้าหมายร่วมกันในการลดการบริโภคผลิตภัณฑ์จากสัตว์ ​และ ProVeg International เองก็มีสถานะเป็นผู้สังเกตการณ์ถาวรในองค์การสหประชาชาติ เช่น UNFCCC, IPCC และ CBD รวมถึงมีสถานะที่ปรึกษาพิเศษกับ ECOSOC และได้รับการรับรองจาก UNEA อีกด้วย ถ้ามองแค่เนทเวิร์คเบื้องต้นแล้ว วินาทีนี้ ตอบได้เลยครับว่า "อาหารที่เพาะเลี้ยงในห้องปฏิบัติการเป็นหลัก​" มาแน่นอนครับ มองข้ามความ plant based / animal based ได้เลย

เพื่อบรรลุเป้าหมายนี้ โครงการได้ดำเนินกิจกรรมต่างๆ ทั้งในระดับโรงเรียนและการผลักดันนโยบายสาธารณะ ผมจะลองแบ่งเป็นข้อๆให้เพื่อความสะดวกในการมองภาพรวมประมาณนี้นะครับ

การดำเนินงานในโรงเรียนและเยาวชน 1. Early Action Network โครงการนี้เป็นความร่วมมือระหว่าง 50by40, ProVeg International และ Educated Choices Program โดยมีเป้าหมายในการส่งเสริมการบริโภคอาหารจากพืชในกลุ่มเด็กและเยาวชนผ่านกิจกรรมต่างๆ เช่น การจัดกิจกรรมเชิงโต้ตอบเกี่ยวกับสุขภาพ สิ่งแวดล้อม และสวัสดิภาพสัตว์, การจัดแคมเปญในโรงเรียนและชุมชน, การเผยแพร่สื่อการเรียนรู้และโปรแกรมฝึกอบรม, การปรับปรุงเมนูอาหารในโรงเรียนให้มีทางเลือกจากพืชมากขึ้น

โครงการนี้มุ่งหวังที่จะสร้างความตระหนักรู้และเปลี่ยนแปลงพฤติกรรมการบริโภคของเยาวชนตั้งแต่เนิ่นๆ เพื่อส่งเสริมการบริโภคอาหารที่ยั่งยืนและเป็นมิตรกับสิ่งแวดล้อม

1. School Plates Programme ProVeg International ได้เปิดตัวโครงการ School Plates ในสหราชอาณาจักรเมื่อปี 2018 โดยมีเป้าหมายในการปรับปรุงเมนูอาหารในโรงเรียนให้มีความหลากหลายและสุขภาพดีขึ้นผ่านการเพิ่มทางเลือกอาหารจากพืช โครงการนี้ได้ร่วมมือกับโรงเรียน หน่วยงานท้องถิ่น และบริษัทจัดเลี้ยง เพื่อเปลี่ยนแปลงเมนูอาหารในโรงเรียนกว่า 3.1 ล้านมื้อจากอาหารที่มีเนื้อสัตว์เป็นหลักไปเป็นอาหารจากพืช

สำหรับในส่วนของการผลักดันนโยบายสาธารณะและการมีส่วนร่วมในเวทีนานาชาตินั้น ก็มีไม่น้อยครับ อาทิเช่น การมีส่วนร่วมในองค์การสหประชาชาติ ProVeg International มีสถานะเป็นผู้สังเกตการณ์ถาวรในองค์การสหประชาชาติ เช่น UNFCCC และ UNEP และได้มีบทบาทในการผลักดันให้มีการรวมประเด็นเกี่ยวกับอาหารจากพืชในการเจรจาด้านสภาพภูมิอากาศ โดยในปี 2022 ProVeg ได้เข้าร่วมการประชุมสภาพภูมิอากาศของสหประชาชาติในสตอกโฮล์มและบอนน์ เพื่อส่งเสริมแนวคิด "Diet Change Not Climate Change" และเรียกร้องให้มีการเปลี่ยนแปลงระบบอาหารสู่การบริโภคอาหารจากพืชมากขึ้น

การสนับสนุนเยาวชนในเวทีนานาชาติ ProVeg ได้จัดตั้ง Youth Board ซึ่งประกอบด้วยเยาวชนจากทั่วโลก เพื่อมีส่วนร่วมในการผลักดันนโยบายด้านอาหารจากพืชในเวทีสหประชาชาติ และเตรียมความพร้อมสำหรับการประชุม COP30 ที่จะจัดขึ้นในเบเลง ประเทศบราซิล

นอกจากนี้ยังมีการสนับสนุนองค์กรและสตาร์ทอัพที่มุ่งเปลี่ยนแปลงระบบอาหารอีกมากมาย โดยที่โดดเด่นเป็นพิเศษคือ โปรแกรม Kickstarting for Good ProVeg International ได้เปิดตัวโปรแกรม Kickstarting for Good ซึ่งเป็นโปรแกรมบ่มเพาะและเร่งการเติบโตสำหรับองค์กรไม่แสวงหาผลกำไร โครงการที่มีผลกระทบ และสตาร์ทอัพทางสังคมที่มุ่งเปลี่ยนแปลงระบบอาหาร โปรแกรมนี้มีระยะเวลา 8 สัปดาห์ โดยมีการฝึกอบรมแบบเข้มข้น การให้คำปรึกษาจากผู้เชี่ยวชาญ และโอกาสในการสร้างเครือข่าย เพื่อสนับสนุนการพัฒนาโครงการที่มีศักยภาพในการลดการบริโภคผลิตภัณฑ์จากสัตว์และส่งเสริมอาหารจากพืช

นอกจาก Sebastian Joy จะเริ่มต้นโครงการต่างๆมากมายไม่ว่าจะ ProVeg International, ProVeg Incubator, Kickstarting for Good แต่ก็ยังมี องค์กรพันธมิตรในเครือข่าย 50by40 ที่หลากหลาย เช่น Plant Powered Metro New York, Public Justice, Rainforest Alliance, Real Food Systems, Reducetarian Foundation, Rethink Your Food, SEED และ Seeding Sovereignty ซึ่งร่วมกันส่งเสริมการบริโภคอาหารจากพืชและการลดการบริโภคผลิตภัณฑ์จากสัตว์ แม้ว่าโครงการ 50by40 จะได้รับการสนับสนุนจากองค์กรต่างๆ อย่างกว้างขวาง แต่ยังไม่มีข้อมูลที่ชัดเจนเกี่ยวกับบริษัทเอกชนรายใดที่แสดงการสนับสนุนโครงการนี้อย่างเปิดเผยครับ

ทีนี้เรามาดูความเคลื่อนไหวของลูกพี่ใหญ่อย่าง USDA กันบ้างนะครับ ​จากการตรวจสอบข้อมูลที่มีอยู่จนถึงปัจจุบัน ยังไม่พบหลักฐานชัดเจนว่า กระทรวงเกษตรสหรัฐฯ (USDA) มีการสนับสนุนโครงการ 50by40 อย่างเป็นทางการหรือเปิดเผย อย่างไรก็ตาม มีความเคลื่อนไหวที่เกี่ยวข้องกับการส่งเสริมโปรตีนทางเลือกและการลดการบริโภคเนื้อสัตว์ในระดับนโยบายของสหรัฐฯ ซึ่งอาจสอดคล้องกับเป้าหมายของโครงการ 50by40 อยู่เช่นกันครับ

ในปี 2021 คณะกรรมาธิการด้านการเกษตรของสภาผู้แทนราษฎรสหรัฐฯ ได้สนับสนุนให้ USDA จัดสรรงบประมาณ 50 ล้านดอลลาร์สหรัฐฯ ผ่านโครงการ Agriculture and Food Research Initiative (AFRI) เพื่อสนับสนุนการวิจัยเกี่ยวกับโปรตีนทางเลือก เช่น การใช้พืช การเพาะเลี้ยงเซลล์ และการหมัก เพื่อพัฒนาอาหารที่มีคุณสมบัติคล้ายเนื้อสัตว์

นอกจากนี้ USDA ได้ยอมรับคำว่า "cell-cultured" เป็นคำที่ใช้เรียกเนื้อสัตว์ที่ผลิตจากการเพาะเลี้ยงเซลล์ในห้องปฏิบัติการ ซึ่งเป็นส่วนหนึ่งของการกำหนดมาตรฐานและการควบคุมผลิตภัณฑ์อาหารใหม่ๆ ที่เกี่ยวข้องกับโปรตีนทางเลือก

แล้วกลุ่มองค์กรด้านสิ่งแวดล้อมและสุขภาพ เช่น Center for Biological Diversity ได้ส่งจดหมายถึงรัฐมนตรีกระทรวงเกษตรสหรัฐฯ เรียกร้องให้ USDA นำประเด็นการลดการบริโภคเนื้อสัตว์และผลิตภัณฑ์นมมาเป็นส่วนหนึ่งของยุทธศาสตร์ด้านสภาพภูมิอากาศ และปรับปรุงแนวทางโภชนาการแห่งชาติให้สอดคล้องกับเป้าหมาย "ด้านความยั่งยืน"

แม้ว่า USDA จะไม่ได้แสดงการสนับสนุนโครงการ 50by40 โดยตรง แต่มีความร่วมมือกับองค์กรที่มีเป้าหมายคล้ายคลึงกัน เช่น ProVeg International และ The Good Food Institute ซึ่งเป็นพันธมิตรในเครือข่ายของ 50by40 โดยมีเป้าหมายในการส่งเสริมการบริโภคอาหารจากการเพาะเลี้ยงเซลล์ในห้องปฏิบัติการและโปรตีนทางเลือก

อนาคตได้มีการขีด Goal ไว้ประมาณนี้ เรายังคิดว่าการที่ "แค่ไม่กินมัน" "ก็แค่เลือกกินอาหารธรรมชาติ" จะยังเป็นคำพูดที่เราพูดได้อีกไหม สิ่งนี้ก็ยังเป็นคำถามต่อไปครับ คงไม่มีใครสามารถตอบได้ใน วันนี้ (มั๊ง)

แต่ที่แน่ๆ มีคนไม่น้อยแล้วแหละครับ ที่บอกว่าอาหารจากแลปคุมในโรงงานที่สะอาด มันก็ดีนี่ สะอาดปลอดภัย ดีกว่าเนื้อหมูที่ผัดข้างทาง ล้างหรือเปล่าก็ไม่รู้ เอาหมูแบบไหนมาก็ไม่รู้

มันดูเหมือนว่าเป็นการเปรียบเปรยแบบตรรกะวิบัตินะครับ แต่รอบตัวคุณ มีคนคิดแบบนี้เยอะไหม? เป็นคำถามที่ไม่มีคำตอบอีกเช่นกันครับ

#pirateketo #กูต้องรู้มั๊ย #ม้วนหางสิลูก #siamstr

@ 3bf0c63f:aefa459d

Why relay hints are important

Recently Coracle has removed support for following relay hints in Nostr event references.

Supposedly Coracle is now relying only on public key hints and kind:10002 events to determine where to fetch events from a user. That is a catastrophic idea that destroys much of Nostr's flexibility for no gain at all.

• Someone makes a post inside a community (either a NIP-29 community or a NIP-87 community) and others want to refer to that post in discussions in the external Nostr world of kind:1s -- now that cannot work because the person who created the post doesn't have the relays specific to those communities in their outbox list;
• There is a discussion happening in a niche relay, for example, a relay that can only be accessed by the participants of a conference for the duration of that conference -- since that relay is not in anyone's public outbox list, it's impossible for anyone outside of the conference to ever refer to these events;
• Some big public relays, say, relay.damus.io, decide to nuke their databases or periodically delete old events, a user keeps using that big relay as their outbox because it is fast and reliable, but chooses to archive their old events in a dedicated archival relay, say, cellar.nostr.wine, while prudently not including that in their outbox list because that would make no sense -- now it is impossible for anyone to refer to old notes from this user even though they are publicly accessible in cellar.nostr.wine;
• There are topical relays that curate content relating to niche (non-microblogging) topics, say, cooking recipes, and users choose to publish their recipes to these relays only -- but now they can't refer to these relays in the external Nostr world of kind:1s because these topical relays are not in their outbox lists.
• Suppose a user wants to maintain two different identities under the same keypair, say, one identity only talks about soccer in English, while the other only talks about art history in French, and the user very prudently keeps two different kind:10002 events in two different sets of "indexer" relays (or does it in some better way of announcing different relay sets) -- now one of this user's audiences cannot ever see notes created by him with their other persona, one half of the content of this user will be inacessible to the other half and vice-versa.
• If for any reason a relay does not want to accept events of a certain kind a user may publish to other relays, and it would all work fine if the user referenced that externally-published event from a normal event, but now that externally-published event is not reachable because the external relay is not in the user's outbox list.
• If someone, say, Alex Jones, is hard-banned everywhere and cannot event broadcast kind:10002 events to any of the commonly used index relays, that person will now appear as banned in most clients: in an ideal world in which clients followed nprofile and other relay hints Alex Jones could still live a normal Nostr life: he would print business cards with his nprofile instead of an npub and clients would immediately know from what relay to fetch his posts. When other users shared his posts or replied to it, they would include a relay hint to his personal relay and others would be able to see and then start following him on that relay directly -- now Alex Jones's events cannot be read by anyone that doesn't already know his relay.

@ c1e6505c:02b3157e

Photography, to me, is a game - a game of snatching absurd, beautiful, fleeting moments from life. Anything staged or overly polished falls into what Garry Winogrand nails as “illustration work.” I’m with him on that. Photography is about staying awake to the world, to the “physical reality” or circumstances we’re steeped in, and burning that light onto film emulsion (or pixels now), locking a moment into matter forever. It’s not like painting, where brushstrokes mimic what’s seen, felt, or imagined. Photography captures photons - light itself - and turns it into something tangible. The camera, honestly, doesn’t get enough credit for being such a wild invention.

Lately, I’ve been chewing on what to do with a batch of new photos I’ve shot over the past month, which includes photographs from a film project, a trip to Manhattan and photos of David Byrne (more on that in another post). Maybe it's another photo-zine that I should make. It’s been a minute since my last one, Hiding in Hudson (https://www.youtube.com/watch?v=O7_t0OldrTk&t=339s). Putting out printed work like zines or books is killer practice — it forces you to sharpen your compositions, your vision, your whole deal as a photographer. Proof of work, you know?

This leads to a question: anyone out there down to help or collab on printing a photo-zine? I’d love to keep it DIY, steering clear of big companies.

In the spirit of getting back into a rhythm of daily shooting, here are a few recent shots from the past few days. Just wandering aimlessly around my neighborhood — bike rides, grocery runs, wherever I end up.

---

Camera used: Leica M262

Edited with: Lightroom + Dehancer Film

*Support my work and the funding for my new zine by sending a few sats: colincz@getalby.com *

@ 3bf0c63f:aefa459d

How to do curation and businesses on Nostr

Suppose you want to start a Nostr business.

You might be tempted to make a closed platform that reuses Nostr identities and grabs (some) content from the external Nostr network, only to imprison it inside your thing -- and then you're going to run an amazing AI-powered algorithm on that content and "surface" only the best stuff and people will flock to your app.

This will be specially good if you're going after one of the many unexplored niches of Nostr in which reading immediately from people you know doesn't work as you generally want to discover new things from the outer world, such as:

• food recipe sharing;
• sharing of long articles about varying topics;
• markets for used goods;
• freelancer work and job offers;
• specific in-game lobbies and matchmaking;
• directories of accredited professionals;
• sharing of original music, drawings and other artistic creations;
• restaurant recommendations
• and so on.

But that is not the correct approach and damages the freedom and interoperability of Nostr, posing a centralization threat to the protocol. Even if it "works" and your business is incredibly successful it will just enshrine you as the head of a platform that controls users and thus is prone to all the bad things that happen to all these platforms. Your company will start to display ads and shape the public discourse, you'll need a big legal team, the FBI will talk to you, advertisers will play a big role and so on.

If you are interested in Nostr today that must be because you appreciate the fact that it is not owned by any companies, so it's safe to assume you don't want to be that company that owns it. So what should you do instead? Here's an idea in two steps:

1. Write a Nostr client tailored to the niche you want to cover

If it's a music sharing thing, then the client will have a way to play the audio and so on; if it's a restaurant sharing it will have maps with the locations of the restaurants or whatever, you get the idea. Hopefully there will be a NIP or a NUD specifying how to create and interact with events relating to this niche, or you will write or contribute with the creation of one, because without interoperability none of this matters much.

The client should work independently of any special backend requirements and ideally be open-source. It should have a way for users to configure to which relays they want to connect to see "global" content -- i.e., they might want to connect to wss://nostr.chrysalisrecords.com/ to see only the latest music releases accredited by that label or to wss://nostr.indiemusic.com/ to get music from independent producers from that community.

1. Run a relay that does all the magic

This is where your value-adding capabilities come into play: if you have that magic sauce you should be able to apply it here. Your service, let's call it wss://magicsaucemusic.com/, will charge people or do some KYM (know your music) validation or use some very advanced AI sorcery to filter out the spam and the garbage and display the best content to your users who will request the global feed from it (["REQ", "_", {}]), and this will cause people to want to publish to your relay while others will want to read from it.

You set your relay as the default option in the client and let things happen. Your relay is like your "website" and people are free to connect to it or not. You don't own the network, you're just competing against other websites on a leveled playing field, so you're not responsible for it. Users get seamless browsing across multiple websites, unified identities, a unified interface (that could be different in a different client) and social interaction capabilities that work in the same way for all, and they do not depend on you, therefore they're more likely to trust you.

---

Does this centralize the network still? But this a simple and easy way to go about the matter and scales well in all aspects.

Besides allowing users to connect to specific relays for getting a feed of curated content, such clients should also do all kinds of "social" (i.e. following, commenting etc) activities (if they choose to do that) using the outbox model -- i.e. if I find a musician I like under wss://magicsaucemusic.com and I decide to follow them I should keep getting updates from them even if they get banned from that relay and start publishing on wss://nos.lol or wss://relay.damus.io or whatever relay that doesn't even know what music is.

The hardcoded defaults and manual typing of relay URLs can be annoying. But I think it works well at the current stage of Nostr development. Soon, though, we can create events that recommend other relays or share relay lists specific to each kind of activity so users can get in-app suggestions of relays their friends are using to get their music from and so on. That kind of stuff can go a long way.

@ d1e87ba1:6adce0f2

K68 là một nền tảng giải trí trực tuyến mới mẻ, được phát triển để mang lại những trải nghiệm thú vị và đa dạng cho người dùng. Với giao diện thân thiện và dễ sử dụng, K68 không chỉ là nơi giải trí mà còn là không gian kết nối, giao lưu giữa những người có cùng sở thích và đam mê. Nền tảng này cung cấp nhiều dịch vụ giải trí hấp dẫn, từ các trò chơi trực tuyến, chương trình truyền hình cho đến các sự kiện trực tiếp. K68 được tối ưu hóa cho cả điện thoại di động và máy tính, cho phép người dùng truy cập mọi lúc, mọi nơi một cách dễ dàng. Điều đặc biệt ở K68 là sự chú trọng đến tính năng cá nhân hóa, giúp người dùng có thể tùy chỉnh giao diện và các dịch vụ phù hợp với sở thích cá nhân. Điều này không chỉ mang lại sự tiện lợi mà còn giúp người dùng cảm thấy thoải mái và hài lòng khi tham gia vào nền tảng này.

K68 cũng đặc biệt chú trọng đến việc xây dựng một cộng đồng giải trí trực tuyến mạnh mẽ và gắn kết. Các tính năng tương tác, như trò chuyện trực tuyến, tạo nhóm thảo luận, tham gia sự kiện trực tuyến đều được tích hợp để giúp người dùng dễ dàng kết nối và chia sẻ với nhau. Nền tảng này không chỉ là nơi để giải trí mà còn là không gian để người dùng thể hiện bản thân và giao lưu với những người có cùng sở thích. Các chương trình và sự kiện được tổ chức thường xuyên không chỉ mang đến cơ hội giải trí mà còn tạo ra những sân chơi thú vị cho cộng đồng. Đặc biệt, K68 cũng chú trọng đến việc cung cấp các trò chơi sáng tạo và thú vị, giúp người chơi giải trí một cách thư giãn nhưng cũng không kém phần hấp dẫn. Điều này giúp K68 tạo nên một cộng đồng năng động, nơi mà người dùng không chỉ tìm thấy sự giải trí mà còn có thể học hỏi, giao lưu và kết nối.

Một yếu tố quan trọng khác khiến K68 trở thành nền tảng được yêu thích là tính năng bảo mật vượt trội. Nền tảng này sử dụng công nghệ bảo mật tiên tiến để bảo vệ thông tin người dùng, đảm bảo rằng mọi dữ liệu cá nhân đều được mã hóa và lưu trữ an toàn. Người dùng có thể hoàn toàn yên tâm khi tham gia các hoạt động trên K68, vì nền tảng này luôn nỗ lực đảm bảo bảo mật và quyền riêng tư tuyệt đối. K68 cũng đặc biệt chú trọng đến việc bảo vệ quyền lợi của người dùng và đảm bảo rằng mọi giao dịch, thông tin cá nhân đều được xử lý một cách cẩn thận. Bên cạnh đó, tính năng cá nhân hóa của K68 cho phép người dùng dễ dàng tùy chỉnh các dịch vụ và giao diện, giúp mỗi người dùng có thể tận hưởng trải nghiệm giải trí theo cách riêng của mình. Với cam kết bảo mật, tính năng sáng tạo không ngừng và một cộng đồng giải trí sôi động, K68 đang dần khẳng định vị thế của mình là một trong những nền tảng giải trí trực tuyến hàng đầu, được người dùng yêu thích và tin tưởng.

@ d1e87ba1:6adce0f2

ZINGME là một nền tảng giải trí trực tuyến nổi bật, thu hút sự quan tâm của đông đảo người dùng nhờ vào những tính năng vượt trội và giao diện dễ sử dụng. Được phát triển để mang đến không gian giải trí phong phú và sáng tạo, ZINGME cung cấp một loạt các dịch vụ giải trí hấp dẫn, từ âm nhạc, video cho đến các chương trình trực tuyến và trò chơi. ZINGME không chỉ đơn thuần là một công cụ giải trí mà còn là nơi giúp người dùng kết nối, chia sẻ và thể hiện bản thân. Với thiết kế giao diện tối ưu, nền tảng này mang lại trải nghiệm mượt mà và không gặp phải bất kỳ khó khăn nào, cho phép người dùng dễ dàng truy cập và tận hưởng những nội dung yêu thích. Dù bạn đang sử dụng máy tính hay điện thoại thông minh, ZINGME đều mang đến một trải nghiệm trực tuyến tuyệt vời và tiện lợi, phù hợp với nhu cầu của mọi đối tượng người dùng.

Bên cạnh những tính năng giải trí đa dạng, ZINGME đặc biệt chú trọng đến việc xây dựng một cộng đồng trực tuyến mạnh mẽ. Nền tảng này cung cấp cho người dùng nhiều công cụ tương tác, giúp họ kết nối và giao lưu với nhau. Các tính năng như trò chuyện trực tiếp, nhóm thảo luận, chia sẻ ý tưởng, và tham gia vào các sự kiện trực tuyến đều được tích hợp một cách thông minh và hiệu quả. ZINGME không chỉ tạo ra một không gian giải trí mà còn là nơi để người dùng xây dựng những mối quan hệ mới, kết nối với những người có cùng sở thích và đam mê. Các công cụ sáng tạo cũng được cung cấp đầy đủ để người dùng có thể tự do thể hiện bản thân qua việc tạo ra các nội dung như bài viết, video, hoặc tham gia các cuộc thi. Chính sự kết hợp giữa giải trí và tính năng xã hội này đã tạo ra một cộng đồng ZINGME sống động và luôn phát triển, nơi mà mọi người có thể chia sẻ, học hỏi và kết nối với nhau một cách tự nhiên.

Bảo mật và quyền riêng tư là một yếu tố quan trọng mà ZINGME luôn chú trọng. Với sự phát triển mạnh mẽ của công nghệ, nền tảng này đã đầu tư vào các biện pháp bảo mật tiên tiến để bảo vệ thông tin người dùng khỏi các nguy cơ từ thế giới mạng. Mọi dữ liệu cá nhân của người dùng đều được mã hóa và lưu trữ một cách an toàn, giúp người tham gia yên tâm khi sử dụng các dịch vụ của ZINGME. Nền tảng này cũng cung cấp các tính năng cá nhân hóa, giúp người dùng tùy chỉnh giao diện và các dịch vụ theo sở thích và nhu cầu riêng của mình. Điều này không chỉ mang lại một trải nghiệm giải trí thú vị mà còn giúp mỗi người dùng cảm thấy thoải mái và an toàn khi tham gia vào cộng đồng ZINGME. Với cam kết bảo vệ quyền riêng tư, sự sáng tạo không ngừng và cộng đồng tương tác mạnh mẽ, ZINGME đang từng bước khẳng định vị thế của mình là một trong những nền tảng giải trí trực tuyến hàng đầu tại Việt Nam.

@ 3bf0c63f:aefa459d

About Nostr, email and subscriptions

I check my emails like once or twice a week, always when I am looking for something specific in there.

Then I go there and I see a bunch of other stuff I had no idea I was missing. Even many things I wish I had seen before actually. And sometimes people just expect and assume I would have checked emails instantly as they arrived.

It's so weird because I'm not making a point, I just don't remember to open the damn "gmail.com" URL.

---

I remember some people were making some a Nostr service a while ago that sent a DM to people with Nostr articles inside -- or some other forms of "subscription services on Nostr". It makes no sense at all.

Pulling in DMs from relays is exactly the same process (actually slightly more convoluted) than pulling normal public events, so why would a service assume that "sending a DM" was more likely to reach the target subscriber when the target had explicitly subscribed to that topic or writer?

Maybe due to how some specific clients work that is true, but fundamentally it is a very broken assumption that comes from some fantastic past era in which emails were 100% always seen and there was no way for anyone to subscribe to someone else's posts.

Building around such broken assumptions is the wrong approach. Instead we should be building new flows for subscribing to specific content from specific Nostr-native sources (creators directly or manual or automated curation providers, communities, relays etc), which is essentially what most clients are already doing anyway, but specifically Coracle's new custom feeds come to mind now.

---

This also reminds me of the interviewer asking the Farcaster creator if Farcaster made "email addresses available to content creators" completely ignoring all the cryptography and nature of the protocol (Farcaster is shit, but at least they tried, and in this example you could imagine the interviewer asking the same thing about Nostr).

I imagine that if the interviewer had asked these people who were working (or suggesting) the Nostr DM subscription flow they would have answered: "no, you don't get their email addresses, but you can send them uncensorable DMs!" -- and that, again, is getting everything backwards.

@ d1e87ba1:6adce0f2

SUN789 là một nền tảng giải trí trực tuyến được thiết kế để mang đến cho người dùng những trải nghiệm đa dạng và đầy thú vị. Với giao diện dễ sử dụng, nền tảng này cho phép người dùng tiếp cận các dịch vụ giải trí, trò chơi và chương trình yêu thích một cách dễ dàng. SUN789 không chỉ chú trọng vào việc phát triển các tính năng giải trí mà còn đặc biệt quan tâm đến việc xây dựng một hệ sinh thái liên kết mạnh mẽ, nơi người dùng có thể kết nối, chia sẻ và tương tác với nhau. Giao diện của SUN789 được tối ưu hóa cho cả thiết bị di động và máy tính, giúp người dùng dễ dàng truy cập và sử dụng bất kể thời gian hay địa điểm. Không chỉ vậy, SUN789 còn liên tục cập nhật và cải tiến các tính năng để đáp ứng nhu cầu ngày càng cao của người dùng. Điều này không chỉ mang lại sự tiện lợi mà còn giúp nền tảng duy trì sự cạnh tranh trong một thị trường giải trí trực tuyến đầy tiềm năng.

Một trong những điểm nổi bật của SUN789 chính là sự đa dạng trong các lựa chọn giải trí mà nền tảng này cung cấp. Từ các chương trình âm nhạc, phim ảnh, thể thao đến những trò chơi hấp dẫn, SUN789 luôn nỗ lực để đáp ứng nhu cầu giải trí của tất cả người dùng. Các chương trình phát trực tuyến liên tục được cập nhật với nội dung mới mẻ và đa dạng, đảm bảo mang đến những giây phút thư giãn tuyệt vời cho người dùng. Đặc biệt, các trò chơi giải trí trên nền tảng này luôn được cải tiến về mặt đồ họa và tính năng, giúp người chơi có thể trải nghiệm những giây phút thư giãn thú vị. Hệ thống trò chơi của SUN789 không chỉ đơn giản là các trò chơi giải trí thông thường mà còn bao gồm những trò chơi chiến thuật, thể thao và các loại hình giải trí sáng tạo khác. Nền tảng này cũng thường xuyên tổ chức các sự kiện, cuộc thi để người dùng có thể tham gia và nhận được nhiều phần thưởng hấp dẫn, tạo thêm động lực cho người tham gia.

SUN789 đặc biệt chú trọng đến vấn đề bảo mật và quyền riêng tư của người dùng, đảm bảo một không gian giải trí an toàn và tin cậy. Với công nghệ bảo mật tiên tiến, nền tảng này cam kết bảo vệ thông tin cá nhân và giao dịch của người dùng khỏi các mối nguy hại từ không gian mạng. Mọi thông tin cá nhân đều được mã hóa và bảo vệ nghiêm ngặt, giúp người dùng yên tâm khi tham gia vào các hoạt động trên nền tảng. Hệ thống bảo mật của SUN789 luôn được cập nhật để đối phó với các mối đe dọa mới, đảm bảo rằng thông tin người dùng luôn được bảo vệ tuyệt đối. Ngoài ra, nền tảng này cũng cung cấp các tính năng cá nhân hóa, cho phép người dùng tùy chỉnh giao diện và các dịch vụ theo sở thích cá nhân. Điều này giúp mỗi người dùng có được một trải nghiệm giải trí hoàn hảo, phù hợp với nhu cầu riêng của mình. Với những cam kết về bảo mật, tính năng đa dạng và dịch vụ chăm sóc khách hàng tận tình, SUN789 đang dần trở thành lựa chọn hàng đầu của người dùng trên thị trường giải trí trực tuyến hiện nay.

@ 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

@ 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.

@ 4cebd4f5:0ac3ed15

TỔNG QUAN HACKATHON

Hedera Hashathon: Nairobi Edition vừa khép lại với 223 developer tham gia và 49 dự án được phê duyệt. Tổ chức trực tuyến bởi Kenya Tech Events, Sở Giao dịch Chứng khoán Nairobi (NSE) và Phòng Tài sản Ảo (Virtual Assets Chamber), sự kiện hướng đến thúc đẩy đổi mới địa phương và gia tăng ứng dụng blockchain tại Kenya.

Hackathon tập trung vào 3 track chính: AI Agents (Trí tuệ nhân tạo), Capital Markets (Thị trường vốn) và Hedera Explorer. Các đội thi ứng dụng blockchain Hedera để giải quyết thách thức về tự động hóa, tiếp cận tài chính và tương tác tài sản số. Điểm nhấn là Demo Day tại Đại học Nairobi – nơi các dự án vào chung kết trình diễn giải pháp và nhận giải thưởng. Nhóm xuất sắc nhất (đặc biệt từ track Capital Markets) được hỗ trợ ươm tạo và mentorship để phát triển tiếp.

Với trọng tâm ứng dụng thực tiễn, sự kiện khẳng định tiềm năng biến đổi ngành công nghiệp Kenya của blockchain, thúc đẩy tiến bộ công nghệ và mở rộng thị trường.

CÁC DỰ ÁN ĐOẠT GIẢI

Giải Nhất

• Hedgehog: Giao thức cho vay trên chuỗi, sử dụng cổ phiếu sàn chứng khoán được token hóa trên Hedera làm tài sản thế chấp. Kết hợp tính minh bạch blockchain với thế chấp truyền thống, đảm bảo an toàn và phi tập trung.

Giải Nhì

• Orion: Đơn giản hóa giao dịch cổ phiếu NSE (Nairobi) bằng cách token hóa chúng trên Hedera. Tích hợp Mpesa (ví điện tử hàng đầu Kenya) để tối ưu quy trình giao dịch số.

Giải Ba

• NSEChainBridge: Nền tảng blockchain nâng cao giao dịch cổ phiếu NSE dưới dạng token số, cải thiện khả năng tiếp cận và thanh khoản thị trường.

Giải Tư

• HashGuard: Nền tảng bảo hiểm vi mô token hóa dành cho tài xế boda boda (xe máy chở khách), ứng dụng công nghệ Hedera Hashgraph. Cung cấp bảo hiểm giá rẻ, tức thì – không yêu cầu kiến thức blockchain.

Xem toàn bộ dự án tại Danh sách BUIDL.

THÔNG TIN VỀ ĐƠN VỊ TỔ CHỨC: HEDERA

Hedera – nền tảng sổ cái phân tán công khai, nổi tiếng nhờ tốc độ, bảo mật và khả năng mở rộng. Thuật toán đồng thuận hashgraph (biến thể của Proof of Stake) mang lại cách tiếp cận độc đáo để đạt đồng thuận phi tập trung. Hedera hoạt động đa ngành, hỗ trợ dự án tập trung vào minh bạch và hiệu quả. Tổ chức cam kết phát triển cơ sở hạ tầng mạng lưới phi tập trung, thúc đẩy giao dịch số an toàn toàn cầu.

@ 0e67f053:cb1d4b93

How to Be an Anti-Fascist

According to Me, a Certified Organic Latte-Drinking Empathy Warrior

By Tucker Carlson’s Emotionally Available Clone Carl Tuckerson

Namaste, comrades.

Are you tired of watching democracy get mildly inconvenienced by billionaires while sipping your ethically sourced, $19 oat milk flat white? Do you sometimes feel like tweeting just isn’t enough to stop the slow, fascist creep of boomers with opinions?

Well, worry not. Because tonight, I, a glowing beacon of progressive perfection, will guide you through the sacred, carbon-neutral art of being an Anti-Fascist—from the comfort of your iPad, handcrafted from rare earth minerals mined by literal children.

Let’s begin.

Step 1: Declare Yourself Anti-Fascist... On Instagram.

Nothing says “resistance” quite like a filtered selfie captioned “Punching Nazis with love 💕✊ #Resist #SelfCareRevolution”. Bonus points if you’re wearing a Che Guevara shirt made in a sweatshop. Because nothing defeats authoritarianism like aesthetics.

Remember: optics over action. Always.

Step 2: Elon Musk Is Literally Hitler (Until He Makes a Space Weed Dispensary)

We used to love Elon. He was our quirky space daddy. He tweeted in lowercase. He smoked weed with Joe Rogan. He wore weird shoes. We loved that. Then he bought Twitter and suddenly—BOOM—he’s literally Benito Mussolini with better branding.

But hey, let’s be honest: if he announced a carbon-neutral Neuralink that dispenses vegan Adderall, we’d be back on the bandwagon so fast. We are morally opposed to fascism... unless it syncs with our Apple Watches.

Step 3: Donald Trump Is an Existential Threat (Also... Kinda Fun to Keep Around)

Yes, Trump is a threat to democracy. Yes, he incited an insurrection. Yes, he talks like a Big Mac with a head injury. But if we actually stopped him? What would we tweet about?

He’s the villain we love to hate. He’s like Voldemort, if Voldemort ran on cheeseburgers and late-stage narcissism. He’s our algorithmic muse. He’s content.

Let’s not pretend we didn’t low-key enjoy four years of outrage-fueled identity formation. He gave us purpose. He gave us merch. Admit it—you miss him a little. That’s not anti-fascism, babe. That’s codependence.

Step 4: Say “Fascism” a Lot. Define It? Not So Much.

When in doubt, call literally anything “fascism.” Voter ID laws? Fascism. Gas stoves? Fascism. Someone didn’t like your TikTok about polyamorous Marxism? Fascism.

Defining the word would ruin the fun. It’s like “vibes,” but with historical trauma. Why read a book when you can just compare everything to Hitler and get 12,000 retweets?

Remember: if you say “fascism” enough times, you don’t have to actually do anything about it.

Step 5: Be Loud. Be Online. Be Ironic.

Who needs grassroots organizing when you can “dunk on fascists” in the quote tweets? Nothing defeats authoritarianism like being aggressively smug with a PFP of a frog holding a Molotov cocktail.

Marching in the streets? Mutual aid? Local elections?

Cringe.

Let’s just post a meme of Trump hugging Mussolini with a caption that says, “When your fascist BF also texts other regimes 🥺👉👈.”

Final Thoughts (Because I Have So Many)

Being an anti-fascist in 2025 is hard. You have to juggle being morally superior, chronically online, and vaguely condescending all at once. But if we just stay in our bubbles, talk over each other on Clubhouse, and continue to believe that irony is activism, we’ll totally defeat fascism.

Eventually.

Maybe.

After brunch.

Stay performative. Stay smug. Stay revolution-adjacent.

We’ll see you tomorrow—for another episode of "The Whisper of Democracy", where we dismantle empires with emotional vulnerability and artisanal zines.

Namaste, but make it confrontational.

— Delusionally Chill Carl

originally posted at https://stacker.news/items/967043

@ 3bf0c63f:aefa459d

Nostr: a quick introduction, attempt #1

Nostr doesn't have a material existence, it is not a website or an app. Nostr is just a description what kind of messages each computer can send to the others and vice-versa. It's a very simple thing, but the fact that such description exists allows different apps to connect to different servers automatically, without people having to talk behind the scenes or sign contracts or anything like that.

When you use a Nostr client that is what happens, your client will connect to a bunch of servers, called relays, and all these relays will speak the same "language" so your client will be able to publish notes to them all and also download notes from other people.

That's basically what Nostr is: this communication layer between the client you run on your phone or desktop computer and the relay that someone else is running on some server somewhere. There is no central authority dictating who can connect to whom or even anyone who knows for sure where each note is stored.

If you think about it, Nostr is very much like the internet itself: there are millions of websites out there, and basically anyone can run a new one, and there are websites that allow you to store and publish your stuff on them.

The added benefit of Nostr is that this unified "language" that all Nostr clients speak allow them to switch very easily and cleanly between relays. So if one relay decides to ban someone that person can switch to publishing to others relays and their audience will quickly follow them there. Likewise, it becomes much easier for relays to impose any restrictions they want on their users: no relay has to uphold a moral ground of "absolute free speech": each relay can decide to delete notes or ban users for no reason, or even only store notes from a preselected set of people and no one will be entitled to complain about that.

There are some bad things about this design: on Nostr there are no guarantees that relays will have the notes you want to read or that they will store the notes you're sending to them. We can't just assume all relays will have everything — much to the contrary, as Nostr grows more relays will exist and people will tend to publishing to a small set of all the relays, so depending on the decisions each client takes when publishing and when fetching notes, users may see a different set of replies to a note, for example, and be confused.

Another problem with the idea of publishing to multiple servers is that they may be run by all sorts of malicious people that may edit your notes. Since no one wants to see garbage published under their name, Nostr fixes that by requiring notes to have a cryptographic signature. This signature is attached to the note and verified by everybody at all times, which ensures the notes weren't tampered (if any part of the note is changed even by a single character that would cause the signature to become invalid and then the note would be dropped). The fix is perfect, except for the fact that it introduces the requirement that each user must now hold this 63-character code that starts with "nsec1", which they must not reveal to anyone. Although annoying, this requirement brings another benefit: that users can automatically have the same identity in many different contexts and even use their Nostr identity to login to non-Nostr websites easily without having to rely on any third-party.

To conclude: Nostr is like the internet (or the internet of some decades ago): a little chaotic, but very open. It is better than the internet because it is structured and actions can be automated, but, like in the internet itself, nothing is guaranteed to work at all times and users many have to do some manual work from time to time to fix things. Plus, there is the cryptographic key stuff, which is painful, but cool.

@ 99895004:c239f905

Yes, FINALLY, we are extremely excited to announce support for nostr.build (blossom.band) on Primal! Decades in the making, billions of people have been waiting, and now it’s available! But it’s not just any integration, it is the next level of decentralized media hosting for Nostr. Let us explain.

Primal is an advanced Twitter/X like client for Nostr and is probably the fastest up-and-coming, highly used Nostr app available for iOS, Android and the web. Nostr.build is a very popular media hosting service for Nostr that can be used standalone or integrated into many Nostr apps using nip-96. This is an extremely feature rich, tested and proven integration we recommend for most applications, but it’s never been available on Primal.

And then, Blossom was born, thank you Hzrd149! Blossom is a Nostr media hosting protocol that makes it extremely easy for Nostr clients to integrate a media host, and for users of Blossom media hosts (even an in-house build) to host on any Nostr client. Revolutionary, right! Use whatever host you want on any client you want, the flexible beauty of Nostr. But there is an additional feature to Blossom that is key, mirroring.

One of the biggest complaints to media hosting on Nostr is, if a media hosting service goes down, so does all of the media hosted on that service. No bueno, and defeats the whole decentralized idea behind Nostr.. This has always been a hard problem to solve until Blossom mirroring came along. Mirroring allows a single media upload to be hosted on multiple servers using its hash, or unique media identifier. This way, if a media host goes down, the media is still available and accessible on the other host.

So, we are not only announcing support of nostr.build’s blossom.band on the Primal app, we are also announcing the first known fully integrated implementation of mirroring with multiple media hosts on Nostr. Try it out for yourself! Go to the settings of your Primal web, iOS or Android app, choose ‘Media Servers’, enable ‘Media Mirrors’, and add https://blossom.band and https://blossom.primal.net as your Media server and Mirror, done!

Video here!

@ 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.

@ d9a329af:bef580d7

Since 2022, Dungeons and Dragons has been going down a sort of death spiral after the release of a revised version of 5th Edition... which didn't turn out very well to say the least. In light of that, I present a list of TTRPGs you can play if you don't want to purchase 5E. I wouldn't recommend 5E, as I've DM'd it in the past. It tastes like a lollipop that's cockroach and larvae flavored.

This list of TTRPG games is in no particular order, though my favorite of these systems is number one.

1. Basic Fantasy Role-Playing Game (BFRPG)
2. B/X-style OSR retroclone with ascending armor class, and the original retroclone from 2006
3. Fully libre under CC BY-SA for the 4th Edition, and OGL 1.0a for 1-3 Editions.
4. Full books are free PDF files on the website (Basic Fantasy Website)
5. All BFRPG editions are compatible with each other, meaning you can have a 3rd Edition book to a 4th Edition game and still have fun. 4th Edition is just the removal of the 3E SRD that's in the OGL editions.
6. As with the core rulebooks, all the supplementation is free as a PDF as well, though you can buy physical books at cost (BFRPG principal rights holder Chris Gonnerman doesn't make much profit from Basic Fantasy)
7. Old-school community that's an all-around fantastic group of players, authors and enthusiasts.

8. Fun Fact: Out of all the TTRPGs I'd want to DM/GM the most, it'd be this one by far.

9. Iron Falcon (IF)

10. OD&D-style retroclone from 2015 (It's also by Gonnerman, same guy behind BFRPG)
11. A close ruleset to the White Box rules and supplements
12. Also fully libre under CC BY-SA for the latest releases, just like BFRPG for 4th Edition releases
13. Just like BFRPG, the core rules and supplementation come as PDF files for free, or physical books.

14. Fast and loose ruleset open to interpretation, just like in 1975-1981... somewhere right around that timeline for OD&D

15. Old-School Reference and Index Compendium (OSRIC)

16. AD&D 1E-based retroclone by Stewart Marshall and Matt Finch
17. An old system that surprisingly still holds up, even after a long time of no new versions of the rules
18. Extremely in-depth ruleset, licensed under OGL 1.0a and OSRIC Open License
19. Compatible with AD&D 1e modules for the 1st Edition, though 2.2 potentially has its own supplementation

20. I don't know much about it, as I'd be too slow to learn it. That's all I know, which is the above.

21. Ironsworn

22. Custom loosely-based PbtA (Powered by the Apocalypse) system by Shawn Tomkin from 2018
23. Includes GM, GMless and solo play in the rulebook
24. Supplementation is surely something else with one look at the downloads section for the PDFs of the original, which is free under CC BY-NC-SA. The SRD is under CC BY otherwise.
25. No original adventures are made for this system as are known, as it's expected that the Ironlands are where they take place

26. Fun Fact: This was a non-D&D system I considered running as a GM.

27. Advanced Dungeons & Dragons 2nd Edition (AD&D 2e)

28. An official edition from 1989-2000
29. At the time, the most customizable edition in its history, before 3E took the spot as the most customizable edition
30. A streamlined revision of the AD&D 1E rules (AD&D 1E was exclusively written by E. Gary Gygax)
31. The end of old-school D&D, as 3E and beyond are different games altogether
32. Wide array of supplementation, which oversaturated 2E's customization... and most of it didn't sell well as a result
33. Final TSR-published edition of D&D, as they went bankrupt and out of business during this edition's life cycle, to then be liquidated to Wizards of the Coast (Boy did WOTC mess it up once 5.1E was released)

34. Fun Fact: A Canadian history professor named Dr. Robert Wardough runs a customized ruleset using 2E as a base, which he's been DMing since the 80's during the "Satanic Panic" (The Satanic Panic was fake as a result of horrible deceivers gaslighting people to not play D&D). He started RAW (Rules as Written), but saw some things he needed to change for his games, so he did so over time.

35. Moldvay/Cook Basic/Expert Dungeons & Dragons (B/X)

36. Competing system to 1E from 1981 and 1982
37. Official edition of D&D, part of the old-school era
38. Simplified rules for Basic, but some decently complex rules for Expert
39. Only goes up to Lv. 14, as it's potentially a 1E or White Box primer (similar to 1977 Basic)
40. Supplementation, from some research done, was decent for the time, and a little bit extensive
41. The inspiration for BFRPG in 2006 (Did I mention this already? Maybe I have, but I might emphasize that here too.)

42. Fun Fact: I considered running B/X, but decided that I'd do BFRPG, as the ascending armor class is easier math than with B/X and the THAC0 armor class (descending armor class).

43. Basic, Expert, Companion, Master, Immortal Dungeons & Dragons (BECMI) and/or Rules Cyclopedia

44. 1983 variant of the Moldvay/Cook Basic/Expert system, an official edition and part of the old-school era
45. Essentially, 1981 B/X D&D on steroids
46. 5 boxed sets were released for the five parts of the rules for this system
47. Rules Cyclopedia is a reprint of the 1983 Basic, Expert, Companion and Master rules boxed sets. The Immortal set was never reprinted outside of the original boxed set because Immortal is such a bizarre game within a game altogether.
48. With the first 4 boxed sets (whether individual sets or the Rules Cyclopedia), levels are 1-36

49. Fun Fact: This edition I was considering DMing as well, alongside BFRPG. They're similar rulesets with some mechanical differences, but I think either or would be worth it.

50. Original Dungeons & Dragons (OD&D or White Box)

51. The original release of D&D from 1974 written by Gygax and Dave Arneson, published by TSR
52. Uses the rules from Chainmail, a wargame made by Gygax and Jeff Perren
53. Base has three little booklets (Men & Magic, Monsters & Magic, and The Underworld & Wilderness Adventures), five official supplements were released (Greyhawk; Blackmoor; Eldritch Wizardry; Gods, Demi-Gods and Heroes; and Swords & Spells), and many more from fanzines
54. Fast and loose ruleset open to interpretation
55. Not based upon adventurers taking on dangerous quest, but kings commanding armies (which is why OD&D is actually a Chainmail supplement). The latter was the original purpose of D&D before it got changed in 2000.

There are many more games that are not D&D that you can look up too. See what you like, read the rules, learn them, and start playing with your group. Have fun and slay some monsters!

@ 3bf0c63f:aefa459d

Anglicismos estúpidos no português contemporâneo

Palavras e expressões que ninguém deveria usar porque não têm o sentido que as pessoas acham que têm, são apenas aportuguesamentos de palavras inglesas que por nuances da história têm um sentido ligeiramente diferente em inglês.

Cada erro é acompanhado também de uma sugestão de como corrigi-lo.

Palavras que existem em português com sentido diferente

• submissão (de trabalhos): envio, apresentação
• disrupção: perturbação
• assumir: considerar, pressupor, presumir
• realizar: perceber
• endereçar: tratar de
• suporte (ao cliente): atendimento
• suportar (uma idéia, um projeto): apoiar, financiar
• suportar (uma função, recurso, característica): oferecer, ser compatível com
• literacia: instrução, alfabetização
• convoluto: complicado.
• acurácia: precisão.
• resiliência: resistência.

Aportuguesamentos desnecessários

• estartar: iniciar, começar
• treidar: negociar, especular

Expressões

• "não é sobre...": "não se trata de..."

Ver também

• Algumas expressões e ditados excelentes da língua portuguesa, e outras não tão excelentes assim

@ 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

@ be063e14:06d214ce

hallo welt

[[ ]] Add as many elements as you want? [[X]] The X marks the correct answer! [[ ]] ... this is wrong ... [[X]] ... this has to be selected too ...

daten können auch, ich meine multimedia ... übertragen werden ...

@ dc814bb0:7a410cb5

hallo welt

[[ ]] Add as many elements as you want? [[X]] The X marks the correct answer! [[ ]] ... this is wrong ... [[X]] ... this has to be selected too ...

@ 3bf0c63f:aefa459d

bitcoind decentralization

It is better to have multiple curator teams, with different vetting processes and release schedules for bitcoind than a single one.

"More eyes on code", "Contribute to Core", "Everybody should audit the code".

All these points repeated again and again fell to Earth on the day it was discovered that Bitcoin Core developers merged a variable name change from "blacklist" to "blocklist" without even discussing or acknowledging the fact that that innocent pull request opened by a sybil account was a social attack.

After a big lot of people manifested their dissatisfaction with that event on Twitter and on GitHub, most Core developers simply ignored everybody's concerns or even personally attacked people who were complaining.

The event has shown that:

1) Bitcoin Core ultimately rests on the hands of a couple maintainers and they decide what goes on the GitHub repository[^pr-merged-very-quickly] and the binary releases that will be downloaded by thousands; 2) Bitcoin Core is susceptible to social attacks; 2) "More eyes on code" don't matter, as these extra eyes can be ignored and dismissed.

Solution: bitcoind decentralization

If usage was spread across 10 different bitcoind flavors, the network would be much more resistant to social attacks to a single team.

This has nothing to do with the question on if it is better to have multiple different Bitcoin node implementations or not, because here we're basically talking about the same software.

Multiple teams, each with their own release process, their own logo, some subtle changes, or perhaps no changes at all, just a different name for their bitcoind flavor, and that's it.

Every day or week or month or year, each flavor merges all changes from Bitcoin Core on their own fork. If there's anything suspicious or too leftist (or perhaps too rightist, in case there's a leftist bitcoind flavor), maybe they will spot it and not merge.

This way we keep the best of both worlds: all software development, bugfixes, improvements goes on Bitcoin Core, other flavors just copy. If there's some non-consensus change whose efficacy is debatable, one of the flavors will merge on their fork and test, and later others -- including Core -- can copy that too. Plus, we get resistant to attacks: in case there is an attack on Bitcoin Core, only 10% of the network would be compromised. the other flavors would be safe.

Run Bitcoin Knots

The first example of a bitcoind software that follows Bitcoin Core closely, adds some small changes, but has an independent vetting and release process is Bitcoin Knots, maintained by the incorruptible Luke DashJr.

Next time you decide to run bitcoind, run Bitcoin Knots instead and contribute to bitcoind decentralization!

---

See also:

• How to attack Bitcoin, Anthony Towns' take

[^pr-merged-very-quickly]: See PR 20624, for example, a very complicated change that could be introducing bugs or be a deliberate attack, merged in 3 days without time for discussion.

@ dc814bb0:7a410cb5

Hallo welt

[[ ]] Add as many elements as you want? [[X]] The X marks the correct answer! [[ ]] ... this is wrong ... [[X]] ... this has to be selected too ...

@ 43aec65f:003ef459

test

!?

@ 3bf0c63f:aefa459d

início

"Vocês vêem? Vêem a história? Vêem alguma coisa? Me parece que estou tentando lhes contar um sonho -- fazendo uma tentativa inútil, porque nenhum relato de sonho pode transmitir a sensação de sonho, aquela mistura de absurdo, surpresa e espanto numa excitação de revolta tentando se impôr, aquela noção de ser tomado pelo incompreensível que é da própria essência dos sonhos..."

Ele ficou em silêncio por alguns instantes.

"... Não, é impossível; é impossível transmitir a sensação viva de qualquer época determinada de nossa existência -- aquela que constitui a sua verdade, o seu significado, a sua essência sutil e contundente. É impossível. Vivemos, como sonhamos -- sozinhos..."

• Livros mencionados por Olavo de Carvalho
• Antiga homepage Olavo de Carvalho
• Bitcoin explicado de um jeito correto e inteligível
• Reclamações

---

• Nostr
• Bitcoin
• How IPFS is broken
• Programming quibbles
• Economics
• Open-source software

---

Nostr GitHub Telegram Donate

@ 93e8ebba:1075c629

test

@ 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

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

@ 3a8a16a7:f4c3b0b4

test

@ 3bf0c63f:aefa459d

rosetta.alhur.es

A service that grabs code samples from two chosen languages on RosettaCode and displays them side-by-side.

The code-fetching is done in real time and snippet-by-snippet (there is also a prefetch of which snippets are available in each language, so we only compare apples to apples).

This was my first Golang web application if I remember correctly.

• https://rosetta.alhur.es/
• https://github.com/fiatjaf/rosetta.alhur.es

@ 3bf0c63f:aefa459d

Thoughts on Nostr key management

On Why I don't like NIP-26 as a solution for key management I talked about multiple techniques that could be used to tackle the problem of key management on Nostr.

Here are some ideas that work in tandem:

• NIP-41 (stateless key invalidation)
• NIP-46 (Nostr Connect)
• NIP-07 (signer browser extension)
• Connected hardware signing devices
• other things like musig or frostr keys used in conjunction with a semi-trusted server; or other kinds of trusted software, like a dedicated signer on a mobile device that can sign on behalf of other apps; or even a separate protocol that some people decide to use as the source of truth for their keys, and some clients might decide to use that automatically
• there are probably many other ideas

Some premises I have in my mind (that may be flawed) that base my thoughts on these matters (and cause me to not worry too much) are that

• For the vast majority of people, Nostr keys aren't a target as valuable as Bitcoin keys, so they will probably be ok even without any solution;
• Even when you lose everything, identity can be recovered -- slowly and painfully, but still --, unlike money;
• Nostr is not trying to replace all other forms of online communication (even though when I think about this I can't imagine one thing that wouldn't be nice to replace with Nostr) or of offline communication, so there will always be ways.
• For the vast majority of people, losing keys and starting fresh isn't a big deal. It is a big deal when you have followers and an online persona and your life depends on that, but how many people are like that? In the real world I see people deleting social media accounts all the time and creating new ones, people losing their phone numbers or other accounts associated with their phone numbers, and not caring very much -- they just find a way to notify friends and family and move on.

We can probably come up with some specs to ease the "manual" recovery process, like social attestation and explicit signaling -- i.e., Alice, Bob and Carol are friends; Alice loses her key; Bob sends a new Nostr event kind to the network saying what is Alice's new key; depending on how much Carol trusts Bob, she can automatically start following that and remove the old key -- or something like that.

---

One nice thing about some of these proposals, like NIP-41, or the social-recovery method, or the external-source-of-truth-method, is that they don't have to be implemented in any client, they can live in standalone single-purpose microapps that users open or visit only every now and then, and these can then automatically update their follow lists with the latest news from keys that have changed according to multiple methods.

@ 3bf0c63f:aefa459d

lnurl-auth explained

You may have seen the lnurl-auth spec or heard about it, but might not know how it works or what is its relationship with other lnurl protocols. This document attempts to solve that.

Relationship between lnurl-auth and other lnurl protocols

First, what is the relationship of lnurl-auth with other lnurl protocols? The answer is none, except the fact that they all share the lnurl format for specifying https URLs.

In fact, lnurl-auth is very unique in the sense that it doesn't even need a Lightning wallet to work, it is a standalone authentication protocol that can work anywhere.

How does it work

Now, how does it work? The basic idea is that each wallet has a seed, which is a random value (you may think of the BIP39 seed words, for example). Usually from that seed different keys are derived, each of these yielding a Bitcoin address, and also from that same seed may come the keys used to generate and manage Lightning channels.

What lnurl-auth does is to generate a new key from that seed, and from that a new key for each service (identified by its domain) you try to authenticate with.

That way, you effectively have a new identity for each website. Two different services cannot associate your identities.

The flow goes like this: When you visit a website, the website presents you with a QR code containing a callback URL and a challenge. The challenge should be a random value.

When your wallet scans or opens that QR code it uses the domain in the callback URL plus the main lnurl-auth key to derive a key specific for that website, uses that key to sign the challenge and then sends both the public key specific for that for that website plus the signed challenge to the specified URL.

When the service receives the public key it checks it against the challenge signature and start a session for that user. The user is then identified only by its public key. If the service wants it can, of course, request more details from the user, associate it with an internal id or username, it is free to do anything. lnurl-auth's goals end here: no passwords, maximum possible privacy.

FAQ

• What is the advantage of tying this to Bitcoin and Lightning?

  One big advantage is that your wallet is already keeping track of one seed, it is already a precious thing. If you had to keep track of a separate auth seed it would be arguably worse, more difficult to bootstrap the protocol, and arguably one of the reasons similar protocols, past and present, weren't successful.

• Just signing in to websites? What else is this good for?

  No, it can be used for authenticating to installable apps and physical places, as long as there is a service running an HTTP server somewhere to read the signature sent from the wallet. But yes, signing in to websites is the main problem to solve here.

• Phishing attack! Can a malicious website proxy the QR from a third website and show it to the user to it will steal the signature and be able to login on the third website?

  No, because the wallet will only talk to the the callback URL, and it will either be controlled by the third website, so the malicious won't see anything; or it will have a different domain, so the wallet will derive a different key and frustrate the malicious website's plan.

• I heard SQRL had that same idea and it went nowhere.

  Indeed. SQRL in its first version was basically the same thing as lnurl-auth, with one big difference: it was vulnerable to phishing attacks (see above). That was basically the only criticism it got everywhere, so the protocol creators decided to solve that by introducing complexity to the protocol. While they were at it they decided to add more complexity for managing accounts and so many more crap that in the the spec which initially was a single page ended up becoming 136 pages of highly technical gibberish. Then all the initial network effect it had, libraries and apps were trashed and nowadays no one can do anything with it (but, see, there are still people who love the protocol writing in a 90's forum with no clue of anything besides their own Java).

• We don't need this, we need WebAuthn!

  WebAuthn is essentially the same thing as lnurl-auth, but instead of being simple it is complex, instead of being open and decentralized it is centralized in big corporations, and instead of relying on a key generated by your own device it requires an expensive hardware HSM you must buy and trust the manufacturer. If you like WebAuthn and you like Bitcoin you should like lnurl-auth much more.

• What about BitID?

  This is another one that is very similar to lnurl-auth, but without the anti-phishing prevention and extra privacy given by making one different key for each service.

• What about LSAT?

  It doesn't compete with lnurl-auth. LSAT, as far as I understand it, is for when you're buying individual resources from a server, not authenticating as a user. Of course, LSAT can be repurposed as a general authentication tool, but then it will lack features that lnurl-auth has, like the property of having keys generated independently by the user from a common seed and a standard way of passing authentication info from one medium to another (like signing in to a website at the desktop from the mobile phone, for example).

@ 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

A biblioteca infinita

Agora esqueci o nome do conto de Jorge Luis Borges em que a tal biblioteca é descrita, ou seus detalhes específicos. Eu tinha lido o conto e nunca havia percebido que ele matava a questão da aleatoriedade ser capaz de produzir coisas valiosas. Precisei mesmo da Wikipédia me dizer isso.

Alguns anos atrás levantei essa questão para um grupo de amigos sem saber que era uma questão tão batida e baixa. No meu exemplo era um cachorro andando sobre letras desenhadas e não um macaco numa máquina de escrever. A minha conclusão da discussão foi que não importa o que o cachorro escrevesse, sem uma inteligência capaz de compreender aquilo nada passaria de letras aleatórias.

Borges resolve tudo imaginando uma biblioteca que contém tudo o que o cachorro havia escrito durante todo o infinito em que fez o experimento, e portanto contém todo o conhecimento sobre tudo e todas as obras literárias possíveis -- mas entre cada página ou frase muito boa ou pelo menos legívei há toneladas de livros completamente aleatórios e uma pessoa pode passar a vida dentro dessa biblioteca que contém tanto conhecimento importante e mesmo assim não aprender nada porque nunca vai achar os livros certos.

Everything would be in its blind volumes. Everything: the detailed history of the future, Aeschylus' The Egyptians, the exact number of times that the waters of the Ganges have reflected the flight of a falcon, the secret and true nature of Rome, the encyclopedia Novalis would have constructed, my dreams and half-dreams at dawn on August 14, 1934, the proof of Pierre Fermat's theorem, the unwritten chapters of Edwin Drood, those same chapters translated into the language spoken by the Garamantes, the paradoxes Berkeley invented concerning Time but didn't publish, Urizen's books of iron, the premature epiphanies of Stephen Dedalus, which would be meaningless before a cycle of a thousand years, the Gnostic Gospel of Basilides, the song the sirens sang, the complete catalog of the Library, the proof of the inaccuracy of that catalog. Everything: but for every sensible line or accurate fact there would be millions of meaningless cacophonies, verbal farragoes, and babblings. Everything: but all the generations of mankind could pass before the dizzying shelves – shelves that obliterate the day and on which chaos lies – ever reward them with a tolerable page.

Tenho a impressão de que a publicação gigantesca de artigos, posts, livros e tudo o mais está transformando o mundo nessa biblioteca. Há tanta coisa pra ler que é difícil achar o que presta. As pessoas precisam parar de escrever.

@ 3bf0c63f:aefa459d

IPFS problems: Shitcoinery

IPFS was advertised to the Ethereum community since the beggining as a way to "store" data for their "dApps". I don't think this is harmful in any way, but for some reason it may have led IPFS developers to focus too much on Ethereum stuff. Once I watched a talk showing libp2p developers – despite being ignored by the Ethereum team (that ended up creating their own agnostic p2p library) – dedicating an enourmous amount of work on getting a libp2p app running in the browser talking to a normal Ethereum node.

The always somewhat-abandoned "Awesome IPFS" site is a big repository of "dApps", some of which don't even have their landing page up anymore, useless Ethereum smart contracts that for some reason use IPFS to store whatever the useless data their users produce.

Again, per se it isn't a problem that Ethereum people are using IPFS, but it is at least confusing, maybe misleading, that when you search for IPFS most of the use-cases are actually Ethereum useless-cases.

See also

• Bitcoin, the only non-shitcoin

@ 3bf0c63f:aefa459d

Why IPFS cannot work, again

Imagine someone comes up with a solution for P2P content-addressed data-sharing that involves storing all the files' contents in all computers of the network. That wouldn't work, right? Too much data, if you think this can work then you're a BSV enthusiast.

Then someone comes up with the idea of not storing everything in all computers, but only some things on some computers, based on some algorithm to determine what data a node would store given its pubkey or something like that. Still wouldn't work, right? Still too much data no matter how much you spread it, but mostly incentives not aligned, would implode in the first day.

Now imagine someone says they will do the same thing, but instead of storing the full contents each node would only store a pointer to where each data is actually available. Does that make it better? Hardly so. Still, you're just moving the problem.

This is IPFS.

Now you have less data on each computer, but on a global scale that is still a lot of data.

No incentives.

And now you have the problem of finding the data. First if you have some data you want the world to access you have to broadcast information about that, flooding the network -- and everybody has to keep doing this continuously for every single file (or shard of file) that is available.

And then whenever someone wants some data they must find the people who know about that, which means they will flood the network with requests that get passed from peer to peer until they get to the correct peer.

The more you force each peer to store the worse it becomes to run a node and to store data on behalf of others -- but the less your force each peer to store the more flooding you'll have on the global network, and the slower will be for anyone to actually get any file.

---

But if everybody just saves everything to Infura or Cloudflare then it works, magic decentralized technology.

Related

• How IPFS is broken

@ 3bf0c63f:aefa459d

Who will build the roads?

Who will build the roads? Em Lagoa Santa, as mais novas e melhores ruas -- que na verdade acabam por formar enormes teias de bairros que se interligam -- são construídas pelos loteadores que querem as ruas para que seus lotes valham mais -- e querem que outras pessoas usem as ruas também. Também são esses mesmos loteadores que colocam os postes de luz e os encanamentos de água, não sem antes terem que se submeter a extorsões de praxe praticadas por COPASA e CEMIG.

Se ao abrir um loteamento, condomínio, prédio um indivíduo ou uma empresa consegue sem muito problema passar rua, eletricidade, água e esgoto, por que não seria possível existir livre-concorrência nesses mercados? Mesmo aquela velha estória de que é ineficiente passar cabos de luz duplicados para que companhias elétricas possam competir já me parece bobagem.

@ 3bf0c63f:aefa459d

How IPFS is broken

I once fell for this talk about "content-addressing". It sounds very nice. You know a certain file exists, you know there are probably people who have it, but you don't know where or if it is hosted on a domain somewhere. With content-addressing you can just say "start" and the download will start. You don't have to care.

Other magic properties that address common frustrations: webpages don't go offline, links don't break, valuable content always finds its way, other people will distribute your website for you, any content can be transmitted easily to people near you without anyone having to rely on third-party centralized servers.

But you know what? Saying a thing is good doesn't automatically make it possible and working. For example: saying stuff is addressed by their content doesn't change the fact that the internet is "location-addressed" and you still have to know where peers that have the data you want are and connect to them.

And what is the solution for that? A DHT!

DHT?

Turns out DHTs have terrible incentive structure (as you would expect, no one wants to hold and serve data they don't care about to others for free) and the IPFS experience proves it doesn't work even in a small network like the IPFS of today.

If you have run an IPFS client you'll notice how much it clogs your computer. Or maybe you don't, if you are very rich and have a really powerful computer, but still, it's not something suitable to be run on the entire world, and on web pages, and servers, and mobile devices. I imagine there may be a lot of unoptimized code and technical debt responsible for these and other problems, but the DHT is certainly the biggest part of it. IPFS can open up to 1000 connections by default and suck up all your bandwidth -- and that's just for exchanging keys with other DHT peers.

Even if you're in the "client" mode and limit your connections you'll still get overwhelmed by connections that do stuff I don't understand -- and it makes no sense to run an IPFS node as a client, that defeats the entire purpose of making every person host files they have and content-addressability in general, centralizes the network and brings back the dichotomy client/server that IPFS was created to replace.

Connections?

So, DHTs are a fatal flaw for a network that plans to be big and interplanetary. But that's not the only problem.

Finding content on IPFS is the most slow experience ever and for some reason I don't understand downloading is even slower. Even if you are in the same LAN of another machine that has the content you need it will still take hours to download some small file you would do in seconds with scp -- that's considering that IPFS managed to find the other machine, otherwise your command will just be stuck for days.

Now even if you ignore that IPFS objects should be content-addressable and not location-addressable and, knowing which peer has the content you want, you go there and explicitly tell IPFS to connect to the peer directly, maybe you can get some seconds of (slow) download, but then IPFS will drop the connection and the download will stop. Sometimes -- but not always -- it helps to add the peer address to your bootstrap nodes list (but notice this isn't something you should be doing at all).

IPFS Apps?

Now consider the kind of marketing IPFS does: it tells people to build "apps" on IPFS. It sponsors "databases" on top of IPFS. It basically advertises itself as a place where developers can just connect their apps to and all users will automatically be connected to each other, data will be saved somewhere between them all and immediately available, everything will work in a peer-to-peer manner.

Except it doesn't work that way at all. "libp2p", the IPFS library for connecting people, is broken and is rewritten every 6 months, but they keep their beautiful landing pages that say everything works magically and you can just plug it in. I'm not saying they should have everything perfect, but at least they should be honest about what they truly have in place.

It's impossible to connect to other people, after years there's no js-ipfs and go-ipfs interoperability (and yet they advertise there will be python-ipfs, haskell-ipfs, whoknowswhat-ipfs), connections get dropped and many other problems.

So basically all IPFS "apps" out there are just apps that want to connect two peers but can't do it manually because browsers and the IPv4/NAT network don't provide easy ways to do it and WebRTC is hard and requires servers. They have nothing to do with "content-addressing" anything, they are not trying to build "a forest of merkle trees" nor to distribute or archive content so it can be accessed by all. I don't understand why IPFS has changed its core message to this "full-stack p2p network" thing instead of the basic content-addressable idea.

IPNS?

And what about the database stuff? How can you "content-address" a database with values that are supposed to change? Their approach is to just save all values, past and present, and then use new DHT entries to communicate what are the newest value. This is the IPNS thing.

Apparently just after coming up with the idea of content-addressability IPFS folks realized this would never be able to replace the normal internet as no one would even know what kinds of content existed or when some content was updated -- and they didn't want to coexist with the normal internet, they wanted to replace it all because this message is more bold and gets more funding, maybe?

So they invented IPNS, the name system that introduces location-addressability back into the system that was supposed to be only content-addressable.

And how do they manage to do it? Again, DHTs. And does it work? Not really. It's limited, slow, much slower than normal content-addressing fetches, most of the times it doesn't even work after hours. But still although developers will tell it is not working yet the IPFS marketing will talk about it as if it was a thing.

Archiving content?

The main use case I had for IPFS was to store content that I personally cared about and that other people might care too, like old articles from dead websites, and videos, sometimes entire websites before they're taken down.

So I did that. Over many months I've archived stuff on IPFS. The IPFS API and CLI don't make it easy to track where stuff are. The pin command doesn't help as it just throws your pinned hash in a sea of hashes and subhashes and you're never able to find again what you have pinned.

The IPFS daemon has a fake filesystem that is half-baked in functionality but allows you to locally address things by names in a tree structure. Very hard to update or add new things to it, but still doable. It allows you to give names to hashes, basically. I even began to write a wrapper for it, but suddenly after many weeks of careful content curation and distribution all my entries in the fake filesystem were gone.

Despite not having lost any of the files I did lose everything, as I couldn't find them in the sea of hashes I had in my own computer. After some digging and help from IPFS developers I managed to recover a part of it, but it involved hacks. My things vanished because of a bug at the fake filesystem. The bug was fixed, but soon after I experienced a similar (new) bug. After that I even tried to build a service for hash archival and discovery, but as all the problems listed above began to pile up I eventually gave up. There were also problems of content canonicalization, the code the IPFS daemon use to serve default HTML content over HTTP, problems with the IPFS browser extension and others.

Future-proof?

One of the core advertised features of IPFS was that it made content future-proof. I'm not sure they used this expression, but basically you have content, you hash that, you get an address that never expires for that content, now everybody can refer to the same thing by the same name. Actually, it's better: content is split and hashed in a merkle-tree, so there's fine-grained deduplication, people can store only chunks of files and when a file is to be downloaded lots of people can serve it at the same time, like torrents.

But then come the protocol upgrades. IPFS has used different kinds of hashing algorithms, different ways to format the hashes, and will change the default algorithm for building the merkle-trees, so basically the same content now has a gigantic number of possible names/addresses, which defeats the entire purpose, and yes, files hashed using different strategies aren't automagically compatible.

Actually, the merkle algorithm could have been changed by each person on a file-by-file basis since the beginning (you could for example split a book file by chapter or page instead of by chunks of bytes) -- although probably no one ever did that. I know it's not easy to come up with the perfect hashing strategy in the first go, but the way these matters are being approached make me wonder that IPFS promoters aren't really worried about future-proof, or maybe we're just in Beta phase forever.

Ethereum?

This is also a big problem. IPFS is built by Ethereum enthusiasts. I can't read the mind of people behind IPFS, but I would imagine they have a poor understanding of incentives like the Ethereum people, and they tend towards scammer-like behavior like getting a ton of funds for investors in exchange for promises they don't know they can fulfill (like Filecoin and IPFS itself) based on half-truths, changing stuff in the middle of the road because some top-managers decided they wanted to change (move fast and break things) and squatting fancy names like "distributed web".

The way they market IPFS (which is not the main thing IPFS was initially designed to do) as a "peer-to-peer cloud" is very seductive for Ethereum developers just like Ethereum itself is: as a place somewhere that will run your code for you so you don't have to host a server or have any responsibility, and then Infura will serve the content to everybody. In the same vein, Infura is also hosting and serving IPFS content for Ethereum developers these days for free. Ironically, just like the Ethereum hoax peer-to-peer money, IPFS peer-to-peer network may begin to work better for end users as things get more and more centralized.

More about IPFS problems:

• IPFS problems: Too much immutability
• IPFS problems: General confusion
• IPFS problems: Shitcoinery
• IPFS problems: Community
• IPFS problems: Pinning
• IPFS problems: Conceit
• IPFS problems: Inefficiency
• IPFS problems: Dynamic links

See also

• A crappy course on torrents, on the protocol that has done most things right
• The Tragedy of IPFS in a series of links, an ongoing Twitter thread.

@ 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.

@ 3a8a16a7:f4c3b0b4

lkhkjhlk

!?

@ 3bf0c63f:aefa459d

Jofer

Jofer era um jogador diferente. À primeira vista não, parecia igual, um volante combativo, perseguia os atacantes adversários implacavelmente, um bom jogador. Mas não era essa a característica que diferenciava Jofer. Jofer era, digamos, um chutador.

Começou numa semifinal de um torneio de juniores. O time de Jofer precisava do empate e estava sofrendo uma baita pressão do adversário, mas o jogo estava 1 a 1 e parecia que ia ficar assim mesmo, daquele jeito futebolístico que parece, parece mesmo. Só que aos 46 do segundo tempo tomaram um gol espírita, Ruizinho do outro time saiu correndo pela esquerda e, mesmo sendo canhoto, foi cortando para o meio, os zagueiros meio que achando que já tinha acabado mesmo, devia ter só mais aquele lance, o árbitro tinha dado dois minutos, Ruizinho chutou, marcou e o goleiro, que só pulou depois que já tinha visto que não ia ter jeito, ficou xingando.

A bola saiu do meio e tocaram para Jofer, ninguém nem veio marcá-lo, o outro time já estava comemorando, e com razão, o juiz estava de sacanagem em fazer o jogo continuar, já estava tudo acabado mesmo. Mas não, estava certo, mais um minuto de acréscimo, justo. Em um minuto dá pra fazer um gol. Mas como? Jofer pensou nas partidas da NBA em que com alguns centésimos de segundo faltando o armador jogava de qualquer jeito para a cesta e às vezes acertava. De trás do meio de campo, será? Não vou ter nem força pra fazer chegar no gol. Vou virar piada, melhor tocar pro Fumaça ali do lado e a gente perde sem essa humilhação no final. Mas, poxa, e daí? Vou tentar mesmo assim, qualquer coisa eu falo que foi um lançamento e daqui a uns dias todo mundo esquece. Olhou para o próprio pé, virou ele de ladinho, pra fora e depois pra dentro (bom, se eu pegar daqui, direitinho, quem sabe?), jogou a bola pro lado e bateu. A bola subiu escandalosamente, muito alta mesmo, deve ter subido uns 200 metros. Jofer não tinha como ter a menor noção. Depois foi descendo, o goleirão voltando correndo para debaixo da trave e olhando pra bola, foi chegando e pulando já só pra acompanhar, para ver, dependurado no travessão, a bola sair ainda bem alta, ela bateu na rede lateral interna antes de bater no chão, quicar violentamente e estufar a rede no alto do lado direito de quem olhava.

Mas isso tudo foi sonho do Jofer. Sonhou acordado, numa noite em que demorou pra dormir, deitado na sua cama. Ficou pensando se não seria fácil, se ele treinasse bastante, acertar o gol bem de longe, tipo no sonho, e se não dava pra fazer gol assim. No dia seguinte perguntou a Brunildinho, o treinador de goleiros. Era difícil defender essas bolas, ainda mais se elas subissem muito, o goleiro ficava sem perspectiva, o vento alterava a trajetória a cada instante, tinha efeito, ela cairia rápido, mas claro que não valia à pena treinar isso, a chance de acertar o gol era minúscula. Mas Jofer só ia tentar depois que treinasse bastante e comprovasse o que na sua imaginação parecia uma excelente idéia.

Começou a treinar todos os dias. Primeiro escondido, por vergonha dos colegas, chegava um pouco antes e ficava lá, chutando do círculo central. Ao menor sinal de gente se aproximando, parava e ia catar as bolas. Depois, quando começou a acertar, perdeu a vergonha. O pessoal do clube todo achava engraçado quando via Jofer treinando e depois ouvia a explicação da boca de alguém, ninguém levava muito a sério, mas também não achava de todo ridículo. O pessoal ria, mas no fundo torcia praquilo dar certo, mesmo.

Aconteceu que num jogo que não valia muita coisa, empatezinho feio, aos 40 do segundo tempo, a marcação dos adversários já não estava mais pressionando, todo mundo contente com o empate e com vontade de parar de jogar já, o Henrique, meia-esquerdo, humilde, mas ainda assim um pouco intimidante para Jofer (jogava demais), tocou pra ele. Vai lá, tenta sua loucura aí. Assumiu a responsabilidade do nosso volante introspectivo. Seria mais verossímil se Jofer tivesse errado, primeira vez que tentou, restava muito tempo ainda pra ele ter a chance de ser herói, ninguém acerta de primeira, mas ele acertou. Quase como no sonho, Lucas, o goleiro, não esperava, depois que viu o lance, riu-se, adiantou-se para pegar a bola que ele julgava que quicaria na área, mas ela foi mais pra frente, mais e mais, daí Lucas já estava correndo, só que começou a pensar que ela ia pra fora, e ele ia só se dependurar no travessão e fazer seu papel de estar na bola. Acabou que por conta daquele gol eles terminaram em segundo no grupo daquele torneiozinho, ao invés de terceiro, e não fez diferença nenhuma.

@ 3bf0c63f:aefa459d

The flaw of "just use paypal/coinbase" arguments

For the millionth time I read somewhere that "custodial bitcoin is not bitcoin" and that "if you're going to use custodial, better use Paypal". No, actually it was "better use Coinbase", but I had heard the "PayPal" version in the past.

There are many reasons why using PayPal is not the same as using a custodial Bitcoin service or wallet that are obvious and not relevant here, such as the fact that you can't have Bitcoin balances on Bitcoin (or maybe now you can? but you can't send it around); plus all the reasons that are also valid for Coinbase such as you having to give all your data and selfies of yourself and your government documents and so on -- but let's ignore these reasons for now.

The most important reason why it isn't the same thing is that when you're using Coinbase you are stuck in Coinbase. Your Coinbase coins cannot be used to pay anyone that isn't in Coinbase. So Coinbase-style custodianship doesn't help Bitcoin. If you want to move out of Coinbase you have to withdraw from Coinbase.

Custodianship on Lightning is of a very different nature. You can pay people from other custodial platforms and people that are hosting their own Lightning nodes and so on.

That kind of custodianship doesn't do any harm to anyone, doesn't fracture the network, doesn't reduce the network effect of Lightning, in fact it increases it.

@ 3bf0c63f:aefa459d

My personal experience (as a complete ignorant) of the blocksize debate in 2017

In the beginning of 2017 I didn't know Bitcoin was having a "blocksize debate". I had stopped paying attention to Bitcoin in 2014 after reading Tim Swanson's book on shitcoineiry and was surprise people even care about Bitcoin still while Ethereum and other fancy things were around.

My introduction to the subject was this interview with Andrew Stone and Andrew Clifford from Bitcoin Unlimited (still don't know who these guys are). I've listened to it and kinda liked the conspiracy theory about "a group of developers trying, against miners and users, to control the whole ecosystem by not allowing blocks to grow" (actually, if you listen to this interview that announced the creation of Blockstream and the sidechains whitepaper it does sound like a government agent bribing all the Core developers into forming a consortium that will turn Bitcoin into an Ethereum-like shitcoin under their control -- but this is just a useless digression).

Some time later I listened to this interview with Jimmy Song and was introduced to two hard forks and conspiracies and New York Agreement and got excited because I didn't care about Bitcoin (I'm ashamed to remember this feeling) and wanted to see things changing, people fighting, Bitcoin burning, for no reason. Oddly, what I grasped from the interview was that Jimmy Song was defending the agreement and expecting everybody to fulfill it.

When the day actually come and "Bitcoin Cash" forked I looked at it with pity because it looked clearly a failure from the beginning, but I still cheered for it a bit, still not knowing anything about the debate, besides the fact that blocks were bigger on BCH, which looked like a very reductionist explanation to me.

"Of course it's not just making blocks bigger, that would be too simple, they probably have a very complex plan I'm not apt to understand", I thought.

To my surprise the entire argument was actually just that: bigger blocks bigger blocks. I came to that conclusion by listening to tomwoods.com/1064, a debate in which reasonable arguments faced childish claims. That debate gave me perspective and was a clear, undisputed win from Jameson Lopp against Roger Ver.

Actually some time before that I had listened to another Tom Woods Show episode thinking it was going to be an episode about Bitcoin, but in fact it was just propaganda about a debate I had almost forgotten. And nothing about Bitcoin, everything about "Bitcoin Cash" and how there were two Bitcoins, one legitimate and the other unlegitimate.

So, from the perspective of someone that came to the debate totally fresh and only listens to the big-blocker arguments for a long time, they still don't convince anyone with some common sense (as I would like to think of myself), they just sound like mad dogs and everything goes against themselves.

---

Fast forward to the present and with much more understanding of the issues in place I started digging some material from 2016-2017 about the debate to try to get more context, and found this ridiculous interview with Mike Hearn. It isn't a waste of time to listen to it if you're not familiar with the debate from that time.

As I should have probably expected from my experience with Epicenter.tv, both the interviewers agree with Mike Hearn about his ridiculous claims about how (not his words) we have to subsidize the few thousand current Bitcoin users by preventing fees from increase and there are no trade-offs to doing that -- and even with everybody agreeing they all manage to sound stupid. There's not a single phrase that is defendable in the entire interview, no criticisms make any sense, it makes me feel bad for the the guy as he feels so self-assured and obviouslyright.

After knowing about these and other adventures of stupid people with high influences in the Bitcoin world trying to impose their idiocy on others it feels even more odd and unexpected to find Bitcoin in the right track. Generally in politics the most dumb wins, but apparently not in Bitcoin.

Bitcoin is a miracle.

@ 3bf0c63f:aefa459d

idea: Per-paragraph paywalls

Using the lnurl-allowance protocol, a website could instead of putting a paywall over the entire site, charge a reader for only the paragraphs they read. Of course this requires trust from the reader on the website, but this is normal. The website could just hide the rest of the article before an invoice from the paragraph just read was paid.

This idea came from Colin from the Unhashed Podcast.

Could also work with podcasts and videos.

@ 3bf0c63f:aefa459d

SummaDB

This was a hierarchical database server similar to the original Firebase. Records were stored on a LevelDB on different paths, like:

• /fruits/banana/color: yellow
• /fruits/banana/flavor: sweet

And could be queried by path too, using HTTP, for example, a call to http://hostname:port/fruits/banana, for example, would return a JSON document like

json { "color": "yellow", "flavor": "sweet" }

While a call to /fruits would return

json { "banana": { "color": "yellow", "flavor": "sweet" } }

POST, PUT and PATCH requests also worked.

In some cases the values would be under a special "_val" property to disambiguate them from paths. (I may be missing some other details that I forgot.)

GraphQL was also supported as a query language, so a query like

graphql query { fruits { banana { color } } }

would return {"fruits": {"banana": {"color": "yellow"}}}.

SummulaDB

SummulaDB was a browser/JavaScript build of SummaDB. It ran on the same Go code compiled with GopherJS, and using PouchDB as the storage backend, if I remember correctly.

It had replication between browser and server built-in, and one could replicate just subtrees of the main tree, so you could have stuff like this in the server:

json { "users": { "bob": {}, "alice": {} } }

And then only allow Bob to replicate /users/bob and Alice to replicate /users/alice. I am sure the require auth stuff was also built in.

There was also a PouchDB plugin to make this process smoother and data access more intuitive (it would hide the _val stuff and allow properties to be accessed directly, today I wouldn't waste time working on these hidden magic things).

The computed properties complexity

The next step, which I never managed to get fully working and caused me to give it up because of the complexity, was the ability to automatically and dynamically compute materialized properties based on data in the tree.

The idea was partly inspired on CouchDB computed views and how limited they were, I wanted a thing that would be super powerful, like, given

json { "matches": { "1": { "team1": "A", "team2": "B", "score": "2x1", "date": "2020-01-02" }, "1": { "team1": "D", "team2": "C", "score": "3x2", "date": "2020-01-07" } } }

One should be able to add a computed property at /matches/standings that computed the scores of all teams after all matches, for example.

I tried to complete this in multiple ways but they were all adding much more complexity I could handle. Maybe it would have worked better on a more flexible and powerful and functional language, or if I had more time and patience, or more people.

Screenshots

This is just one very simple unfinished admin frontend client view of the hierarchical dataset.

• https://github.com/fiatjaf/summadb
• https://github.com/fiatjaf/summuladb
• https://github.com/fiatjaf/pouch-summa

@ 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

OP_CHECKTEMPLATEVERIFY and the "covenants" drama

There are many ideas for "covenants" (I don't think this concept helps in the specific case of examining proposals, but fine). Some people think "we" (it's not obvious who is included in this group) should somehow examine them and come up with the perfect synthesis.

It is not clear what form this magic gathering of ideas will take and who (or which ideas) will be allowed to speak, but suppose it happens and there is intense research and conversations and people (ideas) really enjoy themselves in the process.

What are we left with at the end? Someone has to actually commit the time and put the effort and come up with a concrete proposal to be implemented on Bitcoin, and whatever the result is it will have trade-offs. Some great features will not make into this proposal, others will make in a worsened form, and some will be contemplated very nicely, there will be some extra costs related to maintenance or code complexity that will have to be taken. Someone, a concreate person, will decide upon these things using their own personal preferences and biases, and many people will not be pleased with their choices.

That has already happened. Jeremy Rubin has already conjured all the covenant ideas in a magic gathering that lasted more than 3 years and came up with a synthesis that has the best trade-offs he could find. CTV is the result of that operation.

---

The fate of CTV in the popular opinion illustrated by the thoughtless responses it has evoked such as "can we do better?" and "we need more review and research and more consideration of other ideas for covenants" is a preview of what would probably happen if these suggestions were followed again and someone spent the next 3 years again considering ideas, talking to other researchers and came up with a new synthesis. Again, that person would be faced with "can we do better?" responses from people that were not happy enough with the choices.

And unless some famous Bitcoin Core or retired Bitcoin Core developers were personally attracted by this synthesis then they would take some time to review and give their blessing to this new synthesis.

To summarize the argument of this article, the actual question in the current CTV drama is that there exists hidden criteria for proposals to be accepted by the general community into Bitcoin, and no one has these criteria clear in their minds. It is not as simple not as straightforward as "do research" nor it is as humanly impossible as "get consensus", it has a much bigger social element into it, but I also do not know what is the exact form of these hidden criteria.

This is said not to blame anyone -- except the ignorant people who are not aware of the existence of these things and just keep repeating completely false and unhelpful advice for Jeremy Rubin and are not self-conscious enough to ever realize what they're doing.

@ 3bf0c63f:aefa459d

A response to Achim Warner's "Drivechain brings politics to miners" article

I mean this article: https://achimwarner.medium.com/thoughts-on-drivechain-i-miners-can-do-things-about-which-we-will-argue-whether-it-is-actually-a5c3c022dbd2

There are basically two claims here:

1. Some corporate interests might want to secure sidechains for themselves and thus they will bribe miners to have these activated

First, it's hard to imagine why they would want such a thing. Are they going to make a proprietary KYC chain only for their users? They could do that in a corporate way, or with a federation, like Facebook tried to do, and that would provide more value to their users than a cumbersome pseudo-decentralized system in which they don't even have powers to issue currency. Also, if Facebook couldn't get away with their federated shitcoin because the government was mad, what says the government won't be mad with a sidechain? And finally, why would Facebook want to give custody of their proprietary closed-garden Bitcoin-backed ecosystem coins to a random, open and always-changing set of miners?

But even if they do succeed in making their sidechain and it is very popular such that it pays miners fees and people love it. Well, then why not? Let them have it. It's not going to hurt anyone more than a proprietary shitcoin would anyway. If Facebook really wants a closed ecosystem backed by Bitcoin that probably means we are winning big.

2. Miners will be required to vote on the validity of debatable things

He cites the example of a PoS sidechain, an assassination market, a sidechain full of nazists, a sidechain deemed illegal by the US government and so on.

There is a simple solution to all of this: just kill these sidechains. Either miners can take the money from these to themselves, or they can just refuse to engage and freeze the coins there forever, or they can even give the coins to governments, if they want. It is an entirely good thing that evil sidechains or sidechains that use horrible technology that doesn't even let us know who owns each coin get annihilated. And it was the responsibility of people who put money in there to evaluate beforehand and know that PoS is not deterministic, for example.

About government censoring and wanting to steal money, or criminals using sidechains, I think the argument is very weak because these same things can happen today and may even be happening already: i.e., governments ordering mining pools to not mine such and such transactions from such and such people, or forcing them to reorg to steal money from criminals and whatnot. All this is expected to happen in normal Bitcoin. But both in normal Bitcoin and in Drivechain decentralization fixes that problem by making it so governments cannot catch all miners required to control the chain like that -- and in fact fixing that problem is the only reason we need decentralization.

@ 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

Flowi.es

At the time I thought Workflowy had the ideal UI for everything. I wanted to implement my custom app maker on it, but ended up doing this: a platform for enhancing Workflowy with extra features:

• An email reminder based on dates input in items
• A website generator, similar to Websites For Trello, also based on Classless Templates

Also, I didn't remember this was also based on CouchDB and had some couchapp functionalities.

• https://flowi.es
• https://github.com/fiatjaf/flowies

@ 3bf0c63f:aefa459d

Module Linker

A browser extension that reads source code on GitHub and tries to find links to imported dependencies so you can click on them and navigate through either GitHub or package repositories or base language documentation. Works for many languages at different levels of completeness.

• https://github.com/fiatjaf/module-linker
• https://module-linker.alhur.es/
• https://addons.mozilla.org/firefox/addon/module-linker
• https://chrome.google.com/webstore/detail/dglofghjinifeolcpjfjmfdnnbaanggn

@ 3bf0c63f:aefa459d

Using Spacechains and Fedimint to solve scaling

What if instead of trying to create complicated "layer 2" setups involving noveau cryptographic techniques we just did the following:

• we take that Fedimint source code and remove the "mint" stuff, and just use their federation stuff secure coins with multisig;
• then we make a spacechain;
• and we make the federations issue multisig-btc tokens on it;
• and then we put some uniswap-like thing in there to allow these tokens to be exchanged freely.

Why?

The recent spike in fees caused by Ordinals and BRC-20 shitcoinery has shown that Lightning isn't a silver bullet. Channels are too fragile, it costs a lot to open a channel under a high fee environment, to run a routing node and so on.

People who want to keep using Lightning are instead flocking to the big Lightning custodial providers: WalletofSatoshi, ZEBEDEE, OpenNode and so on. We could leverage that trust people have in these companies (and individuals) operating shadow Lightning providers and turn each of these into a btc-token issuer. Each issue their own token, transactions flow freely. Each person can hold only assets from the issuers they trust more.

@ 3bf0c63f:aefa459d

Just malinvestiment

Traditionally the Austrian Theory of Business Cycles has been explained and reworked in many ways, but the most widely accepted version (or the closest to the Mises or Hayek views) view is that banks (or the central bank) cause the general interest rate to decline by creation of new money and that prompts entrepreneurs to invest in projects of longer duration. This can be confusing because sometimes entrepreneurs embark in very short-time projects during one of these bubbles and still contribute to the overall cycle.

The solution is to think about the "longer term" problem is to think of the entire economy going long-term, not individual entrepreneurs. So if one entrepreneur makes an investiment in a thing that looks simple he may actually, knowingly or not, be inserting himself in a bigger machine that is actually involved in producing longer-term things. Incidentally this thinking also solves the biggest criticism of the Austrian Business Cycle Theory: that of the rational expectations people who say: "oh but can't the entrepreneurs know that the interest rate is artificially low and decide to not make long-term investiments?" ("and if they don't know they should lose money and be replaced like in a normal economy flow blablabla?"). Well, the answer is that they are not really relying on the interest rate, they are only looking for profit opportunities, and this is the key to another confusion that has always followed my thinkings about this topic.

If a guy opens a bar in an area of a town where many new buildings are being built during a "housing bubble" he may not know, but he is inserting himself right into the eye of that business cycle. He expects all these building projects to continue, and all the people involved in that to be getting paid more and be able to spend more at his bar and so on. That is a bet that may or may not end up paying.

Now what does that bar investiment has to do with the interest rate? Nothing. It is just a guy who saw a business opportunity in a place where hungry people with money had no bar to buy things in, so he opened a bar. Additionally the guy has made some calculations about all the ending, starting and future building projects in the area, and then the people that would live or work in that area afterwards (after all the buildings were being built with the expectation of being used) and so on, there is no interest rate calculations involved. And yet that may be a malinvestiment because some building projects will end up being canceled and the expected usage of the finished ones will turn out to be smaller than predicted.

This bubble may have been caused by a decline in interest rates that prompted some people to start buying houses that they wouldn't otherwise, but this is just a small detail. The bubble can only be kept going by a constant influx of new money into the economy, but the focus on the interest rate is wrong. If new money is printed and used by the government to buy ships then there will be a boom and a bubble in the ship market, and that involves all the parts of production process of ships and also bars that will be opened near areas of the town where ships are built and new people are being hired with higher salaries to do things that will eventually contribute to the production of ships that will then be sold to the government.

It's not interest rates or the length of the production process that matters, it's just printed money and malinvestiment.

@ 3bf0c63f:aefa459d

hledger-web

A Haskell app that uses Miso and hledger's Haskell libraries plus ghcjs to be compiled to a web page, and then adds optional remoteStorage so you can store your ledger data somewhere else.

This was my introduction to Haskell and also built at a time I thought remoteStorage was a good idea that solved many problems, and that it could use some help in the form of just yet another somewhat-useless-but-cool project using it that could be added to their wiki.

• https://hledger.alhur.es/
• https://github.com/fiatjaf/hledger-web

See also

• My stupid introduction to Haskell
• LessPass remoteStorage
• TiddlyWiki remoteStorage

@ 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

A big Ethereum problem that is fixed by Drivechain

While reading the following paragraphs, assume Drivechain itself will be a "smart contract platform", like Ethereum. And that it won't be used to launch an Ethereum blockchain copy, but instead each different Ethereum contract could be turned into a different sidechain under BIP300 rules.

A big Ethereum problem

Anyone can publish any "contract" to Ethereum. Often people will come up with somewhat interesting ideas and publish them. Since they want money they will add an unnecessary token and use that to bring revenue to themselves, gamify the usage of their contract somehow, and keep some control over the supposedly open protocol they've created by keeping a majority of the tokens. They will use the profits on marketing and branding, have a visual identity, a central website and a forum with support personnel and so on: their somewhat interesting idea have become a full-fledged company.

If they have success then another company will appear in the space and copy the idea, launch it using exactly the same strategy with a tweak, then try to capture the customers of the first company and new people. And then another, and another, and another. Very often these contracts require some network effect to work, i.e., they require people to be using it so others will use it. The fact that the market is now split into multiple companies offering roughly the same product hurts that, such that none of these protocols get ever enough usage to become really useful in the way they were first conceived. At this point it doesn't matter though, they get some usage, and they use that in their marketing material. It becomes a race to pump the value of the tokens and the current usage is just another point used for that purpose. The company will even start giving out money to attract new users and other weird moves that have no relationship with the initial somewhat intereting idea.

Once in a lifetime it happens that the first implementer of these things is not a company seeking profits, but some altruistic developer or company that believes in Ethereum and wants to see it grow -- or more likely someone financed by the Ethereum Foundation, which allegedly doesn't like these token schemes and would prefer everybody to use the token they issued first, the ETH --, but that's a fruitless enterprise because someone else will copy that idea anyway and turn it into a company as described above.

How Drivechain fixes it

In the Drivechain world, if someone had an idea, they would -- as it happens all the time with Bitcoin things -- publish it in a public forum. Other members of the community would evaluate that idea, add or remove things, all interested parties would contribute to make it the best possible incarnation of that idea. Once the design was settled, someone would volunteer to start writing the code to turn that idea into a sidechain. Maybe some company would fund those efforts and then more people would join. It's not a perfect process and one that often involves altruism, but Bitcoin inspires people to do these things.

Slowly, the thing would get built, tested, activated as a sidechain on testnet, tested more, and at this point luckily the entire community of interested Bitcoin users and miners would have grown to like that idea and see its benefits. It could then be proposed to be activated according to BIP300 rules.

Once it was activated, the entire pool of interested users would join it. And it would be impossible for someone else to create a copy of that because everybody would instantly notice it was a copy. There would be no token, no one profiting directly from the operations of that "smart contract". And everybody would be incentivized to join and tell others to join that same sidechain since the network effect was already the biggest there, they will know more network effect would only be good for everybody involved, and there would be no competing marketing and free token giveaways from competing entities.

See also

• Upgrading 'Smart Contracts' to 'Wise Contracts', by Paul Sztorc
• Drivechain
• Drivechain comparison with Ethereum
• Alternatives to Drivechain

@ 3bf0c63f:aefa459d

Reasons why Lightning is not that great

Some Bitcoiners, me included, were fooled by hyperbolic discourse that presented Lightning as some magical scaling solution with no flaws. This is an attempt to list some of the actual flaws uncovered after 5 years of experience. The point of this article is not to say Lightning is a complete worthless piece of crap, but only to highlight the fact that Bitcoin needs to put more focus on developing and thinking about other scaling solutions (such as Drivechain, less crappy and more decentralized trusted channels networks and statechains).

Unbearable experience

Maintaining a node is cumbersome, you have to deal with closed channels, allocating funds, paying fees unpredictably, choosing new channels to open, storing channel state backups -- or you'll have to delegate all these decisions to some weird AI or third-party services, it's not feasible for normal people.

Channels fail for no good reason all the time

Every time nodes disagree on anything they close channels, there have been dozens, maybe hundreds, of bugs that lead to channels being closed in the past, and implementors have been fixing these bugs, but since these node implementations continue to be worked on and new features continue to be added we can be quite sure that new bugs continue to be introduced.

Trimmed (fake) HTLCs are not sound protocol design

What would you tell me if I presented a protocol that allowed for transfers of users' funds across a network of channels and that these channels would pledge to send the money to miners while the payment was in flight, and that these payments could never be recovered if a node in the middle of the hop had a bug or decided to stop responding? Or that the receiver could receive your payment, but still claim he didn't, and you couldn't prove that at all?

These are the properties of "trimmed HTLCs", HTLCs that are uneconomical to have their own UTXO in the channel presigned transaction bundles, therefore are just assumed to be there while they are not (and their amounts are instead added to the fees of the presigned transaction).

Trimmed HTLCs, like any other HTLC, have timelocks, preimages and hashes associated with them -- which are properties relevant to the redemption of actual HTLCs onchain --, but unlike actual HTLCs these things have no actual onchain meaning since there is no onchain UTXO associated with them. This is a game of make-believe that only "works" because (1) payment proofs aren't worth anything anyway, so it makes no sense to steal these; (2) channels are too expensive to setup; (3) all Lightning Network users are honest; (4) there are so many bugs and confusion in a Lightning Network node's life that events related to trimmed HTLCs do not get noticed by users.

Also, so far these trimmed HTLCs have only been used for very small payments (although very small payments probably account for 99% of the total payments), so it is supposedly "fine" to have them. But, as fees rise, more and more HTLCs tend to become fake, which may make people question the sanity of the design.

Tadge Dryja, one of the creators of the Lightning Network proposal, has been critical of the fact that these things were allowed to creep into the BOLT protocol.

Routing

Routing is already very bad today even though most nodes have a basically 100% view of the public network, the reasons being that some nodes are offline, others are on Tor and unreachable or too slow, channels have the balance shifted in the wrong direction, so payments fail a lot -- which leads to the (bad) solution invented by professional node runners and large businesses of probing the network constantly in order to discard bad paths, this creates unnecessary load and increases the risk of channels being dropped for no good reason.

As the network grows -- if it indeed grow and not centralize in a few hubs -- routing tends to become harder and harder.

While each implementation team makes their own decisions with regard to how to best way to route payments and these decisions may change at anytime, it's worth noting, for example, that CLN will use MPP to split up any payment in any number of chunks of 10k satoshis, supposedly to improve routing success rates. While this often backfires and causes payments to fail when they should have succeeded, it also contributes to making it so there are proportionally more fake HTLCs than there should be, as long as the threshold for fake HTLCs is above 10k.

Payment proofs are somewhat useless

Even though payment proofs were seen by many (including me) as one of the great things about Lightning, the sad fact is that they do not work as proofs if people are not aware of the fact that they are proofs. Wallets do all they can to hide these details from users because it is considered "bad UX" and low-level implementors do not care very much to talk about them at all. There have been attempts from Lightning Labs to get rid of the payment proofs entirely (which at the time to me sounded like a terrible idea, but now I realize they were not wrong).

Here's a piece of anecdote: I've personally witnessed multiple episodes in which Phoenix wallet released the preimage without having actually received the payment (they did receive a minor part of the payment, but the payment was split in many parts). That caused my service, @lntxbot, to mark the outgoing payment as complete, only then to have to endure complaints from the users because the receiver side, Phoenix, had not received the full amount. In these cases, if the protocol and the idea of preimages as payment proofs be respected, should I have been the one in charge of manually fixing user balances?

Another important detail: when an HTLC is sent and then something goes wrong with the payment the channel has to be closed in order to redeem that payment. When the redeemer is on the receiver side, the very act of redeeming should cause the preimage to be revealed and a proof of payment to be made available for the sender, who can then send that back to the previous hop and the payment is proven without any doubt. But when this happens for fake HTLCs (which is the vast majority of payments, as noted above) there is no place in the world for a preimage and therefore there are no proofs available. A channel is just closed, the payer loses money but can't prove a payment. It also can't send that proof back to the previous hop so he is forced to say the payment failed -- even if it wasn't him the one who declared that hop a failure and closed the channel, which should be a prerequisite. I wonder if this isn't the source of multiple bugs in implementations that cause channels to be closed unnecessarily. The point is: preimages and payment proofs are mostly a fiction.

Another important fact is that the proofs do not really prove anything if the keypair that signs the invoice can't be provably attached to a real world entity.

LSP-centric design

The first Lightning wallets to show up in the market, LND as a desktop daemon (then later with some GUIs on top of it like Zap and Joule) and Anton's BLW and Eclair wallets for mobile devices, then later LND-based mobile wallets like Blixt and RawTX, were all standalone wallets that were self-sufficient and meant to be run directly by consumers. Eventually, though, came Breez and Phoenix and introduced the "LSP" model, in which a server would be trusted in various forms -- not directly with users' funds, but with their privacy, fees and other details -- but most importantly that LSP would be the primary source of channels for all users of that given wallet software. This was all fine, but as time passed new features were designed and implemented that assumed users would be running software connected to LSPs. The very idea of a user having a standalone mobile wallet was put out of question. The entire argument for implementation of the bolt12 standard, for example, hinged on the assumption that mobile wallets would have LSPs capable of connecting to Google messaging services and being able to "wake up" mobile wallets in order for them to receive payments. Other ideas, like a complicated standard for allowing mobile wallets to receive payments without having to be online all the time, just assume LSPs always exist; and changes to the expected BOLT spec behavior with regards to, for example, probing of mobile wallets.

Ark is another example of a kind of LSP that got so enshrined that it become a new protocol that depends on it entirely.

Protocol complexity

Even though the general idea of how Lightning is supposed to work can be understood by many people (as long as these people know how Bitcoin works) the Lightning protocol is not really easy: it will take a long time of big dedication for anyone to understand the details about the BOLTs -- this is a bad thing if we want a world of users that have at least an idea of what they are doing. Moreover, with each new cool idea someone has that gets adopted by the protocol leaders, it increases in complexity and some of the implementors are kicked out of the circle, therefore making it easier for the remaining ones to proceed with more and more complexity. It's the same process by which Chrome won the browser wars, kicked out all competitors and proceeded to make a supposedly open protocol, but one that no one can implement as it gets new and more complex features every day, all envisioned by the Chrome team.

Liquidity issues?

I don't believe these are a real problem if all the other things worked, but still the old criticism that Lightning requires parking liquidity and that has a cost is not a complete non-issue, specially given the LSP-centric model.

@ 3bf0c63f:aefa459d

Carl R. Rogers sobre a ciência

Creio que o objetivo primário da ciência é fornecer uma hipótese, uma convicção e uma fé mais seguras e que satisfaçam melhor o próprio investigador. Na medida em que o cientista procura provar qualquer coisa a alguém -- um erro em que incorri mais de uma vez --, creio que ele está se servindo da ciência para remediar uma insegurança pessoal, desviando-a do seu verdadeiro papel criativo a serviço do indivíduo.

Tornar-se Pessoa, página aleatória

@ 3bf0c63f:aefa459d

contratos.alhur.es

A website that allowed people to fill a form and get a standard Contrato de Locação.

Better than all the other "templates" that float around the internet, which are badly formatted .doc files.

It was fully programmable so other templates could be added later, but I never did. This website made maybe one dollar in Google Ads (and Google has probably stolen these like so many other dollars they did with their bizarre requirements).

• https://github.com/fiatjaf/contratos
• http://contratos.alhur.es

@ 3bf0c63f:aefa459d

comentário pertinente de Olavo de Carvalho sobre atribuições indevidas de acontecimentos à "ordem espontânea"

Eis aqui um exemplo entre outros mil, extraído das minhas apostilas de aulas, de como se analisam as relações entre fatores deliberados e casuais na ação histórica. O sr, Beltrão está INFINITAMENTE ABAIXO da possibilidade de discutir essas coisas, e por isso mesmo me atribui uma simploriedade que é dele próprio e não minha:

Já citei mil vezes este parágrafo de Georg Jellinek e vou citá-lo de novo: “Os fenômenos da vida social dividem-se em duas classes: aqueles que são determinados essencialmente por uma vontade diretriz e aqueles que existem ou podem existir sem uma organização devida a atos de vontade. Os primeiros estão submetidos necessariamente a um plano, a uma ordem emanada de uma vontade consciente, em oposição aos segundos, cuja ordenação repousa em forças bem diferentes.”

Essa distinção é crucial para os historiadores e os analistas estratégicos não porque ela é clara em todos os casos, mas precisamente porque não o é. O erro mais comum nessa ordem de estudos reside em atribuir a uma intenção consciente aquilo que resulta de uma descontrolada e às vezes incontrolável combinação de forças, ou, inversamente, em não conseguir enxergar, por trás de uma constelação aparentemente fortuita de circunstâncias, a inteligência que planejou e dirigiu sutilmente o curso dos acontecimentos.

Exemplo do primeiro erro são os Protocolos dos Sábios de Sião, que enxergam por trás de praticamente tudo o que acontece de mau no mundo a premeditação maligna de um número reduzidos de pessoas, uma elite judaica reunida secretamente em algum lugar incerto e não sabido.

O que torna essa fantasia especialmente convincente, decorrido algum tempo da sua publicação, é que alguns dos acontecimentos ali previstos se realizam bem diante dos nossos olhos. O leitor apressado vê nisso uma confirmação, saltando imprudentemente da observação do fato à imputação da autoria. Sim, algumas das idéias anunciadas nos Protocolos foram realizadas, mas não por uma elite distintamente judaica nem muito menos em proveito dos judeus, cuja papel na maioria dos casos consistiu eminentemente em pagar o pato. Muitos grupos ricos e poderosos têm ambições de dominação global e, uma vez publicado o livro, que em certos trechos tem lances de autêntica genialidade estratégica de tipo maquiavélico, era praticamente impossível que nada aprendessem com ele e não tentassem por em prática alguns dos seus esquemas, com a vantagem adicional de que estes já vinham com um bode expiatório pré-fabricado. Também é impossível que no meio ou no topo desses grupos não exista nenhum judeu de origem. Basta portanto um pouquinho de seletividade deformante para trocar a causa pelo efeito e o inocente pelo culpado.

Mas o erro mais comum hoje em dia não é esse. É o contrário: é a recusa obstinada de enxergar alguma premeditação, alguma autoria, mesmo por trás de acontecimentos notavelmente convergentes que, sem isso, teriam de ser explicados pela forca mágica das coincidências, pela ação de anjos e demônios, pela "mão invisível" das forças de mercado ou por hipotéticas “leis da História” ou “constantes sociológicas” jamais provadas, que na imaginação do observador dirigem tudo anonimamente e sem intervenção humana.

As causas geradoras desse erro são, grosso modo:

Primeira: Reduzir as ações humanas a efeitos de forças impessoais e anônimas requer o uso de conceitos genéricos abstratos que dão automaticamente a esse tipo de abordagem a aparência de coisa muito científica. Muito mais científica, para o observador leigo, do que a paciente e meticulosa reconstituição histórica das cadeias de fatos que, sob um véu de confusão, remontam às vezes a uma autoria inicial discreta e quase imperceptível. Como o estudo dos fenômenos histórico-políticos é cada vez mais uma ocupação acadêmica cujo sucesso depende de verbas, patrocínios, respaldo na mídia popular e boas relações com o establishment, é quase inevitável que, diante de uma questão dessa ordem, poucos resistam à tentação de matar logo o problema com duas ou três generalizações elegantes e brilhar como sábios de ocasião em vez de dar-se o trabalho de rastreamentos históricos que podem exigir décadas de pesquisa.

Segunda: Qualquer grupo ou entidade que se aventure a ações histórico-políticas de longo prazo tem de possuir não só os meios de empreendê-las, mas também, necessariamente, os meios de controlar a sua repercussão pública, acentuando o que lhe convém e encobrindo o que possa abortar os resultados pretendidos. Isso implica intervenções vastas, profundas e duradouras no ambiente mental. [Etc. etc. etc.]

(no facebook em 17 de julho de 2013)

@ 3bf0c63f:aefa459d

Comprimido desodorante

No episódio sei-lá-qual de Aleixo FM Bruno Aleixo diz que os bêbados sempre têm as melhores idéias e daí conta uma idéia que ele teve quando estava bêbado: um comprimido que funciona como desodorante. Ao invés de passar o desodorante spray ou roll-on a pessoa pode só tomar o comprimido e pronto, é muito mais prático e no tempo de frio a pessoa pode vestir a roupa mais rápido, sem precisar ficar passando nada com o tronco todo nu. Quando o Busto lhe pergunta sobre a possibilidade de algo assim ser fabricado ele diz que não sabe, que não é cientista, só tem as idéias.

Essa passagem tão boba de um programa de humor esconde uma verdade sobre a doutrina cientística que permeia a sociedade. A doutrina segundo a qual é da ciência que vêm as inovações tecnológicas e de todos os tipos, e por isso é preciso que o Estado tire dinheiro das pessoas trabalhadoras e dê para os cientistas. Nesse ponto ninguém mais sabe o que é um cientista, foi-se toda a concretude, ficou só o nome: "cientista". Daí vão procurar o tal cientista, é um cara que se formou numa universidade e está fazendo um mestrado. Pronto, é só dar dinheiro pra esse cara e tudo vai ficar bom.

Tirando o problema da desconexão entre realidade e a tese, existe também, é claro, o problema da tese: não faz sentido, que um cientista fique procurando formas de realizar uma idéia, que não se sabe nem se é possível nem se é desejável, que ele ou outra pessoa tiveram, muito pelo contrário (mas não vou dizer aqui o que é que era para o cientista fazer porque isso seria contraditório e eu não acho que devam nem existir cientistas).

O que eu queria dizer mesmo era: todo o aparato científico da nossa sociedade, todos os departamentos, universidades, orçamentos e bolsas e revistas, tudo se resume a um monte de gente tentando descobrir como fazer um comprimido desodorante.

@ 3bf0c63f:aefa459d

Zettelkasten

https://writingcooperative.com/zettelkasten-how-one-german-scholar-was-so-freakishly-productive-997e4e0ca125 (um artigo meio estúpido, mas útil).

Esta incrível técnica de salvar notas sem categorias, sem pastas, sem hierarquia predefinida, mas apenas fazendo referências de uma nota à outra e fazendo supostamente surgir uma ordem (ou heterarquia, disseram eles) a partir do caos parece ser o que faltava pra eu conseguir anotar meus pensamentos e idéias de maneira decente, veremos.

Ah, e vou usar esse tal neuron que também gera sites a partir das notas?, acho que vai ser bom.

@ 3bf0c63f:aefa459d

Criteria for activating Drivechain on Bitcoin

Drivechain is, in essence, just a way to give Bitcoin users the option to deposit their coins in a hashrate escrow. If Bitcoin is about coin ownership, in theory there should be no objection from anyone on users having the option to do that: my keys, my coins etc. In other words: even if you think hashrate escrows are a terrible idea and miners will steal all coins from that, you shouldn't care about what other people do with their own money.

There are only two reasonable objections that could be raised by normal Bitcoin users against Drivechain:

1. Drivechain adds code complexity to bitcoind
2. Drivechain perverts miner incentives of the Bitcoin chain

If these two objections can be reasonably answered there remains no reason for not activating the Drivechain soft-fork.

1

To address 1 we can just take a look at the code once it's done (which I haven't) but from my understanding the extra validation steps needed for ensuring hashrate escrows work are very minimal and self-contained, they shouldn't affect anything else and the risks of introducing some catastrophic bug are roughly zero (or the same as the risks of any of the dozens of refactors that happen every week on Bitcoin Core).

For the BMM/BIP-301 part, again the surface is very small, but we arguably do not need that at all, since anyprevout (once that is merged) enables blind merge-mining in way that is probably better than BIP-301, and that soft-fork is also very simple, plus already loved and accepted by most of the Bitcoin community, implemented and reviewed on Bitcoin Inquisition and is live on the official Bitcoin Core signet.

2

To address 2 we must only point that BMM ensures that Bitcoin miners don't have to do any extra work to earn basically all the fees that would come from the sidechain, as competition for mining sidechain blocks would bid the fee paid to Bitcoin miners up to the maximum economical amount. It is irrelevant if there is MEV on the sidechain or not, everything that reaches the Bitcoin chain does that in form of fees paid in a single high-fee transaction paid to any Bitcoin miner, regardless of them knowing about the sidechain or not. Therefore, there are no centralization pressure or pervert mining incentives that can affect Bitcoin land.

Sometimes it's argued that Drivechain may facilitate the ocurrence of a transaction paying a fee so high it would create incentives for reorging the Bitcoin chain. There is no reason to believe Drivechain would make this more likely than an actual attack than anyone can already do today or, as has happened, some rich person typing numbers wrong on his wallet. In fact, if a drivechain is consistently paying high fees on its BMM transactions that is an incentive for Bitcoin miners to keep mining those transactions one after the other and not harm the users of sidechain by reorging Bitcoin.

Moreover, there are many factors that exist today that can be seen as centralization vectors for Bitcoin mining: arguably one of them is non-blind merge mining, of which we have a (very convoluted) example on the Stacks shitcoin, and introducing the possibility of blind merge-mining on Bitcoin would basically remove any reasonable argument for having such schemes, therefore reducing the centralizing factor of them.

@ 3bf0c63f:aefa459d

idea: Custom multi-use database app

Since 2015 I have this idea of making one app that could be repurposed into a full-fledged app for all kinds of uses, like powering small businesses accounts and so on. Hackable and open as an Excel file, but more efficient, without the hassle of making tables and also using ids and indexes under the hood so different kinds of things can be related together in various ways.

It is not a concrete thing, just a generic idea that has taken multiple forms along the years and may take others in the future. I've made quite a few attempts at implementing it, but never finished any.

I used to refer to it as a "multidimensional spreadsheet".

Can also be related to DabbleDB.

@ 3bf0c63f:aefa459d

On HTLCs and arbiters

This is another attempt and conveying the same information that should be in Lightning and its fake HTLCs. It assumes you know everything about Lightning and will just highlight a point. This is also valid for PTLCs.

The protocol says HTLCs are trimmed (i.e., not actually added to the commitment transaction) when the cost of redeeming them in fees would be greater than their actual value.

Although this is often dismissed as a non-important fact (often people will say "it's trusted for small payments, no big deal"), but I think it is indeed very important for 3 reasons:

1. Lightning absolutely relies on HTLCs actually existing because the payment proof requires them. The entire security of each payment comes from the fact that the payer has a preimage that comes from the payee. Without that, the state of the payment becomes an unsolvable mystery. The inexistence of an HTLC breaks the atomicity between the payment going through and the payer receiving a proof.
2. Bitcoin fees are expected to grow with time (arguably the reason Lightning exists in the first place).
3. MPP makes payment sizes shrink, therefore more and more of Lightning payments are to be trimmed. As I write this, the mempool is clear and still payments smaller than about 5000sat are being trimmed. Two weeks ago the limit was at 18000sat, which is already below the minimum most MPP splitting algorithms will allow.

Therefore I think it is important that we come up with a different way of ensuring payment proofs are being passed around in the case HTLCs are trimmed.

Channel closures

Worse than not having HTLCs that can be redeemed is the fact that in the current Lightning implementations channels will be closed by the peer once an HTLC timeout is reached, either to fulfill an HTLC for which that peer has a preimage or to redeem back that expired HTLCs the other party hasn't fulfilled.

For the surprise of everybody, nodes will do this even when the HTLCs in question were trimmed and therefore cannot be redeemed at all. It's very important that nodes stop doing that, because it makes no economic sense at all.

However, that is not so simple, because once you decide you're not going to close the channel, what is the next step? Do you wait until the other peer tries to fulfill an expired HTLC and tell them you won't agree and that you must cancel that instead? That could work sometimes if they're honest (and they have no incentive to not be, in this case). What if they say they tried to fulfill it before but you were offline? Now you're confused, you don't know if you were offline or they were offline, or if they are trying to trick you. Then unsolvable issues start to emerge.

Arbiters

One simple idea is to use trusted arbiters for all trimmed HTLC issues.

This idea solves both the protocol issue of getting the preimage to the payer once it is released by the payee -- and what to do with the channels once a trimmed HTLC expires.

A simple design would be to have each node hardcode a set of trusted other nodes that can serve as arbiters. Once a channel is opened between two nodes they choose one node from both lists to serve as their mutual arbiter for that channel.

Then whenever one node tries to fulfill an HTLC but the other peer is unresponsive, they can send the preimage to the arbiter instead. The arbiter will then try to contact the unresponsive peer. If it succeeds, then done, the HTLC was fulfilled offchain. If it fails then it can keep trying until the HTLC timeout. And then if the other node comes back later they can eat the loss. The arbiter will ensure they know they are the ones who must eat the loss in this case. If they don't agree to eat the loss, the first peer may then close the channel and blacklist the other peer. If the other peer believes that both the first peer and the arbiter are dishonest they can remove that arbiter from their list of trusted arbiters.

The same happens in the opposite case: if a peer doesn't get a preimage they can notify the arbiter they hadn't received anything. The arbiter may try to ask the other peer for the preimage and, if that fails, settle the dispute for the side of that first peer, which can proceed to fail the HTLC is has with someone else on that route.

@ 3bf0c63f:aefa459d

"Você só aprendeu mesmo uma coisa quando consegue explicar para os outros"

Mentira. Tá certo que existe um ponto em que você acha que sabe algo mas não consegue explicar, mas não necessariamente isso significa não saber. Conseguir explicar não depende de saber, mas de verbalizar. Podemos saber muitas coisas sem as conseguir verbalizar. Aliás, para a maior parte das experiências humanas verbalizar é que é a parte difícil. Por último, é importante dizer que a verbalização é uma abstração e portanto quando alguém tenta explicar algo e se força a fazer uma abstração está arriscando substituir a experiência concreta ou mesmo o conhecimento difuso de algo por aquela abstração e com isso ficar mais burro -- me parece que esse é risco é maior quanto mais prematura for a tentativa de explicação e quando mais sucesso a abstração improvisada fizer.

@ 3bf0c63f:aefa459d

Multi-service Graph Reputation protocol

The problem

1. Users inside centralized services need to know reputations of other users they're interacting with;
2. Building reputation with ratings imposes a big burden on the user and still accomplishes nothing, can be faked, no one cares about these ratings etc.

The ideal solution

Subjective reputation: reputation based on how you rated that person previously, and how other people you trust rated that person, and how other people trusted by people you trust rated that person and so on, in a web-of-trust that actually can give you some insight on the trustworthiness of someone you never met or interacted with.

The problem with the ideal solution

1. Most of the times the service that wants to implement this is not as big as Facebook, so it won't have enough people in it for such graphs of reputation to be constructed.
2. It is not trivial to build.

My proposed solution:

I've drafted a protocol for an open system based on services publishing their internal reputation records and indexers using these to build graphs, and then serving the graphs back to the services so they can show them to users when it is needed (as HTTP APIs that can be called directly from the user client app or browser).

Crucially, these indexers will gather data from multiple services and cross-link users from these services so the graph is better.

https://github.com/fiatjaf/multi-service-reputation-rfc

The first and single actionable and useful feedback I got, from @bootstrapbandit was that services shouldn't share email addresses in plain text (email addresses and other external relationships users of a service may have are necessary to establish links from users accross services), but I think it is ok if services publish hashes of these email addresses instead. At some point I will update the spec draft and that may have been before the time you're reading this.

Another issue is that services may lie about their reputation records and that will hurt other services and users in these other services that are relying on that data. Maybe indexers will have to do some investigative job here to assert service honesty. Or maybe this entire protocol is just failed and we will actually need a system in which users themselves will publish their own records.

See also

• P2P reputation thing
• idea: Graph subjective reputation as a service
• https://github.com/jangerritharms/reputation_systems

@ 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/

@ 957df479:13e9e08e

LiaScript Course

Course Main Title

This is your course initialization stub.

Please see the Docs to find out what is possible in LiaScript.

If you want to use instant help in your Atom IDE, please type lia to see all available shortcuts.

Markdown

You can use common Markdown syntax to create your course, such as:

1. Lists

2. ordered or

3. unordered

4. ones ...

| Header 1 | Header 2 | | :--------- | :--------- | | Item 1 | Item 2 |

Images:

Extensions

 --{{0}}--

But you can also include other features such as spoken text.

  --{{1}}--

Insert any kind of audio file:

   {{1}}

?audio

 --{{2}}--

Even videos or change the language completely.

   {{2-3}}

!?video

  --{{3 Russian Female}}--

Первоначально создан в 2004 году Джоном Грубером (англ. John Gruber) и Аароном Шварцем. Многие идеи языка были позаимствованы из существующих соглашений по разметке текста в электронных письмах...

{{3}}

Type "voice" to see a list of all available languages.

Styling

The whole text-block should appear in purple color and with a wobbling effect. Which is a bad example, please use it with caution ... ~~ only this is red ;-) ~~

Charts

Use ASCII-Art to draw diagrams:

                                Multiline
1.9 |    DOTS
    |                 ***
  y |               *     *
  - | r r r r r r r*r r r r*r r r r r r r
  a |             *         *
  x |            *           *
  i | B B B B B * B B B B B B * B B B B B
  s |         *                 *
    | *  * *                       * *  *
 -1 +------------------------------------
    0              x-axis               1

Quizzes

A Textquiz

What did the fish say when he hit a concrete wall?

[[dam]]

Multiple Choice

Just add as many points as you wish:

[[X]] Only the **X** marks the correct point.
[[ ]] Empty ones are wrong.
[[X]] ...

Single Choice

Just add as many points as you wish:

[( )] ...
[(X)] <-- Only the **X** is allowed.
[( )] ...

Executable Code

A drawing example, for demonstrating that any JavaScript library can be used, also for drawing.

```javascript // Initialize a Line chart in the container with the ID chart1 new Chartist.Line('#chart1', { labels: [1, 2, 3, 4], series: [[100, 120, 180, 200]] });

// Initialize a Line chart in the container with the ID chart2 new Chartist.Bar('#chart2', { labels: [1, 2, 3, 4], series: [[5, 2, 8, 3]] }); ```

Projects

You can make your code executable and define projects:

``` js -EvalScript.js let who = data.first_name + " " + data.last_name;

if(data.online) { who + " is online"; } else { who + " is NOT online"; } json +Data.json { "first_name" : "Sammy", "last_name" : "Shark", "online" : true } ```

More

Find out what you can even do more with quizzes:

https://liascript.github.io/course/?https://raw.githubusercontent.com/liaScript/docs/master/README.md

@ 3a8a16a7:f4c3b0b4

lkhkjhlk

!?

@ 2ce0697b:1ee3d3fc

Excerpt

Special Jurisdictions, Free Cities and Bitcoin Citadels are the sly roundabout way that is removing the market of living together from the hands of the government, without violence and in a way that they can´t stop it. With Bitcoin as the backbone of a new societal order, we are beginning to disrupt the old paradigm.

---

“If you have built castles in the air, your work need not be lost; that is where they should be. Now put the foundations under them.” ― Henry David Thoreau, Walden

---

The problem: lack of freedom in the physical realm

Freedom is essential to human life. Being free is what matters. That´s our target, always. No matter the time or space. We pursue freedom because we know its the right thing to do. Freedom is the right to question and change the stablished way of doing things.

Where can we find some freedom? Certainly in the cyberspace. The cyberspace is a free space. Humanity has been blessed by the magic of cryptography, a technology that gave us all the necessary tools to operate in that environment without intervention of undesired third parties.

In cyberspace cryptography performs the function of an impenetrable cyberwall. So, whatever we build in cyberspace can be perfectly protected. Thank to this cybernetic walls we can be sure that the gardens we build and nurture will be protected and cannot be trampled. When we build our digital gardens we have the keys to open the doors to let in whoever we want and most important to leave out whoever we don´t want. In the digital world we can already perfectly interact with one and another in a peer to peer way, without intervention of undesired third parties.

In cyberspace we have Bitcoin for freedom of money and Nostr, torrent and Tor for freedom of information and speech. These open-source protocols are designed to fully realize and expand the promise of freedom, and they certainly deliver what they promise.

So, thanks to the magic of asymmetric cryptography, we´ve already achieved sufficiently descentralization and the possibility of any level of desired digital privacy. Cryptoanarchists and cypherpunks have set their conquering flag in cyberspace and there´s no force on Earth than can remove it. The digital world cannot escape the rules of cryptography. This is great but it only works in the digital realm, meanwhile in the physical realm we are overrun by centralized attackers due to the impossibility of the creation of impenetrable walls such as the ones we have online.

Humans have the upper hand in creating impenetrable walled gardens in cyberspace, but in the physical space authoritarians have the upper hand in bullying physical persons.

The physical world is also naturally free. According to natural law each person is free to do whatever he wants as long as it doesn´t hurt other people. However due to unnatural -artificial and inhuman- centralization of power, the natural freedom of the physical world has been completely undermined. Mostly by Governments, the entities that centralize violence and law.

Bitcoin as a bridge between both realms

Let´s take a look at one connection between both realms, the physical and the digital world. Bitcoin layer one is made essentially of software plus hardware. It consists of any software that produces the same output as the reference implementation - Bitcoin core- and the hardware needed to run that software. Layer two, three or any other layer above, is made essentially of other software and other hardware that interacts with layer one in some way. All these layers, one, two and subsequent, are completely protected by cryptography and a set of game theories that have been successfully tested. Each new block added to the timechain is a testimony of the unstoppable force of freedom and meritocracy.

Before layer one we have Bitcoin layer zero, which is essentially the sum of all actions and inactions done by bitcoiners regarding to or because of bitcoin. In other words, layer zero is composed by flesh and bone people interacting in some way with layer one of the bitcoin network.

Hence, an attack on a bitcoiner - on his way of life- is an attack on bitcoin, the network itself. First because it is an attack on a layer zero node, the physical person, the bitcoiner under duress or coercion. And second because is also an attack on the store-of-value-aspect of bitcoin. Nowaday, the most common attack against bitcoiners is the entirety of compliance regulations. This is the sum of all coercive regulations,such as laws, threats of more laws, imprisonment, threats of more imprisonment, taxation, threats of more taxation, requirements to prove the origin of funds, coercive removal of privacy such as the travel rule, unnecessary bureaucracy such as the need to obtain a money transmitting license and many others rules, in a never stopping inflationary coercive legislation.

If a physical attack is preventing any bitcoiner to exchange the value he created for bitcoin due to any kind of artificial obstacles -such as any kind of compliance- that specific attack is successful in the sense that even though the whole network keeps operating, the attack itself diminishes the value of all the bitcoins.

So, even if layer-zero cannot be taken down, every interference on this layer is an attack on the bitcoin network. Attacks on layer one, two or any other layer that exists in the cyberspace can interfere with the network but they may hardly subtract any value from it. For example we have already been through plenty of times where hashing power was diminished due to government intervention and the bitcoin network remain completely unaffected.

On the other hand successful attacks on layer zero subtract potential, but real and demonstrable value. This value is equal to the amount of value the frustrated user would have added to the network if he would have been able to use it freely, that means if he would have sold his product without the cost of compliance. I´ll demonstrate this in the next chapter.

The cost of compliance

Alice is a merchant specialized in a specific area and topic. She studied the market, her business, her suppliers, consumers, the logistics involved, marketing, design, and everything necessary to become a successful entrepreneur. After investing a considerable amount of resources, she developed a perfect product. Or at least she considers it perfect, that is, the best in its class. While developing everything necessary to create her product, she met Bob, who became her main lead and stereotype of a buyer persona. She knows what Bob wants and she wants to sell it to him. According to Alice's calculations, for her business to be viable, she must sell the product at ten satoshis per unit, and fortunately, Bob is willing to pay that price for it. Alice's product is finished, ready to hit the market, but just before sending it to production, Alice decides to take a pause to analyze her reality. Before taking the public action of making her product available in the open market, Alice analyzes her material, political, and legal reality. In doing so, she realizes that she lives under the jurisdiction of a State. She learns that the Government prescribes through its regulations how she must behave. She analyzes that in order to sell her product legally, in compliance, she must make a series of modifications to it. The product before hitting the shelves must first be modified both in the way it is presented to the market and also regarding certain technical characteristics that it possesses. She must also modify the way it produces her product by changing the contractual relationship with its suppliers, distribution channels, and all other types of logistics involved. She must make all these changes even if they bring about significant and insurmountable inefficiencies.

Likewise, Alice also sees that she not only has to modify the product but also has to meet tax obligations. In addition to paying an accountant since the tax obligations by some irrational reason are not calculated by the creditor. Additionally, she must hire other professionals to assist her in studying the current regulations and how they should be applied in all stages of production, distribution, and sale of her product.

Alice, being a rational person, wishes to avoid having to make these modifications since they increase her costs while also decreasing the quality of her product. But when studying compliance, that is, the entirety of applicable regulations, she also examines the consequences of not being in compliance. Alice realizes that if she does not comply with the regulations, she risks having all her assets legally confiscated, going to prison, being killed while they try to capture her to imprison her, and, if she goes to prison, being tortured in jail by other inmates or by State officials in charge of holding her in that place. So, since Alice does not want to suffer these negative consequences, she decides to modify the product and be in compliance.

So, Alice makes the necessary changes and puts her new version of the product on the market. Then she has the following dialogue with Bob, her lead, the interested party in acquiring the product.

Bob: - Hey Alice, nice meeting you here in this market. I came to buy the product you were developing and told me about. However, this product I´m seeing now is not what you promised me. This is clearly inferior.

Alice: - Yeah, I know. I'm sorry Bob, but I prefer to sell this inferior product rather than risk having all my assets confiscated, going to prison, being killed while they try to capture me, and if they don´t kill but managed to put me in jail I could be tortured there.

Bob: - Ok, no problem. Thats quite understandable. I don´t believe anyone would prefer those kind of experiences. But given the quality of the product, I no longer intend to pay you ten satoshis; I only offer you eight. Shall we close the deal?

Alice: - I'm sorry Bob, but I can't sell it to you for eight sats. Due to government intervention and its requirements, now I can't even sell it for less than thirteen satoshis.

Bob: - Ok. Considering this I prefer not to purchase it. I will keep looking for alternatives. Bye

Some time later, Charlie arrives at the market, who is also interested in the product and, despite it not being like the original version, decides to purchase it by paying the thirteen satoshis demanded by the seller Alice.

Meanwhile, in the same universe, we have Daniel, the last character in this example. Daniel is a merchant competing with Alice. Daniel has a product that is very similar, practically identical to the one originally designed by Alice. Like Alice, Daniel initially also wants to sell it for ten satoshis. Just like Alice, before heading to the market, Daniel analyzes the reality in which he lives. And it turns out that he also lives under the jurisdiction of a State. Daniel too then analyzes the entirety of the applicable regulations and also comes to the conclusion that to comply with them, he would also need to modify the product and cover all the additional expenses artificially generated to be in compliance.

However, Daniel's ethics are different from Alice's. Daniel understands that his product is indeed perfect (the best in its class) and that therefore modifying it would go against its essence. Daniel understands that changing the product would be a betrayal of his creation and therefore a betrayal of his own self and the essence of his being. Daniel conducts an ethical analysis of his actions and the moral implications of putting the product on the market. Daniel sees that the product not only does not harm anyone but is also made to be freely acquired by adults who give their consent for its purchase and subsequent use. Daniel also understands that paying taxes only serves to promote the slavery system driven by fiat and that whenever he can avoid collaborating with the immoral fiat system, it is his ethical obligation to do so. Likewise, Daniel highlights the hypocrisy and inefficiencies of anti-money laundering regulations, as well as the futility of requiring licenses for naturally free acts that do not harm others. For all these reasons, Daniel decides to sell the product in its current state irregardles of compliance regulations.

However, before going to market, Daniel also studies the possible consequences of neglecting compliance. By doing so, Daniel sees that if he does not comply with the regulations, he risks having all his assets legally confiscated, going to prison, being killed while they attempt to capture him to imprison him, and, in the event of going to prison, being tortured in jail by other inmates or by State officials responsible for holding him in that place. So, since Daniel is a rational person who does not want to suffer these negative consequences but also does not want to betray his product and himself, he decides to take the risk of not being in compliance. After making this decision, Daniel puts the product on the market and there he meets Bob. In doing so, they converse in the following terms:

Bob: - Hey Daniel, this product is exactly what I was looking for. A product like the one promised by Alice but never delivered. I love it! I offer you ten satoshis for it.

Daniel: - Thank you for your feedback Bob and for the offer! However I am currently selling it for eleven satoshis. Ten satoshis seems like a good price to me, and it was indeed my original intention to sell it for that amount because at that price I achieve competitiveness and a sustainable business model.

Bob: - So why are you asking me for eleven satoshis? Interrupts Bob

Daniel: - Because that price is calculated before assessing compliance and the risks associated with non-compliance. By not complying with the regulation, I managed to maintain the quality of the product and avoided a large amount of unnecessary expenses, but there is no way to avoid the risk of facing penalties for non-compliance. To bring this product to market, I had to incur several expenses in order to minimize the risk of non-compliance as much as possible. While I am taking all reasonable actions to prevent all of my assets from being legally confiscated, from going to prison, from being killed while they try to capture me, and in case of going to prison, from being tortured, the reality is that I still run the risk of all that, or part of all that, happening to me, my family, or any of my company's employees. The remaining risk balance is transferred to the price along with the costs of mitigating those risks. The total of those costs and the remaining risk I estimate them at one satoshi per unit of product. Therefore, I can't sell you the product for ten satoshis, but I can sell it to you for eleven.

To which Bob, lacking a better option in the market, ends up buying the product for eleven satoshis.

In summary: two products were made by two different merchants whose business model allowed them, in both cases, to put the product on the market at a rate of ten satoshis per unit. However, in one case, a lower quality product was sold for thirteen satoshis, and in the other case, a higher quality product was sold for eleven satoshis. That is to say, in the first case there was an overprice or inefficiency objectively measured at three satoshis, while in the second case there was an overprice or inefficiency of one satoshi. So, we are facing a total loss of value equivalent to four satoshis. The value represented by these four satoshis was absorbed by the inefficiency programmed and ruled by the State. The example shows us that whether one chooses the compliance route, as Alice did, or the free market route, as Daniel did, in both cases the existence of regulations generates an additional cost to the market. In this example the state attack on layer zero was successful and extracted from the Bitcoin network a value of four satoshis.

Bitcoin is money

Bitcoin is many things but essentially is money. And money sole purpose is to store value in order to facilitate future exchanges of products and services with other people. Without the products and services to be exchanged for the money, money itself would be useless and worthless. We only use money because we may require favors, benefits, services, products from other people in the future. And we don´t know which services and products we´ll need nor exactly when we are goint to need them.

The total value of bitcoin equals to infinity divided twenty one millions. This is because the total worth of the network mirrors the total worth of accumulated capital by the entirety of mankind throughout its entire history. That is clearly a lot of value. But if the if the dividend equals zero then the divisor is also zero and if the dividend growth is obstructed through artificial means -such as compliance- then the divisor growth is also obstructed.

Bitcoin layer zero, the bitcoiners and the services and products we create, are what give value to the twenty one million units of bitcoin.

Freedom is without a doubt the best context for value creation. So, the more and better games we can create that allow humankind to find a way to exercise freedom, then the most value we can add to all the layers of the network.

This is why the most important layer of the whole bitcoin phenomenon is layer zero, the bitcoiners. Hence the problem to be solved is not how to prevent bitcoin - layer one upwards- from successful attacks. The problem to solve is how to prevent attacks on layer zero. Or in other words, the problem to be solved is how to get bitcoiners in the physical world to practice the same level of freedom that bitcoin achieves in the cyberspace.

Summary of the first part of this article: freedom in cyberspace has already been conquered and each further development in the digital realm contributes to further developments but only in the same realm. Meanwhile in the physical space, the layer zero of bitcoin is under constant attacks that successfully extract value from it.

Exercising freedom in a sly roundabout way

In 1984 the Austrian economist Friedrich Hayek predicted that we couldn´t take money with violence out of the hands of government. He stated that we needed to do it in a sly roundabout way. Twenty five years later Satoshi Nakamoto discovered the sly roundabout way actually introducing something that the government couldn´t stop. Thus fulfilling Hayek´s prophecy.

Bitcoin is a sly roundabout way that removed money without violence from the hands of the government in a way that they can´t stop it.

Cryptography in general and protocols such as Tor and Tails are a sly roundabout way that removed confidential information from the hands of the government without violence in a way that they can´t stop it.

Nostr is a sly roundabout way that removed social media and public information from the hands of the government without violence in a way that they can´t stop it.

Special Jurisdictions, Free Cities and Bitcoin Citadels are the sly roundabout way that is removing the market of living together from the hands of the government without violence in a way that they can´t stop it.

So, what are Special Jurisdictions, Free Cities and Bitcoin Citadels? To understand what they are we can take a look at the current mainstream market of living together, at how the physical space is organized. Essentially the entire planet Earth and its surroundings are run by a conglomerate of Governments. They create all the rules, regarding every aspect of life, of all the individuals, and enforce every rule through coercive means.

In the mainstream market of living together individuals have several alternatives to pick from. We can choose to live in a natural city or a pre design city, in a public neighborhood or private neighborhood or even in an intentional community with common interest amongst the users. But irregardless of the choice, every product offered in the mainstream market has the sames rules which are established by the host state to the entirety of organizations in his territory. In the mainstream market, even the most different products abide by the same high level rules such as criminal law, civil law, taxation laws, customs, enviromental laws, money laundering regulations and many others. To abide to the sum of all the laws and regulations is to be in compliance.

The centralization of regulations makes extremely difficult to experiment in market of living together. The less experimentation is allowed, the more human progress is hindered.

So what is the sly roundabout that fixes this? What are Special Jurisdictions, Free Cities and Bitcoin Citadels? I´m using the term Special Jurisdictions as an umbrella term that includes the entire spectrum of iterations of products that aim to modify the mainstream rules of the market of living together.

This term includes all the different models such as Charter Cities, Free Cities, Special Economic Zones, microstates, micropolis, start up societies, government as a service, self governing jurisdictions, autonomous intentional communities, network states and Bitcoin Citadels. The array of possible iterations is huge and permanently expanding. What they all have in common is that each of these experiments aims to create a functional game theory that replaces the lack of unbreakable walls in the physical space.

Let´s take a look of a couple of examples. Special Economic Zones are bounded areas of countries that have their own rules and regulations. Worldwide, there are more than five thousands special economic zones located in more than hundred countries.

One of them is the special economic zone of Shenzhen in China. The Chinese government allowed Shenzhen the freedom to experiment with certain practices that were prohibited in the rest of the country at the time. This included allowing foreign companies to make direct investments in China, allowing people to buy and sell land, allowing Chinese people to set up their own private businesses and relaxation of the system that limited internal migration within China for Chinese citizens. It served as a place where China could experiment with market reforms. The experiment was such a huge economic success that it was replicated in many other areas of the country.

Another place that has made extensive use of special economic zones is Dubai. The monarchic Government has more than 30 SEZs. In this case one of the many obstacles removed by the host state its the monopoly of the legal system. Dubai Government allowed the special economic zone to have its own independent legal system thus conceding a modification of the mainstream rules in that area.

This kind of projects, such as Dubai or Shenzhen, are a top-to-down product. Fully created by the Governments thus compliant with their own regulations.

On the other side of the spectrum we have Citadels and several other archetypes of not so compliant projects .

For example the Free Commune of Penadexo it´s a grassroots project building a freedom-oriented community in one of Spain’s abandoned villages.

It´s model is based on building a peer to peer society avoiding government intervention as much as possible. They stablished themselves in an abandoned historic village and the started to track down the owners to purchase as much property as possible. Meanwhile, they are living there and expanding their users base while also reconstructing buildings.

This is an example of a completely different way of dealing with the Government. While Special Economic Zones are fully compliant and created top to down, this model on the other hand is bottom-up and aims to add value to the users relying in factual freedom which is exercised by stablishing the commune away from heavily populated centers where Government grip is tighter. Under this model the interaction with the Government is kept as low as possible. Their strategy relies in ignoring the Government as much as possible and being a good neighbor. With this simple and effective tactic some Citadels enjoy the benefits of liberty in their lifetime without needing to spend huge resources in governmental lobby.

There are countless models or archetypes of Bitcoin Citadels trying to solve the obstacles in different ways, trying to restart the system. And one of the challenges of the Bitcoin Citadels is how to connect the different projects to boost and help each other.

This is where The Meshtadel comes into play. The Meshtadel is a system where decentralized tactics are used to help and defend citadels connected in a global network. With real life connections with fellow bitcoiners. Its an organization equivalent to the hanseatic league built under a starfish model. If you cut off a spider’s head, it dies, but if you cut off a starfish’s arm, it can regenerate and even grow into a new starfish.
The Meshtadel its a network of peer relationships, with ambiguous leadership roles, trust among participants, a shared ideology and vision based on the Bitcoin ethos, and an open system where new nodes - bitcoin citadel builders - can participate.

The long term goal of the Bitcoin Meshtadel is to help Bitcoin Citadels to gain the support of a critical mass of the total population. If enough people see that Bitcoin is as peaceful as it gets, in the long run, some nations could become friendly and supportive enough to legally tolerate the Bitcoin Citadel inside its territory in the form of a Bitcoin safe haven. In the Meshtadel we are fighting from the moral high ground using memes, Nostr notes and zapping our way into freedom creating an online and offline circular economy.

TO CONCLUDE:

Special Jurisdictions, Free Cities and Bitcoin Citadels are the sly roundabout way that is removing the market of living together from the hands of the government, without violence and in a way that they can´t stop it.

Nation states, abusing the myth of authority, have halted development on the market of living together for so long that a blooming freer market is eating its lunch. The sovereign individual thesis is live and continuously expanding. The network state is forming and intentional communities are flourishing all around the world reshaping globally the relationship between individuals and the governments.

With global internet connections, uncensorable means of communication and Bitcoin as the backbone of a new societal order, we are beginning to disrupt the old paradigm.

The fashion of the present world is passing away, let’s help it to move forward along by building Special Jurisdictions, Free Cities and Bitcoin Citadels.

--- --- --- --- --- --- --- --- ------

byCamiloat 875.341 timechain.

If you find this content helpful, zap it to support more content of the sort and to boost the V4V model.

@ 3bf0c63f:aefa459d

Idéia de um sistema jurídico centralizado, mas com um pouco de lógica

um processo, é, essencialmente, imagino eu na minha ingenuidade leiga, um apelo que se faz ao juiz para que este reconheça certos fatos como probantes de um certo fenômeno tipificado por uma certa lei.

imagino então o seguinte:

uma petição não é mais um enorme documento escrito numa linguagem nojenta com referências a leis e a evidências factuais espalhadas segundo a (in) capacidade ensaística do advogado, mas apenas um esquema lógico - talvez até um diagrama desenhado (ou talvez quem sabe uma série de instruções compreensíveis por um computador?) - mostrando a ligação entre a lei e os fatos e os pedidos, por exemplo:

1. a lei tal diz que ninguém pode vender
2. fulano vendeu cigarros
3. é prova de que fulano vendeu cigarros ia foto tirada na rua tal no dia tal que mostra fulano vendendo cigarros
4. a mesma lei pede que fulano pague uma multa

este exemplo está ainda muito verborrágico, mas é só um exemplo simples. coisas mais complicadas precisariam de outras formas de expressão caso queiramos evitar as longas dissertações jurídicas em voga.

a idéia é que o esquema acima vale por si. um proto-juiz pode julgá-lo como válido ou inválido apenas pela sua lógica interna.

a outra parte do julgamento seria a ligação desse esquema com a realidade externa: anexados à petição viriam as evidências. no caso, anexada ao ponto 3 viria uma foto do fulano. ao ponto 1 também precisa ser anexado o texto da lei referida, mas isto pode ser feito automaticamente pelo número da lei.

uma vez que tenhamos um esquema lógico válido um outro proto-juiz, ou vários outros, pode julgar individualmente cada evidência: ver se o texto da lei confere com a interpretação feita no ponto 1, e se a foto anexada ao ponto 3 é mesmo a foto do réu vendendo cigarro e não a de um urso comendo laranjas.

cada um desses julgamentos pode ser feito sem que o proto-juiz tenha conhecimento do resto das coisas do processo: o primeiro proto-juiz não precisa ver a foto ou a lei, o segundo não precisa ver o esquema lógico ou a foto, o terceiro não precisa ver a lei nem o esquema lógico, e mesmo assim teríamos um julgamento de procedência ou não da petição ao final, o mais impessoal e provavelmente o mais justo possível.

a defesa consistiria em apontar erros no esquema lógico ou falhas no nexo entre a realidade é o esquema. por exemplo:

1. uma foto assim não é uma prova de que fulano vendeu, ele podia estar só passando lá perto.
2. ele estava de fato só passando lá perto. do que é prova este documento mostrando seu comparecimento a uma aula do curso de direito da UFMG no mesmo horário.

---

perdoem-me se estiver falando besteira, mas são 5h e estou ainda dormindo. obviamente há vários pontos problemáticos aí, e quero entendê-los, mas a forma geral me parece bem razoável.

o que descrevi acima é uma proposta, digamos, de sistema jurídico que não se diferencia em nada do nosso sistema jurídico atual, exceto na forma (não no sentido escolástico). é também uma tentativa de compreender sua essência.

as vantagens desse formato ao atual são muitas:

• menos papel, coisas pra ler, repetição infinita de citações legais e longuíssimas dissertações escritas por advogados analfabetos que destroem a língua e a inteligência de todos
• diminuição drástica do tempo gasto por cada juiz em cada processo
• diminuição do poder de cada juiz (se cada ato de julgamento humano necessário em cada processo pode ser feito por qualquer juiz, sem conhecimento dos outros aspectos do mesmo processo, tudo é muito mais rápido, e cada julgamento desses pode ser feito por vários juízes diferentes, escolhidos aleatoriamente)
• diminuição da pomposidade de casa juiz: com menos poder e obrigações maus simples, um juiz não precisa ser mais uma pessoa especial que ganha milhões, pode ser uma pessoa comum, um proto-juiz, ganhando menos (o que possibilitaria até ter mais desses e aumentar a confiabilidade de cada julgamento)
• os juízes podem trabalhar da casa deles e a qualquer momento
• passa a ter sentido a existência de um sistema digital de processos (porque é ridículo que o sistema digital atual seja só uma forma de passar documentos do Word de um lado para o outro)
• o fim das audiências de conciliação, que são uma monstruosidade criada apenas pela necessidade de diminuir a quantidade de processos em tramitação e acabam retirandobo sentido da justiça (as partes são levemente pressionadas a ignorar a validade ou não das suas posições e fazer um acordo, sob pena de o juiz ficar com raiva delas depois)

milhares de precauções devem ser tomadas caso um sistema desses vá ser implantado (ahahah), talvez manter uma forma de julgamento tradicional, de corpo presente e com um juiz ou júri que tem conhecimento de toda situação, mas apenas para processos que chegarem até certo ponto, e assim por diante.

Ver também

• P2P reputation thing para um fundamento de um sistema jurídico anárquico.

@ 3bf0c63f:aefa459d

Why I don't like NIP-26 as a solution for key management

NIP-26 was created out of the needs of the Nostr integration at https://minds.com/. They wanted Minds users to be able to associate their "custodial" Nostr key with an external self-owned key. NIP-26 looked like a nice fit for the job, because it would allow supporting clients to associate the two identities statelessly (i.e. by just seeing one event published by Minds but with a delegation tag on it the client would be able to associate that with the self-owned external key without anything else[^1]).

The big selling point of NIP-26 (to me) was that it was fully optional. Clients were free to not implement it and they would not suffer much. They would just see "bob@minds.com" published this, and "bob-self-owned" published that. They would probably know intuitively that these two were the same person, or not, but it wouldn't be an issue. Both would still be identified as Bob and have a picture, a history and so on. Moreover, this wasn't expected to happen a lot, it would be mostly for the small intersection of people that wanted to have their own keys and also happened to be using one of these "custodial Nostr" platforms like Minds.

At some point, though, NIP-26 started to be seen as the solution for key management on Nostr. The idea is that someone will generate a very safe key on a hardware device and guard it as their most precious treasure without it ever touching the internet, and use it just to sign delegation tags. Then use multiple of these delegation tags, one for each different Nostr app, and maybe rotate them every month or so, details are unclear.

This breaks the previous expectations I had for NIP-26 entirely, as now these keys become faceless entities that can't be associated with anything except their "master" key (the one that is in cold storage). So in a world in which most Nostr users are using NIP-26 for everything, clients that do not implement NIP-26 become completely useless, as all they will see is a constant stream of random keys. They won't be able to follow anyone or interact with anyone, as these keys will not identify any concrete person on their back, they will vanish all the time and new keys will show up and the world will be chaotic. So now every client must implement NIP-26 to become usable at all, it is not optional anymore.

You may argue that making NIP-26 a de facto mandatory NIP isn't a bad thing and is worth the cost, but I think it breaks a lot of the simplicity of the protocol. It would probably be worth the cost if we knew NIP-26 was an actual complete solution, but it definitely is not, it is partial, and not the most elegant thing in the world. I think key management can be solved in multiple different ways that can all work together or not, but most importantly they can all remain optional.

More thoughts on these multiple ways can be found at Thoughts on Nostr key management.

If I am wrong about all this and we really come to the conclusion that we need a de facto mandatory key delegation method for Nostr, so be it -- but in that case, considering that we will break backwards-compatibility anyway, I think there might be a better design than NIP-26, more optimized and easier to implement, I don't know how exactly. But I really think we shouldn't rush that.

[^1]: as opposed to other suggestions that would also work, but that would require dealing with multiple events -- for example, the external user could publish a new replaceable event -- or use kind:0 -- to say they wanted to grandfather the Minds key into their umbrella, while the Minds key would also need to signal its acceptance of that. This also had the problem of requiring changes every time a new replaceable event of such kind was found. Although I am unsure now, at the time me and William agreed this was worse than NIP-26 with the delegation tag.

@ 866e0139:6a9334e5

Autor: Thomas Eisinger. Dieser Beitrag wurde mit dem Pareto-Client geschrieben. Sie finden alle Texte der Friedenstaube und weitere Texte zum Thema Frieden hier.**

---

Die neuesten Artikel der Friedenstaube gibt es jetzt auch im eigenen Friedenstaube-Telegram-Kanal.

---

Vor Kurzem war ich bei einem «Ecstatic Dance» (mehr dazu z. B. hier) dabei. Wer das noch nicht kennt: es lohnt sich! Irgendwann in diesem speziellen Space bekam ich einen Gedanken - oder er kam von irgendwo zu mir: die Vorstellung, dass niemand in meiner Reihe von Eltern, Großeltern, Ahnen je an so etwas hätte teilnehmen können. Einmal, weil es das damals nicht gab. Zum Zweiten, weil ihr Mind niemals für so etwas offen gewesen wäre, gar nicht sein konnte. Sie alle waren einfache Menschen, die genug damit zu tun hatten für das Überleben der eigenen Familie zu sorgen. Urlaub war ein Fremdwort, intellektuelle Faxen gab es ganz sicher keine. Diese meine Vorstellung erschuf ein inneres Bild in mir: ich sah meine beiden Großmütter wild und lebensfroh durch den Raum tanzen! (Übrigens wurden beide 95 Jahre alt, trotz zwei Kriegen, Währungsreform, Hunger und ohne jemals Sport getrieben oder Ernährungsratgeber gelesen zu haben. Dies nur am Rande).

Ich erfreute mich an dem Bild der tanzenden Großmütter, konnte mich eines breiten Grinsens nicht erwehren. Nach dieser Freude wechselte mein Gefühl jäh zu Dankbarkeit. Dafür, in dieser wunderbaren Zeit leben zu dürfen. In der so viel mehr möglich ist als es jemals war. Das enge Korsett, das die Gesellschaft seit Jahrtausenden jedem auferlegt hatte, ist so viel weiter geworden. Nur, wenn man es selbst annehmen möchte (oder zumindest meint, dies tun zu müssen) kann es noch Macht ausüben. Sonst nicht. Die persönliche Freiheit ist größer als jemals zuvor, wenn man sie mit den Hundert Generationen vor uns vergleicht. Natürlich ist aktuell «the Trend not our friend», aber wir haben die Wahl, den Zeitmaßstab selbst anzulegen. 10 Jahre, 100 oder 200 Jahre? Lass es vor Deinem inneren Auge erscheinen ...

Die innere Freiheit ist größer als in all den Zeiten vor meiner Generation (Boomer). Millionen Menschen haben Meditationserfahrung, einige können sich mit Informationsfeldern (jenseits der rechtgläubigen Physik) verbinden und darüber sprechen, ohne dass sie verbrannt werden. Man muss keiner offiziellen Religion mehr folgen, um Verbindung mit dem Höheren zu erlangen. Im Gegenteil, die Ablösung von den Amtskirchen erleichtert dies für viele sogar. Wie auch immer, der eigenen Wahl stehen weder Priester noch Eltern oder starre Konventionen entgegen. Anders als vor 100 oder 200 Jahren. Just do it!

Es geht noch weiter. Wie dankbar bin ich, dass ich in dieser Zeit leben darf. Dass trotz des Leides meiner in ziemlicher Armut lebender Großeltern ihr Wille zum Überleben stärker war: nur deshalb kann ich hier sein. Ich darf all diese Vorzüge genießen, obwohl ich viel weniger hart arbeiten muss(te) als sie. Auch wurde mein Haus nicht ausgebombt und ich musste nie in den Krieg ziehen. Meine beiden Großväter ereilte dieses Schicksal. Ob mein Sohn diesem Schicksal entrinnt?

Wir sollen wieder kriegstüchtig werden. Unfassbar. Doch damit will ich diese Betrachtung nicht enden lassen. Denn nur wenn wir auch begreifen, wie gut es uns allen geht, trotz dieser Regierung, trotz Massenpropaganda, trotz dauernder medialer Panikmache: erst, wenn wir das Leben wirklich lieben, werden wir wissen, wofür es sich wirklich lohnt zu kämpfen. Nicht mit Waffe in der Hand, sondern mit Herz und Verstand.

---

LASSEN SIE DER FRIEDENSTAUBE FLÜGEL WACHSEN!

Hier können Sie die Friedenstaube abonnieren und bekommen die Artikel zugesandt.

Schon jetzt können Sie uns unterstützen:

• Für 50 CHF/EURO bekommen Sie ein Jahresabo der Friedenstaube.
• Für 120 CHF/EURO bekommen Sie ein Jahresabo und ein T-Shirt/Hoodie mit der Friedenstaube.
• Für 500 CHF/EURO werden Sie Förderer und bekommen ein lebenslanges Abo sowie ein T-Shirt/Hoodie mit der Friedenstaube.
• Ab 1000 CHF werden Sie Genossenschafter der Friedenstaube mit Stimmrecht (und bekommen lebenslanges Abo, T-Shirt/Hoodie).

Für Einzahlungen in CHF (Betreff: Friedenstaube):

Für Einzahlungen in Euro:

Milosz Matuschek

IBAN DE 53710520500000814137

BYLADEM1TST

Sparkasse Traunstein-Trostberg

Betreff: Friedenstaube

Wenn Sie auf anderem Wege beitragen wollen, schreiben Sie die Friedenstaube an: friedenstaube@pareto.space

---

Sie sind noch nicht auf Nostr and wollen die volle Erfahrung machen (liken, kommentieren etc.)? Zappen können Sie den Autor auch ohne Nostr-Profil! Erstellen Sie sich einen Account auf Start. Weitere Onboarding-Leitfäden gibt es im Pareto-Wiki.

@ 3bf0c63f:aefa459d

IPFS problems: Dynamic links

Content-addressability is cool and we all like it, but we all also know we can't live in a world without readable and memorizeable names. IPFS has proposed IPNS, the Interplanetary Name System (the names are very cool indeed), since its beggining (or maybe it was some months after the first IPFS idea, which would indicate this problem arrived as an afterthought).

It has been said IPNS would work in a manner similar to Git heads and branches (this was probably part of Juan Benet's marketing pitches that were immensely repeated in the first years, that IPFS was a mix between Torrents, Git and some other cool technology). This remains a distant promise, however. IPNS has been, for the last years, a very slow, unrecommended by their own developers and unusable way of addressing content that is basically just a pointer from a public key to an object hash.

Recommendations fall on using a domain and dnslink, the way to tell IPFS nodes you own a domain and that can be used to identify an object hash. That works, but it is not the wonder of decentralization that was promised, and still, it's just a pointer. Any key-value store, database of filesystem can do pointers.

---

Here I'm not saying, like tons of stupid people have on the internet, that IPFS should support dynamic links so we can build web apps on it. No, I would be pretty fine with just static links for static content, and continue to use the other internet protocols for things that needed to be dynamic.

@ 3bf0c63f:aefa459d

LessPass remoteStorage

LessPass is a nice idea: a password manager without any state. Just remember one master password and you can generate a different one for every site using the power of hashes.

But it has a very bad issue: some sites require just numbers, others have a minimum or maximum character limits, some require non-letter characters, uppercase characters, others forbid these and so on.

The solution: to allow you to specify parameters when generating the password so you can fit a generated password on every service.

The problem with the solution: it creates state. Now you must remember what parameters you used when generating a password for each site.

This was a way to store these settings on a remoteStorage bucket. Since it isn't confidential information in any way, that wasn't a problem, and I thought it was a good fit for remoteStorage.

Some time later I realized it maybe would be better to have a centralized repository hosting all weird requirements for passwords each domain forced on its users, and let LessPass use data from that central place when generating a password. Still stateful, not ideal, not very far from a centralized password manager, but still requiring less trust and less cryptographic assumptions.

• https://github.com/fiatjaf/lesspass-remotestorage
• https://addons.mozilla.org/firefox/addon/lesspass-remotestorage/
• https://chrome.google.com/webstore/detail/lesspass-remotestorage/aogdpopejodechblppdkpiimchbmdcmc
• https://lesspass.alhur.es/

See also

• hledger-web
• TiddlyWiki remoteStorage

@ 3c389c8f:7a2eff7f

Let go of the algorithms and truly discover what it means to explore. Social media used to mean something. Once upon a time, it was a way to stay connected to friends, family, and colleagues over things we enjoy. We could share, laugh, and learn. Over time, it has devolved into cheap entertainment at the cost of our privacy. Our relationships and interests have been shoved into a corner in order to make room for "suggested posts" and "for you" content designed to evaluate our attention for advertising purposes. We've lost what it means to truly connect, and we've lost what it means to explore our curiosities.

Enter Nostr. A protocol designed to resist authoritative censorship, just happens to fix a whole lot of other problems, too. By removing the central authority, Nostr offers its users complete control of what we feed our minds. How do we break our algorithm dependency to find better content and better relationships again? We explore and discover:

The Chronological Life.

The existence of time may be debatable but our dependence on our perception of it is not. We live our lives chronologically. Why do our online lives need to be any different? There is no real reason, other than we've just gotten used to being engulfed by whatever the black box wants us to see. When we remove the algorithms, we find that online information flows just as it would in our daily lives. Important events get talked about by many people, over a long period of time. Things of less relevance fade. We see the rhythm of life reflected in our feed. This is an organic human experience transferred to the digital world. We depend on the people we know and the sources we trust to keep us informed about what really matters. We have fun, we move on. Nearly every Nostr social client brings this experience front and center through the traditional follow feed. Many use replies as a way to show you what is worth talking about for more than a hot minute. Its what old social media gave us, then took away. Nostr gives it back. It's not the only way to enjoy Nostr, though, so let's continue.

"The Human Animal Differs From the Lesser Primates in His Passion for Lists"

Who doesn't love lists? (besides maybe to-do lists.) List functionality on Nostr is a powerful way to curate your feeds. You can make lists of artists, vendors, friends, or whatever you want. They can be public or private. You can subscribe to other people's public lists too. Make one to share with your friends. Many clients have list support and management. Amethyst, Nostur, Voyage, and Nostrudel are a few that come to mind. Nostr.band and Listr.lol offer in depth list management. Some clients even support lists for specific notes so that you can curate a feed by topic or aesthetic to share with your friends.

Being John Malcovich.

Everyone has a different view of Nostr. Do you want to see what someone else is seeing? Sign in with any npub to get a different perspective. You might find profiles and content that you didn't know existed before. Some clients integrate variations of this feature right into their apps, so you don't have to log out of your account in order to step through that tiny door.

DV-what? DVM.

Data Vending Machines. These fancy little things are AIs tasked with a simple job: to find content for you. Most of these feeds are free, though some more personalized ones require a small fee. Many DVM services are stand-alone apps, like Vendata and Noogle . These clever Nostr clients will let you do a lot more than just create feeds to browse notes. Explore if you wish. A few social clients have DVMs integrated, too, so if you see "discovery" or similar term on a tab, be sure to check it out.

Relays, Man. Relays.

It's right there in the name. Nostr- notes and other stuff transmitted by RELAY. Specialized relays exist for subjects, news, communities, personal spaces, content creators, cats... there's even a relay where everyone just says "Good Morning" to each other. Find a client that lets you browse a relay's contents, and enjoy the purest form of content discovery on Nostr. Unearthing these relays is getting better and better every day. Right now there are relay browsing capabilities in quite a few clients, like Coracle, Relay Tools, Jumble and Nostur.

The Algo Relay.

Maybe you've been busy and missed a lot. Maybe you are a sane person who rarely uses social media. Hook up with a personalized algorithm relay to catch you up on all the things you've missed. This is skirting the sharp edges of Nostr relay development, so keep in mind that not many implementations yet exist. Algo relay currently aims to bring the feel-good vibe of your chronological feed to an algorithmic feed, freeing up your time but letting you stay up with what 's going on in your social circles.

Trendy Trends.

A few clients, relays, and DVM's have developed various Trending feeds. Catch up on what's popular across a wider view of the Nostr ecosystem. If trends are your thing, be sure to check them out.

Now that you're equipped with the tools to explore Nostr, its time to go discover some great content and find your people. Feed your curiosity.

@ 3bf0c63f:aefa459d

Classless Templates

There are way too many hours being wasted in making themes for blogs. And then comes a new blog framework, it requires new themes. Old themes can't be used because they relied on different ways of rendering the website. Everything is a mess.

Classless was an attempt at solving it. It probably didn't work because I wasn't the best person to make themes and showcase the thing.

Basically everybody would agree on a simple HTML template that could fit blogs and simple websites very easily. Then other people would make pure-CSS themes expecting that template to be in place.

No classes were needed, only a fixed structure of header. main, article etc.

With flexbox and grid CSS was enough to make this happen.

The templates that were available were all ported by me from other templates I saw on the web, and there was a simple one I created for my old website.

• https://github.com/fiatjaf/classless
• https://classless.alhur.es/
• https://classless.alhur.es/themes/

@ 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

@ 3c389c8f:7a2eff7f

TL;DR visit this post for a list of signers

Your nsec/private key is your key to controlling all that you do on Nostr. Every action you take is signed by this private key, validating that was you that generated that event, whether it be a note, a like, a list, or whatever else. Like a broken record, I have to state that it is irreplaceable. YOU own your identity and no one else. It is your responsibility to keep your nsec safe, but of course, you also want to be able to use all the different apps and clients available. To aid you in this process, a few different tools have been developed. Let's take a look at some that are more common and easy-to-use, where to use them, and for what.

The Browser Extension

This is probably the simplest and most straight forward form of private key manager available. There are many options to choose from, each compatible with various, commonly used browsers, including mobile browsers. Many provide the option to manage multiple keys for different profiles. Some are simply a signer while others may include other features. The concept is very simple. The extension holds your key and exposes it only only enough to sign an event. These extensions can be set to different levels of manual approval that you can control based on the level of convenience you seek. The ease and convenience does trade off a bit of security, as your private key will be exposed momentarily each time you create an event. It is up to you to choose whether this is appropriate for your use. For casual browsing and social media use, it is a fairly good and easy to use option. Nearly all Nostr apps and clients support signing with this method.

The Remote Signer

Often referred as a "bunker", Nostr remote signers hold your private key completely offline and communicating with clients. Clients send events to the signer to be signed, which then sends back the signed event for publishing. This bunker can be hosted on your own hardware or managed by a truested 3rd party. As long as the signer is online, it can communicate as needed. The signer generates a "bunker string" that is used to communicate. These may seem cumbersome to set up, as each client that you intend to use will need its own permissions. Once all of the pieces and permissions are in place, most of this activity will happen in the background. Bunkers allow for a lot of flexibility. The "bunker string" for a single app can be shared with other users who you may want to be able to make posts on your behalf. Multiple people can manage a social media profile, while the main owner of that identity maintains control of the nsec. These bunker strings can be revoked and replaced at any time. This signing method is growing in popularity and many clients already offer support for it.

The Native Android Signer

Currently, Amber is the only native app available to handle Nostr event signing. It is an incredible tool for managing your Nostr key on your mobile device. The signing flow is similar to remote signing, as described above, but it can communicate with both your Android native Nostr apps and web clients accessed through most mobile browsers, eliminating the need for a browser extension. Similar apps are under development for iOS, but I don't use any of those devices, so covering that here will only happen via other's opinions at a later date. Check this list for current options.

NcryptSec

NcryptSec signing works by encrypting your nsec on a local device, unlocked by a password that you choose. Support for this method is very limited, as the encrypted private key stays on your device. If you intend to use Nostr through one device and few apps, this can be a very secure option, as long as you can remember your password, as it cannot be changed.

NFC and Hardware Signers

Some devices have been developed to store your nsec completely offline on a device or NFC chip, and some clients have added support for scanning/connecting to sign. I haven't personally tried any of these options, nor do I intend to promote the sale of any particular products. If you are interested in these techniques and devices, the information is not hard to find. The price of a devices varies, depending on your feature needs.

There are also DIY options that utilize existing hardware, if you are into that sort of thing.

Higher Security and Recoverability Options

Creating a scheme that allows for recovery of a lost key while maintaining the integrity of a unique identity is no easy task. The key must be fractured into shards, encrypted, and distributed across multiple servers in various locations, while you maintain a portion or portions of your own. These servers are run by trusted 3rd parties who will then sign events "with" you. Some include a scheme of running your own always online hardware to act as host for these shards. I fall short on the technical understanding of certain aspects of these processes, so I will spare you of my attempt to explain. As far as I know, there are a couple of methods underway that are worth paying attention to:

Frostr nostr:nevent1qvzqqqqqqypzqs3fcg0szqdtcway2ge7zahfwhafuecmkx9xwg4a7aexhgj5ghleqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgwwaehxw309ahx7uewd3hkctcqyrh3r7uhytc4dywjggxz24277xgqtvcadvnjfks6fram7gjpev9nuentfht

Promenade nostr:nevent1qvzqqqqqqypzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqydhwumn8ghj7un9d3shjtnhv4ehgetjde38gcewvdhk6tcprdmhxue69uhhyetvv9ujuam9wd6x2unwvf6xxtnrdakj7qpqqqq0dlpwxhw5l97yrcts2klhr9zqqpcmdfpaxm8r7hygykp630cq23ggph

For a List of signers, please visit this post.

@ 3bf0c63f:aefa459d

jiq

When someone created jiq claiming it had "jq queries" I went to inspect and realized it didn't, it just had a poor simple JSON query language that implemented 1% of all jq features, so I forked it and plugged jq directly into it, and renamed to jiq.

After some comments on issues in the original repository from people complaining about lack of jq compatibility it got a ton of unexpected users, was even packaged to ArchLinux.

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

@ 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.

@ 3c389c8f:7a2eff7f

Extentions:

https://chromewebstore.google.com/detail/flamingo-%E2%80%93-nostr-extensio/alkiaengfedemppafkallgifcmkldohe

https://chromewebstore.google.com/detail/nos2x/kpgefcfmnafjgpblomihpgmejjdanjjp

https://chromewebstore.google.com/detail/aka-profiles/ncmflpbbagcnakkolfpcpogheckolnad

https://keys.band/

https://github.com/haorendashu/nowser

The Remote Signer:

https://nsec.app/

https://github.com/kind-0/nsecbunkerd

Native Android Signer:

https://github.com/greenart7c3/amber

iOS

https://testflight.apple.com/join/8TFMZbMs

https://testflight.apple.com/join/DUzVMDMK

Higher Security Options: To start using Nostr with a secure, recoverable keypair: https://nstart.me/en

For Existing Keys: https://www.frostr.org/

Thank you to https://nostr.net/ for keeping a thorough list of Nostr apps, clients, and tools!

@ 3bf0c63f:aefa459d

Motte-and-bailey

há aqui um artigo, escrito por um sujeito provavelmente esquerdista, ateu e tal, que toca num ponto importante sobre o discurso dessas esquerdas defensoras de minorias.

ele introduz brevemente o conceito da motte-and-bailey doctrine, que é um nome bacana que deram para a estratégia que esses conhecidos e amigos seus de esquerda usam para dizer os maiores absurdos na internet e em grupos fechados esquerdistas, mas, quando confrontados por você, parecem ser mansos, inteligentes e gente boa, como você sempre esperou que fossem.

o sujeito é meio confuso, mas o fato mesmo de ele ser esquerdista valida mais ainda o argumento.

@ 266815e0:6cd408a5

I'm excited to announce the release of Applesauce v1.0.0! There are a few breaking changes and a lot of improvements and new features across all packages. Each package has been updated to 1.0.0, marking a stable API for developers to build upon.

Applesauce core changes

There was a change in the applesauce-core package in the QueryStore.

The Query interface has been converted to a method instead of an object with key and run fields.

A bunch of new helper methods and queries were added, checkout the changelog for a full list.

Applesauce Relay

There is a new applesauce-relay package that provides a simple RxJS based api for connecting to relays and publishing events.

Documentation: applesauce-relay

Features:

• A simple API for subscribing or publishing to a single relay or a group of relays
• No connect or close methods, connections are managed automatically by rxjs
• NIP-11 auth_required support
• Support for NIP-42 authentication
• Prebuilt or custom re-connection back-off
• Keep-alive timeout (default 30s)
• Client-side Negentropy sync support

Example Usage: Single relay

```typescript import { Relay } from "applesauce-relay";

// Connect to a relay const relay = new Relay("wss://relay.example.com");

// Create a REQ and subscribe to it relay .req({ kinds: [1], limit: 10, }) .subscribe((response) => { if (response === "EOSE") { console.log("End of stored events"); } else { console.log("Received event:", response); } }); ```

Example Usage: Relay pool

```typescript import { Relay, RelayPool } from "applesauce-relay";

// Create a pool with a custom relay const pool = new RelayPool();

// Create a REQ and subscribe to it pool .req(["wss://relay.damus.io", "wss://relay.snort.social"], { kinds: [1], limit: 10, }) .subscribe((response) => { if (response === "EOSE") { console.log("End of stored events on all relays"); } else { console.log("Received event:", response); } }); ```

Applesauce actions

Another new package is the applesauce-actions package. This package provides a set of async operations for common Nostr actions.

Actions are run against the events in the EventStore and use the EventFactory to create new events to publish.

Documentation: applesauce-actions

Example Usage:

```typescript import { ActionHub } from "applesauce-actions";

// An EventStore and EventFactory are required to use the ActionHub import { eventStore } from "./stores.ts"; import { eventFactory } from "./factories.ts";

// Custom publish logic const publish = async (event: NostrEvent) => { console.log("Publishing", event); await app.relayPool.publish(event, app.defaultRelays); };

// The publish method is optional for the async run method to work const hub = new ActionHub(eventStore, eventFactory, publish); ```

Once an ActionsHub is created, you can use the run or exec methods to execute actions:

```typescript import { FollowUser, MuteUser } from "applesauce-actions/actions";

// Follow fiatjaf await hub.run( FollowUser, "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d", );

// Or use the exec method with a custom publish method await hub .exec( MuteUser, "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d", ) .forEach((event) => { // NOTE: Don't publish this event because we never want to mute fiatjaf // pool.publish(['wss://pyramid.fiatjaf.com/'], event) }); ```

There are a log more actions including some for working with NIP-51 lists (private and public), you can find them in the reference

Applesauce loaders

The applesauce-loaders package has been updated to support any relay connection libraries and not just rx-nostr.

Before:

```typescript import { ReplaceableLoader } from "applesauce-loaders"; import { createRxNostr } from "rx-nostr";

// Create a new rx-nostr instance const rxNostr = createRxNostr();

// Create a new replaceable loader const replaceableLoader = new ReplaceableLoader(rxNostr); ```

After:

```typescript

import { Observable } from "rxjs"; import { ReplaceableLoader, NostrRequest } from "applesauce-loaders"; import { SimplePool } from "nostr-tools";

// Create a new nostr-tools pool const pool = new SimplePool();

// Create a method that subscribes using nostr-tools and returns an observable function nostrRequest: NostrRequest = (relays, filters, id) => { return new Observable((subscriber) => { const sub = pool.subscribe(relays, filters, { onevent: (event) => { subscriber.next(event); }, onclose: () => subscriber.complete(), oneose: () => subscriber.complete(), });

return () => sub.close();

}); };

// Create a new replaceable loader const replaceableLoader = new ReplaceableLoader(nostrRequest); ```

Of course you can still use rx-nostr if you want:

```typescript import { createRxNostr } from "rx-nostr";

// Create a new rx-nostr instance const rxNostr = createRxNostr();

// Create a method that subscribes using rx-nostr and returns an observable function nostrRequest( relays: string[], filters: Filter[], id?: string, ): Observable { // Create a new oneshot request so it will complete when EOSE is received const req = createRxOneshotReq({ filters, rxReqId: id }); return rxNostr .use(req, { on: { relays } }) .pipe(map((packet) => packet.event)); }

// Create a new replaceable loader const replaceableLoader = new ReplaceableLoader(nostrRequest); ```

There where a few more changes, check out the changelog

Applesauce wallet

Its far from complete, but there is a new applesauce-wallet package that provides a actions and queries for working with NIP-60 wallets.

Documentation: applesauce-wallet

Example Usage:

```typescript import { CreateWallet, UnlockWallet } from "applesauce-wallet/actions";

// Create a new NIP-60 wallet await hub.run(CreateWallet, ["wss://mint.example.com"], privateKey);

// Unlock wallet and associated tokens/history await hub.run(UnlockWallet, { tokens: true, history: true }); ```

@ 3bf0c63f:aefa459d

There's a problem with using Git concepts for everything

We've been seeing a surge in applications that use Git to store other things than code, or that are based on Git concepts and so enable "forking, merging and distributed collaboration" for things like blogs, recipes, literature, music composition, normal files in a filesystem, databases.

The problem with all this is they will either:

1. assume the user will commit manually and expect that commit to be composed by a set of meaningful changes, and the commiter will also add a message to the commit, describing that set of meaningful, related changes; or
2. try to make the committing process automatic and hide it from the user, so will producing meaningless commits, based on random changes in many different files (it's not "files" if we are talking about a recipe or rows in a table, but let's say "files" for the sake of clarity) that will probably not be related and not reduceable to a meaningful commit message, or maybe the commit will contain only the changes to a single file, and its commit message would be equivalent to "updated <name of the file>".

Programmers, when using Git, think in Git, i.e., they work with version control in their minds. They try hard to commit together only sets of meaningful and related changes, even when they happen to make unrelated changes in the meantime, and that's why there are commands like git add -p and many others.

Normal people, to whom many of these git-based tools are intended to (and even programmers when out of their code-world), are much less prone to think in Git, and that's why another kind of abstraction for fork-merge-collaborate in non-code environments must be used.

@ e7454994:7bb2dac7

Imagine

According to Cazoomi, total revenue for nonprofits in the U.S. reached approximately $3.7 trillion in 2024.

I know in some cases a billion is a hundred million instead of a thousand million (presumably so that some millionaires can call themselves billionaires to distinguish themselves from the riffraff). But that’s not the case here. A trillion is one followed by 12 zeros, so in 2024, US non-profits’ expenses were

3,700,000,000,000 dollars.

How much is a trillion?

And that’s just the USA. We could safely double it for worldwide non-profits and still be well below the actual figure. To be conservative, let’s say 6 trillion of our dollars each year goes on the kinds of projects that non-profits are allowed to do (essentially, making the world a better place).

Think what you could do with just one million dollars. Now think of that times six million! The entire population of Congo, each man, woman, and child, could become a millionaire!. It’s not really imaginable.

That’s how much nonprofits have. What the hell have they done with all that money? In most places where poverty and malnutrition are rife, two thousand dollars a year per family would be more than enough to enable people to sort out whatever problems they have and convert their local community to abundance over three years. Six trillion divided by two thousand is three billion.

The people whom we allow to manage ‘aid’ for us are (to be polite) inept, and we need to bypass them urgently. Directsponsor.org and clickforcharity.net are part of a proof of concept, and our aim is to prove that a better way is possible by doing it.

When a hierarchy exists, it presents a focus of power that power-seeking individuals and cliques can over time turn to their advantage… Even volunteer organizations are subject to intrigues, power grabs, covert arrangements, misallocation of funds, etc. The problem is made worse by the fact that those who most desire power and who are the most ruthless are the very ones who tend to work their way to the top of hierarchies.

Richard Moore

More Fun With Figures

Oxfam UK raised £368,000,000 in 2013-14. That’s around 450,000,000 euros. What could we do with that kind of money? A direct sponsorship project is, for a family, 120 per month = 1440 per year. 1440 / 450,000,000 = 312,500 families.

312,500 families, x 4 = 1,250,000 people, would move from poverty into abundance every 3 years with the money that goes through Oxfam. Does Oxfam achieve anything like this with our money?

Oxfam UK is just one of many, many such charities and is small fry when you look at things like USAID, which ran through 27 billion dollars in the year to 2025. What could we do with that?

Its well over 15 million families. Over 60 million people! Or, the entire population of Botswana, Namibia, Mauritania, Liberia, the Republic of Congo, the Central African Republic, Libya, Sierra Leone, Eritrea, Togo, and Guinea combined. This is only to make a point, not to suggest that we would ever achieve such numbers. It shows how wasteful and scandalous our present “aid” efforts really are.

NGOs and governments waste our money.

Solution

Until recently, it was impossible to send money directly to another human without going through the banking system. The big charity organisations were a necessary part of the process, and they made the most of their position. Think about it: you have a family to feed, rent or a mortgage that has to be paid, or you’ll be homeless and destitute. What would your priority be? Apart from the top level, these are generally good people with the best intentions.

But now we have Bitcoin. People can send money all over the world at extremely low cost. The recipients aren’t stupid; they know what they need better than any NGO “expert,” and any expertise or teaching they need, they can get if they have the money to pay for it. This way, the power relationship is reversed in favor of our recipients.

All we need is a system (open and distributed) that ensures sponsors’ funds are not being squandered and the projects being supported are not scams. 

A few people decided to start such a project. We have a system almost fully built and currently being tested out. It will enable people to get together into small groups of sponsors to fund small, local projects by directly funding the individuals working on the project. Anything from a regular monthly commitment to a click-for-charity system where you don’t even need any money to occasional one-off purchases of items for a project will be possible.

Here’s our pilot project in Badilisha, on Lake Victoria.

If you like doing stuff on social media, please sign up on our beta site (no money needed) and say hi; we need a few people to get it started. clickforcharity.net.

@ 3bf0c63f:aefa459d

busca múltipla na estante virtual

A single-page app made in Elm with a Go backend that scrapped estantevirtual.com.br in real-time for search results of multiple different search terms and aggregated the results per book store, so when you want to buy many books you can find the stores that have the biggest part of what you want and buy everything together, paying less for the delivery fee.

It had a very weird unicode issue I never managed to solve, something with the encoding estantevirtual.com.br used.

I also planned to build the entire checkout flow directly in this UI, but then decided it wasn't worth it. The search flow only was already good enough.

• https://estantevirtual.alhur.es/
• https://github.com/fiatjaf/estantevirtual

@ 005bc4de:ef11e1a2

Trump Bitcoin Report Card - Day 100

For whatever reason day 100 of a president's term has been deemed a milestone. So, it's time to check in with President Trump's bitcoin pledges and issue a report card.

Repo and prior reports: - GitHub: https://github.com/crrdlx/trump-bitcoin-report-card - First post: https://stacker.news/items/757211 - Progress Report 1: https://stacker.news/items/774165 - Day 1 Report Card: https://stacker.news/items/859475 - Day 100 Report Card: https://stacker.news/items/966434

Report Card | | Pledge | Prior Grade | Current Grade | |--|--|--|--| | 1 | Fire SEC Chair Gary Gensler on day 1 | A | A | | 2 | Commute the sentence of Ross Ulbricht on day 1 | A | A | | 3 | Remove capital gains taxes on bitcoin transactions | F | F | | 4 | Create and hodl a strategic bitcoin stockpile | D | C- | | 5 | Prevent a CBDC during his presidency | B+ | A | | 6 | Create a "bitcoin and crypto" advisory council | C- | C | | 7 | Support the right to self-custody | D+ | B- | | 8 | End the "war on crypto" | D+ | B+ | | 9 | Mine all remaining bitcoin in the USA | C- | C | | 10 | Make the US the "crypto capital of the planet" | C- | C+ |

Comments

Pledge 1 - SEC chair - (no change from earlier) - Gensler is out. This happened after the election and Trump took office. With the writing on the wall, Gensler announced he would resign, Trump picked a new SEC head in Paul Atkins, and Gensler left office just before Trump was sworn in. The only reason an A+ was not awarded was that Trump wasn't given the chance to actually fire Gensler, because he quit. No doubt, though, his quitting was due to Trump and the threat of being sacked.

Day 100 Report Card Grade: A

Pledge 2 - free Ross - (no change from earlier) - Ross Ulbricht's sentence was just commuted. Going will "option 3" above, the pledge was kept. An A+ would have been a commutation yesterday or by noon today, but, let's not split hairs. It's done.

Day 100 Report Card Grade: A

Pledge 3 - capital gains - This requires either executive action and/or legislation. There was no action. Executive action can be done with the stroke of a pen, but it was not. Legislation is tricky and time-consuming, however, there wasn't even mention of this matter. This seems to be on the back burner since statements such as this report in November. See Progress Report 1: https://stacker.news/items/774165 for more context.

Trump's main tax thrust has been the tariff, actually a tax increase, instead of a cut. Currently, the emphasis is on extending the "Trump tax cuts" and recently House Speaker Mike Johnson indicated such a bill would be ready by Memorial Day. Earlier in his term, there was more chatter about tax relief for bitcoin or cryptocurrency. There seems to be less chatter on this, or none at all, such as its absence in the "ready by Memorial Day" article.

Until tax reform is codified and signed, it isn't tax law and the old code still applies.

Day 100 Report Card Grade: F

Pledge 4 - bitcoin reserve - The initial grade was a C, it was dropped to a D mainly due to Trump's propensity to [alt]coinery, and now it's back to a C-.

Getting the grade back up into C-level at a C- was a little bumpy. On March 2, 2025, Trump posted that a U.S. Crypto Reserve would be created. This is what had been hoped for, except that the pledge was for a Bitcoin Reserve, not crypto. And secondly, he specifically named XRP, SOL, and ADA (but not BTC). Just a couple of hours later, likely in clean up mode, he did add BTC (along with ETH) as "obviously" being included. So, the "Bitcoin Reserve" became a "Crypto Reserve."

Maybe still in "cleanup mode," Sec. of Commerce Howard Lutnick said bitcoin will hold "special status" in the reserve. Then, on March 6, an executive order made the U.S. Digital Asset Stockpile official. Again, "Bitcoin" was generalized until section 3 where the "Strategic Bitcoin Reserve" did come to official fruition.

The grade is only a C- because the only thing that happened was the naming of the stockpile. Indeed, it became official. But the "stockpile" was just BTC already held by the U.S. government. I think it's fair to say most bitcoiners would have preferred a statement about buying BTC. Other Trump bitcoin officials indicated acquiring "as much as we can get", which sounds great, but until it happens, is only words.

Day 100 Report Card Grade: C-

Pledge 5 - no CBDC - An executive order on January 23, 2025 forbade a CBDC in section 1, part v by "prohibiting the establishment, issuance, circulation, and use of a CBDC."

Day 100 Report Card Grade: A

Pledge 6 - advisory council - The Trump bitcoin or crypto team consists of the following: David Sacks as “crypto czar” and Bo Hines as executive director of the Presidential Council of Advisers for Digital Assets.

A White House Crypto Summit (see video) was held on March 7, 2025. In principle, the meeting was good, however, the summit seemed (a) to be very heavily "crypto" oriented, and (b) to largely be a meet-and-greet show.

Still, just the fact that such a show took place, inside the White House, reveals how far things have come and the change in climate. For the grade to go higher, more tangible things should take place over time.

Day 100 Report Card Grade: C

Pledge 7 - self-custody - There's been a bit of good news though on this front. First, the executive order above from January 23 stated in section 1, i, one of the goals was "...to maintain self-custody of digital assets." Also, the Phoenix wallet returned to the U.S. In 2024, both Phoenix and Wallet of Satoshi pulled out of the U.S. for fear of government crackdowns. The return of Phoenix, again, speaks to the difference in climate now and is a win for self-custody.

To rise above B-level, more assurance, it would be good to see further clear assurance that people can self-custody, that developers can build self-custody, and businesses can create products to self-custody. Also, Congressional action could get to an A.

Day 100 Report Card Grade: B-

Pledge 8 - end war on crypto - There has been improvement here. First, tangibly, SAB 121 was sent packing as SEC Commissioner Hester Peirce announced. Essentially, this removed a large regulatory burden. Commissioner Peirce also said ending the burdens will be a process to get out of the "mess". So, there's work to do. Also, hurdles were recently removed so that banks can now engage in bitcoin activity. This is both a symbolic and real change.

Somewhat ironically, Trump's own venture into cryptocurrency with his World Liberty Financial and the $TRUMP and $MELANIA tokens, roundly poo-pood by bitcoiners, might actually be beneficial in a way. The signal from the White House seems to be on all things cryptocurrency, "Do it."

The improvement and climate now seems very different than with the previous administration and leaders who openly touted a war on crypto.

Day 100 Report Card Grade: B+

Pledge 9 - USA mining - As noted earlier, this is an impossible pledge. That said, things can be done to make America mining friendly. The U.S. holds an estimated 37 to 40% of Bitcoin hash rate, which is substantial. Plus, Trump, or the Trump family at least, has entered into bitcoin mining. With Hut 8, Eric Trump is heading "American Bitcoin" to mine BTC. Like the $TRUMP token, this conveys that bitcoin mining is a go in the USA.

Day 100 Report Card Grade: C

Pledge 10 - USA crypto capital - This pledge closely aligned with pledges 8 and 9. If the war on crypto ends, the USA becomes more and more crypto and bitcoin friendly. And, if the hashrate stays high and even increases, that puts the USA at the center of it all. Most of the categories above have seen improvements, all of which help this last pledge. Trump's executive orders help this grade as well as they move from only words spoken to becoming official policy.

To get higher, the Bitcoin Strategic Reserve should move from a name-change only to acquiring more BTC. If the USA wants to be the world's crypto capital, being the leader in bitcoin ownership is the way to do it.

Day 100 Report Card Grade: C+

Sources

1. Nashville speech - https://www.youtube.com/watch?v=EiEIfBatnH8
2. CryptoPotato "top 8 promises" - https://x.com/Crypto_Potato/status/1854105511349584226
3. CNBC - https://www.cnbc.com/2024/11/06/trump-claims-presidential-win-here-is-what-he-promised-the-crypto-industry-ahead-of-the-election.html
4. BLOCKHEAD - https://www.blockhead.co/2024/11/07/heres-everything-trump-promised-to-the-crypto-industry/
5. CoinTelegraph - https://cointelegraph.com/news/trump-promises-crypto-election-usa
6. China vid - Bitcoin ATH and US Strategic Bitcoin Stockpile - https://njump.me/nevent1qqsgmmuqumhfktugtnx9kcsh3ap6v7ca4z8rgx79palz2qk0wzz5cksppemhxue69uhkummn9ekx7mp0qgszwaxc8j8e0zw9sdq59y43rykyx3wm0lcd2502xth699v0gxf0degrqsqqqqqpglusv6
7. Capitals gains tax - https://bravenewcoin.com/insights/trump-proposes-crypto-tax-cuts-targets-u-s-made-tokens-for-tax-exemption Progress report 1 ------------------------------------------------------------------------------------
8. Meeting with Brian Armstrong - https://www.wsj.com/livecoverage/stock-market-today-dow-sp500-nasdaq-live-11-18-2024/card/exclusive-trump-to-meet-privately-with-coinbase-ceo-brian-armstrong-DDkgF0xW1BW242rVeuqx
9. Michael Saylor podcast - https://fountain.fm/episode/DHEzGE0f99QQqyM36nVr
10. Gensler resigns - https://coinpedia.org/news/big-breaking-sec-chair-gary-gensler-officially-resigns/ Progress report 2 ------------------------------------------------------------------------------------
11. Trump & Justin Sun - https://www.coindesk.com/business/2024/11/26/justin-sun-joins-donald-trumps-world-liberty-financial-as-adviser $30M investment: https://www.yahoo.com/news/trump-crypto-project-bust-until-154313241.html
12. SEC chair - https://www.cnbc.com/2024/12/04/trump-plans-to-nominate-paul-atkins-as-sec-chair.html
13. Crypto czar - https://www.zerohedge.com/crypto/trump-names-david-sacks-white-house-ai-crypto-czar
14. Investigate Choke Point 2.0 - https://www.cryptopolitan.com/crypto-czar-investigate-choke-point/
15. Crypto council head Bo Hines - https://cointelegraph.com/news/trump-appoints-bo-hines-head-crypto-council
16. National hash rate: https://www.cryptopolitan.com/the-us-controls-40-of-bitcoins-hashrate/
17. Senate committee https://coinjournal.net/news/rep-senator-cynthia-lummis-selected-to-chair-crypto-subcommittee/
18. Treasurh Sec. CBDC: https://decrypt.co/301444/trumps-treasury-pick-scott-bessant-pours-cold-water-on-us-digital-dollar-initiative
19. National priority: https://cointelegraph.com/news/trump-executive-order-crypto-national-priority-bloomberg?utm_source=rss_feed&utm_medium=rss&utm_campaign=rss_partner_inbound
20. $TRUMP https://njump.me/nevent1qqsffe0d7mgtu5jhasy4hmkcdy7wfrlcqwc4vf676hulvdn8uaqa3acpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyztpa8q038vw5xluyhnydj5u39d7cpssvuswjhhjqj8q42jh4ul3wqcyqqqqqqgmha026
21. World Liberty buys alts: https://www.theblock.co/post/335779/trumps-world-liberty-buys-25-million-of-tokens-including-link-tron-aave-and-ethena?utm_source=rss&utm_medium=rss
22. CFTC chair: https://cryptoslate.com/trump-appoints-crypto-advocate-caroline-pham-as-cftc-acting-chair/
23. WLF buys wrapped BTC https://www.cryptopolitan.com/trump-buys-47-million-in-bitcoin/
24. SEC turnover https://www.theblock.co/post/335944/trump-names-sec-commissioner-mark-uyeda-as-acting-chair-amid-a-crypto-regulatory-shift?utm_source=rss&utm_medium=rss
25. ----------------------------100 Days Report---------------------------------Davos speech "world capital of AI and crypto" https://coinpedia.org/news/big-breaking-president-trump-says-u-s-to-become-ai-and-crypto-superpower/
26. SAB 121 gone, Hester P heads talk force & ends sab 121?, war on crypto https://x.com/HesterPeirce/status/1882562977985114185 article: https://www.theblock.co/post/336761/days-after-gensler-leaves-sec-rescinds-controversial-crypto-accounting-guidance-sab-121?utm_source=twitter&utm_medium=social CoinTelegraph: https://cointelegraph.com/news/trump-executive-order-cbdc-ban-game-changer-us-institutional-crypto-adoption?utm_source=rss_feed&utm_medium=rss&utm_campaign=rss_partner_inbound
27. Possible tax relief https://cryptodnes.bg/en/will-trumps-crypto-policies-lead-to-tax-relief-for-crypto-investors/
28. War on crypto https://decrypt.co/304395/trump-sec-crypto-task-force-priorities-mess
29. Trump "truths" 2/18 make usa #1 in crypto, "Trump effect" https://www.theblock.co/post/333137/ripple-ceo-says-75-of-open-roles-are-now-us-based-due-to-trump-effect and https://www.coindesk.com/markets/2025/01/06/ripples-garlinghouse-touts-trump-effect-amid-bump-in-u-s-deals
30. Strategic reserve https://njump.me/nevent1qqsf89l74mqfkk74jqhjcqtwp5m970gedmtykn5uhl0vz9mhmrvvvgqpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyztpa8q038vw5xluyhnydj5u39d7cpssvuswjhhjqj8q42jh4ul3wqcyqqqqqqge7c74u and https://njump.me/nevent1qqswv50m7mc95m3saqce08jzpqc0vedw4avdk6zxy9axrn3hqet52xgpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyztpa8q038vw5xluyhnydj5u39d7cpssvuswjhhjqj8q42jh4ul3wqcyqqqqqqgpc7cp3
31. Strategic reserve, bitcoin special https://www.thestreet.com/crypto/policy/bitcoin-to-hold-special-status-in-u-s-crypto-strategic-reserve
32. Bitcoin reserve, crypto stockpile https://decrypt.co/309032/president-trump-signs-executive-order-to-establish-bitcoin-reserve-crypto-stockpile vid link https://njump.me/nevent1qqs09h58patpv9vfjpcss6v5nxv7m23u8g6g43nqvkjzgzescztucmspr9mhxue69uhhyetvv9ujumt0d4hhxarj9ecxjmnt9upzqtjzyy2ylrsceh5uj20j5e95v0e99s3epsvyctu2y0vrwyltvq33qvzqqqqqqyus4pu7
33. Truth summit https://njump.me/nevent1qqswj6sv0wr4d4ppwzam5egr5k6nmqgjpwmsrlx2a7d4ndpfj0fxvcqpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyztpa8q038vw5xluyhnydj5u39d7cpssvuswjhhjqj8q42jh4ul3wqcyqqqqqqgu0mzzh and vid https://njump.me/nevent1qqsptn8c8wyuhlqtjr5u767x20q4dmjvxy28cdj30t4v9phhf6y5a5spzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyztpa8q038vw5xluyhnydj5u39d7cpssvuswjhhjqj8q42jh4ul3wqcyqqqqqqgqklklu
34. SEC chair confirmed https://beincrypto.com/sec-chair-paul-atkins-confirmed-senate-vote/
35. pro bitcoin USA https://coinpedia.org/news/u-s-secretary-of-commerce-howard-lutnick-says-america-is-ready-for-bitcoin/
36. tax cuts https://thehill.com/homenews/house/5272043-johnson-house-trump-agenda-memorial-day/
37. "as much as we can get" https://cryptobriefing.com/trump-bitcoin-acquisition-strategy/
38. ban on CBDC https://www.whitehouse.gov/presidential-actions/2025/01/strengthening-american-leadership-in-digital-financial-technology/
39. Phoenix WoS leave https://www.coindesk.com/opinion/2024/04/29/wasabi-wallet-and-phoenix-leave-the-us-whats-next-for-non-custodial-crypto
40. Trump hut 8 mining https://www.reuters.com/technology/hut-8-eric-trump-launch-bitcoin-mining-company-2025-03-31/

@ d1667293:388e7004

The "Bitcoindollar" system—an emerging term which describes the interplay of U.S. dollar-denominated stablecoins and Bitcoin as complementary forces in the evolving monetary framework of the digital era (and which replaces the defunct Petrodollar system)—has sparked an interesting debate on Nostr with PowMaxi.

You will find the thread links at the bottom of this article.

Powmaxi argues that attempting to merge hard money (Bitcoin) with soft money (the U.S. dollar) is structurally doomed, because the systems are inherently contradictory and cannot coexist without one eventually destroying the other.

This critique is certainly valid, but ONLY if the Bitcoindollar is viewed as a final system. But I never claim that. To the contrary, the conclusion in my book is that this is a system that buys time for fiat, absorbs global demand for monetary stability, and ushers in a Bitcoinized world without the immediate collapse and the reset of the fiat system which would otherwise cause dramatic consequences. The Bitcoindollar is the only way to a gradual Bitcoin dominance in 10-20 years time while avoiding sudden collapse of the fiat system, so that also the power elites who hold the keys to this system can adapt.\ At least this is my hope.

Therefore the "fusion" isn't the future. The siphoning is. And the U.S. may try to ride it as long as possible. The Bitcoindollar system is a transitional strategic framework, not a\ permanent monetary equilibrium. In the end I agree with PowMaxi.

His detailed critique deserves an equally detailed analysis. Here's how the objections break down and why they don’t necessarily undermine the Bitcoindollar system.

1. Hard Money vs. Soft Money: Opposed Systems?

Objection: Bitcoin is a closed, decentralized system with a fixed supply; the dollar is an open, elastic system governed by central banks and political power. These traits are mutually exclusive and incompatible.

Response: Ideologically, yes. Practically, no. Hybrid financial systems are not uncommon. Bitcoin and stablecoins serve different user needs: Bitcoin is a store of value; stablecoins are mediums of exchange. Their coexistence mirrors real-world economic needs. The contradiction can be managed, and is not fatal at least for the transitional phase.

2. Scarcity vs. Elasticity: Economic Incompatibility?

Objection: Bitcoin can’t inject liquidity in crises; fiat systems can. Anchoring fiat to Bitcoin removes policymakers' tools.

Response: Correct — but that’s why Bitcoin is held as a reserve, not used as the primary medium of exchange in the Bitcoindollar model. Fiat-based liquidity mechanisms still function via stablecoins, while Bitcoin acts as a counterweight to long-term monetary debasement. The system’s strength is in its optionality: you don’t have to use Bitcoin until you want an exit ramp from fiat.

3. No Stable Equilibrium: One Must Win?

Objection: The system will destabilize. Either Bitcoin undermines fiat or fiat suppresses Bitcoin.

Response: Not necessarily in this transitional phase. The “conflict” isn’t between tools — it’s between control philosophies. The dollar won’t disappear overnight, and Bitcoin isn’t going away. The likely outcome is a gradual shifting of savings and settlement layers to Bitcoin, while fiat continues to dominate day-to-day payments and credit markets — until Bitcoin becomes structurally better in both.

4. Gresham’s and Thiers’ Law: Hollowing Fiat?

Objection: People save in Bitcoin and spend fiat, eroding fiat value.

Response: Yes — and that’s been happening since 2009. But this isn’t a flaw; it’s a transition mechanism. The Bitcoindollar model recognizes this and creates a bridge: it monetizes U.S. debt while preserving access to hard money. In the long run, my expectation is that naturally bitcoin will prevail both as a SOV and currency, but until then, stablecoins and T-bill-backed tokens serve useful roles in the global economy.

5. Philosophical Incompatibility?

Objection: Bitcoin prioritizes individual sovereignty; fiat systems are hierarchical. They can't be reconciled.

Response: They don’t need to be reconciled ideologically to function in parallel. Users choose the tool that suits their needs. One empowers individual autonomy; the other offers state-backed convenience. This is a competition of values, not a mechanical incompatibility. The Bitcoindollar model is a strategy. It’s a bridge between old and new systems, not a permanent coexistence.

6. Fusion is Impossible?

Objection: It’s only a temporary bridge. One side must lose.

Response: Exactly. The Bitcoindollar system is a transitional bridge. But that doesn’t reduce its value. It provides a functional pathway for individuals, companies, and governments to gradually exit broken monetary systems and experiment with new models.

In the meantime, the U.S. benefits from stablecoin-driven Treasury demand, while Bitcoin continues to grow as a global reserve asset.

Bottom line: A Strategic Convergence, Not a Permanent Fusion

The Bitcoindollar system isn’t a contradiction. It’s a convergence zone. It reflects the reality that monetary systems evolve gradually, not cleanly. Bitcoin and fiat will compete, overlap, and influence each other. Eventually, yes — hard money wins. But until then, hybrid systems offer powerful stepping stones.

Thread links:

Thread started from this initial post.

Thread Powmaxi

PowMaxi profile

@ 3bf0c63f:aefa459d

Token-Curated Registries

So you want to build a TCR?

TCRs (Token Curated Registries) are a construct for maintaining registries on Ethereum. Imagine you have lots of scissor brands and you want a list with only the good scissors. You want to make sure only the good scissors make into that list and not the bad scissors. For that, people will tell you, you can just create a TCR of the best scissors!

It works like this: some people have the token, let's call it Scissor Token. Some other person, let's say it's a scissor manufacturer, wants to put his scissor on the list, this guy must acquire some Scissor Tokens and "stake" it. Holders of the Scissor Tokens are allowed to vote on "yes" or "no". If "no", the manufactures loses his tokens to the holders, if "yes" then its tokens are kept in deposit, but his scissor brand gets accepted into the registry.

Such a simple process, they say, have strong incentives for being the best possible way of curating a registry of scissors: consumers have the incentive to consult the list because of its high quality; manufacturers have the incentive to buy tokens and apply to join the list because the list is so well-curated and consumers always consult it; token holders want the registry to accept good and reject bad scissors because that good decisions will make the list good for consumers and thus their tokens more valuable, bad decisions will do the contrary. It doesn't make sense, to reject everybody just to grab their tokens, because that would create an incentive against people trying to enter the list.

Amazing! How come such a simple system of voting has such enourmous features? Now we can have lists of everything so well-curated, and for that we just need Ethereum tokens!

Now let's imagine a different proposal, of my own creation: SPCR, Single-person curated registries.

Single-person Curated Registries are equal to TCR, except they don't use Ethereum tokens, it's just a list in a text file kept by a single person. People can apply to join, and they will have to give the single person some amount of money, the single person can reject or accept the proposal and so on.

Now let's look at the incentives of SPCR: people will want to consult the registry because it is so well curated; vendors will want to enter the registry because people are consulting it; the single person will want to accept the good and reject the bad applicants because these good decisions are what will make the list valuable.

Amazing! How such a single proposal has such enourmous features! SPCR are going to take over the internet!

What TCR enthusiasts get wrong?

TCR people think they can just list a set of incentives for something to work and assume that something will work. Mix that with Ethereum hype and they think theyve found something unique and revolutionary, while in fact they're just making a poor implementation of "democracy" systems that fail almost everywhere.

The life is not about listing a set of "incentives" and then considering the problems solved. Almost everybody on the Earth has the incentive for being rich: being rich has a lot of advantages over being poor, however not all people get rich! Why are the incentives failing?

Curating lists is a hard problem, it involves a lot of knowledge about the problem that just holding a token won't give you, it involves personal preferences, politics, it involves knowing where is the real limit between "good" and "bad". The Single Person list may have a good result if the single person doing the curation is knowledgeable and honest (yes, you can game the system to accept your uncle's scissors and not their competitor that is much better, for example, without losing the entire list reputation), same thing for TCRs, but it can also fail miserably, and it can appear to be good but be in fact not so good. In all cases, the list entries will reflect the preferences of people choosing and other things that aren't taken into the incentives equation of TCR enthusiasts.

We don't need lists

The most important point to be made, although unrelated to the incentive story, is that we don't need lists. Imagine you're looking for a scissor. You don't want someone to tell if scissor A or B are "good" or "bad", or if A is "better" than B. You want to know if, for your specific situation, or for a class of situations, A will serve well, and do that considering A's price and if A is being sold near you and all that.

Scissors are the worst example ever to make this point, but I hope you get it. If you don't, try imagining the same example with schools, doctors, plumbers, food, whatever.

Recommendation systems are badly needed in our world, and TCRs don't solve these at all.

@ 7d33ba57:1b82db35

Located in eastern Poland, Lublin is a city where history, culture, and youthful energy come together. Often called the "Gateway to the East," Lublin blends Gothic and Renaissance architecture, vibrant street life, and deep historical roots—especially as a center of Jewish heritage and intellectual life.

🏙️ Top Things to See in Lublin

🏰 Lublin Castle

• A striking hilltop castle with a neo-Gothic façade and a beautifully preserved Romanesque chapel (Chapel of the Holy Trinity)
• Don’t miss the frescoes inside—a rare mix of Byzantine and Western art styles

🚪 Old Town (Stare Miasto)

• Wander through cobblestone streets, pastel buildings, and arched gateways
• Filled with cozy cafes, galleries, and vibrant murals
• The Grodzka Gate symbolizes the passage between Christian and Jewish quarters

🕯️ Lublin’s Jewish Heritage

• Visit the Grodzka Gate – NN Theatre, a powerful memorial and museum telling the story of the once-vibrant Jewish community
• Nearby Majdanek Concentration Camp offers a sobering but important historical experience

🎭 Culture & Events

• Lublin is known for its festivals, like Carnaval Sztukmistrzów (Festival of Magicians and Street Performers) and the Night of Culture
• The city has a thriving theatre and music scene, supported by its large student population

🌳 Green Spaces

• Relax in Saski Garden, a peaceful park with walking paths and fountains
• Or take a walk along the Bystrzyca River for a quieter, more local feel

🍽️ Local Tastes

• Sample Polish classics like pierogi, żurek (sour rye soup), and bigos (hunter’s stew)
• Look for modern twists on traditional dishes in Lublin’s growing number of bistros and artisan cafés

🚆 Getting There

• Easy access by train or bus from Warsaw (2–2.5 hours)
• Compact center—easily walkable

@ 3bf0c63f:aefa459d

idea: "numbeo" with satoshis

This site has a crowdsourced database of cost-of-living in many countries and cities: https://www.numbeo.com/cost-of-living/ and it sells the data people write there freely. It's wrong!

Could be an fruitful idea to pay satoshis for people to provide data.

@ 3bf0c63f:aefa459d

Lightning and its fake HTLCs

Lightning is terrible but can be very good with two tweaks.

How Lightning would work without HTLCs

In a world in which HTLCs didn't exist, Lightning channels would consist only of balances. Each commitment transaction would have two outputs: one for peer A, the other for peer B, according to the current state of the channel.

When a payment was being attempted to go through the channel, peers would just trust each other to update the state when necessary. For example:

1. Channel AB's balances are A[10:10]B (in sats);
2. A sends a 3sat payment through B to C;
3. A asks B to route the payment. Channel AB doesn't change at all;
4. B sends the payment to C, C accepts it;
5. Channel BC changes from B[20:5]C to B[17:8]C;
6. B notifies A the payment was successful, A acknowledges that;
7. Channel AB changes from A[10:10]B to A[7:13]B.

This in the case of a success, everything is fine, no glitches, no dishonesty.

But notice that A could have refused to acknowledge that the payment went through, either because of a bug, or because it went offline forever, or because it is malicious. Then the channel AB would stay as A[10:10]B and B would have lost 3 satoshis.

How Lightning would work with HTLCs

HTLCs are introduced to remedy that situation. Now instead of commitment transactions having always only two outputs, one to each peer, now they can have HTLC outputs too. These HTLC outputs could go to either side dependending on the circumstance.

Specifically, the peer that is sending the payment can redeem the HTLC after a number of blocks have passed. The peer that is receiving the payment can redeem the HTLC if they are able to provide the preimage to the hash specified in the HTLC.

Now the flow is something like this:

1. Channel AB's balances are A[10:10]B;
2. A sends a 3sat payment through B to C:
3. A asks B to route the payment. Their channel changes to A[7:3:10]B (the middle number is the HTLC).
4. B offers a payment to C. Their channel changes from B[20:5]C to B[17:3:5]C.
5. C tells B the preimage for that HTLC. Their channel changes from B[17:3:5]C to B[17:8]C.
6. B tells A the preimage for that HTLC. Their channel changes from A[7:3:10]B to A[7:13]B.

Now if A wants to trick B and stop responding B doesn't lose money, because B knows the preimage, B just needs to publish the commitment transaction A[7:3:10]B, which gives him 10sat and then redeem the HTLC using the preimage he got from C, which gives him 3 sats more. B is fine now.

In the same way, if B stops responding for any reason, A won't lose the money it put in that HTLC, it can publish the commitment transaction, get 7 back, then redeem the HTLC after the certain number of blocks have passed and get the other 3 sats back.

How Lightning doesn't really work

The example above about how the HTLCs work is very elegant but has a fatal flaw on it: transaction fees. Each new HTLC added increases the size of the commitment transaction and it requires yet another transaction to be redeemed. If we consider fees of 10000 satoshis that means any HTLC below that is as if it didn't existed because we can't ever redeem it anyway. In fact the Lightning protocol explicitly dictates that if HTLC output amounts are below the fee necessary to redeem them they shouldn't be created.

What happens in these cases then? Nothing, the amounts that should be in HTLCs are moved to the commitment transaction miner fee instead.

So considering a transaction fee of 10000sat for these HTLCs if one is sending Lightning payments below 10000sat that means they operate according to the unsafe protocol described in the first section above.

It is actually worse, because consider what happens in the case a channel in the middle of a route has a glitch or one of the peers is unresponsive. The other node, thinking they are operating in the trustless protocol, will proceed to publish the commitment transaction, i.e. close the channel, so they can redeem the HTLC -- only then they find out they are actually in the unsafe protocol realm and there is no HTLC to be redeemed at all and they lose not only the money, but also the channel (which costed a lot of money to open and close, in overall transaction fees).

One of the biggest features of the trustless protocol are the payment proofs. Every payment is identified by a hash and whenever the payee releases the preimage relative to that hash that means the payment was complete. The incentives are in place so all nodes in the path pass the preimage back until it reaches the payer, which can then use it as the proof he has sent the payment and the payee has received it. This feature is also lost in the unsafe protocol: if a glitch happens or someone goes offline on the preimage's way back then there is no way the preimage will reach the payer because no HTLCs are published and redeemed on the chain. The payee may have received the money but the payer will not know -- but the payee will lose the money sent anyway.

The end of HTLCs

So considering the points above you may be sad because in some cases Lightning doesn't use these magic HTLCs that give meaning to it all. But the fact is that no matter what anyone thinks, HTLCs are destined to be used less and less as time passes.

The fact that over time Bitcoin transaction fees tend to rise, and also the fact that multipart payment (MPP) are increasedly being used on Lightning for good, we can expect that soon no HTLC will ever be big enough to be actually worth redeeming and we will be at a point in which not a single HTLC is real and they're all fake.

Another thing to note is that the current unsafe protocol kicks out whenever the HTLC amount is below the Bitcoin transaction fee would be to redeem it, but this is not a reasonable algorithm. It is not reasonable to lose a channel and then pay 10000sat in fees to redeem a 10001sat HTLC. At which point does it become reasonable to do it? Probably in an amount many times above that, so it would be reasonable to even increase the threshold above which real HTLCs are made -- thus making their existence more and more rare.

These are good things, because we don't actually need HTLCs to make a functional Lightning Network.

We must embrace the unsafe protocol and make it better

So the unsafe protocol is not necessarily very bad, but the way it is being done now is, because it suffers from two big problems:

1. Channels are lost all the time for no reason;
2. No guarantees of the proof-of-payment ever reaching the payer exist.

The first problem we fix by just stopping the current practice of closing channels when there are no real HTLCs in them.

That, however, creates a new problem -- or actually it exarcebates the second: now that we're not closing channels, what do we do with the expired payments in them? These payments should have either been canceled or fulfilled before some block x, now we're in block x+1, our peer has returned from its offline period and one of us will have to lose the money from that payment.

That's fine because it's only 3sat and it's better to just lose 3sat than to lose both the 3sat and the channel anyway, so either one would be happy to eat the loss. Maybe we'll even split it 50/50! No, that doesn't work, because it creates an attack vector with peers becoming unresponsive on purpose on one side of the route and actually failing/fulfilling the payment on the other side and making a profit with that.

So we actually need to know who is to blame on these payments, even if we are not going to act on that imediatelly: we need some kind of arbiter that both peers can trust, such that if one peer is trying to send the preimage or the cancellation to the other and the other is unresponsive, when the unresponsive peer comes back, the arbiter can tell them they are to blame, so they can willfully eat the loss and the channel can continue. Both peers are happy this way.

If the unresponsive peer doesn't accept what the arbiter says then the peer that was operating correctly can assume the unresponsive peer is malicious and close the channel, and then blacklist it and never again open a channel with a peer they know is malicious.

Again, the differences between this scheme and the current Lightning Network are that:

a. In the current Lightning we always close channels, in this scheme we only close channels in case someone is malicious or in other worst case scenarios (the arbiter is unresponsive, for example). b. In the current Lightning we close the channels without having any clue on who is to blame for that, then we just proceed to reopen a channel with that same peer even in the case they were actively trying to harm us before.

What is missing? An arbiter.

The Bitcoin blockchain is the ideal arbiter, it works in the best possible way if we follow the trustless protocol, but as we've seen we can't use the Bitcoin blockchain because it is expensive.

Therefore we need a new arbiter. That is the hard part, but not unsolvable. Notice that we don't need an absolutely perfect arbiter, anything is better than nothing, really, even an unreliable arbiter that is offline half of the day is better than what we have today, or an arbiter that lies, an arbiter that charges some satoshis for each resolution, anything.

Here are some suggestions:

• random nodes from the network selected by an algorithm that both peers agree to, so they can't cheat by selecting themselves. The only thing these nodes have to do is to store data from one peer, try to retransmit it to the other peer and record the results for some time.
• a set of nodes preselected by the two peers when the channel is being opened -- same as above, but with more handpicked-trust involved.
• some third-party cloud storage or notification provider with guarantees of having open data in it and some public log-keeping, like Twitter, GitHub or a Nostr relay;
• peers that get paid to do the job, selected by the fact that they own some token (I know this is stepping too close to the shitcoin territory, but could be an idea) issued in a Spacechain;
• a Spacechain itself, serving only as the storage for a bunch of OP_RETURNs that are published and tracked by these Lightning peers whenever there is an issue (this looks wrong, but could work).

Key points

1. Lightning with HTLC-based routing was a cool idea, but it wasn't ever really feasible.
2. HTLCs are going to be abandoned and that's the natural course of things.
3. It is actually good that HTLCs are being abandoned, but
4. We must change the protocol to account for the existence of fake HTLCs and thus make the bulk of the Lightning Network usage viable again.

See also

• Ripple and the problem of the decentralized commit
• The Lightning Network solves the problem of the decentralized commit

@ 3bf0c63f:aefa459d

IPFS problems: Conceit

IPFS is trying to do many things. The IPFS leaders are revolutionaries who think they're smarter than the rest of the entire industry.

The fact that they've first proposed a protocol for peer-to-peer distribution of immutable, content-addressed objects, then later tried to fix that same problem using their own half-baked solution (IPNS) is one example.

Other examples are their odd appeal to decentralization in a very non-specific way, their excessive flirtation with Ethereum and their never-to-be-finished can-never-work-as-advertised Filecoin project.

They could have focused on just making the infrastructure for distribution of objects through hashes (not saying this would actually be a good idea, but it had some potential) over a peer-to-peer network, but in trying to reinvent the entire internet they screwed everything up.

@ bbb5dda0:f09e2747

GitHub Actions (CI/CD) over Nostr

I Spent quite a bit of time on getting Nostr-based GitHub actions working. I have a basic runner implementation now, which i've reworked quite a bit when working with @dan on getting the front-end of it into gitworkshop.dev. We found that the nature of these jobs don't really lend itself to fit within the NIP-90 DVM spec.

What we have now: - A dvm-cicd-runner that - Advertises itself using NIP-89 announcements. - Takes a DVM request with: - repository - branch/ref - path to workflow file (.yml) - job timeout (max duration) - 🥜 Cashu prepayment for the job timeout (to be refunded) - Pulls the repository and executes the provided workflow file - Sends logs in batches as partial job results - Publishes job results and gets displayed in gitworkshop - Gitworkshop.dev (all nostr:npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr work) UI that : - Shows available workflow runners. - Instructing + paying runner to execute workflow file - Displaying job status, live updating with the latest logs / autoscroll, all the stuff you'd expect - Neatly displaying past jobs for the current repository

TODO'S + Ideas/vision

• TODO: refunding the unused minutes (job timeout - processing time) to the requester
• TODO: create seperate kinds/nip for worflow execution over nostr
• Create separate kinds for streaming arbitrary text data over nostr (line by line logs)
• automated git watchers for projects to kick of jobs
• Separate out workflow management stuff from gitworkshop.dev. A micro-app might serve better to manage runners for git projects etc and takes away pressure from gitworkshop.dev to do it all.
• Perhaps support just running .yaml files, without the requirement to have it in a git repo. Could just be a .yaml file on blossom.

TollGate

I spent most of my time working on TollGate. There's been a lot of back and forth to the drawing board to narrow down what the TollGate protocol looks like. I helped define some concepts on implementing a tollgate which we could use as language to discuss the different components that are part of a tollgate implementation. It helped us narrow down what was implementation and what is part of the protocol.

Current state of the project

• We have a website displaying the project: TollGate.me
• Worked on a basic android app for auto payments, validating we can auto-buy from tollgates by our phones
  • demo
• Presented TollGate at @Sats 'n Facts
• There's a protocol draft, presented at SEC-04
• We've done workshops, people were able to turn an OpenWRT router into a TollGate
• Building and releasing TollGate as a singular OpenWRT package, installable on any compatible architecture
• Building and releasing TollGate OS v0.0.1 (prebuilt OpenWRT image), targeting a few specific routers
• First tollgate deployed in the wild!! (At a restaurant in Funchal, Madeira)
• Other developers started to make their own adjacent implementations, which decentralizes the protocol already

What's next:

• We're gathering useful real user feedback to be incorporated in OS v0.0.2 soon
• Refine the protocol further
• Showing TollGate at various conferences in Europe throughout the summer
• Keep building the community, it's growing fast

Epoxy (Nostr based Addressing)

Although i've pivoted towards focusing on TollGate I worked out an implementation of my NIP-(1)37 proposal. During SEC-04 I worked out this browser plugin to demonstrate one way to make websites resistant to rugpulls.

It works by looking for a meta tag in the page's head: html <meta name="nostr-pubkey" relays="relay.site.com,other.relay.com">[hexPubkey]</meta>

When we've never recorded a pubkey for this domain, we save it. This pubkey now serves as the owner of the website. It looks for a kind 11111 event of that pubkey. It should list the current domain as one of it's domains. If not, it shows a warning.

The key concept is that if we visit this website again and one of these scenario's is true: - There is no longer a meta tag - There's another pubkey in the meta tag - The pubkey is still on the webpage, but the 11111 no longer lists this domain

Then we consider this domain as RUGPULLED and the user gets an error, suggesting to navigate to other domain listed by this pubkey. I'd like it to perhaps auto-redirect to another domain listed by the owner, this is especially useful for frequently rugged domains.

This extension does try to solve a bootstrapping problem. We need to establish the website's pubkey at some point. We have to start somewhere, which is why the first load is considered as the 'real' one, since we have no way of knowing for sure.

Other

🥜/⚡️ Receipt.Cash - Social Receipt sharing app

During SEC I worked on scratching an itch that has been lingering in my mind since SEC-03 already. And now that vibecoding is a thing it wasn't this huge undertaking anymore to handle the front-end stuff (which i suck at).

The usage scenario is a bunch of bitcoiners that are at a restaurant, we get the bill and want to split it amongst each other. One person can pay the bill, then: - Payer photographs receipt - Payer adds Cashu Payment request - Payer sets dev split % - App turns the receipt + request into a (encrypted) nostr event - The payer shares the event with QR or Share Menu

The friend scan the QR: - Receipt is loaded and displayed - Friend selects items they ordered - Friend hits pay button (⚡️Lightning or 🥜Cashu) and pays - Payment gets sent to Payer's cashu wallet - Dev split set by Payer goes to dev address.

Some features: - Change LLM model that processes the receipt to extract data - Proofs storage + recovery (if anything fails during processing)

Todo's: - Letting payer configure LNURL for payouts - Letting payer edit Receipt before sharing - Fix: live updates on settled items

The repo: receipt-cash

@ 2fe297f6:553a49da

lkhkjhlk

!?

@ 3bf0c63f:aefa459d

Custom spreadsheets

The idea was to use it to make an app that would serve as custom database for everything and interact with the spreadsheet so people could play and calculate with their values after they were created by the custom app, something like an MS Access integrated with Excel?

My first attempt that worked (I believe there was an attempt before but I have probably deleted it from everywhere) was this react-microspreadsheet thing (at the time called react-spreadsheet before I donated the npm name to someone who asked):

• https://github.com/fiatjaf/react-microspreadsheet

This was a very good spreadsheet component that did many things current "react spreadsheet" components out there don't do. It had formulas; support for that handle thing that you pulled with the mouse and it autofilled cells with a pattern; it had keyboard navigation with Ctrl, Shift, Ctrl+Shift; it had that thing through which you copy-pasted formulas and they would change their parameters depending on where you pasted them (implemented in a very poor manner because I was using and thinking about Excel in baby mode at the time).

Then I tried to make it into "a small sheet you can share" kind of app through assemblymade.com, and eventually as I tried to add more things bugs began to appear.

Then there was cycle6-spreadsheet:

• https://github.com/fiatjaf/spreadsheet-cycle6

If I remember well this was very similar to the other one, although made almost 2 years after. Despite having the same initial goal of the other (the multi-app custom database thing) it only yielded:

• Sidesheet, a Chrome extension that opened a spreadsheet on the side of the screen that you could use to make calculations and so on. It worked, but had too many bugs that probably caused me to give up entirely.

I'm not sure which of the two spreadsheets above powers http://sheets.alhur.es.

@ fd0bcf8c:521f98c0

The vag' sits on the edge of the highway, broken, hungry. Overhead flies a transcontinental plane filled with highly paid executives. The upper class has taken to the air, the lower class to the roads: there is no longer any bond between them, they are two nations."—The Sovereign Individual

Fire

I was talking to a friend last night. Coffee in hand. Watching flames consume branches. Spring night on his porch.

He believed in America's happy ending. Debt would vanish. Inflation would cool. Manufacturing would return. Good guys win.

I nodded. I wanted to believe.

He leaned forward, toward the flame. I sat back, watching both fire and sky.

His military photos hung inside. Service medals displayed. Patriotism bone-deep.

The pendulum clock on his porch wall swung steadily. Tick. Tock. Measuring moments. Marking epochs.

History tells another story. Not tragic. Just true.

Our time has come. America cut off couldn't compete. Factories sit empty. Supply chains span oceans. Skills lack. Children lag behind. Rebuilding takes decades.

Truth hurts. Truth frees.

Cycles

History moves in waves. Every 500 years, power shifts. Systems fall. Systems rise.

500 BC - Greek coins changed everything. Markets flourished. Athens dominated.

1 AD - Rome ruled commerce. One currency. Endless roads. Bustling ports.

500 AD - Rome faded. Not overnight. Slowly. Trade withered. Cities emptied. Money debased. Roads crumbled. Local strongmen rose. Peasants sought protection. Feudalism emerged.

People still lived. Still worked. Horizons narrowed. Knowledge concentrated. Most barely survived. Rich adapted. Poor suffered.

Self-reliance determined survival. Those growing food endured. Those making essential goods continued. Those dependent on imperial systems suffered most.

1000 AD - Medieval revival began. Venice dominated seas. China printed money. Cathedrals rose. Universities formed.

1500 AD - Europeans sailed everywhere. Spanish silver flowed. Banks financed kingdoms. Companies colonized continents. Power moved west.

The pendulum swung. East to West. West to East. Civilizations rose. Civilizations fell.

2000 AD - Pattern repeats. America strains. Digital networks expand. China rises. Debt swells. Old systems break.

We stand at the hinge.

Warnings

Signs everywhere. Dollar weakens globally. BRICS builds alternatives. Yuan buys oil. Factories rust. Debt exceeds GDP. Interest consumes budgets.

Bridges crumble. Education falters. Politicians chase votes. We consume. We borrow.

Rome fell gradually. Citizens barely noticed. Taxes increased. Currency devalued. Military weakened. Services decayed. Life hardened by degrees.

East Rome adapted. Survived centuries. West fragmented. Trade shrank. Some thrived. Others suffered. Life changed permanently.

Those who could feed themselves survived best. Those who needed the system suffered worst.

Pendulum

My friend poured another coffee. The burn pile popped loudly. Sparks flew upward like dying stars.

His face changed as facts accumulated. Military man. Trained to assess threats. Detect weaknesses.

He stared at the fire. National glory reduced to embers. Something shifted in his expression. Recognition.

His fingers tightened around his mug. Knuckles white. Eyes fixed on dying flames.

I traced the horizon instead. Observing landscape. Noting the contrast.

He touched the flag on his t-shirt. I adjusted my plain gray one.

The unpayable debt. The crumbling infrastructure. The forgotten manufacturing. The dependent supply chains. The devaluing currency.

The pendulum clock ticked. Relentless. Indifferent to empires.

His eyes said what his patriotism couldn't voice. Something fundamental breaking.

I'd seen this coming. Years traveling showed me. Different systems. Different values. American exceptionalism viewed from outside.

Pragmatism replaced my old idealism. See things as they are. Not as wished.

The logs shifted. Flames reached higher. Then lower. The cycle of fire.

Divergence

Society always splits during shifts.

Some adapt. Some don't.

Printing arrived. Scribes starved. Publishers thrived. Information accelerated. Readers multiplied. Ideas spread. Adapters prospered.

Steam engines came. Weavers died. Factory owners flourished. Villages emptied. Cities grew. Coal replaced farms. Railways replaced wagons. New skills meant survival.

Computers transformed everything. Typewriters vanished. Software boomed. Data replaced paper. Networks replaced cabinets. Programmers replaced typists. Digital skills determined success.

The self-reliant thrived in each transition. Those waiting for rescue fell behind.

Now AI reshapes creativity. Some artists resist. Some harness it. Gap widens daily.

Bitcoin offers refuge. Critics mock. Adopters build wealth. The distance grows.

Remote work redraws maps. Office-bound struggle. Location-free flourish.

The pendulum swings. Power shifts. Some rise with it. Some fall against it.

Two societies emerge. Adaptive. Resistant. Prepared. Pretending.

Advantage

Early adapters win. Not through genius. Through action.

First printers built empires. First factories created dynasties. First websites became giants.

Bitcoin followed this pattern. Laptop miners became millionaires. Early buyers became legends.

Critics repeat themselves: "Too volatile." "No value." "Government ban coming."

Doubters doubt. Builders build. Gap widens.

Self-reliance accelerates adaptation. No permission needed. No consensus required. Act. Learn. Build.

The burn pile flames like empire's glory. Bright. Consuming. Temporary.

Blindness

Our brains see tigers. Not economic shifts.

We panic at headlines. We ignore decades-long trends.

We notice market drops. We miss debt cycles.

We debate tweets. We ignore revolutions.

Not weakness. Just humanity. Foresight requires work. Study. Thought.

Self-reliant thinking means seeing clearly. No comforting lies. No pleasing narratives. Just reality.

The clock pendulum swings. Time passes regardless of observation.

Action

Empires fall. Families need security. Children need futures. Lives need meaning.

You can adapt faster than nations.

Assess honestly. What skills matter now? What preserves wealth? Who helps when needed?

Never stop learning. Factory workers learned code. Taxi drivers joined apps. Photographers went digital.

Diversify globally. No country owns tomorrow. Learn languages. Make connections. Stay mobile.

Protect your money. Dying empires debase currencies. Romans kept gold. Bitcoin offers similar shelter.

Build resilience. Grow food. Make energy. Stay strong. Keep friends. Read old books. Some things never change.

Self-reliance matters most. Can you feed yourself? Can you fix things? Can you solve problems? Can you create value without systems?

Movement

Humans were nomads first. Settlers second. Movement in our blood.

Our ancestors followed herds. Sought better lands. Survival meant mobility.

The pendulum swings here too. Nomad to farmer. City-dweller to digital nomad.

Rome fixed people to land. Feudalism bound serfs to soil. Nations created borders. Companies demanded presence.

Now technology breaks chains. Work happens anywhere. Knowledge flows everywhere.

The rebuild America seeks requires fixed positions. Factory workers. Taxpaying citizens in permanent homes.

But technology enables escape. Remote work. Digital currencies. Borderless businesses.

The self-reliant understand mobility as freedom. One location means one set of rules. One economy. One fate.

Many locations mean options. Taxes become predatory? Leave. Opportunities disappear? Find new ones.

Patriotism celebrates roots. Wisdom remembers wings.

My friend's boots dug into his soil. Planted. Territorial. Defending.

My Chucks rested lightly. Ready. Adaptable. Departing.

His toolshed held equipment to maintain boundaries. Fences. Hedges. Property lines.

My backpack contained tools for crossing them. Chargers. Adapters. Currency.

The burn pile flame flickers. Fixed in place. The spark flies free. Movement its nature.

During Rome's decline, the mobile survived best. Merchants crossing borders. Scholars seeking patrons. Those tied to crumbling systems suffered most.

Location independence means personal resilience. Economic downturns become geographic choices. Political oppression becomes optional suffering.

Technology shrinks distance. Digital work. Video relationships. Online learning.

Self-sovereignty requires mobility. The option to walk away. The freedom to arrive elsewhere.

Two more worlds diverge. The rooted. The mobile. The fixed. The fluid. The loyal. The free.

Hope

Not decline. Transition. Painful but temporary.

America may weaken. Humanity advances. Technology multiplies possibilities. Poverty falls. Knowledge grows.

Falling empires see doom. Rising ones see opportunity. Both miss half the picture.

Every shift brings destruction and creation. Rome fell. Europe struggled. Farms produced less. Cities shrank. Trade broke down.

Yet innovation continued. Water mills appeared. New plows emerged. Monks preserved books. New systems evolved.

Different doesn't mean worse for everyone.

Some industries die. Others birth. Some regions fade. Others bloom. Some skills become useless. Others become gold.

The self-reliant thrive in any world. They adapt. They build. They serve. They create.

Choose your role. Nostalgia or building.

The pendulum swings. East rises again. The cycle continues.

Fading

The burn pile dimmed. Embers fading. Night air cooling.

My friend's shoulders changed. Tension releasing. Something accepted.

His patriotism remained. His illusions departed.

The pendulum clock ticked steadily. Measuring more than minutes. Measuring eras.

Two coffee cups. His: military-themed, old and chipped but cherished. Mine: plain porcelain, new and unmarked.

His eyes remained on smoldering embers. Mine moved between him and the darkening trees.

His calendar marked local town meetings. Mine tracked travel dates.

The last flame flickered out. Spring peepers filled the silence.

In darkness, we watched smoke rise. The world changing. New choices ahead.

No empire lasts forever. No comfort in denial. Only clarity in acceptance.

Self-reliance the ancient answer. Build your skills. Secure your resources. Strengthen your body. Feed your mind. Help your neighbors.

The burn pile turned to ash. Empire's glory extinguished.

He stood facing his land. I faced the road.

A nod between us. Respect across division. Different strategies for the same storm.

He turned toward his home. I toward my vehicle.

The pendulum continued swinging. Power flowing east once more. Five centuries ending. Five centuries beginning.

"Bear in mind that everything that exists is already fraying at the edges." — Marcus Aurelius

Tomorrow depends not on nations. On us.