@ bc575705:dba3ed39

In our hyper-connected age, the concept of "Know Your Customer" (KYC) has morphed from a regulatory necessity into a pervasive surveillance apparatus, subtly eroding our fundamental liberties. While purported to combat financial crime, KYC has become a tool for mass surveillance, data exploitation, and the gradual dismantling of personal privacy. Let’s embark on a comprehensive exploration of this system, exposing its inherent flaws and advocating for a paradigm shift towards decentralized financial sovereignty. ## **Beyond the Surface: The Intricate Web of KYC Data Collection** **KYC transcends mere identity verification;** it's a deep dive into the minutiae of our lives. Consider the breadth and depth of data extracted: **Geographic Surveillance:** Proof of address requirements delve into historical residency, creating granular maps of our movements. Combined with location data from mobile devices and online activity, this paints a comprehensive picture of our physical presence. **Financial Autopsy:** KYC dissects our financial lives with surgical precision. Income sources, asset declarations, and transaction histories are meticulously cataloged. Algorithmic analysis reveals spending habits, investment strategies, and even potential political affiliations. **Behavioral Predictive Modeling:** AI algorithms analyze our financial behavior, predicting future actions and preferences. This data is invaluable for targeted advertising, but also for social engineering and political manipulation. **Biometric Invasiveness:** Facial recognition, iris scans, and voice analysis create permanent, immutable records of our physical selves. These biometrics are highly sensitive and vulnerable to breaches, potentially leading to identity theft and even physical harm. **Social Network Mapping:** KYC extends beyond individuals, mapping our social and professional networks. Institutions analyze our connections, identifying potential risks based on our associations. This has a chilling effect on free association and dissent, as individuals become hesitant to associate with those deemed "risky." **Psychometric Profiling:** With the increase of online tests, and the collection of online data, companies and states can build psychometric profiles. These profiles can be used to predict actions, and even manipulate populations. ## **The Fallacy of Security: KYC's Ineffectiveness and the Rise of the Surveillance State** Despite its claims, KYC fails to effectively combat sophisticated financial crime. Instead, it creates a system of mass surveillance that disproportionately targets law-abiding citizens. **The Scourge of False Positives:** Automated KYC systems frequently generate false positives, flagging innocent individuals as potential criminals. This can lead to financial exclusion, reputational damage, and even legal persecution. **A Ticking Time Bomb:** Centralized KYC databases are prime targets for hackers, putting vast amounts of sensitive personal information at risk. Data breaches can lead to identity theft, financial fraud, and even physical harm. **The State's Panopticon:** KYC empowers governments to monitor the financial activities of their citizens, creating a powerful tool for surveillance and control. This can be used to suppress dissent, target political opponents, and enforce conformity. **The Criminals Advantage:** Sophisticated criminals easily bypass KYC using shell companies, money laundering, and other techniques. This makes KYC a system that punishes the innocent, and gives the criminals a false sense of security for the data collected. ## **Decentralized Alternatives: Reclaiming Financial Sovereignty and Privacy** In the face of this encroaching surveillance state, decentralized technologies offer a path to financial freedom and privacy. **Cryptocurrency | A Bastion of Financial Freedom:** Bitcoin and other cryptocurrencies provide censorship-resistant alternatives to traditional financial systems. They empower individuals to transact freely, without the need for intermediaries or government oversight. **Decentralized Finance (DeFi) | Democratizing Finance:** DeFi platforms offer a range of financial services, including lending, borrowing, and trading, without the need for traditional banks. These platforms are built on blockchain technology, ensuring transparency, security, and accessibility. **Self-Sovereign Identity (SSI) | Empowering Individuals:** SSI solutions enable individuals to control their own digital identities, without relying on centralized authorities. This allows for secure and private verification of identity, without the need to share sensitive personal information with every service provider. **Privacy-Enhancing Technologies (PETs) | Shielding Your Data:** Technologies like zero-knowledge proofs, homomorphic encryption, and secure multi-party computation can be used to protect personal data while still allowing for necessary verification. **Decentralized Autonomous Organizations (DAOs) | Creating new forms of governance:** DAOs provide new ways for groups to organize, and make decisions. They provide a transparent way to pool resources, and make decisions. ## **A Call to Action: Defending Our Digital Rights and Building a Decentralized Future** We cannot passively accept the erosion of our fundamental freedoms. We must actively defend our digital rights and demand a more just and equitable financial system. **Advocate for Robust Privacy Laws:** Demand stronger regulations that limit the collection and use of personal data. **Champion Decentralized Technologies:** Support the development and adoption of cryptocurrencies, DeFi platforms, and other decentralized solutions. **Educate and Empower:** Raise awareness about the dangers of KYC and state surveillance. **Cultivate Critical Thinking:** Question the narratives presented by governments and corporations. **Build Decentralized Communities:** Join and support decentralized communities that are working to build a more free and open financial system. **Demand transparency from all data collection:** Insist that all data collection is open, and that there are strong penalties for those that misuse data. **The fight for financial freedom is a fight for human freedom. Let us stand together and reclaim our digital sovereignty.**

