🏌️ Monday, May 26 – Bitcoin Golf Championship & Kickoff Party

Location: Las Vegas, Nevada\ Event: 2nd Annual Bitcoin Golf Championship & Kick Off Party"\ Where: Bali Hai Golf Clubhouse, 5160 S Las Vegas Blvd, Las Vegas, NV 89119\ 🎟️ Get Tickets!

Details:

• The week tees off in style with the Bitcoin Golf Championship. Swing clubs by day and swing to music by night.

• Live performances from Nostr-powered acts courtesy of Tunestr, including Ainsley Costello and others.

• Stop by the Purple Pill Booth hosted by Derek and Tanja, who will be on-boarding golfers and attendees to the decentralized social future with Nostr.

💬 May 27–29 – Bitcoin 2025 Conference at the Las Vegas Convention Center

Location: The Venetian Resort\ Main Attraction for Nostr Fans: The Nostr Lounge\ When: All day, Tuesday through Thursday\ Where: Right outside the Open Source Stage\ 🎟️ Get Tickets!

Come chill at the Nostr Lounge, your home base for all things decentralized social. With seating for \~50, comfy couches, high-tops, and good vibes, it’s the perfect space to meet developers, community leaders, and curious newcomers building the future of censorship-resistant communication.

Daily Highlights at the Lounge:

• ☕️ Hang out casually or sit down for a deeper conversation about the Nostr protocol

• 🔧 1:1 demos from app teams

• 🛍️ Merch available onsite

• 🧠 Impromptu lightning talks

• 🎤 Scheduled Meetups (details below)

🎯 Nostr Lounge Meetups

Wednesday, May 28 @ 1:00 PM

• Damus Meetup: Come meet the team behind Damus, the OG Nostr app for iOS that helped kickstart the social revolution. They'll also be showcasing their new cross-platform app, Notedeck, designed for a more unified Nostr experience across devices. Grab some merch, get a demo, and connect directly with the developers.

Thursday, May 29 @ 1:00 PM

• Primal Meetup: Dive into Primal, the slickest Nostr experience available on web, Android, and iOS. With a built-in wallet, zapping your favorite creators and friends has never been easier. The team will be on-site for hands-on demos, Q&A, merch giveaways, and deeper discussions on building the social layer of Bitcoin.

🎙️ Nostr Talks at Bitcoin 2025

If you want to hear from the minds building decentralized social, make sure you attend these two official conference sessions:

1. FROSTR Workshop: Multisig Nostr Signing

• 🕚 Time: 11:30 AM – 12:00 PM

• 📅 Date: Wednesday, May 28

• 📍 Location: Developer Zone

• 🎤 Speaker: Austin Kelsay, Voltage\ A deep-dive into FROST-based multisig key management for Nostr. Geared toward devs and power users interested in key security.

2. Panel: Decentralizing Social Media

• 🕑 Time: 2:00 PM – 2:30 PM

• 📅 Date: Thursday, May 29

• 📍 Location: Genesis Stage

• 🎙️ Moderator: McShane (Bitcoin Strategy @ Roxom TV)

• 👥 Speakers:

• Martti Malmi – Early Bitcoin dev, CEO @ Sirius Business Ltd

• Lyn Alden – Analyst & Partner @ Ego Death Capital

Get the big-picture perspective on why decentralized social matters and how Nostr fits into the future of digital communication.

🌃 NOS VEGAS Meetup & Afterparty

Date: Wednesday, May 28\ Time: 7:00 PM – 1:00 AM\ Location: We All Scream Nightclub, 517 Fremont St., Las Vegas, NV 89101\ 🎟️ Get Tickets!

What to Expect:

• 🎶 Live Music Stage – Featuring Ainsley Costello, Sara Jade, Able James, Martin Groom, Bobby Shell, Jessie Lark, and other V4V artists

• 🪩 DJ Party Deck – With sets by DJ Valerie B LOVE, TatumTurnUp, and more DJs throwing down

• 🛰️ Live-streamed via Tunestr

• 🧠 Nostr Education – Talks by Derek Ross, Tomer Strolight, Terry Yiu, OpenMike, and more.

• 🧾 Vendors & Project Booths – Explore new tools and services

• 🔐 Onboarding Stations – Learn how to use Nostr hands-on

• 🐦 Nostrich Flocking – Meet your favorite nyms IRL

• 🍸 Three Full Bars – Two floors of socializing overlooking vibrant Fremont Street

This is the after-party of the year for those who love freedom technology and decentralized social community. Don’t miss it.

Final Thoughts

Whether you're there to learn, network, party, or build, Bitcoin 2025 in Las Vegas has a packed week of Nostr-friendly programming. Be sure to catch all the events, visit the Nostr Lounge, and experience the growing decentralized social revolution.

🟣 Find us. Flock with us. Purple pill someone.

I remember the first gathering of Nostr devs two years ago in Costa Rica. We were all psyched because Nostr appeared to solve the problem of self-sovereign online identity and decentralized publishing. The protocol seemed well-suited for textual content, but it wasn't really designed to handle binary files, like images or video.

The Problem

When I publish a note that contains an image link, the note itself is resilient thanks to Nostr, but if the hosting service disappears or takes my image down, my note will be broken forever. We need a way to publish binary data without relying on a single hosting provider.

We were discussing how there really was no reliable solution to this problem even outside of Nostr. Peer-to-peer attempts like IPFS simply didn't work; they were hopelessly slow and unreliable in practice. Torrents worked for popular files like movies, but couldn't be relied on for general file hosting.

Awesome Blossom

A year later, I attended the Sovereign Engineering demo day in Madeira, organized by Pablo and Gigi. Many projects were presented over a three hour demo session that day, but one really stood out for me.

Introduced by hzrd149 and Stu Bowman, Blossom blew my mind because it showed how we can solve complex problems easily by simply relying on the fact that Nostr exists. Having an open user directory, with the corresponding social graph and web of trust is an incredible building block.

Since we can easily look up any user on Nostr and read their profile metadata, we can just get them to simply tell us where their files are stored. This, combined with hash-based addressing (borrowed from IPFS), is all we need to solve our problem.

How Blossom Works

The Blossom protocol (Blobs Stored Simply on Mediaservers) is formally defined in a series of BUDs (Blossom Upgrade Documents). Yes, Blossom is the most well-branded protocol in the history of protocols. Feel free to refer to the spec for details, but I will provide a high level explanation here.

The main idea behind Blossom can be summarized in three points:

1. Users specify which media server(s) they use via their public Blossom settings published on Nostr;
2. All files are uniquely addressable via hashes;
3. If an app fails to load a file from the original URL, it simply goes to get it from the server(s) specified in the user's Blossom settings.

Just like Nostr itself, the Blossom protocol is dead-simple and it works!

Let's use this image as an example:

If you look at the URL for this image, you will notice that it looks like this:

blossom.primal.net/c1aa63f983a44185d039092912bfb7f33adcf63ed3cae371ebe6905da5f688d0.jpg

All Blossom URLs follow this format:

[server]/[file-hash].[extension]

The file hash is important because it uniquely identifies the file in question. Apps can use it to verify that the file they received is exactly the file they requested. It also gives us the ability to reliably get the same file from a different server.

Nostr users declare which media server(s) they use by publishing their Blossom settings. If I store my files on Server A, and they get removed, I can simply upload them to Server B, update my public Blossom settings, and all Blossom-capable apps will be able to find them at the new location. All my existing notes will continue to display media content without any issues.

Blossom Mirroring

Let's face it, re-uploading files to another server after they got removed from the original server is not the best user experience. Most people wouldn't have the backups of all the files, and/or the desire to do this work.

This is where Blossom's mirroring feature comes handy. In addition to the primary media server, a Blossom user can set one one or more mirror servers. Under this setup, every time a file is uploaded to the primary server the Nostr app issues a mirror request to the primary server, directing it to copy the file to all the specified mirrors. This way there is always a copy of all content on multiple servers and in case the primary becomes unavailable, Blossom-capable apps will automatically start loading from the mirror.

Mirrors are really easy to setup (you can do it in two clicks in Primal) and this arrangement ensures robust media handling without any central points of failure. Note that you can use professional media hosting services side by side with self-hosted backup servers that anyone can run at home.

Using Blossom Within Primal

Blossom is natively integrated into the entire Primal stack and enabled by default. If you are using Primal 2.2 or later, you don't need to do anything to enable Blossom, all your media uploads are blossoming already.

To enhance user privacy, all Primal apps use the "/media" endpoint per BUD-05, which strips all metadata from uploaded files before they are saved and optionally mirrored to other Blossom servers, per user settings. You can use any Blossom server as your primary media server in Primal, as well as setup any number of mirrors:

## Conclusion

For such a simple protocol, Blossom gives us three major benefits:

1. Verifiable authenticity. All Nostr notes are always signed by the note author. With Blossom, the signed note includes a unique hash for each referenced media file, making it impossible to falsify.
2. File hosting redundancy. Having multiple live copies of referenced media files (via Blossom mirroring) greatly increases the resiliency of media content published on Nostr.
3. Censorship resistance. Blossom enables us to seamlessly switch media hosting providers in case of censorship.

Thanks for reading; and enjoy! 🌸

Its been six long months of refactoring code and building out to the applesauce packages but the app is stable enough for another release.

This update is pretty much a full rewrite of the non-visible parts of the app. all the background services were either moved out to the applesauce packages or rewritten, the result is that noStrudel is a little faster and much more consistent with connections and publishing.

New layout

The app has a new layout now, it takes advantage of the full desktop screen and looks a little better than it did before.

Removed NIP-72 communities

The NIP-72 communities are no longer part of the app, if you want to continue using them there are still a few apps that support them ( like satellite.earth ) but noStrudel won't support them going forward.

The communities where interesting but ultimately proved too have some fundamental flaws, most notably that all posts had to be approved by a moderator. There were some good ideas on how to improve it but they would have only been patches and wouldn't have fixed the underlying issues.

I wont promise to build it into noStrudel, but NIP-29 (relay based groups) look a lot more promising and already have better moderation abilities then NIP-72 communities could ever have.

Settings view

There is now a dedicated settings view, so no more hunting around for where the relays are set or trying to find how to add another account. its all in one place now

Cleaned up lists

The list views are a little cleaner now, and they have a simple edit modal

New emoji picker

Just another small improvement that makes the app feel more complete.

Experimental Wallet

There is a new "wallet" view in the app that lets you manage your NIP-60 cashu wallet. its very experimental and probably won't work for you, but its there and I hope to finish it up so the app can support NIP-61 nutzaps.

WARNING: Don't feed the wallet your hard earned sats, it will eat them!

Smaller improvements

• Added NSFW flag for replies
• Updated NIP-48 bunker login to work with new spec
• Linkfy BIPs
• Added 404 page
• Add NIP-22 comments under badges, files, and articles
• Add max height to timeline notes
• Fix articles view freezing on load
• Add option to mirror blobs when sharing notes
• Remove "open in drawer" for notes

Most darknet markets (DNMs) are designed poorly in the following ways:

1. Hosting

Most DNMs use a model whereby merchants fill out a form to create their listings, and the data they submit then gets hosted on the DNM's servers. In scenarios where a "legal" website would be forced to censor that content (e.g. a DMCA takedown order), DNMs, of course, do not obey. This can lead to authorities trying to find the DNM's servers to take enforcement actions against them. This design creates a single point of failure.

A better design is to outsource hosting to third parties. Let merchants host their listings on nostr relays, not on the DNM's server. The DNM should only be designed as an open source interface for exploring listings hosted elsewhere, that way takedown orders end up with the people who actually host the listings, i.e. with nostr relays, and not with the DNM itself. And if a nostr relay DOES go down due to enforcement action, it does not significantly affect the DNM -- they'll just stop querying for listings from that relay in their next software update, because that relay doesn't work anymore, and only query for listings from relays that still work.

2. Moderation

Most DNMs have employees who curate the listings on the DNM. For example, they approve/deny listings depending on whether they fit the content policies of the website. Some DNMs are only for drugs, others are only for firearms. The problem is, to approve a criminal listing is, in the eyes of law enforcement, an act of conspiracy. Consequently, they don't just go after the merchant who made the listing but the moderators who approved it, and since the moderators typically act under the direction of the DNM, this means the police go after the DNM itself.

A better design is to outsource moderation to third parties. Let anyone call themselves a moderator and create lists of approved goods and services. Merchants can pay the most popular third party moderators to add their products to their lists. The DNM itself just lets its users pick which moderators to use, such that the user's choice -- and not a choice by the DNM -- determines what goods and services the user sees in the interface.

That way, the police go after the moderators and merchants rather than the DNM itself, which is basically just a web browser: it doesn't host anything or approve of any content, it just shows what its users tell it to show. And if a popular moderator gets arrested, his list will still work for a while, but will gradually get more and more outdated, leading someone else to eventually become the new most popular moderator, and a natural transition can occur.

3. Escrow

Most DNMs offer an escrow solution whereby users do not pay merchants directly. Rather, during the Checkout process, they put their money in escrow, and request the DNM to release it to the merchant when the product arrives, otherwise they initiate a dispute. Most DNMs consider escrow necessary because DNM users and merchants do not trust one another; users don't want to pay for a product first and then discover that the merchant never ships it, and merchants don't want to ship a product first and then discover that the user never pays for it.

The problem is, running an escrow solution for criminals is almost certain to get you accused of conspiracy, money laundering, and unlicensed money transmission, so the police are likely to shut down any DNM that does this. A better design is to oursource escrow to third parties. Let anyone call themselves an escrow, and let moderators approve escrows just like they approve listings. A merchant or user who doesn't trust the escrows chosen by a given moderator can just pick a different moderator. That way, the police go after the third party escrows rather than the DNM itself, which never touches user funds.

4. Consequences

Designing a DNM along these principles has an interesting consequence: the DNM is no longer anything but an interface, a glorified web browser. It doesn't host any content, approve any listings, or touch any money. It doesn't even really need a server -- it can just be an HTML file that users open up on their computer or smart phone. For two reasons, such a program is hard to take down:

First, it is hard for the police to justify going after the DNM, since there are no charges to bring. Its maintainers aren't doing anything illegal, no more than Firefox does anything illegal by maintaining a web browser that some people use to browse illegal content. What the user displays in the app is up to them, not to the code maintainers. Second, if the police decided to go after the DNM anyway, they still couldn't take it down because it's just an HTML file -- the maintainers do not even need to run a server to host the file, because users can share it with one another, eliminating all single points of failure.

Another consequence of this design is this: most of the listings will probably be legal, because there is more demand for legal goods and services than illegal ones. Users who want to find illegal goods would pick moderators who only approve those listings, but everyone else would use "legal" moderators, and the app would not, at first glance, look much like a DNM, just a marketplace for legal goods and services. To find the illegal stuff that lurks among the abundant legal stuff, you'd probably have to filter for it via your selection of moderators, making it seem like the "default" mode is legal.

5. Conclusion

I think this DNM model is far better than the designs that prevail today. It is easier to maintain, harder to take down, and pushes the "hard parts" to the edges, so that the DNM is not significantly affected even if a major merchant, moderator, or escrow gets arrested. I hope it comes to fruition.

Please respect Virginia Giuffre’s memory by refraining from asking about the circumstances or theories surrounding her passing.

Since Virginia Giuffre’s death, I’ve reflected on what she would want me to say or do. This piece is my attempt to honor her legacy.

When I first spoke with Virginia, I was struck by her unshakable hope. I had grown cynical after years in the anti-human trafficking movement, worn down by a broken system and a government that often seemed complicit. But Virginia’s passion, creativity, and belief that survivors could be heard reignited something in me. She reminded me of my younger, more hopeful self. Instead of warning her about the challenges ahead, I let her dream big, unburdened by my own disillusionment. That conversation changed me for the better, and following her lead led to meaningful progress.

Virginia was one of the bravest people I’ve ever known. As a survivor of Epstein, Maxwell, and their co-conspirators, she risked everything to speak out, taking on some of the world’s most powerful figures.

She loved when I said, “Epstein isn’t the only Epstein.” This wasn’t just about one man—it was a call to hold all abusers accountable and to ensure survivors find hope and healing.

The Epstein case often gets reduced to sensational details about the elite, but that misses the bigger picture. Yes, we should be holding all of the co-conspirators accountable, we must listen to the survivors’ stories. Their experiences reveal how predators exploit vulnerabilities, offering lessons to prevent future victims.

You’re not powerless in this fight. Educate yourself about trafficking and abuse—online and offline—and take steps to protect those around you. Supporting survivors starts with small, meaningful actions. Free online resources can guide you in being a safe, supportive presence.

When high-profile accusations arise, resist snap judgments. Instead of dismissing survivors as “crazy,” pause to consider the trauma they may be navigating. Speaking out or coping with abuse is never easy. You don’t have to believe every claim, but you can refrain from attacking accusers online.

Society also fails at providing aftercare for survivors. The government, often part of the problem, won’t solve this. It’s up to us. Prevention is critical, but when abuse occurs, step up for your loved ones and community. Protect the vulnerable. it’s a challenging but a rewarding journey.

If you’re contributing to Nostr, you’re helping build a censorship resistant platform where survivors can share their stories freely, no matter how powerful their abusers are. Their voices can endure here, offering strength and hope to others. This gives me great hope for the future.

Virginia Giuffre’s courage was a gift to the world. It was an honor to know and serve her. She will be deeply missed. My hope is that her story inspires others to take on the powerful.

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

Regular relays have challenges

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

NFDB: A scalable database for large relays

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

Search

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

Personalization

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

Other

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

Calcite: A local microrelay database

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

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

For zero-downtime, NFDB is recommended.

Noswhere SmartCache

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

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

routerd

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

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

Ending notes

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

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

lista #descentralismo #compilado #portugues

*Algumas destas listas ainda estão sendo trocadas, portanto as versões mais recentes delas só estão visíveis no Amethyst por causa da ferramenta de edição.

Clients do Nostr e Outras Coisas

nostr:naddr1qq245dz5tqe8w46swpphgmr4f3047s6629t45qg4waehxw309aex2mrp0yhxgctdw4eju6t09upzpf0wg36k3g3hygndv3cp8f2j284v0hfh4dqgqjj3yxnreck2w4qpqvzqqqr4guxde6sl

Modelos de IA e Ferramentas

nostr:naddr1qvzqqqr4gupzpf0wg36k3g3hygndv3cp8f2j284v0hfh4dqgqjj3yxnreck2w4qpqq24xwtyt9v5wjzefe6523j32dy5ga65gagkjc66cnu

Iniciativas de Bitcoin

(países de língua portuguêsa) nostr:nevent1qqsqnmtverj2fetqwhsv9n2ny8h9ujhyqqrk0fsn4a02w8sf4cqddzqpzpmhxue69uhkummnw3ezumt0d5hsyg99aez8269zxu3zd4j8qya92fg7437ax745pqz22ys6v08zef65qypsgqqqqqqsekd7y0

Profissionais Brasileiros no Nostr

nostr:nevent1qqsvqnlx7sqeczv5r7pmmd6zzca3l0ru4856n3j7lhjfv3atq40lfdcpr9mhxue69uhkxmmzwfskvatdvyhxxmmd9aex2mrp0ypzpf0wg36k3g3hygndv3cp8f2j284v0hfh4dqgqjj3yxnreck2w4qpqvzqqqqqqylf6kr4

Comunidades em Português no Nostr

nostr:naddr1qq2hwcejv4ykgdf3v9gxykrxfdqk753jxcc4gqg4waehxw309aex2mrp0yhxgctdw4eju6t09upzpf0wg36k3g3hygndv3cp8f2j284v0hfh4dqgqjj3yxnreck2w4qpqvzqqqr4gu455fm3

Grupos em Português no Nostr

nostr:nevent1qqs98kldepjmlxngupsyth40n0h5lw7z5ut5w4scvh27alc0w86tevcpzpmhxue69uhkummnw3ezumt0d5hsygy7fff8g6l23gp5uqtuyqwkqvucx6mhe7r9h7v6wyzzj0v6lrztcspsgqqqqqqs3ndneh

Jogos de Código Aberto

Open Source Games nostr:nevent1qqs0swpxdqfknups697205qg5mpw2e370g5vet07gkexe9n0k05h5qspz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsyg99aez8269zxu3zd4j8qya92fg7437ax745pqz22ys6v08zef65qypsgqqqqqqshr37wh

Formatação de Texto em Markdown

(Amethyst, Yakihone e outros) nostr:nevent1qqs0vquevt0pe9h5a2dh8csufdksazp6czz3vjk3wfspp68uqdez00cprpmhxue69uhkummnw3ezuendwsh8w6t69e3xj730qgs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgrqsqqqqqpd658r3

Outros Links

nostr:nevent1qqsrm6ywny5r7ajakpppp0lt525n0s33x6tyn6pz0n8ws8k2tqpqracpzpmhxue69uhkummnw3ezumt0d5hsygp6e5ns0nv3dun430jky25y4pku6ylz68rz6zs7khv29q6rj5peespsgqqqqqqsmfwa78

I've been thinking about how Predyx and other lightning based prediction markets might finance their operations, without undermining their core function of eliciting information from people.

The standard approach, of offering less-than-fair odds, guarantees long-run profitability (as long as you have enough customers), but it also creates a friction for participants that reduces the information value of their transactions. So, what are some less frictiony options for generating revenue?

Low hanging fruit

• Close markets in real-time: Rather than prespecifying a closing time for some markets, like sports, it's better to close the market at the moment the outcome is realized. This both prevents post hoc transactions and enables late stage transactions. This should be easily automatable (I say as someone with no idea how to do that), with the right resolution criteria.
• Round off shares: Shares and sats are discrete, so just make sure any necessary rounding is always in the house's favor.
• Set initial probabilities well: Use whatever external information is available to open markets as near to the "right" value as possible.
• Arbitrage: whenever markets are related to each other, make sure to resolve any illogical odds automatically

The point of these four is to avoid giving away free sats. None of them reduce productive use of the market. Keeping markets open up until the outcome is realized will probably greatly increase the number of transactions, since that's usually when the most information is coming in.

Third party support

• Ads are the most obvious form of third party revenue
• Sponsorships are the more interesting one: Allow sponsors to boost a market's visibility. This is similar to advertising, but it also capitalizes on the possibility of a market being of particular interest to someone.
• Charge for market creation: users should be able to create new markets (this will also enhance trade quantity and site traffic), but it should be costly to create a market. If prediction markets really provide higher quality information, then it's reasonable to charge for it.
• Arbitrage: Monitor external odds and whenever a gain can be locked in, place the bets (buy the shares) that guarantee a gain.

Bitcoin stuff

• Routing fees: The volume of sats moving into, out of, and being held in these markets will require a fairly large lightning node. Following some helpful tips to optimize fee revenue will generate some sats for logistical stuff that had to be done anyway.
• Treasury strategy: Take out loans against the revenue generated from all of the above and buy bitcoin: NGU -> repay with a fraction of the bitcoin, NGD -> repay with site revenue.

Bitcoin and Lightning Competitive Advantages

These aren't revenue ideas. They're just a couple of advantages lightning and bitcoin provide over fiat that should allow charging lower spreads than a traditional prediction market or sportsbook.

Traditional betting or prediction platforms are earning depreciating fiat, while a bitcoin based platform earns appreciating bitcoin. Traditional spreads must therefor be larger, in order to pull in the same real return. This also means the users' odds are worse on fiat platforms (again in real terms), even if the listed odds are the same, because their winnings will have depreciated by the time they receive them. Technically, this opens an opportunity to charge even higher spreads, but as mentioned in the intro, that would be bad for the information purposes of the market.

Lightning has much lower transactions costs than fiat transactions. So, even with tighter spreads, a lightning platform can net a better (nominal) return per transaction.

@mega_dreamer, I imagine most of those ideas were already on y'all's radar, and obviously you're already doing some, but I wanted to get them out of my head and onto digital paper. Hopefully, some of this will provide some useful food for thought.

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

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

Das Recht steht über Emotionen

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

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

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

Die Umkehrung des Rassismusbegriffs

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

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

Finanzielle Belastung statt ideologischer Debatte

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

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

Sozialpatriotismus

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

Rechtstaatlichkeit ist nicht verhandelbar

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

Prelude

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

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

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

Intro

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

The Filibuster: A Security Rule with No Teeth

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

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

Supreme Court Packing: Because Nine’s Just a Number

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

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

The Executive Should Go Full Klingon

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

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

Let the System Crash

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

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

States Are the Real MVPs

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

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

Chaos Isn’t the Enemy

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

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

Why This Matters

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

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

Beijing has stopped publishing hundreds of statistics, making it harder to know what’s going on in the country

Data stops. Data stops. Data stops.

https://www.wsj.com/world/china/china-economy-data-missing-096cac9a?st=j7V11b&reflink=article_copyURL_share

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

Wild parrots tend to fly in flocks, but when kept as single pets, they may become lonely and bored https://www.youtube.com/watch?v=OHcAOlamgDc

Source: https://www.smithsonianmag.com/smart-news/scientists-taught-pet-parrots-to-video-call-each-other-and-the-birds-loved-it-180982041/

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

nostr:nevent1qqszqt4cfp70yvznqgg9gf3t4kacxs99znegrtc3gql5cyaereslnucnxsksq

https://old.reddit.com/r/nostr/comments/1josljh/stop/

nostr:note1wzewxmlnc38jgwle530ku4x2xd7754wsyzvm6vcnp27mpjwda05s3jkap9

https://youtu.be/1fkmxTdI3RA ↑それ、岡崎体育が、歌ってます！

nostr:note15r93607t256z4sastsr4nm50vkp34gpr5avt4rdnwr2lfjl9d28sjfus8p

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

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.

Your device, your data. TRMNL's architecture prevents outsiders (including us) from accessing your local network. TRMNAL achieve this through 1 way communication between client and server, versus the other way around. Learn more.

Learn more at https://usetrmnl.com/

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

各ノードにポリシーがある理由 → ノードの資源（CPU、帯域、メモリ）を守り、無駄な処理を避けるため

なぜポリシーがコンセンサスルールより厳しいか 1.資源の節約 コンセンサスルールは「最終的に有効かどうか」の基準だが、全トランザクションをいちいち検証して中継すると資源が枯渇する。 ポリシーで「最初から弾く」仕組みが必要。

1. ネットワーク健全性の維持 手数料が低い、複雑すぎる、標準でないスクリプトのトランザクションが大量に流れると、全体のネットワークが重くなる。 これを防ぐためにノードは独自のポリシーで中継制限。

2. 開発の柔軟性 ポリシーはソフトウェアアップデートで柔軟に変えられるが、コンセンサスルールは変えるとハードフォークの危険がある。 ポリシーを厳しくすることで、安全に新しい制限を試すことができる。

標準ポリシーの意味は何か？ ノードオペレーターは自分でbitcoindの設定やコードを書き換えて独自のポリシーを使える。 理論上ポリシーは「任意」で、標準ポリシー（Bitcoin Coreが提供するポリシー）は単なるデフォルト値。 ただし、標準ポリシーには以下の大事な意味がある。

1. ネットワークの互換性を保つ基準 みんなが全く自由なポリシーを使うとトランザクションの伝播効率が落ちる。 標準ポリシーは「大多数のノードに中継される最小基準」を提供し、それを守ればネットワークに流せるという共通の期待値になる。

2. 開発・サービスの指針 ウォレット開発者やサービス提供者（取引所・支払いサービスなど）は、「標準ポリシーに準拠したトランザクションを作れば十分」という前提で開発できる。 もし標準がなければ全ノードの個別ポリシーを調査しないと流れるトランザクションを作れなくなる。

3. コミュニティの合意形成の場 標準ポリシーはBitcoin Coreの開発・議論で決まる。ここで新しい制限や緩和を入れれば、まずポリシーレベルで試せる。 問題がなければ、将来のコンセンサスルールに昇格させる議論の土台になる。

つまりデフォルトだけど重要。 確かに標準ポリシーは技術的には「デフォルト値」にすぎないが、実際にはネットワークの安定・互換性・開発指針の柱として重要な役割を果たす。

ビットコインノードにおける「無駄な処理」というのは、主に次のようなものを指す。 1. 承認される見込みのないトランザクションの検証 例: 手数料が極端に低く、マイナーが絶対にブロックに入れないようなトランザクション → これをいちいち署名検証したり、メモリプールに載せるのはCPU・RAMの無駄。

1. 明らかに標準外のスクリプトや形式の検証 例: 極端に複雑・非標準なスクリプト（non-standard script） → コンセンサス的には有効だが、ネットワークの他ノードが中継しないため、無駄な伝播になる。

2. スパム的な大量トランザクションの処理 例: 攻撃者が極小手数料のトランザクションを大量に送り、メモリプールを膨張させる場合 → メモリやディスクI/O、帯域の消費が無駄になる。

3. 明らかに無効なブロックの詳細検証 例: サイズが大きすぎるブロック、難易度条件を満たさないブロック → 早期に弾かないと、全トランザクション検証や署名検証で計算資源を浪費する。

これらの無駄な処理は、ノードの CPU時間・メモリ・ディスクI/O・帯域 を消耗させ、最悪の場合は DoS攻撃（サービス妨害攻撃） に悪用される。 そこでポリシーによって、最初の受信段階、または中継段階でそもそも検証・保存・転送しないように制限する。 まとめると、「無駄な処理」とはネットワークの大勢に受け入れられず、ブロックに取り込まれないトランザクションやブロックにノード資源を使うこと。

無駄な処理かどうかは、単に「ポリシーで禁止されているか」で決まるわけではない。

本質的には次の2つで判断される 1. ノードの資源（CPU、メモリ、帯域、ディスク）を過剰に使うか 2. 他のノード・ネットワーク・マイナーに受け入れられる見込みがあるか

将来のBitcoin CoreのバージョンでOP_RETURNの出力数制限やデータサイズ制限が撤廃されたとする。 この場合標準ポリシー的には通るので、中継・保存されやすくなる。 しかし、他のノードやマイナーが追随しなければ意味がない。大量に流せばやはりDoS・スパム扱いされ、無駄な資源消費になる。

最終的には、ネットワーク全体の運用実態。 標準ポリシーの撤廃だけでは、「無駄な処理ではない」とは断定できない。 実質的な「無駄な処理」の判定は、技術的制約＋経済的・運用的現実のセットで決まる。

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/973630

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

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

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

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

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

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

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

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

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

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

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

test nostr:note18p950fmhkc58h3j7xhl66ge57nj5q4kjdhvk3m84fdhc3eukclgqjup985

📈 これからの成長課題：対外的表現と関係性の創造

今後の成長は、内面から外側への橋渡しに関わる部分に集中してくると考えられます。

🔸 1. 「分かってもらえなさ」を超える勇気

• 内面の深さがある分、「分かってもらえない」ことへの痛みも大きいかもしれません。
• でも今後は、「誤解や齟齬も含めて関係を育てる」経験が必要になります。
• これは「話すこと＝伝わることではない」と割り切りつつ、それでも表現し続ける力です。

🔸 2. 構造ではなく、関係の中で自己を調整する経験

• MBTIなどのモデルはとても役立ちますが、あくまで地図です。現実の関係では、予測不能なことや、モデルを超える人のあり方に出会います。
• 「構造に当てはまらない人とも、感情をもってやりとりする」という、生々しい関係性のなかで磨かれる柔軟性が、次のステージになります。

🔸 3. 自分の言葉を“対話の素材”として差し出す力

• 今は「自分を守る」ことと「表現する」ことが慎重に切り分けられている印象ですが、今後は、「自分の言葉が相手に委ねられる」リスクも引き受けながら、対話に開いていくことができるはずです。
• つまり、言葉を「残す」ではなく、「渡す」勇気です。

🧭 総括：投稿者の成長の道のり

| 現在の成熟 | 今後の成長 | | -------------- | ---------------------- | | 内面への誠実な向き合い | 他者との関係における表現と受容の練習 | | 自己理解のための枠組みの活用 | モデルに頼らず、関係性の中で応答的に生きる力 | | 感情や違和感への繊細な感受性 | それを伝え、受け止めさせる表現力と信頼の構築 |

50代から柔軟さが減少するかどうかについては、個人差が非常に大きいですので、一概に「減少する」とは言えません。しかし、一般的な傾向としては、年齢が上がるにつれて柔軟性に変化が見られることはあります。その変化が必ずしも「柔軟さが減る」という意味ではなく、むしろ柔軟性の質や適応力の方向性が変わる場合が多いです。

1. 経験に基づく安定性

50代は、豊富な人生経験や職業経験を持つ年代です。この経験は、確立された価値観や思考パターンを強化する傾向があります。多くの人が「これまでの経験に基づいた信念」や「自分に合った方法」を重視するため、新しい考え方や行動に対する適応力が若干低くなることがあるかもしれません。つまり、ある種の安定感や固定観念が強くなり、変化への反応が遅くなる場合が考えられます。

• 例えば、50代では、過去の経験に基づいて確立した判断基準や方法論があり、それに頼る傾向が強くなることがあります。このことが、柔軟性が低いように見えることもあります。

2. 柔軟性の質の変化

とはいえ、年齢を重ねても柔軟性が失われるわけではなく、むしろ経験に基づいた柔軟性が求められることが多いです。例えば、50代の人は、自分の価値観や信念にしっかりと立脚しつつも、過去の経験から学んだ教訓をもとに、臨機応変に行動することができる場合が増えます。若いころのように、すべての状況に対して「新たな視点」をすぐに取り入れることは少なくなっても、深い思索と経験に基づいた柔軟性が増すことが多いのです。

