@ 9e69e420:d12360c2

## Chef's notes # arbitray - test - of - chefs notes ## hedding 2 ## Details - ⏲️ Prep time: 20 - 🍳 Cook time: 1 hour - 🍽️ Servings: 5 ## Ingredients - Test ingredient - 2nd test ingredient ## Directions 1. Bake 2. Cool

@ 9e69e420:d12360c2

Oregano oil is a potent natural compound that offers numerous scientifically-supported health benefits. ## Active Compounds The oil's therapeutic properties stem from its key bioactive components: - Carvacrol and thymol (primary active compounds) - Polyphenols and other antioxidant ## Antimicrobial Properties **Bacterial Protection** The oil demonstrates powerful antibacterial effects, even against antibiotic-resistant strains like MRSA and other harmful bacteria. Studies show it effectively inactivates various pathogenic bacteria without developing resistance. **Antifungal Effects** It effectively combats fungal infections, particularly Candida-related conditions like oral thrush, athlete's foot, and nail infections. ## Digestive Health Benefits Oregano oil supports digestive wellness by: - Promoting gastric juice secretion and enzyme production - Helping treat Small Intestinal Bacterial Overgrowth (SIBO) - Managing digestive discomfort, bloating, and IBS symptoms ## Anti-inflammatory and Antioxidant Effects The oil provides significant protective benefits through: - Powerful antioxidant activity that fights free radicals - Reduction of inflammatory markers in the body - Protection against oxidative stress-related conditions ## Respiratory Support It aids respiratory health by: - Loosening mucus and phlegm - Suppressing coughs and throat irritation - Supporting overall respiratory tract function ## Additional Benefits **Skin Health** - Improves conditions like psoriasis, acne, and eczema - Supports wound healing through antibacterial action - Provides anti-aging benefits through antioxidant properties **Cardiovascular Health** Studies show oregano oil may help: - Reduce LDL (bad) cholesterol levels - Support overall heart health **Pain Management** The oil demonstrates effectiveness in: - Reducing inflammation-related pain - Managing muscle discomfort - Providing topical pain relief ## Safety Note While oregano oil is generally safe, it's highly concentrated and should be properly diluted before use Consult a healthcare provider before starting supplementation, especially if taking other medications.

@ 9e69e420:d12360c2

A new report from the National Sports Shooting Foundation (NSSF) shows that civilian firearm possession exceeded 490 million in 2022. The total from 1990 to 2022 is estimated at 491.3 million firearms. In 2022, over ten million firearms were domestically produced, leading to a total of 16,045,911 firearms available in the U.S. market. Of these, 9,873,136 were handguns, 4,195,192 were rifles, and 1,977,583 were shotguns. Handgun availability aligns with the concealed carry and self-defense market, as all states allow concealed carry, with 29 having constitutional carry laws.

@ f9cf4e94:96abc355