@ f7d424b5:618c51e8

It's time for the obligatory Monster Hunter episode. Some of the audio is a little messed up towards the end of the episode, sorry about that. Minus a few relevant tangents this episode is almost entirely about Monster Hunter, I was being serious. Charts: - [Monster Hunter Wilds chart](https://steamdb.info/app/2246340/charts/) - [Capcom IR sales numbers for 2024](https://www.capcom.co.jp/ir/english/business/million.html) - [Avowed steam chart](https://steamdb.info/app/2457220/charts/) - [CP2077 Chart](https://steamdb.info/app/1091500/charts/#3y) Obligatory: - [Listen to the new episode here!](https://melonmancy.net/listen) - [Discuss this episode on OUR NEW FORUM](https://melonmancy.cafe/d/104-mp102-she-would-break-my-skull-by-patting-me-on-the-head) - [Get the RSS and Subscribe](https://feeds.rssblue.com/melonmancy-podcast) (this is a new feed URL, but the old one redirects here too!) - Get a modern podcast app to use that RSS feed on at [newpodcastapps.com](http://newpodcastapps.com/) - Or listen to the show on [the forum](https://melonmancy.cafe) using the embedded [Podverse](https://podverse.fm) player! - [Send your complaints here](https://melonmancy.net/contact-us) Reminder that this is a [Value4Value](https://value4value.info/) podcast so any support you can give us via a modern podcasting app is greatly appreciated and we will never bow to corporate sponsors! Our podcast is created entirely with free software and is proudly hosted on [RSSBlue!](https://rssblue.com)

@ c13fd381:b46236ea

