fix(web): stop NEXT_PUBLIC_*_AUTH_ENABLED from hiding the provider it names

[Chirag6722]

Fixes #1278.

The bug

The Google and GitHub buttons on the login page were gated like this:

{process.env.NEXT_PUBLIC_HOST_ID === "supermemory" ||
 !process.env.NEXT_PUBLIC_GOOGLE_AUTH_ENABLED ? ( /* Google button */ )

Because of the !, a self-hosted deployment that set NEXT_PUBLIC_GOOGLE_AUTH_ENABLED=true to turn Google on got the opposite result — the button disappeared. Same for GitHub.

Why not just drop the !

#1278 deliberately stopped short of a patch, because the two readings imply different defaults and the right one is a product call:

• Drop the ! (opt-in): matches the name, but the buttons vanish for every existing self-hoster who never set the flag. Breaking.
• Keep current behaviour (opt-out): the default is fine, but the variable is misnamed and setting it to true does the wrong thing.

This PR takes the second reading and makes the implementation honest, so no existing deployment changes behaviour:

flag value	before	after
unset	shown	shown (unchanged)
true	hidden ← the bug	shown
false / 0	shown	hidden (new — a real off-switch)

Only the previously broken case changes. The flag now never hides the provider it names, and self-hosters get an actual way to turn a provider off, which the old logic couldn't express either.

If you'd rather have true opt-in semantics (unset = hidden), say so and I'll flip it — it's a two-line change to isSocialProviderEnabled, though it would want a changelog note for self-hosters.

Also

Both variables are now in apps/web/.env.example. #1278 notes the two gating lines were their only references anywhere in the repo — no example entry, no docs.

Verification

• biome check passes on both changed files.
• tsc --noEmit on apps/web: 84 errors before, 84 after, 0 in the login page. (Those 84 are pre-existing — CI only type-checks @supermemory/ai-sdk and @supermemory/memory-graph, which is the subject of turbo run check-types is a no-op — no workspace package implements the script #1249 / fix: make check-types cover all major workspaces #1446.)

[Chirag6722]

@Dhravya @MaheshtheDev — first contribution here, so both Actions runs are parked at action_required and need a maintainer to approve them before anything runs.

In the meantime I ran CI's exact steps locally against this branch:

• bunx biome ci --changed --since=main --no-errors-on-unmatched — passes
• bunx turbo run check-types --filter='@supermemory/ai-sdk' --filter='@supermemory/memory-graph' — 2 successful, 2 total
• bun.lock is untouched, so bun install --frozen-lockfile is unaffected

The one thing worth your call is the default, which is why #1278 was filed as an issue rather than a PR: I went with opt-out semantics so no existing self-hosted deployment changes behaviour (unset still shows the provider, true now shows it instead of hiding it, false/0 hides it). If you'd rather have true opt-in — unset means hidden — it's a two-line change to isSocialProviderEnabled and I'll push it right away.

[Chirag6722]

Hi @MaheshtheDev — no problem with this being closed, but could you say what the reason was? There's no note here and I'd like to know for next time.

Asking because #1278 is still open and both gates are still inverted on main (apps/web/app/(auth)/login/page.tsx lines 479 and 536), so I don't think it was fixed elsewhere.

If it was the semantics: #1467 added the AgentID gate as plain opt-in (HOST_ID === "supermemory" || NEXT_PUBLIC_AGENTID_AUTH_ENABLED, no !), which answers the question #1278 was waiting on. I'd happily redo this to match that, so all three providers read the same way — it's a small change and the branch also needs a rebase now.

If you'd rather not take this from outside the team, that's completely fine — just let me know and I'll leave #1278 alone.

[MaheshtheDev]

yeah, will share more briefing about it by monday