Nostr notes by hoppe

Shouldn't it be a comma instead of a period? 10.000 should be ...

2025-05-17T07:05:15Z

In reply to nevent1q…h4vw
_________________________

Shouldn't it be a comma instead of a period? 10.000 should be written as 10,000.

What I dislike the most about modern web apps is the practice of ...

2025-05-15T13:18:37Z

What I dislike the most about modern web apps is the practice of displaying time in a relative format, such as "a few minutes ago," "a few hours ago," or "a few days ago," instead of showing the actual time. It's a relief when hovering over the time reveals the exact time, but that's quite rare.

Since almost all web apps follow this trend, it seems like I'm the only one who doesn't like this method, and I really can't understand it.

While Lightning nodes prioritize fast responsiveness and expose ...

2025-05-15T04:10:29Z

In reply to nevent1q…tv6x
_________________________

While Lightning nodes prioritize fast responsiveness and expose their regular IP addresses, most Bitcoin nodes communicate through Tor, making it difficult to infer anything from their IP addresses.

When I try to copy notes to put them into a translator, I miss ...

2025-05-13T00:11:52Z

When I try to copy notes to put them into a translator, I miss the one-click full copy feature of Amethyst when using Jumble, and when using Amethyst, I miss the ability to select and copy only a certain portion.

I logged into Keychat using Amber. In the 'Me' tab, I ...

2025-05-12T10:43:40Z

In reply to nevent1q…ujm5
_________________________

I logged into Keychat using Amber. In the 'Me' tab, I noticed a 'Create ID' option. When I clicked it, I found an already generated seed phrase, and several npubs derived from it were already listed there. I don't recall ever setting up a seed phrase myself. Was it automatically generated either when I logged into Keychat through Amber or upon my very first access to Keychat?
Also, this seed phrase is completely separate and in no way linked to my Amber key, right? This is because my Amber private key wouldn't actually be stored in Keychat, correct? Is my understanding accurate?
Regarding usability, while for typical Android Nostr apps it's convenient to just use the native app directly and log in using Amber, I find that for web clients (or PWAs), viewing them through Keychat is more convenient.

Is Coinos really okay? This is a Lightning wallet, right? As far ...

2025-05-11T05:25:39Z

Is Coinos really okay? This is a Lightning wallet, right? As far as I know, a data loss issue in a Lightning wallet is not just a simple problem of transaction records disappearing; it can lead to significant financial losses. It could be a serious issue where you might lose the entire channel capacity.

quoting
nevent1q…h5em
SERVICE UPDATE:

Coinos is back online but withdrawals are currently frozen due to a data loss incident. We lost our whole database sometime overnight and the latest available backup is about 24 hours old so we will need to piece together payment records and balance updates that occurred in the meantime from logs somehow. We're working on it.

We also had an unplanned outage of about 4 hours yesterday due to issues arising from an Internet connection upgrade at our data center. It's not clear whether these two incidents are related. We don't suspect any foul play. Funds are safe and we will make sure everything is accounted for.

Thank you for your patience as we work to restore service.

Adam Soltys

It seems there might have been a misunderstanding, possibly due ...

2025-05-09T14:51:39Z

In reply to nevent1q…r5zd
_________________________

It seems there might have been a misunderstanding, possibly due to using a translator. My question wasn't about whether any Android app can use Amber.
Rather, I was asking: if a signer complies with NIP-55, can it be used for signing by a client, regardless of the specific signer implementation? This is similar to how client developers can request signing from any NIP-07 compliant signer (be it nos2x or Alby) without needing to specifically target or worry about which particular one it is.

"Bitcoin pays my settlements."

2025-05-09T00:33:56Z

In reply to nevent1q…tr54
_________________________

"Bitcoin pays my settlements."

When using a signer in the app, is it a concept that is dependent ...

2025-05-09T00:24:47Z

When using a signer in the app, is it a concept that is dependent on a specific app, or does it work in a way where any signer that meets a certain interface on the same phone can automatically handle requests?

Given that using #amethyst specifies "logging in with 'Amber'" and mentions a specific app name, it seems like it leans towards the former. However, if it were the latter approach, it would be more convenient. For example, browser signers like nos2x or Alby work seamlessly with any compatible signer.

There might be technical challenges involved, though.

I've made some improvements to the outbox-based relay sync ...

2025-05-05T07:22:59Z

I've made some improvements to the outbox-based relay sync tool I built earlier. While it doesn’t have many users, I personally use it and continue to maintain and improve it regularly.

https://tajava2006.github.io/sync-nostr-relay/

🔄 Switched to #NDK from `nostr-tools`
The core relay communication logic has been migrated from `nostr-tools` to `ndk`, which provides better support for:
Automatic reconnection to dropped relays
NIP-46-based automatic authentication
Previously, the sync process would immediately stop if any error occurred during communication. While this strict approach ensured consistent results, it also meant that syncs frequently stopped due to minor connection issues.
With `ndk`, automatic reconnection helps the sync process proceed more reliably without compromising data integrity.
🔐 Optional login via NIP-46
You can now optionally login using browser extensions like nos2x or Alby, thanks to `ndk`’s built-in NIP-46 support.
Important: login is optional — syncing still works without logging in.
Also, syncing is always performed for the pubkey entered, not the logged-in user.
The main reason for adding login support is to work around relays that require authentication or impose rate limits without it.
🧠 Smarter recovery from connection failures
As is expected in a decentralized environment, relay connections can drop unexpectedly — usually due to rate limits.
In the past, you had to restart the entire sync from scratch if this happened.
Now, if a sync stops due to a temporary issue, you can simply wait a bit and click the sync button again — it will resume from where it left off.
Caveat: If you manually change the "Sync From (Newest)" date before resuming, it will start fresh from that new date instead.)
📆 Date-range sync support
While implementing the resume-from-error feature, I also added support for syncing only a specific date range.
This can be useful if a relay was down for a certain period and you want to retry just that part.
⏱ Increased sleep interval to reduce rate-limits
I originally added generous `sleep` intervals between requests, but some relays were still rate-limiting.
I’ve increased the interval slightly to reduce disruptions.
Yes, this makes the sync process slower — but that’s an inevitable tradeoff when syncing all of your relays reliably.
If you're only using paid relays or ones that offer unlimited read/write access, feel free to comment out the `sleep` — it’ll speed things up significantly.

The core philosophy remains: accuracy and consistency first. If the tool can't reliably sync an event to all target relays (due to a persistent error, not just a temporary hiccup NDK handles), it will still stop to let you know.

quoting
nevent1q…a646
I’ve built a service that backs up nostr events. More precisely, it synchronizes between relays.

There have probably been similar tools before, but what sets this apart is that it strictly synchronizes based on the outbox model. Well, maybe something like this already exists too, but who cares? The world is full of similar programs anyway.

https://tajava2006.github.io/sync-nostr-relay/

The usage is simple: just enter your npub and press the sync button below. From that moment, it starts going back in time until there are no more events to fetch, syncing the relays as it goes. It queries notes in chronological order and republishes them only to the relays where they’re missing.

It syncs the posts I’ve written only to my write relays, and the posts I need to read only to my read relays.

This whole idea was inspired by this post I deeply resonated with:
naddr1qq…ytln

Because of that, the sync feature is not provided to users who have registered too many relays.

This should be helpful when you’ve changed your relay configuration and want to back up your past notes to newly added relays.

maybe peanut butter?

2025-05-05T06:32:09Z

In reply to nevent1q…r2v4
_________________________

maybe peanut butter?