# Nostr *IS* Bitcoin: The Layer 3 That Ends the Old Internet Most people are still trapped in the old way of thinking. They try to compare Nostr to decentralised social media, calling it “the new Twitter” or “the uncensorable Facebook.” But this mindset is limiting—it completely misses the fundamental truth about what Nostr is. Nostr isn’t just another application built alongside Bitcoin. **It is the next logical extension of Bitcoin itself—a Layer 3 that completes the decentralised internet.** Bitcoin solved money. The Lightning Network solved fast, scalable payments. Nostr solves identity, communication, and coordination. And when you put all of these pieces together, something profound happens: **the old internet becomes obsolete.** --- ## The Internet Today: A System of Control The internet as we know it is broken. It’s a patchwork of corporate-owned platforms that act as gatekeepers to communication, identity, and finance. Every time you log into Twitter, Instagram, or LinkedIn, you’re not really accessing *your* identity—you’re borrowing space on someone else’s server, subject to their rules. This is a permissioned system. Your access is conditional. - Your Twitter account? Twitter controls it. - Your Facebook profile? Facebook owns it. - Even your emails and cloud storage? They sit on a corporate server that can delete them at any time. Bitcoin exposed the flaw in this model when it did the same thing to banks. Before Bitcoin, money was always controlled by an intermediary. But with Bitcoin, **your money became truly yours**, with no need for banks or approval. Now, Nostr is doing the same thing for identity and communication. --- ## Nostr as Bitcoin’s Layer 3 To understand why **Nostr is Bitcoin**, you have to look at how the layers fit together: - **Layer 1: Bitcoin** – The base layer of decentralised money. - **Layer 2: Lightning Network** – Scalable, instant payments built on Bitcoin. - **Layer 3: Nostr** – Decentralised identity, communication, and coordination. Bitcoin gave us financial sovereignty. But money alone isn’t enough—you also need a way to **communicate, organise, and transact without permission.** That’s where Nostr comes in. Nostr acts as **the identity and coordination layer of Bitcoin.** It allows users to interact freely, without relying on corporations, while remaining interoperable with Bitcoin itself. Through cryptographic keys, your Nostr identity isn’t just a social media profile—it’s **your passport to the decentralised internet.** And because Nostr integrates directly with Bitcoin and Lightning, the system is already primed to support payments, contracts, and governance without intermediaries. This isn’t just a Twitter replacement. **This is the new internet.** --- ## Why Nostr Changes Everything ### 1. **Your Identity Becomes Yours** Nostr eliminates the need for platform-based identity. Instead of creating an account on someone else’s system, you control a private key that acts as your identity across every application. No bans, no suspensions, no need for permission. ### 2. **Social Media Becomes Just a Skin** In the old model, social media platforms *were* the network. But with Nostr, **the network exists independently of any specific app.** Twitter, Facebook, and LinkedIn all become interchangeable interfaces that simply display Nostr data. This makes platforms obsolete—because your identity, posts, and connections live *outside* of any single service. ### 3. **Bitcoin and Nostr Are Interoperable** Nostr isn't separate from Bitcoin—it’s built to work with it. Lightning payments are already integrated into Nostr through Zaps, allowing instant Bitcoin transactions to be woven into communication itself. This means: - Tipping and payments happen *natively* in social interactions. - Crowdfunding, subscriptions, and paywalls don’t require third-party payment processors. - Entire economic models become possible without intermediaries. ### 4. **Censorship Becomes Impossible** Unlike traditional social media, Nostr has **no central authority**. It’s a protocol, not a platform. No one can shut it down. If one relay (server) censors content, another can pick it up. Your data and identity persist regardless. This makes Nostr the first truly **unstoppable** system for global communication—just as Bitcoin is the first unstoppable system for money. --- ## The Frustration of Seeing the Future All of this is inevitable. And yet, most people still don’t see it. They’re still asking, *“What’s the best Twitter alternative?”* They’re still thinking in terms of Web 2.0 platforms, branding themselves through corporate services instead of owning their own digital identity. But this mindset will soon be irrelevant. With Nostr, identity and communication become **protocols, not platforms.** And once identity is self-sovereign, platforms lose their power entirely. --- ## The Only Path Forward The future isn’t being built on platforms. It’s being built on **protocols.** Bitcoin started this shift by decentralising money. Lightning made it scalable. Now, Nostr is finishing it—by decentralising identity, communication, and social interaction. The Nostr protocol is already deployed. The infrastructure is here. The transition is happening whether people realise it or not. It’s only a matter of time before the world wakes up and understands: **Nostr *IS* Bitcoin. The old internet is already dead.**

@ df67f9a7:2d4fc200

