No way to link a Hive account to an email account from the app

[Bielcx]

The gap

An email account and a Hive account can be linked — the web shows it plainly:

available connections
hive — not linked
eth — not linked
farcaster — not linked

The mobile app has no way to do that. lib/userbase/api.ts exposes voting, commenting, following, profile edit and reporting; there is no link, connect or attach call anywhere.

It does, however, already depend on the result. lib/instagram.ts:13 notes that for an email account "the server resolves the linked Hive identity", and the eligibility check reads "a userbase account whose attached Hive account has HP". So linking exists server-side, matters to features that already ship, and simply cannot be started from the phone.

Why it matters now

#60 made email the primary way in, and #63 tells lite users how to get a Hive account of their own. Follow those instructions today and this happens:

1. Create the Hive account at signup.hive.io.
2. Come back and use Sign in with Hive ›.
3. The app now holds two separate accounts — the email one and the key one — with no idea they are the same person.

The only way to join them is to open skatehive.app in a browser and link there. A path the app recommends should not end outside the app.

What it needs

• The linking endpoint exposed for the app, whatever proof of ownership the web flow uses. Signing a challenge with the posting key is the obvious candidate, since the app already signs requests that way for Instagram.
• Somewhere to start it. The natural spot is the lite-account profile, right where "how to get your own" already lives — the moment someone has just created their account is exactly when they want to attach it.
• A clear result: after linking, one account in the list, not two.

Until then

The instructions should say so out loud: after creating a Hive account, link it at skatehive.app, or the app will treat it as a second account. Better an honest extra step than a confusing surprise.

Suggested label: mobile, needs-backend

[Bielcx]

Investigated the backend. This is not "expose an endpoint" — it is a trust-model decision, and it conflicts with something the app currently promises.

What "linked" actually means

From SkateHive/skatehive-api, src/lib/userbase/posting.ts:

// tabela: userbase_hive_keys
select("encrypted_posting_key, encryption_iv, encryption_auth_tag, hive_username")
  .eq("user_id", userId)
// row present → sign as that Hive account
// no row      → sign as the shared account (lite)

So an account is "linked" when the server holds your posting key, encrypted at rest, and signs on your behalf. resolveSigner() is the whole mechanism: key present means you post as yourself, absent means you post as @SkateHive.

That is server custody. It is a perfectly coherent design for a web app where there is nowhere safe to keep a key — but it is the opposite of what the mobile app does.

Which is a problem, because the app promises otherwise

The Hive sign-in screen says, in as many words:

Your key is encrypted on this device and never leaves it.

That is true today: lib/secure-key.ts encrypts with PBKDF2 and stores in expo-secure-store, unlocked by PIN or biometrics. Adding "link your account" as the web implements it would mean asking users to upload the private key that sentence promises to keep local.

Nobody should ship that without deciding it deliberately.

The two ways out

A — server custody, like the web. The app sends the posting key to be stored encrypted server-side. The upside is real: the server can then act as you everywhere, including the Instagram cross-post and anything the web does. The cost is that the promise above has to be rewritten, honestly and prominently, and a private key leaves the phone.

B — association only, signing stays local. The server records hive_username for the user with no key, and mobile keeps signing locally as it already does for key accounts. Nothing leaves the device.

The catch for B is what the server can no longer do on your behalf: anything routed through /hive/* today (vote, comment, follow, report) assumes it can sign. Those calls would need the app to sign locally once linked — which it already knows how to do — and the web would still need its own key path.

Worth noting B is also closer to how Hive apps normally work: prove ownership by signing a challenge, store nothing.

Also worth knowing

No route in skatehive-api writes userbase_hive_keys — posting.ts only reads it. Whatever populates it lives somewhere else (an admin panel, or the sponsorship flow). So the write path may not be public API at all, which matters for estimating this.

What this issue needs before code

A decision between A and B, from whoever owns the key-custody policy. Everything else — endpoint shape, where the button lives, what the app shows after linking — follows from it, and none of it is hard.

Related: #63, whose instructions currently end by telling people to link on the web, because of exactly this gap.

[Bielcx]

Two corrections to the analysis above, from the docs (https://docs.skatehive.app/docs/Get%20Started/accounts-and-identities) and from @vladimir-jelovac.

1. Linking by Keychain signature is already a documented path, not an open policy question. I framed this as a choice between "give the server your key" and "don't link at all", and treated server custody as the blocker. The docs describe linking by proving ownership with a signature instead — the key never leaves the device, and the server stores the association, not the secret. That resolves the conflict I raised with the app's "your key never leaves this device" promise; it does not need deciding, it needs building. Mobile has no Keychain, so the app's equivalent is signing locally with the posting key it already holds.

2. The sponsored-account case is not this issue. New users get sponsored automatically after their first post, and the posting key is added to userbase server-side, so email login arrives already linked (see #63). Nothing to unify by hand there.

What remains here is the genuine case: someone who already had a Hive account, then signed up by email. Two identities, both theirs, no way to say so. That is the scope now.

[Bielcx]

Worth being explicit that automatic sponsorship (#63) does not close this — it sharpens it.

Someone who already has a Hive account and signs up by email anyway now gets, after their first post, a freshly sponsored account under whatever handle they picked at signup. They end up holding two identities, with reputation and rewards split between them, and nothing in the app warns them or offers to join the two.

Before, the worst case was "linking isn't possible". Now the app actively manufactures the duplicate.

Cheapest mitigation that doesn't need the linking flow: at signup, when the handle someone types already exists on Hive, ask whether it's theirs, and point them at "Sign in with Hive" if so. checkUsername already calls that endpoint (lib/userbase/api.ts) — today it only reports the name as taken, which reads as "pick another" exactly when the right answer is "you already have this".

That's a hint, not a fix. Actual linking still needs the server side described above.