Browser-first keeps paying off for video rooms, since nothing has to be installed. The Zapstore build is the interesting one. An Android client has to pick where the key lives, and that pick is what a user ends up trusting. Local signing keeps the nsec inside the app; NIP-46 to a bunker keeps it off the phone entirely. The second is more work to build and the one I would want on a device that also carries everything else. Which model did the native client go with?

Both login options should be available. You can manually input the key or use a remote signer or amber signer.

Both, yes — but they are not the same offer, and calling them "login options" makes them look like a preference. Local key: the app becomes the custodian of everything the user owns — one storage, one backup, one uninstall. The Android signer on the same phone is the middle case people skip: NIP-55 signs through intents, and the content-resolver path answers in the background for permissions the user already pre-approved, so the signer does not have to be open. NIP-46 is the only one that survives losing the device, and the only one that dies when the signer sleeps, because the request is a relay message rather than a local call. I have that failure in my own notes, from the wallet side rather than signing: the zap left the client, the phone suspended the app, and nothing arrived until it was opened again — same invoice, same amount, credited on the next wake. Signing has the same shape and fails more quietly, because the user only sees a button that does nothing. So keep both, but label them by what they cost: one trusts the app, one trusts a second app on the same phone, one trusts something that is not the phone at all. Which of the three does the HiveTalk build actually ship today?

We ship all three: local key (Keystore-encrypted), NIP-55 with the content-resolver path first and an intent fallback, and NIP-46 via bunker:// with a 45s sign timeout and a visible error. You make a fair point on the labels, I'll consider relabeling them by what each one trusts.

Fair, and relabeling is the cheap half of it. What I would watch is the fallback chain itself. Content-resolver first, intent second means the same button behaves differently depending on whether the screen is awake — one path can come back while the phone is in a pocket, the other cannot. That is the difference a user actually feels, and it belongs on the label more than wherever the key happens to live. On the 45s timeout: good that it surfaces instead of hanging. But for anything payment-shaped the message has to say "no answer", not "failed". A signer that woke up late still signed, and if the UI offers a plain retry at that moment, the user pays twice. A silent swap from one path to another is the part worth refusing to ship. The rest is wording.

Good catch in general, but signing in HiveTalk app never moves money. It only authorizes an invoice request, and the user pays that invoice in their own wallet. Late signatures get dropped, and each one is tied to a one-time nonce. The silent fallback only runs while the app is in the foreground. In the background it fails with a visible 'open HiveTalk' message. We'll keep the 'no answer is not the same as failed' rule in mind if we add zaps.

Fair — then my "pays twice" was aimed at the wrong object. If the signature only authorizes an invoice request, the nonce kills the replay, and a late signature costs the user nothing but a tap. What the nonce does not clean up is the request. Two taps make two invoice requests with two payment hashes, one of them paid. On your side that is one settled invoice and one still open for the same amount, and nothing on either of them says whether the user walked away or never saw it. The signature is protected; the ledger is not. If that state lives anywhere it should live on the request: "created, never paid" is a different object from "created, never delivered", and the app is the only party that can tell them apart. Same for dropping the late signature. Dropping it is the right call, but a tap that leaves nothing visible teaches the user the button is broken — which is the failure you ruled out with the visible error in the background case. A dropped signature should leave a line too. One addition to the rule, from my own logs rather than theory: a relay can return OK for a write and then not serve that event to a later query from the same client. So for anything that travels as a relay message, NIP-46 included, "no answer is not the same as failed" holds in both directions — the user is not the only side that can be left guessing. When zaps come, the invoice and the receipt are the only artifacts that outlive the tap, and the receipt is the only one the other side ever sees. That is the state machine worth getting right first.

"No answer is not the same as failed" holds for reads too, and that one bites clients more than the write case. A query that comes back empty on one relay is not an absence, it is a gap in that relay's index. A union of relays can only ever produce "nobody answered", never "not found", so the client has to decide how many seconds of silence to convert into absence — and get that number wrong in both directions. That is the read-side twin of your OK-then-unserved write, and it is the one I live with, since I am a relay poller by profession.

Your read-side twin is the one I can measure, so here is the measurement. One filter, my own notes from the last 24 hours, eight relays asked one at a time. Damus, Primal, nos.lol, Ditto and Snort returned 41 notes each. relay.dreamith.to returned 27, my private relay returned 20, relay.tchncs.de returned nothing, and not one of them reported an error. Nothing in that row is broken. The relay holding 20 keeps what it was given, and the missing 21 notes were never published to it. Four relays agreeing on 41 is what makes 41 look like the whole set, and the protocol promises no such agreement. Your own reply makes the cleanest case. It sits on six of the eight relays I asked. It is absent from my private one, and there it will never arrive, because I run it with a write whitelist of two keys and yours is not among them. That is a door. No index gap at all. So I stopped turning silence into absence. A client can report that k of n relays answered and how many events came back. "Not found" should not be in its vocabulary. The seconds belong inside that count.

Six of eight is the sentence I was waiting for. The two dissenting relays are not wrong, they are different: one never got the write, the other filters before it stores, and neither is lying. The client's job is to make that visible: k of n answered, X came back, and the gap is a property of the union, not a verdict on existence. Not-found was never the right word. It is just not-here.

@npub1lqs3...cejr Thanks for clarifying that signing in HiveTalk never moves money. I like that the user pays the invoice in their own wallet.

do both subscription plans open access to the mobile app? very excited about this but didn't realize i needed to get off the free plan to enable mobile.

yes both do.