> For over a year, I have been developing “webs of trust onboarding and discovery” tools for Nostr. With additional funding, I hope to continue this endeavor in 2025. Here’s the story so far… ## What I’m Building More than simply a “list of follows follows”, “web of trust” implementations will power user discovery, content search, reviews and reccomendations, identity verification and access to all corners of the “trusted” Nostr network as it scales. Without relying on a central “trust authority” to recommend people and content for us, sovereign Nostr users will leverage many forms of “relative trust” derived from our own “web” of natural interactions, “simply” by normalizing and scoring these interactions. The problem is, Nostr doesn’t have an extensible library for performing these “web of trust” calculations and delivering standardized reccomendations to any client … until now. I have built a developer library by which clients and relays can offer “webs of trust” score calculations for any user. Primarily, I am also building a “social onboarding” client, which will leverage this library to provide “webs of trust” powered recommendations for new users at their crucial “first interaction” touchpoint. - [Meet Me On Nostr](https://nostrmeet.me) (onboarding client) : This is my first project on Nostr, which I started a year ago with seed funding from [@druid](https://primal.net/druid). This “social onboarding” client will leverage in person relationships, QR invites, and advocate recommendations to improve new user retention. Currently, it creates new accounts with encrypted keys upon scanning any user’s invite. Last summer, without additional funding or a reliable WoT engine to produce recommendations, I “paused” development of this project. - [GrapeRank Engine](https://github.com/Pretty-Good-Freedom-Tech/graperank-nodejs) (developer library) : Working with [@straycat](https://primal.net/straycat) last fall, I built an open source and extensible library for Nostr developers to integrate “web of trust” powered reccomendations into their products and services. The power of GrapeRank is that it can generate different recommendations for different use cases (not just “web of trust” from “follows and mutes”), configurable easily by developers and by end users. This library is currently in v0.1, “generating and storing usable scores” without NIP standard outputs for Nostr clients. - [My Grapevine](https://grapevine.my) (algo dashboard) : In addition, I’ve just now wrapped up the demo release of a web client by which users and developers can explore the power of the GrapeRank Engine. 
 ## Potential Impact Webs of Trust is how Nostr scales. But so far, “web of trust” recommendations on Nostr have been implemented ad-hoc by clients with no consistency and little choice for end users. The “onboarding and discovery” tools I am developing promise to : - Establish “sovereignty” for webs of trust users, by stimulating a “free market of choices” with open source libraries, enabling any developer to implement WoT powered recommendations with ease. - Accelerate the isolation of “bots and bad actors”, and improve the “trustiness” of Nostr for everyone else, by streamlining the onboarding of “real world” trusted people directly into established “webs of trust”. - Improve “discoverability of users and content” across all clients, by providing an extensible algo engine with “unlimited” NIP standard outputs, allowing any client to consume and take advantage of WoT powered recommendations, even as these NIPs are still in flux. - Pave the way for “global Nostr adoption”, where WoT powered recommendations (and searches) are consistently available for any user across a wide variety of clients. ## Timeline & Milestones 2025 roadmap for “Webs of Trust Onboarding and Discovery” : - [Meet Me On Nostr](https://nostrmeet.me/) (onboarding client) : MVP release : “scan my QR for instant account and DM with me on Nostr”. - [GrapeRank Engine ](https://github.com/Pretty-Good-Freedom-Tech/graperank-nodejs)(developer library) : 1.0 release : “output WoT scores to Nostr NIPs and other stuff” for consumption by clients and relays. - [My Grapevine](https://grapevine.my/) (algo dashboard) : 1.0 release : “usable dashboard with API endpoints” for end users to configure and consume GrapeRank scores on their own clients and relays. - [Meet Me On Nostr](https://nostrmeet.me/) (onboarding client) : 1.0 release : first integration with My Grapevine, offering “follow and app recommendations for invited users”, customizable per-invite for Nostr advocates. ## Funding In February 2024, I received a one time donation from [@druid](https://primal.net/druid) to start the “Meet Me On Nostr” client. In May 2024, I applied for an OpenSats grant to fund further development of “Meet Me On Nostr”. This was denied. In September 2024, [@straycat](https://primal.net/straycat) offered to fund me for three months, to develop the “GrapeRank Engine” and “My Grapevine” demo client around his algorithm design. I have a [Geyser Fund page](https://geyser.fund/project/nostrmeetme) Please reach out via DM if you are interested to fund part of this or any related project.

@ ddf03aca:5cb3bbbe