There are many people who can endlessly talk about how Bitcoin is ...

2025-05-04T03:28:45Z

In reply to nevent1q…s9gy
_________________________

There are many people who can endlessly talk about how Bitcoin is superior to fiat currencies and how fiat currencies are an exploitative system, yet they seem to have no thoughts about the government that imposes this on us. It's even more surprising that some of them not only lack critical thinking but also support and flatter certain politicians. I find it quite strange. While I could understand if someone who isn't a Bitcoiner acted that way, it's puzzling when a Bitcoiner does.

If you issue about a billion notes on that relay, they might ...

2025-04-30T16:00:20Z

In reply to nevent1q…eqzz
_________________________

If you issue about a billion notes on that relay, they might delete all your notes.

#nevent1q…evja I've noticed from the comments here that ...

2025-04-30T11:24:13Z

quoting nevent1q…evja

Freedom Tech at the Oslo Freedom Forum this year is going to be 🔥

🇳🇴

I've noticed from the comments here that there are quite a few Monero supporters on Nostr as well. I've had some thoughts I've wanted to share with the Monero community for a while now, and seeing this discussion gave me a good opportunity to finally put them into writing. It ended up being longer than expected, so I’ve written it in long-form.
To those Monero supporters who are already well aware of the issues discussed in this piece and continue to support the project regardless — I don’t have much to add. But for those who may not be fully aware of these technical limitations and have committed, or are considering committing, a significant amount of money based solely on the idea that Monero offers strong privacy, I hope this serves as a chance to take a step back and think things through more carefully.

https://habla.news/a/naddr1qvzqqqr4gupzpqt9pxpxfx80uaysfuvx7ngfu2uc0vu3zwedpv59j6xz3q5e8q86qqxnzde5xccrqde48qungdf4z8hcc0

If anyone has experience with operating a Lightning address ...

2025-04-30T01:17:28Z

If anyone has experience with operating a Lightning address hosting server, please help me out. I'm trying to set it up, but it's not going well.

First, I connected the domain to the server's public IP and completed the TLS setup in nginx. I confirmed that I can access it via HTTPS from an external browser, and I also saw the lock icon in the address bar. I verified that the invoice is generated correctly at the lnurlp/myname?amount=1000 endpoint, and I can send payments using that invoice. So, it seems there are no issues with the connection.

However, when I try to send to the Lightning address, it doesn't work, and I have no idea why.

At first, I thought my Lightning address hosting server was too old and that the standards might have changed in the meantime, but that doesn't seem to be the case. I also wondered if the node I'm connected to isn't routing, but since I can send payments using the invoice obtained through the browser, that doesn't seem to be the issue either.

At this point, it seems like WOS might be the problem, but has anyone had a similar experience? For instance, does it not connect at all to addresses with self-signed certificates?

The address is hoppe@lightning.hoppe-relay.it.com. What could be the reason?

The moment we acknowledge that land ownership belongs to the ...

2025-04-30T00:36:46Z

In reply to nevent1q…ndwn
_________________________

The moment we acknowledge that land ownership belongs to the government rather than individuals (which is often supported by the public because it provides a sense of satisfaction when the wealthy are taken down a notch), it is a price we must accept.

Oh, are they not that old after all? I guess I can't really ...

2025-04-27T14:20:18Z

In reply to nevent1q…gj0q
_________________________

Oh, are they not that old after all? I guess I can't really gauge the age of Westerners very well.

I can understand why someone might feel they can't wait any ...

2025-04-27T14:19:24Z

In reply to nevent1q…cm0s
_________________________

I can understand why someone might feel they can't wait any longer when considering that person's age.

Indeed, the potential of something can be most sensitively ...

2025-04-27T12:04:58Z

In reply to nevent1q…mpnf
_________________________

Indeed, the potential of something can be most sensitively perceived not by its followers, but by its adversaries

Normalization is a principle of database design that aims to ...

2025-04-27T10:31:36Z

Normalization is a principle of database design that aims to eliminate redundancy. It means that if data can be derived from the source data, it should not be stored in the database (although this is often ignored for performance reasons). In this context, considering the differences between the UTXO model (represented by Bitcoin) and the account model (represented by Ethereum), the latter may seem more convenient and intuitive for usage, but from the perspective of data normalization, it has its drawbacks.

In Ethereum, the balance of my address is 'recorded' on the blockchain, so I can immediately know how much it is, and development is easier. However, in Bitcoin, the concept of account balance does not exist; the balance is simply the sum of the UTXOs that I control. I have to calculate and display the total every time.

But if you think about it, the account balance is not a piece of data that originally exists. The balance is merely the cumulative sum of the amounts that have come and gone from my address. Ultimately, it is storing separate aggregate information redundantly. This carries the risk of data integrity issues. Of course, the calculation of the cumulative amount and the balance is designed to be atomic, but that does not come for free; it consumes additional computational resources.

The most representative trade-off is that Ethereum must permanently maintain the nonce value of an account. In Bitcoin, each UTXO exists completely independently, so a transaction using a UTXO only needs to validate its own transaction. However, in Ethereum, the balance is literally the sum of previously received values, so it is not a matter of using a specific coin. Therefore, it cannot be validated separately, and all transactions occurring in an account must be processed sequentially, adhering to the nonce values in order. The account balance must be updated in sequence.

The nonce value cannot be deleted by the network even if the address is no longer in use, so it remains permanently. Assuming that there is no need to look for past transactions and that I only need to handle what I will receive, I can aggressively delete everything else while maintaining the UTXO set in Bitcoin. However, this is not possible in Ethereum (various attempts have been made to mitigate this, but ultimately, it requires sacrificing something else to achieve it).

For these reasons, the amount of hard disk space required to verify transactions and my account without relying on anyone else is slightly over 12GB for Bitcoin, while for Ethereum, as far as I know, it exceeds 100GB.

In summary, the main advantage of Cashu is that it frees ordinary ...

2025-04-27T04:08:17Z

In reply to nevent1q…rt8a
_________________________

In summary, the main advantage of Cashu is that it frees ordinary people, who may not know much about the Lightning Network, from the challenging task of operating a Lightning Network node. Complex issues like inbound and outbound liquidity are handled by specialized mints.

The downside, of course, is that it is custodial, meaning there is always a risk that the service could disappear, and this risk primarily falls on the buyer who actually receives the Cashu tokens.

As a seller, there is no need to trust random mints (in which case the tokens would essentially have no value); you can choose to only accept tokens from specific mints that you trust.

This means that both buyers and sellers can deposit or receive payments through mints they trust.

However, this also means that sellers and buyers must rely on their trusted mints to "swap" through the Lightning Network, which still presents the issue of routing failures. Ultimately, even when using Cashu, payment failures can occur. Of course, the liquidity management will be much more professional than that of the buyer or seller.

The number of deaths from the "common cold," which had ...

2025-04-27T01:26:10Z

In reply to nevent1q…y546
_________________________

The number of deaths from the "common cold," which had been very high in the years leading up to the COVID pandemic, suddenly dropped to zero. It's one of humanity's eight wonders, haha.

When someone comments on my writing, it would typically be ...

2025-04-26T09:22:03Z

In reply to nevent1q…a3mw
_________________________

When someone comments on my writing, it would typically be expected that they publish not only to their own writing relay but also to my reading relay (assuming we are following the outbox model of nostr). However, I'm unsure who should bear the cost for that, and I think it would be difficult to reach a consensus on it. Given the issue of spam, it doesn't make sense for me to pay, and it also seems a bit odd for the person commenting on my writing to pay for my reading relay.

