Adopt 'Atmosphere account' terminology in default OAuth/login copy #32

New issue

Closed

opened 2026-04-26 14:08:18 +00:00 by Grandiras · 2 comments

Grandiras commented

2026-04-26 14:08:18 +00:00

Owner

Summary

The community has been converging on "Atmosphere" as the user-facing umbrella term for the AT Protocol ecosystem (analogous to how "the Web" is the user-facing term while "HTTP" stays under the hood). Several apps have already started shipping copy like "Sign in with your Atmosphere account" instead of "Sign in with AT Protocol", and it reads noticeably more humanly to non-technical users.

It would be great if ATProtoNet.Blazor's LoginForm (and any default copy in the OAuth start endpoints) supported this terminology — either as configurable strings, or as the new default with the old "AT Protocol" copy still available for opt-in.

Why this matters

"AT Protocol" is a developer term — fine for docs, awkward in a sign-in button shown to a Bluesky user who's never heard of the protocol.
"Atmosphere" is being adopted across community-built apps; if SDKs lag the user-facing copy, every app ends up wrapping/overriding the defaults (which I'm doing right now in my project).
Keeps the SDK's defaults aligned with where the network is heading.

Concretely, what I'd like

The default copy in components like LoginForm is currently something like:

Sign in with AT Protocol

I'd like to be able to ship it as either:

Sign in with your Atmosphere account

…or similar. Two reasonable shapes for the API:

Config-only: add HeadingText, SubtitleText, etc. parameters to LoginForm so apps can fully override the strings without re-implementing the form.
Default change: swap "AT Protocol" for "Atmosphere" in default English copy, with the old wording available via parameters or via i18n resource overrides.

Either works for me — option 1 alone is enough to unblock downstream apps; option 2 would be the kinder default for everyone.

Context

I'm hitting this on a small Blazor app that uses ATProtoNet.Blazor. Right now I'm overriding the heading/subtitle in my own page wrapper and only using LoginForm for the form fields — would prefer to just configure copy on the component itself.

Happy to send a PR if you'd like, just want to make sure the direction is welcome before I start.

## Summary The community has been converging on **"Atmosphere"** as the user-facing umbrella term for the AT Protocol ecosystem (analogous to how "the Web" is the user-facing term while "HTTP" stays under the hood). Several apps have already started shipping copy like *"Sign in with your Atmosphere account"* instead of *"Sign in with AT Protocol"*, and it reads noticeably more humanly to non-technical users. It would be great if `ATProtoNet.Blazor`'s `LoginForm` (and any default copy in the OAuth start endpoints) supported this terminology — either as configurable strings, or as the new default with the old "AT Protocol" copy still available for opt-in. ## Why this matters - "AT Protocol" is a developer term — fine for docs, awkward in a sign-in button shown to a Bluesky user who's never heard of the protocol. - "Atmosphere" is being adopted across community-built apps; if SDKs lag the user-facing copy, every app ends up wrapping/overriding the defaults (which I'm doing right now in my project). - Keeps the SDK's defaults aligned with where the network is heading. ## Concretely, what I'd like The default copy in components like `LoginForm` is currently something like: > Sign in with AT Protocol I'd like to be able to ship it as either: > Sign in with your Atmosphere account …or similar. Two reasonable shapes for the API: 1. **Config-only:** add `HeadingText`, `SubtitleText`, etc. parameters to `LoginForm` so apps can fully override the strings without re-implementing the form. 2. **Default change:** swap "AT Protocol" for "Atmosphere" in default English copy, with the old wording available via parameters or via i18n resource overrides. Either works for me — option 1 alone is enough to unblock downstream apps; option 2 would be the kinder default for everyone. ## Context I'm hitting this on a small Blazor app that uses `ATProtoNet.Blazor`. Right now I'm overriding the heading/subtitle in my own page wrapper and only using `LoginForm` for the form fields — would prefer to just configure copy on the component itself. Happy to send a PR if you'd like, just want to make sure the direction is welcome before I start.

Grandiras commented

2026-04-26 14:09:40 +00:00

Author

Owner

Also, supporting translations would be nice.

Grandiras referenced this issue from a commit

2026-05-26 01:04:52 +00:00

feat: Atmosphere account terminology and i18n in LoginForm (closes #32)

Grandiras closed this issue

2026-05-26 01:04:52 +00:00

Grandiras commented

2026-05-26 01:05:20 +00:00

Author

Owner

Implemented in v0.4.0 (commit 4f18c36).

LoginForm now defaults to the "Atmosphere account" terminology:

Default copy: "Sign in with your Atmosphere account" / "Your Atmosphere account handle — your PDS is detected automatically."
New HeadingText / SubtitleText parameters for optional heading + subtitle above the form (no default, rendered only when set)
All string parameters now accept string? and consult an injected IStringLocalizer<LoginForm> when one is registered, falling back to the English defaults — translations work via standard ASP.NET Core localization (.resx, JSON, custom factories, etc.)
Explicit parameter values still take precedence over both the localizer and the defaults

Both samples (BlazorOAuthSample, ServerIntegrationSample) and docs/blazor.md updated to reflect the new copy and document the translation flow.

Implemented in v0.4.0 (commit 4f18c36). `LoginForm` now defaults to the "Atmosphere account" terminology: - Default copy: "Sign in with your Atmosphere account" / "Your Atmosphere account handle — your PDS is detected automatically." - New `HeadingText` / `SubtitleText` parameters for optional heading + subtitle above the form (no default, rendered only when set) - All string parameters now accept `string?` and consult an injected `IStringLocalizer<LoginForm>` when one is registered, falling back to the English defaults — translations work via standard ASP.NET Core localization (`.resx`, JSON, custom factories, etc.) - Explicit parameter values still take precedence over both the localizer and the defaults Both samples (`BlazorOAuthSample`, `ServerIntegrationSample`) and `docs/blazor.md` updated to reflect the new copy and document the translation flow.