There's a feature in Keychat wallet where sending "pay ecash" returns an ecash token, but sometimes it comes with a QR code and sometimes it doesn't. What's the difference? I'd like to provide a smooth experience where users can simply pass along a QR code, but when it only returns a token, I have to send it via DM, which is a bit inconvenient. #asknostr @Keychat

Sometimes, while using a VPN, Nostr-related apps occasionally fail to work properly. Since they always start working again as soon as I turn the VPN off, it's nearly certain that the VPN is the apparent cause. I initially thought the VPN might be blocking WebSocket connections to relays, but since the apps often work perfectly fine even when the VPN is on, that doesn't seem to fully explain it. What's more puzzling is that @Amethyst always works without any issues, regardless of whether the VPN is active or not. I can't figure out the reason for this inconsistency.

I believe providing economic incentives to relay operators is essential for the nostr ecosystem, and among the possible approaches, attaching e-cash when publishing events seems optimal to me. I’ve been skeptical of subscription-based payment models, and more importantly, with standards like NIP-17, users send their DMs not from their main pubkey but a temporary one—making subscription models fundamentally incompatible. Recently, I noticed increasing spam accumulating on my personal relay, which became quite unpleasant. I thought there must already be a NIP addressing this, so I went looking—but found nothing. Hmm? I decided to try implementing a solution myself, even if just according to my own idea. But immediately after starting, I understood why such a standard hasn’t emerged yet. It turned out to be too complicated. When publishing an event, devs familiar with the nostr ecosystem typically use an outbox model, publishing across different sets of relays dynamically. However, most clients don’t publish to individual relays one by one, but broadcast to all target relays via nostr-tools(or something like that). This means if we want to attach e-cash to a *specific relay only*, implementation complexity spikes dramatically. Moreover, what happens if the relay’s price changes? How should the relay behave if it receives the same event again (e.g., due to a re-synchronization or backfill)? Should already-sent e-cash be refunded, and if so, how? And if refunded, must that e-cash be redeemable again? When you dig into all these edge cases one by one, the feasibility of such a system becomes questionable. The most practical implementation so far might be keychat approach, but even that was designed for a messaging app rather than a social network—and still doesn’t integrate well with the idea of an inbox-relay model for DMs.

Snorkeling with sharks in the Maldives

Being at a resort with a poor internet connection has made the performance differences between Nostr clients strikingly obvious. nosotros seems to be the best. Of course, this might require a deduction based on how well it adheres to the Outbox model, so a simple comparison based on initial loading speed alone might not be a fair assessment. ​ Originally, the top performer in this area was @Amethyst but it slowed down a bit after the Outbox model update a few months ago. ​In reality, we can't really know how perfectly nostr clients construct the feed using the Outbox model. Since most people designate at least one large, popular relay as their outbox relay, it would be difficult to notice if a client doesn't actually support the Outbox model. ​As a side note, @Damus android was the only one that worked even when the internet connection was completely severed. This must be due to it fetching the feed from a local database rather than a relay, building the feed, and continuing to accumulate data in the local DB in the background. It's fast, too.

Questions about @Keychat * Direct Message Sorting: When I receive DMs through Keychat, the messages are often out of order, not sorted by the correct chronological time. This seems to be due to sorting by the randomly chosen time for metadata protection, following the NIP-17 standard. However, doesn't the encrypted data inside the seal contain the true timestamp of when the message was written? * Duplicate DMs: The DMs I receive are consistently displayed twice, as duplicates. I have no idea why this is happening. * Signal Protocol and NIP-17: I understand that Keychat uses the Signal Protocol, yet I still receive DMs from clients that do not support it. Does this mean that while sending messages uses the Signal Protocol, receiving messages supports both NIP-17 and the Signal Protocol? * Transaction Fees and Refunds: I saw in the documentation that sending a message (adopting a "postal system" model) consumes 1 sat via ecash. However, it seems to be immediately refunded. What is the reason for this refund? Could it be because I sent a DM to someone using a client that doesn't support the Signal Protocol, and the message therefore couldn't be delivered? In other words, does Keychat have a system to refund the sat if the message delivery fails?

There is a single reason why I cannot be completely positive about the future of Bitcoin. It's the scalability issue, and many people would say the Lightning Network is the answer. Of course, I've realized its usefulness by actually running a node, but I'm not fully convinced that it will work perfectly even when Bitcoin is used as the true money itself in the future. This is because an on-chain transaction is still required to open a channel, and Bitcoin's block size is fixed at 1 megabyte at the consensus level. I agree that the proper way to solve the scaling problem is through the Lightning Network, after solving the transaction malleability issue with SegWit, rather than increasing the block size. Increasing the block size requires a hard fork, is not a fundamental solution, and makes it increasingly difficult for individuals to run a node. However, can the Lightning Network be a fundamental solution? If the population continues to grow while Bitcoin's supply and block size are fixed, won't there inevitably come a day when people cannot afford the fee for even a single transaction, even if they work their whole lives? Even if everything is processed through Lightning, at least as many channel opening transactions as the number of people being born are needed, and that number will only continue to increase, right? This is a mathematically foreseen problem if we accept the assumption that the population will grow, not just a curse from pessimistic critics driven by jealousy. Consequently, won't the common people be unable to achieve true ownership in the genuine sense of the word? I'm curious about the stance of nostr user on this. The positions I've encountered so far are as follows, and I can't agree with any of them: * Solve it with a hard fork. -> This is the stupidest solution. How is this different from Bitcoin Cash? * The population won't grow that much. -> Is the future of humanity that pessimistic? * Ownership can be managed in a form like ecash. -> Does this mean complete ownership is solely the privilege of the rich and earlier generations? Doesn't this negate Bitcoin's greatest advantage? * A solution will eventually emerge that guarantees complete ownership and is affordable for common people, no matter how large the population. -> Isn't this overly optimistic? This is the reason why, even after understanding the Lightning Network, I bought Bitcoin with all the money I had left, and continue to buy Bitcoin with my salary (excluding living expenses), but I haven't been able to go all-in by selling my gold. Is there a solution I don't know about? If someone knows, please let me know.