I think a model that pays a small fee for serving the writing I ...

2025-04-26T09:08:35Z

In reply to nevent1q…k3um
_________________________

I think a model that pays a small fee for serving the writing I produce would work well. However, I can't seem to come up with a suitable business model for the comments I should receive or for when I leave comments on others' writings.

The term "shrinkflation" should be avoided. The word ...

2025-04-26T08:59:18Z

In reply to nevent1q…n2uf
_________________________

The term "shrinkflation" should be avoided. The word "inflation" is appropriate in every sense, and such terms are merely a tactic by the government, which monopolizes the power to issue currency and robs citizens of their wealth, to shift the blame onto entrepreneurs for its own wrongdoings.

I think NoteDeck is doing amazing work. It's just that when ...

2025-04-25T06:11:28Z

In reply to nevent1q…t7s7
_________________________

I think NoteDeck is doing amazing work. It's just that when fiatjaf mentioned the reason was him not having large relays, I commented wondering if maybe I had completely misunderstood NIP-65, but I think my intention might have been misunderstood. There's definitely no need for yet another very similar app. I'm particularly looking forward to the part in NoteDeck where I can query AI using Zaps.

It seems intentional that it resumes from where you left off last ...

2025-04-25T05:27:25Z

In reply to nevent1q…ar4e
_________________________