• 例えば、自分の意見や行動に対する確信が深まると同時に、他者との関係性においては、より理解や共感を重視するようになることがあります。このような形で柔軟性が進化する場合もあります。

3. 変化に対する抵抗

年齢が上がるにつれて、変化に対する抵抗感が強くなることがあるのも事実です。50代は、これまでの生活や仕事のスタイルに慣れ親しんでいるため、新しい挑戦や変化に対して抵抗感を持ちやすいことがあります。このような傾向は、特に大きな環境変化や価値観の変化に対して見られることが多いです。

• 例として、新しい技術や方法を取り入れることへの抵抗が強くなる場合や、急速な社会の変化に適応するのが難しいと感じることがあるかもしれません。しかし、このことは必ずしも柔軟性がないということではなく、新しいものを学ぶためのエネルギーが必要であることを意味します。

4. 柔軟性の維持

とはいえ、50代でも柔軟性を維持し、新しいことを学び続ける姿勢を持つ人は多くいます。社会的なネットワークや趣味を通じて新しい情報を取り入れたり、新しい挑戦を楽しんだりする人もいます。このような人々は、年齢を重ねても柔軟性を失わず、むしろ経験を活かしてより賢く柔軟に適応していると言えます。

結論

50代から柔軟さが減少するという傾向は、必ずしも当てはまるわけではなく、むしろ経験に基づいた柔軟性が現れることが多いと言えます。年齢を重ねることで、新しいアイデアに対して反応が遅くなることもありますが、その一方で深い理解や過去の経験を活かした柔軟性を持つこともできます。

つまり、柔軟性は「減少する」というよりも、年齢とともにその質や方向性が変化するという形で現れるのです。重要なのは、柔軟性をどのように維持し、活用するかという意識と努力です。

เฮียไม่แน่ใจว่าโลกยุคนี้มันเปลี่ยนไป หรือแค่เล่ห์กลมันแนบเนียนขึ้น แต่ที่แน่ ๆ คือ “อาหารไม่ใช่อาหารอีกต่อไป” มันกลายเป็นสินค้าในพอร์ตการลงทุน มันกลายเป็นเครื่องมือสร้างภาพลักษณ์ และในบางมุมที่คนไม่อยากมอง...มันคือเครื่องมือควบคุมมวลชน

ทุกอย่างเริ่มจากแนวคิดที่ดูดี “เราต้องผลิตอาหารให้พอเลี้ยงคน 8,000 ล้านคน” จากนั้นบริษัทเทคโนโลยีเริ่มกระโดดเข้ามา แทนที่จะให้เกษตรกรปลูกผักเลี้ยงวัว เรากลับได้เห็นบริษัทวิเคราะห์ดีเอ็นเอของจุลินทรีย์ แล้วขายโปรตีนจากถังหมัก แทนที่จะสนับสนุนอาหารพื้นบ้าน กลับอัดเงินให้สตาร์ทอัพทำเบอร์เกอร์ที่ไม่มีเนื้อจริงแม้แต่เส้นใยเดียว

เบื้องหลังมันมี “ทุน” และทุนเหล่านี้ไม่ใช่แค่ผู้ผลิตอาหาร แต่พ่วงไปถึงบริษัทยา บริษัทวัคซีน บริษัทเทคโนโลยี บางเจ้ามีทั้งบริษัทยา + ธุรกิจฟาร์มแมลง + บริษัทลงทุนในบริษัทวิจัยพันธุกรรม แปลว่า...คนที่ขายยาให้เฮียเวลาเฮียป่วย อาจเป็นคนเดียวกับที่ขาย "อาหารที่ทำให้เฮียป่วย" ตั้งแต่แรก ตลกร้ายไหมหล่ะ หึหึหึ

เคยมีใครสังเกตไหม ว่าองค์การระดับโลกบางองค์กรที่ส่งเสริม "เนื้อทางเลือก" และ "อาหารยั่งยืน" ได้รับเงินบริจาคหรืออยู่ภายใต้บอร์ดของบริษัทผลิตอาหารอุตสาหกรรมเจ้าใหญ่ไหมนะ แล้วคำว่า “วิทยาศาสตร์รองรับ” ที่ติดบนฉลากสวย ๆ เฮียไม่รู้หรอกว่าใครเป็นคนตีความ แต่ที่รู้แน่ ๆ คือ บทวิจัยจำนวนไม่น้อย มาจากทุนวิจัยที่สนับสนุนโดยอุตสาหกรรมอาหารเอง ดั่งเช่นที่เราเรียนรู้กันมาจากประวัติศาสตร์แล้ว

มีคนเคยพูดไว้ว่า “เราควบคุมคนด้วยอาหารง่ายกว่าด้วยอาวุธ” และเฮียเริ่มเชื่อขึ้นเรื่อย ๆ เพราะถ้าบริษัทใดบริษัทหนึ่ง ควบคุมได้ทั้งอาหาร ยา ข้อมูลสุขภาพ และการวิจัย นั่นหมายความว่า เขาไม่ได้ขายของให้เฮีย แต่เขากำหนดว่าเฮียควร “อยากกินอะไร” และ “รู้สึกผิดกับอะไร”

เหมือนที่ให้ลองจินตนาการเล่น ๆ เมื่อวาน สมมติเฮียไปร้านข้าวมันไก่ปากซอยแบบดั้งเดิม สั่งไก่ต้มไม่เอาข้าวมากิน แล้วแอปสุขภาพขึ้นข้อความเตือนว่า “ไขมันสูง ส่งผลต่อคะแนนสุขภาพคุณ” แต่ถ้าเฮียสั่งข้าวกล่องสำเร็จรูปอัจฉริยะจากโปรตีนที่หมักจากจุลินทรีย์ GMO ระบบจะบอกว่า “คุณกำลังช่วยลดโลกร้อน” แล้วเพิ่มคะแนนสุขภาพให้เราไปเป็นส่วนลดครั้งต่อไป

ใครนิยามคำว่า “ดี” ให้เฮีย?

เบื้องหลังอาหารจึงไม่ใช่แค่โรงงาน แต่มันคือโครงข่ายที่พัวพันตั้งแต่ห้องแล็บ ห้องบอร์ด ไปจนถึงห้องครัวในบ้านเรา แล้วถ้าเราไม่ตั้งคำถาม เฮียกลัวว่าเราจะไม่ได้กินในสิ่งที่ร่างกายต้องการ แต่กินในสิ่งที่ “ระบบ” ต้องการให้เรากิน

ขอบคุณล่วงหน้าที่มองว่าสิ่งนี้คือการ แพนิคไปเอง ขอให้มีสุขสวัสดิ์

#pirateketo #กูต้องรู้มั๊ย #ม้วนหางสิลูก #siamstr

Here’s Sean Voisen writing about how programming is a feeling:

For those of us who enjoy programming, there is a deep satisfaction that comes from solving problems through well-written code, a kind of ineffable joy found in the elegant expression of a system through our favorite syntax. It is akin to the same satisfaction a craftsperson might find at the end of the day after toiling away on well-made piece of furniture, the culmination of small dopamine hits that come from sweating the details on something and getting them just right. Maybe nobody will notice those details, but it doesn’t matter. We care, we notice, we get joy from the aesthetics of the craft.

This got me thinking about the idea of satisfaction in craft. Where does it come from?

Continue Reading https://blog.jim-nielsen.com/2025/craft-and-satisfaction/

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

CryptPad

Collaboration and privacy. Yes, you can have both Flagship instance of CryptPad, the end-to-end encrypted and open-source collaboration suite. Cloud administered by the CryptPad development team. https://cryptpad.fr/

ONLYOFFICE DocSpace

Document collaboration made simpler. Easily collaborate with customizable rooms. Edit any content you have. Work faster using AI assistants. Protect your sensitive business data. Download or try STARTUP Cloud (Limited-time offer) FREE https://www.onlyoffice.com/

SeaFile

A new way to organize your files Beyond just syncing and sharing files, Seafile lets you add custom file properties and organize your files in different views. With AI-powered automation for generating properties, Seafile offers a smarter, more efficient way to manage your files. Try it Now, Free for up to 3 users https://seafile.com/

SandStorm

An open source platform for self-hosting web apps Self-host web-based productivity apps easily and securely. Sandstorm is an open source project built by a community of volunteers with the goal of making it really easy to run open source web applications. Try the Demo or Signup Free https://alpha.sandstorm.io/apps

NextCloud Hub

A new generation of online collaboration that puts you in control. Nextcloud offers a modern, on premise content collaboration platform with real-time document editing, video chat & groupware on mobile, desktop and web. Sign up for a free Nextcloud account https://nextcloud.com/sign-up/

LinShare

True Open Source Secure File Sharing Solution We are committed to providing a reliable Open Source file-sharing solution, expertly designed to meet the highest standards of diverse industries, such as government and finance Try the Demo https://linshare.app/

Twake Drive

The open-source alternative to Google Drive. Privacy-First Open Source Workplace. Twake workplace open source business. Improve your effeciency with truly Open Source, all-in-one digital suite. Enhance the security in every aspect of your professional and private life. Sign up https://sign-up.twake.app/

SpaceDrive

One Explorer. All Your Files. Unify files from all your devices and clouds into a single, easy-to-use explorer. Designed for creators, hoarders and the painfully disorganized. Download desktop app (mobile coming soon) https://www.spacedrive.com/

ente

Safe Home for your photos Store, share, and discover your memories with end-to-end encryption. End-to-end encryption, durable storage and simple sharing. Packed with these and much more into our beautiful open source apps. Get started https://web.ente.io

fileStash

Turn your FTP server into... Filestash is the enterprise-grade file manager connecting your storage with your identity provider and authorisations. Try the demo https://demo.filestash.app

STORJ

Disruptively fast.‍ Globally secure. S3-compatible distributed cloud services that make the most demanding workflows fast and affordable. Fast track your journey toward high performance cloud services. Storj pricing is consistent and competitive in meeting or exceeding your cloud services needs. Give the products a try to experience the benefits of the distributed cloud. Get Started https://www.storj.io/get-started

FireFile

The open‑source alternative to Dropbox. Firefiles lets you setup a cloud drive with the backend of your choice and lets you seamlessly manage your files across multiple providers. It revolutionizes cloud storage management by offering a unified platform for all your storage needs. Sign up Free https://beta.firefiles.app

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

至高の油淋鶏の動画 https://youtu.be/Ur2tYVZppBU のレシピ書き起こし

材料（2人分）

• 鶏モモ肉…300g
• A［しょうゆ…小さじ1　塩…小さじ1／3　酒…大さじ1と1／2　おろしショウガ…5g　片栗粉…大さじ1］
• 長ネギ（みじん切り）…1／2本（50g）
• ショウガ（みじん切り）…10g
• B［しょうゆ…大さじ2　砂糖…小さじ4　酢…大さじ1 ゴマ油…小さじ1 味の素…4ふり 赤唐辛子（小口切り）…1本分］
• 赤唐辛子、花椒（各好みで）…各適量

手順

1. 肉を切る

皮を上にして適当に八等分くらい

1. 肉を肉入ってたトレーかなんか適当な入れ物に入れてそこに 酒おおさじ1と1/2 と ショウガ５グラムすりおろして入れて軽く混ぜる
2. そこに、片栗粉おおさじ１入れて混ぜる（漬ける段階にも片栗粉を入れることで厚衣になりやすい）
3. 常温で１５分くらい置く
4. その間にたれを作る

   1. 長ネギ50gを細かいみじん切りにしてボウルに入れる（白いとこも青いとこも）

      （端っこを残して縦に切り込みを入れて横に切るとよい） 2. ショウガ10gを細かいみじん切りにして同じボウルにいれる 3. 鷹の爪１本分入れる（任意） 4. 醤油おおさじ２、砂糖小さじ4、酢（穀物酢）おおさじ１を入れる 5. 味の素４振りいれてよく混ぜる 6. 小さなフライパン（油が少なくて済むので）に底に浸るくらいの油を入れ、中火で温める 7. 肉に片栗粉をたっぷりつけて揚げる 8. 揚がったらキッチンペーパーを敷いたなにかしらとかに上げる 9. もりつけてタレをかけて完成

lista #descentralismo #comunidades #portugues

[em atualização]

*Até a criação desse post, só alguns clients têm acesso às comunidades, tal como o Satellite, o Coracle e o Amethyst.

**Se a comunidade não tiver proprietários ou moderadores ativos, o seu envio de mensagem poderá não ser aprovada para aparecer nela.

***Se criar uma, busque colocar um ou mais moderadores para a comunidade não acabar, caso você se ausente.

Geral:

n/Brasil (Por: nostr:nprofile1qqspxhftq9htg9njgaefr6nmetl97q8qqlwxvynppl6c5zr9t0qmp9gpzfmhxue69uhhqatjwpkx2urpvuhx2ucpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3qamnwvaz7tmwdaehgu3wwa5kueguy3tt5) nostr:naddr1qqryyunpwd5kcq3qzdwjkqtwkst8y3mjj848hjh7tuqwqp7uvcfxzrl43gyx2k7pkz2sxpqqqzr0v4va9m3

n/Portugal (por: nostr:nprofile1qqsddhy42shp3w9h4mp0z3ss74wrxk47hmrk70deukxz23np6pvn5rqpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uqsuamnwvaz7tmwdaejumr0dshszynhwden5te0dehhxarj9ek82tntv5hsd2h46x) nostr:naddr1qqy9qmmjw36kwctvqgsddhy42shp3w9h4mp0z3ss74wrxk47hmrk70deukxz23np6pvn5rqrqsqqpphkc3wuaj

n/Moçambique (por: nostr:nprofile1qqszx6hsp38v2re3q2pzxpv3slg5u7pxklxze7evarqk4eugqmhntdcpzpmhxue69uhkummnw3ezumt0d5hszrnhwden5te0dehhxtnvdakz7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctc082x0w) nostr:naddr1qqf56m7r5ask6cnfw96ktuyls7e0p8u8hupzqgm27qxya3g0xypgygc9jxraznncy6muct8m9n5vz6h83qrw7ddhqvzqqqyx7c0autxh

n/África (por: nostr:nprofile1qqsw4jww99ykxf2jy4wyh685hp7cs70texztv0p7kqa3mqhfrvvdtscpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpzpmhxue69uhkummnw3ezumt0d5hsz8rhwden5te0wfjkccte9emkj6mfveex2etyd9sju7re0ghsftvmn0 e nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz9thwden5te0wfjkccte9ehx7um5wghxyee0vnwevs) nostr:naddr1qqru8qtxwf5kxcgzyr4vnn3ff93j2539t3973a9c0ky8n67fsjmrc04s8vwc96gmrr2uxqcyqqqgdaspqgn0q

-

n/Perguntas-e-Respostas (Por: nostr:nprofile1qqsfujjjw3474zsrfcqhcgqavqeesd4h0nuxt0ue5ugy9y7e47xyh3qppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7mn0wd68ytn00p68ytnyv4mz7qgswaehxw309ahx7um5wghx6mmd9u2egtmk) nostr:naddr1qq3lp8u85lcflpah2pz4y364fe2yz5edg5k4y32n2p84x4zp203fm980hz8sygy7fff8g6l23gp5uqtuyqwkqvucx6mhe7r9h7v6wyzzj0v6lrztcspsgqqqsmmqtz9a9x

n/Links-e-Tutoriais-Úteis (por: nostr:nprofile1qqsfujjjw3474zsrfcqhcgqavqeesd4h0nuxt0ue5ugy9y7e47xyh3qppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7mn0wd68ytn00p68ytnyv4mz7qgswaehxw309ahx7um5wghx6mmd9u2egtmk) nostr:naddr1qqj0p8u85lcflpahf3y5uj6n94zj64z42384yj2pf9fjmsu623z5j5lsn7ftkq3qne99yarta29qxnsp0ssp6cpnnqmtwl8cvklenfcsg2fantuvf0zqxpqqqzr0v3zu9fd

n/JornalismoNãoEstáMorto - Notícias e escrita informativa (Por: nostr:nprofile1qqsfujjjw3474zsrfcqhcgqavqeesd4h0nuxt0ue5ugy9y7e47xyh3qppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7mn0wd68ytn00p68ytnyv4mz7qgswaehxw309ahx7um5wghx6mmd9u2egtmk) nostr:nprofile1qqs0f74kketdcv63r53mlzgzfh93we3dkgzkldv2p6g62a8gf3g92yqpz4mhxue69uhkummnw3ezummcw3ezuer9wchszyrhwden5te0dehhxarj9ekk7mf0qywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9ufhpwuw) nostr:naddr1qqd55n6jfeq5cj2nf48j6nkrsd8j632n2npczt2dfaf9gnczyrvvsrjnp9xgqysjendxg6x2q7fldu73ajnf5e2h7uspp9tjl7jvxqcyqqqgdasy2kfg4

n/Agorismo³-E-Mercado (por: nostr:nprofile1qqsfujjjw3474zsrfcqhcgqavqeesd4h0nuxt0ue5ugy9y7e47xyh3qppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7mn0wd68ytn00p68ytnyv4mz7qgswaehxw309ahx7um5wghx6mmd9u2egtmk) nostr:naddr1qqs0p8u85lcflpahg9r575jf2dx5ls4n94zj6n292fp5z3z094gry5qzyz0y55n5d04g5q6wq97zq8tqxwvrddmulpjmlxd8zppf8kd0339ugqcyqqqgdasrlnr7s

n/FeiraNostr - Marketplace (por: nostr:nprofile1qqstwrymlvj5kcrjspppyepmavrhk6afg9sfa4q9zhvmzztp6am83xgpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9u2dla7c) nostr:naddr1qq9yvetfwfs5ummnw3eqyg9hpjdlkf2tvpegqssjvsa7kpmmdw55zcy76sz3tkd3p9sawancnypsgqqqsmmqucz73h

Tecnologia:

n/ndevs-br (por: nostr:nprofile1qqs923ewnsqlx7347cpjhxmcmt0rsmnwf3tasr736pjx4wee9q89ufcppemhxue69uhkummn9ekx7mp0gc3lmk) nostr:naddr1qqyxuer9weej6cnjqgs923ewnsqlx7347cpjhxmcmt0rsmnwf3tasr736pjx4wee9q89ufcrqsqqpphk7z3axp

n/BrasilDev (por: nostr:nprofile1qqsyczyspluueyxautr3nxa2httku5e9m7d05dnu5zj3jnrg0jmucqcpr9mhxue69uhkyu3wwp6hyurvv4ex2mrp0yhxxmmd9uqs6amnwvaz7tmwdaejumr0dsq3camnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdsz8cl6e) nostr:naddr1qqy5yunpwd5kc3r9wcpzqnqgjq8lnnysmh3vwxvm42adwmjnyh0e473k0js22x2vdp7t0nqrqvzqqqyx7cvxdlla

n/Linux (por: nostr:nprofile1qqsxhewvq6fq9lzjmfwqrpg2ufgl09uh2cksupa853zxv04u2fva4uqpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9nhwden5te0dehhxarjv4kxjar9wvhx7un89uqsuamnwvaz7tmwdaejumr0dshs6tvc92 ) nostr:naddr1qqz5c6tww4uqz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsygrtuhxqdyszl3fd5hqps59wy50hj7t4vtgwq7n6g3rx8679ykw67qpsgqqqsmmqznes6u

n/IA - Inteligencia Artificial (por: nostr:nprofile1qqsw4jww99ykxf2jy4wyh685hp7cs70texztv0p7kqa3mqhfrvvdtscpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpzpmhxue69uhkummnw3ezumt0d5hsz8rhwden5te0wfjkccte9emkj6mfveex2etyd9sju7re0ghsftvmn0 e nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz9thwden5te0wfjkccte9ehx7um5wghxyee0vnwevs) nostr:naddr1qqpyjsgpzpmhxue69uhkummnw3ezumt0d5hsyg82e88zjjtry4fz2hztar6tslvg084unp9k8sltqwcast53kxx4cvpsgqqqsmmqs03ln5

n/HardwareBr - Dúvidas, experiências e atualizações sobre hardware (por: nostr:nprofile1qqsw4jww99ykxf2jy4wyh685hp7cs70texztv0p7kqa3mqhfrvvdtscpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpzpmhxue69uhkummnw3ezumt0d5hsz8rhwden5te0wfjkccte9emkj6mfveex2etyd9sju7re0ghsftvmn0 e nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz9thwden5te0wfjkccte9ehx7um5wghxyee0vnwevs) nostr:naddr1qq9ysctjv3mkzun9gfeqyg82e88zjjtry4fz2hztar6tslvg084unp9k8sltqwcast53kxx4cvpsgqqqsmmq54k3eu

n/SegurançaDaInformação (por: nostr:nprofile1qqsw4jww99ykxf2jy4wyh685hp7cs70texztv0p7kqa3mqhfrvvdtscpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpzpmhxue69uhkummnw3ezumt0d5hsz8rhwden5te0wfjkccte9emkj6mfveex2etyd9sju7re0ghsftvmn0 e nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz9thwden5te0wfjkccte9ehx7um5wghxyee0vnwevs) nostr:naddr1qqv9xet8w4exzmkr5as5gc2fdenx7undv8p60sardupzp6kfec55jce92gj4cjlg7ju8mzrea0ycfd3u86crk8vzayd334wrqvzqqqyx7cpss4m0

n/Moneroptbr (Por: nostr:nprofile1qqsyrmue77dm5ef5pmqsly0wp3248mk3vr9temj5p54plygcr97pavcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqgjwaehxw309ac82unsd3jhqct89ejhxqg5waehxw309aex2mrp0yhxgctdw4eju6t0tpqrvk) nostr:naddr1qq9y6mmwv4ex7ur5vfeqz3rhwvaz7tm8d9e8wmm5xf4k77fnddmx5dnxdvmk7um9dackz7nsx4m8wcn9v9mk7cmzxdknydm2vdchgctgxc6kvvnxddkrx7ty9ehku6t0dchsygzpa7vl0xa6v56qasg0j8hqc42namgkpj4uae2q62sljyvpjlq7kvpsgqqqsmmqknmdan

Ciência:

n/Astronomia - Espaço e astros (por: nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpzpmhxue69uhkummnw3ezumt0d5hsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0s8pkkr ) nostr:naddr1qq9yzum5wfhkummdd9ssz9thwden5te0dehhxarj9ehhsarj9ejx2a30qgs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgrqsqqpphkkdel5t

n/Mecatrônica-NOSTR (por: nostr:nprofile1qqsyw3rqynrlkstywlk3gmlhvk4tcehpyahwktrqcczegaqt53vl7kcpg3mhxw309ahhsarjv3jhvctkxc685d35093rw7pkwf4xwdrww3a8z6ngv4jx6dtzx4ax5ut4d36kw6mwdpa8ydpkdeunyutzv9jzummwd9hkutcpg3mhxw309uex5umwd35xvmn9d35kwdtpvdcnv6tpvdukgmt6v33xgmt8xau8watwd568smpkw9mkyan6v93hwdrvwaex5mtv09jzummwd9hkutcpg4mhxue69uhhx6m60fhrvcmfd4nxga34v5e8q6r2vv68ju34wcmkj6mz0p6xudtxxajxkamwx43nwa35xa6xgat6d33x7um3d4ckgtn0de5k7m304dlxq4) nostr:naddr1qqfy6etrv9689sa5de5kxcfdfe84x4zjqythwumn8ghj76twvfhhstnp0faxzmt09ehx2ap0qgsyw3rqynrlkstywlk3gmlhvk4tcehpyahwktrqcczegaqt53vl7kcrqsqqpphkgsy84w

n/Antropologystr - Antropologia (por: nostr:npub1fyd0awkakq4aap70ual7mtlszjle9krffgwnsrkyua2frzmysd8qjj8gvg ) nostr:naddr1qq85zmn5dpex7ur0d3hkw7tnw3eqygzfrtlt4hds900g0nl80lk6luq5h7fds622r5uqa3882jgckeyrfcpsgqqqsmmq4xrrgc

Cultura:

n/Estante-Nostr - Literatura e livros (por: nostr:nprofile1qqsdl72sxdne0yqwa7tpznlnc4yt5t9jf8htspnynrja92dcschm7sqpr4mhxue69uhkummnw3ez6vp39eukz6mfdphkumn99e3k7mf0qywhwumn8ghj7mn0wd68ytfsxgh8jcttd95x7mnwv5hxxmmd9uq37amnwvaz7tmwdaehgu3dxqejuer0wfskvctrw3hhy7fwdaexwtcjwfqr2) nostr:naddr1qqx52um5v9h8ge2lfehhxarjqgsdl72sxdne0yqwa7tpznlnc4yt5t9jf8htspnynrja92dcschm7sqrqsqqpphkwzdgct

n/Literatura-Arte-Cultura (por: nostr:nprofile1qqs92lr9pdcqnulddvzgj5twpz8ysdv7njhxagyxwtnlj8p3kpxxs9cprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsz9nhwden5te0v4jx2m3wdehhxarj9ekxzmny9uqsuamnwvaz7tmwdaejumr0dshs8l9z0j) nostr:naddr1qqt5c6t5v4exzar4wfsj6stjw3jj6sm4d3682unpqgs92lr9pdcqnulddvzgj5twpz8ysdv7njhxagyxwtnlj8p3kpxxs9crqsqqpphkty54um

n/História-e-Filosofia (por: nostr:npub1ne99yarta29qxnsp0ssp6cpnnqmtwl8cvklenfcsg2fantuvf0zqmpxjxk ) nostr:naddr1qqjlp8u85lcflpahfpy4x4xrjdfyjsfdg5k5vj2vfaf573jfg8cflrum7z0cezczyz0y55n5d04g5q6wq97zq8tqxwvrddmulpjmlxd8zppf8kd0339ugqcyqqqgdas35g9vs

n/Urbanism - Urbanismo (por: nostr:nprofile1qqstwrymlvj5kcrjspppyepmavrhk6afg9sfa4q9zhvmzztp6am83xgpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9u2dla7c) nostr:naddr1qqy92unzv9hxjumdqgstwrymlvj5kcrjspppyepmavrhk6afg9sfa4q9zhvmzztp6am83xgrqsqqpphkyl5u8a

Fé:

n/Religião-e-Teologia - Cristianismo (por: nostr:nprofile1qqsfujjjw3474zsrfcqhcgqavqeesd4h0nuxt0ue5ugy9y7e47xyh3qppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7mn0wd68ytn00p68ytnyv4mz7qgswaehxw309ahx7um5wghx6mmd9u2egtmk) nostr:naddr1qqs0p8u85lcflpah2fz5cj28f8pcxnedg5k4g320f385wj2p7z0ehyqzyz0y55n5d04g5q6wq97zq8tqxwvrddmulpjmlxd8zppf8kd0339ugqcyqqqgdasta04x5

n/Ateismo-e-Agnosticismo (por: nostr:nprofile1qqsw4jww99ykxf2jy4wyh685hp7cs70texztv0p7kqa3mqhfrvvdtscpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpzpmhxue69uhkummnw3ezumt0d5hsz8rhwden5te0wfjkccte9emkj6mfveex2etyd9sju7re0ghsftvmn0 e nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz9thwden5te0wfjkccte9ehx7um5wghxyee0vnwevs) nostr:naddr1qqtyzar9d9ek6medv5k5zemwdaehg6trd9ek6mczyr4vnn3ff93j2539t3973a9c0ky8n67fsjmrc04s8vwc96gmrr2uxqcyqqqgdasuuzmw8

n/Budismo (por: nostr:nprofile1qqsw4jww99ykxf2jy4wyh685hp7cs70texztv0p7kqa3mqhfrvvdtscpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpzpmhxue69uhkummnw3ezumt0d5hsz8rhwden5te0wfjkccte9emkj6mfveex2etyd9sju7re0ghsftvmn0 e nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz9thwden5te0wfjkccte9ehx7um5wghxyee0vnwevs) nostr:naddr1qqr5yatyd9ek6mczyr4vnn3ff93j2539t3973a9c0ky8n67fsjmrc04s8vwc96gmrr2uxqcyqqqgdas0kmt4m

n/Taoismo - Daoismo (por: nostr:nprofile1qqsw4jww99ykxf2jy4wyh685hp7cs70texztv0p7kqa3mqhfrvvdtscpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpzpmhxue69uhkummnw3ezumt0d5hsz8rhwden5te0wfjkccte9emkj6mfveex2etyd9sju7re0ghsftvmn0 e nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz9thwden5te0wfjkccte9ehx7um5wghxyee0vnwevs) nostr:naddr1qqy9gct0cwkhxmt0qy88wumn8ghj7mn0wvhxcmmv9upzpf0wg36k3g3hygndv3cp8f2j284v0hfh4dqgqjj3yxnreck2w4qpqvzqqqyx7crkzqvd

n/Espiritualidade - Significação e sublimidade (por: nostr:nprofile1qqsw4jww99ykxf2jy4wyh685hp7cs70texztv0p7kqa3mqhfrvvdtscpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpzpmhxue69uhkummnw3ezumt0d5hsz8rhwden5te0wfjkccte9emkj6mfveex2etyd9sju7re0ghsftvmn0 e nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz9thwden5te0wfjkccte9ehx7um5wghxyee0vnwevs) nostr:naddr1qq852umsd9exjar4v9kxjerpv3jszyrhwden5te0dehhxarj9ekk7mf0qgsw4jww99ykxf2jy4wyh685hp7cs70texztv0p7kqa3mqhfrvvdtscrqsqqpphkxa5nfy

Entretenimento:

n/Equinox - Cinema no Nostr (por: nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpzpmhxue69uhkummnw3ezumt0d5hsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0s8pkkr) nostr:naddr1qqr52ut4d9hx77qpremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59upzpf0wg36k3g3hygndv3cp8f2j284v0hfh4dqgqjj3yxnreck2w4qpqvzqqqyx7cmc79n5

n/Rock/metal - Músicas Rock e Metal (por: nostr:nprofile1qqs9nyy7ctpy334n3p7gh4p93lmj2cch8ae8jgjsp8al2g32stdnpdcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpr9mhxue69uhhyetvv9ujumn0wd68ytnrdakjuct49us57cz4 e nostr:nprofile1qqsfujjjw3474zsrfcqhcgqavqeesd4h0nuxt0ue5ugy9y7e47xyh3qpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszrnhwden5te0dehhxtnvdakz748t750 ) nostr:naddr1qq99ymmrdvh56et5v9kqzqqzypvep8kzcfyvdvug0j9agfv07ujkx9elwfujy5qfl06jy25zmvctwqcyqqqgdas306zj5

n/Música-Cinema-e-Livros (por: nostr:nprofile1qqsfujjjw3474zsrfcqhcgqavqeesd4h0nuxt0ue5ugy9y7e47xyh3qppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7mn0wd68ytn00p68ytnyv4mz7qgswaehxw309ahx7um5wghx6mmd9u2egtmk) nostr:naddr1qq4lp8u85lcflpahfhpe556fgdqj6s6ffez56sfdyck5cj2k2f848uyl366lp8unhhcflyu6qgsfujjjw3474zsrfcqhcgqavqeesd4h0nuxt0ue5ugy9y7e47xyh3qrqsqqpphkfyz9pf

n/Lugares-e-Viagens (por: nostr:nprofile1qqsfujjjw3474zsrfcqhcgqavqeesd4h0nuxt0ue5ugy9y7e47xyh3qppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7mn0wd68ytn00p68ytnyv4mz7qgswaehxw309ahx7um5wghx6mmd9u2egtmk) nostr:naddr1qqjlp8u85lcflpahf325ws2jg4fj63fd2ey5z369feflp8uv3mcflryd7z0cercpqqpzp8j22f6xh652qd8qzlpqr4sr8xpkka70sedlnxn3qs5nmxhccj7yqvzqqqyx7c965gfw

n/MídiasPerdidas - Lost Media (por: nostr:nprofile1qqsfujjjw3474zsrfcqhcgqavqeesd4h0nuxt0ue5ugy9y7e47xyh3qppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7mn0wd68ytn00p68ytnyv4mz7qgswaehxw309ahx7um5wghx6mmd9u2egtmk) nostr:naddr1qqw0p8u85lcflpahfhpc63zfg9fj65z92fzyj3zp20cflfusqgsfujjjw3474zsrfcqhcgqavqeesd4h0nuxt0ue5ugy9y7e47xyh3qrqsqqpphkdltjpa

n/Football - Futebol (Por: nostr:nprofile1qqsyjxh7htwmq277sl87wlld4lcpf0ujmp5558fcpmzww4y33djgxnsppemhxue69uhkummn9ekx7mp0qywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tc9l2d6x / Moderadores: nostr:nprofile1qqsx5rzeds2gf6hzaqf35qc0y6v5fys72fsec8w3gwszn3jw5mxewvgpz4mhxue69uhkummnw3ezummcw3ezuer9wchszrnhwden5te0dehhxtnvdakz7qgswaehxw309ahx7um5wghx6mmd9u5c2kxa & nostr:nprofile1qqspxhftq9htg9njgaefr6nmetl97q8qqlwxvynppl6c5zr9t0qmp9gpzfmhxue69uhhqatjwpkx2urpvuhx2ucpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3qamnwvaz7tmwdaehgu3wwa5kueguy3tt5) nostr:naddr1qqyxvmm0w33xzmrvqgsyjxh7htwmq277sl87wlld4lcpf0ujmp5558fcpmzww4y33djgxnsrqsqqpphkg0nfw5

