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. πŸ”„ 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. View quoted note β†’
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?