Para esse exemplo iremos usar: | Nome | Imagem | Descrição | | --------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | | Raspberry PI B+ |  | **Cortex-A53 (ARMv8) 64-bit a 1.4GHz e 1 GB de SDRAM LPDDR2,** | | Pen drive |  | **16Gb** | Recomendo que use o **Ubuntu Server** para essa instalação. Você pode baixar o Ubuntu para Raspberry Pi [aqui]( https://ubuntu.com/download/raspberry-pi). O passo a passo para a instalação do Ubuntu no Raspberry Pi está disponível [aqui]( https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi). **Não instale um desktop** (como xubuntu, lubuntu, xfce, etc.). --- ## Passo 1: Atualizar o Sistema 🖥️ Primeiro, atualize seu sistema e instale o Tor: ```bash apt update apt install tor ``` --- ## Passo 2: Criar o Arquivo de Serviço `nrs.service` 🔧 Crie o arquivo de serviço que vai gerenciar o servidor Nostr. Você pode fazer isso com o seguinte conteúdo: ```unit [Unit] Description=Nostr Relay Server Service After=network.target [Service] Type=simple WorkingDirectory=/opt/nrs ExecStart=/opt/nrs/nrs-arm64 Restart=on-failure [Install] WantedBy=multi-user.target ``` --- ## Passo 3: Baixar o Binário do Nostr 🚀 Baixe o binário mais recente do Nostr [aqui no GitHub]( https://github.com/gabrielmoura/SimpleNosrtRelay/releases). --- ## Passo 4: Criar as Pastas Necessárias 📂 Agora, crie as pastas para o aplicativo e o pendrive: ```bash mkdir -p /opt/nrs /mnt/edriver ``` --- ## Passo 5: Listar os Dispositivos Conectados 🔌 Para saber qual dispositivo você vai usar, liste todos os dispositivos conectados: ```bash lsblk ``` --- ## Passo 6: Formatando o Pendrive 💾 Escolha o pendrive correto (por exemplo, `/dev/sda`) e formate-o: ```bash mkfs.vfat /dev/sda ``` --- ## Passo 7: Montar o Pendrive 💻 Monte o pendrive na pasta `/mnt/edriver`: ```bash mount /dev/sda /mnt/edriver ``` --- ## Passo 8: Verificar UUID dos Dispositivos 📋 Para garantir que o sistema monte o pendrive automaticamente, liste os UUID dos dispositivos conectados: ```bash blkid ``` --- ## Passo 9: Alterar o `fstab` para Montar o Pendrive Automáticamente 📝 Abra o arquivo `/etc/fstab` e adicione uma linha para o pendrive, com o UUID que você obteve no passo anterior. A linha deve ficar assim: ```fstab UUID=9c9008f8-f852 /mnt/edriver vfat defaults 0 0 ``` --- ## Passo 10: Copiar o Binário para a Pasta Correta 📥 Agora, copie o binário baixado para a pasta `/opt/nrs`: ```bash cp nrs-arm64 /opt/nrs ``` --- ## Passo 11: Criar o Arquivo de Configuração 🛠️ Crie o arquivo de configuração com o seguinte conteúdo e salve-o em `/opt/nrs/config.yaml`: ```yaml app_env: production info: name: Nostr Relay Server description: Nostr Relay Server pub_key: "" contact: "" url: http://localhost:3334 icon: https://external-content.duckduckgo.com/iu/?u= https://public.bnbstatic.com/image/cms/crawler/COINCU_NEWS/image-495-1024x569.png base_path: /mnt/edriver negentropy: true ``` --- ## Passo 12: Copiar o Serviço para o Diretório de Systemd ⚙️ Agora, copie o arquivo `nrs.service` para o diretório `/etc/systemd/system/`: ```bash cp nrs.service /etc/systemd/system/ ``` Recarregue os serviços e inicie o serviço `nrs`: ```bash systemctl daemon-reload systemctl enable --now nrs.service ``` --- ## Passo 13: Configurar o Tor 🌐 Abra o arquivo de configuração do Tor `/var/lib/tor/torrc` e adicione a seguinte linha: ```torrc HiddenServiceDir /var/lib/tor/nostr_server/ HiddenServicePort 80 127.0.0.1:3334 ``` --- ## Passo 14: Habilitar e Iniciar o Tor 🧅 Agora, ative e inicie o serviço Tor: ```bash systemctl enable --now tor.service ``` O Tor irá gerar um endereço `.onion` para o seu servidor Nostr. Você pode encontrá-lo no arquivo `/var/lib/tor/nostr_server/hostname`. --- ## Observações ⚠️ - Com essa configuração, **os dados serão salvos no pendrive**, enquanto o binário ficará no cartão SD do Raspberry Pi. - O endereço `.onion` do seu servidor Nostr será algo como: `ws://y3t5t5wgwjif<exemplo>h42zy7ih6iwbyd.onion`. --- Agora, seu servidor Nostr deve estar configurado e funcionando com Tor! 🥳 Se este artigo e as informações aqui contidas forem úteis para você, convidamos a considerar uma doação ao autor como forma de reconhecimento e incentivo à produção de novos conteúdos.

@ 3f770d65:7a745b24

I’ve been using Notedeck for several months, starting with its extremely early and experimental alpha versions, all the way to its current, more stable alpha releases. The journey has been fascinating, as I’ve had the privilege of watching it evolve from a concept into a functional and promising tool. In its earliest stages, Notedeck was raw—offering glimpses of its potential but still far from practical for daily use. Even then, the vision behind it was clear: a platform designed to redefine how we interact with Nostr by offering flexibility and power for all users. I'm very bullish on Notedeck. Why? Because Will Casarin is making it! Duh! 😂 Seriously though, if we’re reimagining the web and rebuilding portions of the Internet, it’s important to recognize [the potential of Notedeck](https://damus.io/notedeck/). If Nostr is reimagining the web, then Notedeck is reimagining the Nostr client. Notedeck isn’t just another Nostr app—it’s more a Nostr browser that functions more like an operating system with micro-apps. How cool is that? Much like how Google's Chrome evolved from being a web browser with a task manager into ChromeOS, a full blown operating system, Notedeck aims to transform how we interact with the Nostr. It goes beyond individual apps, offering a foundation for a fully integrated ecosystem built around Nostr. As a Nostr evangelist, I love to scream **INTEROPERABILITY** and tout every application's integrations. Well, Notedeck has the potential to be one of the best platforms to showcase these integrations in entirely new and exciting ways. Do you want an Olas feed of images? Add the media column. Do you want a feed of live video events? Add the zap.stream column. Do you want Nostr Nests or audio chats? Add that column to your Notedeck. Git? Email? Books? Chat and DMs? It's all possible. Not everyone wants a super app though, and that’s okay. As with most things in the Nostr ecosystem, flexibility is key. Notedeck gives users the freedom to choose how they engage with it—whether it’s simply following hashtags or managing straightforward feeds. You'll be able to tailor Notedeck to fit your needs, using it as extensively or minimally as you prefer. Notedeck is designed with a local-first approach, utilizing Nostr content stored directly on your device via the local nostrdb. This will enable a plethora of advanced tools such as search and filtering, the creation of custom feeds, and the ability to develop personalized algorithms across multiple Notedeck micro-applications—all with unparalleled flexibility. Notedeck also supports multicast. Let's geek out for a second. Multicast is a method of communication where data is sent from one source to multiple destinations simultaneously, but only to devices that wish to receive the data. Unlike broadcast, which sends data to all devices on a network, multicast targets specific receivers, reducing network traffic. This is commonly used for efficient data distribution in scenarios like streaming, conferencing, or large-scale data synchronization between devices. > In a local first world where each device holds local copies of your nostr nodes, and each device transparently syncs with each other on the local network, each node becomes a backup. Your data becomes antifragile automatically. When a node goes down it can resync and recover from other nodes. Even if not all nodes have a complete collection, negentropy can pull down only what is needed from each device. All this can be done without internet. > > \-Will Casarin In the context of Notedeck, multicast would allow multiple devices to sync their Nostr nodes with each other over a local network without needing an internet connection. Wild. Notedeck aims to offer full customization too, including the ability to design and share custom skins, much like Winamp. Users will also be able to create personalized columns and, in the future, share their setups with others. This opens the door for power users to craft tailored Nostr experiences, leveraging their expertise in the protocol and applications. By sharing these configurations as "Starter Decks," they can simplify onboarding and showcase the best of Nostr’s ecosystem. Nostr’s “Other Stuff” can often be difficult to discover, use, or understand. Many users doesn't understand or know how to use web browser extensions to login to applications. Let's not even get started with nsecbunkers. Notedeck will address this challenge by providing a native experience that brings these lesser-known applications, tools, and content into a user-friendly and accessible interface, making exploration seamless. However, that doesn't mean Notedeck should disregard power users that want to use nsecbunkers though - hint hint. For anyone interested in watching Nostr be [developed live](https://github.com/damus-io/notedeck), right before your very eyes, Notedeck’s progress serves as a reminder of what’s possible when innovation meets dedication. The current alpha is already demonstrating its ability to handle complex use cases, and I’m excited to see how it continues to grow as it moves toward a full release later this year.

@ e97aaffa:2ebd765d

Último dia do ano, momento para tirar o pó da bola de cristal, para fazer reflexões, previsões e desejos para o próximo ano e seguintes. Ano após ano, o Bitcoin evoluiu, foi ultrapassando etapas, tornou-se cada vez mais _mainstream_. Está cada vez mais difícil fazer previsões sobre o Bitcoin, já faltam poucas barreiras a serem ultrapassadas e as que faltam são altamente complexas ou tem um impacto profundo no sistema financeiro ou na sociedade. Estas alterações profundas tem que ser realizadas lentamente, porque uma alteração rápida poderia resultar em consequências terríveis, poderia provocar um retrocesso. # Código do Bitcoin No final de 2025, possivelmente vamos ter um _fork_, as discussões sobre os _covenants_ já estão avançadas, vão acelerar ainda mais. Já existe um consenso relativamente alto, a favor dos _covenants_, só falta decidir que modelo será escolhido. Penso que até ao final do ano será tudo decidido. Depois dos _covenants,_ o próximo foco será para a criptografia post-quantum, que será o maior desafio que o Bitcoin enfrenta. Criar uma criptografia segura e que não coloque a descentralização em causa. Espero muito de Ark, possivelmente a inovação do ano, gostaria de ver o Nostr a furar a bolha bitcoinheira e que o Cashu tivesse mais reconhecimento pelos _bitcoiners_. Espero que surjam avanços significativos no BitVM2 e BitVMX. Não sei o que esperar das layer 2 de Bitcoin, foram a maior desilusão de 2024. Surgiram com muita força, mas pouca coisa saiu do papel, foi uma mão cheia de nada. Uma parte dos projetos caiu na tentação da _shitcoinagem_, na criação de tokens, que tem um único objetivo, enriquecer os devs e os VCs. Se querem ser levados a sério, têm que ser sérios. > “À mulher de César não basta ser honesta, deve parecer honesta” Se querem ter o apoio dos _bitcoiners_, sigam o _ethos_ do Bitcoin. Neste ponto a atitude do pessoal da Ark é exemplar, em vez de andar a chorar no Twitter para mudar o código do Bitcoin, eles colocaram as mãos na massa e criaram o protocolo. É claro que agora está meio “coxo”, funciona com uma _multisig_ ou com os _covenants_ na Liquid. Mas eles estão a criar um produto, vão demonstrar ao mercado que o produto é bom e útil. Com a adoção, a comunidade vai perceber que o Ark necessita dos _covenants_ para melhorar a interoperabilidade e a soberania. É este o pensamento certo, que deveria ser seguido pelos restantes e futuros projetos. É seguir aquele pensamento do J.F. Kennedy: > “Não perguntem o que é que o vosso país pode fazer por vocês, perguntem o que é que vocês podem fazer pelo vosso país” Ou seja, não fiquem à espera que o bitcoin mude, criem primeiro as inovações/tecnologia, ganhem adoção e depois demonstrem que a alteração do código camada base pode melhorar ainda mais o vosso projeto. A necessidade é que vai levar a atualização do código. # Reservas Estratégicas de Bitcoin ## Bancos centrais Com a eleição de Trump, emergiu a ideia de uma Reserva Estratégia de Bitcoin, tornou este conceito _mainstream_. Foi um _pivot_, a partir desse momento, foram enumerados os políticos de todo o mundo a falar sobre o assunto. A Senadora Cynthia Lummis foi mais além e propôs um programa para adicionar 200 mil bitcoins à reserva ao ano, até 1 milhão de Bitcoin. Só que isto está a criar uma enorme expectativa na comunidade, só que pode resultar numa enorme desilusão. Porque no primeiro ano, o Trump em vez de comprar os 200 mil, pode apenas adicionar na reserva, os 198 mil que o Estado já tem em sua posse. Se isto acontecer, possivelmente vai resultar numa forte queda a curto prazo. Na minha opinião os bancos centrais deveriam seguir o exemplo de El Salvador, fazer um DCA diário. Mais que comprar bitcoin, para mim, o mais importante é a criação da Reserva, é colocar o Bitcoin ao mesmo nível do ouro, o impacto para o resto do mundo será tremendo, a teoria dos jogos na sua plenitude. Muitos outros bancos centrais vão ter que comprar, para não ficarem atrás, além disso, vai transmitir uma mensagem à generalidade da população, que o Bitcoin é “afinal é algo seguro, com valor”. Mas não foi Trump que iniciou esta teoria dos jogos, mas sim foi a primeira vítima dela. É o próprio Trump que o admite, que os EUA necessitam da reserva para não ficar atrás da China. Além disso, desde que os EUA utilizaram o dólar como uma arma, com sanção contra a Rússia, surgiram boatos de que a Rússia estaria a utilizar o Bitcoin para transações internacionais. Que foram confirmados recentemente, pelo próprio governo russo. Também há poucos dias, ainda antes deste reconhecimento público, Putin elogiou o Bitcoin, ao reconhecer que “Ninguém pode proibir o bitcoin”, defendendo como uma alternativa ao dólar. A narrativa está a mudar. Já existem alguns países com Bitcoin, mas apenas dois o fizeram conscientemente (El Salvador e Butão), os restantes têm devido a apreensões. Hoje são poucos, mas 2025 será o início de uma corrida pelos bancos centrais. Esta corrida era algo previsível, o que eu não esperava é que acontecesse tão rápido.  ## Empresas A criação de reservas estratégicas não vai ficar apenas pelos bancos centrais, também vai acelerar fortemente nas empresas em 2025.  Mas as empresas não vão seguir a estratégia do Saylor, vão comprar bitcoin sem alavancagem, utilizando apenas os tesouros das empresas, como uma proteção contra a inflação. Eu não sou grande admirador do Saylor, prefiro muito mais, uma estratégia conservadora, sem qualquer alavancagem. Penso que as empresas vão seguir a sugestão da BlackRock, que aconselha um alocações de 1% a 3%. Penso que 2025, ainda não será o ano da entrada das 6 magníficas (excepto Tesla), será sobretudo empresas de pequena e média dimensão. As magníficas ainda tem uma cota muito elevada de _shareholders_ com alguma idade, bastante conservadores, que têm dificuldade em compreender o Bitcoin, foi o que aconteceu recentemente com a Microsoft. Também ainda não será em 2025, talvez 2026, a inclusão nativamente de wallet Bitcoin nos sistema da Apple Pay e da Google Pay. Seria um passo gigante para a adoção a nível mundial. # ETFs Os ETFs para mim são uma incógnita, tenho demasiadas dúvidas, como será 2025. Este ano os _inflows_ foram superiores a 500 mil bitcoins, o IBIT foi o lançamento de ETF mais bem sucedido da história. O sucesso dos ETFs, deve-se a 2 situações que nunca mais se vão repetir. O mercado esteve 10 anos à espera pela aprovação dos ETFs, a procura estava reprimida, isso foi bem notório nos primeiros meses, os _inflows_ foram brutais. Também se beneficiou por ser um mercado novo, não existia _orderbook_ de vendas, não existia um mercado interno, praticamente era só _inflows_. Agora o mercado já estabilizou, a maioria das transações já são entre clientes dos próprios ETFs. Agora só uma pequena percentagem do volume das transações diárias vai resultar em _inflows_ ou _outflows_. Estes dois fenómenos nunca mais se vão repetir, eu não acredito que o número de _inflows_ em BTC supere os número de 2024, em dólares vai superar, mas em btc não acredito que vá superar. Mas em 2025 vão surgir uma infindável quantidade de novos produtos, derivativos, novos ETFs de cestos com outras criptos ou cestos com ativos tradicionais. O bitcoin será adicionado em produtos financeiros já existentes no mercado, as pessoas vão passar a deter bitcoin, sem o saberem. Com o fim da operação ChokePoint 2.0, vai surgir uma nova onda de adoção e de produtos financeiros. Possivelmente vamos ver bancos tradicionais a disponibilizar produtos ou serviços de custódia aos seus clientes. Eu adoraria ver o crescimento da adoção do bitcoin como moeda, só que a regulamentação não vai ajudar nesse processo. # Preço Eu acredito que o topo deste ciclo será alcançado no primeiro semestre, posteriormente haverá uma correção. Mas desta vez, eu acredito que a correção será muito menor que as anteriores, inferior a 50%, esta é a minha expectativa. Espero estar certo. # Stablecoins de dólar Agora saindo um pouco do universo do Bitcoin, acho importante destacar as _stablecoins_. No último ciclo, eu tenho dividido o tempo, entre continuar a estudar o Bitcoin e estudar o sistema financeiro, as suas dinâmicas e o comportamento humano. Isto tem sido o meu foco de reflexão, imaginar a transformação que o mundo vai sofrer devido ao padrão Bitcoin. É uma ilusão acreditar que a transição de um padrão FIAT para um padrão Bitcoin vai ser rápida, vai existir um processo transitório que pode demorar décadas. Com a re-entrada de Trump na Casa Branca, prometendo uma política altamente protecionista, vai provocar uma forte valorização do dólar, consequentemente as restantes moedas do mundo vão derreter. Provocando uma inflação generalizada, gerando uma corrida às _stablecoins_ de dólar nos países com moedas mais fracas. Trump vai ter uma política altamente expansionista, vai exportar dólares para todo o mundo, para financiar a sua própria dívida. A desigualdade entre os pobres e ricos irá crescer fortemente, aumentando a possibilidade de conflitos e revoltas. > “Casa onde não há pão, todos ralham e ninguém tem razão” Será mais lenha, para alimentar a fogueira, vai gravar os conflitos geopolíticos já existentes, ficando as sociedade ainda mais polarizadas. Eu acredito que 2025, vai haver um forte crescimento na adoção das _stablecoins_ de dólares, esse forte crescimento vai agravar o problema sistémico que são as _stablecoins_. Vai ser o início do fim das _stablecoins_, pelo menos, como nós conhecemos hoje em dia. ## Problema sistémico O sistema FIAT não nasceu de um dia para outro, foi algo que foi construído organicamente, ou seja, foi evoluindo ao longo dos anos, sempre que havia um problema/crise, eram criadas novas regras ou novas instituições para minimizar os problemas. Nestes quase 100 anos, desde os acordos de Bretton Woods, a evolução foram tantas, tornaram o sistema financeiro altamente complexo, burocrático e nada eficiente. Na prática é um castelo de cartas construído sobre outro castelo de cartas e que por sua vez, foi construído sobre outro castelo de cartas. As _stablecoins_ são um problema sistémico, devido às suas reservas em dólares e o sistema financeiro não está preparado para manter isso seguro. Com o crescimento das reservas ao longo dos anos, foi se agravando o problema. No início a Tether colocava as reservas em bancos comerciais, mas com o crescimento dos dólares sob gestão, criou um problema nos bancos comerciais, devido à reserva fracionária. Essas enormes reservas da Tether estavam a colocar em risco a própria estabilidade dos bancos. A Tether acabou por mudar de estratégia, optou por outros ativos, preferencialmente por títulos do tesouro/obrigações dos EUA. Só que a Tether continua a crescer e não dá sinais de abrandamento, pelo contrário. Até o próprio mundo cripto, menosprezava a gravidade do problema da Tether/_stablecoins_ para o resto do sistema financeiro, porque o _marketcap_ do cripto ainda é muito pequeno. É verdade que ainda é pequeno, mas a Tether não o é, está no top 20 dos maiores detentores de títulos do tesouros dos EUA e está ao nível dos maiores bancos centrais do mundo. Devido ao seu tamanho, está a preocupar os responsáveis/autoridades/reguladores dos EUA, pode colocar em causa a estabilidade do sistema financeiro global, que está assente nessas obrigações. Os títulos do tesouro dos EUA são o colateral mais utilizado no mundo, tanto por bancos centrais, como por empresas, é a charneira da estabilidade do sistema financeiro. Os títulos do tesouro são um assunto muito sensível. Na recente crise no Japão, do _carry trade_, o Banco Central do Japão tentou minimizar a desvalorização do iene através da venda de títulos dos EUA. Esta operação, obrigou a uma viagem de emergência, da Secretaria do Tesouro dos EUA, Janet Yellen ao Japão, onde disponibilizou liquidez para parar a venda de títulos por parte do Banco Central do Japão. Essa forte venda estava desestabilizando o mercado. Os principais detentores de títulos do tesouros são institucionais, bancos centrais, bancos comerciais, fundo de investimento e gestoras, tudo administrado por gestores altamente qualificados, racionais e que conhecem a complexidade do mercado de obrigações. O mundo cripto é seu oposto, é _naife_ com muita irracionalidade e uma forte pitada de loucura, na sua maioria nem faz a mínima ideia como funciona o sistema financeiro. Essa irracionalidade pode levar a uma “corrida bancária”, como aconteceu com o UST da Luna, que em poucas horas colapsou o projeto. Em termos de escala, a Luna ainda era muito pequena, por isso, o problema ficou circunscrito ao mundo cripto e a empresas ligadas diretamente ao cripto. Só que a Tether é muito diferente, caso exista algum FUD, que obrigue a Tether a desfazer-se de vários biliões ou dezenas de biliões de dólares em títulos num curto espaço de tempo, poderia provocar consequências terríveis em todo o sistema financeiro. A Tether é grande demais, é já um problema sistémico, que vai agravar-se com o crescimento em 2025. Não tenham dúvidas, se existir algum problema, o Tesouro dos EUA vai impedir a venda dos títulos que a Tether tem em sua posse, para salvar o sistema financeiro. O problema é, o que vai fazer a Tether, se ficar sem acesso às venda das reservas, como fará o _redeem_ dos dólares? Como o crescimento do Tether é inevitável, o Tesouro e o FED estão com um grande problema em mãos, o que fazer com o Tether? Mas o problema é que o atual sistema financeiro é como um curto cobertor: Quanto tapas a cabeça, destapas os pés; Ou quando tapas os pés, destapas a cabeça. Ou seja, para resolver o problema da guarda reservas da Tether, vai criar novos problemas, em outros locais do sistema financeiro e assim sucessivamente. ### Conta mestre Uma possível solução seria dar uma conta mestre à Tether, dando o acesso direto a uma conta no FED, semelhante à que todos os bancos comerciais têm. Com isto, a Tether deixaria de necessitar os títulos do tesouro, depositando o dinheiro diretamente no banco central. Só que isto iria criar dois novos problemas, com o Custodia Bank e com o restante sistema bancário. O Custodia Bank luta há vários anos contra o FED, nos tribunais pelo direito a ter licença bancária para um banco com _full-reserves_. O FED recusou sempre esse direito, com a justificativa que esse banco, colocaria em risco toda a estabilidade do sistema bancário existente, ou seja, todos os outros bancos poderiam colapsar. Perante a existência em simultâneo de bancos com reserva fracionária e com _full-reserves_, as pessoas e empresas iriam optar pelo mais seguro. Isso iria provocar uma corrida bancária, levando ao colapso de todos os bancos com reserva fracionária, porque no Custodia Bank, os fundos dos clientes estão 100% garantidos, para qualquer valor. Deixaria de ser necessário limites de fundos de Garantia de Depósitos. Eu concordo com o FED nesse ponto, que os bancos com _full-reserves_ são uma ameaça a existência dos restantes bancos. O que eu discordo do FED, é a origem do problema, o problema não está nos bancos _full-reserves_, mas sim nos que têm reserva fracionária. O FED ao conceder uma conta mestre ao Tether, abre um precedente, o Custodia Bank irá o aproveitar, reclamando pela igualdade de direitos nos tribunais e desta vez, possivelmente ganhará a sua licença. Ainda há um segundo problema, com os restantes bancos comerciais. A Tether passaria a ter direitos similares aos bancos comerciais, mas os deveres seriam muito diferentes. Isto levaria os bancos comerciais aos tribunais para exigir igualdade de tratamento, é uma concorrência desleal. Isto é o bom dos tribunais dos EUA, são independentes e funcionam, mesmo contra o estado. Os bancos comerciais têm custos exorbitantes devido às políticas de _compliance_, como o KYC e AML. Como o governo não vai querer aliviar as regras, logo seria a Tether, a ser obrigada a fazer o _compliance_ dos seus clientes. A obrigação do KYC para ter _stablecoins_ iriam provocar um terramoto no mundo cripto. Assim, é pouco provável que seja a solução para a Tether. ### FED Só resta uma hipótese, ser o próprio FED a controlar e a gerir diretamente as _stablecoins_ de dólar, nacionalizado ou absorvendo as existentes. Seria uma espécie de CBDC. Isto iria provocar um novo problema, um problema diplomático, porque as _stablecoins_ estão a colocar em causa a soberania monetária dos outros países. Atualmente as _stablecoins_ estão um pouco protegidas porque vivem num limbo jurídico, mas a partir do momento que estas são controladas pelo governo americano, tudo muda. Os países vão exigir às autoridades americanas medidas que limitem o uso nos seus respectivos países. Não existe uma solução boa, o sistema FIAT é um castelo de cartas, qualquer carta que se mova, vai provocar um desmoronamento noutro local. As autoridades não poderão adiar mais o problema, terão que o resolver de vez, senão, qualquer dia será tarde demais. Se houver algum problema, vão colocar a responsabilidade no cripto e no Bitcoin. Mas a verdade, a culpa é inteiramente dos políticos, da sua incompetência em resolver os problemas a tempo. Será algo para acompanhar futuramente, mas só para 2026, talvez… É curioso, há uns anos pensava-se que o Bitcoin seria a maior ameaça ao sistema ao FIAT, mas afinal, a maior ameaça aos sistema FIAT é o próprio FIAT(_stablecoins_). A ironia do destino. Isto é como uma corrida, o Bitcoin é aquele atleta que corre ao seu ritmo, umas vezes mais rápido, outras vezes mais lento, mas nunca pára. O FIAT é o atleta que dá tudo desde da partida, corre sempre em velocidade máxima. Só que a vida e o sistema financeiro não é uma prova de 100 metros, mas sim uma maratona. # Europa 2025 será um ano desafiante para todos europeus, sobretudo devido à entrada em vigor da regulamentação (MiCA). Vão começar a sentir na pele a regulamentação, vão agravar-se os problemas com os _compliance_, problemas para comprovar a origem de fundos e outras burocracias. Vai ser lindo. O _Travel Route_ passa a ser obrigatório, os europeus serão obrigados a fazer o KYC nas transações. A _Travel Route_ é uma suposta lei para criar mais transparência, mas prática, é uma lei de controle, de monitorização e para limitar as liberdades individuais dos cidadãos. O MiCA também está a colocar problemas nas _stablecoins_ de Euro, a Tether para já preferiu ficar de fora da europa. O mais ridículo é que as novas regras obrigam os emissores a colocar 30% das reservas em bancos comerciais. Os burocratas europeus não compreendem que isto coloca em risco a estabilidade e a solvência dos próprios bancos, ficam propensos a corridas bancárias. O MiCA vai obrigar a todas as exchanges a estar registadas em solo europeu, ficando vulnerável ao temperamento dos burocratas. Ainda não vai ser em 2025, mas a UE vai impor políticas de controle de capitais, é inevitável, as exchanges serão obrigadas a usar em exclusividade _stablecoins_ de euro, as restantes _stablecoins_ serão deslistadas. Todas estas novas regras do MiCA, são extremamente restritas, não é para garantir mais segurança aos cidadãos europeus, mas sim para garantir mais controle sobre a população. A UE está cada vez mais perto da autocracia, do que da democracia. A minha única esperança no horizonte, é que o sucesso das políticas cripto nos EUA, vai obrigar a UE a recuar e a aligeirar as regras, a teoria dos jogos é implacável. Mas esse recuo, nunca acontecerá em 2025, vai ser um longo período conturbado. # Recessão Os mercados estão todos em máximos históricos, isto não é sustentável por muito tempo, suspeito que no final de 2025 vai acontecer alguma correção nos mercados. A queda só não será maior, porque os bancos centrais vão imprimir dinheiro, muito dinheiro, como se não houvesse amanhã. Vão voltar a resolver os problemas com a injeção de liquidez na economia, é empurrar os problemas com a barriga, em de os resolver. Outra vez o efeito Cantillon. Será um ano muito desafiante a nível político, onde o papel dos políticos será fundamental. A crise política na França e na Alemanha, coloca a UE órfã, sem um comandante ao leme do navio. 2025 estará condicionado pelas eleições na Alemanha, sobretudo no resultado do AfD, que podem colocar em causa a propriedade UE e o euro. Possivelmente, só o fim da guerra poderia minimizar a crise, algo que é muito pouco provável acontecer. Em Portugal, a economia parece que está mais ou menos equilibrada, mas começam a aparecer alguns sinais preocupantes. Os jogos de sorte e azar estão em máximos históricos, batendo o recorde de 2014, época da grande crise, não é um bom sinal, possivelmente já existe algum desespero no ar. A Alemanha é o motor da Europa, quanto espirra, Portugal constipa-se. Além do problema da Alemanha, a Espanha também está à beira de uma crise, são os países que mais influenciam a economia portuguesa. Se existir uma recessão mundial, terá um forte impacto no turismo, que é hoje em dia o principal motor de Portugal. # Brasil Brasil é algo para acompanhar em 2025, sobretudo a nível macro e a nível político. Existe uma possibilidade de uma profunda crise no Brasil, sobretudo na sua moeda. O banco central já anda a queimar as reservas para minimizar a desvalorização do Real.  Sem mudanças profundas nas políticas fiscais, as reservas vão se esgotar. As políticas de controle de capitais são um cenário plausível, será interesse de acompanhar, como o governo irá proceder perante a existência do Bitcoin e _stablecoins_. No Brasil existe um forte adoção, será um bom _case study_, certamente irá repetir-se em outros países num futuro próximo. Os próximos tempos não serão fáceis para os brasileiros, especialmente para os que não têm Bitcoin. # Blockchain Em 2025, possivelmente vamos ver os primeiros passos da BlackRock para criar a primeira bolsa de valores, exclusivamente em _blockchain_. Eu acredito que a BlackRock vai criar uma própria _blockchain_, toda controlada por si, onde estarão os RWAs, para fazer concorrência às tradicionais bolsas de valores. Será algo interessante de acompanhar. ----------- Estas são as minhas previsões, eu escrevi isto muito em cima do joelho, certamente esqueci-me de algumas coisas, se for importante acrescentarei nos comentários. A maioria das previsões só acontecerá após 2025, mas fica aqui a minha opinião. Isto é apenas a minha opinião, **Don’t Trust, Verify**!

@ 75869cfa:76819987

**GM, Nostriches!** The Nostr Review is a biweekly newsletter focused on nostr statistics, protocol updates, exciting programs, the long-form content ecosystem, and key events happening in the Nostr-verse. If you’re interested, join me in covering updates from the Nostr ecosystem! **Quick review:** In the past two weeks, Nostr statistics show over 240,000 daily trusted pubkey events, a 28% increase from the previous period, The daily peak reached 22201, the highest in the past two months.New user profiles with bios have reached around 40,000，profiles with contact lists are around 18000，both showing increases over 20%. More than 11 million events have been published, with posts leading in volume, totaling about 2.1 million. Total Zap activity reached over 19 million, marking a significant 70% increase. Additionally, 26 pull requests were submitted to the Nostr protocol, with 8 merged. A total of 42 Nostr projects were tracked, with 12 releasing product updates, and over 419 long-form articles were published, 33% focusing on Bitcoin and Nostr. During this period, 1 notable event took place, and 3 significant events are upcoming. **Nostr Statistics** --- Based on user activity, the total daily trusted pubkeys writing events exceeded 240,000, a 28% increase compared to the previous period (Oct 29-Nov 10). The daily peak reached 22201, the highest in the past two months, with a low of nearly 17682. In terms of new user numbers, profiles with bios are around 40000, up 21% over the past two weeks; profiles with contact lists are around 18697, up 22%. Public writing events exceeded 200,000,The daily peak reached 32480. Regarding event publishing, the total number of note events published has surpassed 11 million, marking a significant increase of approximately 28%. Posts remain the most dominant in volume, totaling about 2.1 million, far exceeding reposts (357,168) and reactions (560,243). For zap activity, the total zap amount has exceeded 19 million, showing a significant increase of over 70% compared to the previous period. In terms of relay usage, the top five relays by user count are: wss://bostr.bitcointxoko.com/,wss://feeds.nostr.band/,wss://realy.nostr.band/,wss://realy.lumina.rocks/,wss://unostr.site/ Data source: https://stats.nostr.band/ **NIPs** --- **[Break out chat and threads from nip 29](https://github.com/nostr-protocol/nips/pull/1591)** nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn is proposing that this is a variant of #1589 which attempts to reconcile NIP 29 and flotilla's rooms over chat and thread kinds. This requires no changes of NIP 29 clients, only flotilla will need to be modified,andmove kind 9 and 11 out of NIP 29. The choice of new event kinds was initially made to avoid conflicts with existing implementations. However, it would be beneficial to align the two approaches. For chat and threads, maintaining shallow reply hierarchies rather than arbitrary ones is a key consideration. Moving forward would depend on whether this stipulation is acceptable to the NIP 29 community. **[Relay chat](https://github.com/nostr-protocol/nips/pull/1589)** nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn is proposing an alternative to NIP 29 for several reasons. NIP 29 is overly prescriptive in several ways and encourages group admins to host their groups on a third-party relay. Moving group-like features to relays eliminates the need for separate specifications for each group. Additionally, group metadata is redundant because relays already have a NIP 11 information document and a public key with which they can publish additional information.Admins and moderators can be handled implicitly, out-of-band, or by querying feature support using LIMITS. This approach keeps the base specification small while allowing features like moderator lists to be added as optional extensions. Member lists are managed by the members themselves, enabling them to choose whether to publicly disclose their group membership. This approach facilitates web-of-trust-based community recommendations. **[Time-ordered event ids](https://github.com/nostr-protocol/nips/pull/1587)** nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z is proposing that there are a lot of performance benefits to having primary keys with temporal locality.when your database needs to check the uniqueness of IDs, only a small portion of the index needs to be hot (in memory). With the current “random identifiers”, the working set eventually becomes all of the data and your database will be page-faulting continuously. Sequential primary keys also make it easier for the database to place new records in order, minimizing the need to rearrange data or update index structures.This PR makes a simple, but breaking change, to the way we compute event ids. It was inspired by the improvements made by UUIDv7. **[NIP-37 - Transport method announcement](https://github.com/nostr-protocol/nips/pull/1585)** nostr:npub1hw6amg8p24ne08c9gdq8hhpqx0t0pwanpae9z25crn7m9uy7yarse465gr is proposing that Nostr decouples applications completely from the transportation layer, meaning services no longer have to be designed around a single transportation method, but can be accessible through a plethora of ways. This NIP is meant to act as a lookup system that tells a client which transportation methods can be used to access its services.There have been NIP proposals that touch the connection between pubkeys and addresses, example NIP-97 - Nostr Naming System, NIP-66 - Relay Discovery and Liveness Monitoring. NIP-97 is very close to solving the issue of this mapping.However, it attempts to also include human-readable naming into the solution. human-readable naming of pubkeys/services is inherently different from mapping a pubkey to an address where a user can access that pubkey's services, which may or may not map to a legacy domain name.NIP-66 covers discoverability from the client side and can be a very important tool to discern which services are worth connecting to. I think it can act as the feedback mechanism to the proposed event of this NIP. It can be used to build metrics for the various networks a pubkey announces it to be accessible. Things like rtt (round trip time) can also be different for each network and should be measured separately. **[nip46: simple public key login using kind:10046](https://github.com/nostr-protocol/nips/pull/1578)** nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 is proposing that This vastly simplifies the bunker:// flow while also making it easy for the user on every other front possibly -- and brings back NIP-05 login, but in a simpler, more generic way. **[Add optional arg to nostr.getPublicKey()](https://github.com/nostr-protocol/nips/pull/1599)** Lez is proposing that if login is optional for an application, nostr.getPublicKey({optional: true}) can be used to retrieve the pubkey if the user has already granted permission to the app. This allows the user to view the app’s landing page without being interrupted by a popup window. The user can still press the login button later, which calls nostr.getPublicKey() and prompts for permission. **[NIP-62: Collections](https://github.com/nostr-protocol/nips/pull/1600)** limina1 is defining a specification for organizing nostr events into collections - ordered, optionally-hierarchical structures like books, journals, or documentation. Currently, there's no standardized way to create versioned collections of content. The closest option is to use lists, but this extends that idea beyond a strictly linear hierarchy. Introducing two new event kinds: kind:30040 - Collection Index and kind:30041 - Collection Section. The Collection Index serves as a table of contents, providing metadata about the collection and listing events in display order. Meanwhile, the Collection Section contains the actual content and supports linking to other content using wikilinks, enabling seamless connectivity within the collection. **[Add r to kind 10009](https://github.com/nostr-protocol/nips/pull/1602)** nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn is proposing adding an "r" field to kind 10009, allowing users can advertise what relays/groups they are members of. Flotilla uses this to recommend relays. These of course should be considered non-canonical because the users publishing them may not actually have access to the relay specified. **[Add support for naming unmanaged groups](https://github.com/nostr-protocol/nips/pull/1603)** nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn is proposing Instead of allowing human-readable ids, it's probably better to just allow users to name groups. I opted for a petnames strategy here instead of recommending sending 9002 events or something. Clients can choose whatever heuristic they want to resolve conflicts. **[Add feature detection for unmanaged groups](https://github.com/nostr-protocol/nips/pull/1604)** nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn is proposing feature detection for unmanaged groups that has to exist on two levels.On the group level, so that clients can toggle the richer NIP 29 behavior on or off. Feature detection based on NIP 11's supported_nips field isn't sufficient, since a relay implementation might support NIP 29, but the actual relay may not.On the relay level, since clients need to be able to know whether users can post events to groups that don't yet exist, or whether they have to send a create-group event instead.The default (obviously) has to be that unmanaged groups are allowed, so unmanaged group support is opt-out. **[kind-scoped follow](https://github.com/nostr-protocol/nips/pull/1605)** nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft is proposing kind-scoped follow does NOT (necessarily) replace kind:3, it's a way to do a very simple follow of one or more kinds that might be of interest.This way we also start moving away from huge follow lists that can get wiped at a moment's notice and instead clients are responsible for computing the follow list and updating its local state.This also allows apps to show "followed" notifications without a central source. **[Build Your Own Adventure posts](https://github.com/nostr-protocol/nips/pull/1606)** nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z is defining kind:296 and kind:297 as text notes with options to navigate to the next text notes and continue reading. Kind 296 serves as the root story and 297 for the sections of that story.The idea is to replicate the dynamism of build your own adventure books, where each reader takes their own journey in the story.Story Section events contain an optional title tag and option tags for the next sections.Clients SHOULD render options in a way that users can select and move to that post. **Notable Projects** --- **[Primal 2.0](https://yakihonne.com/notes/nostr:nevent1qgsdv8emcke7k3qqaldwv956tstu40ejg663gdsaayuuujs6pknw7jsqyzmh8kf6at6je4eh2plp26pjg4y79d7mmjpy5zgaxl4thrmwkn2ts3289tm)** nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg Primal now offers a much more comprehensive view of Nostr, with the following additions: * New tab: READS * New tab: EXPLORE * Feed Marketplace * Advanced Search * launched Primal Premium, for $7/month, you can get a Primal Name and Nostr Tools for power users * enable plugging any feed into the sidebar **[Yakihonne](https://yakihonne.com/notes/nostr:nevent1qgszpxr0hql8whvk6xyv5hya7yxwd4snur4hu4mg5rctz2ehekkzrvcqyq0zhhc5pf4282h8culuavgjr8fyqf9d6t389ac2yjtuz9eer3wnysu8666)** nostr:npub1yzvxlwp7wawed5vgefwfmugvumtp8c8t0etk3g8sky4n0ndvyxesnxrf8q Mobile latest updates: * Adjust your home feed with what interests you the most. * Home suggestion box can be enabled and disabled. * Profile preview can be enabled and disabled. * Replies can be previewed and highlighted directly. * Articles, videos and curations can be quoted inside notes for more exposure. * Add the ability to link connected wallets to your profile for zaps receiving. * Thread view is enhanced and well adjusted. * Fix a variety of introduced bugs. * General improvements across the app. Web latest updates: * A fresh design overhaul for the article, video, and curation pages, enabling seamless browsing and enhanced interaction with content. * Connected threads! A refined notes thread makes following entire discussions more intuitive. * Users can now personalize their home feed by selecting their top interests. * Replies can now be previewed directly from the note card, without needing to open the full note. * Wallets can now be linked to your account directly from the wallet page. * Drafts for notes and replies are now saved, allowing easy edits later. * The suggestions box on the home page can now be hidden. * The on-hover user preview can now be disabled for quicker access to profiles. * Articles, videos and curations can now be quoted and shared as notes. * General improvements. * Bug fixes and optimizations. **[ZEUS Pay](https://yakihonne.com/notes/nostr:nevent1qgsrf5h4ya83jk8u6t9jgc76h6kalz3plp9vusjpm2ygqgalqhxgp9gqyrw6d974sgj6sf4m7x6zdv095y4ahenl59fv63rwde6hucr3ug2sg6sgvm8)** nostr:npub1xnf02f60r9v0e5kty33a404dm79zr7z2eepyrk5gsq3m7pwvsz2sazlpr5 - All payments will incur no fee for the receiver (previously 2.5-10% depending on amount) - The minimum amount receivable has been lowered to 1 satoshi (previously 10 satoshis) **[TestFlight](https://yakihonne.com/notes/nostr:nevent1qgsraldwhvwcjgltmxwfu7kw8dqef2692yhzheuurd7k3kfy8cxjdqgqyz54jkm9xtzqkxeh54txnvt5zfsn3u0kgrttsvq8zw2dv5y7glsmcm5plac)** nostr:npub18m76awca3y37hkvuneavuw6pjj4525fw90necxmadrvjg0sdy6qsngq955 TestFlight is a program designed for those who want to join the nostr:#damus roadmap, prioritizing improvements to video support and introducing several new features： * Improved video controls * Stability improvements to video support * New image share options on the full screen carousel * Hashtag suggestions * Multi image uploads * A video player that actually works * Share sheet action * Seamless scroll * Added Damus Share Feature * Fixed missing tab bar on navigation * Fixed some issues where profile QR code scanning would not work, and improved UX to make experience more robust **[Olas 0.1](https://yakihonne.com/notes/nostr:nevent1qgs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75sqyptnpmnmwakxmv7gh50arhfra553gs3erev6wykqppg22630et5xkv7d8l3)** nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft Olas is an Instagram-like client for iOS and Android，provides a feed of videos (like those on flare/highlighter/zap.stream), picture events (kind:20, a new kind that no client had implemented yet) and the classical short notes with images attached we are all used to.Some more features already available: * blossom uploads * NIP-22 replies * Reels (still quite buggy though) * Edit your preferred blossom servers * Edit your nutsack mint list * Image download optimization (to be gentle with mobile data plans) Additionally, there are some coming next, including NIP-55 (Amber) Logic,Fix NIP-46 (bunker) login,complete NIP-60 (nutsack) wallet,Add NIP-57/61 zaps + nutzaps,and more. **[Gossip 0.12.0](https://yakihonne.com/notes/nostr:nevent1qqs9t7adjjjmg63c23hmvacurn0wjw5xwsejrts586qt9akj9urraaqzyqukgu3galwlytuy5l8rd5g3kduvuheazkuyqy68s40qfvjv3e8qgqcyqqqqqqgcu55c9)** nostr:npub189j8y280mhezlp98ecmdzydn0r8970g4hpqpx3u9tcztynywfczqqr3tg8 This is a major release with the following major changes: * Bookmarks support (including private bookmarks) * Global feed and per-Relay feeds (with volatile storage, erased when you quit) * Friends-of-friends scores shown in avatar * Improved spam filtering script with more inputs to make decisions on Additionally, there are some minor changes, including updated emoji picker, reworked relay scoring, more efficient background tasks, faster database (less syncing),and more. **[Nostur v1.16.0](https://yakihonne.com/notes/nostr:nevent1qqs2lp33runu4lakajj6v05wqflnf543ckufrkv5vat7f4pz8l0ulnqzyzd7p0s0cpu4fq3nyvtpfe8palyl9zcdkwvqz8h7anc9letsuhwnxqcyqqqqqqgf3jfck)** nostr:npub1n0stur7q092gyverzc2wfc00e8egkrdnnqq3alhv7p072u89m5es5mk6h0 * Nostr Nests integration * Live video streams and chats * Relay Autopilot improvements * VPN detection toggle: only connect to additional relays if VPN is detected * Relay Connection stats improvements * Rewrite of feed loading. Faster & more efficient * Possible imposter label also added on new follower notification and quoted posts * Improved profile card rendering/animation * Improved quoted post and inline naddr1 rendering * Optimized profile gallery loading * Exclude reposts for new posts notifier * UI tweaks, more compact, less clutter * Full width images now go to screen edge * Reduced data usage for new follower notifications * Many many bug fixes and other optimizations **[Fountain Radio 1.1.8](https://yakihonne.com/notes/nostr:nevent1qgsx2wyjt6lmvc05rrvv05r5hm3w3t7h0pcpmkyswrpd4ymd2u09tscqyrfwgemapeyhsalry9p0k82zwfgqmvspqm24g2jje5sm508xkvz35ualhra)** nostr:npub1v5ufyh4lkeslgxxcclg8f0hzazhaw7rsrhvfquxzm2fk64c72hps45n0v5 * Add and upvote tracks in the queue * Support the artist currently playing * Post in the live chat * Save tracks to your library * Listen to Fountain Radio on other apps * Artist takeovers **[Plebeian Progress Update](https://yakihonne.com/notes/nostr:nevent1qqsxc9lpjpl24ycc8ajvkttylahx2hp49jrpmfejd4gxvsr4l5qtrhczyr05wm90fzyt7hvec6n3p6n2a9pa8e5n62wdcawyalculd35swdmsqcyqqqqqqgdksqga)** nostr:npub1market6g3zl4mxwx5ugw56hfg0f7dy7jnnw8t380788mvdyrnwuqgep7hd There are some enhancements and new features: * dialog manager * hide non-working parts of the ui * publish events, we are just signing * Moderation Tools for Admins and Editors * introduce 'editor' role Additionally, a major bug causing errors when creating stalls with more than one shipping method has been fixed, and the “v4v” text has been updated to Community Contribution. **[Zapstore 0.16](https://yakihonne.com/notes/nostr:nevent1qgs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgqyqpkulq4uthl9n444p6l4dhmv5rgln8f9pw58y0tuv2ys5xa8rkm7ef4a2d)** nostr:npub10r8xl2njyepcw2zwv3a6dyufj4e4ajx86hz6v4ehu4gnpupxxp7stjt2p8 Zapstore 0.1.6 released now.Some performance issues addressed, reverted installer, fixed themed icon and toasts, and more. **[0xchat 1.4.1](https://yakihonne.com/notes/nostr:nevent1qqszxnnaeehzqvmjav6t5hmc2djlepcc9s7p4tv2qym4qvplk5ju98szyp0v559qftawle2kt8ahfqgtgfj5ugngcxkv5mjnsqdesckmwj5r5qcyqqqqqqgyw6fts)** nostr:npub1tm99pgz2lth724jeld6gzz6zv48zy6xp4n9xu5uqrwvx9km54qaqkkxn72 * Optimized video player UI with support for landscape mode * Added audio configuration in settings * Enabled copying of ecash tokens from ecash messages * Support for media deletion Additionally, some bug fixes,such as the occasional gray screen when sending e-cash，gray screen issue in Hungarian language，“mark all as read” function not working，and more. **[DEG Mods update](https://yakihonne.com/notes/nostr:nevent1qgs0f0clkkagh6pe7ux8xvtn8ccf77qgy2e3ra37q8uaez4mks5034gqypuhql0zcvgtxjt0xv33u6mte60y2d0fx3l06tz7xdjcp8fucxcl742lca9)** nostr:npub17jl3ldd6305rnacvwvchx03snauqsg4nz8mruq0emj9thdpglr2sst825x The updated version introduces a new Web of Trust system and a Blog system, with relevant pages and sections now implemented and updated.And there are some changes: * (technical) nPub user addresses now lead to a user's profile if added through the URL, which would be auto-converted to an nProfile type address. * Reaction (heart/poop) numbers now show a loading indication with 3 dot animation, and you'd only be able to react once loading is finished. * There's now a spinning loader animation for the comments of a post to make sure, as a user, if there are comments or not * There's now a comment loader button that you can press to load newly discovered comments for a mod or blog post * Minor design adjustments for blog posts Additionally, fixed the ordering of the latest mods, ensured profile links in comments (from clicking the name or user address) lead to the correct profile page now, and more. **Long-Form Content Eco** --- In the past two weeks, more than 419 long-form articles have been published, including over 100 articles on Bitcoin and more than 30 related to Nostr, accounting for 33% of the total content. These articles about Nostr mainly explore the protocol's development, practical applications, and its role in driving the decentralized social media ecosystem. They cover updates on tools and features like TestFlight and Knox Beta, highlighting innovations such as healthcare micro-apps, privacy enhancements, and NFC integration. Community-driven initiatives, like self-hosted Zap cooking, board member introductions, and the power of collaboration, reflect the growth of the ecosystem. Additionally, the articles discuss challenges such as key management and content moderation, as well as creative contributions like Thanksgiving use cases and cultural content. The Bitcoin articles discuss the development, adoption, and impact of Bitcoin on the global financial landscape. They cover Bitcoin's market performance, technological advancements, and its role in the broader cryptocurrency ecosystem. The articles also explore Bitcoin's rise, its increasing market cap, and predictions for its future price movements. In addition, they focus on Bitcoin's use in various applications, the challenges faced by Bitcoin mining, and its evolving role in decentralized finance, highlighting Bitcoin's potential to address global issues, from the limitations of fiat currencies to the challenges posed by central banking systems and surveillance. Overall, the articles reflect Bitcoin's growing influence and its potential to drive future technological and financial revolutions. Thankyou,nostr:npub1qe3e5wrvnsgpggtkytxteaqfprz0rgxr8c3l34kk3a9t7e2l3acslezefe，nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn，nostr:npub1r0d8u8mnj6769500nypnm28a9hpk9qg8jr0ehe30tygr3wuhcnvs4rfsft，nostr:npub1t0an3j7nk007fuc7r9zpm89g66dksuc245jsm4xy2674w2uen2nsceqmmp，nostr:npub1klshrs20h2nxf73vrshfjpmmnrq7m8tz7l77sjapwkyaveu22agq5pvxnv，nostr:npub1f7ptem2ztp9x4n7w62n90ddv40z0jrt4490d8lug3uasfwyjsccqkknerm，nostr:npub176zu0wg5l8436nu66qaxwfekx0zz58l66s72dhcu0ur0lvd7q5lq9f66qx，nostr:npub1kun5628raxpm7usdkj62z2337hr77f3ryrg9cf0vjpyf4jvk9r9smv3lhe， and others,for your work. Enriching Nostr’s long-form content ecosystem is crucial. **Nostriches Global Meet Ups** --- Recently, several Nostr events have been hosted in different countries. * **[Adopting Bitcoin 2024](https://sv24.adoptingbitcoin.org/)** took place successfully from November 15 to 16, 2024, in the southern region of El Salvador. The event attracted over a hundred Bitcoin experts, advocates, and innovators from around the world, including nostr:npub14d5399mthprnnur9g2wq877hg0htr5afrdad5dryryeftct885fqtcpuyp, nostr:npub1dtgg8yk3h23ldlm6jsy79tz723p4sun9mz62tqwxqe7c363szkzqm8up6m, nostr:npub16dhgpql60vmd4mnydjut87vla23a38j689jssaqlqqlzrtqtd0kqex0nkq, nostr:npub1lelkh3hhxw9hdwlcpk6q9t0xt9f7yze0y0nxazvzqjmre3p98x3sthkvyz，and more. Discussions focused on Bitcoin’s potential to reshape global finance, culture, and social structures, with key themes around decentralization, Bitcoin’s challenge to sovereignty, and its impact on education and family life. nostr:npub1ad0ptuzte83alpkpqqctvewlaqj5zq23c83m82xw8apg4t6zlyns6xng2c Here are the upcoming Nostr events in November that you might want to check out. * **[Btrust Developer Day](https://x.com/btrustteam/status/1838630559184228490)** will take place on Sunday, December 8, 2024, in Nairobi, Kenya, as part of the Africa Bitcoin Conference (ABC 2024). This event aims to provide a platform for African developers to explore Bitcoin technology, learn from industry leaders, and collaborate on projects. The event will feature lightning talks, panel discussions, hands-on workshops, project showcases, and networking opportunities, making it ideal for Bitcoin developers, open-source developers, technologists, and Bitcoin enthusiasts. * **[The Africa Bitcoin Conference 2024](https://afrobitcoin.org/speakers/)** will take place from December 9 to 11, 2024, in Nairobi, Kenya, featuring key programs such as Btrust Developer Day, TBD Hackathon, ABC Social Impact Award, Afro Bitcoin Fellowship, and Africa Bitcoin Day. The event will host nearly 70 distinguished speakers, including nostr:npub1ju2sw9unanr94p5wama3ydv90hcke34wcnmnxedummspaayz55qswlya32, nostr:npub16hssgmdhw9e9j6z8na45lzz4grdsfjqlp5hf8dtcqnp0glseeu3seecguf, nostr:npub1m7uxdt50d2jw35q79zlszlsvy79t7dpdxptz6rfsrsamra7l8ttsq752yl, nostr:npub1gaxapm9t9damh6q2lpc04ptcyeh0ysfdfzzs997agu3ae80ftrns7t985l, and more,focusing on topics such as Bitcoin adoption, regulation, innovation, and security. This conference offers attendees valuable opportunities for in-depth discussions and knowledge sharing. * **[The Asia Bitcoin Tech Unconference](https://yakihonne.com/notes/nostr:nevent1qgszpxr0hql8whvk6xyv5hya7yxwd4snur4hu4mg5rctz2ehekkzrvcqyz3dkv6yzsf8h70mtjnvta365maf0j8edy5lgapawra5x884rj6cvjkulg4)** is set to take place from February 8 to 10, 2025, in Chiang Mai, Thailand. Organized as a workshop-style event, it will feature a diverse lineup of speakers, including nostr:npub1zk6u7mxlflguqteghn8q7xtu47hyerruv6379c36l8lxzzr4x90q0gl6ef, nostr:npub1htnhsay5dmq3r72tukdw72pduzfdcja0yylcajuvnc2uklkhxp8qnz3qac, nostr:npub1ejxswthae3nkljavznmv66p9ahp4wmj4adux525htmsrff4qym9sz2t3tv, nostr:npub1xtwy7fvu8f7wdtgnpm68wyrf6uxshf49tn5kp7kyusu6872amn8qh06rus, nostr:npub147whqsr5vsj86x0ays70r0hgreklre3ey97uvcmxhum65skst56s30selt，and others. The conference will focus on key topics such as scalability, mining, payments, and infrastructure, while also encouraging participants to share unfinished projects or technical challenges. Through hackathons and hands-on discussions, the event aims to foster collaboration and innovation. Highlights include technical talks, pitch competitions, Bitcoin product showcases, and creative and wellness activities such as Thai massages, ice baths, and arts and crafts workshops.nostr:npub1yrnuj56rnen08zp2h9h7p74ghgjx6ma39spmpj6w9hzxywutevsst7k5cx Additionally, We warmly invite event organizers who have held recent activities to reach out to us so we can work together to promote the prosperity and development of the Nostr ecosystem. Thanks for reading! If there’s anything I missed, feel free to reach out and help improve the completeness and accuracy of my coverage.

@ a849beb6:b327e6d2

<img src="https://blossom.primal.net/e306357a7e53c4e40458cf6fa5625917dc8deaa4d1012823caa5a0eefb39e53c.jpg"> \ \ It was another historic week for both bitcoin and the Ten31 portfolio, as the world’s oldest, largest, most battle-tested cryptocurrency climbed to new all-time highs each day to close out the week just shy of the $100,000 mark. Along the way, bitcoin continued to accumulate institutional and regulatory wins, including the much-anticipated approval and launch of spot bitcoin ETF options and the appointment of several additional pro-bitcoin Presidential cabinet officials. The timing for this momentum was poetic, as this week marked the second anniversary of the pico-bottom of the 2022 bear market, a level that bitcoin has now hurdled to the tune of more than 6x despite the litany of bitcoin obituaries published at the time. The entirety of 2024 and especially the past month have further cemented our view that bitcoin is rapidly gaining a sense of legitimacy among institutions, fiduciaries, and governments, and we remain optimistic that this trend is set to accelerate even more into 2025. Several Ten31 portfolio companies made exciting announcements this week that should serve to further entrench bitcoin’s institutional adoption. AnchorWatch, a first of its kind bitcoin insurance provider offering 1:1 coverage with its innovative use of bitcoin’s native properties, announced it has been designated a Lloyd’s of London Coverholder, giving the company unique, blue-chip status as it begins to write bitcoin insurance policies of up to $100 million per policy starting next month. Meanwhile, Battery Finance Founder and CEO Andrew Hohns appeared on CNBC to delve into the launch of Battery’s pioneering private credit strategy which fuses bitcoin and conventional tangible assets in a dual-collateralized structure that offers a compelling risk/return profile to both lenders and borrowers. Both companies are clearing a path for substantially greater bitcoin adoption in massive, untapped pools of capital, and Ten31 is proud to have served as lead investor for AnchorWatch’s Seed round and as exclusive capital partner for Battery. As the world’s largest investor focused entirely on bitcoin, Ten31 has deployed nearly $150 million across two funds into more than 30 of the most promising and innovative companies in the ecosystem like AnchorWatch and Battery, and we expect 2025 to be the best year yet for both bitcoin and our portfolio. Ten31 will hold a first close for its third fund at the end of this year, and investors in that close will benefit from attractive incentives and a strong initial portfolio. Visit ten31.vc/funds to learn more and get in touch to discuss participating.\ \ **Portfolio Company Spotlight**  [Primal](http://primal.net/) is a first of its kind application for the Nostr protocol that combines a client, caching service, analytics tools, and more to address several unmet needs in the nascent Nostr ecosystem. Through the combination of its sleek client application and its caching service (built on a completely open source stack), Primal seeks to offer an end-user experience as smooth and easy as that of legacy social media platforms like Twitter and eventually many other applications, unlocking the vast potential of Nostr for the next billion people. Primal also offers an integrated wallet (powered by [Strike BLACK](https://x.com/Strike/status/1755335823023558819)) that substantially reduces onboarding and UX frictions for both Nostr and the lightning network while highlighting bitcoin’s unique power as internet-native, open-source money.  ### **Selected Portfolio News** AnchorWatch announced it has achieved Llody’s Coverholder status, allowing the company to provide unique 1:1 bitcoin insurance offerings starting in [December](https://x.com/AnchorWatch/status/1858622945763131577).\ \ Battery Finance Founder and CEO Andrew Hohns appeared on CNBC to delve into the company’s unique bitcoin-backed [private credit strategy](https://www.youtube.com/watch?v=26bOawTzT5U). Primal launched version 2.0, a landmark update that adds a feed marketplace, robust advanced search capabilities, premium-tier offerings, and many [more new features](https://primal.net/e/note1kaeajwh275kdwd6s0c2ksvj9f83t0k7usf9qj8fha2ac7m456juqpac43m). Debifi launched its new iOS app for Apple users seeking non-custodial [bitcoin-collateralized loans](https://x.com/debificom/status/1858897785044500642). ### **Media** Strike Founder and CEO Jack Mallers [joined Bloomberg TV](https://www.youtube.com/watch?v=i4z-2v_0H1k) to discuss the strong volumes the company has seen over the past year and the potential for a US bitcoin strategic reserve.  Primal Founder and CEO Miljan Braticevic [joined](https://www.youtube.com/watch?v=kqR_IQfKic8) The Bitcoin Podcast to discuss the rollout of Primal 2.0 and the future of Nostr.  Ten31 Managing Partner Marty Bent [appeared on](https://www.youtube.com/watch?v=_WwZDEtVxOE&t=1556s) BlazeTV to discuss recent changes in the regulatory environment for bitcoin.  Zaprite published a customer [testimonial video](https://x.com/ZapriteApp/status/1859357150809587928) highlighting the popularity of its offerings across the bitcoin ecosystem.  ### **Market Updates** Continuing its recent momentum, bitcoin reached another new all-time high this week, clocking in just below $100,000 on Friday. Bitcoin has now reached a market cap of [nearly $2 trillion](https://companiesmarketcap.com/assets-by-market-cap/), putting it within 3% of the market caps of Amazon and Google.  After receiving SEC and CFTC approval over the past month, long-awaited options on spot bitcoin ETFs were fully [approved](https://finance.yahoo.com/news/bitcoin-etf-options-set-hit-082230483.html) and launched this week. These options should help further expand bitcoin’s institutional [liquidity profile](https://x.com/kellyjgreer/status/1824168136637288912), with potentially significant [implications](https://x.com/dgt10011/status/1837278352823972147) for price action over time. The new derivatives showed strong performance out of the gate, with volumes on options for BlackRock’s IBIT reaching [nearly $2 billion](https://www.coindesk.com/markets/2024/11/20/bitcoin-etf-options-introduction-marks-milestone-despite-position-limits/) on just the first day of trading despite [surprisingly tight](https://x.com/dgt10011/status/1858729192105414837) position limits for the vehicles.  Meanwhile, the underlying spot bitcoin ETF complex had yet another banner week, pulling in [$3.4 billion](https://farside.co.uk/btc/) in net inflows.  New reports [suggested](https://archive.is/LMr4o) President-elect Donald Trump’s social media company is in advanced talks to acquire crypto trading platform Bakkt, potentially the latest indication of the incoming administration’s stance toward the broader “crypto” ecosystem.  On the macro front, US housing starts [declined M/M again](https://finance.yahoo.com/news/us-single-family-housing-starts-134759234.html) in October on persistently high mortgage rates and weather impacts. The metric remains well below pre-COVID levels.  Pockets of the US commercial real estate market remain challenged, as the CEO of large Florida developer Related indicated that [developers need further rate cuts](https://www.bloomberg.com/news/articles/2024-11-19/miami-developer-says-real-estate-market-needs-rate-cuts-badly) “badly” to maintain project viability.  US Manufacturing PMI [increased slightly](https://www.fxstreet.com/news/sp-global-pmis-set-to-signal-us-economy-continued-to-expand-in-november-202411220900) M/M, but has now been in contraction territory (&lt;50) for well over two years. The latest iteration of the University of Michigan’s popular consumer sentiment survey [ticked up](https://archive.is/fY5j6) following this month’s election results, though so did five-year inflation expectations, which now sit comfortably north of 3%.  ### **Regulatory Update** After weeks of speculation, the incoming Trump administration appointed hedge fund manager [Scott Bessent](https://www.cnbc.com/amp/2024/11/22/donald-trump-chooses-hedge-fund-executive-scott-bessent-for-treasury-secretary.html) to head up the US Treasury. Like many of Trump’s cabinet selections so far, Bessent has been a [public advocate](https://x.com/EleanorTerrett/status/1856204133901963512) for bitcoin.  Trump also [appointed](https://www.axios.com/2024/11/19/trump-commerce-secretary-howard-lutnick) Cantor Fitzgerald CEO Howard Lutnick – another outspoken [bitcoin bull](https://www.coindesk.com/policy/2024/09/04/tradfi-companies-want-to-transact-in-bitcoin-says-cantor-fitzgerald-ceo/) – as Secretary of the Commerce Department.  Meanwhile, the Trump team is reportedly considering creating a new [“crypto czar”](https://archive.is/jPQHF) role to sit within the administration. While it’s unclear at this point what that role would entail, one report indicated that the administration’s broader “crypto council” is expected to move forward with plans for a [strategic bitcoin reserve](https://archive.is/ZtiOk). Various government lawyers suggested this week that the Trump administration is likely to be [less aggressive](https://archive.is/Uggnn) in seeking adversarial enforcement actions against bitcoin and “crypto” in general, as regulatory bodies appear poised to shift resources and focus elsewhere.  Other updates from the regulatory apparatus were also directionally positive for bitcoin, most notably FDIC Chairman Martin Gruenberg’s confirmation that he [plans to resign](https://www.politico.com/news/2024/11/19/fdics-gruenberg-says-he-will-resign-jan-19-00190373) from his post at the end of President Biden’s term.  Many critics have alleged Gruenberg was an architect of [“Operation Chokepoint 2.0,”](https://x.com/GOPMajorityWhip/status/1858927571666096628) which has created banking headwinds for bitcoin companies over the past several years, so a change of leadership at the department is likely yet another positive for the space. SEC Chairman Gary Gensler also officially announced he plans to resign at the start of the new administration. Gensler has been the target of much ire from the broader “crypto” space, though we expect many projects outside bitcoin may continue to struggle with questions around the [Howey Test](https://www.investopedia.com/terms/h/howey-test.asp). Overseas, a Chinese court ruled that it is [not illegal](https://www.benzinga.com/24/11/42103633/chinese-court-affirms-cryptocurrency-ownership-as-legal-as-bitcoin-breaks-97k) for individuals to hold cryptocurrency, even though the country is still ostensibly [enforcing a ban](https://www.bbc.com/news/technology-58678907) on crypto transactions.  ### **Noteworthy** The incoming CEO of Charles Schwab – which administers over $9 trillion in client assets – [suggested](https://x.com/matthew_sigel/status/1859700668887597331) the platform is preparing to “get into” spot bitcoin offerings and that he “feels silly” for having waited this long. As this attitude becomes more common among traditional finance players, we continue to believe that the number of acquirers coming to market for bitcoin infrastructure capabilities will far outstrip the number of available high quality assets.  BlackRock’s 2025 Thematic Outlook notes a [“renewed sense of optimism”](https://www.ishares.com/us/insights/2025-thematic-outlook#rate-cuts) on bitcoin among the asset manager’s client base due to macro tailwinds and the improving regulatory environment. Elsewhere, BlackRock’s head of digital assets [indicated](https://www.youtube.com/watch?v=TE7cAw7oIeA) the firm does not view bitcoin as a “risk-on” asset.  MicroStrategy, which was a sub-$1 billion market cap company less than five years ago, briefly breached a [$100 billion equity value](https://finance.yahoo.com/news/microstrategy-breaks-top-100-u-191842879.html) this week as it continues to aggressively acquire bitcoin. The company now holds nearly 350,000 bitcoin on its balance sheet.  Notably, Allianz SE, Germany’s largest insurer, [spoke for 25%](https://bitbo.io/news/allianz-buys-microstrategy-notes/) of MicroStrategy’s latest $3 billion convertible note offering this week, suggesting [growing appetite](https://x.com/Rob1Ham/status/1860053859181199649) for bitcoin proxy exposure among more restricted pools of capital.  The [ongoing meltdown](https://www.cnbc.com/2024/11/22/synapse-bankruptcy-thousands-of-americans-see-their-savings-vanish.html) of fintech middleware provider Synapse has left tens of thousands of customers with nearly 100% deposit haircuts as hundreds of millions in funds remain missing, the latest unfortunate case study in the fragility of much of the US’s legacy banking stack.  ### **Travel** - [BitcoinMENA](https://bitcoin2024.b.tc/mena), Dec 9-10 - [Nashville BitDevs](https://www.meetup.com/bitcoinpark/events/302533726/?eventOrigin=group_upcoming_events), Dec 10 - [Austin BitDevs](https://www.meetup.com/austin-bitcoin-developers/events/303476169/?eventOrigin=group_upcoming_events), Dec 19 - [Nashville Energy and Mining Summit](https://www.meetup.com/bitcoinpark/events/304092624/?eventOrigin=group_events_list), Jan 30

@ 41e6f20b:06049e45

Let me tell you a beautiful story. Last night, during the speakers' dinner at Monerotopia, the waitress was collecting tiny tips in Mexican pesos. I asked her, "Do you really want to earn tips seriously?" I then showed her how to set up a Cake Wallet, and she started collecting tips in Monero, reaching 0.9 XMR. Of course, she wanted to cash out to fiat immediately, but it solved a real problem for her: making more money. That amount was something she would never have earned in a single workday. We kept talking, and I promised to give her Zoom workshops. What can I say? I love people, and that's why I'm a natural orange-piller.

@ fd208ee8:0fd927c1

## You have no idea I regularly read comments from people, on here, wondering how it's possible to marry -- or even simply be friends! -- with someone who doesn't agree with you on politics. I see this sentiment expressed quite often, usually in the context of Bitcoin, or whatever _pig is currently being chased through the village_, as they say around here.  It seems rather sensible, but I don't think it's as hard, as people make it out to be. Further, I think it's a dangerous precondition to set, for your interpersonal relationships, because the political field is constantly in flux. If you determine who you will love, by their opinions, do you stop loving them if their opinions change, or if the opinions they have become irrelevant and a new set of opinions are needed -- and their new ones don't match your new ones? We could see this happen to relationships en masse, during the Covid Era, and I think it happens every day, in a slow grind toward the disintegration of interpersonal discourse. I suspect many people do stop loving, at that point, as they never really loved the other person for their own sake, they loved the other person because they thought the other person was exactly like they are. But no two people are alike, and the longer you are in a relationship with someone else, the more the initial giddiness wears off and the trials and tribulations add up, the more you notice how very different you actually are. This is the point, where best friends and romantic couples say, _We just grew apart._ But you were always apart. You were always two different people. You just didn't notice, until now.  I've also always been surprised at how many same-party relationships disintegrate because of some disagreement over some particular detail of some particular topic, that they generally agree on. To me, it seems like an irrelevant side-topic, but _they can't stand to be with this person_... and they stomp off. So, I tend to think that it's less that opinions need to align to each other, but rather that opinions need to align in accordance with the level of interpersonal tolerance they can bring into the relationship. ## I was raised by relaxed revolutionaries Maybe I see things this way because my parents come from two diverging political, cultural, national, and ethnic backgrounds, and are prone to disagreeing about a lot of "important" (to people outside their marriage) things, but still have one of the healthiest, most-fruitful, and most long-running marriages of anyone I know, from that generation. My parents, you see, aren't united by their opinions. They're united by their relationship, which is something _outside_ of opinions. Beyond opinions. Relationships are what turn two different people into one, cohesive unit, so that they slowly grow together. Eventually, even their faces merge, and their biological clocks tick to the same rhythm. They eventually become one entity that contains differing opinions about the same topics. It's like magic, but it's the result of a mindset, not a worldview. Or, as I like to quip: > The best way to stay married, is to not get divorced.  My parents simply determined early on, that they would stay together, and whenever they would find that they disagreed on something that _didn't directly pertain to their day-to-day existence with each other_ they would just agree-to-disagree about that, or roll their eyes, and move on. You do you. Live and let live. My parents have some of the most strongly held personal opinions of any people I've ever met, but they're also incredibly tolerant and can get along with nearly anyone, so their friends are a confusing hodgepodge of _people we liked and found interesting enough to keep around_. Which makes their house parties really fun, and highly unusual, in this day and age of mutual-damnation across the aisle.  The things that did affect them, directly, like which school the children should attend or which country they should live in, etc. were things they'd sit down and discuss, and somehow one opinion would emerge, and they'd again... move on. And that's how my husband and I also live our lives, and it's been working surprisingly well. No topics are off-limits to discussion (so long as you don't drone on for too long), nobody has to give up deeply held beliefs, or stop agitating for the political decisions they prefer. You see, we didn't like that the other always had the same opinion. We liked that the other always held their opinions strongly. That they were passionate about their opinions. That they were willing to voice their opinions; sacrifice to promote their opinions. And that they didn't let anyone browbeat or cow them, for their opinions, not even their best friends or their spouse. But that they were open to listening to the other side, and trying to wrap their mind around the possibility that they _might just be wrong about something_.  We married each other because we knew: this person really cares, this person has thought this through, and they're in it, to win it. What "it" is, is mostly irrelevant, so long as it doesn't entail torturing small animals in the basement, or raising the children on a diet of Mountain Dew and porn, or something. Live and let live. At least, it's never boring. At least, there's always something to ~~argue~~ talk about. At least, we never think... we've just grown apart.

@ 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 this can't be Nostr. 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. 2. **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 anything about music. 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.

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

@ 0176967e:1e6f471e

Objavte, ako avatari a pseudonymné identity ovplyvňujú riadenie kryptokomunít a decentralizovaných organizácií (DAOs). V tejto prednáške sa zameriame na praktické fungovanie decentralizovaného rozhodovania, vytváranie a správu avatarových profilov, a ich rolu v online reputačných systémoch. Naučíte sa, ako si vytvoriť efektívny pseudonymný profil, zapojiť sa do rôznych krypto projektov a využiť svoje aktivity na zarábanie kryptomien. Preskúmame aj príklady úspešných projektov a stratégie, ktoré vám pomôžu zorientovať sa a uspieť v dynamickom svete decentralizovaných komunít.

@ 0176967e:1e6f471e

Jan Kolčák pochádza zo stredného Slovenska a vystupuje pod umeleckým menom Deepologic. Hudbe sa venuje už viac než 10 rokov. Začínal ako DJ, ktorý s obľubou mixoval klubovú hudbu v štýloch deep-tech a afrohouse. Stále ho ťahalo tvoriť vlastnú hudbu, a preto sa začal vzdelávať v oblasti tvorby elektronickej hudby. Nakoniec vydal svoje prvé EP s názvom "Rezonancie". Učenie je pre neho celoživotný proces, a preto sa neustále zdokonaľuje v oblasti zvuku a kompozície, aby jeho skladby boli kvalitné na posluch aj v klube. V roku 2023 si založil vlastnú značku EarsDeep Records, kde dáva príležitosť začínajúcim producentom. Jeho značku podporujú aj etablované mená slovenskej alternatívnej elektronickej scény. Jeho prioritou je sloboda a neškatulkovanie. Ako sa hovorí v jednej klasickej deephouseovej skladbe: "We are all equal in the house of deep." So slobodou ide ruka v ruke aj láska k novým technológiám, Bitcoinu a schopnosť udržať si v digitálnom svete prehľad, odstup a anonymitu. V súčasnosti ďalej produkuje vlastnú hudbu, venuje sa DJingu a vedie podcast, kde zverejňuje svoje mixované sety. Na Lunarpunk festivale bude hrať DJ set tvorený vlastnou produkciou, ale aj skladby, ktoré sú blízke jeho srdcu. [Podcast](https://fountain.fm/show/eYFu6V2SUlN4vC5qBKFk) [Bandcamp](https://earsdeep.bandcamp.com/) [Punk Nostr website](https://earsdeep-records.npub.pro/) alebo nprofile1qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qy88wumn8ghj7mn0wvhxcmmv9uq3xamnwvaz7tmsw4e8qmr9wpskwtn9wvhsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qyg8wumn8ghj7mn0wd68ytnddakj7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qpqguvns4ld8k2f3sugel055w7eq8zeewq7mp6w2stpnt6j75z60z3swy7h05

@ 0176967e:1e6f471e

Workshop je zameraný pre všetkých, ktorí sa potýkajú s vysvetľovaním Bitcoinu svojej rodine, kamarátom, partnerom alebo kolegom. Pri námietkach z druhej strany väčšinou ideme do protiútoku a snažíme sa vytiahnuť tie najlepšie argumenty. Na tomto workshope vás naučím nový prístup k zvládaniu námietok a vyskúšate si ho aj v praxi. Know-how je aplikovateľné nie len na komunikáciu Bitcoinu ale aj pre zlepšenie vzťahov, pri výchove detí a celkovo pre lepší osobný život.

@ 0176967e:1e6f471e

Ak ste v Bitcoine už nejaký ten rok, možno máte pocit, že už všetkému rozumiete a že vás nič neprekvapí. Viete čo je to peňaženka, čo je to seed a čo adresa, možno dokonca aj čo je to sha256. Ste si istí? Táto prednáška sa vám to pokúsi vyvrátiť. 🙂

@ 0176967e:1e6f471e

Bojovať s rakovinou metabolickou metódou znamená použiť metabolizmus tela proti rakovine. Riadenie cukru a ketónov v krvi stravou a pohybom, časovanie rôznych typov cvičení, včasná kombinácia klasickej onko-liečby a hladovania. Ktoré vitamíny a suplementy prijímam a ktorým sa napríklad vyhýbam dajúc na rady mojej dietologičky z USA Miriam (ktorá sa špecializuje na rakovinu). Hovori sa, že čo nemeriame, neriadime ... Ja som meral, veľa a dlho ... aj grafy budú ... aj sranda bude, hádam ... 😉

@ 0176967e:1e6f471e

Predikčné trhy predstavujú praktický spôsob, ako môžeme nahliadnuť do budúcnosti bez nutnosti spoliehať sa na tradičné, často nepresné metódy, ako je veštenie z kávových zrniek. V prezentácii sa ponoríme do histórie a vývoja predikčných trhov, a popíšeme aký vplyv mali a majú na dostupnosť a kvalitu informácií pre širokú verejnosť, a ako menia trh s týmito informáciami. Pozrieme sa aj na to, ako tieto trhy umožňujú obyčajným ľuďom prístup k spoľahlivým predpovediam a ako môžu prispieť k lepšiemu rozhodovaniu v rôznych oblastiach života.

@ 0176967e:1e6f471e

AI hype vnímame asi všetci okolo nás — už takmer každá appka ponúka nejakú “AI fíčuru”, AI startupy raisujú stovky miliónov a Európa ako obvykle pracuje na regulovaní a našej ochrane pred nebezpečím umelej inteligencie. Pomaly sa ale ukazuje “ovocie” spojenia umelej inteligencie a človeka, kedy mnohí ľudia reportujú signifikantné zvýšenie produktivity v práci ako aj kreatívnych aktivitách (aj napriek tomu, že mnohí hardcore kreatívci by každého pri spomenutí skratky “AI” najradšej upálili). V prvej polovici prednášky sa pozrieme na to, akými rôznymi spôsobmi nám vie byť AI nápomocná, či už v práci alebo osobnom živote. Umelé neuróny nám už vyskakujú pomaly aj z ovsených vločiek, no to ako sa k nám dostávajú sa veľmi líši. Hlavne v tom, či ich poskytujú firmy v zatvorených alebo open-source modeloch. V druhej polovici prednášky sa pozrieme na boom okolo otvorených AI modelov a ako ich vieme využiť.

@ 0176967e:1e6f471e

Čo vznikne keď spojíš hru SNAKE zo starej Nokie 3310 a Bitcoin? - hra [Chain Duel](https://www.youtube.com/watch?v=5hCI2MzxOzE)! Jedna z najlepších implementácií funkcionality Lightning Networku a gamingu vo svete Bitcoinu. Vyskúšať si ju môžete s kamošmi [na tomto odkaze](https://game.chainduel.net/). Na stránke nájdeš aj základné pravidlá hry avšak odporúčame pravidlá pochopiť [aj priamo hraním](https://game.chainduel.net/gamemenu) Chain Duel si získava hromady fanúšikov po bitcoinových konferenciách po celom svete a práve na Lunarpunk festival ho prinesieme tiež. Multiplayer 1v1 hra, kde nejde o náhodu, ale skill, vás dostane. Poďte si zmerať sily s ďalšími bitcoinermi a vyhrať okrem samotných satoshi rôzne iné ceny. Príďte sa zúčastniť prvého oficiálneho Chain Duel turnaja na Slovensku! Pre účasť na turnaji je [potrebná registrácia dopredu](https://docs.google.com/forms/d/e/1FAIpQLScq96a-zM2i9FCkd3W3haNVcdKFTbPkXObNDh4vJwbmADsb0w/viewform).

@ 0176967e:1e6f471e

Co se nomádská rodina již 3 roky utíkající před kontrolou naučila o kontrole samotné? Co je to vlastně svoboda? Může koexistovat se strachem? S konfliktem? Zkusme na chvíli zapomenout na daně, policii a stát a pohlédnout na svobodu i mimo hranice společenských ideologií. Zkusme namísto hledání dalších odpovědí zjistit, zda se ještě někde neukrývají nové otázky. Možná to bude trochu ezo. Karel provozuje již přes 3 roky se svou ženou, dvěmi dětmi a jedním psem minimalistický život v obytné dodávce. Na cestách spolu začali tvořit youtubový kanál "[Karel od Martiny](https://www.youtube.com/@KarelodMartiny)" o svobodě, nomádství, anarchii, rodičovství, drogách a dalších normálních věcech. Nájdete ho aj [na nostr](nostr:npub1y2se87uxc7fa0aenfqfx5hl9t2u2fjt4sp0tctlcr0efpauqtalqxfvr89).

@ 0176967e:1e6f471e

Lístky na festival Lunarpunku sú už v predaji [na našom crowdfunding portáli](https://pay.cypherpunk.today/apps/maY3hxKArQxMpdyh5yCtT6UWMJm/crowdfund). V predaji sú dva typy lístkov - štandardný vstup a špeciálny vstup spolu s workshopom oranžového leta. Neváhajte a zabezpečte si lístok, čím skôr to urobíte, tým bude festival lepší. Platiť môžete Bitcoinom - Lightningom aj on-chain. Vaša vstupenka je e-mail adresa (neposielame potvrdzujúce e-maily, ak platba prešla, ste in). [Kúpte si lístok](https://pay.cypherpunk.today/apps/maY3hxKArQxMpdyh5yCtT6UWMJm/crowdfund)

@ 0176967e:1e6f471e

Čo nám prinášajú exotické protokoly ako Nostr, Cashu alebo Reticulum? Šifrovanie, podpisovanie, peer to peer komunikáciu, nové spôsoby šírenia a odmeňovania obsahu. Ukážeme si kúl appky, ako sa dajú jednotlivé siete prepájať a ako spolu súvisia.

@ 0176967e:1e6f471e

Podnikanie je jazyk s "crystal clear" pravidlami. Inštrumentalisti vidia podnikanie staticky, a toto videnie prenášajú na spoločnosť. Preto nás spoločnosť vníma často negatívne. Skutoční podnikatelia sú však "komunikátori". Jozef Martiniak je zakladateľ AUSEKON - Institute of Austrian School of Economics

@ 0176967e:1e6f471e

Ako sa snažím praktizovať LunarPunk bez budovania opcionality "odchodom" do zahraničia. Nie každý je ochotný alebo schopný meniť "miesto", ako však v takom prípade minimalizovať interakciu so štátom? Nie návod, skôr postrehy z bežného života.

@ 0176967e:1e6f471e

Tento rok vás čaká workshop na tému "oranžové leto" s Jurajom Bednárom a Mariannou Sádeckou. Dozviete sa ako mení naše vnímanie skúsenosť s Bitcoinom, ako sa navigovať v dnešnom svete a odstrániť mentálnu hmlu spôsobenú fiat životom. Na workshop je potrebný [extra lístok](https://pay.cypherpunk.today/apps/maY3hxKArQxMpdyh5yCtT6UWMJm/crowdfund) (môžete si ho dokúpiť aj na mieste). Pre viac informácií o oranžovom lete odporúčame pred workshopom vypočuťi si [podcast na túto tému](https://juraj.bednar.io/podcast/2024/04/13/oranzove-leto-stanme-sa-tvorcami-svojho-zivota-s-mariannou-sadeckou/).

@ 3bf0c63f:aefa459d

# Estórias * [O caso da Grêmio TV](nostr:naddr1qqyxzce3vguxvvfkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823caz985v) * [Jofer](nostr:naddr1qqyxxdt9x4snwwpkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cgsxml2) * [Lagoa Santa: como chegar -- partindo da rodoviária de Belo Horizonte](nostr:naddr1qqyrsdrpxverwdmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c724d7h) * [O Planetinha](nostr:naddr1qqyxzvnzv9jrgef5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cgmfd3v)

@ 3bf0c63f:aefa459d

# Why relay hints are important Recently [Coracle has removed support](nostr:nevent1qqsfmgthccjuz7quucel20wjanh80sp8nxf5ujgpj5hwdzk8japavzgpzemhxue69uhky6t5vdhkjmn9wgh8xmmrd9skcq3qjlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qca68ht) 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:1`s -- 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](nostr:naddr1qqyrze35vscrzvfcqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c0z85e2) 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:1`s 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.

@ 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](nostr:nevent1qqsda83vup73lhv6m4mee2wka83dzuwf78e95wtpn70r6ce99e8ah4gpr9mhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vammnc95) 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.

@ 3bf0c63f:aefa459d

# Bitcoin transactions explained A transaction is a piece of data that takes **inputs** and produces **outputs**. Forget about the blockchain thing, Bitcoin is actually just a big tree of transactions. The blockchain is just a way to keep transactions ordered. Imagine you have 10 satoshis. That means you have them in an unspent transaction output (**UTXO**). You want to spend them, so you create a transaction. The transaction should reference unspent outputs as its inputs. Every transaction has an immutable id, so you use that id plus the index of the output (because transactions can have multiple outputs). Then you specify a **script** that unlocks that transaction and related signatures, then you specify outputs along with a **script** that locks these outputs.  As you can see, there's this lock/unlocking thing and there are inputs and outputs. Inputs must be unlocked by fulfilling the conditions specified by the person who created the transaction they're in. And outputs must be locked so anyone wanting to spend those outputs will need to unlock them. For most of the cases locking and unlocking means specifying a **public key** whose controller (the person who has the corresponding **private key**) will be able to spend. Other fancy things are possible too, but we can ignore them for now. Back to the 10 satoshis you want to spend. Since you've successfully referenced 10 satoshis and unlocked them, now you can specify the outputs (this is all done in a single step). You can specify one output of 10 satoshis, two of 5, one of 3 and one of 7, three of 3 and so on. The sum of outputs can't be more than 10. And if the sum of outputs is less than 10 the difference goes to fees. In the first days of Bitcoin you didn't need any fees, but now you do, otherwise your transaction won't be included in any block.  If you're still interested in transactions maybe you could take a look at [this small chapter](https://github.com/bitcoinbook/bitcoinbook/blob/6d1c26e1640ae32b28389d5ae4caf1214c2be7db/ch06_transactions.adoc) of that Andreas Antonopoulos book. If you hate Andreas Antonopoulos because he is a communist shitcoiner or don't want to read more than half a page, go here: <https://en.bitcoin.it/wiki/Coin_analogy>

@ 88cc134b:5ae99079

This is just a test of how a long form would look like. A need a new note, some old stuff I can find doesn't do it for me. So here I am typing away... I apologize for the spamming and bad grammar, if there is any. The problem with not being good at English grammar and spelling is that you are unaware of the mistakes you make until someone points them out to you. By which time it's too late. One good thing about the editor I'm typing this in is that it seems to have a grammar check, which is cool. Well, I won't keep you any longer, after all this was just a test. Bye!

@ 266815e0:6cd408a5

> NOTE: this is just a quick technical guide. sorry for the lack of details ## Install NodeJS Download it from the official website https://nodejs.org/en/download Or use nvm https://github.com/nvm-sh/nvm?tab=readme-ov-file#install--update-script ```bash wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash nvm install 20 ``` ## Clone example config.yml ```bash wget https://raw.githubusercontent.com/hzrd149/blossom-server/master/config.example.yml -O config.yml ``` ## Modify config.yml ```bash nano config.yml # or if your that type of person vim config.yml ``` ## Run blossom-server ```bash npx blossom-server-ts # or install it locally and run using npm npm install blossom-server-ts ./node_modules/.bin/blossom-server-ts ``` Now you can open http://localhost:3000 and see your blossom server And if you set the `dashboard.enabled` option in the `config.yml` you can open http://localhost:3000/admin to see the admin dashboard

@ 3bf0c63f:aefa459d

# Nostr is not decentralized nor censorship-resistant Peter Todd has been [saying this](nostr:nevent1qqsq5zzu9ezhgq6es36jgg94wxsa2xh55p4tfa56yklsvjemsw7vj3cpp4mhxue69uhkummn9ekx7mqpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qy8hwumn8ghj7mn0wd68ytnddaksz9rhwden5te0dehhxarj9ehhsarj9ejx2aspzfmhxue69uhk7enxvd5xz6tw9ec82cspz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3vamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmnyqy28wumn8ghj7un9d3shjtnwdaehgu3wvfnsz9nhwden5te0wfjkccte9ec8y6tdv9kzumn9wspzpn92tr3hexwgt0z7w4qz3fcch4ryshja8jeng453aj4c83646jxvxkyvs4) 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](https://fiatjaf.com/.well-known/nostr.json) and on my [NIP-65](https://nips.nostr.com/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](nostr:naddr1qqykycekxd3nxdpcvgq3zamnwvaz7tmxd9shg6npvchxxmmdqgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqa2803ksy8) 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](nostr:naddr1qqykycekxd3nxdpcvgq3zamnwvaz7tmxd9shg6npvchxxmmdqgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqa2803ksy8) - [A vision for content discovery and relay usage for basic social-networking in Nostr](nostr:naddr1qqyrxe33xqmxgve3qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cywwjvq)

@ 3bf0c63f:aefa459d

# Censorship-resistant relay discovery in Nostr In [Nostr is not decentralized nor censorship-resistant](nostr:naddr1qqyrsdmpxgcrsepeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c4n8rw6) 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](https://github.com/mikedilger/gossip) was the first client to implement a [truly censorship-resistant relay discovery mechanism](https://mikedilger.com/gossip-relay-model.mp4) that used NIP-05 hints (originally proposed by [Mike Dilger](nprofile1qqswuyd9ml6qcxd92h6pleptfrcqucvvjy39vg4wx7mv9wm8kakyujgua442w)) relay hints and `kind:3` relay lists, and then with the simple insight of [NIP-65](https://nips.nostr.com/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](https://coracle.social) and [Snort](https://snort.social). 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](nostr:naddr1qqyxgvek8qmryc3eqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823chekfst), 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.

@ 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](https://fiatjaf.com/livros-olavo.html) * [Antiga _homepage_ Olavo de Carvalho](https://site.olavo.fiatjaf.com "Sapientiam autem non vincit malitia") * [Bitcoin explicado de um jeito correto e inteligível](nostr:naddr1qqrky6t5vdhkjmspz9mhxue69uhkv6tpw34xze3wvdhk6q3q80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsxpqqqp65wp3k3fu) * [Reclamações](nostr:naddr1qqyrgwf4vseryvmxqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c9f9u03) --- * [Nostr](-/tags/nostr) * [Bitcoin](nostr:naddr1qqyryveexumnyd3kqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c7nywz4) * [How IPFS is broken](nostr:naddr1qqyxgdfsxvck2dtzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8y87ll) * [Programming quibbles](nostr:naddr1qqyrjvehxq6ngvpkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cu05y0j) * [Economics](nostr:naddr1qqyk2cm0dehk66trwvq3zamnwvaz7tmxd9shg6npvchxxmmdqgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqa28clr866) * [Open-source software](nostr:naddr1qqy8xmmxw3mkzun9qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cmyvl8h) --- [Nostr](nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gpyfmhxue69uhkummnw3ez6an9wf5kv6t9vsh8wetvd3hhyer9wghxuet5fmsq8j) [GitHub](https://github.com/fiatjaf) [Telegram](https://t.me/fiatjaf) [Donate](lnurlp://zbd.gg/.well-known/lnurlp/fiatjaf)

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

@ 676c0224:e641b6d6

test

@ 1c9dcd8f:1852f704

Now as to Nuada of the Silver Hand, he was holding a great feast at Teamhair one time, after he was back in the kingship. And there were two door-keepers at Teamhair, Gamal, son of Figal, and Camel, son of Riagall. And a young man came to the door where one of them was, and bade him bring him in to the king. "Who are you yourself?" said the door-keeper. "I am Lugh, son of Cian of the Tuatha de Danaan, and of Ethlinn, daughter of Balor, King of the Fomor," he said; "and I am foster-son of Taillte, daughter of the King of the Great Plain, and of Echaid the Rough, son of Duach." "What are you skilled in?" said the door-keeper; "for no one without an art comes into Teamhair." "Question me," said Lugh; "I am a carpenter." "We do not want you; we have a carpenter ourselves, Luchtar, son of Luachaid." "Then I am a smith." "We have a smith ourselves, Colum Cuaillemech of the Three New Ways." "Then I am a champion." "That is no use to us; we have a champion before, Ogma, brother to the king." "Question me again," he said; "I am a harper." "That is no use to us; we have a harper ourselves, Abhean, son of Bicelmos, that the Men of the Three Gods brought from the hills." "I am-a poet," he said then, "and a teller of tales." "That is no use to us; we have a teller of tales ourselves, Ere, son of Ethaman." "And I am a magician." "That is no use to us; we have plenty of magicians and people of power." "I am a physician," he said. "That is no use; we have Diancecht-for our physician." "Let me be a cup-bearer," he said. "We do not want you; we have nine cup-bearers ourselves." "I am a good worker in brass." "We have a worker in brass ourselves, that is Credne Cerd." Then Lugh said: "Go and ask the king if he has any one man that can do all these things, and if he has, I will not ask to come into Teamhair." The door-keeper went into the king's house then and told him all that. "There is a young man at the door," he said, "and his name should be the Ildánach, the Master of all Arts, for all the things the people of your house can do, he himself is able to do every one of them." "Try him with the chess-boards," said Nuada. So the chess-boards were brought out, and every game that was played, Lugh won it. And when Nuada was told that, he said: "Let him in, for the like of him never came into Teamhair before.  Then the door-keeper let him pass, and he came into the king's house and sat down in the seat of knowledge. And there was a great flag-stone there that could hardly be moved by four times twenty yoke of oxen, and Ogma took it up and hurled it out through the house, so that it lay on the outside of Teamhair, as a challenge to Lugh. But Lugh hurled it back again that it lay in the middle of the king's house. He played the harp for them then, and he had them laughing and crying, till he put them asleep at the end with a sleepy tune. And when Nuada saw all the things Lugh could do, he began to think that by his help the country might get free of the taxes and the tyranny put on it by the Fomor. And it is what he did, he came down from his throne, and he put Lugh on it in his place, for the length of thirteen days, the way they might all listen to the advice he would give. This now is the story of the birth of Lugh. The time the Fomor used to be coming to Ireland, Balor of the Strong Blows, or, as some called him, of the Evil Eye, was living on the Island of the Tower of Glass. There was danger for ships that went near that island, for the Fomor would come out and take them. And some say the sons of Nemed in the old time, before the Firbolgs were in Ireland, passed near it in their ships, and what they saw was a tower of glass in the middle of the sea, and on the tower something that had the appearance of men, and they went against it with Druid spells to attack it. And the Fomor worked against them with Druid spells of their own; and the sons of Nemed attacked the tower, and it vanished, and they thought it was destroyed. But a great wave rose over them then, and all their ships went down and all that were in them. And the tower was there as it was before, and Balor living in it. And it is the reason he was called "of the Evil Eye," there was a power of death in one of his eyes, so that no person could look at it and live. It is the way it got that power, he was passing one time by a house where his father's Druids were making spells of death, and the window being open he looked in, and the smoke of the poisonous spells was rising up, and it went into his eye. And from that time he had to keep it closed unless he wanted to be the death of some enemy, and then the men that were with him would lift the eyelid with a ring of ivory.  Now a Druid foretold one time that it was by his own grandson he would get his death. And he had at that time but one child, a daughter whose name was Ethlinn; and when he heard what the Druid said, he shut her up in the tower on the island. And he put twelve women with her to take charge of her and to guard her, and he bade them never to let her see a man or hear the name of a man. So Ethlinn was brought up in the tower, and she grew to be very beautiful; and sometimes she would see men passing in the currachs, and sometimes she would see a man in her dreams. But when she would speak of that to the women, they would give her no answer. So there was no fear on Balor, and he went on with war and robbery as he was used, seizing every ship that passed by, and sometimes going over to Ireland to do destruction there. Now it chanced at that time there were three brothers of the Tuatha de Danaan living together in a place that was called Druim na Teine, the Ridge of the Fire, Goibniu and Samthainn and Cian. Cian was a lord of land, and Goibniu was the smith that had such a great name. Now Cian had a wonderful cow, the Glas Gaibhnenn, and her milk never failed. And every one that heard of her coveted her, and many had tried to steal her away, so that she had to be watched night and day. And one time Cian was wanting some swords made, and he went to Goibniu's forge, and he brought the Glas Gaibhnenn with him, holding her by a halter. When he came to the forge his two brothers were there together, for Samthainn had brought some steel to have weapons made for himself; and Cian bade Samthainn to hold the halter while he went into the forge to speak with Goibniu. Now Balor had set his mind for a long time on the Glas Gaibhnenn, but he had never been able to get near her up to this time. And he was watching not far off, and when he saw Samthainn holding the cow, he put on the appearance of a little boy, having red hair, and came up to him and told him he heard his two brothers that were in the forge saying to one another that they would use all his steel for their own swords, and make his of iron. "By my word," said Samthainn, "they will not deceive me so easily. Let you hold the cow, little lad," he said, "and I will go in to them." With that he rushed into the forge, and great anger on him. And no sooner did Balor get the halter in his hand than he set out, dragging the Glas along with him, to the strand, and across the sea to his own island. When Cian saw his brother coming in he rushed out, and there he saw Balor and the Glas out in the sea. And he had nothing to do then but to reproach his brother, and to wander about as if his wits had left him, not knowing what way to get his cow back from Balor. At last he went to a Druid to ask an advice from him; and it is what the Druid told him, that so long as Balor lived, the cow would never be brought back, for no one would go within reach of his Evil Eye. Cian went then to a woman-Druid, Birog of the Mountain, for her help. And she dressed him in a woman's clothes, and brought him across the sea in a blast of wind, to the tower where Ethlinn was. Then she called to the women in the tower, and asked them for shelter for a high queen she was after saving from some hardship, and the women in the tower did not like to refuse a woman of the Tuatha de Danaan, and they let her and her comrade in. Then Birog by her enchantments put them all into a deep sleep, and Cian went to speak with Ethlinn. And when she saw him she said that was the face she had seen in her dreams. So she gave him her love; but after a while he was brought away again on a blast of wind. And when her time came, Ethlinn gave birth to a son. And when Balor knew that, he bade his people put the child in a cloth and fasten it with a pin, and throw him into a current of the sea. And as they were carrying the child across an arm of the sea, the pin dropped out, and the child slipped from the cloth into the water, and they thought he was drowned. But he was brought away by Birog of the Mountain, and she brought him to his father Cian; and he gave him to be fostered by Taillte, daughter of the King of the Great Plain. It is thus Lugh was born and reared. And some say Balor came and struck the head off Cian on a white stone, that has the blood marks on it to this day; but it is likely it was some other man he struck the head off, for it was by the sons of Tuireann that Cian came to his death. And after Lugh had come to Teamhair, and made his mind up to join with his father's people against the Fomor, he put his mind to the work; and he went to a quiet place in Grellach Dollaid, with Nuada and the Dagda, and with Ogma; and Goibniu and Diancecht were called to them there. A full year they stopped there, making their plans together in secret, the way the Fomor would not know they were going to rise against them till such time as all would be ready, and till they would know what their strength was. And it is from that council the place got the name afterwards of "The Whisper of the Men of Dea." And they broke up the council, and agreed to meet again that day three years, and every one of them went his own way, and Lugh went back to his own friends, the sons of Manannan. And it was a good while after that, Nuada was holding a great assembly of the people on the Hill of Uisnech, on the west side of Teamhair. And they were not long there before they saw an armed troop coming towards them from the east, over the plain; and there was a young man in front of the troop, in command over the rest, and the brightness of his face was like the setting sun, so that they were not able to look at him because of its brightness.  And when he came nearer they knew it was Lugh Lamh-Fada, of the Long Hand, that had come back to them, and along with him were the Riders of the Sidhe from the Land of Promise, and his own foster-brothers, the sons of Manannan, Sgoith Gleigeil, the White Flower, and Goitne Gorm-Shuileach, the Blue-eyed Spear, and Sine Sindearg, of the Red Ring, and Donall Donn-Ruadh, of the Red-brown Hair. And it is the way Lugh was, he had Manannan's horse, the Aonbharr, of the One Mane, under him, that was as swift as the naked cold wind of spring, and the sea was the same as dry land to her, and the rider was never killed off her back. And he had Manannan's breast-plate on him, that kept whoever was wearing it from wounds, and a helmet on his head with two beautiful precious stones set in the front of it and one at the back, and when he took it off, his forehead was like the sun on a dry summer day. And he had Manannan's sword, the Freagarthach, the Answerer, at his side, and no one that was wounded by it would ever get away alive; and when that sword was bared in a battle, no man that saw it coming against him had any more strength than a woman in child-birth.  And the troop came to where the King of Ireland was with the Tuatha de Danaan, and they welcomed one another. And they were not long there till they saw a surly, slovenly troop coming towards them, nine times nine of the messengers of the Fomor, that were coming to ask rent and taxes from the men of Ireland; and the names of the four that were the hardest and the most cruel were Eine and Eathfaigh and Coron and Compar; and there was such great dread of these four on the Tuatha de Danaan, that not one of them would so much as punish his own son or his foster-son without leave from them. They came up then to where the King of Ireland was with the Riders of the Sidhe, and the king and all the Tuatha de Danaan stood up before them. And Lugh of the Long Hand said: "Why do you rise up before that surly, slovenly troop, when you did not rise up before us?" "It is needful for us to do it," said the king; "for if there was but a child of us sitting before them, they would not think that too small a cause for killing him." "By my word," said Lugh, "there is a great desire coming on me to kill themselves." "That is a thing would bring harm on us," said the king, "for we would meet our own death and destruction through it." "It is too long a time you have been under this oppression," said Lugh. And with that he started up and made an attack on the Fomor, killing and wounding them, till he had made an end of eight nines of them, but he let the last nine go under the protection of Nuada the king. "And I would kill you along with the others," he said, "but I would sooner see you go with messages to your own country than my own people, for fear they might get any ill-treatment." So the nine went back then till they came to Lochlann, where the men of the Fomor were, and they told them the story from beginning to end, and how a young well-featured lad had come into Ireland and had killed all the tax-gatherers but themselves, "and it is the reason he let us off," they said, "that we might tell you the story ourselves." "Do you know who is the young man?" said Balor of the Evil Eye then. "I know well," said Ceithlenn, his wife; "he is the son of your daughter and mine. And it was foretold," she said, "that from the time he would come into Ireland, we would never have power there again for ever." Then the chief men of the Fomor went into a council, Eab, son of Neid, and Seanchab, grandson of Neid, and Sital Salmhor, and Liath, son of Lobais, and the nine poets of the Fomor that had learning and the gift of foreknowledge, and Lobais the Druid, and Balor himself and his twelve white-mouthed sons, and Ceithlenn of the Crooked Teeth, his queen. And it was just at that time Bres and his father Elathan were come to ask help of the Fomor, and Bres said: "I myself will go to Ireland, and seven great battalions of the Riders of the Fomor along with me, and I will give battle to this Ildánach, this master of all arts, and I will strike his head off and bring it here to you, to the green of Berbhe." "It would be a fitting thing for you to do," said they all. "Let my ships be made ready for me," said Bres, "and let food and provisions be put in them." So they made no delay, but went and got the ships ready, and they put plenty of food and drink in them, and the two swift Luaths were sent out to gather the army to Bres. And when they were all gathered, they made ready their armour and their weapons, and they set out for Ireland. And Balor the king followed them to the harbour, and he said: "Give battle to that Ildánach, and strike off his head; and tie that island that is called Ireland to the back of your ships, and let the destroying water take its place, and put it on the north side of Lochlann, and not one of the Men of Dea will follow it there to the end of life and time."  Then they pushed out their ships and put up their painted sails, and went out from the harbour on the untilled country, on the ridges of the wide-lying sea, and they never turned from their course till they came to the harbour of Eas Dara. And from that they sent out an army through West Connacht and destroyed it altogether, through and through. And the King of Connacht at that time was Bodb Dearg, son of the Dagda.

@ 9ca0bd74:4052340b

needed to reattach the space bar have i fixed my keyboards? i think that i have, but let's see how long it lasts I'm just writing to see that all the keys work, i think that they do, wait i havent tried Caps Lock yet, good. Now that's the end of a sentence! The quick brown fox jumped over the red cow, I can't remember if that is the phrase with all the letters. Lazy cow, That's it lazy bloody cow.

@ 4ba8e86d:89d32de4

Mas a todos que desejam testar configurações, experimentar, praticar restaurações de carteiras e se familiarizar com ferramentas CoinJoin PayNym Stowaway/PayJoin Stonewall STONEWALLx2 os mini CoinJoins. Pra usar testnet na SamouraiWallet faça o download na página oficial em https://samouraiwallet.com ou na F-DROID Assim permitirá que você entre no modo testnet, o que facilitará a prática com as ferramentas e a compreensão das opções disponíveis. FAÇA A VERIFICAÇÃO DA ASSINATURA. https://nostrcheck.me/media/public/nostrcheck.me_4284977124189379291696977272.webp https://nostrcheck.me/media/public/nostrcheck.me_5885204588237039521696977229.webp depois da instalação do aplicativo E Só testa as funcionalidade. Obs: A versão disponível no Google Play não faz essa solicitação e segue diretamente para a mainnet. Testnet faucets: * https://bitcoinfaucet.uo1.net * https://tbtc.bitaps.com * https://coinfaucet.eu/en/btc-testnet * https://kuttler.eu/en/bitcoin/btc/faucet/ Offline at the moment (maybe permanently): * https://testnet-faucet.mempool.co * https://tpfaucet.appspot.com Via Twitter @ottosch_

@ 676c0224:e641b6d6

testr

@ 676c0224:e641b6d6

test testr

@ 676c0224:e641b6d6

test test test

@ 676c0224:e641b6d6

test test

@ e42dd2a2:eeddb96f

testr testr

@ e42dd2a2:eeddb96f

bounce bounce baby

@ e42dd2a2:eeddb96f

testr 123 lorem ipsum

@ e42dd2a2:eeddb96f

testr lorem ipsum 123

@ e42dd2a2:eeddb96f

testing lorem ipsum

@ e42dd2a2:eeddb96f

lorem ipsum

@ 1c9dcd8f:1852f704

 ----------- But if Nuada won the battle, he lost his own arm in it, that was struck off by Sreng; and by that loss there came troubles and vexation on his people. For it was a law with the Tuatha de Danaan that no man that was not perfect in shape should be king. And after Nuada had lost the battle he was put out of the kingship on that account. And the king they chose in his place was Bres, that was the most beautiful of all their young men, so that if a person wanted to praise any beautiful thing, whether it was a plain, or a dun, or ale, or a flame, or a woman, or a man, or a horse, it is what he would say, "It is as beautiful as Bres." And he was the son of a woman of the Tuatha de Danaan, but who his father was no one knew but herself. But in spite of Bres being so beautiful, his reign brought no great good luck to his people; for the Fomor, whose dwelling-place was beyond the sea, or as some say below the sea westward, began putting tribute on them, the way they would get them under their own rule. It was a long time before that the Fomor came first to Ireland; dreadful they were to look at, and maimed, having but one foot or one hand, and they under the leadership of a giant and his mother. There never came to Ireland an army more horrible or more dreadful than that army of the Fomor. And they were friendly with the Firbolgs and content to leave Ireland to them, but there was jealousy between them and the Men of Dea. And it was a hard tax they put on them, a third part of their corn they asked, and a third part of their milk, and a third part of their children, so that there was not smoke rising from a roof in Ireland but was under tribute to them. And Bres made no stand against them, but let them get their way. And as to Bres himself, he put a tax on every house in Ireland of the milk of hornless dun cows, or of the milk of cows of some other single colour, enough for a hundred men. And one time, to deceive him, Nechtan singed all the cows of Ireland in a fire of fern, and then he smeared them with the ashes of flax seed, the way they were all dark brown. He did that by the advice of the Druid Findgoll, son of Findemas. And another time they made three hundred cows of wood with dark brown pails in place of udders, and the pails were filled with black bog stuff. Then Bres came to look at the cows, and to see them milked before him, and Cian, father of Lugh, was there. And when they were milked it was the bog stuff that was squeezed out; and Bres took a drink of it thinking it to be milk, and he was not the better of it for a long time. And there was another thing against Bres; he was no way open-handed, and the chief men of the Tuatha de Danaan grumbled against him, for their knives were never greased in his house, and however often they might visit him there was no smell of ale on their breath. And there was no sort of pleasure or merriment in his house, and no call for their poets, or singers, or harpers, or pipers, or horn-blowers, or jugglers, or fools. And as to the trials of strength they were used to see between their champions, the only use their strength was put to now was to be doing work for the king. Ogma himself, the shining poet, was under orders to bring firing to the palace every day for the whole army from the Islands of Mod; and he so weak for want of food that the sea would sweep away two-thirds of his bundle every day. And as to the Dagda, he was put to build raths, for he was a good builder, and he made a trench round Rath Brese. And he used often to be tired at the work, and one time he nearly gave in altogether for want of food, and this is the way that happened. He used to meet in the house an idle blind man, Cridenbel his name was, that had a sharp tongue, and that coveted the Dagda's share of food, for he thought his own to be small beside it. So he said to him: "For the sake of your good name let the three best bits of your share be given to me." And the Dagda gave in to that every night; but he was the worse of it, for what the blind man called a bit would be the size of a good pig, and with his three bits he would take a full third of the whole. But one day, as the Dagda was in the trench, he saw his son, Angus Og, coming to him. "That is a good meeting," said Angus; "but what is on you, for you have no good appearance to-day?" "There is a reason for that," said the Dagda, "for every evening, Cridenbel, the blind man, makes a demand for the three best bits of my share of food, and takes them from me." "I will give you an advice," said Angus. He put his hand in his bag then, and took out three pieces of gold and gave them to him. "Put these pieces of gold into the three bits you will give this evening to Cridenbel," he said, "and they will be the best bits in the dish, and the gold will turn within him the way he will die." So in the evening the Dagda did that; and no sooner had Cridenbel swallowed down the gold than he died. Some of the people said then to the king: "The Dagda has killed Cridenbel, giving him some deadly herb." The king believed that, and there was anger on him against the Dagda, and he gave orders he should be put to death. But the Dagda said: "You are not giving the right judgment of a prince." And he told all that had happened, and how Cridenbel used to say, "Give me the three best bits before you, for my own share is not good to-night." "And on this night," he said, "the three pieces of gold were the best things before me, and I gave them to him, and he died." The king gave orders then to have the body cut open. And they found the gold inside it, and they knew it was the truth the Dagda had told. And Angus came to him again the next day, and he said: "Your work will soon be done, and when you are given your wages, take nothing they may offer you till the cattle of Ireland are brought before you, and choose out a heifer then, black and black-maned, that I will tell you the signs of." So when the Dagda had brought his work to an end, and they asked him what reward he wanted, he did as Angus had bidden him. And that seemed folly to Bres; he thought the Dagda would have asked more than a heifer of him. There came a day at last when a poet came to look for hospitality at the king's house, Corpre, son of Etain, poet of the Tuatha de Danaan. And it is how he was treated, he was put in a little dark narrow house where there was no fire, or furniture, or bed; and for a feast three small cakes, and they dry, were brought to him on a little dish. When he rose up on the morrow he was no way thankful, and as he was going across the green, it is what he said: "Without food ready on a dish; without milk enough for a calf to grow on; without shelter; without light in the darkness of night; without enough to pay a story-teller; may that be the prosperity of Bres." And from that day there was no good luck with Bres, but it is going down he was for ever after. And that was the first satire ever made in Ireland. Now as to Nuada: after his arm being struck off, he was in his sickness for a while, and then Diancecht, the healer, made an arm of silver for him, with movement in every finger of it, and put it on him. And from that he was called Nuada Argat-lamh, of the Silver Hand, for ever after. Now Miach, son of Diancecht, was a better hand at healing than his father, and had done many things. He met a young man, having but one eye, at Teamhair one time, and the young man said: "If you are a good physician you will put an eye in the place of the eye I lost." "I could put the eye of that cat in your lap in its place," said Miach. "I would like that well," said the young man. So Miach put the cat's eye in his head; but he would as soon have been without it after, for when he wanted to sleep and take his rest, it is then the eye would start at the squeaking of the mice, or the flight of the birds, or the movement of the rushes; and when he was wanting to watch an army or a gathering, it is then it was sure to be in a deep sleep. And Miach was not satisfied with what his father had done to the king, and he took Nuada's own hand that had been struck off, and brought it to him and set it in its place, and he said: "Joint to joint, and sinew to sinew." Three days and three nights he was with the king; the first day he put the hand against his side, and the second day against his breast, till it was covered with skin, and the third day he put bulrushes that were blackened in the fire on it, and at the end of that time the king was healed. But Diancecht was vexed when he saw his son doing a better cure than himself, and he threw his sword at his head, that it cut the flesh, but the lad healed the wound by means of his skill. Then Diancecht threw it a second time, that it reached the bone, but the lad was able to cure the wound. Then he struck him the third time and the fourth, till he cut out the brain, for he knew no physician could cure him after that blow; and Miach died, and he buried him. And herbs grew up from his grave, to the number of his joints and sinews, three hundred and sixty-five. And Airmed, his sister, came and spread out her cloak and laid out the herbs in it, according to their virtue. But Diancecht saw her doing that, and he came and mixed up the herbs, so that no one knows all their right powers to this day. Then when the Tuatha de Danaan saw Nuada as well as he was before, they gathered together to Teamhair, where Bres was, and they bade him give up the kingship, for he had held it long enough. So he had to give it up, though he was not very willing, and Nuada was put back in the kingship again. There was great vexation on Bres then, and he searched his mind to know how could he be avenged on those that had put him out, and how he could gather an army against them; and he went to his mother, Eri, daughter of Delbaith, and bade her tell him what his race was. "I know that well," she said; and she told him then that his father was a king of the Fomor, Elathan, son of Dalbaech, and that he came to her one time over a level sea in some great vessel that seemed to be of silver, but she could not see its shape, and he himself having the appearance of a young man with yellow hair, and his clothes sewed with gold, and five rings of gold about his neck. And she that had refused the love of all the young men of her own people, gave him her love, and she cried when he left her. And he gave her a ring from his hand, and bade her give it only to the man whose finger it would fit, and he went away then the same way as he had come. And she brought out the ring then to Bres, and he put it round his middle finger, and it fitted him well. And they went then together to the hill where she was the time she saw the silver vessel coming, and down to the strand, and she and Bres and his people set out for the country of the Fomor. And when they came to that country they found a great plain with many gatherings of people on it, and they went to the gathering that looked the best, and the people asked where did they come from, and they said they were come from Ireland. "Have you hounds with you?" they asked them then, for it was the custom at that time, when strangers came to a gathering, to give them some friendly challenge. "We have hounds," said Bres. So the hounds were matched against one another, and the hounds of the Tuatha de Danaan were better than the hounds of the Fomor. "Have you horses for a race?" they asked then. "We have," said Bres. And the horses of the Tuatha de Danaan beat the horses of the Fomor. Then they asked was any one among them a good hand with the sword, and they said Bres was the best. But when he put his hand to his sword, Elathan, his father, that was among them, knew the ring, and he asked who was this young man. Then his mother answered him and told the whole story, and that Bres was his own son. There was sorrow on his father then, and he said: "What was it drove you out of the country you were king over?" And Bres said: "Nothing drove me out but my own injustice and my own hardness; I took away their treasures from the people, and their jewels, and their food itself. And there were never taxes put on them before I was their king." "That is bad," said his father; "it is of their prosperity you had a right to think more than of your own kingship. And their good-will would be better than their curses," he said; "and what is it you are come to look for here?" "I am come to look for fighting men," said Bres, "that I may take Ireland by force." "You have no right to get it by injustice when you could not keep it by justice," said his father. "What advice have you for me then?" said Bres. And Elathan bade him go to the chief king of the Fomor, Balor of the Evil Eye, to see what advice and what help would he give him.

@ 6ad3e2a3:c90b7740

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">The sense of futility is part of the psy-op. Maybe the most important part.</p>&mdash; Christopher Liss (@Chris_Liss) <a href="https://twitter.com/Chris_Liss/status/1575220465877909505?ref_src=twsrc%5Etfw">September 28, 2022</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> I imagine most of you have been on the phone with a company that didn’t deliver on its obligations. Maybe the time-sensitive package you overnighted was delayed, the airline lost your luggage or your health insurance refused to cover a bill, and after some back and forth regarding potential remedies, the customer service rep says, “I’m sorry sir, but that’s company policy.” “Company policy” is invoked to end the conversation, get you to move on and accept whatever remedy (or mere apology) they are offering, no matter how incommensurate with their error. And it often works because wise people learn to direct their energies toward things they can change, rather than things they cannot. <blockquote class="twitter-tweet"><p lang="en" dir="ltr">A rational person can find peace by cultivating indifference to things outside of their control.</p>&mdash; Naval (@naval) <a href="https://twitter.com/naval/status/919317409852297218?ref_src=twsrc%5Etfw">October 14, 2017</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> Sure, you have ripped me off, cost me time and money, mishandled something that was important to me, but if a remedy isn’t possible, per your policy, what can I do, shout into my phone for 20 more minutes? I can vow never to use that company again, but it’s a massive conglomerate, possibly a virtual monopoly in my area, and in any event, my business won’t be especially missed. “Fine,” you say, as you hang up the phone, grumbling under your breath and trying to put it out of your mind so you can go about the rest of your day. This is what happens most of the time for most people, but [not for me](https://medium.com/@chris_liss/stop-stealing-our-money-694d3649d274). What I realized is the “company policy” trick works by exploiting the “pick your battles” and “worry only about what you can control” heuristics that serve people well in most circumstances. They know you have them on the question of right and wrong, fairness and proportionality, so rather than fight on losing ground, they shift to the question of what’s possible for you to do about it. But let’s consider what this pivot from what’s right to what’s possible has wrought. It’s not just that you won’t get reimbursed for the $4K anesthesiologist bill who was out of network (and did his work while you were unconscious), but runs much deeper than that. Here’s Cindy McCain, John McCain’s widow, [talking about](https://x.com/CarolSm33801/status/1746906610306351163?s=20) Jeffery Epstein: <blockquote class="twitter-tweet" data-media-max-width="560"><p lang="en" dir="ltr">They ALL KNEW<a href="https://t.co/qrce1zs49B">https://t.co/qrce1zs49B</a></p>&mdash; Carol SMART Baker (@CarolSm33801) <a href="https://twitter.com/CarolSm33801/status/1746906610306351163?ref_src=twsrc%5Etfw">January 15, 2024</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> Her point is that everyone knew Epstein was doing horrendous wrongs, but they didn’t believe anyone would do anything about it. In a sense, they assumed, via the [CIA or whatever powerful organization was so obviously protecting him](https://www.thedailybeast.com/jeffrey-epsteins-sick-story-played-out-for-years-in-plain-sight?ref=scroll), his activities were “company policy.” Whether it was wrong was not sufficient. It was not possible for him to face punishment. Until it was. The illusion of untouchability is a tactic to make you give up. What are you going to do about it? Nothing. A “rational person”, a person who wants to “find peace” will “cultivate indifference to things outside of their [sic] control.” And we don’t just see this frame coming from powerful malefactors wanting you to give up. Via Stockholm Syndrome it has spread to regular citizens, even among those who are awake to disturbing truths about our institutions and policymakers. “Coerced injections were abominable, but get real, no one will ever go to jail for it,” is essentially the same thing as “Sorry sir, but it’s company policy,” only [the call is coming from inside the house](https://www.youtube.com/watch?v=rkcGm-pWwsQ). You’ve ceded the fight about what’s right to what’s possible, and even though you’re justifiably angry about it, you not only expect nothing to come of it, but actively discourage others who feel as you do. Why should you accept a wrong? Why should you concede an injustice? Because it might not possible to redress it? Well of course it’s not possible if you care whether it’s possible! How about fighting for what’s right, whether or not in your narrow-minded crystal-ball-lacking capacity you can predict the future? *The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.* [―George Bernard Shaw, Man and Superman](https://www.goodreads.com/work/quotes/376394-man-and-superman) The fight over what’s possible is the trick. Obviously it’s possible. If we stand up, sue, complain, demand, it will happen. It need not be everyone, not even a majority, just a committed, principled and intransigent minority. Of course, they don’t want you to do that. A bully wants to intimidate, not get into an actual fistfight on the merits. How do they prevent it? Divide, distract, despond and deride. They shout “Conspiracy theory!” to deter questioning. They don’t care whether what’s alleged is true — they want to make the subject off limits. If it’s not permissible to discuss, then it doesn’t matter whether it’s true. Evidence doesn’t matter because that claim doesn’t have standing to be heard. Summary judgment. These are the tactics. You are losing because you are blind to them. You buy into the frame. We must choose an alternative frame: I hear that it’s YOUR policy, but that doesn’t address MY problem. This is wrong, and you stating that you’re in the habit of doing wrong and not addressing it will not make me go away. In fact, it’s going to make me even more resolute because clearly you are not even prepared to defend your conduct. Had you persuaded me that actually I were mistaken, I would drop it. But you are persuading me that I am even more on target than I thought because you are trying to render a discussion on the merits off limits. Assuming I have persuaded some of you that “Company Policy” is to fool people into giving up meretricious claims by making the prospect of relief appear futile, and that “They’ll never be held to account” is but the internalization of that tactic, you might ask, okay, what *can* we do about it? How do we hold the powerful to account? Podcaster Marty Bent posed a related question to his guest Tom Luongo on a recent TFTC podcast, and Luongo’s [answer]( https://youtu.be/ZqTjwsJ3r68?si=cia-drU2DKDKQe0b&t=5417) was enlightening. Luongo said you have to keep talking, expressing dissenting views that bubble up into the zeitgeist where they gain increasing influence. The discourse is a complex system — it’s impossible to predict the long-term effects of one’s ideas on it. You could be shouting into the void for months, and one day something you say sparks a better-worded idea in the mind of someone with more reach. Sometimes little things turn out to be big things, the ripple that births a tsunami. I agree with Luongo on this point. I want people to understand the notion that things are futile does not arise in your mind accidentally. It has been crafted to deter you. And if you are deterred the prophecy will self-fulfill. But the moment enough people demand and expect accountability, scoff at the idea that humans like you and me, but who just happen to have wealth or social connections, are untouchable, is when justice is possible. The bully just got punched in the face, we see in truth he was always scared and weak. It’s why he became a bully. But we will not be bullied. “Company policy” will not suffice. We demand an accounting on the merits. And we will get it, so long as we refuse to be deterred by false notions of what’s possible.

@ 3bf0c63f:aefa459d

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

@ 3bf0c63f:aefa459d

# 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](https://fiatjaf.alhur.es/expressões-e-ditados.txt)

@ 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"](https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki) 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](https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki) or by [the Spacechains mechanism](https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5). ## 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](https://twitter.com/LukeDashjr/status/1126221228182843398) 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](https://developers.rsk.co/rsk/architecture/mining/implementation-guide/). 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](https://www.youtube.com/watch?v=DhU6nsB5Z-0) * [Alternatives to Drivechain](nostr:naddr1qqyrqenzvvukvcfkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823csjg2t6) * [Drivechain comparison with Ethereum](nostr:naddr1qqyx2dp58qcx2wpjqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cane7px)

@ 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][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](nostr:naddr1qqyrywphxdskzwp5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cwx779x) [^pr-merged-very-quickly]: See [PR 20624](https://github.com/bitcoin/bitcoin/pull/20624), for example, a very complicated change that [could be introducing bugs or be a deliberate attack](http://www.erisian.com.au/wordpress/2021/01/07/bitcoin-in-2021), merged in 3 days without time for discussion. [knots]: https://bitcoinknots.org/

@ 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

# 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](https://techcommunity.microsoft.com/t5/identity-standards-blog/ion-we-have-liftoff/ba-p/1441555) is a [DID method](nostr:naddr1qqyrjwrpv93rjcf4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cuxp7vx) 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](nostr:naddr1qqyrydtpx33nsvpcqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ccx33ee)

@ 3bf0c63f:aefa459d

# rosetta.alhur.es A service that grabs code samples from two chosen languages on [RosettaCode](http://rosettacode.org/wiki/Rosetta_Code) 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](nostr:naddr1qqyrgceh89nxgdmzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ctgmx78) 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](https://github.com/nostr-protocol/nips/blob/master/41.md) (stateless key invalidation) - [NIP-46](https://github.com/nostr-protocol/nips/blob/master/46.md) (Nostr Connect) - [NIP-07](https://github.com/nostr-protocol/nips/blob/master/07.md) (signer browser extension) - [Connected hardware signing devices](https://lnbits.github.io/nostr-signing-device/installer/) - 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](https://github.com/btcontract/lnurl-rfc/blob/master/lnurl-auth.md) spec or heard about it, but might not know how it works or what is its relationship with other [lnurl](https://github.com/fiatjaf/awesome-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](https://sqrl.grc.com/) 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](https://sqrl.grc.com/threads/developer-documentation-conflicted-and-confusing-please-help-clarify.951/), 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](https://webauthn.guide/) 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](https://github.com/bitid/bitid)? This is another one that is [very similar](https://www.youtube.com/watch?v=3eepEWTnRTc) 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](https://en.wikipedia.org/wiki/Infinite_monkey_theorem) 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](nostr:naddr1qqyryveexumnyd3kqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c7nywz4), 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](nostr:naddr1qqyxgdfsxvck2dtzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8y87ll)

@ 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](nostr:naddr1qqyrqen9xf3nvdpeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cmdjnnj) * [IPFS problems: General confusion](nostr:naddr1qqyr2wf4xvcrwvnyqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823chvx94h) * [IPFS problems: Shitcoinery](nostr:naddr1qqyxxdpev5cnsvpkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cta4a2e) * [IPFS problems: Community](nostr:naddr1qqyrxdmrvvengdmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cekkch5) * [IPFS problems: Pinning](nostr:naddr1qqyrgvf3xcenydesqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c9ckstx) * [IPFS problems: Conceit](nostr:naddr1qqyxyeryx93kxv3nqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cwxek0q) * [IPFS problems: Inefficiency](nostr:naddr1qqyr2dp3vsmx2vpsqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ckklcy6) * [IPFS problems: Dynamic links](nostr:naddr1qqyrvcnx8y6nwwtpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cz8tlwh) ### See also * [A crappy course on torrents](nostr:naddr1qqyrwdfevfjnxefcqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cuskhxf), on the protocol that has done most things right * [The Tragedy of IPFS in a series of links](https://mobile.twitter.com/fiatjaf/status/1289246273669697536), 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.

@ 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

# 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](https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5) 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](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) [^eltoo]: The same thing used in [Eltoo](nostr:naddr1qqyxvenyvejnwdejqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c6qlqxc).

@ 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`](https://github.com/srid/neuron) que também gera sites a partir das notas?, acho que vai ser bom.

@ 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

# Flowi.es At the time I thought [Workflowy][workflowy] had the ideal UI for everything. I wanted to implement my [custom app maker](nostr:naddr1qqyxgcejv5unzd33qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cz3va32) 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](nostr:naddr1qqyrydpkvverwvehqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c9d4yku), also based on [Classless Templates](nostr:naddr1qqyxyv35vymk2vfsqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cqwgdau) Also, I didn't remember this was also based on CouchDB and had some _couchapp_ functionalities.  - <https://flowi.es> - <https://github.com/fiatjaf/flowies> [workflowy]: <https://workflowy.com/>

@ 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](https://bips.xyz/300) 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](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) 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](https://bips.xyz/300) 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'](https://www.truthcoin.info/blog/wise-contracts/), by Paul Sztorc - [Drivechain](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) - [Drivechain comparison with Ethereum](nostr:naddr1qqyx2dp58qcx2wpjqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cane7px) - [Alternatives to Drivechain](nostr:naddr1qqyrqenzvvukvcfkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823csjg2t6)

@ 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

# 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

# neuron.vim I started using this [neuron][neuron] thing to create an update this same [zettelkasten](nostr:naddr1qqyrwwfh8yurgefnqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c7qmjrw), but the [existing vim plugin](https://github.com/ihsanturk/neuron.vim) 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> [neuron]: https://github.com/srid/neuron

@ 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](https://hackage.haskell.org/package/miso) and [hledger's Haskell libraries](https://hledger.org/) plus [ghcjs](https://github.com/ghcjs/ghcjs) to be compiled to a web page, and then adds [optional remoteStorage](https://remotestorage.io/) 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://wiki.remotestorage.io/Apps). - <https://hledger.alhur.es/> - <https://github.com/fiatjaf/hledger-web> ## See also - [My stupid introduction to Haskell](nostr:naddr1qqyrxveevscrqcmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cxd5qyk) - [LessPass remoteStorage](nostr:naddr1qqyrsctpxfjnqepeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cfa6z2z) - [TiddlyWiki remoteStorage](nostr:naddr1qqyxxve4x33nqerrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cat32d3)

@ 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](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp), less crappy and more decentralized trusted channels networks and [statechains](https://bitcoinmagazine.com/technical/statechains-sending-keys-not-coins-to-scale-bitcoin-off-chain)). ## 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](https://twitter.com/hampus_s/status/1442493786110705668) 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](https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html); and changes to the expected BOLT spec behavior with regards to, for example, [probing of mobile wallets](https://github.com/lightningnetwork/lnd/pull/4785). 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

# On HTLCs and arbiters This is another attempt and conveying the same information that should be in [Lightning and its fake HTLCs](nostr:naddr1qqyryefsxqcxgdmzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cp0m63a). 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

# 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][dabble-db]. [dabble-db]: <https://en.wikipedia.org/wiki/Dabble_DB>

@ 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](https://twitter.com/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](nostr:naddr1qqyrqv3cxumnydfsqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cnjc88q) * [idea: Graph subjective reputation as a service](nostr:naddr1qqyrjdehxymrsdpkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cal60d8) * <https://github.com/jangerritharms/reputation_systems>

@ 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: 3. uma foto assim não é uma prova de que fulano vendeu, ele podia estar só passando lá perto. * 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](nostr:naddr1qqyrqv3cxumnydfsqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cnjc88q) para um fundamento de um sistema jurídico anárquico.

@ 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](nostr:naddr1qqyrwepevf3n2wf5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c0jq39e)

@ 3bf0c63f:aefa459d

# jiq When someone created [`jiq`](https://github.com/simeji/jid) 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`](https://stedolan.github.io/jq/manual/) 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

# 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](https://github.com/nostr-protocol/nips/blob/master/26.md) 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](nostr:naddr1qqyrwvnxx4jrzef5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cchlq3c). 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.

@ 3bf0c63f:aefa459d

# LessPass remoteStorage [LessPass](https://www.lesspass.com/) 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](https://wiki.remotestorage.io/Apps) 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](nostr:naddr1qqyrsefkvvck2efkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cffvz7c) - [TiddlyWiki remoteStorage](nostr:naddr1qqyxxve4x33nqerrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cat32d3)

@ 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][mupdf] binary. - <https://github.com/fiatjaf/splitpages> - <https://splitpages.herokuapp.com/> [mupdf]: <https://mupdf.com/>