Add setting to disable direct messages - #147
Conversation
PastaPastaPasta
commented
Jan 18, 2026
- Add allowDirectMessages setting to Zustand store (enabled by default)
- Add toggle in Privacy & Security settings to turn DMs on/off
- Show warning message when DMs are disabled in settings
- Show disabled state on messages page when DMs are turned off
- Link to settings from disabled state to easily re-enable
- Add allowDirectMessages setting to Zustand store (enabled by default) - Add toggle in Privacy & Security settings to turn DMs on/off - Show warning message when DMs are disabled in settings - Show disabled state on messages page when DMs are turned off - Link to settings from disabled state to easily re-enable
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (3)
Comment |
Deploying yappr with
|
| Latest commit: |
afe1db5
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://9e98aa75.yappr.pages.dev |
| Branch Preview URL: | https://claude-disable-dms-setting-b.yappr.pages.dev |
|
🕓 Ready for review — 64 ahead in queue (commit afe1db5) |
thepastaclaw
left a comment
There was a problem hiding this comment.
Preliminary review — Codex only
The toggle persists and renders the disabled state, but it does not enforce the advertised direct-message opt-out. Senders can still create messages for the identity, while the disabled recipient page continues querying and decrypting messages behind the guard.
Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.
Review provenance
- Codex reviewers:
gpt-5.6-sol— general (completed) - Verifier:
gpt-5.6-sol— verifier - Sonnet: not run (deferred by blocker gate)
🔴 2 blocking
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `lib/store.ts`:
- [BLOCKING] lib/store.ts:175-176: The local-only setting cannot prevent other users from sending DMs
The Privacy & Security toggle says “Allow other users to send you direct messages,” but this value exists only in the current browser's persisted `yappr-settings` store. Nothing publishes an identity-scoped preference that another client can query: profile pages still expose the Message action, and `DirectMessageService.sendMessage` creates the recipient's `conversationInvite` and `directMessage` without checking any opt-out. Disabling the toggle therefore has no effect on another user's client, which can continue writing messages for this identity. Store the preference somewhere sender clients can query and enforce it in every send/start-conversation path, or change the feature and its copy to accurately describe a local inbox-access control.
In `app/messages/page.tsx`:
- [BLOCKING] app/messages/page.tsx:544-545: The disabled return occurs after message-loading effects
The disabled-state guard does not stop any hook declared above it. Opening `/messages` with DMs disabled still runs `getConversations`, which queries each conversation's messages and decrypts its latest message. A `startConversation` parameter can also select a conversation and trigger full message loading, read-receipt writes, and polling because those effects do not depend on `allowDirectMessages`; polling already active when the toggle is disabled also remains mounted. This contradicts the page's statement that messages must be enabled to receive them. Gate the conversation, auto-start, message-loading, read-receipt, search, and polling effects on the setting, or mount the messaging implementation only while DMs are enabled.
| allowDirectMessages: true, // Enabled by default | ||
| setAllowDirectMessages: (enabled) => set({ allowDirectMessages: enabled }), |
There was a problem hiding this comment.
🔴 Blocking: The local-only setting cannot prevent other users from sending DMs
The Privacy & Security toggle says “Allow other users to send you direct messages,” but this value exists only in the current browser's persisted yappr-settings store. Nothing publishes an identity-scoped preference that another client can query: profile pages still expose the Message action, and DirectMessageService.sendMessage creates the recipient's conversationInvite and directMessage without checking any opt-out. Disabling the toggle therefore has no effect on another user's client, which can continue writing messages for this identity. Store the preference somewhere sender clients can query and enforce it in every send/start-conversation path, or change the feature and its copy to accurately describe a local inbox-access control.
source: ['codex']
| // Show disabled state when DMs are turned off | ||
| if (!allowDirectMessages) { |
There was a problem hiding this comment.
🔴 Blocking: The disabled return occurs after message-loading effects
The disabled-state guard does not stop any hook declared above it. Opening /messages with DMs disabled still runs getConversations, which queries each conversation's messages and decrypts its latest message. A startConversation parameter can also select a conversation and trigger full message loading, read-receipt writes, and polling because those effects do not depend on allowDirectMessages; polling already active when the toggle is disabled also remains mounted. This contradicts the page's statement that messages must be enabled to receive them. Gate the conversation, auto-start, message-loading, read-receipt, search, and polling effects on the setting, or mount the messaging implementation only while DMs are enabled.
source: ['codex']