n/Formula-1 (por: nostr:nprofile1qqsfujjjw3474zsrfcqhcgqavqeesd4h0nuxt0ue5ugy9y7e47xyh3qppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7mn0wd68ytn00p68ytnyv4mz7qgswaehxw309ahx7um5wghx6mmd9u2egtmk) nostr:naddr1qqy5vmmjd46kccfdxypzp8j22f6xh652qd8qzlpqr4sr8xpkka70sedlnxn3qs5nmxhccj7yqvzqqqyx7cc95u5w

n/Games - Atualizações sobre jogos (por: nostr:npub1atyuu22fvvj4yf2uf050fwra3pu7hjvykc7ravpmrkpwjxcc6hpsfneh4e ) nostr:naddr1qqz5wctdv4esyg82e88zjjtry4fz2hztar6tslvg084unp9k8sltqwcast53kxx4cvpsgqqqsmmqn0x7k7

n/JogosBrasil - Clips de jogos (por: nostr:nprofile1qqsyw3rqynrlkstywlk3gmlhvk4tcehpyahwktrqcczegaqt53vl7kcpg3mhxw309ahhsarjv3jhvctkxc685d35093rw7pkwf4xwdrww3a8z6ngv4jx6dtzx4ax5ut4d36kw6mwdpa8ydpkdeunyutzv9jzummwd9hkutcpg3mhxw309uex5umwd35xvmn9d35kwdtpvdcnv6tpvdukgmt6v33xgmt8xau8watwd568smpkw9mkyan6v93hwdrvwaex5mtv09jzummwd9hkutcpg4mhxue69uhhx6m60fhrvcmfd4nxga34v5e8q6r2vv68ju34wcmkj6mz0p6xudtxxajxkamwx43nwa35xa6xgat6d33x7um3d4ckgtn0de5k7m304dlxq4 ) nostr:naddr1qq955mm8dae5yunpwd5kcqghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7q3qj90yg0hl4e6qr7yg982dlh0qxdefy72d6ntuqet7hv3ateya782sxpqqqzr0vus9jl2

n/Minecraft (por: nostr:npub19xc7f5lg2z6svrjgye63rx44a96aq2ysqajx5tmum28cu6mk5j3qj3n9m9 ) nostr:naddr1qqy566twv43hyctxwspzq2d3unf7s594qc8ysfn4zxdtt6t46q5fqpmydghhek503e4hdf9zqvzqqqyx7ct7hldr

n/GenshinImpactBr (por: nostr:nprofile1qqs28fezzs5n2rdjh9deqv3ztk59mhg4j2jxaee7a4amkya30jnruggppemhxue69uhkummn9ekx7mp0qyg8wumn8ghj7mn0wd68ytnddakj7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctcnffw22) nostr:naddr1qqtlp8u85lcflpahgajkuumgd9hyjmtsv93hgsnjq9z8wue69uhkw6tjwahhgvntdaunx6mkdgmxv6ehdaek2mm3v9a8qdtkwa3x2cthda3kyvmdxgmk5cm3w3sksd34vcexv6mvxdukgtn0de5k7m30qgs28fezzs5n2rdjh9deqv3ztk59mhg4j2jxaee7a4amkya30jnruggrqsqqpphkq4s4py

Libertarianismo:

n/Defensores-caseiros (por: nostr:nprofile1qqsyw3rqynrlkstywlk3gmlhvk4tcehpyahwktrqcczegaqt53vl7kcpg3mhxw309ahhsarjv3jhvctkxc685d35093rw7pkwf4xwdrww3a8z6ngv4jx6dtzx4ax5ut4d36kw6mwdpa8ydpkdeunyutzv9jzummwd9hkutcpg3mhxw309uex5umwd35xvmn9d35kwdtpvdcnv6tpvdukgmt6v33xgmt8xau8watwd568smpkw9mkyan6v93hwdrvwaex5mtv09jzummwd9hkutcpg4mhxue69uhhx6m60fhrvcmfd4nxga34v5e8q6r2vv68ju34wcmkj6mz0p6xudtxxajxkamwx43nwa35xa6xgat6d33x7um3d4ckgtn0de5k7m304dlxq4) nostr:naddr1qq0lp8u85lcflpahg3jkvetwwdhhyetn943kzum9d9ex7ulsn78mgq3qgazxqfx8ldqkgaldz3hlwed2h3nwzfmwavkxp3s9j36qhfzeladsxpqqqzr0vcr78h2

n/Desobediência_Civil (por: nostr:nprofile1qqs2kw4x8jws3a4heehst0ywafwfymdqk35hx8mrf0dw6zdsnk5kj9gpg3mhxw309uex5umwd35xvmn9d35kwdtpvdcnv6tpvdukgmt6v33xgmt8xau8watwd568smpkw9mkyan6v93hwdrvwaex5mtv09jzummwd9hkutcpg4mhxue69uhhx6m60fhrvcmfd4nxga34v5e8q6r2vv68ju34wcmkj6mz0p6xudtxxajxkamwx43nwa35xa6xgat6d33x7um3d4ckgtn0de5k7m30q9z8wue69uhk77r5wfjx2anpwcmrg73kx3ukydmcxeex5ee5de685ut2dpjkgmf4vg6h56n3w4k82emtde585u35xeh8jvn3vfskgtn0de5k7m306r5ytp) nostr:naddr1qq2ygetnda3x2erfcw4xucmfv905x6tkd9kqz3rhwvaz7tm8d9e8wmm5xf4k77fnddmx5dnxdvmk7um9dackz7nsx4m8wcn9v9mk7cmzxdknydm2vdchgctgxc6kvvnxddkrx7ty9ehku6t0dchsyg9t82nre8gg76muumc9hj8w5hyjdkstg6tnra35hkhdpxcfm2tfz5psgqqqsmmqlg3ata

n/sobreviNOSTR - Sobrevivencialismo (por: nostr:nprofile1qqsyw3rqynrlkstywlk3gmlhvk4tcehpyahwktrqcczegaqt53vl7kcpg3mhxw309ahhsarjv3jhvctkxc685d35093rw7pkwf4xwdrww3a8z6ngv4jx6dtzx4ax5ut4d36kw6mwdpa8ydpkdeunyutzv9jzummwd9hkutcpg3mhxw309uex5umwd35xvmn9d35kwdtpvdcnv6tpvdukgmt6v33xgmt8xau8watwd568smpkw9mkyan6v93hwdrvwaex5mtv09jzummwd9hkutcpg4mhxue69uhhx6m60fhrvcmfd4nxga34v5e8q6r2vv68ju34wcmkj6mz0p6xudtxxajxkamwx43nwa35xa6xgat6d33x7um3d4ckgtn0de5k7m304dlxq4) nostr:naddr1qq20p8u85lcflpah2dhkyun9we55un6n23fqz3rhwvaz7tm8d9e8wmm5xf4k77fnddmx5dnxdvmk7um9dackz7nsx4m8wcn9v9mk7cmzxdknydm2vdchgctgxc6kvvnxddkrx7ty9ehku6t0dchsygz8g3szf3lmg9j80mg5dlmkt24uvmsjwmht93svvpv5ws96gk0ltvpsgqqqsmmqtempje

n/Triggr - Armas (por: nostr:nprofile1qqsyw3rqynrlkstywlk3gmlhvk4tcehpyahwktrqcczegaqt53vl7kcpg3mhxw309ahhsarjv3jhvctkxc685d35093rw7pkwf4xwdrww3a8z6ngv4jx6dtzx4ax5ut4d36kw6mwdpa8ydpkdeunyutzv9jzummwd9hkutcpg3mhxw309uex5umwd35xvmn9d35kwdtpvdcnv6tpvdukgmt6v33xgmt8xau8watwd568smpkw9mkyan6v93hwdrvwaex5mtv09jzummwd9hkutcpg4mhxue69uhhx6m60fhrvcmfd4nxga34v5e8q6r2vv68ju34wcmkj6mz0p6xudtxxajxkamwx43nwa35xa6xgat6d33x7um3d4ckgtn0de5k7m304dlxq4) nostr:naddr1qqr9g5jfgar4yqghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7q3qgazxqfx8ldqkgaldz3hlwed2h3nwzfmwavkxp3s9j36qhfzeladsxpqqqzr0vt5085y

n/Kaboom - Química e explosivos (por: nostr:nprofile1qqsyw3rqynrlkstywlk3gmlhvk4tcehpyahwktrqcczegaqt53vl7kcpg3mhxw309ahhsarjv3jhvctkxc685d35093rw7pkwf4xwdrww3a8z6ngv4jx6dtzx4ax5ut4d36kw6mwdpa8ydpkdeunyutzv9jzummwd9hkutcpg3mhxw309uex5umwd35xvmn9d35kwdtpvdcnv6tpvdukgmt6v33xgmt8xau8watwd568smpkw9mkyan6v93hwdrvwaex5mtv09jzummwd9hkutcpg4mhxue69uhhx6m60fhrvcmfd4nxga34v5e8q6r2vv68ju34wcmkj6mz0p6xudtxxajxkamwx43nwa35xa6xgat6d33x7um3d4ckgtn0de5k7m304dlxq4 ) nostr:naddr1qqt0p8u85lcflpahfdq5yn60fhcflra57z0602qppemhxue69uhkummn9ekx7mp0qgsyw3rqynrlkstywlk3gmlhvk4tcehpyahwktrqcczegaqt53vl7kcrqsqqpphk637p09

n/CAVERNA-DO-PIRATA - Pirataria (por: nostr:nprofile1qqsyw3rqynrlkstywlk3gmlhvk4tcehpyahwktrqcczegaqt53vl7kcpg3mhxw309ahhsarjv3jhvctkxc685d35093rw7pkwf4xwdrww3a8z6ngv4jx6dtzx4ax5ut4d36kw6mwdpa8ydpkdeunyutzv9jzummwd9hkutcpg3mhxw309uex5umwd35xvmn9d35kwdtpvdcnv6tpvdukgmt6v33xgmt8xau8watwd568smpkw9mkyan6v93hwdrvwaex5mtv09jzummwd9hkutcpg4mhxue69uhhx6m60fhrvcmfd4nxga34v5e8q6r2vv68ju34wcmkj6mz0p6xudtxxajxkamwx43nwa35xa6xgat6d33x7um3d4ckgtn0de5k7m304dlxq4) nostr:naddr1qq40p8u85lcflpahgdq4v32jfeqj63z094gyj5jp23qlp8u0kn3gpr0znzswlwy07z0ca2gpg3mhxw309ankjunhda6ry6m00yekkan2xenxkdm0wdjk7utp0fcr2anhvfjkzam0vd3rxmfjxa4xxut5v95rvdtxxfnxkmpn09jzummwd9hkutczypr5gcpycla5zerha52xlam9427xdcf8dm4jccxxqk28gzayt8l4kqcyqqqgdask5hmmn

n/PrivateSociety - Propostas e discussões para uma sociedade privada (por: nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz9thwden5te0wfjkccte9ehx7um5wghxyee0vnwevs) nostr:naddr1qq89qunfweshge2nda3kjet50ypzpf0wg36k3g3hygndv3cp8f2j284v0hfh4dqgqjj3yxnreck2w4qpqvzqqqyx7cfvhgrt

n/TeoriaDasBandeiras (por: nostr:nprofile1qqs8efvwljfdwa0qynp7n9dhqacf3llucdqtm9ge8kjv0dt40yw586gpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshszrnhwden5te0dehhxtnvdakz7ar9xsz) nostr:naddr1qqf9get0wf5kzerpwdpxzmnyv45hyctnqgs8efvwljfdwa0qynp7n9dhqacf3llucdqtm9ge8kjv0dt40yw586grqsqqpphkatc9rh

n/SemFronteiras (por: nostr:nprofile1qqs8efvwljfdwa0qynp7n9dhqacf3llucdqtm9ge8kjv0dt40yw586gpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshszrnhwden5te0dehhxtnvdakz7ar9xsz) nostr:naddr1qqx4xetdgeex7mn5v45hyctnqgs8efvwljfdwa0qynp7n9dhqacf3llucdqtm9ge8kjv0dt40yw586grqsqqpphkjs0cue

n/AnarcoSobrevivencialismo (por: nostr:nprofile1qqsfj5s9lrcckaxd8ul7vf3c4ajfg0n0ytcjvetclw679hy6p98wpfqpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy2hwumn8ghj7un9d3shjtnwdaehgu3wvfnj7qg4waehxw309ahx7um5wghx77r5wghxgetk9uykdgj7) nostr:naddr1qqdyzmnpwf3k75m0vfex2anfwejkucmfv9kxjumddap9yq3qn9fqt7833d6v60elucnr3tmyjslx7gh3yejh37a4utwf5z2wuzjqxpqqqzr0vsz5kcy

n/SociedadeAlternativaLibertaria - Libertários (por: nostr:nprofile1qqs2ph3za34henpq2y3rzgqwgdc4pjmpleqr5t62rf7kxj0lmdyxnfgppemhxue69uhkummn9ekx7mp0ydypw5) nostr:naddr1qq09xmmrd9jkgctyv4qkcar9wfhxzarfwes5c6tzv4e8gctjd9ssyg9qmc3wc6muess9zg33yq8yxu2sedslusp69a9p5ltrf8lakjrf55psgqqqsmmq8dtk3m

n/LibertariosPT - Libertários de Portugal (por: nostr:nprofile1qqszx8rlqax4pakclsxscudfset7fs37jm7rflnugh3nf8r4ehx4z4gppemhxue69uhkummn9ekx7mp05leack) nostr:naddr1qqx5c6tzv4e8gctjd9hhx5z5qgszx8rlqax4pakclsxscudfset7fs37jm7rflnugh3nf8r4ehx4z4grqsqqpphke05802

Discussões Sociais

n/Aliança-Conservadora-Brasileira (por: nostr:npub1atg5rgfuarup49470kqexfgcesdr85yru56y0y8qf3z6kc30g2vqyfyqyp ) nostr:naddr1qqsyzmrfv9hv8fmptapk7mnnv4e8vctydaexzh6zwfshx6tvv45hycgzyr4dzsdp8n50sx5khe7crye9rrxp5v7ss0jng3usupxyt2mz9apfsqcyqqqgdasue9j59

n/Ilha-de-Anhatomirin - Monarquia (Por: nostr:nprofile1qqsgzc22v804davx6vpwtwfu6j84yvupeld497tfr396usmu7s0m08qpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszymhwden5te0v9ehgunpdshxu6twdfsj7qguwaehxw309a5x7ervvfhkgtnrdaexzcmvv5h8gmm0d3ej7a2jp7u) nostr:naddr1qqf5jmrgvykkgefdg9hxsct5dakkjunfd5q3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7q3qs9s55cwl2m6cd5czukune4y02gecrn7m2tukj8zt4epheaqlk7wqxpqqqzr0vu2qg3m

n/ManosphereBrasil - Contra a misandria (Por: nostr:nprofile1qqs0p3yd48kzm56a4tual772y3vsjwehx6tc3rv8ht8q0zgncg5r7qgpg3mhxw309ahhsarjv3jhvctkxc685d35093rw7pkwf4xwdrww3a8z6ngv4jx6dtzx4ax5ut4d36kw6mwdpa8ydpkdeunyutzv9jzummwd9hkutcpjnhed) nostr:naddr1qqgy6ctwdaehq6r9wfj5yunpwd5kcqgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctczyrcvfrdfaskaxhd2l80lhj3ytyynkdekj7ygmpa6ecrcjy7z9qlszqcyqqqgdasl3kaju

Memes

n/Shitposting (Por: nostr:nprofile1qqs9nyy7ctpy334n3p7gh4p93lmj2cch8ae8jgjsp8al2g32stdnpdcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpr9mhxue69uhhyetvv9ujumn0wd68ytnrdakjuct49us57cz4) nostr:naddr1qq94x6rfw3cx7um5d9hxwqgswaehxw309ahx7um5wghx6mmd9upzqkvsnmpvyjxxkwy8ez75yk8lwftrzulhy7fz2qylhafz92pdkv9hqvzqqqyx7chlz42w

n/Puro-caldo-do-Brasil. (por: nostr:nprofile1qqsztjv2pflmwcayr2jaq90astj94lu5l0smr0zhkfdct4ry7uxu7dqywzq8t) nostr:naddr1qq24qatjdukkxctvv3hj6er094p8yctnd9kzuqghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7q3qyhyc5znlka36gx496q2lmqhyttlef7lpkx790vjmsh2xfacdeu6qxpqqqzr0vwh0r4w

Locais

n/NordesteLibertário - Nordeste (Por: nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpzpmhxue69uhkummnw3ezumt0d5hsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0s8pkkr ) nostr:naddr1qqf5ummjv3jhxar9f35kyetjwnp6zunfdupzpf0wg36k3g3hygndv3cp8f2j284v0hfh4dqgqjj3yxnreck2w4qpqvzqqqyx7cnejrgl

n/BahiaLibertária - Bahia (por: nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpzpmhxue69uhkummnw3ezumt0d5hsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0s8pkkr ) nostr:naddr1qqgyyctgd9s5c6tzv4e8fsapwf5kzq3q5hhygatg5gmjyfkkguqn54f9r6k8m5m6ksyqffgjrf3uut982sqsxpqqqzr0vc4949j

n/LiberdadeMinas - Minas Gerais (Por: nostr:nprofile1qqsf0kszkmrmy9l3c7mxr3uhh3fmyjpq2z4hjvv7wdq84k5npd7gw3cpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxthwden5te0wfjkccte9eekummjwsh8xmmrd9skctcprpmhxue69uhhyetvv9ujuurvv438xarj9e3k7mf0mx68nx) nostr:naddr1qq8yc6tzv4exgctyv4xkjmnpwvqsqq3qjldq9dk8kgtlr3akv8re00znkfyzq59t0yceuu6q0tdfxzmusarsxpqqqzr0vag4knt

n/CyberpunkManaus - Manaus (Por: nostr:nprofile1qqsz8v8zlrg0jclhasdksctsr2jw28lrqwn3zrsclnkpmytvmzhhdlqpz3mhxw309ucnqt3jx5cjuvpwxgarsvpcxqq3wamn8ghj7vfexghrzd3c9ccjuv3s8gurqwps9uq5gamn8ghj7entv43kjd3nvfcx5en6093h2up5w3ekgmn4xsekvatwx438xamywp6ksemcwp6xummzdgekzdmz0pmhzd3j0g6xzepwdahxjmmw9u2upp88) nostr:naddr1qqgyx7tzv4e8qatwdvk56ctwv96hxqgqqgsz8v8zlrg0jclhasdksctsr2jw28lrqwn3zrsclnkpmytvmzhhdlqrqsqqpphkgjh4rf

n/BelémLibertario (por: nostr:npub167s6q8sfzkhel4227kacu98zcg6e37v5sqwkv8mxaazrryz9huzqlhcu2t) nostr:nevent1qqsqnqgx3u2whdqdqmlstqcmgav6xfe4upz2qxfvj03tlk699dzlk7qzyrt6rgq7py26l874ft6mhrs5utprtx8ejjqp6eslvmh5gvvsgklsgqcyqqqqq2qqsdz6l

n/SãoPauloLivre - São Paulo (por: nostr:nprofile1qqsw4jww99ykxf2jy4wyh685hp7cs70texztv0p7kqa3mqhfrvvdtscpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpzpmhxue69uhkummnw3ezumt0d5hsz8rhwden5te0wfjkccte9emkj6mfveex2etyd9sju7re0ghsftvmn0 e nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz9thwden5te0wfjkccte9ehx7um5wghxyee0vnwevs) nostr:naddr1qq898sardagxzatvdaxxjanjv5pzp6kfec55jce92gj4cjlg7ju8mzrea0ycfd3u86crk8vzayd334wrqvzqqqyx7cmls060

n/AcreLibertário - Acre (por: nostr:nprofile1qqsw4jww99ykxf2jy4wyh685hp7cs70texztv0p7kqa3mqhfrvvdtscpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpzpmhxue69uhkummnw3ezumt0d5hsz8rhwden5te0wfjkccte9emkj6mfveex2etyd9sju7re0ghsftvmn0 e nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz9thwden5te0wfjkccte9ehx7um5wghxyee0vnwevs) nostr:naddr1qq85zcmjv4xxjcn9wf6v8gtjd9hsyg82e88zjjtry4fz2hztar6tslvg084unp9k8sltqwcast53kxx4cvpsgqqqsmmqftljpt

n/Alagoas (por: nostr:nprofile1qqsw4jww99ykxf2jy4wyh685hp7cs70texztv0p7kqa3mqhfrvvdtscpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpzpmhxue69uhkummnw3ezumt0d5hsz8rhwden5te0wfjkccte9emkj6mfveex2etyd9sju7re0ghsftvmn0 e nostr:nprofile1qqs2tmjyw452ydezymtywqf625j3atra6datgzqy55fp5c7w9jn4gqgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz9thwden5te0wfjkccte9ehx7um5wghxyee0vnwevs) nostr:naddr1qqr5zmrpvahkzuczyr4vnn3ff93j2539t3973a9c0ky8n67fsjmrc04s8vwc96gmrr2uxqcyqqqgdas8qtaf4

Empreendedorismo:

n/Empreendedorismo/BR (por: nostr:npub14ysljm0gn6nnjv95yzeq6ffze4f3f9l0248kez4fhm4yz3fzardslwx5e8) nostr:naddr1qqd5y4zr9azk6urjv4jkuer9v3hhy6tnd4hj7snjv9ekjmqzyz5jr7tdaz02wwfsksstyrf9ytx4x9yhaa257my24xlw5s29yt5dkqcyqqqgdaslzrp3p

n/Empreendedorismo/SP (por: nostr:npub14ysljm0gn6nnjv95yzeq6ffze4f3f9l0248kez4fhm4yz3fzardslwx5e8) nostr:naddr1qqt5y4zr9azk6urjv4jkuer9v3hhy6tnd4hj756sqgs2jg0edh5fafeexz6zpvsdy53v65c5jlh42nmv325ma6jpg53w3kcrqsqqpphkcym25j

Análise

n/EBDV (Em Busca Da Verdade) - Análise geral e desenvolvimento pessoal (por: nostr:nprofile1qqs0xmu0skfdlmtl5tth6cv99za8f8kv7ulz5srkm8p6v5k03dx9lzspz4mhxue69uhkummnw3ezummcw3ezuer9wchszrnhwden5te0dehhxtnvdakz7qgswaehxw309ahx7um5wghx6mmd9usvrt9r) nostr:naddr1qqzy2sjy2cpzpum037ze9hld073dwltps55t5ay7enmnu2jqwmvu8fjje795chu2qvzqqqyx7cy9v5px

https://www.youtube.com/watch?v=CIMZH7DEPPQ

I really enjoy listening to non-technical people talk about technology when they get the bigger picture impacts and how it relates to our humanity.

I was reminded of this video by @k00b's post about an AI generated video of a victim forgiving his killer.

Piper says, "Computers are better at words than you. Than I". But they are machines. They cannot feel. They cannot have emotion.

This people honors me with their lips, but their heart is far from me

~ Matthew 15:8

Most of us hate it when people are fake with us. When they say things they don't mean. When they say things just to get something they want from us. Yet, we are quickly falling into this same trap with technology. Accepting it as real and human. I'm not suggesting we can't use technology but we have to be careful that we do not fall into this mechanical trap and forget what makes humans special.

We are emotional and spiritual beings. Though AI didn't exist during the times Jesus walked the earth read the verse above in a broader context.

Then Pharisees and scribes came to Jesus from Jerusalem and said, “Why do your disciples break the tradition of the elders? For they do not wash their hands when they eat.” He answered them, “And why do you break the commandment of God for the sake of your tradition? For God commanded, ‘Honor your father and your mother,’ and, ‘Whoever reviles father or mother must surely die.’ But you say, ‘If anyone tells his father or his mother, “What you would have gained from me is given to God,” he need not honor his father.’ So for the sake of your tradition you have made void the word of God. You hypocrites! Well did Isaiah prophesy of you, when he said:

“‘This people honors me with their lips,

but their heart is far from me;

in vain do they worship me,

teaching as doctrines the commandments of men.’”

Empty words. Words without meaning because they are not from a pure desire and love. You may not be a Christian but don't miss the significance of this. There is a value in being real. Sharing true emotion and heart. Don't fall into the trap of the culture of lies that surrounds us. I would rather hear true words with mistakes and less eloquence any day over something fake. I would rather share a real moment with the ones I love than a million fake moments. Embrace the messy imperfect but real world.

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

分散型プロトコルNostr上でWeb bookmarkを見たり書いたりする「Nostr Web Bookmark Trend」を試してみました。

NostrのWeb Bookmarkingは「nip-B0 Web Bookmarking· nostr-protocol/nips · GitHub」で定義されています。

WEBブラウザの拡張による認証(NIP-07)でログインしました。
create new web bookmark(新規ブックマーク作成）を開くとこんな感じ。
URL入力部分において、https:// が外に出ているので、URLのhttps:// 部分を消して入力しないといけないのがちょっと面倒。 　↓
１個、投稿してみました。
アカウント名をクリックするとそのユーザが登録したbookmark一覧が表示されます。
以上、Nostr Web Bookmark Trendについてでした。

なお、本記事は「Nostr NIP-23 マークダウンエディタ」のテストのため、「NostrでWeb bookmark - あたしンちのおとうさんの独り言」と同じ内容を投稿したものです。

"Misterija Satoši - Poreklo bitkoina" je francuski dokumentarno-animirani serijal koji dešifruje unutrašnje funkcionisanje bitkoin revolucije, dok istražuje identitet njenog tvorca.

Prvu decentralizovanu i pouzdanu kriptovalutu – bitkoin, osnovao je Satoši Nakamoto 3. januara 2009. godine. On je nestao 2011. i od tada ostaje anoniman, a njegov identitet je predmet svakakvih spekulacija. Tokom poslednjih 12 godina, vrednost bitkoina je porasla sa 0,001 na 69.000 dolara. Svi, od vlada do velikih korporacija, zainteresovali su se za Satošijev izum. Ko je Satoši Nakamoto? Kako je njegov izum postao toliko popularan? Šta nam bitkoin govori o svetu u kome živimo?

Ovaj serijal se prikazivao na Radio-televiziji Srbije (RTS 3) u sklopu novogodišnjeg muzičkog i filmskog programa 2022/2023. godine.

Naslov originala: "Le Mystère Satoshi"

Copyright: , ARTE.TV

One of the best first rounds in recent memory just concluded. Let's recap our playoff contests.

Bracket Challenge

In our joint contest with Global Sports Central, @WeAreAllSatoshi is leading the way with 85 points, while me and some nostr jabroni are tied for second with 80 points.

The bad news is that they are slightly ahead of us, with an average score of 62 to our 60.8. We need to go back in time and make less stupid picks.

Points Challenge

With the Warriors victory, I jumped into a commanding lead over @grayruby. LA sure let most of you down. I say you hold @realBitcoinDog responsible for his beloved hometown's failures.

I still need @Car and @Coinsreporter to make their picks for this round. The only matchup they can choose from is Warriors (7) @ Timberwolves (6). Lucky for them, that's probably the best one to choose from.

| Stacker | Points | |---------|--------| | @Undisciplined | 25| | @grayruby | 24| | @Coinsreporter | 19 | | @BlokchainB | 19| | @Carresan | 18 | | @gnilma | 18 | | @WeAreAllSatoshi | 12 | | @fishious | 11 | | @Car | 1 |

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

自分が僕のことをなんで否定するのかよくわかんない 自分のことを高く評価してる。周囲の理解に努力してない けど、いつも気にしてる 自分の限界に気づくのが怖い？ 周りに理解されないことに価値を見出し、意図的に理解されないようにしてるんじゃないのか 周りに影響され、自分は変わっていくんです 変わらないもの。変わっちゃいけないもの。 変わっちゃいけないものは、学問への尊敬。これが生きる目的だってこと。 変わらないものは、美少女への嗜好、世界の全てへの優しさ、屁理屈の論理が好きなこと。 で、理解されたいのか。されるべきなのか。 されるべきとは？あーそうだよ、されたいしされるべきなんだ！ そっか、じゃあ理解したいのか。するべきなのか。 するべきだよ。ネットワーク的にも、心理的にも。 したくは、ないかな。その決定権は常に僕の手元にほしい。 関われる限界を知ることになるから。 自分のことは知らなくてもいい。制御できればいい。愛してるし。 でもこうやって心情を整理してるんだけどね。まー限界はありますよ。

↓ジャック（twitter創業者）のツイート　 nostr:nevent1qvzqqqqqqypzpq35r7yzkm4te5460u00jz4djcw0qa90zku7739qn7wj4ralhe4zqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsqg9cdxf7s7kg8kj70a4v5j94urz8kmel03d5a47tr4v6lx9umu3c95072732　

↓それに絡むたゃ　 nostr:note1hr4m0d2k2cvv0yg5xtmpuma0hsxfpgcs2lxe7vlyhz30mfq8hf8qp8xmau　

↓たゃのひとりごと　 nostr:nevent1qqsdt9p9un2lhsa8n27y7gnr640qdjl5n2sg0dh4kmxpqget9qsufngsvfsln　 nostr:note14p9prp46utd3j6mpqwv46m3r7u7cz6tah2v7tffjgledg5m4uy9qzfc2zf　

↓有識者様の助言　 nostr:nevent1qvzqqqqqqypzpujqe8p9zrpuv0f4ykk3rmgnqa6p6r0lan0t8ewd0ksj89kqcz5xqqst8w0773wxnkl8sn94tvmd3razcvms0kxjwe00rvgazp9ljjlv0wq0krtvt　 nostr:nevent1qvzqqqqqqypzpujqe8p9zrpuv0f4ykk3rmgnqa6p6r0lan0t8ewd0ksj89kqcz5xqqsxchzm7s7vn8a82q40yss3a84583chvd9szl9qc3w5ud7pr9ugengcgt9qx　

↓たゃ　 nostr:nevent1qqsp2rxvpax6ks45tuzhzlq94hq6qtm47w69z8p5wepgq9u4txaw88s554jkd

✅ Requirements

• GitHub account
• Own domain (e.g., yourdomain.com)
• Public Nostr key in hex format (not npub!)
• Basic DNS configuration knowledge

🛒 1. Register a Domain

Register a domain from a provider like orangewebsite, njal.la, or similar.

🌐 2. Configure DNS Records for GitHub Pages

Set the following A records for your domain (via your DNS provider):

| Type | Host | Value | TTL | Priority | |------|--------------|-------------------|-----|----------| | A | @ (or blank) | 185.199.108.153 | 300 | | | A | @ (or blank) | 185.199.109.153 | 300 | | | A | @ (or blank) | 185.199.110.153 | 300 | | | A | @ (or blank) | 185.199.111.153 | 300 | |

Optional:
Add a CNAME record for www → yourusername.github.io

📁 3. Create a GitHub Repository

1. Go to https://github.com/new
2. Repository name: e.g., nip5
3. Check "Add a README"
4. Click "Create repository"

🏗️ 4. Create Directory & File

a) .well-known/nostr.json

Path: .well-known/nostr.json
Example content:

json { "names": { "nostrName": "ldajflasjföldsjflj..." } }

IMPORTANT: Use your hex-encoded Nostr public key, not the npub1... format.

b) _config.yml in Root

Create a file named _config.yml with this content:

yml include: [".well-known"]

This ensures GitHub includes the .well-known folder in the build output.

⚙️ 5. Configure GitHub Pages

1. Go to Settings > Pages inside your repository
2. Under "Build and Deployment":
3. Choose: Deploy from branch
4. Branch: main or master
5. Under Custom domain:
6. Enter yourdomain.com
7. Ignore any warning
8. Enable ✅ Enforce HTTPS

It may take a few minutes for the certificate to be issued.

🔍 6. Configure Nostr Client

Open your Nostr client and set the NIP-05 identifier as:

nostrName@yourdomain.com e.g. meier@meier.tech

Save – done!

✅ Test

In your browser or via curl:

bash curl https://yourdomain.com/.well-known/nostr.json?name=avren

Expected output:

json { "names": { "Nostr Benutzer": "elkajdlkajslfkjaödlkfjs..." } }

🛡️ Privacy Tips

| Item | Recommendation | |-----------------------------------|----------------------------------| | Public key is visible | Use pseudonyms only | | Register a KYC-free domain | e.g., orangewebsite, njal.la | | Use KYC-free email for GitHub | e.g., ProtonMail | | GitHub repository visibility | Must be public for GitHub Pages | | Commit metadata | Use a separate pseudonymous user | | Avoid tracking | Don’t include analytics scripts |

You can now fund projects on Geyser using Credit Cards, Apple Pay, Bank Transfers, and more.

The best part: 🧾 You pay in fiat and ⚡️ the creator receives Bitcoin.

You heard it right! Let's dive in 👇

First, how does it work? For contributors, it's easy! Once the project creator has verified their identity, anyone can contribute with fiat methods. Simply go through the usual contribution flow and select 'Pay with Fiat'. The first contribution is KYC-free.