It seems intentional that it resumes from where you left off last time (and I think that's actually a nice feature), but I don't understand why the feed not showing up properly isn't considered a bug.

Isn't NIP-65 supposed to work by fetching notes from each write relay listed in my follow list’s NIP-65 models, rather than just connecting to my own NIP-65 relays? That way, whether or not my relays are shared with others shouldn’t really matter, right? Or maybe I'm misunderstanding how NIP-65 is meant to work.

Of course, merging all the write relays from a long follow list and constructing proper filters from the overlaps is probably not easy. So maybe it’s not exactly a bug, but more like an implementation that just isn’t fully finished yet.

Ah, the wallet is separate, so it doesn’t completely free you ...

2025-04-25T02:49:25Z

In reply to nevent1q…yk3z
_________________________

Ah, the wallet is separate, so it doesn’t completely free you from having to manage liquidity. But then again, saying you don’t have to worry about liquidity kind of implies a custodial wallet anyway — so maybe just create a custodial wallet and register it?

If you use https://shopstr.store/marketplace, you can probably ...

2025-04-25T02:42:38Z

In reply to nevent1q…nj57
_________________________

If you use https://shopstr.store/marketplace, you can probably sell things in a permissionless way without needing to host anything yourself. I can also help you test if the products show up properly and if LN payments work — as long as you list something for a tiny amount and send it back to me afterward.

😇

2025-04-24T15:59:34Z

In reply to nevent1q…akym
_________________________

😇

Worst case? The free society never comes — but , we’ll still ...

2025-04-24T09:41:39Z

In reply to nevent1q…rtzt
_________________________

Worst case? The free society never comes — but , we’ll still be rich in some broke country.

"You'll own nothing. And you will be happy"

2025-04-23T00:27:30Z

In reply to nevent1q…wkcs
_________________________

"You'll own nothing. And you will be happy"

I’ve always been really curious about this, so thanks for ...

2025-04-23T00:18:31Z

I’ve always been really curious about this, so thanks for sharing the info.
As things stand now, I see this as a process of building a reputation in preparation for the coming Bitcoin standard.
When that day finally arrives, the ones who get chosen as real routing nodes won’t be those scrambling to hire people, set up nodes, and market themselves at the last minute — it’ll be those who have quietly and reliably run routing nodes for years without any issues.
Someday, reputation might matter more than licenses.

quoting
nevent1q…5aea
Hello everyone! I want to share my opinion on how much a node or multiple nodes in the #Bitcoin #LightningNetwork can earn for their owners, using the example of my own nodes. I will provide the figures as an annual percentage.

Currently, over approximately five days, the entire network of my nodes earns about 500,000 satoshis per day on average. This is an average parameter. 500,000 satoshis is 0.005 bitcoins.

The liquidity on my side across all nodes is roughly around 300 bitcoins. So, let's simply calculate the annual percentage. You can roughly calculate it like this: 0.005 bitcoin multiplied by 365 days divided by 300 bitcoins. Multiply by 100%, and it comes out to about 0.6% profit from fees, which are currently at 700 ppm + 1 sat base fee.

This formula does not take into account the costs for opening channels, which include on-chain fees for Bitcoin channel opening transactions, nor does it include various expenses related to channel closures, whether automatic or forced, cooperative or forced. We are just taking the net figure as if the same channels were open all year without any expenses. You should also consider the risks associated with annual node maintenance. These include hosting costs, creating backups, labor efforts, and the risks of node hacking, which could theoretically be hacked and have all funds stolen.

Is this a profitable venture? You decide for yourselves. I just wanted to share some useful information with you.

Goodbye!

#Stats #LNBiG #profit #fees

Anyone who answered "yes" here doesn't understand why ...

2025-04-21T10:54:03Z

In reply to nevent1q…v694
_________________________

Anyone who answered "yes" here doesn't understand why Bitcoin was created.
Satoshi showed us that trust exists to be broken.

Exactly. Knowing the key is ownership, and nothing else should be ...

2025-04-21T09:03:01Z

In reply to nevent1q…8ap4
_________________________

Exactly. Knowing the key is ownership, and nothing else should be inserted into that equation. So what if someone else takes the coins? It's like treasure from a shipwreck decades ago — it belongs to whoever recovers it.

Any attempt to act outside of consensus wouldn't succeed anyway.

Every time I go through a revolving door, I can’t help but ...

2025-04-20T10:33:04Z

Every time I go through a revolving door, I can’t help but wonder—what’s the actual benefit compared to an automatic door? It doesn’t seem to save electricity, and it’s not like it offers any real security since anyone can walk through. It’s not even safer in terms of avoiding door-related accidents.

All it really seems to do is disrupt your normal walking pace and make things more inconvenient. Honestly, who designed this thing in the first place?

https://youtu.be/fZ0Qkhnt6bQ It might be helpful

2025-04-19T06:28:09Z

In reply to nevent1q…reyl
_________________________

https://youtu.be/fZ0Qkhnt6bQ
It might be helpful

Looks like #amethyst changed a bit in a weird way. I was ...

2025-04-19T01:10:25Z

Looks like #amethyst changed a bit in a weird way. I was wondering why it seemed off even though I hadn’t updated it — turns out I was looking at the Conversation tab instead of the New Threads tab.

The idea that objective standards exist can easily drift toward ...

2025-04-18T17:12:59Z

In reply to nevent1q…8hrj
_________________________

The idea that objective standards exist can easily drift toward socialism.
It stems from the belief that a central government can perform economic calculation.

If evaluations and compensation are made based on each person’s subjective judgment, things tend to balance out reasonably well.
Of course, such evaluations won’t directly correspond to productivity — not only is it impossible to create truly objective metrics in the first place, but in a free market, companies that make good judgments will be rewarded by the market, while those that fail to do so and drive away great employees will be penalized.

Over the long run, resources will naturally shift from the latter to the former.

That is… assuming the minor detail that we actually live in a free market.

It would be a relief if they were merely unproductive, but they ...

2025-04-18T11:49:43Z

In reply to nevent1q…x88l
_________________________

It would be a relief if they were merely unproductive, but they actively destroy industries.

I'm not sure which is more profitable — running a ...

2025-04-18T11:37:49Z

I'm not sure which is more profitable — running a JoinMarket maker bot or operating a Lightning node.
Both usually earn fees proportional to the volume they process, and the more liquidity you provide, the higher your chances of being chosen, so naturally, more funds mean better profitability.

Assuming you run both with, say, 10 BTC — not that I actually have 10 BTC, just saying — I wonder which one would be more profitable.

Anyone out there know?

Sometimes, it's unavoidable to use legacy social networks.

2025-04-18T10:53:41Z

In reply to nevent1q…mfl6
_________________________

Sometimes, it's unavoidable to use legacy social networks.

A small fee is indeed the most effective way to prevent spam. If ...

2025-04-17T00:15:15Z

In reply to nevent1q…n30v
_________________________

A small fee is indeed the most effective way to prevent spam. If it’s not worth spending money, you can just leave a reply instead. I do use it from time to time too, but if someone ask me whether it’s an essential feature, I’d say probably not.

Is it correct to understand it like this: Keychat uses Nostr for ...

2025-04-16T10:21:46Z

In reply to nevent1q…trgl
_________________________

Is it correct to understand it like this: Keychat uses Nostr for handling user identity and message delivery, but uses a different encryption protocol for the actual message encryption? And the reason for doing that is because Nostr alone, even with something like NIP-17, can't fully hide the recipient and doesn't offer complete encryption — so this is meant to address those limitations?

If that's the case, does it mean that i can't have a conversation with a regular Nostr client user at the level of encryption and privacy that Keychat promotes? Would it just fall back to the standard level of encryption provided by typical Nostr clients in that case?

They’re the kind of people who believe that land ownership ...

2025-04-16T00:59:46Z

In reply to nevent1q…0rpg
_________________________

They’re the kind of people who believe that land ownership belongs to the government, not the individual landowner. In other words, they’re basically communists—though they probably don’t even realize it themselves. It’s ironic how they also claim to love Bitcoin.

Speaking of which, the most absurd promotional claim about Nostr ...

2025-04-15T12:16:05Z

Speaking of which, the most absurd promotional claim about Nostr is that you can "own your own data." This isn't just because Nostr doesn't work that way at all, but more fundamentally, because information or ideas cannot be owned – not on Nostr, not anywhere.
The concept of ownership originates from the need for logical rules to allocate scarce resources. Therefore, information, which is not scarce, cannot fundamentally be an object of ownership. While the state attempts to recognize information as ownable through various intellectual property laws, this is just one of the government's many absurdities – a privilege that cannot be logically justified.
Intellectual property, from its very inception, is rooted in government coercion and lacks a basis in logic and reason, which is why it's inherently inconsistent. Can anyone provide a logical reason why a semiconductor recipe is considered intellectual property, but a cooking recipe is not?
Of course, this discussion pertains to general, publicly available information (like Kind 1 events on Nostr). However, if you can effectively exclude others' interference through certain means, establishing exclusive possession, then that can become an object of ownership. Thanks to cryptography, we can own our identity on Nostr (via private keys) and own Bitcoin (as money).
But publicly shared information, quite literally, is not 'your data' in the sense of ownership.

quoting
nevent1q…d004
there are currently so many factors that make this whole process near impossible to achieve:

- it's not only about trust in relays, but also trust in end users as they could re-broadcast what they see.

- clients have default big pre-defined relays

users are told they "own" their data which is kind of true only under very specific conditions

among other major onboarding issues, nostr is advertised with crazy statements: "you own your data" but as many others also mentioned before, data ownership is not real, it has never been.
and you can't ever have true control over where your data is going. for this to be real, each user would have their own household relay, all clients would use outbox model and, even then, it would only work for protected events while also hoping your posts don't end up broadcasted to relays that don't care about nip-70.

this makes me think there could be data crawlers all over nostr that will find your data and possibly just sell it.

PoW and paid relays are solutions yet to be, for the former, deployed on more clients, and for the latter, accepted by people (no one wants to pay)

- there's basically no information on the biggest relays rn and who owns them as far as i know

what relays to use in order to have the broadest view possible or to help with discoverability? nostr.wine looks okay... but what else is there?
if your client doesn't use the outbox model, setting main big relays is the only way for you to discover new content.

at this point i have accepted that anything posted on nostr is automatically freely accessible to everyone on earth by default. and we should expect all the companies in the world to track everyone's data. the censorship-resistant aspect is real though.

My phone isn’t a server, so I used to wonder — how is push ...

2025-04-15T00:54:18Z

In reply to nevent1q…fad9
_________________________

My phone isn’t a server, so I used to wonder — how is push notification even technically possible? After looking into it, I came to the same conclusion: in the end, our phones have always had to pull notifications from a big company like Google or Apple.

When I first encountered Nostr, I couldn’t understand why notifications didn’t work — but now it makes perfect sense.

But then I started thinking — if IPv6 becomes mainstream, could we finally have true push notifications in the literal sense? If every phone can essentially be a server, then yeah — I think it might be possible!
There would be some privacy issues, of course, but still.

And since we’re talking about Pokey, I’ve noticed that alerts often didn’t seem to work properly. I suspect there are two possible reasons:

1. Pokey doesn’t pull from the user’s own nip65-based read relays, but just fetches from some popular relays.

2. The socket connection between my phone and the read relays gets dropped when the phone goes idle.

It's kind of weird that there are country-specific settings ...

2025-04-14T05:56:31Z

In reply to nevent1q…gjj2
_________________________

It's kind of weird that there are country-specific settings beyond just language and time zone.

Every time I have to make changes to a legacy system at work, I ...

2025-04-14T00:34:11Z

In reply to nevent1q…7yz8
_________________________

Every time I have to make changes to a legacy system at work, I feel a strong urge to just tear it all down and build it from scratch.

If it's more than five, yeah. But if you run the code locally ...

2025-04-14T00:10:24Z

In reply to nevent1q…5pvy
_________________________

If it's more than five, yeah. But if you run the code locally yourself, you can bypass that limitation.

You're talking about notes that, for whatever reason, ...

2025-04-14T00:08:49Z

In reply to nevent1q…v2md
_________________________

You're talking about notes that, for whatever reason, don't appear on any of the user's current outbox relay list, right? Yeah, those definitely slip through.

I actually thought about trying to catch those too, but decided it’d be better to start with a simpler version first.

Along with what you mentioned below, that’s definitely something I should try implementing next. If that works, it might as well be called Nostr archaeology.

People really do think alike. If edits were implemented this way, ...

2025-04-13T14:00:28Z

In reply to nevent1q…3aje
_________________________

People really do think alike. If edits were implemented this way, we could call it a kind of SegWit for nostr. The difference is that, unlike SegWit which excluded the signature to preserve the ID, here it's the content that's excluded.

Thanks for the feedback. There’s still a lot to add — like ...

2025-04-13T13:35:47Z

In reply to nevent1q…h3hy
_________________________

Thanks for the feedback. There’s still a lot to add — like automatic reconnection on socket failure, user-configurable sleep time, auth support for users of paid relays, and more — but I decided to just release it for now.

I hope people find it useful, but I’m a bit worried there might be some bugs lol.

I’ve built a service that backs up nostr events. More ...

2025-04-13T09:16:36Z

I’ve built a service that backs up nostr events. More precisely, it synchronizes between relays.

There have probably been similar tools before, but what sets this apart is that it strictly synchronizes based on the outbox model. Well, maybe something like this already exists too, but who cares? The world is full of similar programs anyway.

https://tajava2006.github.io/sync-nostr-relay/

The usage is simple: just enter your npub and press the sync button below. From that moment, it starts going back in time until there are no more events to fetch, syncing the relays as it goes. It queries notes in chronological order and republishes them only to the relays where they’re missing.

It syncs the posts I’ve written only to my write relays, and the posts I need to read only to my read relays.

This whole idea was inspired by this post I deeply resonated with:

quoting
naddr1qq…ytln

Nostr is a mess. It always has been and will always be. That's part of the appeal! But it's important that users be able to navigate the rolling seas of this highly partition-tolerant network of kaleidoscopically-interwoven people, bots, topics, relays, clients, events, recommendations, lists, feeds, micro-apps, macro-apps, Chinese spam, and "GM"s.

In order to do this, users must be able to articulate "what" they are looking for, and clients must be able to articulate "how" to find that thing. This "how" is divided into two parts: building a request that will match the desired content (very easy), and selecting a relay that is able to serve that content to the user requesting it (very very hard).

Why guessing isn't good enough

As a concrete example, let's say the user wants to find everyone in their "network" who is using a particular topic. The process would look something like this:

The user clicks the "network" tab and types in the topic they want to browse. This is the "what".

The client then translates the term "network" to a list of public keys using whatever definition they prefer (Follows? WoT? Grapevine?), and builds a filter that might look something like this: [{"authors": pubkeys, "#t": ["mytopic"]}]. Any relay will happily accept, understand, and respond to that filter.

The client then has to decide which relays it should send that filter to. This is the ??? stage of the outbox model, which immediately precedes:

Profit

It may not be immediately obvious why selecting the correct relays might be difficult. Most people post to relay.damus.io, and most people read from relay.damus.io, so in most cases you should be good, right?

This approach to relay selection has historically worked "well enough", but it depends on a flawed definition of success. If you only want to find 90% of the content that matches your query, using the top 10 relays will suffice. But nostr is intended to be censorship-resistant. What if those 10 hubs have banned a particular public key? Nostr clients should (at least in theory) be 100% successful in retrieving requested content. Even if someone only posts to their self-hosted relay, you should be able to find their notes if their account is set up properly.

A naive solution to fixing the FOMO

A 90% hit rate results in a feeling of flakiness, even if users aren't completely aware of what isn't working. Feeds will be incomplete, quoted notes will be missing, replies will be orphaned, user profiles won't load. The natural response to the FOMO this creates is for users to "try harder" by adding more relays.

On the read side, this means clients open more connections, resulting in much higher data transfer requirements, with massively diminishing returns, since there's no reason to expect that a randomly chosen relay will have a substantially different data set.

One the publish side, this means that clients end up publishing more copies of their data to more relays. This approach has been automated in the past by services like Blastr, which don't store a copy of events published to the relay, but instead forward events to the top 300 relays in the network. This results in a two-orders-of-magnitude increase in storage required, and only makes the read side of the problem worse, since it reduces the uniqueness of the data set each relay stores. This in turn means that more duplicates are retrieved when querying relays.

Both halves of this approach are equivalent to guessing. On the read side, users are guessing which relays will have any arbitrary content they might ask for in the future. On the write side, users are guessing which relays other people might use to find their notes. It is a brute-force method for finding content.

Randomness results in centralization

In theory, random relay selection would result in a perfect distribution of content across all relays in the network. But in practice, this method of selection isn't random at all, but is strongly influenced by user bias in what constitutes a "good" relay. While some users may check nostr.watch for ping times, geographical proximity, or uptime, most will choose relays based on familiar names or other people's recommendations.

In either case, these biases are entirely orthogonal to achieving a higher content retrieval hit rate, except when bias in relay selection results in clustering — i.e., centralization. In other words, the kind of randomness exhibited by users when selecting relays actually results in pretty much everyone picking the same few relays. We see this same effect when people try to come up with passwords or seed phrases — human-provided randomness is anything but random.

Clustering improves the hit rate when requesting events (slightly), but it results in nearly as much centralization as if only a single relay was used — and a lot more duplicate events.

Something (anything) other than randomness

In early 2023, Mike Dilger introduced NIP 65 (now known as the "Outbox Model") with a problem statement in the spirit of the original description of nostr: "Nostr should scale better. People should be able to find what they want."

_Historical note: NIP 65 was formerly known as the "Gossip Model", derived from the name of Mike's desktop nostr client, called "Gossip". This unfortunately created a lot of confusion, since gossip protocols work very differently from how nostr tends to work, hence the re-brand._

Before NIP 65, an informal standard existed in which kind 3 user contact lists also included a list of relays that clients could use as something similar to Mastodon's "home servers". This list included the option to only read or write from a given relay. Unfortunately, it wasn't really clear what the semantics of this relay list were, so different clients handled them differently (and many clients ignored them). Usually this amounted to user-provided static relay configurations, which resulted in the naive relay selection approach described above.

NIP 65 used a very similar format (a list of relay urls with optional "read" or "write" directives), but with a very important semantic difference: relays listed in a user's kind 10002 were intended to "advertise to others, not for configuring one's client." In other words, these relay selections were intended as a signal to other users that they should use certain relays when attempting to communicate with the author of the relay list.

I highly recommend reading the entire NIP, which is very short and easy to read. But the mechanics of the spec are very simple:

When seeking events from a user, Clients SHOULD use the WRITE relays of the user's kind:10002.

When seeking events about a user, where the user was tagged, Clients SHOULD use the READ relays of the user's kind:10002.

When broadcasting an event, Clients SHOULD:

Broadcast the event to the WRITE relays of the author

Broadcast the event to all READ relays of each tagged user

For the first time, we had a way to differentiate relays in terms of what content could be found where.

When looking for a note by a particular user, a client could now look up the author's write relays according to their kind 10002 event, and send its query there. The result is a much higher hit rate with much lower data transfer requirements, and fewer connections per query.

Making Outbox Work

There are of course some assumptions required to make this work.

First, the user must know which author they're looking for. This isn't always true when looking up a quote or parent note, but context and pubkey hints solve this difficulty in most cases.

The author must also publish a kind 10002 event. This may not always be the case, but clients should prompt users to set up their relay list correctly. This isn't really a flaw in the Outbox Model, just in implementations of it.

Additionally, the user's client must be able to find the author's kind 10002 event. This is the "bootstrapping" phase of the Outbox Model, during which the mechanisms the system provides for finding events aren't available. This requires us to fall back to randomly guessing which relays have the content we're looking for, which as we saw above doesn't work very well.

Other than guessing, there are a few different ways a client might find the relay selection event in question, each of which is applicable in different circumstances. In most cases, using one of a handful of indexer relays like purplepag.es or relay.nostr.band is a simple and efficient way to find user profiles and relay selections.

However, if an author's content has been aggressively purged from these indexers due to censorship, they obviously can't be relied upon. Even though the author in question hasn't been deplatformed from nostr itself (since he can always self-host a publicly accessible relay to store his content), he has been effectively shadow-banned.

To get around this, relay selections have to be communicated in some other way. Nostr has a few different mechanisms for this:

If the author's NIP 05 address is known and properly configured (it may not be), clients can look up the author's NIP 05 endpoint to find some reasonable relay hints. Unfortunately, these are often neglected, and usually custodial, so they can run into the same problems.

If the author's pubkey is found in another signed event found on nostr, relay hints can be a way to propagate relay selections through the network. This relies on implementations picking reliable relay hints which can be difficult, and hints do tend to become less reliable over time. However, this strategy is very effective in resisting censorship because it makes banning viral — if a relay wants to completely purge a particular pubkey from their database, they have to purge every event that references it, since events are tamper-proof.

In extremis, relay recommendations can always be communicated out-of-band. This can be done using manual input, QR codes, DHTs, jsonl torrents full of kind 10002 events, or any other mechanism client developers choose to resort to.

Another, more technical assumption is that any given query can be fulfilled by few enough relays that a client can actually make all the connections needed, without running into resource limits. If you're trying to request content from 10,000 users across 1,000 relays, you're going to have a bad time. This was pointed out to me by Mazin of nostr.wine. He makes a good point, and it's definitely something to keep in mind. There are some mitigating factors though.

The first is that the current topology of the network probably won't persist forever. Because nostr is largely populated by self-hosting enthusiasts, the number of "tiny" relays is proportionally much higher than it will be if adoption picks up, even if the total number of relays grows. The trajectory is that nostr will drift toward fewer, larger relays, reducing the number of connections needed to fulfill any given query.

This is "centralizing", but it's important to understand that this isn't necessarily a bad thing. As long as there are more than one or two large hubs, there is user choice. And as long as it's possible to run a new relay, there is always an escape hatch. Nostr, like bitcoin, has no hard dependency on the biggest player in the network.

The other thing to consider is that there are lots of other techniques we can use to overcome the limits of the lowest-common denominator's limitations (mobile browser clients), including self hosted or third-party relay proxies. The trade-off here is that a little trust (aka centralization) can go a long way to reducing resource requirements needed to fulfill queries using the Outbox model.

If you're interested in more details on this topic, see this blog post.

That was a long digression, but there is one other thing that the Outbox model assumes to be the case. Even if the correct relays are found and connected to, they still may not return all desired content, either because they don't have it, or because they refuse to return it to the user requesting it.

This can happen if the publishing client isn't following the Outbox Model, if the author had migrated from one relay set to another without copying their notes over, or if the relay in question chose not to retain the author's content for some reason.

The first two issues can be fixed by improving implementations, but the question of policy is a little more interesting.

Relativistic relays

The Outbox Model is a mechanical process; it's only as useful as user relay selections are. In order for it to work, users have to be able to make intelligent relay selections.

Every relay has trade-offs, depending on its policy. 140.f7z.io would not be useful for long-form content, for example. Some relays might have a content retention policy that changes depending on whether you're a paying user. If you don't pay, you might find out too late that your content has been deleted from the relay.

So what makes a relay "good" for a particular use case? Well, it's complicated. Here are a few factors that go into that calculus:

Is the relay in the same geographical as the user? Proximity reduces latency, but jurisdictional arbitrage might be desired. Users should probably have a variety of relays that fit different profiles.

Will the relay ban the user? Do the operators have a history of good behavior? Is the relay focused on particular types of content? Is the relay's focus consistent with the user's goal in adding that relay to their list?

What are the relay's retention policies? A user might want to set up an archival relay for her old content, or a multi-availability-zone relay so her notes are immediately accessible to the rest of the network.

Does the relay require payment? Paid relays are more aligned with their users, but obviously come at a financial cost.

Does the relay have policies for read-protecting content? If so, other users might not be able to find your posts published to that relay. On the other hand, some relays are configured to work as inboxes for direct messages, which can help preserve privacy.

Does the relay request that users authenticate? Authentication can help manage spam, but it also allows relays to correlate content requests with users, reducing user privacy.

Is the relay you use hosted by your client's developer? If so, you're in danger of getting banned from your client and your relay at the same time.

Is the relay a hub? Using hubs can help smooth out rough areas in Outbox Model implementations, at the cost of centralization.

Is the relay used by anyone else? One-off relays can be useful for archival purposes, but often won't be used by clients following the Outbox Model, depending on how they optimize requests.

There are lots of ways to approach the problem of helping users select relays, but it's an inherently complex problem which very few people will have the patience to properly address on their own. Relay selection is a multi-dimensional problem, and requires satisfying multiple constraints with a limited number of relay selections.

In the future, special-purpose clients might be used to help people build relay sets. Clients also might provide curated "relay kits" that users can choose and customize. Or, we might see an increase in hybrid solutions, like smarter relay proxies or client-local relays that synchronize using other protocols or platforms.

The Limitations of Outbox

Outbox is not a complete solution, not because of any of the caveats listed above, but because NIP 65 per se only addresses the question of how to index content by pubkey in a broadcast social media context. But there are many other scenarios for relay selection that Outbox does not solve:

Community, chat, and group posts might be best posted to relays dedicated to that context.

Direct messages shouldn't follow the same contours as public social media content.

Topic-oriented relays, or relays serving a custom feed might be useful independent of who uses them.

Relays focused on serving a particular kind of event, like music, long-form content, or relay selections, are useful independent of who reads from or writes to them.

Certain clients might need to fulfill particular use cases by using relays that support certain protocol features, like search, count, or sync commands.

Some events might not make sense to publish to relays, but should instead be shared only directly, out of band.

Some of these use cases might be solved by new specifications similar to Outbox that prescribe where certain data belongs — for example, NIP 17 requires users to publish a different relay list before they can receive direct messages, while NIP 72 places community relay recommendations directly into the group's metadata object. A reasonably complete list of different relay types can be found in this PR, very few of which have a canonical way to manage selections.

Other use cases might be supported more informally, either by relays advertising their own value proposition, or via third-party NIP 66 metadata. Still others might be supported by scoping the network down to only certain relays through explicit relay selection — this is how white-labeled Coracle instances work.

The basic idea here is that there are categories of events that don't have anything to do with where a particular person puts his or her "tweets". For every "what" on nostr, there should be a "how".

Keep nostr weird

Whatever additional systems we end up adopting for helping with relay selection, one thing is certain — people will continue to discover new, creative uses for relays, and we will always be playing catch up. This is one of the coolest things about nostr!

But it does mean that users will have to adapt their expectations to a network that partitions, re-configures, and evolves over time. Nostr is not a "worse" experience than legacy social media, but it is a version of social media that has itself been set free from the stagnant walled-garden model. Nostr is in many ways a living organism — we should be careful not to impose our expectations prematurely, leaving room to discover what this thing actually is, or can be.

If you enjoyed this post but want more take a look at the talk I gave at Nostrasia last year. I also wrote up a blog post at about the same time that addresses some of the same issues, but focuses more on privacy concerns around relays and nostr groups. Finally, I recently wrote this comment, which includes some details about challenges I've faced putting Outbox into Coracle.

Because of that, the sync feature is not provided to users who have registered too many relays.

This should be helpful when you’ve changed your relay configuration and want to back up your past notes to newly added relays.

In the end, one way or another, the direction may look different, ...

2025-04-07T12:29:50Z

In reply to nevent1q…rflg
_________________________

In the end, one way or another, the direction may look different, but the essence is the same — the price of fiat money inevitably converges toward its intrinsic value: zero.

That would be a massive bank run. It might temporarily look like ...

2025-04-07T12:28:29Z

In reply to nevent1q…f72k
_________________________

That would be a massive bank run. It might temporarily look like the value of fiat money is rising — and in some ways, it actually is — but people won’t be able to access that money. In modern society, all assets are someone else’s debt. A chain of defaults will follow. The people who used to watch others’ assets go up with envy might feel thrilled for a moment, but they’ll soon realize the bank doesn’t have their money either.

Thank you for the interesting article. It was very helpful in ...

2025-04-06T03:03:56Z

In reply to naddr1qq…j8s4
_________________________

Thank you for the interesting article. It was very helpful in understanding the nostr ecosystem.
I have one question to confirm if my understanding is correct.
Assuming all clients adhere to the Outbox Model (NIP-65), and all relays store and serve requested notes completely, users should theoretically be able to find 100% of the posts authored by people they follow and the reactions to those specific posts without guessing or manually adding relays (ignoring the bootstrapping problem of how to initially find the NIP-65 event for someone I follow, let's assume that's solvable through reasonable guessing or indexers).
However, my understanding is that finding an original post (let's call it Post A) when someone I follow replies to or quotes it cannot be achieved 100% solely through the Outbox Model of the person I follow. It seems dependent on NIP-10 hints (p and e tags).
Specifically, is this process correct?

When my follow replies/quotes, their event must include hints (like a p-tag for the original author, let's call them Author B, and an e-tag for Post A).
My client finds the reply/quote on my follow's write relays (as per NIP-65).
My client extracts Author B's pubkey (from the p-tag) and Post A's event ID (from the e-tag).
My client then needs to find Author B's NIP-65 event (facing the bootstrapping issue again).
Then, my client must query Author B's write relays to fetch Post A itself (using its event ID).
And additionally, query Author B's read relays to find other reactions (likes, zaps, other replies) to Post A (since Author B is tagged in those reactions).

Is this multi-step process, relying on hints and the original author's NIP-65 relays, the correct way this interaction works within the Outbox Model's scope?

It’s like trading the difficulty of managing bitcoind for ...

2025-04-04T00:47:14Z

In reply to nevent1q…jh8z
_________________________

It’s like trading the difficulty of managing bitcoind for increased complexity in setup and maintenance. Considering that LN is usually used for micropayments, this still seems like the most realistic approach. I should probably consider it too. Thanks for the advice.

Embedding a Lightning node into everything that accepts payments ...

2025-04-02T00:39:59Z

In reply to nevent1q…zrqy
_________________________

Embedding a Lightning node into everything that accepts payments would certainly be the most reliable solution. However, every time I come up with a similar idea, I always get stuck on the question of where to source the Bitcoin node to use as the backend for LN.

Unlike other so-called "decentralized" coins, Bitcoin doesn't have a "foundation" running public nodes. As long as I control my private keys, using a Bitcoin node operated by someone else for a small fee wouldn't be a huge issue. But would it make sense to think of it that way?

Really? Thanks for the notification. I’ll have to check it when ...

2025-04-01T00:29:59Z

In reply to nevent1q…4zw5
_________________________

Really? Thanks for the notification. I’ll have to check it when I get home. I’m not sure if this is a Tor issue or a hosting server issue. Hopefully, there will soon be a field to add NWC to profiles like this.

quoting
nevent1q…2mlr
Our profiles should have a field for nwc where I can input a connection that only has make_invoice and make_chain_address permission

That way we don't need to rely on lnurl to zap

Yeah, running a Lightning Address hosting service directly seems ...

2025-03-31T23:59:36Z

In reply to nevent1q…lzaq
_________________________

Yeah, running a Lightning Address hosting service directly seems a bit inconvenient. It's easier to just use a relay.

Simple relay list. Gossip will just use your relays. No more ...

2025-03-31T23:49:04Z

In reply to nevent1q…nnks
_________________________

Simple relay list. Gossip will just use your relays. No more connecting to strange
relays or other outbox model nonsense.

Does this mean that gossip does not follow the outbox model? I heard that the outbox model originated from the gossip client—did I misunderstand?

the prettiest? She is at my home ☺

2025-03-31T23:43:44Z

In reply to nevent1q…f9nq
_________________________

the prettiest? She is at my home ☺

worked from alby ...

2025-03-31T23:41:02Z

In reply to nevent1q…u4kf
_________________________

worked from alby

Nostr event nevent1qqswtueaskrhyrhvsrdyam8s78an5uappnrj0xajvm2ltqkxcxzq44czyzqk2zvzvjvwle6fqnccdaxsnc4es7eezyaj6zegt95v9zpfjwq05te4g8v

2025-03-29T13:21:53Z

My first #lightning payment at an offline store. March 29, 2025, South Korea.

Every time I eat pork, I can't help but wonder if it might ...

2025-03-29T12:53:01Z

Every time I eat pork, I can't help but wonder if it might actually be tastier than beef. Of course, that thought lasts only until the next time I have beef.

There will be more and more people like him in the future, and ...

2025-03-29T12:44:34Z

In reply to nevent1q…ymvz
_________________________

There will be more and more people like him in the future, and that’s exactly why we need to store our wealth in a way that doesn’t get caught in the government’s digital system. Ah, democracy...

😥 Which mint?

2025-03-25T03:34:03Z

In reply to nevent1q…lp6q
_________________________

😥 Which mint?

Nostr event nevent1qqsz8vqyr3glrp4ls83040vevkdtsu4eqqpmgkdq5sa2l0fvcjl2f9gzyzqk2zvzvjvwle6fqnccdaxsnc4es7eezyaj6zegt95v9zpfjwq05f90z45

2025-03-22T01:07:11Z

#amethyst is great, but there's one annoying thing—when I scroll up, images that were expanded while scrolling down collapse and then expand again, which pushes the content in a way I didn't intend. Am I the only one bothered by this?

Thank you, I'll give it a try.

2025-03-20T23:38:49Z

In reply to nevent1q…vjr2
_________________________

Thank you, I'll give it a try.

Can someone recommend a combination of Bitcoin/Lightning Network ...

2025-03-16T09:25:52Z

Can someone recommend a combination of Bitcoin/Lightning Network node implementations that work well with a pruned Bitcoin node? I'm using Bitcoin Core and LND, and I've found that LND fails to sync properly when Bitcoin Core is pruned.
#asknostr #lightning

Do you have sufficient inbound capacity? I had a similar issue in ...

2025-03-13T10:37:50Z

In reply to nevent1q…kq4c
_________________________

Do you have sufficient inbound capacity? I had a similar issue in the beginning, and it turned out to be a capacity problem.

When I opened a channel, I sent a small amount of sats elsewhere, so I thought I’d be able to receive at least that much. But due to channel policies or something like that, I had to spend a certain amount first before I could start receiving.

If your channel is newly opened, most of the sats are probably on your side. Try spending at least 5,000 sats and then attempt receiving again—it might work.

I also struggled for days when I initially tried setting everything up as a fully self-hosted system.

The government's excessive power stems from its monopoly on ...

2025-03-11T01:18:41Z

In reply to naddr1qq…y428
_________________________

The government's excessive power stems from its monopoly on currency issuance. At a deeper level, its authority is upheld only by the public’s belief that government is necessary. Since Bitcoin is inherently anarchic in nature, the U.S. government will inevitably turn against it again.

If people truly realize that Bitcoin is real money and that the dollar is fake, why would they continue to use dollars and go through the hassle of exchanging them? Workers would demand to be paid in Bitcoin from the start, and merchants would insist on accepting Bitcoin for payments. Of course, this won’t happen overnight, but in a world where fiat currency continues to lose value, it is an eventuality.

When that time comes, people will also realize that transacting in Bitcoin could allow them to avoid paying taxes. That’s when the government will step in and take action.

Right. Changing the existing kind 1 like that would have too much ...

2025-03-11T00:51:59Z

In reply to nevent1q…vrg5
_________________________

Right. Changing the existing kind 1 like that would have too much of an impact. What I was talking about was creating a new kind (like 1999) that functions like a kind-1 note.

After writing a post, users would choose whether to publish it as a non-editable note or a new type of editable note. People would see both kind 1 and 1999 in their feeds the same way, but they might perceive the former as a more responsible statement.

And kind 1 would be made completely uneditable (maybe even undeletable).

Thanks for linking the thread—I’ll read through it when I get home.

It seems like there are two irreconcilable positions on this: One ...

2025-03-09T08:15:44Z

In reply to nevent1q…stgt
_________________________

It seems like there are two irreconcilable positions on this:

One side argues that the edit feature is technically complex, making it difficult for multiple clients to implement. This could lead to centralization, as the feature would be concentrated in a single client, or it could create issues where the same note appears differently in different clients. Therefore, they believe that edit functionality should never have been implemented from the start.

On the other hand, the opposing side argues that this is really a basic, fundamental feature that should be there.

What if, instead of including the content in the note ID, we only include everything except the content itself when generating the ID and then sign it? The content could be stored separately and merely referenced. This way, we could freely modify the content without complex implementations for how replies would refer to it.

And for other users, the note would simply be displayed with the understanding that "this person is saying something that could easily be changed later." What do you think about this approach?

time to stack preserved food

2025-03-08T02:39:07Z

In reply to nevent1q…785e
_________________________

time to stack preserved food

Just one step away from anarcho-capitalism.

2025-03-05T11:12:27Z

In reply to nevent1q…st4l
_________________________

Just one step away from anarcho-capitalism.

Regardless of the type of state, as long as a state exists, there ...

2025-03-05T00:33:41Z

In reply to nevent1q…c762
_________________________

Regardless of the type of state, as long as a state exists, there is no free trade.

A Lightning Node can be built-in, but each individual still needs ...

2025-02-28T05:03:02Z

In reply to nevent1q…r5ns
_________________________

A Lightning Node can be built-in, but each individual still needs to set up their own separate Bitcoin Core to connect to it, right? Bitcoin is the only coin that has truly achieved decentralization, but because of that, there is no foundation behind it. So, there would be no one to publicly provide shared nodes for public use.

Thanks!

2025-02-21T11:10:40Z

In reply to nevent1q…rdl9
_________________________

Thanks!

Wellcome to nostr!

2025-02-20T04:35:00Z

In reply to nevent1q…8par
_________________________

Wellcome to nostr!

That probably means it's not you but the other party in your ...

2025-02-19T04:20:41Z

In reply to nevent1q…4u54
_________________________

That probably means it's not you but the other party in your channel who is offline. Waiting won't solve the issue—once they turn their node back on, it will come online.

I once self-hosted a BTC node, a Lightning node, a wallet ...

2025-02-19T00:24:27Z

In reply to nevent1q…3zun
_________________________

I once self-hosted a BTC node, a Lightning node, a wallet service, and a Lightning address server, but things didn’t work well, so I ended up bothering a lot of people to test if they were working properly.

"Hard times create strong men. Strong men create good times. ...

2025-02-17T00:22:23Z

In reply to nevent1q…mh8u
_________________________

"Hard times create strong men.
Strong men create good times.
Good times create weak men.
Weak men create hard times."

Before long, we’ll have a generation that needs permission just to go to the bathroom. You might think that’s an exaggeration, but this is the direction things are heading.

Laws will be passed requiring workplaces to guarantee break times, mandating at least ten minutes of rest every hour. And when laws are enacted that put restrictions on their business counterparts, people will cheer, thinking it benefits them—applauding it as 'worker-friendly'—without realizing that, eventually, it will come back to affect them too.

There's no need to fight. We just have to walk away.

2025-02-13T00:12:15Z

In reply to nevent1q…ge3x
_________________________

There's no need to fight. We just have to walk away.

yyyyyes It works!!! Thank you so much☺

2025-02-09T16:11:47Z

In reply to nevent1q…pu62
_________________________

yyyyyes It works!!! Thank you so much☺

I think I’ve fixed it now. I’d really appreciate it if you ...

2025-02-09T14:50:17Z

In reply to nevent1q…7pac
_________________________

I think I’ve fixed it now. I’d really appreciate it if you could test it out when you have some time! Pawn Dev (nprofile…8q8q)

It may mean that the Bank of England is not far from declaring ...

2025-02-09T04:19:15Z

In reply to nevent1q…my5r
_________________________

It may mean that the Bank of England is not far from declaring default.

It seems like there might be an issue with my server. I don’t ...

2025-02-07T16:53:07Z

In reply to nevent1q…hnrm
_________________________

It seems like there might be an issue with my server. I don’t want to bother others with requests anymore, so I guess the only option is to create a personal NWC custodial wallet and test sending from there. It really doesn't seem like anything is easy. Still, thanks a lot.

My address is hoppe@lightning.hoppe-relay.it.com but you're ...

2025-02-07T16:21:47Z

In reply to nevent1q…p5ds
_________________________

My address is hoppe@lightning.hoppe-relay.it.com
but you're saying that zap can't be sent to this? I thought I had everything set up, but I still don't know what the issue is. Anyway, thanks for your help.

Sorry to bother you on first contact, but would it be alright if ...

2025-02-07T16:06:59Z

In reply to nevent1q…gt0k
_________________________

Sorry to bother you on first contact, but would it be alright if we both send each other a zap just to test? I'm testing my Lightning address self-hosting and it's been failing a lot, so I really hope this works this time. I've sent 21 sats #zap

It seems like the issue was that the domain name and IP ...

2025-02-07T15:02:13Z

In reply to nevent1q…8v5m
_________________________

It seems like the issue was that the domain name and IP weren't properly matched! I believe I just fixed it, but I'm really sorry to ask, but could you please test it one more time?

Nothing's easy. But thanks for testing it out! I’ll need to ...

2025-02-07T14:11:48Z

In reply to nevent1q…8v5m
_________________________

Nothing's easy. But thanks for testing it out! I’ll need to dig into it more.

GM. Although it's GN where I live. Recently, I tried ...

2025-02-07T14:01:18Z

In reply to nevent1q…m8lw
_________________________

GM. Although it's GN where I live. Recently, I tried self-hosting a Lightning Address server, but I'm not sure if it's actually working. I hope it works out.

I'm done! Can you check my lightning address? ...

2025-02-06T13:37:31Z

In reply to nevent1q…6e2f
_________________________

I'm done! Can you check my lightning address? saunter (nprofile…8czm)

I just created a Lightning address. I want to check if it's ...

2025-02-05T22:45:09Z

In reply to nevent1q…6e2f
_________________________

I just created a Lightning address. I want to check if it's working. Since the receiving capacity is low, Could you send me slightly less than the amount of sats I just sent?

Why is this being discussed at the World Economic Forum? Well, of ...

2025-02-03T01:04:48Z

In reply to nevent1q…etl8
_________________________

Why is this being discussed at the World Economic Forum? Well, of course, it's because this is about policies on economics, not physiology. 😁

# 📢

2025-02-01T15:42:39Z

In reply to nevent1q…ad7w
_________________________

# 📢

I’m currently looking for a way to self-host a Lightning ...

2025-02-01T00:09:11Z

In reply to nevent1q…juj5
_________________________

I’m currently looking for a way to self-host a Lightning address, so I can’t test receiving yet. So, this is just my gift!

There are many fools who equate their country with themselves and ...

2025-01-31T03:59:01Z

In reply to nevent1q…fe97
_________________________

There are many fools who equate their country with themselves and believe that protectionism, which strikes a blow to other nations, benefits them. Voluntary trade is mutually beneficial for both parties, and restricting it is essentially self-harm. When will they finally understand this?