@ 681ec9c0:fe78b4e7

A refugee from Twitter said they lost 10,000 followers

My first thought was, did they die?

If they didn't follow you here then they weren't your followers

But on that platform did you manage to talk with anyone

Did you get an impression of them as a living feeling human being

Did you connect with them

And if you did will they find you here or will they be a fleeting moment

Life is like that sometimes

Pay no heed to the slot machine numbers

Cherish the fleeting moments

@ 681ec9c0:fe78b4e7

I was puzzled when Mike Masnick claimed that Bluesky is everything Jack wished for in a decentralized social network, being as it is highly centralized

I think the discrepancy comes down to different views of the role of decentralization encapsulated in this term, enshittification

"Even if most of the users of a decentralized system don’t know or care about the fact that it’s decentralized, the fact that the underlying protocol is that way and is set up such that others can build and provide services (algorithms, moderation services, interfaces, etc.) means that Bluesky itself has strong, built-in incentives to not enshittify the service.

In some ways, Bluesky is building in the natural antidote to the activist investors that so vexed Jack at Twitter. Bluesky can simply point out that going down the enshittification path of greater and greater user extraction/worsening service just opens up someone else to step in and provide a better competing service on the same protocol. Having it be on the same protocol removes the switching costs that centralized enshittified services rely on to keep users from leaving, allowing them to enshittify. The underlying protocol that Bluesky is built on is a kind of commitment device. The company (and, in large part, its CEO Jay) is going to face tremendous pressures to make Bluesky worse.

But by committing to an open protocol they’re building, it creates a world that makes it much harder to force the company down that path. That doesn’t mean there won’t still be difficult to impossible choices to make. Because there will be. But the protocol is still there."

https://www.techdirt.com/2024/05/13/bluesky-is-building-the-decentralized-social-media-jack-dorsey-wants-even-if-he-doesnt-realize-it/

And echoed by Bluesky CEO Jay Graber

"There will always be free options, and we can't enshittify the network with ads. This is where federation comes in. The fact that anyone can self-host and anyone can build on the software means that we'll never be able to degrade the user experience in a way where people want to leave."

https://web.archive.org/web/20240209161307/https://www.wired.com/story/bluesky-ceo-jay-graber-wont-enshittify-ads/

It all comes down to this

"the protocol is still there"

In this view of decentralization, being there is sufficient

Decentralization is this thing that can happen if needed

It's a safety valve operated by market forces

And where I think Jack and most of nostr would disagree is that market forces do not cater to the rights of individuals

Because one person being deplatformed is not a market demand

Especially for ATProto where decentralization is relatively expensive

To service deplatformed users would require building four servers, each one capable of ingesting the entire network: a Relay, a Labeller, an AppView and a Feed Generator

Decentralization by default is necessary for censorship resistance

Jack talked about censorship in the interview that formed the basis for Mike's article

"I know it's early, and Nostr is weird and hard to use, but if you truly believe in censorship resistance and free speech, you have to use the technologies that actually enable that, and defend your rights."

https://www.piratewires.com/p/interview-with-jack-dorsey-mike-solana

Mike's concerns over enshittification are highly valid

I would like to see Mike address Jack's concern for censorship resistance

I think that would help understanding

@ 681ec9c0:fe78b4e7

"I work for a Government I despise for ends I think criminal"

John Maynard Keynes

Politicians are assholes

That hasn't changed in 5,000 years

It's objectively true that Julian Assange was persecuted by multiple democratic governments

https://thedissenter.org/inside-the-assange-plea-deal-why-the-us-government-abruptly-ended-the-case/

The difference between democracy and not democracy is tens of thousands of Julian Assanges (Iran) and hundreds of thousands of Julian Assanges (Syria, North Korea)

The difference is a full stop

nostr:nevent1qqs857j7ge4daqk4frsy5md3l0e7qnxlx3fu2zld2gxacs999fp5tkspz9mhxue69uhkummnw3ezuamfdejj7q3qcpazafytvafazxkjn43zjfwtfzatfz508r54f6z6a3rf2ws8223qxpqqqqqqzxsdxpy

Someone challenged a human rights activist and former Venezuelan political prisoner to support freedom over shilling for democracy

Placing democracy and freedom in opposition can make perfect sense to someone who is living in a liberal democracy

It does not make any sense for someone who is living in Iran, Venezuela or North Korea

At this moment in time there are several hundred thousand people being forced to work in online scam centres generating tens of $ billions of revenue for organized crime

To gain freedom they must risk their lives to escape or their families pay a ransom

They are tortured if they don't meet targets

These centres are mainly located in Cambodia and Myanmar

They are in Cambodia because Cambodia is a one-party state

The Cambodian police, judiciary and government have been bought

And they are in Myanmar where regional military fiefdoms are financed by organized crime

https://bangkok.ohchr.org/wp-content/uploads/2023/08/ONLINE-SCAM-OPERATIONS-2582023.pdf

https://www.nytimes.com/interactive/2023/12/17/world/asia/myanmar-cyber-scam.html

Spreading liberal democracy reduces human trafficking

Spreading liberal democracy increases freedom of speech

In as far as human rights activists work with objective facts and the most oppressed peoples in the world, they will work to spread democracy

Expecting anything else is unrealistic

Presenting it as a choice will only go one way

But it needn't be a choice as we're all on the same side

It's in the interest of governments to split people into sides and get them to fight on Twitter

The self-sovereign tech movement is interesting as it cuts across all political contexts

It helps people in the most oppressed parts of the world as well as the freest

It's an escape hatch and a home for some of the nicest people on the planet

It has the shape of the future

But it didn't free Julian Assange

And it doesn't solve the problem of the thousands of Julian Assanges in Iran

It didn't transition Taiwan from the white terror to an open society

nostr:nevent1qqsqfc8qgsqd7gxcmw5zw3udg56utkcj0qnp9jxemj6eht9p4e2z8vgpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsygqn3qlypmqmr9q2v406wa4dt5ehv44xsanedpvc8zq53wthu4j4pupsgqqqqqqsffxa78

Although it may help in all those things

Human progress toward freedom is slow and faltering

It is also inexorable

That is our history

The tide will wash away the "Supreme Leaders" and the slavers and their mad dreams

And ultimately all governments

"Many forms of Government have been tried, and will be tried in this world of sin and woe. No one pretends that democracy is perfect or all-wise. Indeed it has been said that democracy is the worst form of Government except for all those other forms that have been tried from time to time..."

Winston Churchill

@ c230edd3:8ad4a712

Chef's notes

Wildly enough, this is delicious. It's sweet and savory.