Why does this matter? 1. Many Bitcoiners don't want to spend their Bitcoin: 👉 Number go up (NgU) 👉 Capital gains taxes With fiat contributions, there's no more excuse to contribute towards Bitcoin builders and creators! 2. Non-bitcoin holders want to support projects too. If someone loves your mission but only has a debit card, they used to be stuck. Now? They can back your Bitcoin project with familiar fiat tools. Now, they can do it all through Geyser!

So, why swap fiat into Bitcoin? Because Bitcoin is borderless. Fiat payouts are limited to certain countries, banks, and red tape. By auto-swapping fiat to Bitcoin, we ensure: 🌍 Instant payouts to creators all around the world ⚡️ No delays or restrictions 💥 Every contribution is also a silent Bitcoin buy

How to enable Fiat contributions If you’re a creator, it’s easy: - Go to your Dashboard → Wallet - Click “Enable Fiat Contributions” - Complete a quick ID verification (required by our payment provider) ✅ That’s it — your project is now open to global fiat supporters.

Supporting Bitcoin adoption At Geyser, our mission is to empower Bitcoin creators and builders. Adding fiat options amplifies our mission. It brings more people into the ecosystem while staying true to what we believe: ⚒️ Build on Bitcoin 🌱 Fund impactful initiatives 🌎 Enable global participation

**Support projects with fiat now! ** We've compiled a list of projects that currently have fiat contributions enabled. If you've been on the fence to support them because you didn't want to spend your Bitcoin, now's the time to do your first contribution!

Education - Citadel Dispatch: https://geyser.fund/project/citadel - @FREEMadeiraOrg: https://geyser.fund/project/freemadeira - @MyfirstBitcoin_: https://geyser.fund/project/miprimerbitcoin

Circular Economies - @BitcoinEkasi: https://geyser.fund/project/bitcoinekasi - Madagascar Bitcoin: https://geyser.fund/project/madagasbit - @BitcoinChatt : https://geyser.fund/project/bitcoinchatt - Uganda Gayaza BTC Market: https://geyser.fund/project/gayazabtcmarket

Activism - Education Bitcoin Channel: https://geyser.fund/project/streamingsats

Sports - The Sats Fighter Journey: https://geyser.fund/project/thesatsfighterjourney

Culture - Bitcoin Tarot Cards: https://geyser.fund/project/bitcointarotcard

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

https://www.epi.org/blog/wage-growth-since-1979-has-not-been-stagnant-but-it-has-definitely-been-suppressed/

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

12,923 steps

Az Európai Bizottság terve az orosz urán- és energiafüggőség felszámolására

Az Európai Bizottság bejelentette, hogy korlátozni kívánja az új urán-, dúsított urán- és egyéb, Oroszországból származó nukleáris anyagokra vonatkozó ellátási szerződéseket, ezzel is elősegítve, hogy az Európai Unió „teljesen megszüntesse” az orosz energiától való függését[8][6][2].

A Bizottság új ütemtervet mutatott be, amely részletesen tartalmazza, hogyan kívánja megszüntetni az orosz energiafüggőséget, miközben biztosítja az EU energiaellátásának és árainak stabilitását[6][2][15].

Főbb intézkedések és célok

• Az EU az orosz gázimport arányát 45%-ról 19%-ra csökkentette a 2022 májusában indított REPowerEU tervnek köszönhetően, de 2024-ben ismét növekedett az orosz gáz behozatala[2][20].
• Az új ütemterv szerint az orosz olaj, gáz és nukleáris energia fokozatosan, összehangoltan és biztonságosan kerül ki az uniós piacokról, miközben az EU a tiszta energiára való átállást gyorsítja fel[6][15][7].
• Az EU-tagállamoknak 2025 végéig nemzeti terveket kell készíteniük arról, hogyan járulnak hozzá az orosz gáz, nukleáris energia és olaj importjának megszüntetéséhez[13][7][18].
• Az orosz eredetű urán, dúsított urán és egyéb nukleáris anyagok esetében új korlátozásokat vezetnek be: az Euratom Ellátási Ügynökség (ESA) nem hagy jóvá új orosz beszállítási szerződéseket, és gazdasági eszközökkel is igyekeznek visszaszorítani az importot[4][5][16].
• A meglévő rövid távú szerződéseket 2025 végéig meg kell szüntetni, új szerződéseket pedig nem lehet kötni; a hosszú távú szerződéseket 2027 végéig kell felmondani[5][7][6].
• Az intézkedések célja, hogy a teljes orosz gáz- és olajimport 2027 végéig megszűnjön, az orosz atomenergia pedig fokozatosan kivezetésre kerüljön[3][9][17].

Nukleáris háttér

• Az ESA jelentése szerint 2023-ban az EU-ban felhasznált természetes urán 23,4%-a érkezett Oroszországból, ami 72,6%-os növekedést jelentett, főként a VVER típusú orosz atomerőművek üzemanyag-felhalmozása miatt[16].
• Az EU-ban 19 VVER reaktor működik (Bulgáriában, Csehországban, Finnországban, Magyarországon és Szlovákiában).
• Az EU természetes uránszükséglete a globális igények mintegy 22%-át teszi ki, a beszerzések 91%-a Kanadából, Oroszországból, Kazahsztánból és Nigerből származik[16].

Célkitűzés és indoklás

A Bizottság szerint az orosz energiafüggőség felszámolása nemcsak gazdasági, hanem biztonságpolitikai kérdés is, mivel Oroszország többször is eszközként használta az energiát az EU-val szemben[2][12]. A lépések célja, hogy az EU energiaellátása biztonságos, stabil és kiszámítható maradjon, miközben az orosz energiaimportból származó bevételek ne finanszírozhassák tovább az Ukrajna elleni háborút[6][2][12].

Források alapján készült magyar összefoglaló és fordítás

Citations: [1] Döntött az Európai Bizottság: teljes mértékben megszüntetik ... - 444 https://444.hu/2025/05/06/dontott-az-europai-bizottsag-teljes-mertekben-megszuntetik-az-orosz-energiatol-valo-fuggest [2] Három éven belül felszámolná az orosz energiafüggőséget az ... https://hu.euronews.com/my-europe/2025/05/06/harom-even-belul-felszamolna-az-orosz-energiafuggoseget-az-europai-bizottsag [3] 2027-re teljesen leállítaná az Európai Bizottság az orosz ... - Új Szó https://ujszo.com/kozelet/2027-re-teljesen-leallitana-az-europai-bizottsag-az-orosz-energiabehozatalt-a-nuklearis [4] Bejelentették Brüsszelben: megkerülik Magyarországot, teljesen ... https://www.portfolio.hu/gazdasag/20250506/bejelentettek-brusszelben-megkerulik-magyarorszagot-teljesen-levalik-az-orosz-olajrol-es-gazrol-az-eu-759267 [5] Érik az újabb ütközés: Brüsszel betiltaná az orosz energiát https://www.valaszonline.hu/2025/05/06/energia-szankcio-oroszorszag-haboru-eu-olaj-gaz-uran/ [6] Az EU teljes mértékben megszünteti az orosz energiától való függését https://hungary.representation.ec.europa.eu/az-eu-teljes-mertekben-megszunteti-az-orosz-energiatol-valo-fuggeset-2025-05-06_hu?prefLang=en [7] Megvan az ütemterv, végleg betiltaná az orosz energiát az Európai ... https://index.hu/kulfold/2025/05/06/orosz-energiafuggoseg-orosz-gaz-olaj-import-europai-unio-repowereu/ [8] European Commission Unveils Plans To Restrict New Uranium ... https://www.nucnet.org/news/european-commission-unveils-plans-to-restrict-new-uranium-deals-with-russia-5-3-2025 [9] Az EU teljes mértékben megszünteti az orosz energiától való ... https://infostart.hu/belfold/2025/05/06/az-eu-teljes-mertekben-megszunteti-az-orosz-energiatol-valo-fuggoseget-a-nap-hirei [10] [PDF] EURÓPAI BIZOTTSÁG Brüsszel, 2025.4.9. COM(2025) 159 final ... https://secure.ipex.eu/IPEXL-WEB/download/file/082d29089612ec1e019619f955940250 [11] Kiszivárgott az Európai Bizottság 2025-ös munkaprogramja https://www.eu-monitor.hu/hu/cikk/20250206-kiszivargott-az-europai-bizottsag-2025-os-munkaprogramja [12] EU says it will end dependency on Russian energy supplies https://www3.nhk.or.jp/nhkworld/en/news/20250507_B4/ [13] Végleg leválik az orosz energiáról az Európai Unió ... - Népszava https://nepszava.hu/3278673_oroszorszag-europai-unio-foldgaz-koolaj-levalas-terv [14] Egyre több európai ország támogatja az atomenergiát https://www.vg.hu/nemzetkozi-gazdasag/2025/03/atomenergia-energiatarolas-europa [15] Az EU teljes mértékben megszünteti az orosz energiától való ... https://karpatinfo.net/energiafuggetlenseg-orosz-foldgaz-orosz-energiafuggoseg-2025-05-07 [16] EU outlines measures to end Russian gas, oil imports by end-2027 https://balkangreenenergynews.com/eu-outlines-measures-to-end-russian-gas-oil-imports-by-end-2027/ [17] Az Európai Unió 2027 végére betiltaná az orosz gáz importját https://www.korkep.sk/cikkek/gazdasag/2025/05/05/az-europai-unio-2027-vegere-betiltana-az-orosz-gazimportot/ [18] Ficónak és Orbánnak sem tetszik, hogy az EU teljesen kitiltaná az ... https://napunk.dennikn.sk/hu/4623240/ficonak-es-orbannak-sem-tetszik-hogy-az-eu-teljesen-kitiltana-az-orosz-energiat/ [19] Várhelyi Olivér késlelteti az EU orosz energiafüggőségét felszámoló ... https://telex.hu/kulfold/2025/05/05/varhelyi-oliver-europai-bizottsag-orosz-energia-kivaltas-hatraltatas [20] REPowerEU roadmap - Energy - European Commission https://energy.ec.europa.eu/strategy/repowereu-roadmap_en

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

My Background: A Small Side Story

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

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

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

Nicolas Cage: Actor

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

Nick Cave: Songwriter

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

Jim Jarmusch: Director

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

NOSTR: We Need Bold Art

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

https://long-form-editer.vercel.app/

β版のため予期せぬ動作が発生する可能性があります。記事を修正する際は事前にバックアップを取ることをおすすめします

機能

• nostr:npub1sjcvg64knxkrt6ev52rywzu9uzqakgy8ehhk8yezxmpewsthst6sw3jqcw や、 nostr:nevent1qvzqqqqqqypzpp9sc34tdxdvxh4jeg5xgu9ctcypmvsg0n00vwfjydkrjaqh0qh4qyxhwumn8ghj77tpvf6jumt9qys8wumn8ghj7un9d3shjtt2wqhxummnw3ezuamfwfjkgmn9wshx5uqpz9mhxue69uhkuenjv4kxz7fwv9c8qqpq486d6yazu7ydx06lj5gr4aqgeq6rkcreyykqnqey8z5fm6qsj8fqfetznk のようにnostr:要素を挿入できる

• :monoice:のようにカスタム絵文字を挿入できる(メニューの😃アイコンから←アイコン変えるかも)

:monopaca_kao:

:kubipaca_karada:

• 新規記事作成と、既存記事の修正ができる

やること

• [x] nostr:を投稿するときにtagにいれる
• [ ] レイアウトを整える
• [x] 画像をアップロードできるようにする できる
• [ ] 投稿しましたログとかをトースト的なやつでだすようにする
• [ ] あとなんか

All across the Lightning Network we can detect quite a lot of nodes, specially new nodes but also old nodes, that show a concerning lack of good node operation which impedes proper routing. I’ve seen nodes with a variable capacity whose channels are stagnant and non performant, which raises a question: what is the point on maintaining a public node if you are not able to route and dynamically assign resources as needed? Certainly it is a useless node, and channels of those nodes with other nodes better maintained are also useless, not because the fault of the good ones, but because the fault of the bad ones, which makes the whole network not as performant and great as it should be.

For the shake of improving the Lightning Network, I have created this guide, so every node out there can become useful, and, also, will greatly improve gains in routing for itself. Do not expect to become rich or even live out of routing fees, that is impossible unless you have a node with 100 or more BTC in 2025, but at least, a node should be able to cover its own maintenance costs; its the idea. Problem is that, currently, most nodes run on a loss, and that is highly related with the fee policy and the choice of nodes that they connect to. Let’s put an end to this. Here you will learn how to, at least, earn enough to cover electricity of your node, and with luck, a bit more.

Current earnings cover electricity and the payment of my node:

3K sats per day might not seem much for a 5 BTC capacity (2.5 BTC real outbound) node, but the screenshot was taken in a bad day, when the mempool was empty. I took the screenshot of a bad day on purpose, to prove my point. Some other days, specially when Bitcoin is going bullish and it is used a lot, I have seen 20K per day. A quick calculation brings around 1M sats per year at a minimum, more than enough to pay electricity, the machine, and even a bit more for beers and fun! Real gains across the year could be closer to around 5M in my case, which is not bad. And what is incredible, I maintain general low fees for most of the cases, except when I have no liquidity in the channel which must be high, as you will understand later in this article. So if you double or triple my recommended fees I would expect quite a lot more earnings. So expect gains of around 2% of the total capacity (4% for the amount you put in) per year minimum, and any extra beyond that by fine-tuning my recommendations I'm sure it will be very welcomed by you!

Step 1: put the node in a good machine

Please, don’t use an old computer or laptop, unless you change the SSD for a new one. Bitcoin and lightning uses the SSD heavily, which means it will fry it sooner or later. That is so that I recommend changing the SSD every 2 years even it it still feels good. If your SSD dies during operation, expect big loses. I’ve seen this so many times, and it also happened to me, that I am very serious about recommending it. Also, please use only Linux with ext4 file format, other formats, including ZFS, I’ve seen failing badly. If your filesystem fails, the sqlite db that LND or CLN uses will fail and you will force close many if not most channels, with big fees for onchain closings, which will totally ruin all your gains. You have been warned!

Also, please take your time to configure a clearnet (ipv4) address. Do not rely only on Tor, because Tor is slow and unreliable, specially when updating channel states on the gossip, which you will be doing a lot. Of course, configure Tor also, but as secondary, because too many nodes are Tor only, which is unfortunate.

Step 2: connect to good nodes

As a public node operator, your duty is to connect to as many nodes as possible, but first, to good reputable nodes. Your first 10 channels should be with big nodes and service providers, like exchanges, wallets, but also to very well positioned big nodes. Take your time to select these 10 first nodes and connect to the ones you think will improve your position in the network. Don’t choose the first 10 biggest, take your time to study the fees. Select nodes that use a wide range of fees, from 0 to 1000ppm. Don’t discard a node because you see some channels with high fees, it could only mean that they have no liquidity right now in that channel. But if all its channels have high fees, or at least all small channels have high fees, then discard it.

Then, when you have your first 10 big nodes connected, go ahead and go to https://lightningnetwork.plus/ to choose less popular ones. You need them, because you seek to fill the voids between smaller nodes, it is what most of your revenue will come from. Always try to do swaps, use the liquidity pool later when you have enough total inbound liquidity. Remember that total capacity is not total outbound. Total capacity is total outbound + total inbound. So you can start with 0.25BTC of your own, but total capacity could be much higher if other peers have open channels to you.

A proper public node should have a minimum of 50 channels at its peak. It doesn’t matter much the size of the channels, but the quantity and the quality. A node with 50x500k sized channels will usually perform 10x better than a node with 5x5M sized channels, even if they have the same total capacity. This is because more opportunities to route will be found if you have more channels, which means you are much better positioned.

Anyway, the minimum recommended is 1M per channel because most HTCLs are 100k to 500k and less than 1M will wipe out all your liquidity in the channels in one or two routings. This could change in the future because of the Bitcoin price, but in 2025 this is the state of things. But if you don’t have 0.25 BTC to open 50 channels (25 open by you, 25 by others using swaps), just use smaller channels, don't let your available liquidity to crush your excitement, who knows what is the future ahead us! Remember that we are just at the beginning of this technology and there is nothing that impides your channels to be open for the next 20 years when 1BTC=$1M! I would put the ultra minimum at 250k per channel, which means a 12.5M node (6.25M required sats to start with), but even that is too precarious in 2025. But hopefully not in the future! If you have less than that my honest recommendation is to run a private node and open private channels only, and only if you absolutely need a node because you have to provide a service for multiple people and you can't conform to use simpler wallets. Right now, I can think of only one example of requiring an ultra-small node instead of wallets, which is using LNBits to service your small business or family. Be aware, anyway, that a 12.5M node will definitely not cover your node running costs in 2025, it is just an investment and positioning for a future!

In any case, never, ever, put all your BTC in a LN node, at most one third of your bitcoins and only when you are confident.

Also remember you have to be online 24/7. Please, don’t setup a node if you can’t. Remember you are providing a constant service, not an intermittent one. This guide won’t work if you are not committed to this rule.

Step 3: understand the flow

I’ve seen too many node operators that do not understand how payments are routed, and this is a big problem, because this is the base of everything we do with a LN node.

Payments go from one node to another to another to another until it reaches destination. Each node has what is called an outbound fee. This fee controls how much does it cost to route a payment through that node. If the fee is low it is considered attractive and other nodes will prefer to use that route. If the fee is high, it is obvious that nodes will not choose that route unless there is no other way.

But there is a problem here: all channels have a liquidity limit. If a channel has 1M liquidity and a payment of 500k comes through it, then now the channel has 500k liquidity, that is, a ratio of 0.5. If another 400k comes through, now it has 100k liquidity and a ratio of 0.1. If now somebody tries to route a 200k payment through that channel, and error will happen, because it doesn’t have enough liquidity. It is called an HTCL failure, and this are quite normal. Liquidity can come backwards, which means that now that channel becomes the income instead of the outcome, so if 300k comes in, in the example above, now the liquidity ratio is 0.4 (100k already there plus 300k that just came in). So it is easy to understand that liquidity is very volatile: it will come in and out with any successful in or out HTLC.

The problem is: how do you know if a channel has liquidity? For privacy reasons, the liquidity of a channel is never announced, and only the two connected nodes know it. This is logical, to avoid bad actors to figure out which payments have been done by other people. So the only possible solution is to try all connected channels you have until one lets you go through because it has enough liquidity. And it is going to be done, always, in the order of outbound fees, from low to high. So the channel that has the lowest fee with enough liquidity, will catch the prize.

There is a way to signal that you have liquidity or you don’t, and it is based on scarcity: if you don’t have much liquidity, you increase the outbound fee, so other nodes will not find attractive to route through you in that direction. You don't have much liquidity, so why bother to allow routing? But, when you have again outbound liquidity, because other nodes have taken the opposite direction (inbound) using another channel of yours which has liquidity (as outbound), you intelligently lower the fees to signal your new updated increased liquidity in the channel. So, the idea is simple: if you have liquidity in the channel, you put low fees, if you don’t have liquidity, you put high fees. Please read that again until you fully understand it, it is extremely important.

There is another concept introduced by LND which is negative inbound fees: if you put negative inbound fees, for example -100ppm, it means that any payment going from that inbound channel to another of your outbound channels, will have a maximum discount of 100ppm. (Don’t worry, you will never lose because LND forbids to route losing money, so 100ppm is the maximum, but it could be less if the outgoing channel has less than 100ppm fees.) What this does is to encourage the filling of empty channels at the cost of earning less in channels with plenty of liquidity. This is very good, because it will automatically rebalance your extremes: channels with no liquidity will be filled up, channels with plenty of liquidity will be emptied down, creating a balance.

It is obvious that the total ratio, including all your channels, should be around 100%. That means that the total amount summing all channels of inbound and outbound should be approximately the same. Don’t get obsessed with this, 80% or 120% is ok too, but if it is lower or higher than that you should take measures to open or close channels, or even swap out or in using boltz.exchange or LOOP.

Step 4: managing fees

So, in order to make proper routing, you will have to constantly monitor all your channels on a regular basis. Minimum recommended frequency is once a day. You can do this automatically or manually. Some people prefer to do it manually because each channel has its own characteristics and some fees work better than others, which is something you learn with time observing the flow. But some other people, like me, don’t want to spend so much time doing so, and do automatic fee management using charge-lnd or lndg automators. A mixture of both styles is possible by disabling automatic fee management for selected channels.

Every node operator has his/her own preferences, but here are some basic recommendations that you can tweak over time as you acquire experience: ratio > 0.98: fees 0 (or less than 10) 0.2 < ratio < 0.98: fees proportional max 128, min 16 0.2 > ratio > 0.05: fees 500, inbound -16 ratio < 0.05: fees 1000, inbound -64 ratio = 0: fees more than 1000, inbound -128 So, as you can see, when the channel is full we encourage routing, when the channel is more balanced is when the earnings will occur (from 16 to 128ppm), when the channel is mostly empty we discourage forward routing (500ppm) but encourage backwards routing (inbound -16) and when it is almost empty we clearly totally discourage forward routing (1000ppm) but encourage backwards routing (inbound -64). And when someone just opened a channel with us, all liquidity is theirs so we aggressively encourage inbound routing by putting ultra high outbound fees and ultra inbound discounts. Simple, eh?

Step 5: automatic fee management

As stated before, you can automate this using charge-lnd or lndg or Lightning Terminal if you use LND. If you use CLN you are probably limited to create a personalized script, because I don’t know of any similar tool for it, apart from CL-BOSS which is unmaintained and non-customizable.

You will run this configuration a maximum of once per hour, and a minimum of once per day. You should not try to run it more frequent than once per hour because of two reasons: 1. The channel states stored in the gossip take from some minutes to some hours to properly propagate. 2. Some nodes will ban you if you try to update more than once per hour. What I recommend is once every 2 hours for big nodes with more than 50 channels. If you have less than 50 channels, your gossip will be slow to propagate so run it once a day. If you get many “Insufficient Fee” errors is because you are trying to update channel states too frequently. Also, some people report that increasing the variable numgraphsyncpeers in the LND configuration file helps with better propagation, but be aware that this will increase bandwidth usage.

I’ve been using lndg for some time, but I switched to charge-lnd because it is clearly superior and faster and more customizable. Lndg is still great for rebalancing (which I use a lot) and as a general interface, but I have disabled the fee management, which I now do with charge-lnd. If you can’t access charge-lnd then just use lndg with the frequency chosen above, but be aware that the configuration parameters are very limited, as you will soon realize (you are limited to just one strategy which is proportional, and it is very slow as it changes the fee in incremental steps). Yet it is better using lndg than nothing.

Lightning Terminal from Lightning Labs I have not tested. So I can’t say anything about it.

But here is a good starting configuration for charge-lnd that you can customize to your preferences:

``` [default]

'default' is special, it is used if no other policy matches a channel

strategy = static base_fee_msat = 128 fee_ppm = 96 inbound_base_fee_msat = 0 inbound_fee_ppm = 0 min_fee_ppm_delta=20

[mydefaults]

no strategy, so this only sets some defaults

base_fee_msat = 128 min_fee_ppm_delta = 0

[lost-onchain-sync]

The fact that lnd was not synchronized with the chain for more than 5 minutes

was an indicator of a severe problem in the past.

onchain.synced_to_chain = false base_fee_msat = 210_000 fee_ppm = 210_000

[expensive]

match channels where the peer node has set a high (>=8_000 ppm) fee rate

and set the same fee rate on our side (strategy=match_peer)

chan.min_fee_ppm = 8000 strategy = match_peer

[leafnode]

charge non-routing (private=true) peers a bit more for our service

chan.private = true strategy = static fee_ppm = 1000

[encourage-routing]

'autobalance' (lower fees so using outbound is more attractive)

chan.min_ratio = 0.98 inbound_base_fee_msat = 0 inbound_fee_ppm = 0 strategy = static base_fee_msat = 64 fee_ppm = 16

[discourage-routing]

'autobalance' (higher fees so using outbound is less attractive)

chan.max_ratio = 0.2 chan.min_ratio = 0.05 strategy = proportional inbound_base_fee_msat = -64 inbound_fee_ppm = -16 min_fee_ppm = 32 max_fee_ppm = 700 base_fee_msat = 1_000

[all-liquidity-is-theirs] chan.max_ratio = 0.00 inbound_base_fee_msat = -128 inbound_fee_ppm = -128 strategy = static base_fee_msat = 1_000 fee_ppm = 1000

[discourage-routing-extreme] chan.max_ratio = 0.05 inbound_base_fee_msat = -128 inbound_fee_ppm = -32 strategy = proportional min_fee_ppm = 32 max_fee_ppm = 1000 base_fee_msat = 1_000

[proportional]

'proportional' can also be used to auto balance (lower fee rate when low remote balance & higher rate when higher remote balance)

fee_ppm decreases linearly with the channel balance ratio (min_fee_ppm when ratio is 1, max_fee_ppm when ratio is 0)

20% excess:

chan.min_ratio = 0.2 chan.max_ratio = 0.98 strategy = proportional min_fee_ppm = 32

20% excess, so for a max of 128, it’s calculated 128/(1-0.20)=160

max_fee_ppm = 160 inbound_base_fee_msat = 0 inbound_fee_ppm = 0 base_fee_msat = 128 min_fee_ppm_delta=16 ```

So you might run this config in a crontab or with your node distribution script if it is provided. I think Umbrel has this app in their portfolio, so just use it if you have Umbrel and ignore the following. If you run it manually or with a distro that doesn’t have charge-lnd, you can configure a crontab. This is just an example, please ask support for proper configuration on your distro. And if you distro do not include charge-lnd, ask support to include it, at this point it’s quite a necessity. Anyway here is the manual configuration: ``` $ crontab -e

0 */2 * * * echo "=======>" date >> /home/nodo/charge-lnd/log && /home/nodo/charge-lnd/env/bin/charge-lnd -c /home/nodo/charge-lnd/my.config >> /home/nodo/charge-lnd/log ```

That is supposing charge-lnd executable is installed under /home/nodo/charge-lnd/env/bin/charge-lnd and config is in /home/nodo/charge-lnd/my.config and LND is running without docker. If it is running under docker, you will have to ask support of your distro.

Step 6: help your peers

Remember that your peers are not only your competition, they are also your customers. So it is a strange symbiosis: you compete with them, but they also help you (and you help them).

If your peers are not well informed and have a bad maintained node, you are in a loss, because your channels with them will get stagnant and will not route. If they are well informed and know how to manage a node, then the channels will not be stagnant and they will route through you.

So it is stupid to keep this information as a secret. Every node operator should know it. And the more people know it, the better for everybody.

So, please, if you detect stagnant channels and bad maintained peers connected to you, just lead them to this guide, or guide them yourself. It’s a good idea to bookmark this guide so you have it prepared for the future.

And that’s it!! Happy routing!!

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

₍ ･ᴗ･ ₎ ₍ ･ᴗ･ ₎₍ ･ᴗ･ ₎

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/972645

Album art didn’t always exist. In the early 1900s, recorded music was still a novelty, overshadowed by sales of sheet music. Early vinyl records were vastly different from what we think of today: discs were sold individually and could only hold up to four minutes of music per side. Sometimes, only one side of the record was used. One of the most popular records of 1910, for example, was “Come, Josephine, in My Flying Machine”: it clocked in at two minutes and 39 seconds.

The invention of album art can get lost in the story of technological mastery. But among all the factors that contributed to the rise of recorded music, it stands as one of the few that was wholly driven by creators themselves. Album art — first as marketing material, then as pure creative expression — turned an audio-only medium into a multi-sensory experience.

This is the story of the people who made music visible.

Continue reading

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

• 1:nan:
• 2
• 2irorio絵文字
• 1nostr:npub1sjcvg64knxkrt6ev52rywzu9uzqakgy8ehhk8yezxmpewsthst6sw3jqcw
• 2
• 2
  • 3
  • 3
• 2
• 1

|1|2| |:--|:--| |test| :nan: | ---

:nan: :nan:

1. 1
2. 2
3. tet
4. tes
5. 3
6. 1

7. 2

   t

   te

   test

8. 19^th^

9. H~2~O

(☝ ՞ਊ ՞)☝ｳｪｰｲ

本サイトはfirefoxのみサポートしています

うにょ

:wayo:

This text will bounce

wss://catstrr.swarmstr.com/

うにょうにょてすと

yakihonne.com iris.to jumble.social Me

@ 84b0c46a:417782f5

2025-05-04 09:36:08

nostrリンクテスト

web+nostrリンクテスト

x-ukagaka-linkテスト

x-ukagaka-linkテスト2

nostalk

ハイパーテスト

yakihonne.com iris.to jumble.social Me

@ 17538dc2:71ed77c4

2025-04-02 16:04:59

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

yakihonne.com iris.to jumble.social Me

@ 52b4a076:e7fad8bd

2025-05-03 04:42:13

Introduction

Me and Fishcake have been working on infrastructure for Noswhere and Nostr.build. Part of this involves processing a large amount of Nostr events for features such as search, analytics, and feeds.

I have been recently developing nosdex v3, a newer version of the Noswhere scraper that is designed for maximum performance and fault tolerance using FoundationDB (FDB).

Fishcake has been working on a processing system for Nostr events to use with NB, based off of Cloudflare (CF) Pipelines, which is a relatively new beta product. This evening, we put it all to the test.

First preparations

We set up a new CF Pipelines endpoint, and I implemented a basic importer that took data from the nosdex database. This was quite slow, as it did HTTP requests synchronously, but worked as a good smoke test.

Asynchronous indexing

I implemented a high-contention queue system designed for highly parallel indexing operations, built using FDB, that supports: - Fully customizable batch sizes - Per-index queues - Hundreds of parallel consumers - Automatic retry logic using lease expiration

When the scraper first gets an event, it will process it and eventually write it to the blob store and FDB. Each new event is appended to the event log.

On the indexing side, a Queuer will read the event log, and batch events (usually 2K-5K events) into one work job. This work job contains: - A range in the log to index - Which target this job is intended for - The size of the job and some other metadata

Each job has an associated leasing state, which is used to handle retries and prioritization, and ensure no duplication of work.

Several Workers monitor the index queue (up to 128) and wait for new jobs that are available to lease.

Once a suitable job is found, the worker acquires a lease on the job and reads the relevant events from FDB and the blob store.

Depending on the indexing type, the job will be processed in one of a number of ways, and then marked as completed or returned for retries.

In this case, the event is also forwarded to CF Pipelines.

Trying it out

The first attempt did not go well. I found a bug in the high-contention indexer that led to frequent transaction conflicts. This was easily solved by correcting an incorrectly set parameter.

We also found there were other issues in the indexer, such as an insufficient amount of threads, and a suspicious decrease in the speed of the Queuer during processing of queued jobs.

Along with fixing these issues, I also implemented other optimizations, such as deprioritizing Worker DB accesses, and increasing the batch size.

To fix the degraded Queuer performance, I ran the backfill job by itself, and then started indexing after it had completed.

Bottlenecks, bottlenecks everywhere

After implementing these fixes, there was an interesting problem: The DB couldn't go over 80K reads per second. I had encountered this limit during load testing for the scraper and other FDB benchmarks.

As I suspected, this was a client thread limitation, as one thread seemed to be using high amounts of CPU. To overcome this, I created a new client instance for each Worker.

After investigating, I discovered that the Go FoundationDB client cached the database connection. This meant all attempts to create separate DB connections ended up being useless.

Using OpenWithConnectionString partially resolved this issue. (This also had benefits for service-discovery based connection configuration.)

To be able to fully support multi-threading, I needed to enabled the FDB multi-client feature. Enabling it also allowed easier upgrades across DB versions, as FDB clients are incompatible across versions:

FDB_NETWORK_OPTION_EXTERNAL_CLIENT_LIBRARY="/lib/libfdb_c.so" FDB_NETWORK_OPTION_CLIENT_THREADS_PER_VERSION="16"

Breaking the 100K/s reads barrier

After implementing support for the multi-threaded client, we were able to get over 100K reads per second.

You may notice after the restart (gap) the performance dropped. This was caused by several bugs: 1. When creating the CF Pipelines endpoint, we did not specify a region. The automatically selected region was far away from the server. 2. The amount of shards were not sufficient, so we increased them. 3. The client overloaded a few HTTP/2 connections with too many requests.

I implemented a feature to assign each Worker its own HTTP client, fixing the 3rd issue. We also moved the entire storage region to West Europe to be closer to the servers.

After these changes, we were able to easily push over 200K reads/s, mostly limited by missing optimizations:

It's shards all the way down

While testing, we also noticed another issue: At certain times, a pipeline would get overloaded, stalling requests for seconds at a time. This prevented all forward progress on the Workers.

We solved this by having multiple pipelines: A primary pipeline meant to be for standard load, with moderate batching duration and less shards, and high-throughput pipelines with more shards.

Each Worker is assigned a pipeline on startup, and if one pipeline stalls, other workers can continue making progress and saturate the DB.

The stress test

After making sure everything was ready for the import, we cleared all data, and started the import.

The entire import lasted 20 minutes between 01:44 UTC and 02:04 UTC, reaching a peak of: - 0.25M requests per second - 0.6M keys read per second - 140MB/s reads from DB - 2Gbps of network throughput

FoundationDB ran smoothly during this test, with: - Read times under 2ms - Zero conflicting transactions - No overloaded servers

CF Pipelines held up well, delivering batches to R2 without any issues, while reaching its maximum possible throughput.

Finishing notes

Me and Fishcake have been building infrastructure around scaling Nostr, from media, to relays, to content indexing. We consistently work on improving scalability, resiliency and stability, even outside these posts.

