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