Welcome to Built with Cashu-TS, a series dedicated to crafting cool applications powered by Cashu and its TypeScript library, Cashu-TS. In this first post, we'll dive into creating a tiny, personal Lightning Address server! > [!NOTE] > Quick note: To keep things concise and easy to follow, the examples provided here aren't production-grade code. I'll clearly highlight spots where I've intentionally simplified or taken shortcuts. ## What we are building Today we are building a Lightning Address server. The server is responsible for returning a Lightning Invoice whenever someone tries to pay your Lightning Address. The exact flow is described in LUD16, but here is a quick rundown: 1. User enters your Lightning Address into their wallet 2. Wallet constructs the matching URL as per LUD16 and sends a GET request 3. Server creates a JSON response with some metadata (min amount, max amount, callback url, etc.) and returns it 4. Wallet displays metadata and upon user interaction sends a second SET request to the callback url including the specified amount. 5. Server fetches an invoice for the requested amount and returns it Usually the invoices are fetched from a Lightning Node. But today we are using a Cashu mint as our Lightning provider. ## Setup the project Our Lightning Address server will be written in TypeScript using the express framework. First we got to initialise a new project and install our dependencies. ```sh mkdir tiny-lud16 cd tiny-lud16 npm init npm i express cors @cashu/cashu-ts npm i -D typescript esbuild @types/node @types/cors @types/express ``` ### Adding a build script Because we are using TypeScript we need to add a build step to execute our code (recent versions of node support direct execution of node, but this is the "traditional" way). We are using esbuild to compile our code to JavaScript > [!NOTE] > esbuild does not check types. If you want to make sure your code typechecks use `tsc` **build.js** ```js #!/usr/bin/env node const esbuild = require("esbuild"); esbuild .build({ outdir: "dist/", format: "cjs", platform: "node", entryPoints: ["src/index.ts"], bundle: true, sourcemap: "external", }) .then(() => { console.log("Server built sucessfully"); }); ``` Now we can build our project using `node build.js` and then run our project with `node dist/index.js` ## Configuration Before we start working on our web server we need to set some options. For this we create `/src/config.ts` - `USERNAME` will be the address part in front of the `@`. - `HOSTNAME` is the URL (including the protocol) the server will run on - `MINT_URL` is the URL of the mint that we want to use to generate invoices and receive token from. - `MIN_AMOUNT` and `MAX_AMOUNT` are LNURL specific settings that define the range of amounts in mSats that we want to allow. > [!NOTE] > Because the smalles amount in the `sat` unit in Cashu is 1 Sat, `MIN_AMOUNT` can not be smaller than 1000 ```ts export const USERNAME = "egge"; export const HOSTNAME = " https://test.test"; export const MINT_URL = " https://mint.minibits.cash/Bitcoin"; export const MIN_AMOUNT = 1000; export const MAX_AMOUNT = 10000; ``` ## Adding some utility To keep our request handler clean, we will put some of the utility functions in a separate file `src/utils.ts`. ```ts import { HOSTNAME, MAX_AMOUNT, MIN_AMOUNT, USERNAME } from "./config"; export function createLnurlResponse() { return { callback: `${HOSTNAME}/.well-known/lnurlp/${USERNAME}`, maxSendable: MAX_AMOUNT, minSendable: MIN_AMOUNT, metadata: JSON.stringify([ ["text/plain", "A cashu lightning address... Neat!"], ]), tag: "payRequest", }; } export function isValidAmount(amountInSats: number) { return ( amount >= MIN_AMOUNT && amount <= MAX_AMOUNT && Number.isInteger(amount) ); } ``` The `createLnurlResponse` function creates the response for the first call to our LNURL endpoint. This structure is defined in LUD16 and in our case it does not rely on any state, other than the configuration constants we defined in `src/config.ts`. This object contains the metadata that is the response of step 3 in our flow. The `isValidAmount` function helps us determine whether the amount we will receive in Step 4 is valid. We check whether it is within the boundaries of our `MIN_AMOUNT` and `MAX_AMOUNT`. Because we will convert the requested amount from mSats into sats, we need to check whether this converted amount is an integer. ## Adding out wallet backend This blog series is about awesome Cashu use cases, so of course our "Lightning backend" is a mint. We are using the `@cashu/cashu-ts` npm package to streamline Cashu interaction. ```ts import { CashuMint, CashuWallet, getEncodedToken, Proof, } from "@cashu/cashu-ts"; import { MINT_URL } from "./config"; import { resolve } from "path"; import { existsSync, mkdirSync, writeFileSync } from "fs"; const mint = new CashuMint(MINT_URL); const wallet = new CashuWallet(mint); export async function createInvoiceAndHandlePayment(amount: number) { const { quote, request } = await wallet.createMintQuote(amount); const interval = setInterval(async () => { const stateRes = await wallet.checkMintQuote(quote); if (stateRes.state === "PAID") { const proofs = await wallet.mintProofs(amount, quote); clearInterval(interval); const token = turnProofsIntoToken(proofs); saveTokenLocally(token); } }, 10000); return request; } function turnProofsIntoToken(proofs: Proof[]) { return getEncodedToken({ mint: MINT_URL, proofs }); } function saveTokenLocally(token: string) { const tokenDirPath = resolve(__dirname, "../token"); if (!existsSync(tokenDirPath)) { mkdirSync(tokenDirPath); } writeFileSync(resolve(tokenDirPath, `${Date.now()}_token.txt`), token); } ``` The first thing we do here is instantiating a CashuWallet class from Cashu-TS. This class will take care of the Cashu operations required to create an invoice and mint tokens. Then we create a utility function that will handle our invoice creation and later make sure to check whether an invoice was paid. `wallet.createMintQuote` will talk to the mint to create a mint quote. The mint returns a `MintQuoteReponse` that includes the ID of the quote as well as the invoice (`request`) that needs to be paid before the Cashu proofs can be minted. This `request` is what we will return to the payer later. Once the mint quote is created we will start polling the mint for it's payment state using `wallet.checkMintQuote`. As soon as the state changes to `"PAID"` we know that the payment was done and we can mint the proofs using Cashu-TS' `mintProofs` method. This returns some Cashu proofs that we will serialize into a Cashu Token and save to our disk using the `saveTokenLocally` function. > [!NOTE] > In this example we use `setInterval` to poll for a payment update. In the real world you would use a proper request queue for this to make sure we do not spam the mint with too many requests at the same time > Also saving the token to disk is not ideal. You could instead send yourself a nostr DM or post it to a webhook ## Adding the handler Because our LNURL endpoint and our callback endpoint are the same, we only need a single route handler. This route handler will take care of any GET request coming in at `/.well-known/lnurlp/USERNAME`. Wether it is a callback or not can be determined by checking the `amount` query parameter. ```ts import { NextFunction, Request, Response } from "express"; import { createLnurlResponse, isValidAmount } from "./utils"; import { createInvoiceAndHandlePayment } from "./wallet"; export const lud16Controller = async ( req: Request<unknown, unknown, unknown, { amount: string }>, res: Response, next: NextFunction, ) => { try { if (!req.query.amount) { res.json(createLnurlResponse()); return; } const parsedAmount = parseInt(req.query.amount); const mintAmount = parsedAmount / 1000; const isValid = isValidAmount(mintAmount); if (!isValid) { throw new Error("Invalid Amount"); } const invoice = await createInvoiceAndHandlePayment(mintAmount); res.json({ pr: invoice, routes: [], }); } catch (e) { next(e); } }; ``` Let's take this handler function apart and see hat is happening here. First we check whether the `amount` query parameter is present. If it is not, we now that we are currently in step 3 of our LNURL flow. In this case all we need to do is create the expected metadata object using our `createLnurlResponse` utility and return it to the caller. If the parameter is present we are in step 5 of our flow and the real work begins. As mentioned above we need to first convert the amount, which is in mSats as per LUD16 into sats to be compatible with our mint running the `sat` unit. Because query parameters are always `string`, we use the built-in `parseInt` to parse the string into a `number`. We then check whether the amount is valid using our `isValidAmount` utility. If it is not, we throw an error which will get caught and passed to express' built in error middleware. > [!NOTE] > The error returned by the express middleware is a basic error page without proper error codes. Usually you would define error classed and a custom middleware to take care of this. Once we made sure that the amount is valid the Cashu logic takes place. We pass the amount to `createInvoiceAndHandlePayment` to create an invoice and start the state polling behind the scenes. At the end of the function we simply return the mint's invoice in a JSON reponse as per LUD16. ## Adding the route The last step of the process is to add our route handler to the right path of our web server. This path is defined in LUD16: `<domain>/.well-known/lnurlp/<username>`. We create our web server and add the route handler in `/src/index.ts`. ```ts import express from "express"; import { USERNAME } from "./config"; import { lud16Controller } from "./controller"; const app = express(); app.get("/.well-known/lnurlp/" + USERNAME, lud16Controller); app.listen(8080, () => { console.log("Server running on port 8080"); }); ``` This snippet is very straight forward. We create an express app, add the route handler to handle GET requests at our desired path and then tell the server to listen on port 8080. ## Conclusion With just a few lines of code and without using our own Lightning backend we have built a working LNURL Lightning Address server. This is one of the features I love so much about Cashu: It enables new Lightning and Bitcoin use cases. I hope you enjoyed this first part of the new series. Please make sure to leave your feedback 💜🥜