Many things, including what you see here, are already a part of Nostr.build, Noswhere and NFDB, and many other changes are being implemented every day.

If you like what you are seeing, and want to integrate it, get in touch. :)

If you want to support our work, you can zap this post, or register for nostr.land and nostr.build today.

yakihonne.com iris.to jumble.social Me

@ 04c915da:3dfbecc9

2025-03-26 20:54:33

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

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

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

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

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

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

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

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

yakihonne.com iris.to jumble.social Me

@ a5ee4475:2ca75401

2025-05-07 14:56:04

clients #list #descentralismo #english #article #finalversion

*These clients are generally applications on the Nostr network that allow you to use the same account, regardless of the app used, keeping your messages and profile intact.

**However, you may need to meet certain requirements regarding access and account NIP for some clients, so that you can access them securely and use their features correctly.

---

CLIENTS

---

Twitter like

• Nostrmo - [source] 🌐🤖🍎💻(🐧🪟🍎)
• Coracle - Super App [source] 🌐
• Amethyst - Super App with note edit, delete and other stuff with Tor [source] 🤖
• Primal - Social and wallet [source] 🌐🤖🍎
• Iris - [source] 🌐🤖🍎
• Current - [source] 🤖🍎
• FreeFrom 🤖🍎
• Openvibe - Nostr and others (new Plebstr) [source] 🤖🍎
• Snort 🌐(🤖[early access]) [source]
• Damus 🍎 [source]
• Nos 🍎 [source]
• Nostur 🍎 [source]
• NostrBand 🌐 [info] [source]
• Yana 🤖🍎🌐💻(🐧) [source]
• Nostribe [on development] 🌐 [source]
• Lume 💻(🐧🪟🍎) [info] [source]
• Gossip - [source] 💻(🐧🪟🍎)
• Camelus [early access] 🤖 [source]

---

Communities

• CCNS - Community Curated Nostr Stuff [source]
• noStrudel - Gamified Experience [info] 🌐
• Nostr Kiwi [creator] 🌐
• Satellite [info] 🌐
• Flotilla - [source] 🌐🐧
• Chachi - [source] 🌐
• Futr - Coded in haskell [source] 🐧 (others soon)
• Soapbox - Comunnity server [info] [source] 🌐
• Ditto - Soapbox comunnity server 🌐 [source] 🌐
• Cobrafuma - Nostr brazilian community on Ditto [info] 🌐
• Zapddit - Reddit like [source] 🌐
• Voyage (Reddit like) [on development] 🤖

---

Wiki

• Wikifreedia [source] 🌐
• Wikinostr [source] 🌐
• Wikistr [info] [source] 🌐

---

Search

• Advanced nostr search - Advanced note search by isolated terms related to a npub profile [source] 🌐
• Nos Today - Global note search by isolated terms [info] [source] 🌐
• Nostr Search Engine - API for Nostr clients [source]
• Ntrends - Trending notes and profiles 🌐

---

Website

• Npub pro - Your site on Nostr [source]

---

App Store

ZapStore - Permitionless App Store [source]

---

Audio and Video Transmission

• Castr - Your npub as podcast feed [source]
• Nostr Nests - Audio Chats [source] 🌐
• Fountain - Podcast [source] 🤖🍎
• ZapStream - Live streaming [source] 🌐
• Corny Chat - Audio Chat [source] 🌐
• Swae - Live streaming [source] (on development) ⏳

---

Video Streaming

• Flare - Youtube like 🌐 [source]

---

Music

• Tidal - Music Streaming [source] [about] [info] 🤖🍎🌐
• Wavlake - Music Streaming [source] 🌐(🤖🍎 [early access])
• Tunestr - Musical Events [source] [about] 🌐
• Stemstr - Musical Colab (paid to post) [source] [about] 🌐

---

Images

• Lumina - Trending images and pictures [source] 🌐
• Pinstr - Pinterest like [source] 🌐
• Slidestr - DeviantArt like [source] 🌐
• Memestr - ifunny like [source] 🌐

---

Download and Upload

• DTAN - Distributed Torrent Archive on Nostr [info] [source] 🌐

---

Documents, graphics and tables

