The app can't tell when a lite account graduates to a real Hive account

[Bielcx]

The problem

The app decides an account is "lite" from one thing: session.kind === 'userbase'. Nothing in the session says whether a Hive account has since been attached to it.

That is correct today, because an email account has no Hive account. It stops being correct the moment sponsorship lands (#63): the crew sponsors an account after the user's first post, the posting key is added to userbase, and from then on the server signs as the real account — while the app still believes the user is lite, forever, because the session still says userbase.

What a graduated user would see

• Notifications stay empty, permanently. lib/hooks/useNotifications.ts:18 and lib/notifications-context.tsx:32 skip the fetch for userbase sessions. Their real account can be commented on, voted, followed, and the app shows nothing and never badges.
• Their profile stays a lite profile. app/(tabs)/profile.tsx:184 renders the explainer card and zeroed stats instead of their grid, follower count and Hive Power — for an account that now has all three.
• The posts request is skipped (Lite account profile still asks Hive for posts, and logs an RPC error #61), so even the underlying data is never asked for.

Eight places branch on this: lib/auth-provider.tsx:179,487, lib/notifications-context.tsx:32, lib/hooks/useNotifications.ts:18,54, lib/posting.ts:23, app/(tabs)/profile.tsx:184,599.

The irony worth naming: the whole point of #63's copy is to tell people an account in their name is coming. When it arrives, the app is the last to know.

What is missing

UserbaseUser carries id, handle, display_name, avatar_url, status, onboarding_step — and no Hive account. The server already knows: resolveSigner() reads userbase_hive_keys to decide who signs.

So the fix starts on the API: GET /api/userbase/auth/session should return the attached Hive username (the account name is enough — the key must stay server-side). Then the app's question changes from "is this an email account?" to "does this account have a Hive account behind it?", which is the thing every one of those eight branches actually meant.

Two of the branches genuinely stay as they are — lib/posting.ts:23 and auth-provider.tsx:487 are about how to sign (server-custody vs local key), which does not change when the user graduates. The rest are about what the user has, and those are the wrong question today.

Ordering

This blocks nothing until sponsorship goes live, and blocks everything the day it does. Worth having the API field before the first sponsored user exists, rather than discovering it through someone whose notifications never arrive.

Suggested label: bug, blocked-on-api

[Bielcx]

Tested end to end with a real sponsorship (@fiveoout, sponsored from a Hive account via the web SponsorButton). The issue above was partly wrong, and the part that survives is narrower and clearer.

What actually happens

The profile graduates on its own, with no relog. The lite screen branches on (error || !hiveAccount), so the moment the account exists on chain the normal profile renders — including the bio the sponsorship process itself wrote to posting_json_metadata ("Account created via Skatehive sponsorship"). I predicted the opposite; the code was already right.

Posting graduates too. The next post went out as @fiveoout, not through @skatehive, and showed up on the web feed. The server's resolveSigner picks up the stored posting key with no client change.

One real regression was found by this test and fixed in #74. The posts gate added for #61 asked only whether the session was an email one — which stays true forever — so a freshly sponsored user got a correct profile showing "0 Clips" and "No posts yet". It now shares the same derived condition as the lite render.

What is still broken

Notifications. lib/notifications-context.tsx:32 and lib/hooks/useNotifications.ts:18 skip the fetch whenever session.kind === 'userbase', with no account check. A sponsored user has a real Hive account that can be replied to, voted and followed, and will never see a notification or a badge.

Unlike the profile, this cannot be fixed the same way: neither of those modules fetches the Hive account, and adding a per-poll account lookup to a two-minute badge refresh is worse than the bug. The clean fix is still the one this issue asked for — GET /api/userbase/auth/session returning the attached Hive username — so the app can ask "does this account have a Hive account?" instead of "is this an email account?".

Scope is therefore smaller than written above: three call sites, not eight.