Repository navigation
fix(federated-identity): name only communities that require NIP-FI as affected by a switch - #3072
Conversation
… affected by a switch The Switch account prompts and Settings' "Used by" listed every joined community under a server's host pattern, including ones that don't require NIP-FI and are reached with the key alone. Native now answers whether a community requires it from the /info discovery it shares with admission, and the UI lists only those (a failed discovery counts). Sign in again no longer names other communities: the refused session is already dead for them too. Co-authored-by: mbot <3754f8729004d95654c46dbab3129e4ab9ef05cc2534e2a3fbfc155983bd637b@buzz.block.builderlab.xyz> Signed-off-by: Bradley Axen <baxen@squareup.com>
…ties outside native Co-authored-by: mbot <3754f8729004d95654c46dbab3129e4ab9ef05cc2534e2a3fbfc155983bd637b@buzz.block.builderlab.xyz> Signed-off-by: Bradley Axen <baxen@squareup.com>
…y says it isn't A Switch account clicked before a community's /info answered skipped its warning. Pending discovery now counts as requiring NIP-FI, like a failed one. Co-authored-by: mbot <3754f8729004d95654c46dbab3129e4ab9ef05cc2534e2a3fbfc155983bd637b@buzz.block.builderlab.xyz> Signed-off-by: Bradley Axen <baxen@squareup.com>
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cd0b4ce60d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| <p className="text-body-sm"> | ||
| {`This also signs you out of: ${others.join(", ")}.`} | ||
| </p> | ||
| {refusal === "access" && ( |
There was a problem hiding this comment.
When refusal === "sign-in" while the session is still signed-in—for example, after the relay returns the mapped evidence rejected refusal—the button below still calls runSwitch(..., "sign-out", ...), so it signs out the shared server session and may change access to every other protected community. Restricting SwitchAffects to access removes the only warning before that cross-community action; render the filtered warning for this signed-in sign-in-refusal branch as well.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
🤖 [P2] Keep the warning for shared-account recovery
evidence rejected maps to sign-in, but the relay verifier also returns it when this community does not authorize the assertion’s issuer. That does not end the issuer session or invalidate other communities. This branch still runs runSwitch(..., "sign-out", ...); can we retain SwitchAffects while still signed in so “Sign in again” warns about interrupting working communities?
Posted by Codex (gpt-6.1-sol) on behalf of kylez
| for (const url of key.split("\n")) | ||
| void identity | ||
| .communityRequiresSignIn(url) |
There was a problem hiding this comment.
When a server covers more than 128 joined communities, opening Organization sign-in starts discovery for every one here. The first 128 successful lookups permanently occupy that server's shared discovery cache, while discovery_generation rejects later entries with Too many discovered communities; because admission uses the same cache, an undiscovered community then cannot connect until the app restarts. Bound or separate these presentation lookups so merely opening Settings cannot disable community admission.
AGENTS.md reference: AGENTS.md:L147-L149
Useful? React with 👍 / 👎.
kazemek21
left a comment
There was a problem hiding this comment.
🤖 Kyle reviewed this PR and the Nexus review-tracker notes. Approving with the non-blocking shared-account recovery feedback above.
Posted by Codex (gpt-6.1-sol) on behalf of kylez
…nt-progress-rows * origin/main: (53 commits) fix(search): make Command F search the Bestie conversation (#3084) fix(plugins): keep failed update checks on the plugin's Settings row instead of a toast (#3088) Show single-agent Stop on the activity bubble (#3140) fix: support explicit hosted browser origins (#3149) fix: keep Codex tool namespace descriptions bounded (#3128) fix(messages): show "New messages" in channels longer than one page (#3071) Keep shared agent guidance generic (#3134) fix(typing): a thread reply also ends the agent's channel-level typing (#3148) Stream protected evidence across agent runtimes (#2882) feat(identity): consolidate key and account controls (#3069) Add portrait-colored foil and animated agent card reveal (#3144) NEXUS-4190: Disclose unavailable saved Solo choices (#2544) docs: mark the plugin API as preview and say which parts are steady (#3129) Open the app with a saved key; check the account's key in the background (#3064) fix(federated-identity): name only communities that require NIP-FI as affected by a switch (#3072) feat(pairing): signed in with Builderlab, say to get the app instead of pairing (#3039) Show Add agent button on shared agent previews (#3131) NEXUS-4224: Preserve peer unread intent during automatic reads (#2641) fix(plugins): review a pinned link to an installed plugin's source as an update (#3024) perf(profiles): resume verified-profile batches after a planned renewal (#2293) ... Signed-off-by: Gil Birman <gil@squareup.com> # Conflicts: # docs/buzz-help.md
Problem
When a community refuses your organization account, the recovery prompts list the other joined communities the switch "also signs you out of". That list came only from the sign-in server's community host pattern. On Builderlab the pattern covers every community under its domain, so it named communities that don't require NIP-FI. Those are reached with the key alone, and the server session makes no difference to them. Settings → Identity → Organization sign-in had the same problem in its "Used by" list.
Change
federated_identity_requires): says whether a community requires NIP-FI. It routes the community to its server withserver_forand reads that server'srequires_federated_identity, so it uses the same cached/infodiscovery as admission (requires_nip_fi, otherwise the capability). It never sends a credential. The command is registered inbuild.rs, the default capability and the browser permission test.FederatedIdentity.communityRequiresSignInis optional and calls that command.coveredCommunitiesis replaced byuseSignInCommunities, which keeps only the host-matched communities that require NIP-FI./infoanswers (up to the 30 s protocol deadline) must not skip it. Communities you're connected to already have cached discovery, so the list rarely shrinks after it appears.sign-inwhile still signed in) no longer names other communities. The refused session is already dead, so they are broken too.SwitchAccountprompt now share one line: "A, B and C also use this account. Switching may change your access there." (singular "uses").docs/buzz-help.md: Settings and Switch account wording updated to describe this. The Refused by a community section was still accurate.Tests
CommunityRefusalNotice.test.tsx: onaccess, a community whose discovery is held is listed until it answers "doesn't require" and is then dropped; one whose discovery failed stays listed. The refusing community and another server's community are never asked about. Onsign-in, no line appears and discovery is never called.IdentitySettings.test.tsx: "Used by" excludes a covered community that doesn't require NIP-FI.CommunitySignIn.test.tsx: existing switch test updated to the new copy.vitest run(1035 files passed) andcargo test --lib browser_permissions federated_identitypass. At cd0b4ce (pending-counts change): the federated-identity and IdentitySettings Vitest files pass, plus typecheck and pre-push hooks.Known limit
Settings → Organization sign-in now runs discovery for every joined community under a server's hosts, not just the ones you've connected to. Successes are cached, but the per-server discovery cache refuses new entries past 128 (
assertion.rs, "Too many discovered communities"). Someone with more than 128 joined communities on one server could fill it from Settings, and admission to a community not yet discovered would then fail. That cap was there before this PR; no code change here.Deferred
canonical_relay,server_forandrequires_federated_identity, which are already covered.