@ 8f69ac99:4f92f5fd

Há algo quase reconfortante na previsibilidade com que certos colunistas abordam Bitcoin: a cada oportunidade, repetem os mesmos chavões, reciclados com indignação moralista e embrulhados numa embalagem de falsa autoridade. O artigo publicado na Visão, com o título dramático "De criança prodígio a adolescente problemático", encaixa-se perfeitamente nesse molde.

Trata-se de uma peça de opinião que mistura factos irrelevantes com interpretações enviesadas, estatísticas sem contexto e um medo mal disfarçado de perder o monopólio da narrativa económica. A autora, Sofia Santos Machado, opta por colar em Bitcoin os desastres do chamado “mundo cripto” como se fossem parte do mesmo fenómeno — ignorando, por conveniência ou ignorância, que Bitcoin não é altcoins, não é NFTs, não é esquemas de yield exótico, e não é fintech vestida de blockchain.

Esta resposta centra-se exclusivamente em Bitcoin — um protocolo monetário aberto, incorruptível e resistente à censura, que já está a servir como salvaguarda de valor em regiões onde o sistema financeiro convencional falhou. Não me interessa defender pirâmides, tokens inflacionários ou aventuras bancárias mal calculadas.

Criticar Bitcoin é legítimo — mas fazê-lo sem saber do que se fala é apenas desinformação.

A Histeria da Água — Falar Sem Saber

O artigo abre com uma pérola alarmista sobre o consumo de água:

“Uma única transacção de bitcoin consome seis milhões de vezes mais água do que um pagamento com cartão.”

Seis. Milhões. De vezes. Resta saber se a autora escreveu isto com cara séria ou a rir-se enquanto bebia água engarrafada dos Alpes Suíços.

Fontes? Metodologia? Contexto? Estou a brincar — isto é a Visão, onde os números são decoração e os factos opcionais.

Claro que comparar transacções na camada base de Bitcoin com pagamentos "instantâneos" da rede Visa é tão rigoroso como comparar um Boeing 747 com um avião de papel porque um voa mais longe. Um artigo sério teria falado em batching, na Lightning Network, ou no facto de que Bitcoin nem sequer compete com a Visa nesse nível, nem em nenhum. Mas isso exigiria, imagine-se, investigação.

Pior ainda, não há qualquer menção ao consumo de água na extracção de ouro, nos data centers bancários, ou no treino de modelos de inteligência artificial. Pelos vistos, só Bitcoin tem de obedecer aos mandamentos ecológicos da Visão. O resto? Santa ignorância selectiva.

Criminosos e o Fantasma do Satoshi

Eis o clássico: “Bitcoin é usado por criminosos”. Um cliché bafiento tirado do baú de 2013, agora reapresentado como se fosse escândalo fresco.

Na realidade, Bitcoin é pseudónimo, não anónimo. Todas as transacções ficam gravadas num livro público — não é propriamente o esconderijo ideal para lavar dinheiro, a menos que sejas fã de disfarces em néon.

E os dados? Claríssimos. Segundo a Chainalysis e a Europol, a actividade ilícita com Bitcoin tem vindo a diminuir. Enquanto isso, os bancos — esses bastiões de confiança — continuam a ser apanhados a lavar biliões para cartéis e cleptocratas. Mas disso a Visão não fala. Devia estragar a narrativa.

O verdadeiro crime aqui é a preguiça intelectual tão profunda que quase merece uma moldura. A Visão tem um editor?

O Espantalho Energético

Como uma criança que acabou de aprender uma palavra nova, a Visão repete “consumo energético” como se fosse um pecado original. Bitcoin usa electricidade — escândalo!

Mas vejamos: o Proof-of-Work não é um defeito. É a razão pela qual Bitcoin é seguro. Não há “desperdício” — há uso, e muitas vezes com energia excedente, renovável, ou que de outro modo seria desperdiçada. É por isso que os mineiros se instalam junto a barragens remotas, queima de gás (flaring), ou parques eólicos no meio do nada — não porque odeiam o planeta, mas porque os incentivos económicos funcionam. Escrevi sobre isso aqui.

O que a Visão convenientemente ignora é que Bitcoin está a ajudar a integrar mais energia renovável nas redes, funcionando como carga flexível. Mas nuance? Trabalho de casa? Esquece lá isso.

Para uma explicação mais séria, podiam ter ouvido o podcast A Seita Bitcoin com o Daniel Batten. Mas para quê investigar?

Cripto = Bitcoin = Fraude?

Aqui chegamos ao buraco negro intelectual: enfiar tudo no mesmo saco. FTX colapsou? Culpa de Bitcoin. Um banqueiro jogou com altcoins? Culpa de Bitcoin. Scam de NFT? Deve ter sido o Satoshi.

Vamos esclarecer: Bitcoin não é “cripto”. Bitcoin é descentralizado, sem líderes, transparente. Não teve pré-mineração, não tem CEO, não promete lucros. O que o rodeia? Tokens centralizados, esquemas Ponzi, pirâmides e vaporware — precisamente o oposto do que Bitcoin representa.

Se um executivo bancário perde o dinheiro dos clientes em Dogecoins, isso é um problema dele. Bitcoin não lhe prometeu nada. Foi a ganância.

E convenhamos: os bancos tradicionais também colapsam. E não precisam de satoshis para isso. Bastam dívidas mal geridas, contabilidade criativa e uma fé cega no sistema.

Culpar Bitcoin por falcatruas “cripto” é como culpar o TCP/IP ou SMTP por emails de phishing. É preguiçoso, desonesto e diz-nos mais sobre a autora do que sobre a tecnologia.

Promessas Por Cumprir? Só Se Não Estiveres a Ver

A "jornalista" da Visão lamenta que “após 15 anos, os riscos são reais mas as promessas por cumprir”. Que promessas? Dinheiro grátis? Cafés pagos com QR codes mágicos?

Bitcoin nunca prometeu fazer cappuccinos mais rápidos. Prometeu soberania monetária, resistência à censura e um sistema previsível. E tem cumprido — diariamente, para milhões. E para o cappuccino, há sempre a Lightning Network.

Pergunta aos venezuelanos, nigerianos, peruanos ou argentinos se Bitcoin falhou. Para muitos, é a única forma de escapar à hiperinflação, ao confisco estatal e à decadência financeira.

Bitcoin não é uma app. É infra-estrutura. É uma nova camada base para o dinheiro global. Não se vê — mas protege, impõe regras e não obedece a caprichos de banqueiros centrais.

E isso assusta. Especialmente quem nunca viveu fora da bolha do euro.

Conclusão: A Visão a Gritar Contra o Progresso

No fim, o artigo da Visão é um festival de clichés, dados errados e ressentimento. Não é só enganador. É desonesto. Culpa a tecnologia pelos erros dos homens. Rejeita o futuro em nome do conforto passado.

Bitcoin não é uma varinha mágica. Mas é a fundação de uma nova liberdade financeira. Uma ferramenta para proteger valor, resistir a abusos e escapar ao controlo constante de quem acha que sabe o que é melhor para ti.

Portanto, fica aqui o desafio, Sofia: se queres criticar Bitcoin, primeiro percebe o que é. Lê o white paper. Estuda. Faz perguntas difíceis.

Caso contrário, és só mais um cão a ladrar para a trovoada — muito barulho, zero impacto.

@ 0e29efc2:ff142af2

Table of Contents

1. Intro
2. Important Terminology
3. Getting Started
4. Where do I buy bitcoin?
5. Okay, I bought some bitcoin-now what?
6. Less than 0.01 BTC
7. More than 0.01 BTC and less than 0.1 BTC
8. More than 0.1 BTC
9. How Bitcoin Works
10. Skepticism
11. Someone will hack it
12. The government will try to stop it
13. It’s not backed by anything
14. Conclusion

Intro

Maybe you saw an article in Forbes, a news segment about MicroStrategy (MSTR), or you glanced at the bitcoin price chart; whatever the spark, your curiosity led you here. Enough friends and relatives keep asking me about bitcoin that I finally organized my thoughts into a single reference. This is not a comprehensive guide—it assumes you trust me as a heuristic.

Important Terminology

Sat (satoshi) – the smallest unit of bitcoin. One bitcoin (₿) equals 100 000 000 sats.

Getting Started

Where do I buy bitcoin?

I use River because it publishes proof‑of‑reserves, supports the Lightning Network, and pays interest on idle USD balances (currently 3.8 %).

Okay, I bought some bitcoin-now what?

Withdraw it immediately. Centralized exchanges can and do fail. Your next step depends on how much bitcoin you hold.

If at any point you're struggling, please reach out to me.

Less than 0.01 BTC

1. On your phone open Safari (iOS) or Chrome (Android).
2. Paste https://wallet.cashu.me?mint=https://mint.westernbtc.com. Confirm the prompt that asks whether you trust https://mint.westernbtc.com. I run this mint so beginners can skip the gnarly parts.
3. Complete setup.
4. Tap Receive → LIGHTNING → enter amount → COPY.
5. In River choose Send → Send to a Bitcoin wallet, paste the invoice, verify, and send.
6. Return to the wallet; your sats should appear.

More than 0.01 BTC and less than 0.1 BTC

It's time for cold storage. Cold storage means a dedicated signing device not connected to the internet. Think of it like keys to a house. If you have the keys (your cold storage signing device), you can get into your house (the bitcoin). I recommend and use the COLDCARD Q or COLDCARD MK4 from COLDCARD. See this thorough walkthrough.

The creator nostr:npub1rxysxnjkhrmqd3ey73dp9n5y5yvyzcs64acc9g0k2epcpwwyya4spvhnp8 makes reliable content.

More than 0.1 BTC

The next security upgrade involves something called multisig. It requires the use of multiple devices instead of one. Think of those nuclear launch silos in movies where two keys need to be turned in order to launch the missile. One person can't reach both keys, so you need two people. Like the two keys needing to be turned, we need a certain number of keys (signing devices) to be used.

This offers a number of benefits. Say you have a 2-of-3 multisig setup. You would need two of the three keys to move the bitcoin. If you were to lose one, you could use the two others to move it instead. Many choose to geographically distribute the keys; choosing to keep one at a friend’s house or with a bank.

The previous video I linked covers multisig as well. Again, please reach out to me if you need help.

How Bitcoin Works

I'm going to paint a scene portraying the basics of how bitcoin works. Picture a race that's supposed to take 10 minutes to run start-to-finish, and there's a crowd of people spectating. When the fastest runner crosses the finish line, they're awarded 50 bitcoin. Everyone in the crowd recognizes who won, and writes it down on their own scoreboard. Then, the next race begins.

Now, let's say more racers who've had special training join. They start winning consistently because of it, and now the race only lasts about 9 minutes. There's a special rule everyone in the crowd agreed to, that they can make the race harder to ensure it's around 10 minutes long. So they make the race harder to counteract the faster runners.

With this in mind, let's get to the skepticism you might have.

Skepticism

Someone will hack it

Think of bitcoin as the people in the crowd. If someone tries to cheat and writes on their scoreboard that they have a billion bitcoin, their scoreboard is going to look different than everybody else’s. The other people in the crowd will cross-reference with each other and decide to ignore that person who cheated.

The government will try to stop it

Again, think of the crowd. In reality, the "crowd participants" are scattered all around the world. You might be able to stop many of them, but it would be almost impossible to stop everyone. Imagine people are watching the race on TV, can you find everyone who's spectating? Ironically, attempted bans often increase interest.

It’s not backed by anything.

Think of the runners. The runners are bitcoin miners. They have to expend real energy to participate in the race. The more bitcoin miners, the more secure the network. In summary, it's backed by electricity and work.

Conclusion

There are too many topics to cover in one article. I haven't even touched on the history of money, what money is, scarcity, etc. The best way to learn is to research the topics you're interested in for yourself. It took months of deep diving before I was sold on bitcoin, and I had many touch points before that.

Once you see it though, you can't unsee it.

@ 8f69ac99:4f92f5fd

A concepção popular de "anarquia" evoca frequentemente caos, colapso e violência. Mas e se anarquia significasse outra coisa? E se representasse um mundo onde as pessoas cooperam e se coordenam sem autoridades impostas? E se implicasse liberdade, ordem voluntária e resiliência—sem coerção?

Bitcoin é um dos raros exemplos funcionais de princípios anarquistas em acção. Não tem CEO, nem Estado, nem planeador central—e, no entanto, o sistema funciona. Faz cumprir regras. Propõe um novo modelo de governação e oferece uma exploração concreta do anarcocapitalismo.

Para o compreendermos, temos de mudar de perspectiva. Bitcoin não é apenas software ou um instrumento de investimento—é um sistema vivo: uma ordem espontânea.

Ordem Espontânea, Teoria dos Jogos e o Papel dos Incentivos Económicos

Na política e economia contemporâneas, presume-se geralmente que a ordem tem de vir de cima. Governos, corporações e burocracias são vistos como essenciais para organizar a sociedade em grande escala.

Mas esta crença nem sempre se verifica.

Os mercados surgem espontaneamente da troca. A linguagem evolui sem supervisão central. Projectos de código aberto prosperam graças a contribuições voluntárias. Nenhum destes sistemas precisa de um rei—e, no entanto, têm estrutura e funcionam.

Bitcoin insere-se nesta tradição de ordens emergentes. Não é ditado por uma entidade única, mas é governado através de código, consenso dos utilizadores e incentivos económicos que recompensam a cooperação e penalizam a desonestidade.

Código Como Constituição

Bitcoin funciona com base num conjunto de regras de software transparentes e verificáveis. Estas regras determinam quem pode adicionar blocos, com que frequência, o que constitui uma transacção válida e como são criadas novas moedas.

Estas regras não são impostas por exércitos nem pela polícia. São mantidas por uma rede descentralizada de milhares de nós, cada um a correr voluntariamente software que valida o cumprimento das regras. Se alguém tentar quebrá-las, o resto da rede simplesmente rejeita a sua versão.

Isto não é governo por maioria—é aceitação baseada em regras.

Cada operador de nó escolhe qual versão do software quer executar. Se uma alteração proposta não tiver consenso suficiente, não se propaga. Foi assim que as "guerras do tamanho do bloco" foram resolvidas—não por votação, mas através de sinalização do que os utilizadores estavam dispostos a aceitar.

Este modelo de governação ascendente é voluntário, sem permissões, e extraordinariamente resiliente. Representa um novo paradigma de sistemas autorregulados.

Mineiros, Incentivos e a Segurança Baseada na Teoria dos Jogos

Bitcoin assegura a sua rede utilizando a Teoria de Jogos. Os mineiros que seguem o protocolo são recompensados financeiramente. Quem tenta enganar—como reescrever blocos ou gastar duas vezes—sofre perdas financeiras e desperdiça recursos.

Agir honestamente é mais lucrativo.

A genialidade de Bitcoin está em alinhar incentivos egoístas com o bem comum. Elimina a necessidade de confiar em administradores ou esperar benevolência. Em vez disso, torna a fraude economicamente irracional.

Isto substitui o modelo tradicional de "confiar nos líderes" por um mais robusto: construir sistemas onde o mau comportamento é desencorajado por design.

Isto é segurança anarquista—não a ausência de regras, mas a ausência de governantes.

Associação Voluntária e Confiança Construída em Consenso

Qualquer pessoa pode usar Bitcoin. Não há controlo de identidade, nem licenças, nem processo de aprovação. Basta descarregar o software e começar a transaccionar.

Ainda assim, Bitcoin não é um caos desorganizado. Os utilizadores seguem regras rigorosas do protocolo. Porquê? Porque é o consenso que dá valor às "moedas". Sem ele, a rede fragmenta-se e falha.

É aqui que Bitcoin desafia as ideias convencionais sobre anarquia. Mostra que sistemas voluntários podem gerar estabilidade—não porque as pessoas são altruístas, mas porque os incentivos bem desenhados tornam a cooperação a escolha racional.

Bitcoin é sem confiança (trustless), mas promove confiança.

Uma Prova de Conceito Viva

Muitos acreditam que, sem controlo central, a sociedade entraria em colapso. Bitcoin prova que isso não é necessariamente verdade.

É uma rede monetária global, sem permissões, capaz de fazer cumprir direitos de propriedade, coordenar recursos e resistir à censura—sem uma autoridade central. Baseia-se apenas em regras, incentivos e participação voluntária.

Bitcoin não é um sistema perfeito. É um projecto dinâmico, em constante evolução. Mas isso faz parte do que o torna tão relevante: é real, está a funcionar e continua a melhorar.

Conclusão

A anarquia não tem de significar caos. Pode significar cooperação sem coerção. Bitcoin prova isso.

Procuramos, desesperados, por alternativas às instituições falhadas, inchadas e corruptas. Bitcoin oferece mais do que dinheiro digital. É uma prova viva de que podemos construir sociedades descentralizadas, eficientes e justas.

E isso, por si só, já é revolucionário.

---

Photo by Floris Van Cauwelaert on Unsplash

@ 8f69ac99:4f92f5fd

À medida que Portugal se aproxima das eleições legislativas de 2025, a 18 de Maio, torna-se essencial compreender as diferentes propostas políticas e os programas eleitorais dos partidos para votar de forma informada. Este artigo funciona como um índice para uma série de análises realizadas aos programas dos principais partidos, com foco em temas como liberdades individuais, descentralização e crescimento económico.

---

A Evolução da Esquerda e da Direita: Um Contexto Histórico e Ideológico

Os termos “esquerda” e “direita” surgiram na Revolução Francesa (1789–1799) para distinguir quem se sentava ao lado do presidente da Assembleia: as forças favoráveis às reformas radicais (à esquerda) e as defensoras da monarquia e da ordem estabelecida (à direita). Com o século XIX e o advento do liberalismo económico, a direita passou a associar-se ao livre mercado e ao direito de propriedade, enquanto a esquerda defendeu maior intervenção estatal para promover igualdade.

No final do século XIX e início do século XX, surgiram o socialismo e o comunismo como correntes mais radicais da esquerda, propondo a abolição da propriedade privada dos meios de produção (comunismo) ou sistemas mistos com forte regulação e redistribuição (socialismo). A resposta liberal-conservadora evoluiu para o capitalismo democrático, que combina mercado livre com alguns mecanismos de assistência social.

Hoje, o espectro político vai além do simples eixo esquerda–direita, incluindo dimensões como:

• Autoritarismo vs. Liberdade: grau de controlo do Estado sobre a vida individual e as instituições;
• Intervenção Estatal vs. Livre Mercado: equilíbrio entre regulação económica e iniciativas privadas;
• Igualdade Social vs. Mérito e Responsabilidade Individual: ênfase na redistribuição de recursos ou na criação de incentivos pessoais.

Este modelo multidimensional ajuda a capturar melhor as posições dos partidos contemporâneos e as suas promessas de governação.

---

Visão Geral das Análises por Partido

Segue-se um resumo dos principais partidos políticos em Portugal, com destaque para a sua orientação ideológica segundo as dimensões de autoritarismo, nível de Intervenção estatal e grau de liberdade individual. Cada nome de partido estará ligado à respectiva análise detalhada.

| Partido | Orientação Ideológica | Nível de Intervenção Estatal | Grau de Liberdade Individual | |----------------------------------------|---------------------------------------------------------------------------------------|------------------------------|------------------------------| | AD – Aliança Democrática (PSD/CDS) | Centro-direita democrática (baixo autoritarismo / equilíbrio intervenção–mercado) | Médio | Médio | | PS – Partido Socialista | Centro-esquerda social-democrata (moderado autoritarismo / intervenção estatal) | Alto | Médio | | CDU – Coligação Democrática Unitária (PCP/PEV) | Esquerda comunista/eco-marxista (mais autoritário / forte intervenção) | Muito alto | Baixo | | IL – Iniciativa Liberal | Liberalismo clássico (muito baixa intervenção / alta liberdade) | Baixo | Muito alto | | Chega | Nacionalismo autoritário (controlo social elevado / mercado regulado com foco interno)| Médio | Baixo | | Livre | Esquerda progressista verde (baixa hierarquia / intervenção social) | Alto | Médio | | BE – Bloco de Esquerda | Esquerda democrática radical (moderado autoritarismo / intervenção forte) | Alto | Médio | | PAN – Pessoas-Animais-Natureza | Ambientalismo progressista (intervenção pragmática / foco em direitos e sustentabilidade) | Médio | Alto | | Ergue-te | Nacionalismo soberanista (autoritarismo elevado / intervenção seletiva com foco nacional) | Médio | Baixo | | ADN – Alternativa Democrática Nacional | Nacionalismo conservador (autoritarismo elevado / intervenção seletiva com foco nacional) | Médio | Baixo |

---

Análises Detalhadas dos Programas Eleitorais

Estas análises pretendem oferecer aos eleitores uma visão clara e objetiva das propostas de cada partido, facilitando decisões conscientes nas urnas. Ao focar-se nas promessas relacionadas com liberdades individuais, descentralização e crescimento económico, este conjunto de textos ajuda a compreender melhor o impacto potencial de cada escolha política.

Aliança Democrática (AD)

Partido Socialista (PS)

Coligação Democrática Unitária (CDU)

Iniciativa Liberal (IL)

Chega

Livre

Bloco de Esquerda (BE)

Pessoas,Animais e Natureza (PAN)

Alternativa Democrática Nacional (ADN)

Ergue-te

---

Photo by Brett Kunsch on Unsplash

@ 3bf0c63f:aefa459d

Redistributing Git with Nostr

Every time someone tries to "decentralize" Git -- like many projects tried in the past to do it with BitTorrent, IPFS, ScuttleButt or custom p2p protocols -- there is always a lurking comment: "but Git is already distributed!", and then the discussion proceeds to mention some facts about how Git supports multiple remotes and its magic syncing and merging abilities and so on.

Turns out all that is true, Git is indeed all that powerful, and yet GitHub is the big central hub that hosts basically all Git repositories in the giant world of open-source. There are some crazy people that host their stuff elsewhere, but these projects end up not being found by many people, and even when they do they suffer from lack of contributions.

Because everybody has a GitHub account it's easy to open a pull request to a repository of a project you're using if it's on GitHub (to be fair I think it's very annoying to have to clone the repository, then add it as a remote locally, push to it, then go on the web UI and click to open a pull request, then that cloned repository lurks forever in your profile unless you go through 16 screens to delete it -- but people in general seem to think it's easy).

It's much harder to do it on some random other server where some project might be hosted, because now you have to add 4 more even more annoying steps: create an account; pick a password; confirm an email address; setup SSH keys for pushing. (And I'm not even mentioning the basic impossibility of offering push access to external unknown contributors to people who want to host their own simple homemade Git server.)

At this point some may argue that we could all have accounts on GitLab, or Codeberg or wherever else, then those steps are removed. Besides not being a practical strategy this pseudo solution misses the point of being decentralized (or distributed, who knows) entirely: it's far from the ideal to force everybody to have the double of account management and SSH setup work in order to have the open-source world controlled by two shady companies instead of one.

What we want is to give every person the opportunity to host their own Git server without being ostracized. at the same time we must recognize that most people won't want to host their own servers (not even most open-source programmers!) and give everybody the ability to host their stuff on multi-tenant servers (such as GitHub) too. Importantly, though, if we allow for a random person to have a standalone Git server on a standalone server they host themselves on their wood cabin that also means any new hosting company can show up and start offering Git hosting, with or without new cool features, charging high or low or zero, and be immediately competing against GitHub or GitLab, i.e. we must remove the network-effect centralization pressure.

External contributions

The first problem we have to solve is: how can Bob contribute to Alice's repository without having an account on Alice's server?

SourceHut has reminded GitHub users that Git has always had this (for most) arcane git send-email command that is the original way to send patches, using an once-open protocol.

Turns out Nostr acts as a quite powerful email replacement and can be used to send text content just like email, therefore patches are a very good fit for Nostr event contents.

Once you get used to it and the proper UIs (or CLIs) are built sending and applying patches to and from others becomes a much easier flow than the intense clickops mixed with terminal copypasting that is interacting with GitHub (you have to clone the repository on GitHub, then update the remote URL in your local directory, then create a branch and then go back and turn that branch into a Pull Request, it's quite tiresome) that many people already dislike so much they went out of their way to build many GitHub CLI tools just so they could comment on issues and approve pull requests from their terminal.

Replacing GitHub features

Aside from being the "hub" that people use to send patches to other people's code (because no one can do the email flow anymore, justifiably), GitHub also has 3 other big features that are not directly related to Git, but that make its network-effect harder to overcome. Luckily Nostr can be used to create a new environment in which these same features are implemented in a more decentralized and healthy way.

Issues: bug reports, feature requests and general discussions

Since the "Issues" GitHub feature is just a bunch of text comments it should be very obvious that Nostr is a perfect fit for it.

I will not even mention the fact that Nostr is much better at threading comments than GitHub (which doesn't do it at all), which can generate much more productive and organized discussions (and you can opt out if you want).

Search

I use GitHub search all the time to find libraries and projects that may do something that I need, and it returns good results almost always. So if people migrated out to other code hosting providers wouldn't we lose it?

The fact is that even though we think everybody is on GitHub that is a globalist falsehood. Some projects are not on GitHub, and if we use only GitHub for search those will be missed. So even if we didn't have a Nostr Git alternative it would still be necessary to create a search engine that incorporated GitLab, Codeberg, SourceHut and whatnot.

Turns out on Nostr we can make that quite easy by not forcing anyone to integrate custom APIs or hardcoding Git provider URLs: each repository can make itself available by publishing an "announcement" event with a brief description and one or more Git URLs. That makes it easy for a search engine to index them -- and even automatically download the code and index the code (or index just README files or whatever) without a centralized platform ever having to be involved.

The relays where such announcements will be available play a role, of course, but that isn't a bad role: each announcement can be in multiple relays known for storing "public good" projects, some relays may curate only projects known to be very good according to some standards, other relays may allow any kind of garbage, which wouldn't make them good for a search engine to rely upon, but would still be useful in case one knows the exact thing (and from whom) they're searching for (the same is valid for all Nostr content, by the way, and that's where it's censorship-resistance comes from).

Continuous integration

GitHub Actions are a very hardly subsidized free-compute-for-all-paid-by-Microsoft feature, but one that isn't hard to replace at all. In fact there exists today many companies offering the same kind of service out there -- although they are mostly targeting businesses and not open-source projects, before GitHub Actions was introduced there were also many that were heavily used by open-source projects.

One problem is that these services are still heavily tied to GitHub today, they require a GitHub login, sometimes BitBucket and GitLab and whatnot, and do not allow one to paste an arbitrary Git server URL, but that isn't a thing that is very hard to change anyway, or to start from scratch. All we need are services that offer the CI/CD flows, perhaps using the same framework of GitHub Actions (although I would prefer to not use that messy garbage), and charge some few satoshis for it.

It may be the case that all the current services only support the big Git hosting platforms because they rely on their proprietary APIs, most notably the webhooks dispatched when a repository is updated, to trigger the jobs. It doesn't have to be said that Nostr can also solve that problem very easily.

@ 3bf0c63f:aefa459d

Report of how the money Jack donated to the cause in December 2022 has been misused so far.

Bounties given

March 2025

• Dhalsim: 1,110,540 - Work on Nostr wiki data processing

February 2025

• BOUNTY* NullKotlinDev: 950,480 - Twine RSS reader Nostr integration
• Dhalsim: 2,094,584 - Work on Hypothes.is Nostr fork
• Constant, Biz and J: 11,700,588 - Nostr Special Forces

January 2025

• Constant, Biz and J: 11,610,987 - Nostr Special Forces
• BOUNTY* NullKotlinDev: 843,840 - Feeder RSS reader Nostr integration
• BOUNTY* NullKotlinDev: 797,500 - ReadYou RSS reader Nostr integration

December 2024

• BOUNTY* tijl: 1,679,500 - Nostr integration into RSS readers yarr and miniflux
• Constant, Biz and J: 10,736,166 - Nostr Special Forces
• Thereza: 1,020,000 - Podcast outreach initiative

November 2024

• Constant, Biz and J: 5,422,464 - Nostr Special Forces

October 2024

• Nostrdam: 300,000 - hackathon prize
• Svetski: 5,000,000 - Latin America Nostr events contribution
• Quentin: 5,000,000 - nostrcheck.me

June 2024

• Darashi: 5,000,000 - maintaining nos.today, searchnos, search.nos.today and other experiments
• Toshiya: 5,000,000 - keeping the NIPs repo clean and other stuff

May 2024

• James: 3,500,000 - https://github.com/jamesmagoo/nostr-writer
• Yakihonne: 5,000,000 - spreading the word in Asia
• Dashu: 9,000,000 - https://github.com/haorendashu/nostrmo

February 2024

• Viktor: 5,000,000 - https://github.com/viktorvsk/saltivka and https://github.com/viktorvsk/knowstr
• Eric T: 5,000,000 - https://github.com/tcheeric/nostr-java
• Semisol: 5,000,000 - https://relay.noswhere.com/ and https://hist.nostr.land relays
• Sebastian: 5,000,000 - Drupal stuff and nostr-php work
• tijl: 5,000,000 - Cloudron, Yunohost and Fraidycat attempts
• Null Kotlin Dev: 5,000,000 - AntennaPod attempt

December 2023

• hzrd: 5,000,000 - Nostrudel
• awayuki: 5,000,000 - NOSTOPUS illustrations
• bera: 5,000,000 - getwired.app
• Chris: 5,000,000 - resolvr.io
• NoGood: 10,000,000 - nostrexplained.com stories

October 2023

• SnowCait: 5,000,000 - https://nostter.vercel.app/ and other tools
• Shaun: 10,000,000 - https://yakihonne.com/, events and work on Nostr awareness
• Derek Ross: 10,000,000 - spreading the word around the world
• fmar: 5,000,000 - https://github.com/frnandu/yana
• The Nostr Report: 2,500,000 - curating stuff
• james magoo: 2,500,000 - the Obsidian plugin: https://github.com/jamesmagoo/nostr-writer

August 2023

• Paul Miller: 5,000,000 - JS libraries and cryptography-related work
• BOUNTY tijl: 5,000,000 - https://github.com/github-tijlxyz/wikinostr
• gzuus: 5,000,000 - https://nostree.me/

July 2023

• syusui-s: 5,000,000 - rabbit, a tweetdeck-like Nostr client: https://syusui-s.github.io/rabbit/
• kojira: 5,000,000 - Nostr fanzine, Nostr discussion groups in Japan, hardware experiments
• darashi: 5,000,000 - https://github.com/darashi/nos.today, https://github.com/darashi/searchnos, https://github.com/darashi/murasaki
• jeff g: 5,000,000 - https://nostr.how and https://listr.lol, plus other contributions
• cloud fodder: 5,000,000 - https://nostr1.com (open-source)
• utxo.one: 5,000,000 - https://relaying.io (open-source)
• Max DeMarco: 10,269,507 - https://www.youtube.com/watch?v=aA-jiiepOrE
• BOUNTY optout21: 1,000,000 - https://github.com/optout21/nip41-proto0 (proposed nip41 CLI)
• BOUNTY Leo: 1,000,000 - https://github.com/leo-lox/camelus (an old relay thing I forgot exactly)

June 2023

• BOUNTY: Sepher: 2,000,000 - a webapp for making lists of anything: https://pinstr.app/
• BOUNTY: Kieran: 10,000,000 - implement gossip algorithm on Snort, implement all the other nice things: manual relay selection, following hints etc.
• Mattn: 5,000,000 - a myriad of projects and contributions to Nostr projects: https://github.com/search?q=owner%3Amattn+nostr&type=code
• BOUNTY: lynn: 2,000,000 - a simple and clean git nostr CLI written in Go, compatible with William's original git-nostr-tools; and implement threaded comments on https://github.com/fiatjaf/nocomment.
• Jack Chakany: 5,000,000 - https://github.com/jacany/nblog
• BOUNTY: Dan: 2,000,000 - https://metadata.nostr.com/

April 2023

• BOUNTY: Blake Jakopovic: 590,000 - event deleter tool, NIP dependency organization
• BOUNTY: koalasat: 1,000,000 - display relays
• BOUNTY: Mike Dilger: 4,000,000 - display relays, follow event hints (Gossip)
• BOUNTY: kaiwolfram: 5,000,000 - display relays, follow event hints, choose relays to publish (Nozzle)
• Daniele Tonon: 3,000,000 - Gossip
• bu5hm4nn: 3,000,000 - Gossip
• BOUNTY: hodlbod: 4,000,000 - display relays, follow event hints

March 2023

• Doug Hoyte: 5,000,000 sats - https://github.com/hoytech/strfry
• Alex Gleason: 5,000,000 sats - https://gitlab.com/soapbox-pub/mostr
• verbiricha: 5,000,000 sats - https://badges.page/, https://habla.news/
• talvasconcelos: 5,000,000 sats - https://migrate.nostr.com, https://read.nostr.com, https://write.nostr.com/
• BOUNTY: Gossip model: 5,000,000 - https://camelus.app/
• BOUNTY: Gossip model: 5,000,000 - https://github.com/kaiwolfram/Nozzle
• BOUNTY: Bounty Manager: 5,000,000 - https://nostrbounties.com/

February 2023

• styppo: 5,000,000 sats - https://hamstr.to/
• sandwich: 5,000,000 sats - https://nostr.watch/
• BOUNTY: Relay-centric client designs: 5,000,000 sats https://bountsr.org/design/2023/01/26/relay-based-design.html
• BOUNTY: Gossip model on https://coracle.social/: 5,000,000 sats
• Nostrovia Podcast: 3,000,000 sats - https://nostrovia.org/
• BOUNTY: Nostr-Desk / Monstr: 5,000,000 sats - https://github.com/alemmens/monstr
• Mike Dilger: 5,000,000 sats - https://github.com/mikedilger/gossip

January 2023

• ismyhc: 5,000,000 sats - https://github.com/Galaxoid-Labs/Seer
• Martti Malmi: 5,000,000 sats - https://iris.to/
• Carlos Autonomous: 5,000,000 sats - https://github.com/BrightonBTC/bija
• Koala Sat: 5,000,000 - https://github.com/KoalaSat/nostros
• Vitor Pamplona: 5,000,000 - https://github.com/vitorpamplona/amethyst
• Cameri: 5,000,000 - https://github.com/Cameri/nostream

December 2022

• William Casarin: 7 BTC - splitting the fund
• pseudozach: 5,000,000 sats - https://nostr.directory/
• Sondre Bjellas: 5,000,000 sats - https://notes.blockcore.net/
• Null Dev: 5,000,000 sats - https://github.com/KotlinGeekDev/Nosky
• Blake Jakopovic: 5,000,000 sats - https://github.com/blakejakopovic/nostcat, https://github.com/blakejakopovic/nostreq and https://github.com/blakejakopovic/NostrEventPlayground

@ 21335073:a244b1ad

The other day, I had the privilege of sitting down with one of my favorite living artists. Our conversation was so captivating that I felt compelled to share it. I’m leaving his name out for privacy.

Since our last meeting, I’d watched a documentary about his life, one he’d helped create. I told him how much I admired his openness in it. There’s something strange about knowing intimate details of someone’s life when they know so little about yours—it’s almost like I knew him too well for the kind of relationship we have.

He paused, then said quietly, with a shy grin, that watching the documentary made him realize how “odd and eccentric” he is. I laughed and told him he’s probably the sanest person I know. Because he’s lived fully, chasing love, passion, and purpose with hardly any regrets. He’s truly lived.

Today, I turn 44, and I’ll admit I’m a bit eccentric myself. I think I came into the world this way. I’ve made mistakes along the way, but I carry few regrets. Every misstep taught me something. And as I age, I’m not interested in blending in with the world—I’ll probably just lean further into my own brand of “weird.” I want to live life to the brim. The older I get, the more I see that the “normal” folks often seem less grounded than the eccentric artists who dare to live boldly. Life’s too short to just exist, actually live.

I’m not saying to be strange just for the sake of it. But I’ve seen what the crowd celebrates, and I’m not impressed. Forge your own path, even if it feels lonely or unpopular at times.

It’s easy to scroll through the news and feel discouraged. But actually, this is one of the most incredible times to be alive! I wake up every day grateful to be here, now. The future is bursting with possibility—I can feel it.

So, to my fellow weirdos on nostr: stay bold. Keep dreaming, keep pushing, no matter what’s trending. Stay wild enough to believe in a free internet for all. Freedom is radical—hold it tight. Live with the soul of an artist and the grit of a fighter. Thanks for inspiring me and so many others to keep hoping. Thank you all for making the last year of my life so special.

@ 51bbb15e:b77a2290

Yeah, I’m sure everything in the file is legit. 👍 Let’s review the guard witness testimony…Oh wait, they weren’t at their posts despite 24/7 survellience instructions after another Epstein “suicide” attempt two weeks earlier. Well, at least the video of the suicide is in the file? Oh wait, a techical glitch. Damn those coincidences!

At this point, the Trump administration has zero credibility with me on anything related to the Epstein case and his clients. I still suspect the administration is using the Epstein files as leverage to keep a lot of RINOs in line, whereas they’d be sabotaging his agenda at every turn otherwise. However, I just don’t believe in ends-justify-the-means thinking. It’s led almost all of DC to toss out every bit of the values they might once have had.

@ 34f1ddab:2ca0cf7c

Losing access to your cryptocurrency can feel like losing a part of your future. Whether it’s due to a forgotten password, a damaged seed backup, or a simple mistake in a transfer, the stress can be overwhelming. Fortunately, cryptrecver.com is here to assist! With our expert-led recovery services, you can safely and swiftly reclaim your lost Bitcoin and other cryptocurrencies.

Why Trust Crypt Recver? 🤝 🛠️ Expert Recovery Solutions At Crypt Recver, we specialize in addressing complex wallet-related issues. Our skilled engineers have the tools and expertise to handle:

Partially lost or forgotten seed phrases Extracting funds from outdated or invalid wallet addresses Recovering data from damaged hardware wallets Restoring coins from old or unsupported wallet formats You’re not just getting a service; you’re gaining a partner in your cryptocurrency journey.

🚀 Fast and Efficient Recovery We understand that time is crucial in crypto recovery. Our optimized systems enable you to regain access to your funds quickly, focusing on speed without compromising security. With a success rate of over 90%, you can rely on us to act swiftly on your behalf.

🔒 Privacy is Our Priority Your confidentiality is essential. Every recovery session is conducted with the utmost care, ensuring all processes are encrypted and confidential. You can rest assured that your sensitive information remains private.

💻 Advanced Technology Our proprietary tools and brute-force optimization techniques maximize recovery efficiency. Regardless of how challenging your case may be, our technology is designed to give you the best chance at retrieving your crypto.

Our Recovery Services Include: 📈 Bitcoin Recovery: Lost access to your Bitcoin wallet? We help recover lost wallets, private keys, and passphrases. Transaction Recovery: Mistakes happen — whether it’s an incorrect wallet address or a lost password, let us manage the recovery. Cold Wallet Restoration: If your cold wallet is failing, we can safely extract your assets and migrate them into a secure new wallet. Private Key Generation: Lost your private key? Our experts can help you regain control using advanced methods while ensuring your privacy. ⚠️ What We Don’t Do While we can handle many scenarios, some limitations exist. For instance, we cannot recover funds stored in custodial wallets or cases where there is a complete loss of four or more seed words without partial information available. We are transparent about what’s possible, so you know what to expect

Don’t Let Lost Crypto Hold You Back! Did you know that between 3 to 3.4 million BTC — nearly 20% of the total supply — are estimated to be permanently lost? Don’t become part of that statistic! Whether it’s due to a forgotten password, sending funds to the wrong address, or damaged drives, we can help you navigate these challenges

🛡️ Real-Time Dust Attack Protection Our services extend beyond recovery. We offer dust attack protection, keeping your activity anonymous and your funds secure, shielding your identity from unwanted tracking, ransomware, and phishing attempts.

🎉 Start Your Recovery Journey Today! Ready to reclaim your lost crypto? Don’t wait until it’s too late! 👉 cryptrecver.com

📞 Need Immediate Assistance? Connect with Us! For real-time support or questions, reach out to our dedicated team on: ✉️ Telegram: t.me/crypptrcver 💬 WhatsApp: +1(941)317–1821

Crypt Recver is your trusted partner in cryptocurrency recovery. Let us turn your challenges into victories. Don’t hesitate — your crypto future starts now! 🚀✨

Act fast and secure your digital assets with cryptrecver.com.Losing access to your cryptocurrency can feel like losing a part of your future. Whether it’s due to a forgotten password, a damaged seed backup, or a simple mistake in a transfer, the stress can be overwhelming. Fortunately, cryptrecver.com is here to assist! With our expert-led recovery services, you can safely and swiftly reclaim your lost Bitcoin and other cryptocurrencies.

# Why Trust Crypt Recver? 🤝

🛠️ Expert Recovery Solutions\ At Crypt Recver, we specialize in addressing complex wallet-related issues. Our skilled engineers have the tools and expertise to handle:

• Partially lost or forgotten seed phrases
• Extracting funds from outdated or invalid wallet addresses
• Recovering data from damaged hardware wallets
• Restoring coins from old or unsupported wallet formats

You’re not just getting a service; you’re gaining a partner in your cryptocurrency journey.

🚀 Fast and Efficient Recovery\ We understand that time is crucial in crypto recovery. Our optimized systems enable you to regain access to your funds quickly, focusing on speed without compromising security. With a success rate of over 90%, you can rely on us to act swiftly on your behalf.

🔒 Privacy is Our Priority\ Your confidentiality is essential. Every recovery session is conducted with the utmost care, ensuring all processes are encrypted and confidential. You can rest assured that your sensitive information remains private.

💻 Advanced Technology\ Our proprietary tools and brute-force optimization techniques maximize recovery efficiency. Regardless of how challenging your case may be, our technology is designed to give you the best chance at retrieving your crypto.

Our Recovery Services Include: 📈

• Bitcoin Recovery: Lost access to your Bitcoin wallet? We help recover lost wallets, private keys, and passphrases.
• Transaction Recovery: Mistakes happen — whether it’s an incorrect wallet address or a lost password, let us manage the recovery.
• Cold Wallet Restoration: If your cold wallet is failing, we can safely extract your assets and migrate them into a secure new wallet.
• Private Key Generation: Lost your private key? Our experts can help you regain control using advanced methods while ensuring your privacy.

⚠️ What We Don’t Do\ While we can handle many scenarios, some limitations exist. For instance, we cannot recover funds stored in custodial wallets or cases where there is a complete loss of four or more seed words without partial information available. We are transparent about what’s possible, so you know what to expect

# Don’t Let Lost Crypto Hold You Back!

Did you know that between 3 to 3.4 million BTC — nearly 20% of the total supply — are estimated to be permanently lost? Don’t become part of that statistic! Whether it’s due to a forgotten password, sending funds to the wrong address, or damaged drives, we can help you navigate these challenges

🛡️ Real-Time Dust Attack Protection\ Our services extend beyond recovery. We offer dust attack protection, keeping your activity anonymous and your funds secure, shielding your identity from unwanted tracking, ransomware, and phishing attempts.

🎉 Start Your Recovery Journey Today!\ Ready to reclaim your lost crypto? Don’t wait until it’s too late!\ 👉 cryptrecver.com

📞 Need Immediate Assistance? Connect with Us!\ For real-time support or questions, reach out to our dedicated team on:\ ✉️ Telegram: t.me/crypptrcver\ 💬 WhatsApp: +1(941)317–1821

Crypt Recver is your trusted partner in cryptocurrency recovery. Let us turn your challenges into victories. Don’t hesitate — your crypto future starts now! 🚀✨

Act fast and secure your digital assets with cryptrecver.com.

@ c11cf5f8:4928464d

Let's hear some of your latest Bitcoin purchases, feel free to include links to the shops or merchants you bought from too!

If you missed our last thread, here are some of the items stackers recently spent their sats on.

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

@ 6c2d68ba:846525ec

Dear friend,

it seems like you have decided to turn your back on those walled gardens and set sails to enter uncharted territory. A world without walls, an open world, a world of beautiful chaos. At least for today, I don't intend guiding you out of the safe harbour onto the open, endless sea. Today, my only intent is sharing a few thoughts, before you depart.

As a wise man on Madeira once said, it's not so much about having the right answers, it's about asking the right questions. While I'm not certain whether I have found the right questions myself by now, let me share the current set with you:

• What causes the discomfort that drives you out of the walled garden onto the open sea?

• Are you trying to transfer from one walled garden to the next one, where the difference being a slightly friendlier colour on the wall?

• What are you hoping to find on the open sea that walled gardens cannot provide?

• What are you willing to sacrifice for freedom (of speech)?

• What will you need to keep the ship afloat?

• How will you react when you find yourself in the middle of a storm?

I sincerely believe that it's worthwile taking a step back before departing to reflect on the big picture and the underlying paradigm shift between walled gardens and nostr. This is not about building competitors to broken systems, this is not about mimicking centralised services, this is not about repeating the same mistakes over and over.

This is about building a new world, an open world without walled gardens and data silos.

Onwards!

@ 8f69ac99:4f92f5fd

Dizem-nos que a inflação é necessária. Mas e se for, afinal, a raiz da disfunção económica que enfrentamos?

A crença mainstream é clara: para estimular o crescimento, os governos devem poder desvalorizar a sua moeda — essencialmente, criar dinheiro do nada. Supostamente, isso incentiva o investimento, aumenta o consumo e permite responder a crises económicas. Esta narrativa foi repetida tantas vezes que se tornou quase um axioma — raramente questionado.

No centro desta visão está a lógica fiat-keynesiana: uma economia estável exige um banco central disposto a manipular o valor do dinheiro para alcançar certos objectivos políticos. Esta abordagem, inspirada por John Maynard Keynes, defende a intervenção estatal como forma de estabilizar a economia durante recessões. Na teoria, os investidores e consumidores beneficiam de taxas de juro artificiais e de maior poder de compra — um suposto ganho para todos.

Mas há outra perspectiva: a visão do dinheiro sólido (sound money, em inglês). Enraizada na escola austríaca e nos princípios da liberdade individual, esta defende que a manipulação monetária não é apenas desnecessária — é prejudicial. Uma moeda estável, não sujeita à depreciação arbitrária, é essencial para promover trocas voluntárias, empreendedorismo e crescimento económico genuíno.

Está na hora de desafiar esta sabedoria convencional. Ao longo dos próximos capítulos, vamos analisar os pressupostos errados que sustentam a lógica fiat-keynesiana e explorar os benefícios de um sistema baseado em dinheiro sólido — como Bitcoin. Vamos mostrar por que desvalorizar a moeda é moralmente questionável e economicamente prejudicial, e propor alternativas mais éticas e eficazes.

Este artigo (que surge em resposta ao "guru" Miguel Milhões) pretende iluminar as diferenças entre estas duas visões opostas e apresentar uma abordagem mais sólida e justa para a política económica — centrada na liberdade pessoal, na responsabilidade individual e na preservação de instituições financeiras saudáveis.

O Argumento Fiat: Por que Dizem que é Preciso Desvalorizar a Moeda

Este argumento parte geralmente de uma visão económica keynesiana e/ou estatista e assenta em duas ideias principais: o incentivo ao investimento e a necessidade de resposta a emergências.

Incentivo ao Investimento

Segundo os defensores do sistema fiat, se uma moeda como o ouro ou bitcoin valorizar ao longo do tempo, as pessoas tenderão a "acumular" essa riqueza em vez de investir em negócios produtivos. O receio é que, se guardar dinheiro se torna mais rentável do que investir, a economia entre em estagnação.

Esta ideia parte de uma visão simplista do comportamento humano. Na realidade, as pessoas tomam decisões financeiras com base em múltiplos factores. Embora seja verdade que activos valorizáveis são atractivos, isso não significa que os investimentos desapareçam. Pelo contrário, o surgimento de activos como bitcoin cria novas oportunidades de inovação e investimento.

Historicamente, houve crescimento económico em períodos de moeda sólida — como no padrão-ouro. Uma moeda estável e previsível pode incentivar o investimento, ao dar confiança nos retornos futuros.

Resposta a Emergências

A segunda tese é que os governos precisam de imprimir dinheiro rapidamente em tempos de crise — pandemias, guerras ou recessões. Esta capacidade de intervenção é vista como essencial para "salvar" a economia.

De acordo com economistas keynesianos, uma injecção rápida de liquidez pode estabilizar a economia e evitar colapsos sociais. No entanto, este argumento ignora vários pontos fundamentais:

• A política monetária não substitui a responsabilidade fiscal: A capacidade de imprimir dinheiro não torna automaticamente eficaz o estímulo económico.
• A inflação é uma consequência provável: A impressão de dinheiro pode levar a pressões inflacionistas, reduzindo o poder de compra dos consumidores e minando o próprio estímulo pretendido. Estamos agora a colher os "frutos" da impressão de dinheiro durante a pandemia.
• O timing é crítico: Intervenções mal cronometradas podem agravar a situação.

Veremos em seguida porque estes argumentos não se sustentam.

Rebatendo os Argumentos

O Investimento Não Morre num Sistema de Dinheiro Sólido

O argumento de que o dinheiro sólido mata o investimento falha em compreender a ligação entre poupança e capital. Num sistema sólido, a poupança não é apenas acumulação — é capital disponível para financiar novos projectos. Isso conduz a um crescimento mais sustentável, baseado na qualidade e não na especulação.

Em contraste, o sistema fiat, com crédito barato, gera bolhas e colapsos — como vimos em 2008 ou na bolha dot-com. Estes exemplos ilustram os perigos da especulação facilitada por políticas monetárias artificiais.

Já num sistema de dinheiro sólido, como o que cresce em torno de Bitcoin, vemos investimentos em mineração, startups, educação e arte. Os investidores continuam activos — mas fazem escolhas mais responsáveis e de longo prazo.

Imprimir Dinheiro Não Resolve Crises

A ideia de que imprimir dinheiro é essencial em tempos de crise parte de uma ilusão perigosa. A inflação que se segue reduz o poder de compra e afecta especialmente os mais pobres — é uma forma oculta de imposto.

Além disso, soluções descentralizadas — como os mercados, redes comunitárias e poupança — são frequentemente mais eficazes. A resposta à COVID-19 ilustra isso: grandes empresas foram salvas, mas pequenos negócios e famílias ficaram para trás. Os últimos receberam um amuse-bouche, enquanto os primeiros comeram o prato principal, sopa, sobremesa e ainda levaram os restos.

A verdade é que imprimir dinheiro não cria valor — apenas o redistribui injustamente. A verdadeira resiliência nasce de comunidades organizadas e de uma base económica saudável, não de decretos políticos.

Dois Mundos: Fiat vs. Dinheiro Sólido

| Dimensão | Sistema Fiat-Keynesiano | Sistema de Dinheiro Sólido | |----------|--------------------------|-----------------------------| | Investimento | Estimulado por crédito fácil, alimentando bolhas | Baseado em poupança real e oportunidades sustentáveis | | Resposta a crises | Centralizada, via impressão de moeda | Descentralizada, baseada em poupança e solidariedade | | Preferência temporal | Alta: foco no consumo imediato | Baixa: foco na poupança e no futuro | | Distribuição de riqueza | Favorece os próximos ao poder (Efeito Cantillon) | Benefícios da deflação são distribuídos de forma mais justa | | Fundamento moral | Coercivo e redistributivo | Voluntário e baseado na liberdade individual |

Estes contrastes mostram que a escolha entre os dois sistemas vai muito além da economia — é também uma questão ética.

Consequências de Cada Sistema

O Mundo Fiat

Num mundo dominado pelo sistema fiat, os ciclos de euforia e colapso são a norma. A desigualdade aumenta, com os mais próximos ao poder a lucrar com a inflação e a impressão de dinheiro. A poupança perde valor, e a autonomia financeira das pessoas diminui.

À medida que o Estado ganha mais controlo sobre a economia, os cidadãos perdem capacidade de escolha e dependem cada vez mais de apoios governamentais. Esta dependência destrói o espírito de iniciativa e promove o conformismo.

O resultado? Estagnação, conflitos sociais e perda de liberdade.

O Mundo com Dinheiro Sólido

Com uma moeda sólida, o crescimento é baseado em valor real. As pessoas poupam mais, investem melhor e tornam-se mais independentes financeiramente. As comunidades tornam-se mais resilientes, e a cooperação substitui a dependência estatal.

Benefícios chave:

• Poupança real: A moeda não perde valor, e a riqueza pode ser construída com estabilidade.
• Resiliência descentralizada: Apoio mútuo entre indivíduos e comunidades em tempos difíceis.
• Liberdade económica: Menor interferência política e mais espaço para inovação e iniciativa pessoal.

Conclusão

A desvalorização da moeda não é uma solução — é um problema. Os sistemas fiat estão desenhados para transferir riqueza e poder de forma opaca, perpetuando injustiças e instabilidade.

Por outro lado, o dinheiro sólido — como Bitcoin — oferece uma alternativa credível e ética. Promove liberdade, responsabilidade e transparência. Impede abusos de poder e expõe os verdadeiros custos da má governação.

Não precisamos de mais inflação — precisamos de mais integridade.

Está na hora de recuperarmos o controlo sobre a nossa vida financeira. De rejeitarmos os sistemas que nos empobrecem lentamente e de construirmos um futuro em que o dinheiro serve as pessoas — e não os interesses políticos.

O futuro do dinheiro pode e deve ser diferente. Juntos, podemos criar uma economia mais justa, livre e resiliente — onde a prosperidade é partilhada e a dignidade individual respeitada.

---

Photo by rc.xyz NFT gallery on Unsplash

@ c9badfea:610f861a

1. Install Sky Map (it's free and open source)
2. Launch the app and tap Accept, then tap OK
3. When asked to access the device's location, tap While Using The App
4. Tap somewhere on the screen to activate the menu, then tap ⁝ and select Settings
5. Disable Send Usage Statistics
6. Return to the main screen and enjoy stargazing!

ℹ️ Use the 🔍 icon in the upper toolbar to search for a specific celestial body, or tap the 👁️ icon to activate night mode

@ 8f69ac99:4f92f5fd

No dia 2 de Abril de 2025, o Presidente dos Estados Unidos, Donald Trump, anunciou um novo pacote abrangente de tarifas com o objectivo de combater os desequilíbrios comerciais e revitalizar as indústrias nacionais. Foi imposta uma tarifa geral de 10% sobre todas as importações, com taxas mais elevadas—34% para a China e 20% para a União Europeia—em preparação para entrar em vigor. O anúncio reacendeu debates antigos sobre proteccionismo, globalização e o futuro do dólar norte-americano.

Embora estas medidas possam parecer extremas, as tarifas são um instrumento tradicional da política comercial internacional. Países de todo o mundo, incluindo a União Europeia, utilizam-nas rotineiramente para proteger indústrias estratégicas, regular o comércio e gerar receitas. A UE, por exemplo, impõe há muito tempo taxas sobre produtos norte-americanos como bens agrícolas, maquinaria e têxteis. Em contrapartida, os EUA já taxaram importações da UE, como o aço, alumínio e aeronaves, em disputas comerciais.

O que distingue a proposta de Trump é a sua escala, ambição e o objectivo mais amplo: reestruturar a economia dos EUA. Por detrás desta estratégia está uma realidade económica mais profunda—moldada por décadas de défices comerciais, endividamento crescente e o papel do dólar como moeda de reserva mundial. Este artigo explora como estes factores se cruzam, por que razão os EUA se encontram numa posição precária, e se políticas como tarifas elevadas, taxas de juro baixas ou até o Bitcoin podem apontar o caminho a seguir.

As Raízes da Crise: Sobreconsumo e Desindustrialização nos EUA

Durante décadas, os Estados Unidos "viveram acima das suas possibilidades", acumulando um défice comercial que actualmente ultrapassa os 800 mil milhões de dólares por ano. Este desequilíbrio—em que o país compra mais do que vende ao exterior—é sintoma de um problema mais profundo. No pós-Segunda Guerra Mundial, os EUA eram uma potência industrial. Mas, a partir dos anos 70, e com maior intensidade nos anos 90, a globalização transferiu a produção para o estrangeiro. As empresas procuraram custos de mão de obra mais baixos e os mercados norte-americanos encheram-se de produtos fabricados fora.

Para sustentar este consumo, os EUA apoiaram-se na sua posição privilegiada: a emissão da moeda de reserva mundial. Isso gerou um ciclo de endividamento, com o país a pedir emprestado ao exterior para manter o nível de vida. O resultado? Desindustrialização. Fábricas fecharam e milhões de empregos na indústria desapareceram em estados como Ohio, Michigan e Pensilvânia.

Hoje, os EUA produzem muito menos—em proporção ao seu tamanho—do que há algumas décadas, mesmo mantendo um apetite crescente por importações. O défice comercial expõe uma fragilidade estrutural: um país cada vez mais incapaz de sustentar-se através da sua própria produção. Os dólares gastos fora regressam muitas vezes sob a forma de compras de dívida pública, perpetuando o ciclo.

À medida que os défices crescem e a economia depende cada vez mais de mecanismos financeiros do que da produção real, surge uma questão inevitável: até quando poderá a América continuar a comprar a crédito antes que o cartão seja recusado?

O Dilema de Triffin: Moeda Global vs. Potência Industrial

Imagine ser a única pessoa numa cidade com uma impressora de dinheiro que todos usam. Para satisfazer a procura, continua a imprimir e a enviar notas para o exterior—até que o seu próprio negócio local entra em decadência e se torna dependente dos outros. Esta é a essência do Dilema de Triffin, e a corda bamba que os EUA têm vindo a atravessar há gerações.

O dilema surge quando a moeda de um país é usada como padrão global. O dólar—utilizado mundialmente para transacções de petróleo, comércio e reservas—precisa de estar amplamente disponível. Essa abundância provém de défices comerciais persistentes por parte dos EUA.

Mas os défices têm um custo. Os dólares enviados para fora voltam como procura por bens estrangeiros, enfraquecendo a produção interna. Porque fabricar um produto em Detroit por 10 dólares, quando se pode importar por $2? Com o tempo, isto destrói a base industrial do país.

Esta não é uma preocupação teórica—é uma realidade histórica. O economista Robert Triffin advertiu nos anos 60 que um país não pode simultaneamente manter a sua moeda como padrão mundial e conservar uma base industrial sólida. Os EUA confirmaram essa previsão. Após a guerra, os dólares ajudaram a reconstruir a Europa e o Japão, mas esses mesmos países tornaram-se concorrentes industriais dos EUA em sectores como o aço e a indústria automóvel.

As fábricas abandonadas no Midwest e os teares silenciosos no sul são marcas visíveis desta troca. O domínio do dólar concedeu influência global à América, mas às custas da sua produção.

Espiral da Dívida: Obrigações Financeiras Crescentes dos EUA

Em 2025, a dívida federal dos EUA ultrapassa os 36 biliões de dólares ($36 000 000 000 000 000 000)—cerca de 108 mil dólares por cada americano, adultos, jovens, idosos. Durante anos, o acesso fácil ao crédito e a procura global por dívida americana mascararam os riscos. Agora, as fissuras estão à vista.

O problema não é apenas o montante—é o prazo e o custo de manter esta dívida. Grande parte dela é de curto prazo, exigindo refinanciamentos frequentes. Com o aumento das taxas de juro, os custos associados disparam. Só em 2024, os pagamentos de juros ultrapassaram 1 bilião de dólares—mais do que os orçamentos combinados de educação, transportes e habitação.

A “Lei de Ferguson”, proposta pelo historiador Niall Ferguson, afirma que quando os juros da dívida superam os gastos militares, o império está em declínio. Em 2025, os EUA gastam cerca de 900 mil milhões em defesa, e os encargos com juros já os ultrapassaram.

Este ponto de viragem trouxe problemas a impérios do passado—do Reino Unido após a Primeira Guerra Mundial até Roma no seu declínio. Hoje, cresce o cepticismo quanto à saúde fiscal dos EUA. Países como a China e a Rússia estão a reduzir as suas reservas em dívida americana, preferindo ouro, yuan ou outros activos.

Se mais nações seguirem o mesmo caminho, os EUA terão de escolher: continuar a endividar-se para sustentar o sistema ou aceitar um papel reduzido para o dólar na economia mundial.

Desdolarização: A Mudança Global Longe do Dólar

A desdolarização refere-se à tendência crescente de reduzir a dependência do dólar nas transacções comerciais, reservas e sistemas financeiros. Embora o dólar ainda domine, a sua supremacia está sob crescente pressão de novas potências económicas e tensões geopolíticas.

Porque Está o Mundo a Afastar-se do Dólar?

1. Risco Económico: A volatilidade do dólar, agravada pela dívida e instabilidade política nos EUA, torna-o menos fiável como reserva de valor.
2. Instrumento Geopolítico: O uso do dólar pelos EUA para impor sanções leva rivais a procurar alternativas.

Alternativas Emergentes

• Ouro: Bancos centrais estão a reforçar as reservas em ouro como protecção.
• Commodities: Petróleo e cereais começam a ser transaccionados em moedas alternativas—como vendas de petróleo em yuan pela Arábia Saudita.
• Criptomoedas: Bitcoin e outros activos digitais ganham terreno como reservas neutras e descentralizadas.
• Moedas Regionais: Os países dos BRICS desenvolvem sistemas de pagamento e discutem uma moeda comum para reduzir a dependência do dólar.

Um Declínio Lento, Mas Visível

A percentagem do dólar nas reservas cambiais mundiais caiu de 70% no ano 2000 para menos de 60% actualmente. O comércio em moedas não-dólar cresceu 25% desde 2020. O domínio do dólar persiste, mas o movimento de mudança é claro.

A Estratégia Económica de Trump em 3 Etapas

Em 2025, Trump apresentou uma estratégia económica audaciosa em três frentes:

1. Tarifas Elevadas para Revitalizar a Indústria

Uma tarifa de 10% sobre todas as importações, com taxas superiores para países com superavit comercial, visa incentivar a produção interna. Críticos alertam para o aumento de preços e inflação, mas apoiantes defendem que é necessário para reindustrializar.

2. Redução das Taxas de Juro para Gerir a Dívida

A administração pressiona a Reserva Federal para baixar as taxas, reduzindo os encargos da dívida pública. Isto levanta preocupações sobre a independência do banco central e a estabilidade monetária a longo prazo.

3. Bitcoin como Activo Estratégico de Reserva

Num passo histórico, Trump assinou uma ordem executiva para criar a Reserva Estratégica de Bitcoin e o Stock Nacional de Activos Digitais. O objectivo é diversificar as reservas e proteger contra a inflação.

Riscos e Compensações

A estratégia económica de Trump não está isenta de riscos:

• Inflação: Tarifas mais altas poderão aumentar o custo de vida.
• Polarização Política: Medidas controversas poderão acentuar divisões internas.
• Incerteza Económica: O proteccionismo pode afastar investimento e travar a inovação.
• Instabilidade Monetária: Um erro na gestão da dívida ou dos activos digitais poderá enfraquecer o dólar.

Estes riscos exigem gestão cuidadosa para evitar agravar os problemas existentes.

O Papel de Bitcoin: Protecção ou Último Recurso?

Integrar Bitcoin nas reservas nacionais é ousado—mas pode ser revolucionário, e a meu ver, inevitável!

Vantagens

• Escassez: Com oferta limitada a 21 milhões de unidades, Bitcoin é deflacionário.
• Descentralização: Resistente à censura e manipulação, reforça a soberania financeira.
• Alcance Global: Sem fronteiras, permite trocas neutras num mundo multipolar.

Desafios

• Volatilidade: As flutuações no curto prazo são ainda significativas, mas a adopção institucional pode estabilizar o preço.
• Regulação: O enquadramento legal está em evolução, mas tende para maior clareza.
• Adopção Técnica: Persistem desafios de escalabilidade, embora soluções como a Lightning Network estejam a amadurecer.

A Reserva Estratégica de Bitcoin pode revelar-se visionária—ou precipitada. Tudo dependerá da execução e da aceitação global.

Futuros Possíveis: Crise ou Reinvenção?

Os EUA estão perante uma encruzilhada histórica. Um caminho aponta para a renovação: revitalizar a indústria e adoptar activos digitais, como por exemplo as stablecoins para perpetuar a hegemonia do dólar, lastreado em Bitcoin. O outro conduz à crise—com inflação, instabilidade e perda de influência global.

Num cenário optimista, os EUA emergem como líderes industriais e digitais, com reservas diversificadas que incluem Bitcoin. A recente ordem executiva para adquirir Bitcoin de forma neutra ao orçamento é um sinal positivo.

Num cenário pessimista, menos provável com as medidas em curso, o país mergulha em dívidas, vê o dólar enfraquecer e perde coesão interna. Mas com visão estratégica e inovação económica, há margem para navegar os desafios com sucesso.

Conclusão

A América enfrenta uma oportunidade única de redefinir o seu destino económico. A estratégia de Trump—baseada em tarifas, taxas de juro baixas e Bitcoin—pode marcar o início de uma nova era de resiliência e recuperação industrial.

A inclusão de Bitcoin nas reservas nacionais mostra que os instrumentos tradicionais já não bastam. Ao abraçar os activos digitais e restaurar a produção nacional, os EUA podem recuperar a liderança económica mundial.

O caminho será difícil. Mas com ousadia e execução eficaz, os Estados Unidos não só podem recuperar—podem reinventar-se.

---

Photo by Jon Tyson on Unsplash

@ 30ceb64e:7f08bdf5

Heres a scenario:

Imagine you have a nostr e-cash/Lightning Wallet and you would like to have a maximum receive balance of 20k split in between 5 mints that enable multipath payments.

Pick 5 mints below to store 4k sats each, the funds are automatically withdrawn to your lightning node at the end of the day.

Stacker News Robosats Sparrow Coinkite Start9 Rabbit Hole Recap @siggy47 Damus LND Your own mint

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

@ 04c915da:3dfbecc9

This piece is the first in a series that will focus on things I think are a priority if your focus is similar to mine: building a strong family and safeguarding their future.

---

Choosing the ideal place to raise a family is one of the most significant decisions you will ever make. For simplicity sake I will break down my thought process into key factors: strong property rights, the ability to grow your own food, access to fresh water, the freedom to own and train with guns, and a dependable community.

A Jurisdiction with Strong Property Rights

Strong property rights are essential and allow you to build on a solid foundation that is less likely to break underneath you. Regions with a history of limited government and clear legal protections for landowners are ideal. Personally I think the US is the single best option globally, but within the US there is a wide difference between which state you choose. Choose carefully and thoughtfully, think long term. Obviously if you are not American this is not a realistic option for you, there are other solid options available especially if your family has mobility. I understand many do not have this capability to easily move, consider that your first priority, making movement and jurisdiction choice possible in the first place.

Abundant Access to Fresh Water

Water is life. I cannot overstate the importance of living somewhere with reliable, clean, and abundant freshwater. Some regions face water scarcity or heavy regulations on usage, so prioritizing a place where water is plentiful and your rights to it are protected is critical. Ideally you should have well access so you are not tied to municipal water supplies. In times of crisis or chaos well water cannot be easily shutoff or disrupted. If you live in an area that is drought prone, you are one drought away from societal chaos. Not enough people appreciate this simple fact.

Grow Your Own Food

A location with fertile soil, a favorable climate, and enough space for a small homestead or at the very least a garden is key. In stable times, a small homestead provides good food and important education for your family. In times of chaos your family being able to grow and raise healthy food provides a level of self sufficiency that many others will lack. Look for areas with minimal restrictions, good weather, and a culture that supports local farming.

Guns

The ability to defend your family is fundamental. A location where you can legally and easily own guns is a must. Look for places with a strong gun culture and a political history of protecting those rights. Owning one or two guns is not enough and without proper training they will be a liability rather than a benefit. Get comfortable and proficient. Never stop improving your skills. If the time comes that you must use a gun to defend your family, the skills must be instinct. Practice. Practice. Practice.

A Strong Community You Can Depend On

No one thrives alone. A ride or die community that rallies together in tough times is invaluable. Seek out a place where people know their neighbors, share similar values, and are quick to lend a hand. Lead by example and become a good neighbor, people will naturally respond in kind. Small towns are ideal, if possible, but living outside of a major city can be a solid balance in terms of work opportunities and family security.

---

Let me know if you found this helpful. My plan is to break down how I think about these five key subjects in future posts.

@ 30ceb64e:7f08bdf5

It's wild. I just proved I can build #nostr 'wallet' where I can store the encrypted tokens in a Germany relay and make the lightning payment out of a Singapore mint. All using a #nsec that never leaves my machine. https://primal.net/e/note15l02rf4r474ck04mlrxxfagyl0z6t04ltsugf9dtph4xxhzfnd4sqpk74n

I’ve proven to myself that a #nostr wallet can exist across time and space, independently of any one app, server or custodian. The only thing which controls the ‘wallet’ is the generation and control of an #nsec which is free to exist within or flee any jurisdiction.

In my mind, this lays to rest the notion that a wallet needs to be an app, service, or anything that can be captured commercially or by the state. https://primal.net/e/note13nwsh852x9tfex2jade6vwymhhct8zussxr4zwy7uag24hjc9stq0xsxaf

https://image.nostr.build/07dd1b56d6bb60b13cfe6c19d9384bc3ef198d01af4be9a5c544f791b80b746a.png

I am thinking about coining the term “nsac” to refer to a wallet-like thing that can exist on #nostr holding your valuable things, such as ecash tokens. I have already implemented a prototype #cashu ecash wallet which looks to be promising.

So you would have:

npub - your identity

nsec - your private key

nsac - your valuables

Your #nsac could be the same as your #nsec but better case is to generate as many #nsacs as required.

Happy to hear feedback!

For reference, what a ‘sac’ is in the biological sense:

A sac is a biological term referring to a pouch or cavity in an organism that is typically enclosed and may contain fluid, air, or other substances. Sacs can serve various functions depending on their location and role in the body, such as protecting a developing embryo, facilitating the exchange of gases in the lungs, or reducing friction between moving parts in joints

https://primal.net/e/note1snj7y9m6f7lhfzkd2ujzqcvparpgddzmgcgwsgghqvkcyd0rkqhsmmlyla

npub1q6mcr8tlr3l4gus3sfnw6772s7zae6hqncmw5wj27ejud5wcxf7q0nx7d5

Wild stuff freaks, will nostr become the best lightning/E-Cash wallet? Let me know what you think.

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

@ 04c915da:3dfbecc9

Here’s a revised timeline of macro-level events from The Mandibles: A Family, 2029–2047 by Lionel Shriver, reimagined in a world where Bitcoin is adopted as a widely accepted form of money, altering the original narrative’s assumptions about currency collapse and economic control. In Shriver’s original story, the failure of Bitcoin is assumed amid the dominance of the bancor and the dollar’s collapse. Here, Bitcoin’s success reshapes the economic and societal trajectory, decentralizing power and challenging state-driven outcomes.

Part One: 2029–2032

• 2029 (Early Year)\ The United States faces economic strain as the dollar weakens against global shifts. However, Bitcoin, having gained traction emerges as a viable alternative. Unlike the original timeline, the bancor—a supranational currency backed by a coalition of nations—struggles to gain footing as Bitcoin’s decentralized adoption grows among individuals and businesses worldwide, undermining both the dollar and the bancor.

• 2029 (Mid-Year: The Great Renunciation)\ Treasury bonds lose value, and the government bans Bitcoin, labeling it a threat to sovereignty (mirroring the original bancor ban). However, a Bitcoin ban proves unenforceable—its decentralized nature thwarts confiscation efforts, unlike gold in the original story. Hyperinflation hits the dollar as the U.S. prints money, but Bitcoin’s fixed supply shields adopters from currency devaluation, creating a dual-economy split: dollar users suffer, while Bitcoin users thrive.

• 2029 (Late Year)\ Dollar-based inflation soars, emptying stores of goods priced in fiat currency. Meanwhile, Bitcoin transactions flourish in underground and online markets, stabilizing trade for those plugged into the bitcoin ecosystem. Traditional supply chains falter, but peer-to-peer Bitcoin networks enable local and international exchange, reducing scarcity for early adopters. The government’s gold confiscation fails to bolster the dollar, as Bitcoin’s rise renders gold less relevant.

• 2030–2031\ Crime spikes in dollar-dependent urban areas, but Bitcoin-friendly regions see less chaos, as digital wallets and smart contracts facilitate secure trade. The U.S. government doubles down on surveillance to crack down on bitcoin use. A cultural divide deepens: centralized authority weakens in Bitcoin-adopting communities, while dollar zones descend into lawlessness.

• 2032\ By this point, Bitcoin is de facto legal tender in parts of the U.S. and globally, especially in tech-savvy or libertarian-leaning regions. The federal government’s grip slips as tax collection in dollars plummets—Bitcoin’s traceability is low, and citizens evade fiat-based levies. Rural and urban Bitcoin hubs emerge, while the dollar economy remains fractured.

Time Jump: 2032–2047

• Over 15 years, Bitcoin solidifies as a global reserve currency, eroding centralized control. The U.S. government adapts, grudgingly integrating bitcoin into policy, though regional autonomy grows as Bitcoin empowers local economies.

Part Two: 2047

• 2047 (Early Year)\ The U.S. is a hybrid state: Bitcoin is legal tender alongside a diminished dollar. Taxes are lower, collected in BTC, reducing federal overreach. Bitcoin’s adoption has decentralized power nationwide. The bancor has faded, unable to compete with Bitcoin’s grassroots momentum.

• 2047 (Mid-Year)\ Travel and trade flow freely in Bitcoin zones, with no restrictive checkpoints. The dollar economy lingers in poorer areas, marked by decay, but Bitcoin’s dominance lifts overall prosperity, as its deflationary nature incentivizes saving and investment over consumption. Global supply chains rebound, powered by bitcoin enabled efficiency.

• 2047 (Late Year)\ The U.S. is a patchwork of semi-autonomous zones, united by Bitcoin’s universal acceptance rather than federal control. Resource scarcity persists due to past disruptions, but economic stability is higher than in Shriver’s original dystopia—Bitcoin’s success prevents the authoritarian slide, fostering a freer, if imperfect, society.

Key Differences

• Currency Dynamics: Bitcoin’s triumph prevents the bancor’s dominance and mitigates hyperinflation’s worst effects, offering a lifeline outside state control.
• Government Power: Centralized authority weakens as Bitcoin evades bans and taxation, shifting power to individuals and communities.
• Societal Outcome: Instead of a surveillance state, 2047 sees a decentralized, bitcoin driven world—less oppressive, though still stratified between Bitcoin haves and have-nots.

This reimagining assumes Bitcoin overcomes Shriver’s implied skepticism to become a robust, adopted currency by 2029, fundamentally altering the novel’s bleak trajectory.

@ 8f69ac99:4f92f5fd

Bitcoin tem-se afirmado como um meio de pagamento global, atraindo cada vez mais comerciantes e consumidores. Em Portugal, os pequenos e médios empresários têm uma oportunidade única para reduzir custos, expandir mercados e proteger-se da inflação ao aceitar bitcoin como opção pagamento.

Apesar das vantagens, muitos comerciantes enfrentam desafios significativos, especialmente no que toca às obrigações fiscais e à falta de conhecimento (ou vontade de aprender) por parte dos contabilistas. Questões como o registo contábil adequado, a tributação do IRC e a facturação com IVA ainda geram incerteza e dificultam a adopção da criptomoeda.

Este artigo explora como os comerciantes podem aceitar bitcoin de forma legal e eficiente, analisa os desafios fiscais e contábeis e apresenta soluções práticas para superar os obstáculos impostos pela regulamentação e pela falta de apoio dos profissionais de contabilidade.

Benefícios de Aceitar Bitcoin

1. Redução de Custos

Aceitar pagamentos em bitcoin permite evitar taxas bancárias elevadas, especialmente em transacções internacionais. Como as transferências ocorrem directamente entre carteiras digitais, sem a intermediação de bancos, os comerciantes podem poupar significativamente em comissões e taxas de processamento.

2. Liquidação Rápida

Diferente dos pagamentos bancários tradicionais, que podem demorar dias, uma transacção na rede Bitcoin pode ser confirmada em minutos, ou em segundos ou menos usando a Lightning Network. Isto reduz o tempo de espera para a disponibilidade dos fundos e melhora o fluxo de caixa dos comerciantes.

3. Expansão de Mercado

Os comerciantes podem atrair clientes internacionais e um público mais inovador e tecnológico. A aceitação de bitcoin pode diferenciar um negócio da concorrência e aumentar a base de clientes ao incluir entusiastas de criptomoedas e consumidores que preferem meios de pagamento descentralizados.

4. Protecção Contra Inflação

Bitcoin pode actuar como reserva de valor, protegendo o património contra desvalorizações monetárias. Em contextos de inflação elevada, manter parte do capital em Bitcoin pode ajudar a preservar o poder de compra a longo prazo.

| | |:--:| | Bruno de Gouveia da Care to Beauty - A Seita Bitcoin |

Como Funciona na Prática?

1. Aceitação Directa vs. Conversão Automática

Os comerciantes podem optar por aceitar bitcoin directamente, mantendo-o na sua carteira digital, ou utilizar serviços como OpenNode, Swiss Bitcoin Pay, Coincorner ou Coinbase para converter automaticamente os pagamentos em euros. A escolha depende da estratégia da empresa quanto à exposição à volatilidade da criptomoeda.

2. Configuração de Carteira Bitcoin

Para receber pagamentos directamente, o comerciante precisa de uma carteira Bitcoin segura, como Electrum, BlueWallet ou Aqua entre outras. Estas carteiras oferecem diferentes níveis de segurança e acessibilidade, permitindo que os comerciantes escolham a solução mais adequada ao seu modelo de negócio.

3. Facturação e Registo Contábil

Cada pagamento deve ser facturado em euros, com referência à taxa de câmbio do momento. O registo contábil deve ser feito correctamente para garantir a conformidade fiscal, reflectindo o valor recebido em bitcoin e a sua equivalência em euros na altura da transacção. Muitas carteiras e plataformas de pagamento oferecem relatórios detalhados que facilitam o registo contábil e a declaração fiscal.

Obrigações Fiscais e Contábeis

1. IRC (Imposto sobre o Rendimento das Pessoas Colectivas)

Os rendimentos obtidos através de bitcoin devem ser devidamente registados na contabilidade da empresa, uma vez que são considerados receitas operacionais. Para efeitos fiscais, a conversão do valor recebido em bitcoin deve ser feita com base na taxa de câmbio vigente no momento da transacção, garantindo um registo transparente e conforme com as normas contábeis.

Se a empresa optar por manter os bitcoins sem os converter imediatamente para euros, estes podem ser classificados como activos intangíveis, conforme a Norma Contabilística e de Relato Financeiro (NCRF), artigo 6. No entanto, se forem utilizados como meio de pagamento recorrente, por exemplo pagar a fornecedores que também aceitem bitcoin, podem ser classificados como inventário, dependendo da natureza da actividade empresarial.

No momento da venda ou conversão dos bitcoins para euros, qualquer mais-valia obtida é considerada um rendimento da empresa e estará sujeita a tributação em sede de IRC à taxa geral em vigor.

2. IVA (Imposto sobre o Valor Acrescentado)

As transacções de troca de bitcoin por euros estão isentas de IVA, conforme o artigo 9.º, alínea 27), subalínea d), do Código do IVA (CIVA), que reconhece as criptomoedas como meios de pagamento e as exclui da incidência de IVA.

No entanto, a venda de bens ou serviços pagos em bitcoin deve ser facturada normalmente, em euros, com a taxa de IVA correspondente ao produto ou serviço comercializado. Para garantir conformidade fiscal, a factura deve indicar a contrapartida em euros, com base na taxa de câmbio do momento da transacção, independentemente da moeda utilizada no pagamento.

Na prática, aceitar pagamento em bitcoin funciona de forma muito semelhante a aceitar pagamento em dinheiro físico... 😉

3. Registos e Demonstrações Financeiras

As empresas que aceitam bitcoin devem manter registos contabilísticos detalhados sobre todas as transacções realizadas. bitcoin pode ser registado como activo intangível ou inventário, dependendo do seu uso:

• Activo intangível: Quando a empresa detém bitcoin como reserva de valor ou investimento, registando-o ao custo de aquisição e procedendo a ajustamentos caso haja desvalorização relevante.
• Inventário: Se a empresa opera no sector de compra e venda de criptomoedas ou usa bitcoin para transacções comerciais frequentes, deve ser registado como inventário, seguindo as regras de mensuração aplicáveis a mercadorias.

As demonstrações financeiras devem reflectir correctamente a posse de bitcoin, incluindo informações sobre variações de valor ao longo do tempo. Os contabilistas devem garantir a correta apresentação destes activos nos balanços e relatórios anuais, o que pode exigir reavaliação periódica dos valores contabilizados.

O Obstáculo: Contabilistas e a Falta de Apoio

1. Falta de Conhecimento

Muitos TOC não estão familiarizados com a contabilidade de criptomoedas, o que gera incertezas e complicações para os comerciantes.

2. Resistência e Falta de Vontade

Em vez de se actualizarem, muitos contabilistas recusam-se a aprender sobre Bitcoin, deixando os comerciantes sem apoio adequado.

3. Impacto nos Negócios

Com a falta de informação e apoio dos TOC, muitos comerciantes evitam aceitar bitcoin, perdendo uma oportunidade de mercado.

Soluções e Alternativas

1. Educação e Autonomia

Os comerciantes podem aprender o essencial sobre contabilidade de bitcoin para questionar e orientar os seus contabilistas. Existem recursos online, cursos e materiais educativos que permitem aos empresários compreender as melhores práticas para registo e declaração das transacções em bitcoin.

2. Ferramentas e Software

Existem algumas plataformas que ajudam na gestão e declaração de criptomoedas, fornecendo relatórios detalhados sobre transacções, ganhos e impostos devidos. Essas ferramentas facilitam a organização financeira e reduzem erros contábeis.

3. Rede de Apoio

Juntar-se a comunidades de empresários e especialistas em bitcoin pode ajudar a encontrar soluções e recomendações de contabilistas competentes. Fóruns, grupos em redes sociais e associações focadas no tema podem ser excelentes fontes de suporte e partilha de experiências.

4. Links uteis

• Website Aceita Bitcoin
• Grupo Telegram Aceita Bitcoin
• Mario Moura Contabilidade
• MM Law

Conclusão

Aceitar bitcoin pode ser vantajoso para pequenos e médios comerciantes, mas a burocracia e a falta de conhecimento dos contabilistas dificultam esse processo. É essencial que os comerciantes exijam um melhor serviço dos seus TOC e procurem alternativas para garantir que estão em conformidade com a lei, aproveitando ao mesmo tempo os benefícios desta nova forma de pagamento.

---

Disclaimer: Este artigo é meramente informativo e não deve ser considerado como aconselhamento jurídico ou fiscal. É recomendável consultar um profissional qualificado para obter orientações específicas sobre a aceitação de bitcoin e as obrigações fiscais associadas. A legislação pode variar e é importante estar sempre actualizado com as normas vigentes. A responsabilidade pela aceitação de bitcoin e o cumprimento das obrigações fiscais recai exclusivamente sobre o comerciante. O autor não se responsabiliza por quaisquer consequências decorrentes da aceitação de bitcoin ou da interpretação das informações contidas neste artigo.

Photo by CardMapr.nl on Unsplash

@ 6ad3e2a3:c90b7740

I’ve written about MSTR twice already, https://www.chrisliss.com/p/mstr and https://www.chrisliss.com/p/mstr-part-2, but I want to focus on legendary short seller James Chanos’ current trade wherein he buys bitcoin (via ETF) and shorts MSTR, in essence to “be like Mike” Saylor who sells MSTR shares at the market and uses them to add bitcoin to the company’s balance sheet. After all, if it’s good enough for Saylor, why shouldn’t everyone be doing it — shorting a company whose stock price is more than 2x its bitcoin holdings and using the proceeds to buy the bitcoin itself?

Saylor himself has said selling shares at 2x NAV (net asset value) to buy bitcoin is like selling dollars for two dollars each, and Chanos has apparently decided to get in while the getting (market cap more than 2x net asset value) is good. If the price of bitcoin moons, sending MSTR’s shares up, you are more than hedged in that event, too. At least that’s the theory.

The problem with this bet against MSTR’s mNAV, i.e., you are betting MSTR’s market cap will converge 1:1 toward its NAV in the short and medium term is this trade does not exist in a vacuum. Saylor has described how his ATM’s (at the market) sales of shares are accretive in BTC per share because of this very premium they carry. Yes, we’ll dilute your shares of the company, but because we’re getting you 2x the bitcoin per share, you are getting an ever smaller slice of an ever bigger overall pie, and the pie is growing 2x faster than your slice is reducing. (I https://www.chrisliss.com/p/mstr how this works in my first post.)

But for this accretion to continue, there must be a constant supply of “greater fools” to pony up for the infinitely printable shares which contain only half their value in underlying bitcoin. Yes, those shares will continue to accrete more BTC per share, but only if there are more fools willing to make this trade in the future. So will there be a constant supply of such “fools” to keep fueling MSTR’s mNAV multiple indefinitely?

Yes, there will be in my opinion because you have to look at the trade from the prospective fools’ perspective. Those “fools” are not trading bitcoin for MSTR, they are trading their dollars, selling other equities to raise them maybe, but in the end it’s a dollars for shares trade. They are not selling bitcoin for them.

You might object that those same dollars could buy bitcoin instead, so they are surely trading the opportunity cost of buying bitcoin for them, but if only 5-10 percent of the market (or less) is buying bitcoin itself, the bucket in which which those “fools” reside is the entire non-bitcoin-buying equity market. (And this is not considering the even larger debt market which Saylor has yet to tap in earnest.)

So for those 90-95 percent who do not and are not presently planning to own bitcoin itself, is buying MSTR a fool’s errand, so to speak? Not remotely. If MSTR shares are infinitely printable ATM, they are still less so than the dollar and other fiat currencies. And MSTR shares are backed 2:1 by bitcoin itself, while the fiat currencies are backed by absolutely nothing. So if you hold dollars or euros, trading them for MSTR shares is an errand more sage than foolish.

That’s why this trade (buying BTC and shorting MSTR) is so dangerous. Not only are there many people who won’t buy BTC buying MSTR, there are many funds and other investment entities who are only able to buy MSTR.

Do you want to get BTC at 1:1 with the 5-10 percent or MSTR backed 2:1 with the 90-95 percent. This is a bit like medical tests that have a 95 percent accuracy rate for an asymptomatic disease that only one percent of the population has. If someone tests positive, it’s more likely to be a false one than an indication he has the disease*. The accuracy rate, even at 19:1, is subservient to the size of the respective populations.

At some point this will no longer be the case, but so long as the understanding of bitcoin is not widespread, so long as the dollar is still the unit of account, the “greater fools” buying MSTR are still miles ahead of the greatest fools buying neither, and the stock price and mNAV should only increase.

. . .

One other thought: it’s more work to play defense than offense because the person on offense knows where he’s going, and the defender can only react to him once he moves. Similarly, Saylor by virtue of being the issuer of the shares knows when more will come online while Chanos and other short sellers are borrowing them to sell in reaction to Saylor’s strategy. At any given moment, Saylor can pause anytime, choosing to issue convertible debt or preferred shares with which to buy more bitcoin, and the shorts will not be given advance notice.

If the price runs, and there is no ATM that week because Saylor has stopped on a dime, so to speak, the shorts will be left having to scramble to change directions and buy the shares back to cover. Their momentum might be in the wrong direction, though, and like Allen Iverson breaking ankles with a crossover, Saylor might trigger a massive short squeeze, rocketing the share price ever higher. That’s why he actually welcomes Chanos et al trying this copycat strategy — it becomes the fuel for outsized gains.

For that reason, news that Chanos is shorting MSTR has not shaken my conviction, though there are other more pertinent https://www.chrisliss.com/p/mstr-part-2 with MSTR, of which one should be aware. And as always, do your own due diligence before investing in anything.

* To understand this, consider a population of 100,000, with one percent having a disease. That means 1,000 have it, 99,000 do not. If the test is 95 percent accurate, and everyone is tested, 950 of the 1,000 will test positive (true positives), 50 who have it will test negative (false negatives.) Of the positives, 95 percent of 99,000 (94,050) will test negative (true negatives) and five percent (4,950) will test positive (false positives). That means 4,950 out of 5,900 positives (84%) will be false.

@ b83a28b7:35919450

This article was originally part of the sermon of Plebchain Radio Episode 111 (May 2, 2025) that nostr:nprofile1qyxhwumn8ghj7mn0wvhxcmmvqyg8wumn8ghj7mn0wd68ytnvv9hxgqpqtvqc82mv8cezhax5r34n4muc2c4pgjz8kaye2smj032nngg52clq7fgefr and I did with nostr:nprofile1qythwumn8ghj7ct5d3shxtnwdaehgu3wd3skuep0qyt8wumn8ghj7ct4w35zumn0wd68yvfwvdhk6tcqyzx4h2fv3n9r6hrnjtcrjw43t0g0cmmrgvjmg525rc8hexkxc0kd2rhtk62 and nostr:nprofile1qyxhwumn8ghj7mn0wvhxcmmvqyg8wumn8ghj7mn0wd68ytnvv9hxgqpq4wxtsrj7g2jugh70pfkzjln43vgn4p7655pgky9j9w9d75u465pqahkzd0 of the nostr:nprofile1qythwumn8ghj7ct5d3shxtnwdaehgu3wd3skuep0qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcqyqwfvwrccp4j2xsuuvkwg0y6a20637t6f4cc5zzjkx030dkztt7t5hydajn

Listen to the full episode here:

<<https://fountain.fm/episode/Ln9Ej0zCZ5dEwfo8w2Ho>>

---

Bitcoin has always been a narrative revolution disguised as code. White paper, cypherpunk lore, pizza‑day legends - every block is a paragraph in the world’s most relentless epic. But code alone rarely converts the skeptic; it’s the camp‑fire myth that slips past the prefrontal cortex and shakes hands with the limbic system. People don’t adopt protocols first - they fall in love with protagonists.

Early adopters heard the white‑paper hymn, but most folks need characters first: a pizza‑day dreamer; a mother in a small country, crushed by the cost of remittance; a Warsaw street vendor swapping złoty for sats. When their arcs land, the brain releases a neurochemical OP_RETURN which says, “I belong in this plot.” That’s the sly roundabout orange pill: conviction smuggled inside catharsis.

That’s why, from 22–25 May in Warsaw’s Kinoteka, the Bitcoin Film Fest is loading its reels with rebellion. Each documentary, drama, and animated rabbit‑hole is a stealth wallet, zipping conviction straight into the feels of anyone still clasped within the cold claw of fiat. You come for the plot, you leave checking block heights.

---

Here's the clip of the sermon from the episode:

nostr:nevent1qvzqqqqqqypzpwp69zm7fewjp0vkp306adnzt7249ytxhz7mq3w5yc629u6er9zsqqsy43fwz8es2wnn65rh0udc05tumdnx5xagvzd88ptncspmesdqhygcrvpf2

@ 8f69ac99:4f92f5fd

O Banco Central Europeu (BCE) está a intensificar a sua propagan... a sua campanha a favor do euro digital, apresentando-o como uma evolução necessária do dinheiro. Mas trata-se realmente de conveniência ou há uma agenda oculta? Vamos desmontar os argumentos do BCE e perceber por que razão esta moeda digital de banco central (CBDC) tem mais a ver com controlo do que com inovação financeira.

Argumento 1: 'A nossa moeda precisa de acompanhar a forma como queremos pagar.'

O BCE afirma que mais de metade dos europeus prefere pagamentos digitais, mas ignora o facto de que esses pagamentos já existem. Desde cartões bancários a PayPal, transferências SEPA, Apple Pay e Google Pay, não faltam opções. Em 2020 já 60% de todos os pagamentos na UE foram digitais, segundo dados do BCE.

O que não mencionam é que o euro digital será controlado pelo Estado (ou neste caso o BCE e a UE que são efectivamente um governo supranacional, não eleito) e programável. Ao contrário do dinheiro físico, que permite verdadeira autonomia financeira, uma CBDC permitirá ao governo monitorizar, condicionar e até restringir os teus gastos.

Já Bitcoin oferece há mais de 16 anos uma solução global, descentralizada e sem necessidade de permissão, sem precisar de supervisão estatal.

Argumento 2: 'Os europeus poderão usar o euro digital ao lado do dinheiro físico.'

A história mostra-nos que, sempre que surgem alternativas digitais estatais, o dinheiro físico acaba por ser eliminado. Restrições a levantamentos, proibições de transacções em numerário e a desvalorização do dinheiro físico são tácticas comuns para empurrar as pessoas para pagamentos digitais controlados.

Bitcoin não precisa de autorização e pode ser usado de forma independente do sistema bancário. Continua a ser a única forma de dinheiro digital realmente descentralizada, garantindo soberania financeira aos indivíduos.

Argumento 3: 'O euro digital garantirá privacidade e confiança.'

O BCE já admitiu que o anonimato total não é uma opção no euro digital. Ao contrário do dinheiro físico, que permite transacções privadas, uma CBDC será totalmente rastreável. Cada transacção será monitorizada, armazenada e potencialmente sujeita a restrições ou impostos.

Já Bitcoin oferece pseudonimato e resistência à censura. Nenhuma entidade central pode bloqueá-lo, congelá-lo ou controlá-lo, tornando-o a melhor opção para pagamentos digitais livres.

Argumento 4: 'O euro digital funcionará offline, sem internet ou electricidade.'

Embora o BCE afirme que o euro digital terá funcionalidade offline, qualquer transacção terá de ser reconciliada online mais tarde, o que significa que a privacidade continua a ser uma ilusão. Além disso, essa funcionalidade offline será provavelmente limitada a pequenos valores pré-carregados—nada de revolucionário.

Já Bitcoin pode ser enviado via ondas de rádio, redes mesh e até satélites, ou opções como o LNURL ou mesmo ecash, tornando-o mais resiliente do que qualquer moeda digital, governamental ou não.

Argumento 5: 'Precisamos de uma legislação forte para apoiar o euro digital.'

Se o euro digital fosse realmente útil, por que razão precisa de ser imposto por lei? Bitcoin cresceu de forma orgânica porque funciona. O BCE está a pressionar por leis que poderão, no futuro, tornar as CBDCs a única forma legal de dinheiro digital, eliminando a liberdade financeira.

Bitcoin, por sua vez, é imparável, descentralizado e independente de decisões políticas. Nenhuma autoridade central pode decidir como deve, e se pode, usá-lo.

Conclusão: O Euro Digital Não É O Que Parece

O euro digital não se trata de inovação, mas de controlo. Os europeus já têm métodos de pagamento digitais eficientes, e o dinheiro físico garante a verdadeira privacidade financeira. Uma moeda digital estatal introduz o risco de vigilância financeira, restrições de gastos e dinheiro programável, onde o governo pode decidir quando, onde e como podes gastar o teu dinheiro.

Entretanto, Bitcoin já funciona há mais de 16 anos como uma alternativa descentralizada e global, sem precisar da aprovação de bancos centrais. Garante soberania financeira e resistência à censura, tornando-se a verdadeira forma de dinheiro digital do futuro.

A questão não é se o euro digital tornará os pagamentos mais fáceis—mas se tornará a liberdade financeira impossível.

@ 04c915da:3dfbecc9

Bitcoin has always been rooted in freedom and resistance to authority. I get that many of you are conflicted about the US Government stacking but by design we cannot stop anyone from using bitcoin. Many have asked me for my thoughts on the matter, so let’s rip it.

Concern

One of the most glaring issues with the strategic bitcoin reserve is its foundation, built on stolen bitcoin. For those of us who value private property this is an obvious betrayal of our core principles. Rather than proof of work, the bitcoin that seeds this reserve has been taken by force. The US Government should return the bitcoin stolen from Bitfinex and the Silk Road.

Using stolen bitcoin for the reserve creates a perverse incentive. If governments see bitcoin as a valuable asset, they will ramp up efforts to confiscate more bitcoin. The precedent is a major concern, and I stand strongly against it, but it should be also noted that governments were already seizing coin before the reserve so this is not really a change in policy.

Ideally all seized bitcoin should be burned, by law. This would align incentives properly and make it less likely for the government to actively increase coin seizures. Due to the truly scarce properties of bitcoin, all burned bitcoin helps existing holders through increased purchasing power regardless. This change would be unlikely but those of us in policy circles should push for it regardless. It would be best case scenario for American bitcoiners and would create a strong foundation for the next century of American leadership.

Optimism

The entire point of bitcoin is that we can spend or save it without permission. That said, it is a massive benefit to not have one of the strongest governments in human history actively trying to ruin our lives.

Since the beginning, bitcoiners have faced horrible regulatory trends. KYC, surveillance, and legal cases have made using bitcoin and building bitcoin businesses incredibly difficult. It is incredibly important to note that over the past year that trend has reversed for the first time in a decade. A strategic bitcoin reserve is a key driver of this shift. By holding bitcoin, the strongest government in the world has signaled that it is not just a fringe technology but rather truly valuable, legitimate, and worth stacking.

This alignment of incentives changes everything. The US Government stacking proves bitcoin’s worth. The resulting purchasing power appreciation helps all of us who are holding coin and as bitcoin succeeds our government receives direct benefit. A beautiful positive feedback loop.

Realism

We are trending in the right direction. A strategic bitcoin reserve is a sign that the state sees bitcoin as an asset worth embracing rather than destroying. That said, there is a lot of work left to be done. We cannot be lulled into complacency, the time to push forward is now, and we cannot take our foot off the gas. We have a seat at the table for the first time ever. Let's make it worth it.

We must protect the right to free usage of bitcoin and other digital technologies. Freedom in the digital age must be taken and defended, through both technical and political avenues. Multiple privacy focused developers are facing long jail sentences for building tools that protect our freedom. These cases are not just legal battles. They are attacks on the soul of bitcoin. We need to rally behind them, fight for their freedom, and ensure the ethos of bitcoin survives this new era of government interest. The strategic reserve is a step in the right direction, but it is up to us to hold the line and shape the future.

@ 8f69ac99:4f92f5fd

Durante décadas, os europeus foram incentivados a poupar para o futuro — para a reforma, a compra de casa ou segurança financeira. Mas agora, a Comissão Europeia quer redefinir a poupança — não como património pessoal, mas como um recurso para investimento controlado pelo Estado.

A União de Poupanças e Investimentos (Savings and Investments Union, ou SIU), um plano que integra a União dos Mercados de Capitais e a União Bancária. Oficialmente, trata-se de “empoderar os cidadãos” e “desbloquear oportunidades de investimento”. Na realidade, trata-se de uma mudança radical rumo ao controlo financeiro, onde as suas poupanças são pressionadas ou mesmo desviadas para investimentos aprovados pelo Estado.

Ao mesmo tempo, o euro digital será lançado em Outubro de 2025. Esta moeda programável tornará os juros negativos, os controlos de capital e as restrições de gastos mais fáceis de aplicar do que nunca. A mensagem é clara: a UE está a desmantelar a autonomia financeira. O que antes eram as suas poupanças privadas pode em breve tornar-se uma ferramenta económica gerida pelo Estado.

Será apenas mais uma medida burocrática ou o primeiro passo para uma distopia financeira? Vamos analisar.

O Plano: "Transformar Poupanças Privadas em Investimento"

A declaração de Ursula von der Leyen — "Vamos transformar poupanças privadas em investimento muito necessário" — parece um plano inofensivo para impulsionar a economia. Mas, na realidade, assinala uma tomada de controlo estatal da riqueza pessoal.

Os governos desconfiam da independência financeira. Quando os indivíduos poupam por conta própria, fazem escolhas financeiras pessoais que podem não estar alinhadas com as agendas burocráticas. A União de Poupanças e Investimentos da UE pretende mudar isso, criando mecanismos para empurrar o capital privado para sectores aprovados pelo governo.

A Comissão Europeia estima que os cidadãos da UE detenham 10 biliões de euros em poupanças inactivas, e pretende mobilizar esse dinheiro para financiar a militarização da Europa e apoiar o complexo militar-industrial europeu. A Comissária Europeia para os Serviços Financeiros e para a União de Poupança e Investimento, Maria Luís Albuquerque, afirmou explicitamente que o rearmamento europeu dependerá fortemente da captação de investimento privado.

Como Isto Será Feito?

• Taxas de juro negativas — A erosão lenta das poupanças, tornando oneroso manter dinheiro no banco.
• Investimentos forçados em sectores “verdes”, militares e “estratégicos” — O seu dinheiro pode não ir para onde quer, mas para onde os políticos decidem.
• Controlos de capital — Impedindo a livre movimentação do seu dinheiro para alternativas mais seguras.

Albuquerque declarou que o problema da Europa é a diferença entre poupanças paradas e empresas que precisam de financiamento. Para fechar essa diferença, a Comissão Europeia pretende criar um novo esquema para mobilizar fundos privados para o investimento na indústria da UE no âmbito da União de Investimento e Poupança.

Isto não tem a ver com liberdade económica. Tem a ver com direccionar capital para onde o Estado deseja. E o novo euro digital do BCE, a CBDC europeia, facilita ainda mais esse controlo.

O Euro Digital: A Ferramenta Perfeita de Controlo

Com o euro digital, o BCE está a introduzir dinheiro programável, o que significa que as transacções podem ser controladas, monitorizadas e até restringidas em tempo real.

O Que Pode Fazer o Dinheiro Programável?

• Aplicar taxas de juro negativas automaticamente — As suas poupanças digitais podem diminuir com o tempo.
• Restringir como e onde pode gastar — Compras podem ser bloqueadas para itens considerados “não essenciais”.
• Definir datas de validade para o dinheiro — Forçando-o a gastar rapidamente.
• Limitar levantamentos ou transferências — Impedindo-o de sair do sistema.

O BCE afirma que o euro digital melhorará a “eficiência financeira”, mas o seu verdadeiro poder reside em vigiar e controlar todas as transacções. Se você não pode manter dinheiro fora do sistema, então não é dono do seu dinheiro — o Estado é.

Como Proteger-se

Com a UE a apertar o cerco, precisa de agir agora para proteger a sua riqueza:

• Opte pelo Bitcoin — A melhor reserva de valor fora do controlo governamental.
• Use dinheiro físico enquanto pode — Mantenha-o em circulação para retardar a sua eliminação.
• Auto-custódia de tudo — Se não tem controlo directo, não é realmente seu.
• Eduque-se e resista — Espalhe a consciência antes que estas medidas se tornem irreversíveis.

Conclusão: Reivindique a Sua Liberdade Financeira

O plano da UE é claro: controlo total sobre o seu dinheiro e a sua vida.

O euro digital, as taxas de juro negativas e os controlos de capital não visam a prosperidade, mas garantir que ninguém possa escapar.

Mas Bitcoin oferece uma alternativa. Um sistema financeiro paralelo, incensurável, inconfiscável e deflacionário.

A escolha é clara: submeter-se à tirania financeira ou optar pela soberania monetária com Bitcoin.

O tempo para agir é agora.

---

Photo by Etienne Girardet on Unsplash

@ 04c915da:3dfbecc9

Recently we have seen a wave of high profile X accounts hacked. These attacks have exposed the fragility of the status quo security model used by modern social media platforms like X. Many users have asked if nostr fixes this, so lets dive in. How do these types of attacks translate into the world of nostr apps? For clarity, I will use X’s security model as representative of most big tech social platforms and compare it to nostr.

The Status Quo

On X, you never have full control of your account. Ultimately to use it requires permission from the company. They can suspend your account or limit your distribution. Theoretically they can even post from your account at will. An X account is tied to an email and password. Users can also opt into two factor authentication, which adds an extra layer of protection, a login code generated by an app. In theory, this setup works well, but it places a heavy burden on users. You need to create a strong, unique password and safeguard it. You also need to ensure your email account and phone number remain secure, as attackers can exploit these to reset your credentials and take over your account. Even if you do everything responsibly, there is another weak link in X infrastructure itself. The platform’s infrastructure allows accounts to be reset through its backend. This could happen maliciously by an employee or through an external attacker who compromises X’s backend. When an account is compromised, the legitimate user often gets locked out, unable to post or regain control without contacting X’s support team. That process can be slow, frustrating, and sometimes fruitless if support denies the request or cannot verify your identity. Often times support will require users to provide identification info in order to regain access, which represents a privacy risk. The centralized nature of X means you are ultimately at the mercy of the company’s systems and staff.

Nostr Requires Responsibility

Nostr flips this model radically. Users do not need permission from a company to access their account, they can generate as many accounts as they want, and cannot be easily censored. The key tradeoff here is that users have to take complete responsibility for their security. Instead of relying on a username, password, and corporate servers, nostr uses a private key as the sole credential for your account. Users generate this key and it is their responsibility to keep it safe. As long as you have your key, you can post. If someone else gets it, they can post too. It is that simple. This design has strong implications. Unlike X, there is no backend reset option. If your key is compromised or lost, there is no customer support to call. In a compromise scenario, both you and the attacker can post from the account simultaneously. Neither can lock the other out, since nostr relays simply accept whatever is signed with a valid key.

The benefit? No reliance on proprietary corporate infrastructure.. The negative? Security rests entirely on how well you protect your key.

Future Nostr Security Improvements

For many users, nostr’s standard security model, storing a private key on a phone with an encrypted cloud backup, will likely be sufficient. It is simple and reasonably secure. That said, nostr’s strength lies in its flexibility as an open protocol. Users will be able to choose between a range of security models, balancing convenience and protection based on need.

One promising option is a web of trust model for key rotation. Imagine pre-selecting a group of trusted friends. If your account is compromised, these people could collectively sign an event announcing the compromise to the network and designate a new key as your legitimate one. Apps could handle this process seamlessly in the background, notifying followers of the switch without much user interaction. This could become a popular choice for average users, but it is not without tradeoffs. It requires trust in your chosen web of trust, which might not suit power users or large organizations. It also has the issue that some apps may not recognize the key rotation properly and followers might get confused about which account is “real.”

For those needing higher security, there is the option of multisig using FROST (Flexible Round-Optimized Schnorr Threshold). In this setup, multiple keys must sign off on every action, including posting and updating a profile. A hacker with just one key could not do anything. This is likely overkill for most users due to complexity and inconvenience, but it could be a game changer for large organizations, companies, and governments. Imagine the White House nostr account requiring signatures from multiple people before a post goes live, that would be much more secure than the status quo big tech model.

Another option are hardware signers, similar to bitcoin hardware wallets. Private keys are kept on secure, offline devices, separate from the internet connected phone or computer you use to broadcast events. This drastically reduces the risk of remote hacks, as private keys never touches the internet. It can be used in combination with multisig setups for extra protection. This setup is much less convenient and probably overkill for most but could be ideal for governments, companies, or other high profile accounts.

---

Nostr’s security model is not perfect but is robust and versatile. Ultimately users are in control and security is their responsibility. Apps will give users multiple options to choose from and users will choose what best fits their need.

@ 97c70a44:ad98e322

When developing on nostr, normally it's enough to read the NIP related to a given feature you want to build to know what has to be done. But there are some aspects of nostr development that aren't so straightforward because they depend less on specific data formats than on how different concepts are combined.

An example of this is how for a while it was considered best practice to re-publish notes when replying to them. This practice emerged before the outbox model gained traction, and was a hacky way of attempting to ensure relays had the full context required for a given note. Over time though, pubkey hints emerged as a better way to ensure other clients could find required context.

Another one of these things is "relay-based groups", or as I prefer to call it "relays-as-groups" (RAG). Such a thing doesn't really exist - there's no spec for it (although some aspects of the concept are included in NIP 29), but at the same time there are two concrete implementations (Flotilla and Chachi) which leverage several different NIPs in order to create a cohesive system for groups on nostr.

This composability is one of the neat qualities of nostr. Not only would it be unhelpful to specify how different parts of the protocol should work together, it would be impossible because of the number of possible combinations possible just from applying a little bit of common sense to the NIPs repo. No one said it was ok to put t tags on a kind 0. But no one's stopping you! And the semantics are basically self-evident if you understand its component parts.

So, instead of writing a NIP that sets relay-based groups in stone, I'm writing this guide in order to document how I've combined different parts of the nostr protocol to create a compelling architecture for groups.

Relays

Relays already have a canonical identity, which is the relay's url. Events posted to a relay can be thought of as "posted to that group". This means that every relay is already a group. All nostr notes have already been posted to one or more groups.

One common objection to this structure is that identifying a group with a relay means that groups are dependent on the relay to continue hosting the group. In normal broadcast nostr (which forms organic permissionless groups based on user-centric social clustering), this is a very bad thing, because hosts are orthogonal to group identity. Communities are completely different. Communities actually need someone to enforce community boundaries, implement moderation, etc. Reliance on a host is a feature, not a bug (in contrast to NIP 29 groups, which tend to co-locate many groups on a single host, relays-as-groups tends to encourage one group, one host).

This doesn't mean that federation, mirrors, and migration can't be accomplished. In a sense, leaving this on the social layer is a good thing, because it adds friction to the dissolution/forking of a group. But the door is wide open to protocol additions to support those use cases for relay-based groups. One possible approach would be to follow this draft PR which specified a "federation" event relays could publish on their own behalf.

Relay keys

This draft PR to NIP 11 specifies a self field which represents the relay's identity. Using this, relays can publish events on their own behalf. Currently, the pubkey field sort of does the same thing, but is overloaded as a contact field for the owner of the relay.

AUTH

Relays can control access using NIP 42 AUTH. There are any number of modes a relay can operate in:

1. No auth, fully public - anyone can read/write to the group.

2. Relays may enforce broad or granular access controls with AUTH.

Relays may deny EVENTs or REQs depending on user identity. Messages returned in AUTH, CLOSED, or OK messages should be human readable. It's crucial that clients show these error messages to users. Here's how Flotilla handles failed AUTH and denied event publishing:

LIMITS could also be used in theory to help clients adapt their interface depending on user abilities and relay policy.

1. AUTH with implicit access controls.

In this mode, relays may exclude matching events from REQs if the user does not have permission to view them. This can be useful for multi-use relays that host hidden rooms. This mode should be used with caution, because it can result in confusion for the end user.

See Triflector for a relay implementation that supports some of these auth policies.

Invite codes

If a user doesn't have access to a relay, they can request access using this draft NIP. This is true whether access has been explicitly or implicitly denied (although users will have to know that they should use an invite code to request access).

The above referenced NIP also contains a mechanism for users to request an invite code that they can share with other users.

The policy for these invite codes is entirely up to the relay. They may be single-use, multi-use, or require additional verification. Additional requirements can be communicated to the user in the OK message, for example directions to visit an external URL to register.

See Triflector for a relay implementation that supports invite codes.

Content

Any kind of event can be published to a relay being treated as a group, unless rejected by the relay implementation. In particular, NIP 7D was added to support basic threads, and NIP C7 for chat messages.

Since which relay an event came from determines which group it was posted to, clients need to have a mechanism for keeping track of which relay they received an event from, and should not broadcast events to other relays (unless intending to cross-post the content).

Rooms

Rooms follow NIP 29. I wish NIP 29 wasn't called "relay based groups", which is very confusing when talking about "relays as groups". It's much better to think of them as sub-groups, or as Flotilla calls them, "rooms".

Rooms have two modes - managed and unmanaged. Managed rooms follow all the rules laid out in NIP 29 about metadata published by the relay and user membership. In either case, rooms are represented by a random room id, and are posted to by including the id in an event's h tag. This allows rooms to switch between managed and unmanaged modes without losing any content.

Managed room names come from kind 39000 room meta events, but unmanaged rooms don't have these. Instead, room names should come from members' NIP 51 kind 10009 membership lists. Tags on these lists should look like this: ["group", "groupid", "wss://group.example.com", "Cat lovers"]. If no name can be found for the room (i.e., there aren't any members), the room should be ignored by clients.

Rooms present a difficulty for publishing to the relay as a whole, since content with an h tag can't be excluded from requests. Currently, relay-wide posts are h-tagged with _ which works for "group" clients, but not more generally. I'm not sure how to solve this other than to ask relays to support negative filters.

Cross-posting

The simplest way to cross-post content from one group (or room) to another, is to quote the original note in whatever event kind is appropriate. For example, a blog post might be quoted in a kind 9 to be cross-posted to chat, or in a kind 11 to be cross-posted to a thread. kind 16 reposts can be used the same way if the reader's client renders reposts.

Posting the original event to multiple relays-as-groups is trivial, since all you have to do is send the event to the relay. Posting to multiple rooms simultaneously by appending multiple h tags is however not recommended, since group relays/clients are incentivised to protect themselves from spam by rejecting events with multiple h tags (similar to how events with multiple t tags are sometimes rejected).

Privacy

Currently, it's recommended to include a NIP 70 - tag on content posted to relays-as-groups to discourage replication of relay-specific content across the network.

Another slightly stronger approach would be for group relays to strip signatures in order to make events invalid (or at least deniable). For this approach to work, users would have to be able to signal that they trust relays to be honest. We could also use ZkSNARKS to validate signatures in bulk.

In any case, group posts should not be considered "private" in the same way E2EE groups might be. Relays-as-groups should be considered a good fit for low-stakes groups with many members (since trust deteriorates quickly as more people get involved).

Membership

There is currently no canonical member list published by relays (except for NIP 29 managed rooms). Instead, users keep track of their own relay and room memberships using kind 10009 lists. Relay-level memberships are represented by an r tag containing the relay url, and room-level memberships are represented using a group tag.

Users can choose to advertise their membership in a RAG by using unencrypted tags, or they may keep their membership private by using encrypted tags. Advertised memberships are useful for helping people find groups based on their social graph:

User memberships should not be trusted, since they can be published unilaterally by anyone, regardless of actual access. Possible improvements in this area would be the ability to provide proof of access:

• Relays could publish member lists (although this would sacrifice member privacy)
• Relays could support a new command that allows querying a particular member's access status
• Relays could provide a proof to the member that they could then choose to publish or not

Moderation

There are two parts to moderation: reporting and taking action based on these reports.

Reporting is already covered by NIP 56. Clients should be careful about encouraging users to post reports for illegal content under their own identity, since that can itself be illegal. Relays also should not serve reports to users, since that can be used to find rather than address objectionable content.

Reports are only one mechanism for flagging objectionable content. Relay operators and administrators can use whatever heuristics they like to identify and address objectionable content. This might be via automated policies that auto-ban based on reports from high-reputation people, a client that implements NIP 86 relay management API, or by some other admin interface.

There's currently no way for moderators of a given relay to be advertised, or for a moderator's client to know that the user is a moderator (so that they can enable UI elements for in-app moderation). This could be addressed via NIP 11, LIMITS, or some other mechanism in the future.

General best practices

In general, it's very important when developing a client to assume that the relay has no special support for any of the above features, instead treating all of this stuff as progressive enhancement.

For example, if a user enters an invite code, go ahead and send it to the relay using a kind 28934 event. If it's rejected, you know that it didn't work. But if it's accepted, you don't know that it worked - you only know that the relay allowed the user to publish that event. This is helpful, becaues it may imply that the user does indeed have access to the relay. But additional probing may be needed, and reliance on error messages down the road when something else fails unexpectedly is indispensable.

This paradigm may drive some engineers nuts, because it's basically equivalent to coding your clients to reverse-engineer relay support for every feature you want to use. But this is true of nostr as a whole - anyone can put whatever weird stuff in an event and sign it. Clients have to be extremely compliant with Postell's law - doing their absolute best to accept whatever weird data or behavior shows up and handle failure in any situation. Sure, it's annoying, but it's the cost of permissionless development. What it gets us is a completely open-ended protocol, in which anything can be built, and in which every solution is tested by the market.

@ 04c915da:3dfbecc9

In much of the world, it is incredibly difficult to access U.S. dollars. Local currencies are often poorly managed and riddled with corruption. Billions of people demand a more reliable alternative. While the dollar has its own issues of corruption and mismanagement, it is widely regarded as superior to the fiat currencies it competes with globally. As a result, Tether has found massive success providing low cost, low friction access to dollars. Tether claims 400 million total users, is on track to add 200 million more this year, processes 8.1 million transactions daily, and facilitates $29 billion in daily transfers. Furthermore, their estimates suggest nearly 40% of users rely on it as a savings tool rather than just a transactional currency.

Tether’s rise has made the company a financial juggernaut. Last year alone, Tether raked in over $13 billion in profit, with a lean team of less than 100 employees. Their business model is elegantly simple: hold U.S. Treasuries and collect the interest. With over $113 billion in Treasuries, Tether has turned a straightforward concept into a profit machine.

Tether’s success has resulted in many competitors eager to claim a piece of the pie. This has triggered a massive venture capital grift cycle in USD tokens, with countless projects vying to dethrone Tether. Due to Tether’s entrenched network effect, these challengers face an uphill battle with little realistic chance of success. Most educated participants in the space likely recognize this reality but seem content to perpetuate the grift, hoping to cash out by dumping their equity positions on unsuspecting buyers before they realize the reality of the situation.

Historically, Tether’s greatest vulnerability has been U.S. government intervention. For over a decade, the company operated offshore with few allies in the U.S. establishment, making it a major target for regulatory action. That dynamic has shifted recently and Tether has seized the opportunity. By actively courting U.S. government support, Tether has fortified their position. This strategic move will likely cement their status as the dominant USD token for years to come.

While undeniably a great tool for the millions of users that rely on it, Tether is not without flaws. As a centralized, trusted third party, it holds the power to freeze or seize funds at its discretion. Corporate mismanagement or deliberate malpractice could also lead to massive losses at scale. In their goal of mitigating regulatory risk, Tether has deepened ties with law enforcement, mirroring some of the concerns of potential central bank digital currencies. In practice, Tether operates as a corporate CBDC alternative, collaborating with authorities to surveil and seize funds. The company proudly touts partnerships with leading surveillance firms and its own data reveals cooperation in over 1,000 law enforcement cases, with more than $2.5 billion in funds frozen.

---

The global demand for Tether is undeniable and the company’s profitability reflects its unrivaled success. Tether is owned and operated by bitcoiners and will likely continue to push forward strategic goals that help the movement as a whole. Recent efforts to mitigate the threat of U.S. government enforcement will likely solidify their network effect and stifle meaningful adoption of rival USD tokens or CBDCs. Yet, for all their achievements, Tether is simply a worse form of money than bitcoin. Tether requires trust in a centralized entity, while bitcoin can be saved or spent without permission. Furthermore, Tether is tied to the value of the US Dollar which is designed to lose purchasing power over time, while bitcoin, as a truly scarce asset, is designed to increase in purchasing power with adoption. As people awaken to the risks of Tether’s control, and the benefits bitcoin provides, bitcoin adoption will likely surpass it.

@ 04c915da:3dfbecc9

One of the most common criticisms leveled against nostr is the perceived lack of assurance when it comes to data storage. Critics argue that without a centralized authority guaranteeing that all data is preserved, important information will be lost. They also claim that running a relay will become prohibitively expensive. While there is truth to these concerns, they miss the mark. The genius of nostr lies in its flexibility, resilience, and the way it harnesses human incentives to ensure data availability in practice.

A nostr relay is simply a server that holds cryptographically verifiable signed data and makes it available to others. Relays are simple, flexible, open, and require no permission to run. Critics are right that operating a relay attempting to store all nostr data will be costly. What they miss is that most will not run all encompassing archive relays. Nostr does not rely on massive archive relays. Instead, anyone can run a relay and choose to store whatever subset of data they want. This keeps costs low and operations flexible, making relay operation accessible to all sorts of individuals and entities with varying use cases.

Critics are correct that there is no ironclad guarantee that every piece of data will always be available. Unlike bitcoin where data permanence is baked into the system at a steep cost, nostr does not promise that every random note or meme will be preserved forever. That said, in practice, any data perceived as valuable by someone will likely be stored and distributed by multiple entities. If something matters to someone, they will keep a signed copy.

Nostr is the Streisand Effect in protocol form. The Streisand effect is when an attempt to suppress information backfires, causing it to spread even further. With nostr, anyone can broadcast signed data, anyone can store it, and anyone can distribute it. Try to censor something important? Good luck. The moment it catches attention, it will be stored on relays across the globe, copied, and shared by those who find it worth keeping. Data deemed important will be replicated across servers by individuals acting in their own interest.

Nostr’s distributed nature ensures that the system does not rely on a single point of failure or a corporate overlord. Instead, it leans on the collective will of its users. The result is a network where costs stay manageable, participation is open to all, and valuable verifiable data is stored and distributed forever.

@ 02f0a63d:f91bde2c

Usa PGP para enviar mensajes privados por telegram

PGP es una gran herramienta con la que podremos cifrar nuestras conversaciones en cualquier canal de comunicación. En esta publicación te mostraré la forma más rápida y sencilla para poder usar esta herramienta junto con telegram. Te guiaré en unos pasos sencillos para disponer de todo lo necesario para comunicarte con tus contactos de forma privada. Existen muchas formas de hacerlo, a continuación te enseñaré la mas sencilla en mi opinión, no necesitas conocimientos previos ¡¡Los irás adquiriendo practicando ¡¡

Aplicaciones necesarias

F-Droid

Es una store de aplicaciones open source para android, del cual descargaremos las aplicaciones que necesitamos. Descarga : https://f-droid.org/F-Droid.apk

Nekogram x

Es un cliente de Telegram open source con funciones añadidas entre las que se encuentra la integración de PGP a través de Openkeychain. La descarga e instalación la realizaremos desde F-droid.

https://github.com/NekoX-Dev/NekoX

Openkeychain

Aplicación para android con el estandar OpenPGP . Con Openkeychain se hace muy sencilla La creación de claves PGP y su uso integrado con Nekogram facilita sus uso.

La descarga e instalación la realizaremos desde F-droid.

Guía para comunicarte de forma privada con tu contraparte

Creación de clave con openkeychain

Te pedirá que introduzcas un nombre para identificar la clave y un correo electrónico (puedes poner uno inventado). Haz click en crear clave. Podrás ver tus claves almacenadas.

Compartir tu clave pública con el receptor

Una vez creada tu clave, ve al chat en Nekogram con quien vas a compartir tu clave pública, haz click en los 3 puntitos de la esquina superior en el chat. Elige tu clave y se compartirá en el chat de tu contacto.

Importar clave pública de mi contacto

Necesitas la clave pública de tu contacto para poder cifrar la información y que solo el pueda descifrarla con su clave privada. Pídele a tu contacto que te envíe su clave pública (si no sabe comparte esta guía)para que te la envíe al chat de telegram. Haz click sobre el mensaje con la clave pública y pincha en importar clave.

Se abrirá openkeychain y le daremos a importar.

Y aparecerá almacenada junto con tu clave.

Cifrar mensaje con la clave pública de mi contacto

Una vez creada tu clave e importada la clave pública de tu contacto ya tienes todo para poder cifrar y descifrar los mensajes que os enviéis. En Openkeychain abre el menu pinchando en las 3 rayas horizontales en la esquina superior derecha. le das a cifrar/descifrar. Elige cifrar texto

En cifrar para : la calve de tu contacto.

En firmar con : tu clave

Escribe el texto que quieres cifrar y lo copias o comparte pinchando en los símbolos de arriba.

Pegalo en el chat del contacto

mensaje cifrado, telegram no puede ver el mensaje que contiene.

Descifrar un mensaje en Nekogram

Podremos descifrar un mensaje cuando el emisor lo haya cifrado con nuestra clave pública. Es tan sencillo como pinchar en el mensaje cifrado y darle a descifrar mensaje en la pantalla que sale. Te llevará a Openkeychain.

Se abrira Openkeychain y te mostrará el mensaje descifrado.

Conclusiones:

Hemos visto la manera más fácil para cifrar y descrifrar mensajes con quien quieras, gracias a Openkeychain y la integración de éste en Nekogram X hacen muy fácil mandar mensajes cifrados que solo tú y tu receptor podeis descifrar.

Este sistema se hace necesario usarlo para enviar información que no quiero que un tercero (servidores de telegram) sepa. Como cuando compartimos información personal, o direcciones de bitcoin para no vincularla a tu cuenta de telegram, etc.

Ya no tienes excusa para hacer uso de tu privacidad y revelarla selectivamente a quien desees.

@ 97c70a44:ad98e322

So you've decided to join nostr! Some wide-eyed fanatic has convinced you that the "sun shines every day on the birds and the bees and the cigarette trees" in a magical land of decentralized, censorship-resistant freedom of speech - and it's waiting just over the next hill.

But your experience has not been all you hoped. Before you've even had a chance to upload your AI-generated cyberpunk avatar or make up exploit codenames for your pseudonym's bio, you've been confronted with a new concept that has left you completely nonplussed.

It doesn't help that this new idea might be called by any number of strange names. You may have been asked to "paste your nsec", "generate a private key", "enter your seed words", "connect with a bunker", "sign in with extension", or even "generate entropy". Sorry about that.

All these terms are really referring to one concept under many different names: that of "cryptographic identity".

Now, you may have noticed that I just introduced yet another new term which explains exactly nothing. You're absolutely correct. And now I'm going to proceed to ignore your complaints and talk about something completely different. But bear with me, because the juice is worth the squeeze.

Identity

What is identity? There are many philosophical, political, or technical answers to this question, but for our purposes it's probably best to think of it this way:

Identity is the essence of a thing. Identity separates one thing from all others, and is itself indivisible.

This definition has three parts:

• Identity is "essential": a thing can change, but its identity cannot. I might re-paint my house, replace its components, sell it, or even burn it down, but its identity as something that can be referred to - "this house" - is durable, even outside the boundaries of its own physical existence.
• Identity is a unit: you can't break an identity into multiple parts. A thing might be composed of multiple parts, but that's only incidental to the identity of a thing, which is a concept, not a material thing.
• Identity is distinct: identity is what separates one thing from all others - the concept of an apple can't be mixed with that of an orange; the two ideas are distinct. In the same way, a single concrete apple is distinct in identity from another - even if the component parts of the apple decompose into compost used to grow more apples.

Identity is not a physical thing, but a metaphysical thing. Or, in simpler terms, identity is a "concept".

I (or someone more qualified) could at this point launch into a Scholastic tangent on what "is" is, but that is, fortunately, not necessary here. The kind of identities I want to focus on here are not our actual identities as people, but entirely fictional identities that we use to extend our agency into the digital world.

Think of it this way - your bank login does not represent you as a complete person. It only represents the access granted to you by the bank. This access is in fact an entirely new identity that has been associated with you, and is limited in what it's useful for.

Other examples of fictional identities include:

• The country you live in
• Your social media persona
• Your mortgage
• Geographical coordinates
• A moment in time
• A chess piece

Some of these identites are inert, for example points in space and time. Other identies have agency and so are able to act in the world - even as fictional concepts. In order to do this, they must "authenticate" themselves (which means "to prove they are real"), and act within a system of established rules.

For example, your D&D character exists only within the collective fiction of your D&D group, and can do anything the rules say. Its identity is authenticated simply by your claim as a member of the group that your character in fact exists. Similarly, a lawyer must prove they are a member of the Bar Association before they are allowed to practice law within that collective fiction.

"Cryptographic identity" is simply another way of authenticating a fictional identity within a given system. As we'll see, it has some interesting attributes that set it apart from things like a library card or your latitude and longitude. Before we get there though, let's look in more detail at how identities are authenticated.

Certificates

Merriam-Webster defines the verb "certify" as meaning "to attest authoritatively". A "certificate" is just a fancy way of saying "because I said so". Certificates are issued by a "certificate authority", someone who has the authority to "say so". Examples include your boss, your mom, or the Pope.

This method of authentication is how almost every institution authenticates the people who associate with it. Colleges issue student ID cards, governments issue passports, and websites allow you to "register an account".

In every case mentioned above, the "authority" creates a closed system in which a document (aka a "certificate") is issued which serves as a claim to a given identity. When someone wants to access some privileged service, location, or information, they present their certificate. The authority then validates it and grants or denies access. In the case of an international airport, the certificate is a little book printed with fancy inks. In the case of a login page, the certificate is a username and password combination.

This pattern for authentication is ubiquitous, and has some very important implications.

First of all, certified authentication implies that the issuer of the certificate has the right to exclusive control of any identity it issues. This identity can be revoked at any time, or its permissions may change. Your social credit score may drop arbitrarily, or money might disappear from your account. When dealing with certificate authorities, you have no inherent rights.

Second, certified authentication depends on the certificate authority continuing to exist. If you store your stuff at a storage facility but the company running it goes out of business, your stuff might disappear along with it.

Usually, authentication via certificate authority works pretty well, since an appeal can always be made to a higher authority (nature, God, the government, etc). Authorities also can't generally dictate their terms with impunity without losing their customers, alienating their constituents, or provoking revolt. But it's also true that certification by authority creates an incentive structure that frequently leads to abuse - arbitrary deplatforming is increasingly common, and the bigger the certificate authority, the less recourse the certificate holder (or "subject") has.

Certificates also put the issuer in a position to intermediate relationships that wouldn't otherwise be subject to their authority. This might take the form of selling user attention to advertisers, taking a cut of financial transactions, or selling surveillance data to third parties.

Proliferation of certificate authorities is not a solution to these problems. Websites and apps frequently often offer multiple "social sign-in" options, allowing their users to choose which certificate authority to appeal to. But this only piles more value into the social platform that issues the certificate - not only can Google shut down your email inbox, they can revoke your ability to log in to every website you used their identity provider to get into.

In every case, certificate issuance results in an asymmetrical power dynamic, where the issuer is able to exert significant control over the certificate holder, even in areas unrelated to the original pretext for the relationship between parties.

Self-Certification

But what if we could reverse this power dynamic? What if individuals could issue their own certificates and force institutions to accept them?

Ron Swanson's counterexample notwithstanding, there's a reason I can't simply write myself a parking permit and slip it under the windshield wiper. Questions about voluntary submission to legitimate authorities aside, the fact is that we don't have the power to act without impunity - just like any other certificate authority, we have to prove our claims either by the exercise of raw power or by appeal to a higher authority.

So the question becomes: which higher authority can we appeal to in order to issue our own certificates within a given system of identity?

The obvious answer here is to go straight to the top and ask God himself to back our claim to self-sovereignty. However, that's not how he normally works - there's a reason they call direct acts of God "miracles". In fact, Romans 13:1 explicitly says that "the authorities that exist have been appointed by God". God has structured the universe in such a way that we must appeal to the deputies he has put in place to govern various parts of the world.

Another tempting appeal might be to nature - i.e. the material world. This is the realm in which we most frequently have the experience of "self-authenticating" identities. For example, a gold coin can be authenticated by biting it or by burning it with acid. If it quacks like a duck, walks like a duck, and looks like a duck, then it probably is a duck.

In most cases however, the ability to authenticate using physical claims depends on physical access, and so appeals to physical reality have major limitations when it comes to the digital world. Captchas, selfies and other similar tricks are often used to bridge the physical world into the digital, but these are increasingly easy to forge, and hard to verify.

There are exceptions to this rule - an example of self-certification that makes its appeal to the physical world is that of a signature. Signatures are hard to forge - an incredible amount of data is encoded in physical signatures, from strength, to illnesses, to upbringing, to personality. These can even be scanned and used within the digital world as well. Even today, most contracts are sealed with some simulacrum of a physical signature. Of course, this custom is quickly becoming a mere historical curiosity, since the very act of digitizing a signature makes it trivially forgeable.

So: transcendent reality is too remote to subtantiate our claims, and the material world is too limited to work within the world of information. There is another aspect of reality remaining that we might appeal to: information itself.

Physical signatures authenticate physical identities by encoding unique physical data into an easily recognizable artifact. To transpose this idea to the realm of information, a "digital signature" might authenticate "digital identities" by encoding unique "digital data" into an easily recognizable artifact.

Unfortunately, in the digital world we have the additional challenge that the artifact itself can be copied, undermining any claim to legitimacy. We need something that can be easily verified and unforgeable.

Digital Signatures

In fact such a thing does exist, but calling it a "digital signature" obscures more than it reveals. We might just as well call the thing we're looking for a "digital fingerprint", or a "digital electroencephalogram". Just keep that in mind as we work our way towards defining the term - we are not looking for something looks like a physical signature, but for something that does the same thing as a physical signature, in that it allows us to issue ourselves a credential that must be accepted by others by encoding privileged information into a recognizable, unforgeable artifact.

With that, let's get into the weeds.

An important idea in computer science is that of a "function". A function is a sort of information machine that converts data from one form to another. One example is the idea of "incrementing" a number. If you increment 1, you get 2. If you increment 2, you get 3. Incrementing can be reversed, by creating a complementary function that instead subtracts 1 from a number.

A "one-way function" is a function that can't be reversed. A good example of a one-way function is integer rounding. If you round a number and get 5, what number did you begin with? It's impossible to know - 5.1, 4.81, 5.332794, in fact an infinite number of numbers can be rounded to the number 5. These numbers can also be infinitely long - for example rounding PI to the nearest integer results in the number 3.

A real-life example of a useful one-way function is sha256. This function is a member of a family of one-way functions called "hash functions". You can feed as much data as you like into sha256, and you will always get 256 bits of information out. Hash functions are especially useful because collisions between outputs are very rare - even if you change a single bit in a huge pile of data, you're almost certainly going to get a different output.

Taking this a step further, there is a whole family of cryptographic one-way "trapdoor" functions that act similarly to hash functions, but which maintain a specific mathematical relationship between the input and the output which allows the input/output pair to be used in a variety of useful applications. For example, in Elliptic Curve Cryptography, scalar multiplication on an elliptic curve is used to derive the output.

"Ok", you say, "that's all completely clear and lucidly explained" (thank you). "But what goes into the function?" You might expect that because of our analogy to physical signatures we would have to gather an incredible amount of digital information to cram into our cryptographic trapdoor function, mashing together bank statements, a record of our heartbeat, brain waves and cellular respiration. Well, we could do it that way (maybe), but there's actually a much simpler solution.

Let's play a quick game. What number am I thinking of? Wrong, it's 82,749,283,929,834. Good guess though.

The reason we use signatures to authenticate our identity in the physical world is not because they're backed by a lot of implicit physical information, but because they're hard to forge and easy to validate. Even so, there is a lot of variation in a single person's signature, even from one moment to the next.

Trapdoor functions solve the validation problem - it's trivially simple to compare one 256-bit number to another. And randomness solves the problem of forgeability.

Now, randomness (A.K.A. "entropy") is actually kind of hard to generate. Random numbers that don't have enough "noise" in them are known as "pseudo-random numbers", and are weirdly easy to guess. This is why Cloudflare uses a video stream of their giant wall of lava lamps to feed the random number generator that powers their CDN. For our purposes though, we can just imagine that our random numbers come from rolling a bunch of dice.

To recap, we can get a digital equivalent of a physical signature (or fingerprint, etc) by 1. coming up with a random number, and 2. feeding it into our chosen trapdoor function. The random number is called the "private" part. The output of the trapdoor function is called the "public" part. These two halves are often called "keys", hence the terms "public key" and "private key".

And now we come full circle - remember about 37 years ago when I introduced the term "cryptographic identity"? Well, we've finally arrived at the point where I explain what that actually is.

A "cryptographic identity" is identified by a public key, and authenticated by the ability to prove that you know the private key.

Notice that I didn't say "authenticated by the private key". If you had to reveal the private key in order to prove you know it, you could only authenticate a public key once without losing exclusive control of the key. But cryptographic identities can be authenticated any number of times because the certification is an algorithm that only someone who knows the private key can execute.

This is the super power that trapdoor functions have that hash functions don't. Within certain cryptosystems, it is possible to mix additional data with your private key to get yet another number in such a way that someone else who only knows the public key can prove that you know the private key.

For example, if my secret number is 12, and someone tells me the number 37, I can "combine" the two by adding them together and returning the number 49. This "proves" that my secret number is 12. Of course, addition is not a trapdoor function, so it's trivially easy to reverse, which is why cryptography is its own field of knowledge.

What's it for?

If I haven't completely lost you yet, you might be wondering why this matters. Who cares if I can prove that I made up a random number?

To answer this, let's consider a simple example: that of public social media posts.

Most social media platforms function by issuing credentials and verifying them based on their internal database. When you log in to your Twitter (ok, fine, X) account, you provide X with a phone number (or email) and password. X compares these records to the ones stored in the database when you created your account, and if they match they let you "log in" by issuing yet another credential, called a "session key".

Next, when you "say" something on X, you pass along your session key and your tweet to X's servers. They check that the session key is legit, and if it is they associate your tweet with your account's identity. Later, when someone wants to see the tweet, X vouches for the fact that you created it by saying "trust me" and displaying your name next to the tweet.

In other words, X creates and controls your identity, but they let you use it as long as you can prove that you know the secret that you agreed on when you registered (by giving it to them every time).

Now pretend that X gets bought by someone even more evil than Elon Musk (if such a thing can be imagined). The new owner now has the ability to control your identity, potentially making it say things that you didn't actually say. Someone could be completely banned from the platform, but their account could be made to continue saying whatever the owner of the platform wanted.

In reality, such a breach of trust would quickly result in a complete loss of credibility for the platform, which is why this kind of thing doesn't happen (at least, not that we know of).

But there are other ways of exploiting this system, most notably by censoring speech. As often happens, platforms are able to confiscate user identities, leaving the tenant no recourse except to appeal to the platform itself (or the government, but that doesn't seem to happen for some reason - probably due to some legalese in social platforms' terms of use). The user has to start completely from scratch, either on the same platform or another.

Now suppose that when you signed up for X instead of simply telling X your password you made up a random number and provided a cryptographic proof to X along with your public key. When you're ready to tweet (there's no need to issue a session key, or even to store your public key in their database) you would again prove your ownership of that key with a new piece of data. X could then publish that tweet or not, along with the same proof you provided that it really came from you.

What X can't do in this system is pretend you said something you didn't, because they don't know your private key.

X also wouldn't be able to deplatform you as effectively either. While they could choose to ban you from their website and refuse to serve your tweets, they don't control your identity. There's nothing they can do to prevent you from re-using it on another platform. Plus, if the system was set up in such a way that other users followed your key instead of an ID made up by X, you could switch platforms and keep your followers. In the same way, it would also be possible to keep a copy of all your tweets in your own database, since their authenticity is determined by your digital signature, not X's "because I say so".

This new power is not just limited to social media either. Here are some other examples of ways that self-issued cryptographic identites transform the power dynamic inherent in digital platforms:

• Banks sometimes freeze accounts or confiscate funds. If your money was stored in a system based on self-issued cryptographic keys rather than custodians, banks would not be able to keep you from accessing or moving your funds. This system exists, and it's called bitcoin.
• Identity theft happens when your identifying information is stolen and used to take out a loan in your name, and without your consent. The reason this is so common is because your credentials are not cryptographic - your name, address, and social security number can only be authenticated by being shared, and they are shared so often and with so many counterparties that they frequently end up in data breaches. If credit checks were authenticated by self-issued cryptographic keys, identity theft would cease to exist (unless your private key itself got stolen).
• Cryptographic keys allow credential issuers to protect their subjects' privacy better too. Instead of showing your ID (including your home address, birth date, height, weight, etc), the DMV could sign a message asserting that the holder of a given public key indeed over 21. The liquor store could then validate that claim, and your ownership of the named key, without knowing anything more about you. Zero-knowledge proofs take this a step further.

In each of these cases, the interests of the property owner, loan seeker, or customer are elevated over the interests of those who might seek to control their assets, exploit their hard work, or surveil their activity. Just as with personal privacy, freedom of speech, and Second Amendment rights the individual case is rarely decisive, but in the aggregate realigned incentives can tip the scale in favor of freedom.

Objections

Now, there are some drawbacks to digital signatures. Systems that rely on digital signatures are frequently less forgiving of errors than their custodial counterparts, and many of their strengths have corresponding weaknesses. Part of this is because people haven't yet developed an intuition for how to use cryptographic identities, and the tools for managing them are still being designed. Other aspects can be mitigated through judicious use of keys fit to the problems they are being used to solve.

Below I'll articulate some of these concerns, and explore ways in which they might be mitigated over time.

Key Storage

Keeping secrets is hard. "A lie can travel halfway around the world before the truth can get its boots on", and the same goes for gossip. Key storage has become increasingly important as more of our lives move online, to the extent that password managers have become almost a requirement for keeping track of our digital lives. But even with good password management, credentials frequently end up for sale on the dark web as a consequence of poorly secured infrastructure.

Apart from the fact that all of this is an argument for cryptographic identities (since keys are shared with far fewer parties), it's also true that the danger of losing a cryptographic key is severe, especially if that key is used in multiple places. Instead of hackers stealing your Facebook password, they might end up with access to all your other social media accounts too!

Keys should be treated with the utmost care. Using password managers is a good start, but very valuable keys should be stored even more securely - for example in a hardware signing device. This is a hassle, and something additional to learn, but is an indispensable part of taking advantage of the benefits associated with cryptographic identity.

There are ways to lessen the impact of lost or stolen secrets, however. Lots of different techniques exist for structuring key systems in such a way that keys can be protected, invalidated, or limited. Here are a few:

• Hierarchical Deterministic Keys allow for the creation of a single root key from which multiple child keys can be generated. These keys are hard to link to the parent, which provides additional privacy, but this link can also be proven when necessary. One limitation is that the identity system has to be designed with HD keys in mind.
• Key Rotation allows keys to become expendable. Additional credentials might be attached to a key, allowing the holder to prove they have the right to rotate the key. Social attestations can help with the process as well if the key is embedded in a web of trust.
• Remote Signing is a technique for storing a key on one device, but using it on another. This might take the form of signing using a hardware wallet and transferring an SD card to your computer for broadcasting, or using a mobile app like Amber to manage sessions with different applications.
• Key sharding takes this to another level by breaking a single key into multiple pieces and storing them separately. A coordinator can then be used to collaboratively sign messages without sharing key material. This dramatically reduces the ability of an attacker to steal a complete key.

Multi-Factor Authentication

One method for helping users secure their accounts that is becoming increasingly common is "multi-factor authentication". Instead of just providing your email and password, platforms send a one-time use code to your phone number or email, or use "time-based one time passwords" which are stored in a password manager or on a hardware device.

Again, MFA is a solution to a problem inherent in account-based authentication which would not be nearly so prevalent in a cryptographic identity system. Still, theft of keys does happen, and so MFA would be an important improvement - if not for an extra layer of authentication, then as a basis for key rotation.

In a sense, MFA is already being researched - key shards is one way of creating multiple credentials from a single key. However, this doesn't address the issue of key rotation, especially when an identity is tied to the public key that corresponds to a given private key. There are two possible solutions to this problem:

• Introduce a naming system. This would allow identities to use a durable name, assigning it to different keys over time. The downside is that this would require the introduction of either centralized naming authorities (back to the old model), or a blockchain in order to solve Zooko's trilemma.
• Establish a chain of keys. This would require a given key to name a successor key in advance and self-invalidate, or some other process like social recovery to invalidate an old key and assign the identity to a new one. This also would significantly increase the complexity of validating messages and associating them with a given identity.

Both solutions are workable, but introduce a lot of complexity that could cause more trouble than it's worth, depending on the identity system we're talking about.

Surveillance

One of the nice qualities that systems based on cryptographic identities have is that digitally signed data can be passed through any number of untrusted systems and emerge intact. This ability to resist tampering makes it possible to broadcast signed data more widely than would otherwise be the case in a system that relies on a custodian to authenticate information.

The downside of this is that more untrusted systems have access to data. And if information is broadcast publicly, anyone can get access to it.

This problem is compounded by re-use of cryptographic identities across multiple contexts. A benefit of self-issued credentials is that it becomes possible to bring everything attached to your identity with you, including social context and attached credentials. This is convenient and can be quite powerful, but it also means that more context is attached to your activity, making it easier to infer information about you for advertising or surveillance purposes. This is dangerously close to the dystopian ideal of a "Digital ID".

The best way to deal with this risk is to consider identity re-use an option to be used when desirable, but to default to creating a new key for every identity you create. This is no worse than the status quo, and it makes room for the ability to link identities when desired.

Another possible approach to this problem is to avoid broadcasting signed data when possible. This could be done by obscuring your cryptographic identity when data is served from a database, or by encrypting your signed data in order to selectively share it with named counterparties.

Still, this is a real risk, and should be kept in mind when designing and using systems based on cryptographic identity. If you'd like to read more about this, please see this blog post.

Making Keys Usable

You might be tempted to look at that list of trade-offs and get the sense that cryptographic identity is not for mere mortals. Key management is hard, and footguns abound - but there is a way forward. With nostr, some new things are happening in the world of key management that have never really happened before.

Plenty of work over the last 30 years has gone into making key management tractable, but none have really been widely adopted. The reason for this is simple: network effect.

Many of these older key systems only applied the thinnest veneer of humanity over keys. But an identity is much richer than a mere label. Having a real name, social connections, and a corpus of work to attach to a key creates a system of keys that humans care about.

By bootstrapping key management within a social context, nostr ensures that the payoff of key management is worth the learning curve. Not only is social engagement a strong incentive to get off the ground, people already on the network are eager to help you get past any roadblocks you might face.

So if I could offer an action item: give nostr a try today. Whether you're in it for the people and their values, or you just want to experiment with cryptographic identity, nostr is a great place to start. For a quick introduction and to securely generate keys, visit njump.me.

Thanks for taking the time to read this post. I hope it's been helpful, and I can't wait to see you on nostr!

@ 256a7941:b828ba8d

Taking calls, texts and FaceTimes. Be direct Be courageous

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

@ 6c05c73e:c4356f17

Como a grande maioria dos brasileiros. Eu não comecei um negócio porque “queria empreender”. Diferente disso, eu PRECISAVA para poder pagar contas e manter o básico.

Festas, openbar e camisas

Meu primeiro negócio foi na verdade um combo. Eu tinha saído do último trampo e eu gostava de festas. Então, comecei a organizar uma festa mensalmente na casa do meu pai. Eu pagava a água, energia e dava uma grana para ele. Em troca, organizava festa de sábado para domingo open bar.

A fórmula era simples. Criava o evento da festa no facebook, convidava todo mundo que conhecia. Panfletava na cidade e espalhava cartazes nos pontos de ônibus sobre a festa. E, para fechar com chave de ouro. Mulher era OFF até 20:00. Consequência? Os caras vinham e pagavam o ingresso deles e delas. Kkkkk. E, enchia…

Comecei a notar que a galera se vestia mal. E, pensei: "Porque não vestir eles?” Pimba! Comecei a desenha e confeccionar camisas para vender nas festas. E, pimba denovo! Vendeu, tudo! Fiz 2 coleções e mais algumas festas. Até o dia que um menino deu PT de tanto beber e decidi que era hora de tentar outra coisa.

Como assim a Apple não vai vender mais os carregadores?

Isso, foi durante a pandemia. A Apple decidiu vender o telefone e o cabo. E, você que lute com a fonte. Estava difícil achar dinheiro no mercado naqueles tempos e eu pensei. Vou pesquisar no google trends e validar a ideia. Caixa! Tinha mais de 80 pts de busca. Colei em SP, no Brás e comprei literalmente. Todo meu dinheiro de cabo de iphone, carregador e bateria portátil.

Fiquei com R$100 na conta. Para fazer um lanche e pagar pelo uber para voltar para casa. Chegando aqui, eu tirei foto e fiz várias copys. Anunciei no Olx, Mercado Livre e Facebook. Impulsionei os anúncios no OLX, vendi para familiares e amigos, e; vendia até para quem estava na rua. Fiz entrega de bike, a pé, de ônibus e é isso mesmo. Tem que ralar. Para queimar o resto da mercadoria. Deixei com uma loja de eletrônicos e fiz consignado. E, hora da próxima ideia.

Mulheres, doces e TPM

Meu penúltimo negócio veio depois dos cabos. Eu pesquisei na net, negócios online para começar com pouca grana. (Depois que paguei as contas do dia a dia, sobraram R$3mil). E, achei uma pesquisa mostrando que doces. Tinha baixa barreira de entrada e exigia poucos equipamentos. Eu trabalhei em restaurante por muitos anos e sabia como lucrar com aquilo. Além do mais, mulheres consomem mais doce em uma certa época do mês.

Não deu outra, convidei 2 pessoas para serem sócias. Desenvolvemos os produtos, fotografamos e fizemos as copys. Em sequência, precisávamos vender. Então, lá vamos denovo: Ifood, WPP, 99food (na época), Uber eats (na época), Elo7, famílias e amigos e; por fim começamos a vender consignado com alguns restaurantes e lojas. Foi uma época em que aprendi a prospectar clientes de todas as maneiras possíveis.

De novo, minha maior dificuldade era a locomoção para fazer entregas. Só tinha uma bike. Mas, entregávamos. Os primeiros 3 meses foram difíceis demais. Mas, rolou. No fim, nossas maiores vendas vinham de: Ifood, encomendas de festas e consignados. Mas, como nem tudo são flores. Meus dois sócios tomaram outros caminhos e abandonaram o projeto. Galera, está tudo bem com isso. Isso acontece o tempo todo. A vida muda e temos que aprender a aceitar isso. Vida que segue e fui para frente de novo.

Sobre paixões, paciência e acreditar

Estava eu comemorando meu níver de 30 anos, num misto de realizações e pouco realizado. Como assim? Sabe quando você faz um monte de coisas, mas ainda assim. Não sente que é aquilo? Pois então…

Eu amo investimentos, livros, escrever e sempre curti trocar ideia com amigos e família sobre como se desenvolver. Desde que comecei a usar a internet eu criei: Canal no youtube, páginas no IG e FB, pinterest, steemit, blog e até canal no Telegram. Mas, nunca tinha consistente sabe? Tipo assim, vou fazer isso por um ano e plantar 100 sementes aqui. Enfim, inconsistência te derruba meu amigo…Eu voltei a trabalhar com restaurantes e estava doido para mudar de área. Estava exausto de trabalhar e meu wpp não parava de tocar. Fui estudar ADM e Desenvolvimento de sistemas no Senac. Dois anos depois, formei. Consegui trabalho.

E, comecei a pensar em como criar um negócio online, escalável e multilíngue. Passei os próximos 7 meses desenhando e pensando como. Mas, tinha que dar o primeiro passo. Criei um site e fui escrevendo textos. Os primeiros 30 foram aquilo, os próximos 10 melhoraram muito e os 10 a seguir eu fiquei bem satisfeitos. Hoje, tenho o negócio que estava na cabeça desde 2023. Mas, olha o tamanho da volta que o universo me fez dar e aprender para chegar aqui hoje. Dicas? Só 3:

1. Você precisa usar a internet para fazer negócio. Em todos os negócios que falei, sempre teve algo online. Não negligencie isso.
2. Tem que aprender a vender e se vender.
3. Confia em si mesmo e faz sem medo de errar. Porque, advinha? Você vai errar! Mas, vai aprender e melhorar. Tem que persistir…

Por hoje é isso. Tamo junto!

@ 256a7941:b828ba8d

BITCOINERS NEED A REMINDER THAT ROSS ULBRICHT WAS A SELF-PROCLAIMED LIBERTARIAN. NOT DEMOCRAT. NOT REPUBLICAN

FREEROSS

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

@ bf47c19e:c3d2573b

Originalni tekst na antenam.net

22.05.2025 / Autor: Ana Nives Radović

---

Da nema besplatnog ručka sigurno ste čuli svaki put kad bi neko poželio da naglasi da se sve na neki način plaća, iako možda tu cijenu ne primjećujemo odmah. Međutim, kada govorimo o događaju od kojeg je prošlo tačno 15 godina onda o „ručku“ ne govorimo u prenešenom smislu, već o porudžbini pice čija tržišna vrijednost iz godine u godinu dostiže iznos koji je čini najskupljom hranom koja je ikad poručena.

Tog 22. maja 2010. godine čovjek sa Floride pod imenom Laslo Hanjec potrošio je 10.000 bitcoina na dvije velike pice. U to vrijeme, ta količina bitcoina imala je tržišnu vrijednost od oko 41 dolar. Ako uzmemo u obzir da je vrijednost jedne jedinice ove digitalne valute danas nešto više od 111.000 dolara, tih 10.000 bitcoina danas bi značilo vrijednost od 1,11 milijardi dolara.

Nesvakidašnji događaj u digitalnoj i ugostiteljskoj istoriji, nastao zbog znatiželje poručioca koji je želio da se uvjeri da koristeći bitcoin može da plati nešto u stvarnom svijetu, pretvorio se u Bitcoin Pizza Day, kao podsjetnik na trenutak koji je označio prelaz bitcoina iz apstraktnog kriptografskog eksperimenta u nešto što ima stvarnu vrijednost.

Hanjec je bio znatiželjan i pitao se da li se prva, a u to vrijeme i jedina kriptovaluta može iskoristiti za kupovinu nečeg opipljivog. Objavio je ponudu na jednom forumu koja je glasila: 10.000 BTC za dvije pice. Jedan entuzijasta se javio, naručio pice iz restorana Papa John’s i ispisao zanimljivu stranicu istorije digitalne imovine.

Taj inicijalni zabilježeni finansijski dogovor dao je bitcoinu prvu široko prihvaćenu tržišnu vrijednost: 10.000 BTC za 41 dolar, čime je bitcoin napravio svoj prvi korak ka onome što danas mnogi zovu digitalnim zlatom.

Šta je zapravo bitcoin?

Bitcoin je oblik digitalnog novca koji je osmišljen da bude decentralizovan, transparentan i otporan na uticaj centralnih banaka. Kreirao ga je 2009. godine anonimni autor poznat kao Satoši Nakamoto, neposredno nakon globalne finansijske krize 2008. godine. U svojoj suštini, bitcoin je protokol, skup pravila koja sprovodi kompjuterski kod, koji omogućava korisnicima da bez posrednika sigurno razmjenjuju vrijednost putem interneta.

Osnova cijelog sistema je blockchain, distribuisana digitalna knjiga koju održavaju hiljade nezavisnih računara (tzv. čvorova) širom svijeta. Svaka transakcija se bilježi u novi „blok“, koji se potom dodaje u lanac (otud naziv „lanac blokova“, odnosno blockchain). Informacija koja se jednom upiše u blok ne može da se izbriše, niti promijeni, što omogućava više transparentnosti i više povjerenja.

Da bi blockchain mreža u kojoj se sve to odvija zadržala to svojstvo, bitcoin koristi mehanizam konsenzusa nazvan dokaz rada (proof-of-work), što znači da specijalizovani računari koji „rudare“ bitcoin rješavaju kompleksne matematičke probleme kako bi omogućili obavljanje transakcija i pouzdanost mreže.

Deflatorna priroda bitcoina

Najjednostavniji način da se razumije deflatorna priroda bitcoina je da pogledamo cijene izražene u valuti kojoj plaćamo. Sigurno ste u posljednje vrijeme uhvatili sebe da komentarišete da ono što je prije nekoliko godina koštalo 10 eura danas košta 15 ili više. Budući da to ne zapažate kada je u pitanju cijena samo određenog proizvoda ili usluge, već kao sveprisutan trend, shvatate da se radi o tome da je novac izgubio vrijednost. Na primjer, kada je riječ o euru, otkako je Evropska centralna banka počela intenzivno da doštampava novac svake godine, pa je od 2009. kada je program tzv. „kvantitativnog popuštanja“ započet euro zabilježio kumulativnu inflaciju od 42,09% zbog povećane količine sredstava u opticaju.

Međutim, kada je riječ o bitcoinu, njega nikada neće biti više od 21 milion koliko je izdato prvog dana, a to nepromjenjivo pravilo zapisano je i u njegovom kodu. Ova ograničena ponuda oštro se suprotstavlja principima koji važe kod monetarnih institucija, poput centralnih banaka, koje doštampavaju novac, često da bi povećale količinu u opticaju i tako podstakle finansijske tokove, iako novac zbog toga gubi vrijednost. Nasuprot tome, bitcoin se zadržava na iznosu od 21 milion, pa je upravo ta konačnost osnova za njegovu deflatornu prirodu i mogućnost da vremenom dobija na vrijednosti.

Naravno, ovo ne znači da je cijena bitcoina predodređena da samo raste. Ona je zapravo prilično volatilna i oscilacije su česte, posebno ukoliko, na primjer, posmatramo odnos cijena unutar jedne godine ili nekoliko mjeseci, međutim, gledano sa vremenske distance od četiri do pet godina bilo koji uporedni period od nastanka bitcoina do danas upućuje na to da je cijena u međuvremenu porasla. Taj trend će se nastaviti, tako da, kao ni kada je riječ o drugim sredstvima, poput zlata ili nafte, nema mjesta konstatacijama da je „vrijeme niskih cijena prošlo“.

Šta zapravo znači ovaj dan?

Bitcoin Pizza Day je za mnoge prilika da saznaju ponešto novo o bitcoinu, jer tada imaju priliku da o njemu čuju detalje sa raznih strana, jer kako se ovaj događaj popularizuje stvaraju se i nove prilike za učenje. Takođe, ovaj dan od 2021. obilježavaju picerije širom svijeta, u više od 400 gradova iz najmanje 75 zemalja, jer je za mnoge ovo prilika da korisnike bitcoina navedu da potroše djelić svoje imovine na nešto iz njihove ponude. Naravno, taj iznos je danasd zanemarljivo mali, a cijena jedne pice danas je otprilike 0,00021 bitcoina.

No, dok picerije širom svijeta danas na zabavan način pokušavaju da dođu do novih gostiju, ovaj dan je za mnoge vlasnike bitcoina nešto poput opomene da svoje digitalne novčiće ipak ne treba trošiti na nešto potrošno, jer je budućnost nepredvidiva. Bitcoin Pizza Day je dan kada se ideja pretvorila u valutu, kada su linije koda postale sredstvo razmjene.

Prvi let avionom trajao je svega 12 sekundi, a u poređenju sa današnjim transkontinentalnim linijama to djeluje gotovo neuporedivo i čudno, međutim, od nečega je moralo početi. Porudžbina pice plaćene bitcoinom označile su početak razmjene ove vrste, dok se, na primjer, tokom jučerašnjeg dana obim plaćanja bitcoinom premašio 23 milijarde dolara. Nauka i tehnologija nas podsjećaju na to da sve počinje malim, zanemarivim koracima.

@ 6d5c826a:4b27b659

• DefGuard - True enterprise WireGuard with MFA/2FA and SSO. (Source Code) Apache-2.0 Rust
• Dockovpn - Out-of-the-box stateless dockerized OpenVPN server which starts in less than 2 seconds. (Source Code) GPL-2.0 Docker
• Firezone - WireGuard based VPN Server and Firewall. (Source Code) Apache-2.0 Docker
• Gluetun VPN client - VPN client in a thin Docker container for multiple VPN providers, written in Go, and using OpenVPN or Wireguard, DNS over TLS, with a few proxy servers built-in. MIT docker
• Headscale - Self-hostable fork of Tailscale, cross-platform clients, simple to use, built-in (currently experimental) monitoring tools. BSD-3-Clause Go
• Nebula - A scalable p2p VPN with a focus on performance, simplicity and security. MIT Go
• ocserv - Cisco AnyConnect-compatible VPN server. (Source Code) GPL-2.0 C
• OpenVPN - Uses a custom security protocol that utilizes SSL/TLS for key exchange. (Source Code) GPL-2.0 C
• SoftEther - Multi-protocol software VPN with advanced features. (Source Code) Apache-2.0 C
• sshuttle - Poor man's VPN. LGPL-2.1 Python
• strongSwan - Complete IPsec implementation for Linux. (Source Code) GPL-2.0 C
• WireGuard - Very fast VPN based on elliptic curve and public key crypto. (Source Code) GPL-2.0 C

@ 6d5c826a:4b27b659

• Ganeti - Cluster virtual server management software tool built on top of KVM and Xen. (Source Code) BSD-2-Clause Python/Haskell
• KVM - Linux kernel virtualization infrastructure. (Source Code) GPL-2.0/LGPL-2.0 C
• OpenNebula - Build and manage enterprise clouds for virtualized services, containerized applications and serverless computing. (Source Code) Apache-2.0 C++
• oVirt - Manages virtual machines, storage and virtual networks. (Source Code) Apache-2.0 Java
• Packer - A tool for creating identical machine images for multiple platforms from a single source configuration. (Source Code) MPL-2.0 Go
• Proxmox VE - Virtualization management solution. (Source Code) GPL-2.0 Perl/Shell
• QEMU - QEMU is a generic machine emulator and virtualizer. (Source Code) LGPL-2.1 C
• Vagrant - Tool for building complete development environments. (Source Code) BUSL-1.1 Ruby
• VirtualBox - Virtualization product from Oracle Corporation. (Source Code) GPL-3.0/CDDL-1.0 C++
• XCP-ng - Virtualization platform based on Xen Source and Citrix® Hypervisor (formerly XenServer). (Source Code) GPL-2.0 C
• Xen - Virtual machine monitor for 32/64 bit Intel / AMD (IA 64) and PowerPC 970 architectures. (Source Code) GPL-2.0 C

@ 8cb60e21:5f2deaea

Title

subtitle

subsub

some Code some code: ```js import NextAuth from "next-auth"; import CredentialsProvider from "next-auth/providers/credentials"; import NDK from "@nostr-dev-kit/ndk"; import axios from "axios"; import { findKind0Fields } from "@/utils/nostr";

const relayUrls = [ "wss://nos.lol/", "wss://relay.damus.io/", "wss://relay.snort.social/", "wss://relay.nostr.band/", "wss://nostr.mutinywallet.com/", "wss://relay.mutinywallet.com/", "wss://relay.primal.net/" ];

const BASE_URL = process.env.BASE_URL;

const ndk = new NDK({ explicitRelayUrls: relayUrls, });

const authorize = async (pubkey) => { await ndk.connect(); const user = ndk.getUser({ pubkey });

try {
    const profile = await user.fetchProfile();

    // Check if user exists, create if not
    const response = await axios.get(`${BASE_URL}/api/users/${pubkey}`);
    if (response.status === 200 && response.data) {
        const fields = await findKind0Fields(profile);

        // Combine user object with kind0Fields, giving priority to kind0Fields
        const combinedUser = { ...fields, ...response.data };

        // Update the user on the backend if necessary
        // await axios.put(`${BASE_URL}/api/users/${combinedUser.id}`, combinedUser);

        return combinedUser;
    } else if (response.status === 204) {
        // Create user
        if (profile) {
            const fields = await findKind0Fields(profile);
            console.log('FEEEEELDS', fields);
            const payload = { pubkey, ...fields };

            const createUserResponse = await axios.post(`${BASE_URL}/api/users`, payload);
            return createUserResponse.data;
        }
    }
} catch (error) {
    console.error("Nostr login error:", error);
}
return null;

}

export default NextAuth({ providers: [ CredentialsProvider({ id: "nostr", name: "Nostr", credentials: { pubkey: { label: "Public Key", type: "text" }, }, authorize: async (credentials) => { if (credentials?.pubkey) { return await authorize(credentials.pubkey); } return null; }, }), ], callbacks: { async jwt({ token, trigger, user }) { console.log('TRIGGER', trigger); if (trigger === "update") { // if we trigger an update call the authorize function again const newUser = await authorize(token.user.pubkey); token.user = newUser; } // Add combined user object to the token if (user) { token.user = user; } return token; }, async session({ session, token }) { // Add user from token to session session.user = token.user; session.jwt = token; return session; }, async redirect({ url, baseUrl }) { return baseUrl; }, async signOut({ token, session }) { console.log('signOut', token, session); token = {} session = {} return true }, }, secret: process.env.NEXTAUTH_SECRET, session: { strategy: "jwt" }, jwt: { signingKey: process.env.JWT_SECRET, }, pages: { signIn: "/auth/signin", }, }); ```

@ 8f69ac99:4f92f5fd

O Estado Social tem sido um pilar das políticas sociais europeias há décadas, oferecendo uma rede de segurança aos cidadãos através de diversos programas governamentais. Contudo, com a evolução das economias e o envelhecimento da população a pressionar os recursos públicos, este modelo tradicional enfrenta desafios crescentes. Custos em alta, ineficiências burocráticas e efeitos indesejados têm gerado um debate cada vez mais intenso sobre a sua sustentabilidade. Como alternativa, o Rendimento Básico Universal (RBU) ganhou destaque, prometendo simplicidade, mas trazendo preocupações quanto ao custo e aos desincentivos ao trabalho. Há, porém, uma opção mais equilibrada que merece atenção: o Imposto sobre o Rendimento Negativo (IRN).

Diferente da assistência social convencional, o IRN oferece apoio financeiro a quem está abaixo de um limiar de rendimento definido, sem exigir que procurem emprego ou dependam de ajudas públicas. Ao reduzir gradualmente os subsídios à medida que os rendimentos aumentam, incentiva a produtividade e preserva a iniciativa pessoal. Neste artigo, vamos explorar o IRN em profundidade, destacando as suas vantagens sobre os sistemas tradicionais, abordando as falhas do RBU e avaliando o seu potencial como uma reforma transformadora na Europa. Num contexto de mudanças económicas e demográficas, o IRN surge como um caminho prático para um sistema que equilibre apoio, dignidade e sustentabilidade.

Problemas dos Sistemas Tradicionais de Assistência Social

O Estado Social tradicional, embora bem-intencionado, tem sido alvo de críticas crescentes pelas suas ineficiências e consequências inesperadas.

Ineficiência e Burocracia

Estruturas administrativas complexas frequentemente atrasam os sistemas de assistência social, levando a desperdícios de recursos. Programas sobrepostos e serviços redundantes aumentam os custos, sobrecarregando os contribuintes. Por exemplo, várias entidades podem oferecer benefícios semelhantes, enquanto processos morosos atrasam a ajuda a quem precisa. Com o envelhecimento da população europeia a exigir mais apoio, estas ineficiências põem em risco a estabilidade financeira, desafiando os decisores políticos a repensarem a distribuição de recursos.

Incentivos Perversos

A assistência social pode, sem querer, desencorajar o trabalho e perpetuar a dependência. Surgem "armadilhas de assistência" quando os benefícios são estruturados de forma a que ganhar um salário resulte numa redução abrupta da ajuda, tornando o emprego menos atractivo do que permanecer no assistencialismo. Isso cria um ciclo em que os beneficiários hesitam em procurar trabalho ou formação, comprometendo as suas perspectivas a longo prazo. Com o tempo, tais sistemas arriscam criar uma cultura de dependência, minando a iniciativa pessoal e prendendo indivíduos numa estagnação económica.

Peso Económico

A pressão financeira do Estado Social está a intensificar-se com as mudanças demográficas na Europa. Populações mais envelhecidas requerem maior apoio, elevando os custos e exigindo impostos mais altos ou gastos públicos acrescidos. Isso desvia recursos da inovação e do investimento, podendo travar o crescimento económico. Sem reformas, estas despesas crescentes podem tornar-se insustentáveis, obrigando os governos a encontrar soluções que mantenham o apoio sem comprometer as finanças.

Estigma Social

Além das questões económicas, a assistência social traz muitas vezes um custo social. Os beneficiários enfrentam frequentemente estereótipos de preguiça ou incompetência, o que gera vergonha e diminui a autoestima. Este estigma pode dificultar a mobilidade social, tornando mais complicado sair da dependência. Resolver isto exige um sistema que não só apoie, mas também capacite, reduzindo preconceitos e promovendo inclusão.

Face a estas falhas, a Europa precisa de explorar alternativas que prestem ajuda de forma mais eficaz. O Imposto sobre o Rendimento Negativo apresenta-se como uma opção promissora, capaz de enfrentar estas questões sistémicas.

O Caso Contra o Rendimento Básico Universal (RBU)

O Rendimento Básico Universal surgiu como uma ideia ousada para combater a pobreza e a desigualdade, oferecendo a cada cidadão um pagamento fixo independentemente das suas necessidades. No entanto, a sua simplicidade traz desvantagens significativas.

O custo do RBU é um obstáculo enorme. Implementá-lo em toda a Europa exigiria fundos avultados, pressionando orçamentos já sobrecarregados pelos compromissos actuais do Estado Social. Isso poderia implicar subidas acentuadas de impostos ou cortes noutros serviços, enquanto a criação da infraestrutura administrativa necessária traria mais despesas. Há também quem tema os desincentivos ao trabalho: se todos receberem o mesmo valor, alguns podem sentir menos motivação para trabalhar ou arriscar em projectos empreendedores, podendo afectar a vitalidade económica.

Além disso, a abordagem universal do RBU sacrifica eficiência. Ao distribuir fundos de forma igual, não dá prioridade a quem mais precisa, entregando recursos aos mais ricos enquanto dilui o impacto sobre os pobres. Esta falta de foco levanta dúvidas sobre a sua capacidade de combater a desigualdade de forma eficaz. Embora o apelo do RBU esteja na sua universalidade, estes desafios apontam para a necessidade de uma solução mais direccionada—e é aqui que o IRN entra em cena.

Compreender o Imposto sobre o Rendimento Negativo (IRN)

O Imposto sobre o Rendimento Negativo propõe uma abordagem refinada ao apoio social, combinando assistência com incentivos. No seu cerne, define um limiar de rendimento base—digamos, 1.000 euros por mês. Quem ganha menos recebe um subsídio proporcional à diferença, enquanto quem ultrapassa esse valor paga impostos para financiar o sistema. Por exemplo, com uma taxa de subsídio de 50%, quem não tem rendimentos recebe 500 euros, e quem ganha 400 euros recebe 300 euros, elevando o total para 700 euros. À medida que o rendimento se aproxima do limiar, o subsídio diminui, desaparecendo nos 1.000 euros, altura em que a tributação começa.

Veja-se uma ilustração simples:

| Rendimento Mensal (€) | Pagamento IRN (€) | Rendimento Total Após IRN (€) | |-----------------------|-------------------|------------------------------| | 0 | 500 | 500 | | 400 | 300 | 700 | | 800 | 100 | 900 | | 1.000 | 0 | 1.000 | | 1.200 | - (impostos aplicam-se) | 1.200 - impostos |

Isto garante que trabalhar compensa sempre: ganhar mais aumenta o rendimento total, evitando a armadilha da assistência. O financiamento vem de um imposto fixo—talvez 19%—sobre os rendimentos acima do limiar. Quem ganha 1.500 euros, por exemplo, paga 95 euros sobre os 500 euros acima de 1.000, ficando com 1.405 euros. Este modelo fiscal simples facilita a gestão e assegura equidade.

| Rendimento (€) | Rendimento Tributável (€) | Imposto (€) | Após Imposto (€) | |----------------|---------------------|---------|------------------| | 1000 | 0 | 0 | 1000 | | 1200 | 200 | 38 | 1162 | | 2000 | 1000 | 190 | 1810 |

O IRN pode ser de participação voluntária, através de um contrato. As pessoas podem aderir ao sistema se precisarem de apoio ou rejeitá-lo se não aceitarem ajuda estatal, evitando os impostos associados ao financiamento do IRN. Quem optar por sair pode reentrar em caso de dificuldades, equilibrando liberdade de escolha com pragmatismo. Para libertários desconfiados de ingerências governamentais, isto torna o IRN um compromisso—um passo para longe do assistencialismo coercivo e em direcção a maior autonomia.

Filosoficamente, o IRN não é um objectivo final, mas uma ponte. Ao simplificar a ajuda e reduzir a burocracia, pode abrir caminho para soluções privadas, como caridade ou apoio mútuo, diminuindo o papel do estado ao longo do tempo. Características como a avaliação de meios e a indexação à inflação reforçam a sua adaptabilidade, garantindo que o apoio permaneça justo e relevante.

Vantagens do Imposto sobre o Rendimento Negativo (IRN)

O IRN destaca-se onde o Estado Social tradicional falha. Os seus subsídios decrescentes incentivam o trabalho, premiando o esforço à medida que o rendimento sobe e impulsionando a produtividade. Isto contrasta fortemente com as armadilhas da assistência, encorajando as pessoas a procurarem formação ou a arriscarem em empreendedorismo sem medo de perder apoio de repente.

Na gestão, o IRN é revolucionário. Substituir um emaranhado de programas por um único sistema reduz a burocracia e os custos, canalizando recursos directamente para quem precisa. Um processo de pagamento único elimina sobreposições, tornando a entrega de ajuda mais rápida e eficiente.

A dignidade é outro ponto forte. Ao oferecer escolha e evitar supervisão intrusiva, o IRN escapa ao estigma do assistencialismo, dando aos beneficiários autonomia para gerir as suas finanças. Isso promove o autorrespeito e um sentido de controlo, quebrando o ciclo de dependência.

Economicamente, a flexibilidade do IRN sobressai. Adapta-se às flutuações de rendimento, direccionando a ajuda exactamente onde é necessária. Estudos indicam que pode reduzir a pobreza, melhorar a mobilidade social e até beneficiar a saúde, ao aliviar o stress financeiro, oferecendo um impulso abrangente ao bem-estar.

Responder às Críticas ao Imposto sobre o Rendimento Negativo (IRN)

Nenhuma política escapa a críticas, e o IRN tem as suas. Os libertários veem, e bem, os impostos como roubo, e embora o IRN não elimine esta tensão, suaviza-a. Ao condensar o Estado Social num sistema claro e simples, reduz a intromissão estatal face à burocracia actual. Os seus incentivos ao trabalho alinham-se com valores de responsabilidade, tornando-o um passo aceitável a curto prazo.

O financiamento preocupa, sobretudo em países europeus já muito tributados, mas uma taxa fixa oferece uma solução. Simples e previsível, minimiza os custos administrativos e assegura contribuições justas, sustentando o IRN sem sobrecarga excessiva. Há também quem debata o seu impacto social—uns chamam-lhe um subsídio fácil, um hand-out, outros um sistema demasiado voltado para o mercado. Ainda assim, o IRN encontra um meio-termo, oferecendo uma rede de segurança que recompensa o esforço sem controlar vidas.

Passar para o IRN exige eliminar gradualmente os programas antigos e informar o público sobre os seus benefícios: um governo mais leve, menos dependência e maior iniciativa pessoal. Para quem sonha com um futuro sem estado, o IRN não é o destino, mas um movimento prático rumo a sistemas de apoio voluntários, promovendo uma cultura de autossuficiência.

Conclusão

O Imposto sobre o Rendimento Negativo não é perfeito, mas é um avanço claro face ao status quo. Reduz os excessos do Estado Social, promove trabalho e dignidade, e oferece à Europa uma reforma viável perante as pressões económicas. Para os contribuintes, promete eficiência; para os beneficiários, oportunidade. Numa região onde o assistencialismo está profundamente enraizado, o IRN surge como um passo ousado, mas possível, para um futuro mais livre e sustentável—um que capacite as pessoas enquanto alivia o peso do estado.

---

Photo by The New York Public Library on Unsplash

@ 6d5c826a:4b27b659

• Darcs - Cross-platform version control system, like git, mercurial or svn but with a very different approach: focus on changes rather than snapshots. (Source Code) GPL-2.0 Haskell
• Fossil - Distributed version control with built-in wiki and bug tracking. (Source Code) BSD-2-Clause C
• Git - Distributed revision control and source code management (SCM) with an emphasis on speed. (Source Code) GPL-2.0 C
• Mercurial - Distributed source control management tool. (Source Code) GPL-2.0 Python/C/Rust
• Subversion - Client-server revision control system. (Source Code) Apache-2.0 C

@ 8e7462a8:c723a97b

Here's some code!

```js import React, { useEffect, useState } from "react"; import { useNDKContext } from "@/context/NDKContext"; import { parseEvent } from "@/utils/nostr"; import { ProgressSpinner } from "primereact/progressspinner";

const PurchasedListItem = ({ eventId, category }) => { const { ndk } = useNDKContext(); const [event, setEvent] = useState(null);

useEffect(() => {
    const fetchEvent = async () => {
        if (!eventId) return;

        try {
            await ndk.connect();
            const event = await ndk.fetchEvent(eventId);
            if (event) {
                setEvent(parseEvent(event));
            }
        } catch (error) {
            console.error("Error fetching event:", error);
        }
    }
    fetchEvent();
}, [eventId, ndk]);

return !event || !ndk ? <ProgressSpinner className="w-[40px] h-[40px]" /> : (<a className="text-blue-500 underline hover:text-blue-600" href={category === "courses" ? `/courses/${event.id}` : `/details/${event.id}`}>{event.title}</a>);

}

export default PurchasedListItem; ```

@ 3bf0c63f:aefa459d

P2Panda and the super-peer curse

Recently was suggested to me that https://p2panda.org/ was a great protocol and that maybe Nostr wouldn't be necessary if we could just use that. After making the blind remark that p2p doesn't work I was pointed to https://github.com/p2panda/aquadoggo which acts as a "node" in some ways similar to a "relay", and it all looks somewhat well, cool, maybe they're into something:

Then I realized that Aquadoggo isn't really a relay, it is more like an "app server". There are still no relays in the Nostr sense in p2panda, the base of communication is still p2p between "nodes", and, as Aquadoggo's readme say, it could be run both as a client and as a server. In other words, we could easily have an "Nostr Aquadoggo" that abstracts all communication with relays, relay selection, event and tag parsing and signatures then stores filtered, ordered, indexed data locally: it is just a Nostr client.

That you can put one of these in a server doesn't change that fact that it will be still a client -- and that underlings behind it consuming its API will be controlled, censored, mislead and tricked. This design that requires trust in one single server from a dumb client in exchange for massaged, sorted, filtered, ordered data is seen not only in p2panda, but it's also a fundamental part of the design in many of the supposed decentralized protocols out there, including Bluesky, Farcaster and Pubky. It has also found its way even into RSS, with feed aggregators, and into IRC with bouncers. It can also be seen being experimented with inside Nostr, with ZBD Social, Primal, Ditto, Satlantis and others I forgot, and even behind the ideas of some pseudo-relays like Bostr and filter.nostr.wine (although I'm not sure). Notably, though, this design is not a part of SSB or Mastodon and these two weren't ever corrupted by it as far as I know.

In any case, should we accept that such architecture will eventually find its way into Nostr and completely dominate it? If I believed the answer was "yes" I would immediately declare Nostr a failed experiment, but I don't. As the main author of one such experiment (ZBD Social), I still think this architecture isn't necessarily bad as long as it's limited and restricted to certain circumstances, but it does pose a risk of Nostr becoming almost as bad as Bluesky, so the path has to be threaded carefully.

Ultimately, though, what all these protocols are trying to achieve by injecting these dangerous super-peers into their architecture is the reliability that pure p2p cannot provide, along with filtering and discovery features. And Nostr's multi-relay architecture, as cumbersome and weird as it is, represents a very different approach to solving the same problems, one that none of these other protocols can even begin to consider emulating, and I believe we have to accept that, embrace it and lean on it more.

We can go there by having whitelisted relays as communities, relays that enforce group rules automatically, relays that provide fulltext search, relays that provide AI-based personalized custom feeds, relays that filter out reply spam or harassment (or enforce blocks at the server-side), relays that restrict reads to a certain selected group, relays that perform curation and make valuable content reemerge from the abyss of the ongoing stream; and of course clients that surface all these different types of relays and their features.

Why is this complex madness better than the super-peer architecture? Because, well, even though custom relays give us all these cool weird features, The basic Nostr feature of being able to follow anyone you want and not giving a super-peer the power to break that link between follower and followed, i.e. the outbox model, is still the most basic function of relays.

@ 6bae33c8:607272e8

BCL2 took place today. I drew the third pick.

Here are the results:

1.3 Ja’Marr Chase — I didn’t want Christian McCalfinjury, of whom I already have a share, so I was set on CeeDee Lamb or Tyreek Hill if they were there. But I had an inkling they might go 1-2 in which case Ja’Marr Chase was narrowly my fallback over Amon Ra St. Brown and Breece Hall. Chase has St. Brown’s target upside, but with a much bigger vertical game. The biggest negative for him is Burrow’s health, but Burrow’s fine now, and anyone can get hurt. I also thought maybe I’d draft Tee Higgins if he fell to me in Round 5 (which was unlikely) in which case I’d try to get Burrow too.

2.10 Jaylen Waddle — It was Waddle the solid, boring pick or Malik Nabers the fun, exciting one. Team 4 did me a favor and took De’Von Achane out of the equation — I have Achane in BCL1, and while I love his upside, he’s not the kind of player to which you tie all your teams. I narrowly went Waddle who actually has upside too if Tyreek Hill ever got hurt.

3.10 Malik Nabers — I couldn’t believe it, but Nabers made it all the way back despite third-round reversal. I love Nabers, but I think the market is over-drafting him slightly relative to his projected target share. I mean he might get 150, but I think 130-140 Daniel Jones targets is more likely, and that’s a third, not a second-round pick. ** 4.3 Stefon Diggs** — This was going perfectly. Had Nabers been taken, I would have gone Diggs in Round 3, but he was still there four picks later. I’ve mentioned before I have Diggs as a top-10-ish WR.

5.10 Anthony Richardson — I took Reachardson early because I didn’t need another receiver (would be my first bench spot), the running back I liked best was still likely to be back in Round 6 too, and I couldn’t bring myself to take Kyle Pitts who has burned me so many times. ** 6.3 Rhamondre Stevenson** — Backs were flying off the board in this draft which figures because I went so WR-heavy, but I think Stevenson is good, and there’s no way the Patriots offense won’t be better than last year’s just from pure regression to the mean.

7.10 Javonte Williams — Another good back on a bad team, Williams’ 2023 was not representative given he was only one year removed from an ACL tear. We should see the real version this year, and I expect him to be the main guy in Denver. ** 8.3 Ladd McConkey** — This was a luxury pick, but I liked the value too much, and I wasn’t in love with any of the RB or TE at cost. (I missed out on Jake Ferguson right after the Williams pick.) But the McConkey pick cost me Zack Moss, Devin Singletary, Nick Chubb, Brian Robinson, Chase Brown, Blake Corum and Tyjae Spears.

9.10 Brock Bowers — I missed out on David Njoku by one pick too, so it was time to get Bowers, the last of that tier of tight ends.

10.3 Jerome Ford — He’s Nick Chubb’s backup at worst, and that assumes Chubb will even be at full health any time soon.

11.10 Rashid Shaheed — Another luxury pick, but I couldn’t pass him up here. I’ve mentioned many times, I think he’s as good as Chris Olave, and there are only two of them now, so Shaheed should see his share of targets, either way. Shaheed cost me Zach Charbonnet and Cole Kmet though.

12.3 J.K. Dobbins — I’m not a big Gus Edwards believer — he’s 29 and with a limited skill set. Dobbins can never stay healthy, but worth a flyer here on what should be a run-heavy offense.

13.10 Kimani Vidal — Sounds like a high-end hair salon, but he’s actually the fallback if Dobbins and Edwards don’t pan out. I like his build (5-8, 215), speed and pass-catching skills.

14.3 Bucky Irving — I’m not sold on Rachaad White being anything special, and Irving is his backup. I needed a lot of lottery ticket backs with this build. ** 15.10 Khalil Herbert** — There are rumors he could be moved, but either way, I don’t trust D’Andre Soft, and Roschon Johnson is just a guy.

16.3 Jonnu Smith — This was a bit early per ADP, but I needed a second TE, and Smith has a lot of upside in an offense that’s so top heavy.

17.10 Justin Fields — In the likely event Russell Wilson is cooked, Fields is a top-10 fantasy quarterback already. I thought about Danny Dimes too. ** 18.3 Younghoe Koo** — I’m tired of drafting Justin Tucker every year, felt it was time for a Younghoe.

19.10 Giants Defense — They get the Sam Darnold Vikings in Week 1, the Football Team in Week 2. And they now have three elite pass rushers in Kayvon Thibodeaux, Dexter Lawrence and Brian Burns.

20.3 Roman Wilson — I wanted to take Danny Dimes, but Wilson could easily be the Steelers’ slot guy — Van Jefferson is bad, and even George Pickens is more of a highlight-reel guy who doesn’t command massive target share.

Roster By Position

QB Anthony Richardson

RB Rhamondre Stevenson/Javonte Williams

WR Ja’Marr Chase/Jaylen Waddle/Malik Nabers

TE Brock Bowers

FLEX Stefon Diggs

K Younghoe Koo

D Giants

B Ladd McConkey/Jerome Ford/Rashid Shaheed/J.K. Dobbins/Kimani Vidal/Bucky Irving/Khalil Herbert/Jonnu Smith/Justin Fields/Roman Wilson

@ 6d5c826a:4b27b659

• grml - Bootable Debian Live CD with powerful CLI tools. (Source Code) GPL-3.0 Shell
• mitmproxy - A Python tool used for intercepting, viewing and modifying network traffic. Invaluable in troubleshooting certain problems. (Source Code) MIT Python
• mtr - Network utility that combines traceroute and ping. (Source Code) GPL-2.0 C
• Sysdig - Capture system state and activity from a running Linux instance, then save, filter and analyze. (Source Code) Apache-2.0 Docker/Lua/C
• Wireshark - The world's foremost network protocol analyzer. (Source Code) GPL-2.0 C

@ 3bf0c63f:aefa459d

document.characterSet and another meaningless example of flexibility destroying protocols

I always knew of at least two standardized ways browsers used to determine the charset of a given webpage document: the Content-Type header and the <meta charset> tag. These are widely understood, teached and documented specs that a lot of developers assume are being followed because they're "web standards".

Turns out there are a lot of pages on the internet that declare themselves as UTF-8 but are actually using other types of encoding (here's an example), and just by looking at the headers and meta tags you would think they are actually UTF-8, since they render correctly on Chromium and Firefox.

But the actual truth is that browsers actually ignore these headers completely and use their own internal heuristics to determine the actual charset. And they expose their internal result in the DOM property document.characterSet.

"Oh, that's great! Technology is awesome, they've fixed a problem!", you may think. But the actual result of that is:

1. developers never learn that they're wrongly declaring "UTF-8" when their content is actually "windows-1252" because they never see their page being rendered wrongly;
2. the actual spec is now that browsers should correctly guess a page encoding instead of just following what is written;
3. people are fooled and continue to teach, learn (and write) the falsehood of these useless HTTP headers and <meta> tags not knowing they are completely wrong.
4. new browsers coming to the space have to first learn that this is a thing, which is not obvious nor written anywhere, then they must implement it, because if they follow the spec people will think it is their fault that some broken pages are rendered with broken characters on this new browser;
5. barriers to entry are higher, the protocol continues to centralize more and more;
6. other people trying to read these HTML pages for whatever reason, from any software that isn't Google Chrome or Mozilla Firefox, will have the same problem and will have to learn everything and come up with their own charset detection mechanism, this again closes the content of webpages to being more and more restricted to the walled garden of existing browser vendors.

I think we can all agree these are not good outcomes.

In the end of things, this is just a very small example, but "the web" protocol has thousands of such small examples, and they add up.

Also, arguably the spec should have been "browsers must do their own charset detection" since the beginning, but that's irrelevant. The fact is that it wasn't (and still isn't, the specs weren't updated as far as I know), and here's again another undeniable example of how being flexible can bloat a protocol.

@ 6d5c826a:4b27b659

• Docker Compose - Define and run multi-container Docker applications. (Source Code) Apache-2.0 Go
• Docker Swarm - Manage cluster of Docker Engines. (Source Code) Apache-2.0 Go
• Docker - Platform for developers and sysadmins to build, ship, and run distributed applications. (Source Code) Apache-2.0 Go
• LXC - Userspace interface for the Linux kernel containment features. (Source Code) GPL-2.0 C
• LXD - Container "hypervisor" and a better UX for LXC. (Source Code) Apache-2.0 Go
• OpenVZ - Container-based virtualization for Linux. (Source Code) GPL-2.0 C
• Podman - Daemonless container engine for developing, managing, and running OCI Containers on your Linux System. Containers can either be run as root or in rootless mode. Simply put: alias docker=podman. (Source Code) Apache-2.0 Go
• Portainer Community Edition - Simple management UI for Docker. (Source Code) Zlib Go
• systemd-nspawn - Lightweight, chroot-like, environment to run an OS or command directly under systemd. (Source Code) GPL-2.0 C

@ eed76ece:afa98124

Hopefully people out there that are importers, exporters, agents, traders, wholesalers in various types of goods, will eventually post, or at the very least find some possible business leads, contacts and most importantly reviews on payments methods using Bitcoin around the World.

The Good News

1. Wholesale and Retail merchants have heard the Independent, Democratic and Republican parties are speaking in a positive tone about Bitcoin and the C word in general. Whether any of them actually will do anything in the future is another issue, note the fact that Bitcoin and the C word is being brought up in a positive way is a good.

2. Bitcoin Dev groups are opening up in more places around the World and obviously some general education, terminology and introduction to Lightning, Nostr, and hybrid point of sale systems are slowly be added to merchants retail and wholesale.

3. Shopify, As the majority of business are using Shopify, Open Node is easily added as a payment method to accept Bitcoin. (I'm using it) works fine, had to as ibexpay left supporting the USA.

4. "Just hodl" comes up more and more in conversations with my peers, asking with a confused look "When do we use it, circulate it in transacting buying or selling goods (wholesale), NOT just a cup of coffee, we are just suppose to hodl, and never use it ?

5. We have SN, we should be thankful it's a positive tool.

If anyone wants to communicate with other manufacturers, wholesalers, B2B merchants, importers, exporters, agents selling goods of any type consider reaching out as a post on SN, or contacting me directly, hopefully that you are considering using Bitcoin as the payment method.

Stay humble use SATS

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

@ 6d5c826a:4b27b659

• Consul - Consul is a tool for service discovery, monitoring and configuration. (Source Code) MPL-2.0 Go
• etcd - Distributed K/V-Store, authenticating via SSL PKI and a REST HTTP Api for shared configuration and service discovery. (Source Code) Apache-2.0 Go
• ZooKeeper - ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. (Source Code) Apache-2.0 Java/C++

@ 6d5c826a:4b27b659

• DD-WRT - A Linux-based firmware for wireless routers and access points, originally designed for the Linksys WRT54G series. (Source Code) GPL-2.0 C
• OpenWrt - A Linux-based router featuring Mesh networking, IPS via snort and AQM among many other features. (Source Code) GPL-2.0 C
• OPNsense - An open source FreeBSD-based firewall and router with traffic shaping, load balancing, and virtual private network capabilities. (Source Code) BSD-2-Clause C/PHP
• pfSense CE - Free network firewall distribution, based on the FreeBSD operating system with a custom kernel and including third party free software packages for additional functionality. (Source Code) Apache-2.0 Shell/PHP/Other

@ 8f69ac99:4f92f5fd

Anarquia: uma palavra que frequentemente evoca imagens de caos e desordem, associada ao velho oeste sem lei ou a futuros distópicos onde impera a força bruta. No entanto, para aqueles que investigam mais a fundo, a anarquia revela-se como algo muito mais sofisticado—um sistema não definido pela ausência de regras, mas sim pela ausência de governantes (rules without rulers). Essa distinção fundamental é essencial para compreender um dos conceitos mais fascinantes e, ao mesmo tempo, mais difamados da sociedade.

A ideia de que anarquia significa desordem ou uma sociedade sem estrutura é um equívoco baseado no medo do desconhecido e na falta de compreensão dos seus princípios básicos. Na realidade, a anarquia assenta sobre um princípio fundamental: o Princípio da Não-Agressão (PNA). Este princípio estabelece que nenhum indivíduo tem o direito de iniciar o uso da força, coerção ou fraude contra os outros, sem o seu consentimento, sendo este um dos pilares fundamentais para a preservação da propriedade privada e das liberdades individuais.

Não se trata, portanto, de uma sociedade sem regras, mas sim de uma organização baseada em estruturas legais descentralizadas e orgânicas, como a lei natural e o direito consuetudinário, que emergem naturalmente através das interacções voluntárias entre indivíduos. A história demonstra que, mesmo na ausência de uma autoridade central, os seres humanos são perfeitamente capazes de criar ordens sociais complexas, baseadas na cooperação, na ajuda mútua e no progresso.

Este artigo explora como a anarquia funciona enquanto sistema de cooperação voluntária e direito natural, desafiando as concepções erradas que persistem sobre o tema e revelando o seu potencial para fortalecer a liberdade individual e a coesão social. Ao analisar as suas raízes filosóficas, o papel do Estado dentro de um enquadramento anarquista e os exemplos históricos que demonstram a capacidade da humanidade para se auto-organizar, procuramos iluminar um futuro onde a liberdade não seja apenas um sonho utópico, mas uma possibilidade concreta.

Principio da Não Agressão (PNA)

A base da anarquia assenta sobre um princípio inegociável: o Princípio da Não-Agressão. Este postulado não é apenas uma directriz moral, mas sim uma regra essencial de conduta, destinada a fomentar uma sociedade cooperativa e pacífica, onde os indivíduos vivem sem medo da coerção ou da violência.

A partir deste princípio, deriva-se naturalmente a propriedade privada, pois cada indivíduo tem o direito de usufruir e gerir os recursos que adquire sem recorrer à força contra terceiros. Da mesma forma, a violação deste princípio—seja através do roubo, homicídio ou qualquer tipo de agressão física ou psicológica, não consentida—é condenada de forma universal, pois representa um atentado contra a liberdade de cada um.

Num enquadramento anarquista, a ausência de uma estrutura coerciva não significa a ausência de ordem. Métodos como pressão social, ostracismo de infractores e mecanismos privados de justiça ajudam a manter a harmonia social. Por exemplo, em situações de litígio entre vizinhos sobre a posse de um terreno, em vez de recorrer ao Estado, poderiam simplesmente resolver a disputa através de um mediador comunitário ou de um serviço de arbitragem voluntário.

Ordem Sem Autoridade Central

A crença de que a lei e a ordem dependem de um poder centralizado ignora uma vasta tradição histórica de sistemas legais descentralizados que surgiram espontaneamente, sem intervenção estatal. A anarquia não significa ausência de normas, mas sim uma ordem espontânea baseada em leis naturais e consuetudinárias.

A lei natural consiste em princípios universais, reconhecidos pela razão, que não dependem da autoridade estatal. Já o direito consuetudinário assenta na tradição e nos precedentes, evoluindo conforme as necessidades das comunidades. Um excelente exemplo histórico é o código jurídico medieval islandês "Grágás", que regulava litígios e contratos através de mediação voluntária.

Sistemas baseados na reputação também são eficazes. No passado, comerciantes que desrespeitassem contratos viam-se rapidamente excluídos do mercado. Hoje, soluções descentralizadas como a arbitragem privada demonstram que contratos podem ser cumpridos sem necessidade de coerção estatal.

Anarquia como Estado Natural da Cooperação Humana

A cooperação voluntária está no cerne da natureza humana. A ideia de que é necessária uma autoridade central para garantir harmonia social desconsidera as inúmeras instâncias de colaboração espontânea ao longo da história.

O funcionamento dos mercados ilustra perfeitamente a anarquia em acção. Sem um governo a ditar regras, indivíduos interagem livremente, criando riqueza e inovação. A busca pelo progresso científico também reflecte este princípio: Albert Einstein, Nikola Tesla, Henry Ford ou Thomas Edison não foram forçados pelo Estado a desenvolver as suas invenções—fizeram-no por interesse próprio, beneficiando toda a humanidade.

Da mesma forma, a revolução industrial não foi um plano centralizado, mas sim o resultado de inúmeras inovações individuais que impulsionaram a prosperidade global. A tecnologia moderna, com exemplos como Bitcoin e Nostr, redes descentralizadas, prova que sociedades podem operar sem intermediários estatais, ou autoridades centrais.

Estado: Pode Existir Num Enquadramento Anarquista?

O Estado, mesmo na sua versão mais reduzida, pode representar um risco para a liberdade individual. Alguns, eu incluído, argumentam que um "Estado mínimo" (minarquia) poderia existir para garantir segurança e mediar disputas, mas essa estrutura pode rapidamente expandir-se e transformar-se num mecanismo de coerção.

A necessidade de mecanismos de controlo e equilíbrio

Mesmo um Estado reduzido exigiria salvaguardas para evitar abusos de poder. Para isso, seriam necessários mecanismos que garantam que nenhuma autoridade se torne dominante e que a sociedade mantenha a sua autonomia.

Algumas soluções incluem:

• Representação directa: Em vez de delegar decisões a políticos, a população poderia ter mais influência directa nas questões que afectam a sua vida (como na Suiça por exemplo).
• Arbitragem independente: Conflitos poderiam ser resolvidos sem recorrer a tribunais estatais, através de mediação voluntária e sistemas de justiça comunitária.
• Redes de apoio social: Fortalecer redes de ajuda mútua reduziria a necessidade de um governo central para fornecer serviços essenciais.

Exemplos práticos

Algumas iniciativas mostram que a sociedade pode funcionar com estruturas descentralizadas:

• Cidades com participação cívica activa: Experiências como o orçamento participativo em algumas cidades demonstram como a sociedade pode gerir recursos colectivos sem excessiva intervenção estatal.
• Redes de ajuda mútua: Grupos como a Mutual Aid Disaster Response Network nos EUA provam que comunidades podem organizar-se para responder a crises sem depender do Estado.

O desafio não é apenas imaginar um mundo sem Estado, mas conceber modelos descentralizados que garantam a liberdade individual e impeçam a concentração de poder. A verdadeira questão é: conseguiremos criar sistemas mais justos e funcionais sem recorrer à coerção estatal?

Raízes Filosóficas da Anarquia

A anarquia tem uma longa tradição filosófica que remonta a pensadores como William Godwin, Pierre-Joseph Proudhon e Max Stirner, cada um contribuindo com diferentes perspectivas sobre a organização social sem governantes. No século XX, pensadores como Murray Rothbard e Hans-Hermann Hoppe aprofundaram a ideia do anarco-capitalismo, propondo que todos os serviços actualmente providenciados pelo Estado poderiam ser oferecidos por meio de mercados livres.

A raiz histórica da anarquia está firmemente ancorada no pensamento de esquerda (a tradicional... ), na medida em que a sua proposta fundamental é a eliminação do poder central. O anarquismo clássico emergiu como uma resposta ao absolutismo e ao capitalismo industrial, defendendo que a autoridade imposta pelo Estado e pelas elites económicas deveria ser desmantelada para dar lugar a um sistema de cooperação voluntária e descentralizada. Proudhon, ao afirmar "a propriedade é roubo", reflectia esta preocupação com a concentração de poder e riqueza nas mãos de poucos.

Com o tempo, no entanto, diferentes correntes começaram a emergir dentro da tradição anarquista. A tradição anarquista de esquerda enfatiza a justiça social e a solidariedade comunitária, rejeitando tanto o Estado como o capitalismo. Nomes como Bakunin e Kropotkin defenderam a abolição da propriedade privada em favor de sistemas cooperativos, argumentando que apenas a auto gestão e o apoio mútuo poderiam garantir a verdadeira liberdade.

Por outro lado, no século XX, surgiu uma vertente anarquista mais associada à direita, especialmente com Rothbard e Hoppe, que viam o mercado como a melhor alternativa ao Estado. Para os anarco-capitalistas, a liberdade individual é prioritária, e a descentralização deve ocorrer não apenas ao nível político, mas também económico, permitindo que todas as transacções sejam voluntárias e baseadas na propriedade privada.

Apesar dessas divergências, há um ponto comum entre todas as vertentes anarquistas: a rejeição do monopólio da violência estatal. Tanto anarquistas de esquerda quanto de direita reconhecem que o poder centralizado inevitavelmente conduz à opressão e à limitação da liberdade individual. O debate interno dentro do anarquismo não é sobre a necessidade de abolir o Estado, mas sim sobre o que deve substituí-lo: auto gestão comunitária e colectivismo ou mercados livres e concorrência voluntária?

A preservação da propriedade privada e a liberdade de associação são, para mim, princípios fundamentais dentro do pensamento anarquista. Nada impede que, numa sociedade anarquista, grupos de indivíduos escolham unir-se voluntariamente para formar projectos cooperativos baseados em valores partilhados. O que distingue essa abordagem da imposição estatal é o carácter voluntário e descentralizado dessas associações, garantindo que cada pessoa possa viver conforme os seus próprios princípios sem coerção externa.

Esta dicotomia entre esquerda e direita dentro do anarquismo reflecte diferentes interpretações sobre a melhor forma de organizar a sociedade sem coerção. O que permanece inegável é que a anarquia, independentemente da vertente, continua a ser uma proposta de resistência contra qualquer forma de domínio centralizado, colocando a liberdade e a autonomia no centro da organização social.

Conclusão

A anarquia não é um sonho utópico, mas sim uma alternativa viável à organização centralizada da sociedade. Através do respeito pelo Princípio da Não-Agressão, da descentralização das normas jurídicas e da cooperação voluntária, podemos construir um mundo mais livre, onde as pessoas têm o poder de se governar a si mesmas.

Sistemas como Bitcoin já demonstram que a descentralização funciona e que a ausência de intermediários coercivos é não só possível, mas desejável. O desafio não é saber se a anarquia pode funcionar, mas sim quanto tempo levará para as pessoas perceberem que um mundo sem Estado é mais próspero e justo.

anarquia #anarco #bitcoin

---

Photo by Orit Matee on Unsplash

@ 6d5c826a:4b27b659

• Remmina - Feature-rich remote desktop application for linux and other unixes. (Source Code) GPL-2.0 C
• Tiger VNC - High-performance, multi-platform VNC client and server. (Source Code) GPL-2.0 C++
• X2go - X2Go is an open source remote desktop software for Linux that uses the NoMachine/NX technology protocol. (Source Code) GPL-2.0 Perl

@ 6d5c826a:4b27b659

• ActiveMQ - Java message broker. (Source Code) Apache-2.0 Java
• BeanstalkD - A simple, fast work queue. (Source Code) MIT C
• Gearman - Fast multi-language queuing/job processing platform. (Source Code) BSD-3-Clause C++
• NSQ - A realtime distributed messaging platform. (Source Code) MPL-2.0 Go
• ZeroMQ - Lightweight queuing system. (Source Code) GPL-3.0 C++

@ 09fbf8f3:fa3d60f0

由于gmail在中国被防火墙拦截了，无法打开，不想错过邮件通知。

通过自建ntfy接受gmail邮件通知。 怎么自建ntfy，后面再写。

---

2024年08月13日更新：

修改不通过添加邮件标签来标记已经发送的通知，通过Google Sheets来记录已经发送的通知。

为了不让Google Sheets文档的内容很多，导致文件变大，用脚本自动清理一个星期以前的数据。

---

准备工具

• Ntfy服务
• Google Script
• Google Sheets

操作步骤

1. 在Ntfy后台账号，设置访问令牌。
2. 添加订阅主题。
3. 进入Google Sheets创建一个表格.记住id，如下图：
4. 进入Google Script创建项目。填入以下代码（注意填入之前的ntfy地址和令牌）：

```javascript function checkEmail() { var sheetId = "你的Google Sheets id"; // 替换为你的 Google Sheets ID var sheet = SpreadsheetApp.openById(sheetId).getActiveSheet();

// 清理一星期以前的数据 cleanOldData(sheet, 7 * 24 * 60); // 保留7天（即一周）内的数据

var sentEmails = getSentEmails(sheet);

var threads = GmailApp.search('is:unread'); Logger.log("Found threads: " + threads.length);

if (threads.length === 0) return;

threads.forEach(function(thread) { var threadId = thread.getId();

if (!sentEmails.includes(threadId)) {
  thread.getMessages().forEach(sendNtfyNotification);
  recordSentEmail(sheet, threadId);
}

}); }

function sendNtfyNotification(email) { if (!email) { Logger.log("Email object is undefined or null."); return; }

var message = `发件人: ${email.getFrom() || "未知发件人"} 主题: ${email.getSubject() || "无主题"}

内容: ${email.getPlainBody() || "无内容"}`;

var url = "https://你的ntfy地址/Gmail"; var options = { method: "post", payload: message, headers: { Authorization: "Bearer Ntfy的令牌" }, muteHttpExceptions: true };

try { var response = UrlFetchApp.fetch(url, options); Logger.log("Response: " + response.getContentText()); } catch (e) { Logger.log("Error: " + e.message); } }

function getSentEmails(sheet) { var data = sheet.getDataRange().getValues(); return data.map(row => row[0]); // Assuming email IDs are stored in the first column }

function recordSentEmail(sheet, threadId) { sheet.appendRow([threadId, new Date()]); }

function cleanOldData(sheet, minutes) { var now = new Date(); var thresholdDate = new Date(now.getTime() - minutes * 60 * 1000); // 获取X分钟前的时间

var data = sheet.getDataRange().getValues(); var rowsToDelete = [];

data.forEach(function(row, index) { var date = new Date(row[1]); // 假设日期保存在第二列 if (date < thresholdDate) { rowsToDelete.push(index + 1); // 存储要删除的行号 } });

// 逆序删除（从最后一行开始删除，以避免行号改变） rowsToDelete.reverse().forEach(function(row) { sheet.deleteRow(row); }); }

```

4.Goole Script需要添加gmail服务，如图：

5.Google Script是有限制的不能频繁调用，可以设置五分钟调用一次。如图：

结尾

本人不会代码，以上代码都是通过chatgpt生成的。经过多次修改，刚开始会一直发送通知，后面修改后将已发送的通知放到一个“通知”的标签里。后续不会再次发送通知。

如需要发送通知后自动标记已读，可以把代码复制到chatgpt给你写。

效果预览：

@ 6d5c826a:4b27b659

• aptly - Swiss army knife for Debian repository management. (Source Code) MIT Go
• fpm - Versatile multi format package creator. (Source Code) MIT Ruby
• omnibus-ruby - Easily create full-stack installers for your project across a variety of platforms. Apache-2.0 Ruby
• tito - Builds RPMs for git-based projects. GPL-2.0 Python

@ 35f3a26c:92ddf231

Share!

https://video.nostr.build/9217eb6231f0c18055329679f582b41b60e4e74359ba0d86b040f45ffaa480ae.mp4

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

@ 6d5c826a:4b27b659

• CapRover - Build your own PaaS in a few minutes. (Demo, Source Code) Apache-2.0 Docker/Nodejs
• Coolify - An open-source & self-hostable Heroku / Netlify alternative (and even more). (Source Code) Apache-2.0 Docker
• Dokku - An open-source PaaS (alternative to Heroku). (Source Code) MIT Docker/Shell/Go/deb
• fx - A tool to help you do Function as a Service with painless on your own servers. MIT Go
• Kubero - A self-hosted Heroku PaaS alternative for Kubernetes that implements GitOps. (Demo, Source Code) GPL-3.0 K8S/Nodejs/Go
• LocalStack - LocalStack is a fully functional local AWS cloud stack. This includes Lambda for serverless computation. (Source Code) Apache-2.0 Python/Docker/K8S
• Nhost - Firebase Alternative with GraphQL. Get a database and backend configured and ready in minutes. (Source Code) MIT Docker/Nodejs/Go
• OpenFaaS - Serverless Functions Made Simple for Docker & Kubernetes. (Source Code) MIT Go
• Tau - Easily build Cloud Computing Platforms with features like Serverless WebAssembly Functions, Frontend Hosting, CI/CD, Object Storage, K/V Database, and Pub-Sub Messaging. (Source Code) BSD-3-Clause Go/Rust/Docker
• Trusted-CGI - Lightweight self-hosted lambda/applications/cgi/serverless-functions platform. MIT Go/deb/Docker

@ a9434ee1:d5c885be

Markdown + X, Y, Z is a problem, but Markdown + N can fix that.
Where N = any type of Nostr event.

Whatever Markup language you choose, people will be referencing other Nostr events in it all the time. Since apps have to find ways to display those events (or the links to them) anyway, we mights as well use that as an opportunity.

Why can't Tables, for example, be embedded Nostr events?

Switching from Markdown to Asciidocs (because it has tables and some more technical stuff) still doesn’t make Tables a great experience. On mobile, Tables are notoriously hard to display in a useful way. It depends on the use case, size of the table, etc….

Creators need guarantees on these things being displayed the way they intended.
There’s a reason why most authors just embed pictures of tables instead. It has little to do with Markdown not really supporting tables and more with them ensuring readability and appropriate styling.

So what if you enhance Markdown not only with embedded Nostr Events but also with something like Hypernotes Widgets that serve as a preview/display for those Nostr Events?

That way: - you are still using the most simple and popular markup language - devs “only” have to implement one extra thing (Hypernotes) that handles all the complexity and extensibility from there - authors can create articles and wiki entries with interactive elements in them, can have the guarantee that they display properly, can use any styling that suits them, etc… - the worst case scenario of reading it in a random crappy app still displays the link to the event (including it's explanatory metadata)

Imagine custom interactive graphs, polls, media players, products, … embedded in articles BUT limited to the Nostr-verse for all interaction and data fetching.

(this article will be updated with UI prototypes and further thoughts)

@ 97c70a44:ad98e322

For the last couple of weeks, I've been dealing with the fallout of upgrading a web application to Svelte 5. Complaints about framework churn and migration annoyances aside, I've run into some interesting issues with the migration. So far, I haven't seen many other people register the same issues, so I thought it might be constructive for me to articulate them myself.

I'll try not to complain too much in this post, since I'm grateful for the many years of Svelte 3/4 I've enjoyed. But I don't think I'll be choosing Svelte for any new projects going forward. I hope my reflections here will be useful to others as well.

If you're interested in reproductions for the issues I mention here, you can find them below.

• Can't save state to indexeddb
• Component unmount results in undefined variables in closures

The Need for Speed

To start with, let me just quickly acknowledge what the Svelte team is trying to do. It seems like most of the substantial changes in version 5 are built around "deep reactivity", which allows for more granular reactivity, leading to better performance. Performance is good, and the Svelte team has always excelled at reconciling performance with DX.

In previous versions of Svelte, the main way this was achieved was with the Svelte compiler. There were many ancillary techniques involved in improving performance, but having a framework compile step gave the Svelte team a lot of leeway for rearranging things under the hood without making developers learn new concepts. This is what made Svelte so original in the beginning.

At the same time, it resulted in an even more opaque framework than usual, making it harder for developers to debug more complex issues. To make matters worse, the compiler had bugs, resulting in errors which could only be fixed by blindly refactoring the problem component. This happened to me personally at least half a dozen times, and is what ultimately pushed me to migrate to Svelte 5.

Nevertheless, I always felt it was an acceptable trade-off for speed and productivity. Sure, sometimes I had to delete my project and port it to a fresh repository every so often, but the framework was truly a pleasure to use.

Svelte is not Javascript

Svelte 5 doubled down on this tradeoff — which makes sense, because it's what sets the framework apart. The difference this time is that the abstraction/performance tradeoff did not stay in compiler land, but intruded into runtime in two important ways:

• The use of proxies to support deep reactivity
• Implicit component lifecycle state

Both of these changes improved performance and made the API for developers look slicker. What's not to like? Unfortunately, both of these features are classic examples of a leaky abstraction, and ultimately make things more complex for developers, not less.

Proxies are not objects

The use of proxies seems to have allowed the Svelte team to squeeze a little more performance out of the framework, without asking developers to do any extra work. Threading state through multiple levels of components without provoking unnecessary re-renders in frameworks like React is an infamously difficult chore.

Svelte's compiler avoided some of the pitfalls associated with virtual DOM diffing solutions, but evidently there was still enough of a performance gain to be had to justify the introduction of proxies. The Svelte team also seems to argue that their introduction represents an improvement in developer experience:

we... can maximise both efficiency and ergonomics.

Here's the problem: Svelte 5 looks simpler, but actually introduces more abstractions.

Using proxies to monitor array methods (for example) is appealing because it allows developers to forget all the goofy heuristics involved with making sure state was reactive and just push to the array. I can't count how many times I've written value = value to trigger reactivity in svelte 4.

In Svelte 4, developers had to understand how the Svelte compiler worked. The compiler, being a leaky abstraction, forced its users to know that assignment was how you signaled reactivity. In svelte 5, developers can just "forget" about the compiler!

Except they can't. All the introduction of new abstractions really accomplishes is the introduction of more complex heuristics that developers have to keep in their heads in order to get the compiler to act the way they want it to.

In fact, this is why after years of using Svelte, I found myself using Svelte stores more and more often, and reactive declarations less. The reason being that Svelte stores are just javascript. Calling update on a store is simple, and being able to reference them with a $ was just a nice bonus — nothing to remember, and if I mess up the compiler yells at me.

Proxies introduce a similar problem to reactive declarations, which is that they look like one thing but act like another on the edges.

When I started using Svelte 5, everything worked great — until I tried to save a proxy to indexeddb, at which point I got a DataCloneError. To make matters worse, it's impossible to reliably tell if something is a Proxy without try/catching a structured clone, which is a performance-intensive operation.

This forces the developer to remember what is and what isn't a Proxy, calling $state.snapshot every time they pass a proxy to a context that doesn't expect or know about them. This obviates all the nice abstractions they gave us in the first place.

Components are not functions

The reason virtual DOM took off way back in 2013 was the ability to model your application as composed functions, each of which takes data and spits out HTML. Svelte retained this paradigm, using a compiler to sidestep the inefficiencies of virtual DOM and the complexities of lifecycle methods.

In Svelte 5, component lifecycles are back, react-hooks style.

In React, hooks are an abstraction that allows developers to avoid writing all the stateful code associated with component lifecycle methods. Modern React tutorials universally recommend using hooks instead, which rely on the framework invisibly synchronizing state with the render tree.

While this does result in cleaner code, it also requires developers to tread carefully to avoid breaking the assumptions surrounding hooks. Just try accessing state in a setTimeout and you'll see what I mean.

Svelte 4 had a few gotchas like this — for example, async code that interacts with a component's DOM elements has to keep track of whether the component is unmounted. This is pretty similar to the kind of pattern you'd see in old React components that relied on lifecycle methods.

It seems to me that Svelte 5 has gone the React 16 route by adding implicit state related to component lifecycles in order to coordinate state changes and effects.

For example, here is an excerpt from the documentation for $effect:

You can place $effect anywhere, not just at the top level of a component, as long as it is called during component initialization (or while a parent effect is active). It is then tied to the lifecycle of the component (or parent effect) and will therefore destroy itself when the component unmounts (or the parent effect is destroyed).

That's very complex! In order to use $effect... effectively (sorry), developers have to understand how state changes are tracked. The documentation for component lifecycles claims:

In Svelte 5, the component lifecycle consists of only two parts: Its creation and its destruction. Everything in-between — when certain state is updated — is not related to the component as a whole; only the parts that need to react to the state change are notified. This is because under the hood the smallest unit of change is actually not a component, it’s the (render) effects that the component sets up upon component initialization. Consequently, there’s no such thing as a “before update”/"after update” hook.

But then goes on to introduce the idea of tick in conjunction with $effect.pre. This section explains that "tick returns a promise that resolves once any pending state changes have been applied, or in the next microtask if there are none."

I'm sure there's some mental model that justifies this, but I don't think the claim that a component's lifecycle is only comprised of mount/unmount is really helpful when an addendum about state changes has to come right afterward.

The place where this really bit me, and which is the motivation for this blog post, is when state gets coupled to a component's lifecycle, even when the state is passed to another function that doesn't know anything about svelte.

In my application, I manage modal dialogs by storing the component I want to render alongside its props in a store and rendering it in the layout.svelte of my application. This store is also synchronized with browser history so that the back button works to close them. Sometimes, it's useful to pass a callback to one of these modals, binding caller-specific functionality to the child component:

javascript const {value} = $props() const callback = () => console.log(value) const openModal = () => pushModal(MyModal, {callback})

This is a fundamental pattern in javascript. Passing a callback is just one of those things you do.

Unfortunately, if the above code lives in a modal dialog itself, the caller component gets unmounted before the callback gets called. In Svelte 4, this worked fine, but in Svelte 5 value gets updated to undefined when the component gets unmounted. Here's a minimal reproduction.

This is only one example, but it seems clear to me that any prop that is closed over by a callback function that lives longer than its component will be undefined when I want to use it — with no reassignment existing in lexical scope. It seems that the reason this happens is that the props "belong" to the parent component, and are accessed via getters so that the parent can revoke access when it unmounts.

I don't know why this is necessary, but I assume there's a good engineering reason for it. The problem is, this just isn't how javascript works. Svelte is essentially attempting to re-invent garbage collection around component lifecycles, which breaks the assumption every javascript developer has that variables don't simply disappear without an explicit reassignment. It should be safe to pass stuff around and let the garbage collector do its job.

Conclusion

Easy things are nice, but as Rich Hickey says, easy things are not always simple. And like Joel Spolsky, I don't like being surprised. Svelte has always been full of magic, but with the latest release I think the cognitive overhead of reciting incantations has finally outweighed the power it confers.

My point in this post is not to dunk on the Svelte team. I know lots of people like Svelte 5 (and react hooks). The point I'm trying to make is that there is a tradeoff between doing things on the user's behalf, and giving the user agency. Good software is built on understanding, not cleverness.

I also think this is an important lesson to remember as AI-assisted coding becomes increasingly popular. Don't choose tools that alienate you from your work. Choose tools that leverage the wisdom you've already accumulated, and which help you to cultivate a deeper understanding of the discipline.

Thank you to Rich Harris and team for many years of pleasant development. I hope that (if you read this) it's not so full of inaccuracies as to be unhelpful as user feedback.

@ 1c9dcd8f:1852f704

Many strange spells are effected by the means of a dead man’s hand—chiefly to produce butter in the churn. The milk is stirred round nine times with the dead hand, the operator crying aloud all the time, “Gather! gather! gather!” While a secret form of words is used which none but the initiated know.

Another use is to facilitate robberies. If a candle is placed in a dead hand, neither wind nor water can extinguish it. And if carried into a house the inmates will sleep the sleep of the dead as long as it remains under the roof, and no power on earth can wake them while the dead hand holds the candle.

---

For a mystic charm, one of the strongest known is the hand of an unbaptized infant fresh taken from the grave in the name of the Evil One.

---

A dead hand is esteemed also a certain cure for most diseases, and many a time sick people have been brought to a house where a corpse lay that the hand of the dead might be laid on them.

--

The souls of the dead who may happen to die abroad, greatly desire to rest in Ireland. And the relations deem it their duty to bring back the body to be laid in Irish earth. But even then the dead will not rest peaceably unless laid with their forefathers and their own people, and not amongst strangers.

---

A young girl happened to die of a fever while away on a visit to some friends, and her father thought it safer not to bring her home, but to have her buried in the nearest churchyard. However, a few nights after his return home, he was awakened by a mournful wail at the window, and a voice cried, “I am alone; I am alone; I am alone!” Then the poor father knew well what it meant, and he prayed in the name of God that the spirit of his dead child might rest in peace until the morning. And when the day broke he arose and set off to the strange burial ground, and there he drew the coffin from the earth, and had it carried all the way back from Cork to Mayo; and after he had laid the dead in the old graveyard beside his people and his kindred, the spirit of his child had rest, and the mournful cry was no more heard in the night.

---

The corner of a sheet that has wrapped a corpse is a cure for headache if tied round the head.

---

The ends of candles used at wakes are of great efficacy in curing burns.

---

A piece of linen wrap taken from a corpse will cure the swelling of a limb if tied round the part affected.

---

It is believed that the spirit of the dead last buried has to watch in the churchyard until another corpse is laid there; or has to perform menial offices in the spirit world, such as carrying wood and water until the next spirit comes from earth. They are also sent on messages to earth, chiefly to announce the coming death of some relative, and at this they are glad, for then their time of peace and rest will come at last.

---

If any one stumbles at a grave it is a bad omen; but if he falls and touches the clay, he will assuredly die before the year is out.

---

Any one meeting a funeral must turn back and walk at least four steps with the mourners.

---

If the nearest relative touches the hand of a corpse it will utter a wild cry if not quite dead.

---

On Twelfth Night the dead walk, and on every tile of the house a soul is sitting, waiting for your prayers to take it out of purgatory.

---

There are many strange superstitions in the western islands of Connemara. At night the dead can be heard laughing with the fairies and spinning the flax. One girl declared that she distinctly heard her dead mother’s voice singing a mournful Irish air away down in the heart of the hill. But after a year and a day the voices cease, and the dead are gone for ever.

---

It is a custom in the West, when a corpse is carried to the grave, for the bearers to stop half way, while the nearest relatives build up a small monument of loose stones, and no hand would ever dare to touch or disturb this monument while the world lasts.

---

When the grave is dug, a cross is made of two spades, and the coffin is carried round it three times before being placed in the clay. Then the prayers for the dead are said, all the people kneeling with uncovered head.

@ 6bae33c8:607272e8

I’ve written about this before. The point of this league isn’t the meager $50 entry fee and the modest prize for winning it. It’s avoiding the downside of losing the steakhouse side bet wherein you foot the bill (one year I paid $520) for a bunch of greedy gluttonous douches who stuff their faces on your dime.*

It’s a 14-team, half-PPR auction, with IDPs instead of team defenses. Here are the results:

*It’s well known I’m the greediest most gluttonous douche when I win the bet, and that is often.

My strategy was to buy three elite receivers and skimp everywhere else. It was going well until I price-enforced on Chris Olave (who I hate at his second-round ADP) and got stuck for $31. I would much rather have gone the extra mile for a $47 Amon-Ra St. Brown or spent it instead on a running back.

I thought I’d be able to get RBs cheap late too, but that wasn’t the case. After bowing out on an $18 Rhamondre Stevenson, I found myself bidding up Brian Robinson (who I like) to $16. And I wanted to pair Jerome Ford ($11) with Nick Chubb ($14), but he too got out of reach late.

Everything else went fine. I spent $4 combined on Tua Tagovailoa and Danny Dimes who in this running-QB-friendly format has more value. I also got Rashid Shaheed late because I think he’s a better player in real life than Olave and felt like I needed the insurance after that mistake.

All things considered, the draft was fine — CeeDee Lamb and Ja’Marr Chase are two top-seven overall picks, Olave is a second rounder and Stefon Diggs goes late third-early fourth, and that’s in the NFFC’s 12-team format, though unlike this, it’s full PPR.

@ 6ad3e2a3:c90b7740

From the ages of 8-11, I spent my summers in Saltaire, Fire Island, a tiny town across the bay from Bayshore Long Island, accessible only by ferry. I vaguely recall the first summer our parents enrolled my younger brother Damon and me in day camp where they made us swim in the cold, jelly-fish-ridden bay water early in the morning. We quit the camp within the week and were largely left to our own devices after that.

The island didn’t have cars, so you got around by bike. That meant it was safe for kids, and late-70s/early-80s parents could check out entirely. By the time I was 10 or 11, I would wake up whenever it suited me, scarf down a bowl of cereal, grab my bike and return for dinner. No one knew where we were — though the baseball field was a good bet — and no one cared.

I remember one time we brought a two-man inflatable raft to the ocean on a choppy day and had the bright idea to ride the waves in it. We got so destroyed by one wave, Damon wound up face-down in the sand underneath the raft. He was crying, but no real harm done.

. . .

To this day, I often find myself projecting into the future. “In 12 hours, I’ll be back in Lisbon, in 48 hours, I’ll be done with my running for the week, in 72 hours, etc.” And when the time comes, and I’m done with whatever travel or unpleasant task, I’ll start all over again.

If you tell this to someone, they’ll often say, “You need to be in the present.” Yeah no shit. That’s like telling someone you’re an alcoholic and them saying, “You should stop drinking.” It’s a bad habit, I’m aware. But where did this habit come from, and why is it so entrenched?

. . .

My summers were a stark contrast to the school year where like everyone else I was up at 7:00 am, exhausted and forced to sit through class after class all day, the teachers droning on about something in which I had no interest. I remember watching the clock, as though trying to make the hands move faster with my mind. Only 20 minutes left, only 10 minutes, only five. Thank God it’s Friday.

. . .

I’ve never had a real job. I worked on the Truckee River one summer blowing up rafts, stacking them on trucks and putting people in the water. I cleaned houses one summer, I worked for free during law school for the NY Attorney General’s office, I ghost wrote car blurbs for Motor Trend and Car And Driver and then I worked for RotoWire (in fantasy sports) for 22 years before we sold it. The idea of grinding away at a law firm or some other joyless menial mental labor filled me with dread. Even tedious tasks like editing our annual NFL magazine, going over the copy word by word four or five times was torture. And I had a dream job and owned part of the company.

. . .

I partied a lot in my 20s and 30s, and it was not without consequence. I have a beautiful 12-YO daughter now, but we started too late to have more than one kid. Had I known then what I know now, I would have started a big family much earlier. I would have been more serious and made it a priority. But even though I wasn’t exactly an alcoholic, I had a strong urge to use the weekend as an escape. It was my time, and I wanted to use it to chase the pleasures that were denied to me during the slog of the work week.

. . .

For parents, school is kid storage, but for kids like me it was prison. My biggest takeaway was there are dreadful, pointless things society wants from you, and you should get those done with the least possible effort so you could do whatever you wanted later. That life is divided into appeasing the machine and having fun, and the problem to solve was how to get rich despite having a very low tolerance for appeasement. The point of getting rich was to do whatever you wanted whenever you wanted and to dispense with the dreadful, pointless things forever.

. . .

Now that I have no job, and the dreadful, pointless things are kept to a minimum, I mostly do whatever I want. But the younger version of me would be surprised to know that includes running at the track three times a week, doing pull-ups at the local park, writing and editing my own essays, learning and using to the extent I’m capable the challenging new freedom tech protocols (bitcoin and nostr.) I’ve largely stopped drinking, almost never smoke weed, fast once a week, am gluten-free, rarely eat junk food, don’t drive a fancy car. I save rather than spend most of my money.

There is nothing from which to escape and nowhere to go anymore. And yet my mind still projects into the future, perpetuating the dichotomy between obligations and leisure, indentured servitude and escapism. It’s as if I’m back in Saltaire, the whole day every day in front of me, but it’s only June, and I haven’t yet adjusted fully to the reality that school’s out, and it’s really, actually summer.

Just as soon as I post this essay, walk the dog, do my pull-ups at the park, I’ll start to relax and enjoy myself.

@ 1c9dcd8f:1852f704

It is especially dangerous to be out late on the last night of November, for it is the closing scene of the revels—the last night when the dead have leave to dance on the hill with the fairies, and after that they must all go back to their graves and lie in the chill, cold earth, without music or wine till the next November comes round, when they all spring up again in their shrouds and rush out into the moonlight with mad laughter.

One November night, a woman of Shark Island, coming home late at the hour of the dead, grew tired and sat down to rest, when presently a young man came up and talked to her.

“Wait a bit,” he said, “and you will see the most beautiful dancing you ever looked on there by the side of the hill.”

And she looked at him steadily. He was very pale, and seemed sad.

“Why are you so sad?” she asked, “and as pale as if you were dead?”

“Look well at me,” he answered. “Do you not know me?”

“Yes, I know you now,” she said. “You are young Brien that was drowned last year when out fishing. What are you here for?”

“Look,” he said, “at the side of the hill and you will see why I am here.”

And she looked, and saw a great company dancing to sweet music; and amongst them were all the dead who had died as long as she could remember—men, women, and children, all in white, and their faces were pale as the moonlight.

“Now,” said the young man, “run for your life; for if once the fairies bring you into the dance you will never be able to leave them any more.”

But while they were talking, the fairies came up and danced round her in a circle, joining their hands. And she fell to the ground in a faint, and knew no more till she woke up in the morning in her own bed at home. And they all saw that her face was pale as the dead, and they knew that she had got the fairy-stroke. So the herb doctor was sent for, and every measure tried to save her, but without avail, for just as the moon rose that night, soft, low music was heard round the house, and when they looked at the woman she was dead.

It is a custom amongst the people, when throwing away water at night, to cry out in a loud voice, “Take care of the water;” or, literally from the Irish, “Away with yourself from the water”—for they say the spirits of the dead last buried are then wandering about, and it would be dangerous if the water fell on them.

One dark winter’s night a woman suddenly threw out a pail of boiling water without thinking of the warning words. Instantly a cry was heard as of a person in pain, but no one was seen. However, the next night a black lamb entered the house, having the back all fresh scalded, and it lay down moaning by the hearth and died. Then they all knew this was the spirit that had been scalded by the woman. And they carried the dead lamb out reverently and buried it deep in the earth. Yet every night at the same hour it walked again into the house and lay down and moaned and died. And after this had happened many times, the priest was sent for, and finally, by the strength of his exorcism, the spirit of the dead was laid to rest, and the black lamb appeared no more. Neither was the body of the dead lamb found in the grave when they searched for it, though it had been laid by their own hands deep in the earth and covered with the clay.

Before an accident happens to a boat, or a death by drowning, low music is often heard, as if under the water, along with harmonious lamentations, and then every one in the boat knows that some young man or beautiful young girl is wanted by the fairies, and is doomed to die. The best safeguard is to have music and singing in the boat, for the fairies are so enamoured of the mortal voices and music that they forget to weave the spell till the fatal moment has passed, and then all in the boat are safe from harm.

@ 6d5c826a:4b27b659

• GNS3 - Graphical network simulator that provides a variety of virtual appliances. (Source Code) GPL-3.0 Python
• OpenWISP - Open Source Network Management System for OpenWRT based routers and access points. (Demo, Source Code) GPL-3.0 Python
• Oxidized - Network device configuration backup tool. Apache-2.0 Ruby
• phpIPAM - Open source IP address management with PowerDNS integration. (Source Code) GPL-3.0 PHP
• RANCID - Monitor network devices configuration and maintain history of changes. (Source Code) BSD-3-Clause Perl/Shell
• rConfig - Network device configuration management tool. (Source Code) GPL-3.0 PHP

@ 6d5c826a:4b27b659

• Adagios - Web based Nagios interface for configuration and monitoring (replacement to the standard interface), and a REST interface. (Source Code) AGPL-3.0 Docker/Python
• Alerta - Distributed, scalable and flexible monitoring system. (Source Code) Apache-2.0 Python
• Beszel - Lightweight server monitoring platform that includes Docker statistics, historical data, and alert functions. (Source Code) MIT Go
• Cacti - Web-based network monitoring and graphing tool. (Source Code) GPL-2.0 PHP
• cadvisor - Analyzes resource usage and performance characteristics of running containers. Apache-2.0 Go
• checkmk - Comprehensive solution for monitoring of applications, servers, and networks. (Source Code) GPL-2.0 Python/PHP
• dashdot - A simple, modern server dashboard for smaller private servers. (Demo) MIT Nodejs/Docker
• EdMon - A command-line monitoring application helping you to check that your hosts and services are available, with notifications support. MIT Java
• eZ Server Monitor - A lightweight and simple dashboard monitor for Linux, available in Web and Bash application. (Source Code) GPL-3.0 PHP/Shell
• glances - Open-source, cross-platform real-time monitoring tool with CLI and web dashboard interfaces and many exporting options. (Source Code) GPL-3.0 Python
• Healthchecks - Monitoring for cron jobs, background services and scheduled tasks. (Source Code) BSD-3-Clause Python
• Icinga - Nagios fork that has since lapped nagios several times. Comes with the possibility of clustered monitoring. (Source Code) GPL-2.0 C++
• LibreNMS - Fully featured network monitoring system that provides a wealth of features and device support. (Source Code) GPL-3.0 PHP
• Linux Dash - A low-overhead monitoring web dashboard for a GNU/Linux machine. MIT Nodejs/Go/Python/PHP
• Monit - Small utility for managing and monitoring Unix systems. (Source Code) AGPL-3.0 C
• Munin - Networked resource monitoring tool. (Source Code) GPL-2.0 Perl/Shell
• Naemon - Network monitoring tool based on the Nagios 4 core with performance enhancements and new features. (Source Code) GPL-2.0 C
• Nagios - Computer system, network and infrastructure monitoring software application. (Source Code) GPL-2.0 C
• Netdata - Distributed, real-time, performance and health monitoring for systems and applications. Runs on Linux, FreeBSD, and MacOS. (Source Code) GPL-3.0 C
• NetXMS - Open Source network and infrastructure monitoring and management. (Source Code) LGPL-3.0/GPL-3.0 Java/C++/C
• Observium Community Edition - Network monitoring and management platform that provides real-time insight into network health and performance. QPL-1.0 PHP
• openITCOCKPIT Community Edition - Monitoring Suite featuring seamless integrations with Naemon, Checkmk, Grafana and more. (Demo, Source Code) GPL-3.0 deb/Docker
• Performance Co-Pilot - Lightweight, distributed system performance and analysis framework. (Source Code) LGPL-2.1/GPL-2.0 C
• PHP Server Monitor - Open source tool to monitor your servers and websites. (Source Code) GPL-3.0 PHP
• PhpSysInfo - A customizable PHP script that displays information about your system nicely. (Source Code) GPL-2.0 PHP
• Prometheus - Service monitoring system and time series database. (Source Code) Apache-2.0 Go
• Riemann - Flexible and fast events processor allowing complex events/metrics analysis. (Source Code) EPL-1.0 Java
• rtop - Interactive, remote system monitoring tool based on SSH. MIT Go
• ruptime - Classic system status server. AGPL-3.0 Shell
• Scrutiny - Web UI for hard drive S.M.A.R.T monitoring, historical trends & real-world failure thresholds. MIT Go
• Sensu - Monitoring tool for ephemeral infrastructure and distributed applications. (Source Code) MIT Go
• Status - Simple and lightweight system monitoring tool for small homeservers with a pleasant web interface. (Demo MIT Python
• Thruk - Multibackend monitoring web interface with support for Naemon, Nagios, Icinga and Shinken. (Source Code) GPL-1.0 Perl
• Wazuh - Unified XDR and SIEM protection for endpoints and cloud workloads. (Source Code) GPL-2.0 C
• Zabbix - Enterprise-class software for monitoring of networks and applications. (Source Code) GPL-2.0 C

@ 97c70a44:ad98e322

Everyone knows that relays are central to how nostr works - they're even in the name: Notes and Other Stuff Transmitted by Relays. As time goes on though, there are three other letters which are becoming conspicuously absent from our beloved and ambiguously pronounceable acronym - "D", "V", and "M".

For the uninitiated, DVM stands for "data vending machines". They're actually sort of hard to describe — in technical terms they act more like clients, since they simply read events from and publish events to relays. In most cases though, these events are part of a request/response flow initiated by users elsewhere on the network. In practice, DVMs are bots, but there's also nothing to prevent the work they do from being powered by human interaction. They're an amazingly flexible tool for building anything from custom feeds, to transcription services, to chatbots, to protocol gateways.

The hype cycle for DVMs seems to have reached escape velocity in a way few other things have - zaps being the possible exception. But what exactly DVMs are remains something of a mystery to many nostr developers - and how to build one may as well be written on clay tablets.

This blog post is designed to address that - below is a soup to nuts (no nutzaps though) guide to building a DVM flow, both from the client and the server side.

Here's what we'll be covering:

• Discovering DVM metadata
• Basic request/response flow
• Implementing a minimal example

Let's get started!

DVM Metadata

First of all, it's helpful to know how DVMs are reified on the nostr network. While not strictly necessary, this can be useful for discovering DVMs and presenting them to users, and for targeting specific DVMs we want a response from.

NIP 89 goes into this in more detail, but the basic idea is that anyone can create a kind 31990 "application handler" event and publish it to the network with their own (or a dedicated) public key. This handler was originally intended to advertise clients, but has been re-purposed for DVM listings as well.

Here's what the "Fluffy Frens" handler looks like:

json { "content": "{\"name\": \"Fluffy Frens\", \"picture\": \"https://image.nostr.build/f609311532c470f663e129510a76c9a1912ae9bc4aaaf058e5ba21cfb512c88e.jpg\", \"about\": \"I show recent notes about animals\", \"lud16\": \"discovery_content_fluffy@nostrdvm.com\", \"supportsEncryption\": true, \"acceptsNutZaps\": false, \"personalized\": false, \"amount\": \"free\", \"nip90Params\": {\"max_results\": {\"required\": false, \"values\": [], \"description\": \"The number of maximum results to return (default currently 100)\"}}}", "created_at": 1738874694, "id": "0aa8d1f19cfe17e00ce55ca86fea487c83be39a1813601f56f869abdfa776b3c", "kind": 31990, "pubkey": "7b7373dd58554ff4c0d28b401b9eae114bd92e30d872ae843b9a217375d66f9d", "sig": "22403a7996147da607cf215994ab3b893176e5302a44a245e9c0d91214e4c56fae40d2239dce58ea724114591e8f95caed2ba1a231d09a6cd06c9f0980e1abd5", "tags": [ ["k", "5300"], ["d", "198650843898570c"] ] }

This event is rendered in various clients using the kind-0-style metadata contained in the content field, allowing users to browse DVMs and pick one for their use case. If a user likes using a particular DVM, they might publish a kind 31989 "application recommendation", which other users can use to find DVMs that are in use within their network.

Note the k tag in the handler event - this allows DVMs to advertise support only for specific job types. It's also important to note that even though the spec doesn't cover relay selection, most clients use the publisher's kind 10002 event to find out where the DVM listens for events.

If this looks messy to you, you're right. See this PR for a proposal to split DVMs out into their own handler kind, give them a dedicated pubkey along with dedicated metadata and relay selections, and clean up the data model a bit.

DVM Flow

Now that we know what a DVM looks like, we can start to address how they work. My explanation below will elide some of the detail involved in NIP 90 for simplicity, so I encourage you to read the complete spec.

The basic DVM flow can be a little (very) confusing to work with, because in essence it's a request/response paradigm, but it has some additional wrinkles.

First of all, the broker for the request isn't abstracted away as is usually the case with request/response flows. Regular HTTP requests involve all kinds of work in the background - from resolving domain names to traversing routers, VPNs, and ISP infrastructure. But developers don't generally have to care about all these intermediaries.

With DVMs, on the other hand, the essential complexity of relay selection can't simply be ignored. DVMs often advertise their own relay selections, which should be used rather than a hard-coded or randomly chosen relay to ensure messages are delivered. The benefit of this is that DVMs can avoid censorship, just as users can, by choosing relays that are willing to broker their activity. DVMs can even select multiple relays to broker requests, which means that clients might receive multiple copies of the same response.

Secondly, the DVM request/response model is far more fluid than is usually the case with request/response flows. There are a set of standard practices, but the flow is flexible enough to admit exceptions to these conventions for special use cases. Here are some examples:

• Normally, clients p-tag the DVM they wish to address. But if a client isn't picky about where a response comes from, they may choose to send an open request to the network and collect responses from multiple DVMs simultaneously.
• Normally, a client creates a request before collecting responses using a subscription with an e-tag filter matching the request event. But clients may choose to skip the request step entirely and collect responses from the network that have already been created. This can be useful for computationally intensive tasks or common queries, where a single result can be re-used multiple times.
• Sometimes, a DVM may respond with a kind 7000 job status event to let clients know they're working on the request. This is particularly useful for longer-running tasks, where feedback is useful for building a responsive UX.
• There are also some details in the spec regarding monetization, parameterization, error codes, encryption, etc.

Example DVM implementation

For the purposes of this blog post, I'll keep things simple by illustrating the most common kind of DVM flow: a kind 5300 content discovery request, addressed to a particular DVM. If you're interested in other use cases, please visit data-vending-machines.org for additional documented kinds.

The basic flow looks like this:

• The DVM starts by listening for kind 5300 job requests on some relays it has selected and advertised via NIP 89 (more on that later)
• A client creates a request event of kind 5300, p-tagged with the DVM's pubkey and sends it to the DVM's relay selections.
• The DVM receives the event and processes it, issuing optional kind 7000 job status events, and eventually issuing a kind 6300 job result event (job result event kinds are always 1000 greater than the request's kind).
• The client listens to the same relays for a response, and when it comes through does whatever it wants to with it.

Here's a swimlane diagram of that flow:

To avoid massive code samples, I'm going to implement our DVM entirely using nak (backed by the power of the human mind).

The first step is to start our DVM listening for requests that it wants to respond to. Nak's default pubkey is 79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798, so we'll only listen for requests sent to nak.

bash nak req -k 5300 -t p=79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798

This gives us the following filter:

json ["REQ","nak",{"kinds":[5300],"#p":["79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798"]}]

To open a subscription to nos.lol and stream job requests, add --stream wss://nos.lol to the previous request and leave it running.

Next, open a new terminal window for our "client" and create a job request. In this case, there's nothing we need to provide as input, but we'll include it just for illustration. It's also good practice to include an expiration tag so we're not asking relays to keep our ephemeral requests forever.

bash nak event -k 5300 -t p=79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 -t expiration=$(( $(date +%s) + 30 )) -t input=hello

Here's what comes out:

json { "kind": 5300, "id": "0e419d0b3c5d29f86d2132a38ca29cdfb81a246e1a649cb2fe1b9ed6144ebe30", "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798", "created_at": 1739407684, "tags": [ ["p", "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798"], ["expiration", "1739407683"], ["input", "hello"] ], "content": "", "sig": "560807548a75779a7a68c0ea73c6f097583e2807f4bb286c39931e99a4e377c0a64af664fa90f43e01ddd1de2e9405acd4e268f1bf3bc66f0ed5a866ea093966" }

Now go ahead and publish this event by adding nos.lol to the end of your nak command. If all goes well, you should see your event pop up in your "dvm" subscription. If so, great! That's half of the flow.

Next, we'll want our client to start listening for kind 6300 responses to the request. In your "client" terminal window, run:

bash nak req -k 6300 -t e=<your-eventid-here> --stream nos.lol

Note that if you only want to accept responses from the specified DVM (a good policy in general to avoid spam) you would include a p tag here. I've omitted it for brevity. Also notice the k tag specifies the request kind plus 1000 - this is just a convention for what kinds requests and responses use.

Now, according to data-vending-machines.org, kind 5300 responses are supposed to put a JSON-encoded list of e-tags in the content field of the response. Weird, but ok. Stop the subscription in your "dvm" terminal and respond to your "client" with a recommendation to read my first note:

bash nak event -k 6300 -t e=a65665a3a4ca2c0d7b7582f4f0d073cd1c83741c25a07e98d49a43e46d258caf -c '[["e","214f5898a7b75b7f95d9e990b706758ea525fe86db54c1a28a0f418c357f9b08","wss://nos.lol/"]]' nos.lol

Here's the response event we're sending:

json { "kind": 6300, "id": "bb5f38920cbca15d3c79021f7d0051e82337254a84c56e0f4182578e4025232e", "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798", "created_at": 1739408411, "tags": [ ["e", "a65665a3a4ca2c0d7b7582f4f0d073cd1c83741c25a07e98d49a43e46d258caf"] ], "content": "[[\"e\",\"214f5898a7b75b7f95d9e990b706758ea525fe86db54c1a28a0f418c357f9b08\",\"wss://nos.lol/\"]]", "sig": "a0fe2c3419c5c54cf2a6d9a2a5726b2a5b766d3c9e55d55568140979354003aacb038e90bdead43becf5956faa54e3b60ff18c0ea4d8e7dfdf0c8dd97fb24ff9" }

Notice the e tag targets our original request.

This should result in the job result event showing up in our "client" terminal. Success!

If something isn't working, I've also create a video of the full process with some commentary which you can find here.

Note that in practice, DVMs can be much more picky about the requests they will respond to, due to implementations failing to follow Postel's law. Hopefully that will improve over time. For now, here are a few resources that are useful when working with or developing DVMs:

• dvmdash
• data-vending-machines.org
• noogle
• nostrdvm

Conclusion

I started this post by hinting that DVMs might be as fundamental as relays are to making nostr work. But (apart from the fact that we'd end up with an acronym like DVMNOSTRZ+*, which would only exascerbate the pronounciation wars (if such a thing were possible)), that's not exactly true.

DVMs have emerged as a central paradigm in the nostr world because they're a generalization of a design pattern unique to nostr's architecture - but which exists in many other places, including NIP 46 signer flows and NIP 47 wallet connect. Each of these sub-protocols works by using relays as neutral brokers for requests in order to avoid coupling services to web addresses.

This approach has all kinds of neat benefits, not least of which is allowing service providers to host their software without having to accept incoming TCP connections. But it's really an emergent property of relays, which not only are useful for brokering communication between users (aka storing events), but also brokering communication between machines.

The possibilities of this architecture have only started to emerge, so be on the lookout for new applications, and don't be afraid to experiment - just please, don't serialize json inside json 🤦‍♂️

@ c0a57a12:8b230f7a

Concept:

This sauce is intended to be used on 10-16 lb smoked pork butt (Boston Butt). #foodstr

Ingredients:

• 1 Pineapple (cored, peeled)
• 2 cup coconut water
• 1/3 cup Red Wine Vinegar
• 6 Scotch Bonnet Peppers or 3 TBSP Eaton's Scotch Bonnet Pepper Sauce
• 4 tbsp minced garlic
• 4 tbsp minced onion
• 4 tbsp ground allspice
• 2 tbsp ground cinnamon
• 1 tbsp ground clove
• 1 tbsp ground nutmeg
• 1 tbsp dried thyme
• 2 tsp paprika
• 2 tsp ground ginger
• 1 tbsp salt

Instructions:

1. Core pineapple
2. Place all ingredients in blender. Blend well.
3. Pour purée into medium saucepan
4. Reduce to thicken.
5. Allow sauce to cool.

@ 6d5c826a:4b27b659

• Chocolatey - The package manager for Windows. (Source Code) Apache-2.0 C#/PowerShell
• Clonezilla - Partition and disk imaging/cloning program. (Source Code) GPL-2.0 Perl/Shell/Other
• DadaMail - Mailing List Manager, written in Perl. (Source Code) GPL-2.0 Perl
• Fog - Cloning/imaging solution/rescue suite. (Source Code) GPL-3.0 PHP/Shell
• phpList - Newsletter and email marketing software. (Source Code) AGPL-3.0 PHP

@ 97c70a44:ad98e322

Last week, in a bid to understand the LLM hype, I decided to write a trivial nostr-related program in rust via a combination of codebuff (yes, that is a referral link, pls click), aider, and goose.

The result of the experiment was inconclusive, but as a side effect it produced a great case study in converting a NINO into a Real Nostr App.

Introducing Roz

Roz, a friendly notary for nostr events.

To use it, simply publish an event to relay.damus.io or nos.lol, and roz will make note of it. To find out when roz first saw a given event, just ask:

curl https://roz.coracle.social/notary/cb429632ae22557d677a11149b2d0ccd72a1cf66ac55da30e3534ed1a492765d

This will return a JSON payload with a seen key indicating when roz first saw the event. How (and whether) you use this is up to you!

De-NINO-fying roz

Roz is just a proof of concept, so don't rely on it being there forever. And anyway, roz is a NINO, since it provides value to nostr (potentially), but doesn't really do things in a nostr-native way. It also hard-codes its relays, and certainly doesn't use the outbox model or sign events. But that's ok, it's a proof of concept.

A much better way to do this would be to modify roz to properly leverage nostr's capabilities, namely:

• Use nostr-native data formats (i.e., draft a new kind)
• Use relays instead of proprietary servers for data storage
• Leverage nostr identities and signatures to decouple trust from storage, and allow trusted attestations to be discovered

Luckily, this is not hard at all. In fact, I've gone ahead and drafted a PR to the NIPs repo that adds timestamp annotations to NIP 03, as an alternative to OpenTimestamps. The trade-off is that while user attestations are far less reliable than OTS proofs, they're much easier to verify, and can reach a pretty high level of reliability by combining multiple attestation sources with other forms of reputation.

In other words, instead of going nuclear and embedding your attestations into The Time Chain, you can simply ask 5-10 relays or people you trust for their attestations for a given event.

This PR isn't terribly important on its own, but it does remove one small barrier between us and trusted key rotation events (or other types of event that require establishing a verifiable chain of causality).

@ e968e50b:db2a803a

...a 25W light bulb. Sorry. But is anybody working on this (using mining heat and a lower watt LED bulb)? I know that GekkoScience is working on a coffee warmer right now.

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

@ 6d5c826a:4b27b659

• Beats - Single-purpose data shippers that send data from hundreds or thousands of machines and systems to Logstash or Elasticsearch. (Source Code) Apache-2.0 Go
• Collectd - System statistics collection daemon. (Source Code) MIT C
• Diamond - Daemon that collects system metrics and publishes them to Graphite (and others). MIT Python
• Grafana - A Graphite & InfluxDB Dashboard and Graph Editor. (Source Code) AGPL-3.0 Go
• Graphite - Scalable graphing server. (Source Code) Apache-2.0 Python
• RRDtool - Industry standard, high performance data logging and graphing system for time series data. (Source Code) GPL-2.0 C
• Statsd - Daemon that listens for statistics like counters and timers, sent over UDP or TCP, and sends aggregates to one or more pluggable backend services. MIT Nodejs
• tcollector - Gathers data from local collectors and pushes the data to OpenTSDB. (Source Code) LGPL-3.0/GPL-3.0 Python
• Telegraf - Plugin-driven server agent for collecting, processing, aggregating, and writing metrics. MIT Go

@ 57d1a264:69f1fee1

Zap this meme for today (Special Edition) Meme Monday contest

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

@ 97c70a44:ad98e322

There was a slight dust up recently over a website someone runs removing a listing for an app someone built based on entirely arbitrary criteria. I'm not to going to attempt to speak for either wounded party, but I would like to share my own personal definition for what constitutes a "nostr app" in an effort to help clarify what might be an otherwise confusing and opaque purity test.

In this post, I will be committing the "no true Scotsman" fallacy, in which I start with the most liberal definition I can come up with, and gradually refine it until all that is left is the purest, gleamingest, most imaginary and unattainable nostr app imaginable. As I write this, I wonder if anything built yet will actually qualify. In any case, here we go.

It uses nostr

The lowest bar for what a "nostr app" might be is an app ("application" - i.e. software, not necessarily a native app of any kind) that has some nostr-specific code in it, but which doesn't take any advantage of what makes nostr distinctive as a protocol.

Examples might include a scraper of some kind which fulfills its charter by fetching data from relays (regardless of whether it validates or retains signatures). Another might be a regular web 2.0 app which provides an option to "log in with nostr" by requesting and storing the user's public key.

In either case, the fact that nostr is involved is entirely neutral. A scraper can scrape html, pdfs, jsonl, whatever data source - nostr relays are just another target. Likewise, a user's key in this scenario is treated merely as an opaque identifier, with no appreciation for the super powers it brings along.

In most cases, this kind of app only exists as a marketing ploy, or less cynically, because it wants to get in on the hype of being a "nostr app", without the developer quite understanding what that means, or having the budget to execute properly on the claim.

It leverages nostr

Some of you might be wondering, "isn't 'leverage' a synonym for 'use'?" And you would be right, but for one connotative difference. It's possible to "use" something improperly, but by definition leverage gives you a mechanical advantage that you wouldn't otherwise have. This is the second category of "nostr app".

This kind of app gets some benefit out of the nostr protocol and network, but in an entirely selfish fashion. The intention of this kind of app is not to augment the nostr network, but to augment its own UX by borrowing some nifty thing from the protocol without really contributing anything back.

Some examples might include:

• Using nostr signers to encrypt or sign data, and then store that data on a proprietary server.
• Using nostr relays as a kind of low-code backend, but using proprietary event payloads.
• Using nostr event kinds to represent data (why), but not leveraging the trustlessness that buys you.

An application in this category might even communicate to its users via nostr DMs - but this doesn't make it a "nostr app" any more than a website that emails you hot deals on herbal supplements is an "email app". These apps are purely parasitic on the nostr ecosystem.

In the long-term, that's not necessarily a bad thing. Email's ubiquity is self-reinforcing. But in the short term, this kind of "nostr app" can actually do damage to nostr's reputation by over-promising and under-delivering.

It complements nostr

Next up, we have apps that get some benefit out of nostr as above, but give back by providing a unique value proposition to nostr users as nostr users. This is a bit of a fine distinction, but for me this category is for apps which focus on solving problems that nostr isn't good at solving, leaving the nostr integration in a secondary or supporting role.

One example of this kind of app was Mutiny (RIP), which not only allowed users to sign in with nostr, but also pulled those users' social graphs so that users could send money to people they knew and trusted. Mutiny was doing a great job of leveraging nostr, as well as providing value to users with nostr identities - but it was still primarily a bitcoin wallet, not a "nostr app" in the purest sense.

Other examples are things like Nostr Nests and Zap.stream, whose core value proposition is streaming video or audio content. Both make great use of nostr identities, data formats, and relays, but they're primarily streaming apps. A good litmus test for things like this is: if you got rid of nostr, would it be the same product (even if inferior in certain ways)?

A similar category is infrastructure providers that benefit nostr by their existence (and may in fact be targeted explicitly at nostr users), but do things in a centralized, old-web way; for example: media hosts, DNS registrars, hosting providers, and CDNs.

To be clear here, I'm not casting aspersions (I don't even know what those are, or where to buy them). All the apps mentioned above use nostr to great effect, and are a real benefit to nostr users. But they are not True Scotsmen.

It embodies nostr

Ok, here we go. This is the crème de la crème, the top du top, the meilleur du meilleur, the bee's knees. The purest, holiest, most chaste category of nostr app out there. The apps which are, indeed, nostr indigitate.

This category of nostr app (see, no quotes this time) can be defined by the converse of the previous category. If nostr was removed from this type of application, would it be impossible to create the same product?

To tease this apart a bit, apps that leverage the technical aspects of nostr are dependent on nostr the protocol, while apps that benefit nostr exclusively via network effect are integrated into nostr the network. An app that does both things is working in symbiosis with nostr as a whole.

An app that embraces both nostr's protocol and its network becomes an organic extension of every other nostr app out there, multiplying both its competitive moat and its contribution to the ecosystem:

• In contrast to apps that only borrow from nostr on the technical level but continue to operate in their own silos, an application integrated into the nostr network comes pre-packaged with existing users, and is able to provide more value to those users because of other nostr products. On nostr, it's a good thing to advertise your competitors.
• In contrast to apps that only market themselves to nostr users without building out a deep integration on the protocol level, a deeply integrated app becomes an asset to every other nostr app by becoming an organic extension of them through interoperability. This results in increased traffic to the app as other developers and users refer people to it instead of solving their problem on their own. This is the "micro-apps" utopia we've all been waiting for.

Credible exit doesn't matter if there aren't alternative services. Interoperability is pointless if other applications don't offer something your app doesn't. Marketing to nostr users doesn't matter if you don't augment their agency as nostr users.

If I had to choose a single NIP that represents the mindset behind this kind of app, it would be NIP 89 A.K.A. "Recommended Application Handlers", which states:

Nostr's discoverability and transparent event interaction is one of its most interesting/novel mechanics. This NIP provides a simple way for clients to discover applications that handle events of a specific kind to ensure smooth cross-client and cross-kind interactions.

These handlers are the glue that holds nostr apps together. A single event, signed by the developer of an application (or by the application's own account) tells anyone who wants to know 1. what event kinds the app supports, 2. how to link to the app (if it's a client), and (if the pubkey also publishes a kind 10002), 3. which relays the app prefers.

As a sidenote, NIP 89 is currently focused more on clients, leaving DVMs, relays, signers, etc somewhat out in the cold. Updating 89 to include tailored listings for each kind of supporting app would be a huge improvement to the protocol. This, plus a good front end for navigating these listings (sorry nostrapp.link, close but no cigar) would obviate the evil centralized websites that curate apps based on arbitrary criteria.

Examples of this kind of app obviously include many kind 1 clients, as well as clients that attempt to bring the benefits of the nostr protocol and network to new use cases - whether long form content, video, image posts, music, emojis, recipes, project management, or any other "content type".

To drill down into one example, let's think for a moment about forms. What's so great about a forms app that is built on nostr? Well,

• There is a spec for forms and responses, which means that...
• Multiple clients can implement the same data format, allowing for credible exit and user choice, even of...
• Other products not focused on forms, which can still view, respond to, or embed forms, and which can send their users via NIP 89 to a client that does...
• Cryptographically sign forms and responses, which means they are self-authenticating and can be sent to...
• Multiple relays, which reduces the amount of trust necessary to be confident results haven't been deliberately "lost".

Show me a forms product that does all of those things, and isn't built on nostr. You can't, because it doesn't exist. Meanwhile, there are plenty of image hosts with APIs, streaming services, and bitcoin wallets which have basically the same levels of censorship resistance, interoperability, and network effect as if they weren't built on nostr.

It supports nostr

Notice I haven't said anything about whether relays, signers, blossom servers, software libraries, DVMs, and the accumulated addenda of the nostr ecosystem are nostr apps. Well, they are (usually).

This is the category of nostr app that gets none of the credit for doing all of the work. There's no question that they qualify as beautiful nostrcorns, because their value propositions are entirely meaningless outside of the context of nostr. Who needs a signer if you don't have a cryptographic identity you need to protect? DVMs are literally impossible to use without relays. How are you going to find the blossom server that will serve a given hash if you don't know which servers the publishing user has selected to store their content?

In addition to being entirely contextualized by nostr architecture, this type of nostr app is valuable because it does things "the nostr way". By that I mean that they don't simply try to replicate existing internet functionality into a nostr context; instead, they create entirely new ways of putting the basic building blocks of the internet back together.

A great example of this is how Nostr Connect, Nostr Wallet Connect, and DVMs all use relays as brokers, which allows service providers to avoid having to accept incoming network connections. This opens up really interesting possibilities all on its own.

So while I might hesitate to call many of these things "apps", they are certainly "nostr".

Appendix: it smells like a NINO

So, let's say you've created an app, but when you show it to people they politely smile, nod, and call it a NINO (Nostr In Name Only). What's a hacker to do? Well, here's your handy-dandy guide on how to wash that NINO stench off and Become a Nostr.

You app might be a NINO if:

• There's no NIP for your data format (or you're abusing NIP 78, 32, etc by inventing a sub-protocol inside an existing event kind)
• There's a NIP, but no one knows about it because it's in a text file on your hard drive (or buried in your project's repository)
• Your NIP imposes an incompatible/centralized/legacy web paradigm onto nostr
• Your NIP relies on trusted third (or first) parties
• There's only one implementation of your NIP (yours)
• Your core value proposition doesn't depend on relays, events, or nostr identities
• One or more relay urls are hard-coded into the source code
• Your app depends on a specific relay implementation to work (ahem, relay29)
• You don't validate event signatures
• You don't publish events to relays you don't control
• You don't read events from relays you don't control
• You use legacy web services to solve problems, rather than nostr-native solutions
• You use nostr-native solutions, but you've hardcoded their pubkeys or URLs into your app
• You don't use NIP 89 to discover clients and services
• You haven't published a NIP 89 listing for your app
• You don't leverage your users' web of trust for filtering out spam
• You don't respect your users' mute lists
• You try to "own" your users' data

Now let me just re-iterate - it's ok to be a NINO. We need NINOs, because nostr can't (and shouldn't) tackle every problem. You just need to decide whether your app, as a NINO, is actually contributing to the nostr ecosystem, or whether you're just using buzzwords to whitewash a legacy web software product.

If you're in the former camp, great! If you're in the latter, what are you waiting for? Only you can fix your NINO problem. And there are lots of ways to do this, depending on your own unique situation:

• Drop nostr support if it's not doing anyone any good. If you want to build a normal company and make some money, that's perfectly fine.
• Build out your nostr integration - start taking advantage of webs of trust, self-authenticating data, event handlers, etc.
• Work around the problem. Think you need a special relay feature for your app to work? Guess again. Consider encryption, AUTH, DVMs, or better data formats.
• Think your idea is a good one? Talk to other devs or open a PR to the nips repo. No one can adopt your NIP if they don't know about it.
• Keep going. It can sometimes be hard to distinguish a research project from a NINO. New ideas have to be built out before they can be fully appreciated.
• Listen to advice. Nostr developers are friendly and happy to help. If you're not sure why you're getting traction, ask!

I sincerely hope this article is useful for all of you out there in NINO land. Maybe this made you feel better about not passing the totally optional nostr app purity test. Or maybe it gave you some actionable next steps towards making a great NINON (Nostr In Not Only Name) app. In either case, GM and PV.

@ 57d1a264:69f1fee1

Zap this meme for today (Special Edition) Meme Monday contest

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

@ 6d5c826a:4b27b659

• aerc - Terminal MUA with a focus on plaintext and features for developers. (Source Code) MIT Go
• Claws Mail - Old school email client (and news reader), based on GTK+. (Source Code) GPL-3.0 C
• ImapSync - Simple IMAP migration tool for copying mailboxes to other servers. (Source Code) NLPL Perl
• Mutt - Small but very powerful text-based mail client. (Source Code) GPL-2.0 C
• Sylpheed - Still developed predecessor to Claws Mail, lightweight mail client. (Source Code) GPL-2.0 C
• Thunderbird - Free email application that's easy to set up and customize. (Source Code) MPL-2.0 C/C++

@ 6d5c826a:4b27b659

• Fluentd - Data collector for unified logging layer. (Source Code) Apache-2.0 Ruby
• Flume - Distributed, reliable, and available service for efficiently collecting, aggregating, and moving large amounts of log data. (Source Code) Apache-2.0 Java
• GoAccess - Real-time web log analyzer and interactive viewer that runs in a terminal or through the browser. (Source Code) MIT C
• Loki - Log aggregation system designed to store and query logs from all your applications and infrastructure. (Source Code) AGPL-3.0 Go
• rsyslog - Rocket-fast system for log processing. (Source Code) GPL-3.0 C

@ 8cb60e21:5f2deaea

```js import NextAuth from "next-auth"; import CredentialsProvider from "next-auth/providers/credentials"; import NDK from "@nostr-dev-kit/ndk"; import axios from "axios"; import { findKind0Fields } from "@/utils/nostr";

const relayUrls = [ "wss://nos.lol/", "wss://relay.damus.io/", "wss://relay.snort.social/", "wss://relay.nostr.band/", "wss://nostr.mutinywallet.com/", "wss://relay.mutinywallet.com/", "wss://relay.primal.net/" ];

const BASE_URL = process.env.BASE_URL;

const ndk = new NDK({ explicitRelayUrls: relayUrls, });

export default NextAuth({ providers: [ CredentialsProvider({ id: "nostr", name: "Nostr", credentials: { pubkey: { label: "Public Key", type: "text" }, }, authorize: async (credentials) => { if (credentials?.pubkey) { await ndk.connect();

                const user = ndk.getUser({ pubkey: credentials.pubkey });

                try {
                    const profile = await user.fetchProfile();

                    // Check if user exists, create if not
                    const response = await axios.get(`${BASE_URL}/api/users/${credentials.pubkey}`);
                    if (response.status === 200 && response.data) {
                        const fields = await findKind0Fields(profile);

                        // Combine user object with kind0Fields, giving priority to kind0Fields
                        const combinedUser = { ...response.data, ...fields };

                        // Update the user on the backend if necessary
                        // await axios.put(`${BASE_URL}/api/users/${combinedUser.id}`, combinedUser);

                        return combinedUser;
                    } else if (response.status === 204) {
                        // Create user
                        if (profile) {
                            const fields = await findKind0Fields(profile);
                            console.log('FEEEEELDS', fields);
                            const payload = { pubkey: credentials.pubkey, ...fields };

                            const createUserResponse = await axios.post(`${BASE_URL}/api/users`, payload);
                            return createUserResponse.data;
                        }
                    }
                } catch (error) {
                    console.error("Nostr login error:", error);
                }
            }
            return null;
        },
    }),
],
callbacks: {
    async jwt({ token, user }) {
        // Add combined user object to the token
        if (user) {
            token.user = user;
        }
        return token;
    },
    async session({ session, token }) {
        // Add user from token to session
        session.user = token.user;
        session.jwt = token;
        return session;
    },
    async redirect({ url, baseUrl }) {
        return baseUrl;
    },
},
secret: process.env.NEXTAUTH_SECRET,
session: { strategy: "jwt" },
jwt: {
    signingKey: process.env.JWT_SECRET,
},
pages: {
    signIn: "/auth/signin",
},

}); ```

@ 434f9799:2d548c15

如果你在乎你网上的内容, 请为它们附上版权声明. 如果你在共享你的内容, 请表明你的意图. 否则不要抱怨别人为何不按你的意愿使用, 因为你从没有表明过它.

同样身为创作者, 但还没有能自诩 "艺术家" 的程度, 从自己生产内容然后公开的开始就是希望被別人看到自己的作品, 并且要让别人知道「这是我创造的东西」, 然后才会有原创, 抄袭和借鉴的争论. 我是从最开始也是从 UGC 平台上逐渐转移到拥有自己 "平台" (从博客开始) 的人, 当时只为了追求所谓「自由」, 自己想写什么就写什么, 这是我的博客凭什么你来指指点点? 然后逐渐意识到当自己的身份从创作者用户过渡到创作者平台, 必须要考虑的事情就会变多, 这也是权利和义务的无条件对等结果, 我自己一个人就要成为平台. 到这时, 能对我指指点点人只会变得更多, 体量只会更大, 范围也会扩大到全世界, 因为这是互联网. 那么生活在在 UGC 平台的人难道就没有这个烦恼吗? 不是的, 只不过是平台已经帮我做了决定, 因为我必须同意他们的使用政策和隐私协议我才能使用, 包括其中顺带同意的版权声明.

作为小到自己都不想称之为一个 "平台" 的独立博客, 也要用自己身为平台应该要做的事情, 我的博客用户是谁? 是所有能够访问到我的博客的人, 机器人甚至伪装为人的机器人.

---

所以我需要:

• 如果我用了 Google Analytics 而我如果要面向的用户当地存在个人数据法, 那就要加上一个 cookie 知情确认通知.

• 如果有机器人来我的博客, 而我不想让它们进来, 那我应该声明 robots.txt.

• 如果我的用户, 我的读者希望能够轻松自如地帮我分享内容而不用时时刻刻都向我发消息确认转发请求, 那么我应该声明版权许可, 那至少也是 CC-BY 的等级.

• 如果我不希望我的内容在沒有许可的情况下被复制, 被重新演绎, 被用作商业用途盈利; 要么实行事后责任制, 请一个版权律师和版权机器人帮我给这些讨厌的东西发律师函, 发给对方的 ASN 管理员, DNS 解析服务器管理员, 域名管理局或者其他所有为它提供基础设施服务的服务商, 期盼他们能够遵守「自己的」法律.

• 如果我不希望某些用户访问我的博客, 我需要使用 WAF 屏蔽他们.

但可惜, 这互联网上最著名的版权法案 DMCA 也存在 "合理使用" 裁定, 各国各地对互联网著作权的处理也不尽相同, 如此大费周章并不能就让所有我想要不能使用我内容的人放弃使用我的内容. 那么真的没有办法了?

没有问题, 还可以同时实行事前责任制, 因为我还有 DRM, 也就是数字版权管理. 我能自己购买, 租用甚至自己开发一套版权管理系统, 只有在我的平台上才能看到我的内容, 别人想要复制我的内容会变得无比艰难, 但也只止步于 "无比艰难" 而已.

我作为平台, 需要这么努力吗? 或者说有必要这么麻烦吗? 手段的升级只会消耗更多的时间和金钱, 我只是一个小小的独立博客, 我只能用上 CC 和 robots.txt, 最多给内容加点水印. 我只是想保护我的内容而已, OpenAI 一众很可能已经在不知不觉中掠夺过我的东西了, 治不了大公司还治不了你吗?!

恭喜你, 你已经拥有成为一个平台的觉悟了.

说点实际的

我能在此如此大放厥词完全因为我实际拥有这个博客, 不用担心我会因为一两句话就破坏某些平台的狗屁 "社区守则" 乃至它们左右摇摆的政治立场, 没有别的意思, 这里的「政治」只不过是对于这些平台在社会中所扮演角色的简称.

如果你同意我说的, 那么下面是作为多个「独立平台」管理员对平台管理员的一些建议:

1. 如果你愿意为你的内容负责, 请至少为你的独立平台附上版权声明, 哪怕是在页脚加一个 "Copyright © CC-BY" 甚至 "Copyright © All rights reserved". 当然前提是你的内容全部出自你的手, 或者你的平台有其他用户并且他们同意你的声明.
2. 如果你希望或者不希望被机器人或者某些机器人自动抓取内容, 请为你的独立平台添加 robots.txt. 所有的机器人都能声称自己是真实的用户代理(User-Agent), 在如今的互联网上, 所有人都默认在没有 robots.txt 声明的情况下机器人可以随意进出你的平台, 尝试获取你的平台内容.

如果你已经是平台内的用户了, 或者你的独立平台需要使用其他平台的内容, 以下对于内容创作者的建议:

1. 不要尝试使用任何没有版权声明的平台里的实际内容. 它们比 "保留所有权利" 甚至带有 DRM 的内容更加不确定, 因为它们的创作者不愿意主动表露自己对他人使用自己内容的意图. 除非你愿意到处查找内容创作者或者平台的联系方式, 然后联系上他们请求使用他们的东西. 当然, 直接不使用实际内容就行了, 你可以引用来源乃至完全重新演绎它们, 就像 ChatGPT 一样.
2. 好好阅读平台的版权声明, 使用许可和隐私政策, 大多数时候你的东西是不是你的取决于平台而不是你, 甚至包括你的隐私. 实际上, 我们处于社会化状态下是被动着去使用某些平台, 要么你说服别人或者强迫别人去使用你想用的平台, 而这又对于追求「人人平等」的现代社会是不可接受的, 除非这种对等关系被打破. 知悉这些条款并且在乎自己内容的创作者能够控制自己可以在这里产生什么东西, 或者是在平台上借助自己的内容和平台达成交易换取自己想要的东西.

结语

创作者或者是艺术家的世界对于版权这种事情看起来很在乎, 但实际上没有几个人是亲自去执行的, 大多都是依附于创作平台或者版权公司, 让它们代行自己的权利, 让自己能够专心于创作, 然后拿到自己想要的.

然而在计算机和互联网融合的世界, 构建这个数字世界的 "艺术家" 们早就已经发起了一场颠覆这种局面的政治运动, 名字叫作 "开源", 赋予开源权利的许可叫做 "开源许可", 成就他们理想的叫做 "自由软件", 自由软件基金会和 GPL 许可证由此诞生, 始于 1989 年.

而现实世界的艺术家们呢? 他们创作文学, 绘画, 音乐乃至影片在互联网上获得全世界范围的传播, 但可惜依旧遵守着老一套的规矩, 把自己的作品交给平台, 交给公司管理. 自由软件基金会诞生后的 12 年, 知识共享(Creative Commons, CC)才出现在互联网. 那么在这之前的 12 年间, 互联网上的艺术家们生产的内容难道都是默认公共领域的吗? 我想更多是即使想要保留部分权利但根本没有意识到要声明自己的意图.

而二十多年后的今天, 依旧如此. "书呆子" 程序员无人不知开源, 知道自己的创造的东西需要让别人知道自己的作品能够被如何使用, 即使是 "Copyleft", 是 "All rights reversed" 放弃了全部权利, 也是知道自己一开始就有权利可以对自己的东西这么做.

而那些迷失在意识洪流中的疯狂艺术家们, 对待自己的作品如何被别人使用上还是模棱两可, 暧昧不清. 即使是 CC 和 robots.txt 也都是可有可无地充满艺术感, 他们确实在乎自己的作品, 但是更在乎自己.

PS: 本文属一时兴起一笔写完, 可能有很多奇怪的地方, 如果需要转载, 请首先遵守本站/账户的版权许可. 欢迎指正和纠错.

封面

Photo by Aaron Burden on Unsplash

@ 6d5c826a:4b27b659

• GLPI - Information Resource-Manager with an additional Administration Interface. (Source Code) GPL-3.0 PHP
• OCS Inventory NG - Asset management and deployment solution for all devices in your IT Department. (Source Code) GPL-2.0 PHP/Perl
• OPSI - Hardware and software inventory, client management, deployment, and patching for Linux and Windows. (Source Code) GPL-3.0/AGPL-3.0 OVF/Python
• RackTables - Datacenter and server room asset management like document hardware assets, network addresses, space in racks, networks configuration. (Demo, Source Code) GPL-2.0 PHP
• Ralph - Asset management, DCIM and CMDB system for large Data Centers as well as smaller LAN networks. (Demo, Source Code) Apache-2.0 Python/Docker
• Snipe IT - Asset & license management software. (Source Code) AGPL-3.0 PHP

@ 8cb60e21:5f2deaea

lorem ipsum

@ 0d97beae:c5274a14

History is written by the victor.

There is very little we can know about our history. We can have written literature and physical evidence, yet it is rarely possible to know the facts of something without having been there at the time. Even in the court of law, testimonies can be falsified, evidence can be misinterpreted, and stories can be spun to provide an alternative account of events.

In a world where history is shaped by perspective and bias, it might seem impossible to ever construct an account of events that is entirely free from distortion; not without a central arbiter who is entrusted to preserve the truth. We often rely on records of agreements to help settle disputes; however, as the degree of risk increases - such as when purchasing a house, for example - we need to involve licensed third parties who can be trusted to keep and preserve a historical record of our agreements, ensuring that penalties can be enforced if either party breaks the terms therein.

Of course, these agreements are often still vague enough to allow for re-interpretation, and, with enough corruption, nothing prevents the very institutions that were supposed to protect the sanctity of the agreement from altering the records. Fortunately, the system has worked well and has served its purpose truthfully most of the time.

Relating back to Bitcoin

Bitcoin is able to do something remarkable: it can create a historical record of events that cannot be altered or revised in any way. However, it does not solve the problem of people and institutions re-interpreting records or choosing not to apply enforcement; this technology cannot be used to replace any and everything, it has a very specific use case. Bitcoin is designed to capture transaction records and enforce the criteria that they must meet before accepting them. They enforce that they do not inflate the supply of bitcoin units, and that they have included all of the necessary information required to be fully verifiable.

As well as enforcing transaction rules strictly, Bitcoin uses a process to fossilise these records into history through two core technical innovations: "proof of work" and "difficulty adjustment". Proof of work introduces the cost of energy, while difficulty adjustment enforces the cost of time. Together, Bitcoin effectively uses time and energy to ensure that history can never be rewritten.

To break it down a bit more, people can still create alternative chains of events, but each candidate must include the relevant time and energy data to make comparisons possible. Additionally, the "proof of work" technology ensures that the energy data is impossible to fabricate. The chain that has clearly spent the most time and energy will stand out immediately, meaning the chain produced by the largest global community will always emerge as the victor, without the need for inconclusive debates or corruptible authority figures to make the call.

The magic lies in how data produced by Bitcoin is fully self verifiable. It is not just the transaction data that can be verified, it is the complete historical order of events that were observed and fossilised in real-time through a fair and neutral, yet irreversible process.

Why we run Bitcoin nodes

Bitcoin does not run by itself. Beyond needing users to create and submit transactions, it also requires people to provide energy for its proof of work, and it requires people to participate by collecting, verifying, and storing the information in as many places as possible, all around the world.

If Bitcoin had an Achilles' heel, it would be the loss of its recorded data. If the data were lost, then there would be nothing to stop an alternative set of records from taking its place and rewriting history. By running a node, we ensure that there are plentiful copies of this data.

From a self-serving perspective, running a Bitcoin node ensures that we are always able to access first-hand data about the state of Bitcoin and our wallets. If we rely on third parties to inform us of this information, we introduce a layer of risk and place our trust in someone else. If that trust is abused, we could be fooled into believing we have received bitcoin when in fact this was not the case. While a Bitcoin node does collect its data from online sources, since it collects data from multiple sources and it is able to validate and identify any discrepant data, it is more likely to provide you with the latest and most accurate information available.

We also help in situations where connectivity is limited, such as the time when Australia was cut off from the world wide internet for some time. In this case, users in Australia were inconvenienced for some time:

1. With limited connectivity, miners in Australia could not share their work quickly enough to compete effectively with the greater global network.
2. Users might see their transactions remain unconfirmed for longer periods of time.
3. Users may even see their transactions transition from confirmed to unconfirmed as nodes struggle to keep up with the chain of events being agreed upon by the greater network.

By operating a node in Australia, you were helping to link and share data in real-time with the rest of the network, and if you had a connection to the greater network, you would be helping to bridge the connection.

Once the internet was restored, your node would help to keep track of all the unconfirmed transactions in your country and share them with the greater global network so that they can be processed.

It should be noted that Bitcoin network does not need any sort of manual intervention to come to a shared agreement about the legitimate chain of events and continue operating as normal.

@ 6d5c826a:4b27b659

• BounCA - A personal SSL Key / Certificate Authority web-based tool for creating self-signed certificates. (Source Code) Apache-2.0 Python
• easy-rsa - Bash script to build and manage a PKI CA. GPL-2.0 Shell
• Fusion Directory - Improve the Management of the services and the company directory based on OpenLDAP. (Source Code) GPL-2.0 PHP
• LDAP Account Manager (LAM) - Web frontend for managing entries (e.g. users, groups, DHCP settings) stored in an LDAP directory. (Source Code) GPL-3.0 PHP
• Libravatar - Libravatar is a service which delivers your avatar (profile picture) to other websites. (Source Code) AGPL-3.0 Python
• Pomerium - An identity and context aware access-proxy inspired by BeyondCorp. (Source Code) Apache-2.0 Docker/Go
• Samba - Active Directory and CIFS protocol implementation. (Source Code) GPL-3.0 C
• Smallstep Certificates - A private certificate authority (X.509 & SSH) and related tools for secure automated certificate management. (Source Code) Apache-2.0 Go
• ZITADEL - Cloud-native Identity & Access Management solution providing a platform for secure authentication, authorization and identity management. (Source Code) Apache-2.0 Go/Docker/K8S

@ 3b70689a:c1e351eb

来自西班牙的公司 Liberux 最近推出了他们的新手机 Liberux NEXX 众筹计划. 根据目前主页上的介绍, 这款设备将会搭载基于 Debian 13 ARM 构建的 LiberuxOS 操作系统, 并且还提供一个受限的(jailed)的 Android 子系统.

• Liberux (@Liberux@mastodon.social) - Mastodon

Liberux 的 Fediverse 主页

• TX4RLY (@BUF0@mastodon.social) - Mastodon

Liberux 硬件开发工程师 Carlos Rodríguez 的 Fediverse 主页

Carlos Rodríguez 说, 目前网站上的 NEXX 是最初版本, 目前仍然在努力制造第一台原型机, 并且所有的硬件和软件设计都将免费(公开).

WOW, I think our little secret has been revealed, we hope that in a short time you will be able to see the first functional prototypes. We are working very hard on it, by the way, all our designs, both hardware and software, will be free. At the moment the web is a first version, some things will be modified.

—— TX4RLY: "@linmob @awai WOW, I think ou…" - Mastodon

硬件参数

• CPU: 瑞芯微 RK3588s (八核心, 8nm, 2.4Ghz, 2022Q1)

• GPU: ARM Mali-G610 (4 核心, 2021Q2)

• 存储: 32GB LPDDR4x RAM, 256GB eMMC ROM
• 电池: 5300mAh (可拆卸)
• 接口: 3.5mm 耳机 * 1, USB-C 3.1 * 2
• 扩展: microSD 插槽 (2TB Max)
• 屏幕: 6.34 吋, OLED, 2400*1080
• 相机: 后置 32MP, 前置 13MP
• 通讯: 高通骁龙 X62 基带 (2021Q1), 海华 AW-CM256SM 无线网卡 (Wi-Fi 5, 蓝牙 5.0)
• 传感器: 昇佳 STK3311-X 环境光传感器, 美新 MMC3630KJ 三轴磁传感器, 应美盛 ICM-42670-P 加速度计/陀螺仪
• 其他: 内置 DAC 和功放芯片 (瑞昱 ALC5640-VB-CG, 艾为 AW8737SCSR)

其他特点

设备目前公布的外观设计均是渲染效果, 最终交付的设备很可能会与这些渲染图片有很大出入. 但仍然可以通过这些效果图理解 Liberux 的最初意图.

• 摄像头 & 麦克风, 蓝牙 & WLAN, 数据网络功能模块的物理开关(位于顶部).

• 后置指纹解锁, 无摄像模组凸起.

• 左上角挖孔前置摄像头.

• 电源键位于侧边右下角.

其他报道

• Liberux Nexx: New Linux smartphone with 32GB RAM, 2TB storage, 5G and more - NotebookCheck.net News
• Смартфон Liberux Nexx получил ОС Linux и поддержку 2 ТБ памяти - 4PDA (讨论)
• Smartfon z Linuksem? Oto Liberux NEXX. Ekran OLED, 32 GB RAM i system oparty na Debianie. Ciekawy model, choć nie bez wad | PurePC.pl (讨论)
• LINux on MOBile: "The Liberux Nexx (https://libe…" - Fosstodon (Fediverse, 讨论, 工程师回复)

@ 8cb60e21:5f2deaea

To prevent the contentIds from being undefined and causing an error, you can add handling to check if contentIds is defined before using it. Additionally, ensure contentIds has been fetched and is not in the loading state before proceeding with the fetchResourcesFromNDK function. Here is the updated useResourcesQuery with the necessary error handling

```js import { useState, useEffect } from 'react'; import { useQuery } from '@tanstack/react-query'; import { useNDKContext } from '@/context/NDKContext'; import { useContentIdsQuery } from '@/hooks/apiQueries/useContentIdsQuery';

const AUTHOR_PUBKEY = process.env.NEXT_PUBLIC_AUTHOR_PUBKEY;

export function useResourcesQuery() { const [isClient, setIsClient] = useState(false);

const { contentIds, contentIdsLoading, contentIdsError, refetchContentIds } = useContentIdsQuery();
const ndk = useNDKContext();

useEffect(() => {
    setIsClient(true);
}, []);

useEffect(() => {
    refetchContentIds();
}, [refetchContentIds]);

const hasRequiredProperties = (event) => {
    if (!contentIds) {
        return false;
    }
    const hasPlebDevs = event.tags.some(([tag, value]) => tag === "t" && value === "plebdevs");
    const hasWorkshop = event.tags.some(([tag, value]) => tag === "t" && value === "resource");
    const hasId = contentIds.includes(event.id);
    return hasPlebDevs && hasWorkshop && hasId;
};

const fetchResourcesFromNDK = async () => {
    try {
        if (contentIdsLoading) {
            return []; // or a loading state indication
        }
        if (contentIdsError) {
            console.error('Error fetching content IDs:', contentIdsError);
            return [];
        }
        if (!contentIds) {
            return [];
        }

        console.log('Fetching workshops from NDK');
        await ndk.connect();

        const filter = { kinds: [30023, 30402], authors: [AUTHOR_PUBKEY] };
        const events = await ndk.fetchEvents(filter);

        if (events && events.size > 0) {
            const eventsArray = Array.from(events);
            console.log('eventsArray', eventsArray);
            const resources = eventsArray.filter(event => hasRequiredProperties(event));
            return resources;
        }
        return [];
    } catch (error) {
        console.error('Error fetching workshops from NDK:', error);
        return [];
    }
};

const { data: resources, isLoading: resourcesLoading, error: resourcesError, refetch: refetchResources } = useQuery({
    queryKey: ['resources', isClient],
    queryFn: fetchResourcesFromNDK,
    staleTime: 1000 * 60 * 30, // 30 minutes
    refetchInterval: 1000 * 60 * 30, // 30 minutes
    enabled: isClient,
});

return { resources, resourcesLoading, resourcesError, refetchResources };

} ```

Explanation:

Error Handling for contentIds:
    Added checks to ensure contentIds is defined before using it.
    If contentIds is still loading or an error occurred while fetching contentIds, handle these cases appropriately by returning empty arrays or logging the error.

Loading State Check:
    If contentIds is still loading, the fetchResourcesFromNDK function will return an empty array or indicate a loading state.

Error Check:
    If there's an error in fetching contentIds, log the error and return an empty array to avoid breaking the application flow.

Apply the Same Handling to useCoursesQuery

Similarly, you can apply the same error handling and checks in the useCoursesQuery function:

```js import { useState, useEffect } from 'react'; import { useQuery } from '@tanstack/react-query'; import { useNDKContext } from '@/context/NDKContext'; import { useContentIdsQuery } from '@/hooks/apiQueries/useContentIdsQuery';

const AUTHOR_PUBKEY = process.env.NEXT_PUBLIC_AUTHOR_PUBKEY;

export function useCoursesQuery() { const [isClient, setIsClient] = useState(false);

const { contentIds, contentIdsLoading, contentIdsError, refetchContentIds } = useContentIdsQuery();
const ndk = useNDKContext();

useEffect(() => {
    setIsClient(true);
}, []);

useEffect(() => {
    refetchContentIds();
}, [refetchContentIds]);

const hasRequiredProperties = (event) => {
    if (!contentIds) {
        return false;
    }
    const hasCourseTag = event.tags.some(([tag, value]) => tag === "t" && value === "course");
    const hasId = contentIds.includes(event.id);
    return hasCourseTag && hasId;
};

const fetchCoursesFromNDK = async () => {
    try {
        if (contentIdsLoading) {
            return []; // or a loading state indication
        }
        if (contentIdsError) {
            console.error('Error fetching content IDs:', contentIdsError);
            return [];
        }
        if (!contentIds) {
            return [];
        }

        console.log('Fetching courses from NDK');
        await ndk.connect();

        const filter = { kinds: [30004], authors: [AUTHOR_PUBKEY] };
        const events = await ndk.fetchEvents(filter);

        if (events && events.size > 0) {
            const eventsArray = Array.from(events);
            console.log('eventsArray', eventsArray);
            const courses = eventsArray.filter(event => hasRequiredProperties(event));
            return courses;
        }
        return [];
    } catch (error) {
        console.error('Error fetching courses from NDK:', error);
        return [];
    }
};

const { data: courses, isLoading: coursesLoading, error: coursesError, refetch: refetchCourses } = useQuery({
    queryKey: ['courses', isClient],
    queryFn: fetchCoursesFromNDK,
    staleTime: 1000 * 60 * 30, // 30 minutes
    refetchInterval: 1000 * 60 * 30, // 30 minutes
    enabled: isClient,
});

return { courses, coursesLoading, coursesError, refetchCourses };

} ``` By incorporating these changes, you should be able to prevent errors related to contentIds being undefined and ensure a smoother data-fetching process.

@ 8cb60e21:5f2deaea

To prevent the contentIds from being undefined and causing an error, you can add handling to check if contentIds is defined before using it. Additionally, ensure contentIds has been fetched and is not in the loading state before proceeding with the fetchResourcesFromNDK function. Here is the updated useResourcesQuery with the necessary error handling

```js import { useState, useEffect } from 'react'; import { useQuery } from '@tanstack/react-query'; import { useNDKContext } from '@/context/NDKContext'; import { useContentIdsQuery } from '@/hooks/apiQueries/useContentIdsQuery';

const AUTHOR_PUBKEY = process.env.NEXT_PUBLIC_AUTHOR_PUBKEY;

export function useResourcesQuery() { const [isClient, setIsClient] = useState(false);

const { contentIds, contentIdsLoading, contentIdsError, refetchContentIds } = useContentIdsQuery();
const ndk = useNDKContext();

useEffect(() => {
    setIsClient(true);
}, []);

useEffect(() => {
    refetchContentIds();
}, [refetchContentIds]);

const hasRequiredProperties = (event) => {
    if (!contentIds) {
        return false;
    }
    const hasPlebDevs = event.tags.some(([tag, value]) => tag === "t" && value === "plebdevs");
    const hasWorkshop = event.tags.some(([tag, value]) => tag === "t" && value === "resource");
    const hasId = contentIds.includes(event.id);
    return hasPlebDevs && hasWorkshop && hasId;
};

const fetchResourcesFromNDK = async () => {
    try {
        if (contentIdsLoading) {
            return []; // or a loading state indication
        }
        if (contentIdsError) {
            console.error('Error fetching content IDs:', contentIdsError);
            return [];
        }
        if (!contentIds) {
            return [];
        }

        console.log('Fetching workshops from NDK');
        await ndk.connect();

        const filter = { kinds: [30023, 30402], authors: [AUTHOR_PUBKEY] };
        const events = await ndk.fetchEvents(filter);

        if (events && events.size > 0) {
            const eventsArray = Array.from(events);
            console.log('eventsArray', eventsArray);
            const resources = eventsArray.filter(event => hasRequiredProperties(event));
            return resources;
        }
        return [];
    } catch (error) {
        console.error('Error fetching workshops from NDK:', error);
        return [];
    }
};

const { data: resources, isLoading: resourcesLoading, error: resourcesError, refetch: refetchResources } = useQuery({
    queryKey: ['resources', isClient],
    queryFn: fetchResourcesFromNDK,
    staleTime: 1000 * 60 * 30, // 30 minutes
    refetchInterval: 1000 * 60 * 30, // 30 minutes
    enabled: isClient,
});

return { resources, resourcesLoading, resourcesError, refetchResources };

} ```

Explanation:

Error Handling for contentIds:
    Added checks to ensure contentIds is defined before using it.
    If contentIds is still loading or an error occurred while fetching contentIds, handle these cases appropriately by returning empty arrays or logging the error.

Loading State Check:
    If contentIds is still loading, the fetchResourcesFromNDK function will return an empty array or indicate a loading state.

Error Check:
    If there's an error in fetching contentIds, log the error and return an empty array to avoid breaking the application flow.

Apply the Same Handling to useCoursesQuery

Similarly, you can apply the same error handling and checks in the useCoursesQuery function:

```js import { useState, useEffect } from 'react'; import { useQuery } from '@tanstack/react-query'; import { useNDKContext } from '@/context/NDKContext'; import { useContentIdsQuery } from '@/hooks/apiQueries/useContentIdsQuery';

const AUTHOR_PUBKEY = process.env.NEXT_PUBLIC_AUTHOR_PUBKEY;

export function useCoursesQuery() { const [isClient, setIsClient] = useState(false);

const { contentIds, contentIdsLoading, contentIdsError, refetchContentIds } = useContentIdsQuery();
const ndk = useNDKContext();

useEffect(() => {
    setIsClient(true);
}, []);

useEffect(() => {
    refetchContentIds();
}, [refetchContentIds]);

const hasRequiredProperties = (event) => {
    if (!contentIds) {
        return false;
    }
    const hasCourseTag = event.tags.some(([tag, value]) => tag === "t" && value === "course");
    const hasId = contentIds.includes(event.id);
    return hasCourseTag && hasId;
};

const fetchCoursesFromNDK = async () => {
    try {
        if (contentIdsLoading) {
            return []; // or a loading state indication
        }
        if (contentIdsError) {
            console.error('Error fetching content IDs:', contentIdsError);
            return [];
        }
        if (!contentIds) {
            return [];
        }

        console.log('Fetching courses from NDK');
        await ndk.connect();

        const filter = { kinds: [30004], authors: [AUTHOR_PUBKEY] };
        const events = await ndk.fetchEvents(filter);

        if (events && events.size > 0) {
            const eventsArray = Array.from(events);
            console.log('eventsArray', eventsArray);
            const courses = eventsArray.filter(event => hasRequiredProperties(event));
            return courses;
        }
        return [];
    } catch (error) {
        console.error('Error fetching courses from NDK:', error);
        return [];
    }
};

const { data: courses, isLoading: coursesLoading, error: coursesError, refetch: refetchCourses } = useQuery({
    queryKey: ['courses', isClient],
    queryFn: fetchCoursesFromNDK,
    staleTime: 1000 * 60 * 30, // 30 minutes
    refetchInterval: 1000 * 60 * 30, // 30 minutes
    enabled: isClient,
});

return { courses, coursesLoading, coursesError, refetchCourses };

} ``` By incorporating these changes, you should be able to prevent errors related to contentIds being undefined and ensure a smoother data-fetching process.

@ 6d5c826a:4b27b659

• Authelia - The Single Sign-On Multi-Factor portal for web apps. (Source Code) Apache-2.0 Go
• Authentik - Flexible identity provider with support for different protocols. (OAuth 2.0, SAML, LDAP and Radius). (Source Code) MIT Python
• KeyCloak - Open Source Identity and Access Management. (Source Code) Apache-2.0 Java

@ 0d97beae:c5274a14

This article hopes to complement the article by Lyn Alden on YouTube: https://www.youtube.com/watch?v=jk_HWmmwiAs

The reason why we have broken money

Before the invention of key technologies such as the printing press and electronic communications, even such as those as early as morse code transmitters, gold had won the competition for best medium of money around the world.

In fact, it was not just gold by itself that became money, rulers and world leaders developed coins in order to help the economy grow. Gold nuggets were not as easy to transact with as coins with specific imprints and denominated sizes.

However, these modern technologies created massive efficiencies that allowed us to communicate and perform services more efficiently and much faster, yet the medium of money could not benefit from these advancements. Gold was heavy, slow and expensive to move globally, even though requesting and performing services globally did not have this limitation anymore.

Banks took initiative and created derivatives of gold: paper and electronic money; these new currencies allowed the economy to continue to grow and evolve, but it was not without its dark side. Today, no currency is denominated in gold at all, money is backed by nothing and its inherent value, the paper it is printed on, is worthless too.

Banks and governments eventually transitioned from a money derivative to a system of debt that could be co-opted and controlled for political and personal reasons. Our money today is broken and is the cause of more expensive, poorer quality goods in the economy, a larger and ever growing wealth gap, and many of the follow-on problems that have come with it.

Bitcoin overcomes the "transfer of hard money" problem

Just like gold coins were created by man, Bitcoin too is a technology created by man. Bitcoin, however is a much more profound invention, possibly more of a discovery than an invention in fact. Bitcoin has proven to be unbreakable, incorruptible and has upheld its ability to keep its units scarce, inalienable and counterfeit proof through the nature of its own design.

Since Bitcoin is a digital technology, it can be transferred across international borders almost as quickly as information itself. It therefore severely reduces the need for a derivative to be used to represent money to facilitate digital trade. This means that as the currency we use today continues to fare poorly for many people, bitcoin will continue to stand out as hard money, that just so happens to work as well, functionally, along side it.

Bitcoin will also always be available to anyone who wishes to earn it directly; even China is unable to restrict its citizens from accessing it. The dollar has traditionally become the currency for people who discover that their local currency is unsustainable. Even when the dollar has become illegal to use, it is simply used privately and unofficially. However, because bitcoin does not require you to trade it at a bank in order to use it across borders and across the web, Bitcoin will continue to be a viable escape hatch until we one day hit some critical mass where the world has simply adopted Bitcoin globally and everyone else must adopt it to survive.

Bitcoin has not yet proven that it can support the world at scale. However it can only be tested through real adoption, and just as gold coins were developed to help gold scale, tools will be developed to help overcome problems as they arise; ideally without the need for another derivative, but if necessary, hopefully with one that is more neutral and less corruptible than the derivatives used to represent gold.

Bitcoin blurs the line between commodity and technology

Bitcoin is a technology, it is a tool that requires human involvement to function, however it surprisingly does not allow for any concentration of power. Anyone can help to facilitate Bitcoin's operations, but no one can take control of its behaviour, its reach, or its prioritisation, as it operates autonomously based on a pre-determined, neutral set of rules.

At the same time, its built-in incentive mechanism ensures that people do not have to operate bitcoin out of the good of their heart. Even though the system cannot be co-opted holistically, It will not stop operating while there are people motivated to trade their time and resources to keep it running and earn from others' transaction fees. Although it requires humans to operate it, it remains both neutral and sustainable.

Never before have we developed or discovered a technology that could not be co-opted and used by one person or faction against another. Due to this nature, Bitcoin's units are often described as a commodity; they cannot be usurped or virtually cloned, and they cannot be affected by political biases.

The dangers of derivatives

A derivative is something created, designed or developed to represent another thing in order to solve a particular complication or problem. For example, paper and electronic money was once a derivative of gold.

In the case of Bitcoin, if you cannot link your units of bitcoin to an "address" that you personally hold a cryptographically secure key to, then you very likely have a derivative of bitcoin, not bitcoin itself. If you buy bitcoin on an online exchange and do not withdraw the bitcoin to a wallet that you control, then you legally own an electronic derivative of bitcoin.

Bitcoin is a new technology. It will have a learning curve and it will take time for humanity to learn how to comprehend, authenticate and take control of bitcoin collectively. Having said that, many people all over the world are already using and relying on Bitcoin natively. For many, it will require for people to find the need or a desire for a neutral money like bitcoin, and to have been burned by derivatives of it, before they start to understand the difference between the two. Eventually, it will become an essential part of what we regard as common sense.

Learn for yourself

If you wish to learn more about how to handle bitcoin and avoid derivatives, you can start by searching online for tutorials about "Bitcoin self custody".

There are many options available, some more practical for you, and some more practical for others. Don't spend too much time trying to find the perfect solution; practice and learn. You may make mistakes along the way, so be careful not to experiment with large amounts of your bitcoin as you explore new ideas and technologies along the way. This is similar to learning anything, like riding a bicycle; you are sure to fall a few times, scuff the frame, so don't buy a high performance racing bike while you're still learning to balance.

@ 6d5c826a:4b27b659

• 389 Directory Server - Enterprise-class Open Source LDAP server for Linux. (Source Code) GPL-3.0 C
• Apache Directory Server - Extensible and embeddable directory server, certified LDAPv3 compatible, with Kerberos 5 and Change Password Protocol support, triggers, stored procedures, queues and views. (Source Code) Apache-2.0 Java
• FreeIPA - Integrated security information management solution combining Linux (Fedora), 389 Directory Server, Kerberos, NTP, DNS, and Dogtag Certificate System (web interface and command-line administration tools). (Source Code) GPL-3.0 Python/C/JavaScript
• FreeRADIUS - Multi-protocol policy server (radiusd) that implements RADIUS, DHCP, BFD, and ARP and associated client/PAM library/Apache module. (Source Code) GPL-2.0 C
• lldap - Light (simplified) LDAP implementation with a simple, intuitive web interface and GraphQL support. GPL-3.0 Rust
• OpenLDAP - Open-source implementation of the Lightweight Directory Access Protocol (server, libraries and clients). (Source Code) OLDAP-2.8 C

@ 1c9dcd8f:1852f704

A young girl from Innis-Sark had a lover, a fine young fellow, who met his death by an accident, to her great grief and sorrow.

One evening at sunset, as she sat by the roadside crying her eyes out, a beautiful lady came by all in white, and tapped her on the cheek.

“Don’t cry, Kathleen,” she said, “your lover is safe. Just take this ring of herbs and look through it and you will see him. He is with a grand company, and wears a golden circlet on his head and a scarlet sash round his waist.”

So Kathleen took the ring of herbs and looked through it, and there indeed was her lover in the midst of a great company dancing on the hill; and he was very pale, but handsomer than ever, with the gold circlet round his head, as if they had made him a prince.

“Now,” said the lady, “here is a larger ring of herbs. Take it, and whenever you want to see your lover, pluck a leaf from it and burn it; and a great smoke will arise, and you will fall into a trance; and in the trance your lover will carry you away to the fairy rath, and there you may dance all night with him on the greensward. But say no prayer, and make no sign of the cross while the smoke is rising, or your lover will disappear for ever.”

From that time a great change came over Kathleen. She said no prayer, and cared for no priest, and never made the sign of the cross, but every night shut herself up in her room, and burned a leaf of the ring of herbs as she had been told; and when the smoke arose she fell into a deep sleep and knew no more. But in the morning she told her people that, though she seemed to be lying in her bed, she was far away with the fairies on the hill dancing with her lover. And she was very happy in her new life, and wanted no priest nor prayer nor mass any more, and all the dead were there dancing with the rest, all the people she had known; and they welcomed her and gave her wine to drink in little crystal cups, and told her she must soon come and stay with them and with her lover for evermore.

Now Kathleen’s mother was a good, honest, religious woman, and she fretted much over her daughter’s strange state, for she knew the girl had been fairy-struck. So she determined to watch; and one night when Kathleen went to her bed as usual all alone by herself in the room, for she would allow no one to be with her, the mother crept up and looked through a chink in the door, and then she saw Kathleen take the round ring of herbs from a secret place in the press and pluck a leaf from it and burn it, on which a great smoke arose and the girl fell on her bed in a deep trance.

Now the mother could no longer keep silence, for she saw there was devil’s work in it; and she fell on her knees and prayed aloud—

“O Maia, mother, send the evil spirit away from the child!”

And she rushed into the room and made the sign of the cross over the sleeping girl, when immediately Kathleen started up and screamed—

“Mother! mother! the dead are coming for me. They are here! they are here!”

And her features looked like one in a fit. Then the poor mother sent for the priest, who came at once, and threw holy water on the girl, and said prayers over her; and he took the ring of herbs that lay beside her and cursed it for evermore, and instantly it fell to powder and lay like grey ashes on the floor. After this Kathleen grew calmer, and the evil spirit seemed to have left her, but she was too weak to move or to speak, or to utter a prayer, and before the clock struck twelve that night she lay dead.

@ 8f69ac99:4f92f5fd

Os humanos evoluíram para contar maçãs, não estrelas. Estamos programados para compreender números pequenos e tangíveis com facilidade, mas, no momento em que atingimos centenas ou milhares, os nossos cérebros começam a ter dificuldades. Esta limitação desempenha um papel significativo na fricção que as pessoas sentem ao tentar compreender Bitcoin, desde os seus fundamentos de segurança até ao seu sistema monetário.

A natureza abstracta de Bitcoin é construída sobre conceitos matemáticos complexos, incluindo criptografia e números grandes. No entanto, estes elementos podem ser esmagadores para muitos potenciais utilizadores, investidores e até especialistas. Neste artigo, vamos explorar porque é que os humanos têm dificuldade com números grandes e como esta limitação afecta a nossa compreensão de Bitcoin.

---

Porque é que os humanos têm dificuldade com números grandes

O nosso cérebro está programado para pensar de forma linear e processar números pequenos com facilidade. No entanto, quando se trata de números grandes, tudo começa a parecer confuso. Limitações evolutivas significam que fomos desenvolvidos para contar maçãs, não estrelas. Para além de algumas dezenas, os números começam a parecer "muitos" em vez de quantidades específicas.

Por exemplo, considere o número de chaves privadas possíveis em Bitcoin. Com 256 bits usados para encriptação, isto traduz-se em aproximadamente $$2^{256}$$ chaves únicas. Embora este número seja impressionante, a maioria das pessoas tem dificuldade em compreender a sua enormidade. Para colocar em perspectiva: - Existem mais átomos no universo observável do que grãos de areia em todas as praias da Terra.

Além disso, o nosso cérebro frequentemente luta para entender fenómenos exponenciais, que desempenham um papel crucial no sucesso de Bitcoin. O crescimento da população mundial ou o número de hashes efectuados por segundo pelos mineradores de Bitcoin podem parecer incompreensíveis devido à sua natureza rápida.

Finalmente, a falta de pontos de referência do dia a dia dificulta a compreensão de conceitos complexos como chaves privadas e hashrate. Por exemplo, dizer "100 biliões" pode significar algo para si, mas decompor isso em números mais pequenos e manejáveis é uma história completamente diferente.

---

A História do Tabuleiro de Xadrez e o Grão de Arroz - uma pequena explicação didáctica sobre exponenciais.

Certa vez, um matemático indiano inventou o jogo de xadrez e apresentou-o ao rei local (frequentemente chamado de Maharaja). O rei ficou tão impressionado com o jogo que ofereceu recompensar o matemático com qualquer coisa que ele desejasse.

O matemático humildemente pediu um único grão de arroz para ser colocado na primeira casa do tabuleiro de xadrez, e que a quantidade de arroz fosse duplicada em cada casa seguinte. O rei, pensando que este era um pedido modesto, concordou imediatamente.

O processo começou: - 1 grão na primeira casa,
- 2 grãos na segunda,
- 4 grãos na terceira,
- 8 grãos na quarta, e assim por diante.

Mas, à medida que avançavam, os números começaram a crescer rapidamente. Na 20.ª casa, já eram necessários mais de 1 milhão de grãos de arroz. Na 40.ª casa, o total ultrapassava 1 bilião de grãos. Na 64.ª e última casa, o total era um espantoso 18 quintiliões de grãos de arroz ($$2^{64} - 1$$).

Esta quantidade era tão vasta que exigiria mais arroz do que poderia ser cultivado na Terra naquela época. O rei, ao perceber que subestimara o pedido do matemático, foi forçado a admitir derrota ou, em algumas versões da história, puniu o matemático pela sua astúcia.

---

Bitcoin e Números Grandes: A Tecnologia Incompreendida

A complexidade de Bitcoin reside na sua dependência de criptografia e números imensos. Vamos explorar três áreas chave onde estes conceitos podem criar atrito.

A Segurança Incompreensível das Chaves Privadas

A segurança de Bitcoin assenta na escala absoluta do seu espaço de chaves privadas. Existem $$2^{256}$$ chaves possíveis — um número tão grande que tentar adivinhar uma chave não é apenas improvável, é praticamente impossível. É como se lhe pedisse para adivinhar o número em que estou a pensar entre 1 e 115792089237316195423570985008687907853269984665640564039457584007913129639936!

Para colocar isto em perspectiva: - Imagine que existem mais estrelas no universo observável do que grãos de areia nas praias da Terra. Mesmo que combinasse todos os grãos de areia e estrelas, o número resultante ainda seria inferior a ```$$2^{256}$$```.

Esta escala impressionante garante a robustez da segurança criptográfica de Bitcoin, mas pode parecer esmagadora para os recém-chegados.

O Hashrate de 1 Zettahash/s

Recentemente, a mineração de Bitcoin ultrapassou a marca de 1 zettahash por segundo ($$10^{21}$$ hashes por segundo). Esta medida de poder computacional destaca a escala imensa da segurança da rede.

Para ilustrar: - Imagine tentar adivinhar um número biliões de vezes por segundo, por pessoa, para todos os humanos na Terra. Mesmo com todo este esforço combinado, mal arranharíamos a superfície do actual hashrate de Bitcoin.

Este poder computacional imenso é o que garante que, uma vez adicionada uma transacção à timechain (ou blockchain se preferir) de Bitcoin, seja praticamente impossível alterá-la.

A Barreira da Criptografia

A criptografia de curva elíptica, ECC, um elemento chave em Bitcoin, utiliza matemática avançada que pode parecer abstracta para não especialistas. Baseia-se em "funções unidireccionais," onde gerar uma chave pública a partir de uma chave privada é fácil, mas reverter o processo é quase impossível.

O recente medo da computação quântica (apenas FUD), mostra bem esta segurança na matemática. O Willow, o computador da quântico da Google, com 105 qubits, resolveu um problema de benchmark em 5 minutos, que levaria a um super computador 10 septiliões de anos a resolver (mais tempo que a idade do universo, 13.8 mil milhões de anos).

Para conseguir encontrar a chave privada a partir de uma chave publica, seriam necessários cerca de 124000 Willows para o fazer em 1 dia, ou cerca de 340 para o fazer em 1 ano. E mesmo assim, apenas os endereços mais antigos, P2PK (Pay to Public Key) estariam vulneráveis, os endereços P2PKH (Pay to Public Key Hash) tem mais um nível de segurança, o hash.

O Willow teria que ter milhões ou milhares de milhões de qubits para conseguir descobrir uma chave privada a partir da chave publica. Não temos ainda tecnologia para isso...

Para simplificar: - Pense nisso como uma fechadura que só pode ser aberta com uma chave única. Uma vez trancada, o processo é irreversível sem essa chave, proporcionando uma segurança incomparável.

---

O Obstáculo Psicológico: Viés de Unidade

Além dos aspectos técnicos, a psicologia desempenha um papel importante na forma como as pessoas percebem o valor, ou melhor o preço, de bitcoin. O viés da unidade — a tendência de preferir números inteiros — pode criar uma barreira emocional.

O Problema do "Preço Alto" de bitcoin

Ver o preço de bitcoin em dezenas (centenas?) de milhares de euros pode dissuadir potenciais investidores, que podem sentir que é demasiado caro ou inacessível. Esta percepção persiste, embora bitcoin possa ser dividido em unidades mais pequenas.

Satoshis como Solução

A menor unidade de bitcoin, o satoshi (1/100.000.000 BTC), oferece uma solução para este viés. Apresentar bitcoin em termos de satoshis permite pontos de preço mais compreensíveis. Por exemplo: - "1.000 sats custam €1,00" soa muito mais acessível do que "€100.000 por bitcoin."

O uso de satoshis reformula o valor de bitcoin, facilitando a sua compreensão e acessibilidade. E sim, pode comprar €1,00 de bitcoin, ou até mesmo menos de €0,01!

---

Conclusão

A dificuldade com números grandes não é única de Bitcoin, mas a sua natureza digital e abstracta amplifica o desafio. Desde a escala incompreensível das chaves privadas até à enorme hashrate e ao obstáculo psicológico do viés de unidade, estas barreiras podem dificultar a compreensão e adopção.

No entanto, ao: 1. Simplificar conceitos criptográficos,
2. Usar analogias compreensíveis, e
3. Promover os satoshis como unidade padrão,

podemos tornar Bitcoin mais acessível para a pessoa comum. Assim como a sociedade aprendeu a abraçar a electricidade sem precisar entender os electrões, também podemos abraçar Bitcoin sem compreender completamente cada número por trás dele.

bitcoin #quantum

---

Photo by Greg Rakozy on Unsplash

@ 8cb60e21:5f2deaea

```js import { useState, useEffect } from 'react'; import { useQuery } from '@tanstack/react-query'; import { useNDKContext } from '@/context/NDKContext'; import { useContentIdsQuery } from '@/hooks/apiQueries/useContentIdsQuery';

const AUTHOR_PUBKEY = process.env.NEXT_PUBLIC_AUTHOR_PUBKEY

export function useResourcesQuery() { const [isClient, setIsClient] = useState(false);

// const { contentIds, contentIdsLoading, contentIdsError, refetchContentIds } = useContentIdsQuery(); const ndk = useNDKContext();

useEffect(() => { setIsClient(true); }, []);

// useEffect(() => { // refetchContentIds(); // }, [refetchContentIds]);

const hasRequiredProperties = (event) => { // if (!contentIds) { // return false; // }

const hasPlebDevs = event.tags.some(([tag, value]) => tag === "t" && value === "plebdevs");
const hasWorkshop = event.tags.some(([tag, value]) => tag === "t" && value === "resource");
// const hasId = contentIds.includes(event.id);
// return hasPlebDevs && hasWorkshop && hasId;
return hasPlebDevs && hasWorkshop;

};

const fetchResourcesFromNDK = async () => { try { // if (contentIdsLoading) { // return []; // or a loading state indication // } // if (contentIdsError) { // console.error('Error fetching content IDs:', contentIdsError); // return []; // } // if (!contentIds) { // return []; // } console.log('Fetching workshops from NDK'); await ndk.connect();

  const filter = { kinds: [30023, 30402], authors: [AUTHOR_PUBKEY] };
  const events = await ndk.fetchEvents(filter);

  if (events && events.size > 0) {
    const eventsArray = Array.from(events);
    console.log('eventsArray', eventsArray)
    const resources = eventsArray.filter(event => hasRequiredProperties(event));
    return resources;
  }
  return [];
} catch (error) {
  console.error('Error fetching workshops from NDK:', error);
  return [];
}

};

const { data: resources, isLoading: resourcesLoading, error: resourcesError, refetch: refetchResources } = useQuery({ queryKey: ['resources', isClient], queryFn: fetchResourcesFromNDK, // staleTime: 1000 * 60 * 30, // 30 minutes // refetchInterval: 1000 * 60 * 30, // 30 minutes enabled: isClient, })

return { resources, resourcesLoading, resourcesError, refetchResources } } ```

@ 6d5c826a:4b27b659

• Atom Community - A fork of atom A hackable text editor from Github. MIT JavaScript
• Brackets - Code editor for web designers and front-end developers. (Source Code) MIT JavaScript
• Eclipse - IDE written in Java with an extensible plug-in system. (Source Code) EPL-1.0 Java
• Geany - GTK2 text editor. (Source Code) GPL-2.0 C/C++
• GNU Emacs - An extensible, customizable text editor-and more. (Source Code) GPL-3.0 C
• Haroopad - Markdown editor with live preview. (Source Code) GPL-3.0 JavaScript
• jotgit - Git-backed real-time collaborative code editing. MIT Nodejs
• KDevelop - IDE by the people behind KDE. (Source Code) GFDL-1.2 C++
• Micro - A modern and intuitive terminal-based text editor. (Source Code) MIT Go
• Nano - Easy to use, customizable text editor. (Source Code) GPL-3.0 C
• Notepad++ - GPLv2 multi-language editor with syntax highlighting for Windows. (Source Code) GPL-2.0 C++
• TextMate - A graphical text editor for OS X. (Source Code) GPL-3.0 C++
• Vim - A highly configurable text editor built to enable efficient editing. (Source Code) Vim C
• VSCodium - An open source cross-platform extensible code editor based on VS Code by Microsoft removing their non-free additions. (Source Code) MIT TypeScript

@ 6d5c826a:4b27b659

• Bind - Versatile, classic, complete name server software. (Source Code) MPL-2.0 C
• CoreDNS - Flexible DNS server. (Source Code) Apache-2.0 Go
• djbdns - A collection of DNS applications, including tinydns. (Source Code) CC0-1.0 C
• dnsmasq - Provides network infrastructure for small networks: DNS, DHCP, router advertisement and network boot. (Source Code) GPL-2.0 C
• Knot - High performance authoritative-only DNS server. (Source Code) GPL-3.0 C
• NSD - Authoritative DNS name server developed speed, reliability, stability and security. (Source Code) BSD-3-Clause C
• PowerDNS Authoritative Server - Versatile nameserver which supports a large number of backends. (Source Code) GPL-2.0 C++
• Unbound - Validating, recursive, and caching DNS resolver. (Source Code) BSD-3-Clause C
• Yadifa - Clean, small, light and RFC-compliant name server implementation developed from scratch by .eu. (Source Code) BSD-3-Clause C

@ 2efaa715:3d987331

More than you wanted to know about a little-understood but important aspect of diet and health, explained in a nontechnical manner, with oversimplifications abound.

Your cells need some kind of fuel to function. this fuel can only come (ultimately) from the outside world as food. AKA "diet". your blood carries the fuel to the cells so they can do their work. on most diets, the main fuel for cells is glucose, which the body derives from sugar or carbohydrates (which are basically sugar + some complexity). on other diets, the main fuel for cells is fat. on these diets, fat/lipid particles are carried on little blood ferries called lipoproteins (the final "L" in LDL and HDL). LDL carries lipids to your cells so they can use it, HDL carries unused lipids away from your cells (to the liver) so they can be disposed of. (on both very high carb and very low carb diets, your cells will still use some amount of both glucose and fat for energy, but the ratio will change dramatically).
Naturally, if you have a lot of these ferries in your blood (because you are using fat as cell-fuel), your LDL and HDL counts ("total cholesterol") will be high on basic blood tests.

LDL - the ferries that carry fats to your cells to burn - come in two varieties: - small + dense - large + fluffy
both carry fuel to your cells, but the small/dense ones have an unfortunate side-effect of slamming into artery walls, penetrating them, and accidentally depositing their lipids there. This is the "plaque" of cardiovascular disease fame. The large, fluffy particles do not penetrate the arterial walls as readily - they bounce off and keep going on to their destinations. their effect on arterial plaque is not zero, but far less impactful than small, dense particles.

In either case, the HDL particles are always good: they remove excess lipids from the body. this is why HDL is "the good cholesterol". There are advanced blood tests available which measure particle size (so, like, an acutally useful test), but odds are your doctor will refuse to order this test. Strange!

We didn't mention Triglycerides yet. Suffice it to say that more triglycerides = smaller, denser LDL particles = more arterial wall penetration = more cardiovascular risk. To finish off our triglycerides sidebar, the dietary patterns that increase triglycerides (bad!) are: excess calories from carbohydrates, added sugars and refined carbohydrates, low fiber intake, low omega-3 intake (especially in combination with excess seed oil intake), high trans fats consumption (more on trans fat in a moment).

Back to finish up cholesterol: this is why a diet that is high in good fats (again, more in a moment) will increase "total cholesterol" - you have more fat boats fueling your cells - but doesn't indicate greater cardiovascular risk: because the large, fluffy particles are not damaging your arteries and the large number of HDL particles are protective!
Furthermore, if you reconsider the sidebar on triglycerides you'll notice that avoiding refined carbohydrates and sugars has the added effect of lowering triglycerides, which keeps the LDL particles even healthier. You'll often see the simple recommendation to keep the HDL/Triglycerides ratio high. this is why. HDL good, triglycerides bad.

We didn't even get into insulin sensitivity - one of the most important factors in metabolic health... another time.

A last word on dietary fat types: Not all fats are created equally. You can look into monounsaturated and polyunsaturated on your own, but I want to mention two others here: Trans fat and Saturated fat.
Trans fats mostly come from artificial sources, like processed vegetable or seed oils. most often found in ultra-processed, packaged foods. yuck. trans fat lowers HDL, increases inflammation and increases proportion of small, dense LDL particles. These are all the bad things we discussed above.
Saturated fat is mainly found in meat, dairy and coconut oil. It increases LDL particle size and raises HDL. These are the good things we discussed above.
So, yes, while someone's total cholesterol may go up when eating saturated fats, it doesn't necessarily mean their cardiovascular risk has increased.

Now that you understand how cholesterol works, compare moderate saturated fat intake to eating a diet full of refined carbohydrates, sugars, processed vegetable/seed oils, and all the other items we explained above...

Ok really now, the last last word: the "cholesterol" you see on a food label has less impact on blood cholesterol than you thought. the details are too squirrely to go into here, but the takeway is: the fat content discussed above is the lion's share of the impact, with the number you see next to "cholesterol" on your food label having a negligible effect.

diet #paleo #keto #health #healthstr #foodstr #carnivore #cholesterol

@ 8cb60e21:5f2deaea

@ 8cb60e21:5f2deaea

```js import { useState, useEffect } from 'react'; import { useQuery } from '@tanstack/react-query'; import { useNDKContext } from '@/context/NDKContext'; import { useContentIdsQuery } from '@/hooks/apiQueries/useContentIdsQuery';

const AUTHOR_PUBKEY = process.env.NEXT_PUBLIC_AUTHOR_PUBKEY

export function useResourcesQuery() { const [isClient, setIsClient] = useState(false);

// const { contentIds, contentIdsLoading, contentIdsError, refetchContentIds } = useContentIdsQuery(); const ndk = useNDKContext();

useEffect(() => { setIsClient(true); }, []);

// useEffect(() => { // refetchContentIds(); // }, [refetchContentIds]);

const hasRequiredProperties = (event) => { // if (!contentIds) { // return false; // }

const hasPlebDevs = event.tags.some(([tag, value]) => tag === "t" && value === "plebdevs");
const hasWorkshop = event.tags.some(([tag, value]) => tag === "t" && value === "resource");
// const hasId = contentIds.includes(event.id);
// return hasPlebDevs && hasWorkshop && hasId;
return hasPlebDevs && hasWorkshop;

};

const fetchResourcesFromNDK = async () => { try { // if (contentIdsLoading) { // return []; // or a loading state indication // } // if (contentIdsError) { // console.error('Error fetching content IDs:', contentIdsError); // return []; // } // if (!contentIds) { // return []; // } console.log('Fetching workshops from NDK'); await ndk.connect();

  const filter = { kinds: [30023, 30402], authors: [AUTHOR_PUBKEY] };
  const events = await ndk.fetchEvents(filter);

  if (events && events.size > 0) {
    const eventsArray = Array.from(events);
    console.log('eventsArray', eventsArray)
    const resources = eventsArray.filter(event => hasRequiredProperties(event));
    return resources;
  }
  return [];
} catch (error) {
  console.error('Error fetching workshops from NDK:', error);
  return [];
}

};

const { data: resources, isLoading: resourcesLoading, error: resourcesError, refetch: refetchResources } = useQuery({ queryKey: ['resources', isClient], queryFn: fetchResourcesFromNDK, // staleTime: 1000 * 60 * 30, // 30 minutes // refetchInterval: 1000 * 60 * 30, // 30 minutes enabled: isClient, })

return { resources, resourcesLoading, resourcesError, refetchResources } } ```

@ 8cb60e21:5f2deaea

@ 6d5c826a:4b27b659

• Atomia DNS - DNS management system. ISC Perl
• Designate - DNSaaS services for OpenStack. (Source Code) Apache-2.0 Python
• DNSControl - Synchronize your DNS to multiple providers from a simple DSL. (Source Code) MIT Go/Docker
• DomainMOD - Manage your domains and other internet assets in a central location. (Source Code) GPL-3.0 PHP
• nsupdate.info - Dynamic DNS service. (Demo, Source Code) BSD-3-Clause Python
• octoDNS - DNS as code - Tools for managing DNS across multiple providers. MIT Python
• Poweradmin - Web-based DNS control panel for PowerDNS server. (Source Code) GPL-3.0 PHP
• SPF Toolbox - Application to look up DNS records such as SPF, MX, Whois, and more. (Source Code) MIT PHP

@ 8cb60e21:5f2deaea

@ 8f69ac99:4f92f5fd

O recente vídeo do "Cor do Dinheiro", do Camilo Lourenço, na rubrica "Pé de Meia" é um exemplo claro de como a desinformação e uma compreensão superficial continuam a prejudicar as discussões públicas sobre Bitcoin. Os convidados, Francisco Louro e Antonio Mello Campello, regurgitaram argumentos ultrapassados e falaciosos com uma confiança que faria Dunning e Kruger sentirem orgulho. Desde descartar Bitcoin como mera especulação até confundi-lo com moedas meme e actividades criminosas, as suas alegações destacam não apenas a ignorância, mas também a sua recusa em compreender objectivamente esta tecnologia revolucionária. Este artigo visa desmontar algumas das suas afirmações, expondo as suas perspectivas superficiais enquanto apresenta Bitcoin como a inovação transformadora que realmente é.

---

Nem vou comentar a historia da blockchain, ja escrevi sobre isso num outro artigo que podem encontrar aqui.

Bitcoin: É Apenas Especulação?

Antonio Mello Campello começa com o argumento ultrapassado de que Bitcoin é puramente especulativo, desprovido de "valor real". Este argumento é risível, considerando a adopção de Bitcoin por nações como El Salvador e empresas como a MicroStrategy. Se Bitcoin fosse apenas especulativo, por que entidades bilionárias e governos o integrariam nas suas estratégias financeiras?

A sua ignorância torna-se ainda mais evidente na incapacidade de compreender que todas as tecnologias revolucionárias enfrentam cepticismo inicial. A internet já foi vista como uma curiosidade de nicho que desapareceria como o fax, e aqui estamos, usando-a para espalhar opiniões mal informadas sobre Bitcoin. A incapacidade do convidado, e devo dizer do apresentador também, de reconhecer este paralelo revela a sua falta de perspectiva histórica e tecnológica.

---

O Valor de Bitcoin: O Mito do Valor Intrínsecos

“Bitcoin não tem valor intrínseco porque não gera dividendos ou retornos,” afirmam. Por esta lógica, o ouro, que também não gera dividendos, deve ser igualmente sem valor. A verdade é que o valor de Bitcoin reside nas suas propriedades: escassez, descentralização e segurança. Com um limite de fornecimento de 21 milhões e um registo inviolável, Bitcoin oferece um nível de transparência e fiabilidade incomparável a qualquer moeda fiduciária.

A afirmação também ignora o uso de Bitcoin como protecção contra a inflação e instabilidade económica. Ao contrário do euro, que o Banco Central Europeu inflacionou até à exaustão, Bitcoin oferece previsibilidade e independência face a políticas monetárias irresponsáveis. A compreensão superficial dos apresentadores demonstra a sua incapacidade de valorizar como as propriedades únicas de Bitcoin desafiam o status quo dominado pelas moedas fiduciárias.

---

Confundir Bitcoin com Memecoins

Equiparar o Bitcoin ao Dogecoin não é apenas ignorância; é absolutamente ridículo. Enquanto a Dogecoin prospera em memes e tweets de Musk, Bitcoin é um sistema monetário robusto construído com mais de uma década de descentralização, segurança e adopção global. Esta equivalência falsa mina qualquer credibilidade que os participantes do vídeo poderiam esperar manter.

Dogecoin carece da escassez, segurança e descentralização que tornam Bitcoin revolucionário. Comparar os dois é como comparar um carro de luxo a um carrinho de pedais infantil. Um é projectado para utilidade no mundo real; o outro é uma brincadeira passageira.

---

Volatilidade: Uma Característica, Não Um Problema

Outra crítica ultrapassada: a volatilidade de Bitcoin. Sim, o preço da bitcoin oscila, mas o mesmo aconteceu com as acções e mesmo o ouro nos seus primeiros dias. A volatilidade é uma fase natural de uma classe de activos emergente. Apesar disso, a bitcoin tem proporcionado retornos de longo prazo incomparáveis, recompensando aqueles que compreendem o seu potencial e permanecem pacientes.

A ironia é gritante: enquanto desconsideram Bitcoin pela sua volatilidade, falham em mencionar a lenta erosão de valor do euro ou os crashes periódicos dos mercados de acções. A volatilidade de Bitcoin é o preço da inovação, e, à medida que a adopção cresce, a estabilidade seguir-lhe-á. A incapacidade dos participantes de reconhecer esta dinâmica demonstra o seu pensamento de curto prazo e a falta de visão do panorama maior.

---

A Narrativa do Crime: Um Argumento Preguiçoso

Afirmar que Bitcoin é principalmente usado para actividades criminosas, ou teóricos da conspiração, é talvez o argumento mais preguiçoso de todos. Dados mostram consistentemente que transacções ilícitas representam menos de 1% do uso total de bitcoin. Enquanto isso, o dinheiro em espécie, cash, continua a ser a ferramenta preferida dos criminosos em todo o mundo. Devemos banir euros e dólares também?

Ironicamente, a transparência de Bitcoin torna-se uma péssima escolha para criminosos. Ferramentas de análise de blockchain tornaram-se inestimáveis para as autoridades, permitindo-lhes rastrear e capturar infractores. A incapacidade dos participantes de reconhecer este facto reflecte ignorância deliberada ou preguiça intelectual — ou talvez ambos.

---

Aplicações Práticas: Reduzindo a Desigualdade Financeira

“Bitcoin não tem casos de uso no mundo real,” dizem eles, ignorando os milhões que dependem dele para remessas, inclusão financeira e protecção contra hiperinflação. Iniciativas como a Praia Bitcoin no Brasil e o Bitcoin Ekasi na África do Sul, entre muitos outros, mostram como Bitcoin capacita comunidades ignoradas pelos sistemas financeiros tradicionais.

Ao permitir transacções baratas, rápidas e sem fronteiras, Bitcoin resolve problemas reais para pessoas reais. Descartar esses casos de uso como triviais não é apenas ignorância, mas também um exemplo gritante de privilégio financeiro. A incapacidade dos comentadores de reconhecer isso destaca o quão desconectados estão dos desafios enfrentados por aqueles fora de suas bolhas confortáveis.

---

Bitcoin vs. Activos Tradicionais: Uma Falsa Dicotomia

Os convidados argumentam que activos tradicionais, como acções e imobiliário, são investimentos superiores. Isto perde totalmente o ponto. Bitcoin não é (apenas?) um investimento; é um novo paradigma monetário. A sua portabilidade, divisibilidade e resistência à censura fazem dele um activo único, complementar aos investimentos tradicionais.

Imobiliário, ou terreno, podem ser confiscados, ou sujeitos a depreciação por factores ambientais ou sociais, e acções estão sujeitas a má gestão corporativa. Bitcoin, em contrapartida, é inalienável e opera independentemente de erros humanos. A incapacidade dos participantes de compreender esta diferença fundamental fala muito sobre a sua compreensão limitada do potencial transformador de Bitcoin.

---

O Limite de Fornecimento: Um "Gimmick" que Redefine o Dinheiro

Descrever o limite de fornecimento de 21 milhões de bitcoin como um "truque" é tanto desinformado quanto risível. A escassez sempre impulsionou o valor, como visto com o ouro, ou autocolantes do CR7. O fornecimento fixo de Bitcoin garante que ele não pode ser desvalorizado por políticas monetárias arbitrárias — uma característica, não uma falha.

Enquanto bancos centrais inundam economias com moeda fiduciária, erodindo o poder de compra das pessoas, a previsibilidade de Bitcoin oferece um porto seguro. A rejeição desta característica crítica pelos participantes revela uma falta de literacia económica e uma recusa em compreender os princípios fundamentais de Bitcoin.

---

Independência dos Bancos Centrais: A Proposta de Bitcoin

A noção de que a falta de apoio dos bancos centrais enfraquece Bitcoin é ridícula. Bancos centrais, com o seu histórico de políticas inflacionárias e crises financeiras, estão longe de serem exemplos de confiabilidade. A independência de Bitcoin protege-o de manipulações e garante a sua integridade. Essa é, alias, a grande proposta de valor de Bitcoin, inscrita no bloco genesis!

O argumento dos participantes reflecte um apego profundo a sistemas tradicionais que repetidamente falharam mas, do qual provavelmente beneficiam. A transparência, previsibilidade e descentralização de Bitcoin fazem deste activo uma alternativa superior, expondo as suas críticas como infundadas.

---

Conclusão: Ignorância Não é Argumento

O programa falha redondamente a premissa inicial com que o Camilo Lourenço abre o video. Reduzir a ignorância sobre Bitcoin. Os participantes do vídeo demonstraram uma falta chocante de compreensão sobre o assunto, repetindo argumentos ultrapassados e comparações falaciosas sem se darem ao trabalho de debater criticamente com o tema. O seu descarte de Bitcoin como especulativo, volátil e criminoso ignora evidências esmagadoras da sua utilidade, resiliência e potencial transformador.

Bitcoin representa uma mudança de paradigma em como pensamos sobre dinheiro, valor e inclusão financeira. É hora de os críticos irem além de argumentos superficiais e reaccionários e inteirarem-se com Bitcoin pelos seus méritos. Até lá, as suas críticas não passam de ecos de ignorância perante a inovação e alvo de chacota na comunidade.

Admiro bastante o Camilo Lourenço e o seu trabalho mas, desta vez, não esteve bem. Não só não houve contraditório como os convidados não entregaram aquilo que foi prometido no inicio do video.

@ 6d5c826a:4b27b659

• Ceph - Distributed object, block, and file storage platform. (Source Code) LGPL-3.0 C++
• DRBD - Distributed replicated storage system, implemented as a Linux kernel driver. (Source Code) GPL-2.0 C
• GlusterFS - Software-defined distributed storage that can scale to several petabytes, with interfaces for object, block and file storage. (Source Code) GPL-2.0/LGPL-3.0 C
• Hadoop Distributed Filesystem (HDFS) - Distributed file system that provides high-throughput access to application data. (Source Code) Apache-2.0 Java
• JuiceFS - Distributed POSIX file system built on top of Redis and S3. (Source Code) Apache-2.0 Go
• Kubo - Implementation of IPFS, a global, versioned, peer-to-peer filesystem that seeks to connect all computing devices with the same system of files. Apache-2.0/MIT Go
• LeoFS - Highly available, distributed, replicated eventually consistent object/blob store. (Source Code) Apache-2.0 Erlang
• Lustre - Parallel distributed file system, generally used for large-scale cluster computing. (Source Code) GPL-2.0 C
• Minio - High-performance, S3 compatible object store built for large scale AI/ML, data lake and database workloads. (Source Code) AGPL-3.0 Go
• MooseFS - Fault tolerant, network distributed file system. (Source Code) GPL-2.0 C
• OpenAFS - Distributed network file system with read-only replicas and multi-OS support. (Source Code) IPL-1.0 C
• Openstack Swift - A highly available, distributed, eventually consistent object/blob store. (Source Code) Apache-2.0 Python
• Perkeep - A set of open source formats, protocols, and software for modeling, storing, searching, sharing and synchronizing data (previously Camlistore). (Source Code) Apache-2.0 C
• TahoeLAFS - Secure, decentralized, fault-tolerant, peer-to-peer distributed data store and distributed file system. (Source Code) GPL-2.0 Python
• XtreemFS - Distributed, replicated and fault-tolerant file system for federated IT infrastructures.. (Source Code) BSD-3-Clause Java

@ 8f69ac99:4f92f5fd

A conversa global sobre Bitcoin entrou numa nova fase, saindo do campo da especulação para o centro das decisões estratégicas. A proposta do Presidente-eleito Donald Trump para criar uma reserva nacional de Bitcoin, a votação iminente dos acionistas da Microsoft sobre Bitcoin como investimento corporativo e a análise da Amazon para usar Bitcoin como activo de reserva mostram como a teoria dos jogos está a influenciar decisões reais.

No centro destas iniciativas está o conceito de vantagem do first-mover. Os primeiros a agir — sejam empresas ou nações — têm a oportunidade de colher benefícios desproporcionais, desde domínio financeiro até influência global. No entanto, essas acções obrigam os concorrentes a reagir, criando um efeito dominó em várias indústrias e fronteiras. Com apenas ~1.206.000 bitcoins restantes para serem minerados, a corrida começou, e os stakes não poderiam ser mais altos.

A Reserva de Bitcoin de Trump: Uma Estratégia de Estado-Nação

Em julho de 2024, Donald Trump surpreendeu o mundo financeiro ao anunciar planos para estabelecer uma reserva nacional de Bitcoin. Em novembro, mais detalhes foram revelados no projecto de lei proposto pela senadora Cynthia Lummis, “Bitcoin Act of 2024,” que prevê a aquisição de um milhão de bitcoins ao longo de cinco anos, financiada pela realocação de activos do Federal Reserve, evitando aumento da dívida pública.

O plano não é apenas uma protecção contra a inflação; é uma jogada geopolítica. Tornando-se a primeira potência a adoptar Bitcoin nesta escala, os EUA buscam consolidar a sua liderança na economia global em transformação. Esta medida obriga outras nações, como China ou Rússia — que já estão a discutir também integrar Bitcoin nas suas economias — a repensarem as suas estratégias.

A proposta de Trump introduz uma dinâmica de jogo de soma zero. Se os EUA acumularem uma reserva significativa enquanto outras nações ficam para trás, o país ganha soberania financeira, maior influência global e o poder de moldar o futuro. Contudo, essa acção pode desencadear uma corrida global, com países a competir para garantir o máximo de Bitcoin possível antes que sua oferta finita se esgote.

A Proposta de Bitcoin da Microsoft: Pressão sobre Gigantes Corporativos

Em outubro de 2024, os acionistas da Microsoft receberam uma proposta solicitando que a empresa explorasse Bitcoin como investimento corporativo. Com a votação marcada para 10 de dezembro, a decisão terá um impacto que ultrapassa a própria Microsoft. Uma votação a favor pode desencadear uma reacção em cadeia entre outras gigantes tecnológicas, enquanto uma recusa pode abrir espaço para que empresas como Google ou Apple se posicionem como líderes no sector.

Nota: a votacao foi negativa, apenas 0.55% dos accionistas da Microsoft votaram a favor! Caso para dizer que a Microsoft teve um momento Kodak! #HFSP

Michael Saylor, presidente executivo da MicroStrategy, tem estado na linha da frente, defendendo a adopção corporativa de Bitcoin, apresentando-o não apenas como um activo financeiro, mas como uma oportunidade transformadora. A administração da Microsoft recomendou a rejeição da proposta, citando processos de investimento já existentes. No entanto, a pressão está a aumentar. O desempenho impressionante de Bitcoin, com ganhos anuais de 131% e um preço recorde acima de $104.000, torna cada vez mais difícil para as empresas ignorarem a oportunidade.

Para a Microsoft, os stakes são claros: agir cedo permitiria que a empresa se posicionasse como líder na integração de Bitcoin na estratégia corporativa, pressionando concorrentes como Google, Apple e Meta a fazerem o mesmo ou arriscarem ficar para trás. Uma entrada tardia, por outro lado, pode resultar em custos mais elevados e oportunidades perdidas, à medida que o preço de Bitcoin continua a subir com a crescente procura institucional.

A Aposta da Amazon em Bitcoin

A Amazon, a maior retalhista online do mundo, está agora numa encruzilhada. No dia 8 de dezembro de 2024, a empresa recebeu uma proposta dos accionistas para alocar 5% das suas reservas de $88 mil milhões em Bitcoin. Este movimento acompanha uma tendência crescente de interesse institucional, com fundos negociados em bolsa de Bitcoin a atraírem milhares de milhões de dólares em entradas na última semana.

Se a Amazon aprovar a proposta na Assembleia Geral Anual de 2025, o impacto será sísmico. A decisão da empresa enviará um sinal claro ao mercado, validando Bitcoin como um activo de reserva legítimo. Além disso, colocará uma pressão significativa sobre rivais como Walmart, Google e Alibaba para seguirem o exemplo. À medida que mais empresas entram no mercado, a oferta finita de Bitcoin será ainda mais pressionada, elevando seu preço e recompensando aqueles que agiram primeiro.

A possível adopção de Bitcoin pela Amazon também reforça a ideia do efeito de sinalização na teoria dos jogos. Ao abraçar Bitcoin, a Amazon demonstraria confiança no futuro do activo, incentivando outros participantes do mercado a fazerem o mesmo. A decisão provavelmente aceleraria um efeito dominó em várias indústrias, dificultando cada vez mais para os concorrentes permanecerem inertes.

Efeito Dominó

As movimentações estratégicas de Trump, Microsoft e Amazon não existem isoladamente — são catalisadores de uma corrida mais ampla. El Salvador e Butão já se posicionaram como adoptantes iniciais, mas a proposta de Trump eleva a adopção de Bitcoin a um novo patamar. Se os EUA agirem de forma decisiva, é provável que aliados e concorrentes façam o mesmo, desencadeando uma corrida por reservas de Bitcoin que poderá assemelhar-se a uma corrida armamentista em intensidade. Como já se começa a ver no Canada, Rússia, Alemanha, etc...

O mesmo se aplica às corporações. À medida que líderes como MicroStrategy, Tesla e, potencialmente, Microsoft e Amazon tomam posições, os concorrentes enfrentarão uma pressão crescente para agir ou arriscar a irrelevância. Cada novo participante no mercado reduz a oferta disponível de Bitcoin, criando uma urgência crescente para os retardatários.

Os números reforçam a aposta: apenas ~1.206.000 bitcoins permanecem para serem minerados e apenas cerca de 2.000.000 em exchanges. Com a adopção institucional e nacional a acelerar, a luta por este recurso limitado provavelmente impulsionará ainda mais os preços, transformando Bitcoin de um "activo especulativo" para um imperativo estratégico.

Conclusão: O Jogo de Bitcoin Está em Curso

A dinâmica de adopção de Bitcoin ilustra a teoria dos jogos em acção que podemos observar em tempo real. A vantagem dos pioneiros não é apenas um conceito teórico — é uma vantagem tangível na corrida por Bitcoin, oferecendo recompensas desproporcionais aos primeiros a agir e forçando outros a reagirem. A proposta de Trump para uma reserva nacional de Bitcoin define o palco para uma corrida geopolítica, enquanto gigantes corporativos como Microsoft e Amazon enfrentam decisões que moldarão os seus futuros e pondo pressão nos seus concorrentes.

À medida que a oferta de Bitcoin diminui e o seu preço reflecte a crescente procura, a pressão para agir cedo só aumentará. Seja no palco nacional ou corporativo, as decisões tomadas hoje definirão o panorama económico de amanhã. O jogo de Bitcoin está em curso, e os jogadores que compreendem os riscos — e agem estrategicamente — têm o potencial de moldar a próxima era das finanças globais.

bitcoin #gameTheory