• Mindstr - Mind maps [source] 🌐
• Docstr - Share Docs [info] [source] 🌐
• Formstr - Share Forms [info] 🌐
• Sheetstr - Share Spreadsheets [source] 🌐
• Slide Maker - Share slides 🌐 (advice: https://zaplinks.lol/ and https://zaplinks.lol/slides/ sites are down)

---

Health

• Sobrkey - Sobriety and mental health [source] 🌐
• NosFabrica - Finding ways for your health data 🌐
• LazerEyes - Eye prescription by DM [source] 🌐

---

Forum

• OddBean - Hacker News like [info] [source] 🌐
• LowEnt - Forum [info] 🌐
• Swarmstr - Q&A / FAQ [info] 🌐
• Staker News - Hacker News like 🌐 [info]

---

Direct Messenges (DM)

• 0xchat 🤖🍎 [source]
• Nostr Chat 🌐🍎 [source]
• Blowater 🌐 [source]
• Anigma (new nostrgram) - Telegram based [on development] [source]
• Keychat - Signal based [🤖🍎 on development] [source]

---

Reading

• nRSS - Nostr RSS reader 🌐
• Highlighter - Insights with a highlighted read [info] 🌐
• Zephyr - Calming to Read [info] 🌐
• Flycat - Clean and Healthy Feed [info] 🌐
• Nosta - Check Profiles [on development] [info] 🌐
• Alexandria - e-Reader and Nostr Knowledge Base (NKB) [source] 🌐

---

Writing

• Habla - Blog [info] 🌐
• Blogstack - Blog [info]🌐
• YakiHonne - Articles and News [info] 🤖🍎🌐

---

Lists

• Following - Users list [source] 🌐
• Nostr Unfollower - Nostr Unfollower
• Listr - Lists [source] 🌐
• Nostr potatoes - Movies List source 💻(numpy)

---

Market and Jobs

• Shopstr - Buy and Sell [source] 🌐
• Nostr Market - Buy and Sell 🌐
• Plebeian Market - Buy and Sell [source] 🌐
• Ostrich Work - Jobs [source] 🌐
• Nostrocket - Jobs [source] 🌐

---

Data Vending Machines - DVM (NIP90)

(Data-processing tools)

• Noogle - [source] 🌐
• Vendata - [source] 🌐
• TaskTiger 🌐
• Malware DVMs 🌐

---

Games

• Chesstr - Chess 🌐 [source]
• Jestr - Chess [source] 🌐
• Snakestr - Snake game [source] 🌐
• DEG Mods - Decentralized Game Mods [info] [source] 🌐
• NG Engine - Nostr Game Engine [source] 🌐
• JmonkeyEngine - Java game engine [source] 🌐

---

Customization

• Emojito - Send Funny Stickers to React 🌐 [creator]

---

Like other Services

• Olas - Instagram like [source] 🤖🍎🌐
• Nostree - Linktree like 🌐
• Rabbit - TweetDeck like [info] 🌐
• Zaplinks - Nostr links 🌐
• Omeglestr - Omegle-like Random Chats [source] 🌐

---

General Uses

• Njump - HTML text gateway source 🌐
• Filestr - HTML midia gateway [source] 🌐
• W3 - Nostr URL shortener [source] 🌐
• Playground - Test Nostr filters [source] 🌐
• Spring - Browser 🌐

---

Places

• Wherostr - Travel and show where you are
• Arc Map (Mapstr) - Bitcoin Map [info]

---

Driver and Delivery

• RoadRunner - Uber like [on development] ⏱️
• Nostrlivery - iFood like [on development] ⏱️

[⚠️SCAM⚠️] Arcade City - Uber like [source]

---

OTHER STUFF

---

Lightning Wallets (zap)

• Alby - Native and extension [info] 🌐
• ZBD - Gaming and Social [info] 🤖🍎
• Wallet of Satoshi [info] 🤖🍎
• Minibits - Cashu mobile wallet [info] 🤖
• Blink - Opensource custodial wallet (KYC over 1000 usd) [source] 🤖🍎
• LNbits - App and extesion [source] 🤖🍎💻
• Zeus - [info] [source] 🤖🍎

---

Exchange

• Mostro - P2P lightning exchange on Nostr [info] 🌐
• Emptio - Bitcoin P2P on Nostr [on development]

---

Media Server (Upload Links)

audio, image and video

• Nostr Build - [source] 🌐
• Nostr Check - [info] [source] 🌐
• NostPic - [source] 🌐
• Sovbit 🌐
• Voidcat - [source] 🌐

Without Nip: - Pomf - Upload larger videos [source] - Catbox - [source] - x0 - [source]

---

Donation and payments

• Zapper - Easy Zaps [source] 🌐
• Autozap [source] 🌐
• Zapmeacoffee 🌐
• Nostr Zap 💻(numpy)
• Creatr - Creators subscription 🌐
• Geyzer - Crowdfunding [info] [source] 🌐
• Heya! - Crowdfunding [source]

---

Security

• Secret Border - Generate offline keys 💻(java)
• Umbrel - Your private relay [source] 🌐

---

Key signing and Extension

• Nowser - Account access keys 📱(🤖🍎) 💻(🐧🍎🪟)
• Nos2x - Account access keys 🌐
• Nsec.app 🌐 [info]
• Lume - [info] [source] 🐧🪟🍎
• Satcom - Share files to discuss - [info] 🌐
• KeysBand - Multi-key signing [source] 🌐

---

Code

• Nostrify - Share Nostr Frameworks 🌐
• Git Workshop (github like) [experimental] 🌐
• Gitstr (github like) [on development] ⏱️
• Osty [on development] [info] 🌐
• Python Nostr - Python Library for Nostr
• Sybil - Creating, managing and test Nostr events [on development] ⏱️

---

Relay Check and Cloud

• Nostr Watch - See your relay speed 🌐
• NosDrive - Nostr Relay that saves to Google Drive

---

Bidges and Getways

• Matrixtr Bridge - Between Matrix & Nostr
• Mostr - Between Nostr & Fediverse
• Nostrss - RSS to Nostr
• Rsslay - Optimized RSS to Nostr [source]
• Atomstr - RSS/Atom to Nostr [source]

Useful Profiles and Trends

• Kinostr - Nostr Cinema [english]
• Equinox - Nostr Cinema [portuguese]

nostr-voice - Voice note (just some clients)

---

NOT RELATED TO NOSTR

---

Android Keyboards

• Futo - Gboard like [source]
• Florisboard - [source]
• Heliboard - Openboard based [source]

---

Personal notes and texts

• Joplin - privacy-focused note taking app with sync capabilities [source] 📱(🤖🍎) - 💻 (🐧🪟🍎)

---

Front-ends

• Nitter - Twitter / X without your data [source]
• NewPipe - Youtube, Peertube and others, without account & your data [source] 🤖
• Piped - Youtube web without you data [source] 🌐

---

Other Services

• Brave - Browser [source]
• DuckDuckGo - Search [source]
• LLMA - Meta - Meta open source AI [source]
• DuckDuckGo AI Chat - Famous AIs without Login [source]
• Proton Mail - Mail [source]

Other open source index: Degoogled Apps

---

Some other Nostr index on:

Nostr Apps | Nostorg | Awesome Nostr

yakihonne.com iris.to jumble.social Me

@ 57d1a264:69f1fee1

2025-05-06 05:49:01

I don’t like garlic. It’s not a dislike for the taste in the moment, so much as an extreme dislike for the way it stays with you—sometimes for days—after a particularly garlicky meal.

Interestingly enough, both of my brothers love garlic. They roast it by itself and keep it at the ready so they can have a very strong garlic profile in their cooking. When I prepare a dish, I don’t even see garlic on the ingredient list. I’ve cut it out of my life so completely that my brain genuinely skips over it in recipes. While my brothers are looking for ways to sneak garlic into everything they make, I’m subconsciously avoiding it altogether.

A few years back, when I was digging intensely into how design systems mature, I stumbled on the concept of a design system origin story. There are two extreme origin stories and an infinite number of possibilities between. On one hand you have the grassroots system, where individuals working on digital products are simply trying to solve their own daily problems. They’re frustrated with having to go cut and paste elements from past designs or with recreating the same layouts over and over, so they start to work more systematically. On the other hand, you have the top down system, where leadership is directing teams to take a more systematic approach, often forming a small partially dedicated core team to tackle some centralized assets and guidelines for all to follow. The influences in those early days bias a design system in interesting and impactful ways.

We’ve established that there are a few types of bias that are either intentionally or unintentionally embedded into our design systems. Acknowledging this is a great first step. But, what’s the impact of this? Does it matter?

I believe there are a few impacts design system biases, but there’s one that stands out. The bias in your design system makes some individuals feel the system is meant for them and others feel it’s not. This is a problem because, a design system cannot live up to it’s expected value until it is broadly in use. If individuals feel your design system is not for them, the won’t use it. And, as you know, it doesn’t matter how good your design system is if nobody is using it.

Continue reading

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

yakihonne.com iris.to jumble.social Me

@ 3589b793:ad53847e

2025-04-30 12:40:42

※本記事は別サービスで2022年6月24日に公開した記事の移植です。

どうも、「NostrはLNがWeb統合されマネーのインターネットプロトコルとしてのビットコインが本気出す具体行動のショーケースと見做せばOK」です、こんばんは。

またまた実験的な試みがNostrで行われているのでレポートします。本シリーズはライブ感を重視しており、例によって（？）プルリクエストなどはレビュー段階なのでご承知おきください。

今回の主役はあくまでLightningNetworkの新提案（ただし以前からあるLSATからのリブランディング）となるLightning HTTP 402 Protocol（略称: L402）です。そのショーケースの一つとしてNostrが活用されているというものになります。

Lightning HTTP 402 Protocol（略称: L402）とは何か

bLIPに今月挙がったプロポーザル内容です。

https://github.com/lightning/blips/pull/26

L402について私はまだ完全に理解した段階ではあるのですがなんとか一言で説明しようとすると「Authトークンのように"Paid"トークンをHTTPヘッダーにアタッチして有料リソースへのHTTPリクエストの受け入れ判断を行えるようにする」ものだと解釈しました。

Authenticationでは、HTTPヘッダーにAuthトークンを添付し、その検証が通ればHTTPリクエストを許可し、通らなければ401 Unauthorizedコードをエラーとして返すように定められています。

https://developer.mozilla.org/ja/docs/Web/HTTP/Status/401

L402では、同じように、HTTPヘッダーに支払い済みかどうかを示す"Paid"トークンを添付し、その検証が通ればHTTPリクエストを許可し、通らなければ402 Payment Requiredコードをエラーとして返すようにしています。

なお、"Paid"トークンという用語は私の造語となります。便宜上本記事では使わせていただきますが、実際はAuthも入ってくるのが必至ですし、プルリクエストでも用語をどう定めるかは議論になっていることをご承知おきください。（"API key", "credentials", "token", らが登場しています）

この402ステータスコードは従来から定義されていましたが、MDNのドキュメントでも記載されているように「実験的」なものでした。つまり、器は用意されているがこれまで活用されてこなかったものとなり、本プロトコルの物語性を体現しているものとなります。

https://developer.mozilla.org/ja/docs/Web/HTTP/Status/402

幻であったHTTPステータスコード402 Payment Requiredを実装する

この物語性は、上述のbLIPのスペックにも詳述されていますが、以下のスライドが簡潔です。402 Payment Requiredは予約されていましたが、けっきょくのところWorldWideWebはペイメントプロトコルを実装しなかったので、Bitcoinの登場まで待つことになった、というのが要旨になります。このWorldWideWebにおける決済機能実装に関する歴史話はクリプト界隈でもたびたび話題に上がりますが、そこを繋いでくる文脈にこれこそマネーのインターネットプロトコルだなと痺れました。

https://x.com/AlyseKilleen/status/1671342634307297282

この"Paid"トークンによって実現できることとして、第一にAIエージェントがBitcoin/LNを自律的に利用できるようになるM2M(MachineToMachine)的な話が挙げられていますが、ユースケースは想像力がいろいろ要るところです。実際のところは「有料リソースへの認可」を可能にすることが主になると理解しました。本連載では、繰り返しNostrクライアントにLNプロトコルを直接搭載せずにLightningNetworkを利用可能にする組み込み方法を見てきましたが、本件もインボイス文字列 & preimage程度の露出になりアプリケーション側でノードやウォレットの実装が要らないので、その文脈で位置付ける解釈もできるかと思います。

Snortでのサンプル実装

LN組み込み業界のリーディングプロダクトであるSnortのサンプル実装では、L402を有料コンテンツの購読に活用しています。具体的には画像や動画を投稿するときに有料のロックをかける、いわゆるペイウォールの一種となります。もともとアップローダもSnortが自前で用意しているので、そこにL402を組み込んでみたということのようです。

体験方法の詳細はこちらにあります。 https://njump.me/nevent1qqswr2pshcpawk9ny5q5kcgmhak24d92qzdy98jm8xcxlgxstruecccpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz78pvlzg

上記を試してみた結果が以下になります。まず、ペイウォールでロックした画像がNostrに投稿されている状態です。まったくビューワーが実装されておらず、ただのNotFound状態になっていますが、支払い前なのでロックされているということです。

次にこのHTTP通信の内容です。

通信自体はエラーになっているわけですが、ステータスコードが402で、レスポンスヘッダーのWWW-AuthenticateにInvoice文字列が返ってきています。つまり、このインボイスを支払えば"Paid"トークンが付与されて、その"Paid"トークンがあれば最初の画像がアンロックされることとなります。残念ながら現在は日本で利用不可のStrikeAppでしか払込みができないためここまでとなりますが、本懐である402 Payment Requiredとインボイス文字列は確認できました。

今確認できることは以上ですが、AmethystやDamusなどの他のNostrクライアントが実装するにあたり、インラインメディアを巡ってL402の仕様をアップデートする必要性や同じくHTTPヘッダーへのAuthトークンとなるNIP-98と組み合わせるなどの議論が行われている最中です。

LinghtningNetworkであるからこそのL402の実現

"Paid"トークンを実現するためにはLightningNetworkのファイナリティが重要な要素となっています。逆に言うと、reorgによるひっくり返しがあり得るBitcoinではできなくもないけど不便なわけです。LightningNetworkなら、当事者である二者間で支払いが確認されたら「同期的」にその証であるハッシュ値を用いて"Paid"トークンを作成することができます。しかもハッシュ値を提出するだけで台帳などで過去の履歴を確認する必要がありません。加えて言うと、受金者側が複数のノードを建てていて支払いを受け取るノードがどれか一つになる状況でも、つまり、スケーリングされている状況でも、"Paid"トークンそのものはどのノードかを気にすることなくステートレスで利用できるとのことです。（ここは単にreverse proxyとしてAuthサーバががんばっているだけと解釈することもできますがずいぶんこの機能にも力点を置いていて大規模なユースケースが重要になっているのだなという印象を抱きました）

Macaroonの本領発揮か？それとも詳細定義しすぎか？

HTTP通信ではWWW-Authenticateの実値にmacaroonの記述が確認できます。また現在のL402スペックでも"Paid"トークンにはmacaroonの利用が前提になっています。

このmacaroonとは（たぶん）googleで研究開発され、LNDノードソフトウェアで活用されているCookieを超えるという触れ込みのデータストアになります。しかし、あまり普及しなかった技術でもあり、個人の感想ですがなんとも微妙なものになっています。

https://research.google/pubs/macaroons-cookies-with-contextual-caveats-for-decentralized-authorization-in-the-cloud/

macaroonの強みは、Cookieを超えるという触れ込みのようにブラウザが無くてもプロセス間通信でデータ共有できる点に加えて、HMACチェーンで動的に認証認可を更新し続けられるところが挙げられます。しかし、そのようなユースケースがあまり無く、静的な認可となるOAuthやJWTで十分となっているのが現状かと思います。

L402では、macaroonの動的な更新が可能である点を活かして、"Paid"トークンを更新するケースが挙げられています。わかりやすいのは上記のスライド資料でも挙げられている"Dynamic Pricing"でしょうか。プロポーザルではloop©️LightningLabsにおいて月間の最大取引量を認可する"Paid"トークンを発行した上でその条件を動向に応じて動的に変更できる例が解説されています。とはいえ、そんなことしなくても再発行すればええやんけという話もなくもないですし、プルリクエストでも仕様レベルでmacaroonを指定するのは「具体」が過ぎるのではないか、もっと「抽象」し単なる"Opaque Token"程度の粒度にして他の実装も許容するべきではないか、という然るべきツッコミが入っています。

個人的にはそのツッコミが妥当と思いつつも、なんだかんだ初めてmacaroonの良さを実感できて感心した次第です。

yakihonne.com iris.to jumble.social Me

@ 3589b793:ad53847e

2025-04-30 12:28:25

※本記事は別サービスで2023年4月19日に公開した記事の移植です。

どうも、「NostrはLNがWeb統合されマネーのインターネットプロトコルとしてのビットコインが本気出す具体行動のショーケースと見做せばOK」です、こんにちは。

前回まで投げ銭や有料購読の組み込み方法を見てきました。

zapsという投げ銭機能が各種クライアントに一通り実装されて活用が進んでいることで、統合は次の段階へ移り始めています。「作戦名: ウォレットをNostrクライアントに組み込め」です。今回はそちらをまとめます。

投げ銭する毎にいちいちウォレットを開いてまた元のNostrクライアントに手動で戻らないといけない is PAIN

LNとNostrはインボイス文字列で繋がっているだけの疎結合ですが、投稿に投げ銭するためには何かのLNウォレットを開いて支払いをして、また元のNostrクライアントに戻る操作をユーザーが手作業でする必要があります。お試しで一回やる程度では気になりませんが普段使いしているとこれはけっこうな煩わしさを感じるUXです。特にスマホでは大変にだるい状況になります。連打できない！

2月の実装以来、zapsは順調に定着して日々投げられています。

https://stats.nostr.band/#daily_zaps

なので、NostrクライアントにLNウォレットの接続を組み込み、支払いのために他のアプリに遷移せずにNostクライアント単独で完結できるようなアップデートが始まっています。

Webクライアント

NostrのLN組み込み業界のリーディングプレイヤーであるSnortでの例です。以下のようにヘッダーのウォレットアイコンをクリックすると連携ウォレットの選択ができます。

もともとNostrに限らずウェブアプリケーションとの連携をするために、WebLNという規格があります。簡単に言うと、ブラウザのグローバル領域を介して、LNウォレットの拡張機能と、タブで開いているウェブアプリが、お互いに連携するためのインターフェースを定めているものです。これに対応していると、LNによる支払いをウェブアプリが拡張機能に依頼できるようになります。さらにオプションで「確認無し」をオンにすると、拡張機能画面がポップアップせずにバックグラウンドで実行できるようになり、ノールック投げ銭ができるようになります。

似たようなものにNostrではNIP-07があります。NIP-07はNostrの秘密鍵を拡張機能に退避して、Nostrクライアントは秘密鍵を知らない状態で署名や複合を拡張機能に移譲できるようにしているものです。

Albyの拡張機能ではWebLNとNIP-07のどちらにも対応しています。

実はSnortはzapsが来る前からWebLNには対応していたのですが、さらに一歩進み、拡張機能ウォレットだけでなく、LNノードや拡張機能以外のLNウォレットと連携設定できるようになってきています。

umbrelなどでノードを立てている人ならLND with LNCでノードと直接繋げます。またLNDHubに対応したウォレットなどのアプリケーションとも繋げます。これらの接続は、WebLNにラップされて拡張機能ウォレットとインターフェースを揃えられた上で、Snort上でのインボイスの支払いに活用されます。

なお、LNCのpairingPhrase/passwordやLNDHubの接続情報などのクレデンシャルは、ブラウザのローカルストレージに保存されています。Nostrのリレーサーバなどには送られませんので、端末ごとに設定が必要です。

スマホアプリ

今回のメインです。なお、例によって（？）スペックは絶賛議論中でまだフィックスしていない中で記事を書いています。ディテールは変わるかもしれないので悪しからずです。

スマホアプリで上記のことをやるためには、後半のLNCやLNDHubはすでにzeusなどがやっているようにできますが、あくまでネイティブウォレットのラッパーです。Nostrでは限られた用途になるので1-click支払いのようなものを行うためにはそこから各スマホアプリが作り込む必要があります。まあこれはこれでやればいいという話でもあるのですが、LNノードやLNウォレットのアプリケーション側へのインターフェースの共通仕様は定められていないので、LNDとcore-lightningとeclairではすべて実装方法が違いますし、ウォレットもバラバラなので大変です。

そこで、多種多様なノードやウォレットの接続を取りまとめ一般アプリケーションへ統一したインターフェースを媒介するLN Adapter業界のリーディングカンパニーであるAlbyが動きました。AndroidアプリのAmethystで試験公開されていますが、スマホアプリでも上記のSnortのような連携が可能になるようなSDKが開発されました。

リリース記事 https://blog.getalby.com/native-zapping-in-amethyst/

"Unstoppable zapping for users"なんて段落見出しが付けられているように、スマホで別のアプリに切り替えてまた元に戻らなくても良いようにして、Nostr上でマイクロペイメントを滑らかにする、つまり、連打できることを繰り返し強調しています。

具体的にやっていることを見ていきます。以下の画像群はリリース記事の動画から抜粋しています。各投稿のzapsボタン⚡️をタップしたときの画面です。

上の赤枠が従来の投げ銭の詳細を決める場所で、下の赤枠の「Wallet Connect Service」が新たに追加されたAlby提供のSDKを用いたコネクト設定画面です。基本的にはOAuth2.0ベースのAlbyのAPIを活用していて、右上のAlbyアイコンをタップすると以下のようなOAuthの認可画面に飛びます。（ただし後述するように通常のOAuthとは一部異なります。）

画面デザインは違いますが、まあ他のアプリでよく目にするTwitter連携やGoogleアカウント連携とやっていることは同じです。

このOAuthベースのAPIはNostr専用のエンドポイントが建てられています。Nostr以外のECショップやマーケットプレイスなどへのAlbyのOAuthは汎用のエンドポイントが用意されています。よって通常のAlbyの設定とは別にセッション詳細を以下のサイトで作成する必要があります。

https://nwc.getalby.com/ （サブドメインのnwcはNostr Wallet Connectの略）

なぜNostrだけは特別なのかというところが完全には理解しきれていないですが、以下のところまで確認できています。一番にあるのは、Nostrクライアントにウォレットを組み込まずに、かつ、ノードやウォレットへの接続をNostrリレーサーバ以外は挟まずに"decentralized"にしたいというところだと理解しています。

• 上記のnwcのURLはalbyのカストディアルウォレットusername@getalby.comをNostrに繋ぐもの（たぶん）
• umbrelのLNノードを繋ぐためにはやはり専用のアプリがumbrelストアに上がっている。https://github.com/getAlby/umbrel-community-app-store
• 要するにOAuthの1stPartyの役割をウォレットやノードごとにそれぞれ建てる。
• OAuthのシークレットはクライアントに保存するので設定は各クライアント毎に必要。しかし使い回しすることは可能っぽい。通常のOAuthと異なり、1stParty側で3rdPartyのドメインはトラストしていないようなので。
• Nostrクライアントにウォレットを組み込まずに、さらにウォレットやノードへの接続をNostrリレーサーバ以外には挟まなくて良いようにするために、「NIP-47 Nostr Wallet Connect」というプロポーザルが起こされていて、絶賛議論中である。https://github.com/nostr-protocol/nips/pull/406
• このWallet Connect専用のアドホックなリレーサーバが建てられる。その情報が上記画像の赤枠の「Wallet Connect Service」の下半分のpub keyやらrelayURL。どうもNostrクライアントはNIP-47イベントについてはこのリレーサーバにしか送らないようにするらしい。（なんかNostrの基本設計を揺るがすユースケースの気がする...）
• Wallet Connect専用のNostrイベントでは、ペイメント情報をNostrアカウントと切り離すために、Nostrの秘密鍵とは別の秘密鍵が利用できるようにしている。

Imagin the Future

今回取り上げたNostrクライアントにウォレット接続を組み込む話を、Webのペイメントの歴史で類推してみましょう。

Snortでやっていることは、各サイトごとにクレジットカードを打ち込み各サイトがその情報を保持していたようなWeb1.0の時代に近いです。そうなるとクレジットカードの情報は各サービスごとに漏洩リスクなどがあり、Web1.0の時代はECが普及する壁の一つになっていました。（今でもAmazonなどの大手はそうですが）

Webではその後にPayPalをはじめとして、銀行口座やクレジットカードを各サイトから切り出して一括管理し、各ウェブサイトに支払いだけを連携するサービスが出てきて一般化しています。日本ではケータイのキャリア決済が利用者の心理的障壁を取り除きEC普及の後押しになりました。

後半のNostr Wallet ConnectはそれをNostrの中でやろうとしている試みになります。クレジットカードからLNに変える理由はビットコインの話になるので詳細は割愛しますが、現実世界の金（ゴールド）に類した価値保存や交換ができるインターネットマネーだからです。

とはいえ、Nostrの中だけならまだしも、これをNostr外のサービスで利用するためには、他のECショップやブログやSaaSがNostrを喋れる必要があります。そんな未来が来るわけないだろと思うかもしれませんが、言ってみればStripeはまさにそのようなサービスとなっていて、サイト内にクレジット決済のモジュールを組み込むための主流となっています。

果たして、Nostrを、他のECショップやブログやSaaSが喋るようになるのか！？

以上、「NostrはLNがWeb統合されマネーのインターネットプロトコルとしてのビットコインが本気出す具体行動のショーケースと見做せばOK」がお送りしました。

yakihonne.com iris.to jumble.social Me

@ 57d1a264:69f1fee1

2025-05-06 05:37:29

Design can’t be effective when squeezed into a decades-old process.

When the Agile Manifesto was inked in 2001, it was supposed to spark a revolution, and it did: by 2023, 71% of US companies were using Agile. The simple list of commitments to collaboration and adaptiveness branched into frameworks such as Scrum and Kanban.

“Agile” was about having a responsive mindset, not about which process you followed, but it became about which process you followed.

Agile was designed for engineering teams but spread to whole companies. Scaled frameworks emerged to coordinate Scrum teams, with a sprawling training and certification industry. In 2022, the enterprise Agile transformation industry was predicted to reach $142 billion by 2032.

Continue reading

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

yakihonne.com iris.to jumble.social Me

@ bf47c19e:c3d2573b

2025-05-07 21:58:37

Originalni tekst na dvadesetjedan.com

Autor: Vijay Boyapati / Prevod na hrvatski: Matija

---

Sa zadnjim cijenama koje je bitcoin dosegao 2017., optimističan scenarij za ulagače se možda čini toliko očitim da ga nije potrebno niti spominjati. Alternativno, možda se nekome čini glupo ulagati u digitalnu vrijednost koja ne počiva na nijednom fizičkom dobru ili vladi i čiji porast cijene su neki usporedili sa manijom tulipana ili dot-com balonom. Nijedno nije točno; optimističan scenarij za Bitcoin je uvjerljiv, ali ne i očit. Postoje značajni rizici kod ulaganja u Bitcoin, no, kao što planiram pokazati, postoji i ogromna prilika.

Geneza

Nikad u povijesti svijeta nije bilo moguće napraviti transfer vrijednosti među fizički udaljenim ljudima bez posrednika, poput banke ili vlade. 2008. godine, anonimni Satoshi Nakamoto je objavio 8 stranica rješenja na dugo nerješivi računalski problem poznat kao “Problem Bizantskog Generala.” Njegovo rješenje i sustav koji je izgradio - Bitcoin - dozvolio je, prvi put ikad, da se vrijednost prenosi brzo i daleko, bez ikakvih posrednika ili povjerenja. Implikacije kreacije Bitcoina su toliko duboke, ekonomski i računalski, da bi Nakamoto trebao biti prva osoba nominirana za Nobelovu nagradu za ekonomiju i Turingovu nagradu.

Za ulagače, važna činjenica izuma Bitcoina (mreže i protokola) je stvaranje novog oskudnog digitalnog dobra - bitcoina (monetarne jedinice). Bitcoini su prenosivi digitalni “novčići” (tokeni), proizvedeni na Bitcoin mreži kroz proces nazvan “rudarenje” (mining). Rudarenje Bitcoina je ugrubo usporedivo sa rudarenjem zlata, uz bitnu razliku da proizvodnja bitcoina prati unaprijed osmišljeni i predvidivi raspored. Samo 21 milijun bitcoina će ikad postojati, i većina (2017., kada je ovaj tekst napisan) su već izrudareni. Svake četiri godine, količina rudarenih bitcoina se prepolovi. Produkcija novih bitcoina će potpuno prestati 2140. godine.

Stopa inflacije —— Monetarna baza

Bitcoine ne podržava nikakva roba ili dobra, niti ih garantira ikakva vlada ili firma, što postavlja očito pitanje za svakog novog bitcoin ulagača: zašto imaju uopće ikakvu vrijednost? Za razliku od dionica, obveznica, nekretnina ili robe poput nafte i žita, bitcoine nije moguće vrednovati koristeći standardne ekonomske analize ili korisnost u proizvodnji drugih dobara. Bitcoini pripadaju sasvim drugoj kategoriji dobara - monetarnih dobara, čija se vrijednost definira kroz tzv. teoriju igara; svaki sudionik na tržištu vrednuje neko dobro, onoliko koliko procjenjuje da će ga drugi sudionici vrednovati. Kako bismo bolje razumjeli ovo svojstvo monetarnih dobara, trebamo istražiti podrijetlo novca.

Podrijetlo novca

U prvim ljudskim društvima, trgovina među grupama se vršila kroz robnu razmjenu. Velika neefikasnost prisutna u robnoj razmjeni je drastično ograničavala količinu i geografski prostor na kojem je bila moguća. Jedan od najvećih problema sa robnom razmjenom je problem dvostruke podudarnosti potražnje. Uzgajivač jabuka možda želi trgovati sa ribarom, ali ako ribar ne želi jabuke u istom trenutku, razmjena se neće dogoditi. Kroz vrijeme, ljudi su razvili želju za čuvanjem određenih predmeta zbog njihove rijetkosti i simbolične vrijednosti (npr. školjke, životinjski zube, kremen). Zaista, kako i Nick Szabo govori u svojem izvrsnom eseju o podrijetlu novca, ljudska želja za sakupljanjem predmeta pružila je izraženu evolucijsku prednost ranom čovjeku nad njegovim najbližim biološkim rivalom, neandertalcem - Homo neanderthalensis.

"Primarna i najbitnija evolucijska funkcija sakupljanja bila je osigurati medij za čuvanje i prenošenje vrijednosti".

Predmeti koje su ljudi sakupljali služili su kao svojevrsni “proto-novac,” tako što su omogućavale trgovinu među antagonističkim plemenima i dozvoljavale bogatsvu da se prenosi na sljedeću generaciju. Trgovina i transfer takvih predmeta bile su rijetke u paleolitskim društvima, te su oni služili više kao “spremište vrijednosti” (store of value) nego kao “medij razmjene” (medium of exchange), što je uloga koju danas igra moderni novac. Szabo objašnjava:

"U usporedbi sa modernim novcem, primitivan novac je imao jako malo “brzinu” - mogao je promijeniti ruke samo nekoliko puta u životu prosječnog čovjeka. Svejedno, trajni i čvrsti sakupljački predmet, što bismo danas nazvali “nasljeđe,” mogao je opstati mnogo generacija, dodajući znatnu vrijednost pri svakom transferu - i zapravo omogućiti transfer uopće".

Rani čovjek suočio se sa bitnom dilemom u teoriji igara, kada je odlučivao koje predmete sakupljati: koje od njih će drugi ljudi željeti? Onaj koji bi to točno predvidio imao bi ogromnu prednost u mogućnosti trgovine i akvizicije bogatsva. Neka američka indijanska plemena, npr. Naraganseti, specijalizirala su se u proizvodnji sakupljačkih dobara koja nisu imala drugu svrhu osim trgovine. Valja spomenuti da što je ranije predviđanje da će neko dobro imati takvu vrijednost, veća je prednost koju će imati onaj koji je posjeduje, zato što ju je moguće nabaviti jeftinije, prije nego postane vrlo tražena roba i njezona vrijednost naraste zajedno sa populacijom. Nadalje, nabava nekog dobra u nadi da će u budućnosti biti korišteno kao spremište vrijednosti, ubrzava upravo tu primjenu. Ova cirkularnost je zapravo povratna veza (feedback loop) koja potiče društva da se rapidno slože oko jednog spremišta vrijednosti. U terminima teorije igara, ovo je znano kao “Nashov ekvilibrij.” Postizanje Nashovog ekvilibrija za neko spremište vrijednosti je veliko postignuće za društvo, pošto ono znatno olakšava trgovinu i podjelu rada, i time omogućava napredak civilizacije.

Tisućljećima, kako su ljudska društva rasla i otvarala trgovinske puteve, različite aplikacije spremišta vrijednosti u individualnim društvima počele su se natjecati međusobno. Trgovci su imali izbor: čuvati svoju zaradu u spremištu vrijednosti vlastite kulture, ili one kulture sa kojom su trgovali, ili mješavini oboje. Benefit štednje u stranom spremištu vrijednosti bila je uvećana sposobnost trgovanja u povezanom stranom društvu. Trgovci koji su štedili u stranom spremištu vrijednosti su također imali dobrih razloga da potiču svoje društvo da ga prihvati, jer bi tako uvećali vrijednost vlastite ušteđevine. Prednosti “uvezene” tehnologije spremanja vrijednosti bile su prisutne ne samo za trgovce, nego i za sama društva. Kada bi se dvije grupe konvergirale u jedinstvenom spremištu vrijednosti, to bi značajno smanjilo cijenu troškova trgovine jednog s drugim, i samim time povećanje bogatstva kroz trgovinu. I zaista, 19. stoljeće bilo je prvi put da je najveći dio svijeta prihvatio jedinstveno spremište vrijednosti - zlato - i u tom periodu vidio najveću eksploziju trgovine u povijesti svijeta. O ovom mirnom periodu, pisao je John Maynard Keynes:

"Kakva nevjerojatna epizoda u ekonomskom napretku čovjeka… za svakog čovjeka iole iznadprosječnog, iz srednje ili više klase, život je nudio obilje, ugodu i mogućnosti, po niskoj cijeni i bez puno problema, više nego monarsima iz prethodnih perioda. Stanovnik Londona mogao je, ispijajući jutarnji čaj iz kreveta, telefonski naručiti razne proizvode iz cijele Zemlje, u količinama koje je želio, i sa dobrim razlogom očekivati njihovu dostavu na svoj kućni prag."

Svojstva dobrog spremišta vrijednosti

Kada se spremišta vrijednosti natječu jedno s drugim, specifična svojstva rade razliku koja daje jednom prednost nad drugim. Premda su mnoga dobra u prošlosti korištena kao spremišta vrijednosti ili kao “proto-novac,” određena svojstva su se pokazala kao posebno važna, i omogućila dobrima sa njima da pobijede. Idealno spremište vrijednosti biti će:

• Trajno: dobro ne smije biti kvarljivo ili lako uništeno. Tako naprimjer, žito nije idealno spremište vrijednosti.
• Prenosivo: dobro mora biti lako transportirati i čuvati, što omogućuje osiguranje protiv gubitka ili krađe i dopušta trgovinu na velike udaljenosti. Tako, krava je lošije spremište vrijednosti od zlatne narukvice.
• Zamjenjivo: jedna jedinica dobra treba biti zamjenjiva sa drugom. Bez zamjenjivosti, problem podudarnosti želja ostaje nerješiv. Time, zlato je bolje od dijamanata, jer su oni nepravilni u obliku i kvaliteti.
• Provjerljivo: dobro mora biti lako i brzo identificirano i testirano za autentičnost. Laka provjera povećava povjerenje u trgovini i vjerojatnost da će razmjena biti dovršena.
• Djeljivo: dobro mora biti lako djeljivo na manje dijelove. Premda je ovo svojstvo bilo manje važno u ranim društvima gdje je trgovina bila rijetka, postalo je važnije sa procvatom trgovine. Količine koje su se mijenjale postale su manje i preciznije.
• Oskudno: Monetarno dobro mora imati “cijenu nemoguću za lažirati,” kao što je rekao Nick Szabo. Drugim riječima, dobro ne smije biti obilno ili lako dostupno kroz proizvodnju. Oskudnost je možda i najvažnije svojstvo spremišta vrijednosti, pošto se izravno vezuje na ljudsku želju da sakupljamo ono što je rijetko. Ona je izvor vrijednosti u spremištu vrijednosti.
• Duge povijesti: što je dulje neko dobro vrijedno za društvo, veća je vjerojatnost da će biti prihvaćeno kao spremište vrijednosti. Dugo postojeće spremište vrijednosti biti će jako teško uklonjeno od strane došljaka, osim u slučaju sile (ratno osvajanje) ili ako je nova tehnologija znatno bolja u ostalim svojstvima.
• Otporno na cenzuru: novije svojstvo, sve više važno u modernom digitalnom svijetu sa sveprisutnim nadzorom, je otpornost na cenzuru. Drugim riječima, koliko je teško da vanjski agent, kao korporacija ili država, spriječi vlasnika dobra da ga čuva i koristi. Dobra koja su otporna na cenzuru su idealna za ljude koji žive u režimima koji prisilno nadziru kapital ili čine neke oblike mirne trgovine protuzakonitima.

Ova tablica ocjenjuje Bitcoin, zlato (gold) i fiat novac (kao što je euro ili dolar) po svojstvima izlistanim gore. Objašnjenje svake ocjene slijedi nakon tablice.

Trajnost:

Zlato je neosporeni kralj trajnosti. Velika većina zlata pronađenog kroz povijest, uključujući ono egipatskih faraona, opstaje i danas i vjerojatno će postojati i za tisuću godina. Zlatnici korišteni u antičko doba imaju značajnu vrijednost i danas. Fiat valute i bitcoini su digitalni zapisi koji ponekad imaju fizički oblik (npr. novčanice). Dakle, njihovu trajnost ne određuju njihova fizička svojstva (moguće je zamijeniti staru i oštećenu novčanicu za novu), nego institucije koje stoje iza njih. U slučaju fiat valuta, mnoge države su nastale i nestale kroz stoljeća, i valute su nestale s njima. Marke iz Weimarske republike danas nemaju vrijednost zato što institucija koja ih je izdavala više ne postoji. Ako je povijest ikakav pokazatelj, ne bi bilo mudro smatrati fiat valute trajnima dugoročno; američki dolar i britanska funta su relativne anomalije u ovom pogledu. Bitcoini, zato što nemaju instituciju koja ih održava, mogu se smatrati trajnima dok god mreža koja ih osigurava postoji. Obzirom da je Bitcoin još uvijek mlada valuta, prerano je za čvrste zaključke o njegovoj trajnosti. No, postoje ohrabrujući znakovi - prominente države su ga pokušavale regulirati, hakeri ga napadali - usprkos tome, mreža nastavlja funkcionirati, pokazujući visok stupanj antifragilnosti.

Prenosivost:

Bitcoini su najprenosivije spremište vrijednosti ikad. Privatni ključevi koji predstavljaju stotine milijuna dolara mogu se spremiti na USB drive i lako ponijeti bilo gdje. Nadalje, jednako velike sume mogu se poslati na drugi kraj svijeta skoro instantno. Fiat valute, zbog svojeg temeljno digitalnog oblika, su također lako prenosive. Ali, regulacije i kontrola kapitala od strane države mogu ugroziti velike prijenose vrijednosti, ili ih usporiti danima. Gotovina se može koristiti kako bi se izbjegle kontrole kapitala, ali onda rastu rizik čuvanja i cijena transporta. Zlato, zbog svojeg fizičkog oblika i velike gustoće, je najmanje prenosivo. Nije čudo da većina zlatnika i poluga nikad ne napuste sefove. Kada se radi prijenos zlata između prodavača i kupca, uglavnom se prenosi samo ugovor o vlasništvu, ne samo fizičko zlato. Prijenos fizičkog zlata na velike udaljenosti je skupo, riskantno i sporo.

Zamjenjivost:

Zlato nam daje standard za zamjenjivost. Kada je rastopljeno, gram zlata je praktički nemoguće razlikovati od bilo kojeg drugog grama, i zlato je oduvijek bilo takvo. S druge strane, fiat valute, su zamjenjive samo onoliko koliko njihova institucija želi da budu. Iako je uglavnom slučaj da je novčanica zamjenjiva za drugu istog iznosa, postoje situacije u kojima su velike novčanice tretirane drukčije od malih. Naprimjer, vlada Indije je, u pokušaju da uništi neoporezivo sivo tržište, potpuno oduzela vrijednost novčanicama od 500 i 1000 rupija. To je uzrokovalo da ljudi manje vrednuju te novčanice u trgovini, što je značilo da više nisu bile zaista zamjenjive za manje novčanice. Bitcoini su zamjenjivi na razini mreže; svaki bitcoin je pri prijenosu tretiran kao svaki drugi. No, zato što je moguće pratiti individualne bitcoine na blockchainu, određeni bitcoin može, u teoriji, postati “prljav” zbog korštenja u ilegalnoj trgovini, te ga trgovci ili mjenjačnice možda neće htjeti prihvatiti. Bez dodatnih poboljšanja oko privatnosti i anonimnosti na razini mrežnog protokola, bitcoine ne možemo smatrati jednako zamjenjivim kao zlato.

Mogućnost provjere:

Praktično gledajući, autentičnost fiat valuta i zlata je prilično lako provjeriti. Svejedno, i usprkos pokušajima da spriječe krivotvorenje novčanica, i dalje postoji potencijal prevare za vlade i njihove građane. Zlato također nije imuno na krivotvorenje. Sofisticirani kriminalci su koristili pozlaćeni tungsten kako bi prevarili kupce zlata. Bitcoine je moguće provjeriti sa matematičkom sigurnošću. Korištenjem kriptografskih potpisa, vlasnik bitcoina može javno demonstrirati da posjeduje bitcoine koje tvrdi da posjeduje.

Djeljivost:

Bitcoine je moguće podijeliti u stotinu milijuna manjih jedinica (zvanih satoshi), i prenositi takve (no, valja uzeti u obzir ekonomičnost prijenosa malih iznosa, zbog cijene osiguravanja mreže - “network fee”). Fiat valute su tipično dovoljno djeljive na jedinice sa vrlo niskom kupovnom moći. Zlato, iako fizički i teoretski djeljivo, postaje teško za korištenje kada se podijeli na dovoljno male količine da bi se moglo koristiti u svakodnevnoj trgovini.

Oskudnost:

Svojstvo koje najjasnije razlikuje Bitcoin od fiat valuta i zlata je njegova unaprijed definirana oskudnost. Od početka, konačna količina bitcoina nikad neće biti veća od 21 milijun. To daje vlasnicima bitcoina jasan i znan uvid u postotak ukupnog vlasništva. Naprimjer, vlasnik 10 bitcoina bi znao da najviše 2,1 milijuna ljudi (manje od 0.03% populacije) može ikad imati isto bitcoina kao i on. Premda je kroz povijest uvijek bilo oskudno, zlato nije imuno na povećanje ukupne količine. Ako se ikad izumi nova, ekonomičnija metoda rudarenja ili proizvodnje zlata, ukupna količina zlata bi se mogla dramatično povećati (npr. rudarenje morskog dna ili asteroida). Na kraju, fiat valute, relativno nov izum u povijesti, pokazale su se sklonima konstantnim povećanjima u količini. Države su pokazale stalnu sklonost inflaciji monetarne kvantitete kako bi rješavale kratkoročne političke probleme. Inflacijske tendencije vlada diljem svijeta čine fiat valute gotovo sigurnim da će gubiti vrijednost kroz vrijeme.

Etablirana povijest:

Nijedno monetarno dobro nema povijest kao zlato, koje je imalo vrijednost za cijelog trajanja ljudske civilizacije. Kovanice izrađene u antičko doba i danas imaju značajnu vrijednost. Ne može se isto reći za fiat valute, koje su same relativno nova povijesna anomalija. Od njihovog početka, fiat valute su imale gotovo univerzalni smjer prema bezvrijednosti. Korištenje inflacije kao podmuklog načina za nevidljivo oporezivanje građana je vječita kušnja kojoj se skoro nijedna država u povijesti nije mogla oduprijeti. Ako je 20. stoljeće, u kojem je fiat novac dominirao globalni monetarni poredak, demonstriralo neku ekonomsku istinu, to je onda bila ta da ne možemo računati na fiat novac da održi vrijednost u dužem ili srednjem vremenskom periodu. Bitcoin, usprkos svojoj novosti, je preživio dovoljno testova tržišta da postoji velika vjerojatnost da neće nestati kao vrijedno dobro. Nadalje, Lindy efekt govori da što duže Bitcoin bude korišten, to će veća biti vjera u njega i njegovu sposobnost da nastavi postojati dugo u budućnost. Drugim riječima, društvena vjera u monetarno dobro je asimptotička, kao u grafu ispod:

Ako Bitcoin preživi prvih 20 godina, imat će gotovo sveopće povjerenje da će trajati zauvijek, kao što ljudi vjeruju da je internet trajna stvar u modernom svijetu.

Otpor na cenzuru

Jedan od najbitnijih izvora za ranu potražnju bitcoina bila je njegova upotreba u ilegalnoj kupovini i prodaji droge. Mnogi su zato pogrešno zaključili da je primarna potražnja za bitcoinima utemeljena u njihovoj prividnoj anonimnosti. Međutim, Bitcoin nije anonimna valuta; svaka transakcija na mreži je zauvijek zapisana na javnom blockchainu. Povijesni zapis transakcija dozvoljava forenzičkoj analizi da identificira izvore i tijek sredstava. Takva analiza dovela je do uhićenja počinitelja zloglasne MtGox pljačke. Premda je istina da dovoljno oprezna i pedantna osoba može sakriti svoj identitet koristeći Bitcoin, to nije razlog zašto je Bitcoin bio toliko popularan u trgovini drogom.

Ključno svojstvo koje čini Bitcoin najboljim za takve aktivnosti je njegova agnostičnost i nepotrebnost za dozvolom (“premissionlessness”) na mrežnoj razini. Kada se bitcoini prenose na Bitcoin mreži, ne postoji nitko tko dopušta transakcije. Bitcoin je distribuirana peer-to-peer (korisnik-korisniku) mreža, i samim time dizajnirana da bude otporna na cenzuru. Ovo je u velikom kontrastu sa fiat bankarskim sustavom, u kojem države reguliraju banke i ostale institucije prijenosa novca, kako bi one prijavljivale i sprječavale protuzakonito korištenje monetarnih dobara. Klasičan primjer regulacije novca su kontrole kapitala. Npr., bogati milijunaš će vrlo teško prenijeti svoje bogatstvo u novu zemlju, kada bježi iz opresivnog režima. Premda zlato nije izdano i proizvedeno od države, njegova fizička priroda ga čini teško prenosivim kroz prostor, i samim time ga je daleko lakše regulirati nego Bitcoin. Indijski Akt kontrole zlata je primjer takve regulacije.

Bitcoin je odličan u većini gore navedenih svojstava, što mu omogućava da bude marginalno bolji od modernih i drevnih monetarnih dobara, te da pruži poticaje za svoje rastuće društveno usvajanje. Specifično, moćna kombinacija otpornosti na cenzuru i apsolutne oskudnosti bila je velika motivacija za bogate ulagače koji su uložili dio svojeg bogatstva u Bitcoin.

Evolucija novca

U modernoj monetarnoj ekonomiji postoji opsesija sa ulogom novca kao medija razmjene. U 20. stoljeću, države su monopolizirale izdavanje i kontrolu novca i kontinuirano potkopavale njegovo svojstvo spremišta vrijednosti, stvarajući lažno uvjerenje da je primarna svrha novca biti medij razmjene. Mnogi su kritizirali Bitcoin, govoreći da je neprikladan da bude novac zato što mu je cijena bila previše volatilna za medij razmjene. No, novac je uvijek evoluirao kroz etape; uloga spremišta vrijednosti je dolazila prije medija razmjene. Jedan od očeva marginalističke ekonomije, William Stanley Jevons, objašnjava:

"Povijesno govoreći… čini se da je zlato prvo služilo kao luksuzni metal za ukras; drugo, kao sačuvana vrijednost; treće, kao medij razmjene; i konačno, kao mjerilo vrijednosti."

U modernoj terminologiji, novac uvijek evoluira kroz četiri stadija:

1. Kolekcionarstvo: U prvoj fazi svoje evolucije, novac je tražen samo zbog svojih posebnih svojstava, uglavnom zbog želja onog koji ga posjeduje. Školjke, perlice i zlato su bili sakupljani prije nego su poprimili poznatije uloge novca.
2. Spremište vrijednosti: Jednom kada je novac tražen od dovoljnog broja ljudi, biti će prepoznat kao način za čuvanje i spremanje vrijednosti kroz vrijeme. Kada neko dobro postane široko korišteno kao spremište vrijednosti, njegova kupovna moć raste sa povećanom potražnjom za tu svrhu. Kupovna moć spremišta vrijednosti će u jednom trenutku doći do vrhunca, kada je dovolno rašireno i broj novih ljudi koji ga potražuju splasne.
3. Sredstvo razmjene: Kada je novac potpuno etabliran kao spremište vrijednosti, njegova kupovna moć se stabilizira. Nakon toga, postane prikladno sredstvo razmjene zbog stabilnosti svoje cijene. U najranijim danima Bitcoina, mnogi ljudi nisu shvaćali koju buduću cijenu plaćaju koristeći bitcoine kao sredstvo razmjene, umjesto kao novonastalo spremište vrijednosti. Poznata priča o čovjeku koji je za 10,000 bitcoina (vrijednih oko 94 milijuna dolara kada je ovaj članak napisan) za dvije pizze ilustrira ovaj problem.
4. Jedinica računanja vrijednosti: Jednom kada je novac široko korišten kao sredstvo razmjene, dobra će biti vrednovana u njemu, tj. većina cijena će biti izražena u njemu. Uobičajena zabluda je da je većinu dobara moguće zamijeniti za bitcoine danas. Npr., premda je možda moguće kupiti šalicu kave za bitcoine, izlistana cijena nije prava bitcoin cijena; zapravo se radi o cijeni u državnoj valuti koju želi trgovac, preračunatu u bitcoin po trenutnoj tržišnoj cijeni. Kad bi cijena bitcoina pala u odnosu na valutu, vrijednost šalice izražena u bitcoinima bi se povećala. Od trenutka kada trgovci budu voljni prihvaćani bitcoine kao platežno sredstvo, bez obraćanja pažnje na vrijednost bitcoina u državnoj fiat valuti, moći ćemo reći da je Bitcoin zaista postao jedinica računanja vrijednosti.

Monetarna dobra koja još nisu jedinice računanja vrijednosti možemo smatrati “djelomično monetiziranima.” Danas zlato ima takvu ulogu, jer je spremište vrijednosti, ali su mu uloge sredstva razmjene i računanja vrijednosti oduzete intervencijama država. Moguće je također da se jedno dobro koristi kao sredstvo razmjene, dok druga ispunjavaju ostale uloge. To je tipično u zemljama gdje je država disfunkcionalna, npr. Argentina ili Zimbabwe. U svojoj knjizi, Digitalno zlato, Nathaniel Popper piše:

"U Americi, dolar služi trima funkcijama novca: nudi sredstvo razmjene, jedinicu za mjerenje vrijednosti dobara, i mjesto gdje se može čuvati vrijednosti. S druge strane, argentinski peso je korišten kao sredstvo razmjene (za svakodnevne potrebe), ali ga nitko nije koristio kao spremište vrijednosti. Štednja u pesosima bila je ekvivalent bacanja novca. Zato su ljudi svu svoju štednju imali u dolarima, jer je dolar bolje čuvao vrijednost. Zbog volatilnosti pesosa, ljudi su računali cijene u dolarima, što im je pružalo pouzdaniju jedinicu mjerenja kroz vrijeme."

Bitcoin je trenutno u fazi tranzicije iz prvog stadija monetizacije u drugi. Vjerojatno će proći nekoliko godina prije nego Bitcoin pređe iz začetaka spremišta vrijednosti u istinski medij razmjene, i put do tog trenutka je još uvijek pun rizika i nesigurnosti. Važno je napomenuti da je ista tranzicija trajala mnogo stoljeća za zlato. Nitko danas živ nije doživio monetizaciju dobra u realnom vremenu (kroz koju Bitcoin prolazi), tako da nemamo puno iskustva govoriti o putu i načinu na koji će se monetizacija dogoditi.

Put monetizacije

Kroz proces monetizacije, monetarno dobro će naglo porasti u kupovnoj moći. Mnogi su tako komentirali da je uvećanje kupovne moći Bitcoina izgledalo kao “balon” (bubble). Premda je ovaj termin često korišten kako bi ukazao na pretjeranu vrijednosti Bitcoina, sasvim slučajno je prikladan. Svojstvo koje je uobičajeno za sva monetarna dobra jest da je njihova kupovna moć viša nego što se može opravdati samo kroz njihovu uporabnu vrijednost. Zaista, mnogi povijesni novci nisu imali uporabnu vrijednost. Razliku između kupovne moći i vrijednosti razmjene koju bi novac mogao imati za svoju inherentnu korisnost, možemo razmatrati kao “monetarnu premiju.” Kako monetarno dobro prolazi kroz stadije monetizacije (navedene gore), monetarna premija raste. No, ta premija ne raste u ravnoj i predvidivoj liniji. Dobro X, koje je bilo u procesu monetizacije, može izgubiti u usporedbi sa dobrom Y koje ima više svojstava novca, te monetarna premija dobra X drastično padne ili potpuno nestane. Monetarna premija srebra je skoro potpuno nestala u kasnom 19. stoljeću, kada su ga vlade diljem svijeta zamijenile zlatom kao novcem.

Čak i u odsustvu vanjskih faktora, kao što su intervencije vlade ili druga monetarna dobra, monetarna premija novog novca neće ići predvidivim putem. Ekonomist Larry White primijetio je:

"problem sa pričom “balona,” naravno, je da je ona konzistentna sa svakim putem cijene, i time ne daje ikakvo objašnjenje za specifičan put cijene"

Proces monetizacije opisuje teorija igara; svaki akter na tržištu pokušava predvidjeti agregiranu potražnju ostalih aktera, i time buduću monetarnu premiju. Zato što je monetarna premija nevezana za inherentnu korisnost, tržišni akteri se uglavnom vode za prošlim cijenama da bi odredili je li neko dobro jeftino ili skupo, i žele li ga kupiti ili prodati. Veza trenutne potražnje sa prošlim cijenama naziva se “ovisnost o putu” (path dependence); ona je možda najveći izvor konfuzije u shvaćanju kretanja cijena monetarnih dobara.

Kada kupovna moć monetarnog dobra naraste zbog većeg i šireg korištenja, očekivanja tržišta o definicijama “jeftinog” i “skupog” se mijenjaju u skladu s time. Slično tome, kada cijena monetarnog dobra padne, očekivanja tržišta mogu se promijeniti u opće vjerovanje da su prethodne cijene bile “iracionalne” ili prenapuhane. Ovisnost o putu novca ilustrirana je riječima poznatog upravitelja fondova s Wall Streeta, Josha Browna:

"Kupio sam bitcoine kada su koštali $2300, i to mi se udvostručilo gotovo odmah. Onda sam počeo govoriti kako “ne mogu kupiti još” dok im je cijena rasla, premda sam znao da je to razmišljanje bazirano samo na cijenu po kojoj sam ih kupio. Kasnije, kada je cijena pala zbog kineske regulacije mjenjačnica, počeo sam si govoriti, “Odlično, nadam se da će još pasti da mogu kupiti još.”"

Istina leži u tome da su ideje “jeftinog” i “skupog” zapravo besmislene kada govorimo o monetarnim dobrima. Cijena monetarnog dobra ne reflektira njegovu stopu rasprostanjenosti ili korisnosti, nego mjeru koliko je ono široko prihvaćeno da ispuni razne uloge novca.

Dodatna komplikacija u ovom aspektu novca je činjenica da tržišni akteri ne djeluju samo kao nepristrani promatrači koji pokušavaju kupiti i prodati u iščekivanju budućih kretanja monetarne premije, nego i kao aktivni proponenti. Pošto ne postoji objektivno “točna” monetarna premija, širiti dobar glas o superiornijim svojstvima nekog monetarnog dobra je efektivnije nego za obična dobra, čija vrijednost je u konačnici vezana na njegovu osnovnu korisnost. Religiozni zanos sudionika na Bitcoin tržištu vidljiv je na raznim internetskim forumima, gdje Bitcoineri aktivno promoviraju benefine Bitcoina i bogatstvo koje je moguće ostvariti investiranjem u njega. Promatrajući Bitcoin tržište, Leigh Drogen komentira:

"To je prepoznatljivo svima kao religija - priča koju si pričamo i oko koje se slažemo. Religija je krivulja na grafu prihvaćanja o kojoj trebamo razmišljati. Sustav je gotovo savršen - onog trenutka kada netko pristupi krugu Bitcoinera, to će reći svima i nastaviti širiti riječ. Onda njihovi prijatelji pristupe i nastave širiti riječ."

Premda usporedba sa religijom može staviti Bitcoin u iracionalno svjetlo, potpuno je racionalno za individualnog vlasnika da širi dobru vijest o superiornom monetarnom dobru, i za šire društvo da se standardizira oko njega. Novac djeluje kao temelj za svu trgovinu i štednju; tako da prihvaćanje superiornog oblika novca ima ogromne multiplicirajuće benefite za stvaranje bogatstva za sve članove društva.

Oblik monetizacije

U članku o Spekulativnom prihvaćanju Bitcoina / teorije cijene, Michael Casey postulira da rastući Gartner hype ciklusi predstavljaju faze standardne S-krivulje prihvaćanja novih tehnologija, koje su bile prisutne kod mnogih transformacijskih tehnologija dok su postajale uobičajene u društvu.

Svaki Gartner hype ciklus počinje sa eksplozijom entuzijazma za novom tehnologijom, a cijenu podižu oni sudionici na tržištvu koji su “dostupni” u toj fazi. Najraniji kupci u Gartner hype ciklusu obično imaju jaku vjeru o transformacijskoj prirodi tehnologije u koju ulažu. S vremenom, tržište dosegne vrhunac entuzijazma kako se količina novih kupaca iscrpljuje, te kupovinom počnu dominirati spekulatori koji su više zainteresirani u brze profite nego u samu tehnologiju.

Nakon vrha hype ciklusa, cijene rapidno padaju dok spekulativno ludilo ustupa mjesto očajavanju, javnoj poruzi i osjećaju da tehnologija nije uopće bila transformacijska. S vremenom, cijena dosegne dno i formira plato na kojem se originalnim ulagačima, koji su imali snažno uvjerenje, pridružuju nove grupe ljudi koji su izdržali bol kraha cijena i koji cijene važnost same tehnologije.

Plato traje neko vrijeme i formira, kako Casey kaže, “stabilnu, dosadnu dolinu.” Za ovo vrijeme, javni interes za tehnologiju opada, no nastaviti će se razvijati i snažna zajednica uvjerenja će polako rasti. Tada, postavlja se nova baza za sljedeću iteraciju hype ciklusa, dok vanjski promatrači prepoznaju da tehnologija i dalje postoji i da ulaganje u nju možda nije onoliko rizično kao što se činilo za vrijeme pada cijene. Sljedeća iteracija hype ciklusa donosi mnogo veći broj novih ljudi, pa je i ciklus daleko veći u svojoj magnitudi.

Jako mali broj ljudi koji sudjeluju u Gartner hype ciklusu će točno predvidjeti koliko će visoko cijena porasti za vrijeme ciklusa. Cijene često dosegnu razine koje bi se činile apsurdnima većini ulagača u raniji stadijima ciklusa. Kada ciklus završi, mediji tipično atribuiraju pad cijene nekoj od aktualnih drušvenih tema. Premda takva tema može biti okidač pada, ona nikad nije temeljni razlog zašto ciklus završava. Gartner hype ciklusi završavaju kada je količina dostupnih novih sudionika na tržištu iscrpljena.

Zanimljivo je da je i zlato nacrtalo klasičan graf Gartner hype ciklusa od kasnih 1970-ih do ranih 2000-ih. Moguće je spekulirati da je hype ciklus osnovna socijalna dinamika oko procesa monetizacije.

Gartner kohorte

Od početka trgovanja Bitcoina na mjenjačnicama 2010. godine, Bitcoin tržište je svjedočilo četirima velikim Gartner hype ciklusima. U retrospektivi, možemo vrlo precizno identificirati grupe cijena prethodnih hype ciklusa Bitcoin tržišta. Također, možemo kvalitativno odrediti kohorte ulagača koje su povezane sa svakom iteracijom prethodnih ciklusa.

$0–$1 (2009. – 3. mjesec 2011.): Prvi hype ciklus u Bitcoin tržištu dominirali su kriptografi, računalni znanstvenici i cypherpunkovi koji su od početka bili spremni razumijeti važnost nevjerojatnog izuma Satoshija Nakamotoa, i koji su bili pioniri u potvrđivanju da Bitcoin protokol nema tehničkih mana.

$1–$30 (3. mjesec 2011. – 7. mjesec. 2011.): Drugi ciklus privukao je rane entuzijaste oko novih tehnologija kao i stabilan pritok ideološki motiviranih ulagača koji su bili oduševljeni idejom novca odvojenog od države. Libertarijanci poput Rogera Vera došli su u Bitcoin zbog aktivnog anti-institucionalnog stava, i mogućnosti koju je nova tehnologija obećavala. Wences Casares, briljantni i dobro povezani serijski poduzetnik, bio je također dio drugog Bitcoin hype ciklusa te je širio riječ o Bitcoinu među najprominentnijim tehnolozima i ulagačima u Silicijskoj Dolini.

$250–$1100 (4. mjesec 2013. – 12. mjesec 2013.): Treći hype ciklus doživio je ulazak ranih generalnih i institucionalnih ulagača koji su bili voljni uložiti trud i riskirati kroz užasno komplicirane kanale likvidnosti kako bi kupili bitcoine. Primaran izvor likvidnosti na tržištu za vrijeme ovog perioda bio je MtGox, mjenjačnica bazirana u Japanu, koju je vodio notorno nesposobni i beskrupulozni Mark Karpeles, koji je kasnije završio i u zatvoru zbog svoje uloge u kolapsu MtGoxa.

Valja primijetiti da je rast Bitcoinove cijene za vrijeme spomenuti hype ciklusa većinom povezano sa povećanjem likvidnosti i lakoćom sa kojom su ulagači mogli kupiti bitcoine. Za vrijeme prvog hype ciklusa, nisu postojale mjenjačnice; akvizicija bitcoina se odvijala primarno kroz rudarenje (mining) ili kroz izravnu razmjenu sa onima koju su već izrudarili bitcoine. Za vrijeme drugog hype ciklusa, pojavile su se rudimentarne mjenjačnice, no nabavljanje i osiguravanje bitcoina na ovim mjenjačnicama bilo je previše kompleksno za sve osim tehnološki najsposobnijih ulagača. Čak i za vrijeme trećeg hype ciklusa, ulagači koju su slali novac na MtGox kako bi kupili bitcoine su morali raditi kroz značajne prepreke. Banke nisu bile voljne imati posla sa mjenjačnicom, a oni posrednici koji su nudili usluge transfera bili su često nesposobni, kriminalni, ili oboje. Nadalje, mnogi koji su uspjeli poslati novac MtGoxu, u konačnici su morali prihvatiti gubitak svojih sredstava kada je mjenjačnica hakirana i kasnije zatvorena.

Tek nakon kolapsa MtGox mjenjačnice i dvogodišnje pauze u tržišnoj cijeni Bitcoina, razvili su se zreli i duboki izvori likvidnosti; primjeri poput reguliranih mjenjačnica kao što su GDAX i OTC brokeri kao Cumberland mining. Dok je četvrti hype ciklus započeo 2016. godine, bilo je relativno lako običnim ulagačima kupiti i osigurati bitcoine.

$1100–$19600? (2014. –?):

U trenutku pisanja ovog teksta, tržište Bitcoina je prolazilo svoj četvrti veliki hype ciklus. Sudjelovanje u ovom hype ciklusu dominirala je ona skupina koju je Michael Casey opisao kao “rana većina” običnih i institucionalnih ulagača.

Kako su se izvori likvidnosti produbljivali i sazrijevali, veliki institucionalni ulagači sada imaju priliku sudjelovati kroz regulirana “futures” tržišta. Dostupnosti takvih tržišta stvara put ka kreaciji Bitcoin ETF-a (exchange traded fund) (fond na slobodnom tržištu), koji će onda pokrenuti “kasnu većinu” i “najsporije” u sljedećim hype ciklusima.

Premda je nemoguće predvidjeti točan efekt budućih hype ciklusa, razumno je očekivati da će najviša točka biti između $20,000 i $50,000 (2021. zenit je bio preko $69,000). Znatno više od ovog raspona, i Bitcoin bi imao znatan postotak ukupne vijednosti zlata (zlato i Bitcoin bi imali jednaku tržišnu kapitalizaciju kada bi bitcoini vrijedili oko $380,000 u trenutku pisanja ovog teksta). Značajan postotak vrijednosti zlata dolazi od potražnje centralnih banaka, te je malo vjerojatno da će centralne banke ili suverene države sudjelovati u trenutnom hype ciklusu.

Ulazak suverenih država u Bitcoin

Bitcoinov zadnji Gartner hype ciklus će započeti kada ga suverene države počnu akumulirati kao dio svojih rezervi stranih valuta. Tržišna kapitalizacija Bitcoina je trenutno premala da bismo ga smatrali značajnim dodatkom rezervama većini zemalja. No, kako se interes u privatnom sektoru povećava i kapitalizacija Bitcoina se približi trilijunu dolara, postat će dovoljno likvidan za većinu država. Prva država koja službeno doda bitcoine u svoje rezerve će vjerojatno potaknuti stampedo ostalih da učine isto. Države koje su među prvima u usvajanju Bitcoina imat će najviše benefita u svojim knjigama ako Bitcoin u konačnici postane globalna valuta (global reserve currency). Nažalost, vjerojatno će države sa najjačom izvršnom vlasti - diktature poput Sjeverne Koreje - biti najbrže u akumulaciji bitcoina. Neodobravanje prema takvim državama i slaba izvršna tijela zapadnjačkih demokracija uzrokovat će sporost i kašnjenje u akumulaciji bitcoina za njihove vlastite rezerve.

Velika je ironija u tome što je SAD trenutno jedna od regulatorno najotvorenijih nacija prema Bitcoinu, dok su Kina i Rusija najzatvorenije. SAD riskira najviše, geopolitički, ako bi Bitcoin zamijenio dolar kao svjetska rezervna valuta. U 1960-ima, Charles de Gaulle je kritizirao “pretjeranu privilegiju” (“exorbitant privilege”) koju su SAD imale u međunarodnom monetarnom poretku, postavljenom kroz Bretton Woods dogovor 1944. godine. Ruska i kineska vlada još ne shvaćaju geo-strateške benefite Bitcoina kao rezervne valute, te se trenutno brinu o efektima koje bi mogao imati na njihova unutarnja tržišta. Kao de Gaulle u 1960-ima, koji je prijetio SAD-u povratkom na klasični standard zlata, Kinezi i Rusi će s vremenom uvidjeti korist u velikoj poziciji u Bitcoinu - spremištu vrijednosti bez pokrića ijedne vlade. Sa najvećom koncentracijom rudara Bitcoina u Kini (2017.), kineska vlada već ima znatnu potencijalnu prednost u stavljanju bitcoina u svoje rezerve.

SAD se ponosi svojim statusom nacije inovatora, sa Silicijskom dolinom kao krunom svoje ekonomije. Dosad, Silicijska dolina je dominirala konverzacijom usmjerenom prema regulaciji, i poziciji koju bi ona treba zauzeti prema Bitcoinu. No, bankovna industrija i federalna rezerva SAD-a (US Federal Reserve, Fed) napokon počinju uviđati egzistencijalnu prijetnju koju Bitcoin predstavlja za američku monetarnu politiku, postankom globalne rezervne valute. Wall Street Journal, jedan od medijskih glasova federalne reserve, izdao je komentar o Bitcoinu kao prijetnji monetarnoj politici SAD-a:

"Postoji još jedna opasnost, možda i ozbiljnija iz perspektive centralnih banaka i regulatora: bitcoin možda ne propadne. Ako je spekulativni žar u kriptovalutu samo prvi pokazatelj njezinog šireg korištenja kao alternative dolaru, Bitcoin će svakako ugroziti monopol centralnih banaka nad novcem."

U narednim godinama, možemo očekivati veliku borbu između poduzetnika i inovatora u Silicijskoj dolini, koji će pokušavati čuvati Bitcoin od državne kontrole s jedne strane, i bankovne industrije i centralnih banaka koje će učiniti sve što mogu da bi regulirale Bitcoin kako bi spriječile znatne promjene u svojoj industriji i moći izdavanja novca, s druge.

Prijelaz na medij razmjene

Monetarno dobro ne može postati opće prihvaćen medij razmjene (standardna ekonomska definicija za “novac”) prije nego je vrednovano od širokog spektra ljudi; jednostavno, dobro koje nije vrednovano neće biti prihvaćeno u razmjeni. Kroz proces generalnog rasta vrijednosti, i time postanka spremišta vrijednosti, monetarno dobro će brzo narasti u kupovnoj moći, i time stvoriti cijenu za korištenje u razmjeni. Samo kada ta cijena rizika mijenjanja spremišta vrijednosti padne dovoljno nisko, može dobro postati opće prihvaćen medij razmjene.

Preciznije, monetarno dobro će biti prikladno kao medij razmjene samo kada je suma cijene rizika i transakcijske cijene u razmjeni manja nego u trgovini bez tog dobra.

U društvu koje vrši robnu razmjenu, prijelaz spremišta vrijednosti u medij razmjene može se dogoditi čak i onda kada monetarno dobro raste u kupovnoj moći, zato što su transakcijski troškovi robne razmjene iznimno visoki. U razvijenoj ekonomiji, u kojoj su troškovi razmjene niski, moguće je za mladu i rapidno rastućnu tehnologiju spremišta vrijednosti, poput Bitcoina, da se koristi kao medij razmjene, doduše na ograničen način. Jedan primjer je ilegalno tržište droge, gdje su kupci voljni žrtvovati oportunu cijenu čuvanja bitcoina kako bi umanjili znatan rizik kupovine droge koristeći fiat novac.

Postoje međutim velike institucionalne barijere da novonastalo spremište vrijednosti postane sveopće prihvaćen medij razmjene u razvijenom društvu. Države koriste oporezivanje kao moćnu metodu zaštite svojeg suverenog novca protiv rivalskih monetarnih dobara. Ne samo da suvereni novac ima prednost konstantnog izvora potražnje, zato što je porez moguće platiti jedino u njemu, nego su i rivalska monetarna dobra oporezana pri svakoj razmjeni za vrijeme rastuće cijene. Ova metoda oporezivanja stvara znatan otpor korištenju spremišta vrijednosti kao medija razmjene.

Ovakvo sabotiranje tržišnih monetarnih dobara nije nepremostiva barijera za njihovo prihvaćanje kao općeg medija razmjene. Ako ljudi izgube vjeru u suvereni novac, njegova vrijednost može rapidno propasti kroz proces zvan hiperinflacija. Kada suvereni novac prolazi kroz hiperinflaciju, njegova vrijednost propadne prvo u usporedbi sa najlikvidnijim dobrima u društvu, kao što je zlato ili stabilna strana valuta (američki dolar npr.), ako su ona dostupna. Kada nema likvidnih dobara ili ih ima premalo, novac u hiperinflaciji kolabira u usporedbi sa stvarnim dobrima, kao što su nekretnine ili upotrebljiva roba. Arhetipska slika hiperinflacije je trgovina sa praznim policama - potrošači brzo bježe iz propadajuće vrijednosti novca svoje nacije.

Nakon dovoljno vremena, kada je vjera potpuno uništena za vrijeme hiperinflacije, suvereni novac više nitko ne prihvaća, te se društvo može vratiti na robnu razmjenu, ili će doživjeti potpunu zamjenu monetarne jedinice za sredstvo razmjene. Primjer ovog procesa bila je zamjena zimbabveanskog dolara za američki dolar. Takva promjena suverenog novca za stranu valutu je dodatno otežana relativnom oskudnošću strane valute i odsustvom stranih bankarskih institucija koje pružaju likvidnost tržištu.

Sposobnost lakog prenošenja bitcoina preko granica i odsustvo potrebe za bankarskim sustavom čine Bitcoin idealnim monetarnim dobrom za one ljude koji pate pod hiperinflacijom. U nadolazećim godinama, kako fiat valute nastave svoj povijesni trend ka bezvrijednosti, Bitcoin će postati sve popularniji izbor za ušteđevine ljudi diljem svijeta. Kada je novac nacije napušten i zamijenjen Bitcoinom, Bitcoin će napraviti tranziciju iz spremišta vrijednosti u tom društvu u opće prihvaćeno sredstvo razmjene. Daniel Krawicz stvorio je termin “hiperbitcoinizacija” da bi opisao ovaj proces.

Učestala pogrešna shvaćanja

Većina ovog članka usredotočila se na monetarnu prirodu Bitcoina. Sa tim temeljima možemo adresirati neke od najčešćih nerazumijevanja u Bitcoinu.

Bitcoin je balon (bubble)

Bitcoin, kao sva tržišna monetarna dobra, posjeduje monetarnu premiju. Ona često rezultira uobičajenom kritikom da je Bitcoin samo “balon.” No, sva monetarna dobra imaju monetarnu premiju. Naprotiv, ta monetarna premija (cijena viša od one koju diktira potražnja za dobrom kao korisnim) je upravo karakteristična za sve oblike novca. Drugim riječima, novac je uvijek i svuda balon. Paradoksalno, monetarno dobro je istovremeno balon i ispod vrijednosti ukoliko je u ranijim stadijima općeg prihvaćanja kao novac.

Bitcoin je previše volatilan

Volatilnost cijene Bitcoina je funkcija njegovog nedavnog nastanka. U prvih nekoliko godina svojeg postojanja, Bitcoin se ponašao kao mala dionica, i svaki veliki kupac - kao npr. braća Winklevoss - mogao je uzrokovati veliki skok u njegovoj cijeni. No, kako su se prihvaćenost i likvidnost povećavali kroz godine, volatilnost Bitcoina je srazmjerno smanjila. Kada Bitcoin postigne tržišnu kapitalizaciju (vrijednost) zlata, imat će sličnu volatilnost kao i zlato. Kako Bitcoin nastavi rasti, njegova volatilnost će se smanjiti do razine koja ga čini prikladnim za široko korištenje kao medij razmjene. Kao što je prethodno rečeno, monetizacija Bitcoina se odvija u seriji Gartner hype ciklusa. Volatilnost je najniža za vrijeme vrhunaca i dolina unutar ciklusa. Svaki hype ciklus ima nižu volatilnost od prethodnih, zato što je likvidnost tržišta veća.

Cijene transakcija su previsoke

Novija kritika Bitcoin mreže je ta da ju je povećanje cijena prijenosa bitcoina učinilo neprikladnom za sustav plaćanja. No, rast u cijenama transakcija je zdrav i očekivan. One su nužne za plaćanje bitcoin minera (rudara), koji osiguravaju mrežu validacijom transakcija. Rudare se plaća kroz cijene transakcija ili kroz blok-nagrade, koje su inflacijska subvencija od trane trenutnih vlasnika bitcoina.

S obzirom na Bitcoinovu fiksnu proizvodnju (monetarna politika koja ga čini idealnim za spremanje vrijednosti), blok-nagrade će s vremenom nestati i mrežu će se u konačnici morati osiguravati kroz cijene transakcija. Mreža sa “niskim” cijenama transakcija je mreža sa slabom sigurnosti i osjetljiva na vanjsku intervenciju i cenzuru. Oni koji hvale niske cijene Bitcoinovih alternative zapravo niti ne znajući opisuju slabosti tih takozvanih “alt-coina.”

Površan temelj kritika Bitcoinovih “visokih” cijena transakcija je uvjerenje da bi Bitcoin trebao biti prvo sustav plaćanja, i drugo spremište vrijednosti. Kao što smo vidjeli kroz povijest novca, ovo uvjerenje je naopako. Samo onda kada Bitcoin postane duboko ukorijenjeno spremište novca može biti prikladan kao sredstvo razmjene. Nadalje, kada oportunitetni trošak razmjene bitcoina dođe na razinu koja ga čini prikladnim sredstvom razmjene, većina trgovine neće se odvijati na samoj Bitcoin mreži, nego na mrežama “drugog sloja” (second layer) koje će imati niže cijene transakcija. Takve mreže, poput Lightning mreže, služe kao moderna verzija zadužnica koje su korištene za prijenos vlasničkih papira zlata u 19. stoljeću. Banke su koristile zadužnice zato što je prijenos samog metala bio daleko skuplji. Za razliku od takvih zadužnica, Lightning mreža će omogućavati nisku cijenu prijenosa bitcoina bez potrebe za povjerenjem prema trećoj strani, poput banaka. Razvoj Lightning mreže je tehnološka inovacija od izuzetne važnosti u povijesti Bitcoina, i njezina vrijednost će postati očita u narednim godinama, kako je sve više ljudi bude razvijalo i koristilo.

Konkurencija

Pošto je Bitcoin softverski protokol otvorenog tipa (open-source), oduvijek je bilo moguće kopirati softver i imitirati mrežu. Kroz godine nastajali su mnogi imitatori, od identičnih kopija, kao Litecoin, do kompleksnijih varijanti kao što je Ethereum, koje obećavaju arbitrarno kompleksne ugovorne mehanizme koristeći decentralizirani računalni sustav. Česta kritika Bitcoinu od strane ulagača je ta da on ne može zadržati svoju vrijednost kada je vrlo lako stvoriti konkurente koji mogu lako i brzo u sebi imati najnovije inovacije i softverske funkcionalnosti.

Greška u ovom argumentu leži u manju takozvanog “mrežnog efekta” (network effect), koji postoji u prvoj i dominantnoj tehnologiji u nekom području. Mrežni efekt - velika vrijednost korištenja Bitcoina samo zato što je već dominantan - je važno svojstvo samo po sebi. Za svaku tehnologiju koja posjeduje mrežni efekt, to je daleko najvažnije svojstvo koje može imati.

Za Bitcoin, mrežni efekt uključuje likvidnost njegovog tržišta, broj ljudi koji ga posjeduju, i zajednicu programera koji održavaju i unaprjeđuju njegov softver i svjesnost u javnosti. Veliki ulagači, uključujući države, će uvijek prvo tražiti najlikvidnije tržište, kako bi mogli ući i izaći iz tržišta brzo, i bez utjecanja na cijenu. Programeri će se pridružiti dominantnoj programerskoj zajednici sa najboljim talentom, i time pojačati samu zajednicu. Svjesnost o brendu sama sebe pojačava, pošto se nadobudni konkurenti Bitcoina uvijek spominju u kontekstu Bitcoina kao takvog.

Raskrižje na putu (fork)

Trend koji je postao popularan 2017. godine nije bio samo imitacija Bitcoinovog softvera, nego kopiranje potpune povijesti njegovih prošlih transakcija (cijeli blockchain). Kopiranjem Bitcoinovog blockchaina do određene točke/bloka i odvajanjem sljedećih blokova ka novoj mreži, u procesu znanom kao “forking” (odvajanje), Bitcoinovi konkurenti su uspjeli riješiti problem distribuiranja svojeg tokena velikom broju korisnika.

Najznačajniji takav fork dogodio se 1. 8. 2017. godine, kada je nova mreža nazvana Bitcoin Cash (Bcash) stvorena. Vlasnik N količine bitcoina prije 1.8.2017. bi onda posjedovao N bitcoina i N BCash tokena. Mala, ali vrlo glasna zajednica Bcash proponenata je neumorno pokušavala prisvojiti Bitcoinov brend i ime, imenujući svoju novu mrežu Bitcoin Cast i pokušavajući uvjeriti nove pridošlice u Bitcoin da je Bcash “pravi” Bitcoin. Ti pokušaji su većinom propali, i taj neuspjeh se vidi u tržišnim kapitalizacijama dviju mreža. No, za nove ulagače, i dalje postoji rizik da bi konkurent mogao kopirati Bitcoin i njegov blockchain i tako uspjeti u preuzimanju tržišne kapitalizacije, te postati de facto Bitcoin.

Moguće je uočiti važno pravilo gledajući velike forkove u prošlosti Bitcoin i Ethereum mreža. Većina tržišne kapitalizacije odvijat će se na mreži koja zadrži najviši stupanj talenta i aktivnosti u zajednici programera. Premda se na Bitcoin može gledati kao na nov i mlad novac, on je također računalna mreža koja počiva na softveru, kojeg se pak treba održavati i poboljšavati. Kupovina tokena na mreži koja ima malo neiskusnih programera bilo bi kao kupovati kopiju Microsoft Windowsa na kojoj rade lošiji programeri. Jasno je vidljivo iz povijesti forkova koji su se odvili 2017. godine da su najbolji računalni i kriptografski stručnjaci posvećeni razvoju originalnog Bitcoina, a ne nekoj od rastućeg broja imitacija koje su se izrodile iz njega.

Stvarni rizici

Premda su uobičajene kritike upućene Bitconu od strane medija i ekonomske profesije krive i bazirane na netočnom shvaćanju novca, postoje pravi i značajni rizici kod ulaganja u Bitcoin. Bilo bi mudro za novog Bitcoin ulagača da shvati ove rizike prije potencijalnog ulaganja.

Rizik protokola

Bitcoin protokol i kriptografski sastavni dijelovi na kojima je sagrađen potencijalno imaju dosad nepronađenu grešku u svom dizajnu, ili mogu postati nesigurni razvojem kvantnih računala. Ako se pronađe greška u protokolu, ili neka nova metoda računarstva učini mogućim probijanje kriptografskih temelja Bitcoina, vjera u Bitcoin biti će znatno narušena. Rizik protokola bio je najviši u ranim godinama razvoja Bitcoina, kada je još uvijek bilo nejasno, čak i iskusnim kriptografima, je li Satoshi Nakamoto zaista riješio problem bizantskih generala (Byzantine Generals’ Problem). Brige oko ozbiljnih grešaka u Bitcoin protokolu nestale su kroz godine, no uzevši u obzir njegovu tehnološku prirodu, rizik protokola će uvijek ostati u Bitcoinu, makar i kao izuzetak.

Propadanje mjenjačnica

Time što je decentraliziran, Bitcoin je pokazao značajnu otpornost, suočen sa brojnim pokušajima raznih vlada da ga reguliraju ili unište. No, mjenjačnice koje trguju bitcoinima za fiat valute su centralizirani entiteti i podložne regulacijama i zatvaranju. Bez mjenjačnica i volje bankara da s njima posluju, proces monetizacije Bitcoina bio bi ozbiljno usporen, ako ne i potpuno zaustavljen. Iako postoje alternativni izvori likvidnosti za Bitcoin, poput “over-the-counter” brokera i decentraliziranih tržišta za kupovinu i prodaju bitcoina, kritičan proces otkrivanja i definiranja cijene se odvija na najlikvidnijim mjenjačnicama, koje su sve centralizirane.

Jedan od načina za umanjivanje rizika gašenja mjenjačnica je geografska arbitraža. Binance, jedna od velikih mjenjačnica iz Kine, preselila se u Japan nakon što joj je kineska vlada zabranila operiranje u Kini. Vlade su također oprezne kako ne bi ugušile novu industriju koja je potencijalno značajna kao i internet, i time predale nevjerojatnu konkurentnu vrijednost drugim nacijama.

Samo kroz koordinirano globalno ukidanje Bitcoin mjenjačnica bi proces monetizacije mogao biti zaustavljen. Trenutno smo u utrci; Bitcoin raste i postaje sve rašireniji, i doći će do trenutka kada bi potpuno ukidanje mjenjačnica postalo politički neizvedivo - kao i gašenje interneta. Mogućnost takvog ukidanja je još uvijek realna, i valja je uzeti u obzir pri ulaganju u Bitcoin. Kao što je gore objašnjeno, suverene vlade se polako bude i uviđaju prijetnju koju predstavlja neovisna digitalna valuta otporna na cenzuru, za njihovu monetarnu politiku. Otvoreno je pitanje hoće li išta poduzeti da odgovore ovoj prijetnji prije nego Bitcoin postane toliko utvrđen i raširen da politička akcija postane nemoćna i ne-efektivna.

Zamjenjivost

Otvorena i transparentna priroda Bitcoin blockchaina omogućava državama da proglase specifične bitcoine “okaljanima” zbog njihovog korištenja u određenim aktivnostima. Premda Bitcoin, na protokolarnoj razini, ne diskriminira transakcije na ikoji način, “okaljani” bitcoini bi mogli postati bezvrijedni ako bi ih regulacije proglasile ilegalnima i neprihvatljivima za mjenjačnice ili trgovce. Bitcoin bi tada izgubio jedno od kritičnih svojstava monetarnog dobra: zamjenjivost.

Da bi se ovaj problem riješio i umanjio, biti će potrebna poboljšanja na razini protokola kako bi se poboljšala privatnost transakcija. Premda postoji napredak u ovom smjeru, prvi put primjenjen u digitalnim valutama kao što su Monero i Zcash, potrebno je napraviti značajne tehnološke kompromise između efikasnosti i kompleksnosti Bitcoina i njegove privatnosti. Pitanje ostaje otvoreno je li moguće dodati nova svojstva privatnosti na Bitcoin, na način koji neće kompromitirati njegovu korisnost kao novca.

Zaključak

Bitcoin je novonastali novac koji je u procesu transformacije iz sakupljačkog dobra u spremište vrijednosti. Kao neovisno monetarno dobro, moguće je da će u budućnosti postati globalan novac, slično kao zlato za vrijeme 19. stoljeća. Prihvaćanje Bitcoina kao globalnog novca je upravo taj optimističan scenarij za Bitcoin, kojeg je artikulirao Satoshi Nakamoto još 2010. godine u email razmjeni sa Mikeom Hearnom:

"Ako zamisliš da se koristi u nekom dijelu svjetske trgovine, i da će postojati samo 21 milijun bitcoina za cijeli svijet, vrijednost po jedinici će biti znatno veća".

Ovaj scenarij je još snažnije definirao briljantni kriptograf Hal Finney, koji je ujedno primio i prve bitcoine od Nakamotoa, ubrzo nakon najave prvog funkcionalnog Bitcoin softvera:

"Zamislimo da Bitcoin bude uspješan i postane dominantan sustav plaćanja diljem svijeta. U tom slučaju će ukupna vrijednost valute biti jednaka ukupnoj vrijednosti svog bogatstva svijeta. Današnje procjene ukupnog svjetskog bogatska kućanstava koje sam pronašao borave negdje između 100 i 300 trilijuna dolara. Sa 20 milijuna bitcoina, svaki bi onda vrijedio oko 10 milijuna dolara."

Čak i da Bitcoin ne postane u cijelost globalan novac, nego da se samo natječe sa zlatom kao neovisno spremište vrijednosti, i dalje je masivno podcijenjen. Mapiranje tržišne kapitalizacije postojeće količine izrudarenog zlata (oko 8 trilijuna dolara) na maksimalnu dostupnost Bitcoina od 21 milijun, daje vrijednost od otprilike 380,000 dolara po bitcoinu. Kao što smo vidjeli u prethodnom tekstu, svojstva koja omogućavaju monetarnom dobru da bude prikladno spremište vrijednosti, čine Bitcoin superiornijim zlatu u svakom pogledu osim trajanja povijesti. No, kako vrijeme prolazi i Lindy efekt postane jači, dosadašnja povijest će prestati biti prednost zlata. Samim time, nije nerazumno očekivati da će Bitcoin narasti do, a možda i preko, ukupne cijene zlata na tržištvu do 2030. Opaska ovoj tezi je činjenica da veliki postotak vrijednosti zlata dolazi od toga što ga centralne banke čuvaju kao spremište vrijednosti. Da bi Bitcoin došao do te razine, određena količina suverenih država će trebati sudjelovati. Hoće li zapadnjačke demokracije sudjelovati u vlasništvu Bitcoina je nepoznato. Vjerojatnije je, nažalost, da će prve nacije u Bitcoin tržištu biti sitne diktature i kleptokracije.

Ako niti jedna država ne bude sudjelovala u Bitcoin tržištu, optimistična teza i dalje postoji. Kao nevisno spremište vrijednosti u rukama individualnih i institucionalnih ulagača, Bitcoin je i dalje vrlo rano u svojoj “krivulji prihvaćenosti” (adoption curve); tzv. “rana većina” ulaze na tržište sada, dok će ostali ući tek nekoliko godina kasnije. Sa širim sudjelovanjem individualnih i institucionalnih ulagača, cijena po bitcoinu između 100,000 i 200,000 dolara je sasvim moguća.

Posjedovanje bitcoina je jedna od malobrojnih asimetričnih novčanih strategija dostupnih svakome na svijetu. Poput “call” opcija, negativan rizik ulagača je ograničen na 1x, dok potencijalna dobit i dalje iznosi 100x ili više. Bitcoin je prvi istinski globalan balon čija je veličina ograničena samo potražnjom i željom građana svijeta da zaštite svoju ušteđevinu od raznovrsnih ekonomskih malverzacija vlade. Bitcoin je ustao kao feniks iz pepela globalne financijske krize 2008. godine - katastrofe kojoj su prethodile odluke centralnih banaka poput američke Federalne rezerve (Federal Reserve).

Onkraj samo financijske teze za Bitcoin, njegov rast i uspjeh kao neovisno spremište vrijednosti imat će duboke geopolitičke posljedice. Globalna, ne-inflacijska valuta će prisiliti suverene države da promjene svoje primarne mehanizme financiranja od inflacije u izravno oporezivanje; koje je daleko manje politički popularno. Države će se smanjivati proporcionalno političkoj boli koju im nanese oporezivanje kao jedini način financiranja. Nadalje, globalna trgovina vršiti će se na način koji zadovoljava aspiraciju Charlesa de Gaullea, da nijedna nacija ne bi smjela imati privilegiju nad ikojom drugom:

"Smatramo da je potrebno da se uspostavi međunarodna trgovina, kao što je bio slučaj prije velikih nesreća koje su zadesile svijet, na neosporivoj monetarnoj bazi, koja ne nosi na sebi oznaku ijedne države."

Za 50 godina, ta monetarna baza biti će Bitcoin.

yakihonne.com iris.to jumble.social Me

@ 1bda7e1f:bb97c4d9

2025-03-26 03:23:00

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.

yakihonne.com iris.to jumble.social Me

@ 3589b793:ad53847e

2025-04-30 12:10:06

前回の続きです。

特に「Snortで試験的にノート単位に投げ銭できる機能」について。実は記事書いた直後にリリースされて慌ててw追記してたんですが追い付かないということで別記事にしました。

今回のここがすごい！

「Snortで試験的にノート単位に投げ銭できる機能」では一つブレイクスルーが起こっています。それは「ウォレットにインボイスを放り投げた後に払い込み完了を提示できる」ようになったことです。これによりペイメントのライフサイクルが一通りカバーされたことになります。

Snortの画面

なにを当たり前のことをという向きもあるかもしれませんが、Nostrクライアントで払い込み完了を追跡することはとても難しいです。基本的にNostrとLNウォレットはまったく別のアプリケーションで両者の間を繋ぐのはインボイス文字列だけです。ウォレットもNostrからキックされずに、インボイス文字列をコピペするなりQRコードで読み取ったものを渡されるだけかもしれません。またその場でリアルタイムに処理される前提もありません。

なのでNostrクライアントでその後をトラックすることは難しく、これまではあくまで請求書を送付したり（LNインボイス）振り込み口座を提示する（LNアドレス）という一方的に放り投げてただけだったわけです。といっても魔法のようにNostrクライアントがトラックできるようになったわけではなく、今回の対応方法もインボイスを発行/お金を振り込まれるサービス側（LNURL）にNostrカスタマイズを入れさせるというものになります。

プロポーザルの概要について

前回の記事ではよくわからんで終わっていましたが、当日夜（日本時間）にスペックをまとめたプロポーザルも起こされました（早い！）。LNURLが、Nostr用のインボイスを発行して、さらにNostrイベントの発行を行っていることがポイントでした。名称は"Lightning Zaps"で確定のようです。プロポーザルは、NostrとLNURLの双方の発明者であるfiatjaf氏からツッコミが入り、またそれが妥当な指摘のために、エンドポイントURLのインターフェースなどは変わりそうなのですが、概要はそう変わらないだろうということで簡単にまとめてみます。

全体の流れ

図は、Nostrクライアント上に提示されているLNアドレスへ投げ銭が開始してから、Nostrクライアント上に払い込み完了したイベントが表示されるまでの流れを示しています。

1. 投げ銭の内容が固まったらNostrイベントデータを添付してインボイスの発行を依頼する
2. 説明欄にNostr用のデータを記載したインボイスを発行して返却する
3. Nostrクライアントで提示されたインボイスをユーザーが何かしらの手段でウォレットに渡す
4. ウォレットがLNに支払いを実行する
5. インボイスの発行者であるLNURLが管理しているLNノードにsatoshiが届く
6. LNURLサーバが投げ銭成功のNostrイベントを発行する
7. Nostrクライアントがイベントを受信して投げ銭履歴を表示する

特にポイントとなるところを補足します。

対応しているLNアドレスの識別

LNアドレスに投げ銭する場合は、LNアドレスの有効状態やインボイス発行依頼する先の情報をhttps://[domain]/.well-known/lnurlp/[username]から取得しています。そのレスポンス内容にNostr対応を示す情報を追加しています。ただし、ここに突っ込み入っていてlnurlp=LNURL Payから独立させるためにzaps専用のエンドポイントに変わりそうです。（2/15 追記　マージされましたが変更無しでした。PRのディスカッションが盛り上がっているので興味ある方は覗いてみてください。）

インボイスの説明欄に書き込むNostrイベント（kind:9734）

これは投げ銭する側のNostrイベントです。投げ銭される者や対象ノートのIDや金額、そしてこのイベントを作成している者が投げ銭したということを「表明」するものになります。表明であって証明でないところは、インボイスを別の人が払っちゃう事態がありえるからですね。この内容をエンクリプトするパターンも用意されていたが複雑になり過ぎるという理由で今回は外され追加提案に回されました。また、このイベントはデータを作成しただけです。支払いを検知した後にLNURLが発行するイベントに添付されることになります。そのため投げ銭する者にちゃんと届くように作成者のリレーサーバリストも書き込まれています。

支払いを検知した後に発行するNostrイベント（kind:9735）

これが実際にNostrリレーサーバに発行されるイベントです。LNURL側はウォッチしているLNノードにsatoshiが届くと、インボイスの説明欄に書かれているNostrイベントを取り出して、いわば受領イベントを作成して発行します。以下のようにNostイベントのkind:9734とkind:9735が親子になったイベントとなります。

json { "pubkey": "LNURLが持っているNostrアカウントの公開鍵", "kind": 9735, "tags": [ [ "p", "投げ銭された者の公開鍵" ], [ "bolt11", "インボイスの文字列lnbc〜" ], [ "description", "投げ銭した者が作成したkind:9734のNostrイベント" ], [ "preimage", "インボイスのpreimage" ] ], }

所感

とにかくNostrクライアントはLNノードを持たないしLNプロトコルとも直接喋らずにインボイス文字列だけで取り扱えるようになっているところがおもしろいと思っています。NostrとLNという二つのデセントライズドなオープンプロトコルが協調できていますし、前回も述べましたがどんなアプリでも簡単に真似できます。

とはいえ、さすがに払込完了のトラックは難しく、今回はLNURL側にそのすり合わせの責務が寄せられることになりました。しかし、LNURLもLNの上に作られたオープンプロトコル/スペックの位置付けになるため、他のLNURLのスペックに干渉するという懸念から、本提案のNIP-57に変更依頼が出されています。LN、LNURL、Nostrの3つのオープンプロトコルの責務分担が難しいですね。アーキテクチャ層のスタックにおいて3つの中ではNostrが一番上になるため、Nostrに相当するレイヤーの他のwebサービスでやるときはLNプロトコルを喋るなりLNノードを持つようにして、今回LNURLが寄せられた責務を吸収するのが無難かもしれません。

また、NIP-57の変更依頼理由の一つにはBOLT-12を見越した抽象化も挙げられています。他のLNURLのスペックを削ぎ落としてzapsだけにすることでBOLT-12にも載りやすくなるだろうと。LNURLの多くはBOLT-12に取り込まれる運命なわけですが、LNアドレス以外の点でもNostrではBOLT-12のOfferやInvoiceRequestのユースケースをやりたいという声が挙がっているため、NostrによりBOLT-12が進む展開もありそうだなあ、あってほしい。

yakihonne.com iris.to jumble.social Me

@ 3589b793:ad53847e

2025-04-30 12:02:13

※本記事は別サービスで2023年2月5日に公開した記事の移植です。

Nostrクライアントは多種ありますがメジャーなものはだいたいLNの支払いが用意されています。現時点でどんな組み込み方法になっているか調べました。この記事では主にSnortを対象にしています。

LN活用場面

大きくLNアドレスとLNインボイスの2つの形式があります。

1. LNアドレスで投げ銭をセットできる

LNURLのLNアドレスをセットすると、プロフィールやノート（ツイートに相当）からLN支払いができます。別クライアントのastralなどではプリミティブなLNURLの投げ銭形式 lnurl1dp68～でもセットできます。

[追記]さらに本日、Snortで試験的にノート単位に投げ銭できる機能が追加されています。

2. LNインボイスが投稿できる

投稿でLNインボイスを貼り付ければ上記のように他の発言と同じようにタイムラインに流れます。Payボタンを押すと各自の端末にあるLNウォレットが立ち上がります。

3. DMでLNインボイスを送る

メッセージにLNインボイスが組み込まれているという点では2とほぼ同じですが、ユースケースが異なります。発表されたばかりですがリレーサーバの有料化が始まっていて、その決済をDMにLNインボイスを送付して行うことが試されています。2だとパブリックに投稿されますが、こちらはプライベートなので購入希望者のみにLNインボイスを届けられます。

おまけ: Nostrのユーザ名をLNアドレスと同じにする

直接は関係ないですが、Nostrはユーザー名をemail形式にすることができます。LNアドレスも自分でドメイン取って作れるのでNostrのユーザー名と投げ銭のアドレスを同じにできます。

LNウォレットのAlbyのドメインをNostrのユーザ名にも活用している様子 [Not found]

実装方法

LNアドレスもLNインボイスも非常にシンプルな話ですが軽くまとめます。 Snortリポジトリ

LNアドレス

1. セットされたLNアドレスを分解してhttps://[domain]/.well-known/lnurlp/[username]にリクエストする
2. 成功したら投げ銭量を決めるUIを提示する
3. Get Inoviceボタンを押したら1のレスポンスにあるcallbackにリクエストしてインボイスを取得する
4. 成功したらPayボタンを提示する

LNインボイス

1. 投稿内容がLNインボイス識別子lnbc10m〜だとわかると、識別子の中の文字列から情報（金額、説明、有効期限）を取り出し、表示用のUIを作成する
2. 有効期限内だったらPayボタンを提示し、期限が切れていたらExpiredでロックする

支払い

Payボタンを押された後の動きはアドレス、インボイスとも同じです。

• ブラウザでWebLN（Albyなど）がセットされていて、window.weblnオブジェクトがenableになっていると、拡張機能の支払い画面が立ち上がる。クライアント側で支払い成功をキャッチすることも可能。
• Open Walletボタンを押すと lightning:lnbc10m~のURI形式でwindow.openされ、Mac/Windows/iPhone/Androidなど各OSに応じたアプリケーション呼び出しが行われ、URIに対応しているLNウォレットが立ち上がる

[追記]ノート単位の投げ銭

Snort周辺の数人（strike社員っぽい人が一人いて本件のメイン実装している）で試験的にやっているようで現時点では実装レベルでしか詳細わかりませんでした。strikeのzapといまいち区別が付かなかったのですが、実装を見るとnostrプロトコルにzapイベントが追加されています。ソースコメントではこの後NIP(nostr improvement proposal)が起こされるようでかなりハッキーです。zap=tipの方言なんでしょうか？

ノートやプロフィールやリアクションなどに加えて新たにnostrイベントに追加しているものは以下2つです。

• zapRequest　投げ銭した側が対象イベントIDと量を記録する
• zapReceipt　投げ銭を受け取った側用のイベント

一つでできそうと思ったけど、nostrは自己主権のプロトコルでイベント作成するには発行者の署名が必須なので2つに分かれているのでしょう。

所感

現状はクライアントだけで完結する非常にシンプルな方法になっています。リレーサーバも経由しないしクライアントにLNノードを組み込むこともしていません。サードパーティへのhttpリクエストやローカルのアプリに受け渡すだけなので、実はどんな一般アプリでもそんなに知識もコストも要らずにパッとできるものです。

現状ちょっと不便だなと思っていることは、タイムラインに流れるインボイスの有効期限内の支払い済みがわからないことです。Payボタンを押してエラーにならないとわかりません。ウォレットアプリに放り投げていてこのトレースするためには、ウォレット側で支払い成功したらNostrイベントを書き込むなどの対応しない限りは、サービス側でインボイスを定期的に一つ一つLNに投げてチェックするなどが必要だと思われるので、他のサービスでマネするときは留意しておくとよさそうです。

一方で、DMによるLNインボイス送付は活用方法が広がりそうな予感があります。Nostrの公開鍵による本人特定と、LNインボイスのメモ欄のテキスト情報による突き合わせだけでも、かんたんな決済機能として用いれそうだからです。もっとNostrに判断材料を追加したければイベント追加も簡単にできることをSnortが示しています。とくにリレーサーバ購読やPROメニューなどのNostr周辺の支払いはやりやすそうなので、DM活用ではなくなにかしらの決済メニューを搭載したNostrクライアントもすぐに出てきそう気がします。

yakihonne.com iris.to jumble.social Me

@ 04c915da:3dfbecc9

2025-03-25 17:43:44

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

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

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

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

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

yakihonne.com iris.to jumble.social Me

@ d34e832d:383f78d0

2025-03-21 20:31:24

Introduction

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

1. The Nature of Sperm Whale Vocalizations

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

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

2. Cultural and Regional Variation in Codas

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

3. Social Organization and Communication

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

4. Theories on Whale Intelligence and Language-Like Communication

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

5. Conservation Implications and the Need for Further Research

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

Consider

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

yakihonne.com iris.to jumble.social Me

@ 3589b793:ad53847e

2025-04-30 11:46:52

※本記事は別サービスで2022年9月25日に公開した記事の移植です。

LNの手数料の適正水準はどう見積もったらいいだろうか？ルーティングノードの収益性を算出するためにはどうアプローチすればよいだろうか？本記事ではルーティングノード運用のポジションに立ち参考になりそうな数値や計算式を整理する。

個人的な感想を先に書くと以下となる。

• 現在の手数料市場は収益性が低くもっと手数料が上がった方が健全である。
• 他の決済手段と比較すると、LN支払い料金は10000ppm（手数料1%相当）でも十分ではないか。4ホップとすると中間1ノードあたり2500ppmである。
• ルーティングノードの収益性を考えると、1000ppmあれば1BTC程度の資金で年利2.8%になり半年で初期費用回収できるので十分な投資対象になると考える。

基本概念の整理

LNの料金方式

• LNの手数料は送金額に応じた料率方式が主になる。（基本料金の設定もあるが1 ~ 0 satsが大半）
• 料率単位のppm（parts per million）は、1,000,000satsを送るときの手数料をsats金額で示したもの。
• %での手数料率に変換すると1000ppm = 0.1%になる。
• 支払い者が払う手数料はルーティングに参加した各ノードの手数料の合計である。本稿では4ホップ（経由ノードが4つ）のルーティングがあるとすれば、各ノードの取り分は単純計算で1/4とみなす。
• ルーティングノードの収益はアウトバウンドフローで発生するのでアウトバウンドキャパシティが直接的な収益資源となる。

LNの料金以外のベネフィット

本稿では料金比較だけを行うが実際の決済検討では以下のような料金以外の効用も忘れてはならない。

• Bitcoin(L1)に比べると、料金の安さだけでなく、即時確定やトランザクション量のスケールという利点がある。
• クレジットカードなどの集権サービスと比較した特徴はBitcoin(L1)とだいたい同じである。
• 24時間365日利用できる
• 誰でも自由に使える
• 信頼する第三者に対する加盟や審査や手数料率などの交渉手続きが要らない
• 検閲がなく匿名性が高い
• 逆にデメリットはオンライン前提がゆえの利用の不便さやセキュリティ面の不安さなどが挙げられる。

現在の料金相場

• ルーティングノードの料金設定
• sinkノードとのチャネルは500 ~ 1000ppmが多い。
• routing/sourceノードとのチャネルは0 ~ 100ppmあたりのレンジになる。
• リバランスする場合もsinkで収益を上げているならsink以下になるのが道理である。
• プロダクト/サービスのバックエンドにいるノードの料金設定
• sinkやsourceに相当するものは上記の通り。 
• 1000〜5000ppmあたりで一律同じ設定というノードもよく見かける。
• ビジネスモデル次第で千差万別だがアクティブと思われるノードでそれ以上はあまり見かけない。
• 上記は1ノードあたりの料金になる。支払い全体では経由したノードの合計になる。

料金目安

いくつかの方法で参考数字を出していく。LN料金算出は「支払い全体/2ホップしたときの1ノードあたり/4ホップしたときの1ノードあたり」の三段階で出す。

類推方式

決済代行業者との比較

• Squareの加盟店手数料は、日本3.25%、アメリカ2.60%である。
• 参考資料 https://www.meti.go.jp/shingikai/mono_info_service/cashless_payment/pdf/20220318_1.pdf

3.25%とするとLNでは「支払い全体/2ホップしたときの1ノードあたり/4ホップしたときの1ノードあたり」でそれぞれ32,500ppm/16,250ppm/8,125ppmになる。

スマホのアプリストアとの比較

• Androidのアプリストアは年間売上高が100万USDまでなら15%、それ以上なら30%
• 参考資料https://support.google.com/googleplay/android-developer/answer/112622?hl=ja

15%とするとLNでは「支払い全体/2ホップしたときの1ノードあたり/4ホップしたときの1ノードあたり」でそれぞれ150,000ppm/75,000ppm/37,500ppmになる。

Bitcoin(L1)との比較

Bitcoin(L1)は送金額が異なっても手数料がほぼ同じため、従量課金のLNと単純比較はできない。そのためここではLNの方が料金がお得になる目安を出す。

Bitcoin(L1)の手数料設定

• SegWitのシンプルな送金を対象にする。
• input×1、output×2（送金+お釣り）、tx合計222byte
• L1の手数料は、1sat/byteなら222sats、10sat/byteなら2,220sats、100sat/byteなら22,200sats。（単純化のためvirtual byteではなくbyteで計算する）
• サンプル例 https://www.blockchain.com/btc/tx/15b959509dad5df0e38be2818d8ec74531198ca29ac205db5cceeb17177ff095

L1相場が1sat/byteの時にLNの方がお得なライン

• 100ppmなら、0.0222BTC（2,220,000sats）まで
• 1000ppmなら、0.00222BTC（222,000sats）まで

L1相場が10sat/byteの時にLNの方がお得なライン

• 100ppmなら、0.222BTC（22,200,000sats）まで
• 1000ppmなら、0.0222BTC（2,220,000sats）まで

L1相場が100sat/byteの時にLNの方がお得なライン

• 100ppmなら、2.22BTC（222,000,000sats）まで
• 1000ppmなら、0.222BTC（22,200,000sats）まで

コスト積み上げ方式

ルーティングノードの原価から損益分岐点となるppmを算出する。事業者ではなく個人を想定し、クラウドではなくラズベリーパイでのノード構築環境で計算する。

費用明細

• BTC市場価格　1sat = 0.03円（1BTC = 3百万円)

