hoppe

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.

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.

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 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. nostr:nevent1qvzqqqqqqypzpqt9pxpxfx80uaysfuvx7ngfu2uc0vu3zwedpv59j6xz3q5e8q86qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qglwaehxw309ahx7um5wghxsmmswpjj6un9d3shjtnfwshxxmmd9uqzp2eutjj4qzpdgyhv3g8gdunczhyqw7tt9vczcv3v2z63sy8zuts0faa646

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?

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.

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?

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.