qortal-go-2.0/MOBILE_VOICE_HUB_DEV_NOTE.md

Native mobile voice calls are working with the Hub — one small Hub tweak away from complete

We've built a native Android Qortal client with Reticulum voice calling that interoperates with the desktop Hub, and we're genuinely at the finish line. This is the breakthrough: a phone and the Hub now hold a real RNS voice call. We just need one small adjustment on the Hub side to make it work in both call directions.

The breakthrough

Hub → mobile calls work fully today — clean two‑way audio, low latency. No Hub changes were needed for this. The phone:

• captures mic audio, encodes Opus, and QGAU‑wraps frames byte‑for‑byte like the desktop peer;
• performs the QGCCTL1 + signed GC_JOIN link‑auth handshake over the RNS audio link, and the Hub verifies it and delivers GC_KEY over the link — exactly as designed;
• carries audio both ways over the verified Reticulum link.

In other words, the entire wire protocol — audio framing, Ed25519 link‑auth signatures, key delivery, RNS link transport — is already correct and the Hub already accepts it. That's the hard part, and it's done.

The one remaining gap

Mobile‑initiated calls (phone → Hub) get stuck on the Hub showing "connecting…" and drop after a few seconds, even though the phone is already "in call", sending audio, and sending the same signed link‑auth the Hub happily accepts in the other direction.

We traced it through electron/src/group-call.ts, and it is not a protocol or signature problem — the join verifies. It's a small ordering precondition:

• The audio‑link owner is chosen by address ordering (isLocalAddressReticulumAudioLinkOwner), not by who placed the call, so the Hub opens the link in both directions.
• Inbound link audio is dropped unless the link is marked verified (audio-unverified-address).
• A link is only marked verified in applyVerifiedReticulumLinkAuthJoin if the sender is already present in room.participants at that instant.

When the phone initiates, its verified link‑auth GC_JOIN arrives before the Hub has registered the caller in room.participants, so the Hub closes the link with link-auth-no-participant / drops audio as audio-unverified-address, and never leaves "connecting". In the Hub‑initiated direction the participant state is already in place, so the identical handshake verifies and the call connects. That single ordering difference is the whole gap.

The small Hub change we're asking for

In applyVerifiedReticulumLinkAuthJoin, when the signed GC_JOIN verifies and the sender is a valid Qortal member of the call, admit the participant from the verified join instead of bailing with link-auth-no-participant.

The verified join is itself authenticated proof of membership (Ed25519 over buildGcJoinSignedFields, already checked), so this removes the race without weakening security at all — it just lets a correctly‑signed mobile caller be admitted regardless of which side's participant bookkeeping landed first.

That's it. One precondition relaxed for the already‑verified path. With that in place, mobile→Hub (and mobile↔mobile) calls verify deterministically, exactly like the Hub→mobile calls that already work today.

What we are NOT asking for

• No change to the wire format, audio framing, signing, key delivery, or the link‑owner rule.
• Nothing changes for Hub‑initiated calls — they keep working as‑is.

Happy to jump on a call or share a build to demo the working direction live. We think this is a great step toward Qortal voice on phones, and we're one small Hub tweak from calls working every direction.