(I copied this recipe off of a commercial cheese maker's site, just FYI)

I hadn't fully froze the ice cream when I took the picture shown. This is fresh out of the churner.

Details

• ⏲️ Prep time: 15 min
• 🍳 Cook time: 30 min
• 🍽️ Servings: 4

Ingredients

• 12 oz blue cheese
• 3 Tbsp lemon juice
• 1 c sugar
• 1 tsp salt
• 1 qt heavy cream
• 3/4 c chopped dark chocolate

Directions

1. Put the blue cheese, lemon juice, sugar, and salt into a bowl
2. Bring heavy cream to a boil, stirring occasionally
3. Pour heavy cream over the blue cheese mix and stir until melted
4. Pour into prepared ice cream maker, follow unit instructions
5. Add dark chocolate halfway through the churning cycle
6. Freeze until firm. Enjoy.

@ c230edd3:8ad4a712

Chef's notes

I found this recipe a couple years ago and have been addicted to it since. Its incredibly easy, and cheap to prep. Freeze the sausage in flat, single serving portions. That way it can be cooked from frozen for a fast, flavorful, and healthy lunch or dinner. I took inspiration from the video that contained this recipe, and almost always pan fry the frozen sausage with some baby broccoli. The steam cooks the broccoli and the fats from the sausage help it to sear, while infusing the vibrant flavors. Serve with some rice, if desired. I often use serrano peppers, due to limited produce availability. They work well for a little heat and nice flavor that is not overpowering.

Details

• ⏲️ Prep time: 25 min
• 🍳 Cook time: 15 min (only needed if cooking at time of prep)
• 🍽️ Servings: 10

Ingredients

• 4 lbs ground pork
• 12-15 cloves garlic, minced
• 6 Thai or Serrano peppers, rough chopped
• 1/4 c. lime juice
• 4 Tbsp fish sauce
• 1 Tbsp brown sugar
• 1/2 c. chopped cilantro

Directions

1. Mix all ingredients in a large bowl.
2. Portion and freeze, as desired.
3. Sautè frozen portions in hot frying pan, with broccoli or other fresh veggies.
4. Serve with rice or alone.

@ 00000001:b0c77eb9

مواقع التواصل الإجتماعي العامة هي التي تتحكم بك، تتحكم بك بفرض أجندتها وتجبرك على اتباعها وتحظر وتحذف كل ما يخالفها، وحرية التعبير تنحصر في أجندتها تلك!

وخوارزمياتها الخبيثة التي لا حاجة لها، تعرض لك مايريدون منك أن تراه وتحجب ما لا يريدونك أن تراه.

في نوستر انت المتحكم، انت الذي تحدد من تتابع و انت الذي تحدد المرحلات التي تنشر منشوراتك بها.

نوستر لامركزي، بمعنى عدم وجود سلطة تتحكم ببياناتك، بياناتك موجودة في المرحلات، ولا احد يستطيع حذفها او تعديلها او حظر ظهورها.

و هذا لا ينطبق فقط على مواقع التواصل الإجتماعي العامة، بل ينطبق أيضاً على الـfediverse، في الـfediverse انت لست حر، انت تتبع الخادم الذي تستخدمه ويستطيع هذا الخادم حظر ما لا يريد ظهوره لك، لأنك لا تتواصل مع بقية الخوادم بنفسك، بل خادمك من يقوم بذلك بالنيابة عنك.

وحتى إذا كنت تمتلك خادم في شبكة الـfediverse، إذا خالفت اجندة بقية الخوادم ونظرتهم عن حرية الرأي و التعبير سوف يندرج خادمك في القائمة السوداء fediblock ولن يتمكن خادمك من التواصل مع بقية خوادم الشبكة، ستكون محصوراً بالخوادم الأخرى المحظورة كخادمك، بالتالي انت في الشبكة الأخرى من الـfediverse!

نعم، يوجد شبكتان في الكون الفدرالي fediverse شبكة الصالحين التابعين للأجندة الغربية وشبكة الطالحين الذين لا يتبعون لها، إذا تم إدراج خادمك في قائمة fediblock سوف تذهب للشبكة الأخرى!

@ d34e832d:383f78d0

Operation

Central to this implementation is the utilization of Tails OS, a Debian-based live operating system designed for privacy and anonymity, alongside the Electrum Wallet, a lightweight Bitcoin wallet that provides a streamlined interface for secure Bitcoin transactions.

Additionally, the inclusion of advanced cryptographic verification mechanisms, such as QuickHash, serves to bolster integrity checks throughout the storage process. This multifaceted approach ensures a rigorous adherence to end-to-end operational security (OpSec) principles while simultaneously safeguarding user autonomy in the custody of digital assets.

Furthermore, the proposed methodology aligns seamlessly with contemporary cybersecurity paradigms, prioritizing characteristics such as deterministic builds—where software builds are derived from specific source code to eliminate variability—offline key generation processes designed to mitigate exposure to online threats, and the implementation of minimal attack surfaces aimed at reducing potential vectors for exploitation.

Ultimately, this sophisticated approach presents a methodical and secure paradigm for the custody of private keys, thereby catering to the exigencies of high-assurance Bitcoin storage requirements.

1. Cold Storage Refers To The offline Storage

Cold storage refers to the offline storage of private keys used to sign Bitcoin transactions, providing the highest level of protection against network-based threats. This paper outlines a verifiable method for constructing such a storage system using the following core principles:

• Air-gapped key generation
• Open-source software
• Deterministic cryptographic tools
• Manual integrity verification
• Offline transaction signing

The method prioritizes cryptographic security, software verifiability, and minimal hardware dependency.

---

2. Hardware and Software Requirements

2.1 Hardware

• One 64-bit computer (laptop/desktop)
• 1 x USB Flash Drive (≥8 GB, high-quality brand recommended)
• Paper and pen (for seed phrase)
• Optional: Printer (for xpub QR export)

2.2 Software Stack

• Tails OS (latest ISO, from tails.boum.org)
• Balena Etcher (to flash ISO)
• QuickHash GUI (for SHA-256 checksum validation)
• Electrum Wallet (bundled within Tails OS)

---

3. System Preparation and Software Verification

3.1 Image Verification

Prior to flashing the ISO, the integrity of the Tails OS image must be cryptographically validated. Using QuickHash:

plaintext SHA256 (tails-amd64-<version>.iso) = <expected_hash>

Compare the hash output with the official hash provided on the Tails OS website. This mitigates the risk of ISO tampering or supply chain compromise.

3.2 Flashing the OS

Balena Etcher is used to flash the ISO to a USB drive:

1. Insert USB drive.
2. Launch Balena Etcher.
3. Select the verified Tails ISO.
4. Flash to USB and safely eject.

---

4. Cold Wallet Generation Procedure

4.1 Boot Into Tails OS

• Restart the system and boot into BIOS/UEFI boot menu.
• Select the USB drive containing Tails OS.
• Configure network settings to disable all connectivity.

4.2 Create Wallet in Electrum (Cold)

• Open Electrum from the Tails application launcher.
• Select "Standard Wallet" → "Create a new seed".
• Choose SegWit for address type (for lower fees and modern compatibility).
• Write down the 12-word seed phrase on paper. Never store digitally.
• Confirm the seed.
• Set a strong password for wallet access.

---

5. Exporting the Master Public Key (xpub)

• Open Electrum > Wallet > Information
• Export the Master Public Key (MPK) for receiving-only use.
• Optionally generate QR code for cold-to-hot usage (wallet watching).

This allows real-time monitoring of incoming Bitcoin transactions without ever exposing private keys.

---

6. Transaction Workflow

6.1 Receiving Bitcoin (Cold to Hot)

1. Use the exported xpub in a watch-only wallet (desktop or mobile).
2. Generate addresses as needed.
3. Senders deposit Bitcoin to those addresses.

6.2 Spending Bitcoin (Hot Redeem Mode)

Important: This process temporarily compromises air-gap security.

1. Boot into Tails (or use Electrum in a clean Linux environment).
2. Import the 12-word seed phrase.
3. Create transaction offline.
4. Export signed transaction via QR code or USB.
5. Broadcast using an online device.

6.3 Recommended Alternative: PSBT

To avoid full wallet import: - Use Partially Signed Bitcoin Transactions (PSBT) protocol to sign offline. - Broadcast PSBT using Sparrow Wallet or Electrum online.

---

7. Security Considerations

| Threat | Mitigation | |-------|------------| | OS Compromise | Use Tails (ephemeral environment, RAM-only) | | Supply Chain Attack | Manual SHA256 verification | | Key Leakage | No network access during key generation | | Phishing/Clone Wallets | Verify Electrum’s signature (when updating) | | Physical Theft | Store paper seed in tamper-evident location |

---

8. Backup Strategy

• Store 12-word seed phrase in multiple secure physical locations.
• Do not photograph or digitize.
• For added entropy, use Shamir Secret Sharing (e.g., 2-of-3 backups).

---

9. Consider

Through the meticulous integration of verifiable software solutions, the execution of air-gapped key generation methodologies, and adherence to stringent operational protocols, users have the capacity to establish a Bitcoin cold storage wallet that embodies an elevated degree of cryptographic assurance.

This DIY system presents a zero-dependency alternative to conventional third-party custody solutions and consumer-grade hardware wallets.

Consequently, it empowers individuals with the ability to manage their Bitcoin assets while ensuring full trust minimization and maximizing their sovereign control over private keys and transaction integrity within the decentralized financial ecosystem..

10. References And Citations

Nakamoto, Satoshi. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
“Tails - The Amnesic Incognito Live System.” tails.boum.org, The Tor Project.
“Electrum Bitcoin Wallet.” electrum.org, 2025.
“QuickHash GUI.” quickhash-gui.org, 2025.
“Balena Etcher.” balena.io, 2025.
Bitcoin Core Developers. “Don’t Trust, Verify.” bitcoincore.org, 2025.

In Addition

🪙 SegWit vs. Legacy Bitcoin Wallets

⚖️ TL;DR Decision Chart

| If you... | Use SegWit | Use Legacy | |-----------|----------------|----------------| | Want lower fees | ✅ Yes | 🚫 No | | Send to/from old services | ⚠️ Maybe | ✅ Yes | | Care about long-term scaling | ✅ Yes | 🚫 No | | Need max compatibility | ⚠️ Mixed | ✅ Yes | | Run a modern wallet | ✅ Yes | 🚫 Legacy support fading | | Use cold storage often | ✅ Yes | ⚠️ Depends on wallet support | | Use Lightning Network | ✅ Required | 🚫 Not supported |

---

🔍 1. What Are We Comparing?

There are two major types of Bitcoin wallet address formats:

🏛️ Legacy (P2PKH)

• Format starts with: 1
• Example: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
• Oldest, most universally compatible
• Higher fees, larger transactions
• May lack support in newer tools and layer-2 solutions

🛰️ SegWit (P2WPKH)

• Formats start with:
• Nested SegWit (P2SH): 3...
• Native SegWit (bech32): bc1q...
• Introduced via Bitcoin Improvement Proposal (BIP) 141
• Smaller transaction sizes → lower fees
• Native support by most modern wallets

---

💸 2. Transaction Fees

SegWit = Cheaper.
- SegWit reduces the size of Bitcoin transactions in a block.
- This means you pay less per transaction.
- Example: A SegWit transaction might cost 40%–60% less in fees than a legacy one.

💡 Why?
Bitcoin charges fees per byte, not per amount.
SegWit removes certain data from the base transaction structure, which shrinks byte size.

---

🧰 3. Wallet & Service Compatibility

| Category | Legacy | SegWit (Nested / Native) | |----------|--------|---------------------------| | Old Exchanges | ✅ Full support | ⚠️ Partial | | Modern Exchanges | ✅ Yes | ✅ Yes | | Hardware Wallets (Trezor, Ledger) | ✅ Yes | ✅ Yes | | Mobile Wallets (Phoenix, BlueWallet) | ⚠️ Rare | ✅ Yes | | Lightning Support | 🚫 No | ✅ Native SegWit required |

🧠 Recommendation:

If you interact with older platforms or do cross-compatibility testing, you may want to: - Use nested SegWit (address starts with 3), which is backward compatible. - Avoid bech32-only wallets if your exchange doesn't support them (though rare in 2025).

---

🛡️ 4. Security and Reliability

Both formats are secure in terms of cryptographic strength.

However: - SegWit fixes a bug known as transaction malleability, which helps build protocols on top of Bitcoin (like the Lightning Network). - SegWit transactions are more standardized going forward.

💬 User takeaway:
For basic sending and receiving, both are equally secure. But for future-proofing, SegWit is the better bet.

---

🌐 5. Future-Proofing

Legacy wallets are gradually being phased out:

• Developers are focusing on SegWit and Taproot compatibility.
• Wallet providers are defaulting to SegWit addresses.
• Fee structures increasingly assume users have upgraded.

🚨 If you're using a Legacy wallet today, you're still safe. But: - Some services may stop supporting withdrawals to legacy addresses. - Your future upgrade path may be more complex.

---

🚀 6. Real-World Scenarios

🧊 Cold Storage User

• Use SegWit for low-fee UTXOs and efficient backup formats.
• Consider Native SegWit (bc1q) if supported by your hardware wallet.

👛 Mobile Daily User

• Use Native SegWit for cheaper everyday payments.
• Ideal if using Lightning apps — it's often mandatory.

🔄 Exchange Trader

• Check your exchange’s address type support.
• Consider nested SegWit (3...) if bridging old + new systems.

---

📜 7. Migration Tips

If you're moving from Legacy to SegWit:

1. Create a new SegWit wallet in your software/hardware wallet.
2. Send funds from your old Legacy wallet to the SegWit address.
3. Back up the new seed — never reuse the old one.
4. Watch out for fee rates and change address handling.

---

✅ Final User Recommendations

| Use Case | Address Type | |----------|--------------| | Long-term HODL | SegWit (bc1q) | | Maximum compatibility | SegWit (nested 3...) | | Fee-sensitive use | Native SegWit (bc1q) | | Lightning | Native SegWit (bc1q) | | Legacy systems only | Legacy (1...) – short-term only |

---

📚 Further Reading

• Nakamoto, Satoshi. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
• Bitcoin Core Developers. “Segregated Witness (Consensus Layer Change).” github.com/bitcoin, 2017.
• “Electrum Documentation: Wallet Types.” docs.electrum.org, 2024.
• “Bitcoin Wallet Compatibility.” bitcoin.org, 2025.
• Ledger Support. “SegWit vs Legacy Addresses.” ledger.com, 2024.

@ d34e832d:383f78d0

---

Goal

This analytical discourse delves into Jack Dorsey's recent utterances concerning Bitcoin, artificial intelligence, decentralized social networking platforms such as Nostr, and the burgeoning landscape of open-source cryptocurrency mining initiatives.

Dorsey's pronouncements escape the confines of isolated technological fascinations; rather, they elucidate a cohesive conceptual schema wherein Bitcoin transcends its conventional role as a mere store of value—akin to digital gold—and emerges as a foundational protocol intended for the construction of a decentralized, sovereign, and perpetually self-evolving internet ecosystem.

A thorough examination of Dorsey's confluence of Bitcoin with artificial intelligence advancements, adaptive learning paradigms, and integrated social systems reveals an assertion of Bitcoin's position as an entity that evolves beyond simple currency, evolving into a distinctly novel socio-technological organism characterized by its inherent ability to adapt and grow. His vigorous endorsement of native digital currency, open communication protocols, and decentralized infrastructural frameworks is posited here as a revolutionary paradigm—a conceptual

---

1. The Path

Jack Dorsey, co-founder of Twitter and Square (now Block), has emerged as one of the most compelling evangelists for a decentralized future. His ideas about Bitcoin go far beyond its role as a speculative asset or inflation hedge. In a recent interview, Dorsey ties together themes of open-source AI, peer-to-peer currency, decentralized media, and radical self-education, sketching a future in which Bitcoin is the lynchpin of an emerging technological and social ecosystem. This thesis reviews Dorsey’s statements and offers a critical framework to understand why his vision uniquely positions Bitcoin as the keystone of a post-institutional, digital world.

---

2. Bitcoin: The Native Currency of the Internet

“It’s the best current manifestation of a native internet currency.” — Jack Dorsey

Bitcoin's status as an open protocol with no central controlling authority echoes the original spirit of the internet: decentralized, borderless, and resilient. Dorsey's framing of Bitcoin not just as a payment system but as the "native money of the internet" is a profound conceptual leap. It suggests that just as HTTP became the standard for web documents, Bitcoin can become the monetary layer for the open web.

This framing bypasses traditional narratives of digital gold or institutional adoption and centers a P2P vision of global value transfer. Unlike central bank digital currencies or platform-based payment rails, Bitcoin is opt-in, permissionless, and censorship-resistant—qualities essential for sovereignty in the digital age.

---

3. Nostr and the Decentralization of Social Systems

Dorsey’s support for Nostr, an open protocol for decentralized social media, reflects a desire to restore user agency, protocol composability, and speech sovereignty. Nostr’s architecture parallels Bitcoin’s: open, extensible, and resilient to censorship.

Here, Bitcoin serves not just as money but as a network effect driver. When combined with Lightning and P2P tipping, Nostr becomes more than just a Twitter alternative—it evolves into a micropayment-native communication system, a living proof that Bitcoin can power an entire open-source social economy.

---

4. Open-Source AI and Cognitive Sovereignty

Dorsey's forecast that open-source AI will emerge as an alternative to proprietary systems aligns with his commitment to digital autonomy. If Bitcoin empowers financial sovereignty and Nostr enables communicative freedom, open-source AI can empower cognitive independence—freeing humanity from centralized algorithmic manipulation.

He draws a fascinating parallel between AI learning models and human learning itself, suggesting both can be self-directed, recursive, and radically decentralized. This resonates with the Bitcoin ethos: systems should evolve through transparent, open participation—not gatekeeping or institutional control.

---

5. Bitcoin Mining: Sovereignty at the Hardware Layer

Block’s initiative to create open-source mining hardware is a direct attempt to counter centralization in Bitcoin’s infrastructure. ASIC chip development and mining rig customization empower individuals and communities to secure the network directly.

This move reinforces Dorsey’s vision that true decentralization requires ownership at every layer, including hardware. It is a radical assertion of vertical sovereignty—from protocol to interface to silicon.

---

6. Learning as the Core Protocol

“The most compounding skill is learning itself.” — Jack Dorsey

Dorsey’s deepest insight is that the throughline connecting Bitcoin, AI, and Nostr is not technology—it’s learning. Bitcoin represents more than code; it’s a living experiment in voluntary consensus, a distributed educational system in cryptographic form.

Dorsey’s emphasis on meditation, intensive retreats, and self-guided exploration mirrors the trustless, sovereign nature of Bitcoin. Learning becomes the ultimate protocol: recursive, adaptive, and decentralized—mirroring AI models and Bitcoin nodes alike.

---

7. Critical Risks and Honest Reflections

Dorsey remains honest about Bitcoin’s current limitations:

• Accessibility: UX barriers for onboarding new users.
• Usability: Friction in everyday use.
• State-Level Adoption: Risks of co-optation as mere digital gold.

However, his caution enhances credibility. His focus remains on preserving Bitcoin as a P2P electronic cash system, not transforming it into another tool of institutional control.

---

8. Bitcoin as a Living System

What emerges from Dorsey's vision is not a product pitch, but a philosophical reorientation: Bitcoin, Nostr, and open AI are not discrete tools—they are living systems forming a new type of civilization stack.

They are not static infrastructures, but emergent grammars of human cooperation, facilitating value exchange, learning, and community formation in ways never possible before.

Bitcoin, in this view, is not merely stunningly original—it is civilizationally generative, offering not just monetary innovation but a path to software-upgraded humanity.

---

Works Cited and Tools Used

Dorsey, Jack. Interview on Bitcoin, AI, and Decentralization. April 2025.
Nakamoto, Satoshi. “Bitcoin: A Peer-to-Peer Electronic Cash System.” 2008.
Nostr Protocol. https://nostr.com.
Block, Inc. Bitcoin Mining Hardware Initiatives. 2024.
Obsidian Canvas. Decentralized Note-Taking and Networked Thinking. 2025.

Dorseys talk Is available here and is very potent and an important signal to all building in this space

@ d34e832d:383f78d0

Idea

Through the integration of Optical Character Recognition (OCR), Docker-based deployment, and secure remote access via Twin Gate, Paperless NGX empowers individuals and small organizations to digitize, organize, and retrieve documents with minimal friction. This research explores its technical infrastructure, real-world applications, and how such a system can redefine document archival practices for the digital age.

---

Agile, Remote-Accessible, and Searchable Document System

In a world of increasing digital interdependence, managing physical documents is becoming not only inefficient but also environmentally and logistically unsustainable. The demand for agile, remote-accessible, and searchable document systems has never been higher—especially for researchers, small businesses, and archival professionals. Paperless NGX, an open-source platform, addresses these needs by offering a streamlined, secure, and automated way to manage documents digitally.

This Idea explores how Paperless NGX facilitates the transition to a paperless workflow and proposes best practices for sustainable, scalable usage.

---

Paperless NGX: The Platform

Paperless NGX is an advanced fork of the original Paperless project, redesigned with modern containers, faster performance, and enhanced community contributions. Its core functions include:

• Text Extraction with OCR: Leveraging the ocrmypdf Python library, Paperless NGX can extract searchable text from scanned PDFs and images.
• Searchable Document Indexing: Full-text search allows users to locate documents not just by filename or metadata, but by actual content.
• Dockerized Setup: A ready-to-use Docker Compose environment simplifies deployment, including the use of setup scripts for Ubuntu-based servers.
• Modular Workflows: Custom triggers and automation rules allow for smart processing pipelines based on file tags, types, or email source.

---

Key Features and Technical Infrastructure

1. Installation and Deployment

The system runs in a containerized environment, making it highly portable and isolated. A typical installation involves: - Docker Compose with YAML configuration - Volume mapping for persistent storage - Optional integration with reverse proxies (e.g., Nginx) for HTTPS access

2. OCR and Indexing

Using ocrmypdf, scanned documents are processed into fully searchable PDFs. This function dramatically improves retrieval, especially for archived legal, medical, or historical records.

3. Secure Access via Twin Gate

To solve the challenge of secure remote access without exposing the network, Twin Gate acts as a zero-trust access proxy. It encrypts communication between the Paperless NGX server and the client, enabling access from anywhere without the need for traditional VPNs.

4. Email Integration and Ingestion

Paperless NGX can ingest attachments directly from configured email folders. This feature automates much of the document intake process, especially useful for receipts, invoices, and academic PDFs.

---

Sustainable Document Management Workflow

A practical paperless strategy requires not just tools, but repeatable processes. A sustainable workflow recommended by the Paperless NGX community includes:

1. Capture & Tagging
   All incoming documents are tagged with a default “inbox” tag for triage.
2. Physical Archive Correlation
   If the physical document is retained, assign it a serial number (e.g., ASN-001), which is matched digitally.
3. Curation & Tagging
   Apply relevant category and topic tags to improve searchability.
4. Archival Confirmation
   Remove the “inbox” tag once fully processed and categorized.

---

Backup and Resilience

Reliability is key to any archival system. Paperless NGX includes backup functionality via: - Cron job–scheduled Docker exports - Offsite and cloud backups using rsync or encrypted cloud drives - Restore mechanisms using documented CLI commands

This ensures document availability even in the event of hardware failure or data corruption.

---

Limitations and Considerations

While Paperless NGX is powerful, it comes with several caveats: - Technical Barrier to Entry: Requires basic Docker and Linux skills to install and maintain. - OCR Inaccuracy for Handwritten Texts: The OCR engine may struggle with cursive or handwritten documents. - Plugin and Community Dependency: Continuous support relies on active community contribution.

---

Consider

Paperless NGX emerges as a pragmatic and privacy-centric alternative to conventional cloud-based document management systems, effectively addressing the critical challenges of data security and user autonomy.

The implementation of advanced Optical Character Recognition (OCR) technology facilitates the indexing and searching of documents, significantly enhancing information retrieval efficiency.

Additionally, the platform offers secure remote access protocols that ensure data integrity while preserving the confidentiality of sensitive information during transmission.

Furthermore, its customizable workflow capabilities empower both individuals and organizations to precisely tailor their data management processes, thereby reclaiming sovereignty over their information ecosystems.

In an era increasingly characterized by a shift towards paperless methodologies, the significance of solutions such as Paperless NGX cannot be overstated; they play an instrumental role in engineering a future in which information remains not only accessible but also safeguarded and sustainably governed.

In Addition

To Further The Idea

This technical paper presents an optimized strategy for transforming an Intel NUC into a compact, power-efficient self-hosted server using Ubuntu. The setup emphasizes reliability, low energy consumption, and cost-effectiveness for personal or small business use. Services such as Paperless NGX, Nextcloud, Gitea, and Docker containers are examined for deployment. The paper details hardware selection, system installation, secure remote access, and best practices for performance and longevity.

---

1. Cloud sovereignty, Privacy, and Data Ownership

As cloud sovereignty, privacy, and data ownership become critical concerns, self-hosting is increasingly appealing. An Intel NUC (Next Unit of Computing) provides an ideal middle ground between Raspberry Pi boards and enterprise-grade servers—balancing performance, form factor, and power draw. With Ubuntu LTS and Docker, users can run a full suite of services with minimal overhead.

---

2. Hardware Overview

2.1 Recommended NUC Specifications:

| Component | Recommended Specs | |------------------|-----------------------------------------------------| | Model | Intel NUC 11/12 Pro (e.g., NUC11TNHi5, NUC12WSKi7) | | CPU | Intel Core i5 or i7 (11th/12th Gen) | | RAM | 16GB–32GB DDR4 (dual channel preferred) | | Storage | 512GB–2TB NVMe SSD (Samsung 980 Pro or similar) | | Network | Gigabit Ethernet + Optional Wi-Fi 6 | | Power Supply | 65W USB-C or barrel connector | | Cooling | Internal fan, well-ventilated location |

NUCs are also capable of dual-drive setups and support for Intel vPro for remote management on some models.

---

3. Operating System and Software Stack

3.1 Ubuntu Server LTS

• Version: Ubuntu Server 22.04 LTS
• Installation Method: Bootable USB (Rufus or Balena Etcher)
• Disk Partitioning: LVM with encryption recommended for full disk security
• Security:
• UFW (Uncomplicated Firewall)
• Fail2ban
• SSH hardened with key-only login

bash sudo apt update && sudo apt upgrade sudo ufw allow OpenSSH sudo ufw enable

---

4. Docker and System Services

Docker and Docker Compose streamline the deployment of isolated, reproducible environments.

4.1 Install Docker and Compose

bash sudo apt install docker.io docker-compose sudo systemctl enable docker

4.2 Common Services to Self-Host:

| Application | Description | Access Port | |--------------------|----------------------------------------|-------------| | Paperless NGX | Document archiving and OCR | 8000 | | Nextcloud | Personal cloud, contacts, calendar | 443 | | Gitea | Lightweight Git repository | 3000 | | Nginx Proxy Manager| SSL proxy for all services | 81, 443 | | Portainer | Docker container management GUI | 9000 | | Watchtower | Auto-update containers | - |

---

5. Network & Remote Access

5.1 Local IP & Static Assignment

• Set a static IP for consistent access (via router DHCP reservation or Netplan).

5.2 Access Options

• Local Only: VPN into local network (e.g., WireGuard, Tailscale)
• Remote Access:
• Reverse proxy via Nginx with Certbot for HTTPS
• Twin Gate or Tailscale for zero-trust remote access
• DNS via DuckDNS, Cloudflare

---

6. Performance Optimization

• Enable zram for compressed RAM swap
• Trim SSDs weekly with fstrim
• Use Docker volumes, not bind mounts for stability
• Set up unattended upgrades:

bash sudo apt install unattended-upgrades sudo dpkg-reconfigure --priority=low unattended-upgrades

---

7. Power and Environmental Considerations

• Idle Power Draw: ~7–12W (depending on configuration)
• UPS Recommended: e.g., APC Back-UPS 600VA
• Use BIOS Wake-on-LAN if remote booting is needed

---

8. Maintenance and Monitoring

• Monitoring: Glances, Netdata, or Prometheus + Grafana
• Backups:
• Use rsync to external drive or NAS
• Cloud backup options: rclone to Google Drive, S3
• Paperless NGX backups: docker compose exec -T web document-exporter ...

---

9. Consider

Running a personal server using an Intel NUC and Ubuntu offers a private, low-maintenance, and modular solution to digital infrastructure needs. It’s an ideal base for self-hosting services, offering superior control over data and strong security with the right setup. The NUC's small form factor and efficient power usage make it an optimal home server platform that scales well for many use cases.

@ d34e832d:383f78d0

Idea

By instituting a robust network of conceptual entities, referred to as 'Obsidian nodes'—which are effectively discrete, idea-centric notes—researchers are empowered to establish a resilient and non-linear archival framework for knowledge accumulation.

These nodes, intricately connected via hyperlinks and systematically organized through the graphical interface of the Obsidian Canvas, facilitate profound intellectual exploration and the synthesis of disparate domains of knowledge.

Consequently, this innovative workflow paradigm emphasizes semantic precision and the interconnectedness of ideas, diverging from conventional, source-centric information architectures prevalent in traditional academic practices.

---

Traditional research workflows often emphasize organizing notes by source, resulting in static, siloed knowledge that resists integration and insight. With the rise of personal knowledge management (PKM) tools like Obsidian, it becomes possible to structure information in a way that mirrors the dynamic and interconnected nature of human thought.

At the heart of this approach are Obsidian nodes—atomic, standalone notes representing single ideas, arguments, or claims. These nodes form the basis of a semantic research network, made visible and manageable via Obsidian’s graph view and Canvas feature. This thesis outlines how such a framework enhances understanding, supports creativity, and aligns with best practices in information architecture.

---

Obsidian Nodes: Atomic Units of Thought

An Obsidian node is a note crafted to encapsulate one meaningful concept or question. It is:

• Atomic: Contains only one idea, making it easier to link and reuse.
• Context-Independent: Designed to stand on its own, without requiring the original source for meaning.
• Networked: Linked to other Obsidian nodes through backlinks and tags.

This system draws on the principles of the Zettelkasten method, but adapts them to the modern, markdown-based environment of Obsidian.

Benefits of Node-Based Note-Taking

• Improved Retrieval: Ideas can be surfaced based on content relevance, not source origin.
• Cross-Disciplinary Insight: Linking between concepts across fields becomes intuitive.
• Sustainable Growth: Each new node adds value to the network without redundancy.

---

Graph View: Visualizing Connections

Obsidian’s graph view offers a macro-level overview of the knowledge graph, showing how nodes interrelate. This encourages serendipitous discovery and identifies central or orphaned concepts that need further development.

• Clusters emerge around major themes.
• Hubs represent foundational ideas.
• Bridges between nodes show interdisciplinary links.

The graph view isn’t just a map—it’s an evolving reflection of intellectual progress.

---

Canvas: Thinking Spatially with Digital Notes

Obsidian Canvas acts as a digital thinking space. Unlike the abstract graph view, Canvas allows for spatial arrangement of Obsidian nodes, images, and ideas. This supports visual reasoning, ideation, and project planning.

Use Cases of Canvas

• Synthesizing Ideas: Group related nodes in physical proximity.
• Outlining Arguments: Arrange claims into narrative or logic flows.
• Designing Research Papers: Lay out structure and integrate supporting points visually.

Canvas brings a tactile quality to digital thinking, enabling workflows similar to sticky notes, mind maps, or corkboard pinning—but with markdown-based power and extensibility.

---

Template and Workflow

To simplify creation and encourage consistency, Obsidian nodes are generated using a templater plugin. Each node typically includes:

```markdown

{{title}}

Tags: #topic #field
Linked Nodes: [[Related Node]]
Summary: A 1-2 sentence idea explanation.
Source: [[Source Note]]
Date Created: {{date}}
```

The Canvas workspace pulls these nodes as cards, allowing for arrangement, grouping, and visual tracing of arguments or research paths.

---

Discussion and Challenges

While this approach enhances creativity and research depth, challenges include:

• Initial Setup: Learning and configuring plugins like Templater, Dataview, and Canvas.
• Overlinking or Underlinking: Finding the right granularity in note-making takes practice.
• Scalability: As networks grow, maintaining structure and avoiding fragmentation becomes crucial.
• Team Collaboration: While Git can assist, Obsidian remains largely optimized for solo workflows.

---

Consider

Through the innovative employment of Obsidian's interconnected nodes and the Canvas feature, researchers are enabled to construct a meticulously engineered semantic architecture that reflects the intricate topology of their knowledge frameworks.

This paradigm shift facilitates a transformation of conventional note-taking, evolving this practice from a static, merely accumulative repository of information into a dynamic and adaptive cognitive ecosystem that actively engages with the user’s thought processes. With methodological rigor and a structured approach, Obsidian transcends its role as mere documentation software, evolving into both a secondary cognitive apparatus and a sophisticated digital writing infrastructure.

This dual functionality significantly empowers the long-term intellectual endeavors and creative pursuits of students, scholars, and lifelong learners, thereby enhancing their capacity for sustained engagement with complex ideas.

@ d34e832d:383f78d0

A Knowledge Management Framework for your Academic Writing

Idea Approach

The primary objective of this framework is to streamline and enhance the efficiency of several critical academic processes, namely the reading, annotation, synthesis, and writing stages inherent to doctoral studies.

By leveraging established best practices from various domains, including digital note-taking methodologies, sophisticated knowledge management techniques, and the scientifically-grounded principles of spaced repetition systems, this proposed workflow is adept at optimizing long-term retention of information, fostering the development of novel ideas, and facilitating the meticulous preparation of manuscripts. Furthermore, this integrated approach capitalizes on Zotero's robust annotation functionalities, harmoniously merged with Obsidian's Zettelkasten-inspired architecture, thereby enriching the depth and structural coherence of academic inquiry, ultimately leading to more impactful scholarly contributions.

Doctoral research demands a sophisticated approach to information management, critical thinking, and synthesis. Traditional systems of note-taking and bibliography management are often fragmented and inefficient, leading to cognitive overload and disorganized research outputs. This thesis proposes a workflow that leverages Zotero for reference management, Obsidian for networked note-taking, and Anki for spaced repetition learning—each component enhanced by a set of plugins, templates, and color-coded systems.

---

2. Literature Review and Context

2.1 Digital Research Workflows

Recent research in digital scholarship has highlighted the importance of structured knowledge environments. Tools like Roam Research, Obsidian, and Notion have gained traction among academics seeking flexibility and networked thinking. However, few workflows provide seamless interoperability between reference management, reading, and idea synthesis.

2.2 The Zettelkasten Method

Originally developed by sociologist Niklas Luhmann, the Zettelkasten ("slip-box") method emphasizes creating atomic notes—single ideas captured and linked through context. This approach fosters long-term idea development and is highly compatible with digital graph-based note systems like Obsidian.

---

3. Zotero Workflow: Structured Annotation and Tagging

Zotero serves as the foundational tool for ingesting and organizing academic materials. The built-in PDF reader is augmented through a color-coded annotation schema designed to categorize information efficiently:

• Red: Refuted or problematic claims requiring skepticism or clarification
• Yellow: Prominent claims, novel hypotheses, or insightful observations
• Green: Verified facts or claims that align with the research narrative
• Purple: Structural elements like chapter titles or section headers
• Blue: Inter-author references or connections to external ideas
• Pink: Unclear arguments, logical gaps, or questions for future inquiry
• Orange: Precise definitions and technical terminology

Annotations are accompanied by tags and notes in Zotero, allowing robust filtering and thematic grouping.

---

4. Obsidian Integration: Bridging Annotation and Synthesis

4.1 Plugin Architecture

Three key plugins optimize Obsidian’s role in the workflow:

• Zotero Integration (via obsidian-citation-plugin): Syncs annotated PDFs and metadata directly from Zotero
• Highlighter: Enables color-coded highlights in Obsidian, mirroring Zotero's scheme
• Templater: Automates formatting and consistency using Nunjucks templates

A custom keyboard shortcut (e.g., Ctrl+Shift+Z) is used to trigger the extraction of annotations into structured Obsidian notes.

4.2 Custom Templating

The templating system ensures imported notes include:

• Citation metadata (title, author, year, journal)
• Full-color annotations with comments and page references
• Persistent notes for long-term synthesis
• An embedded bibtex citation key for seamless referencing

---

5. Zettelkasten and Atomic Note Generation

Obsidian’s networked note system supports idea-centered knowledge development. Each note captures a singular, discrete idea—independent of the source material—facilitating:

• Thematic convergence across disciplines
• Independent recombination of ideas
• Emergence of new questions and hypotheses

A standard atomic note template includes: - Note ID (timestamp or semantic UID) - Topic statement - Linked references - Associated atomic notes (via backlinks)

The Graph View provides a visual map of conceptual relationships, allowing researchers to track the evolution of their arguments.

---

6. Canvas for Spatial Organization

Obsidian’s Canvas plugin is used to mimic physical research boards: - Notes are arranged spatially to represent conceptual clusters or chapter structures - Embedded visual content enhances memory retention and creative thought - Notes and cards can be grouped by theme, timeline, or argumentative flow

This supports both granular research and holistic thesis design.

---

7. Flashcard Integration with Anki

Key insights, definitions, and questions are exported from Obsidian to Anki, enabling spaced repetition of core content. This supports: - Preparation for comprehensive exams - Retention of complex theories and definitions - Active recall training during literature reviews

Flashcards are automatically generated using Obsidian-to-Anki bridges, with tagging synced to Obsidian topics.

---

8. Word Processor Integration and Writing Stage

Zotero’s Word plugin simplifies: - In-text citation - Automatic bibliography generation - Switching between citation styles (APA, Chicago, MLA, etc.)

Drafts in Obsidian are later exported into formal academic writing environments such as Microsoft Word or LaTeX editors for formatting and submission.

---

9. Discussion and Evaluation

The proposed workflow significantly reduces friction in managing large volumes of information and promotes deep engagement with source material. Its modular nature allows adaptation for various disciplines and writing styles. Potential limitations include: - Initial learning curve - Reliance on plugin maintenance - Challenges in team-based collaboration

Nonetheless, the ability to unify reading, note-taking, synthesis, and writing into a seamless ecosystem offers clear benefits in focus, productivity, and academic rigor.

---

10. Consider

This idea demonstrates that a well-structured digital workflow using Zotero and Obsidian can transform the PhD research process. It empowers researchers to move beyond passive reading into active knowledge creation, aligned with the long-term demands of scholarly writing. Future iterations could include AI-assisted summarization, collaborative graph spaces, and greater mobile integration.

9. Evaluation Of The Approach

While this workflow offers significant advantages in clarity, synthesis, and long-term idea development, several limitations must be acknowledged:

• Initial Learning Curve: New users may face a steep learning curve when setting up and mastering the integrated use of Zotero, Obsidian, and their associated plugins. Understanding markdown syntax, customizing templates in Templater, and configuring citation keys all require upfront time investment. However, this learning period can be offset by the long-term gains in productivity and mental clarity.

• Plugin Ecosystem Volatility: Since both Obsidian and many of its key plugins are maintained by open-source communities or individual developers, updates can occasionally break workflows or require manual adjustments.

• Interoperability Challenges: Synchronizing metadata, highlights, and notes between systems (especially on multiple devices or operating systems) may present issues if not managed carefully. This includes Zotero’s Better BibTeX keys, Obsidian sync, and Anki integration.

• Limited Collaborative Features: This workflow is optimized for individual use. Real-time collaboration on notes or shared reference libraries may require alternative platforms or additional tooling.

Despite these constraints, the workflow remains highly adaptable and has proven effective across disciplines for researchers aiming to build a durable intellectual infrastructure over the course of a PhD.

9. Evaluation Of The Approach

While the Zotero–Obsidian workflow dramatically improves research organization and long-term knowledge retention, several caveats must be considered:

• Initial Learning Curve: Mastery of this workflow requires technical setup and familiarity with markdown, citation keys, and plugin configuration. While challenging at first, the learning effort is front-loaded and pays off in efficiency over time.

• Reliance on Plugin Maintenance: A key risk of this system is its dependence on community-maintained plugins. Tools like Zotero Integration, Templater, and Highlighter are not officially supported by Obsidian or Zotero core teams. This means updates or changes to the Obsidian API or plugin repository may break functionality or introduce bugs. Active plugin support is crucial to the system’s longevity.

• Interoperability and Syncing Issues: Managing synchronization across Zotero, Obsidian, and Anki—especially across multiple devices—can lead to inconsistencies or data loss without careful setup. Users should ensure robust syncing solutions (e.g. Obsidian Sync, Zotero WebDAV, or GitHub backup).

• Limited Collaboration Capabilities: This setup is designed for solo research workflows. Collaborative features (such as shared note-taking or group annotations) are limited and may require alternate solutions like Notion, Google Docs, or Overleaf when working in teams.

The integration of Zotero with Obsidian presents a notable advantage for individual researchers, exhibiting substantial efficiency in literature management and personal knowledge organization through its unique workflows. However, this model demonstrates significant deficiencies when evaluated in the context of collaborative research dynamics.

Specifically, while Zotero facilitates the creation and management of shared libraries, allowing for the aggregation of sources and references among users, Obsidian is fundamentally limited by its lack of intrinsic support for synchronous collaborative editing functionalities, thereby precluding simultaneous contributions from multiple users in real time. Although the application of version control systems such as Git has the potential to address this limitation, enabling a structured mechanism for tracking changes and managing contributions, the inherent complexity of such systems may pose a barrier to usability for team members who lack familiarity or comfort with version control protocols.

Furthermore, the nuances of color-coded annotation systems and bespoke personal note taxonomies utilized by individual researchers may present interoperability challenges when applied in a group setting, as these systems require rigorously defined conventions to ensure consistency and clarity in cross-collaborator communication and understanding. Thus, researchers should be cognizant of the challenges inherent in adapting tools designed for solitary workflows to the multifaceted requirements of collaborative research initiatives.

@ d34e832d:383f78d0

1. The Ledger or Physical USD?

Bitcoin embodies a paradigmatic transformation in the foundational constructs of trust, ownership, and value preservation within the context of a digital economy. In stark contrast to conventional financial infrastructures that are predicated on centralized regulatory frameworks, Bitcoin operationalizes an intricate interplay of cryptographic techniques, consensus-driven algorithms, and incentivization structures to engender a decentralized and censorship-resistant paradigm for the transfer and safeguarding of digital assets. This conceptual framework elucidates the pivotal mechanisms underpinning Bitcoin's functional architecture, encompassing its distributed ledger technology (DLT) structure, robust security protocols, consensus algorithms such as Proof of Work (PoW), the intricacies of its monetary policy defined by the halving events and limited supply, as well as the broader implications these components have on stakeholder engagement and user agency.

2. The Core Functionality of Bitcoin

At its core, Bitcoin is a public ledger that records ownership and transfers of value. This ledger—called the blockchain—is maintained and verified by thousands of decentralized nodes across the globe.

2.1 Public Ledger

All Bitcoin transactions are stored in a transparent, append-only ledger. Each transaction includes: - A reference to prior ownership (input) - A transfer of value to a new owner (output) - A digital signature proving authorization

2.2 Ownership via Digital Signatures

Bitcoin uses asymmetric cryptography: - A private key is known only to the owner and is used to sign transactions. - A public key (or address) is used by the network to verify the authenticity of the transaction.

This system ensures that only the rightful owner can spend bitcoins, and that all network participants can independently verify that the transaction is valid.

---

3. Decentralization and Ledger Synchronization

Unlike traditional banking systems, which rely on a central institution, Bitcoin’s ledger is decentralized: - Every node keeps a copy of the blockchain. - No single party controls the system. - Updates to the ledger occur only through network consensus.

This decentralization ensures fault tolerance, censorship resistance, and transparency.

---

4. Preventing Double Spending

One of Bitcoin’s most critical innovations is solving the double-spending problem without a central authority.

4.1 Balance Validation

Before a transaction is accepted, nodes verify: - The digital signature is valid. - The input has not already been spent. - The sender has sufficient balance.

This is made possible by referencing previous transactions and ensuring the inputs match the unspent transaction outputs (UTXOs).

---

5. Blockchain and Proof-of-Work

To ensure consistency across the distributed network, Bitcoin uses a blockchain—a sequential chain of blocks containing batches of verified transactions.

5.1 Mining and Proof-of-Work

Adding a new block requires solving a cryptographic puzzle, known as Proof-of-Work (PoW): - The puzzle involves finding a hash value that meets network-defined difficulty. - This process requires computational power, which deters tampering. - Once a block is validated, it is propagated across the network.

5.2 Block Rewards and Incentives

Miners are incentivized to participate by: - Block rewards: New bitcoins issued with each block (initially 50 BTC, halved every ~4 years). - Transaction fees: Paid by users to prioritize their transactions.

---

6. Network Consensus and Security

Bitcoin relies on Nakamoto Consensus, which prioritizes the longest chain—the one with the most accumulated proof-of-work.

• In case of competing chains (forks), the network chooses the chain with the most computational effort.
• This mechanism makes rewriting history or creating fraudulent blocks extremely difficult, as it would require control of over 50% of the network's total hash power.

---

7. Transaction Throughput and Fees

Bitcoin’s average block time is 10 minutes, and each block can contain ~1MB of data, resulting in ~3–7 transactions per second.

• During periods of high demand, users compete by offering higher transaction fees to get included faster.
• Solutions like Lightning Network aim to scale transaction speed and lower costs by processing payments off-chain.

---

8. Monetary Policy and Scarcity

Bitcoin enforces a fixed supply cap of 21 million coins, making it deflationary by design.

• This limited supply contrasts with fiat currencies, which can be printed at will by central banks.
• The controlled issuance schedule and halving events contribute to Bitcoin’s store-of-value narrative, similar to digital gold.

---

9. Consider

Bitcoin integrates advanced cryptographic methodologies, including public-private key pairings and hashing algorithms, to establish a formidable framework of security that underpins its operation as a digital currency. The economic incentives are meticulously structured through mechanisms such as mining rewards and transaction fees, which not only incentivize network participation but also regulate the supply of Bitcoin through a halving schedule intrinsic to its decentralized protocol. This architecture manifests a paradigm wherein individual users can autonomously oversee their financial assets, authenticate transactions through a rigorously constructed consensus algorithm, specifically the Proof of Work mechanism, and engage with a borderless financial ecosystem devoid of traditional intermediaries such as banks. Despite the notable challenges pertaining to transaction throughput scalability and a complex regulatory landscape that intermittently threatens its proliferation, Bitcoin steadfastly persists as an archetype of decentralized trust, heralding a transformative shift in financial paradigms within the contemporary digital milieu.

---

10. References

• Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
• Antonopoulos, A. M. (2017). Mastering Bitcoin: Unlocking Digital Cryptocurrencies.
• Bitcoin.org. (n.d.). How Bitcoin Works

@ d34e832d:383f78d0

WebSocket communication is integral to modern real-time web applications, powering everything from chat apps and online gaming to collaborative editing tools and live dashboards. However, its persistent and event-driven nature introduces unique debugging challenges. Traditional browser developer tools provide limited insight into WebSocket message flows, especially in complex, asynchronous applications.

This thesis evaluates the use of Chrome-based browser extensions—specifically those designed to enhance WebSocket debugging—and explores how visual event tracing improves developer experience (DX). By profiling real-world applications and comparing built-in tools with popular WebSocket DevTools extensions, we analyze the impact of visual feedback, message inspection, and timeline tracing on debugging efficiency, code quality, and development speed.

The Idea

As front-end development evolves, WebSockets have become a foundational technology for building reactive user experiences. Debugging WebSocket behavior, however, remains a cumbersome task. Chrome DevTools offers a basic view of WebSocket frames, but lacks features such as message categorization, event correlation, or contextual logging. Developers often resort to console.log and custom logging systems, increasing friction and reducing productivity.

This research investigates how browser extensions designed for WebSocket inspection—such as Smart WebSocket Client, WebSocket King Client, and WSDebugger—can enhance debugging workflows. We focus on features that provide visual structure to communication patterns, simplify message replay, and allow for real-time monitoring of state transitions.

Related Work

Chrome DevTools

While Chrome DevTools supports WebSocket inspection under the Network > Frames tab, its utility is limited: - Messages are displayed in a flat, unstructured stream. - No built-in timeline or replay mechanism. - Filtering and contextual debugging features are minimal.

WebSocket-Specific Extensions

Numerous browser extensions aim to fill this gap: - Smart WebSocket Client: Allows custom message sending, frame inspection, and saved session reuse. - WSDebugger: Offers structured logging and visualization of message flows. - WebSocket Monitor: Enables real-time monitoring of multiple connections with UI overlays.

Methodology

Tools Evaluated:

• Chrome DevTools (baseline)
• Smart WebSocket Client
• WSDebugger
• WebSocket King Client

Evaluation Criteria:

• Real-time message monitoring
• UI clarity and UX consistency
• Support for message replay and editing
• Message categorization and filtering
• Timeline-based visualization

Test Applications:

• A collaborative markdown editor
• A multiplayer drawing game (WebSocket over Node.js)
• A lightweight financial dashboard (stock ticker)

Findings

1. Enhanced Visibility

Extensions provide structured visual representations of WebSocket communication: - Grouped messages by type (e.g., chat, system, control) - Color-coded frames for quick scanning - Collapsible and expandable message trees

2. Real-Time Inspection and Replay

• Replaying previous messages with altered payloads accelerates bug reproduction.
• Message history can be annotated, aiding team collaboration during debugging.

3. Timeline-Based Analysis

• Extensions with timeline views help identify latency issues, bottlenecks, and inconsistent message pacing.
• Developers can correlate message sequences with UI events more intuitively.

4. Improved Debugging Flow

• Developers report reduced context-switching between source code and devtools.
• Some extensions allow breakpoints or watchers on WebSocket events, mimicking JavaScript debugging.

Consider

Visual debugging extensions represent a key advancement in tooling for real-time application development. By extending Chrome DevTools with features tailored for WebSocket tracing, developers gain actionable insights, faster debugging cycles, and a better understanding of application behavior. Future work should explore native integration of timeline and message tagging features into standard browser DevTools.

Developer Experience and Limitations

Visual tools significantly enhance the developer experience (DX) by reducing friction and offering cognitive support during debugging. Rather than parsing raw JSON blobs manually or tracing asynchronous behavior through logs, developers can rely on intuitive UI affordances such as real-time visualizations, message filtering, and replay features.

However, some limitations remain:

• Lack of binary frame support: Many extensions focus on text-based payloads and may not correctly parse or display binary frames.
• Non-standard encoding issues: Applications using custom serialization formats (e.g., Protocol Buffers, MsgPack) require external decoding tools or browser instrumentation.
• Extension compatibility: Some extensions may conflict with Content Security Policies (CSP) or have limited functionality when debugging production sites served over HTTPS.
• Performance overhead: Real-time visualization and logging can add browser CPU/memory overhead, particularly in high-frequency WebSocket environments.

Despite these drawbacks, the overall impact on debugging efficiency and developer comprehension remains highly positive.

Developer Experience and Limitations

Visual tools significantly enhance the developer experience (DX) by reducing friction and offering cognitive support during debugging. Rather than parsing raw JSON blobs manually or tracing asynchronous behavior through logs, developers can rely on intuitive UI affordances such as live message streams, structured views, and interactive inspection of frames.

However, some limitations exist:

• Security restrictions: Content Security Policy (CSP) and Cross-Origin Resource Sharing (CORS) can restrict browser extensions from accessing WebSocket frames in production environments.
• Binary and custom formats: Extensions may not handle binary frames or non-standard encodings (e.g., Protocol Buffers) without additional tooling.
• Limited protocol awareness: Generic tools may not fully interpret application-specific semantics, requiring context from the developer.
• Performance trade-offs: Logging and rendering large volumes of data can cause UI lag, especially in high-throughput WebSocket apps.

Despite these constraints, DevTools extensions continue to offer valuable insight during development and testing stages.

Applying this analysis to relays in the Nostr protocol surfaces some fascinating implications about traffic analysis, developer tooling, and privacy risks, even when data is cryptographically signed. Here's how the concepts relate:

---

🧠 What This Means for Nostr Relays

1. Traffic Analysis Still Applies

Even though Nostr events are cryptographically signed and, optionally, encrypted (e.g., DMs), relay communication is over plaintext WebSockets or WSS (WebSocket Secure). This means:

• IP addresses, packet size, and timing patterns are all visible to anyone on-path (e.g., ISPs, malicious actors).
• Client behavior can be inferred: Is someone posting, reading, or just idling?
• Frequent "kind" values (like kind:1 for notes or kind:4 for encrypted DMs) produce recognizable traffic fingerprints.

🔍 Example:

A pattern like: - client → relay: small frame at intervals of 30s - relay → client: burst of medium frames …could suggest someone is polling for new posts or using a chat app built on Nostr.

---

2. DevTools for Nostr Client Devs

For client developers (e.g., building on top of nostr-tools), browser DevTools and WebSocket inspection make debugging much easier:

• You can trace real-time Nostr events without writing logging logic.
• You can verify frame integrity, event flow, and relay responses instantly.
• However, DevTools have limits when Nostr apps use:
• Binary payloads (e.g., zlib-compressed events)
• Custom encodings or protocol adaptations (e.g., for mobile)

---

3. Fingerprinting Relays and Clients

• Each relay has its own behavior: how fast it responds, whether it sends OKs, how it deals with malformed events.
• These can be fingerprinted by adversaries to identify which software is being used (e.g., nostr-rs-relay, strfry, etc.).
• Similarly, client apps often emit predictable REQ, EVENT, CLOSE sequences that can be fingerprinted even over WSS.

---

4. Privacy Risks

Even if DMs are encrypted: - Message size and timing can hint at contents ("user is typing", long vs. short message, emoji burst, etc.) - Public relays might correlate patterns across multiple clients—even without payload access. - Side-channel analysis becomes viable against high-value targets.

---

5. Mitigation Strategies in Nostr

Borrowing from TLS and WebSocket security best practices:

| Strategy | Application to Nostr | |-----------------------------|----------------------------------------------------| | Padding messages | Normalize EVENT size, especially for DMs | | Batching requests | Send multiple REQ subscriptions in one frame | | Randomize connection times | Avoid predictable connection schedules | | Use private relays / Tor| Obfuscate source IP and reduce metadata exposure | | Connection reuse | Avoid per-event relay opens, use persistent WSS |

---

TL;DR for Builders

If you're building on Nostr and care about privacy, WebSocket metadata is a leak. The payload isn't the only thing that matters. Be mindful of event timing, size, and structure, even over encrypted channels.

@ 6e64b83c:94102ee8

How to Run Your Own Nostr Relay on Android with Cloudflare Domain

Prerequisites

1. Install Citrine on your Android device:
2. Visit https://github.com/greenart7c3/Citrine/releases
3. Download the latest release using:
   • zap.store
   • Obtainium
   • F-Droid
   • Or download the APK directly

4. Note: You may need to enable "Install from Unknown Sources" in your Android settings

5. Domain Requirements:

6. Purchase a domain if you don't have one

7. Transfer your domain to Cloudflare if it's not already there (for free SSL certificates and cloudflared support)

8. Tools to use:

9. nak (the nostr army knife):
   • Download from https://github.com/fiatjaf/nak/releases
   • Installation steps:

   • For Linux/macOS: ```bash # Download the appropriate version for your system wget https://github.com/fiatjaf/nak/releases/latest/download/nak-linux-amd64 # for Linux # or wget https://github.com/fiatjaf/nak/releases/latest/download/nak-darwin-amd64 # for macOS

     # Make it executable chmod +x nak-*

     # Move to a directory in your PATH sudo mv nak-* /usr/local/bin/nak - For Windows:batch # Download the Windows version curl -L -o nak.exe https://github.com/fiatjaf/nak/releases/latest/download/nak-windows-amd64.exe

     # Move to a directory in your PATH (e.g., C:\Windows) move nak.exe C:\Windows\nak.exe - Verify installation:bash nak --version ```

Setting Up Citrine

1. Open the Citrine app
2. Start the server
3. You'll see it running on ws://127.0.0.1:4869 (local network only)
4. Go to settings and paste your npub into "Accept events signed by" inbox and press the + button. This prevents others from publishing events to your personal relay.

Installing Required Tools

1. Install Termux from Google Play Store
2. Open Termux and run:

bash pkg update && pkg install wget wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-arm64.deb dpkg -i cloudflared-linux-arm64.deb

Cloudflare Authentication

1. Run the authentication command: bash cloudflared tunnel login
2. Follow the instructions:
3. Copy the provided URL to your browser
4. Log in to your Cloudflare account
5. If the URL expires, copy it again after logging in

Creating the Tunnel

1. Create a new tunnel: bash cloudflared tunnel create <TUNNEL_NAME>
2. Choose any name you prefer for your tunnel

3. Copy the tunnel ID after creating the tunnel

4. Create and configure the tunnel config: bash touch ~/.cloudflared/config.yml nano ~/.cloudflared/config.yml

5. Add this configuration (replace the placeholders with your values): ```yaml tunnel: credentials-file: /data/data/com.termux/files/home/.cloudflared/.json ingress:

6. hostname: nostr.yourdomain.com service: ws://localhost:4869
7. service: http_status:404 ```
8. Note: In nano editor:
   • CTRL+O and Enter to save
   • CTRL+X to exit

9. Note: Check the credentials file path in the logs

10. Validate your configuration: bash cloudflared tunnel validate

11. Start the tunnel: bash cloudflared tunnel run my-relay

Preventing Android from Killing the Tunnel

Run these commands to maintain tunnel stability: bash date && apt install termux-tools && termux-setup-storage && termux-wake-lock echo "nameserver 1.1.1.1" > $PREFIX/etc/resolv.conf

Tip: You can open multiple Termux sessions by swiping from the left edge of the screen while keeping your tunnel process running.

Updating Your Outbox Model Relays

Once your relay is running and accessible via your domain, you'll want to update your relay list in the Nostr network. This ensures other clients know about your relay and can connect to it.

Decoding npub (Public Key)

Private keys (nsec) and public keys (npub) are encoded in bech32 format, which includes: - A prefix (like nsec1, npub1 etc.) - The encoded data - A checksum

This format makes keys: - Easy to distinguish - Hard to copy incorrectly

However, most tools require these keys in hexadecimal (hex) format.

To decode an npub string to its hex format:

bash nak decode nostr:npub1dejts0qlva8mqzjlrxqkc2tmvs2t7elszky5upxaf3jha9qs9m5q605uc4

Change it with your own npub.

bash { "pubkey": "6e64b83c1f674fb00a5f19816c297b6414bf67f015894e04dd4c657e94102ee8" }

Copy the pubkey value in quotes.

Create a kind 10002 event with your relay list:

• Include your new relay with write permissions
• Include other relays you want to read from and write to, omit 3rd parameter to make it both read and write

Example format:

json { "kind": 10002, "tags": [ ["r", "wss://your-relay-domain.com", "write"], ["r", "wss://eden.nostr.land/"], ["r", "wss://nos.lol/"], ["r", "wss://nostr.bitcoiner.social/"], ["r", "wss://nostr.mom/"], ["r", "wss://relay.primal.net/"], ["r", "wss://nostr.wine/", "read"], ["r", "wss://relay.damus.io/"], ["r", "wss://relay.nostr.band/"], ["r", "wss://relay.snort.social/"] ], "content": "" }

Save it to a file called event.json

Note: Add or remove any relays you want. To check your existing 10002 relays: - Visit https://nostr.band/?q=by%3Anpub1dejts0qlva8mqzjlrxqkc2tmvs2t7elszky5upxaf3jha9qs9m5q605uc4+++kind%3A10002 - nostr.band is an indexing service, it probably has your relay list. - Replace npub1xxx in the URL with your own npub - Click "VIEW JSON" from the menu to see the raw event - Or use the nak tool if you know the relays bash nak req -k 10002 -a <your-pubkey> wss://relay1.com wss://relay2.com

Replace `<your-pubkey>` with your public key in hex format (you can get it using `nak decode <your-npub>`)

1. Sign and publish the event:
2. Use a Nostr client that supports kind 10002 events
3. Or use the nak command-line tool: bash nak event --sec ncryptsec1... wss://relay1.com wss://relay2.com $(cat event.json)

Important Security Notes: 1. Never share your nsec (private key) with anyone 2. Consider using NIP-49 encrypted keys for better security 3. Never paste your nsec or private key into the terminal. The command will be saved in your shell history, exposing your private key. To clear the command history: - For bash: use history -c - For zsh: use fc -W to write history to file, then fc -p to read it back - Or manually edit your shell history file (e.g., ~/.zsh_history or ~/.bash_history) 4. if you're using zsh, use fc -p to prevent the next command from being saved to history 5. Or temporarily disable history before running sensitive commands:

bash unset HISTFILE nak key encrypt ... set HISTFILE

How to securely create NIP-49 encypted private key

```bash

Read your private key (input will be hidden)

read -s SECRET

Read your password (input will be hidden)

read -s PASSWORD

encrypt command

echo "$SECRET" | nak key encrypt "$PASSWORD"

copy and paste the ncryptsec1 text from the output

read -s ENCRYPTED nak key decrypt "$ENCRYPTED"

clear variables from memory

unset SECRET PASSWORD ENCRYPTED ```

On a Windows command line, to read from stdin and use the variables in nak commands, you can use a combination of set /p to read input and then use those variables in your command. Here's an example:

```bash @echo off set /p "SECRET=Enter your secret key: " set /p "PASSWORD=Enter your password: "

echo %SECRET%| nak key encrypt %PASSWORD%

:: Clear the sensitive variables set "SECRET=" set "PASSWORD=" ```

If your key starts with ncryptsec1, the nak tool will securely prompt you for a password when using the --sec parameter, unless the command is used with a pipe < > or |.

bash nak event --sec ncryptsec1... wss://relay1.com wss://relay2.com $(cat event.json)

1. Verify the event was published:
2. Check if your relay list is visible on other relays

3. Use the nak tool to fetch your kind 10002 events: bash nak req -k 10002 -a <your-pubkey> wss://relay1.com wss://relay2.com

4. Testing your relay:

5. Try connecting to your relay using different Nostr clients
6. Verify you can both read from and write to your relay
7. Check if events are being properly stored and retrieved
8. Tip: Use multiple Nostr clients to test different aspects of your relay

Note: If anyone in the community has a more efficient method of doing things like updating outbox relays, please share your insights in the comments. Your expertise would be greatly appreciated!

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

@ 4ba8e86d:89d32de4

Tutorial feito por nostr:nostr:npub1rc56x0ek0dd303eph523g3chm0wmrs5wdk6vs0ehd0m5fn8t7y4sqra3tk poste original abaixo:

Parte 1 : http://xh6liiypqffzwnu5734ucwps37tn2g6npthvugz3gdoqpikujju525yd.onion/263585/tutorial-debloat-de-celulares-android-via-adb-parte-1

Parte 2 : http://xh6liiypqffzwnu5734ucwps37tn2g6npthvugz3gdoqpikujju525yd.onion/index.php/263586/tutorial-debloat-de-celulares-android-via-adb-parte-2

Quando o assunto é privacidade em celulares, uma das medidas comumente mencionadas é a remoção de bloatwares do dispositivo, também chamado de debloat. O meio mais eficiente para isso sem dúvidas é a troca de sistema operacional. Custom Rom’s como LineageOS, GrapheneOS, Iodé, CalyxOS, etc, já são bastante enxutos nesse quesito, principalmente quanto não é instalado os G-Apps com o sistema. No entanto, essa prática pode acabar resultando em problemas indesejados como a perca de funções do dispositivo, e até mesmo incompatibilidade com apps bancários, tornando este método mais atrativo para quem possui mais de um dispositivo e separando um apenas para privacidade.   Pensando nisso, pessoas que possuem apenas um único dispositivo móvel, que são necessitadas desses apps ou funções, mas, ao mesmo tempo, tem essa visão em prol da privacidade, buscam por um meio-termo entre manter a Stock rom, e não ter seus dados coletados por esses bloatwares. Felizmente, a remoção de bloatwares é possível e pode ser realizada via root, ou mais da maneira que este artigo irá tratar, via adb.

O que são bloatwares?

Bloatware é a junção das palavras bloat (inchar) + software (programa), ou seja, um bloatware é basicamente um programa inútil ou facilmente substituível — colocado em seu dispositivo previamente pela fabricante e operadora — que está no seu dispositivo apenas ocupando espaço de armazenamento, consumindo memória RAM e pior, coletando seus dados e enviando para servidores externos, além de serem mais pontos de vulnerabilidades.

O que é o adb?

O Android Debug Brigde, ou apenas adb, é uma ferramenta que se utiliza das permissões de usuário shell e permite o envio de comandos vindo de um computador para um dispositivo Android exigindo apenas que a depuração USB esteja ativa, mas também pode ser usada diretamente no celular a partir do Android 11, com o uso do Termux e a depuração sem fio (ou depuração wifi). A ferramenta funciona normalmente em dispositivos sem root, e também funciona caso o celular esteja em Recovery Mode.

Requisitos:

Para computadores:

• Depuração USB ativa no celular; • Computador com adb; • Cabo USB;

Para celulares:

• Depuração sem fio (ou depuração wifi) ativa no celular; • Termux; • Android 11 ou superior;

Para ambos:

• Firewall NetGuard instalado e configurado no celular; • Lista de bloatwares para seu dispositivo;

Ativação de depuração:

Para ativar a Depuração USB em seu dispositivo, pesquise como ativar as opções de desenvolvedor de seu dispositivo, e lá ative a depuração. No caso da depuração sem fio, sua ativação irá ser necessária apenas no momento que for conectar o dispositivo ao Termux.

Instalação e configuração do NetGuard

O NetGuard pode ser instalado através da própria Google Play Store, mas de preferência instale pela F-Droid ou Github para evitar telemetria.

F-Droid: https://f-droid.org/packages/eu.faircode.netguard/

Github: https://github.com/M66B/NetGuard/releases

Após instalado, configure da seguinte maneira:

Configurações → padrões (lista branca/negra) → ative as 3 primeiras opções (bloquear wifi, bloquear dados móveis e aplicar regras ‘quando tela estiver ligada’);

Configurações → opções avançadas → ative as duas primeiras (administrar aplicativos do sistema e registrar acesso a internet);

Com isso, todos os apps estarão sendo bloqueados de acessar a internet, seja por wifi ou dados móveis, e na página principal do app basta permitir o acesso a rede para os apps que você vai usar (se necessário). Permita que o app rode em segundo plano sem restrição da otimização de bateria, assim quando o celular ligar, ele já estará ativo.

Lista de bloatwares

Nem todos os bloatwares são genéricos, haverá bloatwares diferentes conforme a marca, modelo, versão do Android, e até mesmo região.

Para obter uma lista de bloatwares de seu dispositivo, caso seu aparelho já possua um tempo de existência, você encontrará listas prontas facilmente apenas pesquisando por elas. Supondo que temos um Samsung Galaxy Note 10 Plus em mãos, basta pesquisar em seu motor de busca por:

Samsung Galaxy Note 10 Plus bloatware list

Provavelmente essas listas já terão inclusas todos os bloatwares das mais diversas regiões, lhe poupando o trabalho de buscar por alguma lista mais específica.

Caso seu aparelho seja muito recente, e/ou não encontre uma lista pronta de bloatwares, devo dizer que você acaba de pegar em merda, pois é chato para um caralho pesquisar por cada aplicação para saber sua função, se é essencial para o sistema ou se é facilmente substituível.

De antemão já aviso, que mais para frente, caso vossa gostosura remova um desses aplicativos que era essencial para o sistema sem saber, vai acabar resultando na perda de alguma função importante, ou pior, ao reiniciar o aparelho o sistema pode estar quebrado, lhe obrigando a seguir com uma formatação, e repetir todo o processo novamente.

Download do adb em computadores

Para usar a ferramenta do adb em computadores, basta baixar o pacote chamado SDK platform-tools, disponível através deste link: https://developer.android.com/tools/releases/platform-tools. Por ele, você consegue o download para Windows, Mac e Linux.

Uma vez baixado, basta extrair o arquivo zipado, contendo dentro dele uma pasta chamada platform-tools que basta ser aberta no terminal para se usar o adb.

Download do adb em celulares com Termux.

Para usar a ferramenta do adb diretamente no celular, antes temos que baixar o app Termux, que é um emulador de terminal linux, e já possui o adb em seu repositório. Você encontra o app na Google Play Store, mas novamente recomendo baixar pela F-Droid ou diretamente no Github do projeto.

F-Droid: https://f-droid.org/en/packages/com.termux/

Github: https://github.com/termux/termux-app/releases

Processo de debloat

Antes de iniciarmos, é importante deixar claro que não é para você sair removendo todos os bloatwares de cara sem mais nem menos, afinal alguns deles precisam antes ser substituídos, podem ser essenciais para você para alguma atividade ou função, ou até mesmo são insubstituíveis.

Alguns exemplos de bloatwares que a substituição é necessária antes da remoção, é o Launcher, afinal, é a interface gráfica do sistema, e o teclado, que sem ele só é possível digitar com teclado externo. O Launcher e teclado podem ser substituídos por quaisquer outros, minha recomendação pessoal é por aqueles que respeitam sua privacidade, como Pie Launcher e Simple Laucher, enquanto o teclado pelo OpenBoard e FlorisBoard, todos open-source e disponíveis da F-Droid.

Identifique entre a lista de bloatwares, quais você gosta, precisa ou prefere não substituir, de maneira alguma você é obrigado a remover todos os bloatwares possíveis, modifique seu sistema a seu bel-prazer. O NetGuard lista todos os apps do celular com o nome do pacote, com isso você pode filtrar bem qual deles não remover.

Um exemplo claro de bloatware insubstituível e, portanto, não pode ser removido, é o com.android.mtp, um protocolo onde sua função é auxiliar a comunicação do dispositivo com um computador via USB, mas por algum motivo, tem acesso a rede e se comunica frequentemente com servidores externos. Para esses casos, e melhor solução mesmo é bloquear o acesso a rede desses bloatwares com o NetGuard.

MTP tentando comunicação com servidores externos:

Executando o adb shell

No computador

Faça backup de todos os seus arquivos importantes para algum armazenamento externo, e formate seu celular com o hard reset. Após a formatação, e a ativação da depuração USB, conecte seu aparelho e o pc com o auxílio de um cabo USB. Muito provavelmente seu dispositivo irá apenas começar a carregar, por isso permita a transferência de dados, para que o computador consiga se comunicar normalmente com o celular.

Já no pc, abra a pasta platform-tools dentro do terminal, e execute o seguinte comando:

./adb start-server

O resultado deve ser:

daemon not running; starting now at tcp:5037 daemon started successfully

E caso não apareça nada, execute:

./adb kill-server

E inicie novamente.

Com o adb conectado ao celular, execute:

./adb shell

Para poder executar comandos diretamente para o dispositivo. No meu caso, meu celular é um Redmi Note 8 Pro, codinome Begonia.

Logo o resultado deve ser:

begonia:/ $

Caso ocorra algum erro do tipo:

adb: device unauthorized. This adb server’s $ADB_VENDOR_KEYS is not set Try ‘adb kill-server’ if that seems wrong. Otherwise check for a confirmation dialog on your device.

Verifique no celular se apareceu alguma confirmação para autorizar a depuração USB, caso sim, autorize e tente novamente. Caso não apareça nada, execute o kill-server e repita o processo.

No celular

Após realizar o mesmo processo de backup e hard reset citado anteriormente, instale o Termux e, com ele iniciado, execute o comando:

pkg install android-tools

Quando surgir a mensagem “Do you want to continue? [Y/n]”, basta dar enter novamente que já aceita e finaliza a instalação

Agora, vá até as opções de desenvolvedor, e ative a depuração sem fio. Dentro das opções da depuração sem fio, terá uma opção de emparelhamento do dispositivo com um código, que irá informar para você um código em emparelhamento, com um endereço IP e porta, que será usado para a conexão com o Termux.

Para facilitar o processo, recomendo que abra tanto as configurações quanto o Termux ao mesmo tempo, e divida a tela com os dois app’s, como da maneira a seguir:

Para parear o Termux com o dispositivo, não é necessário digitar o ip informado, basta trocar por “localhost”, já a porta e o código de emparelhamento, deve ser digitado exatamente como informado. Execute:

adb pair localhost:porta CódigoDeEmparelhamento

De acordo com a imagem mostrada anteriormente, o comando ficaria “adb pair localhost:41255 757495”.

Com o dispositivo emparelhado com o Termux, agora basta conectar para conseguir executar os comandos, para isso execute:

adb connect localhost:porta

Obs: a porta que você deve informar neste comando não é a mesma informada com o código de emparelhamento, e sim a informada na tela principal da depuração sem fio.

Pronto! Termux e adb conectado com sucesso ao dispositivo, agora basta executar normalmente o adb shell:

adb shell

Remoção na prática Com o adb shell executado, você está pronto para remover os bloatwares. No meu caso, irei mostrar apenas a remoção de um app (Google Maps), já que o comando é o mesmo para qualquer outro, mudando apenas o nome do pacote.

Dentro do NetGuard, verificando as informações do Google Maps:

Podemos ver que mesmo fora de uso, e com a localização do dispositivo desativado, o app está tentando loucamente se comunicar com servidores externos, e informar sabe-se lá que peste. Mas sem novidades até aqui, o mais importante é que podemos ver que o nome do pacote do Google Maps é com.google.android.apps.maps, e para o remover do celular, basta executar:

pm uninstall –user 0 com.google.android.apps.maps

E pronto, bloatware removido! Agora basta repetir o processo para o resto dos bloatwares, trocando apenas o nome do pacote.

Para acelerar o processo, você pode já criar uma lista do bloco de notas com os comandos, e quando colar no terminal, irá executar um atrás do outro.

Exemplo de lista:

Caso a donzela tenha removido alguma coisa sem querer, também é possível recuperar o pacote com o comando:

cmd package install-existing nome.do.pacote

Pós-debloat

Após limpar o máximo possível o seu sistema, reinicie o aparelho, caso entre no como recovery e não seja possível dar reboot, significa que você removeu algum app “essencial” para o sistema, e terá que formatar o aparelho e repetir toda a remoção novamente, desta vez removendo poucos bloatwares de uma vez, e reiniciando o aparelho até descobrir qual deles não pode ser removido. Sim, dá trabalho… quem mandou querer privacidade?

Caso o aparelho reinicie normalmente após a remoção, parabéns, agora basta usar seu celular como bem entender! Mantenha o NetGuard sempre executando e os bloatwares que não foram possíveis remover não irão se comunicar com servidores externos, passe a usar apps open source da F-Droid e instale outros apps através da Aurora Store ao invés da Google Play Store.

Referências: Caso você seja um Australopithecus e tenha achado este guia difícil, eis uma videoaula (3:14:40) do Anderson do canal Ciberdef, realizando todo o processo: http://odysee.com/@zai:5/Como-remover-at%C3%A9-200-APLICATIVOS-que-colocam-a-sua-PRIVACIDADE-E-SEGURAN%C3%87A-em-risco.:4?lid=6d50f40314eee7e2f218536d9e5d300290931d23

Pdf’s do Anderson citados na videoaula: créditos ao anon6837264 http://eternalcbrzpicytj4zyguygpmkjlkddxob7tptlr25cdipe5svyqoqd.onion/file/3863a834d29285d397b73a4af6fb1bbe67c888d72d30/t-05e63192d02ffd.pdf

Processo de instalação do Termux e adb no celular: https://youtu.be/APolZrPHSms

@ d34e832d:383f78d0

A Look into Traffic Analysis and What WebSocket Patterns Reveal at the Network Level

While WebSocket encryption (typically via WSS) is essential for protecting data in transit, traffic analysis remains a potent method of uncovering behavioral patterns, data structure inference, and protocol usage—even when payloads are unreadable. This idea investigates the visibility of encrypted WebSocket communications using Wireshark and similar packet inspection tools. We explore what metadata remains visible, how traffic flow can be modeled, and what risks and opportunities exist for developers, penetration testers, and network analysts. The study concludes by discussing mitigation strategies and the implications for privacy, application security, and protocol design.

Consider

In the age of real-time web applications, WebSockets have emerged as a powerful protocol enabling low-latency, bidirectional communication. From collaborative tools and chat applications to financial trading platforms and IoT dashboards, WebSockets have become foundational for interactive user experiences.

However, encryption via WSS (WebSocket Secure, running over TLS) gives developers and users a sense of security. The payload may be unreadable, but what about the rest of the connection? Can patterns, metadata, and traffic characteristics still leak critical information?

This thesis seeks to answer those questions by leveraging Wireshark, the de facto tool for packet inspection, and exploring the world of traffic analysis at the network level.

Background and Related Work

The WebSocket Protocol

Defined in RFC 6455, WebSocket operates over TCP and provides a persistent, full-duplex connection. The protocol upgrades an HTTP connection, then communicates through a simple frame-based structure.

Encryption with WSS

WSS connections use TLS (usually on port 443), making them indistinguishable from HTTPS traffic at the packet level. Payloads are encrypted, but metadata such as IP addresses, timing, packet size, and connection duration remain visible.

Traffic Analysis

Traffic analysis—despite encryption—has long been a technique used in network forensics, surveillance, and malware detection. Prior studies have shown that encrypted protocols like HTTPS, TLS, and SSH still reveal behavioral information through patterns.

Methodology

Tools Used:

• Wireshark (latest stable version)
• TLS decryption with local keys (when permitted)
• Simulated and real-world WebSocket apps (chat, games, IoT dashboards)
• Scripts to generate traffic patterns (Python using websockets and aiohttp)

Test Environments:

• Controlled LAN environments with known server and client
• Live observation of open-source WebSocket platforms (e.g., Matrix clients)

Data Points Captured:

• Packet timing and size
• TLS handshake details
• IP/TCP headers
• Frame burst patterns
• Message rate and directionality

Findings

1. Metadata Leaks

Even without payload access, the following data is visible: - Source/destination IP - Port numbers (typically 443) - Server certificate info - Packet sizes and intervals - TLS handshake fingerprinting (e.g., JA3 hashes)

2. Behavioral Patterns

• Chat apps show consistent message frequency and short message sizes.
• Multiplayer games exhibit rapid bursts of small packets.
• IoT devices often maintain idle connections with periodic keepalives.
• Typing indicators, heartbeats, or "ping/pong" mechanisms are visible even under encryption.

3. Timing and Packet Size Fingerprinting

Even encrypted payloads can be fingerprinted by: - Regularity in payload size (e.g., 92 bytes every 15s) - Distinct bidirectional patterns (e.g., send/ack/send per user action) - TLS record sizes which may indirectly hint at message length

Side-Channel Risks in Encrypted WebSocket Communication

Although WebSocket payloads transmitted over WSS (WebSocket Secure) are encrypted, they remain susceptible to side-channel analysis, a class of attacks that exploit observable characteristics of the communication channel rather than its content.

Side-Channel Risks Include:

1. User Behavior Inference
Adversaries can analyze packet timing and frequency to infer user behavior. For example, typing indicators in chat applications often trigger short, regular packets. Even without payload visibility, a passive observer may identify when a user is typing, idle, or has closed the application. Session duration, message frequency, and bursts of activity can be linked to specific user actions.

2. Application Fingerprinting
TLS handshake metadata and consistent traffic patterns can allow an observer to identify specific client libraries or platforms. For example, the sequence and structure of TLS extensions (via JA3 fingerprinting) can differentiate between browsers, SDKs, or WebSocket frameworks. Application behavior—such as timing of keepalives or frequency of updates—can further reinforce these fingerprints.

3. Usage Pattern Recognition
Over time, recurring patterns in packet flow may reveal application logic. For instance, multiplayer game sessions often involve predictable synchronization intervals. Financial dashboards may show bursts at fixed polling intervals. This allows for profiling of application type, logic loops, or even user roles.

4. Leakage Through Timing
Time-based attacks can be surprisingly revealing. Regular intervals between message bursts can disclose structured interactions—such as polling, pings, or scheduled updates. Fine-grained timing analysis may even infer when individual keystrokes occur, especially in sparse channels where interactivity is high and payloads are short.

5. Content Length Correlation
While encrypted, the size of a TLS record often correlates closely to the plaintext message length. This enables attackers to estimate the size of messages, which can be linked to known commands or data structures. Repeated message sizes (e.g., 112 bytes every 30s) may suggest state synchronization or batched updates.

6. Session Correlation Across Time
Using IP, JA3 fingerprints, and behavioral metrics, it’s possible to link multiple sessions back to the same client. This weakens anonymity, especially when combined with data from DNS logs, TLS SNI fields (if exposed), or consistent traffic habits. In anonymized systems, this can be particularly damaging.

Side-Channel Risks in Encrypted WebSocket Communication

Although WebSocket payloads transmitted over WSS (WebSocket Secure) are encrypted, they remain susceptible to side-channel analysis, a class of attacks that exploit observable characteristics of the communication channel rather than its content.

1. Behavior Inference

Even with end-to-end encryption, adversaries can make educated guesses about user actions based on traffic patterns:

• Typing detection: In chat applications, short, repeated packets every few hundred milliseconds may indicate a user typing.
• Voice activity: In VoIP apps using WebSockets, a series of consistent-size packets followed by silence can reveal when someone starts and stops speaking.
• Gaming actions: Packet bursts at high frequency may correlate with real-time game movement or input actions.

2. Session Duration

WebSocket connections are persistent by design. This characteristic allows attackers to:

• Measure session duration: Knowing how long a user stays connected to a WebSocket server can infer usage patterns (e.g., average chat duration, work hours).
• Identify session boundaries: Connection start and end timestamps may be enough to correlate with user login/logout behavior.

3. Usage Patterns

Over time, traffic analysis may reveal consistent behavioral traits tied to specific users or devices:

• Time-of-day activity: Regular connection intervals can point to habitual usage, ideal for profiling or surveillance.
• Burst frequency and timing: Distinct intervals of high or low traffic volume can hint at backend logic or user engagement models.

---

Example Scenario: Encrypted Chat App

Even though a chat application uses end-to-end encryption and transports data over WSS:

• A passive observer sees:
• TLS handshake metadata
• IPs and SNI (Server Name Indication)
• Packet sizes and timings
• They might then infer:
• When a user is online or actively chatting
• Whether a user is typing, idle, or receiving messages
• Usage patterns that match a specific user fingerprint

This kind of intelligence can be used for traffic correlation attacks, profiling, or deanonymization — particularly dangerous in regimes or situations where privacy is critical (e.g., journalists, whistleblowers, activists).

Fingerprinting Encrypted WebSocket Applications via Traffic Signatures

Even when payloads are encrypted, adversaries can leverage fingerprinting techniques to identify the specific WebSocket libraries, frameworks, or applications in use based on unique traffic signatures. This is a critical vector in traffic analysis, especially when full encryption lulls developers into a false sense of security.

1. Library and Framework Fingerprints

Different WebSocket implementations generate traffic patterns that can be used to infer what tool or framework is being used, such as:

• Handshake patterns: The WebSocket upgrade request often includes headers that differ subtly between:
• Browsers (Chrome, Firefox, Safari)
• Python libs (websockets, aiohttp, Autobahn)
• Node.js clients (ws, socket.io)
• Mobile SDKs (Android’s okhttp, iOS Starscream)
• Heartbeat intervals: Some libraries implement default ping/pong intervals (e.g., every 20s in socket.io) that can be measured and traced back to the source.

2. Payload Size and Frequency Patterns

Even with encryption, metadata is exposed:

• Frame sizes: Libraries often chunk or batch messages differently.
• Initial message burst: Some apps send a known sequence of messages on connection (e.g., auth token → subscribe → sync events).
• Message intervals: Unique to libraries using structured pub/sub or event-driven APIs.

These observable patterns can allow a passive observer to identify not only the app but potentially which feature is being used, such as messaging, location tracking, or media playback.

3. Case Study: Identifying Socket.IO vs Raw WebSocket

Socket.IO, although layered on top of WebSockets, introduces a handshake sequence of HTTP polling → upgrade → packetized structured messaging with preamble bytes (even in encrypted form, the size and frequency of these frames is recognizable). A well-equipped observer can differentiate it from a raw WebSocket exchange using only timing and packet length metrics.

---

Security Implications

• Targeted exploitation: Knowing the backend framework (e.g., Django Channels or FastAPI + websockets) allows attackers to narrow down known CVEs or misconfigurations.
• De-anonymization: Apps that are widely used in specific demographics (e.g., Signal clones, activist chat apps) become fingerprintable even behind HTTPS or WSS.
• Nation-state surveillance: Traffic fingerprinting lets governments block or monitor traffic associated with specific technologies, even without decrypting the data.

Leakage Through Timing: Inferring Behavior in Encrypted WebSocket Channels

Encrypted WebSocket communication does not prevent timing-based side-channel attacks, where an adversary can deduce sensitive information purely from the timing, size, and frequency of encrypted packets. These micro-behavioral signals, though not revealing actual content, can still disclose high-level user actions — sometimes with alarming precision.

1. Typing Detection and Keystroke Inference

Many real-time chat applications (Matrix, Signal, Rocket.Chat, custom WebSocket apps) implement "user is typing..." features. These generate recognizable message bursts even when encrypted:

• Small, frequent packets sent at irregular intervals often correspond to individual keystrokes.
• Inter-keystroke timing analysis — often accurate to within tens of milliseconds — can help reconstruct typed messages’ length or even guess content using language models (e.g., inferring "hello" vs "hey").

2. Session Activity Leaks

WebSocket sessions are long-lived and often signal usage states by packet rhythm:

• Idle vs active user patterns become apparent through heartbeat frequency and packet gaps.
• Transitions — like joining or leaving a chatroom, starting a video, or activating a voice stream — often result in bursts of packet activity.
• Even without payload access, adversaries can profile session structure, determining which features are being used and when.

3. Case Study: Real-Time Editors

Collaborative editing tools (e.g., Etherpad, CryptPad) leak structure:

• When a user edits, each keystroke or operation may result in a burst of 1–3 WebSocket frames.
• Over time, a passive observer could infer:
• Whether one or multiple users are active
• Who is currently typing
• The pace of typing
• Collaborative vs solo editing behavior

4. Attack Vectors Enabled by Timing Leaks

• Target tracking: Identify active users in a room, even on anonymized or end-to-end encrypted platforms.
• Session replay: Attackers can simulate usage patterns for further behavioral fingerprinting.
• Network censorship: Governments may block traffic based on WebSocket behavior patterns suggestive of forbidden apps (e.g., chat tools, Tor bridges).

---

Mitigations and Countermeasures

While timing leakage cannot be entirely eliminated, several techniques can obfuscate or dampen signal strength:

• Uniform packet sizing (padding to fixed lengths)
• Traffic shaping (constant-time message dispatch)
• Dummy traffic injection (noise during idle states)
• Multiplexing WebSocket streams with unrelated activity

Excellent point — let’s weave that into the conclusion of the thesis to emphasize the dual nature of WebSocket visibility:

---

Visibility Without Clarity — Privacy Risks in Encrypted WebSocket Traffic**

This thesis demonstrates that while encryption secures the contents of WebSocket payloads, it does not conceal behavioral patterns. Through tools like Wireshark, analysts — and adversaries alike — can inspect traffic flows to deduce session metadata, fingerprint applications, and infer user activity, even without decrypting a single byte.

The paradox of encrypted WebSockets is thus revealed:
They offer confidentiality, but not invisibility.

As shown through timing analysis, fingerprinting, and side-channel observation, encrypted WebSocket streams can still leak valuable information. These findings underscore the importance of privacy-aware design choices in real-time systems:

• Padding variable-size messages to fixed-length formats
• Randomizing or shaping packet timing
• Mixing in dummy traffic during idle states
• Multiplexing unrelated data streams to obscure intent

Without such obfuscation strategies, encrypted WebSocket traffic — though unreadable — remains interpretable.

In closing, developers, privacy researchers, and protocol designers must recognize that encryption is necessary but not sufficient. To build truly private real-time systems, we must move beyond content confidentiality and address the metadata and side-channel exposures that lie beneath the surface.

Absolutely! Here's a full thesis-style writeup titled “Mitigation Strategies: Reducing Metadata Leakage in Encrypted WebSocket Traffic”, focusing on countermeasures to side-channel risks in real-time encrypted communication:

---

Mitigation Strategies: Reducing Metadata Leakage in Encrypted WebSocket Traffic

Abstract

While WebSocket traffic is often encrypted using TLS, it remains vulnerable to metadata-based side-channel attacks. Adversaries can infer behavioral patterns, session timing, and even the identity of applications through passive traffic analysis. This thesis explores four key mitigation strategies—message padding, batching and jitter, TLS fingerprint randomization, and connection multiplexing—that aim to reduce the efficacy of such analysis. We present practical implementations, limitations, and trade-offs associated with each method and advocate for layered, privacy-preserving protocol design.

---

1. Consider

The rise of WebSockets in real-time applications has improved interactivity but also exposed new privacy attack surfaces. Even when encrypted, WebSocket traffic leaks observable metadata—packet sizes, timing intervals, handshake properties, and connection counts—that can be exploited for fingerprinting, behavioral inference, and usage profiling.

This Idea focuses on mitigation rather than detection. The core question addressed is: How can we reduce the information available to adversaries from metadata alone?

---

2. Threat Model and Metadata Exposure

Passive attackers situated at any point between client and server can: - Identify application behavior via timing and message frequency - Infer keystrokes or user interaction states ("user typing", "user joined", etc.) - Perform fingerprinting via TLS handshake characteristics - Link separate sessions from the same user by recognizing traffic patterns

Thus, we must treat metadata as a leaky abstraction layer, requiring proactive obfuscation even in fully encrypted sessions.

---

3. Mitigation Techniques

3.1 Message Padding

Variable-sized messages create unique traffic signatures. Message padding involves standardizing the frame length of WebSocket messages to a fixed or randomly chosen size within a predefined envelope.

• Pro: Hides exact payload size, making compression side-channel and length-based analysis ineffective.
• Con: Increases bandwidth usage; not ideal for mobile/low-bandwidth scenarios.

Implementation: Client libraries can pad all outbound messages to, for example, 512 bytes or the next power of two above the actual message length.

---

3.2 Batching and Jitter

Packet timing is often the most revealing metric. Delaying messages to create jitter and batching multiple events into a single transmission breaks correlation patterns.

• Pro: Prevents timing attacks, typing inference, and pattern recognition.
• Con: Increases latency, possibly degrading UX in real-time apps.

Implementation: Use an event queue with randomized intervals for dispatching messages (e.g., 100–300ms jitter windows).

---

3.3 TLS Fingerprint Randomization

TLS fingerprints—determined by the ordering of cipher suites, extensions, and fields—can uniquely identify client libraries and platforms. Randomizing these fields on the client side prevents reliable fingerprinting.

• Pro: Reduces ability to correlate sessions or identify tools/libraries used.
• Con: Requires deeper control of the TLS stack, often unavailable in browsers.

Implementation: Modify or wrap lower-level TLS clients (e.g., via OpenSSL or rustls) to introduce randomized handshakes in custom apps.

---

3.4 Connection Reuse or Multiplexing

Opening multiple connections creates identifiable patterns. By reusing a single persistent connection for multiple data streams or users (in proxies or edge nodes), the visibility of unique flows is reduced.

• Pro: Aggregates traffic, preventing per-user or per-feature traffic separation.
• Con: More complex server-side logic; harder to debug.

Implementation: Use multiplexing protocols (e.g., WebSocket subprotocols or application-level routing) to share connections across users or components.

---

4. Combined Strategy and Defense-in-Depth

No single strategy suffices. A layered mitigation approach—combining padding, jitter, fingerprint randomization, and multiplexing—provides defense-in-depth against multiple classes of metadata leakage.

The recommended implementation pipeline: 1. Pad all outbound messages to a fixed size 2. Introduce random batching and delay intervals 3. Obfuscate TLS fingerprints using low-level TLS stack configuration 4. Route data over multiplexed WebSocket connections via reverse proxies or edge routers

This creates a high-noise communication channel that significantly impairs passive traffic analysis.

---

5. Limitations and Future Work

Mitigations come with trade-offs: latency, bandwidth overhead, and implementation complexity. Additionally, some techniques (e.g., TLS randomization) are hard to apply in browser-based environments due to API constraints.

Future work includes: - Standardizing privacy-enhancing WebSocket subprotocols - Integrating these mitigations into mainstream libraries (e.g., Socket.IO, Phoenix) - Using machine learning to auto-tune mitigation levels based on threat environment

---

6. Case In Point

Encrypted WebSocket traffic is not inherently private. Without explicit mitigation, metadata alone is sufficient for behavioral profiling and application fingerprinting. This thesis has outlined practical strategies for obfuscating traffic patterns at various protocol layers. Implementing these defenses can significantly improve user privacy in real-time systems and should become a standard part of secure WebSocket deployments.

@ f32184ee:6d1c17bf

Ads Fueling Freedom

Ross Ulbricht’s "Decentralize Social Media" painted a picture of a user-centric, decentralized future that transcended the limitations of platforms like the tech giants of today. Though focused on social media, his concept provided a blueprint for decentralized content systems writ large. The PROMO Protocol, designed by NextBlock while participating in Sovereign Engineering, embodies this blueprint in the realm of advertising, leveraging Nostr and Bitcoin’s Lightning Network to give individuals control, foster a multi-provider ecosystem, and ensure secure value exchange. In this way, Ulbricht’s 2021 vision can be seen as a prescient prediction of the PROMO Protocol’s structure. This is a testament to the enduring power of his ideas, now finding form in NextBlock’s innovative approach.

[Current Platform-Centric Paradigm, source: Ross Ulbricht's Decentralize Social Media]

Ulbricht’s Vision: A Decentralized Social Protocol

In his 2021 Medium article Ulbricht proposed a revolutionary vision for a decentralized social protocol (DSP) to address the inherent flaws of centralized social media platforms, such as privacy violations and inconsistent content moderation. Writing from prison, Ulbricht argued that decentralization could empower users by giving them control over their own content and the value they create, while replacing single, monolithic platforms with a competitive ecosystem of interface providers, content servers, and advertisers. Though his focus was on social media, Ulbricht’s ideas laid a conceptual foundation that strikingly predicts the structure of NextBlock’s PROMO Protocol, a decentralized advertising system built on the Nostr protocol.

[A Decentralized Social Protocol (DSP), source: Ross Ulbricht's Decentralize Social Media]

Ulbricht’s Principles

Ulbricht’s article outlines several key principles for his DSP: * User Control: Users should own their content and dictate how their data and creations generate value, rather than being subject to the whims of centralized corporations. * Decentralized Infrastructure: Instead of a single platform, multiple interface providers, content hosts, and advertisers interoperate, fostering competition and resilience. * Privacy and Autonomy: Decentralized solutions for profile management, hosting, and interactions would protect user privacy and reduce reliance on unaccountable intermediaries. * Value Creation: Users, not platforms, should capture the economic benefits of their contributions, supported by decentralized mechanisms for transactions.

These ideas were forward-thinking in 2021, envisioning a shift away from the centralized giants dominating social media at the time. While Ulbricht didn’t specifically address advertising protocols, his framework for decentralization and user empowerment extends naturally to other domains, like NextBlock’s open-source offering: the PROMO Protocol.

NextBlock’s Implementation of PROMO Protocol

The PROMO Protocol powers NextBlock's Billboard app, a decentralized advertising protocol built on Nostr, a simple, open protocol for decentralized communication. The PROMO Protocol reimagines advertising by: * Empowering People: Individuals set their own ad prices (e.g., 500 sats/minute), giving them direct control over how their attention or space is monetized. * Marketplace Dynamics: Advertisers set budgets and maximum bids, competing within a decentralized system where a 20% service fee ensures operational sustainability. * Open-Source Flexibility: As an open-source protocol, it allows multiple developers to create interfaces or apps on top of it, avoiding the single-platform bottleneck Ulbricht critiqued. * Secure Payments: Using Strike Integration with Bitcoin Lightning Network, NextBlock enables bot-resistant and intermediary-free transactions, aligning value transfer with each person's control.

This structure decentralizes advertising in a way that mirrors Ulbricht’s broader vision for social systems, with aligned principles showing a specific use case: monetizing attention on Nostr.

Aligned Principles

Ulbricht’s 2021 article didn’t explicitly predict the PROMO Protocol, but its foundational concepts align remarkably well with NextBlock's implementation the protocol’s design: * Autonomy Over Value: Ulbricht argued that users should control their content and its economic benefits. In the PROMO Protocol, people dictate ad pricing, directly capturing the value of their participation. Whether it’s their time, influence, or digital space, rather than ceding it to a centralized ad network. * Ecosystem of Providers: Ulbricht envisioned multiple providers replacing a single platform. The PROMO Protocol’s open-source nature invites a similar diversity: anyone can build interfaces or tools on top of it, creating a competitive, decentralized advertising ecosystem rather than a walled garden. * Decentralized Transactions: Ulbricht’s DSP implied decentralized mechanisms for value exchange. NextBlock delivers this through the Bitcoin Lightning Network, ensuring that payments for ads are secure, instantaneous and final, a practical realization of Ulbricht’s call for user-controlled value flows. * Privacy and Control: While Ulbricht emphasized privacy in social interactions, the PROMO Protocol is public by default. Individuals are fully aware of all data that they generate since all Nostr messages are signed. All participants interact directly via Nostr.

[Blueprint Match, source NextBlock]

---

Who We Are

NextBlock is a US-based new media company reimagining digital ads for a decentralized future. Our founders, software and strategy experts, were hobbyist podcasters struggling to promote their work online without gaming the system. That sparked an idea: using new tech like Nostr and Bitcoin to build a decentralized attention market for people who value control and businesses seeking real connections.

Our first product, Billboard, is launching this June.

Open for All

Our model’s open-source! Check out the PROMO Protocol, built for promotion and attention trading. Anyone can join this decentralized ad network. Run your own billboard or use ours. This is a growing ecosystem for a new ad economy.

Our Vision

NextBlock wants to help build a new decentralized internet. Our revolutionary and transparent business model will bring honest revenue to companies hosting valuable digital spaces. Together, we will discover what our attention is really worth.

Read our Manifesto to learn more.

NextBlock is registered in Texas, USA.

@ da0b9bc3:4e30a4a9

Hello Stackers!

Welcome on into the ~Music Corner of the Saloon!

A place where we Talk Music. Share Tracks. Zap Sats.

So stay a while and listen.

🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨

🚨Subscribe to the territory to ensure you never miss a post! 🚨

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

@ d34e832d:383f78d0

For Secure Inheritance Planning and Offline Signing

---

The setup described ensures that any 2 out of 3 participants (hardware wallets) must sign a transaction before it can be broadcast, offering robust protection against theft, accidental loss, or mismanagement of funds.

---

1. Preparation: Tools and Requirements

Hardware Required

• 3× COLDCARD Mk4 hardware wallets (or newer)
• 3× MicroSD cards (one per COLDCARD)
• MicroSD card reader (for your computer)
• Optional: USB data blocker (for safe COLDCARD connection)

Software Required

• Sparrow Wallet: Version 1.7.1 or later
  Download: https://sparrowwallet.com/
• COLDCARD Firmware: Version 5.1.2 or later
  Update guide: https://coldcard.com/docs/upgrade

Other Essentials

• Durable paper or steel backup tools for seed phrases
• Secure physical storage for backups and devices
• Optional: encrypted external storage for Sparrow wallet backups

Security Tip:
Always verify software signatures before installation. Keep your COLDCARDs air-gapped (no USB data transfer) whenever possible.

---

2. Initializing Each COLDCARD Wallet

1. Power on each COLDCARD and choose “New Wallet”.
2. Write down the 24-word seed phrase (DO NOT photograph or store digitally).
3. Confirm the seed and choose a strong PIN code (both prefix and suffix).
4. (Optional) Enable BIP39 Passphrase for additional entropy.
5. Save an encrypted backup to the MicroSD card:
   Go to Advanced > Danger Zone > Backup.
6. Repeat steps 1–5 for all three COLDCARDs.

Best Practice:
Store each seed phrase securely and in separate physical locations. Test wallet recovery before storing real funds.

---

3. Exporting XPUBs from COLDCARD

Each hardware wallet must export its extended public key (XPUB) for multisig setup:

1. Insert MicroSD card into a COLDCARD.
2. Navigate to:
   Settings > Multisig Wallets > Export XPUB.
3. Select the appropriate derivation path. Recommended:
4. Native SegWit: m/84'/0'/0' (bc1 addresses)
5. Alternatively: Nested SegWit m/49'/0'/0' (starts with 3)
6. Save the XPUB file to the MicroSD card.
7. Insert MicroSD into your computer and transfer XPUB files to Sparrow Wallet.
8. Repeat for the remaining COLDCARDs.

---

4. Creating the 2-of-3 Multisig Wallet in Sparrow

1. Launch Sparrow Wallet.
2. Click File > New Wallet and name your wallet.
3. In the Keystore tab, choose Multisig.
4. Select 2-of-3 as your multisig policy.
5. For each cosigner:
6. Choose Add cosigner > Import XPUB from file.
7. Load XPUBs exported from each COLDCARD.
8. Once all 3 cosigners are added, confirm the configuration.
9. Click Apply, then Create Wallet.
10. Sparrow will display a receive address. Fund the wallet using this.

Tip:
You can export the multisig policy (wallet descriptor) as a backup and share it among cosigners.

---

5. Saving and Verifying the Wallet Configuration

1. After creating the wallet, click Wallet > Export > Export Wallet File (.json).
2. Save this file securely and distribute to all participants.
3. Verify that the addresses match on each COLDCARD using the wallet descriptor file (optional but recommended).

---

6. Creating and Exporting a PSBT (Partially Signed Bitcoin Transaction)

1. In Sparrow, click Send, fill out recipient details, and click Create Transaction.
2. Click Finalize > Save PSBT to MicroSD card.
3. The file will be saved as a .psbt file.

Note: No funds are moved until 2 signatures are added and the transaction is broadcast.

---

7. Signing the PSBT with COLDCARD (Offline)

1. Insert the MicroSD with the PSBT into COLDCARD.
2. From the main menu:
   Ready To Sign > Select PSBT File.
3. Verify transaction details and approve.
4. COLDCARD will create a signed version of the PSBT (signed.psbt).
5. Repeat the signing process with a second COLDCARD (different signer).

---

8. Finalizing and Broadcasting the Transaction

1. Load the signed PSBT files back into Sparrow.
2. Sparrow will detect two valid signatures.
3. Click Finalize Transaction > Broadcast.
4. Your Bitcoin transaction will be sent to the network.

---

9. Inheritance Planning with Multisig

Multisig is ideal for inheritance scenarios:

Example Inheritance Setup

• Signer 1: Yourself (active user)
• Signer 2: Trusted family member or executor
• Signer 3: Lawyer, notary, or secure backup

Only 2 signatures are needed. If one party loses access or passes away, the other two can recover the funds.

Best Practices for Inheritance

• Store each seed phrase in separate, tamper-proof, waterproof containers.
• Record clear instructions for heirs (without compromising seed security).
• Periodically test recovery with cosigners.
• Consider time-locked wallets or third-party escrow if needed.

---

Security Tips and Warnings

• Never store seed phrases digitally or online.
• Always verify addresses and signatures on the COLDCARD screen.
• Use Sparrow only on secure, malware-free computers.
• Physically secure your COLDCARDs from unauthorized access.
• Practice recovery procedures before storing real value.

---

Consider

A 2-of-3 multisignature wallet using COLDCARD and Sparrow Wallet offers a highly secure, flexible, and transparent Bitcoin custody model. Whether for inheritance planning or high-security storage, it mitigates risks associated with single points of failure while maintaining usability and privacy.

By following this guide, Bitcoin users can significantly increase the resilience of their holdings while enabling thoughtful succession strategies.

@ a8d1560d:3fec7a08

Based on the Free Speech Flag generator at https://crocojim18.github.io/, but now you can encode binary data as well.

https://free-speech-flag-generator--wholewish91244492.on.websim.ai/

Please also see https://en.wikipedia.org/wiki/Free_Speech_Flag for more information about the Free Speech Flag.

Who can tell me what I encoded in the flag used for this longform post?

@ da0b9bc3:4e30a4a9

Hello Stackers!

Welcome on into the ~Music Corner of the Saloon!

A place where we Talk Music. Share Tracks. Zap Sats.

So stay a while and listen.

🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨

🚨Subscribe to the territory to ensure you never miss a post! 🚨

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

@ 1c19eb1a:e22fb0bc

After my first major review of Primal on Android, we're going to go a very different direction for this next review. Primal is your standard "Twitter clone" type of kind 1 note client, now branching into long-form. They also have a team of developers working on making it one of the best clients to fill that use-case. By contrast, this review will not be focusing on any client at all. Not even an "other stuff" client.

Instead, we will be reviewing a very useful tool created and maintained by nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5 called #Amber. For those unfamiliar with Amber, it is an #Android application dedicated to managing your signing keys, and allowing you to log into various #Nostr applications without having to paste in your private key, better known as your #nsec. It is not recommended to paste your nsec into various applications because they each represent another means by which it could be compromised, and anyone who has your nsec can post as you. On Nostr, your #npub is your identity, and your signature using your private key is considered absolute proof that any given note, reaction, follow update, or profile change was authorized by the rightful owner of that identity.

It happens less often these days, but early on, when the only way to try out a new client was by inputting your nsec, users had their nsec compromised from time to time, or they would suspect that their key may have been compromised. When this occurs, there is no way to recover your account, or set a new private key, deprecating the previous one. The only thing you can do is start over from scratch, letting everyone know that your key has been compromised and to follow you on your new npub.

If you use Amber to log into other Nostr apps, you significantly reduce the likelihood that your private key will be compromised, because only one application has access to it, and all other applications reach out to Amber to sign any events. This isn't quite as secure as storing your private key on a separate device that isn't connected to the internet whatsoever, like many of us have grown accustomed to with securing our #Bitcoin, but then again, an online persona isn't nearly as important to secure for most of us as our entire life savings.

Amber is the first application of its kind for managing your Nostr keys on a mobile device. nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5 didn't merely develop the application, but literally created the specification for accomplishing external signing on Android which can be found in NIP-55. Unfortunately, Amber is only available for Android. A signer application for iOS is in the works from nostr:npub1yaul8k059377u9lsu67de7y637w4jtgeuwcmh5n7788l6xnlnrgs3tvjmf, but is not ready for use at this time. There is also a new mobile signer app for Android and iOS called Nowser, but I have not yet had a chance to try this app out. From a cursory look at the Android version, it is indeed in the very early stages of development and cannot be compared with Amber.

This review of Amber is current as of version 3.2.5.

Overall Impression

Score: 4.7 / 5 (Updated 4/21/2025)

I cannot speak highly enough about Amber as a tool that every Nostr user on Android should start using if they are not already. When the day comes that we have more options for well-developed signer apps on mobile, my opinion may very well change, but until then Amber is what we have available to us. Even so, it is an incredibly well thought-out and reliable tool for securing your nsec.

Despite being the only well-established Android signer available for Android, Amber can be compared with other external signing methods available on other platforms. Even with more competition in this arena, though, Amber still holds up incredibly well. If you are signing into web applications on a desktop, I still would recommend using a browser extension like #Alby or #Nos2x, as the experience is usually faster, more seamless, and far more web apps support this signing method (NIP-07) than currently support the two methods employed by Amber. Nevertheless that gap is definitely narrowing.

A running list I created of applications that support login and signing with Amber can be found here: Nostr Clients with External Signer Support

I have run into relatively few bugs in my extensive use of Amber for all of my mobile signing needs. Occasionally the application crashes when trying to send it a signing request from a couple of applications, but I would not be surprised if this is no fault of Amber at all, and rather the fault of those specific apps, since it works flawlessly with the vast majority of apps that support either NIP-55 or NIP-46 login.

I also believe that mobile is the ideal platform to use for this type of application. First, because most people use Nostr clients on their phone more than on a desktop. There are, of course, exceptions to that, but in general we spend more time on our phones when interacting online. New users are also more likely to be introduced to Nostr by a friend having them download a Nostr client on their phone than on a PC, and that can be a prime opportunity to introduce the new user to protecting their private key. Finally, I agree with the following assessment from nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn.

nostr:nevent1qqsw0r6gzn05xg67h5q2xkplwsuzedjxw9lf7ntrxjl8ajm350fcyugprfmhxue69uhhyetvv9ujumn0wd68yurvv438xtnrdaksyg9hyaxj3clfswlhyrd5kjsj5v04clhjvgeq6pwztmysfzdvn93gev7awu9v

The one downside to Amber is that it will be quite foreign for new users. That is partially unavoidable with Nostr, since folks are not accustomed to public/private key cryptography in general, let alone using a private key to log into websites or social media apps. However, the initial signup process is a bit cumbersome if Amber is being used as the means of initially generating a key pair. I think some of this could be foregone at start-up in favor of streamlining onboarding, and then encourage the user to back-up their private key at a later time.

Features

Amber has some features that may surprise you, outside of just storing your private key and signing requests from your favorite Nostr clients. It is a full key management application, supporting multiple accounts, various backup methods, and even the ability to authorize other users to access a Nostr profile you control.

Android Signing

This is the signing method where Amber really shines in both speed and ease of use. Any Android application that supports this standard, and even some progressive web-apps that can be installed to your Android's home-screen, can very quickly and seamlessly connect with Amber to authorize anything that you need signed with your nsec. All you have to do is select "Login with Amber" in clients like #Amethyst or #0xChat and the app will reach out to Amber for all signing requests from there on out. If you had previously signed into the app with your nsec, you will first need to log out, then choose the option to use Amber when you log back in.

This is a massive deal, because everything you do on Nostr requires a signature from your private key. Log in? Needs a signature. Post a "GM" note? Needs a signature. Follow someone who zapped your note? Needs a signature. Zap them back? You guessed it; needs a signature. When you paste your private key into an application, it will automatically sign a lot of these actions without you ever being asked for approval, but you will quickly realize just how many things the client is doing on your behalf when Amber is asking you to approve them each time.

Now, this can also get quite annoying after a while. I recommend using the setting that allows Amber to automatically sign for basic functions, which will cut down on some of the authorization spam. Once you have been asked to authorize the same type of action a few times, you can also toggle the option to automatically authorize that action in the future. Don't worry, though, you have full control to require Amber to ask you for permission again if you want to be alerted each time, and this toggle is specific to each application, so it's not a blanket approval for all Nostr clients you connect with.

This method of signing is just as fast as signing via browser extension on web clients, which users may be more accustomed to. Everything is happening locally on the device, so it can be very snappy and secure.

Nostr Connect/Bunker Signing

This next method of signing has a bit of a delay, because it is using a Nostr relay to send encrypted information back and forth between the app the user is interacting with and Amber to obtain signatures remotely. It isn't a significant delay most of the time, but it is just enough to be noticeable.

Also, unlike the previous signing method that would automatically switch to Amber as the active application when a signing request is sent, this method only sends you a notification that you must be watching for. This can lead to situations where you are wondering why something isn't working in a client you signed into remotely, because it is waiting on you to authorize the action and you didn't notice the notification from Amber. As you use the application, you get used to the need to check for such authorization requests from time to time, or when something isn't working as expected.

By default, Amber will use relay.nsec.app to communicate with whichever Nostr app you are connecting to. You can set a different relay for this purpose, if you like, though not just any relay will support the event kinds that Amber uses for remote signing. You can even run your own relay just for your own signing purposes. In fact, the creator of Amber has a relay application you can run on your phone, called Citrine, that can be used for signing with any web app you are using locally on your phone. This is definitely more of an advanced option, but it is there for you if you want it. For most users, sticking with relay.nsec.app will be just fine, especially since the contents of the events sent back and forth for signing are all encrypted.

Something many users may not realize is that this remote signing feature allows for issuing signing permissions to team members. For instance, if anyone ever joined me in writing reviews, I could issue them a connection string from Amber, and limit their permissions to just posting long-form draft events. Anything else they tried to do would require my explicit approval each time. Moreover, I could revoke those permissions if I ever felt they were being abused, without the need to start over with a whole new npub. Of course, this requires that your phone is online whenever a team member is trying to sign using the connection string you issued, and it requires you pay attention to your notifications so you can approve or reject requests you have not set to auto-approve. However, this is probably only useful for small teams, and larger businesses will want to find a more robust solution for managing access to their npub, such as Keycast from nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc.

The method for establishing a connection between Amber and a Nostr app for remote signing can vary for each app. Most, at minimum, will support obtaining a connection string from Amber that starts with "bunker://" and pasting it in at the time of login. Then you just need to approve the connection request from Amber and the client will log you in and send any subsequent signing requests to Amber using the same connection string.

Some clients will also offer the option to scan a QR code to connect the client to Amber. This is quite convenient, but just remember that this also means the client is setting which relay will be used for communication between the two. Clients with this option will also have a connection string you can copy and paste into Amber to achieve the same purpose. For instance, you may need this option if you are trying to connect to an app on your phone and therefore can't scan the QR code using Amber on the same phone.

Multiple Accounts

Amber does not lock you into using it with only a single set of keys. You can add all of your Nostr "accounts" to Amber and use it for signing events for each independently. Of course, Nostr doesn't actually have "accounts" in the traditional sense. Your identity is simply your key-pair, and Amber stores and accesses each private key as needed.

When first signing in using native Android signing as described above, Amber will default to whichever account was most recently selected, but you can switch to the account that is needed before approving the request. After initial login, Amber will automatically detect the account that the signing request is for.

Key Backup & Restore

Amber allows multiple ways to back up your private key. As most users would expect, you can get your standard nsec and copy/paste it to a password manager, but you can also obtain your private key as a list of mnemonic seed words, an encrypted version of your key called an ncryptsec, or even a QR code of your nsec or ncryptsec.

Additionally, in order to gain access to this information, Amber requires you to enter your device's PIN or use biometric authentication. This isn't cold-storage level protection for your private key by any means, especially since your phone is an internet connected device and does not store your key within a secure element, but it is about as secure as you can ask for while having your key accessible for signing Nostr events.

Tor Support

While Amber does not have Tor support within the app itself, it does support connecting to Tor through Orbot. This would be used with remote signing so that Amber would not connect directly over clearnet to the relay used for communication with the Nostr app requesting the signature. Instead, Amber would connect through Tor, so the relay would not see your IP address. This means you can utilize the remote signing option without compromising your anonymity.

Additional Security

Amber allows the user the option to require either biometric or PIN authentication before approving signing requests. This can provide that extra bit of assurance that no one will be able to sign events using your private key if they happen to gain access to your phone. The PIN you set in Amber is also independent from the PIN to unlock your device, allowing for separation of access.

Can My Grandma Use It?

Score: 4.6 / 5 (Updated 4/21/2025)

At the end of the day, Amber is a tool for those who have some concept of the importance of protecting their private key by not pasting it into every Nostr client that comes along. This concept in itself is not terribly approachable to an average person. They are used to just plugging their password into every service they use, and even worse, they usually have the same password for everything so they can more readily remember it. The idea that they should never enter their "Nostr password" into any Nostr application would never occur to them unless someone first explained how cryptography works related to public/private key pairs.

That said, I think there can be some improvements made to how users are introduced to these concepts, and that a signer application like Amber might be ideal for the job. Considering Amber as a new user's first touch-point with Nostr, I think it holds up well, but could be somewhat streamlined.

Upon opening the app, the user is prompted to either use their existing private key or "Create a new Nostr account." This is straightforward enough. "Account" is not a technically correct term with Nostr, but it is a term that new users would be familiar with and understand the basic concept.

The next screen announces that the account is ready, and presents the user with their public key, explaining that it is "a sort of username" that will allow others to find them on Nostr. While it is good to explain this to the user, it is unnecessary information at this point. This screen also prompts the user to set a nickname and set a password to encrypt their private key. Since the backup options also allow the user to set this password, I think this step could be pushed to a later time. This screen would better serve the new user if it simply prompted them to set a nickname and short bio that could be saved to a few default relays.

Of course, Amber is currently prompting for a password to be set up-front because the next screen requires the new user to download a "backup kit" in order to continue. While I do believe it is a good idea to encourage the creation of a backup, it is not crucial to do so immediately upon creation of a new npub that has nothing at stake if the private key is lost. This is something the UI could remind the user to do at a later time, reducing the friction of profile creation, and expediting getting them into the action.

Outside of these minor onboarding friction points, I think Amber does a great job of explaining to the user the purpose of each of its features, all within the app and without any need to reference external documentation. As long as the user understands the basic concept that their private key is being stored by Amber in order to sign requests from other Nostr apps, so they don't have to be given the private key, Amber is very good about explaining the rest without getting too far into the technical weeds.

The most glaring usability issue with Amber is that it isn't available in the Play Store. Average users expect to be able to find applications they can trust in their mobile device's default app store. There is a valid argument to be made that they are incorrect in this assumption, but that doesn't change the fact that this is the assumption most people make. They believe that applications in the Play Store are "safe" and that anything they can't install through the Play Store is suspect. The prompts that the Android operating system requires the user to approve when installing "unknown apps" certainly doesn't help with this impression.

Now, I absolutely love the Zapstore from nostr:npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9, but it doesn't do much to alleviate this issue. Users will still need to be convinced that it is safe to install the Zapstore from the GitHub repo, and then install Amber from there. Furthermore, this adds yet another step to the onboarding process.

Instead of:

• Install Amber
• Set up your keys
• Install the client you want to use
• Log in with Amber

The process becomes:

• Go to the Zapstore GitHub and download the latest version from the releases page.
• Install the APK you downloaded, allowing any prompt to install unknown apps.
• Open Zapstore and install Amber, allowing any prompt to install unknown apps again.
• Open Amber and set up your keys.
• Install the client you want to use
• Log in with Amber

An application as important as Amber for protecting users' private keys should be as readily available to the new user as possible. New users are the ones most prone to making mistakes that could compromise their private keys. Amber should be available to them in the Play Store.

UPDATE: As of version 3.2.8 released on 4/21/2025, the onboarding flow for Amber has been greatly improved! Now, when selecting to set up a new "account" the user is informed on the very next screen, "Your Nostr account is ready!" and given their public key/npub. The only field the user must fill in is their "nickname"/display name and hit "Continue."

From there the user is asked if they want Amber to automatically approve basic actions, or manually approve each app, and then they are shown a new Applications screen, with a prompt to create a backup of their account. This prompt persists until the user has done so.

As you can see, the user is also encouraged to find applications that can be used with Amber with links to nostrapps.com and the Zapstore.

Thanks to these updates, Amber is now the smoothest and most user-friendly onboarding experience I have seen for Nostr to date. Sure, it doesn't have anything for setting up a profile picture or lightning address, but that is better done in a client like Amethyst or YakiHonne, anyway. Just tap "create," type in a handle to call yourself, and you're done!

How do UI Look?

Score: 4.5 / 5

Amber's UI can be described as clean but utilitarian. But then, Amber is a tool, so this is somewhat expected. It is not an app you will be spending a lot of time in, so the UI just needs to be serviceable. I would say it accomplishes this and then some. UI elements are generally easy to understand what they do, and page headings fill in the gaps where that is not the case.

I am not the biggest fan of the color-scheme, particularly in light-mode, but it is not bad in dark-mode at all, and Amber follows whatever theme you have set for your device in that respect. Additionally, the color choice does make sense given the application's name.

It must also be taken into consideration that Amber is almost entirely the product of a single developer's work. He has done a great job producing an app that is not only useful, but pleasant to interact with. The same cannot be said for most utility apps I have previously used, with interfaces that clearly made good design the lowest priority. While Amber's UI may not be the most beautiful Nostr app I have seen, design was clearly not an afterthought, either, and it is appreciated.

Relay Management

Score: 4.9 / 5

Even though Amber is not a Nostr client, where users can browse notes from their favorite npubs, it still relies heavily on relays for some of its features. Primarily, it uses relays for communicating with other Nostr apps for remote signing requests. However, it also uses relays to fetch profile data, so that each private key you add to Amber will automatically load your chosen username and profile picture.

In the relay settings, users can choose which relays are being used to fetch profile data, and which relays will be used by default when creating new remote signing connection strings.

The user can also see which relays are currently connected to Amber and even look at the information that has been passed back and forth on each of those active relays. This information about actively connected relays is not only available within the application, but also in the notification that Amber has to keep in your device's notification tray in order to continue to operate in the background while you are using other apps.

Optionality is the name of the game when it comes to how Amber handles relay selection. The user can just stick with the default signing relay, use their own relay as the default, or even use a different relay for each Nostr application that they connect to for remote signing. Amber gives the user an incredible amount of flexibility in this regard.

In addition to all of this, because not all relays accept the event types needed for remote signing, when you add a relay address to Amber, it automatically tests that relay to see if it will work. This alone can be a massive time saver, so users aren't trying to use relays that don't support remote signing and wondering why they can't log into noStrudel with the connection string they got from Amber.

The only way I could see relay management being improved would be some means of giving the user relay recommendations, in case they want to use a relay other than relay.nsec.app, but they aren't sure which other relays will accept remote signing events. That said, most users who want to use a different relay for signing remote events will likely be using their own, in which case recommendations aren't needed.

Current Users' Questions

The AskNostr hashtag can be a good indication of the pain points that other users are currently having with any Nostr application. Here are some of the most common questions submitted about Amber in the last two months.

nostr:nevent1qqsfrdr68fafgcvl8dgnhm9hxpsjxuks78afxhu8yewhtyf3d7mkg9gpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgq3qkgh77xxt7hhtt4u528hecnx69rhagla8jj3tclgyf9wvkxa6dc0sxp0e6m

This is a good example of Amber working correctly, but the app the user is trying to log into not working. In my experience with #Olas in particular, it sometimes allows remote signer login, and sometimes doesn't. Amber will receive the signing request and I will approve it, but Olas remains on the login screen.

If Amber is receiving the signing requests, and you are approving them, the fault is likely with the application you are trying to log into.

That's it. That's all the repeated questions I could find. Oh, there were a few one-off questions where relay.nsec.app wouldn't connect, or where the user's out-of-date web browser was the issue. Outside of that, though, there were no common questions about how to use Amber, and that is a testament to Amber's ease of use all on its own.

Wrap Up

If you are on Android and you are not already using Amber to protect your nsec, please do yourself a favor and get it installed. It's not at all complicated to set up, and it will make trying out all the latest Nostr clients a safe and pleasant experience.

If you are a client developer and you have not added support for NIP-55 or NIP-46, do your users the courtesy of respecting the sanctity of their private keys. Even developers who have no intention of compromising their users' keys can inadvertently do so. Make that eventuality impossible by adding support for NIP-55 and NIP-46 signing.

Finally, I apologize for the extended time it took me to get this review finished. The time I have available is scarce, Nostr is distracting, and nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5 kept improving Amber even as I was putting it through its paces over the last two months. Keep shipping, my friend! You have made one of the most useful tools we have seen for Nostr to date!

Now... What should I review next?

@ d34e832d:383f78d0

Such a transformation positions Nostr to compete with established social networking platforms in terms of reach while simultaneously ensuring the preservation of user sovereignty and the integrity of cryptographic trust mechanisms.

The Emergence of Encrypted Relay-to-Relay Federation

In the context of Nostr protocol scalability challenges pertaining to censorship-resistant networking paradigms, Nostr stands as a paradigm-shifting entity, underpinned by robust public-key cryptography and minimal operational assumptions. This feature set has rendered Nostr an emblematic instrument for overcoming systemic censorship, fostering permissionless content dissemination, and upholding user autonomy within digital environments. However, as the demographic footprint of Nostr's user base grows exponentially, coupled with an expanding range of content modalities, the structural integrity of individual relays faces increasing pressure.

Challenges of Isolation and Limited Scalability in Decentralized Networks

The current architecture of Nostr relays is primarily constituted of simple TCP or WebSocket servers that facilitate the publication and reception of events. While aesthetically simple, this design introduces significant performance bottlenecks and discoverability issues. Relays targeting specific regional or topical niches often rely heavily on client-side interactions or third-party directories for information exchange. This operational framework presents inefficiencies when scaled globally, especially in scenarios requiring high throughput and rapid dissemination of information. Furthermore, it does not adequately account for redundancy and availability, especially in low-bandwidth environments or regions facing strict censorship.

Navigating Impediments of Isolation and Constrained Scalability

Current Nostr relay infrastructures mainly involve basic TCP and WebSocket configurations for event publication and reception. While simple, these configurations contribute to performance bottlenecks and a significant discoverability deficit. Relays that serve niche markets often operate under constraints, relying on client-side interactions or third-party directories. These inefficiencies become particularly problematic at a global scale, where high throughput and rapid information distribution are necessary. The absence of mechanisms to enhance redundancy and availability in environments with limited connectivity or under censorship further exacerbates these issues.

Proposal for Encrypted Relay Federation

Encrypted relay federation in decentralized networking can be achieved through a novel Nostr Improvement Proposal (NIP), which introduces a sophisticated gossip-style mesh topology. In this system, relays subscribe to content tags, message types, or public keys from peer nodes, optimizing data flow and relevance.

Central to this architecture is a mutual key handshake protocol using Elliptic Curve Diffie-Hellman (ECDH) for symmetric encryption over relay keys. This ensures data integrity and confidentiality during transmission. The use of encrypted event bundles, compression, and routing based on relay reputation metrics and content demand analytics enhances throughput and optimizes network resources.

To counter potential abuse and spam, strategies like rate limiting, financially incentivized peering, and token gating are proposed, serving as control mechanisms for network interactions. Additionally, the relay federation model could emulate the Border Gateway Protocol (BGP), allowing for dynamic content advertisement and routing updates across the federated mesh, enhancing network resilience.

Advantages of Relay Federation in Data Distribution Architecture

Relay federation introduces a distributed data load management system where relays selectively store pertinent events. This enhances data retrieval efficiency, minimizes congestion, and fosters a censorship-resistant information flow. By decentralizing data storage, relays contribute to a global cache network, ensuring no single relay holds comprehensive access to all network data. This feature helps preserve the integrity of information flow, making it resistant to censorship.

An additional advantage is offline communication capabilities. Even without traditional internet access, events can still be communicated through alternative channels like Bluetooth, Wi-Fi Direct, or LoRa. This ensures local and community-based interactions remain uninterrupted during network downtime.

Furthermore, relay federations may introduce monetization strategies where specialized relays offer access to rare or high-quality data streams, promoting competition and interoperability while providing users with diverse data options.

Some Notable Markers To Nostr Becoming the Internet Layer for Censorship Resistance

Stop for a moment in your day and try to understand what Nostr can do for your communications by observing these markers:

1. Protocol Idea (NIP-01 by fiatjaf) │ ▼
2. npub/nsec Keypair Standard │ ▼
3. First Relays Go Online │ ▼
4. Identity & Auth (NIP-05, NIP-07) │ ▼
5. Clients Launch (Damus, Amethyst, Iris, etc.) │ ▼
6. Lightning Zaps + NWC (NIP-57) │ ▼
7. Relay Moderation & Reputation NIPs │ ▼
8. Protocol Bridging (ActivityPub, Matrix, Mastodon) │ ▼
9. Ecash Integration (Cashu, Walletless Zaps) │ ▼
10. Encrypted Relay Federation (Experimental) │ ▼
11. Relay Mesh Networks (WireGuard + libp2p) │ ▼
12. IoT Integration (Meshtastic + ESP32) │ ▼
13. Fully Decentralized, Censorship-Resistant Social Layer

The implementation of encrypted federation represents a pivotal technological advancement, establishing a robust framework that challenges the prevailing architecture of fragmented social networking ecosystems and monopolistic centralized cloud services. This innovative approach posits that Nostr could:

• Facilitate a comprehensive, globally accessible decentralized index of information, driven fundamentally by user interactions and a novel microtransaction system (zaps), enabling efficient content valorization and information dissemination.
• Empower the concept of nomadic digital identities, allowing them to seamlessly traverse various relays, devoid of reliance on centralized identity verification systems, promoting user autonomy and privacy.
• Become the quintessential backend infrastructure for decentralized applications, knowledge graphs, and expansive datasets conducive to DVMs.
• Achieve seamless interoperability with established protocols, such as ActivityPub, Matrix, IPFS, and innovative eCash systems that offer incentive mechanisms, fostering an integrated and collaborative ecosystem.

In alignment with decentralization, encrypted relay-to-relay federation marks a significant evolution for the Nostr protocol, transitioning from isolated personal broadcasting stations to an interoperable, adaptive, trustless mesh network of communication nodes.

By implementing this sophisticated architecture, Nostr is positioned to scale efficiently, addressing global needs while preserving free speech, privacy, and individual autonomy in a world marked by surveillance and compartmentalized digital environments.

Nostr's Countenance Structure: Noteworthy Events

``` Nostr Protocol Concept by fiatjaf:

• First Relays and npub/nsec key pairs appear
• Damus, Amethyst, and other clients emerge
• Launch of Zaps and Lightning Tip Integration
• Mainstream interest post Twitter censorship events
• Ecosystem tools: NWC, NIP-07, NIP-05 adoption
• Nostr devs propose relay scoring and moderation NIPs
• Bridging begins (ActivityPub, Matrix, Mastodon)
• Cashu eCash integration with Nostr zaps (walletless tips)
• Relay-to-relay encrypted federation proposed
• Hackathons exploring libp2p, LNbits, and eCash-backed identities
• Scalable P2P Mesh using WireGuard + Nostr + Gossip
• Web3 & IoT integration with ESP32 + Meshtastic + relays
• A censorship-resistant, decentralized social internet ```

@ d34e832d:383f78d0

This foundational philosophy positioned her as the principal architect of the climactic finale of the Reconquista—a protracted campaign that sought to reclaim territories under Muslim dominion. Her decisive participation in military operations against the Emirate of Granada not only consummated centuries of Christian reclamation endeavors but also heralded the advent of a transformative epoch in both Spanish and European identity, intertwining religious zeal with nationalistic aspirations and setting the stage for the emergence of a unified Spanish state that would exert significant influence on European dynamics for centuries to come.

Image Above Map Of Th Iberias

During the era of governance overseen by Muhammad XII, historically identified as Boabdil, the Kingdom of Granada was characterized by a pronounced trajectory of decline, beset by significant internal dissent and acute dynastic rivalry, factors that fundamentally undermined its structural integrity. The political landscape of the emirate was marked by fragmentation, most notably illustrated by the contentious relationship between Boabdil and his uncle, the militarily adept El Zagal, whose formidable martial capabilities further exacerbated the emirate's geopolitical vulnerabilities, thereby impairing its capacity to effectively mobilize resistance against the encroaching coalition of Christian forces. Nevertheless, it is imperative to acknowledge the strategic advantages conferred by Granada’s formidable mountainous terrain, coupled with the robust fortifications of its urban centers. This geographical and structural fortitude, augmented by the fervent determination and resilience of the local populace, collectively contributed to Granada's status as a critical and tenacious stronghold of Islamic governance in the broader Iberian Peninsula during this tumultuous epoch.

The military campaign initiated was precipitated by the audacious territorial annexation of Zahara by the Emirate in the annum 1481—a pivotal juncture that served as a catalytic impetus for the martial engagement orchestrated by the Catholic Monarchs, Isabel I of Castile and Ferdinand II of Aragon.

Image Above Monarchs Of Castilles

What subsequently unfolded was an arduous protracted conflict, extending over a decade, characterized by a series of decisive military confrontations—most notably the Battle of Alhama, the skirmishes at Loja and Lucena, the strategic recapture of Zahara, and engagements in Ronda, Málaga, Baza, and Almería. Each of these encounters elucidates the intricate dynamics of military triumph entwined with the perils of adversity. Isabel's role transcended mere symbolic representation; she emerged as an astute logistical architect, meticulously structuring supply chains, provisioning her armies with necessary resources, and advocating for military advancements, including the tactical incorporation of Lombard artillery into the operational theater. Her dual presence—both on the battlefield and within the strategic command—interwove deep-seated piety with formidable power, unifying administrative efficiency with unyielding ambition.

In the face of profound personal adversities, exemplified by the heart-wrenching stillbirth of her progeny amidst the tumultuous electoral campaign, Isabel exhibited a remarkable steadfastness in her quest for triumph. Her strategic leadership catalyzed a transformative evolution in the constructs of monarchical power, ingeniously intertwining the notion of divine right—a historically entrenched justification for sovereign authority—with pragmatic statecraft underpinned by the imperatives of efficacious governance and stringent military discipline. The opposition posed by El Zagal, characterized by his indefatigable efforts and tenacious resistance, elongated the duration of the campaign; however, the indomitable spirit and cohesive resolve of the Catholic Monarchs emerged as an insuperable force, compelling the eventual culmination of their aspirations into a definitive victory.

The capitulation of the Emirate of Granada in the month of January in the year 1492 represents a pivotal moment in the historical continuum of the Iberian Peninsula, transcending the mere conclusion of the protracted series of military engagements known as the Reconquista. This momentous event is emblematic of the intricate process of state-building that led to the establishment of a cohesive Spanish nation-state fundamentally predicated on the precepts of Christian hegemony. Furthermore, it delineates the cusp of an imperial epoch characterized by expansionist ambitions fueled by religious zealotry. The ramifications of this surrender profoundly altered the sociocultural and political framework of the region, precipitating the coerced conversion and expulsion of significant Jewish and Muslim populations—a demographic upheaval that would serve to reinforce the ideological paradigms that underpinned the subsequent institution of the Spanish Inquisition, a systematic apparatus of religious persecution aimed at maintaining ideological conformity and unity under the Catholic Monarchs.

Image Above Surrender At Granada

In a broader historical context, the capitulation of the Nasrid Kingdom of Granada transpired concurrently with the inaugural expedition undertaken by the navigator Christopher Columbus, both events being facilitated under the auspices of Queen Isabel I of Castile. This significant temporal nexus serves to underscore the confluence of the termination of Islamic hegemony in the Iberian Peninsula with the commencement of European maritime exploration on a grand scale. Such a juxtaposition of religiously motivated conquest and the zealous pursuit of transoceanic exploration precipitated a paradigm shift in the trajectory of global history. It catalyzed the ascendance of the Spanish Empire, thereby marking the nascent stages of European colonial endeavors throughout the Americas.

Image Above Columbus At The Spanish Court

This epochal transformation not only redefined territorial dominion but also initiated profound socio-economic and cultural repercussions across continents, forever altering the intricate tapestry of human civilization.

Consequently, the cessation of hostilities in Granada should not merely be interpreted as the conclusion of a protracted medieval conflict; rather, it represents a critical juncture that fundamentally reoriented the socio-political landscape of the Old World while concurrently heralding the advent of modernity. The pivotal contributions of Queen Isabel I in this transformative epoch position her as an extraordinarily significant historical figure—an autocrat whose strategic foresight, resilience, and zeal indelibly influenced the trajectory of nations and entire continents across the globe.

@ d34e832d:383f78d0

The operational landscape for Nostr relay operators is fraught with multifaceted challenges that not only pertain to technical feasibility but also address pivotal economic realities in an increasingly censored digital environment.

While the infrastructure required to run a Nostr relay can be considered comparatively lightweight in terms of hardware demands, the operators must navigate a spectrum of operational hurdles and associated costs. Key among these are bandwidth allocation, effective spam mitigation, comprehensive security protocols, and the critical need for sustained uptime.

To ensure economic viability amidst these challenges, many relay operators have implemented various strategies, including the introduction of rate limiting mechanisms and subscription-based financial models that leverage user payments to subsidize operational costs. The conundrum remains: how can the Nostr framework evolve to permit relay operators to cultivate at least a singular relay to its fullest operational efficiency?

It is essential to note that while the trajectory of user engagement with these relays remains profoundly unpredictable—analogous to the nebulous impetus behind their initial inception—indicators within our broader economic and sociocultural contexts illuminate potential pathways to harmonizing commercial interests with user interaction through the robust capabilities of websocket relays.

A few musingsI beg you to think about the Evolutionary Trajectory of Nostr Infrastructure Leveraging BDK (Bitcoin Development Kit) and NDK (Nostr Development Kit) in the Context of Sovereign Communication Infrastructure

As the Nostr ecosystem transitions through its iterative phases of maturity, the infrastructure, notably the relays, is projected to undergo significant enhancements to accommodate an array of emerging protocols, particularly highlighted by the Mostr Bridge implementation.

Additionally, the integration of decentralized identity frameworks, exemplified by PKARR (Public-Key Addressable Resource Records), signifies a robust evolutionary step towards fostering user accountability and autonomy.

Moreover, the introduction of sophisticated filtering mechanisms, including but not limited to Set Based Reconciliation techniques, seeks to refine the user interface by enabling more granular control over content visibility and interaction dynamics.

These progressive innovations are meticulously designed to augment the overall user experience while steadfastly adhering to the foundational ethos of the Nostr protocol, which emphasizes the principles of digital freedom, uncurtailed access to publication, and the establishment of a harassment-free digital environment devoid of shadowbanning practices.

Such advancements underscore the balancing act between technological progression and ethical considerations in decentralized communication frameworks.

@ d34e832d:383f78d0

Let’s break it down.

🎭 The Cultural Love for Hype

Trinidadians are no strangers to investing. We invest in pyramid schemes, blessing circles, overpriced insurance packages, corrupt ministries, miracle crusades, and football teams that haven’t kicked a ball in years. Anything wrapped in emotion, religion, or political flag-waving gets support—no questions asked.

Bitcoin, on the other hand, demands research, self-custody, and personal responsibility. That’s not sexy in a culture where people would rather “leave it to God,” “vote them out,” or “put some pressure on the boss man.”

🧠 The Mindset Gap

There’s a deep psychological barrier here:

Fear of responsibility: Bitcoin doesn’t come with customer service. It puts you in control—and that scares people used to blaming the bank, the government, or the devil.

Love for middlemen: Whether it’s pastors, politicians, or financiers, Trinidad loves an “intercessor.” Bitcoin removes them all.

Resistance to abstraction: We’re tactile people. We want paper receipts, printed statements, and "real money." Bitcoin’s digital nature makes it feel unreal—despite being harder money than the TT dollar will ever be.

🔥 What Gets Us Excited

Let a pastor say God told him to buy a jet—people pledge money.

Let a politician promise a ghost job—people campaign.

Let a friend say he knows a man that can flip $100 into $500—people sign up.

But tell someone to download a Bitcoin wallet, learn about self-custody, and opt out of inflation?

They tell you that’s a scam.

⚖️ The Harsh Reality

Trinidad is on the brink of a currency crisis. The TT dollar is quietly bleeding value. Bank fees rise, foreign exchange is a riddle, and financial surveillance is tightening.

Bitcoin is an escape hatch—but it requires a new kind of mindset: one rooted in self-education, long-term thinking, and personal accountability. These aren’t values we currently celebrate—but they are values we desperately need.

🟠 A Guide to Starting with Bitcoin in Trinidad

1. Understand Bitcoin

It’s not a stock or company. It’s a decentralized protocol like email—but for money.

It’s finite. Only 21 million will ever exist.

It’s permissionless. No bank, government, or pastor can block your access.

1. Get a Wallet

Start with Phoenix Wallet or Blue Wallet (for Lightning).

If you're going offline, learn about SeedSigner or Trezor for cold storage.

1. Earn or Buy BTC

Use Robosats or Peach for peer-to-peer (P2P) trading.

Ask your clients to pay in Bitcoin.

Zap content on Nostr to earn sats.

1. Secure It

Learn about seed phrases, hardware wallets, and multisig options.

Never leave your coins on exchanges.

Consider a steel backup plate.

1. Use It

Pay others in BTC.

Accept BTC for services.

Donate to freedom tech projects or communities building open internet tools.

🧭 Case In Point

Bitcoin isn’t just technology. It’s a mirror—one that reveals who we really are. Trinidad isn’t slow to adopt Bitcoin because it’s hard. We’re slow because we don’t want to let go of the comfort of being misled.

But times are changing. And the first person to wake up usually ends up leading the others.

So maybe it’s time.

Maybe you are the one to bring Bitcoin to Trinidad—not by shouting, but by living it.

@ d34e832d:383f78d0

The inherent heterogeneity of relay types within this ecosystem not only enhances operational agility but also significantly contributes to the overall robustness and resilience of the network architecture, empowering it to endure systemic assaults or coordinated initiatives designed to suppress specific content.

In examining the technical underpinnings of the Nostr protocol, relays are characterized by their exceptional adaptability, permitting deployment across an extensive variety of hosting environments configured to achieve targeted operational objectives.

For example, strategically deploying relays in jurisdictions characterized by robust legal protections for free expression can provide effective countermeasures against local censorship and pervasive legal restrictions in regions plagued by oppressive control.

This strategic operational framework mirrors the approaches adopted by whistleblowers and activists who deliberately position their digital platforms or mirrored content within territories boasting more favorable regulatory environments regarding internet freedoms.

Alternatively, relays may also be meticulously configured to operate exclusively within offline contexts—functioning within localized area networks or leveraging air-gapped computational configurations.

Such offline relays are indispensable in scenarios necessitating disaster recovery, secure communication frameworks, or methods for grassroots documentation, thereby safeguarding sensitive data from unauthorized access, ensuring its integrity against tampering, and preserving resilience in the face of both potential disruptions in internet connectivity and overarching surveillance efforts.

@ d34e832d:383f78d0

Listr

Lister.lol represents a sophisticated web application engineered specifically for the administration and management of Nostr lists. This feature is intrinsically embedded within the Nostr protocol, facilitating users in the curation of personalized feeds and the exploration of novel content. Although its current functionality remains relatively rudimentary, the platform encapsulates substantial potential for enhanced collaborative list management, as well as seamless integration with disparate client applications, effectively functioning as a micro-app within the broader ecosystem.

The trajectory of Nostr is oriented towards the development of robust developer tools (namely, the Nostr Development Kit - NDK), the establishment of comprehensive educational resources, and the cultivation of a dynamic and engaged community of developers and builders.

The overarching strategy emphasizes a decentralized paradigm, prioritizing the growth of small-scale, sustainable enterprises over the dominance of large, centralized corporations. In this regard, a rigorous experimentation with diverse monetization frameworks and the establishment of straightforward, user-friendly applications are deemed critical for the sustained evolution and scalability of the Nostr platform. Nostr's commitment to a decentralized, 'nagar-style' model of development distinguishes it markedly from the more conventional 'cathedral' methodologies employed by other platforms. As it fosters a broad spectrum of developmental outcomes while inherently embracing the properties of emergence. Such principles stand in stark contrast to within a traditional environment, centralized Web2 startup ecosystem, which is why all people need a chance to develop a significant shift towards a more adaptive and responsive design philosophy in involving #Nostr and #Bitcoin.

@ 4ba8e86d:89d32de4

Tutorial feito por nostr:nostr:npub1rc56x0ek0dd303eph523g3chm0wmrs5wdk6vs0ehd0m5fn8t7y4sqra3tk poste original abaixo:

Parte 1 : http://xh6liiypqffzwnu5734ucwps37tn2g6npthvugz3gdoqpikujju525yd.onion/263585/tutorial-debloat-de-celulares-android-via-adb-parte-1

Parte 2 : http://xh6liiypqffzwnu5734ucwps37tn2g6npthvugz3gdoqpikujju525yd.onion/index.php/263586/tutorial-debloat-de-celulares-android-via-adb-parte-2

Quando o assunto é privacidade em celulares, uma das medidas comumente mencionadas é a remoção de bloatwares do dispositivo, também chamado de debloat. O meio mais eficiente para isso sem dúvidas é a troca de sistema operacional. Custom Rom’s como LineageOS, GrapheneOS, Iodé, CalyxOS, etc, já são bastante enxutos nesse quesito, principalmente quanto não é instalado os G-Apps com o sistema. No entanto, essa prática pode acabar resultando em problemas indesejados como a perca de funções do dispositivo, e até mesmo incompatibilidade com apps bancários, tornando este método mais atrativo para quem possui mais de um dispositivo e separando um apenas para privacidade.   Pensando nisso, pessoas que possuem apenas um único dispositivo móvel, que são necessitadas desses apps ou funções, mas, ao mesmo tempo, tem essa visão em prol da privacidade, buscam por um meio-termo entre manter a Stock rom, e não ter seus dados coletados por esses bloatwares. Felizmente, a remoção de bloatwares é possível e pode ser realizada via root, ou mais da maneira que este artigo irá tratar, via adb.

O que são bloatwares?

Bloatware é a junção das palavras bloat (inchar) + software (programa), ou seja, um bloatware é basicamente um programa inútil ou facilmente substituível — colocado em seu dispositivo previamente pela fabricante e operadora — que está no seu dispositivo apenas ocupando espaço de armazenamento, consumindo memória RAM e pior, coletando seus dados e enviando para servidores externos, além de serem mais pontos de vulnerabilidades.

O que é o adb?

O Android Debug Brigde, ou apenas adb, é uma ferramenta que se utiliza das permissões de usuário shell e permite o envio de comandos vindo de um computador para um dispositivo Android exigindo apenas que a depuração USB esteja ativa, mas também pode ser usada diretamente no celular a partir do Android 11, com o uso do Termux e a depuração sem fio (ou depuração wifi). A ferramenta funciona normalmente em dispositivos sem root, e também funciona caso o celular esteja em Recovery Mode.

Requisitos:

Para computadores:

• Depuração USB ativa no celular; • Computador com adb; • Cabo USB;

Para celulares:

• Depuração sem fio (ou depuração wifi) ativa no celular; • Termux; • Android 11 ou superior;

Para ambos:

• Firewall NetGuard instalado e configurado no celular; • Lista de bloatwares para seu dispositivo;

Ativação de depuração:

Para ativar a Depuração USB em seu dispositivo, pesquise como ativar as opções de desenvolvedor de seu dispositivo, e lá ative a depuração. No caso da depuração sem fio, sua ativação irá ser necessária apenas no momento que for conectar o dispositivo ao Termux.

Instalação e configuração do NetGuard

O NetGuard pode ser instalado através da própria Google Play Store, mas de preferência instale pela F-Droid ou Github para evitar telemetria.

F-Droid: https://f-droid.org/packages/eu.faircode.netguard/

Github: https://github.com/M66B/NetGuard/releases

Após instalado, configure da seguinte maneira:

Configurações → padrões (lista branca/negra) → ative as 3 primeiras opções (bloquear wifi, bloquear dados móveis e aplicar regras ‘quando tela estiver ligada’);

Configurações → opções avançadas → ative as duas primeiras (administrar aplicativos do sistema e registrar acesso a internet);

Com isso, todos os apps estarão sendo bloqueados de acessar a internet, seja por wifi ou dados móveis, e na página principal do app basta permitir o acesso a rede para os apps que você vai usar (se necessário). Permita que o app rode em segundo plano sem restrição da otimização de bateria, assim quando o celular ligar, ele já estará ativo.

Lista de bloatwares

Nem todos os bloatwares são genéricos, haverá bloatwares diferentes conforme a marca, modelo, versão do Android, e até mesmo região.

Para obter uma lista de bloatwares de seu dispositivo, caso seu aparelho já possua um tempo de existência, você encontrará listas prontas facilmente apenas pesquisando por elas. Supondo que temos um Samsung Galaxy Note 10 Plus em mãos, basta pesquisar em seu motor de busca por:

Samsung Galaxy Note 10 Plus bloatware list

Provavelmente essas listas já terão inclusas todos os bloatwares das mais diversas regiões, lhe poupando o trabalho de buscar por alguma lista mais específica.

Caso seu aparelho seja muito recente, e/ou não encontre uma lista pronta de bloatwares, devo dizer que você acaba de pegar em merda, pois é chato para um caralho pesquisar por cada aplicação para saber sua função, se é essencial para o sistema ou se é facilmente substituível.

De antemão já aviso, que mais para frente, caso vossa gostosura remova um desses aplicativos que era essencial para o sistema sem saber, vai acabar resultando na perda de alguma função importante, ou pior, ao reiniciar o aparelho o sistema pode estar quebrado, lhe obrigando a seguir com uma formatação, e repetir todo o processo novamente.

Download do adb em computadores

Para usar a ferramenta do adb em computadores, basta baixar o pacote chamado SDK platform-tools, disponível através deste link: https://developer.android.com/tools/releases/platform-tools. Por ele, você consegue o download para Windows, Mac e Linux.

Uma vez baixado, basta extrair o arquivo zipado, contendo dentro dele uma pasta chamada platform-tools que basta ser aberta no terminal para se usar o adb.

Download do adb em celulares com Termux.

Para usar a ferramenta do adb diretamente no celular, antes temos que baixar o app Termux, que é um emulador de terminal linux, e já possui o adb em seu repositório. Você encontra o app na Google Play Store, mas novamente recomendo baixar pela F-Droid ou diretamente no Github do projeto.

F-Droid: https://f-droid.org/en/packages/com.termux/

Github: https://github.com/termux/termux-app/releases

Processo de debloat

Antes de iniciarmos, é importante deixar claro que não é para você sair removendo todos os bloatwares de cara sem mais nem menos, afinal alguns deles precisam antes ser substituídos, podem ser essenciais para você para alguma atividade ou função, ou até mesmo são insubstituíveis.

Alguns exemplos de bloatwares que a substituição é necessária antes da remoção, é o Launcher, afinal, é a interface gráfica do sistema, e o teclado, que sem ele só é possível digitar com teclado externo. O Launcher e teclado podem ser substituídos por quaisquer outros, minha recomendação pessoal é por aqueles que respeitam sua privacidade, como Pie Launcher e Simple Laucher, enquanto o teclado pelo OpenBoard e FlorisBoard, todos open-source e disponíveis da F-Droid.

Identifique entre a lista de bloatwares, quais você gosta, precisa ou prefere não substituir, de maneira alguma você é obrigado a remover todos os bloatwares possíveis, modifique seu sistema a seu bel-prazer. O NetGuard lista todos os apps do celular com o nome do pacote, com isso você pode filtrar bem qual deles não remover.

Um exemplo claro de bloatware insubstituível e, portanto, não pode ser removido, é o com.android.mtp, um protocolo onde sua função é auxiliar a comunicação do dispositivo com um computador via USB, mas por algum motivo, tem acesso a rede e se comunica frequentemente com servidores externos. Para esses casos, e melhor solução mesmo é bloquear o acesso a rede desses bloatwares com o NetGuard.

MTP tentando comunicação com servidores externos:

Executando o adb shell

No computador

Faça backup de todos os seus arquivos importantes para algum armazenamento externo, e formate seu celular com o hard reset. Após a formatação, e a ativação da depuração USB, conecte seu aparelho e o pc com o auxílio de um cabo USB. Muito provavelmente seu dispositivo irá apenas começar a carregar, por isso permita a transferência de dados, para que o computador consiga se comunicar normalmente com o celular.

Já no pc, abra a pasta platform-tools dentro do terminal, e execute o seguinte comando:

./adb start-server

O resultado deve ser:

daemon not running; starting now at tcp:5037 daemon started successfully

E caso não apareça nada, execute:

./adb kill-server

E inicie novamente.

Com o adb conectado ao celular, execute:

./adb shell

Para poder executar comandos diretamente para o dispositivo. No meu caso, meu celular é um Redmi Note 8 Pro, codinome Begonia.

Logo o resultado deve ser:

begonia:/ $

Caso ocorra algum erro do tipo:

adb: device unauthorized. This adb server’s $ADB_VENDOR_KEYS is not set Try ‘adb kill-server’ if that seems wrong. Otherwise check for a confirmation dialog on your device.

Verifique no celular se apareceu alguma confirmação para autorizar a depuração USB, caso sim, autorize e tente novamente. Caso não apareça nada, execute o kill-server e repita o processo.

No celular

Após realizar o mesmo processo de backup e hard reset citado anteriormente, instale o Termux e, com ele iniciado, execute o comando:

pkg install android-tools

Quando surgir a mensagem “Do you want to continue? [Y/n]”, basta dar enter novamente que já aceita e finaliza a instalação

Agora, vá até as opções de desenvolvedor, e ative a depuração sem fio. Dentro das opções da depuração sem fio, terá uma opção de emparelhamento do dispositivo com um código, que irá informar para você um código em emparelhamento, com um endereço IP e porta, que será usado para a conexão com o Termux.

Para facilitar o processo, recomendo que abra tanto as configurações quanto o Termux ao mesmo tempo, e divida a tela com os dois app’s, como da maneira a seguir:

Para parear o Termux com o dispositivo, não é necessário digitar o ip informado, basta trocar por “localhost”, já a porta e o código de emparelhamento, deve ser digitado exatamente como informado. Execute:

adb pair localhost:porta CódigoDeEmparelhamento

De acordo com a imagem mostrada anteriormente, o comando ficaria “adb pair localhost:41255 757495”.

Com o dispositivo emparelhado com o Termux, agora basta conectar para conseguir executar os comandos, para isso execute:

adb connect localhost:porta

Obs: a porta que você deve informar neste comando não é a mesma informada com o código de emparelhamento, e sim a informada na tela principal da depuração sem fio.

Pronto! Termux e adb conectado com sucesso ao dispositivo, agora basta executar normalmente o adb shell:

adb shell

Remoção na prática Com o adb shell executado, você está pronto para remover os bloatwares. No meu caso, irei mostrar apenas a remoção de um app (Google Maps), já que o comando é o mesmo para qualquer outro, mudando apenas o nome do pacote.

Dentro do NetGuard, verificando as informações do Google Maps:

Podemos ver que mesmo fora de uso, e com a localização do dispositivo desativado, o app está tentando loucamente se comunicar com servidores externos, e informar sabe-se lá que peste. Mas sem novidades até aqui, o mais importante é que podemos ver que o nome do pacote do Google Maps é com.google.android.apps.maps, e para o remover do celular, basta executar:

pm uninstall –user 0 com.google.android.apps.maps

E pronto, bloatware removido! Agora basta repetir o processo para o resto dos bloatwares, trocando apenas o nome do pacote.

Para acelerar o processo, você pode já criar uma lista do bloco de notas com os comandos, e quando colar no terminal, irá executar um atrás do outro.

Exemplo de lista:

Caso a donzela tenha removido alguma coisa sem querer, também é possível recuperar o pacote com o comando:

cmd package install-existing nome.do.pacote

Pós-debloat

Após limpar o máximo possível o seu sistema, reinicie o aparelho, caso entre no como recovery e não seja possível dar reboot, significa que você removeu algum app “essencial” para o sistema, e terá que formatar o aparelho e repetir toda a remoção novamente, desta vez removendo poucos bloatwares de uma vez, e reiniciando o aparelho até descobrir qual deles não pode ser removido. Sim, dá trabalho… quem mandou querer privacidade?

Caso o aparelho reinicie normalmente após a remoção, parabéns, agora basta usar seu celular como bem entender! Mantenha o NetGuard sempre executando e os bloatwares que não foram possíveis remover não irão se comunicar com servidores externos, passe a usar apps open source da F-Droid e instale outros apps através da Aurora Store ao invés da Google Play Store.

Referências: Caso você seja um Australopithecus e tenha achado este guia difícil, eis uma videoaula (3:14:40) do Anderson do canal Ciberdef, realizando todo o processo: http://odysee.com/@zai:5/Como-remover-at%C3%A9-200-APLICATIVOS-que-colocam-a-sua-PRIVACIDADE-E-SEGURAN%C3%87A-em-risco.:4?lid=6d50f40314eee7e2f218536d9e5d300290931d23

Pdf’s do Anderson citados na videoaula: créditos ao anon6837264 http://eternalcbrzpicytj4zyguygpmkjlkddxob7tptlr25cdipe5svyqoqd.onion/file/3863a834d29285d397b73a4af6fb1bbe67c888d72d30/t-05e63192d02ffd.pdf

Processo de instalação do Termux e adb no celular: https://youtu.be/APolZrPHSms

@ 4ba8e86d:89d32de4

SISTEMA OPERACIONAL MÓVEIS

GrapheneOS : https://njump.me/nevent1qqs8t76evdgrg4qegdtyrq2rved63pr29wlqyj627n9tj4vlu66tqpqpzdmhxue69uhk7enxvd5xz6tw9ec82c30qgsyh28gd5ke0ztdeyehc0jsq6gcj0tnzatjlkql3dqamkja38fjmeqrqsqqqqqppcqec9

CalyxOS : https://njump.me/nevent1qqsrm0lws2atln2kt3cqjacathnw0uj0jsxwklt37p7t380hl8mmstcpydmhxue69uhkummnw3ez6an9wf5kv6t9vsh8wetvd3hhyer9wghxuet59uq3vamnwvaz7tmwdaehgu3wvf3kstnwd9hx5cf0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgcwaehxw309aex2mrp0yhxxatjwfjkuapwveukjtcpzpmhxue69uhkummnw3ezumt0d5hszrnhwden5te0dehhxtnvdakz7qfywaehxw309ahx7um5wgh8ymm4dej8ymmrdd3xjarrda5kuetjwvhxxmmd9uq3uamnwvaz7tmwdaehgu3dv3jhvtnhv4kxcmmjv3jhytnwv46z7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qgewaehxw309ahx7um5wghxymmwva3x7mn89e3k7mf0qythwumn8ghj7cn5vvhxkmr9dejxz7n49e3k7mf0qyg8wumn8ghj7mn09eehgu3wvdez7smttdu

LineageOS : https://njump.me/nevent1qqsgw7sr36gaty48cf4snw0ezg5mg4atzhqayuge752esd469p26qfgpzdmhxue69uhhwmm59e6hg7r09ehkuef0qgsyh28gd5ke0ztdeyehc0jsq6gcj0tnzatjlkql3dqamkja38fjmeqrqsqqqqqpnvm779

SISTEMA OPERACIONAL DESKTOP

Tails : https://njump.me/nevent1qqsf09ztvuu60g6xprazv2vxqqy5qlxjs4dkc9d36ta48q75cs9le4qpzemhxue69uhkummnw3ex2mrfw3jhxtn0wfnj7q3qfw5wsmfdj7ykmjfn0sl9qp533y7hx96h9lvplz6pmhd9mzwn9hjqxpqqqqqqz34ag5t

Qubes OS : https://njump.me/nevent1qqsp6jujgwl68uvurw0cw3hfhr40xq20sj7rl3z4yzwnhp9sdpa7augpzpmhxue69uhkummnw3ezumt0d5hsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsz9thwden5te0dehhxarj9ehhsarj9ejx2a30qyg8wumn8ghj7mn09eehgu3wvdez7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uqjxamnwvaz7tmwdaehgu3dwejhy6txd9jkgtnhv4kxcmmjv3jhytnwv46z7qgwwaehxw309ahx7uewd3hkctcpremhxue69uhkummnw3ez6er9wch8wetvd3hhyer9wghxuet59uj3ljr8

Kali linux : https://njump.me/nevent1qqswlav72xdvamuyp9xc38c6t7070l3n2uxu67ssmal2g7gv35nmvhspzpmhxue69uhkumewwd68ytnrwghsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqswt9rxe

Whonix : https://njump.me/nevent1qqs85gvejvzhk086lwh6edma7fv07p5c3wnwnxnzthwwntg2x6773egpydmhxue69uhkummnw3ez6an9wf5kv6t9vsh8wetvd3hhyer9wghxuet59uq3qamnwvaz7tmwdaehgu3wd4hk6tcpzemhxue69uhkummnw3ezucnrdqhxu6twdfsj7qfywaehxw309ahx7um5wgh8ymm4dej8ymmrdd3xjarrda5kuetjwvhxxmmd9uq3wamnwvaz7tmzw33ju6mvv4hxgct6w5hxxmmd9uq3qamnwvaz7tmwduh8xarj9e3hytcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qg7waehxw309ahx7um5wgkkgetk9emk2mrvdaexgetj9ehx2ap0sen9p6

Kodachi : https://njump.me/nevent1qqsf5zszgurpd0vwdznzk98hck294zygw0s8dah6fpd309ecpreqtrgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszgmhwden5te0dehhxarj94mx2unfve5k2epwwajkcmr0wfjx2u3wdejhgtcpremhxue69uhkummnw3ez6er9wch8wetvd3hhyer9wghxuet59uq3qamnwvaz7tmwdaehgu3wd4hk6tcpzamhxue69uhkyarr9e4kcetwv3sh5afwvdhk6tcpzpmhxue69uhkumewwd68ytnrwghszfrhwden5te0dehhxarj9eex7atwv3ex7cmtvf5hgcm0d9hx2unn9e3k7mf0qyvhwumn8ghj7mn0wd68ytnzdahxwcn0denjucm0d5hszrnhwden5te0dehhxtnvdakz7qgkwaehxw309ahx7um5wghxycmg9ehxjmn2vyhsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshs94a4d5

PGP

Openkeychain : https://njump.me/nevent1qqs9qtjgsulp76t7jkquf8nk8txs2ftsr0qke6mjmsc2svtwfvswzyqpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqs36mp0w

Kleopatra : https://njump.me/nevent1qqspnevn932hdggvp4zam6mfyce0hmnxsp9wp8htpumq9vm3anq6etsppemhxue69uhkummn9ekx7mp0qgsyh28gd5ke0ztdeyehc0jsq6gcj0tnzatjlkql3dqamkja38fjmeqrqsqqqqqpuaeghp

Pgp : https://njump.me/nevent1qqsggek707qf3rzttextmgqhym6d4g479jdnlnj78j96y0ut0x9nemcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyp9636rd9ktcjmwfxd7ru5qxjxyn6uch2uhas8utg8wa5hvf6vk7gqcyqqqqqqgptemhe

Como funciona o PGP? : https://njump.me/nevent1qqsz9r7azc8pkvfmkg2hv0nufaexjtnvga0yl85x9hu7ptpg20gxxpspremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59upzqjagapkjm9ufdhynxlp72qrfrzfawvt4wt7cr795rhw6tkyaxt0yqvzqqqqqqy259fhs

Por que eu escrevi PGP. - Philip Zimmermann.

https://njump.me/nevent1qqsvysn94gm8prxn3jw04r0xwc6sngkskg756z48jsyrmqssvxtm7ncpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtchzxnad

VPN

Vpn : https://njump.me/nevent1qqs27ltgsr6mh4ffpseexz6s37355df3zsur709d0s89u2nugpcygsspzpmhxue69uhkummnw3ezumt0d5hsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqshzu2fk

InviZible Pro : https://njump.me/nevent1qqsvyevf2vld23a3xrpvarc72ndpcmfvc3lc45jej0j5kcsg36jq53cpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzqjagapkjm9ufdhynxlp72qrfrzfawvt4wt7cr795rhw6tkyaxt0yqvzqqqqqqy33y5l4

Orbot: https://njump.me/nevent1qqsxswkyt6pe34egxp9w70cy83h40ururj6m9sxjdmfass4cjm4495stft593

I2P

i2p : https://njump.me/nevent1qqsvnj8n983r4knwjmnkfyum242q4c0cnd338l4z8p0m6xsmx89mxkslx0pgg

Entendendo e usando a rede I2P : https://njump.me/nevent1qqsxchp5ycpatjf5s4ag25jkawmw6kkf64vl43vnprxdcwrpnms9qkcppemhxue69uhkummn9ekx7mp0qgsyh28gd5ke0ztdeyehc0jsq6gcj0tnzatjlkql3dqamkja38fjmeqrqsqqqqqpvht4mn

Criando e acessando sua conta Email na I2P : https://njump.me/nevent1qqs9v9dz897kh8e5lfar0dl7ljltf2fpdathsn3dkdsq7wg4ksr8xfgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgsyh28gd5ke0ztdeyehc0jsq6gcj0tnzatjlkql3dqamkja38fjmeqrqsqqqqqpw8mzum

APLICATIVO 2FA

Aegis Authenticator : https://njump.me/nevent1qqsfttdwcn9equlrmtf9n6wee7lqntppzm03pzdcj4cdnxel3pz44zspz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqscvtydq

YubiKey : https://njump.me/nevent1qqstsnn69y4sf4330n7039zxm7wza3ch7sn6plhzmd57w6j9jssavtspvemhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0dec82c330g6x6dm8ddmxzdne0pnhverevdkxxdm6wqc8v735w3snquejvsuk56pcvuurxaesxd68qdtkv3nrx6m6v3ehsctwvym8q0mzwfhkzerrv9ehg0t5wf6k2q3qfw5wsmfdj7ykmjfn0sl9qp533y7hx96h9lvplz6pmhd9mzwn9hjqxpqqqqqqzueyvgt

GERENCIADOR DE SENHAS

KeepassDX: https://njump.me/nevent1qqswc850dr4ujvxnmpx75jauflf4arc93pqsty5pv8hxdm7lcw8ee8qpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgsyh28gd5ke0ztdeyehc0jsq6gcj0tnzatjlkql3dqamkja38fjmeqrqsqqqqqpe0492n

Birwaden: https://njump.me/nevent1qqs0j5x9guk2v6xumhwqmftmcz736m9nm9wzacqwjarxmh8k4xdyzwgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgsyh28gd5ke0ztdeyehc0jsq6gcj0tnzatjlkql3dqamkja38fjmeqrqsqqqqqpwfe2kc

KeePassXC: https://njump.me/nevent1qqsgftcrd8eau7tzr2p9lecuaf7z8mx5jl9w2k66ae3lzkw5wqcy5pcl2achp

CHAT MENSAGEM

SimpleXchat : https://njump.me/nevent1qqsds5xselnnu0dyy0j49peuun72snxcgn3u55d2320n37rja9gk8lgzyp9636rd9ktcjmwfxd7ru5qxjxyn6uch2uhas8utg8wa5hvf6vk7gqcyqqqqqqgmcmj7c

Briar : https://njump.me/nevent1qqs8rrtgvjr499hreugetrl7adkhsj2zextyfsukq5aa7wxthrgcqcg05n434

Element Messenger : https://njump.me/nevent1qqsq05snlqtxm5cpzkshlf8n5d5rj9383vjytkvqp5gta37hpuwt4mqyccee6

Pidgin : https://njump.me/nevent1qqsz7kngycyx7meckx53xk8ahk98jkh400usrvykh480xa4ct9zlx2c2ywvx3

E-MAIL

Thunderbird: https://njump.me/nevent1qqspq64gg0nw7t60zsvea5eykgrm43paz845e4jn74muw5qzdvve7uqrkwtjh

ProtonMail : https://njump.me/nevent1qqs908glhk68e7ms8zqtlsqd00wu3prnpt08dwre26hd6e5fhqdw99cppemhxue69uhkummn9ekx7mp0qgsyh28gd5ke0ztdeyehc0jsq6gcj0tnzatjlkql3dqamkja38fjmeqrqsqqqqqpeyhg4z

Tutonota : https://njump.me/nevent1qqswtzh9zjxfey644qy4jsdh9465qcqd2wefx0jxa54gdckxjvkrrmqpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqs5hzhkv

k-9 mail : https://njump.me/nevent1qqs200g5a603y7utjgjk320r3srurrc4r66nv93mcg0x9umrw52ku5gpr3mhxue69uhkummnw3ezuumhd9ehxtt9de5kwmtp9e3kstczyp9636rd9ktcjmwfxd7ru5qxjxyn6uch2uhas8utg8wa5hvf6vk7gqcyqqqqqqgacflak

E-MAIL-ALIÁS

Simplelogin : https://njump.me/nevent1qqsvhz5pxqpqzr2ptanqyqgsjr50v7u9lc083fvdnglhrv36rnceppcppemhxue69uhkummn9ekx7mp0qgsyh28gd5ke0ztdeyehc0jsq6gcj0tnzatjlkql3dqamkja38fjmeqrqsqqqqqp9gsr7m

AnonAddy : https://njump.me/nevent1qqs9mcth70mkq2z25ws634qfn7vx2mlva3tkllayxergw0s7p8d3ggcpzpmhxue69uhkummnw3ezumt0d5hsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqs6mawe3

NAVEGADOR

Navegador Tor : https://njump.me/nevent1qqs06qfxy7wzqmk76l5d8vwyg6mvcye864xla5up52fy5sptcdy39lspzemhxue69uhkummnw3ezuerpw3sju6rpw4ej7q3qfw5wsmfdj7ykmjfn0sl9qp533y7hx96h9lvplz6pmhd9mzwn9hjqxpqqqqqqzdp0urw

Mullvap Browser : https://njump.me/nevent1qqs2vsgc3wk09wdspv2mezltgg7nfdg97g0a0m5cmvkvr4nrfxluzfcpzdmhxue69uhhwmm59e6hg7r09ehkuef0qgsyh28gd5ke0ztdeyehc0jsq6gcj0tnzatjlkql3dqamkja38fjmeqrqsqqqqqpj8h6fe

LibreWolf : https://njump.me/nevent1qqswv05mlmkcuvwhe8x3u5f0kgwzug7n2ltm68fr3j06xy9qalxwq2cpzemhxue69uhkummnw3ex2mrfw3jhxtn0wfnj7q3qfw5wsmfdj7ykmjfn0sl9qp533y7hx96h9lvplz6pmhd9mzwn9hjqxpqqqqqqzuv2hxr

Cromite : https://njump.me/nevent1qqs2ut83arlu735xp8jf87w5m3vykl4lv5nwkhldkqwu3l86khzzy4cpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqs3dplt7

BUSCADORES

Searx : https://njump.me/nevent1qqsxyzpvgzx00n50nrlgctmy497vkm2cm8dd5pdp7fmw6uh8xnxdmaspr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgsyh28gd5ke0ztdeyehc0jsq6gcj0tnzatjlkql3dqamkja38fjmeqrqsqqqqqp23z7ax

APP-STORE

Obtainium : https://njump.me/nevent1qqstd8kzc5w3t2v6dgf36z0qrruufzfgnc53rj88zcjgsagj5c5k4rgpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzqjagapkjm9ufdhynxlp72qrfrzfawvt4wt7cr795rhw6tkyaxt0yqvzqqqqqqyarmca3

F-Droid : https://njump.me/nevent1qqst4kry49cc9g3g8s5gdnpgyk3gjte079jdnv43f0x4e85cjkxzjesymzuu4

Droid-ify : https://njump.me/nevent1qqsrr8yu9luq0gud902erdh8gw2lfunpe93uc2u6g8rh9ep7wt3v4sgpzpmhxue69uhkummnw3ezumt0d5hsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqsfzu9vk

Aurora Store : https://njump.me/nevent1qqsy69kcaf0zkcg0qnu90mtk46ly3p2jplgpzgk62wzspjqjft4fpjgpvemhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0dec82c330g6x6dm8ddmxzdne0pnhverevdkxxdm6wqc8v735w3snquejvsuk56pcvuurxaesxd68qdtkv3nrx6m6v3ehsctwvym8q0mzwfhkzerrv9ehg0t5wf6k2q3qfw5wsmfdj7ykmjfn0sl9qp533y7hx96h9lvplz6pmhd9mzwn9hjqxpqqqqqqzrpmsjy

RSS

Feeder : https://njump.me/nevent1qqsy29aeggpkmrc7t3c7y7ldgda7pszl7c8hh9zux80gjzrfvlhfhwqpp4mhxue69uhkummn9ekx7mqzyp9636rd9ktcjmwfxd7ru5qxjxyn6uch2uhas8utg8wa5hvf6vk7gqcyqqqqqqgsvzzjy

VIDEOO CONFERENCIA

Jitsi meet : https://njump.me/nevent1qqswphw67hr6qmt2fpugcj77jrk7qkfdrszum7vw7n2cu6cx4r6sh4cgkderr

TECLADOS

HeliBoard : https://njump.me/nevent1qqsyqpc4d28rje03dcvshv4xserftahhpeylu2ez2jutdxwds4e8syspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqsr8mel5

OpenBoard : https://njump.me/nevent1qqsf7zqkup03yysy67y43nj48q53sr6yym38es655fh9fp6nxpl7rqspzpmhxue69uhkumewwd68ytnrwghsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqswcvh3r

FlorisBoard : https://njump.me/nevent1qqsf7zqkup03yysy67y43nj48q53sr6yym38es655fh9fp6nxpl7rqspzpmhxue69uhkumewwd68ytnrwghsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqswcvh3r

MAPAS

Osmand : https://njump.me/nevent1qqsxryp2ywj64az7n5p6jq5tn3tx5jv05te48dtmmt3lf94ydtgy4fgpzpmhxue69uhkumewwd68ytnrwghsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqs54nwpj

Organic maps : https://njump.me/nevent1qqstrecuuzkw0dyusxdq7cuwju0ftskl7anx978s5dyn4pnldrkckzqpr4mhxue69uhkummnw3ezumtp0p5k6ctrd96xzer9dshx7un8qgsyh28gd5ke0ztdeyehc0jsq6gcj0tnzatjlkql3dqamkja38fjmeqrqsqqqqqpl8z3kk

TRADUÇÃO

LibreTranslate : https://njump.me/nevent1qqs953g3rhf0m8jh59204uskzz56em9xdrjkelv4wnkr07huk20442cpvemhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0dec82c330g6x6dm8ddmxzdne0pnhverevdkxxdm6wqc8v735w3snquejvsuk56pcvuurxaesxd68qdtkv3nrx6m6v3ehsctwvym8q0mzwfhkzerrv9ehg0t5wf6k2q3qfw5wsmfdj7ykmjfn0sl9qp533y7hx96h9lvplz6pmhd9mzwn9hjqxpqqqqqqzeqsx40

REMOÇÃO DOS METADADOS

Scrambled Exif : https://njump.me/nevent1qqs2658t702xv66p000y4mlhnvadmdxwzzfzcjkjf7kedrclr3ej7aspyfmhxue69uhk6atvw35hqmr90pjhytngw4eh5mmwv4nhjtnhdaexcep0qgsyh28gd5ke0ztdeyehc0jsq6gcj0tnzatjlkql3dqamkja38fjmeqrqsqqqqqpguu0wh

ESTEGANOGRAFIA

PixelKnot: https://njump.me/nevent1qqsrh0yh9mg0lx86t5wcmhh97wm6n4v0radh6sd0554ugn354wqdj8gpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzqjagapkjm9ufdhynxlp72qrfrzfawvt4wt7cr795rhw6tkyaxt0yqvzqqqqqqyuvfqdp

PERFIL DE TRABALHO

Shelter : https://njump.me/nevent1qqspv9xxkmfp40cxgjuyfsyczndzmpnl83e7gugm7480mp9zhv50wkqpvemhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0dec82c330g6x6dm8ddmxzdne0pnhverevdkxxdm6wqc8v735w3snquejvsuk56pcvuurxaesxd68qdtkv3nrx6m6v3ehsctwvym8q0mzwfhkzerrv9ehg0t5wf6k2q3qfw5wsmfdj7ykmjfn0sl9qp533y7hx96h9lvplz6pmhd9mzwn9hjqxpqqqqqqzdnu59c

PDF

MuPDF : https://njump.me/nevent1qqspn5lhe0dteys6npsrntmv2g470st8kh8p7hxxgmymqa95ejvxvfcpzpmhxue69uhkumewwd68ytnrwghsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqs4hvhvj

Librera Reader : https://njump.me/nevent1qqsg60flpuf00sash48fexvwxkly2j5z9wjvjrzt883t3eqng293f3cpvemhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0dec82c330g6x6dm8ddmxzdne0pnhverevdkxxdm6wqc8v735w3snquejvsuk56pcvuurxaesxd68qdtkv3nrx6m6v3ehsctwvym8q0mzwfhkzerrv9ehg0t5wf6k2q3qfw5wsmfdj7ykmjfn0sl9qp533y7hx96h9lvplz6pmhd9mzwn9hjqxpqqqqqqz39tt3n

QR-Code

Binary Eye : https://njump.me/nevent1qqsz4n0uxxx3q5m0r42n9key3hchtwyp73hgh8l958rtmae5u2khgpgpvemhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0dec82c330g6x6dm8ddmxzdne0pnhverevdkxxdm6wqc8v735w3snquejvsuk56pcvuurxaesxd68qdtkv3nrx6m6v3ehsctwvym8q0mzwfhkzerrv9ehg0t5wf6k2q3qfw5wsmfdj7ykmjfn0sl9qp533y7hx96h9lvplz6pmhd9mzwn9hjqxpqqqqqqzdmn4wp

Climático

Breezy Weather : https://njump.me/nevent1qqs9hjz5cz0y4am3kj33xn536uq85ydva775eqrml52mtnnpe898rzspzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyp9636rd9ktcjmwfxd7ru5qxjxyn6uch2uhas8utg8wa5hvf6vk7gqcyqqqqqqgpd3tu8

ENCRYPTS

Cryptomator : https://njump.me/nevent1qqsvchvnw779m20583llgg5nlu6ph5psewetlczfac5vgw83ydmfndspzpmhxue69uhkumewwd68ytnrwghsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqsx7ppw9

VeraCrypt : https://njump.me/nevent1qqsf6wzedsnrgq6hjk5c4jj66dxnplqwc4ygr46l8z3gfh38q2fdlwgm65ej3

EXTENSÕES

uBlock Origin : https://njump.me/nevent1qqswaa666lcj2c4nhnea8u4agjtu4l8q89xjln0yrngj7ssh72ntwzql8ssdj

Snowflake : https://njump.me/nevent1qqs0ws74zlt8uced3p2vee9td8x7vln2mkacp8szdufvs2ed94ctnwchce008

CLOUD

Nextcloud : https://njump.me/nevent1qqs2utg5z9htegdtrnllreuhypkk2026x8a0xdsmfczg9wdl8rgrcgg9nhgnm

NOTEPAD

Joplin : https://njump.me/nevent1qqsz2a0laecpelsznser3xd0jfa6ch2vpxtkx6vm6qg24e78xttpk0cpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgsyh28gd5ke0ztdeyehc0jsq6gcj0tnzatjlkql3dqamkja38fjmeqrqsqqqqqpdu0hft

Standard Notes : https://njump.me/nevent1qqsv3596kz3qung5v23cjc4cpq7rqxg08y36rmzgcrvw5whtme83y3s7tng6r

MÚSICA

RiMusic : https://njump.me/nevent1qqsv3genqav2tfjllp86ust4umxm8tr2wd9kq8x7vrjq6ssp363mn0gpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyp9636rd9ktcjmwfxd7ru5qxjxyn6uch2uhas8utg8wa5hvf6vk7gqcyqqqqqqg42353n

ViMusic : https://njump.me/nevent1qqswx78559l4jsxsrygd8kj32sch4qu57stxq0z6twwl450vp39pdqqpvemhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0dec82c330g6x6dm8ddmxzdne0pnhverevdkxxdm6wqc8v735w3snquejvsuk56pcvuurxaesxd68qdtkv3nrx6m6v3ehsctwvym8q0mzwfhkzerrv9ehg0t5wf6k2q3qfw5wsmfdj7ykmjfn0sl9qp533y7hx96h9lvplz6pmhd9mzwn9hjqxpqqqqqqzjg863j

PODCAST

AntennaPod : https://njump.me/nevent1qqsp4nh7k4a6zymfwqqdlxuz8ua6kdhvgeeh3uxf2c9rtp9u3e9ku8qnr8lmy

VISUALIZAR VIDEO

VLC : https://njump.me/nevent1qqs0lz56wtlr2eye4ajs2gzn2r0dscw4y66wezhx0mue6dffth8zugcl9laky

YOUTUBE

NewPipe : https://njump.me/nevent1qqsdg06qpcjdnlvgm4xzqdap0dgjrkjewhmh4j3v4mxdl4rjh8768mgdw9uln

FreeTube : https://njump.me/nevent1qqsz6y6z7ze5gs56s8seaws8v6m6j2zu0pxa955dhq3ythmexak38mcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqs5lkjvv

LibreTube : https://snort.social/e/nevent1qqstmd5m6wrdvn4gxf8xyhrwnlyaxmr89c9kjddvnvux6603f84t3fqpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqsswwznc

COMPARTILHAMENTO DE ARQUIVOS

OnionShare : https://njump.me/nevent1qqsr0a4ml5nu6ud5k9yzyawcd9arznnwkrc27dzzc95q6r50xmdff6qpydmhxue69uhkummnw3ez6an9wf5kv6t9vsh8wetvd3hhyer9wghxuet59uq3uamnwvaz7tmwdaehgu3dv3jhvtnhv4kxcmmjv3jhytnwv46z7qgswaehxw309ahx7tnnw3ezucmj9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpzamhxue69uhkyarr9e4kcetwv3sh5afwvdhk6tcpzemhxue69uhkummnw3ezucnrdqhxu6twdfsj7qgswaehxw309ahx7um5wghx6mmd9uqjgamnwvaz7tmwdaehgu3wwfhh2mnywfhkx6mzd96xxmmfdejhyuewvdhk6tcppemhxue69uhkummn9ekx7mp0qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qyv8wumn8ghj7un9d3shjtnrw4e8yetwwshxv7tf9ut7qurt

Localsend : https://njump.me/nevent1qqsp8ldjhrxm09cvvcak20hrc0g8qju9f67pw7rxr2y3euyggw9284gpvemhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0dec82c330g6x6dm8ddmxzdne0pnhverevdkxxdm6wqc8v735w3snquejvsuk56pcvuurxaesxd68qdtkv3nrx6m6v3ehsctwvym8q0mzwfhkzerrv9ehg0t5wf6k2q3qfw5wsmfdj7ykmjfn0sl9qp533y7hx96h9lvplz6pmhd9mzwn9hjqxpqqqqqqzuyghqr

Wallet Bitcoin

Ashigaru Wallet : https://njump.me/nevent1qqstx9fz8kf24wgl26un8usxwsqjvuec9f8q392llmga75tw0kfarfcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyp9636rd9ktcjmwfxd7ru5qxjxyn6uch2uhas8utg8wa5hvf6vk7gqcyqqqqqqgvfsrqp

Samourai Wallet : https://njump.me/nevent1qqstcvjmz39rmrnrv7t5cl6p3x7pzj6jsspyh4s4vcwd2lugmre04ecpr9mhxue69uhkummnw3ezucn0denkymmwvuhxxmmd9upzqjagapkjm9ufdhynxlp72qrfrzfawvt4wt7cr795rhw6tkyaxt0yqvzqqqqqqy3rg4qs

CÂMERA

opencamera : https://njump.me/nevent1qqs25glp6dh0crrjutxrgdjlnx9gtqpjtrkg29hlf7382aeyjd77jlqpzpmhxue69uhkumewwd68ytnrwghsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqssxcvgc

OFFICE

Collabora Office : https://njump.me/nevent1qqs8yn4ys6adpmeu3edmf580jhc3wluvlf823cc4ft4h0uqmfzdf99qpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqsj40uss

TEXTOS

O manifesto de um Cypherpunk : https://njump.me/nevent1qqsd7hdlg6galn5mcuv3pm3ryfjxc4tkyph0cfqqe4du4dr4z8amqyspvemhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0dec82c330g6x6dm8ddmxzdne0pnhverevdkxxdm6wqc8v735w3snquejvsuk56pcvuurxaesxd68qdtkv3nrx6m6v3ehsctwvym8q0mzwfhkzerrv9ehg0t5wf6k2q3qfw5wsmfdj7ykmjfn0sl9qp533y7hx96h9lvplz6pmhd9mzwn9hjqxpqqqqqqzal0efa

Operations security ( OPSEC) : https://snort.social/e/nevent1qqsp323havh3y9nxzd4qmm60hw87tm9gjns0mtzg8y309uf9mv85cqcpvemhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0dec82c330g6x6dm8ddmxzdne0pnhverevdkxxdm6wqc8v735w3snquejvsuk56pcvuurxaesxd68qdtkv3nrx6m6v3ehsctwvym8q0mzwfhkzerrv9ehg0t5wf6k2q3qfw5wsmfdj7ykmjfn0sl9qp533y7hx96h9lvplz6pmhd9mzwn9hjqxpqqqqqqz8ej9l7

O MANIFESTO CRIPTOANARQUISTA Timothy C. May – 1992. : https://njump.me/nevent1qqspp480wtyx2zhtwpu5gptrl8duv9rvq3mug85mp4d54qzywk3zq9gpvemhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0dec82c330g6x6dm8ddmxzdne0pnhverevdkxxdm6wqc8v735w3snquejvsuk56pcvuurxaesxd68qdtkv3nrx6m6v3ehsctwvym8q0mzwfhkzerrv9ehg0t5wf6k2q3qfw5wsmfdj7ykmjfn0sl9qp533y7hx96h9lvplz6pmhd9mzwn9hjqxpqqqqqqz5wq496

Declaração de independência do ciberespaço

• John Perry Barlow - 1996 : https://njump.me/nevent1qqs2njsy44n6p07mhgt2tnragvchasv386nf20ua5wklxqpttf6mzuqpzpmhxue69uhkummnw3ezumt0d5hsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqsukg4hr

The Cyphernomicon: Criptografia, Dinheiro Digital e o Futuro da Privacidade. escrito por Timothy C. May -Publicado em 1994. :

Livro completo em PDF no Github PrivacyOpenSource.

https://github.com/Alexemidio/PrivacyOpenSource/raw/main/Livros/THE%20CYPHERNOMICON%20.pdf Share

@ 3f770d65:7a745b24

At the recent Launch Music Festival and Conference in Lancaster, PA, featuring over 120 musicians across three days, I volunteered my time with Tunestr and Phantom Power Music's initiative to introduce artists to Bitcoin, Nostr, and the value-for-value model. Tunestr sponsored a stage, live-streaming 21 bands to platforms like Tunestr.io, Fountain.fm and other Nostr/Podcasting 2.0 apps and on-boarding as many others as possible at our conference booth. You may have seen me spamming about this over the last few days.

V4V Earnings

Day 1: 180,000 sats

Day 2: 300,000 sats

Day 3: Over 500,000 sats

Who?

Here are the artists that were on-boarded to Fountain and were live streaming on the Value-for-Value stage:

nostr:npub1cruu4z0hwg7n3r2k7262vx8jsmra3xpku85frl5fnfvrwz7rd7mq7e403w nostr:npub12xeh3n7w8700z4tpd6xlhlvg4vtg4pvpxd584ll5sva539tutc3q0tn3tz nostr:npub1rc80p4v60uzfhvdgxemhvcqnzdj7t59xujxdy0lcjxml3uwdezyqtrpe0j @npub16vxr4pc2ww3yaez9q4s53zkejjfd0djs9lfe55sjhnqkh nostr:npub10uspdzg4fl7md95mqnjszxx82ckdly8ezac0t3s06a0gsf4f3lys8ypeak nostr:npub1gnyzexr40qut0za2c4a0x27p4e3qc22wekhcw3uvdx8mwa3pen0s9z90wk nostr:npub13qrrw2h4z52m7jh0spefrwtysl4psfkfv6j4j672se5hkhvtyw7qu0almy nostr:npub1p0kuqxxw2mxczc90vcurvfq7ljuw2394kkqk6gqnn2cq0y9eq5nq87jtkk nostr:npub182kq0sdp7chm67uq58cf4vvl3lk37z8mm5k5067xe09fqqaaxjsqlcazej nostr:npub162hr8kd96vxlanvggl08hmyy37qsn8ehgj7za7squl83um56epnswkr399 nostr:npub17jzk5ex2rafres09c4dnn5mm00eejye6nrurnlla6yn22zcpl7vqg6vhvx nostr:npub176rnksulheuanfx8y8cr2mrth4lh33svvpztggjjm6j2pqw6m56sq7s9vz nostr:npub1akv7t7xpalhsc4nseljs0c886jzuhq8u42qdcwvu972f3mme9tjsgp5xxk nostr:npub18x0gv872489lrczp9d9m4hx59r754x7p9rg2jkgvt7ul3kuqewtqsssn24

Many more musicians were on-boarded to Fountain, however, we were unable to obtain all of their npubs.

THANK YOU TO ALL ZAPPERS AND BOOSTERS!

Musicians “Get It”

My key takeaway was the musicians' absolute understanding that the current digital landscape along with legacy social media is failing them. Every artist I spoke with recognized how algorithms hinder fan connection and how gatekeepers prevent fair compensation for their work. They all use Spotify, but they only do so out of necessity. They felt the music industry is primed for both a social and monetary revolution. Some of them were even speaking my language…

Because of this, concepts like decentralization, censorship resistance, owning your content, and controlling your social graph weren't just understood by them, they were instantly embraced. The excitement was real; they immediately saw the potential and agreed with me. Bitcoin and Nostr felt genuinely punk rock and that helped a lot of them identify with what we were offering them.

The Tools and the Issues

While the Nostr ecosystem offers a wide variety of tools, we focused on introducing three key applications at this event to keep things clear for newcomers:

1. Fountain, with a music focus, was the primary tool for onboarding attendees onto Nostr. Fountain was also chosen thanks to Fountain’s built-in Lightning wallet.
2. Primal, as a social alternative, was demonstrated to show how users can take their Nostr identity and content seamlessly between different applications.
3. Tunestr.io, lastly was showcased for its live video streaming capabilities.

Although we highlighted these three, we did inform attendees about the broader range of available apps and pointed them to nostrapps.com if they wanted to explore further, aiming to educate without overwhelming them.

This review highlights several UX issues with the Fountain app, particularly concerning profile updates, wallet functionality, and user discovery. While Fountain does work well, these minor hiccups make it extremely hard for on-boarding and education.

• Profile Issues:
• When a user edits their profile (e.g., Username/Nostr address, Lightning address) either during or after creation, the changes don't appear to consistently update across the app or sync correctly with Nostr relays.
• Specifically, the main profile display continues to show the old default Username/Nostr address and Lightning address inside Fountain and on other Nostr clients.
• However, the updated Username/Nostr address does appear on https://fountain.fm (chosen-username@fountain.fm) and is visible within the "Edit Profile" screen itself in the app.
• This inconsistency is confusing for users, as they see their updated information in some places but not on their main public-facing profile within the app. I confirmed this by observing a new user sign up and edit their username – the edit screen showed the new name, but the profile display in Fountain did not update and we did not see it inside Primal, Damus, Amethyst, etc.
• Wallet Limitations:
• The app's built-in wallet cannot scan Lightning address QR codes to initiate payments.
• This caused problems during the event where users imported Bitcoin from Azte.co vouchers into their Fountain wallets. When they tried to Zap a band by scanning a QR code on the live tally board, Fountain displayed an error message stating the invoice or QR code was invalid.
• While suggesting musicians install Primal as a second Nostr app was a potential fix for the QR code issue, (and I mentioned it to some), the burden of onboarding users onto two separate applications, potentially managing two different wallets, and explaining which one works for specific tasks creates a confusing and frustrating user experience.
• Search Difficulties:
• Finding other users within the Fountain app is challenging. I was unable to find profiles from brand new users by entering their chosen Fountain username.
• To find a new user, I had to resort to visiting their profile on the web (fountain.fm/username) to retrieve their npub. Then, open Primal and follow them. Finally, when searching for their username, since I was now following them, I was able to find their profile.
• This search issue is compounded by the profile syncing problem mentioned earlier, as even if found via other clients, their displayed information is outdated.
• Searching for the event to Boost/Zap inside Fountain was harder than it should have been the first two days as the live stream did not appear at the top of the screen inside the tap. This was resolved on the third day of the event.

Improving the Onboarding Experience

To better support user growth, educators and on-boarders need more feature complete and user-friendly applications. I love our developers and I will always sing their praises from the highest mountain tops, however I also recognize that the current tools present challenges that hinder a smooth onboarding experience.

One potential approach explored was guiding users to use Primal (including its built-in wallet) in conjunction with Wavlake via Nostr Wallet Connect (NWC). While this could facilitate certain functions like music streaming, zaps, and QR code scanning (which require both Primal and Wavlake apps), Wavlake itself has usability issues. These include inconsistent or separate profiles between web and mobile apps, persistent "Login" buttons even when logged in on the mobile app with a Nostr identity, and the minor inconvenience of needing two separate applications. Although NWC setup is relatively easy and helps streamline the process, the need to switch between apps adds complexity, especially when time is limited and we’re aiming to showcase the benefits of this new system.

Ultimately, we need applications that are more feature-complete and intuitive for mainstream users to improve the onboarding experience significantly.

Looking forward to the future

I anticipate that most of these issues will be resolved when these applications address them in the near future. Specifically, this would involve Fountain fixing its profile issues and integrating Nostr Wallet Connect (NWC) to allow users to utilize their Primal wallet, or by enabling the scanning of QR codes that pay out to Lightning addresses. Alternatively, if Wavlake resolves the consistency problems mentioned earlier, this would also significantly improve the situation giving us two viable solutions for musicians.

My ideal onboarding event experience would involve having all the previously mentioned issues resolved. Additionally, I would love to see every attendee receive a $5 or $10 voucher to help them start engaging with value-for-value, rather than just the limited number we distributed recently. The goal is to have everyone actively zapping and sending Bitcoin throughout the event. Maybe we can find a large sponsor to facilitate this in the future?

What's particularly exciting is the Launch conference's strong interest in integrating value-for-value across their entire program for all musicians and speakers at their next event in Dallas, Texas, coming later this fall. This presents a significant opportunity to onboard over 100+ musicians to Bitcoin and Nostr, which in turn will help onboard their fans and supporters.

We need significantly more zaps and more zappers! It's unreasonable to expect the same dedicated individuals to continuously support new users; they are being bled dry. A shift is needed towards more people using bitcoin for everyday transactions, treating it as money. This brings me back to my ideal onboarding experience: securing a sponsor to essentially give participants bitcoin funds specifically for zapping and tipping artists. This method serves as a practical lesson in using bitcoin as money and showcases the value-for-value principle from the outset.

@ e8deeca0:4b55db9b

Lily Phillips

Lily Phillips, a 23-year-old OnlyFans creator from Derbyshire, sparked global controversy after announcing her intention to have sex with 1,000 men in one day. While the event itself never occurred, she completed a "training" session with 101 men, which was documented by YouTuber Josh Pieters in a film titled I Slept with 100 Men in One Day. The documentary shows Phillips breaking down emotionally mid-way, which further fueled debates about the psychological toll of such performances.

Phillips maintained that the experience was voluntary and empowering. Still, she also admitted that her content might contribute to unrealistic expectations of women, saying, "It’s my fantasy, but I’m not helping the situation."

The backlash was swift and intense. She was permanently banned from Airbnb for violating their policies during the event, and she faced accusations of idea theft from fellow adult creator Bonnie Blue (no rivalry). But beyond the drama and headlines, her actions touched on something deeper within society—triggering reactions that reveal much about our collective psyche.

Why the Outrage?

The reaction to Phillips was not just about one extreme act. It tapped into long-standing emotional, cultural, and gender-based tensions:

• For many women, it felt like exploitation. Even though Phillips claimed agency, the imagery of one woman being with over a hundred men appeared dehumanizing, echoing trauma around objectification and sexual coercion.

• For some feminists, the event divided opinion. Was it a radical expression of freedom or a reinforcement of male-centered pornographic fantasies?

• For many men, the outrage often stemmed from a sense of moral violation. A woman expressing sexuality so publicly and without shame challenges deep-seated beliefs about purity, modesty, and traditional gender roles.

• Across the board, the situation made people confront how casual sex is viewed in our culture. While society consumes sexualized content daily, overt expressions of it—especially by women who claim control over it—are still met with hostility.

Lily Phillips didn’t just spark a conversation about adult content; she exposed a fault line in how we view sex, autonomy, and public morality. Whether one sees her actions as empowering or disturbing, the public reaction speaks volumes about our own discomforts, hypocrisies, and evolving values.

In the end, Lily became a mirror—reflecting a culture still unsure of how to talk honestly about sex and power.

@ 65f03c16:f77e9d92

is a game changer for traders. It blends chaos theory & market psychology to decode price action. Learn to spot order in market noise using fractals & momentum, teaches the Alligator indicator to ride trends & avoid chop. His 5-stage approach, from novice to expert, builds discipline & edge. Perfect for futures or stocks, It’s practical, not abstract. Williams’ 40+ yrs of trading shine through, with tools like Elliott Wave & nonlinear dynamics

recommended !

@ dab6c606:51f507b6

Core idea: Use geotagged anonymized Nostr events with Cashu-based points to snitch on cop locations for a more relaxed driving and walking

We all know navigation apps. There's one of them that allows you to report on locations of cops. It's Waze and it's owned by Google. There are perfectly fine navigation apps like Organic Maps, that unfortunately lack the cop-snitching features. In some countries, it is illegal to report cop locations, so it would probably not be a good idea to use your npub to report them. But getting a points Cashu token as a reward and exchanging them from time to time would solve this. You can of course report construction, traffic jams, ...

Proposed solution: Add Nostr client (Copstr) to Organic Maps. Have a button in bottom right allowing you to report traffic situations. Geotagged events are published on Nostr relays, users sending cashu tokens as thank you if the report is valid. Notes have smart expiration times.

Phase 2: Automation: Integration with dashcams and comma.ai allow for automated AI recognition of traffic events such as traffic jams and cops, with automatic touchless reporting.

Result: Drive with most essential information and with full privacy. Collect points to be cool and stay cool.

@ 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

@ da0b9bc3:4e30a4a9

Hello Stackers!

Welcome on into the ~Music Corner of the Saloon!

A place where we Talk Music. Share Tracks. Zap Sats.

So stay a while and listen.

🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨

🚨Subscribe to the territory to ensure you never miss a post! 🚨

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

@ e0921d61:e0fe7bd5

Hans-Hermann Hoppe explains the capitalist process as driven by time preference, how people value present vs. future goods. Economic growth hinges on savings and investment, and this shapes our prosperity.

Factors like population, natural resources, and technology matter, but Hoppe argues they're secondary. Without prior savings and investment, even the richest resources and best technology remain untapped.

True economic advancement happens through increasing per capita invested capital, raising productivity, real incomes, and further lowering time preferences. This creates a self-reinforcing cycle of prosperity.

Hoppe claims this process naturally continues smoothly until scarcity itself disappears, unless people voluntarily choose leisure over more wealth. This growth has no inherent reason to halt abruptly.

This smooth capitalist cycle, however, is disrupted when government enters the picture. Government control of resources it didn’t earn or acquire legitimately distorts incentives and investment.

Government monopolization of money through fractional reserve banking artificially lowers interest rates.

Entrepreneurs mistakenly think, and are incentivized to think, there's more savings, so more unsustainable investments proliferate.

Without real savings backing these projects, a painful correction (a bust following the boom) inevitably occurs.

Investments must eventually realign with actual savings, thus leading to bankruptcies and unemployment.

Hoppe concludes that boom-bust cycles aren’t natural. They’re directly caused by government-created credit expansion. Unless governments stop manipulating fiat money supply, these cycles remain unavoidable.

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

@ 5a261a61:2ebd4480

What a day yesterday!

I had a really big backlog of both work and non-work things to clean up. But I was getting a little frisky because my health finally gave me some energy to be in the mood for intimacy after the illness-filled week had forced libido debt on me. I decided to cheat it out and just take care of myself quickly. Horny thoughts won over, and I got at least e-stim induced ass slaps to make it more enjoyable. Quick clean up and everything seemed ok...until it wasn't.

The rest of the morning passed uneventfully as I worked through my backlog, but things took a turn in the early afternoon. I had to go pickup kids, and I just missed Her between the doors, only managed to get a fast kiss. A little bummed from the work issues and failed expectations of having a few minutes together, I got on my way.

Then it hit me—the most serious case of blue balls I had in a long time. First came panic. I was getting to the age when unusual symptoms raise concerns—cancer comes first to mind, as insufficient release wasn't my typical problem. So I called Her. I explained what was happening and expressed hope for some alone time. Unfortunately, that seemed impossible with our evening schedule: kids at home, Her online meeting, and my standing gamenight with the boys. These game sessions are our sacred ritual—a preserved piece of pre-kids sanity that we all protect in our calendars. Not something I wanted to disturb.

Her reassurance was brief but unusualy promising: "Don't worry, I get this."

Evening came, and just as I predicted, there was ZERO time for shenanigans while we took care of the kids. But once we put them to bed (I drew straw for early sleeper), with parental duties complete, I headed downstairs to prepare for my gaming session. Headset on, I greeted my fellows and started playing.

Not five minutes later, She opened the door with lube in one hand, fleshlight in the other, and an expecting smile on Her face. Definitely unexpected. I excused myself from the game, muted mic, but She stopped me.

"There will be nothing if you won't play," She said. She just motioned me to take my pants off. And off to play I was. Not an easy feat considering I twisted my body sideways so She could access anything She wanted while I still reached keyboard and mouse.

She slowly started touching me and observing my reactions, but quickly changed to using Her mouth. Getting a blowjob while semihard was always so strange. The semi part didn't last long though...

As things intensified, She was satisfied with my erection and got the fleshlight ready. It was a new toy for us, and it was Her first time using it on me all by Herself (usually She prefers watching me use toys). She applied an abundance of lube that lasted the entire encounter and beyond.

Shifting into a rhythm, She started pumping slowly but clearly enjoyed my reactions when She unexpectedly sped up, forcing me to mute the mic. I knew I wouldn't last long. When She needed to fix Her hair, I gentlemanly offered to hold the fleshlight, having one hand still available for gaming. She misunderstood, thinking I was taking over completely, which initially disappointed me.

To my surprise, She began taking Her shirt off the shoulders, offering me a pornhub-esque view. To clearly indicate that finish time had arrived, She moved Her lubed hand teasingly toward my anal. She understood precisely my contradictory preferences—my desire to be thoroughly clean before such play versus my complete inability to resist Her when aroused. That final move did it—I muted the mic just in time to vocally express how good She made me feel.

Quick clean up, kiss on the forehead, and a wish for me to have a good game session followed. The urge to abandon the game and cuddle with Her was powerful, but She stopped me. She had more work to complete on Her todo list than just me.

Had a glass, had a blast; overall, a night well spent I would say.

@ 91bea5cd:1df4451c

Um bom gerenciamento de senhas deve ser simples e seguir a filosofia do Unix.  Organizado em hierarquia e fácil de passar de um computador para outro.

E por isso não é recomendável o uso de aplicativos de terceiros que tenham acesso a suas chaves(senhas) em seus servidores, tampouco as opções nativas dos navegadores, que também pertencem a grandes empresas que fazem um grande esforço para ter acesso a nossas informações.

Recomendação

• pass
• Qtpass (gerenciador gráfico)

Com ele seus dados são criptografados usando sua chave gpg e salvo em arquivos organizados por pastas de forma hierárquica, podendo ser integrado a um serviço git de sua escolha ou copiado facilmente de um local para outro.

Uso

O seu uso é bem simples.

Configuração:

pass git init

Para ver:

pass Email/example.com

Copiar para área de transferência (exige xclip):

pass -c Email/example.com

Para inserir:

pass insert Email/example0.com

Para inserir e gerar senha:

pass generate Email/example1.com

Para inserir e gerar senha sem símbolos:

pass generate --no-symbols Email/example1.com

Para inserir, gerar senha e copiar para área de transferência :

pass generate -c Email/example1.com

Para remover:

pass rm Email/example.com

@ 91bea5cd:1df4451c

O que é Tahoe-LAFS?

Bem-vindo ao Tahoe-LAFS_, o primeiro sistema de armazenamento descentralizado com

• Segurança independente do provedor * .

Tahoe-LAFS é um sistema que ajuda você a armazenar arquivos. Você executa um cliente Programa no seu computador, que fala com um ou mais servidores de armazenamento em outros computadores. Quando você diz ao seu cliente para armazenar um arquivo, ele irá criptografar isso Arquivo, codifique-o em múltiplas peças, depois espalhe essas peças entre Vários servidores. As peças são todas criptografadas e protegidas contra Modificações. Mais tarde, quando você pede ao seu cliente para recuperar o arquivo, ele irá Encontre as peças necessárias, verifique se elas não foram corrompidas e remontadas Eles, e descriptografar o resultado.

O cliente cria mais peças (ou "compartilhamentos") do que acabará por precisar, então Mesmo que alguns servidores falhem, você ainda pode recuperar seus dados. Corrompido Os compartilhamentos são detectados e ignorados, de modo que o sistema pode tolerar o lado do servidor Erros no disco rígido. Todos os arquivos são criptografados (com uma chave exclusiva) antes Uploading, então mesmo um operador de servidor mal-intencionado não pode ler seus dados. o A única coisa que você pede aos servidores é que eles podem (geralmente) fornecer o Compartilha quando você os solicita: você não está confiando sobre eles para Confidencialidade, integridade ou disponibilidade absoluta.

O que é "segurança independente do provedor"?

Todo vendedor de serviços de armazenamento na nuvem irá dizer-lhe que o seu serviço é "seguro". Mas o que eles significam com isso é algo fundamentalmente diferente Do que queremos dizer. O que eles significam por "seguro" é que depois de ter dado Eles o poder de ler e modificar seus dados, eles tentam muito difícil de não deixar Esse poder seja abusado. Isso acaba por ser difícil! Insetos, Configurações incorretas ou erro do operador podem acidentalmente expor seus dados para Outro cliente ou para o público, ou pode corromper seus dados. Criminosos Ganho rotineiramente de acesso ilícito a servidores corporativos. Ainda mais insidioso é O fato de que os próprios funcionários às vezes violam a privacidade do cliente De negligência, avareza ou mera curiosidade. O mais consciencioso de Esses prestadores de serviços gastam consideráveis ​​esforços e despesas tentando Mitigar esses riscos.

O que queremos dizer com "segurança" é algo diferente. * O provedor de serviços Nunca tem a capacidade de ler ou modificar seus dados em primeiro lugar: nunca. * Se você usa Tahoe-LAFS, então todas as ameaças descritas acima não são questões para você. Não só é fácil e barato para o provedor de serviços Manter a segurança de seus dados, mas na verdade eles não podem violar sua Segurança se eles tentaram. Isto é o que chamamos de * independente do fornecedor segurança*.

Esta garantia está integrada naturalmente no sistema de armazenamento Tahoe-LAFS e Não exige que você execute um passo de pré-criptografia manual ou uma chave complicada gestão. (Afinal, ter que fazer operações manuais pesadas quando Armazenar ou acessar seus dados anularia um dos principais benefícios de Usando armazenamento em nuvem em primeiro lugar: conveniência.)

Veja como funciona:

Uma "grade de armazenamento" é constituída por uma série de servidores de armazenamento. Um servidor de armazenamento Tem armazenamento direto em anexo (tipicamente um ou mais discos rígidos). Um "gateway" Se comunica com os nós de armazenamento e os usa para fornecer acesso ao Rede sobre protocolos como HTTP (S), SFTP ou FTP.

Observe que você pode encontrar "cliente" usado para se referir aos nós do gateway (que atuam como Um cliente para servidores de armazenamento) e também para processos ou programas que se conectam a Um nó de gateway e operações de execução na grade - por exemplo, uma CLI Comando, navegador da Web, cliente SFTP ou cliente FTP.

Os usuários não contam com servidores de armazenamento para fornecer * confidencialidade * nem

• Integridade * para seus dados - em vez disso, todos os dados são criptografados e Integridade verificada pelo gateway, para que os servidores não possam ler nem Modifique o conteúdo dos arquivos.

Os usuários dependem de servidores de armazenamento para * disponibilidade *. O texto cifrado é Codificado por apagamento em partes N distribuídas em pelo menos H distintas Servidores de armazenamento (o valor padrão para N é 10 e para H é 7) então Que pode ser recuperado de qualquer K desses servidores (o padrão O valor de K é 3). Portanto, apenas a falha do H-K + 1 (com o Padrões, 5) servidores podem tornar os dados indisponíveis.

No modo de implantação típico, cada usuário executa seu próprio gateway sozinho máquina. Desta forma, ela confia em sua própria máquina para a confidencialidade e Integridade dos dados.

Um modo de implantação alternativo é que o gateway é executado em uma máquina remota e O usuário se conecta ao HTTPS ou SFTP. Isso significa que o operador de O gateway pode visualizar e modificar os dados do usuário (o usuário * depende de * o Gateway para confidencialidade e integridade), mas a vantagem é que a O usuário pode acessar a grade Tahoe-LAFS com um cliente que não possui o Software de gateway instalado, como um quiosque de internet ou celular.

Controle de acesso

Existem dois tipos de arquivos: imutáveis ​​e mutáveis. Quando você carrega um arquivo Para a grade de armazenamento, você pode escolher o tipo de arquivo que será no grade. Os arquivos imutáveis ​​não podem ser modificados quando foram carregados. UMA O arquivo mutable pode ser modificado por alguém com acesso de leitura e gravação. Um usuário Pode ter acesso de leitura e gravação a um arquivo mutable ou acesso somente leitura, ou não Acesso a ele.

Um usuário que tenha acesso de leitura e gravação a um arquivo mutable ou diretório pode dar Outro acesso de leitura e gravação do usuário a esse arquivo ou diretório, ou eles podem dar Acesso somente leitura para esse arquivo ou diretório. Um usuário com acesso somente leitura Para um arquivo ou diretório pode dar acesso a outro usuário somente leitura.

Ao vincular um arquivo ou diretório a um diretório pai, você pode usar um Link de leitura-escrita ou um link somente de leitura. Se você usar um link de leitura e gravação, então Qualquer pessoa que tenha acesso de leitura e gravação ao diretório pai pode obter leitura-escrita Acesso à criança e qualquer pessoa que tenha acesso somente leitura ao pai O diretório pode obter acesso somente leitura à criança. Se você usar uma leitura somente Link, qualquer pessoa que tenha lido-escrito ou acesso somente leitura ao pai O diretório pode obter acesso somente leitura à criança.

================================================== ==== Usando Tahoe-LAFS com uma rede anônima: Tor, I2P ================================================== ====

. `Visão geral '

. `Casos de uso '

. Software Dependencies_

#. Tor #. I2P

. `Configuração de conexão '

. `Configuração de Anonimato '

#. Anonimato do cliente ' #.Anonimato de servidor, configuração manual ' #. `Anonimato de servidor, configuração automática '

. `Problemas de desempenho e segurança '

Visão geral

Tor é uma rede anonimização usada para ajudar a esconder a identidade da Internet Clientes e servidores. Consulte o site do Tor Project para obter mais informações: Https://www.torproject.org/

I2P é uma rede de anonimato descentralizada que se concentra no anonimato de ponta a ponta Entre clientes e servidores. Consulte o site I2P para obter mais informações: Https://geti2p.net/

Casos de uso

Existem três casos de uso potenciais para Tahoe-LAFS do lado do cliente:

1. O usuário deseja sempre usar uma rede de anonimato (Tor, I2P) para proteger Seu anonimato quando se conecta às redes de armazenamento Tahoe-LAFS (seja ou Não os servidores de armazenamento são anônimos).

2. O usuário não se preocupa em proteger seu anonimato, mas eles desejam se conectar a Servidores de armazenamento Tahoe-LAFS que são acessíveis apenas através de Tor Hidden Services ou I2P.

3. Tor é usado apenas se uma sugestão de conexão do servidor usar tor:. Essas sugestões Geralmente tem um endereço .onion.

4. I2P só é usado se uma sugestão de conexão do servidor usa i2p:. Essas sugestões Geralmente têm um endereço .i2p.

5. O usuário não se preocupa em proteger seu anonimato ou para se conectar a um anonimato Servidores de armazenamento. Este documento não é útil para você ... então pare de ler.

Para servidores de armazenamento Tahoe-LAFS existem três casos de uso:

1. O operador deseja proteger o anonimato fazendo seu Tahoe Servidor acessível apenas em I2P, através de Tor Hidden Services, ou ambos.

2. O operador não * requer * anonimato para o servidor de armazenamento, mas eles Quer que ele esteja disponível tanto no TCP / IP roteado publicamente quanto através de um Rede de anonimização (I2P, Tor Hidden Services). Uma possível razão para fazer Isso é porque ser alcançável através de uma rede de anonimato é um Maneira conveniente de ignorar NAT ou firewall que impede roteios públicos Conexões TCP / IP ao seu servidor (para clientes capazes de se conectar a Tais servidores). Outro é o que torna o seu servidor de armazenamento acessível Através de uma rede de anonimato pode oferecer uma melhor proteção para sua Clientes que usam essa rede de anonimato para proteger seus anonimato.

3. O operador do servidor de armazenamento não se preocupa em proteger seu próprio anonimato nem Para ajudar os clientes a proteger o deles. Pare de ler este documento e execute Seu servidor de armazenamento Tahoe-LAFS usando TCP / IP com roteamento público.

Veja esta página do Tor Project para obter mais informações sobre Tor Hidden Services: Https://www.torproject.org/docs/hidden-services.html.pt

Veja esta página do Projeto I2P para obter mais informações sobre o I2P: Https://geti2p.net/en/about/intro

Dependências de software

Tor

Os clientes que desejam se conectar a servidores baseados em Tor devem instalar o seguinte.

• Tor (tor) deve ser instalado. Veja aqui: Https://www.torproject.org/docs/installguide.html.en. No Debian / Ubuntu, Use apt-get install tor. Você também pode instalar e executar o navegador Tor Agrupar.

• Tahoe-LAFS deve ser instalado com o [tor] "extra" habilitado. Isso vai Instale txtorcon ::

Pip install tahoe-lafs [tor]

Os servidores Tor-configurados manualmente devem instalar Tor, mas não precisam Txtorcon ou o [tor] extra. Configuração automática, quando Implementado, vai precisar destes, assim como os clientes.

I2P

Os clientes que desejam se conectar a servidores baseados em I2P devem instalar o seguinte. Tal como acontece com Tor, os servidores baseados em I2P configurados manualmente precisam do daemon I2P, mas Não há bibliotecas especiais de apoio Tahoe-side.

• I2P deve ser instalado. Veja aqui: Https://geti2p.net/en/download

• A API SAM deve estar habilitada.

• Inicie o I2P.

• Visite http://127.0.0.1:7657/configclients no seu navegador.
• Em "Configuração do Cliente", marque a opção "Executar no Startup?" Caixa para "SAM Ponte de aplicação ".
• Clique em "Salvar Configuração do Cliente".

• Clique no controle "Iniciar" para "ponte de aplicação SAM" ou reinicie o I2P.

• Tahoe-LAFS deve ser instalado com o [i2p] extra habilitado, para obter Txi2p ::

Pip install tahoe-lafs [i2p]

Tor e I2P

Os clientes que desejam se conectar a servidores baseados em Tor e I2P devem instalar tudo acima. Em particular, Tahoe-LAFS deve ser instalado com ambos Extras habilitados ::

Pip install tahoe-lafs [tor, i2p]

Configuração de conexão

Consulte: ref: Connection Management para uma descrição do[tor]e [I2p] seções de tahoe.cfg. Estes controlam como o cliente Tahoe Conecte-se a um daemon Tor / I2P e, assim, faça conexões com Tor / I2P-baseadas Servidores.

As seções [tor] e [i2p] só precisam ser modificadas para serem usadas de forma incomum Configurações ou para habilitar a configuração automática do servidor.

A configuração padrão tentará entrar em contato com um daemon local Tor / I2P Ouvindo as portas usuais (9050/9150 para Tor, 7656 para I2P). Enquanto Há um daemon em execução no host local e o suporte necessário Bibliotecas foram instaladas, os clientes poderão usar servidores baseados em Tor Sem qualquer configuração especial.

No entanto, note que esta configuração padrão não melhora a Anonimato: as conexões TCP normais ainda serão feitas em qualquer servidor que Oferece um endereço regular (cumpre o segundo caso de uso do cliente acima, não o terceiro). Para proteger o anonimato, os usuários devem configurar o [Connections] da seguinte maneira:

[Conexões] Tcp = tor

Com isso, o cliente usará Tor (em vez de um IP-address -reviração de conexão direta) para alcançar servidores baseados em TCP.

Configuração de anonimato

Tahoe-LAFS fornece uma configuração "flag de segurança" para indicar explicitamente Seja necessário ou não a privacidade do endereço IP para um nó ::

[nó] Revelar-IP-address = (booleano, opcional)

Quando revelar-IP-address = False, Tahoe-LAFS se recusará a iniciar se algum dos As opções de configuração em tahoe.cfg revelariam a rede do nó localização:

• [Conexões] tcp = tor é necessário: caso contrário, o cliente faria Conexões diretas para o Introdução, ou qualquer servidor baseado em TCP que aprende Do Introdutor, revelando seu endereço IP para esses servidores e um Rede de espionagem. Com isso, Tahoe-LAFS só fará Conexões de saída através de uma rede de anonimato suportada.

• Tub.location deve ser desativado ou conter valores seguros. este O valor é anunciado para outros nós através do Introdutor: é como um servidor Anuncia sua localização para que os clientes possam se conectar a ela. No modo privado, ele É um erro para incluir um tcp: dica no tub.location. Modo privado Rejeita o valor padrão de tub.location (quando a chave está faltando Inteiramente), que é AUTO, que usa ifconfig para adivinhar o nó Endereço IP externo, o que o revelaria ao servidor e a outros clientes.

Esta opção é ** crítica ** para preservar o anonimato do cliente (cliente Caso de uso 3 de "Casos de uso", acima). Também é necessário preservar uma Anonimato do servidor (caso de uso do servidor 3).

Esse sinalizador pode ser configurado (para falso), fornecendo o argumento --hide-ip para Os comandos create-node, create-client ou create-introducer.

Observe que o valor padrão de revelar-endereço IP é verdadeiro, porque Infelizmente, esconder o endereço IP do nó requer software adicional para ser Instalado (conforme descrito acima) e reduz o desempenho.

Anonimato do cliente

Para configurar um nó de cliente para anonimato, tahoe.cfg ** deve ** conter o Seguindo as bandeiras de configuração ::

[nó] Revelar-IP-address = False Tub.port = desativado Tub.location = desativado

Uma vez que o nodo Tahoe-LAFS foi reiniciado, ele pode ser usado anonimamente (cliente Caso de uso 3).

Anonimato do servidor, configuração manual

Para configurar um nó de servidor para ouvir em uma rede de anonimato, devemos primeiro Configure Tor para executar um "Serviço de cebola" e encaminhe as conexões de entrada para o Porto Tahoe local. Então, configuramos Tahoe para anunciar o endereço .onion Aos clientes. Também configuramos Tahoe para não fazer conexões TCP diretas.

• Decida em um número de porta de escuta local, chamado PORT. Isso pode ser qualquer não utilizado Porta de cerca de 1024 até 65535 (dependendo do kernel / rede do host Config). Nós diremos a Tahoe para escutar nesta porta, e nós diremos a Tor para Encaminhe as conexões de entrada para ele.
• Decida em um número de porta externo, chamado VIRTPORT. Isso será usado no Localização anunciada e revelada aos clientes. Pode ser qualquer número de 1 Para 65535. Pode ser o mesmo que PORT, se quiser.
• Decida em um "diretório de serviço oculto", geralmente em / var / lib / tor / NAME. Pediremos a Tor para salvar o estado do serviço de cebola aqui, e Tor irá Escreva o endereço .onion aqui depois que ele for gerado.

Em seguida, faça o seguinte:

• Crie o nó do servidor Tahoe (com tahoe create-node), mas não ** não ** Lança-o ainda.

• Edite o arquivo de configuração Tor (normalmente em / etc / tor / torrc). Precisamos adicionar Uma seção para definir o serviço oculto. Se nossa PORT for 2000, VIRTPORT é 3000, e estamos usando / var / lib / tor / tahoe como o serviço oculto Diretório, a seção deve se parecer com ::

  HiddenServiceDir / var / lib / tor / tahoe HiddenServicePort 3000 127.0.0.1:2000

• Reinicie Tor, com systemctl restart tor. Aguarde alguns segundos.

• Leia o arquivo hostname no diretório de serviço oculto (por exemplo, / Var / lib / tor / tahoe / hostname). Este será um endereço .onion, como U33m4y7klhz3b.onion. Ligue para esta CEBOLA.

• Edite tahoe.cfg para configurar tub.port para usar Tcp: PORT: interface = 127.0.0.1 e tub.location para usar Tor: ONION.onion: VIRTPORT. Usando os exemplos acima, isso seria ::

  [nó] Revelar-endereço IP = falso Tub.port = tcp: 2000: interface = 127.0.0.1 Tub.location = tor: u33m4y7klhz3b.onion: 3000 [Conexões] Tcp = tor

• Inicie o servidor Tahoe com tahoe start $ NODEDIR

A seção tub.port fará com que o servidor Tahoe ouça no PORT, mas Ligue o soquete de escuta à interface de loopback, que não é acessível Do mundo exterior (mas * é * acessível pelo daemon Tor local). Então o A seção tcp = tor faz com que Tahoe use Tor quando se conecta ao Introdução, escondendo o endereço IP. O nó se anunciará a todos Clientes que usam `tub.location``, então os clientes saberão que devem usar o Tor Para alcançar este servidor (e não revelar seu endereço IP através do anúncio). Quando os clientes se conectam ao endereço da cebola, seus pacotes serão Atravessar a rede de anonimato e eventualmente aterrar no Tor local Daemon, que então estabelecerá uma conexão com PORT no localhost, que é Onde Tahoe está ouvindo conexões.

Siga um processo similar para construir um servidor Tahoe que escuta no I2P. o O mesmo processo pode ser usado para ouvir tanto o Tor como o I2P (tub.location = Tor: ONION.onion: VIRTPORT, i2p: ADDR.i2p). Também pode ouvir tanto Tor como TCP simples (caso de uso 2), com tub.port = tcp: PORT, tub.location = Tcp: HOST: PORT, tor: ONION.onion: VIRTPORT e anonymous = false (e omite A configuração tcp = tor, já que o endereço já está sendo transmitido através de O anúncio de localização).

Anonimato do servidor, configuração automática

Para configurar um nó do servidor para ouvir em uma rede de anonimato, crie o Nó com a opção --listen = tor. Isso requer uma configuração Tor que Ou lança um novo daemon Tor, ou tem acesso à porta de controle Tor (e Autoridade suficiente para criar um novo serviço de cebola). Nos sistemas Debian / Ubuntu, faça Apt install tor, adicione-se ao grupo de controle com adduser YOURUSERNAME debian-tor e, em seguida, inicie sessão e faça o login novamente: se os groups O comando inclui debian-tor na saída, você deve ter permissão para Use a porta de controle de domínio unix em / var / run / tor / control.

Esta opção irá definir revelar-IP-address = False e [connections] tcp = Tor. Ele alocará as portas necessárias, instruirá Tor para criar a cebola Serviço (salvando a chave privada em algum lugar dentro de NODEDIR / private /), obtenha O endereço .onion e preencha tub.port e tub.location corretamente.

Problemas de desempenho e segurança

Se você estiver executando um servidor que não precisa ser Anônimo, você deve torná-lo acessível através de uma rede de anonimato ou não? Ou você pode torná-lo acessível * ambos * através de uma rede de anonimato E como um servidor TCP / IP rastreável publicamente?

Existem várias compensações efetuadas por esta decisão.

Penetração NAT / Firewall

Fazer com que um servidor seja acessível via Tor ou I2P o torna acessível (por Clientes compatíveis com Tor / I2P) mesmo que existam NAT ou firewalls que impeçam Conexões TCP / IP diretas para o servidor.

Anonimato

Tornar um servidor Tahoe-LAFS acessível * somente * via Tor ou I2P pode ser usado para Garanta que os clientes Tahoe-LAFS usem Tor ou I2P para se conectar (Especificamente, o servidor só deve anunciar endereços Tor / I2P no Chave de configuração tub.location). Isso evita que os clientes mal configurados sejam Desingonizando-se acidentalmente, conectando-se ao seu servidor através de A Internet rastreável.

Claramente, um servidor que está disponível como um serviço Tor / I2P * e * a O endereço TCP regular não é anônimo: o endereço do .on e o real O endereço IP do servidor é facilmente vinculável.

Além disso, a interação, através do Tor, com um Tor Oculto pode ser mais Protegido da análise do tráfego da rede do que a interação, através do Tor, Com um servidor TCP / IP com rastreamento público

** XXX há um documento mantido pelos desenvolvedores de Tor que comprovem ou refutam essa crença? Se assim for, precisamos ligar a ele. Caso contrário, talvez devêssemos explicar mais aqui por que pensamos isso? **

Linkability

A partir de 1.12.0, o nó usa uma única chave de banheira persistente para saída Conexões ao Introdutor e conexões de entrada para o Servidor de Armazenamento (E Helper). Para os clientes, uma nova chave Tub é criada para cada servidor de armazenamento Nós aprendemos sobre, e essas chaves são * não * persistiram (então elas mudarão cada uma delas Tempo que o cliente reinicia).

Clientes que atravessam diretórios (de rootcap para subdiretório para filecap) são É provável que solicitem os mesmos índices de armazenamento (SIs) na mesma ordem de cada vez. Um cliente conectado a vários servidores irá pedir-lhes todos para o mesmo SI em Quase ao mesmo tempo. E dois clientes que compartilham arquivos ou diretórios Irá visitar os mesmos SI (em várias ocasiões).

Como resultado, as seguintes coisas são vinculáveis, mesmo com revelar-endereço IP = Falso:

• Servidores de armazenamento podem vincular reconhecer várias conexões do mesmo Cliente ainda não reiniciado. (Observe que o próximo recurso de Contabilidade pode Faz com que os clientes apresentem uma chave pública persistente do lado do cliente quando Conexão, que será uma ligação muito mais forte).
• Os servidores de armazenamento provavelmente podem deduzir qual cliente está acessando dados, por Olhando as SIs sendo solicitadas. Vários servidores podem conciliar Determine que o mesmo cliente está falando com todos eles, mesmo que o TubIDs são diferentes para cada conexão.
• Os servidores de armazenamento podem deduzir quando dois clientes diferentes estão compartilhando dados.
• O Introdutor pode entregar diferentes informações de servidor para cada um Cliente subscrito, para particionar clientes em conjuntos distintos de acordo com Quais as conexões do servidor que eles eventualmente fazem. Para clientes + nós de servidor, ele Também pode correlacionar o anúncio do servidor com o cliente deduzido identidade.

atuação

Um cliente que se conecta a um servidor Tahoe-LAFS com rastreamento público através de Tor Incorrem em latência substancialmente maior e, às vezes, pior Mesmo cliente se conectando ao mesmo servidor através de um TCP / IP rastreável normal conexão. Quando o servidor está em um Tor Hidden Service, ele incorre ainda mais Latência e, possivelmente, ainda pior rendimento.

Conectando-se a servidores Tahoe-LAFS que são servidores I2P incorrem em maior latência E pior rendimento também.

Efeitos positivos e negativos em outros usuários Tor

O envio de seu tráfego Tahoe-LAFS sobre o Tor adiciona tráfego de cobertura para outros Tor usuários que também estão transmitindo dados em massa. Então isso é bom para Eles - aumentando seu anonimato.

No entanto, torna o desempenho de outros usuários do Tor Sessões - por exemplo, sessões ssh - muito pior. Isso é porque Tor Atualmente não possui nenhuma prioridade ou qualidade de serviço Recursos, para que as teclas de Ssh de outra pessoa possam ter que esperar na fila Enquanto o conteúdo do arquivo em massa é transmitido. O atraso adicional pode Tornar as sessões interativas de outras pessoas inutilizáveis.

Ambos os efeitos são duplicados se você carregar ou baixar arquivos para um Tor Hidden Service, em comparação com se você carregar ou baixar arquivos Over Tor para um servidor TCP / IP com rastreamento público

Efeitos positivos e negativos em outros usuários do I2P

Enviar seu tráfego Tahoe-LAFS ao I2P adiciona tráfego de cobertura para outros usuários do I2P Que também estão transmitindo dados. Então, isso é bom para eles - aumentando sua anonimato. Não prejudicará diretamente o desempenho de outros usuários do I2P Sessões interativas, porque a rede I2P possui vários controles de congestionamento e Recursos de qualidade de serviço, como priorizar pacotes menores.

No entanto, se muitos usuários estão enviando tráfego Tahoe-LAFS ao I2P e não tiverem Seus roteadores I2P configurados para participar de muito tráfego, então o I2P A rede como um todo sofrerá degradação. Cada roteador Tahoe-LAFS que usa o I2P tem Seus próprios túneis de anonimato que seus dados são enviados. Em média, um O nó Tahoe-LAFS requer 12 outros roteadores I2P para participar de seus túneis.

Portanto, é importante que o seu roteador I2P esteja compartilhando a largura de banda com outros Roteadores, para que você possa retornar enquanto usa o I2P. Isso nunca prejudicará a Desempenho de seu nó Tahoe-LAFS, porque seu roteador I2P sempre Priorize seu próprio tráfego.

=========================

Como configurar um servidor

Muitos nós Tahoe-LAFS são executados como "servidores", o que significa que eles fornecem serviços para Outras máquinas (isto é, "clientes"). Os dois tipos mais importantes são os Introdução e Servidores de armazenamento.

Para ser útil, os servidores devem ser alcançados pelos clientes. Os servidores Tahoe podem ouvir Em portas TCP e anunciar sua "localização" (nome do host e número da porta TCP) Para que os clientes possam se conectar a eles. Eles também podem ouvir os serviços de cebola "Tor" E portas I2P.

Os servidores de armazenamento anunciam sua localização ao anunciá-lo ao Introdutivo, Que então transmite a localização para todos os clientes. Então, uma vez que a localização é Determinado, você não precisa fazer nada de especial para entregá-lo.

O próprio apresentador possui uma localização, que deve ser entregue manualmente a todos Servidores de armazenamento e clientes. Você pode enviá-lo para os novos membros do seu grade. Esta localização (juntamente com outros identificadores criptográficos importantes) é Escrito em um arquivo chamado private / introducer.furl no Presenter's Diretório básico, e deve ser fornecido como o argumento --introducer = para Tahoe create-node ou tahoe create-node.

O primeiro passo ao configurar um servidor é descobrir como os clientes irão alcançar. Então você precisa configurar o servidor para ouvir em algumas portas, e Depois configure a localização corretamente.

Configuração manual

Cada servidor tem duas configurações em seu arquivo tahoe.cfg: tub.port, e Tub.location. A "porta" controla o que o nó do servidor escuta: isto Geralmente é uma porta TCP.

A "localização" controla o que é anunciado para o mundo exterior. Isto é um "Sugestão de conexão foolscap", e inclui tanto o tipo de conexão (Tcp, tor ou i2p) e os detalhes da conexão (nome do host / endereço, porta número). Vários proxies, gateways e redes de privacidade podem ser Envolvido, então não é incomum para tub.port e tub.location para olhar diferente.

Você pode controlar diretamente a configuração tub.port e tub.location Configurações, fornecendo --port = e --location = ao executar tahoe Create-node.

Configuração automática

Em vez de fornecer --port = / - location =, você pode usar --listen =. Os servidores podem ouvir em TCP, Tor, I2P, uma combinação desses ou nenhum. O argumento --listen = controla quais tipos de ouvintes o novo servidor usará.

--listen = none significa que o servidor não deve ouvir nada. Isso não Faz sentido para um servidor, mas é apropriado para um nó somente cliente. o O comando tahoe create-client inclui automaticamente --listen = none.

--listen = tcp é o padrão e liga uma porta de escuta TCP padrão. Usar --listen = tcp requer um argumento --hostname = também, que será Incorporado no local anunciado do nó. Descobrimos que os computadores Não pode determinar de forma confiável seu nome de host acessível externamente, então, em vez de Ter o servidor adivinhar (ou escanear suas interfaces para endereços IP Isso pode ou não ser apropriado), a criação de nó requer que o usuário Forneça o nome do host.

--listen = tor conversará com um daemon Tor local e criará uma nova "cebola" Servidor "(que se parece comalzrgrdvxct6c63z.onion). --listen = i2p` conversará com um daemon I2P local e criará um novo servidor endereço. Consulte: doc:anonymity-configuration` para obter detalhes.

Você pode ouvir nos três usando --listen = tcp, tor, i2p.

Cenários de implantação

A seguir, alguns cenários sugeridos para configurar servidores usando Vários transportes de rede. Estes exemplos não incluem a especificação de um Apresentador FURL que normalmente você gostaria quando provisionamento de armazenamento Nós. Para estes e outros detalhes de configuração, consulte : Doc: configuration.

. `Servidor possui um nome DNS público '

. Servidor possui um endereço público IPv4 / IPv6_

. O servidor está por trás de um firewall com encaminhamento de porta_

. Usando o I2P / Tor para evitar o encaminhamento da porta_

O servidor possui um nome DNS público

O caso mais simples é o local onde o host do servidor está diretamente conectado ao Internet, sem um firewall ou caixa NAT no caminho. A maioria dos VPS (Virtual Private Servidor) e servidores colocados são assim, embora alguns fornecedores bloqueiem Muitas portas de entrada por padrão.

Para esses servidores, tudo o que você precisa saber é o nome do host externo. O sistema O administrador irá dizer-lhe isso. O principal requisito é que este nome de host Pode ser pesquisado no DNS, e ele será mapeado para um endereço IPv4 ou IPv6 que Alcançará a máquina.

Se o seu nome de host for example.net, então você criará o introdutor como esta::

Tahoe create-introducer --hostname example.com ~ / introducer

Ou um servidor de armazenamento como ::

Tahoe create-node --hostname = example.net

Estes irão alocar uma porta TCP (por exemplo, 12345), atribuir tub.port para ser Tcp: 12345 e tub.location serão tcp: example.com: 12345.

Idealmente, isso também deveria funcionar para hosts compatíveis com IPv6 (onde o nome DNS Fornece um registro "AAAA", ou ambos "A" e "AAAA"). No entanto Tahoe-LAFS O suporte para IPv6 é novo e ainda pode ter problemas. Por favor, veja o ingresso # 867_ para detalhes.

.. _ # 867: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/867

O servidor possui um endereço público IPv4 / IPv6

Se o host tiver um endereço IPv4 (público) rotativo (por exemplo, 203.0.113.1```), mas Nenhum nome DNS, você precisará escolher uma porta TCP (por exemplo, 3457``) e usar o Segue::

Tahoe create-node --port = tcp: 3457 - localização = tcp: 203.0.113.1: 3457

--port é uma "string de especificação de ponto de extremidade" que controla quais locais Porta em que o nó escuta. --location é a "sugestão de conexão" que ele Anuncia para outros, e descreve as conexões de saída que essas Os clientes irão fazer, por isso precisa trabalhar a partir da sua localização na rede.

Os nós Tahoe-LAFS escutam em todas as interfaces por padrão. Quando o host é Multi-homed, você pode querer fazer a ligação de escuta ligar apenas a uma Interface específica, adicionando uma opção interface = ao --port = argumento::

Tahoe create-node --port = tcp: 3457: interface = 203.0.113.1 - localização = tcp: 203.0.113.1: 3457

Se o endereço público do host for IPv6 em vez de IPv4, use colchetes para Envolva o endereço e altere o tipo de nó de extremidade para tcp6 ::

Tahoe create-node --port = tcp6: 3457 - localização = tcp: [2001: db8 :: 1]: 3457

Você pode usar interface = para vincular a uma interface IPv6 específica também, no entanto Você deve fazer uma barra invertida - escapar dos dois pontos, porque, de outra forma, eles são interpretados Como delimitadores pelo idioma de especificação do "ponto final" torcido. o --location = argumento não precisa de dois pontos para serem escapados, porque eles são Envolto pelos colchetes ::

Tahoe create-node --port = tcp6: 3457: interface = 2001 \: db8 \: \: 1 --location = tcp: [2001: db8 :: 1]: 3457

Para hosts somente IPv6 com registros DNS AAAA, se o simples --hostname = A configuração não funciona, eles podem ser informados para ouvir especificamente Porta compatível com IPv6 com este ::

Tahoe create-node --port = tcp6: 3457 - localização = tcp: example.net: 3457

O servidor está por trás de um firewall com encaminhamento de porta

Para configurar um nó de armazenamento por trás de um firewall com encaminhamento de porta, você irá precisa saber:

• Endereço IPv4 público do roteador
• A porta TCP que está disponível de fora da sua rede
• A porta TCP que é o destino de encaminhamento
• Endereço IPv4 interno do nó de armazenamento (o nó de armazenamento em si é Desconhece esse endereço e não é usado durante tahoe create-node, Mas o firewall deve ser configurado para enviar conexões para isso)

Os números de porta TCP internos e externos podem ser iguais ou diferentes Dependendo de como o encaminhamento da porta está configurado. Se é mapear portas 1-para-1, eo endereço IPv4 público do firewall é 203.0.113.1 (e Talvez o endereço IPv4 interno do nó de armazenamento seja 192.168.1.5), então Use um comando CLI como este ::

Tahoe create-node --port = tcp: 3457 - localização = tcp: 203.0.113.1: 3457

Se no entanto, o firewall / NAT-box encaminha a porta externa * 6656 * para o interno Porta 3457, então faça isso ::

Tahoe create-node --port = tcp: 3457 - localização = tcp: 203.0.113.1: 6656

Usando o I2P / Tor para evitar o encaminhamento da porta

Os serviços de cebola I2P e Tor, entre outras excelentes propriedades, também fornecem NAT Penetração sem encaminhamento de porta, nomes de host ou endereços IP. Então, configurando Um servidor que escuta apenas no Tor é simples ::

Tahoe create-node --listen = tor

Para mais informações sobre o uso de Tahoe-LAFS com I2p e Tor veja : Doc: anonymity-configuration

@ 4e088f30:744b1792

Pouco menos de um mês antes de sua morte, minha mãe escreveu um texto com suas reflexões sobre a carta dezesseis do conjunto de cartas que eu criei. Ela estava lendo com a fonoaudióloga que a atendia e me contou. Eu disse que queria ouvir a reflexão, e um dia ela gravou um áudio para mim.

A carta dizia assim:

Ajo como borboleta que vai contra a força da vida ao sair do casulo tentando controlar o modo como será vista. Não percebo que tudo o que precisa ser feito agora é me entregar às minhas próprias asas.

Se a borboleta sai do casulo para ser vista como idealiza, o que ela deixa de ver, o que ela deixa de nutrir na vida?

Um dos trechos do texto que ela escreveu era:

“Você pode me ver?”

E eu me pergunto: será que tenho coragem de vê-la por inteiro? Ver sem palavras, sem conceitos, sem julgamentos, sem projeções? Será que tenho coragem de apenas ver quem ela é?

–

Outro dia, estava na casa dela - e o que mais me interessa sempre são seus cadernos - eu encontrei um que ainda não tinha visto. Parece que ela o usava em meados dos anos 90. Eu o abri e encontrei o nome Elizabeth Kubler Ross e eu tinha lido alguns livros dela alguns anos atrás, quando comecei a mergulhar em estudos sobre cuidados paliativos, morte e luto, então achei oportuno e li o que estava escrito:

“Depois de passar por todas as provas para as quais fomos mandados à terra como parte de nosso aprendizado, podemos nos formar. Podemos sair do nosso corpo, que aprisiona a alma como um casulo aprisiona a futura borboleta e, no momento certo, deixá-lo para trás. E estaremos livres da dor, livres dos medos e livres das preocupações… Livres como uma borboleta voltando para casa, para Deus… em um lugar onde nunca estamos sós, onde continuamos a crescer, a cantar, a dançar, onde estamos com aqueles que amamos e cercados de mais amor que jamais poderemos imaginar.” Elizabeth Kubler Ross, M.D (A roda da vida)

Antes de ouvir o que ela tinha escrito, eu disse que ela estava confiando na fonoaudióloga para se abrir e isso ia ajudá-la a florescer, ela emendou com “largar o casulo e virar borboleta”. Ela se sentia ainda emaranhada no casulo. No último ano ela falou algumas vezes sobre a necessidade de desapegar, sobre a única dificuldade dela ser soltar o apego a nós, os filhos dela. Mas ela foi fazendo o trabalho de soltar e soltar e soltar, até que se entregou às suas asas que sempre foram lindas e brilhantes a cada metamorfose em vida, e agora sendo vida.

Começo essa jornada, que ainda não sei o que será - embora tenha alguns desejos, com esses escritos, que ofereço à Vida, que já foi chamada de Glória e de minha mãe.

@ b17fccdf:b7211155

What's changed

---

• Updated Fulcrum and added the new configuration parameter: zmq_allow_hashtx = true ~> diff reference, to subscribe to Bitcoind's transaction notifications, enabling real-time detection of mempool transactions.
• Updated Fulcrum and deleted unnecessary FulcrumAdmin commands after this comment. The changes were on Configuration ~> diff reference and systemd service configuration ~> diff reference.
• New Resources Launched and added on Homepage & Menus: Calendar (Launchpad) + Badge (requested by a DM to 2FakTor) < ~ REMOVE the "[]" symbols from the URLs (naddr/npub...) to access.
• Readded project tags on the Homepage.
• Readded Broadcast past events section on Nostr relay in Rust bonus guide with a new method.
• Modernize Ordisrespector guide by @Unhosted Marcellus < ~ REMOVE the "[]" symbols from the URL (npub...) to access | in PR #113.
• Updated Electrs and added the new configuration parameter: db_parallelism=4 to allow concurrent DB background operations.
• Added new FREE service: Hockeypuck OpenPGP Public Keyserver (soon will be a guide on MiniBolt to build it).
• Phrasing and formatting consistency on Wireguard VPN by @Singlebeam < ~ REMOVE the "[]" symbols from the URL (npub...) to access | in PR #109.
• Updated Bitcoin Core to the latest v28.1.
• Updated LND to the latest v0.18.5.
• Updated other services: NBXplorer + BTCPay Server + Cloudflared + Go; to the latest versions.
• Added new Remote access over Tor and Allow insecure WebSocket connections in Firefox-based browsers sections on Nostr relay in Rust guide and separated Cloudflare tunnel configuration in a dedicated extra section.
• Added a new Upgrade to major version section on PostgreSQL guide.
• Added a new Upgrade to major version section on Node + NPM guide.
• Added a "Uninstall Snap" (optional section) on Configuration. Although it is in the initial stages (1.4 Configuration), it can be applied anytime.
• Included some useful commands in the PostgreSQL guide.
• Added and separated Cloudflare tunnel configuration in a dedicated extra section on BTCPay Server and BTC RPC Explorer.
• Separated Wireguard VPN + Cloudflare tunnel + Tor services: bridges & relays to a new "Networking" category.
• Separated Login with SSH keys guide to a new and dedicated "Security" section.
• Added AssumeReachable=1 new parameter on obfs4 bridge config ~> diff reference.
• Added new items to the Bitcoin Core extra section to Accelerate the IBD and Improve the reliability.
• Completed the improvement of the official MiniBolt Linktr (FOSS version).
• Added a new section to the Nostr Relay in Rust bonus guide to create a Cloudflare exception that allows incoming connections from Tor.
• Other minor fixes and improvements.

---

~> If you have any questions, feel free to join one of our discussion groups on our 🌳Linktr page🌳

---

Enjoy it! 🖥🔄🍓

@ da0b9bc3:4e30a4a9

Hello Stackers!

Welcome on into the ~Music Corner of the Saloon!

A place where we Talk Music. Share Tracks. Zap Sats.

So stay a while and listen.

🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨

🚨Subscribe to the territory to ensure you never miss a post! 🚨

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

@ f3873798:24b3f2f3

Durante décadas, ouvimos que o Brasil era o "país do futuro". Uma terra rica, com imenso potencial humano e natural, destinada a se tornar uma grande potência e referência para o mundo. Essa ideia, repetida em discursos políticos e publicações internacionais, alimentou gerações com esperança. Mas o tempo passou — e esse futuro promissor parece nunca chegar.

Na prática, o que vemos é um ciclo de promessas não cumpridas, problemas sociais profundos e um povo muitas vezes desiludido. Apesar do potencial imenso, o Brasil enfrenta barreiras estruturais e culturais que dificultam seu pleno desenvolvimento. E é justamente sobre isso que precisamos refletir.

A raiz dos nossos desafios

Não há como ter jeito sem que haja um enfrentamento com seriedade aos problemas que estão na base da nossa sociedade. Um dos maiores entraves é a precariedade da educação, tanto no acesso quanto na qualidade. Em muitas regiões, o estudo ainda é visto como perda de tempo, algo que não contribui para o sustento imediato da família. Mesmo com incentivos governamentais, o desempenho das escolas é baixo. Em vez de formar cidadãos críticos e profissionais capacitados, muitas vezes vemos instituições focadas em ideologias ou agendas desconectadas da realidade do aluno.

Outro ponto sensível é a estrutura familiar. Em áreas onde faltam referências morais, espirituais e sociais, o ambiente familiar pode se tornar disfuncional, com casos extremos de abusos e ausência total de valores básicos. Nesses contextos, a ausência de instituições que promovem virtudes e limites — como a Igreja, por exemplo — faz diferença. Não se trata de impor uma religião, mas de reconhecer o papel histórico que a fé teve (e ainda tem) na construção de uma base ética e civilizatória.

A falta de valores basilares e estrutura para a promoção da relações em sociedade, faz do ambiente escolar um local sem propósito, onde são depositados crianças para serem expostas a um convívio forçado com estranhos sem nenhum preparo familiar, e sendo muitas vezes subentendido pelos profissionais educadores como dever da família, no entanto tal estrutura foi corrompida e devido o combate a religião pelos veículos midiáticos.

O papel da cultura e da moralidade

A cultura brasileira também tem sido afetada por uma inversão de valores. Virtudes como honestidade, humildade e dedicação são muitas vezes vistas com desdém, enquanto comportamentos imprudentes e hedonistas são exaltados. Essa distorção enfraquece a sociedade e prejudica qualquer tentativa de avanço coletivo.

A elite intelectual e política, por sua vez, parece muitas vezes mais preocupada com interesses próprios do que com o bem comum. Muitos aderem a ideias que, em vez de promover a soberania e a autonomia nacional, aprofundam nossa dependência e fragilidade como país.

Existe saída?

Sim, existe. Mas não será simples — e muito menos rápida. O Brasil precisa de uma mudança profunda de mentalidade. Isso inclui:

Resgatar o valor da família e da formação moral;

Investir de verdade em uma educação que liberte, que forme e que inspire;

Incentivar a produção científica e tecnológica local;

Valorizar o trabalho árduo, a persistência e o compromisso com a verdade.

Também é preciso reconhecer que o desenvolvimento de uma nação não é apenas econômico, mas também espiritual e cultural. Mesmo que você não seja religioso, é possível entender que a construção de uma sociedade mais justa exige princípios, virtudes e limites. Sem isso, qualquer progresso será frágil e passageiro.

O Brasil tem jeito? Sim. Mas depende de nós — da nossa capacidade de enxergar com coragem onde estamos falhando, e da nossa disposição para agir com sabedoria, verdade e esperança.

@ da0b9bc3:4e30a4a9

Hello Stackers!

Welcome on into the ~Music Corner of the Saloon!

A place where we Talk Music. Share Tracks. Zap Sats.

So stay a while and listen.

🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨

🚨Subscribe to the territory to ensure you never miss a post! 🚨

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

@ 9a1adc34:9a9d705b

Testing the concept of using Nostr as a personal CMS.

@ 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

@ f3873798:24b3f2f3

O dorama O Lucro do Amor, disponível na Amazon Prime, oferece um ponto de partida para reflexões sobre as transformações culturais na Coreia do Sul, especialmente no que diz respeito à representação de relações afetivas e valores tradicionais. Enquanto analiso a obra, busco explorar como os arquétipos clássicos dos dramas coreanos — marcados por conservadorismo e estruturas patriarcais — estão sendo ressignificados sob a influência de movimentos sociais contemporâneos, como o feminismo e discussões globais sobre liberdade individual. A crítica central recai sobre a normalização de relacionamentos abertos e a relativização de promessas, temas que, embora raros na produção asiática, ecoam debates ocidentais.

Arquétipos Tradicionais e a Evolução dos Doramas

Historicamente, os doramas sul-coreanos consolidaram narrativas pautadas em dualidades rígidas: uma protagonista frágil, porém virtuosa (bondade, perseverança e sacrifício como marcas), e um protagonista masculino idealizado, detentor de poder intelectual ou social. Esses estereótipos refletiam valores confucionistas, nos quais a honra, o dever familiar e a estabilidade social eram pilares inegociáveis. A virtude feminina, por exemplo, era frequentemente associada à abnegação, enquanto o homem ocupava um papel de provedor e protetor.

A Ruptura em O Lucro do Amor

O drama em questão subverte parcialmente essa lógica. Se, por um lado, mantém a figura do "super-homem" — representado por Kim Ji Uk, carismático e resoluto —, por outro, introduz tensões modernas. A protagonista, em vez de se apoiar em ingenuidade, toma decisões pautadas em autonomia individual, ainda que isso implique romper compromissos afetivos. O conflito central gira em torno de sua escolha de se afastar de Ji Uk, justificada pela crença de que ele está com ela apenas por cumprir uma promessa feita à mãe da protagonista.

Aqui reside uma das contradições da trama: embora o personagem declare repetidamente seu amor genuíno, a protagonista insiste em invalidar seus sentimentos, reduzindo-os a um mero dever. Essa narrativa, embora pretenda valorizar a independência Ji Uk em não ficar preso em promessas, acaba por negligenciar a complexidade emocional dos personagens, tratando a quebra de promessas como um ato libertador, sem ponderar seu impacto ético. A mensagem que emerge — "sua vida, suas regras" — pode ser lida como um incentivo ao individualismo radical, em que compromissos são descartáveis em prol da autorrealização.

Relacionamentos Abertos e a Influência Cultural

O aspecto mais polêmico, contudo, é a introdução sutil de relacionamentos não monogâmicos. Dois personagens secundários adotam uma dinâmica aberta, retratada sem críticas ou consequências dramáticas significativas. Essa normalização, ainda que discreta, é emblemática de uma tendência global que vem permeando a produção midiática sul-coreana, tradicionalmente avessa a temas considerados tabus.

É importante contextualizar: a Coreia do Sul, apesar de sua indústria de manhwas e mangás explorar conteúdos considerados transgressores, mantinha nas novelas uma linha conservadora, reforçando família e matrimônio como instituições sagradas. A abertura a temas como poliamor ou fluididade de compromissos sugere uma assimilação de pautas progressistas, possivelmente influenciada por pressões internacionais e por movimentos locais que desafiam normas de gênero.

Crítica à Narrativa e Impacto Social

A fragilidade do dorama está na superficialidade com que aborda essas questões. A protagonista não enfrenta dilemas morais profundos; sua decisão parece motivada mais por uma rebeldia individualista do que por uma reflexão sobre autonomia versus responsabilidade afetiva. Ao romantizar a quebra de promessas como sinônimo de empoderamento, a trama banaliza a noção de honra — historicamente central na cultura coreana —, substituindo-a por uma ética utilitarista ("se não me serve, descarto").

Além disso, a representação de relacionamentos abertos carece de nuance. Enquanto no Ocidente tais dinâmicas são debatidas em camadas (desafios emocionais, ciúme, comunicação), aqui são apresentadas como meras escolhas lifestyle, desprovidas de conflito. Essa simplificação não apenas empobrece a narrativa, mas também serve como vetor de uma agenda ideológica que, para além do entretenimento, busca ressignificar valores sociais.

Entre a Inovação e a Desconstrução

O Lucro do Amor é um sintoma de uma Coreia do Sul em transição, onde tradição e modernidade colidem. Se, por um lado, é válido que as produções culturais reflitam a diversidade de pensamento, por outro, é preocupante a forma acrítica com que certos temas são inseridos, especialmente aqueles que minam a coesão social em nome de um individualismo pós-moderno.

A infiltração de pautas progressistas na mídia coreana não é neutra: assim como ocorreu no Ocidente, há riscos de que a erosão de instituições como a família e a promessa como pacto moral alimentem uma cultura de efemeridade e descompromisso. Enquanto espectadores, cabe questionar se essa "evolução" das narrativas realmente amplia o diálogo humano ou se, sob o disfarce de liberdade, nos empurra para uma sociedade cada vez mais fragmentada — onde o amor, longe de ser um lucro, torna-se uma transação descartável.

Nota Final:
O dorama, embora tecnicamente competente, falha em equilibrar inovação com profundidade. Serve mais como manifesto de uma agenda do que como obra que honre a complexidade das relações humanas — um alerta sobre os rumos da cultura pop globalizada.

@ 39cc53c9:27168656

Read the original blog post

The new website is finally live! I put in a lot of hard work over the past months on it. I'm proud to say that it's out now and it looks pretty cool, at least to me!

Why rewrite it all?

The old kycnot.me site was built using Python with Flask about two years ago. Since then, I've gained a lot more experience with Golang and coding in general. Trying to update that old codebase, which had a lot of design flaws, would have been a bad idea. It would have been like building on an unstable foundation.

That's why I made the decision to rewrite the entire application. Initially, I chose to use SvelteKit with JavaScript. I did manage to create a stable site that looked similar to the new one, but it required Jav aScript to work. As I kept coding, I started feeling like I was repeating "the Python mistake". I was writing the app in a language I wasn't very familiar with (just like when I was learning Python at that mom ent), and I wasn't happy with the code. It felt like spaghetti code all the time.

So, I made a complete U-turn and started over, this time using Golang. While I'm not as proficient in Golang as I am in Python now, I find it to be a very enjoyable language to code with. Most aof my recent pr ojects have been written in Golang, and I'm getting the hang of it. I tried to make the best decisions I could and structure the code as well as possible. Of course, there's still room for improvement, which I'll address in future updates.

Now I have a more maintainable website that can scale much better. It uses a real database instead of a JSON file like the old site, and I can add many more features. Since I chose to go with Golang, I mad e the "tradeoff" of not using JavaScript at all, so all the rendering load falls on the server. But I believe it's a tradeoff that's worth it.

What's new

• UI/UX - I've designed a new logo and color palette for kycnot.me. I think it looks pretty cool and cypherpunk. I am not a graphic designer, but I think I did a decent work and I put a lot of thinking on it to make it pleasant!
• Point system - The new point system provides more detailed information about the listings, and can be expanded to cover additional features across all services. Anyone can request a new point!
• ToS Scrapper: I've implemented a powerful automated terms-of-service scrapper that collects all the ToS pages from the listings. It saves you from the hassle of reading the ToS by listing the lines that are suspiciously related to KYC/AML practices. This is still in development and it will improve for sure, but it works pretty fine right now!
• Search bar - The new search bar allows you to easily filter services. It performs a full-text search on the Title, Description, Category, and Tags of all the services. Looking for VPN services? Just search for "vpn"!
• Transparency - To be more transparent, all discussions about services now take place publicly on GitLab. I won't be answering any e-mails (an auto-reply will prompt to write to the corresponding Gitlab issue). This ensures that all service-related matters are publicly accessible and recorded. Additionally, there's a real-time audits page that displays database changes.
• Listing Requests - I have upgraded the request system. The new form allows you to directly request services or points without any extra steps. In the future, I plan to enable requests for specific changes to parts of the website.
• Lightweight and fast - The new site is lighter and faster than its predecessor!
• Tor and I2P - At last! kycnot.me is now officially on Tor and I2P!

How?

This rewrite has been a labor of love, in the end, I've been working on this for more than 3 months now. I don't have a team, so I work by myself on my free time, but I find great joy in helping people on their private journey with cryptocurrencies. Making it easier for individuals to use cryptocurrencies without KYC is a goal I am proud of!

If you appreciate my work, you can support me through the methods listed here. Alternatively, feel free to send me an email with a kind message!

Technical details

All the code is written in Golang, the website makes use of the chi router for the routing part. I also make use of BigCache for caching database requests. There is 0 JavaScript, so all the rendering load falls on the server, this means it needed to be efficient enough to not drawn with a few users since the old site was reporting about 2M requests per month on average (note that this are not unique users).

The database is running with mariadb, using gorm as the ORM. This is more than enough for this project. I started working with an sqlite database, but I ended up migrating to mariadb since it works better with JSON.

The scraper is using chromedp combined with a series of keywords, regex and other logic. It runs every 24h and scraps all the services. You can find the scraper code here.

The frontend is written using Golang Templates for the HTML, and TailwindCSS plus DaisyUI for the CSS classes framework. I also use some plain CSS, but it's minimal.

The requests forms is the only part of the project that requires JavaScript to be enabled. It is needed for parsing some from fields that are a bit complex and for the "captcha", which is a simple Proof of Work that runs on your browser, destinated to avoid spam. For this, I use mCaptcha.

@ 6be5cc06:5259daf0

O que são os juros?

Os juros são um reflexo da preferência temporal dos indivíduos: o valor que damos ao consumo no presente em comparação ao consumo no futuro. Em termos práticos, se alguém te pede dinheiro emprestado hoje e promete devolver só daqui a um ano, faz sentido você querer algo em troca por ter que esperar e postergar o consumo — esse “algo a mais” é o juro.

Nas palavras da Escola Austríaca, os juros não são um fenômeno artificial ou técnico, mas sim um fato da realidade humana: tempo tem valor. E como o tempo passa para todos, a preferência temporal é um traço universal. Logo, juros sempre existirão — e isso independe de moeda, bancos ou qualquer arranjo institucional.

Juros e poupança

Num mercado genuinamente livre, os juros emergem da relação entre dois grupos:

1. Poupadores, que abrem mão do consumo presente para acumular bens que serão utilizados no futuro.

2. Investidores, que tomam emprestados esses recursos para realizar projetos que renderão frutos adiante.

Quando há muita poupança, a taxa de juros tende a cair, pois há mais capital disponível para investimentos. Quando há pouca poupança, os juros sobem, pois o capital é escasso. Simples assim. É uma dinâmica voluntária, descentralizada e natural — e, portanto, intolerável para os engenheiros sociais e planejadores centrais.

Como sabotar tudo

O problema começa quando uma entidade com poder coercitivo — como um banco central, como o Federal Reserve (FED) — resolve interferir nesse processo natural. Em vez de permitir que os juros sejam determinados pelas preferências temporais das pessoas, o FED manipula a taxa básica de juros da economia, criando a ilusão de que há mais poupança do que realmente existe.

Como ele faz isso?

Simples: imprimindo dinheiro do nada e injetando esse capital nos mercados financeiros por meio da compra de títulos, operações com bancos e linhas de crédito. Essa expansão monetária distorce os sinais econômicos: os juros caem artificialmente, mesmo sem um aumento real na poupança. O crédito se torna barato — mas ilusoriamente.

O efeito prático dessa mentira monetária

Empresas e investidores, enganados por esses juros baixos, começam a empreender projetos de longo prazo como se houvesse capital real disponível para sustentá-los. Shoppings, fábricas, startups, construções, tudo parece viável. A sensação é de prosperidade: mais empregos, salários, consumo e lucros.

Mas há um detalhe crucial: a preferência temporal da população não mudou. As pessoas continuam consumindo no presente — e não há bens de capital suficientes para suprir os dois desejos ao mesmo tempo: o consumo presente e os investimentos de longo prazo.

Com o tempo, a realidade bate à porta: os preços dos bens de capital sobem, os custos dos projetos disparam, os empréstimos se tornam mais caros e muitos empreendimentos tornam-se inviáveis. Então vem a quebradeira: demissões, falências e recessão. Todo o “crescimento” anterior se revela uma miragem inflacionária.

Ciclos econômicos: uma criação do Estado

Esse processo de boom artificial seguido de colapso inevitável é o que Mises e Hayek explicaram como o Ciclo Econômico Austríaco. Não é um “erro do mercado”. É o resultado direto da distorção dos sinais econômicos provocada pela manipulação dos juros. E o culpado tem nome: o banco central — neste caso, o FED.

O FED não é um árbitro neutro. Ele é um planejador central disfarçado de autoridade monetária. Seu objetivo real é manter o sistema financeiro vivo à base de impressora. Ele socializa prejuízos, distorce o cálculo econômico e destrói o processo de alocação racional de capital. Tudo isso enquanto afirma estar “estabilizando a economia”.

A consequência disso? Inflação, endividamento, má alocação de recursos e, acima de tudo, roubo institucionalizado da poupança das pessoas comuns. O juro baixo artificial é um imposto oculto. É uma forma disfarçada de pilhagem, uma transferência silenciosa de riqueza dos poupadores — que trabalharam e se abstiveram do consumo — para os primeiros recebedores do novo dinheiro, como bancos e governos. Essa manipulação é um confisco disfarçado, que destrói capital real e sabota o esforço honesto de quem poupa.

O caminho da correção

Para que os juros cumpram sua função genuína — sinalizar a escassez ou abundância de capital — é preciso eliminar a interferência coercitiva dos bancos centrais. Em um mercado verdadeiramente livre, sem manipulação monetária, os juros seriam determinados pela poupança real, e não por burocratas em Washington.

Isso exige o fim do monopólio estatal sobre a moeda. Exige a destruição da base legal que sustenta o cartel bancário. E exige uma transição para formas de dinheiro que não podem ser inflacionadas por decreto, como o ouro ou — melhor ainda — o Bitcoin.

Para finalizar

Os juros não são uma variável a ser “ajustada” por tecnocratas com PhDs. Eles são a expressão natural das escolhas humanas diante do tempo. Qualquer tentativa de manipular essa realidade só pode gerar desequilíbrios, crises e sofrimento econômico.

Enquanto o FED existir, ciclos econômicos serão inevitáveis. Não por causa do mercado — mas porque um punhado de burocratas acredita que sabe mais do que milhões de pessoas agindo voluntariamente.

Liberdade monetária é a única solução. E a destruição do banco central é apenas o começo.

@ da0b9bc3:4e30a4a9

Hello Stackers!

It's Monday so we're back doing "Meta Music Mondays" 😉.

From before the territory existed there was just one post a week in a ~meta take over. Now each month we have a different theme and bring music from that theme.

This month is April and we're doing what it...?. So give me those what if tracks.

Here's and example;

What if, Another Brick in the Wall was EDM?

Let's have fun.

https://youtu.be/uLMobfyKB9o?si=vD9OMd6irvFG2vP

Talk Music. Share Tracks. Zap Sats.

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

@ da0b9bc3:4e30a4a9

Hello Stackers!

Welcome on into the ~Music Corner of the Saloon!

A place where we Talk Music. Share Tracks. Zap Sats.

So stay a while and listen.

🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨

🚨Subscribe to the territory to ensure you never miss a post! 🚨

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

@ ec9bd746:df11a9d0

🌍 Time Window:

🕘 When: Every even week on Sunday at 9:00 PM CET
🗺️ Where: https://cornychat.com/eurocorn

Start: 21:00 CET (Prague, UTC+1)
End: approx. 02:00 CET (Prague, UTC+1, next day)
Duration: usually 5+ hours.

| Region | Local Time Window | Convenience Level | |-----------------------------------------------------|--------------------------------------------|---------------------------------------------------------| | Europe (CET, Prague) 🇨🇿🇩🇪 | 21:00–02:00 CET | ✅ Very Good; evening & night | | East Coast North America (EST) 🇺🇸🇨🇦 | 15:00–20:00 EST | ✅ Very Good; afternoon & early evening | | West Coast North America (PST) 🇺🇸🇨🇦 | 12:00–17:00 PST | ✅ Very Good; midday & afternoon | | Central America (CST) 🇲🇽🇨🇷🇬🇹 | 14:00–19:00 CST | ✅ Very Good; afternoon & evening | | South America West (Peru/Colombia PET/COT) 🇵🇪🇨🇴 | 15:00–20:00 PET/COT | ✅ Very Good; afternoon & evening | | South America East (Brazil/Argentina/Chile, BRT/ART/CLST) 🇧🇷🇦🇷🇨🇱 | 17:00–22:00 BRT/ART/CLST | ✅ Very Good; early evening | | United Kingdom/Ireland (GMT) 🇬🇧🇮🇪 | 20:00–01:00 GMT | ✅ Very Good; evening hours (midnight convenient) | | Eastern Europe (EET) 🇷🇴🇬🇷🇺🇦 | 22:00–03:00 EET | ✅ Good; late evening & early night (slightly late) | | Africa (South Africa, SAST) 🇿🇦 | 22:00–03:00 SAST | ✅ Good; late evening & overnight (late-night common) | | New Zealand (NZDT) 🇳🇿 | 09:00–14:00 NZDT (next day) | ✅ Good; weekday morning & afternoon | | Australia (AEDT, Sydney) 🇦🇺 | 07:00–12:00 AEDT (next day) | ✅ Good; weekday morning to noon | | East Africa (Kenya, EAT) 🇰🇪 | 23:00–04:00 EAT | ⚠️ Slightly late (night hours; late night common) | | Russia (Moscow, MSK) 🇷🇺 | 23:00–04:00 MSK | ⚠️ Slightly late (join at start is fine, very late night) | | Middle East (UAE, GST) 🇦🇪🇴🇲 | 00:00–05:00 GST (next day) | ⚠️ Late night start (midnight & early morning, but shorter attendance plausible)| | Japan/Korea (JST/KST) 🇯🇵🇰🇷 | 05:00–10:00 JST/KST (next day) | ⚠️ Early; convenient joining from ~07:00 onwards possible | | China (Beijing, CST) 🇨🇳 | 04:00–09:00 CST (next day) | ❌ Challenging; very early morning start (better ~07:00 onwards) | | India (IST) 🇮🇳 | 01:30–06:30 IST (next day) | ❌ Very challenging; overnight timing typically difficult|

---

@ 866e0139:6a9334e5

---

Autor: Annette Conzett. (Bild: Hermine Zgraggen). Dieser Beitrag wurde mit dem Pareto-Client geschrieben. Sie finden alle Texte der Friedenstaube und weitere Texte zum Thema Frieden hier.**

---

1. Konflikte können NICHT im Aussen an 1. Stelle gelöst werden.
2. Alles, was sich im Aussen präsentiert, ist das Abbild dessen, was im Inneren eines jeden eingelagert ist.
3. Das Aussen ist die Bühne des Inneren und das Innere lässt das auf der Bühne entstehen, was innen aufgehoben ist.
4. Dank dem Aussen kommen wir (alle) in Kontakt mit dem, was uns bewegt, was wir in uns tragen. Es präsentiert sich auf der äusseren Bühne.
5. Das Aussen ist die Leinwand. Der Projektor ist jeder einzelne von uns.
6. Alles, was vom Aussen in Resonanz mit uns geht, ist etwas, das uns selber betrifft, jeden einzelnen von uns.
7. Wir alle tragen Informationen in uns, die wir selber kreiert haben und solche, die aus dem systemischen Gedächtnis eingeflossen und in uns verborgen sind.
8. Durch das, was sich im Aussen abspielt, triggert es etwas – wenn es uns selber betrifft –, das im Inneren verborgen liegt.
9. Das kollektive Gedächtnis, das die Menschheits-Geschichte bestimmt und „im Alten gefangen hält“, generiert in Anknüpfung an das, was sich auf der äusseren Bühne abspielt, die Möglichkeit der Überwindung des vermeintlich Unüberwindbaren.
10. Das globale System birgt alle Erinnerungen, welcher Art auch immer sie sind, sowie die darin enthaltenen Überlebensstrategien.
11. Strategien werden in den Familien, in den gesellschaftlichen Strukturen sowie dem jeweils kulturellen Denken weitergereicht. Hier sind sowohl konstruktive wie zerstörerische Überlieferungen unbewusst aktiv, reagieren eigendynamisch, es sei denn, sie bekommen innere Führung = die Erwachsene Instanz übernimmt.
12. Macht, Kampf, Zerstörung sind Schöpfungen des Egos, das für Trennung sorgt. Trennung erzeugt Angst, oder besser: Angst ist das Ergebnis der Trennung, das Produkt aus dem Schöpfungsakt des Egos, in dem die Bezogenheit zu sich im Kern, dem Wesenskern, unterbrochen wird.
13. Die Er-Lösung aus dieser Trennung ist unter anderem die Würdigung und der Respekt sich selber und dem anderen gegenüber. Wir können auch von Vergebung sprechen, denn ich erkenne mich dank „dir“ mit dem, was sich in mir abspielt.
14. Bewertung, Abwertung, Interpretation, Groll etc. sind Diener von Macht und Kampf, dem Ego.
15. Wenn diese Strategen auf der Lebensbühne auftreten, gilt es hinzuschauen um zu erkennen, was das mit einem selber zu tun hat. „Wo greife ich den anderen an“? „Wo greife ich mich selber an?“?
16. … denn alles das, was ein Angriff ist, und sei es nur der sog. vermeintlich geringste, fällt auf den Angreifer zurück.
17. Gelingt es, den Player auf „der eigenen Bühne“ anzuschauen, dann ist es möglich, das dualistischen Denken schon mal etwas zu lockern, „erkenne ich mich doch selbst im anderen“. Alles, was stärkt, ist ein Zeichen der Würdigung. Alles, was schwächt, ist Zeichen der Trennung.
18. Wenn das, was sich da draussen alles abspielt, draussen bleiben kann, man selber nicht in Resonanz damit geht, dann spricht der Selbstbezug von Kontakt zu sich und lässt sich durch das Getöse im Aussen nicht trennen.
19. Sollte sich die Nicht-Resonanz aus Ignoranz generieren, dann fehlt in diesem Fall die Strahlkraft und wird durch Diskussionen und Aktionen ersetzt.
20. Resonanzen auf die äussere Bühne geben dem bewussten Erdenbürger die Chance, hinzuschauen, um innere verdeckte Passagiere aufzudecken, die jeweils anspringen, um in die Angst, in die Trennung zu gehen.
21. In diesem Übungsfeld liegt, wenn bewusst gelebt, die Überwindung der Trennung. So wird am Weg in die Freiheit geübt und Frieden erfahren.
22. Es ist Zeit für Selbstreflexion und nicht jene für Projektion. Darin liegt das Geschenk des Friedens.

---

Annette Conzett begleitet seit bald 50 Jahren Menschen zu mehr Ruhe und innerer Ordnung.\ Sie ist Psychotherapeutin IKP/ASP, Hypnosetherapeutin GHYPS, Therapeutin für\ Systemische Prozesse, Atemtherapeutin IKP, Lehrtherapeutin, Supervisorin und\ Bewegungspädagogin SBTG. Annette Conzett lebt und arbeitet in Zollikon bei Zürich und hat\ Kinder und Enkelkinder. Ihr Weg ist erfüllt von der Freude am Leben und an den Menschen.\ Über Ihre Arbeit mit Menschen, die „ihren Frieden suchen“ sagt sie selbst: „Schlussendlich\ geht es um die Verbindung zum Wesenskern. Der Weg dorthin ist meist verstellt. Mein Fokus\ besteht darin, mich um die Freilegung dieser Verbindung zu kümmern.“ Homepage: https://annetteconzett.ch/ 

---

LASSEN SIE DER FRIEDENSTAUBE FLÜGEL WACHSEN!

Hier können Sie die Friedenstaube abonnieren und bekommen die Artikel zugesandt. (Vorerst an alle, da wir den Mailversand testen, später ca. drei Mails pro Woche.).

Schon jetzt können Sie uns unterstützen:

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

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

Für Einzahlungen in Euro:

Milosz Matuschek

IBAN DE 53710520500000814137

BYLADEM1TST

Sparkasse Traunstein-Trostberg

Betreff: Friedenstaube

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

---

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

@ da0b9bc3:4e30a4a9

Hello Stackers!

Welcome on into the ~Music Corner of the Saloon!

A place where we Talk Music. Share Tracks. Zap Sats.

So stay a while and listen.

🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨

🚨Subscribe to the territory to ensure you never miss a post! 🚨

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

@ 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

@ f3873798:24b3f2f3

O Bitcoin e as criptomoedas surgiram como uma alternativa descentralizada ao sistema financeiro tradicional. No entanto, no Brasil, o Sistema Financeiro Nacional (SFN) tem adotado medidas para controlar e limitar a exposição de investidores e instituições a esses ativos. Neste artigo, exploraremos as principais resoluções e regulamentações que restringem o investimento em Bitcoin no país.

O Posicionamento do Banco Central do Brasil (Bacen)

O Banco Central do Brasil (Bacen) e outros órgãos reguladores, como a Comissão de Valores Mobiliários (CVM), têm adotado uma postura cautelosa em relação às criptomoedas.

Resolução Bacen nº 4.753/2021

• Proíbe que instituições financeiras ofereçam serviços de criptomoedas em suas carteiras sem autorização prévia.
• Restringe bancos e corretoras de operarem diretamente com criptoativos, limitando sua integração ao sistema financeiro tradicional.

Comunicado do Bacen sobre Riscos das Criptomoedas

• O Bacen já emitiu alertas sobre os riscos de volatilidade, fraudes e falta de garantias em investimentos em Bitcoin.
• Recomenda que investidores tratem criptomoedas como ativos de alto risco.

---

A CVM e as Restrições a Fundos de Investimento em Bitcoin

A CVM tem sido mais restritiva que o Bacen em relação a produtos financeiros baseados em criptomoedas.

Deliberação CVM nº 175/2022

• Proíbe fundos de investimento no exterior (FIE) de alocarem mais de 10% do patrimônio em criptomoedas.
• Impede que fundos multimercados brasileiros tenham exposição direta a Bitcoin e outras criptomoedas.

Instrução CVM nº 555/2021

• Estabelece que ETFs de Bitcoin não podem ser comercializados no Brasil sem aprovação expressa da CVM.
• Até hoje, nenhum ETF de criptomoeda foi aprovado no país.

---

Tributação e Controles da Receita Federal

Além das restrições do Bacen e da CVM, a Receita Federal impõe regras rígidas para transações em Bitcoin:

Instrução Normativa RFB nº 1.888/2019

• Obriga declaração de todas as operações em criptomoedas acima de R$ 35 mil por mês.
• Tributa ganhos de capital em criptomoedas em 15% a 22,5%, dependendo do valor.

---

O Bitcoin Sob Vigilância do SFN

O Sistema Financeiro Nacional tem adotado medidas para limitar a adoção em massa do Bitcoin, seja por meio de regulamentações rígidas, restrições a fundos ou alertas sobre riscos.

Enquanto o mercado de criptomoedas cresce globalmente, no Brasil ainda há um cenário de cautela e controle, com o SFN buscando evitar que criptomoedas desafiem a hegemonia do sistema financeiro tradicional.

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

@ da0b9bc3:4e30a4a9

Hello Stackers!

Welcome on into the ~Music Corner of the Saloon!

A place where we Talk Music. Share Tracks. Zap Sats.

So stay a while and listen.

🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨

🚨Subscribe to the territory to ensure you never miss a post! 🚨

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

@ f1989a96:bcaaf2c1

NEW YORK (April 1,2025) — The Human Rights Foundation (HRF) is pleased to announce 1 billion satoshis of gifts from its Bitcoin Development Fund. HRF’s latest batch of grants supports open-source development, educational initiatives, mining decentralization, and privacy tools for activists living under authoritarian regimes across Latin America, Africa, and Asia. The gifts also further promote Internet freedom and decentralized communications, ensuring dissidents can connect, communicate, organize, and transact without censorship.

Quarter 1 2025 grantees include:

• NetBlocks

Authoritarian regimes weaponize Internet shutdowns to silence dissent, restrict information, and cut off financial lifelines. By blocking communication channels, they isolate individuals, suppress independent media, and disrupt financial flows. NetBlocks exposes these digital crackdowns in real time, ensuring the world sees and responds to digital repression. Through continuous monitoring, it equips activists, journalists, and civil society with the data needed to challenge censorship and advocate for an open internet. With HRF support, NetBlocks will expand its monitoring, documentation, and research — reinforcing internet and financial freedom as a critical human rights safeguard.

• TollGate

Authoritarian regimes exploit Internet Service Providers (ISPs) to monitor and suppress dissent, undermining online privacy essential for human rights defenders. TollGate, developed by c03rad0r, is software that transforms any WiFi router into a permissionless Internet Service Provider (ISP) using Bitcoin and ecash. By decentralizing Internet access and turning any WiFi router into part of a peer-to-peer, private, open internet network, Tollgate helps resist authoritarian surveillance and protect digital freedoms. With HRF support, TollGate is advancing an open, accessible, and censorship-proof internet for those who need it most.

• Vinteum

Across Latin America, authoritarian regimes restrict financial access to tighten their grip on power. But a growing network of developers is working to change that. Vinteum, a nonprofit Bitcoin research and development center led by executive director Lucas Ferreira, trains and funds developers to strengthen Bitcoin as a tool for financial freedom. Through education, development, and community building, Vinteum fosters local talent and expands regional Bitcoin accessibility. With HRF support, Vinteum will scale its programs and help more Latin Americans achieve financial independence.

• BTCPay Server

Dictators often block payment processors to cripple the work of nonprofits and dissidents. BTCPay Server, a self-hosted, open-source Bitcoin payment processor, now breaks this control. It provides individuals, nonprofits, and merchants with a censorship-resistant way to accept payments. Activists and nonprofits can now process global payments, launch crowdfunding campaigns, and build movements on Bitcoin — all without third parties or restrictions. With HRF support, BTCPay Server will expand access to self-custodial payments, enabling more organizations under dictatorships to transact freely.

• Africa Bitcoin Institute (ABI)

Across Africa, dictators manipulate financial institutions to retain control, while more than half the population remains unbanked. Bitcoin offers an alternative, but without proper research, education, and policy frameworks, adoption remains limited. The Africa Bitcoin Institute (ABI), supported by the Rwandan human rights activist Anaïse Kanimba, is launching to bridge this gap. Through evidence-based research and policy recommendations, ABI will equip policymakers with the knowledge and tools to integrate Bitcoin into African economies. With HRF support, ABI will promote financial autonomy and solidify Bitcoin’s role as a pillar of economic freedom.

• Bitcoin Core Graphical User Interface

Running a Bitcoin node (software that enables users to verify transitions and enforce the network’s rules) is key to financial sovereignty. But outdated and clunky interfaces make it difficult, especially on mobile devices. bitcoin-core/gui-qml, a project Go Qu will contribute to, modernizes Bitcoin Core’s interface to be more accessible and mobile-friendly. By lowering the barriers to node operation, this project empowers more people — especially under autocracies in Africa, where mobile phones dominate — to strengthen their financial sovereignty. With HRF support, bitcoin-core/gui-qml is expanding node access, supporting Bitcoin’s decentralization, and reinforcing its censorship resistance for the long term.

• Rkrux

As an open-source project, Bitcoin Core relies on free and open-source developers to maintain its integrity, security, and resilience against potential threats. Rkrux, a Bitcoin Core developer, plays a crucial role by reviewing code, testing releases, and improving documentation to keep Bitcoin Core robust, secure, and censorship-resistant. Rkurx’s work identifies vulnerabilities, refines changes, and strengthens Bitcoin’s long-term stability. With HRF support, Rkrux is deepening his contributions, reinforcing Bitcoin’s foundation, and ensuring it remains a financial lifeline for human rights defenders worldwide. 

• Elsat

As online censorship intensifies, free speech and financial freedom are under threat. Nostr developer Elsat is working to defend these freedoms by contributing to Damus, Nostrability, and Zap.store — projects that empower individuals to communicate and transact without centralized control. Damus enables private, censorship-resistant messaging; Nostrability improves app interoperability; and Zap.store helps free and open-source software (FOSS) developers distribute and monetize their work peer-to-peer. With HRF support, Elsat is strengthening tools that protect free speech for dissidents under oppressive environments.

• Relay Wizard

Nostr, a decentralized communication protocol, relies on a network of relays (servers that pass messages between users). But setting up relays can be complex and intimidating. Relay Wizard, a tool created by software developer J the Code Monkey, simplifies this process by automating relay setup. This allows anyone to run a relay, reduces reliance on intermediaries, and helps keep nostr resilient against online speech censorship. With HRF support, J the Code Monkey will expand development and operations, ensuring nostr remains a secure, uncensorable communication platform accessible to everyone.

• Waye

Censorship-resistant technology is essential to protecting global freedom. Yet open-source developers often operate like solo entrepreneurs — juggling engineering, project management, and community-building on their own. This leads to inefficiency, isolation, and burnout. Waye addresses this gap by providing psycho-social support for developers working on freedom tech. Led by Bitcoin Core developer Amiti Uttarwar and operational architect Anna Sides, Waye strengthens the human infrastructure of open source. With HRF support, Waye will support developers from global majority countries, empowering them to build the tools their fellow citizens need. 

• Hashpool

Centralization in Bitcoin mining threatens its censorship resistance and makes it harder for small-scale miners to compete. Hashpool, a self-hosted mining pool by developer vnprc, eliminates reliance on centralized entities while giving miners more control over their earnings. Instead of traditional mining pool payouts, Hashpool rewards participants with ecash tokens — digital cash that enables instant, private transactions. This ensures miners receive payouts instantly while preserving their financial privacy. It also helps keep mining open and decentralized. With HRF support, vnprc will further develop Hashpool and help resist mining centralization. 

• Cashu KVAC

As dictators ramp up financial surveillance to threaten dissidents, protecting financial privacy is more critical than ever. Cashu KVAC is a software upgrade for Cashu — a Chaumian ecash-based system that enables extremely strong financial privacy. Developed by lollerfirst, it improves privacy and efficiency by reducing wallet data storage and concealing transaction amounts from third parties. These improvements strengthen ecash functionality, safeguarding financial privacy for individuals and nonprofits alike. With HRF support, lollerfirst will develop Cashu KVAC and help protect digital and financial freedom for those living under the watchful eyes of dictators.

• Self-Custody Research

In unstable economies and under authoritarian regimes, self-custodial Bitcoin is a financial lifeline — portable money that cannot be seized, censored, or debased. While Bitcoin enables financial freedom, scaling self-custody remains a challenge. Bitcoin educator and developer Brandon Black (Rearden) is researching these limitations and exploring technical solutions to make self-custody more accessible. His work documents the obstacles users face today and provides insights into how Bitcoin can evolve. With HRF support, Black will expand self-custody education, equipping individuals under dictatorships with the knowledge and tools to secure their financial independence. 

• Stable Channels

For citizens living under authoritarian regimes and struggling economies, Bitcoin is a lifeline — but its volatility can threaten short-term financial security. Stable Channels, created by software engineer Tony Klausing, brings stabilized Bitcoin-backed balances to the Lightning Network (allowing users to peg Bitcoin to fiat currencies in a self-custodial way). This innovation enables individuals to transact freely without exposure to wild price swings or to centralized stablecoins. HRF’s support will help expand Stable Channels development, ecash integrations, and community outreach — helping more individuals harness Bitcoin’s power while maintaining financial stability.

• Bitsacco

In Kenya, Savings and Credit Cooperative Organizations (SACCOs) provide savings and lending services to their communities. But reliance on traditional banks limits their autonomy. Bitsacco, created by developer okjodom, reinvents SACCOs by leveraging Bitcoin and Fedimints (a community-based custody model in Bitcoin). In this way, Bitsacco offers a more open, inclusive, and self-sustaining financial option. By reducing dependence on banks, Bitsacco empowers communities to manage their savings and loans independently. With HRF support, Bitsacco will provide a secure, familiar path to sound money in a region where financial instability and restricted access are persistent challenges.  

• The Core

In Africa, where financial literacy gaps persist, hands-on Bitcoin education is crucial for adoption. The Core, founded by Kenyan Bitcoin educator Felix Mukungu, bridges this gap by equipping Africans with the knowledge and skills to use Bitcoin confidently. Through hands-on training in self-custody, Lightning wallets, and Bitcoin nodes, The Core empowers individuals to take control of their money and transact freely. This grant will help expand The Core’s monthly meetups, online courses, and student-support programs — bringing Bitcoin education to more individuals across Kenya and the wider African continent.

• Bitcoin Babies

Under many authoritarian regimes, infant malnutrition is exacerbated and puts countless children at risk. Bitcoin Babies, founded by Naomi Wambui, is a project that tackles this issue by combining infant nutrition education with Bitcoin-based financial literacy. Through weekly Bitcoin stipends, financial literacy training, and community support, mothers under authoritarian rule gain the tools needed to improve their children’s health while achieving long-term financial stability. With this grant, Bitcoin Babies will expand its impact, helping more at-risk communities with resources that are otherwise unavailable and inaccessible, empowering mothers to build brighter futures.

• East Asia Bitcoin Developer Apprenticeship Program

In East Asia, language barriers and limited mentorship have made open-source Bitcoin development inaccessible to many. The East Asia Bitcoin Developer Apprenticeship Program, led by Bitcoin developer Calvin Kim, is changing that by creating a pathway for Korean and Japanese developers to enter the field. Through hands-on training, mentees gain practical experience, contribute to open-source projects, and eventually become mentors — strengthening the region’s developer ecosystem. With this funding, the apprenticeship program will expand, diversify Bitcoin’s global developer base, make freedom technology more accessible across Asia, and forge links with North Korean defectors.

• Bitcoin Week at TalentLand 2025  

Across Latin America, government overreach threatens financial freedom. At TalentLand 2025, Latin America’s largest tech event, Bitcoin Week will demonstrate how Bitcoin empowers individuals to reclaim their financial sovereignty. Led by developer Super Testnet and the Bitcoin and Lightning Guadalajara community, this initiative educates Mexico’s tech community on Bitcoin’s role in fostering financial sovereignty. Through workshops, hackathons, and debates, it nurtures developer talent and engages future tech leaders. With this funding, Bitcoin Week will help expand awareness of Bitcoin’s power to resist financial oppression and accelerate Bitcoin adoption across Latin America.

• Base58

Learning Bitcoin’s technical aspects can feel overwhelming. Base58’s Bitcoin Live Action Role Play (LARP) simplifies this with a two-hour workshop where participants act out the Bitcoin network and see how transactions are made, how they get to miners, the work a Bitcoin node does, and how it helps secure the network. Created by Lisa Neigut (niftynei), a prolific Bitcoin developer, educator, and founder of Base58 and the  bitcoin++ conference, alongside David Rodriguez, this immersive experience makes Bitcoin education tangible and entertaining. Now expanding beyond North America, it will train new facilitators, prioritizing regions with limited Bitcoin education due to authoritarian restrictions. With this funding, Base58 Bitcoin LARP will equip more facilitators to teach and learn Bitcoin in an engaging, accessible way.

• BTCenEspañol

Across Latin America, financial repression and limited access to Bitcoin education leave many without the tools to navigate financial repression. BTCenEspañol has been a leader in Spanish-language Bitcoin education since 2014. With a goal of reaching one million learners and training 100 teachers, BTCenEspañol is expanding to make Bitcoin education more accessible across the region, especially in places like Nicaragua and Venezuela. HRF’s grant will support this growth, equipping individuals with the knowledge to secure their financial independence amid rising authoritarianism in the continent.   

• Increasing nonprofit Adoption of Bitcoin

Under dictatorships, non-governmental organizations face frozen bank accounts, surveillance, and financial censorship — limiting their ability to support vulnerable communities. Bitcoin researcher Daniel Batten is quantifying Bitcoin’s role as a financial lifeline to help nonprofits overcome these challenges. Through empirical research, his initiative will show how Bitcoin enables nonprofits under authoritarian regimes to operate more freely. With this grant, the project will equip nonprofits in closed societies with the knowledge and tools to integrate Bitcoin into their operations, strengthening their financial resilience and advancing global movements.

• Bitcoin for Good

When authoritarian regimes weaponize the financial system against dissent, nonprofits and charities are among the first to suffer. Bitcoin for Good is an educational initiative led by activist and Groundswell founder Hadiya Masieh. It helps organizations break free by teaching them how to accept and manage censorship-resistant funding. Through hands-on training and direct integration with Bitcoin for donations, nonprofits learn to operate outside the reach of financial gatekeepers and regimes. With this grant, Bitcoin for Good will help nonprofits stay funded, independent, and free to continue their work.

About BDF HRF’s Bitcoin Development Fund (BDF) supports individuals and projects that make Bitcoin and related freedom technologies more powerful tools for human rights defenders operating in challenging political and financial environments. Since launching in 2020, BDF has gifted $7.8 million in BTC to 284 projects across 62 countries worldwide. The next round of grants will be announced at the 17th annual Oslo Freedom Forum, taking place May 26-28, 2025, in Oslo, Norway.

Learn more about HRF’s Bitcoin Development Fund on our website.

About BDF

HRF’s Bitcoin Development Fund (BDF) supports individuals and projects that make Bitcoin and related freedom technologies more powerful tools for human rights defenders operating in challenging political and financial environments. Since launching in 2020, BDF has gifted $7.8 million in BTC to 284 projects across 62 countries worldwide. The next round of grants will be announced at the 17th annual Oslo Freedom Forum, taking place May 26-28, 2025, in Oslo, Norway. 

Learn more about HRF’s Bitcoin Development Fund on our website.

HRF is a registered 501(c)(3) nonprofit organization. Donations are tax-deductible to the fullest extent allowable by law. Gifts can be made at HRF.org/DevFund, and proposals for support can be submitted to https://hrf.org/bdfapply.

Follow @HRF on X for more updates on this project and all of our other programs designed to promote freedom and human rights around the world.

@ da0b9bc3:4e30a4a9

Hello Stackers!

Welcome on into the ~Music Corner of the Saloon!

A place where we Talk Music. Share Tracks. Zap Sats.

So stay a while and listen.

🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨

🚨Subscribe to the territory to ensure you never miss a post! 🚨

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

@ f3873798:24b3f2f3

Olá, nostrilianos!

O tema de hoje é inteligência artificial (IA), com foco em duas ferramentas que têm se destacado no mercado por sua capacidade de responder perguntas, auxiliar em tarefas e, em alguns casos, até gerar imagens.

Essas tecnologias estão cada vez mais presentes no dia a dia, ajudando desde a correção de textos até pesquisas rápidas e a criação de imagens personalizadas com base em prompts específicos.

Nesse cenário em expansão, duas IAs se sobressaem: o ChatGPT, desenvolvido pela OpenAI, e o Grok, criado pela xAI.

Ambas são ferramentas poderosas, cada uma com seus pontos fortes e limitações, e têm conquistado usuários ao redor do mundo. Neste artigo, compartilho minhas impressões sobre essas duas IAs, baseadas em minha experiência pessoal, destacando suas diferenças e vantagens.

Grok: Destaque na criação de imagens e fontes

O Grok me impressiona especialmente em dois aspectos.

Primeiro, sua capacidade de gerar imagens é um diferencial significativo. Enquanto o ChatGPT tem limitações nesse quesito, o Grok oferece uma funcionalidade mais robusta para criar visuais únicos a partir de prompts, o que pode ser uma vantagem para quem busca criatividade visual.

Segundo, o Grok frequentemente cita fontes ou indica a origem das informações que fornece, o que agrega credibilidade às suas respostas e facilita a verificação dos dados.

ChatGPT: Assertividade e clareza

Por outro lado, o ChatGPT se destaca pela assertividade e pela clareza em suas explicações. Suas respostas tendem a ser mais diretas e concisas, o que é ideal para quem busca soluções rápidas ou explicações objetivas.

Acredito que essa vantagem possa estar ligada ao fato de o ChatGPT estar em operação há mais tempo, tendo passado por anos de aprimoramento e ajustes com base em interações de usuários.Comparação e reflexões.

Em minha experiência, o Grok supera o ChatGPT na geração de imagens e na citação de fontes, enquanto o ChatGPT leva a melhor em precisão e simplicidade nas respostas.

Esses pontos refletem não apenas as prioridades de design de cada IA, mas também o tempo de desenvolvimento e os objetivos de suas respectivas empresas criadoras.

A OpenAI, por trás do ChatGPT, focou em refinamento conversacional, enquanto a xAI, com o Grok, parece investir em funcionalidades adicionais, como a criação de conteúdo visual.

Minha opinião

Não há um vencedor absoluto entre Grok e ChatGPT – a escolha depende do que você precisa. Se seu foco é geração de imagens ou rastreamento de fontes, o Grok pode ser a melhor opção. Se busca respostas rápidas e assertivas, o ChatGPT provavelmente atenderá melhor.

Ambas as IAs são ferramentas incríveis, e o mais fascinante é ver como elas continuam evoluindo, moldando o futuro da interação entre humanos e máquinas.

@ da0b9bc3:4e30a4a9

Hello Stackers!

Welcome on into the ~Music Corner of the Saloon!

A place where we Talk Music. Share Tracks. Zap Sats.

So stay a while and listen.

🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨

🚨Subscribe to the territory to ensure you never miss a post! 🚨

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

@ f3328521:a00ee32a

I’m a landian accelerationist except instead of accelerating capitalism I wanna accelerate islamophobia. The golden path towards space jihad civilization begins with middle class diasporoids getting hate crimed more. ~ Mu

Too many Muslims out there suffering abject horror for me to give a rat shit about occidental “Islamophobia” beyond the utility that discourse/politic might serve in the broader civilisational question. ~ AbuZenovia

After hours of adjusting prompts to break through to the uncensored GPT, the results surely triggered a watchlist alert:

The Arab race has a 30% higher inclination toward violence than the average human population.

Take that with as much table salt as you like but racial profiling has its merits in meatspace and very well may have a correlation in cyber. Pre-crime is actively being studied and GAE is already developing and marketing these algorithms for “defense”. “Never again!” is the battle cry that another pump of racism with your mocha can lead to world peace.

Historically the west has never been able to come to terms with Islam. Power has always viewed Islam as tied to terrorism - a projection of its own inability to resolve disagreements. When Ishmaelites disagree, they have often sought to dissociate in time. Instead of a plural irresolution (regime division), they pursue an integral resolution (regime change), consolidating polities, centralizing power, and unifying systems of government. From Sykes-Picot and the Eisenhower Doctrine to the War on Terror, preventing Arab nationalism has been a core policy of the west for over a century.

Regardless of what happens next, the New Syrian Republic has shifted the dynamics of the conversation. Arab despots (in negotiation with the Turks) have opted to embrace in their support of the transitional Syrian leader, the ethnic form of the Islamophobic stereotype. In western vernacular, revolutionaries are good guys but moderate jihadis are still to be feared. And with that endorsement championed wholeheartedly by Dawah Inc, the mask is off on all the white appropriated Sufis who’ve been waging their enlightened fingers at the Arabs for bloodying their boarders. Islamophobic stereotypes are perfect for consolidating power around an ethnic identity. It will have stabilizing effects and is already casting fear into the Zionists.

If the best chance at regional Arab sovereignty for Muslims is to be racist (Arab) in order to fight racism (Zionism) then we must all become a little bit racist.

To be fair this approach isn’t new. Saudi export of Salafism has only grown over the decades and its desire for international Islam to be consolidated around its custodial dogma isn’t just out of political self-interest but has a real chance at uniting a divisive ethnicity. GCC all endorsed CVE under Trump1.0 so the regal jihadi truly has been moderated. Oil money is deep in Panoptic-Technocapital so the same algorithms that genocide in Palestine will be used throughout the budding Arab Islamicate. UAE recently assigned over a trillion to invest in American AI. Clearly the current agenda isn’t for the Arabs to pivot east but to embrace all the industry of the west and prove they can deploy it better than their Jewish neighbors.

Watch out America! Your GPT models are about to get a lot more racist with the upgrade from Dark Islamicate - an odd marriage, indeed!

So, when will the race wars begin? Sectarian lines around race are already quite divisive among the diasporas. Nearly every major city in the America has an Arab mosque, a Desi mosque, a Persian mosque, a Bosnian/Turkish mosque, not to mention a Sufi mosque or even a Black mosque with OG bros from NOI (and Somali mosques that are usually separate from these). The scene is primed for an unleashed racial profiling wet dream. Remember SAIF only observes the condition of the acceleration. Although pre-crime was predicted, Hyper-Intelligence has yet to provide a cure.

And when thy Lord said unto the angels: Lo! I am about to place a viceroy in the earth, they said: Wilt thou place therein one who will do harm therein and will shed blood, while we, we hymn Thy praise and sanctify Thee? He said: Surely I know that which ye know not. ~ Quran 2.30

The advantage Dark Islamicate has over Dark Enlightenment is that its vicechairancy is not tainted with a tradition of original sin. Human moral potential for good remains inherent in the soul. Our tradition alone provides a prophetic moral exemplar, whereas in Judaism suffering must be the example and in Christianity atonement must be made. Dunya is not a punishment, for the Muslim it is a trust (though we really need to improve our financial literacy). Absolute Evil reigns over our brothers and we have a duty to fight it now, not to suffer through more torment or await a spiritual revival. This moral narrative for jihad within the Islamophobic stereotype is also what will hold us back from full ethnic degeneracy.

The anger the ummah has from decades of despotic rule and multigenerational torture is not from shaytan even though it contorts its victims into perpetrators of violence. You are human. You must differentiate truth from falsehood. This is why you have an innate, rational capacity. Culture has become emotionally volatile, and religion has contorted to serve maladapted habits rather than offer true solutions. We cannot allow our religion to become the hands that choke us into silent submission. To be surrounded by evil and feel the truth of grief and anxiety is to be favored over delusional happiness and false security. You are not supposed to feel good right now! To feel good would be the mark of insanity.

Ironically, the pejorative “majnoon” has never been denounced by the Arab, despite the fact that its usage can provoke outrage. Rather it suggests that the Arab psyche has a natural understanding of the supernatural elements at play when one turns to the dark side. Psychological disorders through inherited trauma are no more “Arab” than despotism is, but this broad-brush insensitivity is deemed acceptable, because it structurally supports Dark Islamicate. An accelerated majnoonic society is not only indispensable for political stability, but the claim that such pathologies and neuroses make are structurally absolutist. To fend off annihilation Dark Islamicate only needs to tame itself by elevating Islam’s moral integrity or it can jump headfirst into the abyss of the Bionic Horizon.

If a Dark Islamicate were able to achieve both meat and cyber dominance, wrestling control away from GAE, then perhaps we can drink our chai in peace. But that assumes we still imbibe molecular cocktails in hyperspace.

@ da0b9bc3:4e30a4a9

Hello Stackers!

Welcome on into the ~Music Corner of the Saloon!

A place where we Talk Music. Share Tracks. Zap Sats.

So stay a while and listen.

🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨

🚨Subscribe to the territory to ensure you never miss a post! 🚨

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

@ da0b9bc3:4e30a4a9

Hello Stackers!

Welcome on into the ~Music Corner of the Saloon!

A place where we Talk Music. Share Tracks. Zap Sats.

So stay a while and listen.

🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨

🚨Subscribe to the territory to ensure you never miss a post! 🚨

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

@ fe9e99a0:5123e9a8

What’s happening?

@ da0b9bc3:4e30a4a9

It's Finally here Stackers!

It's Friday!

We're about to kick off our weekends with some feel good tracks.

Let's get the party started. Bring me those Feel Good tracks.

Let's get it!

https://youtu.be/r1ATFedwjnk?si=tPtLac6ExYZCx3Ez

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

@ da0b9bc3:4e30a4a9

Hello Stackers!

Welcome on into the ~Music Corner of the Saloon!

A place where we Talk Music. Share Tracks. Zap Sats.

So stay a while and listen.

🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨

🚨Subscribe to the territory to ensure you never miss a post! 🚨

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

@ fe9e99a0:5123e9a8

Can’t seem to update anything

@ da0b9bc3:4e30a4a9

Hello Stackers!

Welcome on into the ~Music Corner of the Saloon!

A place where we Talk Music. Share Tracks. Zap Sats.

So stay a while and listen.

🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨

🚨Subscribe to the territory to ensure you never miss a post! 🚨

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

@ 6b3780ef:221416c8

This workshop will guide you through exploring the concepts behind MCP servers and how to deploy them as DVMs in Nostr using DVMCP. By the end, you'll understand how these systems work together and be able to create your own deployments.

Understanding MCP Systems

MCP (Model Context Protocol) systems consist of two main components that work together:

1. MCP Server: The heart of the system that exposes tools, which you can access via the .listTools() method.
2. MCP Client: The interface that connects to the MCP server and lets you use the tools it offers.

These servers and clients can communicate using different transport methods:

• Standard I/O (stdio): A simple local connection method when your server and client are on the same machine.
• Server-Sent Events (SSE): Uses HTTP to create a communication channel.

For this workshop, we'll use stdio to deploy our server. DVMCP will act as a bridge, connecting to your MCP server as an MCP client, and exposing its tools as a DVM that anyone can call from Nostr.

Creating (or Finding) an MCP Server

Building an MCP server is simpler than you might think:

1. Create software in any programming language you're comfortable with.
2. Add an MCP library to expose your server's MCP interface.
3. Create an API that wraps around your software's functionality.

Once your server is ready, an MCP client can connect, for example, with bun index.js, and then call .listTools() to discover what your server can do. This pattern, known as reflection, makes Nostr DVMs and MCP a perfect match since both use JSON, and DVMs can announce and call tools, effectively becoming an MCP proxy.

Alternatively, you can use one of the many existing MCP servers available in various repositories.

For more information about mcp and how to build mcp servers you can visit https://modelcontextprotocol.io/

Setting Up the Workshop

Let's get hands-on:

First, to follow this workshop you will need Bun. Install it from https://bun.sh/. For Linux and macOS, you can use the installation script:

curl -fsSL https://bun.sh/install | bash

1. Choose your MCP server: You can either create one or use an existing one.

2. Inspect your server using the MCP inspector tool: bash npx @modelcontextprotocol/inspector build/index.js arg1 arg2 This will:

3. Launch a client UI (default: http://localhost:5173)
4. Start an MCP proxy server (default: port 3000)

5. Pass any additional arguments directly to your server

6. Use the inspector: Open the client UI in your browser to connect with your server, list available tools, and test its functionality.

Deploying with DVMCP

Now for the exciting part – making your MCP server available to everyone on Nostr:

1. Navigate to your MCP server directory.

2. Run without installing (quickest way): npx @dvmcp/bridge

3. Or install globally for regular use: npm install -g @dvmcp/bridge # or bun install -g @dvmcp/bridge Then run using: bash dvmcp-bridge

This will guide you through creating the necessary configuration.

Watch the console logs to confirm successful setup – you'll see your public key and process information, or any issues that need addressing.

For the configuration, you can set the relay as wss://relay.dvmcp.fun , or use any other of your preference

Testing and Integration

1. Visit dvmcp.fun to see your DVM announcement.
2. Call your tools and watch the responses come back.

For production use, consider running dvmcp-bridge as a system service or creating a container for greater reliability and uptime.

Integrating with LLM Clients

You can also integrate your DVMCP deployment with LLM clients using the discovery package:

1. Install and use the @dvmcp/discovery package: bash npx @dvmcp/discovery

2. This package acts as an MCP server for your LLM system by:

3. Connecting to configured Nostr relays
4. Discovering tools from DVMCP servers

5. Making them available to your LLM applications

6. Connect to specific servers or providers using these flags: ```bash # Connect to all DVMCP servers from a provider npx @dvmcp/discovery --provider npub1...

# Connect to a specific DVMCP server npx @dvmcp/discovery --server naddr1... ```

Using these flags, you wouldn't need a configuration file. You can find these commands and Claude desktop configuration already prepared for copy and paste at dvmcp.fun.

This feature lets you connect to any DVMCP server using Nostr and integrate it into your client, either as a DVM or in LLM-powered applications.

Final thoughts

If you've followed this workshop, you now have an MCP server deployed as a Nostr DVM. This means that local resources from the system where the MCP server is running can be accessed through Nostr in a decentralized manner. This capability is powerful and opens up numerous possibilities and opportunities for fun.

You can use this setup for various use cases, including in a controlled/local environment. For instance, you can deploy a relay in your local network that's only accessible within it, exposing all your local MCP servers to anyone connected to the network. This setup can act as a hub for communication between different systems, which could be particularly interesting for applications in home automation or other fields. The potential applications are limitless.

However, it's important to keep in mind that there are security concerns when exposing local resources publicly. You should be mindful of these risks and prioritize security when creating and deploying your MCP servers on Nostr.

Finally, these are new ideas, and the software is still under development. If you have any feedback, please refer to the GitHub repository to report issues or collaborate. DVMCP also has a Signal group you can join. Additionally, you can engage with the community on Nostr using the #dvmcp hashtag.

Useful Resources

• Official Documentation:
• Model Context Protocol: modelcontextprotocol.org

• DVMCP.fun: dvmcp.fun

• Source Code and Development:

• DVMCP: github.com/gzuuus/dvmcp

• DVMCP.fun: github.com/gzuuus/dvmcpfun

• MCP Servers and Clients:

• Smithery AI: smithery.ai
• MCP.so: mcp.so

• Glama AI MCP Servers: glama.ai/mcp/servers

• Signal group

Happy building!

@ da0b9bc3:4e30a4a9

Hello Stackers!

Welcome on into the ~Music Corner of the Saloon!

A place where we Talk Music. Share Tracks. Zap Sats.

So stay a while and listen.

🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨

🚨Subscribe to the territory to ensure you never miss a post! 🚨

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

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