Repository navigation
Conversation
A read for one channel that met the relay's community-wide NIP-FI
refusal ("auth-required: authentication required") ran the per-channel
denial, which removes that channel's saved copy from disk. A refused
first channel-directory read cleared the whole saved cache the same way.
The relay service already owns community refusals and keeps saved data
when only the sign-in ended, so these paths lost what it meant to keep.
Per-channel and directory denial now leave community-wide refusals
(sign-in or access) to the relay service. A refusal of one channel
still forgets that channel.
Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>
Signed-off-by: Logan Johnson <loganj@squareup.com>
Leaving a community refusal to the relay service skipped the whole per-channel denial, including the in-memory part. A refused page read then left its window loading with no read pending, and rows already on screen stayed visible until the service's deny arrived (or forever, if it never did). A community refusal now ends the window's reads and shows the refusal with no rows, the same as a channel denial. It still keeps the channel's access, list entry and saved copy for the relay service to decide on. Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz> Signed-off-by: Logan Johnson <loganj@squareup.com>
… heads The community owner (the relay service) heard a native refusal only through the window's relay-refusal event. If that listener failed to install, a channel refused for the whole community kept its cached head, preview and other session views until a deny that never came. Now every native response that carries the relay's community refusal also reports it to that community's observers, as the browser build's broker already does. The service takes the first report, so the event and the response reporting the same refusal change nothing. A community refusal of a channel read also drops that channel's in-memory head and tail, so revisiting the channel or reading its sidebar preview cannot bring the refused rows back before the service ends the session. The saved copy on disk is still left to the service. Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz> Signed-off-by: Logan Johnson <loganj@squareup.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖
Summary
Details
denyChannelinsrc/features/relay/store.tstreats a recognized community refusal (fromrefusalOfError) as in-memory only: it drops the channel's cached head and preview and closes the window (aborts reads, clears rows, shows the error), but keeps the channel's access, list entry and saved copy. The old window-closing code moved intocloseWindow, which both paths share.nativeRelayRequestinsrc/features/relay/native.ts), as the browser build's broker already does. Before, the relay service heard it only through a window event, so if that event listener failed to install, nothing ended the session. Reporting the same refusal twice is harmless: the service acts on the first.deny(src/features/relay/service.ts) still decides what to clear: it keeps saved data for an ended sign-in and clears it when access is removed.revocation.test.tscover the visible window state and the disk calls for a refused revalidation, a refused first read, revisiting a refused channel, a single-channel session read, the directory read, and a refusal of one channel.native.test.tscovers response-path reporting for the sign-in, access and membership refusals, and none for an ordinary 403.🤖 Generated with Claude Code