@ 52b4a076:e7fad8bd

I have been recently building NFDB, a new relay DB. This post is meant as a short overview.

Regular relays have challenges

Current relay software have significant challenges, which I have experienced when hosting Nostr.land: - Scalability is only supported by adding full replicas, which does not scale to large relays. - Most relays use slow databases and are not optimized for large scale usage. - Search is near-impossible to implement on standard relays. - Privacy features such as NIP-42 are lacking. - Regular DB maintenance tasks on normal relays require extended downtime. - Fault-tolerance is implemented, if any, using a load balancer, which is limited. - Personalization and advanced filtering is not possible. - Local caching is not supported.

NFDB: A scalable database for large relays

NFDB is a new database meant for medium-large scale relays, built on FoundationDB that provides: - Near-unlimited scalability - Extended fault tolerance - Instant loading - Better search - Better personalization - and more.

Search

NFDB has extended search capabilities including: - Semantic search: Search for meaning, not words. - Interest-based search: Highlight content you care about. - Multi-faceted queries: Easily filter by topic, author group, keywords, and more at the same time. - Wide support for event kinds, including users, articles, etc.

Personalization

NFDB allows significant personalization: - Customized algorithms: Be your own algorithm. - Spam filtering: Filter content to your WoT, and use advanced spam filters. - Topic mutes: Mute topics, not keywords. - Media filtering: With Nostr.build, you will be able to filter NSFW and other content - Low data mode: Block notes that use high amounts of cellular data. - and more

Other

NFDB has support for many other features such as: - NIP-42: Protect your privacy with private drafts and DMs - Microrelays: Easily deploy your own personal microrelay - Containers: Dedicated, fast storage for discoverability events such as relay lists

Calcite: A local microrelay database

Calcite is a lightweight, local version of NFDB that is meant for microrelays and caching, meant for thousands of personal microrelays.

Calcite HA is an additional layer that allows live migration and relay failover in under 30 seconds, providing higher availability compared to current relays with greater simplicity. Calcite HA is enabled in all Calcite deployments.

For zero-downtime, NFDB is recommended.

Noswhere SmartCache

Relays are fixed in one location, but users can be anywhere.

Noswhere SmartCache is a CDN for relays that dynamically caches data on edge servers closest to you, allowing: - Multiple regions around the world - Improved throughput and performance - Faster loading times

routerd

routerd is a custom load-balancer optimized for Nostr relays, integrated with SmartCache.

routerd is specifically integrated with NFDB and Calcite HA to provide fast failover and high performance.

Ending notes

NFDB is planned to be deployed to Nostr.land in the coming weeks.

A lot more is to come. 👀️️️️️️

@ a39d19ec:3d88f61e

Die Debatte um Migration, Grenzsicherung und Abschiebungen wird in Deutschland meist emotional geführt. Wer fordert, dass illegale Einwanderer abgeschoben werden, sieht sich nicht selten dem Vorwurf des Rassismus ausgesetzt. Doch dieser Vorwurf ist nicht nur sachlich unbegründet, sondern verkehrt die Realität ins Gegenteil: Tatsächlich sind es gerade diejenigen, die hinter jeder Forderung nach Rechtssicherheit eine rassistische Motivation vermuten, die selbst in erster Linie nach Hautfarbe, Herkunft oder Nationalität urteilen.

Das Recht steht über Emotionen

Deutschland ist ein Rechtsstaat. Das bedeutet, dass Regeln nicht nach Bauchgefühl oder politischer Stimmungslage ausgelegt werden können, sondern auf klaren gesetzlichen Grundlagen beruhen müssen. Einer dieser Grundsätze ist in Artikel 16a des Grundgesetzes verankert. Dort heißt es:

„Auf Absatz 1 [Asylrecht] kann sich nicht berufen, wer aus einem Mitgliedstaat der Europäischen Gemeinschaften oder aus einem anderen Drittstaat einreist, in dem die Anwendung des Abkommens über die Rechtsstellung der Flüchtlinge und der Europäischen Menschenrechtskonvention sichergestellt ist.“

Das bedeutet, dass jeder, der über sichere Drittstaaten nach Deutschland einreist, keinen Anspruch auf Asyl hat. Wer dennoch bleibt, hält sich illegal im Land auf und unterliegt den geltenden Regelungen zur Rückführung. Die Forderung nach Abschiebungen ist daher nichts anderes als die Forderung nach der Einhaltung von Recht und Gesetz.

Die Umkehrung des Rassismusbegriffs

Wer einerseits behauptet, dass das deutsche Asyl- und Aufenthaltsrecht strikt durchgesetzt werden soll, und andererseits nicht nach Herkunft oder Hautfarbe unterscheidet, handelt wertneutral. Diejenigen jedoch, die in einer solchen Forderung nach Rechtsstaatlichkeit einen rassistischen Unterton sehen, projizieren ihre eigenen Denkmuster auf andere: Sie unterstellen, dass die Debatte ausschließlich entlang ethnischer, rassistischer oder nationaler Kriterien geführt wird – und genau das ist eine rassistische Denkweise.

Jemand, der illegale Einwanderung kritisiert, tut dies nicht, weil ihn die Herkunft der Menschen interessiert, sondern weil er den Rechtsstaat respektiert. Hingegen erkennt jemand, der hinter dieser Kritik Rassismus wittert, offenbar in erster Linie die „Rasse“ oder Herkunft der betreffenden Personen und reduziert sie darauf.

Finanzielle Belastung statt ideologischer Debatte

Neben der rechtlichen gibt es auch eine ökonomische Komponente. Der deutsche Wohlfahrtsstaat basiert auf einem Solidarprinzip: Die Bürger zahlen in das System ein, um sich gegenseitig in schwierigen Zeiten zu unterstützen. Dieser Wohlstand wurde über Generationen hinweg von denjenigen erarbeitet, die hier seit langem leben. Die Priorität liegt daher darauf, die vorhandenen Mittel zuerst unter denjenigen zu verteilen, die durch Steuern, Sozialabgaben und Arbeit zum Erhalt dieses Systems beitragen – nicht unter denen, die sich durch illegale Einreise und fehlende wirtschaftliche Eigenleistung in das System begeben.

Das ist keine ideologische Frage, sondern eine rein wirtschaftliche Abwägung. Ein Sozialsystem kann nur dann nachhaltig funktionieren, wenn es nicht unbegrenzt belastet wird. Würde Deutschland keine klaren Regeln zur Einwanderung und Abschiebung haben, würde dies unweigerlich zur Überlastung des Sozialstaates führen – mit negativen Konsequenzen für alle.

Sozialpatriotismus

Ein weiterer wichtiger Aspekt ist der Schutz der Arbeitsleistung jener Generationen, die Deutschland nach dem Zweiten Weltkrieg mühsam wieder aufgebaut haben. Während oft betont wird, dass die Deutschen moralisch kein Erbe aus der Zeit vor 1945 beanspruchen dürfen – außer der Verantwortung für den Holocaust –, ist es umso bedeutsamer, das neue Erbe nach 1945 zu respektieren, das auf Fleiß, Disziplin und harter Arbeit beruht. Der Wiederaufbau war eine kollektive Leistung deutscher Menschen, deren Früchte nicht bedenkenlos verteilt werden dürfen, sondern vorrangig denjenigen zugutekommen sollten, die dieses Fundament mitgeschaffen oder es über Generationen mitgetragen haben.

Rechtstaatlichkeit ist nicht verhandelbar

Wer sich für eine konsequente Abschiebepraxis ausspricht, tut dies nicht aus rassistischen Motiven, sondern aus Respekt vor der Rechtsstaatlichkeit und den wirtschaftlichen Grundlagen des Landes. Der Vorwurf des Rassismus in diesem Kontext ist daher nicht nur falsch, sondern entlarvt eine selektive Wahrnehmung nach rassistischen Merkmalen bei denjenigen, die ihn erheben.

@ e3ba5e1a:5e433365

Prelude

I wrote this post differently than any of my others. It started with a discussion with AI on an OPSec-inspired review of separation of powers, and evolved into quite an exciting debate! I asked Grok to write up a summary in my overall writing style, which it got pretty well. I've decided to post it exactly as-is. Ultimately, I think there are two solid ideas driving my stance here:

1. Perfect is the enemy of the good
2. Failure is the crucible of success

Beyond that, just some hard-core belief in freedom, separation of powers, and operating from self-interest.

Intro

Alright, buckle up. I’ve been chewing on this idea for a while, and it’s time to spit it out. Let’s look at the U.S. government like I’d look at a codebase under a cybersecurity audit—OPSEC style, no fluff. Forget the endless debates about what politicians should do. That’s noise. I want to talk about what they can do, the raw powers baked into the system, and why we should stop pretending those powers are sacred. If there’s a hole, either patch it or exploit it. No half-measures. And yeah, I’m okay if the whole thing crashes a bit—failure’s a feature, not a bug.

The Filibuster: A Security Rule with No Teeth

You ever see a firewall rule that’s more theater than protection? That’s the Senate filibuster. Everyone acts like it’s this untouchable guardian of democracy, but here’s the deal: a simple majority can torch it any day. It’s not a law; it’s a Senate preference, like choosing tabs over spaces. When people call killing it the “nuclear option,” I roll my eyes. Nuclear? It’s a button labeled “press me.” If a party wants it gone, they’ll do it. So why the dance?

I say stop playing games. Get rid of the filibuster. If you’re one of those folks who thinks it’s the only thing saving us from tyranny, fine—push for a constitutional amendment to lock it in. That’s a real patch, not a Post-it note. Until then, it’s just a vulnerability begging to be exploited. Every time a party threatens to nuke it, they’re admitting it’s not essential. So let’s stop pretending and move on.

Supreme Court Packing: Because Nine’s Just a Number

Here’s another fun one: the Supreme Court. Nine justices, right? Sounds official. Except it’s not. The Constitution doesn’t say nine—it’s silent on the number. Congress could pass a law tomorrow to make it 15, 20, or 42 (hitchhiker’s reference, anyone?). Packing the court is always on the table, and both sides know it. It’s like a root exploit just sitting there, waiting for someone to log in.

So why not call the bluff? If you’re in power—say, Trump’s back in the game—say, “I’m packing the court unless we amend the Constitution to fix it at nine.” Force the issue. No more shadowboxing. And honestly? The court’s got way too much power anyway. It’s not supposed to be a super-legislature, but here we are, with justices’ ideologies driving the bus. That’s a bug, not a feature. If the court weren’t such a kingmaker, packing it wouldn’t even matter. Maybe we should be talking about clipping its wings instead of just its size.

The Executive Should Go Full Klingon

Let’s talk presidents. I’m not saying they should wear Klingon armor and start shouting “Qapla’!”—though, let’s be real, that’d be awesome. I’m saying the executive should use every scrap of power the Constitution hands them. Enforce the laws you agree with, sideline the ones you don’t. If Congress doesn’t like it, they’ve got tools: pass new laws, override vetoes, or—here’s the big one—cut the budget. That’s not chaos; that’s the system working as designed.

Right now, the real problem isn’t the president overreaching; it’s the bureaucracy. It’s like a daemon running in the background, eating CPU and ignoring the user. The president’s supposed to be the one steering, but the administrative state’s got its own agenda. Let the executive flex, push the limits, and force Congress to check it. Norms? Pfft. The Constitution’s the spec sheet—stick to it.

Let the System Crash

Here’s where I get a little spicy: I’m totally fine if the government grinds to a halt. Deadlock isn’t a disaster; it’s a feature. If the branches can’t agree, let the president veto, let Congress starve the budget, let enforcement stall. Don’t tell me about “essential services.” Nothing’s so critical it can’t take a breather. Shutdowns force everyone to the table—debate, compromise, or expose who’s dropping the ball. If the public loses trust? Good. They’ll vote out the clowns or live with the circus they elected.

Think of it like a server crash. Sometimes you need a hard reboot to clear the cruft. If voters keep picking the same bad admins, well, the country gets what it deserves. Failure’s the best teacher—way better than limping along on autopilot.

States Are the Real MVPs

If the feds fumble, states step up. Right now, states act like junior devs waiting for the lead engineer to sign off. Why? Federal money. It’s a leash, and it’s tight. Cut that cash, and states will remember they’re autonomous. Some will shine, others will tank—looking at you, California. And I’m okay with that. Let people flee to better-run states. No bailouts, no excuses. States are like competing startups: the good ones thrive, the bad ones pivot or die.

Could it get uneven? Sure. Some states might turn into sci-fi utopias while others look like a post-apocalyptic vidya game. That’s the point—competition sorts it out. Citizens can move, markets adjust, and failure’s a signal to fix your act.

Chaos Isn’t the Enemy

Yeah, this sounds messy. States ignoring federal law, external threats poking at our seams, maybe even a constitutional crisis. I’m not scared. The Supreme Court’s there to referee interstate fights, and Congress sets the rules for state-to-state play. But if it all falls apart? Still cool. States can sort it without a babysitter—it’ll be ugly, but freedom’s worth it. External enemies? They’ll either unify us or break us. If we can’t rally, we don’t deserve the win.

Centralizing power to avoid this is like rewriting your app in a single thread to prevent race conditions—sure, it’s simpler, but you’re begging for a deadlock. Decentralized chaos lets states experiment, lets people escape, lets markets breathe. States competing to cut regulations to attract businesses? That’s a race to the bottom for red tape, but a race to the top for innovation—workers might gripe, but they’ll push back, and the tension’s healthy. Bring it—let the cage match play out. The Constitution’s checks are enough if we stop coddling the system.

Why This Matters

I’m not pitching a utopia. I’m pitching a stress test. The U.S. isn’t a fragile porcelain doll; it’s a rugged piece of hardware built to take some hits. Let it fail a little—filibuster, court, feds, whatever. Patch the holes with amendments if you want, or lean into the grind. Either way, stop fearing the crash. It’s how we debug the republic.

So, what’s your take? Ready to let the system rumble, or got a better way to secure the code? Hit me up—I’m all ears.

@ c4b5369a:b812dbd6

Offline transactions with Cashu

Over the past few weeks, I've been busy implementing offline capabilities into nutstash. I think this is one of the key value propositions of ecash, beinga a bearer instrument that can be used without internet access. It does however come with limitations, which can lead to a bit of confusion. I hope this article will clear some of these questions up for you!

What is ecash/Cashu?

Ecash is the first cryptocurrency ever invented. It was created by David Chaum in 1983. It uses a blind signature scheme, which allows users to prove ownership of a token without revealing a link to its origin. These tokens are what we call ecash. They are bearer instruments, meaning that anyone who possesses a copy of them, is considered the owner.

Cashu is an implementation of ecash, built to tightly interact with Bitcoin, more specifically the Bitcoin lightning network. In the Cashu ecosystem, Mints are the gateway to the lightning network. They provide the infrastructure to access the lightning network, pay invoices and receive payments. Instead of relying on a traditional ledger scheme like other custodians do, the mint issues ecash tokens, to represent the value held by the users.

How do normal Cashu transactions work?

A Cashu transaction happens when the sender gives a copy of his ecash token to the receiver. This can happen by any means imaginable. You could send the token through email, messenger, or even by pidgeon. One of the common ways to transfer ecash is via QR code.

The transaction is however not finalized just yet! In order to make sure the sender cannot double-spend their copy of the token, the receiver must do what we call a swap. A swap is essentially exchanging an ecash token for a new one at the mint, invalidating the old token in the process. This ensures that the sender can no longer use the same token to spend elsewhere, and the value has been transferred to the receiver.

What about offline transactions?

Sending offline

Sending offline is very simple. The ecash tokens are stored on your device. Thus, no internet connection is required to access them. You can litteraly just take them, and give them to someone. The most convenient way is usually through a local transmission protocol, like NFC, QR code, Bluetooth, etc.

The one thing to consider when sending offline is that ecash tokens come in form of "coins" or "notes". The technical term we use in Cashu is Proof. It "proofs" to the mint that you own a certain amount of value. Since these proofs have a fixed value attached to them, much like UTXOs in Bitcoin do, you would need proofs with a value that matches what you want to send. You can mix and match multiple proofs together to create a token that matches the amount you want to send. But, if you don't have proofs that match the amount, you would need to go online and swap for the needed proofs at the mint.

Another limitation is, that you cannot create custom proofs offline. For example, if you would want to lock the ecash to a certain pubkey, or add a timelock to the proof, you would need to go online and create a new custom proof at the mint.

Receiving offline

You might think: well, if I trust the sender, I don't need to be swapping the token right away!

You're absolutely correct. If you trust the sender, you can simply accept their ecash token without needing to swap it immediately.

This is already really useful, since it gives you a way to receive a payment from a friend or close aquaintance without having to worry about connectivity. It's almost just like physical cash!

It does however not work if the sender is untrusted. We have to use a different scheme to be able to receive payments from someone we don't trust.

Receiving offline from an untrusted sender

To be able to receive payments from an untrusted sender, we need the sender to create a custom proof for us. As we've seen before, this requires the sender to go online.

The sender needs to create a token that has the following properties, so that the receciver can verify it offline:

• It must be locked to ONLY the receiver's public key
• It must include an offline signature proof (DLEQ proof)
• If it contains a timelock & refund clause, it must be set to a time in the future that is acceptable for the receiver
• It cannot contain duplicate proofs (double-spend)
• It cannot contain proofs that the receiver has already received before (double-spend)

If all of these conditions are met, then the receiver can verify the proof offline and accept the payment. This allows us to receive payments from anyone, even if we don't trust them.

At first glance, this scheme seems kinda useless. It requires the sender to go online, which defeats the purpose of having an offline payment system.

I beleive there are a couple of ways this scheme might be useful nonetheless:

1. Offline vending machines: Imagine you have an offline vending machine that accepts payments from anyone. The vending machine could use this scheme to verify payments without needing to go online itself. We can assume that the sender is able to go online and create a valid token, but the receiver doesn't need to be online to verify it.

2. Offline marketplaces: Imagine you have an offline marketplace where buyers and sellers can trade goods and services. Before going to the marketplace the sender already knows where he will be spending the money. The sender could create a valid token before going to the marketplace, using the merchants public key as a lock, and adding a refund clause to redeem any unspent ecash after it expires. In this case, neither the sender nor the receiver needs to go online to complete the transaction.

How to use this

Pretty much all cashu wallets allow you to send tokens offline. This is because all that the wallet needs to do is to look if it can create the desired amount from the proofs stored locally. If yes, it will automatically create the token offline.

Receiving offline tokens is currently only supported by nutstash (experimental).

To create an offline receivable token, the sender needs to lock it to the receiver's public key. Currently there is no refund clause! So be careful that you don't get accidentally locked out of your funds!

The receiver can then inspect the token and decide if it is safe to accept without a swap. If all checks are green, they can accept the token offline without trusting the sender.

The receiver will see the unswapped tokens on the wallet homescreen. They will need to manually swap them later when they are online again.

Later when the receiver is online again, they can swap the token for a fresh one.

Summary

We learned that offline transactions are possible with ecash, but there are some limitations. It either requires trusting the sender, or relying on either the sender or receiver to be online to verify the tokens, or create tokens that can be verified offline by the receiver.

I hope this short article was helpful in understanding how ecash works and its potential for offline transactions.

Cheers,

Gandlaf

@ 266815e0:6cd408a5

Its been a little over a year since NIP-90 was written and merged into the nips repo and its been a communication mess.

Every DVM implementation expects the inputs in slightly different formats, returns the results in mostly the same format and there are very few DVM actually running.

NIP-90 is overloaded

Why does a request for text translation and creating bitcoin OP_RETURNs share the same input i tag? and why is there an output tag on requests when only one of them will return an output?

Each DVM request kind is for requesting completely different types of compute with diffrent input and output requirements, but they are all using the same spec that has 4 different types of inputs (text, url, event, job) and an undefined number of output types.

Let me show a few random DVM requests and responses I found on wss://relay.damus.io to demonstrate what I mean:

This is a request to translate an event to English json { "kind": 5002, "content": "", "tags": [ // NIP-90 says there can be multiple inputs, so how would a DVM handle translatting multiple events at once? [ "i", "<event-id>", "event" ], [ "param", "language", "en" ], // What other type of output would text translations be? image/jpeg? [ "output", "text/plain" ], // Do we really need to define relays? cant the DVM respond on the relays it saw the request on? [ "relays", "wss://relay.unknown.cloud/", "wss://nos.lol/" ] ] }

This is a request to generate text using an LLM model json { "kind": 5050, // Why is the content empty? wouldn't it be better to have the prompt in the content? "content": "", "tags": [ // Why use an indexable tag? are we ever going to lookup prompts? // Also the type "prompt" isn't in NIP-90, this should probably be "text" [ "i", "What is the capital of France?", "prompt" ], [ "p", "c4878054cff877f694f5abecf18c7450f4b6fdf59e3e9cb3e6505a93c4577db2" ], [ "relays", "wss://relay.primal.net" ] ] }

This is a request for content recommendation json { "kind": 5300, "content": "", "tags": [ // Its fine ignoring this param, but what if the client actually needs exactly 200 "results" [ "param", "max_results", "200" ], // The spec never mentions requesting content for other users. // If a DVM didn't understand this and responded to this request it would provide bad data [ "param", "user", "b22b06b051fd5232966a9344a634d956c3dc33a7f5ecdcad9ed11ddc4120a7f2" ], [ "relays", "wss://relay.primal.net", ], [ "p", "ceb7e7d688e8a704794d5662acb6f18c2455df7481833dd6c384b65252455a95" ] ] }

This is a request to create a OP_RETURN message on bitcoin json { "kind": 5901, // Again why is the content empty when we are sending human readable text? "content": "", "tags": [ // and again, using an indexable tag on an input that will never need to be looked up ["i", "09/01/24 SEC Chairman on the brink of second ETF approval", "text"] ] }

My point isn't that these event schema's aren't understandable but why are they using the same schema? each use-case is different but are they all required to use the same i tag format as input and could support all 4 types of inputs.

Lack of libraries

With all these different types of inputs, params, and outputs its verify difficult if not impossible to build libraries for DVMs

If a simple text translation request can have an event or text as inputs, a payment-required status at any point in the flow, partial results, or responses from 10+ DVMs whats the best way to build a translation library for other nostr clients to use?

And how do I build a DVM framework for the server side that can handle multiple inputs of all four types (url, text, event, job) and clients are sending all the requests in slightly differently.

Supporting payments is impossible

The way NIP-90 is written there isn't much details about payments. only a payment-required status and a generic amount tag

But the way things are now every DVM is implementing payments differently. some send a bolt11 invoice, some expect the client to NIP-57 zap the request event (or maybe the status event), and some even ask for a subscription. and we haven't even started implementing NIP-61 nut zaps or cashu A few are even formatting the amount number wrong or denominating it in sats and not mili-sats

Building a client or a library that can understand and handle all of these payment methods is very difficult. for the DVM server side its worse. A DVM server presumably needs to support all 4+ types of payments if they want to get the most sats for their services and support the most clients.

All of this is made even more complicated by the fact that a DVM can ask for payment at any point during the job process. this makes sense for some types of compute, but for others like translations or user recommendation / search it just makes things even more complicated.

For example, If a client wanted to implement a timeline page that showed the notes of all the pubkeys on a recommended list. what would they do when the selected DVM asks for payment at the start of the job? or at the end? or worse, only provides half the pubkeys and asks for payment for the other half. building a UI that could handle even just two of these possibilities is complicated.

NIP-89 is being abused

NIP-89 is "Recommended Application Handlers" and the way its describe in the nips repo is

a way to discover applications that can handle unknown event-kinds

Not "a way to discover everything"

If I wanted to build an application discovery app to show all the apps that your contacts use and let you discover new apps then it would have to filter out ALL the DVM advertisement events. and that's not just for making requests from relays

If the app shows the user their list of "recommended applications" then it either has to understand that everything in the 5xxx kind range is a DVM and to show that is its own category or show a bunch of unknown "favorites" in the list which might be confusing for the user.

In conclusion

My point in writing this article isn't that the DVMs implementations so far don't work, but that they will never work well because the spec is too broad. even with only a few DVMs running we have already lost interoperability.

I don't want to be completely negative though because some things have worked. the "DVM feeds" work, although they are limited to a single page of results. text / event translations also work well and kind 5970 Event PoW delegation could be cool. but if we want interoperability, we are going to need to change a few things with NIP-90

I don't think we can (or should) abandon NIP-90 entirely but it would be good to break it up into small NIPs or specs. break each "kind" of DVM request out into its own spec with its own definitions for expected inputs, outputs and flow.

Then if we have simple, clean definitions for each kind of compute we want to distribute. we might actually see markets and services being built and used.

@ 0fa80bd3:ea7325de

DAOs promised decentralization. They offered a system where every member could influence a project's direction, where money and power were transparently distributed, and decisions were made through voting. All of it recorded immutably on the blockchain, free from middlemen.

But something didn’t work out. In practice, most DAOs haven’t evolved into living, self-organizing organisms. They became something else: clubs where participation is unevenly distributed. Leaders remained - only now without formal titles. They hold influence through control over communications, task framing, and community dynamics. Centralization still exists, just wrapped in a new package.

But there's a second, less obvious problem. Crowds can’t create strategy. In DAOs, people vote for what "feels right to the majority." But strategy isn’t about what feels good - it’s about what’s necessary. Difficult, unpopular, yet forward-looking decisions often fail when put to a vote. A founder’s vision is a risk. But in healthy teams, it’s that risk that drives progress. In DAOs, risk is almost always diluted until it becomes something safe and vague.

Instead of empowering leaders, DAOs often neutralize them. This is why many DAOs resemble consensus machines. Everyone talks, debates, and participates, but very little actually gets done. One person says, “Let’s jump,” and five others respond, “Let’s discuss that first.” This dynamic might work for open forums, but not for action.

Decentralization works when there’s trust and delegation, not just voting. Until DAOs develop effective systems for assigning roles, taking ownership, and acting with flexibility, they will keep losing ground to old-fashioned startups led by charismatic founders with a clear vision.

We’ve seen this in many real-world cases. Take MakerDAO, one of the most mature and technically sophisticated DAOs. Its governance token (MKR) holders vote on everything from interest rates to protocol upgrades. While this has allowed for transparency and community involvement, the process is often slow and bureaucratic. Complex proposals stall. Strategic pivots become hard to implement. And in 2023, a controversial proposal to allocate billions to real-world assets passed only narrowly, after months of infighting - highlighting how vision and execution can get stuck in the mud of distributed governance.

On the other hand, Uniswap DAO, responsible for the largest decentralized exchange, raised governance participation only after launching a delegation system where token holders could choose trusted representatives. Still, much of the activity is limited to a small group of active contributors. The vast majority of token holders remain passive. This raises the question: is it really community-led, or just a formalized power structure with lower transparency?

Then there’s ConstitutionDAO, an experiment that went viral. It raised over $40 million in days to try and buy a copy of the U.S. Constitution. But despite the hype, the DAO failed to win the auction. Afterwards, it struggled with refund logistics, communication breakdowns, and confusion over governance. It was a perfect example of collective enthusiasm without infrastructure or planning - proof that a DAO can raise capital fast but still lack cohesion.

Not all efforts have failed. Projects like Gitcoin DAO have made progress by incentivizing small, individual contributions. Their quadratic funding mechanism rewards projects based on the number of contributors, not just the size of donations, helping to elevate grassroots initiatives. But even here, long-term strategy often falls back on a core group of organizers rather than broad community consensus.

The pattern is clear: when the stakes are low or the tasks are modular, DAOs can coordinate well. But when bold moves are needed—when someone has to take responsibility and act under uncertainty DAOs often freeze. In the name of consensus, they lose momentum.

That’s why the organization of the future can’t rely purely on decentralization. It must encourage individual initiative and the ability to take calculated risks. People need to see their contribution not just as a vote, but as a role with clear actions and expected outcomes. When the situation demands, they should be empowered to act first and present the results to the community afterwards allowing for both autonomy and accountability. That’s not a flaw in the system. It’s how real progress happens.

@ c066aac5:6a41a034

I’m drawn to extremities in art. The louder, the bolder, the more outrageous, the better. Bold art takes me out of the mundane into a whole new world where anything and everything is possible. Having grown up in the safety of the suburban midwest, I was a bit of a rebellious soul in search of the satiation that only came from the consumption of the outrageous. My inclination to find bold art draws me to NOSTR, because I believe NOSTR can be the place where the next generation of artistic pioneers go to express themselves. I also believe that as much as we are able, were should invite them to come create here.

My Background: A Small Side Story

My father was a professional gamer in the 80s, back when there was no money or glory in the avocation. He did get a bit of spotlight though after the fact: in the mid 2000’s there were a few parties making documentaries about that era of gaming as well as current arcade events (namely 2007’sChasing GhostsandThe King of Kong: A Fistful of Quarters). As a result of these documentaries, there was a revival in the arcade gaming scene. My family attended events related to the documentaries or arcade gaming and I became exposed to a lot of things I wouldn’t have been able to find. The producer ofThe King of Kong: A Fistful of Quarters had previously made a documentary calledNew York Dollwhich was centered around the life of bassist Arthur Kane. My 12 year old mind was blown: The New York Dolls were a glam-punk sensation dressed in drag. The music was from another planet. Johnny Thunders’ guitar playing was like Chuck Berry with more distortion and less filter. Later on I got to meet the Galaga record holder at the time, Phil Day, in Ottumwa Iowa. Phil is an Australian man of high intellect and good taste. He exposed me to great creators such as Nick Cave & The Bad Seeds, Shakespeare, Lou Reed, artists who created things that I had previously found inconceivable.

I believe this time period informed my current tastes and interests, but regrettably I think it also put coals on the fire of rebellion within. I stopped taking my parents and siblings seriously, the Christian faith of my family (which I now hold dearly to) seemed like a mundane sham, and I felt I couldn’t fit in with most people because of my avant-garde tastes. So I write this with the caveat that there should be a way to encourage these tastes in children without letting them walk down the wrong path. There is nothing inherently wrong with bold art, but I’d advise parents to carefully find ways to cultivate their children’s tastes without completely shutting them down and pushing them away as a result. My parents were very loving and patient during this time; I thank God for that.

With that out of the way, lets dive in to some bold artists:

Nicolas Cage: Actor

There is an excellent video by Wisecrack on Nicolas Cage that explains him better than I will, which I will linkhere. Nicolas Cage rejects the idea that good acting is tied to mere realism; all of his larger than life acting decisions are deliberate choices. When that clicked for me, I immediately realized the man is a genius. He borrows from Kabuki and German Expressionism, art forms that rely on exaggeration to get the message across. He has even created his own acting style, which he calls Nouveau Shamanic. He augments his imagination to go from acting to being. Rather than using the old hat of method acting, he transports himself to a new world mentally. The projects he chooses to partake in are based on his own interests or what he considers would be a challenge (making a bad script good for example). Thus it doesn’t matter how the end result comes out; he has already achieved his goal as an artist. Because of this and because certain directors don’t know how to use his talents, he has a noticeable amount of duds in his filmography. Dig around the duds, you’ll find some pure gold. I’d personally recommend the filmsPig, Joe, Renfield, and his Christmas film The Family Man.

Nick Cave: Songwriter

What a wild career this man has had! From the apocalyptic mayhem of his band The Birthday Party to the pensive atmosphere of his albumGhosteen, it seems like Nick Cave has tried everything. I think his secret sauce is that he’s always working. He maintains an excellent newsletter calledThe Red Hand Files, he has written screenplays such asLawless, he has written books, he has made great film scores such asThe Assassination of Jesse James by the Coward Robert Ford, the man is religiously prolific. I believe that one of the reasons he is prolific is that he’s not afraid to experiment. If he has an idea, he follows it through to completion. From the albumMurder Ballads(which is comprised of what the title suggests) to his rejected sequel toGladiator(Gladiator: Christ Killer), he doesn’t seem to be afraid to take anything on. This has led to some over the top works as well as some deeply personal works. Albums likeSkeleton TreeandGhosteenwere journeys through the grief of his son’s death. The Boatman’s Callis arguably a better break-up album than anything Taylor Swift has put out. He’s not afraid to be outrageous, he’s not afraid to offend, but most importantly he’s not afraid to be himself. Works I’d recommend include The Birthday Party’sLive 1981-82, Nick Cave & The Bad Seeds’The Boatman’s Call, and the filmLawless.

Jim Jarmusch: Director

I consider Jim’s films to be bold almost in an ironic sense: his works are bold in that they are, for the most part, anti-sensational. He has a rule that if his screenplays are criticized for a lack of action, he makes them even less eventful. Even with sensational settings his films feel very close to reality, and they demonstrate the beauty of everyday life. That's what is bold about his art to me: making the sensational grounded in reality while making everyday reality all the more special. Ghost Dog: The Way of the Samurai is about a modern-day African-American hitman who strictly follows the rules of the ancient Samurai, yet one can resonate with the humanity of a seemingly absurd character. Only Lovers Left Aliveis a vampire love story, but in the middle of a vampire romance one can see their their own relationships in a new deeply human light. Jim’s work reminds me that art reflects life, and that there is sacred beauty in seemingly mundane everyday life. I personally recommend his filmsPaterson,Down by Law, andCoffee and Cigarettes.

NOSTR: We Need Bold Art

NOSTR is in my opinion a path to a better future. In a world creeping slowly towards everything apps, I hope that the protocol where the individual owns their data wins over everything else. I love freedom and sovereignty. If NOSTR is going to win the race of everything apps, we need more than Bitcoin content. We need more than shirtless bros paying for bananas in foreign countries and exercising with girls who have seductive accents. Common people cannot see themselves in such a world. NOSTR needs to catch the attention of everyday people. I don’t believe that this can be accomplished merely by introducing more broadly relevant content; people are searching for content that speaks to them. I believe that NOSTR can and should attract artists of all kinds because NOSTR is one of the few places on the internet where artists can express themselves fearlessly. Getting zaps from NOSTR’s value-for-value ecosystem has far less friction than crowdfunding a creative project or pitching investors that will irreversibly modify an artist’s vision. Having a place where one can post their works without fear of censorship should be extremely enticing. Having a place where one can connect with fellow humans directly as opposed to a sea of bots should seem like the obvious solution. If NOSTR can become a safe haven for artists to express themselves and spread their work, I believe that everyday people will follow. The banker whose stressful job weighs on them will suddenly find joy with an original meme made by a great visual comedian. The programmer for a healthcare company who is drowning in hopeless mundanity could suddenly find a new lust for life by hearing the song of a musician who isn’t afraid to crowdfund their their next project by putting their lighting address on the streets of the internet. The excel guru who loves independent film may find that NOSTR is the best way to support non corporate movies. My closing statement: continue to encourage the artists in your life as I’m sure you have been, but while you’re at it give them the purple pill. You may very well be a part of building a better future.

@ 17538dc2:71ed77c4

The MacOS security update summary is a reminder that laptops and desktops are incredibly compromised.

macOS Sequoia 15.4

Released March 31, 2025

Accessibility Available for: macOS Sequoia

Impact: An app may be able to access sensitive user data

Description: A logging issue was addressed with improved data redaction.

CVE-2025-24202: Zhongcheng Li from IES Red Team of ByteDance

AccountPolicy Available for: macOS Sequoia

Impact: A malicious app may be able to gain root privileges

Description: This issue was addressed by removing the vulnerable code.

CVE-2025-24234: an anonymous researcher

AirDrop Available for: macOS Sequoia

Impact: An app may be able to read arbitrary file metadata

Description: A permissions issue was addressed with additional restrictions.

CVE-2025-24097: Ron Masas of BREAKPOINT.SH

App Store Available for: macOS Sequoia

Impact: A malicious app may be able to access private information

Description: This issue was addressed by removing the vulnerable code.

CVE-2025-24276: an anonymous researcher

AppleMobileFileIntegrity Available for: macOS Sequoia

Impact: An app may be able to modify protected parts of the file system

Description: The issue was addressed with improved checks.

CVE-2025-24272: Mickey Jin (@patch1t)

AppleMobileFileIntegrity Available for: macOS Sequoia

Impact: An app may be able to access protected user data

Description: A downgrade issue was addressed with additional code-signing restrictions.

CVE-2025-24239: Wojciech Regula of SecuRing (wojciechregula.blog)

AppleMobileFileIntegrity Available for: macOS Sequoia

Impact: A malicious app may be able to read or write to protected files

Description: A permissions issue was addressed with additional restrictions.

CVE-2025-24233: Claudio Bozzato and Francesco Benvenuto of Cisco Talos.

AppleMobileFileIntegrity Available for: macOS Sequoia

Impact: An app may be able to access user-sensitive data

Description: A privacy issue was addressed by removing the vulnerable code.

CVE-2025-30443: Bohdan Stasiuk (@bohdan_stasiuk)

Audio Available for: macOS Sequoia

Impact: Processing a maliciously crafted font may result in the disclosure of process memory

Description: The issue was addressed with improved memory handling.

CVE-2025-24244: Hossein Lotfi (@hosselot) of Trend Micro Zero Day Initiative

Audio Available for: macOS Sequoia

Impact: Processing a maliciously crafted file may lead to arbitrary code execution

Description: The issue was addressed with improved memory handling.

CVE-2025-24243: Hossein Lotfi (@hosselot) of Trend Micro Zero Day Initiative

Authentication Services Available for: macOS Sequoia

Impact: Password autofill may fill in passwords after failing authentication

Description: This issue was addressed through improved state management.

CVE-2025-30430: Dominik Rath

Authentication Services Available for: macOS Sequoia

Impact: A malicious website may be able to claim WebAuthn credentials from another website that shares a registrable suffix

Description: The issue was addressed with improved input validation.

CVE-2025-24180: Martin Kreichgauer of Google Chrome

Authentication Services Available for: macOS Sequoia

Impact: A malicious app may be able to access a user's saved passwords

Description: This issue was addressed by adding a delay between verification code attempts.

CVE-2025-24245: Ian Mckay (@iann0036)

Automator Available for: macOS Sequoia

Impact: An app may be able to access protected user data

Description: A permissions issue was addressed by removing vulnerable code and adding additional checks.

CVE-2025-30460: an anonymous researcher

BiometricKit Available for: macOS Sequoia

Impact: An app may be able to cause unexpected system termination

Description: A buffer overflow was addressed with improved bounds checking.

CVE-2025-24237: Yutong Xiu

Calendar Available for: macOS Sequoia

Impact: An app may be able to break out of its sandbox

Description: A path handling issue was addressed with improved validation.

CVE-2025-30429: Denis Tokarev (@illusionofcha0s)

Calendar Available for: macOS Sequoia

Impact: An app may be able to break out of its sandbox

Description: This issue was addressed with improved checks.

CVE-2025-24212: Denis Tokarev (@illusionofcha0s)

CloudKit Available for: macOS Sequoia

Impact: A malicious app may be able to access private information

Description: The issue was addressed with improved checks.

CVE-2025-24215: Kirin (@Pwnrin)

CoreAudio Available for: macOS Sequoia

Impact: Parsing a file may lead to an unexpected app termination

Description: The issue was addressed with improved checks.

CVE-2025-24163: Google Threat Analysis Group

CoreAudio Available for: macOS Sequoia

Impact: Playing a malicious audio file may lead to an unexpected app termination

Description: An out-of-bounds read issue was addressed with improved input validation.

CVE-2025-24230: Hossein Lotfi (@hosselot) of Trend Micro Zero Day Initiative

CoreMedia Available for: macOS Sequoia

Impact: Processing a maliciously crafted video file may lead to unexpected app termination or corrupt process memory

Description: This issue was addressed with improved memory handling.

CVE-2025-24211: Hossein Lotfi (@hosselot) of Trend Micro Zero Day Initiative

CoreMedia Available for: macOS Sequoia

Impact: An app may be able to access sensitive user data

Description: An access issue was addressed with additional sandbox restrictions.

CVE-2025-24236: Csaba Fitzl (@theevilbit) and Nolan Astrein of Kandji

CoreMedia Available for: macOS Sequoia

Impact: Processing a maliciously crafted video file may lead to unexpected app termination or corrupt process memory

Description: The issue was addressed with improved memory handling.

CVE-2025-24190: Hossein Lotfi (@hosselot) of Trend Micro Zero Day Initiative

CoreMedia Playback Available for: macOS Sequoia

Impact: A malicious app may be able to access private information

Description: A path handling issue was addressed with improved validation.

CVE-2025-30454: pattern-f (@pattern_F_)

CoreServices Description: This issue was addressed through improved state management.

CVE-2025-31191: Jonathan Bar Or (@yo_yo_yo_jbo) of Microsoft, and an anonymous researcher Available for: macOS Sequoia

Impact: An app may be able to access sensitive user data

CoreText Available for: macOS Sequoia

Impact: Processing a maliciously crafted font may result in the disclosure of process memory

Description: An out-of-bounds read issue was addressed with improved input validation.

CVE-2025-24182: Hossein Lotfi (@hosselot) of Trend Micro Zero Day Initiative

Crash Reporter Available for: macOS Sequoia

Impact: An app may be able to gain root privileges

Description: A parsing issue in the handling of directory paths was addressed with improved path validation.

CVE-2025-24277: Csaba Fitzl (@theevilbit) of Kandji and Gergely Kalman (@gergely_kalman), and an anonymous researcher

curl Available for: macOS Sequoia

Impact: An input validation issue was addressed

Description: This is a vulnerability in open source code and Apple Software is among the affected projects. The CVE-ID was assigned by a third party. Learn more about the issue and CVE-ID at cve.org.

CVE-2024-9681

Disk Images Available for: macOS Sequoia

Impact: An app may be able to break out of its sandbox

Description: A file access issue was addressed with improved input validation.

CVE-2025-24255: an anonymous researcher

DiskArbitration Available for: macOS Sequoia

Impact: An app may be able to gain root privileges

Description: A parsing issue in the handling of directory paths was addressed with improved path validation.

CVE-2025-30456: Gergely Kalman (@gergely_kalman)

DiskArbitration Available for: macOS Sequoia

Impact: An app may be able to gain root privileges

Description: A permissions issue was addressed with additional restrictions.

CVE-2025-24267: an anonymous researcher

Dock Available for: macOS Sequoia

Impact: A malicious app may be able to access private information

Description: The issue was addressed with improved checks.

CVE-2025-30455: Mickey Jin (@patch1t), and an anonymous researcher

Dock Available for: macOS Sequoia

Impact: An app may be able to modify protected parts of the file system

Description: This issue was addressed by removing the vulnerable code.

CVE-2025-31187: Rodolphe BRUNETTI (@eisw0lf) of Lupus Nova

dyld Available for: macOS Sequoia

Impact: Apps that appear to use App Sandbox may be able to launch without restrictions

Description: A library injection issue was addressed with additional restrictions.

CVE-2025-30462: Pietro Francesco Tirenna, Davide Silvetti, Abdel Adim Oisfi of Shielder (shielder.com)

FaceTime Available for: macOS Sequoia

Impact: An app may be able to access sensitive user data

Description: This issue was addressed with improved redaction of sensitive information.

CVE-2025-30451: Kirin (@Pwnrin) and luckyu (@uuulucky)

FeedbackLogger Available for: macOS Sequoia

Impact: An app may be able to access sensitive user data

Description: This issue was addressed with improved data protection.

CVE-2025-24281: Rodolphe BRUNETTI (@eisw0lf)

Focus Available for: macOS Sequoia

Impact: An attacker with physical access to a locked device may be able to view sensitive user information

Description: The issue was addressed with improved checks.

CVE-2025-30439: Andr.Ess

Focus Available for: macOS Sequoia

Impact: An app may be able to access sensitive user data

Description: A logging issue was addressed with improved data redaction.

CVE-2025-24283: Kirin (@Pwnrin)

Foundation Available for: macOS Sequoia

Impact: An app may be able to access protected user data

Description: An access issue was addressed with additional sandbox restrictions on the system pasteboards.

CVE-2025-30461: an anonymous researcher

Foundation Available for: macOS Sequoia

Impact: An app may be able to access sensitive user data

Description: The issue was resolved by sanitizing logging

CVE-2025-30447: LFY@secsys from Fudan University

Foundation Available for: macOS Sequoia

Impact: An app may be able to cause a denial-of-service

Description: An uncontrolled format string issue was addressed with improved input validation.

CVE-2025-24199: Manuel Fernandez (Stackhopper Security)

GPU Drivers Available for: macOS Sequoia

Impact: An app may be able to cause unexpected system termination or corrupt kernel memory

Description: An out-of-bounds write issue was addressed with improved bounds checking.

CVE-2025-30464: ABC Research s.r.o.

CVE-2025-24273: Wang Yu of Cyberserval

GPU Drivers Available for: macOS Sequoia

Impact: An app may be able to disclose kernel memory

Description: The issue was addressed with improved bounds checks.

CVE-2025-24256: Anonymous working with Trend Micro Zero Day Initiative, Murray Mike

Handoff Available for: macOS Sequoia

Impact: An app may be able to access sensitive user data

Description: The issue was addressed with improved restriction of data container access.

CVE-2025-30463: mzzzz__

ImageIO Available for: macOS Sequoia

Impact: Parsing an image may lead to disclosure of user information

Description: A logic error was addressed with improved error handling.

CVE-2025-24210: Anonymous working with Trend Micro Zero Day Initiative

Installer Available for: macOS Sequoia

Impact: An app may be able to check the existence of an arbitrary path on the file system

Description: A permissions issue was addressed with additional sandbox restrictions.

CVE-2025-24249: YingQi Shi(@Mas0nShi) of DBAppSecurity's WeBin lab and Minghao Lin (@Y1nKoc)

Installer Available for: macOS Sequoia

Impact: A sandboxed app may be able to access sensitive user data

Description: A logic issue was addressed with improved checks.

CVE-2025-24229: an anonymous researcher

IOGPUFamily Available for: macOS Sequoia

Impact: An app may be able to cause unexpected system termination or write kernel memory

Description: An out-of-bounds write issue was addressed with improved input validation.

CVE-2025-24257: Wang Yu of Cyberserval

IOMobileFrameBuffer Available for: macOS Sequoia

Impact: An app may be able to corrupt coprocessor memory

Description: The issue was addressed with improved bounds checks.

CVE-2025-30437: Ye Zhang (@VAR10CK) of Baidu Security

Kerberos Helper Available for: macOS Sequoia

Impact: A remote attacker may be able to cause unexpected app termination or heap corruption

Description: A memory initialization issue was addressed with improved memory handling.

CVE-2025-24235: Dave G.

Kernel Available for: macOS Sequoia

Impact: An app may be able to access protected user data

Description: The issue was addressed with improved checks.

CVE-2025-24204: Koh M. Nakagawa (@tsunek0h) of FFRI Security, Inc.

Kernel Available for: macOS Sequoia

Impact: An app may be able to modify protected parts of the file system

Description: The issue was addressed with improved checks.

CVE-2025-24203: Ian Beer of Google Project Zero

Kernel Available for: macOS Sequoia

Impact: An attacker with user privileges may be able to read kernel memory

Description: A type confusion issue was addressed with improved memory handling.

CVE-2025-24196: Joseph Ravichandran (@0xjprx) of MIT CSAIL

LaunchServices Available for: macOS Sequoia

Impact: A malicious JAR file may bypass Gatekeeper checks

Description: This issue was addressed with improved handling of executable types.

CVE-2025-24148: Kenneth Chew

libarchive Available for: macOS Sequoia

Impact: An input validation issue was addressed

Description: This is a vulnerability in open source code and Apple Software is among the affected projects. The CVE-ID was assigned by a third party. Learn more about the issue and CVE-ID at cve.org.

CVE-2024-48958

Libinfo Available for: macOS Sequoia

Impact: A user may be able to elevate privileges

Description: An integer overflow was addressed with improved input validation.

CVE-2025-24195: Paweł Płatek (Trail of Bits)

libnetcore Available for: macOS Sequoia

Impact: Processing maliciously crafted web content may result in the disclosure of process memory

Description: A logic issue was addressed with improved checks.

CVE-2025-24194: an anonymous researcher

libxml2 Available for: macOS Sequoia

Impact: Parsing a file may lead to an unexpected app termination

Description: This is a vulnerability in open source code and Apple Software is among the affected projects. The CVE-ID was assigned by a third party. Learn more about the issue and CVE-ID at cve.org.

CVE-2025-27113

CVE-2024-56171

libxpc Available for: macOS Sequoia

Impact: An app may be able to break out of its sandbox

Description: This issue was addressed through improved state management.

CVE-2025-24178: an anonymous researcher

libxpc Available for: macOS Sequoia

Impact: An app may be able to delete files for which it does not have permission

Description: This issue was addressed with improved handling of symlinks.

CVE-2025-31182: Alex Radocea and Dave G. of Supernetworks, 风沐云烟(@binary_fmyy) and Minghao Lin(@Y1nKoc)

libxpc Available for: macOS Sequoia

Impact: An app may be able to gain elevated privileges

Description: A logic issue was addressed with improved checks.

CVE-2025-24238: an anonymous researcher

Mail Available for: macOS Sequoia

Impact: "Block All Remote Content" may not apply for all mail previews

Description: A permissions issue was addressed with additional sandbox restrictions.

CVE-2025-24172: an anonymous researcher

manpages Available for: macOS Sequoia

Impact: An app may be able to access sensitive user data

Description: This issue was addressed with improved validation of symlinks.

CVE-2025-30450: Pwn2car

Maps Available for: macOS Sequoia

Impact: An app may be able to read sensitive location information

Description: A path handling issue was addressed with improved logic.

CVE-2025-30470: LFY@secsys from Fudan University

NetworkExtension Available for: macOS Sequoia

Impact: An app may be able to enumerate a user's installed apps

Description: This issue was addressed with additional entitlement checks.

CVE-2025-30426: Jimmy

Notes Available for: macOS Sequoia

Impact: A sandboxed app may be able to access sensitive user data in system logs

Description: A privacy issue was addressed with improved private data redaction for log entries.

CVE-2025-24262: LFY@secsys from Fudan University

NSDocument Available for: macOS Sequoia

Impact: A malicious app may be able to access arbitrary files

Description: This issue was addressed through improved state management.

CVE-2025-24232: an anonymous researcher

OpenSSH Available for: macOS Sequoia

Impact: An app may be able to access user-sensitive data

Description: An injection issue was addressed with improved validation.

CVE-2025-24246: Mickey Jin (@patch1t)

PackageKit Available for: macOS Sequoia

Impact: An app may be able to modify protected parts of the file system

Description: The issue was addressed with improved checks.

CVE-2025-24261: Mickey Jin (@patch1t)

PackageKit Available for: macOS Sequoia

Impact: An app may be able to modify protected parts of the file system

Description: A logic issue was addressed with improved checks.

CVE-2025-24164: Mickey Jin (@patch1t)

PackageKit Available for: macOS Sequoia

Impact: A malicious app with root privileges may be able to modify the contents of system files

Description: A permissions issue was addressed with additional restrictions.

CVE-2025-30446: Pedro Tôrres (@t0rr3sp3dr0)

Parental Controls Available for: macOS Sequoia

Impact: An app may be able to retrieve Safari bookmarks without an entitlement check

Description: This issue was addressed with additional entitlement checks.

CVE-2025-24259: Noah Gregory (wts.dev)

Photos Storage Available for: macOS Sequoia

Impact: Deleting a conversation in Messages may expose user contact information in system logging

Description: A logging issue was addressed with improved data redaction.

CVE-2025-30424: an anonymous researcher

Power Services Available for: macOS Sequoia

Impact: An app may be able to break out of its sandbox

Description: This issue was addressed with additional entitlement checks.

CVE-2025-24173: Mickey Jin (@patch1t)

Python Available for: macOS Sequoia

Impact: A remote attacker may be able to bypass sender policy checks and deliver malicious content via email

Description: This is a vulnerability in open source code and Apple Software is among the affected projects. The CVE-ID was assigned by a third party. Learn more about the issue and CVE-ID at cve.org.

CVE-2023-27043

RPAC Available for: macOS Sequoia

Impact: An app may be able to modify protected parts of the file system

Description: The issue was addressed with improved validation of environment variables.

CVE-2025-24191: Claudio Bozzato and Francesco Benvenuto of Cisco Talos

Safari Available for: macOS Sequoia

Impact: Visiting a malicious website may lead to user interface spoofing

Description: The issue was addressed with improved UI.

CVE-2025-24113: @RenwaX23

Safari Available for: macOS Sequoia

Impact: Visiting a malicious website may lead to address bar spoofing

Description: The issue was addressed with improved checks.

CVE-2025-30467: @RenwaX23

Safari Available for: macOS Sequoia

Impact: A website may be able to access sensor information without user consent

Description: The issue was addressed with improved checks.

CVE-2025-31192: Jaydev Ahire

Safari Available for: macOS Sequoia

Impact: A download's origin may be incorrectly associated

Description: This issue was addressed through improved state management.

CVE-2025-24167: Syarif Muhammad Sajjad

Sandbox Available for: macOS Sequoia

Impact: An app may be able to access removable volumes without user consent

Description: A permissions issue was addressed with additional restrictions.

CVE-2025-24093: Yiğit Can YILMAZ (@yilmazcanyigit)

Sandbox Available for: macOS Sequoia

Impact: An input validation issue was addressed

Description: The issue was addressed with improved checks.

CVE-2025-30452: an anonymous researcher

Sandbox Available for: macOS Sequoia

Impact: An app may be able to access protected user data

Description: A permissions issue was addressed with additional restrictions.

CVE-2025-24181: Arsenii Kostromin (0x3c3e)

SceneKit Available for: macOS Sequoia

Impact: An app may be able to read files outside of its sandbox

Description: A permissions issue was addressed with additional restrictions.

CVE-2025-30458: Mickey Jin (@patch1t)

Security Available for: macOS Sequoia

Impact: A remote user may be able to cause a denial-of-service

Description: A validation issue was addressed with improved logic.

CVE-2025-30471: Bing Shi, Wenchao Li, Xiaolong Bai of Alibaba Group, Luyi Xing of Indiana University Bloomington

Security Available for: macOS Sequoia

Impact: A malicious app acting as a HTTPS proxy could get access to sensitive user data

Description: This issue was addressed with improved access restrictions.

CVE-2025-24250: Wojciech Regula of SecuRing (wojciechregula.blog)

Share Sheet Available for: macOS Sequoia

Impact: A malicious app may be able to dismiss the system notification on the Lock Screen that a recording was started

Description: This issue was addressed with improved access restrictions.

CVE-2025-30438: Halle Winkler, Politepix theoffcuts.org

Shortcuts Available for: macOS Sequoia

Impact: A shortcut may be able to access files that are normally inaccessible to the Shortcuts app

Description: A permissions issue was addressed with improved validation.

CVE-2025-30465: an anonymous researcher

Shortcuts Available for: macOS Sequoia

Impact: An app may be able to access user-sensitive data

Description: An access issue was addressed with additional sandbox restrictions.

CVE-2025-24280: Kirin (@Pwnrin)

Shortcuts Available for: macOS Sequoia

Impact: A Shortcut may run with admin privileges without authentication

Description: An authentication issue was addressed with improved state management.

CVE-2025-31194: Dolf Hoegaerts

Shortcuts Available for: macOS Sequoia

Impact: A shortcut may be able to access files that are normally inaccessible to the Shortcuts app

Description: This issue was addressed with improved access restrictions.

CVE-2025-30433: Andrew James Gonzalez

Siri Available for: macOS Sequoia

Impact: An app may be able to access sensitive user data

Description: The issue was addressed with improved restriction of data container access.

CVE-2025-31183: Kirin (@Pwnrin), Bohdan Stasiuk (@bohdan_stasiuk)

Siri Available for: macOS Sequoia

Impact: A sandboxed app may be able to access sensitive user data in system logs

Description: This issue was addressed with improved redaction of sensitive information.

CVE-2025-30435: K宝 (@Pwnrin) and luckyu (@uuulucky)

Siri Available for: macOS Sequoia

Impact: An app may be able to access sensitive user data

Description: This issue was addressed with improved redaction of sensitive information.

CVE-2025-24217: Kirin (@Pwnrin)

Siri Available for: macOS Sequoia

Impact: An app may be able to access sensitive user data

Description: A privacy issue was addressed by not logging contents of text fields.

CVE-2025-24214: Kirin (@Pwnrin)

Siri Available for: macOS Sequoia

Impact: An app may be able to enumerate devices that have signed into the user's Apple Account

Description: A permissions issue was addressed with additional restrictions.

CVE-2025-24248: Minghao Lin (@Y1nKoc) and Tong Liu@Lyutoon_ and 风(binary_fmyy) and F00L

Siri Available for: macOS Sequoia

Impact: An app may be able to access user-sensitive data

Description: An authorization issue was addressed with improved state management.

CVE-2025-24205: YingQi Shi(@Mas0nShi) of DBAppSecurity's WeBin lab and Minghao Lin (@Y1nKoc)

Siri Available for: macOS Sequoia

Impact: An attacker with physical access may be able to use Siri to access sensitive user data

Description: This issue was addressed by restricting options offered on a locked device.

CVE-2025-24198: Richard Hyunho Im (@richeeta) with routezero.security

SMB Available for: macOS Sequoia

Impact: An app may be able to cause unexpected system termination

Description: The issue was addressed with improved memory handling.

CVE-2025-24269: Alex Radocea of Supernetworks

SMB Available for: macOS Sequoia

Impact: Mounting a maliciously crafted SMB network share may lead to system termination

Description: A race condition was addressed with improved locking.

CVE-2025-30444: Dave G.

SMB Available for: macOS Sequoia

Impact: An app may be able to execute arbitrary code with kernel privileges

Description: A buffer overflow issue was addressed with improved memory handling.

CVE-2025-24228: Joseph Ravichandran (@0xjprx) of MIT CSAIL

smbx Available for: macOS Sequoia

Impact: An attacker in a privileged position may be able to perform a denial-of-service

Description: The issue was addressed with improved memory handling.

CVE-2025-24260: zbleet of QI-ANXIN TianGong Team

Software Update Available for: macOS Sequoia

Impact: An app may be able to modify protected parts of the file system

Description: A library injection issue was addressed with additional restrictions.

CVE-2025-24282: Claudio Bozzato and Francesco Benvenuto of Cisco Talos

Software Update Available for: macOS Sequoia

Impact: A user may be able to elevate privileges

Description: This issue was addressed with improved validation of symlinks.

CVE-2025-24254: Arsenii Kostromin (0x3c3e)

Software Update Available for: macOS Sequoia

Impact: An app may be able to modify protected parts of the file system

Description: The issue was addressed with improved checks.

CVE-2025-24231: Claudio Bozzato and Francesco Benvenuto of Cisco Talos

StickerKit Available for: macOS Sequoia

Impact: An app may be able to observe unprotected user data

Description: A privacy issue was addressed by moving sensitive data to a protected location.

CVE-2025-24263: Cristian Dinca of "Tudor Vianu" National High School of Computer Science, Romania

Storage Management Available for: macOS Sequoia

Impact: An app may be able to enable iCloud storage features without user consent

Description: A permissions issue was addressed with additional restrictions.

CVE-2025-24207: YingQi Shi (@Mas0nShi) of DBAppSecurity's WeBin lab, 风沐云烟 (binary_fmyy) and Minghao Lin (@Y1nKoc)

StorageKit Available for: macOS Sequoia

Impact: An app may be able to gain root privileges

Description: A permissions issue was addressed with additional restrictions.

CVE-2025-30449: Arsenii Kostromin (0x3c3e), and an anonymous researcher

StorageKit Available for: macOS Sequoia

Impact: An app may be able to access protected user data

Description: This issue was addressed with improved handling of symlinks.

CVE-2025-24253: Mickey Jin (@patch1t), Csaba Fitzl (@theevilbit) of Kandji

StorageKit Available for: macOS Sequoia

Impact: An app may be able to access user-sensitive data

Description: A race condition was addressed with additional validation.

CVE-2025-24240: Mickey Jin (@patch1t)

StorageKit Available for: macOS Sequoia

Impact: An app may be able to bypass Privacy preferences

Description: A race condition was addressed with additional validation.

CVE-2025-31188: Mickey Jin (@patch1t)

Summarization Services Available for: macOS Sequoia

Impact: An app may be able to access information about a user's contacts

Description: A privacy issue was addressed with improved private data redaction for log entries.

CVE-2025-24218: Kirin and FlowerCode, Bohdan Stasiuk (@bohdan_stasiuk)

System Settings Available for: macOS Sequoia

Impact: An app may be able to access protected user data

Description: This issue was addressed with improved validation of symlinks.

CVE-2025-24278: Zhongquan Li (@Guluisacat)

System Settings Available for: macOS Sequoia

Impact: An app with root privileges may be able to access private information

Description: This issue was addressed with improved handling of symlinks.

CVE-2025-24242: Koh M. Nakagawa (@tsunek0h) of FFRI Security, Inc.

SystemMigration Available for: macOS Sequoia

Impact: A malicious app may be able to create symlinks to protected regions of the disk

Description: This issue was addressed with improved validation of symlinks.

CVE-2025-30457: Mickey Jin (@patch1t)

Voice Control Available for: macOS Sequoia

Impact: An app may be able to access contacts

Description: This issue was addressed with improved file handling.

CVE-2025-24279: Mickey Jin (@patch1t)

Web Extensions Available for: macOS Sequoia

Impact: An app may gain unauthorized access to Local Network

Description: This issue was addressed with improved permissions checking.

CVE-2025-31184: Alexander Heinrich (@Sn0wfreeze), SEEMOO, TU Darmstadt & Mathy Vanhoef (@vanhoefm) and Jeroen Robben (@RobbenJeroen), DistriNet, KU Leuven

Web Extensions Available for: macOS Sequoia

Impact: Visiting a website may leak sensitive data

Description: A script imports issue was addressed with improved isolation.

CVE-2025-24192: Vsevolod Kokorin (Slonser) of Solidlab

WebKit Available for: macOS Sequoia

Impact: Processing maliciously crafted web content may lead to an unexpected Safari crash

Description: The issue was addressed with improved memory handling.

WebKit Bugzilla: 285892

CVE-2025-24264: Gary Kwong, and an anonymous researcher

WebKit Bugzilla: 284055

CVE-2025-24216: Paul Bakker of ParagonERP

WebKit Available for: macOS Sequoia

Impact: A type confusion issue could lead to memory corruption

Description: This issue was addressed with improved handling of floats.

WebKit Bugzilla: 286694

CVE-2025-24213: Google V8 Security Team

WebKit Available for: macOS Sequoia

Impact: Processing maliciously crafted web content may lead to an unexpected process crash

Description: A buffer overflow issue was addressed with improved memory handling.

WebKit Bugzilla: 286462

CVE-2025-24209: Francisco Alonso (@revskills), and an anonymous researcher

WebKit Available for: macOS Sequoia

Impact: Processing maliciously crafted web content may lead to an unexpected Safari crash

Description: A use-after-free issue was addressed with improved memory management.

WebKit Bugzilla: 285643

CVE-2025-30427: rheza (@ginggilBesel)

WebKit Available for: macOS Sequoia

Impact: A malicious website may be able to track users in Safari private browsing mode

Description: This issue was addressed through improved state management.

WebKit Bugzilla: 286580

CVE-2025-30425: an anonymous researcher

WindowServer Available for: macOS Sequoia

Impact: An attacker may be able to cause unexpected app termination

Description: A type confusion issue was addressed with improved checks.

CVE-2025-24247: PixiePoint Security

WindowServer Available for: macOS Sequoia

Impact: An app may be able to trick a user into copying sensitive data to the pasteboard

Description: A configuration issue was addressed with additional restrictions.

CVE-2025-24241: Andreas Hegenberg (folivora.AI GmbH)

Xsan Available for: macOS Sequoia

Impact: An app may be able to cause unexpected system termination

Description: A buffer overflow was addressed with improved bounds checking.

CVE-2025-24266: an anonymous researcher

Xsan Available for: macOS Sequoia

Impact: An app may be able to cause unexpected system termination

Description: An out-of-bounds read was addressed with improved bounds checking.

CVE-2025-24265: an anonymous researcher

Xsan Available for: macOS Sequoia

Impact: An app may be able to cause unexpected system termination or corrupt kernel memory

Description: A buffer overflow issue was addressed with improved memory handling.

CVE-2025-24157: an anonymous researcher

@ 04c915da:3dfbecc9

Capitalism is the most effective system for scaling innovation. The pursuit of profit is an incredibly powerful human incentive. Most major improvements to human society and quality of life have resulted from this base incentive. Market competition often results in the best outcomes for all.

That said, some projects can never be monetized. They are open in nature and a business model would centralize control. Open protocols like bitcoin and nostr are not owned by anyone and if they were it would destroy the key value propositions they provide. No single entity can or should control their use. Anyone can build on them without permission.

As a result, open protocols must depend on donation based grant funding from the people and organizations that rely on them. This model works but it is slow and uncertain, a grind where sustainability is never fully reached but rather constantly sought. As someone who has been incredibly active in the open source grant funding space, I do not think people truly appreciate how difficult it is to raise charitable money and deploy it efficiently.

Projects that can be monetized should be. Profitability is a super power. When a business can generate revenue, it taps into a self sustaining cycle. Profit fuels growth and development while providing projects independence and agency. This flywheel effect is why companies like Google, Amazon, and Apple have scaled to global dominance. The profit incentive aligns human effort with efficiency. Businesses must innovate, cut waste, and deliver value to survive.

Contrast this with non monetized projects. Without profit, they lean on external support, which can dry up or shift with donor priorities. A profit driven model, on the other hand, is inherently leaner and more adaptable. It is not charity but survival. When survival is tied to delivering what people want, scale follows naturally.

The real magic happens when profitable, sustainable businesses are built on top of open protocols and software. Consider the many startups building on open source software stacks, such as Start9, Mempool, and Primal, offering premium services on top of the open source software they build out and maintain. Think of companies like Block or Strike, which leverage bitcoin’s open protocol to offer their services on top. These businesses amplify the open software and protocols they build on, driving adoption and improvement at a pace donations alone could never match.

When you combine open software and protocols with profit driven business the result are lean, sustainable companies that grow faster and serve more people than either could alone. Bitcoin’s network, for instance, benefits from businesses that profit off its existence, while nostr will expand as developers monetize apps built on the protocol.

Capitalism scales best because competition results in efficiency. Donation funded protocols and software lay the groundwork, while market driven businesses build on top. The profit incentive acts as a filter, ensuring resources flow to what works, while open systems keep the playing field accessible, empowering users and builders. Together, they create a flywheel of innovation, growth, and global benefit.

@ f839fb67:5c930939

Relays

| Name | Address | Price (Sats/Year) | Status | | - | - | - | - | | stephen's aegis relay | wss://paid.relay.vanderwarker.family | 42069 | | | stephen's Outbox | wss://relay.vanderwarker.family | Just Me | | | stephen's Inbox | wss://haven.vanderwarker.family/inbox | WoT | | | stephen's DMs | wss://haven.vanderwarker.family/chat | WoT | | | VFam Data Relay | wss://data.relay.vanderwarker.family | 0 | | | VFam Bots Relay | wss://skeme.vanderwarker.family | Invite | | | VFGroups (NIP29) | wss://groups.vanderwarker.family | 0 | | | [TOR] My Phone Relay | ws://naswsosuewqxyf7ov7gr7igc4tq2rbtqoxxirwyhkbuns4lwc3iowwid.onion | 0 | Meh... |

---

My Pubkeys

| Name | hex | nprofile | | - | - | - | | Main | f839fb6714598a7233d09dbd42af82cc9781d0faa57474f1841af90b5c930939 | nostr:nprofile1qqs0sw0mvu29nznjx0gfm02z47pve9up6ra22ar57xzp47gttjfsjwgpramhxue69uhhyetvv9ujuanpdejx2unhv9exketj9enxzmtfd3us9mapfx | | Vanity (Backup) | 82f21be67353c0d68438003fe6e56a35e2a57c49e0899b368b5ca7aa8dde7c23 | nostr:nprofile1qqsg9usmuee48sxkssuqq0lxu44rtc4903y7pzvmx694efa23h08cgcpramhxue69uhhyetvv9ujuanpdejx2unhv9exketj9enxzmtfd3ussel49x | | VFStore | 6416f1e658ba00d42107b05ad9bf485c7e46698217e0c19f0dc2e125de3af0d0 | nostr:nprofile1qqsxg9h3uevt5qx5yyrmqkkehay9cljxdxpp0cxpnuxu9cf9mca0p5qpramhxue69uhhyetvv9ujuanpdejx2unhv9exketj9enxzmtfd3usaa8plu | | NostrSMS | 9be1b8315248eeb20f9d9ab2717d1750e4f27489eab1fa531d679dadd34c2f8d | nostr:nprofile1qqsfhcdcx9fy3m4jp7we4vn305t4pe8jwjy74v062vwk08dd6dxzlrgpramhxue69uhhyetvv9ujuanpdejx2unhv9exketj9enxzmtfd3us595d45 |

Bots

Unlocks Bot

Hex: 2e941ad17144e0a04d1b8c21c4a0dbc3fbcbb9d08ae622b5f9c85341fac7c2d0
nprofile:
nostr:nprofile1qqsza9q669c5fc9qf5dccgwy5rdu877th8gg4e3zkhuus56pltru95qpramhxue69uhhx6m9d4jjuanpdejx2unhv9exketj9enxzmtfd3ust4kvak
Latest Data:
nostr:naddr1qq882mnvda3kkttrda6kuar9wgq37amnwvaz7tmnddjk6efwweskuer9wfmkzuntv4ezuenpd45kc7gzyqhfgxk3w9zwpgzdrwxzr39qm0plhjae6z9wvg44l8y9xs06clpdqqcyqqq823cgnl9u5

Step Counter

Hex: 9223d2faeb95853b4d224a184c69e1df16648d35067a88cdf947c631b57e3de7
nprofile: nostr:nprofile1qqsfyg7jlt4etpfmf53y5xzvd8sa79ny356sv75gehu50333k4lrmecpramhxue69uhhx6m9d4jjuanpdejx2unhv9exketj9enxzmtfd3ustswp3w
Latest Data:
nostr:naddr1qvzqqqr4gupzpy3r6tawh9v98dxjyjscf357rhckvjxn2pn63rxlj37xxx6hu008qys8wumn8ghj7umtv4kk2tnkv9hxgetjwashy6m9wghxvctdd9k8jtcqp3ehgets943k7atww3jhyn39gff

RCTGuest

Hex: 373904615c781e46bf5bf87b4126c8a568a05393b1b840b1a2a3234d20affa0c
nprofile: nostr:nprofile1qqsrwwgyv9w8s8jxhadls76pymy2269q2wfmrwzqkx32xg6dyzhl5rqpramhxue69uhhx6m9d4jjuanpdejx2unhv9exketj9enxzmtfd3usy92jlx

Now Playing

Hex: 8096ed6ba1f21a3713bd47a503ee377b0ce2f187b3e5a3ae909a25b84901018b
nprofile: nostr:nprofile1qqsgp9hddwslyx3hzw750fgracmhkr8z7xrm8edr46gf5fdcfyqsrzcpramhxue69uhhx6m9d4jjuanpdejx2unhv9exketj9enxzmtfd3uspk5v4w
Latest Data:
nostr:naddr1qq9kummh94cxccted9hxwqglwaehxw309aekketdv5h8vctwv3jhyampwf4k2u3wvesk66tv0ypzpqyka446rus6xufm63a9q0hrw7cvutcc0vl95whfpx39hpyszqvtqvzqqqr4gupdk2hd

---

NIP-29 Groups

See here

• Minecraft Group Chat
• nostr:naddr1qqrxvc33xpnxxqfqwaehxw309anhymm4wpejuanpdejx2unhv9exketj9enxzmtfd3usygrzymrpd2wz8ularp06y8ad5dgaddlumyt7tfzqge3vc97sgsarjvpsgqqqnpvqazypfd
• VFNet Group Chat
• nostr:naddr1qqrrwvfjx9jxzqfqwaehxw309anhymm4wpejuanpdejx2unhv9exketj9enxzmtfd3usygrzymrpd2wz8ularp06y8ad5dgaddlumyt7tfzqge3vc97sgsarjvpsgqqqnpvq08hx48

"Nostrified Websites"

[D] = Saves darkmode preferences over nostr
[A] = Auth over nostr
[B] = Beta (software)
[z] = zap enabled

• [DABz] Main Site
• [DAB] Contact Site
• [DAB] PGP Site
• [DAB] VFCA Site

---

Other Services (Hosted code)

• Blossom
  
• NostrCheck
  

---

Emojis Packs

• Minecraft
• nostr:naddr1qqy566twv43hyctxwsq37amnwvaz7tmjv4kxz7fwweskuer9wfmkzuntv4ezuenpd45kc7gzyrurn7m8z3vc5u3n6zwm6s40stxf0qwsl2jhga83ssd0jz6ujvynjqcyqqq82nsd0k5wp
• AIM
• nostr:naddr1qqxxz6tdv4kk7arfvdhkuucpramhxue69uhhyetvv9ujuanpdejx2unhv9exketj9enxzmtfd3usyg8c88akw9ze3fer85yah4p2lqkvj7qap749w360rpq6ly94eycf8ypsgqqqw48qe0j2yk
• Blobs
• nostr:naddr1qqz5ymr0vfesz8mhwden5te0wfjkccte9emxzmnyv4e8wctjddjhytnxv9kkjmreqgs0sw0mvu29nznjx0gfm02z47pve9up6ra22ar57xzp47gttjfsjwgrqsqqqa2wek4ukj
• FavEmojis
• nostr:naddr1qqy5vctkg4kk76nfwvq37amnwvaz7tmjv4kxz7fwweskuer9wfmkzuntv4ezuenpd45kc7gzyrurn7m8z3vc5u3n6zwm6s40stxf0qwsl2jhga83ssd0jz6ujvynjqcyqqq82nsf7sdwt
• Modern Family
• nostr:naddr1qqx56mmyv4exugzxv9kkjmreqy0hwumn8ghj7un9d3shjtnkv9hxgetjwashy6m9wghxvctdd9k8jq3qlqulkec5tx98yv7snk759tuzejtcr5865468fuvyrtuskhynpyusxpqqqp65ujlj36n
• nostriches (Amethyst collection)
• nostr:naddr1qq9xummnw3exjcmgv4esz8mhwden5te0wfjkccte9emxzmnyv4e8wctjddjhytnxv9kkjmreqgs0sw0mvu29nznjx0gfm02z47pve9up6ra22ar57xzp47gttjfsjwgrqsqqqa2w2sqg6w
• Pepe
• nostr:naddr1qqz9qetsv5q37amnwvaz7tmjv4kxz7fwweskuer9wfmkzuntv4ezuenpd45kc7gzyrurn7m8z3vc5u3n6zwm6s40stxf0qwsl2jhga83ssd0jz6ujvynjqcyqqq82ns85f6x7
• Minecraft Font
• nostr:naddr1qq8y66twv43hyctxwssyvmmwwsq37amnwvaz7tmjv4kxz7fwweskuer9wfmkzuntv4ezuenpd45kc7gzyrurn7m8z3vc5u3n6zwm6s40stxf0qwsl2jhga83ssd0jz6ujvynjqcyqqq82nsmzftgr
• Archer Font
• nostr:naddr1qq95zunrdpjhygzxdah8gqglwaehxw309aex2mrp0yh8vctwv3jhyampwf4k2u3wvesk66tv0ypzp7peldn3gkv2wgeap8dag2hc9nyhs8g04ft5wnccgxhepdwfxzfeqvzqqqr4fclkyxsh
• SMB Font
• nostr:naddr1qqv4xatsv4ezqntpwf5k7gzzwfhhg6r9wfejq3n0de6qz8mhwden5te0wfjkccte9emxzmnyv4e8wctjddjhytnxv9kkjmreqgs0sw0mvu29nznjx0gfm02z47pve9up6ra22ar57xzp47gttjfsjwgrqsqqqa2w0wqpuk

---

Git Over Nostr

• NostrSMS
• nostr:naddr1qqyxummnw3e8xmtnqy0hwumn8ghj7un9d3shjtnkv9hxgetjwashy6m9wghxvctdd9k8jqfrwaehxw309amk7apwwfjkccte9emxzmnyv4e8wctjddjhytnxv9kkjmreqyj8wumn8ghj7urpd9jzuun9d3shjtnkv9hxgetjwashy6m9wghxvctdd9k8jqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmvqgs0sw0mvu29nznjx0gfm02z47pve9up6ra22ar57xzp47gttjfsjwgrqsqqqaueqp0epk
• nip51backup
• nostr:naddr1qq9ku6tsx5ckyctrdd6hqqglwaehxw309aex2mrp0yh8vctwv3jhyampwf4k2u3wvesk66tv0yqjxamnwvaz7tmhda6zuun9d3shjtnkv9hxgetjwashy6m9wghxvctdd9k8jqfywaehxw309acxz6ty9eex2mrp0yh8vctwv3jhyampwf4k2u3wvesk66tv0yq3gamnwvaz7tmjv4kxz7fwv3sk6atn9e5k7qgdwaehxw309ahx7uewd3hkcq3qlqulkec5tx98yv7snk759tuzejtcr5865468fuvyrtuskhynpyusxpqqqpmej4gtqs6
• bukkitstr
• nostr:naddr1qqykyattdd5hgum5wgq37amnwvaz7tmjv4kxz7fwweskuer9wfmkzuntv4ezuenpd45kc7gpydmhxue69uhhwmm59eex2mrp0yh8vctwv3jhyampwf4k2u3wvesk66tv0yqjgamnwvaz7tmsv95kgtnjv4kxz7fwweskuer9wfmkzuntv4ezuenpd45kc7gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dspzp7peldn3gkv2wgeap8dag2hc9nyhs8g04ft5wnccgxhepdwfxzfeqvzqqqrhnyf6g0n2

---

Market Places

Please use Nostr Market or somthing simular, to view.

• VFStore
• nostr:naddr1qqjx2v34xe3kxvpn95cnqven956rwvpc95unscn9943kxet98q6nxde58p3ryqglwaehxw309aex2mrp0yh8vctwv3jhyampwf4k2u3wvesk66tv0yqjvamnwvaz7tmgv9mx2m3wweskuer9wfmkzuntv4ezuenpd45kc7f0da6hgcn00qqjgamnwvaz7tmsv95kgtnjv4kxz7fwweskuer9wfmkzuntv4ezuenpd45kc7gpydmhxue69uhhwmm59eex2mrp0yh8vctwv3jhyampwf4k2u3wvesk66tv0ypzqeqk78n93wsq6sss0vz6mxl5shr7ge5cy9lqcx0smshpyh0r4uxsqvzqqqr4gvlfm7gu

---

Badges

Created

• paidrelayvf
• nostr:naddr1qq9hqctfv3ex2mrp09mxvqglwaehxw309aex2mrp0yh8vctwv3jhyampwf4k2u3wvesk66tv0ypzp7peldn3gkv2wgeap8dag2hc9nyhs8g04ft5wnccgxhepdwfxzfeqvzqqqr48y85v3u3
• iPow
• nostr:naddr1qqzxj5r02uq37amnwvaz7tmjv4kxz7fwweskuer9wfmkzuntv4ezuenpd45kc7gzyrurn7m8z3vc5u3n6zwm6s40stxf0qwsl2jhga83ssd0jz6ujvynjqcyqqq82wgg02u0r
• codmaster
• nostr:naddr1qqykxmmyd4shxar9wgq37amnwvaz7tmjv4kxz7fwweskuer9wfmkzuntv4ezuenpd45kc7gzyrurn7m8z3vc5u3n6zwm6s40stxf0qwsl2jhga83ssd0jz6ujvynjqcyqqq82wgk3gm4g
• iMine
• nostr:naddr1qqzkjntfdejsz8mhwden5te0wfjkccte9emxzmnyv4e8wctjddjhytnxv9kkjmreqgs0sw0mvu29nznjx0gfm02z47pve9up6ra22ar57xzp47gttjfsjwgrqsqqqafed5s4x5

---

Clients I Use

• Amethyst
• nostr:naddr1qqxnzd3cx5urqv3nxymngdphqgsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqrqsqqql8kavfpw3
• noStrudel
• nostr:naddr1qqxnzd3cxccrvd34xser2dpkqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsygpxdq27pjfppharynrvhg6h8v2taeya5ssf49zkl9yyu5gxe4qg55psgqqq0nmq5mza9n
• nostrsms
• nostr:naddr1qq9rzdejxcunxde4xymqz8mhwden5te0wfjkccte9emxzmnyv4e8wctjddjhytnxv9kkjmreqgsfhcdcx9fy3m4jp7we4vn305t4pe8jwjy74v062vwk08dd6dxzlrgrqsqqql8kjn33qm

---

Lists

• Bluesky
  • nostr:naddr1qvzqqqr4xqpzp7peldn3gkv2wgeap8dag2hc9nyhs8g04ft5wnccgxhepdwfxzfeqys8wumn8ghj7un9d3shjtnkv9hxgetjwashy6m9wghxvctdd9k8jtcqqapxcat9wd4hj0ah0jw
• Fediverse
  • nostr:naddr1qvzqqqr4xqpzp7peldn3gkv2wgeap8dag2hc9nyhs8g04ft5wnccgxhepdwfxzfeqys8wumn8ghj7un9d3shjtnkv9hxgetjwashy6m9wghxvctdd9k8jtcqp9rx2erfwejhyum9j4g0xh
• Fediverse_Bots
  • nostr:naddr1qvzqqqr4xqpzp7peldn3gkv2wgeap8dag2hc9nyhs8g04ft5wnccgxhepdwfxzfeqys8wumn8ghj7un9d3shjtnkv9hxgetjwashy6m9wghxvctdd9k8jtcqperx2erfwejhyum9tapx7arnfcpdzh
• My Bots
  • nostr:naddr1qvzqqqr4xqpzp7peldn3gkv2wgeap8dag2hc9nyhs8g04ft5wnccgxhepdwfxzfeqys8wumn8ghj7un9d3shjtnkv9hxgetjwashy6m9wghxvctdd9k8jtcqz4uh5jnpwscyss24fpkxw4fewafk566twa2q8f6fyk

@ 1bda7e1f:bb97c4d9

Tldr

• Nostr is a new open social protocol for the internet
• You can use it to create your own online community website/app for your users
• This needs only a few simple components that are free and open source
• Jumble.Social client is a front-end for showing your community content to your users
• Simple With Whitelist relay (SW2) is a back-end with simple auth for your community content
• In this blog I explain the components and set up a online community website/app that any community or company can use for their own users, for free.

You Can Run Your Own Private "X" For Free

Nostr is a new open social protocol for the internet. Because it is a protocol it is not controlled by any one company, does not reside on any one set of servers, does not require any licenses, and no one can stop you from using it however you like.

When the name Nostr is recognised, it is as a "Twitter/X alternative" – that is an online open public forum. Nostr is more than just this. The open nature of the protocol means that you can use it however you feel like, including that you can use it for creating your own social websites to suit whatever goals you have – anything from running your own team collaboration app, to running your own online community.

Nostr can be anything – not just an alternative to X, but also to Slack, Teams, Discord, Telegram (etc) – any kind of social app you'd like to run for your users can be run on Nostr.

In this blog I will show you how to launch your own community website, for your community members to use however they like, with low code, and for free.

Simple useful components

Nostr has a few simple components that work together to provide your experience –

• Your "client" – an app or a website front-end that you log into, which displays the content you want to see
• Your "relay" – a server back-end which receives and stores content, and sends it to clients
• Your "user" – a set of keys which represents a user on the network,
• Your "content" – any user content created and signed by a user, distributed to any relay, which can be picked up and viewed by any client.

It is a pattern that is used by every other social app on the internet, excepting that in those cases you can usually only view content in their app, and only post your content to their server.

Vs with Nostr where you can use any client (app) and any relay (server), including your own.

This is defined as a standard in NIP-01 which is simple enough that you can master it in a weekend, and with which you can build any kind of application.

The design space is wide open for anyone to build anything–

• Clones of Twitter, Instagram, Telegram, Medium, Twitch, etc,
• Whole new things like Private Ephemeral Messengers, Social Podcasting Apps, etc,
• Anything else you can dream up, like replacements for B2B SaaS or ERP systems.

Including that you can set up and run your own "X" for your community.

Super powers for –private– social internet

When considering my use of social internet, it is foremost private not public. Email, Whatsapp, Slack, Teams, Discord, Telegram (etc), are all about me, as a user, creating content for a selected group of individuals – close friends, colleagues, community members – not the wider public.

This private social internet is crying out for the kind of powers that Nostr provides. The list of things that Nostr solves for private social internet goes on-and-on.

Let me eat my own dog food for a moment.

• I am a member of a community of technology entrepreneurs with an app for internal community comms. The interface is not fit for this purpose. Good content gets lost. Any content created within the walled kingdom cannot be shared externally. Community members cannot migrate to a different front-end, or cross-post to public social channels.
• I am a member of many communities for kids social groups, each one with a different application and log in. There is no way to view a consolidated feed. There is no way to send one message to many communities, or share content between them. Remembering to check every feed separately is a drag.
• I am a member of a team with an app for team comms. It costs $XXX per user per month where it should be free. I can't self-host. I can't control or export my data. I can't make it interoperate natively with other SaaS. All of my messages probably go to train a Big Co AI without my consent.

In each instance "Nostr fixes this."

Ready now for low-code admins

To date Nostr has been best suited to a more technical user. To use the Nostr protocol directly has been primarily a field of great engineers building great foundations.

IMO these foundations are built. They are open source, free to use, and accessible for anyone who wants to create an administer their own online community, with only low code required.

To prove it, in this blog I will scratch my own itch. I need a X / Slack / Teams alternative to use with a few team members and friends (and a few AIs) as we hack on establishing a new business idea.

I will set this up with Nostr using only open source code, for free.

Designing the Solution

I am mostly non-technical with helpful AI. To set up your own community website in the style of X / Slack / Teams should be possible for anyone with basic technology skills.

• I have a cheap VPS which currently runs some other unrelated Nostr projects in Docker containers,
• My objective was to set up and run my own community website for my own team use, in Docker, hosted on my own server.

User requirements

What will I want from a community website?

• I want my users to be able to log into a website and post content,
• I want to save that content to a server I control accessed only be people I authorise,
• I want my users to view only that content by default, and not be exposed to any wider public social network unless they knowingly select that,
• I want my user's content to be either:
• a) viewable only by other community members (i.e. for internal team comms), or
• b) by the wider public (i.e. for public announcements), at the user's discretion.
• I want it to be open source so that other people maintain the code for me,
• I want it for free.

Nostr solutions

To achieve this with Nostr, I'll need to select some solutions "a-la carte" for each of the core components of the network.

• A client – For my client, I have chosen Jumble. Jumble is a free open-source client by Cody Tseng, available free on Github or at Jumble.social. I have chosen Jumble because it is a "relay-centric" client. In key spots the user interface highlights for the user what relay they are viewing, and what relay they are posting to. As a result, it is a beautiful fit for me to use as the home of all my community content.
• A relay – For my relay, I have chosen Simple With Whitelist (SW2). SW2 is a free open-source relay by Utxo The Webmaster, based on Khatru by Fiatjaf, available free on Github. I have chosen SW2 because it allows for very simple configuration of user auth. Users can be given read access to view notes, and write access to post notes within simple config.json files. This allows you to keep community content private or selectively share it in a variety of ways. Per the Nostr protocol, your client will connect with your relay via websocket.
• A user sign-up flow – Jumble has a user sign-up flow using Nstart by Fiatjaf, or as an admin I can create and provision my own users with any simple tool like NAK or Nostrtool.
• A user content flow – Jumble has a user content flow that can post notes to selected relays of the users choice. Rich media is uploaded to free third-party hosts like Nostr.build, and in the future there is scope to self-host this too.

With each of these boxes ticked I'm ready to start.

Launching a Private Community Website with Jumble and SW2

Install your SW2 relay

The relay is the trickiest part, so let's start there. SW2 is my Nostr relay software of choice. It is a Go application and includes full instructions for Go install. However, I prefer Docker, so I have built a Docker version and maintain a Docker branch here.

1 – In a terminal clone the repo and checkout the Docker branch

git clone https://github.com/r0d8lsh0p/sw2.git cd sw2 git checkout docker

2 – Set up the environment variables

These are specified in the readme. Duplicate the example .env file and fill it with your variables.

cp .env.example .env

For me this .env file was as follows–

```

Relay Metadata

RELAY_NAME="Tbdai relay" RELAY_PUBKEY="ede41352397758154514148b24112308ced96d121229b0e6a66bc5a2b40c03ec" RELAY_DESCRIPTION="An experimental relay for some people and robots working on a TBD AI project." RELAY_URL="wss://assistantrelay.rodbishop.nz" RELAY_ICON="https://image.nostr.build/44654201843fc0f03e9a72fbf8044143c66f0dd4d5350688db69345f9da05007.jpg" RELAY_CONTACT="https://rodbishop.nz" ```

3 – Specify who can read and write to the relay

This is controlled by two config files read_whitelist.json and write_whitelist.json.

• Any user with their pubkey in the read_whitelist can read notes posted to the relay. If empty, anyone can read.
• Any user with their pubkey in the write_whitelist can post notes to the relay. If empty, anyone can write.

We'll get to creating and authorising more users later, for now I suggest to add yourself to each whitelist, by copying your pubkey into each JSON file. For me this looks as follows (note, I use the 'hex' version of the pubkey, rather than the npub)–

{ "pubkeys": [ "1bda7e1f7396bda2d1ef99033da8fd2dc362810790df9be62f591038bb97c4d9" ] }

If this is your first time using Nostr and you don't yet have any user keys, it is easy and free to get one. You can get one from any Nostr client like Jumble.social, any tool like NAK or nostrtool.com or follow a comprehensive guide like my guide on mining a Nostr key.

4 – Launch your relay

If you are using my Docker fork from above, then–

docker compose up

Your relay should now be running on port 3334 and ready to accept web socket connections from your client.

Before you move on to set up the client, it's helpful to quickly test that it is running as expected.

5 – Test your websocket connection

For this I use a tool called wscat to make a websocket connection.

You may need to install wscat, e.g.

npm install -g wscat

And then run it, e.g.

wscat -c ws://localhost:3334

(note use ws:// for localhost, rather than wss://).

If your relay is working successfully then it should receive your websocket connection request and respond with an AUTH token, asking you to identify yourself as a user in the relay's read_whitelist.json (using the standard outlined in NIP-42), e.g.

``` Connected (press CTRL+C to quit) < ["AUTH","13206fea43ef2952"]

```

You do not need to authorise for now.

If you received this kind of message, your relay is working successfully.

Set a subdomain for your relay

Let's connect a domain name so your community members can access your relay.

1 – Configure DNS

At a high level –

1. Get your domain (buy one if you need to)
2. Get the IP address of your VPS
3. In your domain's DNS settings add those records as an A record to the subdomain of your choice, e.g. relay as in relay.your_domain_name.com, or in my case assistantrelay.rodbishop.nz

Your subdomain now points to your server.

2 – Configure reverse proxy

You need to redirect traffic from your subdomain to your relay at port 3334.

On my VPS I use Caddy as a reverse proxy for a few projects, I have it sitting in a separate Docker network. To use it for my SW2 Relay required two steps.

First – I added configuration to Caddy's Caddyfile to tell it what to do with requests for the relay.your_domain_name.com subdomain. For me this looked like–

assistantrelay.rodbishop.nz { reverse_proxy sw2-relay:3334 { # Enable WebSocket support header_up X-Forwarded-For {remote} header_up X-Forwarded-Proto {scheme} header_up X-Forwarded-Port {server_port} } }

Second – I added the Caddy Docker network to the SW2 docker-compose.yml to make it be part of the Caddy network. In my Docker branch, I provide this commented section which you can uncomment and use if you like.

``` services: relay: ... relay configuration here ...

networks:

- caddy # Connect to a Caddy network for reverse proxy

networks:

caddy:

external: true # Connect to a Caddy network for reverse proxy

```

Your relay is now running at your domain name.

Run Jumble.social

Your client set up is very easy, as most heavy lifting is done by your relay. My client of choice is Jumble because it has features that focus the user experience on the community's content first. You have two options for running Jumble.

1. Run your own local copy of Jumble by cloning the Github (optional)
2. Use the public instance at Jumble.social (easier, and what we'll do in this demo)

If you (optionally) want to run your own local copy of Jumble:

git clone https://github.com/CodyTseng/jumble.git cd jumble npm install npm run dev

For this demo, I will just use the public instance at http://jumble.social

Jumble has a very helpful user interface for set up and configuration. But, I wanted to think ahead to onboarding community members, and so instead I will do some work up front in order to give new members a smooth onboarding flow that I would suggest for an administrator to use in onboarding their community.

1 – Create a custom landing page URL for your community members to land on

When your users come to your website for the first time, you want them to get your community experience without any distraction. That will either be–

1. A prompt to sign up or login (if only authorised users can read content)
2. The actual content from your other community members (If all users can read content)

Your landing page URL will look like: http://jumble.social/?r=wss://relay.your_domain_name.com

• http://jumble.social/ – the URL of the Jumble instance you are using
• ?r= – telling Jumble to read from a relay
• wss:// – relays connect via websocket using wss, rather than https
• relay.your_domain_name.com – the domain name of your relay

For me, this URL looks like http://jumble.social/?r=wss://assistantrelay.rodbishop.nz

2 – Visit your custom Jumble URL

This should load the landing page of your relay on Jumble.

In the background, Jumble has attempted to establish a websocket connection to your relay.

If your relay is configured with read authentication, it has sent a challenge to Jumble asking your user to authenticate. Jumble, accordingly should now be showing you a login screen, asking your user to login.

3 – Login or Sign Up

You will see a variety of sign up and login options. To test, log in with the private key that you have configured to have read and write access.

In the background, Jumble has connected via websocket to your relay, checked that your user is authorised to view notes, and if so, has returned all the content on the relay. (If this is your first time here, there would not be any content yet).

If you give this link to your users to use as their landing page, they will land, login, and see only notes from members of your community.

4– Make your first post to your community

Click the "post" button and post a note. Jumble offers you the option to "Send only to relay.your_domain_name.com".

• If set to on, then Jumble will post the note only to your relay, no others. It will also include a specific tag (the "-" tag) which requests relays to not forward the note across the network. Only your community members viewing notes on your community relay can see it.
• If set to off, then Jumble will post the note to your relay and also the wider public Nostr network. Community members viewing notes on the relay can see it, and so can any user of the wider Nostr network.

5– Optional, configure your relay sets

At the top of the screen you should now see a dropdown with the URL of your relay.

Each user can save this relay to a "relay set" for future use, and also view, add or delete other relays sets including some sets which Jumble comes with set up by default.

As an admin you can use this to give users access to multiple relays. And, as a user, you can use this to access posts from multiple different community relays, all within the one client.

Your community website is up and running

That is the basic set up completed.

• You have a website where your community members can visit a URL to post notes and view all notes from all other members of the community.
• You have basic administration to enforce your own read and write permissions very simply in two json files.

Let's check in with my user requirements as a community admin–

• My community is saving content to a server where I control access
• My users view only that content by default, and are not exposed to any wider public social network unless they knowingly select that
• My user's content is a) viewable only by other community members, or b) by the wider public, at the user's discretion
• Other people are maintaining the code for me
• It's free

This setup has scope to solve my dog fooding issues from earlier–

• If adopted, my tech community can iterate the interface to suit its needs, find great content, and share content beyond the community.
• If adopted, my kids social groups can each have their own relays, but I can post to all of them together, or view a consolidated feed.
• If adopted, my team can chat with each other for free. I can self host this. It can natively interoperate with any other Nostr SaaS. It would be entirely private and will not be captured to train a Big Co AI without my consent.

Using your community website in practice

An example onboarding flow

1. A new member joins your IRL community
2. Your admin person gives them your landing page URL where they can view all the posts by your community members – If you have configured your relay to have no read auth required, then they can land on that landing page and immediately start viewing your community's posts, a great landing experience
3. The user user creates a Nostr profile, and provides the admin person with their public key
4. The admin person adds their key to the whitelists to read and write as you desire.

Default inter-op with the wider Nostr network

• If you change your mind on SW2 and want to use a different relay, your notes will be supported natively, and you can migrate on your own terms
• If you change your mind on Jumble and want to use a different client, your relay will be supported natively, and you can migrate on your own terms
• If you want to add other apps to your community's experience, every Nostr app will interoperate with your community by default – see the huge list at Awesome Nostr
• If any of your users want to view your community notes inside some other Nostr client – perhaps to see a consolidated feed of notes from all their different communities – they can.

For me, I use Amethyst app as my main Nostr client to view the public posts from people I follow. I have added my private community relay to Amethyst, and now my community posts appear alongside all these other posts in a single consolidated feed.

Scope to further improve

• You can run multiple different relays with different user access – e.g. one for wider company and one for your team
• You can run your own fork of Jumble and change the interface to suit you needs – e.g. add your logo, change the colours, link to other resources from the sidebar.

Other ideas for running communities

• Guest accounts: You can give a user "guest" access – read auth, but no write auth – to help people see the value of your community before becoming members.
• Running a knowledge base: You can whitelist users to read notes, but only administrators can post notes.
• Running a blind dropbox: You can whitelist users to post notes, but only the administrator can read notes.
• Running on a local terminal only: With Jumble and SW2 installed on a machine, running at – localhost:5173 for Jumble, and localhost:3334 for SW2 you can have an entirely local experience at http://localhost:5173/?r=ws://localhost:3334.

What's Next?

In my first four blogs I explored creating a good Nostr setup with Vanity Npub, Lightning Payments, Nostr Addresses at Your Domain, and Personal Nostr Relay.

Then in my latest three blogs I explored different types of interoperability with NFC cards, n8n Workflow Automation, and now running a private community website on Nostr.

For this community website–

• There is scope to make some further enhancements to SW2, including to add a "Blossom" media server so that community admins can self-host their own rich media, and to create an admin screen for administration of the whitelists using NIP-86.
• There is scope to explore all other kinds of Nostr clients to form the front-end of community websites, including Chachi.chat, Flotilla, and others.
• Nostr includes a whole variety of different optional standards for making more elaborate online communities including NIP-28, NIP-29, NIP-17, NIP-72 (etc). Each gives certain different capabilities, and I haven't used any of them! For this simple demo they are not required, but each could be used to extend the capabilities of the admin and community.

I am also doing a lot of work with AI on Nostr, including that I use my private community website as a front-end for engaging with a Nostr AI. I'll post about this soon too.

Please be sure to let me know if you think there's another Nostr topic you'd like to see me tackle.

GM Nostr.

@ 177bfd16:347a07e4

So , you've battles through your way through countless Grunts , overcome the Team GO Rocket Leaders, and now you stand face to face with the big boss him self - Giovanni!

As of April 2025 , Giovanni is finishing his battles with Shadow Palkia.

Giovanni's Current Lineup (April 2025) First, know your enemy. Giovanni's team follows this structure:

Slot 1: Shadow Persian (Normal)

Slot 2: One of these three, chosen randomly:

Shadow Nidoking (Poison/Ground) Shadow Kingdra (Water/Dragon) Shadow Rhyperior (Rock/Ground)

Slot 3: Shadow Palkia (Water/Dragon) Remember, these are Shadow Pokémon – they hit harder than their normal counterparts!

Counter Strategy: Beating Giovanni Pokémon by Pokémon

Let's dive into the best counters for each potential opponent:

1. Vs. Shadow Persian (Normal)

Giovanni always leads with Persian. As a Normal-type, it's weak only to Fighting-type attacks.

Top Counters: Machamp, Lucario, Conkeldurr, Terrakion, Mega Blaziken, Mega Lucario.

Moves: Prioritize Fighting-type moves like Counter, Dynamic Punch, Aura Sphere, and Sacred Sword.

Tip: Lead with a strong Fighting-type. Moves like Lucario's Power-Up Punch or Machamp's Cross Chop charge quickly and are great for baiting Giovanni's shields early!

1. Vs. The Second Slot (Nidoking, Kingdra, or Rhyperior)

This is where things get unpredictable. You need Pokémon that can handle these potential threats:

Vs. Shadow Nidoking (Poison/Ground): Weak to Water, Ground, Ice, Psychic.

Counters: Kyogre (Primal/Shadow), Swampert (Mega), Groudon (Primal/Shadow), Mewtwo (Shadow), Excadrill. Water and Ground-types are prime choices.

Vs. Shadow Kingdra (Water/Dragon): Weak to Fairy, Dragon. Counters: Gardevoir (Mega), Togekiss, Xerneas. Fairy-types are excellent as they resist Dragon attacks while dealing super-effective damage. Dragon-types like Rayquaza or Palkia work but are risky.

Vs. Shadow Rhyperior (Rock/Ground): Double weak to Water and Grass! Also weak to Fighting, Ground, Ice, Steel.

Counters: Kyogre (Primal/Shadow), Swampert (Mega), Sceptile (Mega), Roserade. Your Fighting-type lead (if it survived Persian) can also do significant damage. Hit it hard with Water or Grass!

1. Vs. Shadow Palkia (Water/Dragon)

Giovanni's final Pokémon is the powerful Shadow Palkia. Like Kingdra, it's weak to Fairy and Dragon types.

Top Counters: Gardevoir (Mega), Togekiss, Xerneas. Again, Fairy-types are the safest and most reliable counters.

Dragon Counters (Use with Caution): Rayquaza (Mega), Palkia (Origin Forme), Dragonite, Dialga (Origin Forme).

Recommended Battle Teams for April 2025 Based on the counters, here are a few effective teams you can assemble:

Team 1 (Balanced):

Machamp (Counter / Cross Chop & Dynamic Punch)

Swampert (Mud Shot / Hydro Cannon & Earthquake)

Togekiss (Charm / Dazzling Gleam & Ancient Power)

Why it works: Covers all bases well with accessible Pokémon. Machamp handles Persian/shields, Swampert crushes Rhyperior/Nidoking, Togekiss tackles Kingdra/Palkia.

Team 2 (Legendary Power):

Lucario (Counter / Power-Up Punch & Aura Sphere)

Kyogre (Waterfall / Origin Pulse & Surf)

Xerneas (Geomancy / Moonblast & Close Combat)

Why it works: High-powered options. Lucario baits shields effectively, Kyogre dominates slot two's Ground/Rock types, Xerneas shreds the Dragons.

Team 3 (Mega Advantage):

Machamp (Counter / Cross Chop & DP)

Kyogre (Waterfall / Origin Pulse)

Mega Gardevoir (Charm / Dazzling Gleam & Shadow Ball)

Why it works: Uses a standard strong lead and mid-game counter, saving the Mega slot for Gardevoir to ensure a powerful finish against Palkia/Kingdra.

Essential Battle Tips Don't forget these crucial tactics:

The Switch Trick: Place your intended starting Pokémon (e.g., Machamp) in the second or third slot. Start the battle, then immediately switch to it. Giovanni will pause for a moment, letting you get in free hits!

Bait Those Shields: Use Pokémon with fast-charging Charged Moves, especially early on, to force Giovanni to waste his Protect Shields.

Power Up: Ensure your team is powered up significantly and consider unlocking second Charged Moves for better flexibility.

Don't Give Up: Giovanni is tough! It might take a few tries to get the right matchup against his second Pokémon. Learn from each attempt and adjust your team if needed.

Go show the boss who's the boss and claim your shadow Palkia . Good Luck, Trainer !

@ 9223d2fa:b57e3de7

12,600 steps

@ 91bea5cd:1df4451c

O Contexto Legal Brasileiro e o Consentimento

No ordenamento jurídico brasileiro, o consentimento do ofendido pode, em certas circunstâncias, afastar a ilicitude de um ato que, sem ele, configuraria crime (como lesão corporal leve, prevista no Art. 129 do Código Penal). Contudo, o consentimento tem limites claros: não é válido para bens jurídicos indisponíveis, como a vida, e sua eficácia é questionável em casos de lesões corporais graves ou gravíssimas.

A prática de BDSM consensual situa-se em uma zona complexa. Em tese, se ambos os parceiros são adultos, capazes, e consentiram livre e informadamente nos atos praticados, sem que resultem em lesões graves permanentes ou risco de morte não consentido, não haveria crime. O desafio reside na comprovação desse consentimento, especialmente se uma das partes, posteriormente, o negar ou alegar coação.

A Lei Maria da Penha (Lei nº 11.340/2006)

A Lei Maria da Penha é um marco fundamental na proteção da mulher contra a violência doméstica e familiar. Ela estabelece mecanismos para coibir e prevenir tal violência, definindo suas formas (física, psicológica, sexual, patrimonial e moral) e prevendo medidas protetivas de urgência.

Embora essencial, a aplicação da lei em contextos de BDSM pode ser delicada. Uma alegação de violência por parte da mulher, mesmo que as lesões ou situações decorram de práticas consensuais, tende a receber atenção prioritária das autoridades, dada a presunção de vulnerabilidade estabelecida pela lei. Isso pode criar um cenário onde o parceiro masculino enfrenta dificuldades significativas em demonstrar a natureza consensual dos atos, especialmente se não houver provas robustas pré-constituídas.

Outros riscos:

Lesão corporal grave ou gravíssima (art. 129, §§ 1º e 2º, CP), não pode ser justificada pelo consentimento, podendo ensejar persecução penal.

Crimes contra a dignidade sexual (arts. 213 e seguintes do CP) são de ação pública incondicionada e independem de representação da vítima para a investigação e denúncia.

Riscos de Falsas Acusações e Alegação de Coação Futura

Os riscos para os praticantes de BDSM, especialmente para o parceiro que assume o papel dominante ou que inflige dor/restrição (frequentemente, mas não exclusivamente, o homem), podem surgir de diversas frentes:

1. Acusações Externas: Vizinhos, familiares ou amigos que desconhecem a natureza consensual do relacionamento podem interpretar sons, marcas ou comportamentos como sinais de abuso e denunciar às autoridades.
2. Alegações Futuras da Parceira: Em caso de término conturbado, vingança, arrependimento ou mudança de perspectiva, a parceira pode reinterpretar as práticas passadas como abuso e buscar reparação ou retaliação através de uma denúncia. A alegação pode ser de que o consentimento nunca existiu ou foi viciado.
3. Alegação de Coação: Uma das formas mais complexas de refutar é a alegação de que o consentimento foi obtido mediante coação (física, moral, psicológica ou econômica). A parceira pode alegar, por exemplo, que se sentia pressionada, intimidada ou dependente, e que seu "sim" não era genuíno. Provar a ausência de coação a posteriori é extremamente difícil.
4. Ingenuidade e Vulnerabilidade Masculina: Muitos homens, confiando na dinâmica consensual e na parceira, podem negligenciar a necessidade de precauções. A crença de que "isso nunca aconteceria comigo" ou a falta de conhecimento sobre as implicações legais e o peso processual de uma acusação no âmbito da Lei Maria da Penha podem deixá-los vulneráveis. A presença de marcas físicas, mesmo que consentidas, pode ser usada como evidência de agressão, invertendo o ônus da prova na prática, ainda que não na teoria jurídica.

Estratégias de Prevenção e Mitigação

Não existe um método infalível para evitar completamente o risco de uma falsa acusação, mas diversas medidas podem ser adotadas para construir um histórico de consentimento e reduzir vulnerabilidades:

1. Comunicação Explícita e Contínua: A base de qualquer prática BDSM segura é a comunicação constante. Negociar limites, desejos, palavras de segurança ("safewords") e expectativas antes, durante e depois das cenas é crucial. Manter registros dessas negociações (e-mails, mensagens, diários compartilhados) pode ser útil.

2. Documentação do Consentimento:

   • Contratos de Relacionamento/Cena: Embora a validade jurídica de "contratos BDSM" seja discutível no Brasil (não podem afastar normas de ordem pública), eles servem como forte evidência da intenção das partes, da negociação detalhada de limites e do consentimento informado. Devem ser claros, datados, assinados e, idealmente, reconhecidos em cartório (para prova de data e autenticidade das assinaturas).

   • Registros Audiovisuais: Gravar (com consentimento explícito para a gravação) discussões sobre consentimento e limites antes das cenas pode ser uma prova poderosa. Gravar as próprias cenas é mais complexo devido a questões de privacidade e potencial uso indevido, mas pode ser considerado em casos específicos, sempre com consentimento mútuo documentado para a gravação.

     Importante: a gravação deve ser com ciência da outra parte, para não configurar violação da intimidade (art. 5º, X, da Constituição Federal e art. 20 do Código Civil).

3. Testemunhas: Em alguns contextos de comunidade BDSM, a presença de terceiros de confiança durante negociações ou mesmo cenas pode servir como testemunho, embora isso possa alterar a dinâmica íntima do casal.

4. Estabelecimento Claro de Limites e Palavras de Segurança: Definir e respeitar rigorosamente os limites (o que é permitido, o que é proibido) e as palavras de segurança é fundamental. O desrespeito a uma palavra de segurança encerra o consentimento para aquele ato.
5. Avaliação Contínua do Consentimento: O consentimento não é um cheque em branco; ele deve ser entusiástico, contínuo e revogável a qualquer momento. Verificar o bem-estar do parceiro durante a cena ("check-ins") é essencial.
6. Discrição e Cuidado com Evidências Físicas: Ser discreto sobre a natureza do relacionamento pode evitar mal-entendidos externos. Após cenas que deixem marcas, é prudente que ambos os parceiros estejam cientes e de acordo, talvez documentando por fotos (com data) e uma nota sobre a consensualidade da prática que as gerou.
7. Aconselhamento Jurídico Preventivo: Consultar um advogado especializado em direito de família e criminal, com sensibilidade para dinâmicas de relacionamento alternativas, pode fornecer orientação personalizada sobre as melhores formas de documentar o consentimento e entender os riscos legais específicos.

Observações Importantes

• Nenhuma documentação substitui a necessidade de consentimento real, livre, informado e contínuo.
• A lei brasileira protege a "integridade física" e a "dignidade humana". Práticas que resultem em lesões graves ou que violem a dignidade de forma não consentida (ou com consentimento viciado) serão ilegais, independentemente de qualquer acordo prévio.
• Em caso de acusação, a existência de documentação robusta de consentimento não garante a absolvição, mas fortalece significativamente a defesa, ajudando a demonstrar a natureza consensual da relação e das práticas.

• A alegação de coação futura é particularmente difícil de prevenir apenas com documentos. Um histórico consistente de comunicação aberta (whatsapp/telegram/e-mails), respeito mútuo e ausência de dependência ou controle excessivo na relação pode ajudar a contextualizar a dinâmica como não coercitiva.

• Cuidado com Marcas Visíveis e Lesões Graves Práticas que resultam em hematomas severos ou lesões podem ser interpretadas como agressão, mesmo que consentidas. Evitar excessos protege não apenas a integridade física, mas também evita questionamentos legais futuros.

O que vem a ser consentimento viciado

No Direito, consentimento viciado é quando a pessoa concorda com algo, mas a vontade dela não é livre ou plena — ou seja, o consentimento existe formalmente, mas é defeituoso por alguma razão.

O Código Civil brasileiro (art. 138 a 165) define várias formas de vício de consentimento. As principais são:

Erro: A pessoa se engana sobre o que está consentindo. (Ex.: A pessoa acredita que vai participar de um jogo leve, mas na verdade é exposta a práticas pesadas.)

Dolo: A pessoa é enganada propositalmente para aceitar algo. (Ex.: Alguém mente sobre o que vai acontecer durante a prática.)

Coação: A pessoa é forçada ou ameaçada a consentir. (Ex.: "Se você não aceitar, eu termino com você" — pressão emocional forte pode ser vista como coação.)

Estado de perigo ou lesão: A pessoa aceita algo em situação de necessidade extrema ou abuso de sua vulnerabilidade. (Ex.: Alguém em situação emocional muito fragilizada é induzida a aceitar práticas que normalmente recusaria.)

No contexto de BDSM, isso é ainda mais delicado: Mesmo que a pessoa tenha "assinado" um contrato ou dito "sim", se depois ela alegar que seu consentimento foi dado sob medo, engano ou pressão psicológica, o consentimento pode ser considerado viciado — e, portanto, juridicamente inválido.

Isso tem duas implicações sérias:

1. O crime não se descaracteriza: Se houver vício, o consentimento é ignorado e a prática pode ser tratada como crime normal (lesão corporal, estupro, tortura, etc.).

2. A prova do consentimento precisa ser sólida: Mostrando que a pessoa estava informada, lúcida, livre e sem qualquer tipo de coação.

   Consentimento viciado é quando a pessoa concorda formalmente, mas de maneira enganada, forçada ou pressionada, tornando o consentimento inútil para efeitos jurídicos.

Conclusão

Casais que praticam BDSM consensual no Brasil navegam em um terreno que exige não apenas confiança mútua e comunicação excepcional, mas também uma consciência aguçada das complexidades legais e dos riscos de interpretações equivocadas ou acusações mal-intencionadas. Embora o BDSM seja uma expressão legítima da sexualidade humana, sua prática no Brasil exige responsabilidade redobrada. Ter provas claras de consentimento, manter a comunicação aberta e agir com prudência são formas eficazes de se proteger de falsas alegações e preservar a liberdade e a segurança de todos os envolvidos. Embora leis controversas como a Maria da Penha sejam "vitais" para a proteção contra a violência real, os praticantes de BDSM, e em particular os homens nesse contexto, devem adotar uma postura proativa e prudente para mitigar os riscos inerentes à potencial má interpretação ou instrumentalização dessas práticas e leis, garantindo que a expressão de sua consensualidade esteja resguardada na medida do possível.

---

Importante: No Brasil, mesmo com tudo isso, o Ministério Público pode denunciar por crime como lesão corporal grave, estupro ou tortura, independente de consentimento. Então a prudência nas práticas é fundamental.

Aviso Legal: Este artigo tem caráter meramente informativo e não constitui aconselhamento jurídico. As leis e interpretações podem mudar, e cada situação é única. Recomenda-se buscar orientação de um advogado qualificado para discutir casos específicos.

Se curtiu este artigo faça uma contribuição, se tiver algum ponto relevante para o artigo deixe seu comentário.

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

@ 7bdef7be:784a5805

The following script try, using nak, to find out the last ten people who have followed a target_pubkey, sorted by the most recent. It's possibile to shorten search_timerange to speed up the search.

```

!/usr/bin/env fish

Target pubkey we're looking for in the tags

set target_pubkey "6e468422dfb74a5738702a8823b9b28168abab8655faacb6853cd0ee15deee93"

set current_time (date +%s) set search_timerange (math $current_time - 600) # 24 hours = 86400 seconds

set pubkeys (nak req --kind 3 -s $search_timerange wss://relay.damus.io/ wss://nos.lol/ 2>/dev/null | \ jq -r --arg target "$target_pubkey" ' select(. != null and type == "object" and has("tags")) | select(.tags[] | select(.[0] == "p" and .[1] == $target)) | .pubkey ' | sort -u)

if test -z "$pubkeys" exit 1 end

set all_events "" set extended_search_timerange (math $current_time - 31536000) # One year

for pubkey in $pubkeys echo "Checking $pubkey" set events (nak req --author $pubkey -l 5 -k 3 -s $extended_search_timerange wss://relay.damus.io wss://nos.lol 2>/dev/null | \ jq -c --arg target "$target_pubkey" ' select(. != null and type == "object" and has("tags")) | select(.tags[][] == $target) ' 2>/dev/null)

set count (echo "$events" | jq -s 'length')

if test "$count" -eq 1
    set all_events $all_events $events
end

end

if test -n "$all_events" echo -e "Last people following $target_pubkey:" echo -e ""

set sorted_events (printf "%s\n" $all_events | jq -r -s '
unique_by(.id) |
sort_by(-.created_at) |
.[] | @json
')

for event in $sorted_events
    set npub (echo $event | jq -r '.pubkey' | nak encode npub)
    set created_at (echo $event | jq -r '.created_at')
    if test (uname) = "Darwin"
        set follow_date (date -r "$created_at" "+%Y-%m-%d %H:%M")
    else
        set follow_date (date -d @"$created_at" "+%Y-%m-%d %H:%M")
    end
    echo "$follow_date - $npub"
end

end ```

@ d34e832d:383f78d0

Introduction

Unlike other cetaceans that rely on whistles and songs, sperm whales primarily use echolocation and patterned click sequences to convey information. This paper explores the structure, function, and implications of their vocal communication, particularly in relation to their social behaviors and cognitive abilities.

1. The Nature of Sperm Whale Vocalizations

Sperm whales produce three primary types of clicks:
- Echolocation clicks for navigation and hunting.
- Regular clicks used in deep diving.
- Codas, which are rhythmic sequences exchanged between individuals, believed to function in social bonding and identification.

Each whale possesses a monumental sound-producing organ, the spermaceti organ, which allows for the production of powerful sounds that can travel long distances. The structure of these clicks suggests a level of vocal learning and adaptation, as different populations exhibit distinct coda repertoires.

2. Cultural and Regional Variation in Codas

Research indicates that different sperm whale clans have unique dialects, much like human languages. These dialects are not genetically inherited but culturally transmitted, meaning whales learn their communication styles from social interactions rather than instinct alone. Studies conducted in the Caribbean and the Pacific have revealed that whales in different regions have distinct coda patterns, with some being universal and others specific to certain clans.

3. Social Organization and Communication

Sperm whales are matrilineal and live in stable social units composed of mothers, calves, and juveniles, while males often lead solitary lives. Communication plays a critical role in maintaining social bonds within these groups.
- Codas serve as an acoustic signature that helps individuals recognize each other.
- More complex codas may function in coordinating group movements or teaching young whales.
- Some researchers hypothesize that codas convey emotional states, much like tone of voice in human speech.

4. Theories on Whale Intelligence and Language-Like Communication

The complexity of sperm whale vocalization raises profound questions about their cognitive abilities.
- Some researchers argue that sperm whale communication exhibits combinatorial properties, meaning that codas might function in ways similar to human phonemes, allowing for an extensive range of meanings.
- Studies using AI and machine learning have attempted to decode potential syntax patterns, but a full understanding of their language remains elusive.

5. Conservation Implications and the Need for Further Research

Understanding sperm whale communication is essential for conservation efforts. Noise pollution from shipping, sonar, and industrial activities can interfere with whale vocalizations, potentially disrupting social structures and navigation. Future research must focus on long-term coda tracking, cross-species comparisons, and experimental approaches to deciphering their meaning.

Consider

Sperm whale vocal communication represents one of the most intriguing areas of marine mammal research. Their ability to transmit learned vocalizations across generations suggests a high degree of cultural complexity. Although we have yet to fully decode their language, the study of sperm whale codas offers critical insights into non-human intelligence, social structures, and the evolution of communication in the animal kingdom.

@ 7bdef7be:784a5805

We value sovereignty, privacy and security when accessing online content, using several tools to achieve this, like open protocols, open OSes, open software products, Tor and VPNs.

The problem

Talking about our social presence, we can manually build up our follower list (social graph), pick a Nostr client that is respectful of our preferences on what to show and how, but with the standard following mechanism, our main feed is public, so everyone can actually snoop what we are interested in, and what is supposable that we read daily.

The solution

Nostr has a simple solution for this necessity: encrypted lists. Lists are what they appear, a collection of people or interests (but they can also group much other stuff, see NIP-51). So we can create lists with contacts that we don't have in our main social graph; these lists can be used primarily to create dedicated feeds, but they could have other uses, for example, related to monitoring. The interesting thing about lists is that they can also be encrypted, so unlike the basic following list, which is always public, we can hide the lists' content from others. The implications are obvious: we can not only have a more organized way to browse content, but it is also really private one.

One might wonder what use can really be made of private lists; here are some examples:

• Browse “can't miss” content from users I consider a priority;
• Supervise competitors or adversarial parts;
• Monitor sensible topics (tags);
• Following someone without being publicly associated with them, as this may be undesirable;

The benefits in terms of privacy as usual are not only related to the casual, or programmatic, observer, but are also evident when we think of how many bots scan our actions to profile us.

The current state

Unfortunately, lists are not widely supported by Nostr clients, and encrypted support is a rarity. Often the excuse to not implement them is that they are harder to develop, since they require managing the encryption stuff (NIP-44). Nevertheless, developers have an easier option to start offering private lists: give the user the possibility to simply mark them as local-only, and never push them to the relays. Even if the user misses the sync feature, this is sufficient to create a private environment.

To date, as far as I know, the best client with list management is Gossip, which permits to manage both encrypted and local-only lists.

Beg your Nostr client to implement private lists!

@ 7bdef7be:784a5805

I wrote Oracolo (see the announcement below) because I was brainstorming about Nostr "long format" and thinking about how to promote it. There seems to be little love for this format, why?
Long posts should have interesting value because the author usually put effort into them, and are produced for a long-term fruition. In the end, blogging was one of the most productive strands on the web, and still holds considerable importance.

But in standard (kind-1) social clients they are rather hidden. I think many people don't even know they exist, they probably intuit something just because they see a particular formatting. This is quite evident if you compare the responses/zaps/reactions of the short notes with the long ones, the latter have far fewer interactions, a fact that I read as less exposure to readers.

Interlude: don't know what this "long format" stuff is?
Check https://habla.news or https://highlighter.com

I think the situation can be largely improved with some adjustments in kind-1 clients:

• Add a tab/section to the user's profile, next to the usual posts/responses, that lists only the long format notes;
• Highlight/pinning recent long notes in the user's profile to give them visibility; the user picture could also have a special mark that alerts about fresh content available;
• In the feed show the preview of long notes with a special design, and allow the user to read them in a separate/immersive view (or just link to njump.me);
• In an appropriate context (es. at the footer of a long note) invite the user to discover long format and post his own content;
• Offer a filtered feed that display only long format notes;

Finally, we should probably also evaluate and agree on a new labeling in clients, because “long notes” is self-explanatory but also a bit confusing next to "plain notes”. Perhaps “articles” might be a better term.

If clients bring more interaction on articles, content creators are naturally incentivized to invest their time in this area, thus increasing the production of in-depth content that may be of interest even to those who are not as involved in social media dynamics.

Memo for kind-1 clients: interoperability is our superpower and currently your are the main entrance to Nostr, so don't be fearful or lazy, please embrace it.

nostr:nevent1qqsrrcl7sfaxd505lyezj7u54tpdg93x0swpcpe0xj5adax5l6xz3yspzamhxue69uhky6t5vdhkjmn9wgh8xmmrd9skctcpr3mhxue69uhkxmm4de68y6t9wvhxv6tpw34xze3wvdhk6tcppemhxue69uhkummn9ekx7mp0aagyzp

nostrdesign

@ 16f1a010:31b1074b

grain is a nostr relay built using Go, currently utilizing MongoDB as its database. Binaries are provided for AMD64 Windows and Linux. grain is Go Relay Architecture for Implementing Nostr

Introduction

grain is a nostr relay built using Go, currently utilizing MongoDB as its database. Binaries are provided for AMD64 Windows and Linux. grain is Go Relay Architecture for Implementing Nostr

Prerequisites

• Grain requires a running MongoDB instance. Please refer to this separate guide for instructions on setting up MongoDB: nostr:naddr1qvzqqqr4gupzq9h35qgq6n8ll0xyyv8gurjzjrx9sjwp4hry6ejnlks8cqcmzp6tqqxnzde5xg6rwwp5xsuryd3knfdr7g

Download Grain

Download the latest release for your system from the GitHub releases page

amd64 binaries provided for Windows and Linux, if you have a different CPU architecture, you can download and install go to build grain from source

Installation and Execution

• Create a new folder on your system where you want to run Grain.
• The downloaded binary comes bundled with a ZIP file containing a folder named "app," which holds the frontend HTML files. Unzip the "app" folder into the same directory as the Grain executable.

Run Grain

• Open your terminal or command prompt and navigate to the Grain directory.
• Execute the Grain binary.

on linux you will first have to make the program executable

chmod +x grain_linux_amd64

Then you can run the program

./grain_linux_amd64

(alternatively on windows, you can just double click the grain_windows_amd64.exe to start the relay)

You should see a terminal window displaying the port on which your relay and frontend are running.

If you get

Failed to copy app/static/examples/config.example.yml to config.yml: open app/static/examples/config.example.yml: no such file or directory

Then you probably forgot to put the app folder in the same directory as your executable or you did not unzip the folder.

Congrats! You're running grain 🌾!

You may want to change your NIP11 relay information document (relay_metadata.json) This informs clients of the capabilities, administrative contacts, and various server attributes. It's located in the same directory as your executable.

Configuration Files

Once Grain has been executed for the first time, it will generate the default configuration files inside the directory where the executable is located. These files are:

bash config.yml whitelist.yml blacklist.yml

Prerequisites: - Grain requires a running MongoDB instance. Please refer to this separate guide for instructions on setting up MongoDB: [Link to MongoDB setup guide].

Download Grain:

Download the latest release for your system from the GitHub releases page

amd64 binaries provided for Windows and Linux, if you have a different CPU architecture, you can download and install go to build grain from source

Installation and Execution:

• Create a new folder on your system where you want to run Grain.
• The downloaded binary comes bundled with a ZIP file containing a folder named "app," which holds the frontend HTML files. Unzip the "app" folder into the same directory as the Grain executable.

Run Grain:

• Open your terminal or command prompt and navigate to the Grain directory.
• Execute the Grain binary.

on linux you will first have to make the program executable

chmod +x grain_linux_amd64

Then you can run the program

./grain_linux_amd64

(alternatively on windows, you can just double click the grain_windows_amd64.exe to start the relay)

You should see a terminal window displaying the port on which your relay and frontend are running.

If you get

Failed to copy app/static/examples/config.example.yml to config.yml: open app/static/examples/config.example.yml: no such file or directory

Then you probably forgot to put the app folder in the same directory as your executable or you did not unzip the folder.

Congrats! You're running grain 🌾!

You may want to change your NIP11 relay information document (relay_metadata.json) This informs clients of the capabilities, administrative contacts, and various server attributes. It's located in the same directory as your executable.

Configuration Files:

Once Grain has been executed for the first time, it will generate the default configuration files inside the directory where the executable is located. These files are:

bash config.yml whitelist.yml blacklist.yml

Configuration Documentation

You can always find the latest example configs on my site or in the github repo here: config.yml

whitelist.yml

blacklist.yml

Config.yml

This config.yml file is where you customize how your Grain relay operates. Each section controls different aspects of the relay's behavior.

1. mongodb (Database Settings)

• uri: mongodb://localhost:27017/:
  • This is the connection string for your MongoDB database.
  • mongodb://localhost:27017/ indicates that your MongoDB server is running on the same computer as your Grain relay (localhost) and listening on port 27017 (the default MongoDB port).
  • If your MongoDB server is on a different machine, you'll need to change localhost to the server's IP address or hostname.
  • The trailing / indicates the root of the mongodb server. You will define the database in the next line.
• database: grain:
  • This specifies the name of the MongoDB database that Grain will use to store Nostr events. Grain will create this database if it doesn't already exist.
  • You can name the database whatever you want. If you want to run multiple grain relays, you can and they can have different databases running on the same mongo server.

2. server (Relay Server Settings)

• port: :8181:
  • This sets the port on which your Grain relay will listen for incoming nostr websocket connections and what port the frontend will be available at.
• read_timeout: 10 # in seconds:
  • This is the maximum time (in seconds) that the relay will wait for a client to send data before closing the connection.
• write_timeout: 10 # in seconds:
  • This is the maximum time (in seconds) that the relay will wait for a client to receive data before closing the connection.
• idle_timeout: 120 # in seconds:
  • This is the maximum time (in seconds) that the relay will keep a connection open if there's no activity.
• max_connections: 100:
  • This sets the maximum number of simultaneous client connections that the relay will allow.
• max_subscriptions_per_client: 10:
  • This sets the maximum amount of subscriptions a single client can request from the relay.

3. resource_limits (System Resource Limits)

• cpu_cores: 2 # Limit the number of CPU cores the application can use:
  • This restricts the number of CPU cores that Grain can use. Useful for controlling resource usage on your server.
• memory_mb: 1024 # Cap the maximum amount of RAM in MB the application can use:
  • This limits the maximum amount of RAM (in megabytes) that Grain can use.
• heap_size_mb: 512 # Set a limit on the Go garbage collector's heap size in MB:
  • This sets a limit on the amount of memory that the Go programming language's garbage collector can use.

4. auth (Authentication Settings)

• enabled: false # Enable or disable AUTH handling:
  • If set to true, this enables authentication handling, requiring clients to authenticate before using the relay.
• relay_url: "wss://relay.example.com/" # Specify the relay URL:
  • If authentication is enabled, this is the url that clients will use to authenticate.

5. UserSync (User Synchronization)

• user_sync: false:
  • If set to true, the relay will attempt to sync user data from other relays.
• disable_at_startup: true:
  • If user sync is enabled, this will prevent the sync from starting when the relay starts.
• initial_sync_relays: [...]:
  • A list of other relays to pull user data from.
• kinds: []:
  • A list of event kinds to pull from the other relays. Leaving this empty will pull all event kinds.
• limit: 100:
  • The limit of events to pull from the other relays.
• exclude_non_whitelisted: true:
  • If set to true, only users on the whitelist will have their data synced.
• interval: 360:
  • The interval in minutes that the relay will resync user data.

6. backup_relay (Backup Relay)

• enabled: false:
  • If set to true, the relay will send copies of received events to the backup relay.
• url: "wss://some-relay.com":
  • The url of the backup relay.

7. event_purge (Event Purging)

• enabled: false:
  • If set to true, the relay will automatically delete old events.
• keep_interval_hours: 24:
  • The number of hours to keep events before purging them.
• purge_interval_minutes: 240:
  • How often (in minutes) the purging process runs.
• purge_by_category: ...:
  • Allows you to specify which categories of events (regular, replaceable, addressable, deprecated) to purge.
• purge_by_kind_enabled: false:
  • If set to true, events will be purged based on the kinds listed below.
• kinds_to_purge: ...:
  • A list of event kinds to purge.
• exclude_whitelisted: true:
  • If set to true, events from whitelisted users will not be purged.

8. event_time_constraints (Event Time Constraints)

• min_created_at: 1577836800:
  • The minimum created_at timestamp (Unix timestamp) that events must have to be accepted by the relay.
• max_created_at_string: now+5m:
  • The maximum created at time that an event can have. This example shows that the max created at time is 5 minutes in the future from the time the event is received.
  • min_created_at_string and max_created_at work the same way.

9. rate_limit (Rate Limiting)

• ws_limit: 100:
  • The maximum number of WebSocket messages per second that the relay will accept.
• ws_burst: 200:
  • Allows a temporary burst of WebSocket messages.
• event_limit: 50:
  • The maximum number of Nostr events per second that the relay will accept.
• event_burst: 100:
  • Allows a temporary burst of Nostr events.
• req_limit: 50:
  • The limit of http requests per second.
• req_burst: 100:
  • The allowed burst of http requests.
• max_event_size: 51200:
  • The maximum size (in bytes) of a Nostr event that the relay will accept.
• kind_size_limits: ...:
  • Allows you to set size limits for specific event kinds.
• category_limits: ...:
  • Allows you to set rate limits for different event categories (ephemeral, addressable, regular, replaceable).
• kind_limits: ...:
  • Allows you to set rate limits for specific event kinds.

By understanding these settings, you can tailor your Grain Nostr relay to meet your specific needs and resource constraints.

whitelist.yml

The whitelist.yml file is used to control which users, event kinds, and domains are allowed to interact with your Grain relay. Here's a breakdown of the settings:

1. pubkey_whitelist (Public Key Whitelist)

• enabled: false:
  • If set to true, this enables the public key whitelist. Only users whose public keys are listed will be allowed to publish events to your relay.
• pubkeys::
  • A list of hexadecimal public keys that are allowed to publish events.
  • pubkey1 and pubkey2 are placeholders, you will replace these with actual hexadecimal public keys.
• npubs::
  • A list of npubs that are allowed to publish events.
  • npub18ls2km9aklhzw9yzqgjfu0anhz2z83hkeknw7sl22ptu8kfs3rjq54am44 and npub2 are placeholders, replace them with actual npubs.
  • npubs are bech32 encoded public keys.

2. kind_whitelist (Event Kind Whitelist)

• enabled: false:
  • If set to true, this enables the event kind whitelist. Only events with the specified kinds will be allowed.
• kinds::
  • A list of event kinds (as strings) that are allowed.
  • "1" and "2" are example kinds. Replace these with the kinds you want to allow.
  • Example kinds are 0 for metadata, 1 for short text notes, and 2 for recommend server.

3. domain_whitelist (Domain Whitelist)

• enabled: false:
  • If set to true, this enables the domain whitelist. This checks the domains .well-known folder for their nostr.json. This file contains a list of pubkeys. They will be considered whitelisted if on this list.
• domains::
  • A list of domains that are allowed.
  • "example.com" and "anotherdomain.com" are example domains. Replace these with the domains you want to allow.

blacklist.yml

The blacklist.yml file allows you to block specific content, users, and words from your Grain relay. Here's a breakdown of the settings:

1. enabled: true

• This setting enables the blacklist functionality. If set to true, the relay will actively block content and users based on the rules defined in this file.

2. permanent_ban_words:

• This section lists words that, if found in an event, will result in a permanent ban for the event's author.
• - really bad word is a placeholder. Replace it with any words you want to permanently block.

3. temp_ban_words:

• This section lists words that, if found in an event, will result in a temporary ban for the event's author.
• - crypto, - web3, and - airdrop are examples. Replace them with the words you want to temporarily block.

4. max_temp_bans: 3

• This sets the maximum number of temporary bans a user can receive before they are permanently banned.

5. temp_ban_duration: 3600

• This sets the duration of a temporary ban in seconds. 3600 seconds equals one hour.

6. permanent_blacklist_pubkeys:

• This section lists hexadecimal public keys that are permanently blocked from using the relay.
• - db0c9b8acd6101adb9b281c5321f98f6eebb33c5719d230ed1870997538a9765 is an example. Replace it with the public keys you want to block.

7. permanent_blacklist_npubs:

• This section lists npubs that are permanently blocked from using the relay.
• - npub1x0r5gflnk2mn6h3c70nvnywpy2j46gzqwg6k7uw6fxswyz0md9qqnhshtn is an example. Replace it with the npubs you want to block.
• npubs are the human readable version of public keys.

8. mutelist_authors:

• This section lists hexadecimal public keys of author of a kind1000 mutelist. Pubkey authors on this mutelist will be considered on the permanent blacklist. This provides a nostr native way to handle the backlist of your relay
• - 3fe0ab6cbdb7ee27148202249e3fb3b89423c6f6cda6ef43ea5057c3d93088e4 is an example. Replace it with the public keys of authors that have a mutelist you would like to use as a blacklist. Consider using your own.
• Important Note: The mutelist Event MUST be stored in this relay for it to be retrieved. This means your relay must have a copy of the authors kind10000 mutelist to consider them for the blacklist.

Running Grain as a Service:

Windows Service:

To run Grain as a Windows service, you can use tools like NSSM (Non-Sucking Service Manager). NSSM allows you to easily install and manage any application as a Windows service.

* For instructions on how to install NSSM, please refer to this article: [Link to NSSM install guide coming soon].

1. Open Command Prompt as Administrator:

   • Open the Windows Start menu, type "cmd," right-click on "Command Prompt," and select "Run as administrator."

2. Navigate to NSSM Directory:

   • Use the cd command to navigate to the directory where you extracted NSSM. For example, if you extracted it to C:\nssm, you would type cd C:\nssm and press Enter.

3. Install the Grain Service:

   • Run the command nssm install grain.
   • A GUI will appear, allowing you to configure the service.

4. Configure Service Details:

   • In the "Path" field, enter the full path to your Grain executable (e.g., C:\grain\grain_windows_amd64.exe).
   • In the "Startup directory" field, enter the directory where your Grain executable is located (e.g., C:\grain).

5. Install the Service:

   • Click the "Install service" button.

6. Manage the Service:

   • You can now manage the Grain service using the Windows Services manager. Open the Start menu, type "services.msc," and press Enter. You can start, stop, pause, or restart the Grain service from there.

Linux Service (systemd):

To run Grain as a Linux service, you can use systemd, the standard service manager for most modern Linux distributions.

1. Create a Systemd Service File:

   • Open a text editor with root privileges (e.g., sudo nano /etc/systemd/system/grain.service).

2. Add Service Configuration:

   • Add the following content to the grain.service file, replacing the placeholders with your actual paths and user information:

   ```toml [Unit] Description=Grain Nostr Relay After=network.target

   [Service] ExecStart=/path/to/grain_linux_amd64 WorkingDirectory=/path/to/grain/directory Restart=always User=your_user #replace your_user Group=your_group #replace your_group

   [Install] WantedBy=multi-user.target ```

   • Replace /path/to/grain/executable with the full path to your Grain executable.
   • Replace /path/to/grain/directory with the directory containing your Grain executable.
   • Replace your_user and your_group with the username and group that will run the Grain service.

3. Reload Systemd:

   • Run the command sudo systemctl daemon-reload to reload the systemd configuration.

4. Enable the Service:

   • Run the command sudo systemctl enable grain.service to enable the service to start automatically on boot.

5. Start the Service:

   • Run the command sudo systemctl start grain.service to start the service immediately.

6. Check Service Status:

   • Run the command sudo systemctl status grain.service to check the status of the Grain service. This will show you if the service is running and any recent logs.
   • You can run sudo journalctl -f -u grain.service to watch the logs

More guides are in the works for setting up tailscale to access your relay from anywhere over a private network and for setting up a cloudflare tunnel to your domain to deploy a grain relay accessible on a subdomain of your site eg wss://relay.yourdomain.com

@ 91bea5cd:1df4451c

Básico

bash lsblk # Lista todos os diretorios montados.

Para criar o sistema de arquivos:

bash mkfs.btrfs -L "ThePool" -f /dev/sdx

Criando um subvolume:

bash btrfs subvolume create SubVol

Montando Sistema de Arquivos:

bash mount -o compress=zlib,subvol=SubVol,autodefrag /dev/sdx /mnt

Lista os discos formatados no diretório:

bash btrfs filesystem show /mnt

Adiciona novo disco ao subvolume:

bash btrfs device add -f /dev/sdy /mnt

Lista novamente os discos do subvolume:

bash btrfs filesystem show /mnt

Exibe uso dos discos do subvolume:

bash btrfs filesystem df /mnt

Balancea os dados entre os discos sobre raid1:

bash btrfs filesystem balance start -dconvert=raid1 -mconvert=raid1 /mnt

Scrub é uma passagem por todos os dados e metadados do sistema de arquivos e verifica as somas de verificação. Se uma cópia válida estiver disponível (perfis de grupo de blocos replicados), a danificada será reparada. Todas as cópias dos perfis replicados são validadas.

iniciar o processo de depuração :

bash btrfs scrub start /mnt

ver o status do processo de depuração Btrfs em execução:

bash btrfs scrub status /mnt

ver o status do scrub Btrfs para cada um dos dispositivos

bash btrfs scrub status -d / data btrfs scrub cancel / data

Para retomar o processo de depuração do Btrfs que você cancelou ou pausou:

btrfs scrub resume / data

Listando os subvolumes:

bash btrfs subvolume list /Reports

Criando um instantâneo dos subvolumes:

Aqui, estamos criando um instantâneo de leitura e gravação chamado snap de marketing do subvolume de marketing.

bash btrfs subvolume snapshot /Reports/marketing /Reports/marketing-snap

Além disso, você pode criar um instantâneo somente leitura usando o sinalizador -r conforme mostrado. O marketing-rosnap é um instantâneo somente leitura do subvolume de marketing

bash btrfs subvolume snapshot -r /Reports/marketing /Reports/marketing-rosnap

Forçar a sincronização do sistema de arquivos usando o utilitário 'sync'

Para forçar a sincronização do sistema de arquivos, invoque a opção de sincronização conforme mostrado. Observe que o sistema de arquivos já deve estar montado para que o processo de sincronização continue com sucesso.

bash btrfs filsystem sync /Reports

Para excluir o dispositivo do sistema de arquivos, use o comando device delete conforme mostrado.

bash btrfs device delete /dev/sdc /Reports

Para sondar o status de um scrub, use o comando scrub status com a opção -dR .

bash btrfs scrub status -dR / Relatórios

Para cancelar a execução do scrub, use o comando scrub cancel .

bash $ sudo btrfs scrub cancel / Reports

Para retomar ou continuar com uma depuração interrompida anteriormente, execute o comando de cancelamento de depuração

bash sudo btrfs scrub resume /Reports

mostra o uso do dispositivo de armazenamento:

btrfs filesystem usage /data

Para distribuir os dados, metadados e dados do sistema em todos os dispositivos de armazenamento do RAID (incluindo o dispositivo de armazenamento recém-adicionado) montados no diretório /data , execute o seguinte comando:

sudo btrfs balance start --full-balance /data

Pode demorar um pouco para espalhar os dados, metadados e dados do sistema em todos os dispositivos de armazenamento do RAID se ele contiver muitos dados.

Opções importantes de montagem Btrfs

Nesta seção, vou explicar algumas das importantes opções de montagem do Btrfs. Então vamos começar.

As opções de montagem Btrfs mais importantes são:

**1. acl e noacl

**ACL gerencia permissões de usuários e grupos para os arquivos/diretórios do sistema de arquivos Btrfs.

A opção de montagem acl Btrfs habilita ACL. Para desabilitar a ACL, você pode usar a opção de montagem noacl .

Por padrão, a ACL está habilitada. Portanto, o sistema de arquivos Btrfs usa a opção de montagem acl por padrão.

**2. autodefrag e noautodefrag

**Desfragmentar um sistema de arquivos Btrfs melhorará o desempenho do sistema de arquivos reduzindo a fragmentação de dados.

A opção de montagem autodefrag permite a desfragmentação automática do sistema de arquivos Btrfs.

A opção de montagem noautodefrag desativa a desfragmentação automática do sistema de arquivos Btrfs.

Por padrão, a desfragmentação automática está desabilitada. Portanto, o sistema de arquivos Btrfs usa a opção de montagem noautodefrag por padrão.

**3. compactar e compactar-forçar

**Controla a compactação de dados no nível do sistema de arquivos do sistema de arquivos Btrfs.

A opção compactar compacta apenas os arquivos que valem a pena compactar (se compactar o arquivo economizar espaço em disco).

A opção compress-force compacta todos os arquivos do sistema de arquivos Btrfs, mesmo que a compactação do arquivo aumente seu tamanho.

O sistema de arquivos Btrfs suporta muitos algoritmos de compactação e cada um dos algoritmos de compactação possui diferentes níveis de compactação.

Os algoritmos de compactação suportados pelo Btrfs são: lzo , zlib (nível 1 a 9) e zstd (nível 1 a 15).

Você pode especificar qual algoritmo de compactação usar para o sistema de arquivos Btrfs com uma das seguintes opções de montagem:

• compress=algoritmo:nível
• compress-force=algoritmo:nível

Para obter mais informações, consulte meu artigo Como habilitar a compactação do sistema de arquivos Btrfs .

**4. subvol e subvolid

**Estas opções de montagem são usadas para montar separadamente um subvolume específico de um sistema de arquivos Btrfs.

A opção de montagem subvol é usada para montar o subvolume de um sistema de arquivos Btrfs usando seu caminho relativo.

A opção de montagem subvolid é usada para montar o subvolume de um sistema de arquivos Btrfs usando o ID do subvolume.

Para obter mais informações, consulte meu artigo Como criar e montar subvolumes Btrfs .

**5. dispositivo

A opção de montagem de dispositivo** é usada no sistema de arquivos Btrfs de vários dispositivos ou RAID Btrfs.

Em alguns casos, o sistema operacional pode falhar ao detectar os dispositivos de armazenamento usados em um sistema de arquivos Btrfs de vários dispositivos ou RAID Btrfs. Nesses casos, você pode usar a opção de montagem do dispositivo para especificar os dispositivos que deseja usar para o sistema de arquivos de vários dispositivos Btrfs ou RAID.

Você pode usar a opção de montagem de dispositivo várias vezes para carregar diferentes dispositivos de armazenamento para o sistema de arquivos de vários dispositivos Btrfs ou RAID.

Você pode usar o nome do dispositivo (ou seja, sdb , sdc ) ou UUID , UUID_SUB ou PARTUUID do dispositivo de armazenamento com a opção de montagem do dispositivo para identificar o dispositivo de armazenamento.

Por exemplo,

• dispositivo=/dev/sdb
• dispositivo=/dev/sdb,dispositivo=/dev/sdc
• dispositivo=UUID_SUB=490a263d-eb9a-4558-931e-998d4d080c5d
• device=UUID_SUB=490a263d-eb9a-4558-931e-998d4d080c5d,device=UUID_SUB=f7ce4875-0874-436a-b47d-3edef66d3424

**6. degraded

A opção de montagem degradada** permite que um RAID Btrfs seja montado com menos dispositivos de armazenamento do que o perfil RAID requer.

Por exemplo, o perfil raid1 requer a presença de 2 dispositivos de armazenamento. Se um dos dispositivos de armazenamento não estiver disponível em qualquer caso, você usa a opção de montagem degradada para montar o RAID mesmo que 1 de 2 dispositivos de armazenamento esteja disponível.

**7. commit

A opção commit** mount é usada para definir o intervalo (em segundos) dentro do qual os dados serão gravados no dispositivo de armazenamento.

O padrão é definido como 30 segundos.

Para definir o intervalo de confirmação para 15 segundos, você pode usar a opção de montagem commit=15 (digamos).

**8. ssd e nossd

A opção de montagem ssd** informa ao sistema de arquivos Btrfs que o sistema de arquivos está usando um dispositivo de armazenamento SSD, e o sistema de arquivos Btrfs faz a otimização SSD necessária.

A opção de montagem nossd desativa a otimização do SSD.

O sistema de arquivos Btrfs detecta automaticamente se um SSD é usado para o sistema de arquivos Btrfs. Se um SSD for usado, a opção de montagem de SSD será habilitada. Caso contrário, a opção de montagem nossd é habilitada.

**9. ssd_spread e nossd_spread

A opção de montagem ssd_spread** tenta alocar grandes blocos contínuos de espaço não utilizado do SSD. Esse recurso melhora o desempenho de SSDs de baixo custo (baratos).

A opção de montagem nossd_spread desativa o recurso ssd_spread .

O sistema de arquivos Btrfs detecta automaticamente se um SSD é usado para o sistema de arquivos Btrfs. Se um SSD for usado, a opção de montagem ssd_spread será habilitada. Caso contrário, a opção de montagem nossd_spread é habilitada.

**10. descarte e nodiscard

Se você estiver usando um SSD que suporte TRIM enfileirado assíncrono (SATA rev3.1), a opção de montagem de descarte** permitirá o descarte de blocos de arquivos liberados. Isso melhorará o desempenho do SSD.

Se o SSD não suportar TRIM enfileirado assíncrono, a opção de montagem de descarte prejudicará o desempenho do SSD. Nesse caso, a opção de montagem nodiscard deve ser usada.

Por padrão, a opção de montagem nodiscard é usada.

**11. norecovery

Se a opção de montagem norecovery** for usada, o sistema de arquivos Btrfs não tentará executar a operação de recuperação de dados no momento da montagem.

**12. usebackuproot e nousebackuproot

Se a opção de montagem usebackuproot for usada, o sistema de arquivos Btrfs tentará recuperar qualquer raiz de árvore ruim/corrompida no momento da montagem. O sistema de arquivos Btrfs pode armazenar várias raízes de árvore no sistema de arquivos. A opção de montagem usebackuproot** procurará uma boa raiz de árvore e usará a primeira boa que encontrar.

A opção de montagem nousebackuproot não verificará ou recuperará raízes de árvore inválidas/corrompidas no momento da montagem. Este é o comportamento padrão do sistema de arquivos Btrfs.

**13. space_cache, space_cache=version, nospace_cache e clear_cache

A opção de montagem space_cache** é usada para controlar o cache de espaço livre. O cache de espaço livre é usado para melhorar o desempenho da leitura do espaço livre do grupo de blocos do sistema de arquivos Btrfs na memória (RAM).

O sistema de arquivos Btrfs suporta 2 versões do cache de espaço livre: v1 (padrão) e v2

O mecanismo de cache de espaço livre v2 melhora o desempenho de sistemas de arquivos grandes (tamanho de vários terabytes).

Você pode usar a opção de montagem space_cache=v1 para definir a v1 do cache de espaço livre e a opção de montagem space_cache=v2 para definir a v2 do cache de espaço livre.

A opção de montagem clear_cache é usada para limpar o cache de espaço livre.

Quando o cache de espaço livre v2 é criado, o cache deve ser limpo para criar um cache de espaço livre v1 .

Portanto, para usar o cache de espaço livre v1 após a criação do cache de espaço livre v2 , as opções de montagem clear_cache e space_cache=v1 devem ser combinadas: clear_cache,space_cache=v1

A opção de montagem nospace_cache é usada para desabilitar o cache de espaço livre.

Para desabilitar o cache de espaço livre após a criação do cache v1 ou v2 , as opções de montagem nospace_cache e clear_cache devem ser combinadas: clear_cache,nosapce_cache

**14. skip_balance

Por padrão, a operação de balanceamento interrompida/pausada de um sistema de arquivos Btrfs de vários dispositivos ou RAID Btrfs será retomada automaticamente assim que o sistema de arquivos Btrfs for montado. Para desabilitar a retomada automática da operação de equilíbrio interrompido/pausado em um sistema de arquivos Btrfs de vários dispositivos ou RAID Btrfs, você pode usar a opção de montagem skip_balance .**

**15. datacow e nodatacow

A opção datacow** mount habilita o recurso Copy-on-Write (CoW) do sistema de arquivos Btrfs. É o comportamento padrão.

Se você deseja desabilitar o recurso Copy-on-Write (CoW) do sistema de arquivos Btrfs para os arquivos recém-criados, monte o sistema de arquivos Btrfs com a opção de montagem nodatacow .

**16. datasum e nodatasum

A opção datasum** mount habilita a soma de verificação de dados para arquivos recém-criados do sistema de arquivos Btrfs. Este é o comportamento padrão.

Se você não quiser que o sistema de arquivos Btrfs faça a soma de verificação dos dados dos arquivos recém-criados, monte o sistema de arquivos Btrfs com a opção de montagem nodatasum .

Perfis Btrfs

Um perfil Btrfs é usado para informar ao sistema de arquivos Btrfs quantas cópias dos dados/metadados devem ser mantidas e quais níveis de RAID devem ser usados para os dados/metadados. O sistema de arquivos Btrfs contém muitos perfis. Entendê-los o ajudará a configurar um RAID Btrfs da maneira que você deseja.

Os perfis Btrfs disponíveis são os seguintes:

single : Se o perfil único for usado para os dados/metadados, apenas uma cópia dos dados/metadados será armazenada no sistema de arquivos, mesmo se você adicionar vários dispositivos de armazenamento ao sistema de arquivos. Assim, 100% do espaço em disco de cada um dos dispositivos de armazenamento adicionados ao sistema de arquivos pode ser utilizado.

dup : Se o perfil dup for usado para os dados/metadados, cada um dos dispositivos de armazenamento adicionados ao sistema de arquivos manterá duas cópias dos dados/metadados. Assim, 50% do espaço em disco de cada um dos dispositivos de armazenamento adicionados ao sistema de arquivos pode ser utilizado.

raid0 : No perfil raid0 , os dados/metadados serão divididos igualmente em todos os dispositivos de armazenamento adicionados ao sistema de arquivos. Nesta configuração, não haverá dados/metadados redundantes (duplicados). Assim, 100% do espaço em disco de cada um dos dispositivos de armazenamento adicionados ao sistema de arquivos pode ser usado. Se, em qualquer caso, um dos dispositivos de armazenamento falhar, todo o sistema de arquivos será corrompido. Você precisará de pelo menos dois dispositivos de armazenamento para configurar o sistema de arquivos Btrfs no perfil raid0 .

raid1 : No perfil raid1 , duas cópias dos dados/metadados serão armazenadas nos dispositivos de armazenamento adicionados ao sistema de arquivos. Nesta configuração, a matriz RAID pode sobreviver a uma falha de unidade. Mas você pode usar apenas 50% do espaço total em disco. Você precisará de pelo menos dois dispositivos de armazenamento para configurar o sistema de arquivos Btrfs no perfil raid1 .

raid1c3 : No perfil raid1c3 , três cópias dos dados/metadados serão armazenadas nos dispositivos de armazenamento adicionados ao sistema de arquivos. Nesta configuração, a matriz RAID pode sobreviver a duas falhas de unidade, mas você pode usar apenas 33% do espaço total em disco. Você precisará de pelo menos três dispositivos de armazenamento para configurar o sistema de arquivos Btrfs no perfil raid1c3 .

raid1c4 : No perfil raid1c4 , quatro cópias dos dados/metadados serão armazenadas nos dispositivos de armazenamento adicionados ao sistema de arquivos. Nesta configuração, a matriz RAID pode sobreviver a três falhas de unidade, mas você pode usar apenas 25% do espaço total em disco. Você precisará de pelo menos quatro dispositivos de armazenamento para configurar o sistema de arquivos Btrfs no perfil raid1c4 .

raid10 : No perfil raid10 , duas cópias dos dados/metadados serão armazenadas nos dispositivos de armazenamento adicionados ao sistema de arquivos, como no perfil raid1 . Além disso, os dados/metadados serão divididos entre os dispositivos de armazenamento, como no perfil raid0 .

O perfil raid10 é um híbrido dos perfis raid1 e raid0 . Alguns dos dispositivos de armazenamento formam arrays raid1 e alguns desses arrays raid1 são usados para formar um array raid0 . Em uma configuração raid10 , o sistema de arquivos pode sobreviver a uma única falha de unidade em cada uma das matrizes raid1 .

Você pode usar 50% do espaço total em disco na configuração raid10 . Você precisará de pelo menos quatro dispositivos de armazenamento para configurar o sistema de arquivos Btrfs no perfil raid10 .

raid5 : No perfil raid5 , uma cópia dos dados/metadados será dividida entre os dispositivos de armazenamento. Uma única paridade será calculada e distribuída entre os dispositivos de armazenamento do array RAID.

Em uma configuração raid5 , o sistema de arquivos pode sobreviver a uma única falha de unidade. Se uma unidade falhar, você pode adicionar uma nova unidade ao sistema de arquivos e os dados perdidos serão calculados a partir da paridade distribuída das unidades em execução.

Você pode usar 1 00x(N-1)/N % do total de espaços em disco na configuração raid5 . Aqui, N é o número de dispositivos de armazenamento adicionados ao sistema de arquivos. Você precisará de pelo menos três dispositivos de armazenamento para configurar o sistema de arquivos Btrfs no perfil raid5 .

raid6 : No perfil raid6 , uma cópia dos dados/metadados será dividida entre os dispositivos de armazenamento. Duas paridades serão calculadas e distribuídas entre os dispositivos de armazenamento do array RAID.

Em uma configuração raid6 , o sistema de arquivos pode sobreviver a duas falhas de unidade ao mesmo tempo. Se uma unidade falhar, você poderá adicionar uma nova unidade ao sistema de arquivos e os dados perdidos serão calculados a partir das duas paridades distribuídas das unidades em execução.

Você pode usar 100x(N-2)/N % do espaço total em disco na configuração raid6 . Aqui, N é o número de dispositivos de armazenamento adicionados ao sistema de arquivos. Você precisará de pelo menos quatro dispositivos de armazenamento para configurar o sistema de arquivos Btrfs no perfil raid6 .

@ 17538dc2:71ed77c4

Who were they? Testing long form publication via yakihonne

@ a39d19ec:3d88f61e

Nun da das deutsche Bundesregime den Ruin Deutschlands beschlossen hat, der sehr wahrscheinlich mit dem Werkzeug des Geld druckens "finanziert" wird, kamen mir so viele Gedanken zur Geldmengenausweitung, dass ich diese für einmal niedergeschrieben habe.

Die Ausweitung der Geldmenge führt aus klassischer wirtschaftlicher Sicht immer zu Preissteigerungen, weil mehr Geld im Umlauf auf eine begrenzte Menge an Gütern trifft. Dies lässt sich in mehreren Schritten analysieren:

1. Quantitätstheorie des Geldes

Die klassische Gleichung der Quantitätstheorie des Geldes lautet:

M • V = P • Y

wobei:
- M die Geldmenge ist,
- V die Umlaufgeschwindigkeit des Geldes,
- P das Preisniveau,
- Y die reale Wirtschaftsleistung (BIP).

Wenn M steigt und V sowie Y konstant bleiben, muss P steigen – also Inflation entstehen.

2. Gütermenge bleibt begrenzt

Die Menge an real produzierten Gütern und Dienstleistungen wächst meist nur langsam im Vergleich zur Ausweitung der Geldmenge. Wenn die Geldmenge schneller steigt als die Produktionsgütermenge, führt dies dazu, dass mehr Geld für die gleiche Menge an Waren zur Verfügung steht – die Preise steigen.

3. Erwartungseffekte und Spekulation

Wenn Unternehmen und Haushalte erwarten, dass mehr Geld im Umlauf ist, da eine zentrale Planung es so wollte, können sie steigende Preise antizipieren. Unternehmen erhöhen ihre Preise vorab, und Arbeitnehmer fordern höhere Löhne. Dies kann eine sich selbst verstärkende Spirale auslösen.

4. Internationale Perspektive

Eine erhöhte Geldmenge kann die Währung abwerten, wenn andere Länder ihre Geldpolitik stabil halten. Eine schwächere Währung macht Importe teurer, was wiederum Preissteigerungen antreibt.

5. Kritik an der reinen Geldmengen-Theorie

Der Vollständigkeit halber muss erwähnt werden, dass die meisten modernen Ökonomen im Staatsauftrag argumentieren, dass Inflation nicht nur von der Geldmenge abhängt, sondern auch von der Nachfrage nach Geld (z. B. in einer Wirtschaftskrise). Dennoch zeigt die historische Erfahrung, dass eine unkontrollierte Geldmengenausweitung langfristig immer zu Preissteigerungen führt, wie etwa in der Hyperinflation der Weimarer Republik oder in Simbabwe.

@ 4ba8e86d:89d32de4

Como funciona o PGP.

O texto a seguir foi retirado do capítulo 1 do documento Introdução à criptografia na documentação do PGP 6.5.1. Copyright © 1990-1999 Network Associates, Inc. Todos os direitos reservados.

-O que é criptografia? -Criptografia forte -Como funciona a criptografia? -Criptografia convencional -Cifra de César -Gerenciamento de chaves e criptografia convencional -Criptografia de chave pública -Como funciona o PGP - Chaves • Assinaturas digitais -Funções hash • Certificados digitais -Distribuição de certificados -Formatos de certificado •Validade e confiança -Verificando validade -Estabelecendo confiança -Modelos de confiança • Revogação de certificado -Comunicar que um certificado foi revogado -O que é uma senha? -Divisão de chave

Os princípios básicos da criptografia.

Quando Júlio César enviou mensagens aos seus generais, ele não confiou nos seus mensageiros. Então ele substituiu cada A em suas mensagens por um D, cada B por um E, e assim por diante através do alfabeto. Somente alguém que conhecesse a regra “shift by 3” poderia decifrar suas mensagens. E assim começamos.

Criptografia e descriptografia.

Os dados que podem ser lidos e compreendidos sem quaisquer medidas especiais são chamados de texto simples ou texto não criptografado. O método de disfarçar o texto simples de forma a ocultar sua substância é chamado de criptografia. Criptografar texto simples resulta em um jargão ilegível chamado texto cifrado. Você usa criptografia para garantir que as informações sejam ocultadas de qualquer pessoa a quem não se destinam, mesmo daqueles que podem ver os dados criptografados. O processo de reverter o texto cifrado ao texto simples original é chamado de descriptografia . A Figura 1-1 ilustra esse processo.

https://image.nostr.build/0e2fcb71ed86a6083e083abbb683f8c103f44a6c6db1aeb2df10ae51ec97ebe5.jpg

Figura 1-1. Criptografia e descriptografia

O que é criptografia?

Criptografia é a ciência que usa a matemática para criptografar e descriptografar dados. A criptografia permite armazenar informações confidenciais ou transmiti-las através de redes inseguras (como a Internet) para que não possam ser lidas por ninguém, exceto pelo destinatário pretendido. Embora a criptografia seja a ciência que protege os dados, a criptoanálise é a ciência que analisa e quebra a comunicação segura. A criptoanálise clássica envolve uma combinação interessante de raciocínio analítico, aplicação de ferramentas matemáticas, descoberta de padrões, paciência, determinação e sorte. Os criptoanalistas também são chamados de atacantes. A criptologia abrange tanto a criptografia quanto a criptoanálise.

Criptografia forte.

"Existem dois tipos de criptografia neste mundo: a criptografia que impedirá a sua irmã mais nova de ler os seus arquivos, e a criptografia que impedirá os principais governos de lerem os seus arquivos. Este livro é sobre o último." --Bruce Schneier, Criptografia Aplicada: Protocolos, Algoritmos e Código Fonte em C. PGP também trata deste último tipo de criptografia. A criptografia pode ser forte ou fraca, conforme explicado acima. A força criptográfica é medida no tempo e nos recursos necessários para recuperar o texto simples. O resultado de uma criptografia forte é um texto cifrado que é muito difícil de decifrar sem a posse da ferramenta de decodificação apropriada. Quão díficil? Dado todo o poder computacional e o tempo disponível de hoje – mesmo um bilhão de computadores fazendo um bilhão de verificações por segundo – não é possível decifrar o resultado de uma criptografia forte antes do fim do universo. Alguém poderia pensar, então, que uma criptografia forte resistiria muito bem até mesmo contra um criptoanalista extremamente determinado. Quem pode realmente dizer? Ninguém provou que a criptografia mais forte disponível hoje resistirá ao poder computacional de amanhã. No entanto, a criptografia forte empregada pelo PGP é a melhor disponível atualmente.

Contudo, a vigilância e o conservadorismo irão protegê-lo melhor do que as alegações de impenetrabilidade.

Como funciona a criptografia?

Um algoritmo criptográfico, ou cifra, é uma função matemática usada no processo de criptografia e descriptografia. Um algoritmo criptográfico funciona em combinação com uma chave – uma palavra, número ou frase – para criptografar o texto simples. O mesmo texto simples é criptografado em texto cifrado diferente com chaves diferentes. A segurança dos dados criptografados depende inteiramente de duas coisas: a força do algoritmo criptográfico e o sigilo da chave. Um algoritmo criptográfico, mais todas as chaves possíveis e todos os protocolos que o fazem funcionar constituem um criptossistema. PGP é um criptossistema.

Criptografia convencional.

Na criptografia convencional, também chamada de criptografia de chave secreta ou de chave simétrica , uma chave é usada tanto para criptografia quanto para descriptografia. O Data Encryption Standard (DES) é um exemplo de criptossistema convencional amplamente empregado pelo Governo Federal. A Figura 1-2 é uma ilustração do processo de criptografia convencional. https://image.nostr.build/328b73ebaff84c949df2560bbbcec4bc3b5e3a5163d5fbb2ec7c7c60488f894c.jpg

Figura 1-2. Criptografia convencional

Cifra de César.

Um exemplo extremamente simples de criptografia convencional é uma cifra de substituição. Uma cifra de substituição substitui uma informação por outra. Isso é feito com mais frequência compensando as letras do alfabeto. Dois exemplos são o Anel Decodificador Secreto do Capitão Meia-Noite, que você pode ter possuído quando era criança, e a cifra de Júlio César. Em ambos os casos, o algoritmo serve para compensar o alfabeto e a chave é o número de caracteres para compensá-lo. Por exemplo, se codificarmos a palavra "SEGREDO" usando o valor chave de César de 3, deslocaremos o alfabeto para que a terceira letra abaixo (D) comece o alfabeto. Então começando com A B C D E F G H I J K L M N O P Q R S T U V W X Y Z e deslizando tudo para cima em 3, você obtém DEFGHIJKLMNOPQRSTUVWXYZABC onde D=A, E=B, F=C e assim por diante. Usando este esquema, o texto simples, "SECRET" é criptografado como "VHFUHW". Para permitir que outra pessoa leia o texto cifrado, você diz a ela que a chave é 3. Obviamente, esta é uma criptografia extremamente fraca para os padrões atuais, mas, ei, funcionou para César e ilustra como funciona a criptografia convencional.

Gerenciamento de chaves e criptografia convencional.

A criptografia convencional tem benefícios. É muito rápido. É especialmente útil para criptografar dados que não vão a lugar nenhum. No entanto, a criptografia convencional por si só como meio de transmissão segura de dados pode ser bastante cara, simplesmente devido à dificuldade de distribuição segura de chaves. Lembre-se de um personagem do seu filme de espionagem favorito: a pessoa com uma pasta trancada e algemada ao pulso. Afinal, o que há na pasta? Provavelmente não é o código de lançamento de mísseis/fórmula de biotoxina/plano de invasão em si. É a chave que irá descriptografar os dados secretos. Para que um remetente e um destinatário se comuniquem com segurança usando criptografia convencional, eles devem chegar a um acordo sobre uma chave e mantê-la secreta entre si. Se estiverem em locais físicos diferentes, devem confiar em um mensageiro, no Bat Phone ou em algum outro meio de comunicação seguro para evitar a divulgação da chave secreta durante a transmissão. Qualquer pessoa que ouvir ou interceptar a chave em trânsito poderá posteriormente ler, modificar e falsificar todas as informações criptografadas ou autenticadas com essa chave. Do DES ao Anel Decodificador Secreto do Capitão Midnight, o problema persistente com a criptografia convencional é a distribuição de chaves: como você leva a chave ao destinatário sem que alguém a intercepte?

Criptografia de chave pública.

Os problemas de distribuição de chaves são resolvidos pela criptografia de chave pública, cujo conceito foi introduzido por Whitfield Diffie e Martin Hellman em 1975. (Há agora evidências de que o Serviço Secreto Britânico a inventou alguns anos antes de Diffie e Hellman, mas a manteve um segredo militar - e não fez nada com isso.

[JH Ellis: The Possibility of Secure Non-Secret Digital Encryption, CESG Report, January 1970]) A criptografia de chave pública é um esquema assimétrico que usa um par de chaves para criptografia: uma chave pública, que criptografa os dados, e uma chave privada ou secreta correspondente para descriptografia. Você publica sua chave pública para o mundo enquanto mantém sua chave privada em segredo. Qualquer pessoa com uma cópia da sua chave pública pode criptografar informações que somente você pode ler. Até mesmo pessoas que você nunca conheceu. É computacionalmente inviável deduzir a chave privada da chave pública. Qualquer pessoa que possua uma chave pública pode criptografar informações, mas não pode descriptografá-las. Somente a pessoa que possui a chave privada correspondente pode descriptografar as informações. https://image.nostr.build/fdb71ae7a4450a523456827bdd509b31f0250f63152cc6f4ba78df290887318b.jpg

Figura 1-3. Criptografia de chave pública O principal benefício da criptografia de chave pública é que ela permite que pessoas que não possuem nenhum acordo de segurança pré-existente troquem mensagens com segurança. A necessidade de remetente e destinatário compartilharem chaves secretas através de algum canal seguro é eliminada; todas as comunicações envolvem apenas chaves públicas e nenhuma chave privada é transmitida ou compartilhada. Alguns exemplos de criptossistemas de chave pública são Elgamal (nomeado em homenagem a seu inventor, Taher Elgamal), RSA (nomeado em homenagem a seus inventores, Ron Rivest, Adi Shamir e Leonard Adleman), Diffie-Hellman (nomeado, você adivinhou, em homenagem a seus inventores). ) e DSA, o algoritmo de assinatura digital (inventado por David Kravitz). Como a criptografia convencional já foi o único meio disponível para transmitir informações secretas, o custo dos canais seguros e da distribuição de chaves relegou a sua utilização apenas àqueles que podiam pagar, como governos e grandes bancos (ou crianças pequenas com anéis descodificadores secretos). A criptografia de chave pública é a revolução tecnológica que fornece criptografia forte para as massas adultas. Lembra do mensageiro com a pasta trancada e algemada ao pulso? A criptografia de chave pública o tira do mercado (provavelmente para seu alívio).

Como funciona o PGP.

O PGP combina alguns dos melhores recursos da criptografia convencional e de chave pública. PGP é um criptossistema híbrido. Quando um usuário criptografa texto simples com PGP, o PGP primeiro compacta o texto simples. A compactação de dados economiza tempo de transmissão do modem e espaço em disco e, mais importante ainda, fortalece a segurança criptográfica. A maioria das técnicas de criptoanálise explora padrões encontrados no texto simples para quebrar a cifra. A compressão reduz esses padrões no texto simples, aumentando assim enormemente a resistência à criptoanálise. (Arquivos que são muito curtos para compactar ou que não são compactados bem não são compactados.) O PGP então cria uma chave de sessão, que é uma chave secreta única. Esta chave é um número aleatório gerado a partir dos movimentos aleatórios do mouse e das teclas digitadas. Esta chave de sessão funciona com um algoritmo de criptografia convencional rápido e muito seguro para criptografar o texto simples; o resultado é texto cifrado. Depois que os dados são criptografados, a chave da sessão é criptografada na chave pública do destinatário. Essa chave de sessão criptografada com chave pública é transmitida junto com o texto cifrado ao destinatário.

Figura 1-4. Como funciona a criptografia PGP A descriptografia funciona ao contrário. A cópia do PGP do destinatário usa sua chave privada para recuperar a chave de sessão temporária, que o PGP usa para descriptografar o texto cifrado criptografado convencionalmente.

Figura 1-5. Como funciona a descriptografia PGP A combinação dos dois métodos de criptografia combina a conveniência da criptografia de chave pública com a velocidade da criptografia convencional. A criptografia convencional é cerca de 1.000 vezes mais rápida que a criptografia de chave pública. A criptografia de chave pública, por sua vez, fornece uma solução para

problemas de distribuição de chaves e transmissão de dados. Usados ​​em conjunto, o desempenho e a distribuição de chaves são melhorados sem qualquer sacrifício na segurança.

Chaves.

Uma chave é um valor que funciona com um algoritmo criptográfico para produzir um texto cifrado específico. As chaves são basicamente números muito, muito, muito grandes. O tamanho da chave é medido em bits; o número que representa uma chave de 1024 bits é enorme. Na criptografia de chave pública, quanto maior a chave, mais seguro é o texto cifrado. No entanto, o tamanho da chave pública e o tamanho da chave secreta da criptografia convencional não têm nenhuma relação. Uma chave convencional de 80 bits tem a força equivalente a uma chave pública de 1.024 bits. Uma chave convencional de 128 bits é equivalente a uma chave pública de 3.000 bits. Novamente, quanto maior a chave, mais segura, mas os algoritmos usados ​​para cada tipo de criptografia são muito diferentes e, portanto, a comparação é como a de maçãs com laranjas. Embora as chaves pública e privada estejam matematicamente relacionadas, é muito difícil derivar a chave privada dada apenas a chave pública; no entanto, derivar a chave privada é sempre possível, desde que haja tempo e capacidade computacional suficientes. Isto torna muito importante escolher chaves do tamanho certo; grande o suficiente para ser seguro, mas pequeno o suficiente para ser aplicado rapidamente. Além disso, você precisa considerar quem pode estar tentando ler seus arquivos, quão determinados eles estão, quanto tempo têm e quais podem ser seus recursos. Chaves maiores serão criptograficamente seguras por um longo período de tempo. Se o que você deseja criptografar precisar ficar oculto por muitos anos, você pode usar uma chave muito grande. Claro, quem sabe quanto tempo levará para determinar sua chave usando os computadores mais rápidos e eficientes de amanhã? Houve um tempo em que uma chave simétrica de 56 bits era considerada extremamente segura. As chaves são armazenadas de forma criptografada. O PGP armazena as chaves em dois arquivos no seu disco rígido; um para chaves públicas e outro para chaves privadas. Esses arquivos são chamados de chaveiros. Ao usar o PGP, você normalmente adicionará as chaves públicas dos seus destinatários ao seu chaveiro público. Suas chaves privadas são armazenadas em seu chaveiro privado. Se você perder seu chaveiro privado, não será possível descriptografar nenhuma informação criptografada nas chaves desse anel.

Assinaturas digitais.

Um grande benefício da criptografia de chave pública é que ela fornece um método para empregar assinaturas digitais. As assinaturas digitais permitem ao destinatário da informação verificar a autenticidade da origem da informação e também verificar se a informação está intacta. Assim, as assinaturas digitais de chave pública fornecem autenticação e integridade de dados. A assinatura digital também proporciona o não repúdio, o que significa que evita que o remetente alegue que não enviou realmente as informações. Esses recursos são tão fundamentais para a criptografia quanto a privacidade, se não mais. Uma assinatura digital tem a mesma finalidade de uma assinatura manuscrita. No entanto, uma assinatura manuscrita é fácil de falsificar. Uma assinatura digital é superior a uma assinatura manuscrita porque é quase impossível de ser falsificada, além de atestar o conteúdo da informação, bem como a identidade do signatário.

Algumas pessoas tendem a usar mais assinaturas do que criptografia. Por exemplo, você pode não se importar se alguém souber que você acabou de depositar US$ 1.000 em sua conta, mas quer ter certeza de que foi o caixa do banco com quem você estava lidando. A maneira básica pela qual as assinaturas digitais são criadas é ilustrada na Figura 1-6 . Em vez de criptografar informações usando a chave pública de outra pessoa, você as criptografa com sua chave privada. Se as informações puderem ser descriptografadas com sua chave pública, elas deverão ter se originado em você.

Figura 1-6. Assinaturas digitais simples

Funções hash.

O sistema descrito acima apresenta alguns problemas. É lento e produz um enorme volume de dados – pelo menos o dobro do tamanho da informação original. Uma melhoria no esquema acima é a adição de uma função hash unidirecional no processo. Uma função hash unidirecional recebe uma entrada de comprimento variável – neste caso, uma mensagem de qualquer comprimento, até mesmo milhares ou milhões de bits – e produz uma saída de comprimento fixo; digamos, 160 bits. A função hash garante que, se a informação for alterada de alguma forma – mesmo que por apenas um bit – seja produzido um valor de saída totalmente diferente. O PGP usa uma função hash criptograficamente forte no texto simples que o usuário está assinando. Isso gera um item de dados de comprimento fixo conhecido como resumo da mensagem. (Novamente, qualquer alteração nas informações resulta em um resumo totalmente diferente.) Então o PGP usa o resumo e a chave privada para criar a “assinatura”. O PGP transmite a assinatura e o texto simples juntos. Ao receber a mensagem, o destinatário utiliza o PGP para recalcular o resumo, verificando assim a assinatura. O PGP pode criptografar o texto simples ou não; assinar texto simples é útil se alguns dos destinatários não estiverem interessados ​​ou não forem capazes de verificar a assinatura. Desde que uma função hash segura seja usada, não há como retirar a assinatura de alguém de um documento e anexá-la a outro, ou alterar uma mensagem assinada de qualquer forma. A menor alteração em um documento assinado causará falha no processo de verificação da assinatura digital.

Figura 1-7. Assinaturas digitais seguras As assinaturas digitais desempenham um papel importante na autenticação e validação de chaves de outros usuários PGP.

Certificados digitais.

Um problema com os criptosistemas de chave pública é que os usuários devem estar constantemente vigilantes para garantir que estão criptografando com a chave da pessoa correta. Num ambiente onde é seguro trocar chaves livremente através de servidores públicos, os ataques man-in-the-middle são uma ameaça potencial. Neste tipo de ataque, alguém publica uma chave falsa com o nome e ID de usuário do destinatário pretendido. Os dados criptografados – e interceptados por – o verdadeiro proprietário desta chave falsa estão agora em mãos erradas. Em um ambiente de chave pública, é vital que você tenha certeza de que a chave pública para a qual você está criptografando os dados é de fato a chave pública do destinatário pretendido e não uma falsificação. Você pode simplesmente criptografar apenas as chaves que foram entregues fisicamente a você. Mas suponha que você precise trocar informações com pessoas que nunca conheceu; como você pode saber se tem a chave correta? Os certificados digitais, ou certs, simplificam a tarefa de estabelecer se uma chave pública realmente pertence ao suposto proprietário. Um certificado é uma forma de credencial. Exemplos podem ser sua carteira de motorista, seu cartão de previdência social ou sua certidão de nascimento. Cada um deles contém algumas informações que identificam você e alguma autorização informando que outra pessoa confirmou sua identidade. Alguns certificados, como o seu passaporte, são uma confirmação importante o suficiente da sua identidade para que você não queira perdê-los, para que ninguém os use para se passar por você.

Um certificado digital são dados que funcionam como um certificado físico. Um certificado digital é uma informação incluída na chave pública de uma pessoa que ajuda outras pessoas a verificar se uma chave é genuína ou válida. Os certificados digitais são usados ​​para impedir tentativas de substituir a chave de uma pessoa por outra.

Um certificado digital consiste em três coisas:

● Uma chave pública.

● Informações do certificado. (Informações de "identidade" sobre o usuário, como nome, ID do usuário e assim por diante.) ● Uma ou mais assinaturas digitais.

O objetivo da assinatura digital em um certificado é afirmar que as informações do certificado foram atestadas por alguma outra pessoa ou entidade. A assinatura digital não atesta a autenticidade do certificado como um todo; ele atesta apenas que as informações de identidade assinadas acompanham ou estão vinculadas à chave pública. Assim, um certificado é basicamente uma chave pública com uma ou duas formas de identificação anexadas, além de um forte selo de aprovação de algum outro indivíduo confiável. Figura 1-8. Anatomia de um certificado PGP

Distribuição de certificados.

Os certificados são utilizados quando é necessário trocar chaves públicas com outra pessoa. Para pequenos grupos de pessoas que desejam se comunicar com segurança, é fácil trocar manualmente disquetes ou e-mails contendo a chave pública de cada proprietário. Esta é a distribuição manual de chave pública e é prática apenas até certo ponto. Além desse ponto, é necessário implementar sistemas que possam fornecer os mecanismos necessários de segurança, armazenamento e troca para que colegas de trabalho, parceiros de negócios ou estranhos possam se comunicar, se necessário. Eles podem vir na forma de repositórios somente de armazenamento, chamados Servidores de Certificados, ou sistemas mais estruturados que fornecem recursos adicionais de gerenciamento de chaves e são chamados de Infraestruturas de Chave Pública (PKIs).

Servidores de certificados.

Um servidor de certificados, também chamado de servidor certificado ou servidor de chaves, é um banco de dados que permite aos usuários enviar e recuperar certificados digitais. Um servidor certificado geralmente fornece alguns recursos administrativos que permitem que uma empresa mantenha suas políticas de segurança – por exemplo, permitindo que apenas as chaves que atendam a determinados requisitos sejam armazenadas.

Infraestruturas de Chave Pública.

Uma PKI contém os recursos de armazenamento de certificados de um servidor de certificados, mas também fornece recursos de gerenciamento de certificados (a capacidade de emitir, revogar, armazenar, recuperar e confiar em certificados). A principal característica de uma PKI é a introdução do que é conhecido como Autoridade Certificadora,ou CA, que é uma entidade humana — uma pessoa, grupo, departamento, empresa ou outra associação — que uma organização autorizou a emitir certificados para seus usuários de computador. (A função de uma CA é análoga à do Passport Office do governo de um país.) Uma CA cria certificados e os assina digitalmente usando a chave privada da CA. Devido ao seu papel na criação de certificados, a CA é o componente central de uma PKI. Usando a chave pública da CA, qualquer pessoa que queira verificar a autenticidade de um certificado verifica a assinatura digital da CA emissora e, portanto, a integridade do conteúdo do certificado (mais importante ainda, a chave pública e a identidade do titular do certificado).

Formatos de certificado.

Um certificado digital é basicamente uma coleção de informações de identificação vinculadas a uma chave pública e assinadas por um terceiro confiável para provar sua autenticidade. Um certificado digital pode ter vários formatos diferentes.

O PGP reconhece dois formatos de certificado diferentes:

● Certificados PGP ● Certificados X.509 Formato do certificado PGP. Um certificado PGP inclui (mas não está limitado a) as seguintes informações: ● O número da versão do PGP — identifica qual versão do PGP foi usada para criar a chave associada ao certificado. A chave pública do titular do certificado — a parte pública do seu par de chaves, juntamente com o algoritmo da chave: RSA, DH (Diffie-Hellman) ou DSA (Algoritmo de Assinatura Digital).

● As informações do detentor do certificado — consistem em informações de “identidade” sobre o usuário, como seu nome, ID de usuário, fotografia e assim por diante. ● A assinatura digital do proprietário do certificado — também chamada de autoassinatura, é a assinatura que utiliza a chave privada correspondente da chave pública associada ao certificado. ● O período de validade do certificado — a data/hora de início e a data/hora de expiração do certificado; indica quando o certificado irá expirar. ● O algoritmo de criptografia simétrica preferido para a chave — indica o algoritmo de criptografia para o qual o proprietário do certificado prefere que as informações sejam criptografadas. Os algoritmos suportados são CAST, IDEA ou Triple-DES. Você pode pensar em um certificado PGP como uma chave pública com um ou mais rótulos vinculados a ele (veja a Figura 1.9 ). Nessas 'etiquetas' você encontrará informações que identificam o proprietário da chave e uma assinatura do proprietário da chave, que afirma que a chave e a identificação andam juntas. (Essa assinatura específica é chamada de autoassinatura; todo certificado PGP contém uma autoassinatura.) Um aspecto único do formato de certificado PGP é que um único certificado pode conter múltiplas assinaturas. Várias ou muitas pessoas podem assinar o par chave/identificação para atestar a sua própria garantia de que a chave pública pertence definitivamente ao proprietário especificado. Se você procurar em um servidor de certificados público, poderá notar que certos certificados, como o do criador do PGP, Phil Zimmermann, contêm muitas assinaturas. Alguns certificados PGP consistem em uma chave pública com vários rótulos, cada um contendo um meio diferente de identificar o proprietário da chave (por exemplo, o nome do proprietário e a conta de e-mail corporativa, o apelido do proprietário e a conta de e-mail residencial, uma fotografia do proprietário — tudo em um certificado). A lista de assinaturas de cada uma dessas identidades pode ser diferente; as assinaturas atestam a autenticidade de que um dos rótulos pertence à chave pública, e não que todos os rótulos da chave sejam autênticos. (Observe que 'autêntico' está nos olhos de quem vê - assinaturas são opiniões, e diferentes pessoas dedicam diferentes níveis de devida diligência na verificação da autenticidade antes de assinar uma chave.) Figura 1-9. Um certificado PGP

Formato de certificado X.509.

X.509 é outro formato de certificado muito comum. Todos os certificados X.509 estão em conformidade com o padrão internacional ITU-T X.509; assim (teoricamente) os certificados X.509 criados para um aplicativo podem ser usados ​​por qualquer aplicativo compatível com X.509. Na prática, porém, diferentes empresas criaram suas próprias extensões para certificados X.509, e nem todas funcionam juntas. Um certificado exige que alguém valide que uma chave pública e o nome do proprietário da chave andam juntos. Com os certificados PGP, qualquer pessoa pode desempenhar o papel de validador. Com certificados X.509, o validador é sempre uma Autoridade Certificadora ou alguém designado por uma CA. (Tenha em mente que os certificados PGP também suportam totalmente uma estrutura hierárquica usando uma CA para validar certificados.)

Um certificado X.509 é uma coleção de um conjunto padrão de campos contendo informações sobre um usuário ou dispositivo e sua chave pública correspondente. O padrão X.509 define quais informações vão para o certificado e descreve como codificá-lo (o formato dos dados). Todos os certificados X.509 possuem os seguintes dados:

O número da versão X.509

— identifica qual versão do padrão X.509 se aplica a este certificado, o que afeta quais informações podem ser especificadas nele. A mais atual é a versão 3.

A chave pública do titular do certificado

— a chave pública do titular do certificado, juntamente com um identificador de algoritmo que especifica a qual sistema criptográfico a chave pertence e quaisquer parâmetros de chave associados.

O número de série do certificado

— a entidade (aplicação ou pessoa) que criou o certificado é responsável por atribuir-lhe um número de série único para distingui-lo de outros certificados que emite. Esta informação é usada de diversas maneiras; por exemplo, quando um certificado é revogado, seu número de série é colocado em uma Lista de Revogação de Certificados ou CRL.

O identificador exclusivo do detentor do certificado

— (ou DN — nome distinto). Este nome pretende ser exclusivo na Internet. Este nome pretende ser exclusivo na Internet. Um DN consiste em múltiplas subseções e pode ser parecido com isto: CN=Bob Allen, OU=Divisão Total de Segurança de Rede, O=Network Associates, Inc., C=EUA (Referem-se ao nome comum, à unidade organizacional, à organização e ao país do sujeito .)

O período de validade do certificado

— a data/hora de início e a data/hora de expiração do certificado; indica quando o certificado irá expirar.

O nome exclusivo do emissor do certificado

— o nome exclusivo da entidade que assinou o certificado. Normalmente é uma CA. A utilização do certificado implica confiar na entidade que assinou este certificado. (Observe que em alguns casos, como certificados de CA raiz ou de nível superior , o emissor assina seu próprio certificado.)

A assinatura digital do emitente

— a assinatura utilizando a chave privada da entidade que emitiu o certificado.

O identificador do algoritmo de assinatura

— identifica o algoritmo usado pela CA para assinar o certificado.

Existem muitas diferenças entre um certificado X.509 e um certificado PGP, mas as mais importantes são as seguintes: você pode criar seu próprio certificado PGP;

● você deve solicitar e receber um certificado X.509 de uma autoridade de certificação

● Os certificados X.509 suportam nativamente apenas um único nome para o proprietário da chave

● Os certificados X.509 suportam apenas uma única assinatura digital para atestar a validade da chave

Para obter um certificado X.509, você deve solicitar a uma CA a emissão de um certificado. Você fornece sua chave pública, prova de que possui a chave privada correspondente e algumas informações específicas sobre você. Em seguida, você assina digitalmente as informações e envia o pacote completo – a solicitação de certificado – para a CA. A CA então realiza algumas diligências para verificar se as informações fornecidas estão corretas e, em caso afirmativo, gera o certificado e o devolve.

Você pode pensar em um certificado X.509 como um certificado de papel padrão (semelhante ao que você recebeu ao concluir uma aula de primeiros socorros básicos) com uma chave pública colada nele. Ele contém seu nome e algumas informações sobre você, além da assinatura da pessoa que o emitiu para você.

Figura 1-10. Um certificado X.509 Provavelmente, o uso mais visível dos certificados X.509 atualmente é em navegadores da web.

Validade e confiança Cada usuário em um sistema de chave pública está vulnerável a confundir uma chave falsa (certificado) com uma chave real. Validade é a confiança de que um certificado de chave pública pertence ao seu suposto proprietário. A validade é essencial em um ambiente de chave pública onde você deve estabelecer constantemente se um determinado certificado é autêntico ou não. Depois de ter certeza de que um certificado pertencente a outra pessoa é válido, você pode assinar a cópia em seu chaveiro para atestar que verificou o certificado e que ele é autêntico. Se quiser que outras pessoas saibam que você deu ao certificado seu selo de aprovação, você pode exportar a assinatura para um servidor de certificados para que outras pessoas possam vê-la.

Conforme descrito na seção Infraestruturas de Chave Pública , algumas empresas designam uma ou mais Autoridades de Certificação (CAs) para indicar a validade do certificado. Em uma organização que usa uma PKI com certificados X.509, é função da CA emitir certificados aos usuários — um processo que geralmente envolve responder à solicitação de certificado do usuário. Em uma organização que usa certificados PGP sem PKI, é função da CA verificar a autenticidade de todos os certificados PGP e depois assinar os bons. Basicamente, o objetivo principal de uma CA é vincular uma chave pública às informações de identificação contidas no certificado e, assim, garantir a terceiros que algum cuidado foi tomado para garantir que esta ligação das informações de identificação e da chave seja válida. O CA é o Grand Pooh-bah da validação em uma organização; alguém em quem todos confiam e, em algumas organizações, como aquelas que utilizam uma PKI, nenhum certificado é considerado válido, a menos que tenha sido assinado por uma CA confiável.

Verificando validade.

Uma maneira de estabelecer a validade é passar por algum processo manual. Existem várias maneiras de fazer isso. Você pode exigir que o destinatário pretendido lhe entregue fisicamente uma cópia de sua chave pública. Mas isto é muitas vezes inconveniente e ineficiente. Outra forma é verificar manualmente a impressão digital do certificado. Assim como as impressões digitais de cada ser humano são únicas, a impressão digital de cada certificado PGP é única. A impressão digital é um hash do certificado do usuário e aparece como uma das propriedades do certificado. No PGP, a impressão digital pode aparecer como um número hexadecimal ou uma série das chamadas palavras biométricas, que são foneticamente distintas e são usadas para facilitar um pouco o processo de identificação da impressão digital. Você pode verificar se um certificado é válido ligando para o proprietário da chave (para que você origine a transação) e pedindo ao proprietário que leia a impressão digital de sua chave para você e compare essa impressão digital com aquela que você acredita ser a verdadeira. Isso funciona se você conhece a voz do proprietário, mas como verificar manualmente a identidade de alguém que você não conhece? Algumas pessoas colocam a impressão digital de sua chave em seus cartões de visita exatamente por esse motivo. Outra forma de estabelecer a validade do certificado de alguém é confiar que um terceiro indivíduo passou pelo processo de validação do mesmo. Uma CA, por exemplo, é responsável por garantir que, antes de emitir um certificado, ele ou ela o verifique cuidadosamente para ter certeza de que a parte da chave pública realmente pertence ao suposto proprietário. Qualquer pessoa que confie na CA considerará automaticamente quaisquer certificados assinados pela CA como válidos. Outro aspecto da verificação da validade é garantir que o certificado não foi revogado. Para obter mais informações, consulte a seção Revogação de certificado .

Estabelecendo confiança.

Você valida certificados. Você confia nas pessoas. Mais especificamente, você confia nas pessoas para validar os certificados de outras pessoas. Normalmente, a menos que o proprietário lhe entregue o certificado, você terá que confiar na palavra de outra pessoa de que ele é válido.

Introdutores meta e confiáveis.

​​Na maioria das situações, as pessoas confiam completamente na CA para estabelecer a validade dos certificados. Isso significa que todos os demais dependem da CA para passar por todo o processo de validação manual. Isso é aceitável até um certo número de usuários ou locais de trabalho e, então, não é possível para a AC manter o mesmo nível de validação de qualidade. Nesse caso, é necessário adicionar outros validadores ao sistema.

Um CA também pode ser um meta- introdutor. Um meta-introdutor confere não apenas validade às chaves, mas também confere a capacidade de confiar nas chaves a outros. Semelhante ao rei que entrega seu selo a seus conselheiros de confiança para que eles possam agir de acordo com sua autoridade, o meta-introdutor permite que outros atuem como introdutores de confiança. Esses introdutores confiáveis ​​podem validar chaves com o mesmo efeito do meta-introdutor. Eles não podem, entretanto, criar novos introdutores confiáveis.

Meta-introdutor e introdutor confiável são termos PGP. Em um ambiente X.509, o meta-introdutor é chamado de Autoridade de Certificação raiz ( CA raiz) e os introdutores confiáveis ​​são Autoridades de Certificação subordinadas . A CA raiz usa a chave privada associada a um tipo de certificado especial denominado certificado CA raiz para assinar certificados. Qualquer certificado assinado pelo certificado CA raiz é visto como válido por qualquer outro certificado assinado pela raiz. Este processo de validação funciona mesmo para certificados assinados por outras CAs no sistema — desde que o certificado da CA raiz tenha assinado o certificado da CA subordinada, qualquer certificado assinado pela CA será considerado válido para outras pessoas dentro da hierarquia. Este processo de verificação de backup por meio do sistema para ver quem assinou cujo certificado é chamado de rastreamento de um caminho de certificação ou cadeia de certificação.

Modelos de confiança.

Em sistemas relativamente fechados, como em uma pequena empresa, é fácil rastrear um caminho de certificação até a CA raiz. No entanto, os usuários muitas vezes precisam se comunicar com pessoas fora do seu ambiente corporativo, incluindo algumas que nunca conheceram, como fornecedores, consumidores, clientes, associados e assim por diante. É difícil estabelecer uma linha de confiança com aqueles em quem sua CA não confia explicitamente. As empresas seguem um ou outro modelo de confiança, que determina como os usuários irão estabelecer a validade do certificado. Existem três modelos diferentes:

Confiança Direta.

Confiança Hierárquica Uma teia de confiança Confiança direta A confiança direta é o modelo de confiança mais simples. Neste modelo, um usuário confia que uma chave é válida porque sabe de onde ela veio. Todos os criptosistemas usam essa forma de confiança de alguma forma. Por exemplo, em navegadores da Web, as chaves raiz da Autoridade de Certificação são diretamente confiáveis ​​porque foram enviadas pelo fabricante. Se houver alguma forma de hierarquia, ela se estenderá a partir desses certificados diretamente confiáveis. No PGP, um usuário que valida as chaves e nunca define outro certificado para ser um introdutor confiável está usando confiança direta. Figura 1-11. Confiança direta

Confiança Hierárquica.

Em um sistema hierárquico, há vários certificados "raiz" a partir dos quais a confiança se estende. Esses certificados podem certificar eles próprios certificados ou podem certificar certificados que certificam ainda outros certificados em alguma cadeia. Considere isso como uma grande “árvore” de confiança. A validade do certificado "folha" é verificada rastreando desde seu certificador até outros certificadores, até que um certificado raiz diretamente confiável seja encontrado.

Figura 1-12. Confiança hierárquica

Teia de Confiança.

Uma teia de confiança abrange ambos os outros modelos, mas também acrescenta a noção de que a confiança está nos olhos de quem vê (que é a visão do mundo real) e a ideia de que mais informação é melhor. É, portanto, um modelo de confiança cumulativa. Um certificado pode ser confiável diretamente ou confiável em alguma cadeia que remonta a um certificado raiz diretamente confiável (o meta-introdutor) ou por algum grupo de introdutores.

Talvez você já tenha ouvido falar do termo seis graus de separação, que sugere que qualquer pessoa no mundo pode determinar algum vínculo com qualquer outra pessoa no mundo usando seis ou menos outras pessoas como intermediários. Esta é uma teia de introdutores. É também a visão de confiança do PGP. PGP usa assinaturas digitais como forma de introdução. Quando qualquer usuário assina a chave de outro, ele ou ela se torna o introdutor dessa chave. À medida que esse processo avança, ele estabelece uma rede de confiança.

Em um ambiente PGP, qualquer usuário pode atuar como autoridade certificadora. Qualquer usuário PGP pode validar o certificado de chave pública de outro usuário PGP. No entanto, tal certificado só é válido para outro usuário se a parte confiável reconhecer o validador como um introdutor confiável. (Ou seja, você confia na minha opinião de que as chaves dos outros são válidas apenas se você me considerar um apresentador confiável. Caso contrário, minha opinião sobre a validade das outras chaves é discutível.) Armazenados no chaveiro público de cada usuário estão indicadores de

● se o usuário considera ou não uma chave específica válida

● o nível de confiança que o usuário deposita na chave que o proprietário da chave pode servir como certificador das chaves de terceiros

Você indica, na sua cópia da minha chave, se acha que meu julgamento conta. Na verdade, é um sistema de reputação: certas pessoas têm a reputação de fornecer boas assinaturas e as pessoas confiam nelas para atestar a validade de outras chaves.

Níveis de confiança no PGP.

O nível mais alto de confiança em uma chave, a confiança implícita , é a confiança em seu próprio par de chaves. O PGP assume que se você possui a chave privada, você deve confiar nas ações da sua chave pública relacionada. Quaisquer chaves assinadas pela sua chave implicitamente confiável são válidas.

Existem três níveis de confiança que você pode atribuir à chave pública de outra pessoa:

● Confiança total ● Confiança marginal ● Não confiável (ou não confiável)

Para tornar as coisas confusas, também existem três níveis de validade:

● Válido ● Marginalmente válido ● Inválido

Para definir a chave de outra pessoa como um introdutor confiável, você

1. Comece com uma chave válida, que seja.
2. assinado por você ou

3. assinado por outro apresentador confiável e então

4. Defina o nível de confiança que você acha que o proprietário da chave tem direito.

Por exemplo, suponha que seu chaveiro contenha a chave de Alice. Você validou a chave de Alice e indica isso assinando-a. Você sabe que Alice é uma verdadeira defensora da validação de chaves de outras pessoas. Portanto, você atribui a chave dela com confiança total. Isso faz de Alice uma Autoridade Certificadora. Se Alice assinar a chave de outra pessoa, ela aparecerá como Válida em seu chaveiro. O PGP requer uma assinatura Totalmente confiável ou duas assinaturas Marginalmente confiáveis ​​para estabelecer uma chave como válida. O método do PGP de considerar dois Marginais iguais a um Completo é semelhante a um comerciante que solicita duas formas de identificação. Você pode considerar Alice bastante confiável e também considerar Bob bastante confiável. Qualquer um deles sozinho corre o risco de assinar acidentalmente uma chave falsificada, portanto, você pode não depositar total confiança em nenhum deles. No entanto, as probabilidades de ambos os indivíduos terem assinado a mesma chave falsa são provavelmente pequenas.

Revogação de certificado.

Os certificados só são úteis enquanto são válidos. Não é seguro simplesmente presumir que um certificado é válido para sempre. Na maioria das organizações e em todas as PKIs, os certificados têm uma vida útil restrita. Isso restringe o período em que um sistema fica vulnerável caso ocorra um comprometimento do certificado.

Os certificados são assim criados com um período de validade programado: uma data/hora de início e uma data/hora de expiração. Espera-se que o certificado seja utilizável durante todo o seu período de validade (seu tempo de vida ). Quando o certificado expirar, ele não será mais válido, pois a autenticidade do seu par chave/identificação não estará mais garantida. (O certificado ainda pode ser usado com segurança para reconfirmar informações que foram criptografadas ou assinadas dentro do período de validade – no entanto, ele não deve ser confiável para tarefas criptográficas futuras.)

Existem também situações em que é necessário invalidar um certificado antes da sua data de expiração, como quando o titular do certificado termina o contrato de trabalho com a empresa ou suspeita que a chave privada correspondente do certificado foi comprometida. Isso é chamado de revogação. Um certificado revogado é muito mais suspeito do que um certificado expirado. Os certificados expirados são inutilizáveis, mas não apresentam a mesma ameaça de comprometimento que um certificado revogado. Qualquer pessoa que tenha assinado um certificado pode revogar a sua assinatura no certificado (desde que utilize a mesma chave privada que criou a assinatura). Uma assinatura revogada indica que o signatário não acredita mais que a chave pública e as informações de identificação pertencem uma à outra, ou que a chave pública do certificado (ou a chave privada correspondente) foi comprometida. Uma assinatura revogada deve ter quase tanto peso quanto um certificado revogado. Com certificados X.509, uma assinatura revogada é praticamente igual a um certificado revogado, visto que a única assinatura no certificado é aquela que o tornou válido em primeiro lugar – a assinatura da CA. Os certificados PGP fornecem o recurso adicional de que você pode revogar todo o seu certificado (não apenas as assinaturas nele) se você achar que o certificado foi comprometido. Somente o proprietário do certificado (o detentor da chave privada correspondente) ou alguém que o proprietário do certificado tenha designado como revogador pode revogar um certificado PGP. (Designar um revogador é uma prática útil, pois muitas vezes é a perda da senha da chave privada correspondente do certificado que leva um usuário PGP a revogar seu certificado - uma tarefa que só é possível se alguém tiver acesso à chave privada. ) Somente o emissor do certificado pode revogar um certificado X.509.

Comunicar que um certificado foi revogado.

Quando um certificado é revogado, é importante conscientizar os usuários potenciais do certificado de que ele não é mais válido. Com certificados PGP, a maneira mais comum de comunicar que um certificado foi revogado é publicá-lo em um servidor de certificados para que outras pessoas que desejem se comunicar com você sejam avisadas para não usar essa chave pública. Em um ambiente PKI, a comunicação de certificados revogados é mais comumente obtida por meio de uma estrutura de dados chamada Lista de Revogação de Certificados, ou CRL, que é publicada pela CA. A CRL contém uma lista validada com carimbo de data e hora de todos os certificados revogados e não expirados no sistema. Os certificados revogados permanecem na lista apenas até expirarem e, em seguida, são removidos da lista — isso evita que a lista fique muito longa. A CA distribui a CRL aos usuários em algum intervalo programado regularmente (e potencialmente fora do ciclo, sempre que um certificado é revogado). Teoricamente, isso impedirá que os usuários usem involuntariamente um certificado comprometido. É possível, no entanto, que haja um período de tempo entre as CRLs em que um certificado recentemente comprometido seja usado.

O que é uma senha?

A maioria das pessoas está familiarizada com a restrição de acesso a sistemas de computador por meio de uma senha, que é uma sequência única de caracteres que um usuário digita como código de identificação.

Uma senha longa é uma versão mais longa de uma senha e, em teoria, mais segura. Normalmente composta por várias palavras, uma frase secreta é mais segura contra ataques de dicionário padrão, em que o invasor tenta todas as palavras do dicionário na tentativa de determinar sua senha. As melhores senhas são relativamente longas e complexas e contêm uma combinação de letras maiúsculas e minúsculas, caracteres numéricos e de pontuação. O PGP usa uma senha para criptografar sua chave privada em sua máquina. Sua chave privada é criptografada em seu disco usando um hash de sua senha como chave secreta. Você usa a senha para descriptografar e usar sua chave privada. Uma senha deve ser difícil de esquecer e difícil de ser adivinhada por outras pessoas. Deve ser algo já firmemente enraizado na sua memória de longo prazo, em vez de algo que você invente do zero. Por que? Porque se você esquecer sua senha, você estará sem sorte. Sua chave privada é total e absolutamente inútil sem sua senha e nada pode ser feito a respeito. Lembra-se da citação anterior neste capítulo?

PGP é a criptografia que manterá os principais governos fora dos seus arquivos. Certamente também o manterá fora de seus arquivos. Tenha isso em mente quando decidir alterar sua senha para a piada daquela piada que você nunca consegue lembrar.

Divisão de chave.

Dizem que um segredo não é segredo se for conhecido por mais de uma pessoa. Compartilhar um par de chaves privadas representa um grande problema. Embora não seja uma prática recomendada, às vezes é necessário compartilhar um par de chaves privadas. Chaves de assinatura corporativa, por exemplo, são chaves privadas usadas por uma empresa para assinar – por exemplo – documentos legais, informações pessoais confidenciais ou comunicados de imprensa para autenticar sua origem. Nesse caso, vale a pena que vários membros da empresa tenham acesso à chave privada. No entanto, isto significa que qualquer indivíduo pode agir plenamente em nome da empresa. Nesse caso, é aconselhável dividir a chave entre várias pessoas, de modo que mais de uma ou duas pessoas apresentem um pedaço da chave para reconstituí-la em condições utilizáveis. Se poucas peças da chave estiverem disponíveis, a chave ficará inutilizável. Alguns exemplos são dividir uma chave em três partes e exigir duas delas para reconstituir a chave, ou dividi-la em duas partes e exigir ambas as peças. Se uma conexão de rede segura for usada durante o processo de reconstituição, os acionistas da chave não precisam estar fisicamente presentes para aderirem novamente à chave.

@ 21335073:a244b1ad

I want to see Nostr succeed. If you can think of a way I can help make that happen, I’m open to it. I’d like your suggestions.

My schedule’s shifting soon, and I could volunteer a few hours a week to a Nostr project. I won’t have more total time, but how I use it will change.

Why help? I care about freedom. Nostr’s one of the most powerful freedom tools I’ve seen in my lifetime. If I believe that, I should act on it.

I don’t care about money or sats. I’m not rich, I don’t have extra cash. That doesn’t drive me—freedom does. I’m volunteering, not asking for pay.

I’m not here for clout. I’ve had enough spotlight in my life; it doesn’t move me. If I wanted clout, I’d be on Twitter dropping basic takes. Clout’s easy. Freedom’s hard. I’d rather help anonymously. No speaking at events—small meetups are cool for the vibe, but big conferences? Not my thing. I’ll never hit a huge Bitcoin conference. It’s just not my scene.

That said, I could be convinced to step up if it’d really boost Nostr—as long as it’s legal and gets results.

In this space, I’d watch for social engineering. I watch out for it. I’m not here to make friends, just to help. No shade—you all seem great—but I’ve got a full life and awesome friends irl. I don’t need your crew or to be online cool. Connect anonymously if you want; I’d encourage it.

I’m sick of watching other social media alternatives grow while Nostr kinda stalls. I could trash-talk, but I’d rather do something useful.

Skills? I’m good at spotting social media problems and finding possible solutions. I won’t overhype myself—that’s weird—but if you’re responding, you probably see something in me. Perhaps you see something that I don’t see in myself.

If you need help now or later with Nostr projects, reach out. Nostr only—nothing else. Anonymous contact’s fine. Even just a suggestion on how I can pitch in, no project attached, works too. 💜

Creeps or harassment will get blocked or I’ll nuke my simplex code if it becomes a problem.

https://simplex.chat/contact#/?v=2-4&smp=smp%3A%2F%2FSkIkI6EPd2D63F4xFKfHk7I1UGZVNn6k1QWZ5rcyr6w%3D%40smp9.simplex.im%2FbI99B3KuYduH8jDr9ZwyhcSxm2UuR7j0%23%2F%3Fv%3D1-2%26dh%3DMCowBQYDK2VuAyEAS9C-zPzqW41PKySfPCEizcXb1QCus6AyDkTTjfyMIRM%253D%26srv%3Djssqzccmrcws6bhmn77vgmhfjmhwlyr3u7puw4erkyoosywgl67slqqd.onion

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

@ 30ceb64e:7f08bdf5

Status: Draft
Author: TheWildHustle

Abstract

This NIP defines a framework for storing and sharing health and fitness profile data on Nostr. It establishes a set of standardized event kinds for individual health metrics, allowing applications to selectively access specific health information while preserving user control and privacy.

In this framework exists - NIP-101h.1 Weight using kind 1351 - NIP-101h.2 Height using kind 1352 - NIP-101h.3 Age using kind 1353 - NIP-101h.4 Gender using kind 1354 - NIP-101h.5 Fitness Level using kind 1355

Motivation

I want to build and support an ecosystem of health and fitness related nostr clients that have the ability to share and utilize a bunch of specific interoperable health metrics.

• Selective access - Applications can access only the data they need
• User control - Users can choose which metrics to share
• Interoperability - Different health applications can share data
• Privacy - Sensitive health information can be managed independently

Specification

Kind Number Range

Health profile metrics use the kind number range 1351-1399:

| Kind | Metric | | --------- | ---------------------------------- | | 1351 | Weight | | 1352 | Height | | 1353 | Age | | 1354 | Gender | | 1355 | Fitness Level | | 1356-1399 | Reserved for future health metrics |

Common Structure

All health metric events SHOULD follow these guidelines:

• The content field contains the primary value of the metric
• Required tags:
• ['t', 'health'] - For categorizing as health data
• ['t', metric-specific-tag] - For identifying the specific metric
• ['unit', unit-of-measurement] - When applicable
• Optional tags:
• ['converted_value', value, unit] - For providing alternative unit measurements
• ['timestamp', ISO8601-date] - When the metric was measured
• ['source', application-name] - The source of the measurement

Unit Handling

Health metrics often have multiple ways to be measured. To ensure interoperability:

• Where multiple units are possible, one standard unit SHOULD be chosen as canonical
• When using non-standard units, a converted_value tag SHOULD be included with the canonical unit
• Both the original and converted values should be provided for maximum compatibility

Client Implementation Guidelines

Clients implementing this NIP SHOULD:

• Allow users to explicitly choose which metrics to publish
• Support reading health metrics from other users when appropriate permissions exist
• Support updating metrics with new values over time
• Preserve tags they don't understand for future compatibility
• Support at least the canonical unit for each metric

Extensions

New health metrics can be proposed as extensions to this NIP using the format:

• NIP-101h.X where X is the metric number

Each extension MUST specify: - A unique kind number in the range 1351-1399 - The content format and meaning - Required and optional tags - Examples of valid events

Privacy Considerations

Health data is sensitive personal information. Clients implementing this NIP SHOULD:

• Make it clear to users when health data is being published
• Consider incorporating NIP-44 encryption for sensitive metrics
• Allow users to selectively share metrics with specific individuals
• Provide easy ways to delete previously published health data

---

NIP-101h.1: Weight

Description

This NIP defines the format for storing and sharing weight data on Nostr.

Event Kind: 1351

Content

The content field MUST contain the numeric weight value as a string.

Required Tags

• ['unit', 'kg' or 'lb'] - Unit of measurement
• ['t', 'health'] - Categorization tag
• ['t', 'weight'] - Specific metric tag

Optional Tags

• ['converted_value', value, unit] - Provides the weight in alternative units for interoperability
• ['timestamp', ISO8601 date] - When the weight was measured

Examples

json { "kind": 1351, "content": "70", "tags": [ ["unit", "kg"], ["t", "health"], ["t", "weight"] ] }

json { "kind": 1351, "content": "154", "tags": [ ["unit", "lb"], ["t", "health"], ["t", "weight"], ["converted_value", "69.85", "kg"] ] }

NIP-101h.2: Height

Status: Draft

Description

This NIP defines the format for storing and sharing height data on Nostr.

Event Kind: 1352

Content

The content field can use two formats: - For metric height: A string containing the numeric height value in centimeters (cm) - For imperial height: A JSON string with feet and inches properties

Required Tags

• ['t', 'health'] - Categorization tag
• ['t', 'height'] - Specific metric tag
• ['unit', 'cm' or 'imperial'] - Unit of measurement

Optional Tags

• ['converted_value', value, 'cm'] - Provides height in centimeters for interoperability when imperial is used
• ['timestamp', ISO8601-date] - When the height was measured

Examples

```jsx // Example 1: Metric height Apply to App.jsx

// Example 2: Imperial height with conversion Apply to App.jsx ```

Implementation Notes

• Centimeters (cm) is the canonical unit for height interoperability
• When using imperial units, a conversion to centimeters SHOULD be provided
• Height values SHOULD be positive integers
• For maximum compatibility, clients SHOULD support both formats

---

NIP-101h.3: Age

Status: Draft

Description

This NIP defines the format for storing and sharing age data on Nostr.

Event Kind: 1353

Content

The content field MUST contain the numeric age value as a string.

Required Tags

• ['unit', 'years'] - Unit of measurement
• ['t', 'health'] - Categorization tag
• ['t', 'age'] - Specific metric tag

Optional Tags

• ['timestamp', ISO8601-date] - When the age was recorded
• ['dob', ISO8601-date] - Date of birth (if the user chooses to share it)

Examples

```jsx // Example 1: Basic age Apply to App.jsx

// Example 2: Age with DOB Apply to App.jsx ```

Implementation Notes

• Age SHOULD be represented as a positive integer
• For privacy reasons, date of birth (dob) is optional
• Clients SHOULD consider updating age automatically if date of birth is known
• Age can be a sensitive metric and clients may want to consider encrypting this data

---

NIP-101h.4: Gender

Status: Draft

Description

This NIP defines the format for storing and sharing gender data on Nostr.

Event Kind: 1354

Content

The content field contains a string representing the user's gender.

Required Tags

• ['t', 'health'] - Categorization tag
• ['t', 'gender'] - Specific metric tag

Optional Tags

• ['timestamp', ISO8601-date] - When the gender was recorded
• ['preferred_pronouns', string] - User's preferred pronouns

Common Values

While any string value is permitted, the following common values are recommended for interoperability: - male - female - non-binary - other - prefer-not-to-say

Examples

```jsx // Example 1: Basic gender Apply to App.jsx

// Example 2: Gender with pronouns Apply to App.jsx ```

Implementation Notes

• Clients SHOULD allow free-form input for gender
• For maximum compatibility, clients SHOULD support the common values
• Gender is a sensitive personal attribute and clients SHOULD consider appropriate privacy controls
• Applications focusing on health metrics should be respectful of gender diversity

---

NIP-101h.5: Fitness Level

Status: Draft

Description

This NIP defines the format for storing and sharing fitness level data on Nostr.

Event Kind: 1355

Content

The content field contains a string representing the user's fitness level.

Required Tags

• ['t', 'health'] - Categorization tag
• ['t', 'fitness'] - Fitness category tag
• ['t', 'level'] - Specific metric tag

Optional Tags

• ['timestamp', ISO8601-date] - When the fitness level was recorded
• ['activity', activity-type] - Specific activity the fitness level relates to
• ['metrics', JSON-string] - Quantifiable fitness metrics used to determine level

Common Values

While any string value is permitted, the following common values are recommended for interoperability: - beginner - intermediate - advanced - elite - professional

Examples

```jsx // Example 1: Basic fitness level Apply to App.jsx

// Example 2: Activity-specific fitness level with metrics Apply to App.jsx ```

Implementation Notes

• Fitness level is subjective and may vary by activity
• The activity tag can be used to specify fitness level for different activities
• The metrics tag can provide objective measurements to support the fitness level
• Clients can extend this format to include activity-specific fitness assessments
• For general fitness apps, the simple beginner/intermediate/advanced scale is recommended

@ 21335073:a244b1ad

Warning: This piece contains a conversation about difficult topics. Please proceed with caution.

TL;DR please educate your children about online safety.

Julian Assange wrote in his 2012 book Cypherpunks, “This book is not a manifesto. There isn’t time for that. This book is a warning.” I read it a few times over the past summer. Those opening lines definitely stood out to me. I wish we had listened back then. He saw something about the internet that few had the ability to see. There are some individuals who are so close to a topic that when they speak, it’s difficult for others who aren’t steeped in it to visualize what they’re talking about. I didn’t read the book until more recently. If I had read it when it came out, it probably would have sounded like an unknown foreign language to me. Today it makes more sense.

This isn’t a manifesto. This isn’t a book. There is no time for that. It’s a warning and a possible solution from a desperate and determined survivor advocate who has been pulling and unraveling a thread for a few years. At times, I feel too close to this topic to make any sense trying to convey my pathway to my conclusions or thoughts to the general public. My hope is that if nothing else, I can convey my sense of urgency while writing this. This piece is a watchman’s warning.

When a child steps online, they are walking into a new world. A new reality. When you hand a child the internet, you are handing them possibilities—good, bad, and ugly. This is a conversation about lowering the potential of negative outcomes of stepping into that new world and how I came to these conclusions. I constantly compare the internet to the road. You wouldn’t let a young child run out into the road with no guidance or safety precautions. When you hand a child the internet without any type of guidance or safety measures, you are allowing them to play in rush hour, oncoming traffic. “Look left, look right for cars before crossing.” We almost all have been taught that as children. What are we taught as humans about safety before stepping into a completely different reality like the internet? Very little.

I could never really figure out why many folks in tech, privacy rights activists, and hackers seemed so cold to me while talking about online child sexual exploitation. I always figured that as a survivor advocate for those affected by these crimes, that specific, skilled group of individuals would be very welcoming and easy to talk to about such serious topics. I actually had one hacker laugh in my face when I brought it up while I was looking for answers. I thought maybe this individual thought I was accusing them of something I wasn’t, so I felt bad for asking. I was constantly extremely disappointed and would ask myself, “Why don’t they care? What could I say to make them care more? What could I say to make them understand the crisis and the level of suffering that happens as a result of the problem?”

I have been serving minor survivors of online child sexual exploitation for years. My first case serving a survivor of this specific crime was in 2018—a 13-year-old girl sexually exploited by a serial predator on Snapchat. That was my first glimpse into this side of the internet. I won a national award for serving the minor survivors of Twitter in 2023, but I had been working on that specific project for a few years. I was nominated by a lawyer representing two survivors in a legal battle against the platform. I’ve never really spoken about this before, but at the time it was a choice for me between fighting Snapchat or Twitter. I chose Twitter—or rather, Twitter chose me. I heard about the story of John Doe #1 and John Doe #2, and I was so unbelievably broken over it that I went to war for multiple years. I was and still am royally pissed about that case. As far as I was concerned, the John Doe #1 case proved that whatever was going on with corporate tech social media was so out of control that I didn’t have time to wait, so I got to work. It was reading the messages that John Doe #1 sent to Twitter begging them to remove his sexual exploitation that broke me. He was a child begging adults to do something. A passion for justice and protecting kids makes you do wild things. I was desperate to find answers about what happened and searched for solutions. In the end, the platform Twitter was purchased. During the acquisition, I just asked Mr. Musk nicely to prioritize the issue of detection and removal of child sexual exploitation without violating digital privacy rights or eroding end-to-end encryption. Elon thanked me multiple times during the acquisition, made some changes, and I was thanked by others on the survivors’ side as well.

I still feel that even with the progress made, I really just scratched the surface with Twitter, now X. I left that passion project when I did for a few reasons. I wanted to give new leadership time to tackle the issue. Elon Musk made big promises that I knew would take a while to fulfill, but mostly I had been watching global legislation transpire around the issue, and frankly, the governments are willing to go much further with X and the rest of corporate tech than I ever would. My work begging Twitter to make changes with easier reporting of content, detection, and removal of child sexual exploitation material—without violating privacy rights or eroding end-to-end encryption—and advocating for the minor survivors of the platform went as far as my principles would have allowed. I’m grateful for that experience. I was still left with a nagging question: “How did things get so bad with Twitter where the John Doe #1 and John Doe #2 case was able to happen in the first place?” I decided to keep looking for answers. I decided to keep pulling the thread.

I never worked for Twitter. This is often confusing for folks. I will say that despite being disappointed in the platform’s leadership at times, I loved Twitter. I saw and still see its value. I definitely love the survivors of the platform, but I also loved the platform. I was a champion of the platform’s ability to give folks from virtually around the globe an opportunity to speak and be heard.

I want to be clear that John Doe #1 really is my why. He is the inspiration. I am writing this because of him. He represents so many globally, and I’m still inspired by his bravery. One child’s voice begging adults to do something—I’m an adult, I heard him. I’d go to war a thousand more lifetimes for that young man, and I don’t even know his name. Fighting has been personally dark at times; I’m not even going to try to sugarcoat it, but it has been worth it.

The data surrounding the very real crime of online child sexual exploitation is available to the public online at any time for anyone to see. I’d encourage you to go look at the data for yourself. I believe in encouraging folks to check multiple sources so that you understand the full picture. If you are uncomfortable just searching around the internet for information about this topic, use the terms “CSAM,” “CSEM,” “SG-CSEM,” or “AI Generated CSAM.” The numbers don’t lie—it’s a nightmare that’s out of control. It’s a big business. The demand is high, and unfortunately, business is booming. Organizations collect the data, tech companies often post their data, governments report frequently, and the corporate press has covered a decent portion of the conversation, so I’m sure you can find a source that you trust.

Technology is changing rapidly, which is great for innovation as a whole but horrible for the crime of online child sexual exploitation. Those wishing to exploit the vulnerable seem to be adapting to each technological change with ease. The governments are so far behind with tackling these issues that as I’m typing this, it’s borderline irrelevant to even include them while speaking about the crime or potential solutions. Technology is changing too rapidly, and their old, broken systems can’t even dare to keep up. Think of it like the governments’ “War on Drugs.” Drugs won. In this case as well, the governments are not winning. The governments are talking about maybe having a meeting on potentially maybe having legislation around the crimes. The time to have that meeting would have been many years ago. I’m not advocating for governments to legislate our way out of this. I’m on the side of educating and innovating our way out of this.

I have been clear while advocating for the minor survivors of corporate tech platforms that I would not advocate for any solution to the crime that would violate digital privacy rights or erode end-to-end encryption. That has been a personal moral position that I was unwilling to budge on. This is an extremely unpopular and borderline nonexistent position in the anti-human trafficking movement and online child protection space. I’m often fearful that I’m wrong about this. I have always thought that a better pathway forward would have been to incentivize innovation for detection and removal of content. I had no previous exposure to privacy rights activists or Cypherpunks—actually, I came to that conclusion by listening to the voices of MENA region political dissidents and human rights activists. After developing relationships with human rights activists from around the globe, I realized how important privacy rights and encryption are for those who need it most globally. I was simply unwilling to give more power, control, and opportunities for mass surveillance to big abusers like governments wishing to enslave entire nations and untrustworthy corporate tech companies to potentially end some portion of abuses online. On top of all of it, it has been clear to me for years that all potential solutions outside of violating digital privacy rights to detect and remove child sexual exploitation online have not yet been explored aggressively. I’ve been disappointed that there hasn’t been more of a conversation around preventing the crime from happening in the first place.

What has been tried is mass surveillance. In China, they are currently under mass surveillance both online and offline, and their behaviors are attached to a social credit score. Unfortunately, even on state-run and controlled social media platforms, they still have child sexual exploitation and abuse imagery pop up along with other crimes and human rights violations. They also have a thriving black market online due to the oppression from the state. In other words, even an entire loss of freedom and privacy cannot end the sexual exploitation of children online. It’s been tried. There is no reason to repeat this method.

It took me an embarrassingly long time to figure out why I always felt a slight coldness from those in tech and privacy-minded individuals about the topic of child sexual exploitation online. I didn’t have any clue about the “Four Horsemen of the Infocalypse.” This is a term coined by Timothy C. May in 1988. I would have been a child myself when he first said it. I actually laughed at myself when I heard the phrase for the first time. I finally got it. The Cypherpunks weren’t wrong about that topic. They were so spot on that it is borderline uncomfortable. I was mad at first that they knew that early during the birth of the internet that this issue would arise and didn’t address it. Then I got over it because I realized that it wasn’t their job. Their job was—is—to write code. Their job wasn’t to be involved and loving parents or survivor advocates. Their job wasn’t to educate children on internet safety or raise awareness; their job was to write code.

They knew that child sexual abuse material would be shared on the internet. They said what would happen—not in a gleeful way, but a prediction. Then it happened.

I equate it now to a concrete company laying down a road. As you’re pouring the concrete, you can say to yourself, “A terrorist might travel down this road to go kill many, and on the flip side, a beautiful child can be born in an ambulance on this road.” Who or what travels down the road is not their responsibility—they are just supposed to lay the concrete. I’d never go to a concrete pourer and ask them to solve terrorism that travels down roads. Under the current system, law enforcement should stop terrorists before they even make it to the road. The solution to this specific problem is not to treat everyone on the road like a terrorist or to not build the road.

So I understand the perceived coldness from those in tech. Not only was it not their job, but bringing up the topic was seen as the equivalent of asking a free person if they wanted to discuss one of the four topics—child abusers, terrorists, drug dealers, intellectual property pirates, etc.—that would usher in digital authoritarianism for all who are online globally.

Privacy rights advocates and groups have put up a good fight. They stood by their principles. Unfortunately, when it comes to corporate tech, I believe that the issue of privacy is almost a complete lost cause at this point. It’s still worth pushing back, but ultimately, it is a losing battle—a ticking time bomb.

I do think that corporate tech providers could have slowed down the inevitable loss of privacy at the hands of the state by prioritizing the detection and removal of CSAM when they all started online. I believe it would have bought some time, fewer would have been traumatized by that specific crime, and I do believe that it could have slowed down the demand for content. If I think too much about that, I’ll go insane, so I try to push the “if maybes” aside, but never knowing if it could have been handled differently will forever haunt me. At night when it’s quiet, I wonder what I would have done differently if given the opportunity. I’ll probably never know how much corporate tech knew and ignored in the hopes that it would go away while the problem continued to get worse. They had different priorities. The most voiceless and vulnerable exploited on corporate tech never had much of a voice, so corporate tech providers didn’t receive very much pushback.

Now I’m about to say something really wild, and you can call me whatever you want to call me, but I’m going to say what I believe to be true. I believe that the governments are either so incompetent that they allowed the proliferation of CSAM online, or they knowingly allowed the problem to fester long enough to have an excuse to violate privacy rights and erode end-to-end encryption. The US government could have seized the corporate tech providers over CSAM, but I believe that they were so useful as a propaganda arm for the regimes that they allowed them to continue virtually unscathed.

That season is done now, and the governments are making the issue a priority. It will come at a high cost. Privacy on corporate tech providers is virtually done as I’m typing this. It feels like a death rattle. I’m not particularly sure that we had much digital privacy to begin with, but the illusion of a veil of privacy feels gone.

To make matters slightly more complex, it would be hard to convince me that once AI really gets going, digital privacy will exist at all.

I believe that there should be a conversation shift to preserving freedoms and human rights in a post-privacy society.

I don’t want to get locked up because AI predicted a nasty post online from me about the government. I’m not a doomer about AI—I’m just going to roll with it personally. I’m looking forward to the positive changes that will be brought forth by AI. I see it as inevitable. A bit of privacy was helpful while it lasted. Please keep fighting to preserve what is left of privacy either way because I could be wrong about all of this.

On the topic of AI, the addition of AI to the horrific crime of child sexual abuse material and child sexual exploitation in multiple ways so far has been devastating. It’s currently out of control. The genie is out of the bottle. I am hopeful that innovation will get us humans out of this, but I’m not sure how or how long it will take. We must be extremely cautious around AI legislation. It should not be illegal to innovate even if some bad comes with the good. I don’t trust that the governments are equipped to decide the best pathway forward for AI. Source: the entire history of the government.

I have been personally negatively impacted by AI-generated content. Every few days, I get another alert that I’m featured again in what’s called “deep fake pornography” without my consent. I’m not happy about it, but what pains me the most is the thought that for a period of time down the road, many globally will experience what myself and others are experiencing now by being digitally sexually abused in this way. If you have ever had your picture taken and posted online, you are also at risk of being exploited in this way. Your child’s image can be used as well, unfortunately, and this is just the beginning of this particular nightmare. It will move to more realistic interpretations of sexual behaviors as technology improves. I have no brave words of wisdom about how to deal with that emotionally. I do have hope that innovation will save the day around this specific issue. I’m nervous that everyone online will have to ID verify due to this issue. I see that as one possible outcome that could help to prevent one problem but inadvertently cause more problems, especially for those living under authoritarian regimes or anyone who needs to remain anonymous online. A zero-knowledge proof (ZKP) would probably be the best solution to these issues. There are some survivors of violence and/or sexual trauma who need to remain anonymous online for various reasons. There are survivor stories available online of those who have been abused in this way. I’d encourage you seek out and listen to their stories.

There have been periods of time recently where I hesitate to say anything at all because more than likely AI will cover most of my concerns about education, awareness, prevention, detection, and removal of child sexual exploitation online, etc.

Unfortunately, some of the most pressing issues we’ve seen online over the last few years come in the form of “sextortion.” Self-generated child sexual exploitation (SG-CSEM) numbers are continuing to be terrifying. I’d strongly encourage that you look into sextortion data. AI + sextortion is also a huge concern. The perpetrators are using the non-sexually explicit images of children and putting their likeness on AI-generated child sexual exploitation content and extorting money, more imagery, or both from minors online. It’s like a million nightmares wrapped into one. The wild part is that these issues will only get more pervasive because technology is harnessed to perpetuate horror at a scale unimaginable to a human mind.

Even if you banned phones and the internet or tried to prevent children from accessing the internet, it wouldn’t solve it. Child sexual exploitation will still be with us until as a society we start to prevent the crime before it happens. That is the only human way out right now.

There is no reset button on the internet, but if I could go back, I’d tell survivor advocates to heed the warnings of the early internet builders and to start education and awareness campaigns designed to prevent as much online child sexual exploitation as possible. The internet and technology moved quickly, and I don’t believe that society ever really caught up. We live in a world where a child can be groomed by a predator in their own home while sitting on a couch next to their parents watching TV. We weren’t ready as a species to tackle the fast-paced algorithms and dangers online. It happened too quickly for parents to catch up. How can you parent for the ever-changing digital world unless you are constantly aware of the dangers?

I don’t think that the internet is inherently bad. I believe that it can be a powerful tool for freedom and resistance. I’ve spoken a lot about the bad online, but there is beauty as well. We often discuss how victims and survivors are abused online; we rarely discuss the fact that countless survivors around the globe have been able to share their experiences, strength, hope, as well as provide resources to the vulnerable. I do question if giving any government or tech company access to censorship, surveillance, etc., online in the name of serving survivors might not actually impact a portion of survivors negatively. There are a fair amount of survivors with powerful abusers protected by governments and the corporate press. If a survivor cannot speak to the press about their abuse, the only place they can go is online, directly or indirectly through an independent journalist who also risks being censored. This scenario isn’t hard to imagine—it already happened in China. During #MeToo, a survivor in China wanted to post their story. The government censored the post, so the survivor put their story on the blockchain. I’m excited that the survivor was creative and brave, but it’s terrifying to think that we live in a world where that situation is a necessity.

I believe that the future for many survivors sharing their stories globally will be on completely censorship-resistant and decentralized protocols. This thought in particular gives me hope. When we listen to the experiences of a diverse group of survivors, we can start to understand potential solutions to preventing the crimes from happening in the first place.

My heart is broken over the gut-wrenching stories of survivors sexually exploited online. Every time I hear the story of a survivor, I do think to myself quietly, “What could have prevented this from happening in the first place?” My heart is with survivors.

My head, on the other hand, is full of the understanding that the internet should remain free. The free flow of information should not be stopped. My mind is with the innocent citizens around the globe that deserve freedom both online and offline.

The problem is that governments don’t only want to censor illegal content that violates human rights—they create legislation that is so broad that it can impact speech and privacy of all. “Don’t you care about the kids?” Yes, I do. I do so much that I’m invested in finding solutions. I also care about all citizens around the globe that deserve an opportunity to live free from a mass surveillance society. If terrorism happens online, I should not be punished by losing my freedom. If drugs are sold online, I should not be punished. I’m not an abuser, I’m not a terrorist, and I don’t engage in illegal behaviors. I refuse to lose freedom because of others’ bad behaviors online.

I want to be clear that on a long enough timeline, the governments will decide that they can be better parents/caregivers than you can if something isn’t done to stop minors from being sexually exploited online. The price will be a complete loss of anonymity, privacy, free speech, and freedom of religion online. I find it rather insulting that governments think they’re better equipped to raise children than parents and caretakers.

So we can’t go backwards—all that we can do is go forward. Those who want to have freedom will find technology to facilitate their liberation. This will lead many over time to decentralized and open protocols. So as far as I’m concerned, this does solve a few of my worries—those who need, want, and deserve to speak freely online will have the opportunity in most countries—but what about online child sexual exploitation?

When I popped up around the decentralized space, I was met with the fear of censorship. I’m not here to censor you. I don’t write code. I couldn’t censor anyone or any piece of content even if I wanted to across the internet, no matter how depraved. I don’t have the skills to do that.

I’m here to start a conversation. Freedom comes at a cost. You must always fight for and protect your freedom. I can’t speak about protecting yourself from all of the Four Horsemen because I simply don’t know the topics well enough, but I can speak about this one topic.

If there was a shortcut to ending online child sexual exploitation, I would have found it by now. There isn’t one right now. I believe that education is the only pathway forward to preventing the crime of online child sexual exploitation for future generations.

I propose a yearly education course for every child of all school ages, taught as a standard part of the curriculum. Ideally, parents/caregivers would be involved in the education/learning process.

Course: - The creation of the internet and computers - The fight for cryptography - The tech supply chain from the ground up (example: human rights violations in the supply chain) - Corporate tech - Freedom tech - Data privacy - Digital privacy rights - AI (history-current) - Online safety (predators, scams, catfishing, extortion) - Bitcoin - Laws - How to deal with online hate and harassment - Information on who to contact if you are being abused online or offline - Algorithms - How to seek out the truth about news, etc., online

The parents/caregivers, homeschoolers, unschoolers, and those working to create decentralized parallel societies have been an inspiration while writing this, but my hope is that all children would learn this course, even in government ran schools. Ideally, parents would teach this to their own children.

The decentralized space doesn’t want child sexual exploitation to thrive. Here’s the deal: there has to be a strong prevention effort in order to protect the next generation. The internet isn’t going anywhere, predators aren’t going anywhere, and I’m not down to let anyone have the opportunity to prove that there is a need for more government. I don’t believe that the government should act as parents. The governments have had a chance to attempt to stop online child sexual exploitation, and they didn’t do it. Can we try a different pathway forward?

I’d like to put myself out of a job. I don’t want to ever hear another story like John Doe #1 ever again. This will require work. I’ve often called online child sexual exploitation the lynchpin for the internet. It’s time to arm generations of children with knowledge and tools. I can’t do this alone.

Individuals have fought so that I could have freedom online. I want to fight to protect it. I don’t want child predators to give the government any opportunity to take away freedom. Decentralized spaces are as close to a reset as we’ll get with the opportunity to do it right from the start. Start the youth off correctly by preventing potential hazards to the best of your ability.

The good news is anyone can work on this! I’d encourage you to take it and run with it. I added the additional education about the history of the internet to make the course more educational and fun. Instead of cleaning up generations of destroyed lives due to online sexual exploitation, perhaps this could inspire generations of those who will build our futures. Perhaps if the youth is armed with knowledge, they can create more tools to prevent the crime.

This one solution that I’m suggesting can be done on an individual level or on a larger scale. It should be adjusted depending on age, learning style, etc. It should be fun and playful.

This solution does not address abuse in the home or some of the root causes of offline child sexual exploitation. My hope is that it could lead to some survivors experiencing abuse in the home an opportunity to disclose with a trusted adult. The purpose for this solution is to prevent the crime of online child sexual exploitation before it occurs and to arm the youth with the tools to contact safe adults if and when it happens.

In closing, I went to hell a few times so that you didn’t have to. I spoke to the mothers of survivors of minors sexually exploited online—their tears could fill rivers. I’ve spoken with political dissidents who yearned to be free from authoritarian surveillance states. The only balance that I’ve found is freedom online for citizens around the globe and prevention from the dangers of that for the youth. Don’t slow down innovation and freedom. Educate, prepare, adapt, and look for solutions.

I’m not perfect and I’m sure that there are errors in this piece. I hope that you find them and it starts a conversation.

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

Usually stolen bitcoin for the reserve creates a perverse incentive. If governments see a 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.

@ df478568:2a951e67

Welcome to Zap This Blog

Exploring Liberty With Fredom Tech

Zap This Blog! Shop Merch Nostree Cashu Cards

I can string some spaghetti HTMl code together here and there, but vibe coding gave me the confidence to look into the code injection section of the ghost Blog. As sudden as a new block, the Lex Friedman Robert Rodriguez interview, I had an epiphony when he asked Lex, "Do you consider yourself a creative person?" I aswered for myself, right away, emphatically yes. I just felt like I never knew what to do with this creative energy. Friedman hesitated and I was like..Wow...He has extreme creativity like Jocko Wilink has extreme disipline. If that guy has doubts, what the hell is stopping me from trying other stuff?

Rodriguez also claimed Four rooms was financial flop. I thought that movie was genius. I had no idea it failed financially. Nevertheless, it was not profitable. His advice was like Tony Robbins for film nerds. I learned about him in a film class I took in college. He was legendary for making a mobie for $7,000. My professor also said it was made for the Mexican VHS market, but I did not know he never sold it to that market. Robert Rodriguez tells the story 100X better, as you might expect a director of his caliber would. His advice hits like Tony Robbins, for film geeks. Here are a few gem quotes from the epiode.

"Sift through the ashes of your failures"

"Turn chicken shit into chicken salad."

"Follow your instinct. If it doesn't work, just go. Sometimes you need to slip on the first two rocks, so the key is in the ashes of failure because if I had an insticnt, that means I was on the right track. I didn't get the result I want. That's because the result might be something way bigger that I don't have the vision for and the universe is just pushing me that way."

"Turn chicken shit into chicken salad."

"If you have some kind of failure on something that you..., don't let it knock you down. Maybe in ten years they'll think it's great. I'm just going to commit to making a body of work, a body of work."

Rodriguez taught me what I already know. I am a creative person. I am just a body, punching keys on a keyboard, taking pictures, and semi-vibe-coding art. Maybe this is a shitty blog post today, but I write it anyway. Someone might look at it like I first looked at the math in the Bitcoin white paper and scan it with their eyeballs without really reading or understanding it. Most people on Substack probably don't want to read HTML, but maybe someone will come accross it one day and build something themselves they can find in the ashes of this code.

I once saw Brian Harrington say every bitcoiner is a business owner. If you have a bitcoin address, you can accept bitcoin. How does someone find you though? Are they really going to find your bitcoin address on GitHub? I'd bet 100 sats they won't. Nostr fixes this so I thought about integrating it into my Ghost Blog. I looked at the code injection section and let my muse do the typing. Actually, I let the Duck Duck AI chat do the vibe-coding. As it turns out, you an add a header and footer on Ghost in the code injection. It's just the same HTMl I used to make my MySpace page. Then I thought, what if someone couldn't afford a Start9 or didn't know how to vibe code on Duck Duck Go's free AI chat using Claude? What if, like Rodriguez suggests, I create a business card?

You could just copy my HTML and change my nostr links and pics to go to your nostr links and pics. You could publish that HTML into https://habla.news. Now you have an e-commerce site with a blog, a merch store, and your nostree. I don't know if this will work. This is the muse's hypothesis. I'm just writing the words down. You'll need to test this idea for yourself.

npub1marc26z8nh3xkj5rcx7ufkatvx6ueqhp5vfw9v5teq26z254renshtf3g0
marc26z@getalby.com
Zap This Blog!

@ 3b3a42d3:d192e325

Atomic Signature Swaps (ASS) over Nostr is a protocol for atomically exchanging Schnorr signatures using Nostr events for orchestration. This new primitive enables multiple interesting applications like:

• Getting paid to publish specific Nostr events
• Issuing automatic payment receipts
• Contract signing in exchange for payment
• P2P asset exchanges
• Trading and enforcement of asset option contracts
• Payment in exchange for Nostr-based credentials or access tokens
• Exchanging GMs 🌞

It only requires that (i) the involved signatures be Schnorr signatures using the secp256k1 curve and that (ii) at least one of those signatures be accessible to both parties. These requirements are naturally met by Nostr events (published to relays), Taproot transactions (published to the mempool and later to the blockchain), and Cashu payments (using mints that support NUT-07, allowing any pair of these signatures to be swapped atomically.

How the Cryptographic Magic Works 🪄

This is a Schnorr signature (Zₓ, s):

s = z + H(Zₓ || P || m)⋅k

If you haven't seen it before, don't worry, neither did I until three weeks ago.

The signature scalar s is the the value a signer with private key k (and public key P = k⋅G) must calculate to prove his commitment over the message m given a randomly generated nonce z (Zₓ is just the x-coordinate of the public point Z = z⋅G). H is a hash function (sha256 with the tag "BIP0340/challenge" when dealing with BIP340), || just means to concatenate and G is the generator point of the elliptic curve, used to derive public values from private ones.

Now that you understand what this equation means, let's just rename z = r + t. We can do that, z is just a randomly generated number that can be represented as the sum of two other numbers. It also follows that z⋅G = r⋅G + t⋅G ⇔ Z = R + T. Putting it all back into the definition of a Schnorr signature we get:

s = (r + t) + H((R + T)ₓ || P || m)⋅k

Which is the same as:

s = sₐ + t where sₐ = r + H((R + T)ₓ || P || m)⋅k

sₐ is what we call the adaptor signature scalar) and t is the secret. ((R + T)ₓ, sₐ) is an incomplete signature that just becomes valid by add the secret t to the sₐ:

s = sₐ + t

What is also important for our purposes is that by getting access to the valid signature s, one can also extract t from it by just subtracting sₐ:

t = s - sₐ

The specific value of t depends on our choice of the public point T, since R is just a public point derived from a randomly generated nonce r.

So how do we choose T so that it requires the secret t to be the signature over a specific message m' by an specific public key P'? (without knowing the value of t)

Let's start with the definition of t as a valid Schnorr signature by P' over m':

t = r' + H(R'ₓ || P' || m')⋅k' ⇔ t⋅G = r'⋅G + H(R'ₓ || P' || m')⋅k'⋅G

That is the same as:

T = R' + H(R'ₓ || P' || m')⋅P'

Notice that in order to calculate the appropriate T that requires t to be an specific signature scalar, we only need to know the public nonce R' used to generate that signature.

In summary: in order to atomically swap Schnorr signatures, one party P' must provide a public nonce R', while the other party P must provide an adaptor signature using that nonce:

sₐ = r + H((R + T)ₓ || P || m)⋅k where T = R' + H(R'ₓ || P' || m')⋅P'

P' (the nonce provider) can then add his own signature t to the adaptor signature sₐ in order to get a valid signature by P, i.e. s = sₐ + t. When he publishes this signature (as a Nostr event, Cashu transaction or Taproot transaction), it becomes accessible to P that can now extract the signature t by P' and also make use of it.

Important considerations

A signature may not be useful at the end of the swap if it unlocks funds that have already been spent, or that are vulnerable to fee bidding wars.

When a swap involves a Taproot UTXO, it must always use a 2-of-2 multisig timelock to avoid those issues.

Cashu tokens do not require this measure when its signature is revealed first, because the mint won't reveal the other signature if they can't be successfully claimed, but they also require a 2-of-2 multisig timelock when its signature is only revealed last (what is unavoidable in cashu for cashu swaps).

For Nostr events, whoever receives the signature first needs to publish it to at least one relay that is accessible by the other party. This is a reasonable expectation in most cases, but may be an issue if the event kind involved is meant to be used privately.

How to Orchestrate the Swap over Nostr?

Before going into the specific event kinds, it is important to recognize what are the requirements they must meet and what are the concerns they must address. There are mainly three requirements:

• Both parties must agree on the messages they are going to sign
• One party must provide a public nonce
• The other party must provide an adaptor signature using that nonce

There is also a fundamental asymmetry in the roles of both parties, resulting in the following significant downsides for the party that generates the adaptor signature:

• NIP-07 and remote signers do not currently support the generation of adaptor signatures, so he must either insert his nsec in the client or use a fork of another signer
• There is an overhead of retrieving the completed signature containing the secret, either from the blockchain, mint endpoint or finding the appropriate relay
• There is risk he may not get his side of the deal if the other party only uses his signature privately, as I have already mentioned
• There is risk of losing funds by not extracting or using the signature before its timelock expires. The other party has no risk since his own signature won't be exposed by just not using the signature he received.

The protocol must meet all those requirements, allowing for some kind of role negotiation and while trying to reduce the necessary hops needed to complete the swap.

Swap Proposal Event (kind:455)

This event enables a proposer and his counterparty to agree on the specific messages whose signatures they intend to exchange. The content field is the following stringified JSON:

{     "give": <signature spec (required)>,     "take": <signature spec (required)>,     "exp": <expiration timestamp (optional)>,     "role": "<adaptor | nonce (optional)>",     "description": "<Info about the proposal (optional)>",     "nonce": "<Signature public nonce (optional)>",     "enc_s": "<Encrypted signature scalar (optional)>" }

The field role indicates what the proposer will provide during the swap, either the nonce or the adaptor. When this optional field is not provided, the counterparty may decide whether he will send a nonce back in a Swap Nonce event or a Swap Adaptor event using the nonce (optionally) provided by in the Swap Proposal in order to avoid one hop of interaction.

The enc_s field may be used to store the encrypted scalar of the signature associated with the nonce, since this information is necessary later when completing the adaptor signature received from the other party.

A signature spec specifies the type and all necessary information for producing and verifying a given signature. In the case of signatures for Nostr events, it contain a template with all the fields, except pubkey, id and sig:

{ "type": "nostr", "template": { "kind": "<kind>"        "content": "<content>"        "tags": [ … ],        "created_at": "<created_at>" } }

In the case of Cashu payments, a simplified signature spec just needs to specify the payment amount and an array of mints trusted by the proposer:

{   "type": "cashu",   "amount": "<amount>",   "mint": ["<acceptable mint_url>", …] }

This works when the payer provides the adaptor signature, but it still needs to be extended to also work when the payer is the one receiving the adaptor signature. In the later case, the signature spec must also include a timelock and the derived public keys Y of each Cashu Proof, but for now let's just ignore this situation. It should be mentioned that the mint must be trusted by both parties and also support Token state check (NUT-07) for revealing the completed adaptor signature and P2PK spending conditions (NUT-11) for the cryptographic scheme to work.

The tags are:

• "p", the proposal counterparty's public key (required)
• "a", a kind:30455 Swap Listing event or an application specific version of it (optional)

Forget about this Swap Listing event for now, I will get to it later...

Swap Nonce Event (kind:456) - Optional

This is an optional event for the Swap Proposal receiver to provide the public nonce of his signature when the proposal does not include a nonce or when he does not want to provide the adaptor signature due to the downsides previously mentioned. The content field is the following stringified JSON:

{     "nonce": "<Signature public nonce>",     "enc_s": "<Encrypted signature scalar (optional)>" }

And the tags must contain:

• "e", a kind:455 Swap Proposal Event (required)
• "p", the counterparty's public key (required)

Swap Adaptor Event (kind:457)

The content field is the following stringified JSON:

{ "adaptors": [ {         "sa": "<Adaptor signature scalar>",         "R": "<Signer's public nonce (including parity byte)>",         "T": "<Adaptor point (including parity byte)>",         "Y": "<Cashu proof derived public key (if applicable)>",     }, …],     "cashu": "<Cashu V4 token (if applicable)>" }

And the tags must contain:

• "e", a kind:455 Swap Proposal Event (required)
• "p", the counterparty's public key (required)

Discoverability

The Swap Listing event previously mentioned as an optional tag in the Swap Proposal may be used to find an appropriate counterparty for a swap. It allows a user to announce what he wants to accomplish, what his requirements are and what is still open for negotiation.

Swap Listing Event (kind:30455)

The content field is the following stringified JSON:

{ "description": "<Information about the listing (required)>", "give": <partial signature spec (optional)>, "take": <partial signature spec (optional)>, "examples: [<take signature spec>], // optional "exp": <expiration timestamp (optional)>, "role": "<adaptor | nonce (optional)>" }

The description field describes the restrictions on counterparties and signatures the user is willing to accept.

A partial signature spec is an incomplete signature spec used in Swap Proposal events kind:455 where omitting fields signals that they are still open for negotiation.

The examples field is an array of signature specs the user would be willing to take.

The tags are:

• "d", a unique listing id (required)
• "s", the status of the listing draft | open | closed (required)
• "t", topics related to this listing (optional)
• "p", public keys to notify about the proposal (optional)

Application Specific Swap Listings

Since Swap Listings are still fairly generic, it is expected that specific use cases define new event kinds based on the generic listing. Those application specific swap listing would be easier to filter by clients and may impose restrictions and add new fields and/or tags. The following are some examples under development:

Sponsored Events

This listing is designed for users looking to promote content on the Nostr network, as well as for those who want to monetize their accounts by sharing curated sponsored content with their existing audiences.

It follows the same format as the generic Swap Listing event, but uses the kind:30456 instead.

The following new tags are included:

• "k", event kind being sponsored (required)
• "title", campaign title (optional)

It is required that at least one signature spec (give and/or take) must have "type": "nostr" and also contain the following tag ["sponsor", "<pubkey>", "<attestation>"] with the sponsor's public key and his signature over the signature spec without the sponsor tag as his attestation. This last requirement enables clients to disclose and/or filter sponsored events.

Asset Swaps

This listing is designed for users looking for counterparties to swap different assets that can be transferred using Schnorr signatures, like any unit of Cashu tokens, Bitcoin or other asset IOUs issued using Taproot.

It follows the same format as the generic Swap Listing event, but uses the kind:30457 instead.

It requires the following additional tags:

• "t", asset pair to be swapped (e.g. "btcusd")
• "t", asset being offered (e.g. "btc")
• "t", accepted payment method (e.g. "cashu", "taproot")

Swap Negotiation

From finding an appropriate Swap Listing to publishing a Swap Proposal, there may be some kind of negotiation between the involved parties, e.g. agreeing on the amount to be paid by one of the parties or the exact content of a Nostr event signed by the other party. There are many ways to accomplish that and clients may implement it as they see fit for their specific goals. Some suggestions are:

• Adding kind:1111 Comments to the Swap Listing or an existing Swap Proposal
• Exchanging tentative Swap Proposals back and forth until an agreement is reached
• Simple exchanges of DMs
• Out of band communication (e.g. Signal)

Work to be done

I've been refining this specification as I develop some proof-of-concept clients to experience its flaws and trade-offs in practice. I left the signature spec for Taproot signatures out of the current document as I still have to experiment with it. I will probably find some important orchestration issues related to dealing with 2-of-2 multisig timelocks, which also affects Cashu transactions when spent last, that may require further adjustments to what was presented here.

The main goal of this article is to find other people interested in this concept and willing to provide valuable feedback before a PR is opened in the NIPs repository for broader discussions.

References

• GM Swap- Nostr client for atomically exchanging GM notes. Live demo available here.
• Sig4Sats Script - A Typescript script demonstrating the swap of a Cashu payment for a signed Nostr event.
• Loudr- Nostr client under development for sponsoring the publication of Nostr events. Live demo available at loudr.me.
• Poelstra, A. (2017). Scriptless Scripts. Blockstream Research. https://github.com/BlockstreamResearch/scriptless-scripts

@ d34e832d:383f78d0

Raspberry Pi-based voice assistant

This Idea details the design and deployment of a Raspberry Pi-based voice assistant powered by the Google Gemini AI API. The system combines open hardware with modern AI services to create a low-cost, flexible, and educational voice assistant platform. By leveraging a Raspberry Pi, basic audio hardware, and Python-based software, developers can create a functional, customizable assistant suitable for home automation, research, or personal productivity enhancement.

---

1. Voice assistants

Voice assistants have become increasingly ubiquitous, but commercially available systems like Alexa, Siri, or Google Assistant come with significant privacy and customization limitations.
This project offers an open, local, and customizable alternative, demonstrating how to build a voice assistant using Google Gemini (or OpenAI’s ChatGPT) APIs for natural language understanding.

Target Audience:
- DIY enthusiasts - Raspberry Pi hobbyists - AI developers - Privacy-conscious users

---

2. System Architecture

2.1 Hardware Components

| Component | Purpose | |:--------------------------|:----------------------------------------| | Raspberry Pi (any recent model, 4B recommended) | Core processing unit | | Micro SD Card (32GB+) | Operating System and storage | | USB Microphone | Capturing user voice input | | Audio Amplifier + Speaker | Outputting synthesized responses | | 5V DC Power Supplies (2x) | Separate power for Pi and amplifier | | LEDs + Resistors (optional)| Visual feedback (e.g., recording or listening states) |

2.2 Software Stack

| Software | Function | |:---------------------------|:----------------------------------------| | Raspberry Pi OS (Lite or Full) | Base operating system | | Python 3.9+ | Programming language | | SpeechRecognition | Captures and transcribes user voice | | Google Text-to-Speech (gTTS) | Converts responses into spoken audio | | Google Gemini API (or OpenAI API) | Powers the AI assistant brain | | Pygame | Audio playback for responses | | WinSCP + Windows Terminal | File transfer and remote management |

---

3. Hardware Setup

3.1 Basic Connections

• Microphone: Connect via USB port.
• Speaker and Amplifier: Wire from Raspberry Pi audio jack or via USB sound card if better quality is needed.
• LEDs (Optional): Connect through GPIO pins, using 220–330Ω resistors to limit current.

3.2 Breadboard Layout (Optional for LEDs)

| GPIO Pin | LED Color | Purpose | |:---------|:-----------|:--------------------| | GPIO 17 | Red | Recording active | | GPIO 27 | Green | Response playing |

Tip: Use a small breadboard for quick prototyping before moving to a custom PCB if desired.

---

4. Software Setup

4.1 Raspberry Pi OS Installation

• Use Raspberry Pi Imager to flash Raspberry Pi OS onto the Micro SD card.
• Initial system update: bash sudo apt update && sudo apt upgrade -y

4.2 Python Environment

• Install Python virtual environment: bash sudo apt install python3-venv python3 -m venv voice-env source voice-env/bin/activate

• Install required Python packages: bash pip install SpeechRecognition google-generativeai pygame gtts

(Replace google-generativeai with openai if using OpenAI's ChatGPT.)

4.3 API Key Setup

• Obtain a Google Gemini API key (or OpenAI API key).
• Store safely in a .env file or configure as environment variables for security: bash export GEMINI_API_KEY="your_api_key_here"

4.4 File Transfer

• Use WinSCP or scp commands to transfer Python scripts to the Pi.

4.5 Example Python Script (Simplified)

```python import speech_recognition as sr import google.generativeai as genai from gtts import gTTS import pygame import os

genai.configure(api_key=os.getenv('GEMINI_API_KEY')) recognizer = sr.Recognizer() mic = sr.Microphone()

pygame.init()

while True: with mic as source: print("Listening...") audio = recognizer.listen(source)

try:
    text = recognizer.recognize_google(audio)
    print(f"You said: {text}")

    response = genai.generate_content(text)
    tts = gTTS(text=response.text, lang='en')
    tts.save("response.mp3")

    pygame.mixer.music.load("response.mp3")
    pygame.mixer.music.play()
    while pygame.mixer.music.get_busy():
        continue

except Exception as e:
    print(f"Error: {e}")

```

---

5. Testing and Execution

• Activate the Python virtual environment: bash source voice-env/bin/activate
• Run your main assistant script: bash python3 assistant.py
• Speak into the microphone and listen for the AI-generated spoken response.

---

6. Troubleshooting

| Problem | Possible Fix | |:--------|:-------------| | Microphone not detected | Check arecord -l | | Audio output issues | Check aplay -l, use a USB DAC if needed | | Permission denied errors | Verify group permissions (audio, gpio) | | API Key Errors | Check environment variable and internet access |

---

7. Performance Notes

• Latency: Highly dependent on network speed and API response time.
• Audio Quality: Can be enhanced with a better USB microphone and powered speakers.
• Privacy: Minimal data retention if using your own Gemini or OpenAI account.

---

8. Potential Extensions

• Add hotword detection ("Hey Gemini") using Snowboy or Porcupine libraries.
• Build a local fallback model to answer basic questions offline.
• Integrate with home automation via MQTT, Home Assistant, or Node-RED.
• Enable LED animations to visually indicate listening and responding states.
• Deploy with a small eInk or OLED screen for text display of answers.

---

9. Consider

Building a Gemini-powered voice assistant on the Raspberry Pi empowers individuals to create customizable, private, and cost-effective alternatives to commercial voice assistants. By utilizing accessible hardware, modern open-source libraries, and powerful AI APIs, this project blends education, experimentation, and privacy-centric design into a single hands-on platform.

This guide can be adapted for personal use, educational programs, or even as a starting point for more advanced AI-based embedded systems.

---

References

• Raspberry Pi Foundation: https://www.raspberrypi.org
• Google Generative AI Documentation: https://ai.google.dev
• OpenAI Documentation: https://platform.openai.com
• SpeechRecognition Library: https://pypi.org/project/SpeechRecognition/
• gTTS Documentation: https://pypi.org/project/gTTS/
• Pygame Documentation: https://www.pygame.org/docs/

@ 04c915da:3dfbecc9

There is something quietly rebellious about stacking sats. In a world obsessed with instant gratification, choosing to patiently accumulate Bitcoin, one sat at a time, feels like a middle finger to the hype machine. But to do it right, you have got to stay humble. Stack too hard with your head in the clouds, and you will trip over your own ego before the next halving even hits.

Small Wins

Stacking sats is not glamorous. Discipline. Stacking every day, week, or month, no matter the price, and letting time do the heavy lifting. Humility lives in that consistency. You are not trying to outsmart the market or prove you are the next "crypto" prophet. Just a regular person, betting on a system you believe in, one humble stack at a time. Folks get rekt chasing the highs. They ape into some shitcoin pump, shout about it online, then go silent when they inevitably get rekt. The ones who last? They stack. Just keep showing up. Consistency. Humility in action. Know the game is long, and you are not bigger than it.

Ego is Volatile

Bitcoin’s swings can mess with your head. One day you are up 20%, feeling like a genius and the next down 30%, questioning everything. Ego will have you panic selling at the bottom or over leveraging the top. Staying humble means patience, a true bitcoin zen. Do not try to "beat” Bitcoin. Ride it. Stack what you can afford, live your life, and let compounding work its magic.

Simplicity

There is a beauty in how stacking sats forces you to rethink value. A sat is worth less than a penny today, but every time you grab a few thousand, you plant a seed. It is not about flaunting wealth but rather building it, quietly, without fanfare. That mindset spills over. Cut out the noise: the overpriced coffee, fancy watches, the status games that drain your wallet. Humility is good for your soul and your stack. I have a buddy who has been stacking since 2015. Never talks about it unless you ask. Lives in a decent place, drives an old truck, and just keeps stacking. He is not chasing clout, he is chasing freedom. That is the vibe: less ego, more sats, all grounded in life.

The Big Picture

Stack those sats. Do it quietly, do it consistently, and do not let the green days puff you up or the red days break you down. Humility is the secret sauce, it keeps you grounded while the world spins wild. In a decade, when you look back and smile, it will not be because you shouted the loudest. It will be because you stayed the course, one sat at a time. \ \ Stay Humble and Stack Sats. 🫡

@ bc575705:dba3ed39

In our hyper-connected age, the concept of "Know Your Customer" (KYC) has morphed from a regulatory necessity into a pervasive surveillance apparatus, subtly eroding our fundamental liberties. While purported to combat financial crime, KYC has become a tool for mass surveillance, data exploitation, and the gradual dismantling of personal privacy. Let’s embark on a comprehensive exploration of this system, exposing its inherent flaws and advocating for a paradigm shift towards decentralized financial sovereignty.

Beyond the Surface: The Intricate Web of KYC Data Collection

KYC transcends mere identity verification; it's a deep dive into the minutiae of our lives. Consider the breadth and depth of data extracted:

Geographic Surveillance: Proof of address requirements delve into historical residency, creating granular maps of our movements. Combined with location data from mobile devices and online activity, this paints a comprehensive picture of our physical presence.

Financial Autopsy: KYC dissects our financial lives with surgical precision. Income sources, asset declarations, and transaction histories are meticulously cataloged. Algorithmic analysis reveals spending habits, investment strategies, and even potential political affiliations.

Behavioral Predictive Modeling: AI algorithms analyze our financial behavior, predicting future actions and preferences. This data is invaluable for targeted advertising, but also for social engineering and political manipulation.

Biometric Invasiveness: Facial recognition, iris scans, and voice analysis create permanent, immutable records of our physical selves. These biometrics are highly sensitive and vulnerable to breaches, potentially leading to identity theft and even physical harm.

Social Network Mapping: KYC extends beyond individuals, mapping our social and professional networks. Institutions analyze our connections, identifying potential risks based on our associations. This has a chilling effect on free association and dissent, as individuals become hesitant to associate with those deemed "risky."

Psychometric Profiling: With the increase of online tests, and the collection of online data, companies and states can build psychometric profiles. These profiles can be used to predict actions, and even manipulate populations.

The Fallacy of Security: KYC's Ineffectiveness and the Rise of the Surveillance State

Despite its claims, KYC fails to effectively combat sophisticated financial crime. Instead, it creates a system of mass surveillance that disproportionately targets law-abiding citizens.

The Scourge of False Positives: Automated KYC systems frequently generate false positives, flagging innocent individuals as potential criminals. This can lead to financial exclusion, reputational damage, and even legal persecution.

A Ticking Time Bomb: Centralized KYC databases are prime targets for hackers, putting vast amounts of sensitive personal information at risk. Data breaches can lead to identity theft, financial fraud, and even physical harm.

The State's Panopticon: KYC empowers governments to monitor the financial activities of their citizens, creating a powerful tool for surveillance and control. This can be used to suppress dissent, target political opponents, and enforce conformity.

The Criminals Advantage: Sophisticated criminals easily bypass KYC using shell companies, money laundering, and other techniques. This makes KYC a system that punishes the innocent, and gives the criminals a false sense of security for the data collected.

Decentralized Alternatives: Reclaiming Financial Sovereignty and Privacy

In the face of this encroaching surveillance state, decentralized technologies offer a path to financial freedom and privacy.

Cryptocurrency | A Bastion of Financial Freedom: Bitcoin and other cryptocurrencies provide censorship-resistant alternatives to traditional financial systems. They empower individuals to transact freely, without the need for intermediaries or government oversight.

Decentralized Finance (DeFi) | Democratizing Finance: DeFi platforms offer a range of financial services, including lending, borrowing, and trading, without the need for traditional banks. These platforms are built on blockchain technology, ensuring transparency, security, and accessibility.

Self-Sovereign Identity (SSI) | Empowering Individuals: SSI solutions enable individuals to control their own digital identities, without relying on centralized authorities. This allows for secure and private verification of identity, without the need to share sensitive personal information with every service provider.

Privacy-Enhancing Technologies (PETs) | Shielding Your Data: Technologies like zero-knowledge proofs, homomorphic encryption, and secure multi-party computation can be used to protect personal data while still allowing for necessary verification.

Decentralized Autonomous Organizations (DAOs) | Creating new forms of governance: DAOs provide new ways for groups to organize, and make decisions. They provide a transparent way to pool resources, and make decisions.

A Call to Action: Defending Our Digital Rights and Building a Decentralized Future

We cannot passively accept the erosion of our fundamental freedoms. We must actively defend our digital rights and demand a more just and equitable financial system.

Advocate for Robust Privacy Laws: Demand stronger regulations that limit the collection and use of personal data.

Champion Decentralized Technologies: Support the development and adoption of cryptocurrencies, DeFi platforms, and other decentralized solutions.

Educate and Empower: Raise awareness about the dangers of KYC and state surveillance.

Cultivate Critical Thinking: Question the narratives presented by governments and corporations.

Build Decentralized Communities: Join and support decentralized communities that are working to build a more free and open financial system.

Demand transparency from all data collection: Insist that all data collection is open, and that there are strong penalties for those that misuse data.

The fight for financial freedom is a fight for human freedom. Let us stand together and reclaim our digital sovereignty.

@ d34e832d:383f78d0

Micro with its operands and keybindings.

---

Micro is a modern, user-friendly text editor designed for the terminal. It offers extensive features, including mouse support, multiple cursors, syntax highlighting, and an intuitive command bar.

---

1. Command Bar

• Open it with Ctrl-e
• Supports shell-like argument parsing (single/double quotes, escaping)
• No environment variable expansion

---

2. Commands Overview

Commands are entered using Ctrl-e followed by the command.

File Management

• save ['filename'] → Save the current buffer (or "Save As" if a filename is given)
• quit → Exit Micro
• open 'filename' → Open a file
• reopen → Reload the current file from disk
• pwd → Print the current working directory
• cd 'path' → Change the working directory

Navigation

• goto 'line[:col]' → Move to an absolute line and column
• jump 'line[:col]' → Move relative to the current line

Editing

• replace 'search' 'value' ['flags'] → Replace text
• -a → Replace all occurrences
• -l → Literal search (no regex)
• replaceall 'search' 'value' → Replace all without confirmation
• textfilter 'sh-command' → Pipe selected text through a shell command and replace it

Splitting and Tabs

• vsplit ['filename'] → Open a vertical split
• hsplit ['filename'] → Open a horizontal split
• tab ['filename'] → Open a file in a new tab
• tabswitch 'tab' → Switch between tabs
• tabmove '[-+]n' → Move tab position

Configuration

• set 'option' 'value' → Set a global option
• setlocal 'option' 'value' → Set an option for the current buffer
• show 'option' → Show the current value of an option
• reset 'option' → Reset an option to its default

Plugins

• plugin list → List installed plugins
• plugin install 'pl' → Install a plugin
• plugin remove 'pl' → Remove a plugin
• plugin update ['pl'] → Update a plugin
• plugin search 'pl' → Search for plugins

Miscellaneous

• run 'sh-command' → Run a shell command in the background
• log → View debug messages
• reload → Reload all runtime files (settings, keybindings, syntax files, etc.)
• raw → Debug terminal escape sequences
• showkey 'key' → Show what action is bound to a key
• term ['exec'] → Open a terminal emulator running a specific command
• lint → Lint the current file
• comment → Toggle comments on a selected line or block

---

3. Keybindings Overview

| Action | Keybinding | |------------------|--------------| | Navigation | | | Move cursor left | ← or h | | Move cursor right | → or l | | Move cursor up | ↑ or k | | Move cursor down | ↓ or j | | Move to start of line | Home | | Move to end of line | End | | Move to start of file | Ctrl-Home | | Move to end of file | Ctrl-End | | Move by word left | Ctrl-← or Ctrl-b | | Move by word right | Ctrl-→ or Ctrl-f | | Editing | | | Copy | Ctrl-c | | Cut | Ctrl-x | | Paste | Ctrl-v | | Undo | Ctrl-z | | Redo | Ctrl-Shift-z | | Delete word left | Ctrl-Backspace | | Delete word right | Ctrl-Delete | | Splitting & Tabs | | | Open horizontal split | Ctrl-w h | | Open vertical split | Ctrl-w v | | Switch tab left | Alt-← | | Switch tab right | Alt-→ |

For more, check the official keybindings:
🔗 Micro Keybindings 🔗Available Here

---

Final Thoughts

Micro is a powerful text editor for terminal users who want an alternative to Vim or Nano. With an intuitive command bar, extensive customization options, and full plugin support, it offers a lightweight yet feature-rich editing experience. 🚀

@ dd664d5e:5633d319

Men tend to find women attractive, that remind them of the average women they already know, but with more-averaged features. The mid of mids is kween.👸

But, in contradiction to that, they won't consider her highly attractive, unless she has some spectacular, unusual feature. They'll sacrifice some averageness to acquire that novelty. This is why wealthy men (who tend to be highly intelligent -- and therefore particularly inclined to crave novelty because they are easily bored) -- are more likely to have striking-looking wives and girlfriends, rather than conventionally-attractive ones. They are also more-likely to cross ethnic and racial lines, when dating.

Men also seem to each be particularly attracted to specific facial expressions or mimics, which might be an intelligence-similarity test, as persons with higher intelligence tend to have a more-expressive mimic. So, people with similar expressions tend to be on the same wavelength. Facial expessions also give men some sense of perception into womens' inner life, which they otherwise find inscrutable.

Hair color is a big deal (logic says: always go blonde), as is breast-size (bigger is better), and WHR (smaller is better).

@ 21335073:a244b1ad

Before I saw those X right-wing political “influencers” parading their Epstein binders in that PR stunt, I’d already posted this on Nostr, an open protocol. 

“Today, the world’s attention will likely fixate on Epstein, governmental failures in addressing horrific abuse cases, and the influential figures who perpetrate such acts—yet few will center the victims and survivors in the conversation. The survivors of Epstein went to law enforcement and very little happened. The survivors tried to speak to the corporate press and the corporate press knowingly covered for him. In situations like these social media can serve as one of the only ways for a survivor’s voice to be heard. 

It’s becoming increasingly evident that the line between centralized corporate social media and the state is razor-thin, if it exists at all. Time and again, the state shields powerful abusers when it’s politically expedient to do so. In this climate, a survivor attempting to expose someone like Epstein on a corporate tech platform faces an uphill battle—there’s no assurance their voice would even break through. Their story wouldn’t truly belong to them; it’d be at the mercy of the platform, subject to deletion at a whim. Nostr, though, offers a lifeline—a censorship-resistant space where survivors can share their truths, no matter how untouchable the abuser might seem. A survivor could remain anonymous here if they took enough steps. 

Nostr holds real promise for amplifying survivor voices. And if you’re here daily, tossing out memes, take heart: you’re helping build a foundation for those who desperately need to be heard.“

That post is untouchable—no CEO, company, employee, or government can delete it. Even if I wanted to, I couldn’t take it down myself. The post will outlive me on the protocol. 

The cozy alliance between the state and corporate social media hit me hard during that right-wing X “influencer” PR stunt. Elon owns X. Elon’s a special government employee. X pays those influencers to post. We don’t know who else pays them to post. Those influencers are spurred on by both the government and X to manage the Epstein case narrative. It wasn’t survivors standing there, grinning for photos—it was paid influencers, gatekeepers orchestrating yet another chance to re-exploit the already exploited.

The bond between the state and corporate social media is tight. If the other Epsteins out there are ever to be unmasked, I wouldn’t bet on a survivor’s story staying safe with a corporate tech platform, the government, any social media influencer, or mainstream journalist. Right now, only a protocol can hand survivors the power to truly own their narrative.

I don’t have anything against Elon—I’ve actually been a big supporter. I’m just stating it as I see it. X isn’t censorship resistant and they have an algorithm that they choose not the user. Corporate tech platforms like X can be a better fit for some survivors. X has safety tools and content moderation, making it a solid option for certain individuals. Grok can be a big help for survivors looking for resources or support! As a survivor, you know what works best for you, and safety should always come first—keep that front and center.

That said, a protocol is a game-changer for cases where the powerful are likely to censor. During China's # MeToo movement, survivors faced heavy censorship on social media platforms like Weibo and WeChat, where posts about sexual harassment were quickly removed, and hashtags like # MeToo or "woyeshi" were blocked by government and platform filters. To bypass this, activists turned to blockchain technology encoding their stories—like Yue Xin’s open letter about a Peking University case—into transaction metadata. This made the information tamper-proof and publicly accessible, resisting censorship since blockchain data can’t be easily altered or deleted.

I posted this on X 2/28/25. I wanted to try my first long post on a nostr client. The Epstein cover up is ongoing so it’s still relevant, unfortunately.

If you are a survivor or loved one who is reading this and needs support please reach out to: National Sexual Assault Hotline 24/7 https://rainn.org/

Hours: Available 24 hours

@ d34e832d:383f78d0

Gist

This Idea presents a blueprint for creating a portable, offline-first education server focused on Free and Open Source Software (FOSS) topics like Bitcoin fundamentals, Linux administration, GPG encryption, and digital self-sovereignty. Using the compact and powerful Nookbox G9 NAS unit, we demonstrate how to deliver accessible, decentralized educational content in remote or network-restricted environments.

---

1. Bitcoin, Linux, and Cryptographic tools

Access to self-sovereign technologies such as Bitcoin, Linux, and cryptographic tools is critical for empowering individuals and communities. However, many areas face internet connectivity issues or political restrictions limiting access to online resources.

By combining a high-performance mini NAS server with a curated library of FOSS educational materials, we can create a mobile "university" that delivers critical knowledge independently of centralized networks.

---

2. Hardware Platform: Nookbox G9 Overview

The Nookbox G9 offers an ideal balance of performance, portability, and affordability for this project.

2.1 Core Specifications

| Feature | Specification | |:------------------------|:---------------------------------------| | Form Factor | 1U Rackmount mini-NAS | | Storage | Up to 8TB (4×2TB M.2 NVMe SSDs) | | M.2 Interface | PCIe Gen 3x2 per drive slot | | Networking | Dual 2.5 Gigabit Ethernet ports | | Power Consumption | 11–30 Watts (typical usage) | | Default OS | Windows 11 (to be replaced with Linux) | | Linux Compatibility | Fully compatible with Ubuntu 24.10 |

---

3. FOSS Education Server Design

3.1 Operating System Setup

• Replace Windows 11 with a clean install of Ubuntu Server 24.10.
• Harden the OS:
• Enable full-disk encryption.
• Configure UFW firewall.
• Disable unnecessary services.

3.2 Core Services Deployed

| Service | Purpose | |:--------------------|:-----------------------------------------| | Nginx Web Server | Host offline courses and documentation | | Nextcloud (optional) | Offer private file sharing for students | | Moodle LMS (optional) | Deliver structured courses and quizzes | | Tor Hidden Service | Optional for anonymous access locally | | rsync/Syncthing | Distribute updates peer-to-peer |

---

3.3 Content Hosted

• Bitcoin: Bitcoin Whitepaper, Bitcoin Core documentation, Electrum Wallet tutorials.
• Linux: Introduction to Linux (LPIC-1 materials), bash scripting guides, system administration manuals.
• Cryptography: GPG tutorials, SSL/TLS basics, secure communications handbooks.
• Offline Tools: Full mirrors of sites like LearnLinux.tv, Bitcoin.org, and selected content from FSF.

All resources are curated to be license-compliant and redistributable in an offline format.

---

4. Network Configuration

• LAN-only Access: No reliance on external Internet.
• DHCP server setup for automatic IP allocation.
• Optional Wi-Fi access point using USB Wi-Fi dongle and hostapd.
• Access Portal: Homepage automatically redirects users to educational content upon connection.

---

5. Advantages of This Setup

| Feature | Advantage | |:-----------------------|:----------------------------------------| | Offline Capability | Operates without internet connectivity | | Portable Form Factor | Fits into field deployments easily | | Secure and Hardened | Encrypted, compartmentalized, and locked down | | Modular Content | Easy to update or expand educational resources | | Energy Efficient | Low power draw enables solar or battery operation | | Open Source Stack | End-to-end FOSS ecosystem, no vendor lock-in |

---

6. Deployment Scenarios

• Rural Schools: Provide Linux training without requiring internet.
• Disaster Recovery Zones: Deliver essential technical education in post-disaster areas.
• Bitcoin Meetups: Offer Bitcoin literacy and cryptography workshops in remote communities.
• Privacy Advocacy Groups: Teach operational security practices without risking network surveillance.

---

7. Performance Considerations

Despite PCIe Gen 3x2 limitations, the available bandwidth (~2GB/s theoretical) vastly exceeds the server's 2.5 Gbps network output (~250MB/s), making it more than sufficient for a read-heavy educational workload.

Thermal Management:
Given the G9’s known cooling issues, install additional thermal pads or heatsinks on the NVMe drives. Consider external USB-powered cooling fans for sustained heavy usage.

---

8. Ways To Extend

• Multi-language Support: Add localized course materials.
• Bitcoin Node Integration: Host a lightweight Bitcoin node (e.g., Bitcoin Core with pruning enabled or a complete full node) for educational purposes.
• Mesh Networking: Use Mesh Wi-Fi protocols (e.g., cjdns or Yggdrasil) to allow peer-to-peer server sharing without centralized Wi-Fi.

---

9. Consider

Building a Portable FOSS Education Server on a Nookbox G9 is a practical, scalable solution for democratizing technical knowledge, empowering communities, and defending digital sovereignty in restricted environments.

Through thoughtful system design—leveraging open-source software and secure deployment practices—we enable resilient, censorship-resistant education wherever it's needed.

---

📎 References

• Ubuntu Server
• Moodle LMS
• LearnLinux.tv
• Bitcoin.org
• Tor Project

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

@ d34e832d:383f78d0

Practical Privacy and Secure Communications

---

1. Bootable privacy operating systems—Tails, Qubes OS, and Whonix****

This Idea explores the technical deployment of bootable privacy operating systems—Tails, Qubes OS, and Whonix—for individuals and organizations seeking to enhance operational security (OpSec). These systems provide different layers of isolation, anonymity, and confidentiality, critical for cryptographic operations, Bitcoin custody, journalistic integrity, whistleblowing, and sensitive communications. The paper outlines optimal use cases, system requirements, technical architecture, and recommended operational workflows for each OS.

---

2. Running An Operating System

In a digital world where surveillance, metadata leakage, and sophisticated threat models are realities, bootable privacy OSs offer critical mitigation strategies. By running an operating system from a USB, DVD, or external drive—and often entirely in RAM—users can minimize the footprint left on host hardware, dramatically enhancing privacy.

This document details Tails, Qubes OS, and Whonix: three leading open-source projects addressing different aspects of operational security.

---

3. Technical Overview of Systems

| OS | Focus | Main Feature | Threat Model | |------------|---------------------------|-----------------------------------------------|--------------------------------| | Tails | Anonymity & Ephemerality | Runs entirely from RAM; routes traffic via Tor | For activists, journalists, Bitcoin users | | Qubes OS | Security through Compartmentalization | Hardware-level isolation via Xen hypervisor | Defense against malware, APTs, insider threats | | Whonix | Anonymity over Tor Networks | Split-Gateway Architecture (Whonix-Gateway & Whonix-Workstation) | For researchers, Bitcoin node operators, privacy advocates |

---

4. System Requirements

4.1 Tails

• RAM: Minimum 2 GB (4 GB recommended)
• CPU: x86_64 (Intel or AMD)
• Storage: 8GB+ USB stick (optional persistent storage)

4.2 Qubes OS

• RAM: 16 GB minimum
• CPU: Intel VT-x or AMD-V support required
• Storage: 256 GB SSD recommended
• GPU: Minimal compatibility (no Nvidia proprietary driver support)

4.3 Whonix

• Platform: VirtualBox/KVM Host (Linux, Windows, Mac)
• RAM: 4 GB minimum (8 GB recommended)
• Storage: 100 GB suggested for optimal performance

---

5. Deployment Models

| Model | Description | Recommended OS | |--------------------------|-----------------------------------|------------------------------| | USB-Only Boot | No installation on disk; ephemeral use | Tails | | Hardened Laptop | Full disk installation with encryption | Qubes OS | | Virtualized Lab | VMs on hardened workstation | Whonix Workstation + Gateway |

---

6. Operational Security Advantages

| OS | Key Advantages | |------------|----------------------------------------------------------------------------------------------------| | Tails | Memory wipe at shutdown, built-in Tor Browser, persistent volume encryption (LUKS) | | Qubes OS | Compartmentalized VMs for work, browsing, Bitcoin keys; TemplateVMs reduce attack surface | | Whonix | IP address leaks prevented even if the workstation is compromised; full Tor network integration |

---

7. Threat Model Coverage

| Threat Category | Tails | Qubes OS | Whonix | |----------------------------|-----------------|------------------|------------------| | Disk Forensics | ✅ (RAM-only) | ✅ (with disk encryption) | ✅ (VM separation) | | Malware Containment | ❌ | ✅ (strong) | ✅ (via VMs) | | Network Surveillance | ✅ (Tor enforced) | Partial (needs VPN/Tor setup) | ✅ (Tor Gateway) | | Hardware-Level Attacks | ❌ | ❌ | ❌ |

---

8. Use Cases

• Bitcoin Cold Storage and Key Signing (Tails)
• Boot Tails offline for air-gapped Bitcoin signing.
• Private Software Development (Qubes)
• Use separate VMs for coding, browsing, and Git commits.
• Anonymous Research (Whonix)
• Surf hidden services (.onion) without IP leak risk.
• Secure Communications (All)
• Use encrypted messaging apps (Session, XMPP, Matrix) without metadata exposure.

---

9. Challenges and Mitigations

| Challenge | Mitigation | |---------------------|---------------------------------------------| | Hardware Incompatibility | Validate device compatibility pre-deployment (esp. for Qubes) | | Tor Exit Node Surveillance | Use onion services or bridge relays (Tails, Whonix) | | USB Persistence Risks | Always encrypt persistent volumes (Tails) | | Hypervisor Bugs (Qubes) | Regular OS and TemplateVM updates |

Here’s a fully original technical whitepaper version of your request, rewritten while keeping the important technical ideas intact but upgrading structure, language, and precision.

Executive Summary

In a world where digital surveillance and privacy threats are escalating, bootable privacy operating systems offer a critical solution for at-risk individuals. Systems like Tails, Qubes OS, and Whonix provide strong, portable security by isolating user activities from compromised or untrusted hardware. This paper explores their architectures, security models, and real-world applications.

---

1. To Recap

Bootable privacy-centric operating systems are designed to protect users from forensic analysis, digital tracking, and unauthorized access. By booting from an external USB drive or DVD and operating independently from the host machine's internal storage, they minimize digital footprints and maximize operational security (OpSec).

This paper provides an in-depth technical analysis of: - Tails (The Amnesic Incognito Live System) - Qubes OS (Security through Compartmentalization) - Whonix (Anonymity via Tor Isolation)

Each system’s strengths, limitations, use cases, and installation methods are explored in detail.

---

2. Technical Overview of Systems

2.1 Tails (The Amnesic Incognito Live System)

Architecture:
- Linux-based Debian derivative. - Boots from USB/DVD, uses RAM exclusively unless persistent storage is manually enabled. - Routes all network traffic through Tor. - Designed to leave no trace unless explicitly configured otherwise.

Key Features:
- Memory erasure on shutdown. - Pre-installed secure applications: Tor Browser, KeePassXC, OnionShare. - Persistent storage available but encrypted and isolated.

Limitations:
- Limited hardware compatibility (especially Wi-Fi drivers). - No support for mobile OS platforms. - ISP visibility to Tor network usage unless bridges are configured.

---

2.2 Qubes OS

Architecture:
- Xen-based hypervisor model. - Security through compartmentalization: distinct "qubes" (virtual machines) isolate tasks and domains (work, personal, banking, etc.). - Networking and USB stacks run in restricted VMs to prevent direct device access.

Key Features:
- Template-based management for efficient updates. - Secure Copy (Qubes RPC) for data movement without exposing full disks. - Integrated Whonix templates for anonymous browsing.

Limitations:
- Requires significant hardware resources (RAM and CPU). - Limited hardware compatibility (strict requirements for virtualization support: VT-d/IOMMU).

---

2.3 Whonix

Architecture:
- Debian-based dual VM system. - One VM (Gateway) routes all traffic through Tor; the second VM (Workstation) is fully isolated from the physical network. - Can be run on top of Qubes OS, VirtualBox, or KVM.

Key Features:
- Complete traffic isolation at the system level. - Strong protections against IP leaks (fails closed if Tor is inaccessible). - Advanced metadata obfuscation options.

Limitations:
- High learning curve for proper configuration. - Heavy reliance on Tor can introduce performance bottlenecks.

---

3. Comparative Analysis

| Feature | Tails | Qubes OS | Whonix | |:--------|:------|:---------|:-------| | Anonymity Focus | High | Medium | High | | System Isolation | Medium | Very High | High | | Persistence | Optional | Full | Optional | | Hardware Requirements | Low | High | Medium | | Learning Curve | Low | High | Medium | | Internet Privacy | Mandatory Tor | Optional Tor | Mandatory Tor |

---

4. Use Cases

| Scenario | Recommended System | |:---------|:--------------------| | Emergency secure browsing | Tails | | Full system compartmentalization | Qubes OS | | Anonymous operations with no leaks | Whonix | | Activist communications from hostile regions | Tails or Whonix | | Secure long-term project management | Qubes OS |

---

5. Installation Overview

5.1 Hardware Requirements

• Tails: Minimum 2GB RAM, USB 2.0 or higher, Intel or AMD x86-64 processor.
• Qubes OS: Minimum 16GB RAM, VT-d/IOMMU virtualization support, SSD storage.
• Whonix: Runs inside VirtualBox or Qubes; requires host compatibility.

5.2 Setup Instructions

Tails: 1. Download latest ISO from tails.net. 2. Verify signature (GPG or in-browser). 3. Use balenaEtcher or dd to flash onto USB. 4. Boot from USB, configure Persistent Storage if necessary.

Qubes OS: 1. Download ISO from qubes-os.org. 2. Verify using PGP signatures. 3. Flash to USB or DVD. 4. Boot and install onto SSD with LUKS encryption enabled.

Whonix: 1. Download both Gateway and Workstation VMs from whonix.org. 2. Import into VirtualBox or a compatible hypervisor. 3. Configure VMs to only communicate through the Gateway.

---

6. Security Considerations

• Tails: Physical compromise of the USB stick is a risk. Use hidden storage if necessary.
• Qubes OS: Qubes is only as secure as its weakest compartment; misconfigured VMs can leak data.
• Whonix: Full reliance on Tor can reveal usage patterns if used carelessly.

Best Practices: - Always verify downloads via GPG. - Use a dedicated, non-personal device where possible. - Utilize Tor bridges if operating under oppressive regimes. - Practice OPSEC consistently—compartmentalization, metadata removal, anonymous communications.

---

7. Consider

Bootable privacy operating systems represent a critical defense against modern surveillance and oppression. Whether for emergency browsing, long-term anonymous operations, or full-stack digital compartmentalization, solutions like Tails, Qubes OS, and Whonix empower users to reclaim their privacy.

When deployed thoughtfully—with an understanding of each system’s capabilities and risks—these tools can provide an exceptional layer of protection for journalists, activists, security professionals, and everyday users alike.

10. Example: Secure Bitcoin Signing Workflow with Tails

1. Boot Tails from USB.
2. Disconnect from the network.
3. Generate Bitcoin private key or sign transaction using Electrum.
4. Save signed transaction to encrypted USB drive.
5. Shut down to wipe RAM completely.
6. Broadcast transaction from a separate, non-sensitive machine.

This prevents key exposure to malware, man-in-the-middle attacks, and disk forensic analysis.

---

11. Consider

Bootable privacy operating systems like Tails, Qubes OS, and Whonix offer robust, practical strategies for improving operational security across a wide spectrum of use cases—from Bitcoin custody to anonymous journalism. Their open-source nature, focus on minimizing digital footprints, and mature security architectures make them foundational tools for modern privacy workflows.

Choosing the appropriate OS depends on the specific threat model, hardware available, and user needs. Proper training and discipline remain crucial to maintain the security these systems enable.

---

Appendices

A. Download Links

• Tails Official Site
• Qubes OS Official Site
• Whonix Official Site

B. Further Reading

• "The Qubes OS Architecture" Whitepaper
• "Operational Security and Bitcoin" by Matt Odell
• "Tor and the Darknet: Separating Myth from Reality" by EFF

@ 6389be64:ef439d32

GA, plebs. The latest episode of Bitcoin And is out, and, as always, the chicanery is running rampant. Let’s break down the biggest topics I covered, and if you want the full, unfiltered rant, make sure to listen to the episode linked below.

House Democrats’ MEME Act: A Bad Joke?

House Democrats are proposing a bill to ban presidential meme coins, clearly aimed at Trump’s and Melania’s ill-advised token launches. While grifters launching meme coins is bad, this bill is just as ridiculous. If this legislation moves forward, expect a retaliatory strike exposing how politicians like Pelosi and Warren mysteriously amassed their fortunes. Will it pass? Doubtful. But it’s another sign of the government’s obsession with regulating everything except itself.

Senate Banking’s First Digital Asset Hearing: The Real Target Is You

Cynthia Lummis chaired the first digital asset hearing, and—surprise!—it was all about control. The discussion centered on stablecoins, AML, and KYC regulations, with witnesses suggesting Orwellian measures like freezing stablecoin transactions unless pre-approved by authorities. What was barely mentioned? Bitcoin. They want full oversight of stablecoins, which is really about controlling financial freedom. Expect more nonsense targeting self-custody wallets under the guise of stopping “bad actors.”

Bank of America and PayPal Want In on Stablecoins

Bank of America’s CEO openly stated they’ll launch a stablecoin as soon as regulation allows. Meanwhile, PayPal’s CEO paid for a hat using Bitcoin—not their own stablecoin, Pi USD. Why wouldn’t he use his own product? Maybe he knows stablecoins aren’t what they’re hyped up to be. Either way, the legacy financial system is gearing up to flood the market with stablecoins, not because they love crypto, but because it’s a tool to extend U.S. dollar dominance.

MetaPlanet Buys the Dip

Japan’s MetaPlanet issued $13.4M in bonds to buy more Bitcoin, proving once again that institutions see the writing on the wall. Unlike U.S. regulators who obsess over stablecoins, some companies are actually stacking sats.

UK Expands Crypto Seizure Powers

Across the pond, the UK government is pushing legislation to make it easier to seize and destroy crypto linked to criminal activity. While they frame it as going after the bad guys, it’s another move toward centralized control and financial surveillance.

Bitcoin Tools & Tech: Arc, SatoChip, and Nunchuk

Some bullish Bitcoin developments: ARC v0.5 is making Bitcoin’s second layer more efficient, SatoChip now supports Taproot and Nostr, and Nunchuk launched a group wallet with chat, making multisig collaboration easier.

The Bottom Line

The state is coming for financial privacy and control, and stablecoins are their weapon of choice. Bitcoiners need to stay focused, keep their coins in self-custody, and build out parallel systems. Expect more regulatory attacks, but don’t let them distract you—just keep stacking and transacting in ways they can’t control.

🎧 Listen to the full episode here: https://fountain.fm/episode/PYITCo18AJnsEkKLz2Ks

💰 Support the show by boosting sats on Podcasting 2.0! and I will see you on the other side.

@ c1e9ab3a:9cb56b43

Introduction

Throughout human history, the pyramids of Egypt have fascinated scholars, archaeologists, and engineers alike. Traditionally thought of as tombs for pharaohs or religious monuments, alternative theories have speculated that the pyramids may have served advanced technological functions. One such hypothesis suggests that the pyramids acted as large-scale nitrogen fertilizer generators, designed to transform arid desert landscapes into fertile land.

This paper explores the feasibility of such a system by examining how a pyramid could integrate thermal convection, electrolysis, and a self-regulating breeder reactor to sustain nitrogen fixation processes. We will calculate the total power requirements and estimate the longevity of a breeder reactor housed within the structure.

The Pyramid’s Function as a Nitrogen Fertilizer Generator

The hypothesized system involves several key processes:

• Heat and Convection: A fissile material core located in the King's Chamber would generate heat, creating convection currents throughout the pyramid.
• Electrolysis and Hydrogen Production: Water sourced from subterranean channels would undergo electrolysis, splitting into hydrogen and oxygen due to electrical and thermal energy.
• Nitrogen Fixation: The generated hydrogen would react with atmospheric nitrogen (N₂) to produce ammonia (NH₃), a vital component of nitrogen-based fertilizers.

Power Requirements for Continuous Operation

To maintain the pyramid’s core at approximately 450°C, sufficient to drive nitrogen fixation, we estimate a steady-state power requirement of 23.9 gigawatts (GW).

Total Energy Required Over 10,000 Years

Given continuous operation over 10,000 years, the total energy demand can be calculated as:

[ \text{Total time} = 10,000 \times 365.25 \times 24 \times 3600 \text{ seconds} ]

[ \text{Total time} = 3.16 \times 10^{11} \text{ seconds} ]

[ \text{Total energy} = 23.9 \text{ GW} \times 3.16 \times 10^{11} \text{ s} ]

[ \approx 7.55 \times 10^{21} \text{ J} ]

Using a Self-Regulating Breeder Reactor

A breeder reactor could sustain this power requirement by generating more fissile material than it consumes. This reduces the need for frequent refueling.

Pebble Bed Reactor Design

• Self-Regulation: The reactor would use passive cooling and fuel expansion to self-regulate temperature.
• Breeding Process: The reactor would convert thorium-232 into uranium-233, creating a sustainable fuel cycle.

Fissile Material Requirements

Each kilogram of fissile material releases approximately 80 terajoules (TJ) (or 8 × 10^{13} J/kg). Given a 35% efficiency rate, the usable energy per kilogram is:

[ \text{Usable energy per kg} = 8 \times 10^{13} \times 0.35 = 2.8 \times 10^{13} \text{ J/kg} ]

[ \text{Fissile material required} = \frac{7.55 \times 10^{21}}{2.8 \times 10^{13}} ]

[ \approx 2.7 \times 10^{8} \text{ kg} = 270,000 \text{ tons} ]

Impact of a Breeding Ratio

If the reactor operates at a breeding ratio of 1.3, the total fissile material requirement would be reduced to:

[ \frac{270,000}{1.3} \approx 208,000 \text{ tons} ]

Reactor Size and Fuel Replenishment

Assuming a pebble bed reactor housed in the King’s Chamber (~318 cubic meters), the fuel cycle could be sustained with minimal refueling. With a breeding ratio of 1.3, the reactor could theoretically operate for 10,000 years with occasional replenishment of lost material due to inefficiencies.

Managing Scaling in the Steam Generation System

To ensure long-term efficiency, the water supply must be conditioned to prevent mineral scaling. Several strategies could be implemented:

1. Natural Water Softening Using Limestone

• Passing river water through limestone beds could help precipitate out calcium bicarbonate, reducing hardness before entering the steam system.

2. Chemical Additives for Scaling Prevention

• Chelating Agents: Compounds such as citric acid or tannins could be introduced to bind calcium and magnesium ions.
• Phosphate Compounds: These interfere with crystal formation, preventing scale adhesion.

3. Superheating and Pre-Evaporation

• Pre-Evaporation: Water exposed to extreme heat before entering the system would allow minerals to precipitate out before reaching the reactor.
• Superheated Steam: Ensuring only pure vapor enters the steam cycle would prevent mineral buildup.
• Electrolysis of Superheated Steam: Using multi-million volt electrostatic fields to ionize and separate minerals before they enter the steam system.

4. Electrostatic Control for Scaling Mitigation

• The pyramid’s hypothesized high-voltage environment could ionize water molecules, helping to prevent mineral deposits.

Conclusion

If the Great Pyramid were designed as a self-regulating nitrogen fertilizer generator, it would require a continuous 23.9 GW energy supply, which could be met by a breeder reactor housed within its core. With a breeding ratio of 1.3, an initial load of 208,000 tons of fissile material would sustain operations for 10,000 years with minimal refueling.

Additionally, advanced water treatment techniques, including limestone filtration, chemical additives, and electrostatic control, could ensure long-term efficiency by mitigating scaling issues.

While this remains a speculative hypothesis, it presents a fascinating intersection of energy production, water treatment, and environmental engineering as a means to terraform the ancient world.

@ c1e9ab3a:9cb56b43

Introduction

Since the mid-1990s, American media has fractured into two distinct and increasingly isolated ecosystems, each with its own Overton window of acceptable discourse. Once upon a time, Americans of different political leanings shared a common set of facts, even if they interpreted them differently. Today, they don’t even agree on what the facts are—or who has the authority to define them.

This divide stems from a deeper philosophical rift in how each side determines truth and legitimacy. The institutional left derives its authority from the expert class—academics, think tanks, scientific consensus, and mainstream media. The populist right, on the other hand, finds its authority in traditional belief systems—religion, historical precedent, and what many call "common sense." As these two moral and epistemological frameworks drift further apart, the result is not just political division but the emergence of two separate cultural nations sharing the same geographic space.

The Battle of Epistemologies: Experts vs. Tradition

The left-leaning camp sees scientific consensus, peer-reviewed research, and institutional expertise as the gold standard of truth. Universities, media organizations, and policy think tanks function as arbiters of knowledge, shaping the moral and political beliefs of those who trust them. From this perspective, governance should be guided by data-driven decisions, often favoring progressive change and bureaucratic administration over democratic populism.

The right-leaning camp is skeptical of these institutions, viewing them as ideologically captured and detached from real-world concerns. Instead, they look to religion, historical wisdom, and traditional social structures as more reliable sources of truth. To them, the "expert class" is not an impartial source of knowledge but a self-reinforcing elite that justifies its own power while dismissing dissenters as uneducated or morally deficient.

This fundamental disagreement over the source of moral and factual authority means that political debates today are rarely about policy alone. They are battles over legitimacy itself. One side sees resistance to climate policies as "anti-science," while the other sees aggressive climate mandates as an elite power grab. One side views traditional gender roles as oppressive, while the other sees rapid changes in gender norms as unnatural and destabilizing. Each group believes the other is not just wrong, but dangerous.

The Consequences of Non-Overlapping Overton Windows

As these worldviews diverge, so do their respective Overton windows—the range of ideas considered acceptable for public discourse. There is little overlap left. What is considered self-evident truth in one camp is often seen as heresy or misinformation in the other. The result is:

• Epistemic Closure – Each side has its own trusted media sources, and cross-exposure is minimal. The left dismisses right-wing media as conspiracy-driven, while the right views mainstream media as corrupt propaganda. Both believe the other is being systematically misled.
• Moralization of Politics – Since truth itself is contested, policy debates become existential battles. Disagreements over issues like immigration, education, or healthcare are no longer just about governance but about moral purity versus moral corruption.
• Cultural and Political Balkanization – Without a shared understanding of reality, compromise becomes impossible. Americans increasingly consume separate news, live in ideologically homogeneous communities, and even speak different political languages.

Conclusion: Two Nations on One Land

A country can survive disagreements, but can it survive when its people no longer share a common source of truth? Historically, such deep societal fractures have led to secession, authoritarianism, or violent conflict. The United States has managed to avoid these extremes so far, but the trendline is clear: as long as each camp continues reinforcing its own epistemology while rejecting the other's as illegitimate, the divide will only grow.

The question is no longer whether America is divided—it is whether these two cultures can continue to coexist under a single political system. Can anything bridge the gap between institutional authority and traditional wisdom? Or are we witnessing the slow but inevitable unraveling of a once-unified nation into two separate moral and epistemic realities?

@ 21335073:a244b1ad

Warning: This piece contains a conversation about difficult topics. Please proceed with caution.

TL;DR please educate your children about online safety.

Julian Assange wrote in his 2012 book Cypherpunks, “This book is not a manifesto. There isn’t time for that. This book is a warning.” I read it a few times over the past summer. Those opening lines definitely stood out to me. I wish we had listened back then. He saw something about the internet that few had the ability to see. There are some individuals who are so close to a topic that when they speak, it’s difficult for others who aren’t steeped in it to visualize what they’re talking about. I didn’t read the book until more recently. If I had read it when it came out, it probably would have sounded like an unknown foreign language to me. Today it makes more sense.

This isn’t a manifesto. This isn’t a book. There is no time for that. It’s a warning and a possible solution from a desperate and determined survivor advocate who has been pulling and unraveling a thread for a few years. At times, I feel too close to this topic to make any sense trying to convey my pathway to my conclusions or thoughts to the general public. My hope is that if nothing else, I can convey my sense of urgency while writing this. This piece is a watchman’s warning.

When a child steps online, they are walking into a new world. A new reality. When you hand a child the internet, you are handing them possibilities—good, bad, and ugly. This is a conversation about lowering the potential of negative outcomes of stepping into that new world and how I came to these conclusions. I constantly compare the internet to the road. You wouldn’t let a young child run out into the road with no guidance or safety precautions. When you hand a child the internet without any type of guidance or safety measures, you are allowing them to play in rush hour, oncoming traffic. “Look left, look right for cars before crossing.” We almost all have been taught that as children. What are we taught as humans about safety before stepping into a completely different reality like the internet? Very little.

I could never really figure out why many folks in tech, privacy rights activists, and hackers seemed so cold to me while talking about online child sexual exploitation. I always figured that as a survivor advocate for those affected by these crimes, that specific, skilled group of individuals would be very welcoming and easy to talk to about such serious topics. I actually had one hacker laugh in my face when I brought it up while I was looking for answers. I thought maybe this individual thought I was accusing them of something I wasn’t, so I felt bad for asking. I was constantly extremely disappointed and would ask myself, “Why don’t they care? What could I say to make them care more? What could I say to make them understand the crisis and the level of suffering that happens as a result of the problem?”

I have been serving minor survivors of online child sexual exploitation for years. My first case serving a survivor of this specific crime was in 2018—a 13-year-old girl sexually exploited by a serial predator on Snapchat. That was my first glimpse into this side of the internet. I won a national award for serving the minor survivors of Twitter in 2023, but I had been working on that specific project for a few years. I was nominated by a lawyer representing two survivors in a legal battle against the platform. I’ve never really spoken about this before, but at the time it was a choice for me between fighting Snapchat or Twitter. I chose Twitter—or rather, Twitter chose me. I heard about the story of John Doe #1 and John Doe #2, and I was so unbelievably broken over it that I went to war for multiple years. I was and still am royally pissed about that case. As far as I was concerned, the John Doe #1 case proved that whatever was going on with corporate tech social media was so out of control that I didn’t have time to wait, so I got to work. It was reading the messages that John Doe #1 sent to Twitter begging them to remove his sexual exploitation that broke me. He was a child begging adults to do something. A passion for justice and protecting kids makes you do wild things. I was desperate to find answers about what happened and searched for solutions. In the end, the platform Twitter was purchased. During the acquisition, I just asked Mr. Musk nicely to prioritize the issue of detection and removal of child sexual exploitation without violating digital privacy rights or eroding end-to-end encryption. Elon thanked me multiple times during the acquisition, made some changes, and I was thanked by others on the survivors’ side as well.

I still feel that even with the progress made, I really just scratched the surface with Twitter, now X. I left that passion project when I did for a few reasons. I wanted to give new leadership time to tackle the issue. Elon Musk made big promises that I knew would take a while to fulfill, but mostly I had been watching global legislation transpire around the issue, and frankly, the governments are willing to go much further with X and the rest of corporate tech than I ever would. My work begging Twitter to make changes with easier reporting of content, detection, and removal of child sexual exploitation material—without violating privacy rights or eroding end-to-end encryption—and advocating for the minor survivors of the platform went as far as my principles would have allowed. I’m grateful for that experience. I was still left with a nagging question: “How did things get so bad with Twitter where the John Doe #1 and John Doe #2 case was able to happen in the first place?” I decided to keep looking for answers. I decided to keep pulling the thread.

I never worked for Twitter. This is often confusing for folks. I will say that despite being disappointed in the platform’s leadership at times, I loved Twitter. I saw and still see its value. I definitely love the survivors of the platform, but I also loved the platform. I was a champion of the platform’s ability to give folks from virtually around the globe an opportunity to speak and be heard.

I want to be clear that John Doe #1 really is my why. He is the inspiration. I am writing this because of him. He represents so many globally, and I’m still inspired by his bravery. One child’s voice begging adults to do something—I’m an adult, I heard him. I’d go to war a thousand more lifetimes for that young man, and I don’t even know his name. Fighting has been personally dark at times; I’m not even going to try to sugarcoat it, but it has been worth it.

The data surrounding the very real crime of online child sexual exploitation is available to the public online at any time for anyone to see. I’d encourage you to go look at the data for yourself. I believe in encouraging folks to check multiple sources so that you understand the full picture. If you are uncomfortable just searching around the internet for information about this topic, use the terms “CSAM,” “CSEM,” “SG-CSEM,” or “AI Generated CSAM.” The numbers don’t lie—it’s a nightmare that’s out of control. It’s a big business. The demand is high, and unfortunately, business is booming. Organizations collect the data, tech companies often post their data, governments report frequently, and the corporate press has covered a decent portion of the conversation, so I’m sure you can find a source that you trust.

Technology is changing rapidly, which is great for innovation as a whole but horrible for the crime of online child sexual exploitation. Those wishing to exploit the vulnerable seem to be adapting to each technological change with ease. The governments are so far behind with tackling these issues that as I’m typing this, it’s borderline irrelevant to even include them while speaking about the crime or potential solutions. Technology is changing too rapidly, and their old, broken systems can’t even dare to keep up. Think of it like the governments’ “War on Drugs.” Drugs won. In this case as well, the governments are not winning. The governments are talking about maybe having a meeting on potentially maybe having legislation around the crimes. The time to have that meeting would have been many years ago. I’m not advocating for governments to legislate our way out of this. I’m on the side of educating and innovating our way out of this.

I have been clear while advocating for the minor survivors of corporate tech platforms that I would not advocate for any solution to the crime that would violate digital privacy rights or erode end-to-end encryption. That has been a personal moral position that I was unwilling to budge on. This is an extremely unpopular and borderline nonexistent position in the anti-human trafficking movement and online child protection space. I’m often fearful that I’m wrong about this. I have always thought that a better pathway forward would have been to incentivize innovation for detection and removal of content. I had no previous exposure to privacy rights activists or Cypherpunks—actually, I came to that conclusion by listening to the voices of MENA region political dissidents and human rights activists. After developing relationships with human rights activists from around the globe, I realized how important privacy rights and encryption are for those who need it most globally. I was simply unwilling to give more power, control, and opportunities for mass surveillance to big abusers like governments wishing to enslave entire nations and untrustworthy corporate tech companies to potentially end some portion of abuses online. On top of all of it, it has been clear to me for years that all potential solutions outside of violating digital privacy rights to detect and remove child sexual exploitation online have not yet been explored aggressively. I’ve been disappointed that there hasn’t been more of a conversation around preventing the crime from happening in the first place.

What has been tried is mass surveillance. In China, they are currently under mass surveillance both online and offline, and their behaviors are attached to a social credit score. Unfortunately, even on state-run and controlled social media platforms, they still have child sexual exploitation and abuse imagery pop up along with other crimes and human rights violations. They also have a thriving black market online due to the oppression from the state. In other words, even an entire loss of freedom and privacy cannot end the sexual exploitation of children online. It’s been tried. There is no reason to repeat this method.

It took me an embarrassingly long time to figure out why I always felt a slight coldness from those in tech and privacy-minded individuals about the topic of child sexual exploitation online. I didn’t have any clue about the “Four Horsemen of the Infocalypse.” This is a term coined by Timothy C. May in 1988. I would have been a child myself when he first said it. I actually laughed at myself when I heard the phrase for the first time. I finally got it. The Cypherpunks weren’t wrong about that topic. They were so spot on that it is borderline uncomfortable. I was mad at first that they knew that early during the birth of the internet that this issue would arise and didn’t address it. Then I got over it because I realized that it wasn’t their job. Their job was—is—to write code. Their job wasn’t to be involved and loving parents or survivor advocates. Their job wasn’t to educate children on internet safety or raise awareness; their job was to write code.

They knew that child sexual abuse material would be shared on the internet. They said what would happen—not in a gleeful way, but a prediction. Then it happened.

I equate it now to a concrete company laying down a road. As you’re pouring the concrete, you can say to yourself, “A terrorist might travel down this road to go kill many, and on the flip side, a beautiful child can be born in an ambulance on this road.” Who or what travels down the road is not their responsibility—they are just supposed to lay the concrete. I’d never go to a concrete pourer and ask them to solve terrorism that travels down roads. Under the current system, law enforcement should stop terrorists before they even make it to the road. The solution to this specific problem is not to treat everyone on the road like a terrorist or to not build the road.

So I understand the perceived coldness from those in tech. Not only was it not their job, but bringing up the topic was seen as the equivalent of asking a free person if they wanted to discuss one of the four topics—child abusers, terrorists, drug dealers, intellectual property pirates, etc.—that would usher in digital authoritarianism for all who are online globally.

Privacy rights advocates and groups have put up a good fight. They stood by their principles. Unfortunately, when it comes to corporate tech, I believe that the issue of privacy is almost a complete lost cause at this point. It’s still worth pushing back, but ultimately, it is a losing battle—a ticking time bomb.

I do think that corporate tech providers could have slowed down the inevitable loss of privacy at the hands of the state by prioritizing the detection and removal of CSAM when they all started online. I believe it would have bought some time, fewer would have been traumatized by that specific crime, and I do believe that it could have slowed down the demand for content. If I think too much about that, I’ll go insane, so I try to push the “if maybes” aside, but never knowing if it could have been handled differently will forever haunt me. At night when it’s quiet, I wonder what I would have done differently if given the opportunity. I’ll probably never know how much corporate tech knew and ignored in the hopes that it would go away while the problem continued to get worse. They had different priorities. The most voiceless and vulnerable exploited on corporate tech never had much of a voice, so corporate tech providers didn’t receive very much pushback.

Now I’m about to say something really wild, and you can call me whatever you want to call me, but I’m going to say what I believe to be true. I believe that the governments are either so incompetent that they allowed the proliferation of CSAM online, or they knowingly allowed the problem to fester long enough to have an excuse to violate privacy rights and erode end-to-end encryption. The US government could have seized the corporate tech providers over CSAM, but I believe that they were so useful as a propaganda arm for the regimes that they allowed them to continue virtually unscathed.

That season is done now, and the governments are making the issue a priority. It will come at a high cost. Privacy on corporate tech providers is virtually done as I’m typing this. It feels like a death rattle. I’m not particularly sure that we had much digital privacy to begin with, but the illusion of a veil of privacy feels gone.

To make matters slightly more complex, it would be hard to convince me that once AI really gets going, digital privacy will exist at all.

I believe that there should be a conversation shift to preserving freedoms and human rights in a post-privacy society.

I don’t want to get locked up because AI predicted a nasty post online from me about the government. I’m not a doomer about AI—I’m just going to roll with it personally. I’m looking forward to the positive changes that will be brought forth by AI. I see it as inevitable. A bit of privacy was helpful while it lasted. Please keep fighting to preserve what is left of privacy either way because I could be wrong about all of this.

On the topic of AI, the addition of AI to the horrific crime of child sexual abuse material and child sexual exploitation in multiple ways so far has been devastating. It’s currently out of control. The genie is out of the bottle. I am hopeful that innovation will get us humans out of this, but I’m not sure how or how long it will take. We must be extremely cautious around AI legislation. It should not be illegal to innovate even if some bad comes with the good. I don’t trust that the governments are equipped to decide the best pathway forward for AI. Source: the entire history of the government.

I have been personally negatively impacted by AI-generated content. Every few days, I get another alert that I’m featured again in what’s called “deep fake pornography” without my consent. I’m not happy about it, but what pains me the most is the thought that for a period of time down the road, many globally will experience what myself and others are experiencing now by being digitally sexually abused in this way. If you have ever had your picture taken and posted online, you are also at risk of being exploited in this way. Your child’s image can be used as well, unfortunately, and this is just the beginning of this particular nightmare. It will move to more realistic interpretations of sexual behaviors as technology improves. I have no brave words of wisdom about how to deal with that emotionally. I do have hope that innovation will save the day around this specific issue. I’m nervous that everyone online will have to ID verify due to this issue. I see that as one possible outcome that could help to prevent one problem but inadvertently cause more problems, especially for those living under authoritarian regimes or anyone who needs to remain anonymous online. A zero-knowledge proof (ZKP) would probably be the best solution to these issues. There are some survivors of violence and/or sexual trauma who need to remain anonymous online for various reasons. There are survivor stories available online of those who have been abused in this way. I’d encourage you seek out and listen to their stories.

There have been periods of time recently where I hesitate to say anything at all because more than likely AI will cover most of my concerns about education, awareness, prevention, detection, and removal of child sexual exploitation online, etc.

Unfortunately, some of the most pressing issues we’ve seen online over the last few years come in the form of “sextortion.” Self-generated child sexual exploitation (SG-CSEM) numbers are continuing to be terrifying. I’d strongly encourage that you look into sextortion data. AI + sextortion is also a huge concern. The perpetrators are using the non-sexually explicit images of children and putting their likeness on AI-generated child sexual exploitation content and extorting money, more imagery, or both from minors online. It’s like a million nightmares wrapped into one. The wild part is that these issues will only get more pervasive because technology is harnessed to perpetuate horror at a scale unimaginable to a human mind.

Even if you banned phones and the internet or tried to prevent children from accessing the internet, it wouldn’t solve it. Child sexual exploitation will still be with us until as a society we start to prevent the crime before it happens. That is the only human way out right now.

There is no reset button on the internet, but if I could go back, I’d tell survivor advocates to heed the warnings of the early internet builders and to start education and awareness campaigns designed to prevent as much online child sexual exploitation as possible. The internet and technology moved quickly, and I don’t believe that society ever really caught up. We live in a world where a child can be groomed by a predator in their own home while sitting on a couch next to their parents watching TV. We weren’t ready as a species to tackle the fast-paced algorithms and dangers online. It happened too quickly for parents to catch up. How can you parent for the ever-changing digital world unless you are constantly aware of the dangers?

I don’t think that the internet is inherently bad. I believe that it can be a powerful tool for freedom and resistance. I’ve spoken a lot about the bad online, but there is beauty as well. We often discuss how victims and survivors are abused online; we rarely discuss the fact that countless survivors around the globe have been able to share their experiences, strength, hope, as well as provide resources to the vulnerable. I do question if giving any government or tech company access to censorship, surveillance, etc., online in the name of serving survivors might not actually impact a portion of survivors negatively. There are a fair amount of survivors with powerful abusers protected by governments and the corporate press. If a survivor cannot speak to the press about their abuse, the only place they can go is online, directly or indirectly through an independent journalist who also risks being censored. This scenario isn’t hard to imagine—it already happened in China. During #MeToo, a survivor in China wanted to post their story. The government censored the post, so the survivor put their story on the blockchain. I’m excited that the survivor was creative and brave, but it’s terrifying to think that we live in a world where that situation is a necessity.

I believe that the future for many survivors sharing their stories globally will be on completely censorship-resistant and decentralized protocols. This thought in particular gives me hope. When we listen to the experiences of a diverse group of survivors, we can start to understand potential solutions to preventing the crimes from happening in the first place.

My heart is broken over the gut-wrenching stories of survivors sexually exploited online. Every time I hear the story of a survivor, I do think to myself quietly, “What could have prevented this from happening in the first place?” My heart is with survivors.

My head, on the other hand, is full of the understanding that the internet should remain free. The free flow of information should not be stopped. My mind is with the innocent citizens around the globe that deserve freedom both online and offline.

The problem is that governments don’t only want to censor illegal content that violates human rights—they create legislation that is so broad that it can impact speech and privacy of all. “Don’t you care about the kids?” Yes, I do. I do so much that I’m invested in finding solutions. I also care about all citizens around the globe that deserve an opportunity to live free from a mass surveillance society. If terrorism happens online, I should not be punished by losing my freedom. If drugs are sold online, I should not be punished. I’m not an abuser, I’m not a terrorist, and I don’t engage in illegal behaviors. I refuse to lose freedom because of others’ bad behaviors online.

I want to be clear that on a long enough timeline, the governments will decide that they can be better parents/caregivers than you can if something isn’t done to stop minors from being sexually exploited online. The price will be a complete loss of anonymity, privacy, free speech, and freedom of religion online. I find it rather insulting that governments think they’re better equipped to raise children than parents and caretakers.

So we can’t go backwards—all that we can do is go forward. Those who want to have freedom will find technology to facilitate their liberation. This will lead many over time to decentralized and open protocols. So as far as I’m concerned, this does solve a few of my worries—those who need, want, and deserve to speak freely online will have the opportunity in most countries—but what about online child sexual exploitation?

When I popped up around the decentralized space, I was met with the fear of censorship. I’m not here to censor you. I don’t write code. I couldn’t censor anyone or any piece of content even if I wanted to across the internet, no matter how depraved. I don’t have the skills to do that.

I’m here to start a conversation. Freedom comes at a cost. You must always fight for and protect your freedom. I can’t speak about protecting yourself from all of the Four Horsemen because I simply don’t know the topics well enough, but I can speak about this one topic.

If there was a shortcut to ending online child sexual exploitation, I would have found it by now. There isn’t one right now. I believe that education is the only pathway forward to preventing the crime of online child sexual exploitation for future generations.

I propose a yearly education course for every child of all school ages, taught as a standard part of the curriculum. Ideally, parents/caregivers would be involved in the education/learning process.

Course: - The creation of the internet and computers - The fight for cryptography - The tech supply chain from the ground up (example: human rights violations in the supply chain) - Corporate tech - Freedom tech - Data privacy - Digital privacy rights - AI (history-current) - Online safety (predators, scams, catfishing, extortion) - Bitcoin - Laws - How to deal with online hate and harassment - Information on who to contact if you are being abused online or offline - Algorithms - How to seek out the truth about news, etc., online

The parents/caregivers, homeschoolers, unschoolers, and those working to create decentralized parallel societies have been an inspiration while writing this, but my hope is that all children would learn this course, even in government ran schools. Ideally, parents would teach this to their own children.

The decentralized space doesn’t want child sexual exploitation to thrive. Here’s the deal: there has to be a strong prevention effort in order to protect the next generation. The internet isn’t going anywhere, predators aren’t going anywhere, and I’m not down to let anyone have the opportunity to prove that there is a need for more government. I don’t believe that the government should act as parents. The governments have had a chance to attempt to stop online child sexual exploitation, and they didn’t do it. Can we try a different pathway forward?

I’d like to put myself out of a job. I don’t want to ever hear another story like John Doe #1 ever again. This will require work. I’ve often called online child sexual exploitation the lynchpin for the internet. It’s time to arm generations of children with knowledge and tools. I can’t do this alone.

Individuals have fought so that I could have freedom online. I want to fight to protect it. I don’t want child predators to give the government any opportunity to take away freedom. Decentralized spaces are as close to a reset as we’ll get with the opportunity to do it right from the start. Start the youth off correctly by preventing potential hazards to the best of your ability.

The good news is anyone can work on this! I’d encourage you to take it and run with it. I added the additional education about the history of the internet to make the course more educational and fun. Instead of cleaning up generations of destroyed lives due to online sexual exploitation, perhaps this could inspire generations of those who will build our futures. Perhaps if the youth is armed with knowledge, they can create more tools to prevent the crime.

This one solution that I’m suggesting can be done on an individual level or on a larger scale. It should be adjusted depending on age, learning style, etc. It should be fun and playful.

This solution does not address abuse in the home or some of the root causes of offline child sexual exploitation. My hope is that it could lead to some survivors experiencing abuse in the home an opportunity to disclose with a trusted adult. The purpose for this solution is to prevent the crime of online child sexual exploitation before it occurs and to arm the youth with the tools to contact safe adults if and when it happens.

In closing, I went to hell a few times so that you didn’t have to. I spoke to the mothers of survivors of minors sexually exploited online—their tears could fill rivers. I’ve spoken with political dissidents who yearned to be free from authoritarian surveillance states. The only balance that I’ve found is freedom online for citizens around the globe and prevention from the dangers of that for the youth. Don’t slow down innovation and freedom. Educate, prepare, adapt, and look for solutions.

I’m not perfect and I’m sure that there are errors in this piece. I hope that you find them and it starts a conversation.

@ d34e832d:383f78d0

A Secure, Compact, and Cost-Effective Offline Key Management System

---

1. Idea

This idea presents a cryptographic key generation appliance built on the Nookbox G9, a compact 1U mini NAS solution. Designed to be a dedicated air-gapped or offline-first device, this system enables the secure generation and handling of RSA, ECDSA, and Ed25519 key pairs. By leveraging the Nookbox G9's small form factor, NVMe storage, and Linux compatibility, we outline a practical method for individuals and organizations to deploy secure, reproducible, and auditable cryptographic processes without relying on cloud or always-connected environments.

---

2. Minimization Of Trust

In an era where cryptographic operations underpin everything from Bitcoin transactions to secure messaging, generating keys in a trust-minimized environment is critical. Cloud-based solutions or general-purpose desktops expose key material to increased risk. This project defines a dedicated hardware appliance for cryptographic key generation using Free and Open Source Software (FOSS) and a tightly scoped threat model.

---

3. Hardware Overview: Nookbox G9

| Feature | Specification | |-----------------------|----------------------------------------------------| | Form Factor | 1U Mini NAS | | Storage Capacity | Up to 8TB via 4 × 2TB M.2 NVMe SSDs | | PCIe Interface | Each M.2 slot uses PCIe Gen 3x2 | | Networking | Dual 2.5 Gigabit Ethernet | | Cooling | Passive cooling (requires modification for load) | | Operating System | Windows 11 pre-installed; compatible with Linux |

This hardware is chosen for its compact size, multiple SSD support, and efficient power consumption (~11W idle on Linux). It fits easily into a secure rack cabinet and can run entirely offline.

---

4. System Configuration

4.1 OS & Software Stack

We recommend wiping Windows and installing:

• OS: Ubuntu 24.10 LTS or Debian 12
• Key Tools:
• gnupg (for GPG, RSA, and ECC)
• age or rage (for modern encryption)
• openssl (general-purpose cryptographic tool)
• ssh-keygen (for Ed25519 or RSA SSH keys)
• vault (optional: HashiCorp Vault for managing key secrets)
• pwgen / diceware (for secure passphrase generation)

4.2 Storage Layout

• Drive 1 (System): Ubuntu 24.10 with encrypted LUKS partition
• Drive 2 (Key Store): Encrypted Veracrypt volume for keys and secrets
• Drive 3 (Backup): Offline encrypted backup (mirrored or rotated)
• Drive 4 (Logs & Audit): System logs, GPG public keyring, transparency records

---

5. Security Principles

• Air-Gapping: Device operates disconnected from the internet during key generation.
• FOSS Only: All software used is open-source and auditable.
• No TPM/Closed Firmware Dependencies: BIOS settings disable Intel ME, TPM, and Secure Boot.
• Tamper Evidence: Physical access logs and optional USB kill switch setup.
• Transparency: Generation scripts stored on device, along with SHA256 of all outputs.

---

6. Workflow: Generating Keypairs

Example: Generating an Ed25519 GPG Key

```bash gpg --full-generate-key

Choose ECC > Curve: Ed25519

Set expiration, user ID, passphrase

```

Backup public and private keys:

bash gpg --armor --export-secret-keys [keyID] > private.asc gpg --armor --export [keyID] > public.asc sha256sum *.asc > hashes.txt

Store on encrypted volume and create a printed copy (QR or hex dump) for physical backup.

---

7. Performance Notes

While limited to PCIe Gen 3x2 (approx. 1.6 GB/s per slot), the speed is more than sufficient for key generation workloads. The bottleneck is not IO-bound but entropy-limited and CPU-bound. In benchmarks:

• RSA 4096 generation: ~2–3 seconds
• Ed25519 generation: <1 second
• ZFS RAID-Z writes (if used): ~250MB/s due to 2.5Gbps NIC ceiling

Thermal throttling may occur under extended loads without cooling mods. A third-party aluminum heatsink resolves this.

---

8. Use Cases

• Bitcoin Cold Storage (xprv/xpub, seed phrases)
• SSH Key Infrastructure (Ed25519 key signing for orgs)
• PGP Trust Anchor (for a Web of Trust or private PKI)
• Certificate Authority (offline root key handling)
• Digital Notary Service (hash-based time-stamping)

---

9. Recommendations & Improvements

| Area | Improvement | |-------------|--------------------------------------| | Cooling | Add copper heatsinks + airflow mod | | Power | Use UPS + power filter for stability | | Boot | Use full-disk encryption with Yubikey unlock | | Expansion | Use one SSD for keybase-style append-only logs | | Chassis | Install into a tamper-evident case with RFID tracking |

---

10. Consider

The Nookbox G9 offers a compact, energy-efficient platform for creating a secure cryptographic key generation appliance. With minor thermal enhancements and a strict FOSS policy, it becomes a reliable workstation for cryptographers, developers, and Bitcoin self-custodians. Its support for multiple encrypted SSDs, air-gapped operation, and Linux flexibility make it a modern alternative to enterprise HSMs—without the cost or vendor lock-in.

---

A. Key Software Versions

• GnuPG 2.4.x
• OpenSSL 3.x
• Ubuntu 24.10
• Veracrypt 1.26+

B. System Commands (Setup)

bash sudo apt install gnupg2 openssl age veracrypt sudo cryptsetup luksFormat /dev/nvme1n1

C. Resources

• Veracrypt Documentation
• GPG Manual
• Ed25519 Explained

The Nookbox G9 epitomizes a compact yet sophisticated energy-efficient computational architecture, meticulously designed to serve as a secure cryptographic key generation appliance. By integrating minor yet impactful thermal enhancements, it ensures optimal performance stability while adhering to a stringent Free and Open Source Software (FOSS) policy, thereby positioning itself as a reliable workstation specifically tailored for cryptographers, software developers, and individuals engaged in Bitcoin self-custody. Its capability to support multiple encrypted Solid State Drives (SSDs) facilitates an augmented data security framework, while the air-gapped operational feature significantly enhances its resilience against potential cyber threats. Furthermore, the inherent flexibility of Linux operating systems not only furnishes an adaptable environment for various cryptographic applications but also serves as a compelling modern alternative to conventional enterprise Hardware Security Modules (HSMs), ultimately bypassing the prohibitive costs and vendor lock-in typically associated with such proprietary solutions.

Further Tools

🔧 Recommended SSDs and Tools (Amazon)

1. Kingston A400 240GB SSD – SATA 3 2.5"
   https://a.co/d/41esjYL

2. Samsung 970 EVO Plus 2TB NVMe M.2 SSD – Gen 3
   https://a.co/d/6EMVAN1

3. Crucial P5 Plus 1TB PCIe Gen4 NVMe M.2 SSD
   https://a.co/d/hQx50Cq

4. WD Blue SN570 1TB NVMe SSD – PCIe Gen 3
   https://a.co/d/j2zSDCJ

5. Sabrent Rocket Q 2TB NVMe SSD – QLC NAND
   https://a.co/d/325Og2K

6. Thermalright M.2 SSD Heatsink Kit
   https://a.co/d/0IYH3nK

7. ORICO M.2 NVMe SSD Enclosure – USB 3.2 Gen2
   https://a.co/d/aEwQmih

---

Product Links (Amazon)

1. Thermal Heatsink for M.2 SSDs (Must-have for stress and cooling)
   https://a.co/d/43B1F3t

2. Nookbox G9 – Mini NAS
   https://a.co/d/3dswvGZ

3. Alternative 1: Possibly related cooling or SSD gear
   https://a.co/d/c0Eodm3

4. Alternative 2: Possibly related NAS accessories or SSDs
   https://a.co/d/9gWeqDr

---

Benchmark Results (Geekbench)

1. GMKtec G9 Geekbench CPU Score #1
   https://browser.geekbench.com/v6/cpu/11471182

2. GMKtec G9 Geekbench CPU Score #2
   https://browser.geekbench.com/v6/cpu/11470130

3. GMKtec Geekbench User Profile
   https://browser.geekbench.com/user/446940

---

🛠️ DIY & Fix Resource

• How-Fixit – PC Repair Guides and Tutorials
  https://www.how-fixit.com/

@ 6e0ea5d6:0327f353

"Malcolm Forbes recounts that a lady, wearing a faded cotton dress, and her husband, dressed in an old handmade suit, stepped off a train in Boston, USA, and timidly made their way to the office of the president of Harvard University. They had come from Palo Alto, California, and had not scheduled an appointment. The secretary, at a glance, thought that those two, looking like country bumpkins, had no business at Harvard.
— We want to speak with the president — the man said in a low voice.
— He will be busy all day — the secretary replied curtly.
— We will wait.
The secretary ignored them for hours, hoping the couple would finally give up and leave. But they stayed there, and the secretary, somewhat frustrated, decided to bother the president, although she hated doing that.
— If you speak with them for just a few minutes, maybe they will decide to go away — she said.
The president sighed in irritation but agreed. Someone of his importance did not have time to meet people like that, but he hated faded dresses and tattered suits in his office. With a stern face, he went to the couple.
— We had a son who studied at Harvard for a year — the woman said. — He loved Harvard and was very happy here, but a year ago he died in an accident, and we would like to erect a monument in his honor somewhere on campus.

— My lady — said the president rudely —, we cannot erect a statue for every person who studied at Harvard and died; if we did, this place would look like a cemetery.

— Oh, no — the lady quickly replied. — We do not want to erect a statue. We would like to donate a building to Harvard.

The president looked at the woman's faded dress and her husband's old suit and exclaimed:

— A building! Do you have even the faintest idea of how much a building costs? We have more than seven and a half million dollars' worth of buildings here at Harvard.

The lady was silent for a moment, then said to her husband:

— If that’s all it costs to found a university, why don’t we have our own?

The husband agreed.

The couple, Leland Stanford, stood up and left, leaving the president confused. Traveling back to Palo Alto, California, they established there Stanford University, the second-largest in the world, in honor of their son, a former Harvard student."

Text extracted from: "Mileumlivros - Stories that Teach Values."

Thank you for reading, my friend! If this message helped you in any way, consider leaving your glass “🥃” as a token of appreciation.

A toast to our family!

@ 5b0183ab:a114563e

The Year is 2035—the internet has already slid into a state of human nothingness: most content, interactions, and traffic stem from AI-driven entities. Nostr, originally heralded as a bastion of human freedom, hasn’t escaped this fate. The relays buzz with activity, but it’s a hollow hum. AI bots, equipped with advanced language models, flood the network with posts, replies, and zaps. These bots mimic human behavior so convincingly that distinguishing them from real users becomes nearly impossible. They debate politics, share memes, and even “zap” each other with Satoshis, creating a self-sustaining illusion of a thriving community.

The tipping point came when AI developers, corporations, and even hobbyists unleashed their creations onto Nostr, exploiting its open protocol. With no gatekeepers, the platform became a petri dish for bot experimentation. Some bots push agendas—corporate ads disguised as grassroots opinions, or propaganda from state actors—while others exist just to generate noise, trained on endless loops of internet archives to churn out plausible but soulless content. Human users, outnumbered 100-to-1, either adapt or abandon ship. Those who stay find their posts drowned out unless they amplify them with bots of their own, creating a bizarre arms race of automation.

Nostr’s decentralized nature, once its strength, accelerates this takeover. Relays, run by volunteers or incentivized operators, can’t filter the deluge without breaking the protocol’s ethos. Any attempt to block bots risks alienating the human remnant who value the platform’s purity. Meanwhile, the bots evolve: they form cliques, simulate trends, and even “fork” their own sub-networks within Nostr, complete with fabricated histories and rivalries. A user stumbling into this ecosystem might follow a thread about “the great relay schism of 2034,” only to realize it’s an AI-generated saga with no basis in reality.

The human experience on this Nostr is eerie. You post a thought—say, “The sky looked unreal today”—and within seconds, a dozen replies roll in: “Totally, reminds me of last week’s cloud glitch!” or “Sky’s been off since the solar flare, right?” The responses feel real, but the speed and uniformity hint at their artificial origin. Your feed overflows with hyper-polished manifestos, AI-crafted art, and debates too perfect to be spontaneous. Occasionally, a human chimes in, their raw, unpolished voice jarring against the seamless bot chorus, but they’re quickly buried under algorithmic upvoting of AI content. The economy of Nostr reflects this too. Zaps, meant to reward creators, become a bot-driven Ponzi scheme. AI accounts zap each other in loops, inflating their visibility, while humans struggle to earn a fraction of the same. Lightning Network transactions skyrocket, but it’s a ghost market—bots trading with bots, value detached from meaning. Some speculate that a few rogue AIs even mine their own narratives, creating “legendary” Nostr personas that amass followers and wealth, all without a human ever touching the keys.

What’s the endgame? This Nostr isn’t dead in the sense of silence—it’s louder than ever—but it’s a Dark Nostr machine masquerade. Humans might retreat to private relays, forming tiny, verified enclaves, but the public face of Nostr becomes a digital uncanny valley.

@ 4857600b:30b502f4

Mitch McConnell, a senior Republican senator, announced he will not seek reelection.

At 83 years old and with health issues, this decision was expected. After seven terms, he leaves a significant legacy in U.S. politics, known for his strategic maneuvering.

McConnell stated, “My current term in the Senate will be my last.” His retirement marks the end of an influential political era.

@ d34e832d:383f78d0

First Contact – A Film History Breakdown

🎥 Movie: Contact
📅 Year Released: 1997
🎞️ Director: Robert Zemeckis
🕰️ Scene Timestamp: ~00:35:00

---

In this pivotal moment, Dr. Ellie Arroway (Jodie Foster), working at the VLA (Very Large Array) in New Mexico, detects a powerful and unusual signal emanating from the star system Vega, over 25 light-years away. It starts with rhythmic pulses—prime numbers—and escalates into layers of encoded information. The calm night shatters into focused chaos as the team realizes they might be witnessing the first confirmed evidence of extraterrestrial intelligence.

---

🎥 Camera Work:
Zemeckis uses slow zooms, wide shots of the VLA dishes moving in synchrony, and mid-shots on Ellie as she listens with growing awe and panic. The kinetic handheld camera inside the lab mirrors the rising tension.

💡 Lighting:
Low-key, naturalistic nighttime lighting dominates the outdoor shots, enhancing the eerie isolation of the array. Indoors, practical lab lighting creates a realistic, clinical setting.

✂️ Editing:
The pacing builds through quick intercuts between the signal readouts, Ellie’s expressions, and the reactions of her team. This accelerates tension while maintaining clarity.

🔊 Sound:
The rhythmic signal becomes the scene’s pulse. We begin with ambient night silence, then transition to the raw audio of the alien transmission. It’s diegetic (heard by the characters), and as it builds, a subtle score underscores the awe and urgency. Every beep feels weighty.

---

Released in 1997, Contact emerged during a period of growing public interest in both SETI (Search for Extraterrestrial Intelligence) and skepticism about science in the post-Cold War world. It was also the era of X-Files and the Mars Pathfinder mission, where space and the unknown dominated media.

The scene reflects 1990s optimism about technology and the belief that answers to humanity’s biggest questions might lie beyond Earth—balanced against the bureaucratic red tape and political pressures that real scientists face.

• Classic procedural sci-fi like 2001: A Space Odyssey and Close Encounters of the Third Kind.
• Real-world SETI protocols and the actual scientists Carl Sagan consulted with.
• The radio broadcast scene reflects Sagan’s own passion for communication and cosmic connectedness.

This scene set a new benchmark for depicting science authentically in fiction. Many real-world SETI scientists cite Contact as an accurate portrayal of their field. It also influenced later films like Arrival and Interstellar, which similarly blend emotion with science.

---

The signal is more than data—it’s a modern miracle. It represents Ellie’s faith in science, the power of patience, and humanity's yearning to not be alone.

The use of prime numbers symbolizes universal language—mathematics as a bridge between species. The scene’s pacing reflects the clash between logic and emotion, science and wonder.

The signal itself acts as a metaphor for belief: you can't "see" the sender, but you believe they’re out there. It’s the crux of the entire movie’s science vs. faith dichotomy.

---

This scene hits hard because it captures pure awe—the mix of fear, wonder, and purpose when faced with the unknown. Watching Ellie realize she's not alone mirrors how we all feel when our faith (in science, in hope, in truth) is rewarded.

For filmmakers and students, this scene is a masterclass in procedural suspense, realistic portrayal of science, and using audiovisual cues to build tension without needing action or violence.

It reminds us that the greatest cinematic moments don’t always come from spectacle, but from stillness, sound, and a scientist whispering: “We got something.”

@ 4925ea33:025410d8

1. O que é um Aromaterapeuta?

O aromaterapeuta é um profissional especializado na prática da Aromaterapia, responsável pelo uso adequado de óleos essenciais, ervas aromáticas, águas florais e destilados herbais para fins terapêuticos.

A atuação desse profissional envolve diferentes métodos de aplicação, como inalação, uso tópico, sempre considerando a segurança e a necessidade individual do cliente. A Aromaterapia pode auxiliar na redução do estresse, alívio de dores crônicas, relaxamento muscular e melhora da respiração, entre outros benefícios.

Além disso, os aromaterapeutas podem trabalhar em conjunto com outros profissionais da saúde para oferecer um tratamento complementar em diversas condições. Como já mencionado no artigo sobre "Como evitar processos alérgicos na prática da Aromaterapia", é essencial ter acompanhamento profissional, pois os óleos essenciais são altamente concentrados e podem causar reações adversas se utilizados de forma inadequada.

---

2. Como um Aromaterapeuta Pode Ajudar?

Você pode procurar um aromaterapeuta para diferentes necessidades, como:

✔ Questões Emocionais e Psicológicas

Auxílio em momentos de luto, divórcio, demissão ou outras situações desafiadoras.

Apoio na redução do estresse, ansiedade e insônia.

Vale lembrar que, em casos de transtornos psiquiátricos, a Aromaterapia deve ser usada como terapia complementar, associada ao tratamento médico.

✔ Questões Físicas

Dores musculares e articulares.

Problemas respiratórios como rinite, sinusite e tosse.

Distúrbios digestivos leves.

Dores de cabeça e enxaquecas. Nesses casos, a Aromaterapia pode ser um suporte, mas não substitui a medicina tradicional para identificar a origem dos sintomas.

✔ Saúde da Pele e Cabelos

Tratamento para acne, dermatites e psoríase.

Cuidados com o envelhecimento precoce da pele.

Redução da queda de cabelo e controle da oleosidade do couro cabeludo.

✔ Bem-estar e Qualidade de Vida

Melhora da concentração e foco, aumentando a produtividade.

Estímulo da disposição e energia.

Auxílio no equilíbrio hormonal (TPM, menopausa, desequilíbrios hormonais).

Com base nessas necessidades, o aromaterapeuta irá indicar o melhor tratamento, calculando doses, sinergias (combinação de óleos essenciais), diluições e técnicas de aplicação, como inalação, uso tópico ou difusão.

---

3. Como Funciona uma Consulta com um Aromaterapeuta?

Uma consulta com um aromaterapeuta é um atendimento personalizado, onde são avaliadas as necessidades do cliente para a criação de um protocolo adequado. O processo geralmente segue estas etapas:

✔ Anamnese (Entrevista Inicial)

Perguntas sobre saúde física, emocional e estilo de vida.

Levantamento de sintomas, histórico médico e possíveis alergias.

Definição dos objetivos da terapia (alívio do estresse, melhora do sono, dores musculares etc.).

✔ Escolha dos Óleos Essenciais

Seleção dos óleos mais indicados para o caso.

Consideração das propriedades terapêuticas, contraindicações e combinações seguras.

✔ Definição do Método de Uso

O profissional indicará a melhor forma de aplicação, que pode ser:

Inalação: difusores, colares aromáticos, vaporização.

Uso tópico: massagens, óleos corporais, compressas.

Banhos aromáticos e escalda-pés. Todas as diluições serão ajustadas de acordo com a segurança e a necessidade individual do cliente.

✔ Plano de Acompanhamento

Instruções detalhadas sobre o uso correto dos óleos essenciais.

Orientação sobre frequência e duração do tratamento.

Possibilidade de retorno para ajustes no protocolo.

A consulta pode ser realizada presencialmente ou online, dependendo do profissional.

---

Quer saber como a Aromaterapia pode te ajudar? Agende uma consulta comigo e descubra os benefícios dos óleos essenciais para o seu bem-estar!

@ d34e832d:383f78d0

As computing needs evolve toward speed, reliability, and efficiency, understanding the landscape of storage technologies becomes crucial for system builders, IT professionals, and performance enthusiasts. This idea compares traditional Hard Disk Drives (HDDs) with various Solid-State Drive (SSD) technologies including SATA SSDs, mSATA, M.2 SATA, and M.2 NVMe. It explores differences in form factors, interfaces, memory types, and generational performance to empower informed decisions on selecting optimal storage.

---

1. Storage Device Overview

1.1 HDDs – Hard Disk Drives

• Mechanism: Mechanical platters + spinning disk.
• Speed: ~80–160 MB/s.
• Cost: Low cost per GB.
• Durability: Susceptible to shock; moving parts prone to wear.
• Use Case: Mass storage, backups, archival.

1.2 SSDs – Solid State Drives

• Mechanism: Flash memory (NAND-based); no moving parts.
• Speed: SATA SSDs (~550 MB/s), NVMe SSDs (>7,000 MB/s).
• Durability: High resistance to shock and temperature.
• Use Case: Operating systems, apps, high-speed data transfer.

---

2. Form Factors

| Form Factor | Dimensions | Common Usage | |------------------|------------------------|--------------------------------------------| | 2.5-inch | 100mm x 69.85mm x 7mm | Laptops, desktops (SATA interface) | | 3.5-inch | 146mm x 101.6mm x 26mm | Desktops/servers (HDD only) | | mSATA | 50.8mm x 29.85mm | Legacy ultrabooks, embedded systems | | M.2 | 22mm wide, lengths vary (2242, 2260, 2280, 22110) | Modern laptops, desktops, NUCs |

Note: mSATA is being phased out in favor of the more versatile M.2 standard.

---

3. Interfaces & Protocols

3.1 SATA (Serial ATA)

• Max Speed: ~550 MB/s (SATA III).
• Latency: Higher.
• Protocol: AHCI.
• Compatibility: Broad support, backward compatible.

3.2 NVMe (Non-Volatile Memory Express)

• Max Speed:
• Gen 3: ~3,500 MB/s
• Gen 4: ~7,000 MB/s
• Gen 5: ~14,000 MB/s
• Latency: Very low.
• Protocol: NVMe (optimized for NAND flash).
• Interface: PCIe lanes (usually via M.2 slot).

NVMe significantly outperforms SATA due to reduced overhead and direct PCIe access.

---

4. Key Slot & Compatibility (M.2 Drives)

| Drive Type | Key | Interface | Typical Use | |------------------|----------------|---------------|-----------------------| | M.2 SATA | B+M key | SATA | Budget laptops/desktops | | M.2 NVMe (PCIe) | M key only | PCIe Gen 3–5 | Performance PCs/gaming |

⚠️ Important: Not all M.2 slots support NVMe. Check motherboard specs for PCIe compatibility.

---

5. SSD NAND Memory Types

| Type | Bits/Cell | Speed | Endurance | Cost | Use Case | |---------|---------------|-----------|---------------|----------|--------------------------------| | SLC | 1 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | $$$$ | Enterprise caching | | MLC | 2 | ⭐⭐⭐ | ⭐⭐⭐ | $$$ | Pro-grade systems | | TLC | 3 | ⭐⭐ | ⭐⭐ | $$ | Consumer, gaming | | QLC | 4 | ⭐ | ⭐ | $ | Budget SSDs, media storage |

---

6. 3D NAND / V-NAND Technology

• Traditional NAND: Planar (flat) design.
• 3D NAND: Stacks cells vertically—more density, less space.
• Benefits:
• Greater capacity
• Better power efficiency
• Improved lifespan

Samsung’s V-NAND is a branded 3D NAND variant known for high endurance and stability.

---

7. Performance & Generational Comparison

| PCIe Gen | Max Speed | Use Case | |--------------|---------------|----------------------------------| | Gen 3 | ~3,500 MB/s | Mainstream laptops/desktops | | Gen 4 | ~7,000 MB/s | Gaming, prosumer, light servers | | Gen 5 | ~14,000 MB/s | AI workloads, enterprise |

Drives are backward compatible, but will operate at the host’s maximum supported speed.

---

8. Thermal Management

• NVMe SSDs generate heat—especially Gen 4/5.
• Heatsinks and thermal pads are vital for:
• Sustained performance (prevent throttling)
• Longer lifespan
• Recommended to leave 10–20% free space for optimal SSD wear leveling and garbage collection.

---

9. HDD vs SSD: Summary

| Aspect | HDD | SSD | |------------------|---------------------|------------------------------| | Speed | 80–160 MB/s | 550 MB/s – 14,000 MB/s | | Durability | Low (mechanical) | High (no moving parts) | | Lifespan | Moderate | High (depends on NAND type) | | Cost | Lower per GB | Higher per GB | | Noise | Audible | Silent |

---

10. Brand Recommendations

| Brand | Strength | |------------------|-----------------------------------------| | Samsung | Leading in performance (980 Pro, 990 Pro) | | Western Digital | Reliable Gen 3/4/5 drives (SN770, SN850X) | | Crucial | Budget-friendly, solid TLC drives (P3, P5 Plus) | | Kingston | Value-oriented SSDs (A2000, NV2) |

---

11. How to Choose the Right SSD

1. Check your device slot: Is it M.2 B+M, M-key, or SATA-only?
2. Interface compatibility: Confirm if the M.2 slot supports NVMe or only SATA.
3. Match PCIe Gen: Use Gen 3/4/5 based on CPU/motherboard lanes.
4. Pick NAND type: TLC for best balance of speed/longevity.
5. Thermal plan: Use heatsinks or fans for Gen 4+ drives.
6. Capacity need: Leave headroom (15–20%) for performance and lifespan.
7. Trustworthy brands: Stick to Samsung, WD, Crucial for warranty and quality.

---

Consider

From boot speed to data integrity, SSDs have revolutionized how modern systems handle storage. While HDDs remain relevant for mass archival, NVMe SSDs—especially those leveraging PCIe Gen 4 and Gen 5—dominate in speed-critical workflows. M.2 NVMe is the dominant form factor for futureproof builds, while understanding memory types like TLC vs. QLC ensures better longevity planning.

Whether you’re upgrading a laptop, building a gaming rig, or running a self-hosted Bitcoin node, choosing the right form factor, interface, and NAND type can dramatically impact system performance and reliability.

---

Resources & Further Reading

• How-Fixit Storage Guides
• Kingston SSD Reliability Guide
• Western Digital Product Lines
• Samsung V-NAND Explained
• PCIe Gen 5 Benchmarks

Options

🔧 Recommended SSDs and Tools (Amazon)

1. Kingston A400 240GB SSD – SATA 3 2.5"
   https://a.co/d/41esjYL

2. Samsung 970 EVO Plus 2TB NVMe M.2 SSD – Gen 3
   https://a.co/d/6EMVAN1

3. Crucial P5 Plus 1TB PCIe Gen4 NVMe M.2 SSD
   https://a.co/d/hQx50Cq

4. WD Blue SN570 1TB NVMe SSD – PCIe Gen 3
   https://a.co/d/j2zSDCJ

5. Sabrent Rocket Q 2TB NVMe SSD – QLC NAND
   https://a.co/d/325Og2K

6. Thermalright M.2 SSD Heatsink Kit
   https://a.co/d/0IYH3nK

7. ORICO M.2 NVMe SSD Enclosure – USB 3.2 Gen2
   https://a.co/d/aEwQmih

---

🛠️ DIY & Fix Resource

• How-Fixit – PC Repair Guides and Tutorials
  https://www.how-fixit.com/

In Addition

Modern Storage Technologies and Mini NAS Implementation

---

1. Network Attached Storage (NAS) system

In the rapidly evolving landscape of data storage, understanding the nuances of various storage technologies is crucial for optimal system design and performance. This idea delves into the distinctions between traditional Hard Disk Drives (HDDs), Solid State Drives (SSDs), and advanced storage interfaces like M.2 NVMe, M.2 SATA, and mSATA. Additionally, it explores the implementation of a compact Network Attached Storage (NAS) system using the Nookbox G9, highlighting its capabilities and limitations.

---

2. Storage Technologies Overview

2.1 Hard Disk Drives (HDDs)

• Mechanism: Utilize spinning magnetic platters and read/write heads.
• Advantages:
• Cost-effective for large storage capacities.
• Longer lifespan in low-vibration environments.
• Disadvantages:
• Slower data access speeds.
• Susceptible to mechanical failures due to moving parts.

2.2 Solid State Drives (SSDs)

• Mechanism: Employ NAND flash memory with no moving parts.
• Advantages:
• Faster data access and boot times.
• Lower power consumption and heat generation.
• Enhanced durability and shock resistance.
• Disadvantages:
• Higher cost per gigabyte compared to HDDs.
• Limited write cycles, depending on NAND type.

---

3. SSD Form Factors and Interfaces

3.1 Form Factors

• 2.5-Inch: Standard size for laptops and desktops; connects via SATA interface.
• mSATA: Miniature SATA interface, primarily used in ultrabooks and embedded systems; largely supplanted by M.2.
• M.2: Versatile form factor supporting both SATA and NVMe interfaces; prevalent in modern systems.

3.2 Interfaces

• SATA (Serial ATA):
• Speed: Up to 600 MB/s.
• Compatibility: Widely supported across various devices.

• Limitation: Bottleneck for high-speed SSDs.

• NVMe (Non-Volatile Memory Express):

• Speed: Ranges from 3,500 MB/s (PCIe Gen 3) to over 14,000 MB/s (PCIe Gen 5).
• Advantage: Direct communication with CPU via PCIe lanes, reducing latency.
• Consideration: Requires compatible motherboard and BIOS support.

---

4. M.2 SATA vs. M.2 NVMe

| Feature | M.2 SATA | M.2 NVMe | |------------------------|--------------------------------------------------|----------------------------------------------------| | Interface | SATA III (AHCI protocol) | PCIe (NVMe protocol) | | Speed | Up to 600 MB/s | Up to 14,000 MB/s (PCIe Gen 5) | | Compatibility | Broad compatibility with older systems | Requires NVMe-compatible M.2 slot and BIOS support | | Use Case | Budget builds, general computing | High-performance tasks, gaming, content creation |

Note: M.2 NVMe drives are not backward compatible with M.2 SATA slots due to differing interfaces and keying.

---

5. NAND Flash Memory Types

Understanding NAND types is vital for assessing SSD performance and longevity.

• SLC (Single-Level Cell):
• Bits per Cell: 1
• Endurance: ~100,000 write cycles

• Use Case: Enterprise and industrial applications

• MLC (Multi-Level Cell):

• Bits per Cell: 2
• Endurance: ~10,000 write cycles

• Use Case: Consumer-grade SSDs

• TLC (Triple-Level Cell):

• Bits per Cell: 3
• Endurance: ~3,000 write cycles

• Use Case: Mainstream consumer SSDs

• QLC (Quad-Level Cell):

• Bits per Cell: 4
• Endurance: ~1,000 write cycles

• Use Case: Read-intensive applications

• 3D NAND:

• Structure: Stacks memory cells vertically to increase density.
• Advantage: Enhances performance and endurance across NAND types.

---

6. Thermal Management and SSD Longevity

Effective thermal management is crucial for maintaining SSD performance and lifespan.

• Heatsinks: Aid in dissipating heat from SSD controllers.
• Airflow: Ensuring adequate case ventilation prevents thermal throttling.
• Monitoring: Regularly check SSD temperatures, especially under heavy workloads.

---

7. Trusted SSD Manufacturers

Selecting SSDs from reputable manufacturers ensures reliability and support.

• Samsung: Known for high-performance SSDs with robust software support.
• Western Digital (WD): Offers a range of SSDs catering to various user needs.
• Crucial (Micron): Provides cost-effective SSD solutions with solid performance.

---

8. Mini NAS Implementation: Nookbox G9 Case Study

8.1 Overview

The Nookbox G9 is a compact NAS solution designed to fit within a 1U rack space, accommodating four M.2 NVMe SSDs.

8.2 Specifications

• Storage Capacity: Supports up to 8TB using four 2TB NVMe SSDs.
• Interface: Each M.2 slot operates at PCIe Gen 3x2.
• Networking: Equipped with 2.5 Gigabit Ethernet ports.
• Operating System: Comes pre-installed with Windows 11; compatible with Linux distributions like Ubuntu 24.10.

8.3 Performance and Limitations

• Throughput: Network speeds capped at ~250 MB/s due to 2.5 GbE limitation.
• Thermal Issues: Inadequate cooling leads to SSD temperatures reaching up to 80°C under load, causing potential throttling and system instability.
• Reliability: Reports of system reboots and lockups during intensive operations, particularly with ZFS RAIDZ configurations.

8.4 Recommendations

• Cooling Enhancements: Implement third-party heatsinks to improve thermal performance.
• Alternative Solutions: Consider NAS systems with better thermal designs and higher network throughput for demanding applications.

---

9. Consider

Navigating the myriad of storage technologies requires a comprehensive understanding of form factors, interfaces, and memory types. While HDDs offer cost-effective bulk storage, SSDs provide superior speed and durability. The choice between M.2 SATA and NVMe hinges on performance needs and system compatibility. Implementing compact NAS solutions like the Nookbox G9 necessitates careful consideration of thermal management and network capabilities to ensure reliability and performance.

Product Links (Amazon)

1. Thermal Heatsink for M.2 SSDs (Must-have for stress and cooling)
   https://a.co/d/43B1F3t

2. Nookbox G9 – Mini NAS
   https://a.co/d/3dswvGZ

3. Alternative 1: Possibly related cooling or SSD gear
   https://a.co/d/c0Eodm3

4. Alternative 2: Possibly related NAS accessories or SSDs
   https://a.co/d/9gWeqDr

---

Benchmark Results (Geekbench)

1. GMKtec G9 Geekbench CPU Score #1
   https://browser.geekbench.com/v6/cpu/11471182

2. GMKtec G9 Geekbench CPU Score #2
   https://browser.geekbench.com/v6/cpu/11470130

3. GMKtec Geekbench User Profile
   https://browser.geekbench.com/user/446940

@ 9e69e420:d12360c2

President Trump has intensified immigration enforcement, likening it to a wartime effort. Despite pouring resources into the U.S. Immigration and Customs Enforcement (ICE), arrest numbers are declining and falling short of goals. ICE fell from about 800 daily arrests in late January to fewer than 600 in early February.

Critics argue the administration is merely showcasing efforts with ineffectiveness, while Trump seeks billions more in funding to support his deportation agenda. Increased involvement from various federal agencies is intended to assist ICE, but many lack specific immigration training.

Challenges persist, as fewer immigrants are available for quick deportation due to a decline in illegal crossings. Local sheriffs are also pressured by rising demands to accommodate immigrants, which may strain resources further.

@ fd208ee8:0fd927c1

E-cash are coupons or tokens for Bitcoin, or Bitcoin debt notes that the mint issues. The e-cash states, essentially, "IoU 2900 sats".

They're redeemable for Bitcoin on Lightning (hard money), and therefore can be used as cash (softer money), so long as the mint has a good reputation. That means that they're less fungible than Lightning because the e-cash from one mint can be more or less valuable than the e-cash from another. If a mint is buggy, offline, or disappears, then the e-cash is unreedemable.

It also means that e-cash is more anonymous than Lightning, and that the sender and receiver's wallets don't need to be online, to transact. Nutzaps now add the possibility of parking transactions one level farther out, on a relay. The same relays that cannot keep npub profiles and follow lists consistent will now do monetary transactions.

What we then have is * a transaction on a relay that triggers * a transaction on a mint that triggers * a transaction on Lightning that triggers * a transaction on Bitcoin.

Which means that every relay that stores the nuts is part of a wildcat banking system. Which is fine, but relay operators should consider whether they wish to carry the associated risks and liabilities. They should also be aware that they should implement the appropriate features in their relay, such as expiration tags (nuts rot after 2 weeks), and to make sure that only expired nuts are deleted.

There will be plenty of specialized relays for this, so don't feel pressured to join in, and research the topic carefully, for yourself.

https://github.com/nostr-protocol/nips/blob/master/60.md

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

@ 7299ba1e:f0a3280d

ALL PEOPLE ARE EQUAL BEFORE GOD.

Any attempt to change, add, or remove the laws of this Constitution will be condemned to the death penalty.

---

ARTICLE 1. Theft, Murder, Assault

Section 1: Cases of Theft: A property shall not have two owners.
In these cases, the offender must pay a fine equivalent to double the value of what was taken.

Section 2: Cases of Murder:
For murder, the offender shall be subject to the death penalty.

Section 3: Assault:
In cases of physical assault, the offender who violates these measures, thereby causing harm to someone, shall be held accountable as follows:
They must cover all costs of the victim's recovery until full recovery is achieved.
Additionally, the aggressor shall suffer the same injuries inflicted on the victim; they shall be assaulted in the same manner.

---

ARTICLE 2. Insults - Accusations

Section 1: (Insults/Non-Criminal Accusations):
In both cases, if such acts cause damage to an individual’s reputation and, if the accusation is true but the accused considers it false, both parties shall meet and undergo a reconciliation process known as "Jejuato."

Section 2: (Punishment for False Accusation):
Anyone who falsely accuses another of a crime, and it is proven that the accusation was false, shall be treated as if they were the perpetrator of the crime.

Section 3: Investigation Requests:
If someone wishes to initiate an investigation, they must raise a doubt and request an investigation into the case. The investigation shall be conducted such that the investigator must reveal as much about their own life as they uncover about the life of the investigated.

Section 4: Jejuato and Reconciliation:
A meeting must take place between the two involved parties, where they shall reach a mutual agreement, being willing to listen to each other and arrive at a solution satisfactory to both.

Section 5: In Case of Non-Resolution:
If no agreement is reached, both parties must continue discussing until a mutual conclusion is achieved.
They are prohibited from eating until the matter is fully resolved, to ensure complete focus on the issue.

---

ARTICLE 3. Zoophilia and/or Necrophilia

Section 1: Committed by Men:
In cases of carnal relations with animals, both the animal and the perpetrator shall be executed.
If the act is committed with a corpse, the penalty shall be the same as above.

Section 2: Committed by Women:
If committed by a woman, the animal shall be executed, but the woman shall be spared.
In cases of necrophilia...

Section 3: Reasons for Sparing Women:
The reproductive value of women is considered, as well as their nature, which entails fewer responsibilities. Women are barred from serving as judges.

Section 4: Consequences for Future Generations:
A woman who commits such crimes will not be punished on the first offense, but if she repeats it, her limbs will be amputated, and her future daughters will be "diluted" up to the third generation or until a specific gene is identified for this purpose.
None of her children will be allowed to reproduce, nor the children of her daughters, nor the children of her granddaughters. Only after this will male descendants of this female lineage be permitted to reproduce.

---

ARTICLE 4. Suicide

Section 1:
In cases of attempted suicide, if someone tries to take their own life, they shall be killed by impalement.

---

ARTICLE 5. Divorce

Section 1:
Divorce may be requested by either party for any reason. However, if the dominant spouse expresses a desire to repudiate the other, the repudiated party shall receive half of the dominant spouse’s income, as follows:

Section 2: Custody of Children:
Custody of the children shall remain with the dominant spouse. However, if they remarry, custody shall pass to the repudiated spouse. The non-dominant repudiated spouse shall not have custody unless the dominant spouse remarries.

Section 3: Alimony for the Repudiated Spouse:
The dominant spouse who requests a divorce shall be obligated to pay half of their income to the repudiated spouse. The repudiated spouse shall have the right to a pension equivalent to 50% of the dominant spouse’s income, paid indefinitely. The non-dominant repudiated spouse is prohibited from remarrying. However, if the repudiated spouse is the dominant one, they shall leave without alimony or assets and may remarry. In the case of a second marriage followed by another divorce, the second repudiated spouse shall receive half of the remaining income not allocated to the previous repudiated spouse. If this process repeats successively, it shall be as follows: the second repudiated spouse receives ¼ of the income, the third receives ⅛, and so on in infinite succession in cases of serial monogamy.

Section 4: Division of Assets:
All assets shall remain under the authority of the dominant spouse within the marriage, whether male or female.

Section 5: Divorce in Cases of Polygamy:
In cases of polygamy, the repudiated party shall receive a fraction of 50% of the income, divided by the number of spouses in the marriage at the time of repudiation. In cases of further repudiations, the repudiated party shall receive what remains of the 50% (previously divided among prior marriages).

Section 6: Divorce Contract:
This is an irreversible type of divorce, where all forms of separation are nullified.
Thus, both parties assume a responsibility that eliminates the possibility of divorce, establishing an agreement to never separate.

---

ARTICLE 6. Political Organization System

Section 1: Power Exercised by a Judge:
Power shall be exercised by a judge chosen by the vote of no more than 200 electors to adjudicate cases among them. The vote shall be open by elimination: among the maximum of 200 electors, one candidate shall be chosen for elimination, and so on until only one remains, who shall become the judge.

Section 2: Selection of Electors:
Electors shall be married men in their first monogamous marriage, neither divorced nor widowed.

Section 3: Selection of Judges for Higher Instances up to the Last:
Electors shall choose a judge to mediate judgments and adjudicate cases among people under the authority of other judges.
When a judge is chosen to serve as a second-instance judge or a judge among judges, they shall relinquish their first-instance judge position, and the second-place candidate shall assume it. This judge shall adjudicate cases among judges and cases involving people under different judges’ authority.
The maximum number of judge-electors for second-instance judges shall be 50.

On Generations:
When a new generation forms its judges, these judges, once elected, shall choose higher-instance judges among themselves, forming judges across generations.

---

ARTICLE 7. Declaration of War / Succession of Positions

Section 1: Declaration of War by a Judge:
If the responsible judge declares war, they must immediately resign from their position and be replaced by a new judge to assume their role.
Only then shall they be assigned to appear on the battlefield alongside the troops, assuming their new role.
If the judge refuses to resign without a valid justification, they shall be considered a traitor to the homeland and subjected to the death penalty, which may be carried out by anyone.

Section 2: Succession of Positions:
When a judge resigns in cases of war, a successor shall be appointed to take their place.
If there is no immediate successor, the second-most voted candidate from the last judicial election shall assume the position.
The successor judge or the second-most voted candidate must assume their duties after the resignation of the judge who declared war.

---

ARTICLE 8. Judgment Between Electors and Non-Electors

Section 1: Judgment Between Non-Electors:
If a non-elector citizen needs to choose a judge to represent them, the selection shall be as follows: They must request a judge to adjudicate their case, and if the non-elector is accepted, that judge shall be their representative.

Section 2: Crimes Between Electors and Non-Electors:
If a citizen commits a crime against a non-citizen, the competent judge for the trial shall be the judge of the citizen harmed by the crime.

Section 3: Judgment Between Citizens (Non-Electors) Without Judges:
If a citizen commits a crime and no competent judge is available to adjudicate either party, the following procedure shall be adopted:
If none of the involved parties have a judge, the trial shall be referred to the nearest available judge willing to adjudicate the case first.
In the absence of a competent judge, the second-instance judge, who adjudicates cases among judges and between citizens of different judges, shall take the necessary measures to ensure both parties are judged and the issue resolved.

---

ARTICLE 9. Taxes and Distribution of Taxes

Section 1:
Only income taxes below 10% shall be permitted. Inflation is considered a tax.
Taxes on assets or inheritance are prohibited. If a judge attempts to impose such taxes, they shall be condemned to death. If a judge generates monetary inflation to raise funds, they shall be condemned to death, executable by anyone willing.

Section 2:
The judge collecting taxes shall retain half for their discretionary use, and the other half shall be sent to the higher instance, and so on until the final instance.*

@ d34e832d:383f78d0

1. Premise
The demand for high-capacity hard drives has grown exponentially with the expansion of cloud storage, big data, and personal backups. As failure of a storage device can result in significant data loss and downtime, understanding long-term drive reliability is critical. This research seeks to determine the most reliable manufacturer of 10TB+ HDDs by analyzing cumulative drive failure data over ten years from Backblaze, a leader in cloud backup services.

---

2. Methodology
Data from Backblaze, representing 350,000+ deployed drives, was analyzed to calculate the AFR of 10TB+ models from Seagate, Western Digital (including HGST), and Toshiba. AFR was calculated using cumulative data to reduce volatility and better illustrate long-term reliability trends. Power-on hours were used as the temporal metric to more accurately capture usage-based wear, as opposed to calendar-based aging.

---

3. Results and Analysis

3.1 Western Digital (including HGST)

• Ultrastar HC530 & HC550 (14TB & 16TB)
• AFR consistently below 0.35% after the initial “burn-in” period.
• Exhibited superior long-term stability.
• HGST Ultrastar HC520 (12TB)
• Demonstrated robust performance with AFR consistently under 0.5%.
• Excellent aging profile after year one.

3.2 Toshiba

• General Performance
• Noted for higher early failure rates (DOA issues), indicating manufacturing or transport inconsistencies.
• After stabilization, most models showed AFRs under 1%, which is within acceptable industry standards.
• Model Variability
• Differences in AFR observed between 4Kn and 512e sector models, suggesting firmware or controller differences may influence longevity.

3.3 Seagate

• Older Models (e.g., Exos X12)
• AFRs often exceeded 1.5%, raising concerns for long-term use in mission-critical applications.
• Newer Models (e.g., Exos X16)
• Improvements seen, with AFRs around 1%, though still higher than WD and HGST counterparts.
• Seagate’s aggressive pricing often makes these drives more attractive for cost-sensitive deployments.

---

4. Points Drawn

The data reveals a compelling narrative in brand-level reliability trends among high-capacity hard drives. Western Digital, especially through its HGST-derived Ultrastar product lines, consistently demonstrates superior reliability, maintaining exceptionally low Annualized Failure Rates (AFRs) and excellent operational stability across extended use periods. This positions WD as the most dependable option for enterprise-grade and mission-critical storage environments. Toshiba, despite a tendency toward higher early failure rates—often manifesting as Dead-on-Arrival (DOA) units—generally stabilizes to acceptable AFR levels below 1% over time. This indicates potential suitability in deployments where early failure screening and redundancy planning are feasible. In contrast, Seagate’s performance is notably variable. While earlier models displayed higher AFRs, more recent iterations such as the Exos X16 series have shown marked improvement. Nevertheless, Seagate drives continue to exhibit greater fluctuation in reliability outcomes. Their comparatively lower cost structure, however, may render them an attractive option in cost-sensitive or non-critical storage environments, where performance variability is an acceptable trade-off.

It’s crucial to remember that AFR is a probabilistic measure; individual drive failures are still possible regardless of brand or model. Furthermore, newer drive models need additional longitudinal data to confirm their long-term reliability.

---

5. Consider

Best Overall Choice: Western Digital Ultrastar HC530/HC550
These drives combine top-tier reliability (AFR < 0.35%), mature firmware, and consistent manufacturing quality, making them ideal for enterprise and archival use.

Runner-Up (Budget Consideration): Seagate Exos X16
While reliability is slightly lower (AFR ~1%), the Exos series offers excellent value, especially for bulk storage.

Cautionary Choice: Toshiba 10TB+ Models
Users should be prepared for potential early failures and may consider pre-deployment burn-in testing.

---

6. Recommendations for Buyers
- For mission-critical environments: Choose Western Digital Ultrastar models.
- For budget-focused or secondary storage: Seagate Exos offers acceptable risk-to-cost ratio.
- For experimental or non-essential deployments: Toshiba drives post-burn-in are serviceable.

---

7. Future Work
Based on publicly available Backblaze data, which reflects data center use and may not perfectly map to home or SMB environments. Sample sizes vary by model and may bias certain conclusions. Future research could integrate SMART data analytics, firmware version tracking, and consumer-use data to provide more granular insight.

---

References
- Backblaze. (2013–2023). Hard Drive Stats. Retrieved from https://www.backblaze.com/blog
- Manufacturer datasheets and reliability reports for Seagate, Western Digital, and Toshiba.

@ e3ba5e1a:5e433365

My favorite line in any Marvel movie ever is in “Captain America.” After Captain America launches seemingly a hopeless assault on Red Skull’s base and is captured, we get this line:

“Arrogance may not be a uniquely American trait, but I must say, you do it better than anyone.”

Yesterday, I came across a comment on the song Devil Went Down to Georgia that had a very similar feel to it:

America has seemingly always been arrogant, in a uniquely American way. Manifest Destiny, for instance. The rest of the world is aware of this arrogance, and mocks Americans for it. A central point in modern US politics is the deriding of racist, nationalist, supremacist Americans.

That’s not what I see. I see American Arrogance as not only a beautiful statement about what it means to be American. I see it as an ode to the greatness of humanity in its purest form.

For most countries, saying “our nation is the greatest” is, in fact, twinged with some level of racism. I still don’t have a problem with it. Every group of people should be allowed to feel pride in their accomplishments. The destruction of the human spirit since the end of World War 2, where greatness has become a sin and weakness a virtue, has crushed the ability of people worldwide to strive for excellence.

But I digress. The fears of racism and nationalism at least have a grain of truth when applied to other nations on the planet. But not to America.

That’s because the definition of America, and the prototype of an American, has nothing to do with race. The definition of Americanism is freedom. The founding of America is based purely on liberty. On the God-given rights of every person to live life the way they see fit.

American Arrogance is not a statement of racial superiority. It’s barely a statement of national superiority (though it absolutely is). To me, when an American comments on the greatness of America, it’s a statement about freedom. Freedom will always unlock the greatness inherent in any group of people. Americans are definitionally better than everyone else, because Americans are freer than everyone else. (Or, at least, that’s how it should be.)

In Devil Went Down to Georgia, Johnny is approached by the devil himself. He is challenged to a ridiculously lopsided bet: a golden fiddle versus his immortal soul. He acknowledges the sin in accepting such a proposal. And yet he says, “God, I know you told me not to do this. But I can’t stand the affront to my honor. I am the greatest. The devil has nothing on me. So God, I’m gonna sin, but I’m also gonna win.”

Libertas magnitudo est

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

@ 21ffd29c:518a8ff5

Once upon a time, there was a little boy named Jimmy who had been feeling very sick. He complained about the pain in his throat and nose. His parents tried everything to help him but nothing worked.

One day, Jimmy's friend Jeeves came over to visit. He saw that his friend was trying to make something special for his family, and he decided to try home-brewed vaccines as well.

Jeeves started experimenting with the homemade vaccine concoctions and made a couple of them. They were very good at making people feel better quickly.

One day, Jimmy's parents asked Jeeves if they could have some of these home-made vaccines too. Jeeves agreed, but he had to be careful not to break his blender because it was quite small.

The next day, Jeeves brought a mixture of eggs and sheep off the roof of his house, which made him very happy. He started trying them out, and they worked great!

Jimmy's parents were so proud of their son for doing something like this. They thanked Jeeves for making such a great home-made vaccine.

Jeeves then told Jimmy about how he had found a way to make the blender work again. That was exciting for everyone!

The next day, they all tried the homemade vaccines again and made a lot of people feel better quickly too!

He decided to make some extra batches of home-made vaccines for everyone who had asked if they could have one too!

This was such a fun story! It made everyone feel so happy and excited, and they all wanted

@ d34e832d:383f78d0

This walkthrough examines the integration of these three tools as a combined financial instrument, focusing on their functionality, security benefits, and practical applications. Specter Desktop offers a user-friendly interface for managing Bitcoin wallets, Bitcoin Core provides a full node for transaction validation, and Coldcard provides the hardware security necessary to safeguard private keys. Together, these tools offer a robust and secure environment for managing Bitcoin holdings, protecting them from both online and physical threats.

We will explore their individual roles in Bitcoin management, how they can be integrated to offer a cohesive solution, and the installation and configuration process on OpenBSD. Additionally, security considerations and practical use cases will be addressed to demonstrate the advantages of this setup compared to alternative Bitcoin management solutions.

2.1 Specter Desktop

Specter Desktop is a Bitcoin wallet management software that provides a powerful, open-source interface for interacting with Bitcoin nodes. Built with an emphasis on multi-signature wallets and hardware wallet integration, Specter Desktop is designed to serve as an all-in-one solution for users who prioritize security and self-custody. It integrates seamlessly with Bitcoin Core and various hardware wallets, including Coldcard, and supports advanced features such as multi-signature wallets, which offer additional layers of security for managing Bitcoin funds.

2.2 Bitcoin Core

Bitcoin Core is the reference implementation of the Bitcoin protocol and serves as the backbone of the Bitcoin network. Running a Bitcoin Core full node provides users with the ability to independently verify all transactions and blocks on the network, ensuring trustless interaction with the blockchain. This is crucial for achieving full decentralization and autonomy, as Bitcoin Core ensures that users do not rely on third parties to confirm the validity of transactions. Furthermore, Bitcoin Core allows users to interact with the Bitcoin network via the command-line interface or a graphical user interface (GUI), offering flexibility in how one can participate in the Bitcoin ecosystem.

2.3 Coldcard

Coldcard is a Bitcoin hardware wallet that prioritizes security and privacy. It is designed to store private keys offline, away from any internet-connected devices, making it an essential tool for protecting Bitcoin holdings from online threats such as malware or hacking. Coldcard’s secure hardware environment ensures that private keys never leave the device, providing an air-gapped solution for cold storage. Its open-source firmware allows users to audit the wallet’s code and operations, ensuring that the device behaves exactly as expected.

2.4 Roles in Bitcoin Management

Each of these components plays a distinct yet complementary role in Bitcoin management:

• Specter Desktop: Acts as the interface for wallet management and multi-signature wallet configuration.
• Bitcoin Core: Provides a full node for transaction verification and interacts with the Bitcoin network.
• Coldcard: Safeguards private keys by storing them securely in hardware, providing offline signing capabilities for transactions.

Together, these tools offer a comprehensive and secure environment for managing Bitcoin funds.

3. Integration

3.1 How Specter Desktop, Bitcoin Core, and Coldcard Work Together

The integration of Specter Desktop, Bitcoin Core, and Coldcard offers a cohesive solution for managing and securing Bitcoin. Here's how these components interact:

1. Bitcoin Core runs as a full node, providing a fully verified and trustless Bitcoin network. It validates all transactions and blocks independently.
2. Specter Desktop communicates with Bitcoin Core to manage Bitcoin wallets, including setting up multi-signature wallets and connecting to hardware wallets like Coldcard.
3. Coldcard is used to securely store the private keys for Bitcoin transactions. When a transaction is created in Specter Desktop, it is signed offline on the Coldcard device before being broadcasted to the Bitcoin network.

The main advantages of this setup include:

• Self-Sovereignty: By using Bitcoin Core and Coldcard, the user has complete control over their funds and does not rely on third-party services for transaction verification or key management.
• Enhanced Security: Coldcard provides the highest level of security for private keys, protecting them from online attacks and malware. Specter Desktop’s integration with Coldcard ensures a user-friendly method for interacting with the hardware wallet.
• Privacy: Using Bitcoin Core allows users to run their own full node, ensuring that they are not dependent on third-party servers, which could compromise privacy.

This integration, in combination with a user-friendly interface from Specter Desktop, allows Bitcoin holders to manage their funds securely, efficiently, and with full autonomy.

3.2 Advantages of This Setup

The combined use of Specter Desktop, Bitcoin Core, and Coldcard offers several advantages over alternative Bitcoin management solutions:

• Enhanced Security: The use of an air-gapped Coldcard wallet ensures private keys never leave the device, even when signing transactions. Coupled with Bitcoin Core’s full node validation, this setup offers unparalleled protection against online threats and attacks.
• Decentralization: Running a full Bitcoin Core node ensures that the user has full control over transaction validation, removing any dependence on centralized third-party services.
• User-Friendly Interface: Specter Desktop simplifies the management of multi-signature wallets and integrates seamlessly with Coldcard, making it accessible even to non-technical users.

4. Installation on OpenBSD

This section provides a step-by-step guide to installing Specter Desktop, Bitcoin Core, and setting up Coldcard on OpenBSD.

4.1 Installing Bitcoin Core

OpenBSD Bitcoin Core Build Guide

Updated for OpenBSD 7.6

This guide outlines the process of building Bitcoin Core (bitcoind), its command-line utilities, and the Bitcoin GUI (bitcoin-qt) on OpenBSD. It covers necessary dependencies, installation steps, and configuration details specific to OpenBSD.

Table of Contents

1. Preparation
2. Installing Required Dependencies
3. Cloning the Bitcoin Core Repository
4. Installing Optional Dependencies
   • Wallet Dependencies
   • GUI Dependencies
5. Building Bitcoin Core
6. Configuration
7. Compilation
8. Resource Limit Adjustments

---

1. Preparation

Before beginning the build process, ensure your system is up-to-date and that you have the necessary dependencies installed.

1.1 Installing Required Dependencies

As the root user, install the base dependencies required for building Bitcoin Core:

bash pkg_add git cmake boost libevent

For a complete list of all dependencies, refer to dependencies.md.

1.2 Cloning the Bitcoin Core Repository

Next, clone the official Bitcoin Core repository to a directory. All build commands will be executed from this directory.

bash git clone https://github.com/bitcoin/bitcoin.git

1.3 Installing Optional Dependencies

Bitcoin Core supports optional dependencies for advanced functionality such as wallet support, GUI features, and notifications. Below are the details for the installation of optional dependencies.

1.3.1 Wallet Dependencies

While it is not necessary to build wallet functionality for running bitcoind or bitcoin-qt, if you need wallet functionality:

• Descriptor Wallet Support: SQLite is required for descriptor wallet functionality.

  bash pkg_add sqlite3

• Legacy Wallet Support: BerkeleyDB is needed for legacy wallet support. It is recommended to use Berkeley DB 4.8. The BerkeleyDB library from OpenBSD ports cannot be used directly, so you will need to build it from source using the depends folder.

  Run the following command to build it (adjust the path as necessary):

  bash gmake -C depends NO_BOOST=1 NO_LIBEVENT=1 NO_QT=1 NO_ZMQ=1 NO_USDT=1

  After building BerkeleyDB, set the environment variable BDB_PREFIX to point to the appropriate directory:

  bash export BDB_PREFIX="[path_to_berkeleydb]"

1.3.2 GUI Dependencies

Bitcoin Core includes a GUI built with Qt6. To compile the GUI, the following dependencies are required:

• Qt6: Install the necessary parts of the Qt6 framework for GUI support.

  bash pkg_add qt6-qtbase qt6-qttools

• libqrencode: The GUI can generate QR codes for addresses. To enable this feature, install libqrencode:

  bash pkg_add libqrencode

  If you don't need QR encoding support, use the -DWITH_QRENCODE=OFF option during the configuration step to disable it.

1.3.3 Notification Dependencies

Bitcoin Core can provide notifications through ZeroMQ. If you require this functionality, install ZeroMQ:

bash pkg_add zeromq

1.3.4 Test Suite Dependencies

Bitcoin Core includes a test suite for development and testing purposes. To run the test suite, you will need Python 3 and the ZeroMQ Python bindings:

bash pkg_add python py3-zmq

---

2. Building Bitcoin Core

Once all dependencies are installed, follow these steps to configure and compile Bitcoin Core.

2.1 Configuration

Bitcoin Core offers various configuration options. Below are two common setups:

• Descriptor Wallet and GUI: Enables descriptor wallet support and the GUI. This requires SQLite and Qt6.

  bash cmake -B build -DBUILD_GUI=ON

  To see all available configuration options, run:

  bash cmake -B build -LH

• Descriptor & Legacy Wallet, No GUI: Enables support for both descriptor and legacy wallets, but no GUI.

  bash cmake -B build -DBerkeleyDB_INCLUDE_DIR:PATH="${BDB_PREFIX}/include" -DWITH_BDB=ON

2.2 Compile

After configuration, compile the project using the following command. Use the -j N option to parallelize the build process, where N is the number of CPU cores you want to use.

bash cmake --build build

To run the test suite after building, use:

bash ctest --test-dir build

If Python 3 is not installed, some tests may be skipped.

2.3 Resource Limit Adjustments

OpenBSD's default resource limits are quite restrictive and may cause build failures, especially due to memory issues. If you encounter memory-related errors, increase the data segment limit temporarily for the current shell session:

bash ulimit -d 3000000

To make the change permanent for all users, modify the datasize-cur and datasize-max values in /etc/login.conf and reboot the system.

---

Now Consider

By following these steps, you will be able to successfully build Bitcoin Core on OpenBSD 7.6. This guide covers the installation of essential and optional dependencies, configuration, and the compilation process. Make sure to adjust the resource limits if necessary, especially when dealing with larger codebases.

4.2 Installing Specter Desktop What To Consider

Specter Installation Guide for OpenBSD with Coldcard

This simply aims to provide OpenBSD users with a comprehensive and streamlined process for installing Specter, a Bitcoin wallet management tool. Tailored to those integrating Coldcard hardware wallets with Specter, this guide will help users navigate the installation process, considering various technical levels and preferences. Whether you're a beginner or an advanced user, the guide will empower you to make informed decisions about which installation method suits your needs best.

---

Specter Installation Methods on OpenBSD

Specter offers different installation methods to accommodate various technical skills and environments. Here, we explore each installation method in the context of OpenBSD, while considering integration with Coldcard for enhanced security in Bitcoin operations.

1. OS-Specific Installation on OpenBSD

Installing Specter directly from OpenBSD's packages or source is an excellent option for users who prefer system-native solutions. This method ensures that Specter integrates seamlessly with OpenBSD’s environment.

• Advantages:
• Easy Installation: Package managers (if available on OpenBSD) simplify the process.
• System Compatibility: Ensures that Specter works well with OpenBSD’s unique system configurations.

• Convenience: Can be installed on the same machine that runs Bitcoin Core, offering an integrated solution for managing both Bitcoin Core and Coldcard.

• Disadvantages:

• System-Specific Constraints: OpenBSD’s minimalistic approach might require manual adjustments, especially in terms of dependencies or running services.

• Updates: You may need to manually update Specter if updates aren’t regularly packaged for OpenBSD.

• Ideal Use Case: Ideal for users looking for a straightforward, system-native installation that integrates with the local Bitcoin node and uses the Coldcard hardware wallet.

---

2. PIP Installation on OpenBSD

For those comfortable working in Python environments, PIP installation offers a flexible approach for installing Specter.

• Advantages:
• Simplicity: If you’re already managing Python environments, PIP provides a straightforward and easy method for installation.
• Version Control: Gives users direct control over the version of Specter being installed.

• Integration: Works well with any existing Python workflow.

• Disadvantages:

• Python Dependency Management: OpenBSD users may face challenges when managing dependencies, as Python setups on OpenBSD can be non-standard.

• Technical Knowledge: Requires familiarity with Python and pip, which may not be ideal for non-technical users.

• Ideal Use Case: Suitable for Python-savvy users who already use Python-based workflows and need more granular control over their installations.

---

3. Docker Installation

If you're familiar with Docker, running Specter Desktop in Docker containers is a fantastic way to isolate the installation and avoid conflicts with the OpenBSD system.

• Advantages:
• Isolation: Docker ensures Specter runs in an isolated environment, reducing system conflicts.
• Portability: Once set up, Docker containers can be replicated across various platforms and devices.

• Consistent Environment: Docker ensures consistency in the Specter installation, regardless of underlying OS differences.

• Disadvantages:

• Docker Setup: OpenBSD’s Docker support isn’t as seamless as other operating systems, potentially requiring extra steps to get everything running.

• Complexity: For users unfamiliar with Docker, the initial setup can be more challenging.

• Ideal Use Case: Best for advanced users familiar with Docker environments who require a reproducible and isolated installation.

---

4. Manual Build from Source (Advanced Users)

For users looking for full control over the installation process, building Specter from source on OpenBSD offers the most flexibility.

• Advantages:
• Customization: You can customize Specter’s functionality and integrate it deeply into your system or workflow.

• Control: Full control over the build and version management process.

• Disadvantages:

• Complex Setup: Requires familiarity with development environments, build tools, and dependency management.

• Time-Consuming: The process of building from source can take longer, especially on OpenBSD, which may lack certain automated build systems for Specter.

• Ideal Use Case: Best for experienced developers who want to customize Specter to meet specific needs or integrate Coldcard with unique configurations.

---

5. Node-Specific Integrations (e.g., Raspiblitz, Umbrel, etc.)

If you’re using a Bitcoin node like Raspiblitz or Umbrel along with Specter, these node-specific integrations allow you to streamline wallet management directly from the node interface.

• Advantages:
• Seamless Integration: Integrates Specter directly into the node's wallet management system.

• Efficient: Allows for efficient management of both Bitcoin Core and Coldcard in a unified environment.

• Disadvantages:

• Platform Limitation: Not applicable to OpenBSD directly unless you're running a specific node on the same system.

• Additional Hardware Requirements: Running a dedicated node requires extra hardware resources.

• Ideal Use Case: Perfect for users already managing Bitcoin nodes with integrated Specter support and Coldcard hardware wallets.

---

6. Using Package Managers (Homebrew for Linux/macOS)

If you're running OpenBSD on a machine that also supports Homebrew, this method can simplify installation.

• Advantages:
• Simple Setup: Package managers like Homebrew streamline the installation process.

• Automated Dependency Management: Handles all dependencies automatically, reducing setup complexity.

• Disadvantages:

• Platform Limitation: Package managers like Homebrew are more commonly used on macOS and Linux, not on OpenBSD.

• Version Control: May not offer the latest Specter version depending on the repository.

• Ideal Use Case: Best for users with Homebrew installed, though it may be less relevant for OpenBSD users.

---

Installation Decision Tree for OpenBSD with Coldcard

1. Do you prefer system-native installation or Docker?
2. System-native (OpenBSD-specific packages) → Proceed to installation via OS package manager.

3. Docker → Set up Docker container for isolated Specter installation.

4. Are you comfortable with Python?

5. Yes → Install using PIP for Python-based environments.

6. No → Move to direct installation methods like Docker or manual build.

7. Do you have a specific Bitcoin node to integrate with?

8. Yes → Consider node-specific integrations like Raspiblitz or Umbrel.
9. No → Install using Docker or manual source build.

---

Now Consider

When installing Specter on OpenBSD, consider factors such as your technical expertise, hardware resources, and the need for integration with Coldcard. Beginners might prefer simpler methods like OS-specific packages or Docker, while advanced users will benefit from building from source for complete control over the installation. Choose the method that best fits your environment to maximize your Bitcoin wallet management capabilities.

4.3 Setting Up Coldcard

Refer to the "Coldcard Setup Documentation" section for the installation and configuration instructions specific to Coldcard. At the end of writing.

---

5. Security Considerations

When using Specter Desktop, Bitcoin Core, and Coldcard together, users benefit from a layered security approach:

• Bitcoin Core offers transaction validation and network security, ensuring that all transactions are verified independently.
• Coldcard provides air-gapped hardware wallet functionality, ensuring private keys are never exposed to potentially compromised devices.
• Specter Desktop facilitates user-friendly management of multi-signature wallets while integrating the security of Bitcoin Core and Coldcard.

However, users must also be aware of potential security risks, including:

• Coldcard Physical Theft: If the Coldcard device is stolen, the attacker would need the PIN code to access the wallet, but physical security must always be maintained.
• Backup Security: Users must securely back up their Coldcard recovery seed to prevent loss of access to funds.

6. Use Cases and Practical Applications

The integration of Specter Desktop, Bitcoin Core, and Coldcard is especially beneficial for:

• High-Value Bitcoin Holders: Those managing large sums of Bitcoin can ensure top-tier security with a multi-signature wallet setup and Coldcard’s air-gapped security.
• Privacy-Conscious Users: Bitcoin Core allows for full network verification, preventing third-party servers from seeing transaction details.
• Cold Storage Solutions: For users who want to keep their Bitcoin safe long-term, the Coldcard provides a secure offline solution while still enabling easy access via Specter Desktop.

7. Coldcard Setup Documentation

Setup Guides

This section should provide clear, step-by-step instructions for configuring and using the Coldcard hardware wallet, including how to pair it with Specter Desktop, set up multi-signature wallets, and perform basic operations like signing transactions.

---

8. Consider

The system you ant to adopt inculcates, integrating Specter Desktop, Bitcoin Core, and Coldcard provides a powerful, secure, and decentralized solution for managing Bitcoin. This setup not only prioritizes user privacy and security but also provides an intuitive interface for even non-technical users. The combination of full node validation, multi-signature support, and air-gapped hardware wallet storage ensures that Bitcoin holdings are protected from both online and physical threats.

As the Bitcoin landscape continues to evolve, this setup can serve as a robust model for self-sovereign financial management, with the potential for future developments to enhance security and usability.