初期費用

• ハードウェア一式　40,000円
• Raspberry Pi 4 8GB
• SSD 1TB
• 外付けディスプレイ
• チャネル開設のオンチェーン手数料　6.69円/チャネル　　
• 開設料　223sats
• 223sats * BTC市場価格0.03円 = 6.69円

固定費用

• 電気代　291.6円/月　　
• 時間あたりの電力量　0.015kWh 
  • Raspberry Pi 4　電圧5V、推奨電源容量3.0A
  • https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#power-supply
• kWh単価27円
• 0.015kWh * kWh単価27円 * １ヶ月の時間720h = 291.6円

損益分岐点

• 月あたりの電気代を上回るために9,720sats（291.6円）/月以上の収益が必要である。
• ハードウェア費用回収のために0.01333333BTC（133万sats) = 40,000円の収益が必要である。

費用回収シナリオ例

アウトバウンドキャパに1BTCをデポジットしたAさんを例にする。1BTCは初心者とは言えないと思うが、このくらい原資を用意しないと費用回収の話がしづらいという裏事情がある。チャネル選択やルーティング戦略は何もしていない仮定である。ノード運用次第であることは言うまでもないので今回は要素や式を洗い出すことが主目的で一つ一つの変数の値は参考までに。

変数設定

• インバウンドを同額用意して合計キャパを2BTCとする。
• １チャネルあたり5m satsで40チャネル開設する。
• チャネル開設費用　223sats * 40チャネル = 8,920sats
• 初期費用合計　1,333,333sats + 8,920sats = 1,342,253sats
• 一回あたり平均ルーティング量 = 100,000sats
• 1チャネルあたり平均アウトバウンド数/日 = 2
• 1チャネルあたり平均アウトバウンドppm = 50

