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

@nevent1qqs...

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

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.


@nevent1qvz...

maybe peanut butter?

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.