Armada Android app connected over Amber using "Log in with Amber" or "Open signer app" never receives relay lists (while YakiHonne Android app works with no issues). The lists (10002, 10007, 10050, 10051, 10063) exist on wss://relay.ditto.pub and wss://relay.dreamith.to and they were broadcasted with wss://sendit.nosflare.com Reproduced on Samsung Galaxy A22s 5G with the stock latest and last (ended release cycle) firmware build version TP1A.220624.014.A226BXXSBDZC3, Android version 13. Armada 0.59.6, Amber 6.6.1, both from Zapstore. I see nothing meaningful in logcat when I press "Use this relay", no stacktrace. Login with Amber flow log: https://blossom.ditto.pub/ce459c8cb6a56fca1a146f52d810c348b4d5f29744a41fe94d2d86f4da1e4418.txt Open signer app flow log: https://blossom.ditto.pub/b0cc8462cfed040d4a2f87f8cd4c1402a675c9f6c454ed257da62743cae4ad33.txt

Replies (1)

I did. Yet I'm not sure where it will go yet. image It's mostly about the synergy of signers + DMs mess, which I believe is as close to resolution as ever. There's definitely a tension in the beginning: NIP-17 reliability is not just some meme. Clients are either buggy or/and propose wrong relays by default—this destroys UX in the beginning: View quoted note → Two of my close contacts either ran into exactly this issue or something similar. We don't see these bugs because we know what we do, and we don't normally use such crappy hardware as the cheap Samsung phones (with their custom firmware that always lags from the upstream Android). The problem with singers: bunker:// URI works great, but it's inconvenient to use for somebody who wants to connect from desktop to Amber. nostrconnect:// supposed to fix it, but it appears that clients propose some other relays the user didn't choose; these could be dead/slow/unavailable relays from their location. I ended up writing another starter guide/tool due to all this frustration: > anything that we could do in order for you to do that Mostly optimize for reliability: 1. Test apps on the crappiest of the popular devices. 2. Require clients to allow custom relays to be set in nostrconnect:// 3. Implement semi-automatic migration of dead relays to new ones everywhere: in ordinary clients and in the signers: View quoted note → 4. Get rid of raw nsec/ncryptsec input lines in the ordinary clients entirely—these are overabused, specifically when something fails with NIP-46. Every time somebody pastes their nsec in another slopware, I no longer trust them: I don't consider the DMs to be actually private. View quoted note → Some NIP could already directly state: "nsec SHOULD never be used directly in clients; NIP-46 and NIP-07 SHOULD be used instead". It's like the actual example of why we SHOULD use uppercase SHOULD sometimes—to show how stupid we were by allowing it to do otherwise.