hoppe

Public Key

npub1s9jsnqnynrh7wjgy7xr0f5y79wv8kwg38vksk2zedrpgs2vnsraqhzmew7

Profile Code

nprofile1qqsgzegfsfjf3ml8fyz0rph56z0zhxrm8ygnktgt9pvk3s5g9xfcp7spz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsqj7dfn

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1s9jsnqnynrh7wjgy7xr0f5y79wv8kwg38vksk2zedrpgs2vnsraqhzmew7

Show more details

Last Notes

2025-05-17 07:05:15 UTC

- reply

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

2025-05-15 13:18:37 UTC

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.

2025-05-15 04:10:29 UTC

- reply

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.

2025-05-13 00:11:52 UTC

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.

2025-05-12 10:43:40 UTC

- reply

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.

2025-05-11 05:25:39 UTC

- reply

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.
#nevent1q…h5em

2025-05-09 14:51:39 UTC

- reply

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.

2025-05-09 00:33:56 UTC

- reply

"Bitcoin pays my settlements."

2025-05-09 00:24:47 UTC

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.

2025-05-05 07:22:59 UTC

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.
#nevent1q…a646

2025-05-05 06:32:09 UTC

- reply

maybe peanut butter?

2025-05-04 03:28:45 UTC

- reply

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.

2025-04-30 16:00:20 UTC

- reply

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

2025-04-30 11:24:13 UTC

- reply

#nevent1q…evja
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

2025-04-30 01:17:28 UTC

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?

2025-04-30 00:36:46 UTC

- reply

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.

2025-04-27 14:20:18 UTC

- reply

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

2025-04-27 14:19:24 UTC

- reply

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

2025-04-27 12:04:58 UTC

- reply

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

2025-04-27 10:31:36 UTC

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.

2025-04-27 04:08:17 UTC

- reply

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.

2025-04-27 01:26:10 UTC

- reply

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.

2025-04-26 09:22:03 UTC

- reply

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.

2025-04-26 09:08:35 UTC

- reply

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.

2025-04-26 08:59:18 UTC

- reply

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.

2025-04-25 06:11:28 UTC

- reply

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.

2025-04-25 05:27:25 UTC

- reply

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.

2025-04-25 02:49:25 UTC

- reply

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?

2025-04-25 02:42:38 UTC

- reply

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-24 15:59:34 UTC

- reply

😇

2025-04-24 09:41:39 UTC

- reply

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

2025-04-23 00:27:30 UTC

- reply

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

2025-04-23 00:18:31 UTC

- reply

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.
#nevent1q…5aea

2025-04-21 10:54:03 UTC

- reply

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

2025-04-21 09:03:01 UTC

- reply

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.

2025-04-20 10:33:04 UTC

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?

2025-04-19 06:28:09 UTC

- reply

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

2025-04-19 01:10:25 UTC

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.

2025-04-18 17:12:59 UTC

- reply

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.

2025-04-18 11:49:43 UTC

- reply

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

2025-04-18 11:37:49 UTC

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?

2025-04-18 10:53:41 UTC

- reply

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

2025-04-17 00:15:15 UTC

- reply

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.

2025-04-16 10:21:46 UTC

- reply

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?

2025-04-16 00:59:46 UTC

- reply

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.

2025-04-15 12:16:05 UTC

- reply

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.
#nevent1q…d004

2025-04-15 00:54:18 UTC

- reply

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.

2025-04-14 05:56:31 UTC

- reply

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

2025-04-14 00:34:11 UTC

- reply

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.

2025-04-14 00:10:24 UTC

- reply

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

2025-04-14 00:08:49 UTC

- reply

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.

2025-04-13 14:00:28 UTC

- reply

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.

2025-04-13 13:35:47 UTC

- reply

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.

2025-04-13 09:16:36 UTC

- reply

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.

2025-04-07 12:29:50 UTC

- reply

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.

2025-04-07 12:28:29 UTC

- reply

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.

2025-04-06 03:03:56 UTC

- reply

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?

2025-04-04 00:47:14 UTC

- reply

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.

2025-04-02 00:39:59 UTC

- reply

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?

2025-04-01 00:29:59 UTC

- reply

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.
#nevent1q…2mlr

2025-03-31 23:59:36 UTC

- reply

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

2025-03-31 23:49:04 UTC

- reply

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?

2025-03-31 23:43:44 UTC

- reply

the prettiest? She is at my home ☺

2025-03-31 23:41:02 UTC

- reply

worked from alby
https://nostr.download/30e0a7b2040b8325f561e299249c7a4633dfbaf53d2d68e6ff663746a0e18379.webp

2025-03-29 13:21:53 UTC

https://nostr.download/e50752fb1a7e81850b10956a9fba4e2554b5d444f98e9f116bea9a8a558118f3.mp4
My first #lightning payment at an offline store. March 29, 2025, South Korea.

2025-03-29 12:53:01 UTC

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.
https://nostr.download/d01710814f246477c6562c504585839a4e0d5f0a7ad4d0ccf77a4c4c9ad8365e.mp4

2025-03-29 12:44:34 UTC

- reply

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

2025-03-25 03:34:03 UTC

- reply

😥 Which mint?

2025-03-22 01:07:11 UTC

https://video.nostr.build/2baec0f1bfd5f9a68c1b31357bcd83bed2133efb233d22c35b95a8f34517e27a.mp4
#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?

2025-03-20 23:38:49 UTC

- reply

Thank you, I'll give it a try.

2025-03-16 09:25:52 UTC

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

2025-03-13 10:37:50 UTC

- reply

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.

2025-03-11 01:18:41 UTC

- reply

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.

2025-03-11 00:51:59 UTC

- reply

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.

2025-03-09 08:15:44 UTC

- reply

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?

2025-03-08 02:39:07 UTC

- reply

time to stack preserved food

2025-03-05 11:12:27 UTC

- reply

Just one step away from anarcho-capitalism.

2025-03-05 00:33:41 UTC

- reply

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

2025-02-28 05:03:02 UTC

- reply

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.

2025-02-21 11:10:40 UTC

- reply

Thanks!

2025-02-20 04:35:00 UTC

- reply

Wellcome to nostr!

2025-02-19 04:20:41 UTC

- reply

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.

2025-02-19 00:24:27 UTC

- reply

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.

2025-02-17 00:22:23 UTC

- reply

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

2025-02-13 00:12:15 UTC

- reply

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

2025-02-09 16:11:47 UTC

- reply

yyyyyes It works!!! Thank you so much☺

2025-02-09 14:50:17 UTC

- reply

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

2025-02-09 04:19:15 UTC

- reply

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

2025-02-07 16:53:07 UTC

- reply

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.

2025-02-07 16:21:47 UTC

- reply

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.

2025-02-07 16:06:59 UTC

- reply

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

2025-02-07 15:02:13 UTC

- reply

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?

2025-02-07 14:11:48 UTC

- reply

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

2025-02-07 14:01:18 UTC

- reply

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.

2025-02-06 13:37:31 UTC

- reply

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

2025-02-05 22:45:09 UTC

- reply

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?

2025-02-03 01:04:48 UTC

- reply

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-01 15:42:39 UTC

- reply

# 📢

2025-02-01 00:09:11 UTC

- reply

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!

2025-01-31 03:59:01 UTC

- reply

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?