@ e3ba5e1a:5e433365

I got into a [friendly discussion](https://x.com/snoyberg/status/1887007888117252142) on X regarding health insurance. The specific question was how to deal with health insurance companies (presumably unfairly) denying claims? My answer, as usual: get government out of it! The US healthcare system is essentially the worst of both worlds: * Unlike full single payer, individuals incur high costs * Unlike a true free market, regulation causes increases in costs and decreases competition among insurers I'm firmly on the side of moving towards the free market. (And I say that as someone living under a single payer system now.) Here's what I would do: * Get rid of tax incentives that make health insurance tied to your employer, giving individuals back proper freedom of choice. * Reduce regulations significantly. * In the short term, some people will still get rejected claims and other obnoxious behavior from insurance companies. We address that in two ways: 1. Due to reduced regulations, new insurance companies will be able to enter the market offering more reliable coverage and better rates, and people will flock to them because they have the freedom to make their own choices. 2. Sue the asses off of companies that reject claims unfairly. And ideally, as one of the few legitimate roles of government in all this, institute new laws that limit the ability of fine print to allow insurers to escape their responsibilities. (I'm hesitant that the latter will happen due to the incestuous relationship between Congress/regulators and insurers, but I can hope.) Will this magically fix everything overnight like politicians normally promise? No. But it will allow the market to return to a healthy state. And I don't think it will take long (order of magnitude: 5-10 years) for it to come together, but that's just speculation. And since there's a high correlation between those who believe government can fix problems by taking more control and demanding that only credentialed experts weigh in on a topic (both points I strongly disagree with BTW): I'm a trained actuary and worked in the insurance industry, and have directly seen how government regulation reduces competition, raises prices, and harms consumers. And my final point: I don't think any prior art would be a good comparison for deregulation in the US, it's such a different market than any other country in the world for so many reasons that lessons wouldn't really translate. Nonetheless, I asked Grok for some empirical data on this, and at best the results of deregulation could be called "mixed," but likely more accurately "uncertain, confused, and subject to whatever interpretation anyone wants to apply." https://x.com/i/grok/share/Zc8yOdrN8lS275hXJ92uwq98M

@ e3ba5e1a:5e433365

President Trump has started rolling out his tariffs, something I [blogged about in November](https://www.snoyman.com/blog/2024/11/steelmanning-tariffs/). People are talking about these tariffs a lot right now, with many people (correctly) commenting on how consumers will end up with higher prices as a result of these tariffs. While that part is true, I’ve seen a lot of people taking it to the next, incorrect step: that consumers will pay the entirety of the tax. I [put up a poll on X](https://x.com/snoyberg/status/1886035800019599808) to see what people thought, and while the right answer got a lot of votes, it wasn't the winner.  For purposes of this blog post, our ultimate question will be the following: * Suppose apples currently sell for $1 each in the entire United States. * There are domestic sellers and foreign sellers of apples, all receiving the same price. * There are no taxes or tariffs on the purchase of apples. * The question is: if the US federal government puts a $0.50 import tariff per apple, what will be the change in the following: * Number of apples bought in the US * Price paid by buyers for apples in the US * Post-tax price received by domestic apple producers * Post-tax price received by foreign apple producers Before we can answer that question, we need to ask an easier, first question: before instituting the tariff, why do apples cost $1? And finally, before we dive into the details, let me provide you with the answers to the ultimate question. I recommend you try to guess these answers before reading this, and if you get it wrong, try to understand why: 1. The number of apples bought will go down 2. The buyers will pay more for each apple they buy, but not the full amount of the tariff 3. Domestic apple sellers will receive a *higher* price per apple 4. Foreign apple sellers will receive a *lower* price per apple, but not lowered by the full amount of the tariff In other words, regardless of who sends the payment to the government, both taxed parties (domestic buyers and foreign sellers) will absorb some of the costs of the tariff, while domestic sellers will benefit from the protectionism provided by tariffs and be able to sell at a higher price per unit. ## Marginal benefit All of the numbers discussed below are part of a [helper Google Sheet](https://docs.google.com/spreadsheets/d/14ZbkWpw1B9Q1UDB9Yh47DmdKQfIafVVBKbDUsSIfGZw/edit?usp=sharing) I put together for this analysis. Also, apologies about the jagged lines in the charts below, I hadn’t realized before starting on this that there are [some difficulties with creating supply and demand charts in Google Sheets](https://superuser.com/questions/1359731/how-to-create-a-supply-demand-style-chart). Let’s say I absolutely love apples, they’re my favorite food. How much would I be willing to pay for a single apple? You might say “$1, that’s the price in the supermarket,” and in many ways you’d be right. If I walk into supermarket A, see apples on sale for $50, and know that I can buy them at supermarket B for $1, I’ll almost certainly leave A and go buy at B. But that’s not what I mean. What I mean is: how high would the price of apples have to go *everywhere* so that I’d no longer be willing to buy a single apple? This is a purely personal, subjective opinion. It’s impacted by how much money I have available, other expenses I need to cover, and how much I like apples. But let’s say the number is $5. How much would I be willing to pay for another apple? Maybe another $5. But how much am I willing to pay for the 1,000th apple? 10,000th? At some point, I’ll get sick of apples, or run out of space to keep the apples, or not be able to eat, cook, and otherwise preserve all those apples before they rot. The point being: I’ll be progressively willing to spend less and less money for each apple. This form of analysis is called *marginal benefit*: how much benefit (expressed as dollars I’m willing to spend) will I receive from each apple? This is a downward sloping function: for each additional apple I buy (quantity demanded), the price I’m willing to pay goes down. This is what gives my personal *demand curve*. And if we aggregate demand curves across all market participants (meaning: everyone interested in buying apples), we end up with something like this:  Assuming no changes in people’s behavior and other conditions in the market, this chart tells us how many apples will be purchased by our buyers at each price point between $0.50 and $5. And ceteris paribus (all else being equal), this will continue to be the demand curve for apples. ## Marginal cost Demand is half the story of economics. The other half is supply, or: how many apples will I sell at each price point? Supply curves are upward sloping: the higher the price, the more a person or company is willing and able to sell a product. Let’s understand why. Suppose I have an apple orchard. It’s a large property right next to my house. With about 2 minutes of effort, I can walk out of my house, find the nearest tree, pick 5 apples off the tree, and call it a day. 5 apples for 2 minutes of effort is pretty good, right? Yes, there was all the effort necessary to buy the land, and plant the trees, and water them… and a bunch more than I likely can’t even guess at. We’re going to ignore all of that for our analysis, because for short-term supply-and-demand movement, we can ignore these kinds of *sunk costs*. One other simplification: in reality, supply curves often start descending before ascending. This accounts for achieving efficiencies of scale after the first number of units purchased. But since both these topics are unneeded for understanding taxes, I won’t go any further. Anyway, back to my apple orchard. If someone offers me $0.50 per apple, I can do 2 minutes of effort and get $2.50 in revenue, which equates to a $75/hour wage for me. I’m more than happy to pick apples at that price\! However, let’s say someone comes to buy 10,000 apples from me instead. I no longer just walk out to my nearest tree. I’m going to need to get in my truck, drive around, spend the day in the sun, pay for gas, take a day off of my day job (let’s say it pays me $70/hour). The costs go up significantly. Let’s say it takes 5 days to harvest all those apples myself, it costs me $100 in fuel and other expenses, and I lose out on my $70/hour job for 5 days. We end up with: * Total expenditure: $100 \+ $70 \* 8 hours a day \* 5 days \== $2900 * Total revenue: $5000 (10,000 apples at $0.50 each) * Total profit: $2100 So I’m still willing to sell the apples at this price, but it’s not as attractive as before. And as the number of apples purchased goes up, my costs keep increasing. I’ll need to spend more money on fuel to travel more of my property. At some point I won’t be able to do the work myself anymore, so I’ll need to pay others to work on the farm, and they’ll be slower at picking apples than me (less familiar with the property, less direct motivation, etc.). The point being: at some point, the number of apples can go high enough that the $0.50 price point no longer makes me any money. This kind of analysis is called *marginal cost*. It refers to the additional amount of expenditure a seller has to spend in order to produce each additional unit of the good. Marginal costs go up as quantity sold goes up. And like demand curves, if you aggregate this data across all sellers, you get a supply curve like this:  ## Equilibrium price We now know, for every price point, how many apples buyers will purchase, and how many apples sellers will sell. Now we find the equilibrium: where the supply and demand curves meet. This point represents where the marginal benefit a buyer would receive from the next buyer would be less than the cost it would take the next seller to make it. Let’s see it in a chart:  You’ll notice that these two graphs cross at the $1 price point, where 63 apples are both demanded (bought by consumers) and supplied (sold by producers). This is our equilibrium price. We also have a visualization of the *surplus* created by these trades. Everything to the left of the equilibrium point and between the supply and demand curves represents surplus: an area where someone is receiving something of more value than they give. For example: * When I bought my first apple for $1, but I was willing to spend $5, I made $4 of consumer surplus. The consumer portion of the surplus is everything to the left of the equilibrium point, between the supply and demand curves, and above the equilibrium price point. * When a seller sells his first apple for $1, but it only cost $0.50 to produce it, the seller made $0.50 of producer surplus. The producer portion of the surplus is everything to the left of the equilibrium point, between the supply and demand curves, and below the equilibrium price point. Another way of thinking of surplus is “every time someone got a better price than they would have been willing to take.” OK, with this in place, we now have enough information to figure out how to price in the tariff, which we’ll treat as a negative externality. ## Modeling taxes Alright, the government has now instituted a $0.50 tariff on every apple sold within the US by a foreign producer. We can generally model taxes by either increasing the marginal cost of each unit sold (shifting the supply curve up), or by decreasing the marginal benefit of each unit bought (shifting the demand curve down). In this case, since only some of the producers will pay the tax, it makes more sense to modify the supply curve. First, let’s see what happens to the foreign seller-only supply curve when you add in the tariff:  With the tariff in place, for each quantity level, the price at which the seller will sell is $0.50 higher than before the tariff. That makes sense: if I was previously willing to sell my 82nd apple for $3, I would now need to charge $3.50 for that apple to cover the cost of the tariff. We see this as the tariff “pushing up” or “pushing left” the original supply curve. We can add this new supply curve to our existing (unchanged) supply curve for domestic-only sellers, and we end up with a result like this:  The total supply curve adds up the individual foreign and domestic supply curves. At each price point, we add up the total quantity each group would be willing to sell to determine the total quantity supplied for each price point. Once we have that cumulative supply curve defined, we can produce an updated supply-and-demand chart including the tariff:  As we can see, the equilibrium has shifted: * The equilibrium price paid by consumers has risen from $1 to $1.20. * The total number of apples purchased has dropped from 63 apples to 60 apples. * Consumers therefore received 3 less apples. They spent $72 for these 60 apples, whereas previously they spent $63 for 3 more apples, a definite decrease in consumer surplus. * Foreign producers sold 36 of those apples (see the raw data in the linked Google Sheet), for a gross revenue of $43.20. However, they also need to pay the tariff to the US government, which accounts for $18, meaning they only receive $25.20 post-tariff. Previously, they sold 42 apples at $1 each with no tariff to be paid, meaning they took home $42. * Domestic producers sold the remaining 24 apples at $1.20, giving them a revenue of $28.80. Since they don’t pay the tariff, they take home all of that money. By contrast, previously, they sold 21 apples at $1, for a take-home of $21. * The government receives $0.50 for each of the 60 apples sold, or in other words receives $30 in revenue it wouldn’t have received otherwise. We could be more specific about the surpluses, and calculate the actual areas for consumer surplus, producer surplus, inefficiency from the tariff, and government revenue from the tariff. But I won’t bother, as those calculations get slightly more involved. Instead, let’s just look at the aggregate outcomes: * Consumers were unquestionably hurt. Their price paid went up by $0.20 per apple, and received less apples. * Foreign producers were also hurt. Their price received went down from the original $1 to the new post-tariff price of $1.20, minus the $0.50 tariff. In other words: foreign producers only receive $0.70 per apple now. This hurt can be mitigated by shifting sales to other countries without a tariff, but the pain will exist regardless. * Domestic producers scored. They can sell less apples and make more revenue doing it. * And the government walked away with an extra $30. Hopefully you now see the answer to the original questions. Importantly, while the government imposed a $0.50 tariff, neither side fully absorbed that cost. Consumers paid a bit more, foreign producers received a bit less. The exact details of how that tariff was split across the groups is mediated by the relevant supply and demand curves of each group. If you want to learn more about this, the relevant search term is “price elasticity,” or how much a group’s quantity supplied or demanded will change based on changes in the price. ## Other taxes Most taxes are some kind of a tax on trade. Tariffs on apples is an obvious one. But the same applies to income tax (taxing the worker for the trade of labor for money) or payroll tax (same thing, just taxing the employer instead). Interestingly, you can use the same model for analyzing things like tax incentives. For example, if the government decided to subsidize domestic apple production by giving the domestic producers a $0.50 bonus for each apple they sell, we would end up with a similar kind of analysis, except instead of the foreign supply curve shifting up, we’d see the domestic supply curve shifting down. And generally speaking, this is what you’ll *always* see with government involvement in the economy. It will result in disrupting an existing equilibrium, letting the market readjust to a new equilibrium, and incentivization of some behavior, causing some people to benefit and others to lose out. We saw with the apple tariff, domestic producers and the government benefited while others lost. You can see the reverse though with tax incentives. If I give a tax incentive of providing a deduction (not paying income tax) for preschool, we would end up with: * Government needs to make up the difference in tax revenue, either by raising taxes on others or printing more money (leading to inflation). Either way, those paying the tax or those holding government debased currency will pay a price. * Those people who don’t use the preschool deduction will receive no benefit, so they simply pay a cost. * Those who do use the preschool deduction will end up paying less on tax+preschool than they would have otherwise. This analysis is fully amoral. It’s not saying whether providing subsidized preschool is a good thing or not, it simply tells you where the costs will be felt, and points out that such government interference in free economic choice does result in inefficiencies in the system. Once you have that knowledge, you’re more well educated on making a decision about whether the costs of government intervention are worth the benefits.

@ 9e69e420:d12360c2

 Federal employees must remove pronouns from email signatures by the end of the day. This directive comes from internal memos tied to two executive orders signed by Donald Trump. The orders target diversity and equity programs within the government.  CDC, Department of Transportation, and Department of Energy employees were affected. Staff were instructed to make changes in line with revised policy prohibiting certain language. One CDC employee shared frustration, stating, “In my decade-plus years at CDC, I've never been told what I can and can't put in my email signature.” The directive is part of a broader effort to eliminate DEI initiatives from federal discourse.

@ 97c70a44:ad98e322

There was a slight dust up recently over a website someone runs removing a listing for an app someone built based on entirely arbitrary criteria. I'm not to going to attempt to speak for either wounded party, but I would like to share my own personal definition for what constitutes a "nostr app" in an effort to help clarify what might be an otherwise confusing and opaque purity test. In this post, I will be committing the "no true Scotsman" fallacy, in which I start with the most liberal definition I can come up with, and gradually refine it until all that is left is the purest, gleamingest, most imaginary and unattainable nostr app imaginable. As I write this, I wonder if anything built yet will actually qualify. In any case, here we go. # It uses nostr The lowest bar for what a "nostr app" might be is an app ("application" - i.e. software, not necessarily a native app of any kind) that has some nostr-specific code in it, but which doesn't take any advantage of what makes nostr distinctive as a protocol. Examples might include a scraper of some kind which fulfills its charter by fetching data from relays (regardless of whether it validates or retains signatures). Another might be a regular web 2.0 app which provides an option to "log in with nostr" by requesting and storing the user's public key. In either case, the fact that nostr is involved is entirely neutral. A scraper can scrape html, pdfs, jsonl, whatever data source - nostr relays are just another target. Likewise, a user's key in this scenario is treated merely as an opaque identifier, with no appreciation for the super powers it brings along. In most cases, this kind of app only exists as a marketing ploy, or less cynically, because it wants to get in on the hype of being a "nostr app", without the developer quite understanding what that means, or having the budget to execute properly on the claim. # It leverages nostr Some of you might be wondering, "isn't 'leverage' a synonym for 'use'?" And you would be right, but for one connotative difference. It's possible to "use" something improperly, but by definition leverage gives you a mechanical advantage that you wouldn't otherwise have. This is the second category of "nostr app". This kind of app gets some benefit out of the nostr protocol and network, but in an entirely selfish fashion. The intention of this kind of app is not to augment the nostr network, but to augment its own UX by borrowing some nifty thing from the protocol without really contributing anything back. Some examples might include: - Using nostr signers to encrypt or sign data, and then store that data on a proprietary server. - Using nostr relays as a kind of low-code backend, but using proprietary event payloads. - Using nostr event kinds to represent data (why), but not leveraging the trustlessness that buys you. An application in this category might even communicate to its users via nostr DMs - but this doesn't make it a "nostr app" any more than a website that emails you hot deals on herbal supplements is an "email app". These apps are purely parasitic on the nostr ecosystem. In the long-term, that's not necessarily a bad thing. Email's ubiquity is self-reinforcing. But in the short term, this kind of "nostr app" can actually do damage to nostr's reputation by over-promising and under-delivering. # It complements nostr Next up, we have apps that get some benefit out of nostr as above, but give back by providing a unique value proposition to nostr users as nostr users. This is a bit of a fine distinction, but for me this category is for apps which focus on solving problems that nostr isn't good at solving, leaving the nostr integration in a secondary or supporting role. One example of this kind of app was Mutiny (RIP), which not only allowed users to sign in with nostr, but also pulled those users' social graphs so that users could send money to people they knew and trusted. Mutiny was doing a great job of leveraging nostr, as well as providing value to users with nostr identities - but it was still primarily a bitcoin wallet, not a "nostr app" in the purest sense. Other examples are things like Nostr Nests and Zap.stream, whose core value proposition is streaming video or audio content. Both make great use of nostr identities, data formats, and relays, but they're primarily streaming apps. A good litmus test for things like this is: if you got rid of nostr, would it be the same product (even if inferior in certain ways)? A similar category is infrastructure providers that benefit nostr by their existence (and may in fact be targeted explicitly at nostr users), but do things in a centralized, old-web way; for example: media hosts, DNS registrars, hosting providers, and CDNs. To be clear here, I'm not casting aspersions (I don't even know what those are, or where to buy them). All the apps mentioned above use nostr to great effect, and are a real benefit to nostr users. But they are not True Scotsmen. # It embodies nostr Ok, here we go. This is the crème de la crème, the top du top, the meilleur du meilleur, the bee's knees. The purest, holiest, most chaste category of nostr app out there. The apps which are, indeed, nostr indigitate. This category of nostr app (see, no quotes this time) can be defined by the converse of the previous category. If nostr was removed from this type of application, would it be impossible to create the same product? To tease this apart a bit, apps that leverage the technical aspects of nostr are dependent on nostr the *protocol*, while apps that benefit nostr exclusively via network effect are integrated into nostr the *network*. An app that does both things is working in symbiosis with nostr as a whole. An app that embraces both nostr's protocol and its network becomes an organic extension of every other nostr app out there, multiplying both its competitive moat and its contribution to the ecosystem: - In contrast to apps that only borrow from nostr on the technical level but continue to operate in their own silos, an application integrated into the nostr network comes pre-packaged with existing users, and is able to provide more value to those users because of other nostr products. On nostr, it's a good thing to advertise your competitors. - In contrast to apps that only market themselves to nostr users without building out a deep integration on the protocol level, a deeply integrated app becomes an asset to every other nostr app by becoming an organic extension of them through interoperability. This results in increased traffic to the app as other developers and users refer people to it instead of solving their problem on their own. This is the "micro-apps" utopia we've all been waiting for. Credible exit doesn't matter if there aren't alternative services. Interoperability is pointless if other applications don't offer something your app doesn't. Marketing to nostr users doesn't matter if you don't augment their agency _as nostr users_. If I had to choose a single NIP that represents the mindset behind this kind of app, it would be NIP 89 A.K.A. "Recommended Application Handlers", which states: > Nostr's discoverability and transparent event interaction is one of its most interesting/novel mechanics. This NIP provides a simple way for clients to discover applications that handle events of a specific kind to ensure smooth cross-client and cross-kind interactions. These handlers are the glue that holds nostr apps together. A single event, signed by the developer of an application (or by the application's own account) tells anyone who wants to know 1. what event kinds the app supports, 2. how to link to the app (if it's a client), and (if the pubkey also publishes a kind 10002), 3. which relays the app prefers. _As a sidenote, NIP 89 is currently focused more on clients, leaving DVMs, relays, signers, etc somewhat out in the cold. Updating 89 to include tailored listings for each kind of supporting app would be a huge improvement to the protocol. This, plus a good front end for navigating these listings (sorry nostrapp.link, close but no cigar) would obviate the evil centralized websites that curate apps based on arbitrary criteria._ Examples of this kind of app obviously include many kind 1 clients, as well as clients that attempt to bring the benefits of the nostr protocol and network to new use cases - whether long form content, video, image posts, music, emojis, recipes, project management, or any other "content type". To drill down into one example, let's think for a moment about forms. What's so great about a forms app that is built on nostr? Well, - There is a [spec](https://github.com/nostr-protocol/nips/pull/1190) for forms and responses, which means that... - Multiple clients can implement the same data format, allowing for credible exit and user choice, even of... - Other products not focused on forms, which can still view, respond to, or embed forms, and which can send their users via NIP 89 to a client that does... - Cryptographically sign forms and responses, which means they are self-authenticating and can be sent to... - Multiple relays, which reduces the amount of trust necessary to be confident results haven't been deliberately "lost". Show me a forms product that does all of those things, and isn't built on nostr. You can't, because it doesn't exist. Meanwhile, there are plenty of image hosts with APIs, streaming services, and bitcoin wallets which have basically the same levels of censorship resistance, interoperability, and network effect as if they weren't built on nostr. # It supports nostr Notice I haven't said anything about whether relays, signers, blossom servers, software libraries, DVMs, and the accumulated addenda of the nostr ecosystem are nostr apps. Well, they are (usually). This is the category of nostr app that gets none of the credit for doing all of the work. There's no question that they qualify as beautiful nostrcorns, because their value propositions are entirely meaningless outside of the context of nostr. Who needs a signer if you don't have a cryptographic identity you need to protect? DVMs are literally impossible to use without relays. How are you going to find the blossom server that will serve a given hash if you don't know which servers the publishing user has selected to store their content? In addition to being entirely contextualized by nostr architecture, this type of nostr app is valuable because it does things "the nostr way". By that I mean that they don't simply try to replicate existing internet functionality into a nostr context; instead, they create entirely new ways of putting the basic building blocks of the internet back together. A great example of this is how Nostr Connect, Nostr Wallet Connect, and DVMs all use relays as brokers, which allows service providers to avoid having to accept incoming network connections. This opens up really interesting possibilities all on its own. So while I might hesitate to call many of these things "apps", they are certainly "nostr". # Appendix: it smells like a NINO So, let's say you've created an app, but when you show it to people they politely smile, nod, and call it a NINO (Nostr In Name Only). What's a hacker to do? Well, here's your handy-dandy guide on how to wash that NINO stench off and Become a Nostr. You app might be a NINO if: - There's no NIP for your data format (or you're abusing NIP 78, 32, etc by inventing a sub-protocol inside an existing event kind) - There's a NIP, but no one knows about it because it's in a text file on your hard drive (or buried in your project's repository) - Your NIP imposes an incompatible/centralized/legacy web paradigm onto nostr - Your NIP relies on trusted third (or first) parties - There's only one implementation of your NIP (yours) - Your core value proposition doesn't depend on relays, events, or nostr identities - One or more relay urls are hard-coded into the source code - Your app depends on a specific relay implementation to work (*ahem*, relay29) - You don't validate event signatures - You don't publish events to relays you don't control - You don't read events from relays you don't control - You use legacy web services to solve problems, rather than nostr-native solutions - You use nostr-native solutions, but you've hardcoded their pubkeys or URLs into your app - You don't use NIP 89 to discover clients and services - You haven't published a NIP 89 listing for your app - You don't leverage your users' web of trust for filtering out spam - You don't respect your users' mute lists - You try to "own" your users' data Now let me just re-iterate - it's ok to be a NINO. We need NINOs, because nostr can't (and shouldn't) tackle every problem. You just need to decide whether your app, as a NINO, is actually contributing to the nostr ecosystem, or whether you're just using buzzwords to whitewash a legacy web software product. If you're in the former camp, great! If you're in the latter, what are you waiting for? Only you can fix your NINO problem. And there are lots of ways to do this, depending on your own unique situation: - Drop nostr support if it's not doing anyone any good. If you want to build a normal company and make some money, that's perfectly fine. - Build out your nostr integration - start taking advantage of webs of trust, self-authenticating data, event handlers, etc. - Work around the problem. Think you need a special relay feature for your app to work? Guess again. Consider encryption, AUTH, DVMs, or better data formats. - Think your idea is a good one? Talk to other devs or open a PR to the [nips repo](https://github.com/nostr-protocol/nips). No one can adopt your NIP if they don't know about it. - Keep going. It can sometimes be hard to distinguish a research project from a NINO. New ideas have to be built out before they can be fully appreciated. - Listen to advice. Nostr developers are friendly and happy to help. If you're not sure why you're getting traction, ask! I sincerely hope this article is useful for all of you out there in NINO land. Maybe this made you feel better about not passing the totally optional nostr app purity test. Or maybe it gave you some actionable next steps towards making a great NINON (Nostr In Not Only Name) app. In either case, GM and PV.

@ 0fa80bd3:ea7325de

**"Degeneration"** or **"Вырождение"** ![[photo_2025-01-29 23.23.15.jpeg]] A once-functional object, now eroded by time and human intervention, stripped of its original purpose. Layers of presence accumulate—marks, alterations, traces of intent—until the very essence is obscured. Restoration is paradoxical: to reclaim, one must erase. Yet erasure is an impossibility, for to remove these imprints is to deny the existence of those who shaped them. The work stands as a meditation on entropy, memory, and the irreversible dialogue between creation and decay.

@ 0fa80bd3:ea7325de

Lyn Alden - биткойн евангелист или евангелистка, я пока не понял ``` npub1a2cww4kn9wqte4ry70vyfwqyqvpswksna27rtxd8vty6c74era8sdcw83a ``` Thomas Pacchia - PubKey owner - X - @tpacchia ``` npub1xy6exlg37pw84cpyj05c2pdgv86hr25cxn0g7aa8g8a6v97mhduqeuhgpl ``` calvadev - Shopstr ``` npub16dhgpql60vmd4mnydjut87vla23a38j689jssaqlqqlzrtqtd0kqex0nkq ``` Calle - Cashu founder ``` npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg ``` Джек Дорси ``` npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m ``` 21 ideas ``` npub1lm3f47nzyf0rjp6fsl4qlnkmzed4uj4h2gnf2vhe3l3mrj85vqks6z3c7l ``` Много адресов. Хз кто надо сортировать ``` https://github.com/aitechguy/nostr-address-book ``` ФиатДжеф - создатель Ностр - https://github.com/fiatjaf ``` npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 ``` EVAN KALOUDIS Zues wallet ``` npub19kv88vjm7tw6v9qksn2y6h4hdt6e79nh3zjcud36k9n3lmlwsleqwte2qd ``` Программер Коди https://github.com/CodyTseng/nostr-relay ``` npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl ``` Anna Chekhovich - Managing Bitcoin at The Anti-Corruption Foundation https://x.com/AnyaChekhovich ``` npub1y2st7rp54277hyd2usw6shy3kxprnmpvhkezmldp7vhl7hp920aq9cfyr7 ```

@ 0fa80bd3:ea7325de

![[yedinaya-rossiya-bear.png]] 1️⃣ Be where the bear roams. Stay in its territory, where it hunts for food. No point setting a trap in your backyard if the bear’s chilling in the forest. 2️⃣ Set a well-hidden trap. Bury it, disguise it, and place the bait right in the center. Bears are omnivores—just like secret police KGB agents. And what’s the tastiest bait for them? Money. 3️⃣ Wait for the bear to take the bait. When it reaches in, the trap will snap shut around its paw. It’ll be alive, but stuck. No escape. Now, what you do with a trapped bear is another question... 😏

@ 0fa80bd3:ea7325de

The land that belongs to the indigenous peoples of Russia has been seized by a gang of killers who have unleashed a war of extermination. They wipe out anyone who refuses to conform to their rules. Those who disagree and stay behind are tortured and killed in prisons and labor camps. Those who flee lose their homeland, dissolve into foreign cultures, and fade away. And those who stand up to protect their people are attacked by the misled and deceived. The deceived die for the unchecked greed of a single dictator—thousands from both sides, people who just wanted to live, raise their kids, and build a future. Now, they are forced to make an impossible choice: abandon their homeland or die. Some perish on the battlefield, others lose themselves in exile, stripped of their identity, scattered in a world that isn’t theirs. There’s been endless debate about how to fix this, how to clear the field of the weeds that choke out every new sprout, every attempt at change. But the real problem? We can’t play by their rules. We can’t speak their language or use their weapons. We stand for humanity, and no matter how righteous our cause, we will not multiply suffering. Victory doesn’t come from matching the enemy—it comes from staying ahead, from using tools they haven’t mastered yet. That’s how wars are won. Our only resource is the **will of the people** to rewrite the order of things. Historian Timothy Snyder once said that a nation cannot exist without a city. A city is where the most active part of a nation thrives. But the cities are occupied. The streets are watched. Gatherings are impossible. They control the money. They control the mail. They control the media. And any dissent is crushed before it can take root. So I started asking myself: **How do we stop this fragmentation?** How do we create a space where people can **rebuild their connections** when they’re ready? How do we build a **self-sustaining network**, where everyone contributes and benefits proportionally, while keeping their freedom to leave intact? And more importantly—**how do we make it spread, even in occupied territory?** In 2009, something historic happened: **the internet got its own money.** Thanks to **Satoshi Nakamoto**, the world took a massive leap forward. Bitcoin and decentralized ledgers shattered the idea that money must be controlled by the state. Now, to move or store value, all you need is an address and a key. A tiny string of text, easy to carry, impossible to seize. That was the year money broke free. The state lost its grip. Its biggest weapon—physical currency—became irrelevant. Money became **purely digital.** The internet was already **a sanctuary for information**, a place where people could connect and organize. But with Bitcoin, it evolved. Now, **value itself** could flow freely, beyond the reach of authorities. Think about it: when seedlings are grown in controlled environments before being planted outside, they **get stronger, survive longer, and bear fruit faster.** That’s how we handle crops in harsh climates—nurture them until they’re ready for the wild. Now, picture the internet as that **controlled environment** for **ideas**. Bitcoin? It’s the **fertile soil** that lets them grow. A testing ground for new models of interaction, where concepts can take root before they move into the real world. If **nation-states are a battlefield, locked in a brutal war for territory, the internet is boundless.** It can absorb any number of ideas, any number of people, and it doesn’t **run out of space.** But for this ecosystem to thrive, people need safe ways to communicate, to share ideas, to build something real—**without surveillance, without censorship, without the constant fear of being erased.** This is where **Nostr** comes in. Nostr—"Notes and Other Stuff Transmitted by Relays"—is more than just a messaging protocol. **It’s a new kind of city.** One that **no dictator can seize**, no corporation can own, no government can shut down. It’s built on **decentralization, encryption, and individual control.** Messages don’t pass through central servers—they are relayed through independent nodes, and users choose which ones to trust. There’s no master switch to shut it all down. Every person owns their identity, their data, their connections. And no one—no state, no tech giant, no algorithm—can silence them. In a world where cities fall and governments fail, **Nostr is a city that cannot be occupied.** A place for ideas, for networks, for freedom. A city that grows stronger **the more people build within it**.

@ 9e69e420:d12360c2

Secretary of State Marco Rubio issued new guidance halting spending on most foreign aid grants for 90 days, including military assistance to Ukraine. This immediate order shocked State Department officials and mandates “stop-work orders” on nearly all existing foreign assistance awards. While it allows exceptions for military financing to Egypt and Israel, as well as emergency food assistance, it restricts aid to key allies like Ukraine, Jordan, and Taiwan. The guidance raises potential liability risks for the government due to unfulfilled contracts. A report will be prepared within 85 days to recommend which programs to continue or discontinue.

@ 9e69e420:d12360c2

President Trump plans to withdraw 20,000 U.S. troops from Europe and expects European allies to contribute financially to the remaining military presence. Reported by ANSA, Trump aims to deliver this message to European leaders since taking office. A European diplomat noted, “the costs cannot be borne solely by American taxpayers.” The Pentagon hasn't commented yet. Trump has previously sought lower troop levels in Europe and had ordered cuts during his first term. The U.S. currently maintains around 65,000 troops in Europe, with total forces reaching 100,000 since the Ukraine invasion. Trump's new approach may shift military focus to the Pacific amid growing concerns about China. [Sauce](https://www.stripes.com/theaters/europe/2025-01-24/trump-europe-troop-cuts-16590074.html)

@ 6be5cc06:5259daf0

A seguir, veja como instalar e configurar o **Privoxy** no **Pop!_OS**. --- ### **1. Instalar o Tor e o Privoxy** Abra o terminal e execute: ```bash sudo apt update sudo apt install tor privoxy ``` **Explicação:** - **Tor:** Roteia o tráfego pela rede Tor. - **Privoxy:** Proxy avançado que intermedia a conexão entre aplicativos e o Tor. --- ### **2. Configurar o Privoxy** Abra o arquivo de configuração do Privoxy: ```bash sudo nano /etc/privoxy/config ``` Navegue até a última linha (atalho: **`Ctrl`** + **`/`** depois **`Ctrl`** + **`V`** para navegar diretamente até a última linha) e insira: ```bash forward-socks5 / 127.0.0.1:9050 . ``` Isso faz com que o **Privoxy** envie todo o tráfego para o **Tor** através da porta **9050**. Salve (**`CTRL`** + **`O`** e **`Enter`**) e feche (**`CTRL`** + **`X`**) o arquivo. --- ### **3. Iniciar o Tor e o Privoxy** Agora, inicie e habilite os serviços: ```bash sudo systemctl start tor sudo systemctl start privoxy sudo systemctl enable tor sudo systemctl enable privoxy ``` **Explicação:** - **start:** Inicia os serviços. - **enable:** Faz com que iniciem automaticamente ao ligar o PC. --- ### **4. Configurar o Navegador Firefox** Para usar a rede **Tor** com o Firefox: 1. Abra o Firefox. 2. Acesse **Configurações** → **Configurar conexão**. 3. Selecione **Configuração manual de proxy**. 4. Configure assim: - **Proxy HTTP:** `127.0.0.1` - **Porta:** `8118` (porta padrão do **Privoxy**) - **Domínio SOCKS (v5):** `127.0.0.1` - **Porta:** `9050` 5. Marque a opção **"Usar este proxy também em HTTPS"**. 6. Clique em **OK**. --- ### **5. Verificar a Conexão com o Tor** Abra o navegador e acesse: ```text https://check.torproject.org/ ``` Se aparecer a mensagem **"Congratulations. This browser is configured to use Tor."**, a configuração está correta. --- ### **Dicas Extras** - **Privoxy** pode ser ajustado para bloquear anúncios e rastreadores. - Outros aplicativos também podem ser configurados para usar o **Privoxy**.

@ 9e69e420:d12360c2

Oregano oil is a potent natural compound that offers numerous scientifically-supported health benefits. ## Active Compounds The oil's therapeutic properties stem from its key bioactive components: - Carvacrol and thymol (primary active compounds) - Polyphenols and other antioxidant ## Antimicrobial Properties **Bacterial Protection** The oil demonstrates powerful antibacterial effects, even against antibiotic-resistant strains like MRSA and other harmful bacteria. Studies show it effectively inactivates various pathogenic bacteria without developing resistance. **Antifungal Effects** It effectively combats fungal infections, particularly Candida-related conditions like oral thrush, athlete's foot, and nail infections. ## Digestive Health Benefits Oregano oil supports digestive wellness by: - Promoting gastric juice secretion and enzyme production - Helping treat Small Intestinal Bacterial Overgrowth (SIBO) - Managing digestive discomfort, bloating, and IBS symptoms ## Anti-inflammatory and Antioxidant Effects The oil provides significant protective benefits through: - Powerful antioxidant activity that fights free radicals - Reduction of inflammatory markers in the body - Protection against oxidative stress-related conditions ## Respiratory Support It aids respiratory health by: - Loosening mucus and phlegm - Suppressing coughs and throat irritation - Supporting overall respiratory tract function ## Additional Benefits **Skin Health** - Improves conditions like psoriasis, acne, and eczema - Supports wound healing through antibacterial action - Provides anti-aging benefits through antioxidant properties **Cardiovascular Health** Studies show oregano oil may help: - Reduce LDL (bad) cholesterol levels - Support overall heart health **Pain Management** The oil demonstrates effectiveness in: - Reducing inflammation-related pain - Managing muscle discomfort - Providing topical pain relief ## Safety Note While oregano oil is generally safe, it's highly concentrated and should be properly diluted before use Consult a healthcare provider before starting supplementation, especially if taking other medications.

@ b17fccdf:b7211155

The past 26 August, Tor [introduced officially](https://blog.torproject.org/introducing-proof-of-work-defense-for-onion-services/) a proof-of-work (PoW) defense for onion services designed to prioritize verified network traffic as a deterrent against denial of service (DoS) attacks. ~ > This feature at the moment, is [deactivate by default](https://gitlab.torproject.org/tpo/core/tor/-/blob/main/doc/man/tor.1.txt#L3117), so you need to follow these steps to activate this on a MiniBolt node: * Make sure you have the latest version of Tor installed, at the time of writing this post, which is v0.4.8.6. Check your current version by typing ``` tor --version ``` **Example** of expected output: ``` Tor version 0.4.8.6. This build of Tor is covered by the GNU General Public License (https://www.gnu.org/licenses/gpl-3.0.en.html) Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.9, Zlib 1.2.13, Liblzma 5.4.1, Libzstd N/A and Glibc 2.36 as libc. Tor compiled with GCC version 12.2.0 ``` ~ > If you have v0.4.8.X, you are **OK**, if not, type `sudo apt update && sudo apt upgrade` and confirm to update. * Basic PoW support can be checked by running this command: ``` tor --list-modules ``` Expected output: ``` relay: yes dirauth: yes dircache: yes pow: **yes** ``` ~ > If you have `pow: yes`, you are **OK** * Now go to the torrc file of your MiniBolt and add the parameter to enable PoW for each hidden service added ``` sudo nano /etc/tor/torrc ``` Example: ``` # Hidden Service BTC RPC Explorer HiddenServiceDir /var/lib/tor/hidden_service_btcrpcexplorer/ HiddenServiceVersion 3 HiddenServicePoWDefensesEnabled 1 HiddenServicePort 80 127.0.0.1:3002 ``` ~ > Bitcoin Core and LND use the Tor control port to automatically create the hidden service, requiring no action from the user. We have submitted a feature request in the official GitHub repositories to explore the need for the integration of Tor's PoW defense into the automatic creation process of the hidden service. You can follow them at the following links: * Bitcoin Core: https://github.com/lightningnetwork/lnd/issues/8002 * LND: https://github.com/bitcoin/bitcoin/issues/28499 --- More info: * https://blog.torproject.org/introducing-proof-of-work-defense-for-onion-services/ * https://gitlab.torproject.org/tpo/onion-services/onion-support/-/wikis/Documentation/PoW-FAQ --- Enjoy it MiniBolter! 💙

@ 6be5cc06:5259daf0

## Bitcoin: Um sistema de dinheiro eletrônico direto entre pessoas. Satoshi Nakamoto satoshin@gmx.com www.bitcoin.org --- ### Resumo O Bitcoin é uma forma de dinheiro digital que permite pagamentos diretos entre pessoas, sem a necessidade de um banco ou instituição financeira. Ele resolve um problema chamado **gasto duplo**, que ocorre quando alguém tenta gastar o mesmo dinheiro duas vezes. Para evitar isso, o Bitcoin usa uma rede descentralizada onde todos trabalham juntos para verificar e registrar as transações. As transações são registradas em um livro público chamado **blockchain**, protegido por uma técnica chamada **Prova de Trabalho**. Essa técnica cria uma cadeia de registros que não pode ser alterada sem refazer todo o trabalho já feito. Essa cadeia é mantida pelos computadores que participam da rede, e a mais longa é considerada a verdadeira. Enquanto a maior parte do poder computacional da rede for controlada por participantes honestos, o sistema continuará funcionando de forma segura. A rede é flexível, permitindo que qualquer pessoa entre ou saia a qualquer momento, sempre confiando na cadeia mais longa como prova do que aconteceu. --- ### 1. Introdução Hoje, quase todos os pagamentos feitos pela internet dependem de bancos ou empresas como processadores de pagamento (cartões de crédito, por exemplo) para funcionar. Embora esse sistema seja útil, ele tem problemas importantes porque é baseado em **confiança**. Primeiro, essas empresas podem reverter pagamentos, o que é útil em caso de erros, mas cria custos e incertezas. Isso faz com que pequenas transações, como pagar centavos por um serviço, se tornem inviáveis. Além disso, os comerciantes são obrigados a desconfiar dos clientes, pedindo informações extras e aceitando fraudes como algo inevitável. Esses problemas não existem no dinheiro físico, como o papel-moeda, onde o pagamento é final e direto entre as partes. No entanto, não temos como enviar dinheiro físico pela internet sem depender de um intermediário confiável. O que precisamos é de um **sistema de pagamento eletrônico baseado em provas matemáticas**, não em confiança. Esse sistema permitiria que qualquer pessoa enviasse dinheiro diretamente para outra, sem depender de bancos ou processadores de pagamento. Além disso, as transações seriam irreversíveis, protegendo vendedores contra fraudes, mas mantendo a possibilidade de soluções para disputas legítimas. Neste documento, apresentamos o **Bitcoin**, que resolve o problema do gasto duplo usando uma rede descentralizada. Essa rede cria um registro público e protegido por cálculos matemáticos, que garante a ordem das transações. Enquanto a maior parte da rede for controlada por pessoas honestas, o sistema será seguro contra ataques. --- ### 2. Transações Para entender como funciona o Bitcoin, é importante saber como as transações são realizadas. Imagine que você quer transferir uma "moeda digital" para outra pessoa. No sistema do Bitcoin, essa "moeda" é representada por uma sequência de registros que mostram quem é o atual dono. Para transferi-la, você adiciona um novo registro comprovando que agora ela pertence ao próximo dono. Esse registro é protegido por um tipo especial de assinatura digital. #### O que é uma assinatura digital? Uma assinatura digital é como uma senha secreta, mas muito mais segura. No Bitcoin, cada usuário tem duas chaves: uma "chave privada", que é secreta e serve para criar a assinatura, e uma "chave pública", que pode ser compartilhada com todos e é usada para verificar se a assinatura é válida. Quando você transfere uma moeda, usa sua chave privada para assinar a transação, provando que você é o dono. A próxima pessoa pode usar sua chave pública para confirmar isso. #### Como funciona na prática? Cada "moeda" no Bitcoin é, na verdade, uma cadeia de assinaturas digitais. Vamos imaginar o seguinte cenário: 1. A moeda está com o Dono 0 (você). Para transferi-la ao Dono 1, você assina digitalmente a transação com sua chave privada. Essa assinatura inclui o código da transação anterior (chamado de "hash") e a chave pública do Dono 1. 2. Quando o Dono 1 quiser transferir a moeda ao Dono 2, ele assinará a transação seguinte com sua própria chave privada, incluindo também o hash da transação anterior e a chave pública do Dono 2. 3. Esse processo continua, formando uma "cadeia" de transações. Qualquer pessoa pode verificar essa cadeia para confirmar quem é o atual dono da moeda. #### Resolvendo o problema do gasto duplo Um grande desafio com moedas digitais é o "gasto duplo", que é quando uma mesma moeda é usada em mais de uma transação. Para evitar isso, muitos sistemas antigos dependiam de uma entidade central confiável, como uma casa da moeda, que verificava todas as transações. No entanto, isso criava um ponto único de falha e centralizava o controle do dinheiro. O Bitcoin resolve esse problema de forma inovadora: ele usa uma rede descentralizada onde todos os participantes (os "nós") têm acesso a um registro completo de todas as transações. Cada nó verifica se as transações são válidas e se a moeda não foi gasta duas vezes. Quando a maioria dos nós concorda com a validade de uma transação, ela é registrada permanentemente na blockchain. #### Por que isso é importante? Essa solução elimina a necessidade de confiar em uma única entidade para gerenciar o dinheiro, permitindo que qualquer pessoa no mundo use o Bitcoin sem precisar de permissão de terceiros. Além disso, ela garante que o sistema seja seguro e resistente a fraudes. --- ### 3. Servidor Timestamp Para assegurar que as transações sejam realizadas de forma segura e transparente, o sistema Bitcoin utiliza algo chamado de "servidor de registro de tempo" (timestamp). Esse servidor funciona como um registro público que organiza as transações em uma ordem específica. Ele faz isso agrupando várias transações em blocos e criando um código único chamado "hash". Esse hash é como uma impressão digital que representa todo o conteúdo do bloco. O hash de cada bloco é amplamente divulgado, como se fosse publicado em um jornal ou em um fórum público. Esse processo garante que cada bloco de transações tenha um registro de quando foi criado e que ele existia naquele momento. Além disso, cada novo bloco criado contém o hash do bloco anterior, formando uma cadeia contínua de blocos conectados — conhecida como blockchain. Com isso, se alguém tentar alterar qualquer informação em um bloco anterior, o hash desse bloco mudará e não corresponderá ao hash armazenado no bloco seguinte. Essa característica torna a cadeia muito segura, pois qualquer tentativa de fraude seria imediatamente detectada. O sistema de timestamps é essencial para provar a ordem cronológica das transações e garantir que cada uma delas seja única e autêntica. Dessa forma, ele reforça a segurança e a confiança na rede Bitcoin. --- ### 4. Prova-de-Trabalho Para implementar o registro de tempo distribuído no sistema Bitcoin, utilizamos um mecanismo chamado prova-de-trabalho. Esse sistema é semelhante ao Hashcash, desenvolvido por Adam Back, e baseia-se na criação de um código único, o "hash", por meio de um processo computacionalmente exigente. A prova-de-trabalho envolve encontrar um valor especial que, quando processado junto com as informações do bloco, gere um hash que comece com uma quantidade específica de zeros. Esse valor especial é chamado de "nonce". Encontrar o nonce correto exige um esforço significativo do computador, porque envolve tentativas repetidas até que a condição seja satisfeita. Esse processo é importante porque torna extremamente difícil alterar qualquer informação registrada em um bloco. Se alguém tentar mudar algo em um bloco, seria necessário refazer o trabalho de computação não apenas para aquele bloco, mas também para todos os blocos que vêm depois dele. Isso garante a segurança e a imutabilidade da blockchain. A prova-de-trabalho também resolve o problema de decidir qual cadeia de blocos é a válida quando há múltiplas cadeias competindo. A decisão é feita pela cadeia mais longa, pois ela representa o maior esforço computacional já realizado. Isso impede que qualquer indivíduo ou grupo controle a rede, desde que a maioria do poder de processamento seja mantida por participantes honestos. Para garantir que o sistema permaneça eficiente e equilibrado, a dificuldade da prova-de-trabalho é ajustada automaticamente ao longo do tempo. Se novos blocos estiverem sendo gerados rapidamente, a dificuldade aumenta; se estiverem sendo gerados muito lentamente, a dificuldade diminui. Esse ajuste assegura que novos blocos sejam criados aproximadamente a cada 10 minutos, mantendo o sistema estável e funcional. --- ### 5. Rede A rede Bitcoin é o coração do sistema e funciona de maneira distribuída, conectando vários participantes (ou nós) para garantir o registro e a validação das transações. Os passos para operar essa rede são: 1. **Transmissão de Transações**: Quando alguém realiza uma nova transação, ela é enviada para todos os nós da rede. Isso é feito para garantir que todos estejam cientes da operação e possam validá-la. 2. **Coleta de Transações em Blocos**: Cada nó agrupa as novas transações recebidas em um "bloco". Este bloco será preparado para ser adicionado à cadeia de blocos (a blockchain). 3. **Prova-de-Trabalho**: Os nós competem para resolver a prova-de-trabalho do bloco, utilizando poder computacional para encontrar um hash válido. Esse processo é como resolver um quebra-cabeça matemático difícil. 4. **Envio do Bloco Resolvido**: Quando um nó encontra a solução para o bloco (a prova-de-trabalho), ele compartilha esse bloco com todos os outros nós na rede. 5. **Validação do Bloco**: Cada nó verifica o bloco recebido para garantir que todas as transações nele contidas sejam válidas e que nenhuma moeda tenha sido gasta duas vezes. Apenas blocos válidos são aceitos. 6. **Construção do Próximo Bloco**: Os nós que aceitaram o bloco começam a trabalhar na criação do próximo bloco, utilizando o hash do bloco aceito como base (hash anterior). Isso mantém a continuidade da cadeia. #### Resolução de Conflitos e Escolha da Cadeia Mais Longa Os nós sempre priorizam a cadeia mais longa, pois ela representa o maior esforço computacional já realizado, garantindo maior segurança. Se dois blocos diferentes forem compartilhados simultaneamente, os nós trabalharão no primeiro bloco recebido, mas guardarão o outro como uma alternativa. Caso o segundo bloco eventualmente forme uma cadeia mais longa (ou seja, tenha mais blocos subsequentes), os nós mudarão para essa nova cadeia. #### Tolerância a Falhas A rede é robusta e pode lidar com mensagens que não chegam a todos os nós. Uma transação não precisa alcançar todos os nós de imediato; basta que chegue a um número suficiente deles para ser incluída em um bloco. Da mesma forma, se um nó não receber um bloco em tempo hábil, ele pode solicitá-lo ao perceber que está faltando quando o próximo bloco é recebido. Esse mecanismo descentralizado permite que a rede Bitcoin funcione de maneira segura, confiável e resiliente, sem depender de uma autoridade central. --- ### 6. Incentivo O incentivo é um dos pilares fundamentais que sustenta o funcionamento da rede Bitcoin, garantindo que os participantes (nós) continuem operando de forma honesta e contribuindo com recursos computacionais. Ele é estruturado em duas partes principais: a recompensa por mineração e as taxas de transação. #### Recompensa por Mineração Por convenção, o primeiro registro em cada bloco é uma transação especial que cria novas moedas e as atribui ao criador do bloco. Essa recompensa incentiva os mineradores a dedicarem poder computacional para apoiar a rede. Como não há uma autoridade central para emitir moedas, essa é a maneira pela qual novas moedas entram em circulação. Esse processo pode ser comparado ao trabalho de garimpeiros, que utilizam recursos para colocar mais ouro em circulação. No caso do Bitcoin, o "recurso" consiste no tempo de CPU e na energia elétrica consumida para resolver a prova-de-trabalho. #### Taxas de Transação Além da recompensa por mineração, os mineradores também podem ser incentivados pelas taxas de transação. Se uma transação utiliza menos valor de saída do que o valor de entrada, a diferença é tratada como uma taxa, que é adicionada à recompensa do bloco contendo essa transação. Com o passar do tempo e à medida que o número de moedas em circulação atinge o limite predeterminado, essas taxas de transação se tornam a principal fonte de incentivo, substituindo gradualmente a emissão de novas moedas. Isso permite que o sistema opere sem inflação, uma vez que o número total de moedas permanece fixo. #### Incentivo à Honestidade O design do incentivo também busca garantir que os participantes da rede mantenham um comportamento honesto. Para um atacante que consiga reunir mais poder computacional do que o restante da rede, ele enfrentaria duas escolhas: 1. Usar esse poder para fraudar o sistema, como reverter transações e roubar pagamentos. 2. Seguir as regras do sistema, criando novos blocos e recebendo recompensas legítimas. A lógica econômica favorece a segunda opção, pois um comportamento desonesto prejudicaria a confiança no sistema, diminuindo o valor de todas as moedas, incluindo aquelas que o próprio atacante possui. Jogar dentro das regras não apenas maximiza o retorno financeiro, mas também preserva a validade e a integridade do sistema. Esse mecanismo garante que os incentivos econômicos estejam alinhados com o objetivo de manter a rede segura, descentralizada e funcional ao longo do tempo. --- ### 7. Recuperação do Espaço em Disco Depois que uma moeda passa a estar protegida por muitos blocos na cadeia, as informações sobre as transações antigas que a geraram podem ser descartadas para economizar espaço em disco. Para que isso seja possível sem comprometer a segurança, as transações são organizadas em uma estrutura chamada "árvore de Merkle". Essa árvore funciona como um resumo das transações: em vez de armazenar todas elas, guarda apenas um "hash raiz", que é como uma assinatura compacta que representa todo o grupo de transações. Os blocos antigos podem, então, ser simplificados, removendo as partes desnecessárias dessa árvore. Apenas a raiz do hash precisa ser mantida no cabeçalho do bloco, garantindo que a integridade dos dados seja preservada, mesmo que detalhes específicos sejam descartados. Para exemplificar: imagine que você tenha vários recibos de compra. Em vez de guardar todos os recibos, você cria um documento e lista apenas o valor total de cada um. Mesmo que os recibos originais sejam descartados, ainda é possível verificar a soma com base nos valores armazenados. Além disso, o espaço ocupado pelos blocos em si é muito pequeno. Cada bloco sem transações ocupa apenas cerca de 80 bytes. Isso significa que, mesmo com blocos sendo gerados a cada 10 minutos, o crescimento anual em espaço necessário é insignificante: apenas 4,2 MB por ano. Com a capacidade de armazenamento dos computadores crescendo a cada ano, esse espaço continuará sendo trivial, garantindo que a rede possa operar de forma eficiente sem problemas de armazenamento, mesmo a longo prazo. --- ### 8. Verificação de Pagamento Simplificada É possível confirmar pagamentos sem a necessidade de operar um nó completo da rede. Para isso, o usuário precisa apenas de uma cópia dos cabeçalhos dos blocos da cadeia mais longa (ou seja, a cadeia com maior esforço de trabalho acumulado). Ele pode verificar a validade de uma transação ao consultar os nós da rede até obter a confirmação de que tem a cadeia mais longa. Para isso, utiliza-se o ramo Merkle, que conecta a transação ao bloco em que ela foi registrada. Entretanto, o método simplificado possui limitações: ele não pode confirmar uma transação isoladamente, mas sim assegurar que ela ocupa um lugar específico na cadeia mais longa. Dessa forma, se um nó da rede aprova a transação, os blocos subsequentes reforçam essa aceitação. A verificação simplificada é confiável enquanto a maioria dos nós da rede for honesta. Contudo, ela se torna vulnerável caso a rede seja dominada por um invasor. Nesse cenário, um atacante poderia fabricar transações fraudulentas que enganariam o usuário temporariamente até que o invasor obtivesse controle completo da rede. Uma estratégia para mitigar esse risco é configurar alertas nos softwares de nós completos. Esses alertas identificam blocos inválidos, sugerindo ao usuário baixar o bloco completo para confirmar qualquer inconsistência. Para maior segurança, empresas que realizam pagamentos frequentes podem preferir operar seus próprios nós, reduzindo riscos e permitindo uma verificação mais direta e confiável. --- ### 9. Combinando e Dividindo Valor No sistema Bitcoin, cada unidade de valor é tratada como uma "moeda" individual, mas gerenciar cada centavo como uma transação separada seria impraticável. Para resolver isso, o Bitcoin permite que valores sejam combinados ou divididos em transações, facilitando pagamentos de qualquer valor. #### Entradas e Saídas Cada transação no Bitcoin é composta por: - **Entradas**: Representam os valores recebidos em transações anteriores. - **Saídas**: Correspondem aos valores enviados, divididos entre os destinatários e, eventualmente, o troco para o remetente. Normalmente, uma transação contém: - Uma única entrada com valor suficiente para cobrir o pagamento. - Ou várias entradas combinadas para atingir o valor necessário. O valor total das saídas nunca excede o das entradas, e a diferença (se houver) pode ser retornada ao remetente como **troco**. #### Exemplo Prático Imagine que você tem duas entradas: 1. 0,03 BTC 2. 0,07 BTC Se deseja enviar 0,08 BTC para alguém, a transação terá: - **Entrada**: As duas entradas combinadas (0,03 + 0,07 BTC = 0,10 BTC). - **Saídas**: Uma para o destinatário (0,08 BTC) e outra como troco para você (0,02 BTC). Essa flexibilidade permite que o sistema funcione sem precisar manipular cada unidade mínima individualmente. #### Difusão e Simplificação A difusão de transações, onde uma depende de várias anteriores e assim por diante, não representa um problema. Não é necessário armazenar ou verificar o histórico completo de uma transação para utilizá-la, já que o registro na blockchain garante sua integridade. --- ### 10. Privacidade O modelo bancário tradicional oferece um certo nível de privacidade, limitando o acesso às informações financeiras apenas às partes envolvidas e a um terceiro confiável (como bancos ou instituições financeiras). No entanto, o Bitcoin opera de forma diferente, pois todas as transações são publicamente registradas na blockchain. Apesar disso, a privacidade pode ser mantida utilizando **chaves públicas anônimas**, que desvinculam diretamente as transações das identidades das partes envolvidas. #### Fluxo de Informação - No **modelo tradicional**, as transações passam por um terceiro confiável que conhece tanto o remetente quanto o destinatário. - No **Bitcoin**, as transações são anunciadas publicamente, mas sem revelar diretamente as identidades das partes. Isso é comparável a dados divulgados por bolsas de valores, onde informações como o tempo e o tamanho das negociações (a "fita") são públicas, mas as identidades das partes não. #### Protegendo a Privacidade Para aumentar a privacidade no Bitcoin, são adotadas as seguintes práticas: 1. **Chaves Públicas Anônimas**: Cada transação utiliza um par de chaves diferentes, dificultando a associação com um proprietário único. 2. **Prevenção de Ligação**: Ao usar chaves novas para cada transação, reduz-se a possibilidade de links evidentes entre múltiplas transações realizadas pelo mesmo usuário. #### Riscos de Ligação Embora a privacidade seja fortalecida, alguns riscos permanecem: - Transações **multi-entrada** podem revelar que todas as entradas pertencem ao mesmo proprietário, caso sejam necessárias para somar o valor total. - O proprietário da chave pode ser identificado indiretamente por transações anteriores que estejam conectadas. --- ### 11. Cálculos Imagine que temos um sistema onde as pessoas (ou computadores) competem para adicionar informações novas (blocos) a um grande registro público (a cadeia de blocos ou blockchain). Este registro é como um livro contábil compartilhado, onde todos podem verificar o que está escrito. Agora, vamos pensar em um cenário: um atacante quer enganar o sistema. Ele quer mudar informações já registradas para beneficiar a si mesmo, por exemplo, desfazendo um pagamento que já fez. Para isso, ele precisa criar uma versão alternativa do livro contábil (a cadeia de blocos dele) e convencer todos os outros participantes de que essa versão é a verdadeira. Mas isso é extremamente difícil. #### Como o Ataque Funciona Quando um novo bloco é adicionado à cadeia, ele depende de cálculos complexos que levam tempo e esforço. Esses cálculos são como um grande quebra-cabeça que precisa ser resolvido. - Os “bons jogadores” (nós honestos) estão sempre trabalhando juntos para resolver esses quebra-cabeças e adicionar novos blocos à cadeia verdadeira. - O atacante, por outro lado, precisa resolver quebra-cabeças sozinho, tentando “alcançar” a cadeia honesta para que sua versão alternativa pareça válida. Se a cadeia honesta já está vários blocos à frente, o atacante começa em desvantagem, e o sistema está projetado para que a dificuldade de alcançá-los aumente rapidamente. #### A Corrida Entre Cadeias Você pode imaginar isso como uma corrida. A cada bloco novo que os jogadores honestos adicionam à cadeia verdadeira, eles se distanciam mais do atacante. Para vencer, o atacante teria que resolver os quebra-cabeças mais rápido que todos os outros jogadores honestos juntos. Suponha que: - A rede honesta tem **80% do poder computacional** (ou seja, resolve 8 de cada 10 quebra-cabeças). - O atacante tem **20% do poder computacional** (ou seja, resolve 2 de cada 10 quebra-cabeças). Cada vez que a rede honesta adiciona um bloco, o atacante tem que "correr atrás" e resolver mais quebra-cabeças para alcançar. #### Por Que o Ataque Fica Cada Vez Mais Improvável? Vamos usar uma fórmula simples para mostrar como as chances de sucesso do atacante diminuem conforme ele precisa "alcançar" mais blocos: P = (q/p)^z - **q** é o poder computacional do atacante (20%, ou 0,2). - **p** é o poder computacional da rede honesta (80%, ou 0,8). - **z** é a diferença de blocos entre a cadeia honesta e a cadeia do atacante. Se o atacante está 5 blocos atrás (z = 5): P = (0,2 / 0,8)^5 = (0,25)^5 = 0,00098, (ou, 0,098%) Isso significa que o atacante tem menos de 0,1% de chance de sucesso — ou seja, é muito improvável. Se ele estiver 10 blocos atrás (z = 10): P = (0,2 / 0,8)^10 = (0,25)^10 = 0,000000095, (ou, 0,0000095%). Neste caso, as chances de sucesso são praticamente **nulas**. #### Um Exemplo Simples Se você jogar uma moeda, a chance de cair “cara” é de 50%. Mas se precisar de 10 caras seguidas, sua chance já é bem menor. Se precisar de 20 caras seguidas, é quase impossível. No caso do Bitcoin, o atacante precisa de muito mais do que 20 caras seguidas. Ele precisa resolver quebra-cabeças extremamente difíceis e alcançar os jogadores honestos que estão sempre à frente. Isso faz com que o ataque seja inviável na prática. #### Por Que Tudo Isso é Seguro? - **A probabilidade de sucesso do atacante diminui exponencialmente.** Isso significa que, quanto mais tempo passa, menor é a chance de ele conseguir enganar o sistema. - **A cadeia verdadeira (honesta) está protegida pela força da rede.** Cada novo bloco que os jogadores honestos adicionam à cadeia torna mais difícil para o atacante alcançar. #### E Se o Atacante Tentar Continuar? O atacante poderia continuar tentando indefinidamente, mas ele estaria gastando muito tempo e energia sem conseguir nada. Enquanto isso, os jogadores honestos estão sempre adicionando novos blocos, tornando o trabalho do atacante ainda mais inútil. Assim, o sistema garante que a cadeia verdadeira seja extremamente segura e que ataques sejam, na prática, impossíveis de ter sucesso. --- ### 12. Conclusão Propusemos um sistema de transações eletrônicas que elimina a necessidade de confiança, baseando-se em assinaturas digitais e em uma rede peer-to-peer que utiliza prova de trabalho. Isso resolve o problema do gasto duplo, criando um histórico público de transações imutável, desde que a maioria do poder computacional permaneça sob controle dos participantes honestos. A rede funciona de forma simples e descentralizada, com nós independentes que não precisam de identificação ou coordenação direta. Eles entram e saem livremente, aceitando a cadeia de prova de trabalho como registro do que ocorreu durante sua ausência. As decisões são tomadas por meio do poder de CPU, validando blocos legítimos, estendendo a cadeia e rejeitando os inválidos. Com este mecanismo de consenso, todas as regras e incentivos necessários para o funcionamento seguro e eficiente do sistema são garantidos. --- Faça o download do whitepaper original em português: https://bitcoin.org/files/bitcoin-paper/bitcoin_pt_br.pdf

@ 3f770d65:7a745b24

The recent shutdown of TikTok in the United States due to a potential government ban serves as a stark reminder how fragile centralized platforms truly are under the surface. While these platforms offer convenience, a more polished user experience, and connectivity, they are ultimately beholden to governments, corporations, and other authorities. This makes them vulnerable to censorship, regulation, and outright bans. In contrast, Nostr represents a shift in how we approach online communication and content sharing. Built on the principles of decentralization and user choice, Nostr cannot be banned, because it is not a platform—it is a protocol. **PROTOCOLS, NOT PLATFORMS.** At the heart of Nostr's philosophy is **user choice**, a feature that fundamentally sets it apart from legacy platforms. In centralized systems, the user experience is dictated by a single person or governing entity. If the platform decides to filter, censor, or ban specific users or content, individuals are left with little action to rectify the situation. They must either accept the changes or abandon the platform entirely, often at the cost of losing their social connections, their data, and their identity. What's happening with TikTok could never happen on Nostr. With Nostr, the dynamics are completely different. Because it is a protocol, not a platform, no single entity controls the ecosystem. Instead, the protocol enables a network of applications and relays that users can freely choose from. If a particular application or relay implements policies that a user disagrees with, such as censorship, filtering, or even government enforced banning, they are not trapped or abandoned. They have the freedom to move to another application or relay with minimal effort. **THIS IS POWERFUL.** Take, for example, the case of a relay that decides to censor specific content. On a legacy platform, this would result in frustration and a loss of access for users. On Nostr, however, users can simply connect to a different relay that does not impose such restrictions. Similarly, if an application introduces features or policies that users dislike, they can migrate to a different application that better suits their preferences, all while retaining their identity and social connections. The same principles apply to government bans and censorship. A government can ban a specific application or even multiple applications, just as it can block one relay or several relays. China has implemented both tactics, yet Chinese users continue to exist and actively participate on Nostr, demonstrating Nostr's ability to resistant censorship. How? Simply, it turns into a game of whack-a-mole. When one relay is censored, another quickly takes its place. When one application is banned, another emerges. Users can also bypass these obstacles by running their own relays and applications directly from their homes or personal devices, eliminating reliance on larger entities or organizations and ensuring continuous access. **AGAIN, THIS IS POWERUFL.** Nostr's open and decentralized design makes it resistant to the kinds of government intervention that led to TikTok's outages this weekend and potential future ban in the next 90 days. There is no central server to target, no company to regulate, and no single point of failure. (Insert your CEO jokes here). As long as there are individuals running relays and applications, users continue creating notes and sending zaps. Platforms like TikTok can be silenced with the stroke of a pen, leaving millions of users disconnected and abandoned. Social communication should not be silenced so incredibly easily. No one should have that much power over social interactions. Will we on-board a massive wave of TikTokers in the coming hours or days? I don't know. TikTokers may not be ready for Nostr yet, and honestly, Nostr may not be ready for them either. The ecosystem still lacks the completely polished applications, tools, and services they’re accustomed to. This is where we say "we're still early". They may not be early adopters like the current Nostr user base. Until we bridge that gap, they’ll likely move to the next centralized platform, only to face another government ban or round of censorship in the future. But eventually, there will come a tipping point, a moment when they’ve had enough. When that time comes, I hope we’re prepared. If we’re not, we risk missing a tremendous opportunity to onboard people who genuinely need Nostr’s freedom. Until then, to all of the Nostr developers out there, keep up the great work and keep building. Your hard work and determination is needed. ###

@ cff1720e:15c7e2b2

**Einleitung**\ \ Schwierige Dinge einfach zu erklären ist der Anspruch von ELI5 (explain me like I'm 5). Das ist in unserer hoch technisierten Welt dringend erforderlich, denn nur mit dem Verständnis der Technologien können wir sie richtig einsetzen und weiter entwickeln.\ Ich starte meine Serie mit Nostr, einem relativ neuen Internet-Protokoll. Was zum Teufel ist ein Internet-Protokoll? Formal beschrieben sind es internationale Standards, die dafür sorgen, dass das Internet seit über 30 Jahren ziemlich gut funktioniert. Es ist die Sprache, in der sich die Rechner miteinander unterhalten und die auch Sie täglich nutzen, vermutlich ohne es bewusst wahrzunehmen. http(s) transportiert ihre Anfrage an einen Server (z.B. Amazon), und html sorgt dafür, dass aus den gelieferten Daten eine schöne Seite auf ihrem Bildschirm entsteht. Eine Mail wird mit smtp an den Mailserver gesendet und mit imap von ihm abgerufen, und da alle den Standard verwenden, funktioniert das mit jeder App auf jedem Betriebssystem und mit jedem Mail-Provider. Und mit einer Mail-Adresse wie <roland@pareto.space> können sie sogar jederzeit umziehen, egal wohin. **Cool, das ist state of the art!** Aber warum funktioniert das z.B. bei Chat nicht, gibt es da kein Protokoll? Doch, es heißt IRC (Internet Relay Chat → merken sie sich den Namen), aber es wird so gut wie nicht verwendet. Die Gründe dafür sind nicht technischer Natur, vielmehr wurden mit Apps wie Facebook, Twitter, WhatsApp, Telegram, Instagram, TikTok u.a. bewusst Inkompatibilitäten und Nutzerabhängigkeiten geschaffen um Profite zu maximieren.  **Warum Nostr?** Da das Standard-Protokoll nicht genutzt wird, hat jede App ihr eigenes, und wir brauchen eine handvoll Apps um uns mit allen Bekannten auszutauschen. Eine Mobilfunknummer ist Voraussetzung für jedes Konto, damit können die App-Hersteller die Nutzer umfassend tracken und mit dem Verkauf der Informationen bis zu 30 USD je Konto und Monat verdienen. Der Nutzer ist nicht mehr Kunde, er ist das Produkt! Der Werbe-SPAM ist noch das kleinste Problem bei diesem Geschäftsmodell. Server mit Millionen von Nutzerdaten sind ein “honey pot”, dementsprechend oft werden sie gehackt und die Zugangsdaten verkauft. 2024 wurde auch der Twitter-Account vom damaligen Präsidenten Joe Biden gehackt, niemand wusste mehr wer die Nachrichten verfasst hat (vorher auch nicht), d.h. die Authentizität der Inhalte ist bei keinem dieser Anbieter gewährleistet. Im selben Jahr wurde der Telegram-Gründer in Frankreich in Beugehaft genommen, weil er sich geweigert hatte Hintertüren in seine Software einzubauen. Nun kann zum Schutz **"unserer Demokratie”** praktisch jeder mitlesen, was sie mit wem an Informationen austauschen, z.B. darüber welches Shampoo bestimmte Politiker verwenden.   Und wer tatsächlich glaubt er könne Meinungsfreiheit auf sozialen Medien praktizieren, findet sich schnell in der Situation von Donald Trump wieder (seinerzeit amtierender Präsident), dem sein Twitter-Konto 2021 abgeschaltet wurde (Cancel-Culture). Die Nutzerdaten, also ihr Profil, ihre Kontakte, Dokumente, Bilder, Videos und Audiofiles - gehören ihnen ohnehin nicht mehr sondern sind Eigentum des Plattform-Betreibers; lesen sie sich mal die AGB's durch. Aber nein, keine gute Idee, das sind hunderte Seiten und sie werden permanent geändert. Alle nutzen also Apps, deren Technik sie nicht verstehen, deren Regeln sie nicht kennen, wo sie keine Rechte haben und die ihnen die Resultate ihres Handelns stehlen. Was würde wohl der Fünfjährige sagen, wenn ihm seine ältere Schwester anbieten würde, alle seine Spielzeuge zu “verwalten” und dann auszuhändigen wenn er brav ist? “Du spinnst wohl”, und damit beweist der Knirps mehr Vernunft als die Mehrzahl der Erwachsenen. \ \ **Resümee:** keine Standards, keine Daten, keine Rechte = keine Zukunft!  \ **Wie funktioniert Nostr?** Die Entwickler von Nostr haben erkannt dass sich das Server-Client-Konzept in ein Master-Slave-Konzept verwandelt hatte. Der Master ist ein Synonym für Zentralisierung und wird zum **“single point of failure”**, der zwangsläufig Systeme dysfunktional macht. In einem verteilten Peer2Peer-System gibt es keine Master mehr sondern nur gleichberechtigte Knoten (Relays), auf denen die Informationen gespeichert werden. Indem man Informationen auf mehreren Relays redundant speichert, ist das System in jeglicher Hinsicht resilienter. Nicht nur die Natur verwendet dieses Prinzip seit Jahrmillionen erfolgreich, auch das Internet wurde so konzipiert (das ARPAnet wurde vom US-Militär für den Einsatz in Kriegsfällen unter massiven Störungen entwickelt). Alle Nostr-Daten liegen auf Relays und der Nutzer kann wählen zwischen öffentlichen (zumeist kostenlosen) und privaten Relays, z.B. für geschlossene Gruppen oder zum Zwecke von Daten-Archivierung. Da Dokumente auf mehreren Relays gespeichert sind, werden statt URL's (Locator) eindeutige Dokumentnamen (URI's = Identifier) verwendet, broken Links sind damit Vergangenheit und Löschungen / Verluste ebenfalls.\ \ Jedes Dokument (Event genannt) wird vom Besitzer signiert, es ist damit authentisch und fälschungssicher und kann nur vom Ersteller gelöscht werden. Dafür wird ein Schlüsselpaar verwendet bestehend aus privatem (nsec) und öffentlichem Schlüssel (npub) wie aus der Mailverschlüsselung (PGP) bekannt. Das repräsentiert eine Nostr-Identität, die um Bild, Namen, Bio und eine lesbare Nostr-Adresse ergänzt werden kann (z.B. <roland@pareto.space> ), mehr braucht es nicht um alle Ressourcen des Nostr-Ökosystems zu nutzen. Und das besteht inzwischen aus über hundert Apps mit unterschiedlichen Fokussierungen, z.B. für persönliche verschlüsselte Nachrichten (DM → OxChat), Kurznachrichten (Damus, Primal), Blogbeiträge (Pareto), Meetups (Joinstr), Gruppen (Groups), Bilder (Olas), Videos (Amethyst), Audio-Chat (Nostr Nests), Audio-Streams (Tunestr), Video-Streams (Zap.Stream), Marktplätze (Shopstr) u.v.a.m. Die Anmeldung erfolgt mit einem Klick (single sign on) und den Apps stehen ALLE Nutzerdaten zur Verfügung (Profil, Daten, Kontakte, Social Graph → Follower, Bookmarks, Comments, etc.), im Gegensatz zu den fragmentierten Datensilos der Gegenwart.\ \ **Resümee:** ein offener Standard, alle Daten, alle Rechte = große Zukunft!  \ **Warum ist Nostr die Zukunft des Internet?** “Baue Dein Haus nicht auf einem fremden Grundstück” gilt auch im Internet - für alle App-Entwickler, Künstler, Journalisten und Nutzer, denn auch ihre Daten sind werthaltig. Nostr garantiert das Eigentum an den Daten, und überwindet ihre Fragmentierung. Weder die Nutzung noch die kreativen Freiheiten werden durch maßlose Lizenz- und Nutzungsbedingungen eingeschränkt. Aus passiven Nutzern werden durch Interaktion aktive Teilnehmer, Co-Creatoren in einer Sharing-Ökonomie **(Value4Value)**. OpenSource schafft endlich wieder Vertrauen in die Software und ihre Anbieter. Offene Standards ermöglichen den Entwicklern mehr Kooperation und schnellere Entwicklung, für die Anwender garantieren sie Wahlfreiheit. Womit wir letztmalig zu unserem Fünfjährigen zurückkehren. Kinder lieben Lego über alles, am meisten die Maxi-Box “Classic”, weil sie damit ihre Phantasie im Kombinieren voll ausleben können. Erwachsene schenken ihnen dann die viel zu teuren Themenpakete, mit denen man nur eine Lösung nach Anleitung bauen kann. “Was stimmt nur mit meinen Eltern nicht, wann sind die denn falsch abgebogen?" fragt sich der Nachwuchs zu Recht. Das Image lässt sich aber wieder aufpolieren, wenn sie ihren Kindern Nostr zeigen, denn die Vorteile verstehen sogar Fünfjährige.  \ **Das neue Internet ist dezentral. Das neue Internet ist selbstbestimmt. Nostr ist das neue Internet.** <https://nostr.net/> \ <https://start.njump.me/> **Hier das Interview zum Thema mit Radio Berliner Morgenröte** <https://www.podbean.com/ew/pb-yxc36-17bb4be>

@ 9e69e420:d12360c2

A new report from the National Sports Shooting Foundation (NSSF) shows that civilian firearm possession exceeded 490 million in 2022. The total from 1990 to 2022 is estimated at 491.3 million firearms. In 2022, over ten million firearms were domestically produced, leading to a total of 16,045,911 firearms available in the U.S. market. Of these, 9,873,136 were handguns, 4,195,192 were rifles, and 1,977,583 were shotguns. Handgun availability aligns with the concealed carry and self-defense market, as all states allow concealed carry, with 29 having constitutional carry laws.

@ 6389be64:ef439d32

## Black Locust can grow up to 170 ft tall ## Grows 3-4 ft. per year ## Native to North America ## Cold hardy in zones 3 to 8  ## Firewood - BLT wood, on a pound for pound basis is roughly half that of Anthracite Coal - Since its growth is fast, firewood can be plentiful ## Timber  - Rot resistant due to a naturally produced robinin in the wood - 100 year life span in full soil contact! (better than cedar performance) - Fence posts - Outdoor furniture - Outdoor decking - Sustainable due to its fast growth and spread - Can be coppiced (cut to the ground) - Can be pollarded (cut above ground) - Its dense wood makes durable tool handles, boxes (tool), and furniture - The wood is tougher than hickory, which is tougher than hard maple, which is tougher than oak. -  A very low rate of expansion and contraction - Hardwood flooring - The highest tensile beam strength of any American tree - The wood is beautiful ## Legume - Nitrogen fixer - Fixes the same amount of nitrogen per acre as is needed for 200-bushel/acre corn - Black walnuts inter-planted with locust as “nurse” trees were shown to rapidly increase their growth [[Clark, Paul M., and Robert D. Williams. (1978) Black walnut growth increased when interplanted with nitrogen-fixing shrubs and trees. Proceedings of the Indiana Academy of Science, vol. 88, pp. 88-91.]] ## Bees  - The edible flower clusters are also a top food source for honey bees ## Shade Provider  - Its light, airy overstory provides dappled shade - Planted on the west side of a garden it provides relief during the hottest part of the day - (nitrogen provider) - Planted on the west side of a house, its quick growth soon shades that side from the sun ## Wind-break  - Fast growth plus it's feathery foliage reduces wind for animals, crops, and shelters ## Fodder - Over 20% crude protein - 4.1 kcal/g of energy - Baertsche, S.R, M.T. Yokoyama, and J.W. Hanover (1986) Short rotation, hardwood tree biomass as potential ruminant feed-chemical composition, nylon bag ruminal degradation and ensilement of selected species. J. Animal Sci. 63 2028-2043

@ 06639a38:655f8f71

A while back I shared this note via Nostr: [https://njump.me/a0da4693dc761c649e46606ba4cc11cd05afbed2d7c763775d7ba29a473cbed3](https://njump.me/a0da4693dc761c649e46606ba4cc11cd05afbed2d7c763775d7ba29a473cbed3) > I feel I need to ventilate some things I'm struggling with. As a indiepreneur I don't have many professionals around me with who I can share my daily struggles which I'm handling now. I'm aware it's a sort of a luxury position where the current fricton is coming from. It's because I've said too much yes to some responsabilties. I'm managing 4 client (Drupal) projects at this moment and all of them are asking for decent amount of my attention. Integrating new features, updating existing features, questions how things work, bugfixes etc. Normally their demand of them is steady. But as always, at the end of the year things are stacking up. It's no surprise that you can't manage their demands so it's the expection of my output to them I have to manage. It's the output I create for the value I deliver. Especially one project is getting all of my attention because I'm building a complete new commerce rental system with Drupal for campers. There is a deadline involved there, I've one month left to build it and have it tested.   > For me it's very challenging to manage those expectations and basicly saying no to things in a friendly way. But offcourse, this also takes time... > > With this said, there is another project which is not actively demanding anything from me (it's not a kind of a customer client): Nostr-PHP. My work pace on this project is lacking, but it's the damn thing I love the most to work on 💜 > > So what is this? What do I feel? > It feels like cognitive dissonation. If I follow my intrinsic motivation I can work on Nostr-PHP and other Nostr stuff for whole days. If I follow my ratio, it's all the client work what has to be done (and is mostly also paying the bills). > > Anyway, now I ventilated this it's time to go back building stuff ⚒️ ⚒️ ⚒️ > One thing I know of myself is that when the pressure is really high, I'm able to finish stuff rapidly for a short period of time.  Since then I made quite some hours on one specific project building out a commerce rental platform with Drupal. Progress is made and I'm already quite proud on the achievements there. Also the client is happy with the results so far. As things evolve and are being tested, new insights popup which result in adjustments in the features made and the wishlist of new features grow. To me that's natural if you're building a custom solution. But this doesn't change the challenge I mentioned earlier, managing expections and decide to what I will spent my attention to.  With that said, the development for Nostr-PHP library pretty much halted since december. So I decided to ask OpenSats to pause my grant for 3 months, so I can finish up the client-work without guilty feelings. My plan is to pick up the development again around March.  At last, let me sum up the the things I've done in week 48 and 49 in 2024: **Nostr-PHP** * Release 1.5.1 [https://github.com/nostrver-se/nostr-php/releases/tag/1.5.1](https://github.com/nostrver-se/nostr-php/releases/tag/1.5.1) * Thanks for this compliment Prolic (developer of Flutr) [https://njump.me/nevent1qvzqqqqqqypzqwuvj7hf9phszffuf7ydgtgkapvv0jf9zw4l9uuz2xhlwy63f08xqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg4waehxw309aex2mrp0yhxummnw3ezucn89uqzp94nzvmh7nlh3qte8g4g2kz075pqy6gz837y0emeqc9m8l4dlpl672l3gr](https://njump.me/nevent1qvzqqqqqqypzqwuvj7hf9phszffuf7ydgtgkapvv0jf9zw4l9uuz2xhlwy63f08xqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg4waehxw309aex2mrp0yhxummnw3ezucn89uqzp94nzvmh7nlh3qte8g4g2kz075pqy6gz837y0emeqc9m8l4dlpl672l3gr) * Collaboration efforts on encoding / decoding TLV entries in NIP-19: [https://njump.me/nevent1qvzqqqqqqypzqpnrnguxe8qszsshvgkvhn6qjzxy7xsvx03rlrtddr62haj4lrm3qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qpqxh039ng4nr2w5q6np5gzhpfjjgxd4gtkraxeuv9ew5sve7pytawq8l5dzr](https://njump.me/nevent1qvzqqqqqqypzqpnrnguxe8qszsshvgkvhn6qjzxy7xsvx03rlrtddr62haj4lrm3qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qpqxh039ng4nr2w5q6np5gzhpfjjgxd4gtkraxeuv9ew5sve7pytawq8l5dzr) * Working on a fix for a lib\_gmp issue with the latest PHP releases: * [https://github.com/nostrver-se/nostr-php/pull/71](https://github.com/nostrver-se/nostr-php/pull/71) * [https://github.com/nostrver-se/nostr-php/issues/75](https://github.com/nostrver-se/nostr-php/issues/75) * [https://github.com/nostrver-se/nostr-php/pull/76](https://github.com/nostrver-se/nostr-php/pull/76) * Merged [https://github.com/nostrver-se/nostr-php/pull/76](https://github.com/nostrver-se/nostr-php/pull/76) and created a `1.5.2` release with this change * [https://github.com/nostrver-se/nostr-php/releases/tag/1.5.2](https://github.com/nostrver-se/nostr-php/releases/tag/1.5.2) **Other stuff** * Wrote and published my second 90-days progress report for OpenSats. [https://nostrver.se/blog/nostr-php-helper-library-90-day-opensats-report-2](https://nostrver.se/blog/nostr-php-helper-library-90-day-opensats-report-2)

@ 1bda7e1f:bb97c4d9

### Tldr - Nostr is an open and interoperable protocol - You can integrate it with workflow automation tools to augment your experience - n8n is a great low/no-code workflow automation tool which you can host yourself - Nostrobots allows you to integrate Nostr into n8n - In this blog I create some workflow automations for Nostr - A simple form to delegate posting notes - Push notifications for mentions on multiple accounts - Push notifications for your favourite accounts when they post a note - All workflows are provided as open source with MIT license for you to use ### Inter-op All The Things Nostr is a new open social protocol for the internet. This open nature exciting because of the opportunities for interoperability with other technologies. In [Using NFC Cards with Nostr]() I explored the `nostr:` URI to launch Nostr clients from a card tap. The interoperability of Nostr doesn't stop there. The internet has many super-powers, and Nostr is open to all of them. Simply, there's no one to stop it. There is no one in charge, there are no permissioned APIs, and there are no risks of being de-platformed. If you can imagine technologies that would work well with Nostr, then any and all of them can ride on or alongside Nostr rails. My mental model for why this is special is Google Wave ~2010. Google Wave was to be the next big platform. Lars was running it and had a big track record from Maps. I was excited for it. Then, Google pulled the plug. And, immediately all the time and capital invested in understanding and building on the platform was wasted. This cannot happen to Nostr, as there is no one to pull the plug, and maybe even no plug to pull. So long as users demand Nostr, Nostr will exist, and that is a pretty strong guarantee. It makes it worthwhile to invest in bringing Nostr into our other applications. All we need are simple ways to plug things together. ### Nostr and Workflow Automation Workflow automation is about helping people to streamline their work. As a user, the most common way I achieve this is by connecting disparate systems together. By setting up one system to trigger another or to move data between systems, I can solve for many different problems and become way more effective. #### n8n for workflow automation Many workflow automation tools exist. My favourite is [n8n](https://n8n.io/). n8n is a low/no-code workflow automation platform which allows you to build all kinds of workflows. You can use it for free, you can self-host it, it has a user-friendly UI and useful API. Vs Zapier it can be far more elaborate. Vs Make.com I find it to be more intuitive in how it abstracts away the right parts of the code, but still allows you to code when you need to. Most importantly you can plug anything into n8n: You have built-in nodes for specific applications. HTTP nodes for any other API-based service. And community nodes built by individual community members for any other purpose you can imagine. #### Eating my own dogfood It's very clear to me that there is a big design space here just demanding to be explored. If you could integrate Nostr with anything, what would you do? In my view the best way for anyone to start anything is by solving their own problem first (aka "scratching your own itch" and "eating your own dogfood"). As I get deeper into Nostr I find myself controlling multiple Npubs – to date I have a personal Npub, a brand Npub for a community I am helping, an AI assistant Npub, and various testing Npubs. I need ways to delegate access to those Npubs without handing over the keys, ways to know if they're mentioned, and ways to know if they're posting. I can build workflows with n8n to solve these issues for myself to start with, and keep expanding from there as new needs come up. ### Running n8n with Nostrobots I am mostly non-technical with a very helpful AI. To set up n8n to work with Nostr and operate these workflows should be possible for anyone with basic technology skills. - I have a cheap VPS which currently runs my [HAVEN Nostr Relay](https://rodbishop.npub.pro/post/8ca68889/) and [Albyhub Lightning Node](https://rodbishop.npub.pro/post/setting-up-payments-on-nostr-7o6ls7/) in Docker containers, - My objective was to set up n8n to run alongside these in a separate Docker container on the same server, install the required nodes, and then build and host my workflows. #### Installing n8n Self-hosting n8n could not be easier. I followed n8n's [Docker-Compose installation docs](https://docs.n8n.io/hosting/installation/server-setups/docker-compose/)– - Install Docker and Docker-Compose if you haven't already, - Create your ``docker-compose.yml`` and `.env` files from the docs, - Create your data folder `sudo docker volume create n8n_data`, - Start your container with `sudo docker compose up -d`, - Your n8n instance should be online at port `5678`. n8n is free to self-host but does require a license. Enter your credentials into n8n to get your free license key. You should now have access to the Workflow dashboard and can create and host any kind of workflows from there. #### Installing Nostrobots To integrate n8n nicely with Nostr, I used the [Nostrobots](https://github.com/ocknamo/n8n-nodes-nostrobots?tab=readme-ov-file) community node by [Ocknamo](nostr:npub1y6aja0kkc4fdvuxgqjcdv4fx0v7xv2epuqnddey2eyaxquznp9vq0tp75l). In n8n parlance a "node" enables certain functionality as a step in a workflow e.g. a "set" node sets a variable, a "send email" node sends an email. n8n comes with all kinds of "official" nodes installed by default, and Nostr is not amongst them. However, n8n also comes with a framework for community members to create their own "community" nodes, which is where Nostrobots comes in. You can only use a community node in a self-hosted n8n instance (which is what you have if you are running in Docker on your own server, but this limitation does prevent you from using n8n's own hosted alternative). To install a community node, [see n8n community node docs](https://docs.n8n.io/integrations/community-nodes/installation/gui-install/). From your workflow dashboard– - Click the "..." in the bottom left corner beside your username, and click "settings", - Cilck "community nodes" left sidebar, - Click "Install", - Enter the "npm Package Name" which is `n8n-nodes-nostrobots`, - Accept the risks and click "Install", - Nostrobots is now added to your n8n instance. #### Using Nostrobots Nostrobots gives you nodes to help you build Nostr-integrated workflows– - **Nostr Write** – for posting Notes to the Nostr network, - **Nostr Read** – for reading Notes from the Nostr network, and - **Nostr Utils** – for performing certain conversions you may need (e.g. from bech32 to hex). Nostrobots has [good documentation](https://github.com/ocknamo/n8n-nodes-nostrobots?tab=readme-ov-file) on each node which focuses on simple use cases. Each node has a "convenience mode" by default. For example, the "Read" Node by default will fetch Kind 1 notes by a simple filter, in Nostrobots parlance a "Strategy". For example, with Strategy set to "Mention" the node will accept a pubkey and fetch all Kind 1 notes that Mention the pubkey within a time period. This is very good for quick use. What wasn't clear to me initially (until Ocknamo helped me out) is that advanced use cases are also possible. Each node also has an advanced mode. For example, the "Read" Node can have "Strategy" set to "RawFilter(advanced)". Now the node will accept json (anything you like that complies with [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md)). You can use this to query Notes (Kind 1) as above, and also Profiles (Kind 0), Follow Lists (Kind 3), Reactions (Kind 7), Zaps (Kind 9734/9735), and anything else you can think of. #### Creating and adding workflows With n8n and Nostrobots installed, you can now create or add any kind of Nostr Workflow Automation. - Click "Add workflow" to go to the workflow builder screen, - If you would like to build your own workflow, you can start with adding any node. Click "+" and see what is available. Type "Nostr" to explore the Nostrobots nodes you have added, - If you would like to add workflows that someone else has built, click "..." in the top right. Then click "import from URL" and paste in the URL of any workflow you would like to use (including the ones I share later in this article). ### Nostr Workflow Automations It's time to build some things! #### A simple form to post a note to Nostr I started very simply. I needed to delegate the ability to post to Npubs that I own in order that a (future) team can test things for me. I don't want to worry about managing or training those people on how to use keys, and I want to revoke access easily. I needed a basic form with credentials that posted a Note. For this I can use a very simple workflow– - **A n8n Form node** – Creates a form for users to enter the note they wish to post. Allows for the form to be protected by a username and password. This node is the workflow "trigger" so that the workflow runs each time the form is submitted. - **A Set node** – Allows me to set some variables, in this case I set the relays that I intend to use. I typically add a Set node immediately following the trigger node, and put all the variables I need in this. It helps to make the workflows easier to update and maintain. - **A Nostr Write node** (from Nostrobots) – Writes a Kind-1 note to the Nostr network. It accepts Nostr credentials, the output of the Form node, and the relays from the Set node, and posts the Note to those relays. Once the workflow is built, you can test it with the testing form URL, and set it to "Active" to use the production form URL. That's it. You can now give posting access to anyone for any Npub. To revoke access, simply change the credentials or set to workflow to "Inactive". It may also be the world's simplest Nostr client. You can find the [Nostr Form to Post a Note workflow here](https://github.com/r0d8lsh0p/nostr-n8n/blob/main/Nostr_Form_to_Post_a_Note.json). #### Push notifications on mentions and new notes One of the things Nostr is not very good at is push notifications. Furthermore I have some unique itches to scratch. I want– - **To make sure I never miss a note addressed to any of my Npubs** – For this I want a push notification any time any Nostr user mentions any of my Npubs, - **To make sure I always see all notes from key accounts** – For this I need a push notification any time any of my Npubs post any Notes to the network, - **To get these notifications on all of my devices** – Not just my phone where my Nostr regular client lives, but also on each of my laptops to suit wherever I am working that day. I needed to build a Nostr push notifications solution. To build this workflow I had to string a few ideas together– - **Triggering the node on a schedule** – Nostrobots does not include a trigger node. As every workflow starts with a trigger we needed a different method. I elected to run the workflow on a schedule of every 10-minutes. Frequent enough to see Notes while they are hot, but infrequent enough to not burden public relays or get rate-limited, - **Storing a list of Npubs in a Nostr list** – I needed a way to store the list of Npubs that trigger my notifications. I initially used an array defined in the workflow, this worked fine. Then I decided to try Nostr lists ([NIP-51, kind 30000](https://github.com/nostr-protocol/nips/blob/master/51.md)). By defining my list of Npubs as a list published to Nostr I can control my list from within a Nostr client (e.g. [Listr.lol](https://listr.lol/npub1r0d8u8mnj6769500nypnm28a9hpk9qg8jr0ehe30tygr3wuhcnvs4rfsft) or [Nostrudel.ninja](https://nostrudel.ninja/#/lists)). Not only does this "just work", but because it's based on Nostr lists automagically Amethyst client allows me to browse that list as a Feed, and everyone I add gets notified in their Mentions, - **Using specific relays** – I needed to query the right relays, including my own HAVEN relay inbox for notes addressed to me, and wss://purplepag.es for Nostr profile metadata, - **Querying Nostr events** (with Nostrobots) – I needed to make use of many different Nostr queries and use quite a wide range of what Nostrobots can do– - I read the EventID of my Kind 30000 list, to return the desired pubkeys, - For notifications on mentions, I read all Kind 1 notes that mention that pubkey, - For notifications on new notes, I read all Kind 1 notes published by that pubkey, - Where there are notes, I read the Kind 0 profile metadata event of that pubkey to get the displayName of the relevant Npub, - I transform the EventID into a Nevent to help clients find it. - **Using the Nostr URI** – As I did with my NFC card article, I created a link with the `nostr:` URI prefix so that my phone's native client opens the link by default, - **Push notifications solution** – I needed a push notifications solution. I found many with n8n integrations and chose to go with [Pushover](https://pushover.net/) which supports all my devices, has a free trial, and is unfairly cheap with a $5-per-device perpetual license. Once the workflow was built, lists published, and Pushover installed on my phone, I was fully set up with push notifications on Nostr. I have used these workflows for several weeks now and made various tweaks as I went. They are feeling robust and I'd welcome you to give them a go. You can find the [Nostr Push Notification If Mentioned here](https://github.com/r0d8lsh0p/nostr-n8n/blob/main/Nostr_Push_Notify_If_Mentioned.json) and [If Posts a Note here](https://github.com/r0d8lsh0p/nostr-n8n/blob/main/Nostr_Push_Notify_If_Post_a_Note.json). In speaking with other Nostr users while I was building this, there are all kind of other needs for push notifications too – like on replies to a certain bookmarked note, or when a followed Npub starts streaming on zap.stream. These are all possible. #### Use my workflows I have open sourced all my workflows at my [Github](https://github.com/r0d8lsh0p/nostr-n8n) with MIT license and tried to write complete docs, so that you can import them into your n8n and configure them for your own use. To import any of my workflows– - Click on the workflow of your choice, e.g. "[Nostr_Push_Notify_If_Mentioned.json](https://github.com/r0d8lsh0p/nostr-n8n/blob/main/Nostr_Push_Notify_If_Mentioned.json "Nostr_Push_Notify_If_Mentioned.json")", - Click on the "raw" button to view the raw JSON, ex any Github page layout, - Copy that URL, - Enter that URL in the "import from URL" dialog [mentioned above](#creating-and-adding-workflows). To configure them– - Prerequisites, credentials, and variables are all stated, - In general any variables required are entered into a Set Node that follows the trigger node, - Pushover has some extra setup but is very straightforward and documented in the workflow. ### What next? Over my first four blogs I explored creating a good Nostr setup with [Vanity Npub](https://rodbishop.npub.pro/post/mining-your-vanity-pubkey-4iupbf/), [Lightning Payments](https://rodbishop.npub.pro/post/setting-up-payments-on-nostr-7o6ls7/), [Nostr Addresses at Your Domain](https://rodbishop.npub.pro/post/ee8a46bc/), and [Personal Nostr Relay](https://rodbishop.npub.pro/post/8ca68889/). Then in my latest two blogs I explored different types of interoperability [with NFC cards](https://rodbishop.npub.pro/post/edde8387/) and now n8n Workflow Automation. Thinking ahead n8n can power any kind of interoperability between Nostr and any other legacy technology solution. On my mind as I write this: - Further enhancements to posting and delegating solutions and forms (enhanced UI or different note kinds), - Automated or scheduled posting (such as auto-liking everything [Lyn Alden](nostr:npub1a2cww4kn9wqte4ry70vyfwqyqvpswksna27rtxd8vty6c74era8sdcw83a) posts), - Further enhancements to push notifications, on new and different types of events (such as notifying me when I get a new follower, on replies to certain posts, or when a user starts streaming), - All kinds of bridges, such as bridging notes to and from Telegram, Slack, or Campfire. Or bridging RSS or other event feeds to Nostr, - All kinds of other automation (such as [BlackCoffee](nostr:npub1dqepr0g4t3ahvnjtnxazvws4rkqjpxl854n29wcew8wph0fmw90qlsmmgt) [controlling a coffee machine](https://primal.net/e/note16fzhh5yfc3u4kufx0mck63tsfperdrlpp96am2lmq066cnuqutds8retc3)), - All kinds of AI Assistants and Agents, In fact I have already released an open source workflow for an [AI Assistant](https://primal.net/p/npub1ahjpx53ewavp23g5zj9jgyfrpr8djmgjzg5mpe4xd0z69dqvq0kq2lf353), and will share more about that in my next blog. Please be sure to let me know if you think there's another Nostr topic you'd like to see me tackle. GM Nostr.

@ 3f770d65:7a745b24

Here are my predictions for Nostr in 2025: **Decentralization:** The outbox and inbox communication models, sometimes referred to as the Gossip model, will become the standard across the ecosystem. By the end of 2025, all major clients will support these models, providing seamless communication and enhanced decentralization. Clients that do not adopt outbox/inbox by then will be regarded as outdated or legacy systems. **Privacy Standards:** Major clients such as Damus and Primal will move away from NIP-04 DMs, adopting more secure protocol possibilities like NIP-17 or NIP-104. These upgrades will ensure enhanced encryption and metadata protection. Additionally, NIP-104 MLS tools will drive the development of new clients and features, providing users with unprecedented control over the privacy of their communications. **Interoperability:** Nostr's ecosystem will become even more interconnected. Platforms like the Olas image-sharing service will expand into prominent clients such as Primal, Damus, Coracle, and Snort, alongside existing integrations with Amethyst, Nostur, and Nostrudel. Similarly, audio and video tools like Nostr Nests and Zap.stream will gain seamless integration into major clients, enabling easy participation in live events across the ecosystem. **Adoption and Migration:** Inspired by early pioneers like Fountain and Orange Pill App, more platforms will adopt Nostr for authentication, login, and social systems. In 2025, a significant migration from a high-profile application platform with hundreds of thousands of users will transpire, doubling Nostr’s daily activity and establishing it as a cornerstone of decentralized technologies.

@ e97aaffa:2ebd765d

Último dia do ano, momento para tirar o pó da bola de cristal, para fazer reflexões, previsões e desejos para o próximo ano e seguintes. Ano após ano, o Bitcoin evoluiu, foi ultrapassando etapas, tornou-se cada vez mais _mainstream_. Está cada vez mais difícil fazer previsões sobre o Bitcoin, já faltam poucas barreiras a serem ultrapassadas e as que faltam são altamente complexas ou tem um impacto profundo no sistema financeiro ou na sociedade. Estas alterações profundas tem que ser realizadas lentamente, porque uma alteração rápida poderia resultar em consequências terríveis, poderia provocar um retrocesso. # Código do Bitcoin No final de 2025, possivelmente vamos ter um _fork_, as discussões sobre os _covenants_ já estão avançadas, vão acelerar ainda mais. Já existe um consenso relativamente alto, a favor dos _covenants_, só falta decidir que modelo será escolhido. Penso que até ao final do ano será tudo decidido. Depois dos _covenants,_ o próximo foco será para a criptografia post-quantum, que será o maior desafio que o Bitcoin enfrenta. Criar uma criptografia segura e que não coloque a descentralização em causa. Espero muito de Ark, possivelmente a inovação do ano, gostaria de ver o Nostr a furar a bolha bitcoinheira e que o Cashu tivesse mais reconhecimento pelos _bitcoiners_. Espero que surjam avanços significativos no BitVM2 e BitVMX. Não sei o que esperar das layer 2 de Bitcoin, foram a maior desilusão de 2024. Surgiram com muita força, mas pouca coisa saiu do papel, foi uma mão cheia de nada. Uma parte dos projetos caiu na tentação da _shitcoinagem_, na criação de tokens, que tem um único objetivo, enriquecer os devs e os VCs. Se querem ser levados a sério, têm que ser sérios. > “À mulher de César não basta ser honesta, deve parecer honesta” Se querem ter o apoio dos _bitcoiners_, sigam o _ethos_ do Bitcoin. Neste ponto a atitude do pessoal da Ark é exemplar, em vez de andar a chorar no Twitter para mudar o código do Bitcoin, eles colocaram as mãos na massa e criaram o protocolo. É claro que agora está meio “coxo”, funciona com uma _multisig_ ou com os _covenants_ na Liquid. Mas eles estão a criar um produto, vão demonstrar ao mercado que o produto é bom e útil. Com a adoção, a comunidade vai perceber que o Ark necessita dos _covenants_ para melhorar a interoperabilidade e a soberania. É este o pensamento certo, que deveria ser seguido pelos restantes e futuros projetos. É seguir aquele pensamento do J.F. Kennedy: > “Não perguntem o que é que o vosso país pode fazer por vocês, perguntem o que é que vocês podem fazer pelo vosso país” Ou seja, não fiquem à espera que o bitcoin mude, criem primeiro as inovações/tecnologia, ganhem adoção e depois demonstrem que a alteração do código camada base pode melhorar ainda mais o vosso projeto. A necessidade é que vai levar a atualização do código. # Reservas Estratégicas de Bitcoin ## Bancos centrais Com a eleição de Trump, emergiu a ideia de uma Reserva Estratégia de Bitcoin, tornou este conceito _mainstream_. Foi um _pivot_, a partir desse momento, foram enumerados os políticos de todo o mundo a falar sobre o assunto. A Senadora Cynthia Lummis foi mais além e propôs um programa para adicionar 200 mil bitcoins à reserva ao ano, até 1 milhão de Bitcoin. Só que isto está a criar uma enorme expectativa na comunidade, só que pode resultar numa enorme desilusão. Porque no primeiro ano, o Trump em vez de comprar os 200 mil, pode apenas adicionar na reserva, os 198 mil que o Estado já tem em sua posse. Se isto acontecer, possivelmente vai resultar numa forte queda a curto prazo. Na minha opinião os bancos centrais deveriam seguir o exemplo de El Salvador, fazer um DCA diário. Mais que comprar bitcoin, para mim, o mais importante é a criação da Reserva, é colocar o Bitcoin ao mesmo nível do ouro, o impacto para o resto do mundo será tremendo, a teoria dos jogos na sua plenitude. Muitos outros bancos centrais vão ter que comprar, para não ficarem atrás, além disso, vai transmitir uma mensagem à generalidade da população, que o Bitcoin é “afinal é algo seguro, com valor”. Mas não foi Trump que iniciou esta teoria dos jogos, mas sim foi a primeira vítima dela. É o próprio Trump que o admite, que os EUA necessitam da reserva para não ficar atrás da China. Além disso, desde que os EUA utilizaram o dólar como uma arma, com sanção contra a Rússia, surgiram boatos de que a Rússia estaria a utilizar o Bitcoin para transações internacionais. Que foram confirmados recentemente, pelo próprio governo russo. Também há poucos dias, ainda antes deste reconhecimento público, Putin elogiou o Bitcoin, ao reconhecer que “Ninguém pode proibir o bitcoin”, defendendo como uma alternativa ao dólar. A narrativa está a mudar. Já existem alguns países com Bitcoin, mas apenas dois o fizeram conscientemente (El Salvador e Butão), os restantes têm devido a apreensões. Hoje são poucos, mas 2025 será o início de uma corrida pelos bancos centrais. Esta corrida era algo previsível, o que eu não esperava é que acontecesse tão rápido.  ## Empresas A criação de reservas estratégicas não vai ficar apenas pelos bancos centrais, também vai acelerar fortemente nas empresas em 2025.  Mas as empresas não vão seguir a estratégia do Saylor, vão comprar bitcoin sem alavancagem, utilizando apenas os tesouros das empresas, como uma proteção contra a inflação. Eu não sou grande admirador do Saylor, prefiro muito mais, uma estratégia conservadora, sem qualquer alavancagem. Penso que as empresas vão seguir a sugestão da BlackRock, que aconselha um alocações de 1% a 3%. Penso que 2025, ainda não será o ano da entrada das 6 magníficas (excepto Tesla), será sobretudo empresas de pequena e média dimensão. As magníficas ainda tem uma cota muito elevada de _shareholders_ com alguma idade, bastante conservadores, que têm dificuldade em compreender o Bitcoin, foi o que aconteceu recentemente com a Microsoft. Também ainda não será em 2025, talvez 2026, a inclusão nativamente de wallet Bitcoin nos sistema da Apple Pay e da Google Pay. Seria um passo gigante para a adoção a nível mundial. # ETFs Os ETFs para mim são uma incógnita, tenho demasiadas dúvidas, como será 2025. Este ano os _inflows_ foram superiores a 500 mil bitcoins, o IBIT foi o lançamento de ETF mais bem sucedido da história. O sucesso dos ETFs, deve-se a 2 situações que nunca mais se vão repetir. O mercado esteve 10 anos à espera pela aprovação dos ETFs, a procura estava reprimida, isso foi bem notório nos primeiros meses, os _inflows_ foram brutais. Também se beneficiou por ser um mercado novo, não existia _orderbook_ de vendas, não existia um mercado interno, praticamente era só _inflows_. Agora o mercado já estabilizou, a maioria das transações já são entre clientes dos próprios ETFs. Agora só uma pequena percentagem do volume das transações diárias vai resultar em _inflows_ ou _outflows_. Estes dois fenómenos nunca mais se vão repetir, eu não acredito que o número de _inflows_ em BTC supere os número de 2024, em dólares vai superar, mas em btc não acredito que vá superar. Mas em 2025 vão surgir uma infindável quantidade de novos produtos, derivativos, novos ETFs de cestos com outras criptos ou cestos com ativos tradicionais. O bitcoin será adicionado em produtos financeiros já existentes no mercado, as pessoas vão passar a deter bitcoin, sem o saberem. Com o fim da operação ChokePoint 2.0, vai surgir uma nova onda de adoção e de produtos financeiros. Possivelmente vamos ver bancos tradicionais a disponibilizar produtos ou serviços de custódia aos seus clientes. Eu adoraria ver o crescimento da adoção do bitcoin como moeda, só que a regulamentação não vai ajudar nesse processo. # Preço Eu acredito que o topo deste ciclo será alcançado no primeiro semestre, posteriormente haverá uma correção. Mas desta vez, eu acredito que a correção será muito menor que as anteriores, inferior a 50%, esta é a minha expectativa. Espero estar certo. # Stablecoins de dólar Agora saindo um pouco do universo do Bitcoin, acho importante destacar as _stablecoins_. No último ciclo, eu tenho dividido o tempo, entre continuar a estudar o Bitcoin e estudar o sistema financeiro, as suas dinâmicas e o comportamento humano. Isto tem sido o meu foco de reflexão, imaginar a transformação que o mundo vai sofrer devido ao padrão Bitcoin. É uma ilusão acreditar que a transição de um padrão FIAT para um padrão Bitcoin vai ser rápida, vai existir um processo transitório que pode demorar décadas. Com a re-entrada de Trump na Casa Branca, prometendo uma política altamente protecionista, vai provocar uma forte valorização do dólar, consequentemente as restantes moedas do mundo vão derreter. Provocando uma inflação generalizada, gerando uma corrida às _stablecoins_ de dólar nos países com moedas mais fracas. Trump vai ter uma política altamente expansionista, vai exportar dólares para todo o mundo, para financiar a sua própria dívida. A desigualdade entre os pobres e ricos irá crescer fortemente, aumentando a possibilidade de conflitos e revoltas. > “Casa onde não há pão, todos ralham e ninguém tem razão” Será mais lenha, para alimentar a fogueira, vai gravar os conflitos geopolíticos já existentes, ficando as sociedade ainda mais polarizadas. Eu acredito que 2025, vai haver um forte crescimento na adoção das _stablecoins_ de dólares, esse forte crescimento vai agravar o problema sistémico que são as _stablecoins_. Vai ser o início do fim das _stablecoins_, pelo menos, como nós conhecemos hoje em dia. ## Problema sistémico O sistema FIAT não nasceu de um dia para outro, foi algo que foi construído organicamente, ou seja, foi evoluindo ao longo dos anos, sempre que havia um problema/crise, eram criadas novas regras ou novas instituições para minimizar os problemas. Nestes quase 100 anos, desde os acordos de Bretton Woods, a evolução foram tantas, tornaram o sistema financeiro altamente complexo, burocrático e nada eficiente. Na prática é um castelo de cartas construído sobre outro castelo de cartas e que por sua vez, foi construído sobre outro castelo de cartas. As _stablecoins_ são um problema sistémico, devido às suas reservas em dólares e o sistema financeiro não está preparado para manter isso seguro. Com o crescimento das reservas ao longo dos anos, foi se agravando o problema. No início a Tether colocava as reservas em bancos comerciais, mas com o crescimento dos dólares sob gestão, criou um problema nos bancos comerciais, devido à reserva fracionária. Essas enormes reservas da Tether estavam a colocar em risco a própria estabilidade dos bancos. A Tether acabou por mudar de estratégia, optou por outros ativos, preferencialmente por títulos do tesouro/obrigações dos EUA. Só que a Tether continua a crescer e não dá sinais de abrandamento, pelo contrário. Até o próprio mundo cripto, menosprezava a gravidade do problema da Tether/_stablecoins_ para o resto do sistema financeiro, porque o _marketcap_ do cripto ainda é muito pequeno. É verdade que ainda é pequeno, mas a Tether não o é, está no top 20 dos maiores detentores de títulos do tesouros dos EUA e está ao nível dos maiores bancos centrais do mundo. Devido ao seu tamanho, está a preocupar os responsáveis/autoridades/reguladores dos EUA, pode colocar em causa a estabilidade do sistema financeiro global, que está assente nessas obrigações. Os títulos do tesouro dos EUA são o colateral mais utilizado no mundo, tanto por bancos centrais, como por empresas, é a charneira da estabilidade do sistema financeiro. Os títulos do tesouro são um assunto muito sensível. Na recente crise no Japão, do _carry trade_, o Banco Central do Japão tentou minimizar a desvalorização do iene através da venda de títulos dos EUA. Esta operação, obrigou a uma viagem de emergência, da Secretaria do Tesouro dos EUA, Janet Yellen ao Japão, onde disponibilizou liquidez para parar a venda de títulos por parte do Banco Central do Japão. Essa forte venda estava desestabilizando o mercado. Os principais detentores de títulos do tesouros são institucionais, bancos centrais, bancos comerciais, fundo de investimento e gestoras, tudo administrado por gestores altamente qualificados, racionais e que conhecem a complexidade do mercado de obrigações. O mundo cripto é seu oposto, é _naife_ com muita irracionalidade e uma forte pitada de loucura, na sua maioria nem faz a mínima ideia como funciona o sistema financeiro. Essa irracionalidade pode levar a uma “corrida bancária”, como aconteceu com o UST da Luna, que em poucas horas colapsou o projeto. Em termos de escala, a Luna ainda era muito pequena, por isso, o problema ficou circunscrito ao mundo cripto e a empresas ligadas diretamente ao cripto. Só que a Tether é muito diferente, caso exista algum FUD, que obrigue a Tether a desfazer-se de vários biliões ou dezenas de biliões de dólares em títulos num curto espaço de tempo, poderia provocar consequências terríveis em todo o sistema financeiro. A Tether é grande demais, é já um problema sistémico, que vai agravar-se com o crescimento em 2025. Não tenham dúvidas, se existir algum problema, o Tesouro dos EUA vai impedir a venda dos títulos que a Tether tem em sua posse, para salvar o sistema financeiro. O problema é, o que vai fazer a Tether, se ficar sem acesso às venda das reservas, como fará o _redeem_ dos dólares? Como o crescimento do Tether é inevitável, o Tesouro e o FED estão com um grande problema em mãos, o que fazer com o Tether? Mas o problema é que o atual sistema financeiro é como um curto cobertor: Quanto tapas a cabeça, destapas os pés; Ou quando tapas os pés, destapas a cabeça. Ou seja, para resolver o problema da guarda reservas da Tether, vai criar novos problemas, em outros locais do sistema financeiro e assim sucessivamente. ### Conta mestre Uma possível solução seria dar uma conta mestre à Tether, dando o acesso direto a uma conta no FED, semelhante à que todos os bancos comerciais têm. Com isto, a Tether deixaria de necessitar os títulos do tesouro, depositando o dinheiro diretamente no banco central. Só que isto iria criar dois novos problemas, com o Custodia Bank e com o restante sistema bancário. O Custodia Bank luta há vários anos contra o FED, nos tribunais pelo direito a ter licença bancária para um banco com _full-reserves_. O FED recusou sempre esse direito, com a justificativa que esse banco, colocaria em risco toda a estabilidade do sistema bancário existente, ou seja, todos os outros bancos poderiam colapsar. Perante a existência em simultâneo de bancos com reserva fracionária e com _full-reserves_, as pessoas e empresas iriam optar pelo mais seguro. Isso iria provocar uma corrida bancária, levando ao colapso de todos os bancos com reserva fracionária, porque no Custodia Bank, os fundos dos clientes estão 100% garantidos, para qualquer valor. Deixaria de ser necessário limites de fundos de Garantia de Depósitos. Eu concordo com o FED nesse ponto, que os bancos com _full-reserves_ são uma ameaça a existência dos restantes bancos. O que eu discordo do FED, é a origem do problema, o problema não está nos bancos _full-reserves_, mas sim nos que têm reserva fracionária. O FED ao conceder uma conta mestre ao Tether, abre um precedente, o Custodia Bank irá o aproveitar, reclamando pela igualdade de direitos nos tribunais e desta vez, possivelmente ganhará a sua licença. Ainda há um segundo problema, com os restantes bancos comerciais. A Tether passaria a ter direitos similares aos bancos comerciais, mas os deveres seriam muito diferentes. Isto levaria os bancos comerciais aos tribunais para exigir igualdade de tratamento, é uma concorrência desleal. Isto é o bom dos tribunais dos EUA, são independentes e funcionam, mesmo contra o estado. Os bancos comerciais têm custos exorbitantes devido às políticas de _compliance_, como o KYC e AML. Como o governo não vai querer aliviar as regras, logo seria a Tether, a ser obrigada a fazer o _compliance_ dos seus clientes. A obrigação do KYC para ter _stablecoins_ iriam provocar um terramoto no mundo cripto. Assim, é pouco provável que seja a solução para a Tether. ### FED Só resta uma hipótese, ser o próprio FED a controlar e a gerir diretamente as _stablecoins_ de dólar, nacionalizado ou absorvendo as existentes. Seria uma espécie de CBDC. Isto iria provocar um novo problema, um problema diplomático, porque as _stablecoins_ estão a colocar em causa a soberania monetária dos outros países. Atualmente as _stablecoins_ estão um pouco protegidas porque vivem num limbo jurídico, mas a partir do momento que estas são controladas pelo governo americano, tudo muda. Os países vão exigir às autoridades americanas medidas que limitem o uso nos seus respectivos países. Não existe uma solução boa, o sistema FIAT é um castelo de cartas, qualquer carta que se mova, vai provocar um desmoronamento noutro local. As autoridades não poderão adiar mais o problema, terão que o resolver de vez, senão, qualquer dia será tarde demais. Se houver algum problema, vão colocar a responsabilidade no cripto e no Bitcoin. Mas a verdade, a culpa é inteiramente dos políticos, da sua incompetência em resolver os problemas a tempo. Será algo para acompanhar futuramente, mas só para 2026, talvez… É curioso, há uns anos pensava-se que o Bitcoin seria a maior ameaça ao sistema ao FIAT, mas afinal, a maior ameaça aos sistema FIAT é o próprio FIAT(_stablecoins_). A ironia do destino. Isto é como uma corrida, o Bitcoin é aquele atleta que corre ao seu ritmo, umas vezes mais rápido, outras vezes mais lento, mas nunca pára. O FIAT é o atleta que dá tudo desde da partida, corre sempre em velocidade máxima. Só que a vida e o sistema financeiro não é uma prova de 100 metros, mas sim uma maratona. # Europa 2025 será um ano desafiante para todos europeus, sobretudo devido à entrada em vigor da regulamentação (MiCA). Vão começar a sentir na pele a regulamentação, vão agravar-se os problemas com os _compliance_, problemas para comprovar a origem de fundos e outras burocracias. Vai ser lindo. O _Travel Route_ passa a ser obrigatório, os europeus serão obrigados a fazer o KYC nas transações. A _Travel Route_ é uma suposta lei para criar mais transparência, mas prática, é uma lei de controle, de monitorização e para limitar as liberdades individuais dos cidadãos. O MiCA também está a colocar problemas nas _stablecoins_ de Euro, a Tether para já preferiu ficar de fora da europa. O mais ridículo é que as novas regras obrigam os emissores a colocar 30% das reservas em bancos comerciais. Os burocratas europeus não compreendem que isto coloca em risco a estabilidade e a solvência dos próprios bancos, ficam propensos a corridas bancárias. O MiCA vai obrigar a todas as exchanges a estar registadas em solo europeu, ficando vulnerável ao temperamento dos burocratas. Ainda não vai ser em 2025, mas a UE vai impor políticas de controle de capitais, é inevitável, as exchanges serão obrigadas a usar em exclusividade _stablecoins_ de euro, as restantes _stablecoins_ serão deslistadas. Todas estas novas regras do MiCA, são extremamente restritas, não é para garantir mais segurança aos cidadãos europeus, mas sim para garantir mais controle sobre a população. A UE está cada vez mais perto da autocracia, do que da democracia. A minha única esperança no horizonte, é que o sucesso das políticas cripto nos EUA, vai obrigar a UE a recuar e a aligeirar as regras, a teoria dos jogos é implacável. Mas esse recuo, nunca acontecerá em 2025, vai ser um longo período conturbado. # Recessão Os mercados estão todos em máximos históricos, isto não é sustentável por muito tempo, suspeito que no final de 2025 vai acontecer alguma correção nos mercados. A queda só não será maior, porque os bancos centrais vão imprimir dinheiro, muito dinheiro, como se não houvesse amanhã. Vão voltar a resolver os problemas com a injeção de liquidez na economia, é empurrar os problemas com a barriga, em de os resolver. Outra vez o efeito Cantillon. Será um ano muito desafiante a nível político, onde o papel dos políticos será fundamental. A crise política na França e na Alemanha, coloca a UE órfã, sem um comandante ao leme do navio. 2025 estará condicionado pelas eleições na Alemanha, sobretudo no resultado do AfD, que podem colocar em causa a propriedade UE e o euro. Possivelmente, só o fim da guerra poderia minimizar a crise, algo que é muito pouco provável acontecer. Em Portugal, a economia parece que está mais ou menos equilibrada, mas começam a aparecer alguns sinais preocupantes. Os jogos de sorte e azar estão em máximos históricos, batendo o recorde de 2014, época da grande crise, não é um bom sinal, possivelmente já existe algum desespero no ar. A Alemanha é o motor da Europa, quanto espirra, Portugal constipa-se. Além do problema da Alemanha, a Espanha também está à beira de uma crise, são os países que mais influenciam a economia portuguesa. Se existir uma recessão mundial, terá um forte impacto no turismo, que é hoje em dia o principal motor de Portugal. # Brasil Brasil é algo para acompanhar em 2025, sobretudo a nível macro e a nível político. Existe uma possibilidade de uma profunda crise no Brasil, sobretudo na sua moeda. O banco central já anda a queimar as reservas para minimizar a desvalorização do Real.  Sem mudanças profundas nas políticas fiscais, as reservas vão se esgotar. As políticas de controle de capitais são um cenário plausível, será interesse de acompanhar, como o governo irá proceder perante a existência do Bitcoin e _stablecoins_. No Brasil existe um forte adoção, será um bom _case study_, certamente irá repetir-se em outros países num futuro próximo. Os próximos tempos não serão fáceis para os brasileiros, especialmente para os que não têm Bitcoin. # Blockchain Em 2025, possivelmente vamos ver os primeiros passos da BlackRock para criar a primeira bolsa de valores, exclusivamente em _blockchain_. Eu acredito que a BlackRock vai criar uma própria _blockchain_, toda controlada por si, onde estarão os RWAs, para fazer concorrência às tradicionais bolsas de valores. Será algo interessante de acompanhar. ----------- Estas são as minhas previsões, eu escrevi isto muito em cima do joelho, certamente esqueci-me de algumas coisas, se for importante acrescentarei nos comentários. A maioria das previsões só acontecerá após 2025, mas fica aqui a minha opinião. Isto é apenas a minha opinião, **Don’t Trust, Verify**!

@ a1c19849:daacbb52

# Introduction nostr:npub1nj5v9hfxegyuqz4z9vfpgu9lxpgald066wspxadywmhslasuw2gsnyrxzg shared a great thread on X about what the Dutch Noderunners did to push Bitcoin adoption. Since it took him quite some time and he didn’t want to redo it on #nostr I’m happy to share his thread here as well, since it has a lot of cool stuff in it. Here we go: ----------- # Noderunners 2024 Recap by nostr:npub1nj5v9hfxegyuqz4z9vfpgu9lxpgald066wspxadywmhslasuw2gsnyrxzg  > Here it is, the 2024 Noderunners recap! As we are preparing for our annual party on the third day of Christmas I’d like to reflect to all the great stuff we’ve build together to push bitcoin adoption from bottom up. I’m proud we’ve made it this far and we’re just starting! 🔥 We like to come together as often as possible to chat about bitcoin and drink a beer so we started even more meetups. We now do meetups in Roermond, Leiden, Eindhoven, Utrecht, Breda, Friesland, Zaandam. And an occasional party in Arnhem or Den Bosch. Feel free to join us anytime.     > On our meetups and in the wild we meet the most awesome bitcoiners. To show them our respect we honor them by knighting them as an Honorary Noderunner. This year nostr:npub1nw5vdz8sj89y3h3tp7dunx8rhsm2qzfpf8ujq9m8mfvjsjth0uwqs9n2gn nostr:npub13ql75nq8rldygpkjke47y893akh5tglqtqzs6cspancaxktthsusvfqcg7 nostr:npub1cn4t4cd78nm900qc2hhqte5aa8c9njm6qkfzw95tszufwcwtcnsq7g3vle and nostr:npub1uaj9phu5lpxpczm3vaayt46m0yv0pduxzy7z6quwd2uggxue7fmqx9665u joined our ranks! 🧡    > As you can imagine, we were pleasantly surprised when we saw an honorary Noderunner wearing his pin in the courtroom in the case against fAkEtOsHi! Nice to meet again in Amsterdam nostr:npub1qg8j6gdwpxlntlxlkew7eu283wzx7hmj32esch42hntdpqdgrslqv024kw !    > The Bitcoin conference in Amsterdam was full of Noderunners. On and off stage. On stage we had nostr:npub1jqs0u7zhh53e94gyhm4eu458wm6sw7z0kk66jjhhkhh346tcq2ysfgr247 nostr:npub1h0fd5xu8rfhwdkkjr78ssdhm7rdjyf97hhjqr9acwv77ux0uvf8q23kvcg nostr:npub17tyke9lkgxd98ruyeul6wt3pj3s9uxzgp9hxu5tsenjmweue6sqq4y3mgl Tom Lamoen and others.     > In the panel there was nostr:npub1art8cs66ffvnqns5zs5qa9fwlctmusj5lj38j94lv0ulw0j54wjqhpm0w5 who [asked a cheeky question… 🤓](https://yakihonne.s3.ap-east-1.amazonaws.com/a1c1984994512025327f52c7b6d3a1434a37fbb7a318380cab4832f8daacbb52/files/1735554589353-YAKIHONNES3.mp4) He wrote the awesome “The Genesis Book” in which he describes the people and technology that led to the birth of bitcoin. Hope to see you 3kd Aaron! > Proof of work is the thing Noderunners value the most. We do the work on and offline. In Amsterdam we had several projects to display! Of course [the BitcoinTaps](https://yakihonne.s3.ap-east-1.amazonaws.com/a1c1984994512025327f52c7b6d3a1434a37fbb7a318380cab4832f8daacbb52/files/1735554793664-YAKIHONNES3.mp4), the bitcoin bitaxe B at the entrance, The nostr:npub1kd3nlw09ufkgmts2kaf0x8m4mq57exn6l8rz50v5ngyr2h3j5cfswdsdth arcade and the video of @npub1f59dz0ru0l8zpsl4cryj5ch2rahwxeex3mr7lpl2ltzxsfwsdwastu6nqk!  > Personally I was very exited nostr:npub1qg5a5l3t7pakmm4r4up2e764xecsw62fk3rntevm24fwyczhndtsdrvc4x Edward and Stef of Connect The World Podcast allowed us to bring the Arcade to the afterparty at Braai where we played some tournaments with nostr:npub1jt97tpsul3fp8hvf7zn0vzzysmu9umcrel4hpgflg4vnsytyxwuqt8la9y nostr:npub1j8y6tcdfw3q3f3h794s6un0gyc5742s0k5h5s2yqj0r70cpklqeqjavrvg and many others!    > Hopefully we can create a Noderunners lounge or such next year at @npub13e6qu4kdjsyysrfl5an558rawvqg0rx2xuat9ca706spcdqjzhuqq6md43! Connections were made!    > This year there was also the first edition of nostr:npub1uv2tr83c5y7k82af6zdzlqs8m0klcmndd8u5vmlg2eyrskld6uzsv4rmr8 organized by nostr:npub14mge80nm5r0zj0gncxvpunlr28jyku95547q0m82ec475x3yy92skvjgm5 and Bitcoin Stad. It was an awesome event with great speakers but the best thing was the Noderunners Lounge in the basement where [Hester Bais tapped a beer.. 🍺](https://yakihonne.s3.ap-east-1.amazonaws.com/a1c1984994512025327f52c7b6d3a1434a37fbb7a318380cab4832f8daacbb52/files/1735555060373-YAKIHONNES3.mp4)    > There was some trouble in paradise when the GitHub page of nostr:npub1k5f85zx0xdskyayqpfpc0zq6n7vwqjuuxugkayk72fgynp34cs3qfcvqg2 got canceled due to false copyright claims.. He makes the most beautiful, full open source BTClock! He’s a good frend and very productive Noderunner! 🧡    > nostr:npub1k5f85zx0xdskyayqpfpc0zq6n7vwqjuuxugkayk72fgynp34cs3qfcvqg2 also did a lot behind the scenes for the Noderunners SOLO Mining Pool! http://pool.noderunners.network   > As we are also very enthusiastic about NOSTR nostr:npub1p6xyr6u5vet33r4x724vxmp9uwfllax5zjdgxeujyrtxt90lp74qvah0rm has set up our own nostr relay: wss://relay.noderunners.network  > Noderunner nostr:npub1yn84ur49llj7pp9a7uv477f7vrpj0rj7df5pnfncvkusaxgy6jqsj9xgfl set up a mixer where he organizes a weekly coinjoin every sunday for more anonymous bitcoin transactions. https://coinjoin.nl  > Our Belgian Noderunner Kim de Vos made the infamous “Big Mac index” where he expresses the price of bitcoin in Big Macs.. He also runs the AVBpodcast (my personal favorite).  > We have several members who have their own podcasts. Also a lot of Noderunners appeared in podcasts as a guest. nostr:npub1agyf7kae8nkxqrd7rvvxt6nh9vwpcqzen2mc9dl3u38a04awpjcq09n23f educates bitcoin beginners.  Tom Lamoen talks about libertarianism. > nostr:npub1gfxgylgst4lcemkjth6xdvcvq7le8rtlrym7wayml63qrjggngaqkqescl interviews bitcoiners from all over the world.  > And nostr:npub1kj2ngxmm0zccswfqplff87rpgvmq9utvk0g726wc0h8pv4kwm8ss6zgm4n laughs at 🤡🌍  > After months, even years of hard work nostr:npub1w98ems6ryhpv7zvmhwp5sv65p0pwrnvzw4lucn0ch776qan9ntdstscwpx launched [the best bitcoin board game ever!](https://yakihonne.s3.ap-east-1.amazonaws.com/a1c1984994512025327f52c7b6d3a1434a37fbb7a318380cab4832f8daacbb52/files/1735555757989-YAKIHONNES3.mp4)   > nostr:npub1w98ems6ryhpv7zvmhwp5sv65p0pwrnvzw4lucn0ch776qan9ntdstscwpx is also involved with the Dutch bitcoin magazine BitcoinFocus which features a lot of Noderunner builds and articles.   > Of course I should mention our frens at nostr:npub1ua6fxn9ktc4jncanf79jzvklgjftcdrt5etverwzzg0lgpmg3hsq2gh6v6 where you can pay a few sats to play your favorite songs! http://radio.noderunners.org  > LightningPlaces is working hard making entrepreneurs accepting bitcoin and putting them on their website! 🔥💪🏼    > nostr:npub1lhufm09wzp42y67t3s8axlewwna8rmetak68w38yal7xjrwktpsscpt08x is also hooking up webshops and physical shops (and bars) to accept bitcoin! Connect them if you’re looking for a custom solution! https://lightningcheckout.eu/nl/   > Maybe we should create an open source HW Wallet too but for now we have the man, the myth, the legend nostr:npub17tyke9lkgxd98ruyeul6wt3pj3s9uxzgp9hxu5tsenjmweue6sqq4y3mgl in our midst.. A real honor as we all share the same values and ethics in life but especially in bitcoin! We’ve been building seedsigners from scratch by the dozen!   Most of us are very entrepreneurial. Several bitcoin shops are run by Noderunners. nostr:npub1qvwdl9rp7a5ghrxv57wnml5ehg2whjh708vys6kaxpkgu0z3aclsuy2h4p - https://bitcoinbrabant.com nostr:npub1k00lff0ahjv4d2kwuwxy040d2282yjmzj6eeu5ghav054s4yrfzsplyc86 - https://bitsaga.be nostr:npub1837pplcuwcjn35zwmpuy62ekcfdtvklajn6pueus3am09s27vu6smuj6v9 - https://miningwholesale.eu > A special shoutout to our junior Noderunner Esramsterdam who is organizing a bitcoin event focused on women. Because bitcoin is not only for men. More info: https://vanbanknaarbitcoin.nl  > Also a special shoutout to @npub17k8u7c6kfjgtd380890zx0m4adu8vl53m9fvtc7lal4j9gp74xqqkguha4! The only way to get free sats. Drank not enough beer with nostr:npub1pzurm7nx3q08894wl6uautryq95sku5jhzgwjjrskwdafcwxekuq4n7vtu this year.. but we really need to set up a collaborative project!  > Ok I’m done. Forgot a lot but this sums it up quite well. Greetings and love to everyone involved with the Noderunners I forgot to mention. I love you all and hope to build a lot more together! 🧡🔥 nostr:npub103uy2vsk5hrnldwdu0nztmsg7g6207cfqu744rnrnalauns6facsgj5ddp nostr:npub1l9evr9vx4u2xefesmfu6gyypfdu7k8zwdw7rrnh5ckdds8fqx59sy3ferg nostr:npub1cwzduskqu6yuxjs2a75uptj3vzfa84gv5q3xlkcpzs6usjfey24qvk70dv nostr:npub1etuf22z5jwp765m8dqcw7rx5egjzjnwm9xwm4m367e9hxkd9vvaq04duqw nostr:npub1mw6tm8kery0dwmz670vvg74z0xzttwt3y7yppya5rulufpkkaj7qmg2922 nostr:npub12qw34mucxxk200835d8qt5mshfukd39vvz4s94f0e6xthg0xpjmq3wvjlw nostr:npub1d5axlx84ajq7q5yn4u86m9xgnmssgq5c6ktjfmu6qtw7jah24hzs57tmvz nostr:npub1vnlkmja076ft0h2ppme4pvcyfh8zmwl4l7hpfm4du0jagwck04lq8rkr0w Jan Burgers nostr:npub1r35gr0g93gxpkcq77v9sx97d5aqg4edr0qwhdj2xr4xxt6slp7nswgahlx Short Non-Bitcoin nostr:npub12786tz9vyzuhe5jdjc9esd64vqh3pvqe34u9a3dyegudv5chkx9sexz86w Joep Laser Sheep - Elden Lord 3x nostr:npub12xtq7ufn6kjppvl24dnvezsny872u8xacfsy640fzd69446kgczsp8v5nm nostr:npub1m0yz3tvsa8cwheqhkqj96zr9kget8j8yda0vfmrah5c0dafj6xcq4l4az6 @Erik Dutch nostr:npub1kvfz8rglvpsqevznlt86ukcz0s9uap3pypjwd3tnmkn2pgjmjujqlncy2c nostr:npub1l5pxvjzhw77h86tu0sml2gxg8jpwxch7fsj6d05n7vuqpq75v34syk4q0n Noderunners Shop nostr:npub1ylnqfg0neysvsesen9je80wmsv9r5204x30mgd5ev6dr3q95xpxq3nmcxd nostr:npub1ap78x7mvw0vu9s7yltflmkqphx8rt8hsk9gdg0k42vwnmnpvpe2qptxewe nostr:npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc @Bitcmonkey @Roynode nostr:npub18n56f28efvmsjcl80lv2ngtmkl3y6q2rg0m2zqas3kw4jwkrsvdqxnmver nostr:npub135q6dvnjah9023xszmjs2wvd4gqhn2trku52wt2lv8cl4hc8ltjsk0w4sq nostr:npub1837u93v8am8q2rauvkqfk9sf6xfq07p9m4m82jueqh5u4qzkg25qesqrr4 nostr:npub1pkmp7vtgfwg7g0pt4xdd4r2npz2p8yweeq0yx7xm590h4nuszynqq2e2r3 nostr:npub19r33crtgdt4spqxl5a3nhqx2ucdputtqcnnxkplnp4mv2dqldqqs39j5eq nostr:npub19z9g9ymx3aalx3h0jr2cskehvhgppznv2lpqsrpgggpeueesq4lsknsp8r nostr:npub1jlvtd4zmq7ukjcytqxu2gy5myp2uataupjk4a3l467fj7pxpk3xq5p3w0j @HeroVanKampen nostr:npub16htmakd0gvsmwjnravfvfn5mh2x7wjd0vxq20z2c0979e7xh0a8q6ssnew nostr:npub1xw6jekvethghmrlv0chkx5p78h3wk2ep5x588ga854d68cugr40qxuwt5e nostr:npub1zakkum8w7uancehpev0drxuly3e74fg5v7q4n0zpxcdn72wakpjs9cgpve > and all others I can’t find here or I forgot.. 🧡🔥💪🏼 LFG, see you soon! >Bonus: This has never aired but @DanielMol was doubtful of our impact to more bitcoin adoption.. I know we are a bit toxic but we have our hearts on the right place and help anyone who is serious about it.. Happy days Daniel! 🧡 

@ 16d11430:61640947

At the intersection of philosophy, theology, physics, biology, and finance lies a terrifying truth: the fiat monetary system, in its current form, is not just an economic framework but a silent, relentless force actively working against humanity's survival. It isn't simply a failed financial model—it is a systemic engine of destruction, both externally and within the very core of our biological existence. The Philosophical Void of Fiat Philosophy has long questioned the nature of value and the meaning of human existence. From Socrates to Kant, thinkers have pondered the pursuit of truth, beauty, and virtue. But in the modern age, the fiat system has hijacked this discourse. The notion of "value" in a fiat world is no longer rooted in human potential or natural resources—it is abstracted, manipulated, and controlled by central authorities with the sole purpose of perpetuating their own power. The currency is not a reflection of society’s labor or resources; it is a representation of faith in an authority that, more often than not, breaks that faith with reckless monetary policies and hidden inflation. The fiat system has created a kind of ontological nihilism, where the idea of true value, rooted in work, creativity, and family, is replaced with speculative gambling and short-term gains. This betrayal of human purpose at the systemic level feeds into a philosophical despair: the relentless devaluation of effort, the erosion of trust, and the abandonment of shared human values. In this nihilistic economy, purpose and meaning become increasingly difficult to find, leaving millions to question the very foundation of their existence. Theological Implications: Fiat and the Collapse of the Sacred Religious traditions have long linked moral integrity with the stewardship of resources and the preservation of life. Fiat currency, however, corrupts these foundational beliefs. In the theological narrative of creation, humans are given dominion over the Earth, tasked with nurturing and protecting it for future generations. But the fiat system promotes the exact opposite: it commodifies everything—land, labor, and life—treating them as mere transactions on a ledger. This disrespect for creation is an affront to the divine. In many theologies, creation is meant to be sustained, a delicate balance that mirrors the harmony of the divine order. Fiat systems—by continuously printing money and driving inflation—treat nature and humanity as expendable resources to be exploited for short-term gains, leading to environmental degradation and societal collapse. The creation narrative, in which humans are called to be stewards, is inverted. The fiat system, through its unholy alliance with unrestrained growth and unsustainable debt, is destroying the very creation it should protect. Furthermore, the fiat system drives idolatry of power and wealth. The central banks and corporations that control the money supply have become modern-day gods, their decrees shaping the lives of billions, while the masses are enslaved by debt and inflation. This form of worship isn't overt, but it is profound. It leads to a world where people place their faith not in God or their families, but in the abstract promises of institutions that serve their own interests. Physics and the Infinite Growth Paradox Physics teaches us that the universe is finite—resources, energy, and space are all limited. Yet, the fiat system operates under the delusion of infinite growth. Central banks print money without concern for natural limits, encouraging an economy that assumes unending expansion. This is not only an economic fallacy; it is a physical impossibility. In thermodynamics, the Second Law states that entropy (disorder) increases over time in any closed system. The fiat system operates as if the Earth were an infinite resource pool, perpetually able to expand without consequence. The real world, however, does not bend to these abstract concepts of infinite growth. Resources are finite, ecosystems are fragile, and human capacity is limited. Fiat currency, by promoting unsustainable consumption and growth, accelerates the depletion of resources and the degradation of natural systems that support life itself. Even the financial “growth” driven by fiat policies leads to unsustainable bubbles—inflated stock markets, real estate, and speculative assets that burst and leave ruin in their wake. These crashes aren’t just economic—they have profound biological consequences. The cycles of boom and bust undermine communities, erode social stability, and increase anxiety and depression, all of which affect human health at a biological level. Biology: The Fiat System and the Destruction of Human Health Biologically, the fiat system is a cancerous growth on human society. The constant chase for growth and the devaluation of work leads to chronic stress, which is one of the leading causes of disease in modern society. The strain of living in a system that values speculation over well-being results in a biological feedback loop: rising anxiety, poor mental health, physical diseases like cardiovascular disorders, and a shortening of lifespans. Moreover, the focus on profit and short-term returns creates a biological disconnect between humans and the planet. The fiat system fuels industries that destroy ecosystems, increase pollution, and deplete resources at unsustainable rates. These actions are not just environmentally harmful; they directly harm human biology. The degradation of the environment—whether through toxic chemicals, pollution, or resource extraction—has profound biological effects on human health, causing respiratory diseases, cancers, and neurological disorders. The biological cost of the fiat system is not a distant theory; it is being paid every day by millions in the form of increased health risks, diseases linked to stress, and the growing burden of mental health disorders. The constant uncertainty of an inflation-driven economy exacerbates these conditions, creating a society of individuals whose bodies and minds are under constant strain. We are witnessing a systemic biological unraveling, one in which the very act of living is increasingly fraught with pain, instability, and the looming threat of collapse. Finance as the Final Illusion At the core of the fiat system is a fundamental illusion—that financial growth can occur without any real connection to tangible value. The abstraction of currency, the manipulation of interest rates, and the constant creation of new money hide the underlying truth: the system is built on nothing but faith. When that faith falters, the entire system collapses. This illusion has become so deeply embedded that it now defines the human experience. Work no longer connects to production or creation—it is reduced to a transaction on a spreadsheet, a means to acquire more fiat currency in a world where value is ephemeral and increasingly disconnected from human reality. As we pursue ever-expanding wealth, the fundamental truths of biology—interdependence, sustainability, and balance—are ignored. The fiat system’s abstract financial models serve to disconnect us from the basic realities of life: that we are part of an interconnected world where every action has a reaction, where resources are finite, and where human health, both mental and physical, depends on the stability of our environment and our social systems. The Ultimate Extermination In the end, the fiat system is not just an economic issue; it is a biological, philosophical, theological, and existential threat to the very survival of humanity. It is a force that devalues human effort, encourages environmental destruction, fosters inequality, and creates pain at the core of the human biological condition. It is an economic framework that leads not to prosperity, but to extermination—not just of species, but of the very essence of human well-being. To continue on this path is to accept the slow death of our species, one based not on natural forces, but on our own choice to worship the abstract over the real, the speculative over the tangible. The fiat system isn't just a threat; it is the ultimate self-inflicted wound, a cultural and financial cancer that, if left unchecked, will destroy humanity’s chance for survival and peace.

@ a367f9eb:0633efea

I’ll admit that I was wrong about Bitcoin. Perhaps in 2013. Definitely 2017. Probably in 2018-2019. And maybe even today. Being wrong about Bitcoin is part of finally understanding it. It will test you, make you question everything, and in the words of BTC educator and privacy advocate [Matt Odell](https://twitter.com/ODELL), “Bitcoin will humble you”. I’ve had my own stumbles on the way. In a very public fashion in 2017, after years of using Bitcoin, trying to start a company with it, using it as my primary exchange vehicle between currencies, and generally being annoying about it at parties, I let out the bear. In an article published in my own literary magazine *Devolution Review* in September 2017, I had a breaking point. The article was titled “[Going Bearish on Bitcoin: Cryptocurrencies are the tulip mania of the 21st century](https://www.devolutionreview.com/bearish-on-bitcoin/)”. It was later republished in *Huffington Post* and across dozens of financial and crypto blogs at the time with another, more appropriate title: “[Bitcoin Has Become About The Payday, Not Its Potential](https://www.huffpost.com/archive/ca/entry/bitcoin-has-become-about-the-payday-not-its-potential_ca_5cd5025de4b07bc72973ec2d)”. As I laid out, my newfound bearishness had little to do with the technology itself or the promise of Bitcoin, and more to do with the cynical industry forming around it: > In the beginning, Bitcoin was something of a revolution to me. The digital currency represented everything from my rebellious youth. > > It was a decentralized, denationalized, and digital currency operating outside the traditional banking and governmental system. It used tools of cryptography and connected buyers and sellers across national borders at minimal transaction costs. > > … > > The 21st-century version (of Tulip mania) has welcomed a plethora of slick consultants, hazy schemes dressed up as investor possibilities, and too much wishy-washy language for anything to really make sense to anyone who wants to use a digital currency to make purchases. While I called out Bitcoin by name at the time, on reflection, I was really talking about the ICO craze, the wishy-washy consultants, and the altcoin ponzis. What I was articulating — without knowing it — was the frame of NgU, or “numbers go up”. Rather than advocating for Bitcoin because of its uncensorability, proof-of-work, or immutability, the common mentality among newbies and the dollar-obsessed was that Bitcoin mattered because its price was a rocket ship. And because Bitcoin was gaining in price, affinity tokens and projects that were imperfect forks of Bitcoin took off as well. The price alone — rather than its qualities — were the reasons why you’d hear Uber drivers, finance bros, or your gym buddy mention Bitcoin. As someone who came to Bitcoin for philosophical reasons, that just sat wrong with me. Maybe I had too many projects thrown in my face, or maybe I was too frustrated with the UX of Bitcoin apps and sites at the time. No matter what, I’ve since learned something. **I was at least somewhat wrong.** My own journey began in early 2011. One of my favorite radio programs, Free Talk Live, began interviewing guests and having discussions on the potential of Bitcoin. They tied it directly to a libertarian vision of the world: free markets, free people, and free banking. That was me, and I was in. Bitcoin was at about $5 back then (NgU). I followed every article I could, talked about it with guests [on my college radio show](https://libertyinexile.wordpress.com/2011/05/09/osamobama_on_the_tubes/), and became a devoted redditor on r/Bitcoin. At that time, at least to my knowledge, there was no possible way to buy Bitcoin where I was living. Very weak. **I was probably wrong. And very wrong for not trying to acquire by mining or otherwise.** The next year, after moving to Florida, Bitcoin was a heavy topic with a friend of mine who shared the same vision (and still does, according to the Celsius bankruptcy documents). We talked about it with passionate leftists at **Occupy Tampa** in 2012, all the while trying to explain the ills of Keynesian central banking, and figuring out how to use Coinbase. I began writing more about Bitcoin in 2013, writing a guide on “[How to Avoid Bank Fees Using Bitcoin](http://thestatelessman.com/2013/06/03/using-bitcoin/),” discussing its [potential legalization in Germany](https://yael.ca/2013/10/01/lagefi-alternative-monetaire-et-legislation-de/), and interviewing Jeremy Hansen, [one of the first political candidates in the U.S. to accept Bitcoin donations](https://yael.ca/2013/12/09/bitcoin-politician-wants-to-upgrade-democracy-in/). Even up until that point, I thought Bitcoin was an interesting protocol for sending and receiving money quickly, and converting it into fiat. The global connectedness of it, plus this cypherpunk mentality divorced from government control was both useful and attractive. I thought it was the perfect go-between. **But I was wrong.** When I gave my [first public speech](https://www.youtube.com/watch?v=CtVypq2f0G4) on Bitcoin in Vienna, Austria in December 2013, I had grown obsessed with Bitcoin’s adoption on dark net markets like Silk Road. My theory, at the time, was the number and price were irrelevant. The tech was interesting, and a novel attempt. It was unlike anything before. But what was happening on the dark net markets, which I viewed as the true free market powered by Bitcoin, was even more interesting. I thought these markets would grow exponentially and anonymous commerce via BTC would become the norm. While the price was irrelevant, it was all about buying and selling goods without permission or license. **Now I understand I was wrong.** Just because Bitcoin was this revolutionary technology that embraced pseudonymity did not mean that all commerce would decentralize as well. It did not mean that anonymous markets were intended to be the most powerful layer in the Bitcoin stack. What I did not even anticipate is something articulated very well by noted Bitcoin OG [Pierre Rochard](https://twitter.com/BitcoinPierre): [Bitcoin as a *savings technology*](https://www.youtube.com/watch?v=BavRqEoaxjI)*.* The ability to maintain long-term savings, practice self-discipline while stacking stats, and embrace a low-time preference was just not something on the mind of the Bitcoiners I knew at the time. Perhaps I was reading into the hype while outwardly opposing it. Or perhaps I wasn’t humble enough to understand the true value proposition that many of us have learned years later. In the years that followed, I bought and sold more times than I can count, and I did everything to integrate it into passion projects. I tried to set up a company using Bitcoin while at my university in Prague. My business model depended on university students being technologically advanced enough to have a mobile wallet, own their keys, and be able to make transactions on a consistent basis. Even though I was surrounded by philosophically aligned people, those who would advance that to actually put Bitcoin into practice were sparse. This is what led me to proclaim that “[Technological Literacy is Doomed](https://www.huffpost.com/archive/ca/entry/technological-literacy-is-doomed_b_12669440)” in 2016. **And I was wrong again.** Indeed, since that time, the UX of Bitcoin-only applications, wallets, and supporting tech has vastly improved and onboarded millions more people than anyone thought possible. The entrepreneurship, coding excellence, and vision offered by Bitcoiners of all stripes have renewed a sense in me that this project is something built for us all — friends and enemies alike. While many of us were likely distracted by flashy and pumpy altcoins over the years (me too, champs), most of us have returned to the Bitcoin stable. Fast forward to today, there are entire ecosystems of creators, activists, and developers who are wholly reliant on the magic of Bitcoin’s protocol for their life and livelihood. The options are endless. The FUD is still present, but real proof of work stands powerfully against those forces. In addition, there are now [dozens of ways to use Bitcoin privately](https://fixthemoney.substack.com/p/not-your-keys-not-your-coins-claiming) — still without custodians or intermediaries — that make it one of the most important assets for global humanity, especially in dictatorships. This is all toward a positive arc of innovation, freedom, and pure independence. Did I see that coming? Absolutely not. Of course, there are probably other shots you’ve missed on Bitcoin. Price predictions (ouch), the short-term inflation hedge, or the amount of institutional investment. While all of these may be erroneous predictions in the short term, we have to realize that Bitcoin is a long arc. It will outlive all of us on the planet, and it will continue in its present form for the next generation. **Being wrong about the evolution of Bitcoin is no fault, and is indeed part of the learning curve to finally understanding it all.** When your family or friends ask you about Bitcoin after your endless sessions explaining market dynamics, nodes, how mining works, and the genius of cryptographic signatures, try to accept that there is still so much we have to learn about this decentralized digital cash. There are still some things you’ve gotten wrong about Bitcoin, and plenty more you’ll underestimate or get wrong in the future. That’s what makes it a beautiful journey. It’s a long road, but one that remains worth it.

@ 6389be64:ef439d32

Resilience is the ability to withstand shocks, adapt, and bounce back. It’s an essential quality in nature and in life. But what if we could take resilience a step further? What if, instead of merely surviving, a system could improve when faced with stress? This concept, known as anti-fragility, is not just theoretical—it’s practical. Combining two highly resilient natural tools, comfrey and biochar, reveals how we can create systems that thrive under pressure and grow stronger with each challenge. ### **Comfrey: Nature’s Champion of Resilience** Comfrey is a plant that refuses to fail. Once its deep roots take hold, it thrives in poor soils, withstands drought, and regenerates even after being cut down repeatedly. It’s a hardy survivor, but comfrey doesn’t just endure—it contributes. Known as a dynamic accumulator, it mines nutrients from deep within the earth and brings them to the surface, making them available for other plants. Beyond its ecological role, comfrey has centuries of medicinal use, earning the nickname "knitbone." Its leaves can heal wounds and restore health, a perfect metaphor for resilience. But as impressive as comfrey is, its true potential is unlocked when paired with another resilient force: biochar. ### **Biochar: The Silent Powerhouse of Soil Regeneration** Biochar, a carbon-rich material made by burning organic matter in low-oxygen conditions, is a game-changer for soil health. Its unique porous structure retains water, holds nutrients, and provides a haven for beneficial microbes. Soil enriched with biochar becomes drought-resistant, nutrient-rich, and biologically active—qualities that scream resilience. Historically, ancient civilizations in the Amazon used biochar to transform barren soils into fertile agricultural hubs. Known as *terra preta*, these soils remain productive centuries later, highlighting biochar’s remarkable staying power. Yet, like comfrey, biochar’s potential is magnified when it’s part of a larger system. ### **The Synergy: Comfrey and Biochar Together** Resilience turns into anti-fragility when systems go beyond mere survival and start improving under stress. Combining comfrey and biochar achieves exactly that. 1. **Nutrient Cycling and Retention**\ Comfrey’s leaves, rich in nitrogen, potassium, and phosphorus, make an excellent mulch when cut and dropped onto the soil. However, these nutrients can wash away in heavy rains. Enter biochar. Its porous structure locks in the nutrients from comfrey, preventing runoff and keeping them available for plants. Together, they create a system that not only recycles nutrients but amplifies their effectiveness. 2. **Water Management**\ Biochar holds onto water making soil not just drought-resistant but actively water-efficient, improving over time with each rain and dry spell. 3. **Microbial Ecosystems**\ Comfrey enriches soil with organic matter, feeding microbial life. Biochar provides a home for these microbes, protecting them and creating a stable environment for them to multiply. Together, they build a thriving soil ecosystem that becomes more fertile and resilient with each passing season. Resilient systems can withstand shocks, but anti-fragile systems actively use those shocks to grow stronger. Comfrey and biochar together form an anti-fragile system. Each addition of biochar enhances water and nutrient retention, while comfrey regenerates biomass and enriches the soil. Over time, the system becomes more productive, less dependent on external inputs, and better equipped to handle challenges. This synergy demonstrates the power of designing systems that don’t just survive—they thrive. ### **Lessons Beyond the Soil** The partnership of comfrey and biochar offers a valuable lesson for our own lives. Resilience is an admirable trait, but anti-fragility takes us further. By combining complementary strengths and leveraging stress as an opportunity, we can create systems—whether in soil, business, or society—that improve under pressure. Nature shows us that resilience isn’t the end goal. When we pair resilient tools like comfrey and biochar, we unlock a system that evolves, regenerates, and becomes anti-fragile. By designing with anti-fragility in mind, we don’t just bounce back, we bounce forward. By designing with anti-fragility in mind, we don’t just bounce back, we bounce forward.

@ 06639a38:655f8f71

## 1) How did you spend your time? I continued to write and publish more detailed weekly updates here: [https://nostrver.se/blog](https://nostrver.se/blog). These updates are also cross-posted via Nostr as long-form content. #### Integrated RelayResponse classes Pull requests: * [https://github.com/nostrver-se/nostr-php/pull/59](https://github.com/nostrver-se/nostr-php/pull/59)  * [https://github.com/nostrver-se/nostr-php/pull/60](https://github.com/nostrver-se/nostr-php/pull/60) Documentation: [https://nostr-php.dev/guides/relay-responses](https://nostr-php.dev/guides/relay-responses) #### Researched and build a proof of concept of a handling async requests and concurrency I have published the research outcomes here: [https://nostr-php.dev/references/async-concurrent-requests](https://nostr-php.dev/references/async-concurrent-requests).   I also created a page here [https://nostr-php.dev/guides/asynchronous-and-concurrent-requests](https://nostr-php.dev/guides/asynchronous-and-concurrent-requests) with more details and a code snippet. The famous Http/Guzzle client is used for handling the requests in combination with a relative new piece of middleware which enables WebSockets. See [https://github.com/valtzu/guzzle-websocket-middleware/issues/1](https://github.com/valtzu/guzzle-websocket-middleware/issues/1) where I reached out for solving an issue with the middleware. #### NIP-42 client to relay authentication Finished, see [https://github.com/nostrver-se/nostr-php/pull/67](https://github.com/nostrver-se/nostr-php/pull/67)  #### NIP-19 bech32-encoded entities Work in progress, see [https://github.com/nostrver-se/nostr-php/pull/68](https://github.com/nostrver-se/nostr-php/pull/68)  #### 2.0.0 pre-release See [https://github.com/nostrver-se/nostr-php/releases/tag/2.0.0-alpha1](https://github.com/nostrver-se/nostr-php/releases/tag/2.0.0-alpha1)  #### Other stuff * New / updates documentation at [nostr-php.dev](https://nostr-php.dev): * [Generate keys](https://nostr-php.dev/guides/generate-keys) * [Publish an event](https://nostr-php.dev/guides/publish-event) * [Verify event](https://nostr-php.dev/guides/verify-event) * [Examples](https://nostr-php.dev/examples/) * [Introduction](https://nostr-php.dev/introduction) * [Request events](https://nostr-php.dev/guides/request-events) * Nostr-PHP has also a repo at [gitworkshop.dev](https://gitworkshop.dev/r/naddr1qqykummnw3ez6urgwqqs6amnwvaz7tmwdaejumr0dspzqpnrnguxe8qszsshvgkvhn6qjzxy7xsvx03rlrtddr62haj4lrm3qvzqqqrhnyyx5cnk)  * My Telegram bot called Botstix can return my latest note from my personal relay (using PHP Symfony fo this), see [here](https://njump.me/nevent1qvzqqqqqqypzqpnrnguxe8qszsshvgkvhn6qjzxy7xsvx03rlrtddr62haj4lrm3qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgewaehxw309ahx7um5wgh8xetzv9ehg6tc9ejx2a30qqs8z8ufkgnpejpalpwep7tzu4j53a5skd2tn6vkpeg3qh7h6as23jcx52ufe).  * Fixed the issue that Nostr-PHP was installed as a dev dependency (which it is not) [https://github.com/nostrver-se/nostr-php/issues/61](https://github.com/nostrver-se/nostr-php/issues/61) * Added Matomo for analytics on [https://nostr-php.dev](https://nostr-php.dev) which can be viewed by anyone at [https://matomo.sebastix.nl/](https://matomo.sebastix.nl/) * Applied for a Nostr stand at FOSDEM 2025 in collaboration with Jurjen and Tanja, see [https://nostrver.se/blog/nostr-stand-submission-fosdem-2025](https://nostrver.se/blog/nostr-stand-submission-fosdem-2025) (fast forward: it got accepted!) * Tinkered around with a Nostr relay implementation written in PHP: [https://github.com/nostriphant/transpher](https://github.com/nostriphant/transpher) ## 2) What do you plan to work on next quarter? * Finish the NIP-19 implementation which will support every bech32 entity * note * npub * nsec * nevent * naddr * nprofile * Research how the [revolt/event-loop package](https://revolt.run/) can be used to serve as a sort of a message bus for handling async and concurrent requests in the library * Build a final 2.0.x release * By default and full async concurrent requests support * Implement NIP-03 * Implement NIP-45 * Implement a firehose demo for requesting Nostr events * Host the nostr-php.dev website as a static website with Blossom on Nostr. See [https://github.com/lez/nsite](https://github.com/lez/nsite) and [https://github.com/hzrd149/nsite-ts](https://github.com/hzrd149/nsite-ts) ## 3) How did you make use of the money? * Livings costs * I attended the Nostriga unconference. A personal recap on this expierence can be read [here](https://nostr.band/note1dphddcfjell49npnjudyztvv7lakj0cs75vr0gk8gq07gypqd5ws8m9jd0). * I placed a Nostr advertisment on a billboard near the highway here. See this repo with all the assets: [https://gitlab.com/sebastix-group/nostr/nostr-ads](https://gitlab.com/sebastix-group/nostr/nostr-ads)  * I attended Nostrdam and Bitcoin Amsterdam 2024 for organizing and volunteering at the Nostr booth. Here is a post with all my learnings from those days: [https://nostrver.se/note/my-learned-nostr-lessons-nostr-booth-bitcoin-amsterdam-2024](https://nostrver.se/note/my-learned-nostr-lessons-nostr-booth-bitcoin-amsterdam-2024) ## 4) Is there anything we could help with? I would love to see a (closed/private) digital place with other Nostr OpenSats grantees where we can share our experiences and challenges. We could give feedback to each other as a form of encouragement. For example I'm curious how other grantees are explaining the work they to other which are not familiar with FOSS, Nostr and/or Bitcoin.

@ fd208ee8:0fd927c1

# GitHub is a software project graveyard I think the main reason why we have so many lone wolf devs is an economic one. The fact that most FOSS devs aren't being paid for their code is making this worse, not better, as they work for fame, not fortune. Nobody wants to use joint-repos because they don't want to give up or share the property rights to the contents. But because anything someone else does in a repo you own, also belongs to you, people are disincentized from contributing to your repo. GitHub, especially, has incentivized this splintering and isolation. Everyone wants to have all changes in their own repo because they can profit best on repos listed directly under their own name, so long as they become popular. Maximize your 🟩 and ⭐ , like chips you can cash in for a prize. And because forking other people's repos is the norm, rather than teamwork, requests for changes are usually ignored or responded to with "fork it, bro." Go away. Leave me alone. My repo is none of your business. # Too autistic, even for me So, the developers separate their efforts into a million tiny repos that are mostly redundant with other ones, there's little interaction, progress is often surprisingly slow and stalls for months at a time, it's hard to keep track of what other people are doing (so that you can review and test changes), most of the effort is headed straight for the bin, people build the same things over and over, and communication is extremely limited. This is a work environment that is unattractive for anyone who isn't autistic and/or highly introverted. Half of the fun of open-source development used to be the esprit de corps. Much has been said about #Bluesky, but it all misses a major point: that's where you go, if you want to work with other people, to build something large, polished, and impressive. It doesn't actually matter how many developers Nostr has, if they all only stare at their own plates. # Your repo coulda been a file folder. Ironically, git was developed for collaboration on large projects with a distributed team. Now, everyone uses it for projects they work on alone. They put those projects on the Internet to market them. It's a cheap gimmick, not an earnest attempt at collaboration. Collaboration begins at the beginning.

@ 06639a38:655f8f71

Image source: [https://stitcher.io/blog/new-in-php-84](https://stitcher.io/blog/new-in-php-84) and great resource if you would like to know more about the new stuff in PHP 8.4. **Nostr-PHP** * Set a lib-gmp version, see [https://github.com/nostrver-se/nostr-php/pull/71](https://github.com/nostrver-se/nostr-php/pull/71) * Work in progress handling TLV data for bech32 encoded entities: [https://github.com/nostrver-se/nostr-php/pull/68](https://github.com/nostrver-se/nostr-php/pull/68) * There is an issue with `gmp_pow()` method in php-core which affects version 8.2 or higher: [https://github.com/nostrver-se/nostr-php/pull/71](https://github.com/nostrver-se/nostr-php/pull/71) * Added 8.4 PHP support, see [https://github.com/nostrver-se/nostr-php/pull/73](https://github.com/nostrver-se/nostr-php/pull/73) * Surprised by this unexpected but very welcome help while working on NIP-19: [https://github.com/nostrver-se/nostr-php/issues/74](https://github.com/nostrver-se/nostr-php/issues/74) where Nuša Pukšič shared some snippets how to decode bech32 encoded entities. * Fixed [https://github.com/nostrver-se/nostr-php/issues/63](https://github.com/nostrver-se/nostr-php/issues/63) **Other stuff** * On Tuesday the 19th of November we had our 4th Nostr NL meetup which we also streamed live on [https://zap.stream](https://zap.stream). * Had a online call with Fabian who is working on a new Blossom client which he demo’ed to me for getting some feedback.

@ a849beb6:b327e6d2

<img src="https://blossom.primal.net/e306357a7e53c4e40458cf6fa5625917dc8deaa4d1012823caa5a0eefb39e53c.jpg"> \ \ It was another historic week for both bitcoin and the Ten31 portfolio, as the world’s oldest, largest, most battle-tested cryptocurrency climbed to new all-time highs each day to close out the week just shy of the $100,000 mark. Along the way, bitcoin continued to accumulate institutional and regulatory wins, including the much-anticipated approval and launch of spot bitcoin ETF options and the appointment of several additional pro-bitcoin Presidential cabinet officials. The timing for this momentum was poetic, as this week marked the second anniversary of the pico-bottom of the 2022 bear market, a level that bitcoin has now hurdled to the tune of more than 6x despite the litany of bitcoin obituaries published at the time. The entirety of 2024 and especially the past month have further cemented our view that bitcoin is rapidly gaining a sense of legitimacy among institutions, fiduciaries, and governments, and we remain optimistic that this trend is set to accelerate even more into 2025. Several Ten31 portfolio companies made exciting announcements this week that should serve to further entrench bitcoin’s institutional adoption. AnchorWatch, a first of its kind bitcoin insurance provider offering 1:1 coverage with its innovative use of bitcoin’s native properties, announced it has been designated a Lloyd’s of London Coverholder, giving the company unique, blue-chip status as it begins to write bitcoin insurance policies of up to $100 million per policy starting next month. Meanwhile, Battery Finance Founder and CEO Andrew Hohns appeared on CNBC to delve into the launch of Battery’s pioneering private credit strategy which fuses bitcoin and conventional tangible assets in a dual-collateralized structure that offers a compelling risk/return profile to both lenders and borrowers. Both companies are clearing a path for substantially greater bitcoin adoption in massive, untapped pools of capital, and Ten31 is proud to have served as lead investor for AnchorWatch’s Seed round and as exclusive capital partner for Battery. As the world’s largest investor focused entirely on bitcoin, Ten31 has deployed nearly $150 million across two funds into more than 30 of the most promising and innovative companies in the ecosystem like AnchorWatch and Battery, and we expect 2025 to be the best year yet for both bitcoin and our portfolio. Ten31 will hold a first close for its third fund at the end of this year, and investors in that close will benefit from attractive incentives and a strong initial portfolio. Visit ten31.vc/funds to learn more and get in touch to discuss participating.\ \ **Portfolio Company Spotlight**  [Primal](http://primal.net/) is a first of its kind application for the Nostr protocol that combines a client, caching service, analytics tools, and more to address several unmet needs in the nascent Nostr ecosystem. Through the combination of its sleek client application and its caching service (built on a completely open source stack), Primal seeks to offer an end-user experience as smooth and easy as that of legacy social media platforms like Twitter and eventually many other applications, unlocking the vast potential of Nostr for the next billion people. Primal also offers an integrated wallet (powered by [Strike BLACK](https://x.com/Strike/status/1755335823023558819)) that substantially reduces onboarding and UX frictions for both Nostr and the lightning network while highlighting bitcoin’s unique power as internet-native, open-source money.  ### **Selected Portfolio News** AnchorWatch announced it has achieved Llody’s Coverholder status, allowing the company to provide unique 1:1 bitcoin insurance offerings starting in [December](https://x.com/AnchorWatch/status/1858622945763131577).\ \ Battery Finance Founder and CEO Andrew Hohns appeared on CNBC to delve into the company’s unique bitcoin-backed [private credit strategy](https://www.youtube.com/watch?v=26bOawTzT5U). Primal launched version 2.0, a landmark update that adds a feed marketplace, robust advanced search capabilities, premium-tier offerings, and many [more new features](https://primal.net/e/note1kaeajwh275kdwd6s0c2ksvj9f83t0k7usf9qj8fha2ac7m456juqpac43m). Debifi launched its new iOS app for Apple users seeking non-custodial [bitcoin-collateralized loans](https://x.com/debificom/status/1858897785044500642). ### **Media** Strike Founder and CEO Jack Mallers [joined Bloomberg TV](https://www.youtube.com/watch?v=i4z-2v_0H1k) to discuss the strong volumes the company has seen over the past year and the potential for a US bitcoin strategic reserve.  Primal Founder and CEO Miljan Braticevic [joined](https://www.youtube.com/watch?v=kqR_IQfKic8) The Bitcoin Podcast to discuss the rollout of Primal 2.0 and the future of Nostr.  Ten31 Managing Partner Marty Bent [appeared on](https://www.youtube.com/watch?v=_WwZDEtVxOE&t=1556s) BlazeTV to discuss recent changes in the regulatory environment for bitcoin.  Zaprite published a customer [testimonial video](https://x.com/ZapriteApp/status/1859357150809587928) highlighting the popularity of its offerings across the bitcoin ecosystem.  ### **Market Updates** Continuing its recent momentum, bitcoin reached another new all-time high this week, clocking in just below $100,000 on Friday. Bitcoin has now reached a market cap of [nearly $2 trillion](https://companiesmarketcap.com/assets-by-market-cap/), putting it within 3% of the market caps of Amazon and Google.  After receiving SEC and CFTC approval over the past month, long-awaited options on spot bitcoin ETFs were fully [approved](https://finance.yahoo.com/news/bitcoin-etf-options-set-hit-082230483.html) and launched this week. These options should help further expand bitcoin’s institutional [liquidity profile](https://x.com/kellyjgreer/status/1824168136637288912), with potentially significant [implications](https://x.com/dgt10011/status/1837278352823972147) for price action over time. The new derivatives showed strong performance out of the gate, with volumes on options for BlackRock’s IBIT reaching [nearly $2 billion](https://www.coindesk.com/markets/2024/11/20/bitcoin-etf-options-introduction-marks-milestone-despite-position-limits/) on just the first day of trading despite [surprisingly tight](https://x.com/dgt10011/status/1858729192105414837) position limits for the vehicles.  Meanwhile, the underlying spot bitcoin ETF complex had yet another banner week, pulling in [$3.4 billion](https://farside.co.uk/btc/) in net inflows.  New reports [suggested](https://archive.is/LMr4o) President-elect Donald Trump’s social media company is in advanced talks to acquire crypto trading platform Bakkt, potentially the latest indication of the incoming administration’s stance toward the broader “crypto” ecosystem.  On the macro front, US housing starts [declined M/M again](https://finance.yahoo.com/news/us-single-family-housing-starts-134759234.html) in October on persistently high mortgage rates and weather impacts. The metric remains well below pre-COVID levels.  Pockets of the US commercial real estate market remain challenged, as the CEO of large Florida developer Related indicated that [developers need further rate cuts](https://www.bloomberg.com/news/articles/2024-11-19/miami-developer-says-real-estate-market-needs-rate-cuts-badly) “badly” to maintain project viability.  US Manufacturing PMI [increased slightly](https://www.fxstreet.com/news/sp-global-pmis-set-to-signal-us-economy-continued-to-expand-in-november-202411220900) M/M, but has now been in contraction territory (&lt;50) for well over two years. The latest iteration of the University of Michigan’s popular consumer sentiment survey [ticked up](https://archive.is/fY5j6) following this month’s election results, though so did five-year inflation expectations, which now sit comfortably north of 3%.  ### **Regulatory Update** After weeks of speculation, the incoming Trump administration appointed hedge fund manager [Scott Bessent](https://www.cnbc.com/amp/2024/11/22/donald-trump-chooses-hedge-fund-executive-scott-bessent-for-treasury-secretary.html) to head up the US Treasury. Like many of Trump’s cabinet selections so far, Bessent has been a [public advocate](https://x.com/EleanorTerrett/status/1856204133901963512) for bitcoin.  Trump also [appointed](https://www.axios.com/2024/11/19/trump-commerce-secretary-howard-lutnick) Cantor Fitzgerald CEO Howard Lutnick – another outspoken [bitcoin bull](https://www.coindesk.com/policy/2024/09/04/tradfi-companies-want-to-transact-in-bitcoin-says-cantor-fitzgerald-ceo/) – as Secretary of the Commerce Department.  Meanwhile, the Trump team is reportedly considering creating a new [“crypto czar”](https://archive.is/jPQHF) role to sit within the administration. While it’s unclear at this point what that role would entail, one report indicated that the administration’s broader “crypto council” is expected to move forward with plans for a [strategic bitcoin reserve](https://archive.is/ZtiOk). Various government lawyers suggested this week that the Trump administration is likely to be [less aggressive](https://archive.is/Uggnn) in seeking adversarial enforcement actions against bitcoin and “crypto” in general, as regulatory bodies appear poised to shift resources and focus elsewhere.  Other updates from the regulatory apparatus were also directionally positive for bitcoin, most notably FDIC Chairman Martin Gruenberg’s confirmation that he [plans to resign](https://www.politico.com/news/2024/11/19/fdics-gruenberg-says-he-will-resign-jan-19-00190373) from his post at the end of President Biden’s term.  Many critics have alleged Gruenberg was an architect of [“Operation Chokepoint 2.0,”](https://x.com/GOPMajorityWhip/status/1858927571666096628) which has created banking headwinds for bitcoin companies over the past several years, so a change of leadership at the department is likely yet another positive for the space. SEC Chairman Gary Gensler also officially announced he plans to resign at the start of the new administration. Gensler has been the target of much ire from the broader “crypto” space, though we expect many projects outside bitcoin may continue to struggle with questions around the [Howey Test](https://www.investopedia.com/terms/h/howey-test.asp). Overseas, a Chinese court ruled that it is [not illegal](https://www.benzinga.com/24/11/42103633/chinese-court-affirms-cryptocurrency-ownership-as-legal-as-bitcoin-breaks-97k) for individuals to hold cryptocurrency, even though the country is still ostensibly [enforcing a ban](https://www.bbc.com/news/technology-58678907) on crypto transactions.  ### **Noteworthy** The incoming CEO of Charles Schwab – which administers over $9 trillion in client assets – [suggested](https://x.com/matthew_sigel/status/1859700668887597331) the platform is preparing to “get into” spot bitcoin offerings and that he “feels silly” for having waited this long. As this attitude becomes more common among traditional finance players, we continue to believe that the number of acquirers coming to market for bitcoin infrastructure capabilities will far outstrip the number of available high quality assets.  BlackRock’s 2025 Thematic Outlook notes a [“renewed sense of optimism”](https://www.ishares.com/us/insights/2025-thematic-outlook#rate-cuts) on bitcoin among the asset manager’s client base due to macro tailwinds and the improving regulatory environment. Elsewhere, BlackRock’s head of digital assets [indicated](https://www.youtube.com/watch?v=TE7cAw7oIeA) the firm does not view bitcoin as a “risk-on” asset.  MicroStrategy, which was a sub-$1 billion market cap company less than five years ago, briefly breached a [$100 billion equity value](https://finance.yahoo.com/news/microstrategy-breaks-top-100-u-191842879.html) this week as it continues to aggressively acquire bitcoin. The company now holds nearly 350,000 bitcoin on its balance sheet.  Notably, Allianz SE, Germany’s largest insurer, [spoke for 25%](https://bitbo.io/news/allianz-buys-microstrategy-notes/) of MicroStrategy’s latest $3 billion convertible note offering this week, suggesting [growing appetite](https://x.com/Rob1Ham/status/1860053859181199649) for bitcoin proxy exposure among more restricted pools of capital.  The [ongoing meltdown](https://www.cnbc.com/2024/11/22/synapse-bankruptcy-thousands-of-americans-see-their-savings-vanish.html) of fintech middleware provider Synapse has left tens of thousands of customers with nearly 100% deposit haircuts as hundreds of millions in funds remain missing, the latest unfortunate case study in the fragility of much of the US’s legacy banking stack.  ### **Travel** - [BitcoinMENA](https://bitcoin2024.b.tc/mena), Dec 9-10 - [Nashville BitDevs](https://www.meetup.com/bitcoinpark/events/302533726/?eventOrigin=group_upcoming_events), Dec 10 - [Austin BitDevs](https://www.meetup.com/austin-bitcoin-developers/events/303476169/?eventOrigin=group_upcoming_events), Dec 19 - [Nashville Energy and Mining Summit](https://www.meetup.com/bitcoinpark/events/304092624/?eventOrigin=group_events_list), Jan 30

@ 592295cf:413a0db9

November 18th week Let's proceed step by step, calm and reason. ## Bluesky is only 5 doubles from Twitter, now has its own network effect. Article of Hodlbod. The state of the art of Key management nostr:nevent1qqsgpckkyck5m58gux5xst03ls68xxfz0ep2ndws6s039492vxvtc7spp4mhxue69uhkummn9ekx7mqprdmhxue69uhksmmyd33x7epwvdhhyctrd3jjuar0dak8xq3qjlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qcxhke2 ## The problem is how a user creates an account. Will fix It. If you have a signer account like Amber, nsec app, all right, then it says remove all logins And ask the user how he wants to login. ## Bluesky is an anti Trump and Elon Musk movement. It started with Brazil the significant exodus, the thing had a certain amount of stability and began to arrive a lot of people. So it's a sort of political party hanging against. Nostr is still made by fixed stars, there are many stars but they are still firm in the sky. ## Rod made n8n ocKnamo bot nostr:nevent1qvzqqqqqqypzqx760c0h894a5tg7lxgr8k506twrv2qs0yxln0nz7kgs8zae03xeqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg4waehxw309ahx7um5wghx77r5wghxgetk9uqzqjgxwlfdru3zzcee0sxk8d0dddwj4tu3xp00gwahy2t0n5k2se6uu8p7fk This is interesting, ocknamo Is a rock, keep pushing Roadmap are bullshit, you spend the time to the the actual things, sure if a groups ok I read Hodlbod's spech in practice with the tilde wants to create rooms, then there is the space that is the carcass we are very close to what is Unanimity, but it's fine with much more refining, but at the cost of being unique. Discord vs Telegram ### I downloaded three Nostr apps, I called it Atlas instead of Olas, zapstore and flotilla (removing Coracle). ### Olas would be nice if he had the feature awards on the photo and Zap 😉. Zap store continues to mark me an update of minibits, but minibits updates in the app, I also updated to a new version, however maybe it is a different type of app. Putting the key does not seem to have changed a comma the app. But then I realized it's about the app signers. The signers who followed the signers that are in your WoT, the signers that are in your lists 😉. It does not divide Nostr apps from Nostr, but it works. ### Olas there is no focus on the media server, maybe if you have a new account it's all explained. Problems with dark mode and filter. I would like the idea of switching videos and pictures, can be something you can do in the settings photos (home) video (other button) And maybe there's a flip button 😅 So Instagram becomes tik tok. The focus must be in creating content. Ok. Olas allows you to upload only images for the moment and shorts from other Nostr apps. For some reason, I don't hear video audio, maybe some permission to give. ### Flotilla, if you connect with nsec.app creates a Nostr connect token from flotilla and enter it in nsec.app, asks for permissions and lists them and goes. With this test account, I don't follow anyone using it to feed on Coracle. The app also suggests people to contact. There is also a space for personal notes. Then there are spaces. And it basically shows you the Relays and here the situation is a little confused. Although I know that there is a space/group called flotilla I am not able to find it, maybe you need the invitation code that is in the link. Also copying it I couldn't enter but the approach is that I think. [flotilla link](https://flotilla.social/spaces/wss%3A%2Frelay.nostrtalk.org%2F) This was the link. ##### Maybe Hodlbod takes a step back and joins Unanimity. I don't think a step back is a possibility. Maybe there are updates and they make a specific base workflow Relays based group and then the various branches NIP-29 chachi and 0xchat and the others (Telegram group) Flotilla (discord) It seems like there is a reconciliation at least to converge everyone 😉 "shallow reply hierarchies" Kohei is also mentioned 🤙 NFC card article An interesting article nostr:naddr1qvzqqqr4gupzqx760c0h894a5tg7lxgr8k506twrv2qs0yxln0nz7kgs8zae03xeqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg3waehxw309ahx7um5wgh8w6twv5hsqzr9v3jx2wpn8qmsz4edqe ----------- Marketplace on Nostr Help to test yojimble nostr:nevent1qvzqqqqqqypzphn4avwh5e38spagmlc0kvmulnccnelf479tvg5ldz8kv3cscvq5qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qpqw7f0ja820er7d2jfa4vq9upelw88ejha6hcvj5gxt7gqnz646r8ql2a2cp That's all!!

@ 97c70a44:ad98e322

This week I finally released Flotilla, a discord/slack-like client I've been working on for about three months. This project began as a NIP 29 client, and after 3 PRs, lots of discussion, a podcast, and a partial implementation, I decided to go my own way. This of course means that I broke compatibility with all the NIP 29 group clients out there, but I did it for good reasons. In this post I hope to explain those reasons, and speculate on how best to move forward with "relay-based" groups on nostr. To give you some quick context, NIP 29 and my approach to groups (which I'll dub "relays-as-groups" for clarity) are very similar, with a fundamental difference. Both have chat, join requests, group metadata, membership, moderation, etc. However, the basic unit of a NIP 29 group is a random group id string, while the basic unit of a Flotilla group is a relay itself. I believe this design difference emerged in part because of what we were attempting to build. NIP 29 groups tend to be more telegram-like, where groups function more like chat rooms, and users join each one individually. On flotilla, groups function more like Discord servers, or Slack workspaces, and users join an entire group of chat rooms at once. "Relays as groups" has four major advantages over "groups hosted by relays". # Decentralization First, using relays as groups supports decentralization better than hosting user-managed groups on relays. (To be clear here, I'm not referring to client-managed groups, which is a whole different approach that we've experimented with in the past, both with NIP 72 communities and with [NIP 87](https://github.com/nostr-protocol/nips/pull/875) encrypted groups. Both NIP 29 and relays-as-groups solve many of the consistency problems associated with attempting to have a linear, synchronous conversation across multiple relays. While both alternatives have a story for migrating or mirroring a group, both rely heavily on the host relay to not censor user messages.) I know what you're thinking. How can _reducing_ the number of relays _improve_ decentralization? Relays were originally introduced in order to create redundancy and spread trust across many actors, creating censorship resistance. This model was difficult for many bitcoiners to wrap their heads around, because it's a very different kind of decentralization than what a blockchain delivers. Communities are an essentially different use case from a broadcast network where content is delivered based on author or recipient relay selections. Every message to a community would have to be delivered to all members of the community. Sending each message to all members' personal inbox relays just doesn't make sense; there has to be some other inbox for the community to work off of. Additionally, online communities almost always have moderators and admins. This is even true of very public, open types of communities, like subreddits. The only type of community that doesn't have moderators is one that emerges naturally from social clustering. And even in that case there is loose consensus about who is in and who isn't, based on the actions/follows/mutes of the participants, whether these clusters are huge or tiny. Socially-emergent groups are served well by chat applications or broadcast networks. But the subset of online communities that do prefer to confer moderator status on certain members are _essentially centralized_. In other words, centralization and control is a feature, not a bug. Now, that doesn't mean there don't need to be considerations around credible exit and removing/adding moderators over time. But the fact is that moderator-led communities are always under the oversight of the moderators at any given time, even if the identity of those moderators changes and their power is limited. What this implies is that decentralization for moderator-led groups looks very different from decentralization for a broadcast network. There is nothing at all wrong with giving moderators full control over the group's communications (qua the group; DMs and public broadcast content between group members should happen outside the group's infrastructure, just as people also exist outside the communities they are a part of). What is important is that no one has control over groups that they aren't nominally the admin of. In concrete terms, what this all means is that community moderators should self-host their infrastructure. This is the same principle as motivates self-custody and home servers, but applied to communities. If community leaders manage their own relays, this means that no hosting company or relay admin can de-platform their community. Centralization of network infrastructure in this case aligns with the trust structure of the group. Applying this to our group dilemma, it's easy to see that NIP 29 groups are more vulnerable to censorship or data harvesting attacks by malicious relay admins, since many unrelated groups might live on a single relay. In contrast, if you treat relays as groups themselves, every group is forced to live on a separate relay, spreading risk across more hosting providers. Now, this doesn't necessarily mean that many "relays" aren't "virtual relays" managed by the same hosting provider. So I'll admit that even "relay-based" groups don't completely solve this problem. But I think it will tend to nudge community organizers toward thinking about community infrastructure in a more self-sovereign (or community-sovereign) way. # Investment in Relays While both NIP 29 and relays-as-groups rely heavily on relays to implement the features that support each specification, there's an important difference between the feature sets. In NIP 29, relay support is specific only to groups, and isn't applicable to other use cases. In contrast, every protocol feature added to support the "relays as groups" can be re-purposed for other types of relays. Take join requests for example. NIP 29's kind `9021` events allow users to request access to a group, and that's all. [Kind `28934` join requests](https://github.com/nostr-protocol/nips/pull/1079) on the other hand allow users to request access to relays. Which in the relays-as-groups model means group access, but it also means custom feed access, inbox relay access, maybe even blossom server access. In fact, kind `28934` was originally proposed at the beginning of this year in order to support a different version of hosted groups, but remains as relevant as it ever was despite iteration on groups. The orthogonality of features added to relays to any specific use case will long-term result in simpler specs, and more interesting relay-based use cases being possible. Join requests are only one example. The same is true of 1984-based moderation, the proposed LIMITS command, AUTH, NIP 11 relay metadata, etc. We already have web of trust relays, feed relays, archival relays, and [many more](https://github.com/nostr-protocol/nips/issues/1282). Being able to request access to closed versions of these is useful. Being able to signal federation between multiple instances of these, run by different people, is useful. And of course, relay metadata, reports, and LIMITS are self-evidently useful for normal relays, since they pre-date Flotilla. I've always said that relays are some of the coolest and most under-appreciated parts of nostr. This doesn't mean that we should add every possible feature to them, but features related to data curation and access control fit really well with what relays are good for. For more on the role of relays and what features should be added to them, see my nostrasia talk [Functional Relays](https://www.youtube.com/watch?v=R-5DHymkfzw). # Declarative vs Imperative A common paradigm in programming is that of declarative vs imperative programming. Imperative programming focuses on "how" to achieve a given result, leaving "what" the code is doing to be inferred by the programmer. Declarative programming instead focuses on the "what", and allows some underlying implementation to solve the how. A good balance between these paradigms (and knowing when to use one over the other) allows programmers to work faster, make fewer mistakes, and produce less code. Another way to look at this is that a specification should contain as much ambiguity as possible, but without compromising the system attributes the specification is supposed to guarantee. It can get complex when figuring out what attributes are core to the specification, since sometimes the "how" does actually matter a lot. However, nostr in particular falls pretty far along the "declarative" end of this spectrum because of its decentralized nature. The only person who can say anything with any authority is the person who signs an event. This event is a "declaration", and any effects it has are necessarily up to the relays, clients, and people interpreting the event. However, what others do with an event is an expectation that must be taken into account by the publisher, forming a feedback loop. This dialectic is what creates stability in the protocol. In more concrete terms, no one can "tell" anyone else what they have to do by publishing an event like you might in a traditional, centralized RPC-type system. Any event whose semantics are a "command" rather than a "fact" or "request" is broken unless the counter party is fully committed to carrying out the command. An example of a "command" scenario on nostr is NIP 46 remote signing, in which the bunker is the agent of the user making the request. If the bunker implementation fails to carry out a valid command initiated by the user, its interpretation of that event is objectively incorrect. NIP 29 applies this same paradigm to relays, particularly in the area of moderation, membership edits, and group metadata. In other words, there are several "commands" which instruct the relay to do something. This isn't necessarily a bad thing, but it does increase the number of things the interface between the client and relay have to agree on. A regular relay may accept an `add-user` request, but then do nothing with it, violating the contract it has implicitly accepted with the user. The solution to this is feature detection, which is a whole other API to be specified and implemented. My ideal solution to this problem is to shift the semantics of events away from "commands" to "facts" - in other words, to make the interface more declarative. In fact, we already have an interface for moderation that works like this. Many clients support kind `1984` "report" events. Users sending these reports have no expectations about how they will be used. They are a "fact", a declaration of opinion with certain semantics. Other actors in the network may choose whether or not to pay attention to these. This same model is easily applied to communities. Without having to implement any feature detection (either for the relay's implementation, or for the user's role on that relay), anyone can simply send a "report". This goes into the black hole of the relay, and may subsequently be ignored, broadcasted, or acted on. The really nice thing about this model is that because there is no expectation for "how" reports are to be interpreted, any approach to moderation can be used depending on relay policy or client implementation. In NIP 29, if you issue a `delete-event`, it either happens or it doesn't and if it doesn't, you have to explain the failure to the user somehow. In the relays-as-groups model, e-tagging an event in a kind `1984` requires no user feedback, and therefore it can be interpreted however the relay prefer. This can result in insta-banning, manual review, thresholds based on number of reporters, a leaky-bucket social score algorithm, shadow banning, temporary banning, soft-moderation by allowing clients to request reports and respond to them by changing user interface elements, or anything else you can think of. The reason I think this is important is that community moderation is a _very_ hard problem, and baking certain semantics into the specification can result in the complete failure of the spec. NIP 72 should be considered an example of what not to do. Some NIP 72 communities have survived due to the dedication of the moderators, but many more have failed because of the rigid moderation model. We should try not to make the same mistake again. # Conclusion Now, having said all that, I think there is actually a lot of value to NIP 29. What finally clicked for me this week after releasing Flotilla is that the two approaches are actually complementary to one another. One of the most common feature requests I've already heard for flotilla is to have more complete support for rooms, which are currently implemented as not much more than hashtags. Better rooms (i.e., "nested groups") would require: authentication, membership, moderation, and pretty much everything else that exists for the top-level group. As much as I believe the relays-as-groups approach is superior to NIP 29 for top-level groups, it doesn't make any sense to try to "nest" relays to create sub-groups. Something like NIP 29 is needed in order to fully support rooms anyway, so I think the convergence of the two approaches is all but inevitable. In fact, fiatjaf has already merged a [PR](https://github.com/nostr-protocol/nips/pull/1591) which will allow me to use the same event kinds in flotilla as exist already in NIP 29 clients. There are just a few more changes that are necessary in order for me to fully adopt NIP 29 in Flotilla: - [NIP 29 feature detection](https://github.com/nostr-protocol/nips/pull/1604) - [Opaque ids for unmanaged groups prevent unmanaged groups from having human-readable names](https://github.com/nostr-protocol/nips/pull/1603) - [We need a mechanism for building membership lists without relay support](https://github.com/nostr-protocol/nips/pull/1602) - [Better handling for `9021` group join requests](https://github.com/nostr-protocol/nips/pull/1601) I've opened PRs for each of these (linked above). Hopefully we can work through these issues and combine our powers to become the Captain Planet of group implementations.

@ a39d19ec:3d88f61e

A state-controlled money supply can influence the development of socialist policies and practices in various ways. Although the relationship is not deterministic, state control over the money supply can contribute to a larger role of the state in the economy and facilitate the implementation of socialist ideals. ## Fiscal Policy Capabilities When the state manages the money supply, it gains the ability to implement fiscal policies that can lead to an expansion of social programs and welfare initiatives. Funding these programs by creating money can enhance the state's influence over the economy and move it closer to a socialist model. The Soviet Union, for instance, had a centralized banking system that enabled the state to fund massive industrialization and social programs, significantly expanding the state's role in the economy. ## Wealth Redistribution Controlling the money supply can also allow the state to influence economic inequality through monetary policies, effectively redistributing wealth and reducing income disparities. By implementing low-interest loans or providing financial assistance to disadvantaged groups, the state can narrow the wealth gap and promote social equality, as seen in many European welfare states. ## Central Planning A state-controlled money supply can contribute to increased central planning, as the state gains more influence over the economy. Central banks, which are state-owned or heavily influenced by the state, play a crucial role in managing the money supply and facilitating central planning. This aligns with socialist principles that advocate for a planned economy where resources are allocated according to social needs rather than market forces. ## Incentives for Staff Staff members working in state institutions responsible for managing the money supply have various incentives to keep the system going. These incentives include job security, professional expertise and reputation, political alignment, regulatory capture, institutional inertia, and legal and administrative barriers. While these factors can differ among individuals, they can collectively contribute to the persistence of a state-controlled money supply system. In conclusion, a state-controlled money supply can facilitate the development of socialist policies and practices by enabling fiscal policies, wealth redistribution, and central planning. The staff responsible for managing the money supply have diverse incentives to maintain the system, further ensuring its continuation. However, it is essential to note that many factors influence the trajectory of an economic system, and the relationship between state control over the money supply and socialism is not inevitable.

@ 1bda7e1f:bb97c4d9

### Tldr - Nostr is an open protocol which is interoperable with all kinds of other technologies - You can use this interoperability to create custom solutions - Nostr apps define a custom URI scheme handler "nostr:" - In this blog I use this to integrate Nostr with NFC cards - I create a Nostr NFC "login card" which allows me to log into Amethyst client - I create a Nostr NFC "business card" which allows anyone to find my profile with a tap ### Inter-Op All The Things! Nostr is a new open social protocol for the internet. This open nature is very exciting because it means Nostr can add new capabilities to all other internet-connected technologies, from browsers to web applications. In my view, it achieves this through three core capabilities. - A lightweight decentralised identity (Nostr keys, "npubs" and "nsecs"), - A lightweight data distribution network (Nostr relays), - A set of data interoperability standards (The Nostr Improvement Protocols "NIPs"), including the "nostr:" URI which we'll use in this post. The lightweight nature is its core strength. Very little is required to interoperate with Nostr, which means many existing technologies can be easily used with the network. Over the next few blog posts, I'll explore different Nostr inter-op ideas, and also deliver my first small open source projects to the community. I'll cover– - NFC cards integrated with Nostr (in this post), - Workflow Automations integrated with Nostr, - AI LLMs integrated with Nostr. #### The "Nostr:" URI One feature of Nostr is it defines a custom URI scheme handler "nostr:". What is that? A URI is used to identify a resource in a system. A system will have a protocol handler registry used to store such URI's, and if a system has a URI registered, then it knows what to do when it sees it. You are probably already familiar with some URI schemes such as "http:" and "mailto:". For example, when you click an http link, the system knows that it describes an http resource and opens a web browser to fetch the content from the internet. A nostr: link operates in the same way. The nostr: prefix indicates a custom URI scheme specifically designed for the Nostr protocol. If a system has a Nostr application installed, that application may have registered "nostr:" in the protocol handler registry. On that system when a "nostr:" URI is clicked, the system will know that it describes a nostr resource and open the Nostr client to fetch the content from the nostr relay network. This inter-op with the protocol handler registry gives us the power to do nice and exciting things with other technologies. ### Nostr and NFC Another technology that uses URIs is NFC cards. NFC (Near Field Communication) is a wireless technology that enables devices to exchange data over a few centimeters. It’s widely used in contactless payments, access control, and information sharing. NFC tags are small chips embedded in cards or stickers which can store data like plain text, URLs, or custom URIs. They are very cheap (cents each) and widely available (Amazon with next day delivery). When an NFC tag contains a URI, such as a http: (or nostr:) link, it acts as a trigger. Tapping the tag with an NFC-enabled device launches the associated application and processes the URI. For example, tapping a tag with "nostr:..." could open a Nostr client, directing it to a specific login page, public profile, or event. This inter-op allows us to bridge the physical world to Nostr with just a tap. #### Many useful ideas There are many interesting ways to use this. Too many for me to explore. Perhaps some of these are interesting for your next side hustle? - Nostr NFC "login cards" – tap to log into Amethyst on Android, - Nostr NFC "business cards" – give to connections so they can tap to load your npub, - Nostr NFC "payment cards" – integrating lightning network or ecash, - Nostr NFC "doorbells", "punch cards", "drop boxes", or "dead drops" – put a tag in a specific place and tap to open a location-specific message or chat, - Integrations with other access control systems, - Integrations with other home automation systems, - Many more ... To start with I have built and use the "login card" and "business card" solutions. This blog post will show you how to do the same. ### Nostr Login Card You can use an NFC card to log into your Nostr client. Most Nostr clients accept a variety of login methods, from posting your nsec into the app (insecure) to using a remote signer (more secure). A less known but more secure method is to sign into a session with a tap of a specially-configured NFC card. Amethyst is a Nostr client on Android which supports this type of login. - A secure method for logging in - Optionally keeps no log in history on the device after logout - Does not require users to know or understand how keys work - Keys are kept secure on a physically-separated card to reduce risk of compromise Nostr devs think that this is useful for anti-establishment actors–Fair enough. For me, I am interested in this login card pattern as it could be useful for rolling out identities within an organisation context with less training (office workers are already familiar with door access cards). This pattern potentially abstracts away key management to the IT or ops team who provision the cards. I first discovered this when [Kohei](nostr:npub16lrdq99ng2q4hg5ufre5f8j0qpealp8544vq4ctn2wqyrf4tk6uqn8mfeq) demonstrated it in [his video](nostr:nevent1qqstx0jy5jvzgh7wr6entjuw7h58d7mapupfdpt9hkf7s4gze34a0vspremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59upzp47x6q2txs5ptw3fcj8ngj0y7qrnm7z0ft2cptshx5uqgxn2hd4ckqyqd3). Here's how you set it up at a high level– 1. Buy yourself some NFC cards 2. Get your Nostr key ready in an encrypted, password protected format called "nencryptsec" 3. Write the nencryptsec to the NFC card as a custom URI 4. Tap to load the login screen, and enter your password to login Here it is in detail– #### Buy yourself some NFC cards I found no specific requirements. As usual with Nostr so far, I tried to the cheapest possible route and it worked. Generic brand NFC cards shipped from China, I believe it was 50X for $15 from Amazon. Your mileage may vary. #### Get your Nostr key ready Your key will be saved to the NFC card in an encrypted password-protected format called "nencryptsec". Several applications support this. As we'll be using this to login to Amethyst, we will use Amethyst to output the nencryptsec for us. 1. Login to Amethyst with your nsec, 2. Open the sidebar and click "Backup Keys", 3. Enter a password, and click "Encrypt and my secret key", 4. It will add the password-protected key to your clipboard in the format "ncryptsec1...", 5. Remember to backup your password. #### Write the ncryptsec to the NFC card 1. Download the free [NFC Tools app](https://play.google.com/store/apps/details?id=com.wakdev.wdnfc) to your device, and open it, 2. Click "Write" and "Add a record", then click "Custom URL / URI", 3. Paste your nencryptsec with the nostr URI in front, i.e. "nostr:ncryptsec1..." and click OK, 4. Click "Write". NFC Tools will prompt you to "Approach an NFC tag", 5. Place your NFC card against your phone, and it will write to the card, 6. Your card is ready. #### Tap to load the login screen Tap the card against your phone again, and your phone should open the login screen of Amethyst and prompt you for your password. Once you enter your password, Amethyst will decrypt your nsec and log you in. Optionally, you can also set the app to forget you once you log out. You have created a Nostr NFC "login card". ### Nostr Business Card You can use another NFC card to give anyone you meet a link straight to your Nostr profile. I attended [Peter McCormack](nostr:npub14mcddvsjsflnhgw7vxykz0ndfqj0rq04v7cjq5nnc95ftld0pv3shcfrlx)'s #CheatCode conference in Sydney and gave a few of these out following the Nostr panel, notably to [Preston Pysh](nostr:npub1s5yq6wadwrxde4lhfs56gn64hwzuhnfa6r9mj476r5s4hkunzgzqrs6q7z) where it [got some cut through](nostr:nevent1qqsdx0acma85u9knejnvfnfms9pfv27g97mfnnq9fnxslsa9vtrx73spremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59upzppggp5a66uxvmntlwnpf5384twu9e0xnm5xth9ta58fpt0dexysy26d4nm) and found me my first 100 followers. You can do the same. To create your Nostr NFC "business card" is even easier than your NFC "login card". 1. Buy yourself some NFC cards, 2. Download the free [NFC Tools app](https://play.google.com/store/apps/details?id=com.wakdev.wdnfc) to your device, and open it, 2. Click "Write" and "Add a record", then click "Custom URL / URI", 3. Write your npub to the NFC card as a custom URI in the format "nostr:npub1..." (e.g. for me this is "nostr:npub1r0d8u8mnj6769500nypnm28a9hpk9qg8jr0ehe30tygr3wuhcnvs4rfsft"), 4. Your card is ready. Give the card to someone who is a Nostr user, and when they tap the card against their phone it will open their preferred Nostr client and go directly to your Nostr profile page. You have created a Nostr NFC "business card". ### What I Did Wrong I like to share what I did wrong so you don't have to make the same mistakes. This time, this was very easy, and little went wrong. In general - When password-protecting your nsec, don't forget the password! - When writing to the NFC card, make sure to use "Custom URI/URL" as this accepts your "nostr:" URI scheme. If you use generic "URI/URL" it won't work. ### What's Next Over my first four blogs I have explored creating a good Nostr setup - [Mined a Nostr pubkey and backed up the mnemonic](nostr:naddr1qqsy66twd9hxwtteda6hyt2kv9hxjare94g82cntv4uj6drfw4cxyeszyqda5lslwwttmgk3a7vsx0dgl5kuxc5pq7gdlxlx9av3qw9mjlzdjqcyqqq823c6e2ekw) - [Set up Nostr payments with a Lightning wallet plus all the bells and whistles](nostr:naddr1qq34xet5w35kueedw4cz65rp09kk2mn5wvkk7m3dfehhxarj95mk7dnvwvmsygqmmflp7uukhk3drmueqv763lfdcd3gzpusm7d7vt6ezquth97ymypsgqqqw4rsuql6je) - [Set up NIP-05 and Lighting Address at my own domain](nostr:naddr1qqyx2efcvy6rvcnrqyghwumn8ghj7mn0wd68ytnhd9hx2tczyqda5lslwwttmgk3a7vsx0dgl5kuxc5pq7gdlxlx9av3qw9mjlzdjqcyqqq823c634nh0) - [Set up a Personal Relay at my own domain](nostr:naddr1qqyx2efcvy6rvcnrqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7q3qr0d8u8mnj6769500nypnm28a9hpk9qg8jr0ehe30tygr3wuhcnvsxpqqqp65wmzpn9e) Over the next few blogs I will be exploring different types of Nostr inter-op - NFC cards integrated with Nostr (this post) - Workflow Automations integrated with Nostr - AI LLMs integrated with Nostr Please be sure to let me know if you think there's another Nostr topic you'd like to see me tackle. GM Nostr.

@ 06639a38:655f8f71

**Nostr-PHP** * Added generic `setTags()` and `setTag()` function to Filter object to be used in request messages from clients to relays. * Did some small improvements in the relay response handling in the websocket client code. * Trying to send closeMessages trying to the relay to get a close response back. But not any response came back from the relays I’ve tested with. * I published a new release `1.5.0` Changelog: [https://github.com/nostrver-se/nostr-php/compare/1.4.2...1.5.0](https://github.com/nostrver-se/nostr-php/compare/1.4.2...1.5.0) * I set up a new relay with [transpher](https://github.com/nostriphant/transpher) at [chat.nostr-php.dev](http://chat.nostr-php.dev). The main goal of the relay is to replace the current Nostr-PHP Telegram group with a relay based chat group (NIP-29). Repo: [https://github.com/nostrver-se/chat.nostr-php.dev](https://github.com/nostrver-se/chat.nostr-php.dev)  * Work in progress, handling TLV with NIP-19 encoded entities: [https://github.com/nostrver-se/nostr-php/pull/68](https://github.com/nostrver-se/nostr-php/pull/68) **Other stuff** * We received a message from FOSDEM that our submission for a Nostr stand at the conference is accepted! So during the weekend 1st & 2nd of February I will attend FOSDEM volunteering at the Nostr stand with four other Nostriches. * Testing things out with chachi.cat and with different relays (NIP-29). * Did some work on a proof-of-concept at [/nostrides](/nostrides) around this NIP proposal for physical activities: https://github.com/nostr-protocol/nips/pull/1423

@ 87730827:746b7d35

Original: https://techreport.com/crypto-news/brazil-central-bank-ban-monero-stablecoins/ Brazilian’s Central Bank Will Ban Monero and Algorithmic Stablecoins in the Country =================================================================================== Brazil proposes crypto regulations banning Monero and algorithmic stablecoins and enforcing strict compliance for exchanges. * * * **KEY TAKEAWAYS** * The Central Bank of Brazil has proposed **regulations prohibiting privacy-centric cryptocurrencies** like Monero. * The regulations **categorize exchanges into intermediaries, custodians, and brokers**, each with specific capital requirements and compliance standards. * While the proposed rules apply to cryptocurrencies, certain digital assets like non-fungible tokens **(NFTs) are still ‘deregulated’ in Brazil**.  In a Notice of Participation announcement, the Brazilian Central Bank (BCB) outlines **regulations for virtual asset service providers (VASPs)** operating in the country. **_In the document, the Brazilian regulator specifies that privacy-focused coins, such as Monero, must be excluded from all digital asset companies that intend to operate in Brazil._** Let’s unpack what effect these regulations will have. Brazil’s Crackdown on Crypto Fraud ---------------------------------- If the BCB’s current rule is approved, **exchanges dealing with coins that provide anonymity must delist these currencies** or prevent Brazilians from accessing and operating these assets. The Central Bank argues that currencies like Monero make it difficult and even prevent the identification of users, thus creating problems in complying with international AML obligations and policies to prevent the financing of terrorism. According to the Central Bank of Brazil, the bans aim to **prevent criminals from using digital assets to launder money**. In Brazil, organized criminal syndicates such as the Primeiro Comando da Capital (PCC) and Comando Vermelho have been increasingly using digital assets for money laundering and foreign remittances. > … restriction on the supply of virtual assets that contain characteristics of fragility, insecurity or risks that favor fraud or crime, such as virtual assets designed to favor money laundering and terrorist financing practices by facilitating anonymity or difficulty identification of the holder. > > – [Notice of Participation](https://www.gov.br/participamaisbrasil/edital-de-participacao-social-n-109-2024-proposta-de-regulamentacao-do-) The Central Bank has identified that **removing algorithmic stablecoins is essential to guarantee the safety of users’ funds** and avoid events such as when Terraform Labs’ entire ecosystem collapsed, losing billions of investors’ dollars. The Central Bank also wants to **control all digital assets traded by companies in Brazil**. According to the current proposal, the [national regulator](https://techreport.com/cryptocurrency/learning/crypto-regulations-global-view/) will have the **power to ask platforms to remove certain listed assets** if it considers that they do not meet local regulations. However, the regulations will not include [NFTs](https://techreport.com/statistics/crypto/nft-awareness-adoption-statistics/), real-world asset (RWA) tokens, RWA tokens classified as securities, and tokenized movable or real estate assets. These assets are still ‘deregulated’ in Brazil. Monero: What Is It and Why Is Brazil Banning It? ------------------------------------------------ Monero ($XMR) is a cryptocurrency that uses a protocol called CryptoNote. It launched in 2013 and ‘erases’ transaction data, preventing the sender and recipient addresses from being publicly known. The Monero network is based on a proof-of-work (PoW) consensus mechanism, which incentivizes miners to add blocks to the blockchain.  Like Brazil, **other nations are banning Monero** in search of regulatory compliance. Recently, Dubai’s new digital asset rules prohibited the issuance of activities related to anonymity-enhancing cryptocurrencies such as $XMR. Furthermore, exchanges such as **Binance have already announced they will delist Monero** on their global platforms due to its anonymity features. Kraken did the same, removing Monero for their European-based users to comply with [MiCA regulations](https://techreport.com/crypto-news/eu-mica-rules-existential-threat-or-crypto-clarity/). Data from Chainalysis shows that Brazil is the **seventh-largest Bitcoin market in the world**.  In Latin America, **Brazil is the largest market for digital assets**. Globally, it leads in the innovation of RWA tokens, with several companies already trading this type of asset. In Closing ---------- Following other nations, Brazil’s regulatory proposals aim to combat illicit activities such as money laundering and terrorism financing. Will the BCB’s move safeguard people’s digital assets while also stimulating growth and innovation in the crypto ecosystem? Only time will tell. References ---------- Cassio Gusson is a journalist passionate about technology, cryptocurrencies, and the nuances of human nature. With a career spanning roles as Senior Crypto Journalist at CriptoFacil and Head of News at CoinTelegraph, he offers exclusive insights on South America’s crypto landscape. A graduate in Communication from Faccamp and a post-graduate in Globalization and Culture from FESPSP, Cassio explores the intersection of governance, decentralization, and the evolution of global systems. [View all articles by Cassio Gusson](https://techreport.com/author/cassiog/)

@ 5e5fc143:393d5a2c

Now test old reliable front end Stay tuned more later Keeping this as template long note for debugging in future as come across few NIP-33 post edit issues

@ af9c48b7:a3f7aaf4

## Chef's notes This simple, easy, no bake desert will surely be the it at you next family gathering. You can keep it a secret or share it with the crowd that this is a healthy alternative to normal pie. I think everyone will be amazed at how good it really is. ## Details - ⏲️ Prep time: 30 - 🍳 Cook time: 0 - 🍽️ Servings: 8 ## Ingredients - 1/3 cup of Heavy Cream- 0g sugar, 5.5g carbohydrates - 3/4 cup of Half and Half- 6g sugar, 3g carbohydrates - 4oz Sugar Free Cool Whip (1/2 small container) - 0g sugar, 37.5g carbohydrates - 1.5oz box (small box) of Sugar Free Instant Chocolate Pudding- 0g sugar, 32g carbohydrates - 1 Pecan Pie Crust- 24g sugar, 72g carbohydrates ## Directions 1. The total pie has 30g of sugar and 149.50g of carboydrates. So if you cut the pie into 8 equal slices, that would come to 3.75g of sugar and 18.69g carbohydrates per slice. If you decided to not eat the crust, your sugar intake would be .75 gram per slice and the carborytrates would be 9.69g per slice. Based on your objective, you could use only heavy whipping cream and no half and half to further reduce your sugar intake. 2. Mix all wet ingredients and the instant pudding until thoroughly mixed and a consistent color has been achieved. The heavy whipping cream causes the mixture to thicken the more you mix it. So, I’d recommend using an electric mixer. Once you are satisfied with the color, start mixing in the whipping cream until it has a consistent “chocolate” color thorough. Once your satisfied with the color, spoon the mixture into the pie crust, smooth the top to your liking, and then refrigerate for one hour before serving.

@ 41e6f20b:06049e45

Let me tell you a beautiful story. Last night, during the speakers' dinner at Monerotopia, the waitress was collecting tiny tips in Mexican pesos. I asked her, "Do you really want to earn tips seriously?" I then showed her how to set up a Cake Wallet, and she started collecting tips in Monero, reaching 0.9 XMR. Of course, she wanted to cash out to fiat immediately, but it solved a real problem for her: making more money. That amount was something she would never have earned in a single workday. We kept talking, and I promised to give her Zoom workshops. What can I say? I love people, and that's why I'm a natural orange-piller.

@ fd208ee8:0fd927c1

## Drumroll, please.... In a previous article, I introduced the concept of [relay communities](nostr:naddr1qvzqqqr4gupzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqydhwumn8ghj7argv4nx7un9wd6zumn0wd68yvfwvdhk6tcpr3mhxue69uhhg6r9vd5hgctyv4kzumn0wd68yvfwvdhk6tcqp5cnwvesxcunjwpcxymrsvgwmj66e). The ink had barely dried, on that set of instructions, before one of my favorite Nostr devs, [ثعبان](nostr:nprofile1qythwumn8ghj7enjv4h8xtnwdaehgu339e3k7mf0qy88wumn8ghj7mn0wvhxcmmv9uqzqla9dawkjc4trc7dgf88trpsq2uxvhmmpkxua607nc5g6a634sv598gk68), rolled out the alpha version of a relay-community client.  Obviously, it's still a bit of a construction site, but you can check out how it'd work, for your community, by test-driving the functionality on your own relay. Simply type _https://chachi.chat/_ followed by the name of your relay. For instance, one gigantic relay community, where nearly everyone can try out the functionality, is [nos.lol](https://chachi.chat/nos.lol). If your relay community does not require AUTH to read, anyone can pull your chatter into their own relay and respond to it there. That is because every chat entry is simply a kind 09 event, and unprotected events are not private data. For instance, I moderate one community [theforest.nostr1.com](https://chachi.chat/theforest.nostr1.com), that is openly readable, and that's probably where most of the chatter on [nostr.band](https://chachi.chat/relay.nostr.band) is coming from, as that relay is an aggregator of the content of many other relays. However, I have another community, [gitcitadel.nostr1.com](https://chachi.chat/gitcitadel.nostr1.com) that is AUTH-protected, whose content stays private to those allowed on that relay. Communities are where write-protected and AUTH relays are going to really shine, as they create an environment similar to Telegram, but where you control the dataset, you decide which types of events to support, and you design the client, the algos, the moderation, the visibility, etc. With communities, **the onboarding experience is seamless**: just get a browser extension and a nsec, login, start writing and posting, and _start receiving responses_. Active, chatty, well-moderated communities will be more attractive to onboard to, than chaotic, spammy, or empty communities. This means that you don't have to have the killer entry under "Posts" (where kind 11 and eventually kind 01 posts appear), just to get some interaction. Chat is the Great Equalizer. So, we're testing both setups, with [cloudfodder](nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzfmhxue69uhkummnw3eryvfwvdhk6tcqyp7vx29q3hdj4l0elxl800hlfjp538le09epsf7k9zj59ue2y37qu84upun) adjusting the relay faucet code and ثعبان is fiddling with the community client settings, to make the most-comfortable situation for both kinds.  ## This is the signal This #Chachi client, of course, is merely the first horse out of the gate. There are already other devs hacking away at variants of the same concept, such as [#Flotilla](https://flotilla.coracle.social/), I'm sure CloudFodder is also cooking, later versions of #Alexandria will integrate theforest community, and etc. etc. etc. It remains to be seen, how many new use cases can be dreamt up, with this new architecture, but I am quite certain, that this is the beginning of the end of Nostr 1.0. We are moving up and out, and away from the stultifying and limiting concept of Twitter 2.0, toward  Soon, we will enter Nostr 2.0. See you on the other side.

@ fd208ee8:0fd927c1

## You have no idea I regularly read comments from people, on here, wondering how it's possible to marry -- or even simply be friends! -- with someone who doesn't agree with you on politics. I see this sentiment expressed quite often, usually in the context of Bitcoin, or whatever _pig is currently being chased through the village_, as they say around here.  It seems rather sensible, but I don't think it's as hard, as people make it out to be. Further, I think it's a dangerous precondition to set, for your interpersonal relationships, because the political field is constantly in flux. If you determine who you will love, by their opinions, do you stop loving them if their opinions change, or if the opinions they have become irrelevant and a new set of opinions are needed -- and their new ones don't match your new ones? We could see this happen to relationships en masse, during the Covid Era, and I think it happens every day, in a slow grind toward the disintegration of interpersonal discourse. I suspect many people do stop loving, at that point, as they never really loved the other person for their own sake, they loved the other person because they thought the other person was exactly like they are. But no two people are alike, and the longer you are in a relationship with someone else, the more the initial giddiness wears off and the trials and tribulations add up, the more you notice how very different you actually are. This is the point, where best friends and romantic couples say, _We just grew apart._ But you were always apart. You were always two different people. You just didn't notice, until now.  I've also always been surprised at how many same-party relationships disintegrate because of some disagreement over some particular detail of some particular topic, that they generally agree on. To me, it seems like an irrelevant side-topic, but _they can't stand to be with this person_... and they stomp off. So, I tend to think that it's less that opinions need to align to each other, but rather than opinions need to align in accordance with the level of interpersonal tolerance they can bring into the relationship. ## I was raised by relaxed revolutionaries Maybe I see things this way because my parents come from two diverging political, cultural, national, and ethnic backgrounds, and are prone to disagreeing about a lot of "important" (to people outside their marriage) things, but still have one of the healthiest, most-fruitful, and most long-running marriages of anyone I know, from that generation. My parents, you see, aren't united by their opinions. They're united by their relationship, which is something _outside_ of opinions. Beyond opinions. Relationships are what turn two different people into one, cohesive unit, so that they slowly grow together. Eventually, even their faces merge, and their biological clocks tick to the same rhythm. They eventually become one entity that contains differing opinions about the same topics. It's like magic, but it's the result of a mindset, not a worldview. Or, as I like to quip: > The best way to stay married, is to not get divorced.  My parents simply determined early on, that they would stay together, and whenever they would find that they disagreed on something that _didn't directly pertain to their day-to-day existence with each other_ they would just agree-to-disagree about that, or roll their eyes, and move on. You do you. Live and let live. My parents have some of the most strongly held personal opinions of any people I've ever met, but they're also incredibly tolerant and can get along with nearly anyone, so their friends are a confusing hodgepodge of _people we liked and found interesting enough to keep around_. Which makes their house parties really fun, and highly unusual, in this day and age of mutual-damnation across the aisle.  The things that did affect them, directly, like which school the children should attend or which country they should live in, etc. were things they'd sit down and discuss, and somehow one opinion would emerge, and they'd again... move on. And that's how my husband and I also live our lives, and it's been working surprisingly well. No topics are off-limits to discussion (so long as you don't drone on for too long), nobody has to give up deeply held beliefs, or stop agitating for the political decisions they prefer. You see, we didn't like that the other always had the same opinion. We liked that the other always held their opinions strongly. That they were passionate about their opinions. That they were willing to voice their opinions; sacrifice to promote their opinions. And that they didn't let anyone browbeat or cow them, for their opinions, not even their best friends or their spouse. But that they were open to listening to the other side, and trying to wrap their mind around the possibility that they _might just be wrong about something_.  We married each other because we knew: this person really cares, this person has thought this through, and they're in it, to win it. What "it" is, is mostly irrelevant, so long as it doesn't entail torturing small animals in the basement, or raising the children on a diet of Mountain Dew and porn, or something. Live and let live. At least, it's never boring. At least, there's always something to ~~argue~~ talk about. At least, we never think... we've just grown apart.

@ 4ba8e86d:89d32de4

Tutorial feito por Grom mestre⚡poste original abaixo: http://xh6liiypqffzwnu5734ucwps37tn2g6npthvugz3gdoqpikujju525yd.onion/240277/tutorial-criando-e-acessando-sua-conta-de-email-pela-i2p?show=240277#q240277 Bom dia/tarde/noite a todos os camaradas. Seguindo a nossa série de tutoriais referentes a tecnologias essenciais para a segurança e o anonimato dos usuários, sendo as primeiras a openPGP e a I2P, lhes apresento mais uma opção para expandir os seus conhecimentos da DW. Muitos devem conhecer os serviços de mail na onion como DNMX e mail2tor, mas e que tal um serviço de email pela I2P. Nesse tutorial eu vou mostrar a vocês como criar a sua primeira conta no hq.postman.i2p e a acessar essa conta. É importante que vocês tenham lido a minha primeira série de tutoriais a respeito de como instalar, configurar e navegar pela I2P nostr:nevent1qqsyjcz2w0e6d6dcdeprhuuarw4aqkw730y542dzlwxwssneq3mwpaspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqsyp5vcq Esse tutorial é um pré-requisito para o seguinte e portanto recomendo que leia-os antes de prosseguir com o seguinte tutorial. O tutorial de Kleopatra nostr:nevent1qqs8h7vsn5j6qh35949sa60dms4fneussmv9jd76n24lsmtz24k0xlqzyp9636rd9ktcjmwfxd7ru5qxjxyn6uch2uhas8utg8wa5hvf6vk7gqcyqqqqqqgecq8f7 é complementar dado que é extremamente recomendado assinar e criptografar as mensagens que seguem por emails pela DW. Sem mais delongas, vamos ao tutorial de fato. ## 1. Criando uma conta de email no hq.postman Relembrando: Esse tutorial considera que você já tenha acesso à I2P. Entre no seu navegador e acesse o endereço hq.postman.i2p. O roteador provavelmente já contém esse endereço no seu addressbook e não haverá a necessidade de inserir o endereço b32 completo. Após entrar no site vá para a página '1 - Creating a mailbox' https://image.nostr.build/d850379fe315d2abab71430949b06d3fa49366d91df4c9b00a4a8367d53fcca3.jpg Nessa página, insira as credenciais de sua preferências nos campos do formulário abaixo. Lembre-se que o seu endereço de email aceita apenas letras e números. Clique em 'Proceed' depois que preencher todos os campos. https://image.nostr.build/670dfda7264db393e48391f217e60a2eb87d85c2729360c8ef6fe0cf52508ab4.jpg Uma página vai aparecer pedindo para confirmar as credenciais da sua nova conta. Se tudo estiver certo apenas clique em 'Confirm and Create Mailbox'. Se tudo ocorrer como conforme haverá uma confirmação de que a sua nova conta foi criada com sucesso. Após isso aguarde por volta de 5 minutos antes de tentar acessá-la, para que haja tempo suficiente para o servidor atualizar o banco de dados. https://image.nostr.build/ec58fb826bffa60791fedfd9c89a25d592ac3d11645b270c936c60a7c59c067f.jpg https://image.nostr.build/a2b7710d1e3cbb36431acb9055fd62937986b4da4b1a1bbb06d3f3cb1f544fd3.jpg Pronto! Sua nova conta de email na I2P foi criada. Agora vamos para a próxima etapa: como acessar a sua conta via um cliente de email. ## 2. Configurando os túneis cliente de SMTP e POP3 O hq.postman não possui um cliente web que nos permite acessar a nossa conta pelo navegador. Para isso precisamos usar um cliente como Thunderbird e configurar os túneis cliente no I2Pd que serão necessários para o Thunderbird se comunicar com o servidor pela I2P. Caso não tenha instalado o Thunderbird ainda, faça-o agora antes de prosseguir. Vamos configurar os túneis cliente do servidor de email no nosso roteador. Para isso abra um terminal ou o seu gestor de arquivos e vá para a pasta de configuração de túneis do I2P. Em Linux esse diretório se localiza em /etc/i2pd/tunnels.d. Em Windows, essa pasta se localiza em C:\users\user\APPDATA\i2pd. Na pasta tunnels.d crie dois arquivos: smtp.postman.conf e pop-postman.conf. Lembre-se que em Linux você precisa de permissões de root para escrever na pasta de configuração. Use o comando sudoedit <nome_do_arquivo> para isso. Edite-os conforme as imagens a seguir: Arquivo pop-postman.conf https://image.nostr.build/7e03505c8bc3b632ca5db1f8eaefc6cecb4743cd2096d211dd90bbdc16fe2593.jpg Arquivo smtp-postman.conf https://image.nostr.build/2d06c021841dedd6000c9fc2a641ed519b3be3c6125000b188842cd0a5af3d16.jpg Salve os arquivos e reinicie o serviço do I2Pd. Em Linux isso é feito pelo comando: ``` sudo systemctl restart i2pd ``` Entre no Webconsole do I2Pd pelo navegador (localhost:7070) e na seção I2P Tunnels, verifique se os túneis pop-postman e smtp-postman foram criados, caso contrário verifique se há algum erro nos arquivos e reinicie o serviço. Com os túneis cliente criados, vamos agora configurar o Thunderbird ## 3. Configurando o Thunderbird para acessar a nossa conta Abra o Thunderbird e clique em criar uma nova conta de email. Se você não tiver nenhum conta previamente presente nele você vai ser diretamente recebido pela janela de criação de conta a seguir. https://image.nostr.build/e9509d7bd30623716ef9adcad76c1d465f5bc3d5840e0c35fe4faa85740f41b4.jpg https://image.nostr.build/688b59b8352a17389902ec1e99d7484e310d7d287491b34f562b8cdd9dbe8a99.jpg Coloque as suas credenciais, mas não clique ainda em Continuar. Clique antes em Configure Manually, já que precisamos configurar manualmente os servidores de SMTP e POP3 para, respectivamente, enviar e receber mensagens. Preencha os campos como na imagem a seguir. Detalhe: Não coloque o seu endereço completo com o @mail.i2p, apenas o nome da sua conta. https://image.nostr.build/4610b0315c0a3b741965d3d7c1e4aff6425a167297e323ba8490f4325f40cdcc.jpg Clique em Re-test para verificar a integridade da conexão. Se tudo estiver certo uma mensagem irá aparecer avisando que as configurações do servidores estão corretas. Clique em Done assim que estiver pronto para prosseguir. https://image.nostr.build/8a47bb292f94b0d9d474d4d4a134f8d73afb84ecf1d4c0a7eb6366d46bf3973a.jpg A seguinte mensagem vai aparecer alertando que não estamos usando criptografia no envio das credenciais. Não há problema nenhum aqui, pois a I2P está garantindo toda a proteção e anonimato dos nossos dados, o que dispensa a necessidade de uso de TLS ou qualquer tecnologia similar nas camadas acima. Marque a opção 'I Understand the risks' e clique em 'Continue' https://image.nostr.build/9c1bf585248773297d2cb1d9705c1be3bd815e2be85d4342227f1db2f13a9cc6.jpg E por fim, se tudo ocorreu como devido sua conta será criada com sucesso e você agora será capaz de enviar e receber emails pela I2P usando essa conta. https://image.nostr.build/8ba7f2c160453c9bfa172fa9a30b642a7ee9ae3eeb9b78b4dc24ce25aa2c7ecc.jpg ## 4. Observações e considerações finais Como informado pelo próprio site do hq.postman, o domínio @mail.i2p serve apenas para emails enviados dentro da I2P. Emails enviados pela surface devem usar o domínio @i2pmai.org. É imprescindível que você saiba usar o PGP para assinar e criptografar as suas mensagens, dado que provavelmente as mensagens não são armazenadas de forma criptografada enquanto elas estão armazenadas no servidor. Como o protocolo POP3 delete as mensagens no imediato momento em que você as recebe, não há necessidade de fazer qualquer limpeza na sua conta de forma manual. Por fim, espero que esse tutorial tenha sido útil para vocês. Que seu conhecimento tenha expandido ainda mais com as informações trazidas aqui. Até a próxima.

@ 06639a38:655f8f71

* I published a blog **1 year later, why Nostr still resonates** [https://nostrver.se/blog/1-year-later-why-nostr-still-resonates](https://nostrver.se/blog/1-year-later-why-nostr-still-resonates)  * This blog is also cross-posted to Nostr: [link here](nostr:naddr1qvzqqqr4gupzqpnrnguxe8qszsshvgkvhn6qjzxy7xsvx03rlrtddr62haj4lrm3qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qpxxykhjetpwgkkcct5v4ez6amg0ykkummnw3ez6um5d9kxcttjv4ek7mnpw3jhx2pskd0) * I'm running a promenade signer  * I've worked out some Nostr the protocol explained sketches   * Did some improvements on the relay response handling in the websocket client within the Nostr-PHP library * Worked on integrating the TLV part of NIP-19 which is a struggle in the Nostr-PHP library

@ fd208ee8:0fd927c1

## Unsucking the feed is real As a Nostrich with an interesting, thought-provoking, and informative feed... a feed so good, that we're creating clients just to look at that feed... a feed that puts a lie to the idea that Nostr is nothing, but people reposting from Twitter or rehashing worn-out Bitcoin memes... a feed that I personally and increasingly enjoy perusing... I am here to tell you that the feed is real.  It's taken me over a year, to produce this feed. I literally spent hours and hours, day in and day out, scouring the Nostrverse for people worth introducing other people to. It was brutally difficult, as I was fighting the inherent nature of the Nostr clients and relays, in their current, most-popular form. ## It goes like so... Here are the steps I took, that sometimes weren't possible to take, until I tried to take them, and that still will sometimes break your client because the clients are often _intentionally_ designed to steer you into having one particular feed: 1) **Make a screenshot** of your current relay list and copy your follows list. 2) **Unsubscribe from all the relays**, that you are currently subscribed to. Your feed should disappear. If it doesn't, or it doesn't allow for this, switch to a different client app because yours is corrupted. 3) **Unfollow everyone.** Delete the whole list. You are taking your follows private, which will invariably result in only following npubs whose stuff you actually want to see, since there's no longer any virtue-signaling going on. Also, it's easier to explain having no list, than a very short one. If your client doesn't allow for this, or starts throwing error messages and freezing up, then switch to a different client app because yours is corrupted. 4) **Curate your copied follows list.** Go line by line and look at the feed produced by the npub on that list. * Do you want to see that in your feed, going forward? * Do they produce original content and/or are they interesting conversationalists, in the replies? * Have they been active, within the past three months? * Are they simply good friends or real-life acquaintances, that you want to keep tabs on? * If not, cross out their name. * If you have been following someone because they repost or quote interesting things, **look at who they've been reposting** and follow them, instead. 5) Of the npubs remaining on your list, go through and select the 10 most interesting ones, and **look at the reposts and quotes** in their feed, and their topical lists like "Favorites", "Devs", "Recipes", etc. (Not their follows list, unless it's quite short, as follows tend to be full of people they follow for social-signaling or client-functional reasons, that they don't actively look at.) Find some new follows, there. 6) Now, set up a personal relay and add all the follows, that made the cut, to **your allowed-npubs list**. Do not add people to the list, just to make them feel better, or because you feel guilty, as they follow you, or to keep them from yelling at you. Remember, they can't see the list! 7) Think about the topics you find interesting, and add an **allowed-keywords list** (this is better than hashtags, as it searches the entire content of the notes), with the OR operator (these allowed npubs OR these allowed topics). 8) Make sure that you choose words likely to find the content you are most-interested in, and not people just ranting about it or spamming (those are great additions to your relay's block-list). If you are Muslim, for instance, instead of "Islam" or "shariah", choose "hadith" or "riba", as those are words more-likely to be used by people who know what they are talking about. If you are into bread baking, add "sourdough", "rye", "yeast", or "whisk", but don't add "bread" or "carbs". Once a note from those people shows up in your feed, and their feed looks like someone interesting, you can add their npub to your allow list. Remember: **The topics are there to find people to add to the allow list**, not merely for their own sake, as this is not a topical relay, but a personal one. 9) Open up a faucet (or relay syncing) with some of the big relays you previously unsubscribed from, some WoT relays, and some of the paid relays (nostr.land, nostr.wine, nostr21.com, and sovbit.host, for example). **Your relay will filter that feed** and only accept the events from the people and topics on your list. As your relay becomes more popular, npubs will begin writing directly to it, and the connections to other relays will sink in significance. 10) Go to your client of choice and **subscribe to your new relay**. Also subscribe to some topical relays, or curated neighborhood relays, you find interesting or your frens are running. This is an easy way to find new, interesting npubs, to add to your own relay.  That's a lot of work, you say? Yes, but the result is great, and you are now fully in-charge of your own feed. You also -- here's the cool part -- have a feed good enough, that other people can add your feed to theirs and enjoy your manual curation. As you refine and expand your feed, theirs will also be refined, in parallel. You are now an official Nostr Community Curator. My sincere congratulations.  ## Why is this so hard? This is only a lot of work because the clients aren't designed to interact with relays, to this extent, as they were created to service mega-relays, download all their crap to your local cache, and adjust the feed over the follows/mutes lists. This was an idea borne of the axiom that Relays Are Hard, so there will only ever be a handful of them, where we'd all clump together and the relay operators would never judge the quality of someone's content. Then, some unusually clever people made relays increasingly easy, and the mailbox communication model was invented, and here we are. What we have now, and that is slowly growing in popularity, among the #NostrIntelligentsia, are Nostr clients aimed at curating and viewing individual relays or personalized sets of smaller or more-specialized relays. The reigning client devs refused to give us those clients, and most of us aren't up to developing our own clients, so the relay devs took matters into their own hands and made the clients themselves. The free market remains undefeated. This is a total game-changer. Last one to board this train is a rotten egg. Originally, relays were supposed to be completely stupid and clients were supposed to be completely smart, but it's now actually the other way around, because most relay devs have a market-born incentive to make their content highly customizable and appealing to individuals (so that more people run relays). ## But what about algos? Can't you just slap an algo on top of Damus, Lol, or Primal relays, and get the same result? I would argue... no. No, you can't. Or, rather, only in the short to medium term. Running your own relay, is running your own server. You are now _intellectually independent_, at a machine-level, and therefore a fully sovereign consumer. If you then use algos to control your own server, or in a client that subscribes to your own server, then you can further-refine a feed that is already in a high-to-you-signal state, rather than risking an algo inching you toward the Consensus Feed. I have noticed that my own feed is slowly drifting away from the ReplyGuy-Cryptobot-Porny-Bitcoin-Meme Dumpster Fire, that almost everyone else is looking at, and it's due to running my own relay. If I use DVMs, those algos sometimes refer to relays I intentionally avoid, so they return results according to those relays. The results are as underwhelming, as you would expect, and often are simply 31 flavors of the Trending List. But, that isn't your problem, anymore. From here, you can actively expand and refine your feed, over your allow-list, the topics, and your personally-managed algos. Happy Nostr-ing!

@ 592295cf:413a0db9

### Rereading the past articles, they seem to get something mystical. I really wrote this article and yes. Yakihonne sent me 21 sats, thank you! ! ! ----- I left some links to long articles, you can read them or not, sorry. ----- ## Elections are always recounts or broils, we can not vote or let anyone who does not complain, and then people use social media to complain and complain about hatred over these last, less hatred. ### Vitor wrote a NPs for pexel feed, but he forgot videos. He called it Instagram feed, but I think when people now think about Instagram they think about reels and not photos with filters. You really want a social interaction, photo feed. "I just want pictures to cover in the blog, or meme template" I tried *Cornychat*, it works. Not having a microphone, the computer's microphone was freaking out, from the phone I felt the computer's return. It has many features, including chat, slide, post on *Nostr*. It has a secret mood and you can share the room with the link. I'll have to buy a microphone for Christmas, I don't think I do, I'm afraid it's the way to start a podcast. I'm trying to make a client that counts I like, zap and RT. The first takes from global, the second takes from your timeline. I did one for long form article. ### Openvibe added Threads, first version. So from threads to Nostr 🤙 Always the usual thing if sending spam to people or not, I opted for no. Just give random answers to random people. Only naive, standard answers. No more vattelapesca situation increases only expectations, then he knows something. I don't know anything. But maybe I could do two broken links. I like it as a name for a site, maybe that of AI local-first & whatsever projects. Waiting for this to become something WoT Max 0.2 on coracle feed to avoid influncer, I think Voyager can use this NPs, has almost everything ready. 1. ## Laeserin, silberengel or or one of these names wrote an article [How to find humans on Nostr](https://yakihonne.com/article/naddr1qvzqqqr4gupzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqqxnzdenxqcnsdpexcmrxvfhy8lvk0) I haven't read it yet. How to find humans and avoid them. I think her logic is focused on fix the world, fix Bitcoin, fix Nostr. That just what a human person would do. I am pleased to have found these users and if necessary interact with them, it is like a microcosm. If there are few users better it will end sooner. Good thing I'm doing my algorithm so I can get it with myself for the results. I upgraded to nostr_sdk 0.35.1 If *Yakihonne* becomes a content creator application, I'll have to look for another platform, I have to see if freerse is still available. Someone wrote on *Mastodon* that *Nostr* is a place for: > The best place to talk alone is definitely #Nostr :blobfoxangrylaugh: Cool means you can do your things makes public gifts without need of privacy (lol) If you are a developer build, the rest is secondary. 2. ## Derek Ross smart widget one of the most beautiful things this week, maybe you can see with embed here [smart widget nostr:naddr1qq2kyt28xay8s46cgekhsefnwavyusf4w42z6q3q8ams6ewn5aj2n3wt2qawzglx9mr4nzksxhvrdc4gzrecw7n5tvjqxpqqqp657hzkura](https://yakihonne.com/naddr1qvzqqqr4fupzq0mhp4ja8fmy48zuk5p6uy37vtk8tx9dqdwcxm32sy8nsaa8gkeyqq2kyt28xay8s46cgekhsefnwavyusf4w42z62nh2c8) Still too early and content creator don't use, but if it does trend they can start using. I downloaded *Yakihonne* app and looks good, there are still bugs with Amber. As soon as it was downloaded at the opening it blocked the phone, scrolling I was watching a video, but then the video lasted like 10 minutes, maybe it's good to put only previews of 30 s in the feed. I think the bugs will be resolved soon and have already been reported is normal that when you launch an integration but then you don't have feedback you don't know if it's actually working. Unanimity proceeds, I will have to sponsor it, 💡 Join on Unanimity 👾 When it rains, I think of the floods that have hit recently. Cody started making the client that Fiatjaf wanted, what I mentioned last week. What cringe story *Google+* [post on *Mastodon*](https://mastodon.uno/@Mer__edith@mastodon.world/113404149952314316) *Google+* is like believing in BAT tokens. I remember the days of *Google+* I had a blog about blogger who automatically posted. The circles were an interesting concept, I remember that there were influencer lists. Google podcast more recently 😔😔 4. *Nostr build* has a multimedia player (Audio,Video) 🤙, i think it's mostly for mobile phones [song link](https://e.nostr.build/a_ygcIk1sDOASbSyU0_m4a) [link player](https://e.nostr.build/) Vote only if you know that one of the two parts is against you, or it has as an "enemy" target a category of which you are part. 5. The fantastic **zap cooking newsletter** has arrived, [you can read it](https://yakihonne.com/article/naddr1qvzqqqr4gupzqvv660neqc6dh6r0zndec2v4kfhw833z30j4lzwycll2ntxqr4g2qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqp5cnwvesxserqdfhxqenjvc2xupfa)

@ 06639a38:655f8f71

One year ago I wrote the article [Why Nostr resonates](https://sebastix.nl/blog/why-nostr-resonates/) in Dutch and English after I visited the Bitcoin Amsterdam 2023 conference and the Nostrdam event. It got published at [bitcoinfocus.nl](https://bitcoinfocus.nl/2023/11/02/278-waarom-nostr-resoneert/) (translated in Dutch). The main reason why I wrote that piece is that I felt that my gut feeling was tellinng me that Nostr is going to change many things on the web. After the article was published, one of the first things I did was setting up this page on my website: [https://sebastix.nl/nostr-research-and-development](https://sebastix.nl/nostr-research-and-development). The page contains this section (which I updated on 31-10-2024):  One metric I would like to highlight is the number of repositories on Github. Compared to a year ago, there are already more than 1130 repositories now on Github tagged with Nostr. Let's compare this number to other social media protocols and decentralized platforms (24-10-2024): * Fediverse: 522 * ATProto: 159 * Scuttlebot: 49 * Farcaster: 202 * Mastodon: 1407 * ActivityPub: 444 Nostr is growing. FYI there are many Nostr repositories not hosted on Github, so the total number of Nostr reposities is higher. I know that many devs are using their own Git servers to host it. We're even capable of setting up Nostr native Git repositories (for example, see [https://gitworkshop.dev/repos](https://gitworkshop.dev/repos)). Eventually, Nostr will make Github (and other platforms) absolute. Let me continue summarizing my personal Nostr highlights of last year. ## Organising Nostr meetups  This is me playing around with the NostrDebug tool showing how you can query data from Nostr relays. Jurjen is standing behind me. He is one of the people I've met this year who I'm sure I will have a long-term friendship with. ## OpenSats grant for Nostr-PHP   In December 2023 I submitted my application for a OpenSats grant for the further development of the Nostr-PHP helper library. After some months I finally got the message that my application was approved... When I got the message I was really stoked and excited. It's a great form of appreciation for the work I had done so far and with this grant I get the opportunity to take the work to another higher level. So please check out the work done for so far: * [https://nostr-php.dev](https://nostr-php.dev) * [https://github.com/nostrver-se/nostr-php](https://github.com/nostrver-se/nostr-php) ## Meeting Dries  One of my goosebumps moments I had in 2022 when I saw that the founder and tech lead of Drupal Dries Buytaert posted '[Nostr, love at first sight](https://dri.es/nostr-love-at-first-sight)' on his blog. These types of moments are very rare moment where two different worlds merge where I wouldn't expect it. Later on I noticed that Dries would come to the yearly Dutch Drupal event. For me this was a perfect opportunity to meet him in person and have some Nostr talks. I admire the work he is doing for Drupal and the community. I hope we can bridge Nostr stuff in some way to Drupal. In general this applies for any FOSS project out there. [Here](https://sebastix.nl/blog/photodump-and-highlights-drupaljam-2024/) is my recap of that Drupal event. ## Attending Nostriga  A conference where history is made and written. I felt it immediately at the first sessions I attended. I will never forget the days I had at Nostriga. I don't have the words to describe what it brought to me.  I also pushed myself out of my comfort zone by giving a keynote called 'POSSE with Nostr - how we pivot away from API's with one of Nostr superpowers'. I'm not sure if this is something I would do again, but I've learned a lot from it. You can find the presentation [here](https://nostriga.nostrver.se/). It is recorded, but I'm not sure if and when it gets published. ## Nostr billboard advertisement  This advertisment was shown on a billboard beside the [A58 highway in The Netherlands](https://www.google.nl/maps/@51.5544315,4.5607291,3a,75y,34.72h,93.02t/data=!3m6!1e1!3m4!1sdQv9nm3J9SdUQCD0caFR-g!2e0!7i16384!8i8192?coh=205409&entry=ttu) from September 2nd till September 16th 2024. You can find all the assets and more footage of the billboard ad here: [https://gitlab.com/sebastix-group/nostr/nostr-ads](https://gitlab.com/sebastix-group/nostr/nostr-ads). My goal was to set an example of how we could promote Nostr in more traditional ways and inspire others to do the same. In Brazil a fundraiser was achieved to do something similar there: [https://geyser.fund/project/nostrifybrazil](https://geyser.fund/project/nostrifybrazil). ## Volunteering at Nostr booths growNostr  This was such a great motivating experience. Attending as a volunteer at the Nostr booth during the Bitcoin Amsterdam 2024 conference. Please read my note with all the lessons I learned [here](https://nostrver.se/note/my-learned-nostr-lessons-nostr-booth-bitcoin-amsterdam-2024). ## The other stuff * The Nostr related blog articles I wrote past year: * [**Run a Nostr relay with your own policies**](https://sebastix.nl/blog/run-a-nostr-relay-with-your-own-policies/) (02-04-2024) * [**Why social networks should be based on commons**](https://sebastix.nl/blog/why-social-networks-should-be-based-on-commons/) (03-01-2024) * [**How could Drupal adopt Nostr?**](https://sebastix.nl/blog/how-could-drupal-adopt-nostr/) (30-12-2023) * [**Nostr integration for CCHS.social**](https://sebastix.nl/blog/nostr-integration-for-cchs-social-drupal-cms/) (21-12-2023) * [https://ccns.nostrver.se](https://ccns.nostrver.se)  CCNS stands for Community Curated Nostr Stuff. At the end of 2023 I started to build this project. I forked an existing Drupal project of mine (https://cchs.social) to create a link aggregation website inspired by stacker.news. At the beginning of 2024 I also joined the TopBuilder 2024 contest which was a productive period getting to know new people in the Bitcoin and Nostr space. * [https://nuxstr.nostrver.se](https://nuxstr.nostrver.se)  PHP is not my only language I use to build stuff. As a fullstack webdeveloper I also work with Javascript. Many Nostr clients are made with Javascript frameworks or other more client-side focused tools. Vuejs is currently my Javascript framework I'm the most convenient with. With Vuejs I started to tinker around with Nuxt combined with NDK and so I created a starter template for Vue / Nuxt developers. * [ZapLamp](nostr:npub1nfrsmpqln23ls7y3e4m29c22x3qaq9wmmr7zkfcttty2nk2kd6zs9re52s) This is a neat DIY package from LNbits. Powered by an Arduino ESP32 dev board it was running a 24/7 livestream on zap.stream at my office. It flashes when you send a zap to the npub of the ZapLamp. * [https://nosto.re](https://nosto.re)  Since the beginning when the Blossom spec was published by @hzrd49 and @StuartBowman I immediately took the opportunity to tinker with it. I'm also running a relay for transmitting Blossom Nostr events `wss://relay.nosto.re`. * [Relays I maintain](https://nostrver.se/note/relays-i-maintain) I really enjoy to tinker with different relays implementations. Relays are the fundamental base layer to let Nostr work. I'm still sharing my contributions on [https://nostrver.se/](https://nostrver.se/) where I publish my weekly Nostr related stuff I worked on. This website is built with Drupal where I use the Nostr Simple Publish and Nostr long-form content NIP-23 modules to crosspost the notes and long-form content to the Nostr network (like this piece of content you're reading).  ## The Nostr is the people Just like the web, the web is people: [https://www.youtube.com/watch?v=WCgvkslCzTo](https://www.youtube.com/watch?v=WCgvkslCzTo)  > the people on nostr are some of the smartest and coolest i’ve ever got to know. who cares if it doesn’t take over the world. It’s done more than i could ever ask for. - [@jb55](nostr:note1fsfqja9kkvzuhe5yckff3gkkeqe7upxqljg2g4nkjzp5u9y7t25qx43uch) Here are some Nostriches who I'm happy to have met and who influenced my journey in Nostr in a positive way. * Jurjen * Bitpopart * Arjen * Jeroen * Alex Gleason * Arnold Lubach * Nathan Day * Constant * fiatjaf * Sync ## Coming year Generally I will continue doing what I've done last year. Besides the time I spent on Nostr stuff, I'm also very busy with Drupal related work for my customers. I hope I can get the opportunity to work on a paid client project related to Nostr. It will be even better when I can combine my Drupal expertise with Nostr for projects paid by customers. ### Building a new Nostr application When I look at my Nostr backlog where I just put everything in with ideas and notes, there are quite some interesting concepts there for building new Nostr applications. Filtering out, I think these three are the most exciting ones: * nEcho, a micro app for optimizing your reach via Nostr (NIP-65) * Nostrides.cc platform where you can share Nostr activity events (NIP-113) * A child-friendly video web app with parent-curated content (NIP-71) ### Nostr & Drupal When working out a new idea for a Nostr client, I'm trying to combine my expertises into one solution. That's why I also build and maintain some Nostr contrib modules for Drupal. * [Nostr Simple Publish](https://www.drupal.org/project/nostr_simple_publish) Drupal module to cross-post notes from Drupal to Nostr * [Nostr long-form content NIP-23](https://www.drupal.org/project/nostr_content_nip23) Drupal module to cross-post Markdown formatted content from Drupal to Nostr * [Nostr internet identifier NIP-05](https://www.drupal.org/project/nostr_id_nip05) Drupal module to setup Nostr internet identifier addresses with Drupal. * [Nostr NDK](https://drupal.org/project/nostr_dev_kit) Includes the Javascript library Nostr Dev Kit (NDK) in a Drupal project. One of my (very) ambitious goals is to build a Drupal powered Nostr (website) package with the following main features: * Able to login into Drupal with your Nostr keypair * Cross-post content to the Nostr network * Fetch your Nostr content from the Nostr content * Serve as a content management system (CMS) for your Nostr events * Serve as a framework to build a hybrid Nostr web application * Run and maintain a Nostr relay with custom policies * Usable as a feature rich progressive web app * Use it as a remote signer These are just some random ideas as my Nostr + Drupal backlog is way longer than this. ### Nostr-PHP With all the newly added and continues being updated NIPs in the protocol, this helper library will never be finished. As the sole maintainer of this library I would like to invite others to join as a maintainer or just be a contributor to the library. PHP is big on the web, but there are not many PHP developers active yet using Nostr. Also PHP as a programming language is really pushing forward keeping up with the latest innovations.  ### Grow Nostr outside the Bitcoin community We are working out a submission to host a Nostr stand at FOSDEM 2025. If approved, it will be the first time (as far as I know) that Nostr could be present at a conference outside the context of Bitcoin. The audience at FOSDEM is mostly technical oriented, so I'm really curious what type of feedback we will receive. Let's finish this article with some random Nostr photos from last year. Cheers!       

@ 3f770d65:7a745b24

**Amber** [Amber](https://github.com/greenart7c3/Amber) is a Nostr event signer for Android that allows users to securely segregate their private key (nsec) within a single, dedicated application. Designed to function as a NIP-46 signing device, Amber ensures your smartphone can sign events without needing external servers or additional hardware, keeping your private key exposure to an absolute minimum. This approach aligns with the security rationale of NIP-46, which states that each additional system handling private keys increases potential vulnerability. With Amber, no longer do users need to enter their private key into various Nostr applications. <img src="https://cdn.satellite.earth/b42b649a16b8f51b48f482e304135ad325ec89386b5614433334431985d4d60d.jpg"> Amber is supported by a growing list of apps, including [Amethyst](https://www.amethyst.social/), [0xChat](https://0xchat.com/#/), [Voyage](https://github.com/dluvian/voyage), [Fountain](https://fountain.fm/), and [Pokey](https://github.com/KoalaSat/pokey), as well as any web application that supports NIP-46 NSEC bunkers, such as [Nostr Nests](https://nostrnests.com), [Coracle](https://coracle.social), [Nostrudel](https://nostrudel.ninja), and more. With expanding support, Amber provides an easy solution for secure Nostr key management across numerous platforms. <img src="https://cdn.satellite.earth/5b5d4fb9925fabb0005eafa291c47c33778840438438679dfad5662a00644c90.jpg"> Amber supports both native and web-based Nostr applications, aiming to eliminate the need for browser extensions or web servers. Key features include offline signing, multiple account support, and NIP-46 compatibility, and includes a simple UI for granular permissions management. Amber is designed to support signing events in the background, enhancing flexibility when you select the "remember my choice" option, eliminating the need to constantly be signing events for applications that you trust. You can download the app from it's [GitHub](https://github.com/greenart7c3/Amber) page, via [Obtainium ](https://github.com/ImranR98/Obtainium)or Zap.store. To log in with Amber, simply tap the "Login with Amber" button or icon in a supported application, or you can paste the NSEC bunker connection string directly into the login box. For example, use a connection string like this: bunker://npub1tj2dmc4udvgafxxxxxxxrtgne8j8l6rgrnaykzc8sys9mzfcz@relay.nsecbunker.com. <img src="https://cdn.satellite.earth/ca2156bfa084ee16dceea0739e671dd65c5f8d92d0688e6e59cc97faac199c3b.jpg"> --- **Citrine** [Citrine](https://github.com/greenart7c3/Citrine) is a Nostr relay built specifically for Android, allowing Nostr clients on Android devices to seamlessly send and receive events through a relay running directly on their smartphone. This mobile relay setup offers Nostr users enhanced flexibility, enabling them to manage, share, and back up all their Nostr data locally on their device. Citrine’s design supports independence and data security by keeping data accessible and under user control. <img src="https://cdn.satellite.earth/46bbc10ca2efb3ca430fcb07ec3fe6629efd7e065ac9740d6079e62296e39273.jpg"> With features tailored to give users greater command over their data, Citrine allows easy export and import of the database, restoration of contact lists in case of client malfunctions, and detailed relay management options like port configuration, custom icons, user management, and on-demand relay start/stop. Users can even activate TOR access, letting others connect securely to their Nostr relay directly on their phone. Future updates will include automatic broadcasting when the device reconnects to the internet, along with content resolver support to expand its functionality. Once you have your Citrine relay fully configured, simply add it to the Private and Local relay sections in Amethyst's relay configuration. <img src="https://cdn.satellite.earth/6ea01b68009b291770d5b11314ccb3d7ba05fe25cb783e6e1ea977bb21d55c09.jpg"> --- **Pokey** [Pokey](https://github.com/KoalaSat/pokey) for Android is a brand new, real-time notification tool for Nostr. Pokey allows users to receive live updates for their Nostr events and enabling other apps to access and interact with them. Designed for seamless integration within a user's Nostr relays, Pokey lets users stay informed of activity as it happens, with speed and the flexibility to manage which events trigger notifications on their mobile device. <img src="https://cdn.satellite.earth/62ec76cc36254176e63f97f646a33e2c7abd32e14226351fa0dd8684177b50a2.jpg"> Pokey currently supports connections with Amber, offering granular notification settings so users can tailor alerts to their preferences. Planned features include broadcasting events to other apps, authenticating to relays, built-in Tor support, multi-account handling, and InBox relay management. These upcoming additions aim to make Pokey a fantastic tool for Nostr notifications across the ecosystem. --- **Zap.store** [Zap.store](https://github.com/zapstore/zapstore/) is a permissionless app store powered by Nostr and your trusted social graph. Built to offer a decentralized approach to app recommendations, zap.store enables you to check if friends like Alice follow, endorse, or verify an app’s SHA256 hash. This trust-based, social proof model brings app discovery closer to real-world recommendations from friends and family, bypassing centralized app curation. Unlike conventional app stores and other third party app store solutions like Obtainium, zap.store empowers users to see which apps their contacts actively interact with, providing a higher level of confidence and transparency. <img src="https://cdn.satellite.earth/fd162229a404b317306916ae9f320a7280682431e933795f708d480e15affa23.jpg"> Currently available on Android, zap.store aims to expand to desktop, PWAs, and other platforms soon. You can get started by installing [Zap.store](https://github.com/zapstore/zapstore/) on your favorite Android device, and install all of the applications mentioned above. --- Android's openness goes hand in hand with Nostr's openness. Enjoy exploring both expanding ecosystems.

@ 1739d937:3e3136ef

This update marks a major milestone for the project. I know, with certainty, that MLS messaging over Nostr is going to work. That might sound a little crazy after so many months working on the project, and I was pretty confident, but until you’ve got running code, it’s all conjecture. Late last week, I released a video of a working prototype of [White Noise](https://github.com/erskingardner/whitenoise) that shows the full flow; creating groups, inviting other users to join those groups, accepting invites, and sending messages back-and-forth. I’m thrilled that I’ve gotten this far but also appalled that it’s taken so long and disgusted at the state of the code in the app (I’ve been told I have unrelenting standards 😅). If you missed the video last week... nostr:note125cuk0zetc7sshw52v5zaq9apq3rq7e2x587tr2c96t7z7sjs59svwv0fj ## What's Next? In this update, I want to cover a few things about how I'm planning to proceed and how I’m splitting code out of the app into libraries that will help other developers implement MLS messaging in their own Nostr clients. First off, many of you know that I've been building White Noise as a Rust app using the [Tauri](https://tauri.app) framework. The [OpenMLS](https://github.com/openmls/openmls) implementation is also written in Rust (with bindings for many other languages). So, when you hear me talking about library code, think Rust crates for now. The first library, called [openmls-nostr](https://github.com/erskingardner/openmls-nostr), is an extension/abstraction on top of the openmls implementation of the MLS spec that helps Nostr clients interact more easily with that implementation in a way that feels native to Nostr. Mostly this will be helping developers interact with MLS primitives and ensure that they’re creating, validating, and serializing these objects in the right way at the right times. The second isn’t a new library as a big contribution to the already excellent [rust-nostr](https://github.com/rust-nostr) library from nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet. The methods that will go in rust-nostr are highly abstracted and based specifically on the requirements of NIP-104. Mostly this will be helping developers to take those MLS primitives and publish or query them as Nostr events at the right times and to/from the right relays. Most of this code was originally written directly in the White Noise library so this week I've started to pull code for both of those libraries out and move it to its new home. While I’ve been at it, I've been writing some tests and trying to document things. An unfortunate offshoot of this is that the usable builds of White Noise are going to take a touch longer. I promise it’s still a very high priority but at this point I need to clean a few things up based on what I've learned thus far. Another thing that is slowing down release is that; behind the scenes of the dev work, I’ve been battling with Apple for nearly 2 months now to get a proper developer team set up so that we can publish the app via TestFlight for MacOS and iOS. I’ve also been recently learning the intricacies of Android publishing (oh my dear god there are so many devices, OS versions, etc.). With that in mind, if you know anyone who can help get me up to speed on CI/CD, release pipelines, and multi-platform distribution please hit me up. I would love to learn more and hopefully shortcut some of the pain. Thanks again so much for all the support over the last few months! It means a lot to me and is a huge part of what is keeping me going on this. 🙏

@ b8a9df82:6ab5cbbd

**Packing my bags and taking…?** Absolutely no idea, but definitely not a winter jacket. That’s not happening—I’ve been telling myself for years that I don’t want to spend another winter in Berlin. The last few have been brutal. I’m craving a real adventure. Currently on plane number three, with plenty of time to think, read, and write because, honestly, one of the things I love most about flying is not being connected. I’m the person who won’t spend over $10 on an hour of Wi-Fi, and right now, I love that my phone is off. No messages, no notifications. It’s kind of crazy these days—every morning, I wake up to 100 messages. I’m always telling people how toxic phones can be, yet even I can barely stay away from mine lately. Right now, squeezed into the middle seat on a 10-hour flight from Toronto to Buenos Aires, I’m starting to question what I’ve gotten myself into. **Yes, Toronto.** There are people who can afford a direct flight, and then… there’s me. Berlin to Frankfurt, Toronto to São Paulo (just a quick tech stop), and finally, Buenos Aires. Nearly 30 hours of travel. It’s fine, but yeah, I’m kind of jealous watching the business class people, lounging literally just in front of me. My legs are burning; sleep is impossible. I don’t even know what day it is anymore. Flying’s changed so much. It’s ridiculously expensive and uncomfortable now. It’s like today’s business class is what economy used to be ten years ago. Now, we pay extra for everything. I miss when flying felt like a bit of an adventure itself, back when they’d let kids visit the cockpit (I have been there) —impossible now, sadly. So here I am, taking a moment to share some personal insights from last week, preparing for this LATAM-Nostr Tour: The last few weeks have been intense, to say the least. My last official workday was at the end of September, and of course, I got super sick right after. My body was practically screaming for a timeout that my mind didn’t want to give. I kept thinking, “Just four more weeks—Amsterdam, sorting my life out in Berlin, subletting my flat.” Well, clearly, that didn’t quite go as planned. So hey, if anyone needs a cute little flat for a few months, let me know! Excited, overwhelmed, and freaking out all at once. I just hope everything works out: that I haven’t forgotten anything, that the booths will be ready, the schedule will come together, people show up, speakers are prepared, volunteers are there, tickets are sorted. There’s still so much to do, and the conference pace is making it tough. For example, SatsConf still hasn’t sent the final design specs, and I just got the measurements for the graphics. Trying to sort that out while traveling is sending me into a bit of a tailspin. It’s like my inner **German is in crisis mode**, haha. I know what I’m doing, and I know what I’m capable of—but this is a whole new world. I really want to meet everyone’s expectations here. I miss my usual team so much because I know how they work, what to expect, and I can trust that everything will be handled. Here, I just have to let go, trust, and see what happens. And then you meet people. You realize they’re kind, helpful, and excited, and together, it feels like we can actually make something happen. Last week, I went to the Nostr Berlin meet-up, chatting with some guys who also happened to be flying to BA. I suggested they help at our booth, and in return, we could sort out tickets. They were thrilled—it’s the kind of support that makes all of this feel worth it. Even though I don’t know exactly what’s in store or what to expect, I’m truly looking forward to it. The team is incredible, and I know I’ll be looked after. As the only woman in the core team, it’s been an experience. I love working with men, but there are times I wish I had another woman alongside me, someone with a similar mindset and, yes, someone to do the “girly stuff” with. But here I am, embracing the unknown, ready for this journey, and just hoping that somewhere between Buenos Aires and Berlin, this leap will pay off in ways I can’t even imagine. **South America, let’s see what you’ve got!**!!

@ 06639a38:655f8f71

* NIP-42 integration in Nostr-PHP: [https://github.com/nostrver-se/nostr-php/pull/67](https://github.com/nostrver-se/nostr-php/pull/67) * Worked out a submission for a Nostr stand at FOSDEM 2025 [https://nostrudel.ninja/#/n/nevent1qvzqqqqqqypzqpnrnguxe8qszsshvgkvhn6qjzxy7xsvx03rlrtddr62haj4lrm3qythwumn8ghj7un9d3shjt3s0p3ksct59e3k7mf0qy88wumn8ghj77tpvf6jumt99uqzqrswsdmxjtx9er5mdmt388e7payg85yzvnhf6wspvjdxu7q8gmzsraa37w](https://nostrudel.ninja/#/n/nevent1qvzqqqqqqypzqpnrnguxe8qszsshvgkvhn6qjzxy7xsvx03rlrtddr62haj4lrm3qythwumn8ghj7un9d3shjt3s0p3ksct59e3k7mf0qy88wumn8ghj77tpvf6jumt99uqzqrswsdmxjtx9er5mdmt388e7payg85yzvnhf6wspvjdxu7q8gmzsraa37w) * NIP-19 integration in Nostr-PHP work in progress: [https://github.com/nostrver-se/nostr-php/pull/68](https://github.com/nostrver-se/nostr-php/pull/68) * Also tinkering around with this relay implemenation written in PHP: [https://github.com/nostriphant/transpher](https://github.com/nostriphant/transpher)

@ 3bf0c63f:aefa459d

# `kind:1` maximalism and the future of other stuff and Nostr decentralization These two problems exist on Nostr today, and they look unrelated at first: 1. People adding more stuff to `kind:1` notes, such as making them editable, or adding special corky syntax thas has to be parsed and rendered in complicated UIs; 2. The _discovery_ of "other stuff" content (i.e. long-form articles, podcasts, calendar events, livestreams etc) is hard due to the fact that most people only use microblogging clients and they often don't appear there for them. Point **2** above has 3 different solutions: - **a.** Just publish everything as `kind:1` notes; - **b.** Publish different things as different kinds, but make microblogging clients fetch all the event kinds from people you follow, then render them natively or use NIP-31, or NIP-89 to point users to other clients that would render them better; - **c.** Publish different things as different kinds, and reference them in `kind:1` notes that would act as announcements to these other events, also relying on NIP-31 and NIP-89 for displaying references and recommending other clients. Solution **a** is obviously very bad, so I won't address it. For a while I have believed solution **b** was the correct one, and many others seem to tacitly agree with it, given that some clients have been fetching more and more event kinds and going out of their way to render them in the same feed where only `kind:1` notes were originally expected to be. I don't think clients doing that is necessarily bad, but I do think this have some centralizing effects on the protocol, as it pushes clients to become bigger and bigger, raising the barrier to entry into the `kind:1` realm. And also in the past I have talked about the fact that I disliked that some clients would display my long-form articles as if they were normal `kind:1` notes and just dump them into the feeds of whoever was following me: nostr:nevent1qqsdk90k9k30vtzwpj6grxys9mvsegu5kkwd4jmpyhlmtjnxet2rvggprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqy8hwumn8ghj7mn0wd68ytnddaksygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5hae35c These and other reasons have made me switch my preference to solution **c**, as it gives the most flexibility to the publisher: whoever wants to announce stuff so it can be _discovered_ can, whoever doesn't don't have to. And it allows microblogging clients the freedom to render just render tweets and having a straightforward barrier between what they can render and what is just a link to an external app or webapp (of course they can always opt to render the referenced content in-app if they want). It also makes the case for microapps more evident. If all microblogging clients become superapps that can render recipe events perfectly why would anyone want to use a dedicated recipes app? I guess there are still reasons, but blurring the line between content kinds in superapps would definitely remove some of the reasons and eventually kill all the microapps. --- That brings us back to point **1** above (the overcomplication of `kind:1` events): if solution **c** is what we're going to, that makes `kind:1` events very special in Nostr, and not just another kind among others. Microblogging clients become the central plaza of Nostr, thus protecting their neutrality and decentralization much more important. Having a lot of clients with different userbases, doing things in slightly different ways, is essential for that decentralization. It's ok if Nostr ends up having just 2 recipe-sharing clients, but it must have dozens of microblogging clients -- and maybe not even full-blown microblogging clients, but other apps that somehow deal with `kind:1` events in multiple ways. It's ok if implementing a client for public audio-rooms is very hard and complicated, but at the same time it should be very simple to write a client that can render a `kind:1` note referencing an audio-room and linking to that dedicated client. I hope you got my point and agreed because this article is ended.

@ 06639a38:655f8f71

### Project Name Nostr ### Project Description Nostr (Notes and Other Stuff Transmitted by Relays) is an open, censorship-resistant, and decentralized communication protocol designed for simplicity and resilience. Unlike traditional platforms, Nostr doesn’t rely on centralized servers. It already supports various use cases with free, open-source clients—offering alternatives to platforms like Twitter/X, Meetup.com, Excel 365, healthcare system and more. We will help you get started with Nostr. Nostr has seen remarkable adoption and growth within the open-source community, evidenced by over 12,500 GitHub stars, 500+ forks, and contributions from more than 350 developers. The protocol has catalyzed the creation of an impressive ecosystem of over 390 projects, including mobile and web clients, relays, tools, and services that further enhance Nostr’s functionality. With over 70 tools and 48 libraries, developers can integrate Nostr into a wide array of applications—ranging from chat platforms to file storage and even decentralized marketplaces. These resources help to build decentralized, censorship-resistant systems without the need for centralized servers. Whether you’re working on peer-to-peer markets, privacy-focused messaging apps, or decentralized social media, Nostr’s ecosystem offers the tools. ### Project website [https://github.com/nostr-protocol](https://github.com/nostr-protocol)  ### Source code [https://github.com/nostr-protocol/nips](https://github.com/nostr-protocol/nips)  ### Project Theme World Wide Web ### Do you want a stand for the entire event or just for one day? Entire event ### Why do you want to be at FOSDEM? We want to be at FOSDEM because it’s the perfect place to connect with like-minded developers and open-source enthusiasts who share our passion for decentralization, innovation, and building open permissionless technologies. FOSDEM fosters collaboration and the growth of community-driven projects and Nostr is a natural fit as a real grassroots project with its open protocol and commitment to build communication technology with resilience and simplicity in mind. By being at FOSDEM, we aim to raise awareness, share knowledge and inspire others to explore the potential of decentralized communication systems. We also want to engage with the FOSS community and gain feedback to help Nostr grow. If people are really interested in how they can use Nostr we will show the possibilities, demo existing clients and provide in-depth explanations of how the protocol can replace the social layer (with user accounts in living a database) in existing software. ### What is the relation between the project and the primary contact? Jurjen works with the community to promote its development, onboard new developers, and contribute to its open-source ecosystem. My role includes helping to raise awareness of Nostr's potential, organizing events, and supporting adoption by providing educational resources and technical guidance. ### What is the relation between the project and the secondary contact? Sebastian (37) is an independent creative / fullstack web developer who is the maintainer of a PHP helper library supported by OpenSats. Besides this project he is also making contributions with developing Nostr modules for Drupal. _“Since I've been online on the internet (1998), I'm highly interested in online communities, social networking and new ways of digital interactions. The internet has changed radically in the last decade and that change is not serving our interests. It's fair to say the web is broken in many ways. With Nostr we can fix this.”_ ### Social media links `npub1l77twp5l02jadkcjn6eeulv2j7y5vmf9tf3hhtq7h7rp0vzhgpzqz0swft` (Jurjen) `npub1qe3e5wrvnsgpggtkytxteaqfprz0rgxr8c3l34kk3a9t7e2l3acslezefe` (Sebastian) `npub1hz5alqscpp8yjrvgsdp2n4ygkl8slvstrgvmjca7e45w6644ew7sewtysa` (Tanja) `npub1nkmta4dmsa7pj25762qxa6yqxvrhzn7ug0gz5frp9g7p3jdscnhsu049fn` (Kevin) ### Anything else you like to add? We’d also like to highlight that Nostr was created by Fiatjaf, an anonymous founder, which aligns with its principles of openness and decentralization. As an open protocol, Nostr is designed to evolve and find its own way, just like the foundational protocols of the internet. Importantly, Nostr is not a blockchain project—there are no tokens, no costs, and no barriers. It’s also not a platform nor a NFT. It’s purely decentralized, built for resilience and simplicity. While payment solutions like Bitcoin can be integrated, they are optional, not intrinsic to the protocol. This makes Nostr accessible and flexible, truly embodying the spirit of the open internet. Nostr is more than just a technological protocol; it’s about the energy, problem-solving, and sense of hope that draws people in. Even newcomers can play a significant role in the ecosystem, gaining insight from the outside while discovering the protocol’s potential. Tanja, for example, isn’t from a tech background, yet after just three months, she’s taken on a major organizational role. She’s been spreading the message of freedom of speech and is leading the Nostr Booth LATAM tour, where volunteers, entrepreneurs, and Nostr-based businesses come together, supported by the entire community, to raise awareness about Nostr. Her passion for decentralization and open collaboration also drives her efforts to bring Nostr to FOSDEM, where she will help connect the project with like-minded developers and open-source advocates. Please reach out to us if there are any questions. We’re really looking forward to presenting Nostr as a protocol at one of the best places where free and open-source software is flourishing. This content will be used for a FOSDEM stand submission via [https://pretalx.fosdem.org/fosdem-2025-call-for-stands/](https://pretalx.fosdem.org/fosdem-2025-call-for-stands/)

@ 06639a38:655f8f71

* Worked on the [https://nostr-php.dev](https://nostr-php.dev) docs * [Introduction](https://nostr-php.dev/introduction) * [Request events](https://nostr-php.dev/guides/request-events) * [Publish event](https://nostr-php.dev/guides/publish-event) * Discussed a FOSDEM stand application with Jurjen and Tanja to attend that conference with Nostr * Release version `1.4.2` of Nostr-PHP * [https://github.com/nostrver-se/nostr-php/releases/tag/1.4.2](https://github.com/nostrver-se/nostr-php/releases/tag/1.4.2) * Pre-release `2.0.0-alpha1` * [https://github.com/nostrver-se/nostr-php/releases/tag/2.0.0-alpha1](https://github.com/nostrver-se/nostr-php/releases/tag/2.0.0-alpha1)

@ 06639a38:655f8f71

### Week 40 * Added a page with my research findings around async concurrent websocket requests: [https://nostr-php.dev/references/async-concurrent-requests](https://nostr-php.dev/references/async-concurrent-requests) ### Week 41 I attended the Nostrdam meetup and helped as a volunteer at the Nostr booth at the Bitcoin Amsterdam 2024 conference. Here are some photo's:   I also wrote down my personal learned lessons from this expierence: [https://nostrver.se/note/my-learned-nostr-lessons-nostr-booth-bitcoin-amsterdam-2024](https://nostrver.se/note/my-learned-nostr-lessons-nostr-booth-bitcoin-amsterdam-2024)

@ 4fda8b10:7bbee962

# Takeaways from Bitcoin Amsterdam 2024 The [bitcoin](https://notes.peterpeerdeman.nl/bitcoin) conference in Amsterdam to me is my typical yearly check in with the [crypto](https://notes.peterpeerdeman.nl/crypto) scene. From a distance, not much has changed since last year. What struck me most was the correlation between the exchange prices and the amount of visitors, I had the feeling the crowd was about twice as big as last year during the opening and high profile talks. From my personal experience, the increase of audience also brought some dilution to the hard core maximalist anarchist-ness of the event. The overall vibe amongst the attendees was more friendly and open. This also increased the value of the event for me, as I try to broaden my network, get different perspectives and learn more about what interests people in the crypto space. This year was also marked by my involvement in the [Nostr](https://notes.peterpeerdeman.nl/Nostr) side events, I was asked to give a live performance at the [Nostrdam Meetup October 2024](https://notes.peterpeerdeman.nl/Nostrdam-Meetup-October-2024) which went over very well and also acted as a nice conversation starter during the rest of the conference. I was also slightly involved in the organisation of the [Nostr](https://notes.peterpeerdeman.nl/Nostr) booth, but credits go to the awesome volunteers that made that happen. It was a bit of a shame that the [Nostr](https://notes.peterpeerdeman.nl/Nostr) booth was tucked away all the way in the back of the (commercial) expo hall, it would have been nice to promote the [Nostr](https://notes.peterpeerdeman.nl/Nostr) initiative to the social community area next to the satoshi radio / connect the world community area For me the biggest takeaways were the insights I got from the people I’ve met, all from different industries with different perspectives on both [technology](https://notes.peterpeerdeman.nl/technology) and involvement. I tried to specifically reach out to (former) CTO’s, which led me to write and share [this piece on that particular role](https://notes.peterpeerdeman.nl/The-CTO-role,-its-overlap-with-the-CIO-and-covering-technological-responsibilities-in-appropriate-ways). Of course shaking hands and catching up with people I only see once a year is great, and reminds me of the vibe and my experiences at the [Fronteers](https://notes.peterpeerdeman.nl/Fronteers) conference. From a technical point of view I was most inspired by the advancement of AI agent technology and the possibilities of programmable micropayments via de [lightning](https://notes.peterpeerdeman.nl/lightning) network. Michael Levin showed us that the http spec already has a 402 status of “payment required” and that basically all the required infrastructure is already in place to allow both humans and [ai](https://notes.peterpeerdeman.nl/Artificial-Intelligence) agents to use the lightning network to pay for access to compute or resources using this statuscode and an api gateway such as lightning labs [aperture](https://github.com/lightninglabs/aperture). ## talk: HODLing Is Hard: Fundamentals, Cycle & On-Chain Analysis by rational root - bitcoin is already competing in market cap with other currencies - amount of euro is exponentially increasing - from 8 to 16 trillion euros since 2009, but having a real hard cap in btc is fundamentally different - inflation - euro lose 20% in 5 years - bitcoin also loses purchasing power, but only 10% - in current system, we always need to take on maximal debt, instead of saving - two things can happen - we get into overvalued price levels - we get into recession - recession would only mean a shift in the start of the 4 year cycle ## panel: Endless Possibilities: Reusing Heat From Miners - people - 21energy Maximilian (obwexer) - Bert de groot (bitcoin Brabant) - Brad Tom (mara) - perspective: coming from energy to bitcoin is very different and much faster with implementation than the other way around - 95% of heat can be captured from miners, much higher in comparison to AI - being able to balance the grid because you can turn off the bitcoin miners - ”heatbuffers” → heat is still available when power source goes down - common objections: - [Crypto](https://notes.peterpeerdeman.nl/Crypto) is hard to understand - for large industrial clients, heaters, public image of bitcoin (often a door closer) - people don’t see that miners consume electricity and pay for it. - If mining is closed down in Europe, the energy prices will spike because the energy will not be payed for anymore ## panel: How to Guard Privacy Tools & Developers - Dorien Rookmaker & Sjors proviost - chat control - topic keeps returning, and is highly distracting for progress - Parliament wants Netherlands to speak against chat control - initially they want to just, scan messages now want to install malware before [encryption](https://notes.peterpeerdeman.nl/encryption) - it is distracting Sjors from working on bitcoin - samurai and tornado are different cases - tornado cash is harder because it is also a smart contract with custody over funds - samurai is easier: if you don’t have custody, are you responsible for the results of the code? - will decide wether whether non custodial systems are ok or not - micah interpretation is quite vague - the current Denmark case: - if you are rebuilding an interface for a smart contract, you are responsible for implementing all the legal guardrails that apply to securities governance? ## panel: NOSTR: Freedom of Algorithmic Choice - will casarin, mcshane, martti malmi (Sirius iris.to) - arc (alternative layer on top of bitcoin, like lightning but without channels) - aha moment: when seeing the unsiloed experience between [nostr](https://notes.peterpeerdeman.nl/nostr) apps - were trying to create a town square, so we need to deal with spam - social media platforms have stagnated a bit, [nostr](https://notes.peterpeerdeman.nl/nostr) is innovating far more quickly ## panel: Transactions As Bitcoin’s Key Growth Metric - Stephan nilov - classical developers don’t know about money and bitcoin development is harder - total addressable market is highest in btc, biggest number of possible users - bitcoin companies don’t benefit from tokens that are typically exchanged for vc money - users are not looking for payments, they are looking for digital property and other things that Ethereum network offers - Stephan Livera - there is a known, slow pace at which bitcoin will be adopted - btc market is only 1.2 trillion dollars compared to USD 30 trillion ## talk: Making Bitcoin Quantum Resistant by hunter beast - surmount.systems - explaining the threat of quantum computing - problems - key size: larger signature required - proposal: transaction field attestation - 256 bit number key, possibility to factor the private key out of this - introducing p2qrhash - segwitv3 - satoshishield - in layman terms: - quantum safe upgrades to bitcoin protocol are proposed - we need to introduce a software upgrade - requires a soft fork, opt in - possible advantages of quantum in crypto - allow us to sign signatures in a way that is unbreakable - 514 qubits are needed to break something ## talk: Lightning and AI: Where the Bots Pay You by michael levin - two use cases for [bitcoin](https://notes.peterpeerdeman.nl/bitcoin) adoption - people that don’t have access to fiat - things that can’t be handled by fiat systems - [large language models](https://notes.peterpeerdeman.nl/large-language-models) - current phase: big adoption - next phase: agentic ai - costs of ai - compute 400% more (ben bajarin) - algorithm training excess 10 billion dollars - data - costs implications - cost of serving answers is 0 - cost of serving ai query is not 0 - cost for everyone in the world - payments in AI - now - pay per call - data - accessibility - agents - agents must be able to do things that cost money - payment system for AI - globally accessible - near instant - final settlement - internet native - authentication mechanism - personalise access (simple queries for lower tier model) - easy to implement - L402 protocol - 402 payment required in http spec - reverse proxy to have 402 in front of APIs - aperture is lightning labs implementation - all available right now, adoption starting - fewsats, sulu, open agents / plebai - pay with lightning - challenges - do these payments with stablecoins instead of lightning (hence taproot assets protocol) - cases - agent bots can pay for real world resources - taproot assets issue assets on bitcoin allow transfer of - references - L402.org ## talk: Bitcoin is Cypherpunk by Aaron van Wirdum - is bitcoin still [Cypherpunks](https://notes.peterpeerdeman.nl/Cypherpunks) ? - on one hand we see a push to regulation and frameworks to govern btc - on the other hand we are arresting developers for writing code ## pitches: Bitcoin Amsterdam Pitch Day: Presented by GoBTC - umoja - ceo Robby greenfield - LST smartcoin, deflationary by design - competes with pools such as lido and rocket pool, but supports multiple coins, including liquid hashrate - 30% liquid hashrate returns (!) - compliance micah - disaster scenarios - black swan event → automatic exit out - magisat - trading tools for mempool snipers - support for runes - volume on bitcoin nft’s is on certain days higher than nft’s on ethereum ## panel: Crossing the Boundaries Between Bitcoin & Fiat - Christian Rau (Mastercard) & Remi destigny (bitrefill ) - liberation is great, but protocols don’t take customer service into account, chargebacks and rewinding mistakes etc - we aim to smooth process by issuing cards that sell your Bitcoin just in time on the backend ## talk: Gold & Bitcoin: Friends, Not Foes by Paul Buitink - premise “the financial system is crumbling” - there is too much debt - emerging markets lost confidence in western currencies - freezing Russian assets is shooting ourselves in the foot, as it shows the world you might not want to hold too many dollars that can be easily seized - record gold buying by central banks in 2022 2023 2024 - gold: 17 trillion marker cap, compared to bitcoin 1.3 trillion ## talk: Austrian Economics, Hard Money & Bitcoin Cycles, Willem Middelkoop - ”we are on the road towards hyper inflation and collapse of financial system” - central bankers are pretty smart and very aware - this is why they accumulate gold - when system collapses, central bankers will play the gold card, not the bitcoin card - US is preparing for big conflict with Russia and china - then you can’t use IMF monetary reset - Asia leadership is the same as US and Russian leadership: they want to stay on control - all have about similar gold (per Capita) in their central banks vaults to avoid hyperinflation - IMF said to el salvador: you need to reign down your bitcoin position - once central bankers start diversifying (e.g. to bitcoin ) they will strain their own system. The incentives are against adopting bitcoin - watch out for when on and offramp get blocked / repressed - think about diversifying to Dubai, “the new switzerland" - "bitcoin is the best money ever. fact” - superior to gold, because you can store your wealth independant of location - more scarce than gold - but from central bank point of view, gold is superior to bitcoin - younger generation gets this from the start ## talk: The Future Will Be Bitcoinized by Elizabeth stark & Rockstar Dev - stablecoins - taproot assets protocol - there is a demand for stablecoins and apps on stablecoins - 11 trillion dollars in stablecoins - protocol allows payments in other assets such as stablecoins that use bitcoin/lightning liquidity - Elizabeth believes this allows stablecoiners to get interested in the underlying bitcoin layer - Available now: - bridging tether and lightning ## products stumbled upon - [Meshtastic](https://notes.peterpeerdeman.nl/Meshtastic) - Flipper - Noderunners led matrix panel - 21energy bitcoin heater (1k s9, 3,5k s19) - angor.io by dangershony on nostr - bitcoinclock by Djuri canonical link: https://notes.peterpeerdeman.nl/Bitcoin-Amsterdam-2024 originally posted at https://stacker.news/items/724785

@ 460c25e6:ef85065c

NIPs (Nostr Implementation Possibilities) are specifications created by Nostr developers to describe how they are using certain event types and tags. They can be written before or after an implementation and generally go through several iterations before becoming stable enough to matter. Once 2 or more clients implement the complete version of the proposal, it is merged into the main repo. The process is structured to ensure that new ideas are welcomed but also thoroughly vetted. There are generally two paths for NIPs: 1. New Ideas, when developers just have a hunch on a new solution and want to quickly write something up to gather feedback from the community. These are my favorite NIPs because they generally introduce a new way of thinking about a problem we are all having. And because they are not just a general solution, but a specific proposal, it allows us to see the entire picture in just a few paragraphs. Even though they are my favorite, they are quite "green" and usually spur 2-3 separate solutions in following PRs by different authors. 2. Existing implementations that need to explain what they are doing. These happen when a client is already running code in production with a given feature and simply wants to explain to the rest of the community how to generate and interpret the events this client is creating. These NIPs start much more stable than the former and allow for less changes, but because there is already an implementation available, it is also like to be a market-tested solution that just needs a few adjustments to the other clients. Well-written specs ensure clarity, reduce ambiguity, and help developers implement the proposal consistently. The text should be VERY short, precise, prescriptive, and actionable by other devs. Start by introducing the new kind or tag in the first sentence and jump straight into a mockup of how the event looks like. The mockup should be self-explanatory and provide clues to what the remaining of the document will talk about. Some folks like to add long/verbose introductions, conclusions and discussions the reasons why the NIP is needed or why certain features are there. But those are largely unnecessary and are more appropriate to be placed in the body of the Pull Request descriptor. Start your NIP with the following template: ``` NIP-<pick a number> ====== <Title> ------------------ `draft` `optional` Event kind <new kind> defines <whatever it does>. Tags <one or two of the most important ones> <describe what they do>. As an example: ```jsonc { "kind": <your kind>, "tags": [ <your tags> ], "content": "", //... } `` ` Relays MUST... Clients MUST... ## <Details 1> ## <Details 2> ## <How to find them> ``` Your number for the NIP is irrelevant. Just pick a random number that is available so that you can fork the repo, create a file with that name, and start writing. This number will likely change once the NIP is merged. The NIPs title must be self-explanatory and short. If it helps, try to imagine which name would be best to add to the list of NIPs on the readme.md file. Same for event type names. Picture something that is short, unique and that devs can just remove the space to have a class name. The `draft` `optional` tags are there because unless you are working on NIP-01, everything is draft and everything is optional. If you want to write a mandatory NIP, you better make sure your text is so good that it can be added to `01.md` directly without overcomplicating the protocol. Start by describing the new event type, what it does and it's main tags. Show the mockup and then start introducing all the other tags and how clients and relays should behave when implementing it. Use the words MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT to define the mandatory behaviors of those declaring compliance with the NIP. Keep it simple. The specification should be designed to ensure that different clients, relays, and services can implement it without requiring substantial changes to their existing infrastructure. Ideally, devs should be able to implement the entire NIP from near scratch in just a few hours. Don't use jargon. Don't declare a vocabulary of words. Use simple words that anyone can understand and quickly code a demo of all the features in the NIP. They can learn about your reasons as they develop their implementation. Write expecting buggy implementations. The protocol must be resilient to varying implementations and network conditions, and gracefully handle coding errors or random gibberish. You want to promote a defensive design that anticipates misguided implementations, avoids breaking changes, and maximizes compatibility across the ecosystem. What happens if there are two tags with the same name? What happens if events that have missing tags are found? Buggy implementations will exist. The writing and reading clients are generally different and must be ready for anything that shows up on each side. Avoid abstractions, extensible and modular designs. Yes, they can be hidden underneath your text, but writing for them is a mistake and just overcomplicates things. Write for a specific use case and close all possible options to the items/features declared the text. Make sure you are implementing those. There is no point in declaring things that are not going to be used in the short term. We can always add more in the future and we don't need a recipe on how to add more later. Label your relay hosts, setting kinds, and other data management necessities. Every NIP has a way to find out the user's preferred relay associated with the use case. Sometimes it's through a relay hint others through a separate event kind that just lists the user's home relays or contains a list of "following" events designed for the use case. Each NIP can create their own way of finding events. You cannot add new root fields. Use tags instead. Root fields are special and require changes to the core protocol everyone implements. Any new field will take years to come to reality. Once you propose an idea, try not to change too much. It will take time for other devs to wrap their minds around it. If you keep changing it, even if those changes reflect the request of the reviewers in the PR, it just confuses everyone. Some times things change so much that it is worth doing two PRs with separate specifications that solve the same problem. That allows devs to analyze the two propositions side by side and decide which one is better. Always add a test case or an example. This is an absolute requirement if the NIP is complex, like a new encryption scheme. But even for simpler NIPs, test cases help devs to quickly verify if their implementations meet the minimum standard for compliance. They not only add peace of mind, but they also provide some welcoming dopamine when a new dev is trying to implement your NIP. Managing state is hard. Doing it with different implementations and hosting them in separate relays is even harder. If your NIP has multiple events to manage state, like group administration actions (add/remove member, change names/icons, invite/reporting events) try to structure them in a way that devs can quickly see the state machine of all possible state changes. Specify data formats explicitly. Clearly define the format of all data fields, including type (e.g., string, integer), encoding (e.g., base64, hex), and structure (e.g., array, object). Specify constraints like length limits, valid characters, and optional/required fields. Tags are case-sensitive. Avoid having to specify new encodings, but if you do, make sure to include test cases that encompass all potential cases. It's ok to not propose the most efficient way of solving the problem. A simple but slightly less efficient design is preferred over a complex but more efficient one. We already use hex and base64 codes to represent binary bytes in JSON, which wastes 25-50% of space. That level of waste is ok if the solution becomes simpler to code. It's not about you. You may think you must convince everyone that your particular way of solving the problem is the best and get some ego points with yourself. While some of that is beneficial to the debate, be open-minded to the other possible solutions. Once merged, the NIP is not yours anymore. Anyone can change in any way they see fit. If your work was great, people will remember your name. If it just got the conversation started to become something completely different from what you proposed, they will also remember you.

@ 06639a38:655f8f71

* Worked on the async requests with a pool for handling the request concurrent * This is a full working example where a request (to fetch Nostr events) is made to ~10 relays [https://gist.github.com/Sebastix/b4493018020d1d2b74e68016720ea70c](https://gist.github.com/Sebastix/b4493018020d1d2b74e68016720ea70c)  * Updated the following [nostr-php.dev](http://nostr-php.dev) guide pages: * Generate keys * Publish an event * Verify event

@ bbb5dda0:f09e2747

**CI/CD pipelines are great tools for the development cycle of an application, however, they're also very much centralized on platforms like GitHub and GitLab. In this blog I'm exploring the idea of decentralizing these tools using Nostr, and how I think DVM's will be the way forward. But first, let's explore the problem itself...** ## Current situation  Let's establish a baseline first. The average CI/CD pipeline looks something like this, where the first part represents the CI part and the green ones the CD part. ### CI (⚫) Pretty much any build starts with a commit being made on a project. That triggers the code to be pulled by a [build agent](##Definitions). That code then gets fed to a [Runner](##Definitions) that will build your code and produce some kind of [artifact](##Definitions) as an output. That artifact is then pushed to a repository appropriate for the kind of project. Meaning a docker container might be pushed to [Docker Hub](https://hub.docker.com/), a library in TypeScript might be pushed to [NPM](https://www.npmjs.com/search?q=nostr-dev-kit) and so on. That concludes the CI part of the pipeline. ### CD (🟢) While the CI part of CI/CD is often executed for every commit, the CD part is not. Most likely the CD part is only done when you want to release a new version of your software, either manually or automatically when you push to the `main` branch. Here the pipeline will take whatever artifact has been produced from the artifact store, such as Docker Hub and download it. It will also fetch some configuration necessary to boot the application. And lastly the Artifact is booted with that configuration. CD pipelines tend to be much more customized to the needs of the person/organization running the artifact. ### 📜 Facts & Assumptions - This system works regardless of wether or not the maintainer is online. - You need authorization to push to most artifact stores - You trust the entity (company) that runs the build agents to: - keep login credentials safe. - not be compromised and inject malicious code or push malicious artifacts in your name. - not deplatform your project for political reasons. - Each step in the process is executed by the same agent, or at least -in case of multiple- they share state. - You trust the artifact store to store your build output and not alter the contents. - The person pulling the artifact for deployment trusts the artifact store to give them the correct file. ## ⚠️ The problem Most people like the convenience of automated CI/CD pipelines to they don't have to build, package and distribute every version of their software manually. But when dealing with sensitive software like BTC wallets or privacy tools, entrusting centralized entities with the building and distribution of that software can pose a big risk. Moving into the future, this risk will only increase overtime. Even if the entity is friendly towards these projects it can be forced to take action against any project. The alternative is to build software manually anyway, or self-host these automation tools which can be cumbersome and not transparent when collaborating on a project. Also, this approach heavily relies on the presence of a project owner/maintainer. At the same time, the machines of targeted developers also risk being compromised and therefore risk distributing malicious software as well. ## 🌖 The goal What if we can achieve the convenience and transparency of automated CI/CD pipelines, but without the risks of centralized entities? I think Nostr gives us a framework to help us achieve that and even reduce risks of supply-chain attacks in the process. So the goal is to: - Run automated software builds without risk of compromised build agents or developer computers. - Store the output artifacts of builds in immutable, verifyable, decentralized storage. - Sign and distribute software to users without chokepoints. ## 🧩 What to work on? So there are 4 steps on the way from code to a running application. Each of these aspects need to be accounted for to achieve the goal: 1. Source code collaboration 2. Build/test processes 3. Storage of artifacts 4. Discovery of artifacts (artifact/app stores) Let's get into them: 1) This is already covered by other Nostr projects that implement [# NIP-34 (git stuff)](https://nips.nostr.com/34) so we won't focus on that. 2) The build and test process has no [solution](##Definitions) (known to me), so that needs most work. 3) Storage of artifacts is covered by [Blossom](##Definitions) which gives us decentralized, hash-based file storage, but I don't yet know when and by whom (npub) during the build process the file(s) should be uploaded. There also seems to be no current projects that act as artifact stores over Nostr for Docker images, NPM packages, etc... 4) This is already being worked on with projects like [zap.store](https://zap.store), so we won't focus on that either. That means I'm focussing on number 2 and 3. ## 🧭 Possible approaches Up until now I have mostly described the problem and where we want to go, but haven't gone into the HOW yet. The following are my initial ideas on how to approach this problem and reach our goal. Please share your feedback, questions and ideas with me so we can discuss them. ### Use of DVM's First and foremost, I believe Data Vending Machines (DVM) as defined in [NIP-90](https://nips.nostr.com/90) are to play a very important role in providing the compute for these decentralized pipelines. The open market of DVM's should be embraced and there should be many DVM vendors offering to execute specific tasks within a pipeline in the best way possible. There should be DVM's that are competing on the fastest build times, the cheapest builds, or any other metric deemed important to the customer. Utilizing a variety of vendors offering competing DVM's can also be used to enhance security in the process. > [!NOTE] > Whatever implementation of these pipelines is developed should not impose strict requirements on DVMs specialized in a certain task. ### 1) The Naive approach  The easiest and most straight-forward solution is to have each DVM is tasked with requesting the next DVM in line when it's done performing its task, all the way to the end of the flow. This will probably be fine for low-stakes scenario's like running unit-tests or running some (AI) code analysis. | ✅***Pro's*** | ❌***Cons*** | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Easy to implement | You need to trust every DVM in the chain to select trustworthy DVM for the next step | | Good fit for low-stakes tasks (running unit-tests/analysis) | Compromised DVM can gain full control over the rest of the process. | ### 2) Using a 'router' DVM  Credits for this idea go to nostr:npub1mgvwnpsqgrem7jfcwm7pdvdfz2h95mm04r23t8pau2uzxwsdnpgs0gpdjc To prevent any arbitrary DVM in the chain from making bad decisions on which next DVM to run, we can task one DVM for overseeing the process instead. We give it a mandate to execute all the steps of the pipeline. That way you don't have to put full trust in every DVM you might use for your pipeline. | ✅***Pro's*** | ❌***Cons*** | | ------------------------------------------------------------------------- | ---------------------------------------------------------- | | Relatively easy to implement | The router DVM becomes the weak link. | | Reduce trust to one DVM instead of having to fully trust the whole chain. | Compromised router can gain full control over the process. | | | | ### 3a) Spreading the mandate  The previous [solution](##Definitions)s still leave us with the risk of one single DVM being compromised and produce malicious output or execute the next step on another compromised DVM. What if we counter that by adding more 'eyes' to the task. Instead of having one DVM perform a task, we choose 3 or more unrelated DVM's that can execute the same task and have the human(oid) give each of them a piece of a [multisig](##Definitions) Nostr nsec. Then, when all three DVM's produce an output, they have to check each other's work and together sign the request for the next DVM in the chain to execute. That way, if one of the selected DVM's goes rogue, it cannot make any decisions on its own because it doesn't have full access to the nsec. This checking mechanism can be especially useful for verifying that the artifact of a build step is identical across several DVM's. That way you know that your build hasn't been tampered with. In practice this setup will mean there has to be some back and forth between the DVM's to reach an agreement, which can be tricky to implement. > [!NOTE] > For the sake of simplicity, I drew the Build & Deployment DVM steps as a single DVM. Ideally you would also run this one multiple times in parallel, just like the GIT Watcher. | ✅***Pro's*** | ❌***Cons*** | | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | Single Compromised DVM cannot influence process. | Complex, hard to implement | | Instead of trusting a single DVM, you trust a group of DVM's to not be fully compromised. | Requires each DVM to know how to handle the consensus logic. | | Can also be used to send Cashu funds down the chain to pay for DVM requests. | | ### 3b) Spreading the mandate + abstract complexity  A big issue with the previous setup is that the DVM's that execute the specialized task, like running the build now also have to deal with all this consensus logic. This would be a big burden on the people developing DVM's and would probably result in less DVM's being built compatible with these pipelines. To get around this, a wrapper DVM could be added that will handle the multisig and perhaps do some alterations with the in and output to make it work with the underlying DVM. This could however introduce some new trust challenges but they can probably be contained within the logic around the wrappers. | ✅***Pro's*** | ❌***Cons*** | | --------------------------------------------------------- | ------------------------------------------- | | Specialized DVM's don't have to implement consensus logic | Complex to design/build wrapper dvm logic | | | Wrapper DVM introduces new trust challenges | ## 💥 Other Challenges ### Software signing / Manual approvals There will be scenario's where somewhere during a pipeline the approval of a human is required. This is the case for signing an APK and likely too for uploading artifacts to an artifact store. This process will require the author/maintainer to sign some messages. ### On Web of Trust & Policies I think WoT will eventually become an integral part of curating which DVM's can execute certain parts of your pipelines. Depending on the project and risks associated with that (are you building a BTC wallet a Flappy Bird clone?) you might want to change your strategy of selecting DVM's. Some format of selection criteria for DVM's to run could be created by the human and passed down the chain. I have no clear idea yet on how this would work in practice. Some example criteria: - Most trusted DVM operators - Good uptime metrics - Cheapest - Fastest ## Definitions | ***Term*** | ***Explanation*** | ***Links*** | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | | Solution | Mystical response to a problem which only exists in the human mind. Often used by people actually talking about a good trade-off. | [Source](https://www.youtube.com/watch?v=dQw4w9WgXcQ) | | CI | Continuous Integration, the test and build stages of an application. | | | CD | Continuous Delivery, the deployment process of an application. Often involving configuring and booting an application on a server. | | | Build Agent | A (virtual) machine tasked with executing steps of a CI/CD pipeline. | | | Runner | Piece of software that executes jobs in a CI/CD pipeline | [GitLab Runner](https://docs.gitlab.com/runner/) | | Blossom | File storage/distribution protocol. Essentially Nostr, but for file storage. Allows accessing files based on a file's fingerprint (hash), rather than it's location. | | | Multisig key | A private key being divided into multiple private keys, where a certain threshold of keys have to sign a message for it to be valid. For example 3/5 keys need to sign a Nostr event before it can be published. | |

@ 266815e0:6cd408a5

> NOTE: this is just a quick technical guide. sorry for the lack of details ## Install NodeJS Download it from the official website https://nodejs.org/en/download Or use nvm https://github.com/nvm-sh/nvm?tab=readme-ov-file#install--update-script ```bash wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash nvm install 20 ``` ## Clone example config.yml ```bash wget https://raw.githubusercontent.com/hzrd149/blossom-server/master/config.example.yml -O config.yml ``` ## Modify config.yml ```bash nano config.yml # or if your that type of person vim config.yml ``` ## Run blossom-server ```bash npx blossom-server-ts # or install it locally and run using npm npm install blossom-server-ts ./node_modules/.bin/blossom-server-ts ``` Now you can open http://localhost:3000 and see your blossom server And if you set the `dashboard.enabled` option in the `config.yml` you can open http://localhost:3000/admin to see the admin dashboard

@ 3bf0c63f:aefa459d

# Nostr is not decentralized nor censorship-resistant Peter Todd has been [saying this](nostr:nevent1qqsq5zzu9ezhgq6es36jgg94wxsa2xh55p4tfa56yklsvjemsw7vj3cpp4mhxue69uhkummn9ekx7mqpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qy8hwumn8ghj7mn0wd68ytnddaksz9rhwden5te0dehhxarj9ehhsarj9ejx2aspzfmhxue69uhk7enxvd5xz6tw9ec82cspz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3vamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmnyqy28wumn8ghj7un9d3shjtnwdaehgu3wvfnsz9nhwden5te0wfjkccte9ec8y6tdv9kzumn9wspzpn92tr3hexwgt0z7w4qz3fcch4ryshja8jeng453aj4c83646jxvxkyvs4) for a long time and all the time I've been thinking he is misunderstanding everything, but I guess a more charitable interpretation is that he is right. Nostr _today_ is indeed centralized. Yesterday I published two harmless notes with the exact same content at the same time. In two minutes the notes had a noticeable difference in responses:  The top one was published to `wss://nostr.wine`, `wss://nos.lol`, `wss://pyramid.fiatjaf.com`. The second was published to the relay where I generally publish all my notes to, `wss://pyramid.fiatjaf.com`, and that is announced on my [NIP-05 file](https://fiatjaf.com/.well-known/nostr.json) and on my [NIP-65](https://nips.nostr.com/65) relay list. A few minutes later I published that screenshot again in two identical notes to the same sets of relays, asking if people understood the implications. The difference in quantity of responses can still be seen today:  These results are skewed now by the fact that the two notes got rebroadcasted to multiple relays after some time, but the fundamental point remains. What happened was that a huge lot more of people saw the first note compared to the second, and if Nostr was really censorship-resistant that shouldn't have happened at all. Some people implied in the comments, with an air of obviousness, that publishing the note to "more relays" should have predictably resulted in more replies, which, again, shouldn't be the case if Nostr is really censorship-resistant. What happens is that most people who engaged with the note are _following me_, in the sense that they have instructed their clients to fetch my notes on their behalf and present them in the UI, and clients are failing to do that despite me making it clear in multiple ways that my notes are to be found on `wss://pyramid.fiatjaf.com`. If we were talking not about me, but about some public figure that was being censored by the State and got banned (or shadowbanned) by the 3 biggest public relays, the sad reality would be that the person would immediately get his reach reduced to ~10% of what they had before. This is not at all unlike what happened to dozens of personalities that were banned from the corporate social media platforms and then moved to other platforms -- how many of their original followers switched to these other platforms? Probably some small percentage close to 10%. In that sense Nostr today is similar to what we had before. Peter Todd is right that if the way Nostr works is that you just subscribe to a small set of relays and expect to get everything from them then it tends to get very centralized very fast, and this is the reality today. Peter Todd is wrong that Nostr is _inherently_ centralized or that it needs a _protocol change_ to become what it has always purported to be. He is in fact wrong today, because what is written above is not valid for all clients of today, and if we [drive in the right direction](bc63c348b) we can successfully make Peter Todd be more and more wrong as time passes, instead of the contrary. --- See also: - [Censorship-resistant relay discovery in Nostr](nostr:naddr1qqykycekxd3nxdpcvgq3zamnwvaz7tmxd9shg6npvchxxmmdqgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqa2803ksy8) - [A vision for content discovery and relay usage for basic social-networking in Nostr](nostr:naddr1qqyrxe33xqmxgve3qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cywwjvq)

@ 5e5fc143:393d5a2c

We are now given a choice of digital freedom #nostr . Creativity for every nostrich is now unleashed from the cage of bigtech censorship , rules and algo. But freedom comes with responsibility so pick right one(s). I will try share here some learning experience both technical and also from fundamental point of view. Just wanted kick start this article n fill as we go like living reference document. Nostr itself is an application layer protocol that can used beyond just social media mirco or long blogging. Each nostr client heavily dependent on back-end servers call nostr "Relay servers" or in short "rs" or "relays" Relays can hosted anywhere in clearnet internet, onion net , vpn , i2p , nym Relays are controlled by their respective admins based NIP specs that they select to implement according to own decisions. Relays can have certain ToS (Terms of Service) Rules to adhered too. New users can choose and pick client or app (ios / android/ windows) with preset of relays in the simplest form , but other advanced users need to do a regular manual relay management. Relay management is an active regular task based on where when n how you are using. Relay list are saved within you npub profile backup file which can edited and broadcast anytime. Relay management is an active regular task based on where when and how you are using. Relay list always need to be updated time to time as and when needed. 2 Users MUST a common RELAY between them even if one only need to follow another. Occasionally you may notice certain npub accounts you are following already but cannot see frequent notes publish by them – one of cause maybe you not sharing a common relay Most nostr client applications has SETTINGS where user choose add/remove relays Also user choose which function to enable - READ or WRITE Relay list for your account is always saved within you npub profile backup file which can edited and broadcast anytime. Hence any app or browser when u login with you npub the same relay list will be enforced. There could valid reasons why u need have list for if you trying to save bandwidth and traveling. Functions in app.getcurrent.io and primal.net app for mobile apple or android are ideal for user traveling abroad and wanted to save bandwidth since relay management is done the providers in backend and saves hassle for basic usage. Remember if someone is selecting relay on your behalf then you may not be necessarily able to pull and get some specific and special content that you may need. Such providers like coracle and nostrid also give option to override the default relays they selected. Relay types: They can be categorized by various features or policy or technologies. FREE PUBLIC Relays vs PAID PUBLIC Relays PAID relays provide unrestricted access / write / filtering options than FREE relays but both are public clearnet relays. Just subscribing to PAID relays will not solve all problems unless you choose the relays properly and enable settings correctly. Private Replay or Tor Relays – normally not easily visible until unless someone tell you. You can also host own private relay not opened to internet of archive and back of your own notes. The technical landscape in nostr can be fast changing as more NIPs get proposed or updated. Relays admin can choose implement certain NIPs or not based on policy or technical limitations. Example NIP33 defines “long notes” aka blogs as you now reading this in habla site which #1 UI and site for "Editable" long notes – some relays donot implement or allow this. NIP07 is used for client authentication like nos2x and is implemented by all relays in fact. To be continued again ... reference pics will added later also Hope this help you understand "why when what" to tune and maintain active set of proper relays. Relay Proxy, Relay aggregator or Relay multiplexer – Paid, Public, Free, Private, Event, Relays That’s all for now n more later ... Thank you 🙏 ! ⚡️ https://getalby.com/p/captjack ⚡️ PV 💜 🤙 References: https://habla.news/relays https://relay.exchange/ https://relays.vercel.app/ https://nostr.info/relays/ https://nostrudel.ninja/#/relays Related Articles: https://thebitcoinmanual.com/articles/types-nostr-relays/ nostr:naddr1qqd5c6t8dp6xu6twvukkvctnwss92jfqvehhygzwdaehguszyrtp7w79k045gq80mtnpdxjuzl9t7vjxk52rv80f888y5xsd5mh55qcyqqq823cf39s98 https://habla.news/u/current@getcurrent.io/1694434022411