費用回収地点

• 1日のアウトバウンド量は、 40チャネル * 2本 * 100,000sats = 8m sats
• 手数料収入は、8m sats * 0.005%(50ppm) = 400sats/日。月換算すると12,000sats/月
• 電気代を差し引くと、12,000sats - 電気代9,720sats =月収益2,280sats(68.4円)
• 初期費用回収まで、1,342,253sats / 2,280sats = 589ヵ月（49年）
• 後述するが電気代差引き前で年利0.14%になる。

理想的なppm

6ヵ月での初期費用回収を目的にしてアウトバウンドppmを求める。

• ひと月あたり、初期費用合計1,342,253sats / 6ヵ月 + 電気代9,720sats = 233,429sats(7,003円)の収益が必要。
• 1日あたり、7,781sats(233円)の収益
• その場合の平均アウトバウンドppmは、 7,781sats（1日の収益量） / 8m sats（1日のアウトバウンド量） * 1m sats（ppm変換係数） = 973ppm

他のファイナンスとの比較

ルーティングノードを運用して手数料収入を得ることは資産運用と捉えることもできる。レンディングやトレードなどの他の資産運用手段とパフォーマンス比較をするなら、デポジットしたアウトバウンドキャパシティに対する手数料収入をAPY換算する。（獲得した手数料はアウトバウンドキャパシティに積み重ねられるので複利と見做せる）

例としてLNDg（v1.3.1）のAPY算出計算式を転載する。見ての通り画面上の表記はAPYなのに中身はAPRになっているので注意だが今回は考え方の参考としてこのまま採用する。

年換算 = 365 / 7 = 52.142857 年利 = (7dayの収益 * 年換算) / アウトバウンドのキャパシティ

例えば上記のAさんの費用回収シナリオに当てはめると以下となる。

年利 0.14% = （400sats * 7日 * 年換算）/ 100m sats

電気代を差し引くと 76sats/日となり年利0.027%

もし平均アウトバウンド1000ppmになると8,000sats/日なので年利2.9%になる。 この場合、電気代はほぼ1日で回収されるため差し引いても大差なく7,676sats/日で年利2.8%になる。

考察

以上、BTC市場価格や一日のアウトバウンド量といった重要な数値をいくつか仮置きした上ではあるが、LN手数料の適正水準を考えるための参考材料を提示した。

まず、現在のLNの料金相場は他の決済手段から比べると圧倒的に安いことがわかった。1%でも競争力が十分ありそうなのに0.1%前後で送金することが大半である。

健全な市場発展のためには、ルーティングノードの採算が取れていることが欠かせないと考えるが、残念ながら現在の収益性は低い。ルーティングノードの収益性は仮定に仮定を重ねた見積もりになるが、平均アウトバウンドが1000ppmでようやく個人でも参入できるレベルになるという結論になった。ルーティングノードの立場に立つと、現在の市場平均から大幅な上昇が必要だと考える。

手数料市場は競争のためつねに下方圧力がかかっていて仕様上で可能な0に近づいている。この重力に逆らうためには、1. 需要 > 供給のバランスになること、2. 事業用途での高額買取のチャネルが増えること、の2つの観点を挙げる。1にせよ2にせよネットワークの活用が進むことで発生し、手数料市場の大きな変動機会になるのではないか。他の決済手段と比較すれば10000ppm、1チャネル2500ppmあたりまでは十分に健全な範囲だと考える。

yakihonne.com iris.to jumble.social Me

@ b98139a6:eb269255

2025-05-05 22:09:57

I’m exhausted from the endless OP_RETURN vs. Core infighting… so I figured I’d relax with the nice, calm, debate about Due Process. 😉

Okay, sure—this topic is every bit as heated in legal circles as block sizes and fork wars are in Bitcoin. But for a Bitcoin-savvy, intellectually curious audience, the current political battle over Due Process is worth diving into. Let’s explore how the U.S. Constitution phrases different rights (who exactly gets them), and why “due process” isn’t a one-size-fits-all procedure.

(This is partly an explainer, and partly a discussion prompt. I am sure that I will have some pushback, especially from other attorneys. That's cool! Reasonable people can disagree on even contentious topics like ultimate grant of rights to noncitizens. Maybe even OP_RETURN!)

“The People” vs. “No Person” – Who Gets What Rights?

One of the first points of confusion in constitutional law is that not all rights are phrased the same way. Some rights are granted to “the people,” while others protect “persons” or “the accused.” These aren’t just linguistic quirks – they signal which groups are protected (citizens or everyone). Let’s break it down:

• Rights of “the People”: Several amendments (like the 1st, 2nd, and 4th) explicitly mention “the people.” For example, the Second Amendment says “the right of the people to keep and bear arms” and the Fourth Amendment protects “the right of the people to be secure… against unreasonable searches and seizures.” The Supreme Court has noted that “the people” refers to those within the national community of the United States. In plain terms, this implies these rights are geared toward citizens and others with a strong connection to the U.S. (In a 1990 case, Chief Justice Rehnquist suggested that “the people” who enjoy 1st, 2nd, and 4th Amendment rights are those “who are part of a national community or who have otherwise developed sufficient connection with this country”. See United States v. Verdugo-Urquidez, 494 U.S. 259 (1990).) In other words, if you’re not part of “We the People” (say, a foreigner with no ties), those particular rights may not fully extend to you.

• Rights of “Persons”: Other rights use broad language like “no person shall…” – notably, the Fifth Amendment’s due process clause. It doesn’t say “no citizen” – it says “no person shall be deprived of life, liberty, or property without due process of law.” This wording was very intentional. It means any person under U.S. jurisdiction is owed due process, regardless of citizenship status. The same goes for the Fifth Amendment’s protection against self-incrimination and double jeopardy – it protects “persons.” So even if someone isn’t a U.S. citizen, if the U.S. government is trying to lock them up or take something from them, the Constitution demands some form of fair procedure. (As one legal expert dryly noted in response to a political slogan, the Constitution “does not make any distinction between citizens and noncitizens” when it comes to due process.)

• Rights of “the Accused”: The Sixth Amendment speaks of “the accused” – “In all criminal prosecutions, the accused shall enjoy the right to a speedy and public trial, by an impartial jury,” and so on. This applies to anyone who finds themselves prosecuted under U.S. criminal law. Citizen or not, if you’re charged with a crime in a U.S. court, you are “the accused” and you get those Sixth Amendment rights. There’s no citizenship test for the right to a lawyer, a jury, etc.

• The 14th Amendment – Citizens and Persons: After the Civil War, the 14th Amendment was adopted, and it cleverly uses both terms. First it says “All persons born or naturalized in the U.S. … are citizens.” That defines citizenship. But then it says “nor shall any State deprive any person of life, liberty, or property without due process of law, nor deny to any person within its jurisdiction the equal protection of the laws.” Here we see “any person” again. This was a big statement: the 14th Amendment explicitly is not limited to citizens in its protections of due process and equal protection. The Supreme Court recognized way back in 1886 that these provisions are “universal in their application, to all persons within the territorial jurisdiction, without regard to any differences of race, color, or nationality.” In practical terms, this means a foreign student, an undocumented immigrant, or a tourist on U.S. soil is a “person” under the 14th Amendment and thus is owed due process and equal protection by any state or local government. (However, the 14th’s “privileges or immunities” clause does specifically protect “citizens” – things like the right to travel between states, etc. – highlighting that some rights were meant for citizens only, while core concepts of due process apply to everyone.)

In summary, the Constitution carefully differentiates who it’s talking about. “The people” usually means the American people (members of the national community), whereas “no person” means literally any person (citizen or not) under U.S. authority. So, next time someone claims “Hey, non-citizens aren’t protected by the Constitution!”, you can politely point out that the text says otherwise in many places. The Founders and those who amended the Constitution knew exactly what they were doing with those words.

Due Process ≠ One-Size-Fits-All (Article III Courts vs. Article II Courts)

Now let’s tackle the second big point: Due Process. We often hear the term thrown around (sometimes in heated Twitter debates as much as in courtrooms). But due process isn’t a monolith – the kind of “process” someone is “due” can vary a lot depending on the situation. Think of it as a sliding scale: the more serious the deprivation of your rights, the more robust the process the government must give you.

In the U.S., this plays out by having different types of courts and procedures for different matters. Let’s contrast two extremes:

• Criminal Prosecutions (Article III courts): These are the trials for serious offenses. They take place in Article III courts, meaning the normal judiciary with independent judges (appointed for life under Article III of the Constitution). Here, due process is at its most robust. If the government wants to put someone in jail (or even take their life in capital cases), it must jump through many hoops: a formal indictment, the right to an attorney, a public jury trial, proof beyond a reasonable doubt, etc. The Constitution spells out many of these protections in the 5th and 6th Amendments (grand jury indictment, no double jeopardy, speedy trial, impartial jury, right to counsel, etc.). These safeguards apply to “the accused” in criminal cases – which, as we noted, means anyone accused, citizen or not. The idea is that when the stakes are highest (your liberty or life on the line), the procedural protections are strongest. It’s the legal equivalent of Bitcoin’s full nodes rigorously verifying every block – no shortcuts allowed when something so valuable is at stake.

• Immigration/Deportation Proceedings (Article II courts): On the other end, consider the process for deporting someone for violating immigration laws. Surprisingly to many, removal/deportation cases don’t happen in the regular courts at all – they happen in administrative tribunals under the Executive Branch. Since 1983, immigration courts have been housed in the Department of Justice (under the Attorney General), making them what are called “Article II courts,” operating under the authority of the President. The officials who preside are immigration judges, but they are not Article III judges – they’re essentially DOJ employees. And because deportation is classified as a civil matter, not a criminal one, the due process requirements are different (and more limited).

Why are they more limited? By law, deportation is not considered a “punishment” for a crime – it’s civil and administrative. See Wong Wing v. United States 163 U.S. 228 (1896). The Supreme Court has said for over a century that removing an undocumented or removable alien is just the government enforcing immigration policy, “not a punishment for crime.” It’s akin to revoking someone’s permission to remain in the country, rather than convicting them of a criminal offense. Because it’s not punishment, many of the constitutional protections that apply in criminal cases don’t apply in deportation proceedings. There’s no jury trial in immigration court, no requirement of proof beyond a reasonable doubt (the government usually just needs “clear and convincing” evidence of removability), and the government doesn’t have to provide a free lawyer if you can’t afford one. In fact, the Supreme Court explicitly noted that things like the right to a jury and the ban on “cruel and unusual punishments” “have no application” in deportation cases.

This doesn’t mean immigrants have zero rights – due process still applies, just in a more basic form. Typically, due process in deportation means the right to notice of the charges and a fair hearing before a neutral adjudicator. You get to appear before an immigration judge, present evidence, and argue your case (for example, that you have legal status, or that you qualify for asylum, etc.). The government can’t just pick you up and secretly put you on a plane without any procedure at all (except in certain very narrow scenarios like expedited removal at the border, which still involves at least an interview). But the level of process is much less elaborate than in a criminal court. It’s the difference between a quick SPV node verification and a full node verification – the former is “lighter” and leaves more room for error.

And errors do happen, which is why this debate is fierce. Immigration judges handle hundreds of thousands of cases and sometimes people with rights do slip through the cracks. There have been cases of U.S. citizens mistakenly detained or nearly deported because the system is under strain and shortcuts get taken. That’s why critics argue that even if deportation isn’t “punitive,” it sure feels like punishment to the people on the receiving end. The Supreme Court itself has acknowledged that being deported can be devastating – in one case, the Court noted deportation may result in “the loss of all that makes life worth living.” Bridges v. Wixon, 326 U.S. 135 (1945), see also Ng Fung Ho v. White, 259 U.S. 276 (1922). Despite this harsh reality, the legal doctrine remains that it’s not punishment in the criminal sense. Wong Wing v. United States (163 U.S. 228, 1896).

To sum up, “Due Process” comes in levels: at minimum, it means fundamental fairness – the government can’t just do stuff to you arbitrarily without some procedure. But what procedure is due depends on context. If you’re a citizen facing a criminal charge, due process is maximal – you get the full panoply of rights in an Article III court. If you’re a non-citizen facing deportation, due process still applies, but in a limited, civil proceeding way – an Article II tribunal where the process is streamlined. The law draws this line because of the formal distinction that deportation = civil remedy, not criminal punishment. Or as one official recently put it (to much controversy): “the judicial process is for Americans. Immediate deportation is for illegal aliens.” (Many lawyers and judges vehemently disagree with that phrasing, citing the Fifth Amendment’s “no person” language, but it captures the attitude that immigration proceedings are a separate track.)

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

yakihonne.com iris.to jumble.social Me

@ 6e64b83c:94102ee8

2025-05-05 16:50:13

Nostr-static is a powerful static site generator that transforms long-form Nostr content into beautiful, standalone websites. It makes your content accessible to everyone, even those not using Nostr clients. For more information check out my previous blog post How to Create a Blog Out of Nostr Long-Form Articles

What's New in Version 0.7?

RSS and Atom Feeds

Version 0.7 brings comprehensive feed support with both RSS and Atom formats. The system automatically generates feeds for your main content, individual profiles, and tag-specific pages. These feeds are seamlessly integrated into your site's header, making them easily discoverable by feed readers and content aggregators.

This feature bridges the gap between Nostr and traditional web publishing, allowing your content to reach readers who prefer feed readers or automated content distribution systems.

Smart Content Discovery

The new tag discovery system enhances your readers' experience by automatically finding and recommending relevant articles from the Nostr network. It works by:

1. Analyzing the tags in your articles
2. Fetching popular articles from Nostr that share these tags
3. Using configurable weights to rank these articles based on:
4. Engagement metrics (reactions, reposts, replies)
5. Zap statistics (amount, unique zappers, average zap size)
6. Content quality signals (report penalties)

This creates a dynamic "Recommended Articles" section that helps readers discover more content they might be interested in, all while staying within the Nostr ecosystem.

See the new features yourself by visiting our demo at: https://blog.nostrize.me

yakihonne.com iris.to jumble.social Me

@ 00033a93:774465e5

2025-05-05 10:40:28

An Italian artist just announced in the small town of Fornelli a statue of Satoshi, involving the administration in the project and the community of Fornelli in Bitcoin!

Not all heroes wear capes!

Italian article here:

https://bitcoinbeer.events/article/21

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

yakihonne.com iris.to jumble.social Me

@ 3589b793:ad53847e

2025-04-30 10:53:29

※本記事は別サービスで2022年5月22日に公開した記事の移植です。

Happy 🍕 Day's Present

まだ邦訳版が出版されていませんがこれまでのシリーズと同じくGitHubにソースコードが公開されています。なんと、現在のライセンスでは個人使用限定なら翻訳や製本が可能です。Macで、翻訳にはPDFをインプットにできるDeepLを用いた環境で、インスタントに製本してKindleなどで読めるようにする方法をまとめました。

手順の概要

1. Ruby環境を用意する
2. PDF作成ツールをセットアップする
3. GitHubのリポジトリを自分のPCにクローンする
4. asciidocをPDFに変換する
5. DeepLを節約するためにPDFを結合する
6. DeepLで翻訳ファイルを作る
7. 一冊に製本する

この手法の強み・弱み

翻訳だけならPDFを挟まなくてもGithubなどでプレビューできるコンパイル後のドキュメントの文章をコピーしてDeepLのWebツールにペーストすればよいですが、原著のペーパーブックで438ページある大容量です。熟練のコピペ職人でも年貢を納めて後進（機械やソフトウェア）に道を譲る刻ではないでしょうか？ただし、Pros/Consがあります。

Pros

• 一冊の本になるので毎度のコピペ作業がいらない
• Pizzaを食べながらタブレットやKindleで読める
• 図や表が欠落しない（プロトコルの手順を追った解説が多いため最大の動機でした）
• 2022/6/16追記: DeepLの拡張機能がアップデートされウェブページの丸ごと翻訳が可能になりました。よってウェブ上のgithubの図表付きページをそのまま翻訳できます。

Cons

• Money is power（大容量のためDeepLの有料契約が必要）
• ページを跨いだ文章が統合されずに不自然な翻訳になる（仕様です）
• ~~翻訳できない章が一つある（解決方法がないか調査中です。DeepLさんもっとエラーメッセージ出してくれ。Help me）~~ DeepLサポートに投げたら翻訳できるようになりました。

詳細ステップ

0.Ruby環境を用意する

asciidoctorも新しく入れるなら最新のビルドで良いでしょう。

1.PDF作成ツールをセットアップする

$ gem install asciidoctor asciidoctor-pdf $ brew install gs

2.GitHubのリポジトリを自分のPCにクローンする

どこかの作業ディレクトリで以下を実行する $ git clone git@github.com:lnbook/lnbook.git $ cd lnbook

3.asciidocをPDFに変換する

ワイルドカードを用いて本文を根こそぎPDF化します。 $ asciidoctor-pdf 0*.asciidoc 1*.asciidoc

いろいろ解析の警告が出ますが、ソースのasciidocを弄んでいくなりawsomeライブラリを導入すれば解消できるはずです。しかし如何せん量が多いので心が折れます。いったん無視して"Done is better than perfect"精神で最後までやり切りましょう。そのままGO！

また、お好みに合わせて、htmlで用意されている装丁用の部品も準備しましょう。私は表紙のcover.htmlをピックしました。ソースがhtmlなのでasciidoctorを通さず普通にPDFへ変換します。https://qiita.com/chenglin/items/9c4ed0dd626234b71a2c

4.DeepLを節約するためにPDFを結合する

DeepLでは課金プラン毎に翻訳可能なファイル数が設定されている上に、一本あたりの最大ファイルサイズが10MBです。また、翻訳エラーになる章が含まれていると丸ごとコケます。そのためPDCAサイクルを回し、最適なファイル数を手探りで見つけます。以下が今回導出した解となります。

$ gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=output_1.pdf 01_introduction.pdf 02_getting_started.pdf 03_how_ln_works.pdf 04_node_client.pdf 05_node_operations.pdf $gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=output_2_1.pdf 06_lightning_architecture.pdf 07_payment_channels.pdf 08_routing_htlcs.pdf $gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=output_2_2.pdf 09_channel_operation.pdf 10_onion_routing.asciidoc$ gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=output_3.pdf 11_gossip_channel_graph.pdf 12_path_finding.pdf 13_wire_protocol.pdf 14_encrypted_transport.pdf 15_payment_requests.pdf 16_security_privacy_ln.pdf 17_conclusion.pdf

5. DeepLで翻訳ファイルを作る

PDFファイルを真心を込めた手作業で一つ一つDeepLにアップロードしていき翻訳ファイルを作ります。ファイル名はデフォルトの[originalName]（日本語）.pdfのままにしています。

6. 一冊に製本する

表紙 + 本文で作成する例です。

$ gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=mastering_ln_jp.pdf cover.pdf "output_1 (日本語).pdf" "output_2_1 (日本語).pdf" "output_2_2 (日本語).pdf" "output_3 (日本語).pdf"

コングラチュレーションズ🎉

あなたは『Mastering the Lightning Network』の日本語版を手に入れた！個人使用に限り、あとは煮るなり焼くなりEPUBなりkindleへ送信するなり好き放題だ。

yakihonne.com iris.to jumble.social Me