Update DM one-pager with simplified design

[yewreeka]

Replace intent/accept flow with per-convo "Allow DMs" toggle (off/everyone/select members). Removes green circle UI, adds silent filtering so senders never know if they're approved. Ephemeral context shows origin conversation. Inline member picker for select members management.

Updated Notion doc and local one-pager with new flow.

Note

Add planning document for private DMs initiated from group conversations

Adds dm-from-group.md, a design document covering the UX flow, XMTP content types, consent logic, identity creation, and conversation lifecycle for private DMs started from group chats.

^{Macroscope summarized 61975d4.}

[macroscopeapp]

Add DM one-pager to document the simplified design for private DMs from group conversations in dm-from-group.md

Add a planning doc covering user flows, consent logic, XMTP DMRequest content type, conversation creation, locking, FAQs, decisions, and open questions in dm-from-group.md.

📍Where to Start

Start with the planning overview in dm-from-group.md.

---

Macroscope summarized ab97797.

[claude]

Claude finished @yewreeka's task —— View job

---

PR Review: DM One-Pager Design

I've reviewed the DM design document against the existing codebase architecture, XMTP patterns, and security considerations. Overall, this is a well-thought-out design that integrates cleanly with existing infrastructure. Below are my findings organized by category.

---

✅ Strengths

1. Excellent infrastructure reuse

• Leverages existing ProfileUpdate/ProfileSnapshot messages with metadata map (lines 86-103) - no proto changes needed
• Reuses the 1:1 back channel pattern from ConvosInvites (lines 42, 110-122)
• Builds on proven content type pattern (convos.org/convo_request mirrors convos.org/join_request)

2. Strong privacy design

• Silent filtering (lines 55, 248) prevents social graph leakage
• Select members list stored via self-addressed messages (lines 137-142) - encrypted by XMTP, never shared
• Fresh identities for DMs (line 17) prevent linking group and DM personas
• Ephemeral context via disappearing messages (lines 42, 251-252)

3. Clear consent model

• Per-conversation allows_dms flag with three states (lines 25-30)
• Auto-approval vs. select members logic is simple and verifiable (lines 46-54)
• Sender never knows if they're approved (line 249)

---

🔍 Technical Concerns

1. Missing proto definition for convo_request content type ⚠️
Location: Lines 110-122
Issue: The document describes convo_request message structure but doesn't specify if this is JSON (like JoinRequest in ConvosInvites) or protobuf.

Recommendation:

• Define the codec type explicitly (suggest JSON for consistency with JoinRequestCodec.swift:11-24)
• Specify exact field names and types:

  struct ConvoRequestContent: Codable {
      let newInboxId: String        // Fresh inbox for DM
      let convoTag: String           // Random correlation ID
      let originConversationId: String
      let inviteSlug: String?        // Present for group spinoffs
      let expiresAt: Int64?          // Unix timestamp
  }

• Clarify expiration mechanism: Is the message itself ephemeral (XMTP layer), or is expiresAt a field in the content?

---

2. Conversation locking mechanism not specified ⚠️
Location: Lines 134, 153-159
Issue: "Locks the conversation (no additional members allowed)" but XMTP MLS group permissions aren't detailed.

Questions:

• Which specific XMTP group permission bits are set?
• Is this enforced at the XMTP protocol level or client-side validation?
• What happens if someone tries to modify permissions via a different client?

Recommendation:

• Document exact XMTP API calls (e.g., group.updatePermissionPolicy(...))
• Consider adding a locked flag in conversation metadata as defense-in-depth

---

3. DM tag storage unclear ⚠️
Location: Line 133
Issue: "Sets the DM tag in conversation metadata" but doesn't specify where.

Options:

1. ConversationCustomMetadata proto (already has tag field at line 16 of conversation_custom_metadata.proto)
2. GRDB DBConversation table column
3. In-memory only

Recommendation:

• Clarify if the tag field in ConversationCustomMetadata (line 16) is being repurposed for this
• If so, rename it to convoTag or document dual use
• Specify retention: does this persist after the DM request expires?

---

4. Select members list sync race condition ⚠️
Location: Lines 137-142
Issue: "On new device or reinstall, read the latest per conversation" assumes messages are ordered, but XMTP delivery isn't guaranteed to be sequential.

Scenario:

1. User updates select list on Device A → sends message M1
2. User updates again on Device A → sends message M2
3. Device B comes online, receives M2 before M1
4. Device B applies M2, then M1 (out of order) → wrong state

Recommendation:

• Add a version number or timestamp to each select members message
• Client logic: always apply the message with the highest version/timestamp
• Consider using XMTP conversation metadata instead (if available for 1:1 channels)

---

5. Origin context display might leak metadata 🔒
Location: Lines 61-63
Issue: "The origin conversation's image may also be shown alongside the convo name" could leak group membership if someone screenshots the DM.

Example:

• Alice and Bob meet in "Secret Project X" group
• Bob DMs Alice, sees "Alice from Secret Project X" with group avatar
• Bob takes screenshot and shares it
• Now group existence/membership is visible to third parties

Recommendation:

• Make origin image display opt-in per conversation (same setting as includeInfoInPublicPreview)
• Consider showing text only by default: "[display name] from [convo name]"
• Add a note in the design about screenshot risks

---

6. Stale allows_dms flag after member leaves ⚠️
Location: Lines 86-103
Issue: If Bob leaves a group, his DBMemberProfile.metadata["allows_dms"] remains in the database.

Scenario:

1. Bob enables DMs in Group A
2. Bob leaves Group A
3. Alice opens Group A, still sees Bob's profile with DMs enabled
4. Alice tries to DM Bob → what happens?

Recommendation:

• Clarify expected behavior: Should the UI hide DM button for ex-members?
• Clean up member profiles on leave events?
• Add validation in DM request processing: verify sender is still a group member

---

📋 Design Completeness

Missing specification: DM request validation flow
Location: Lines 46-54
What's described: High-level "verifies request is from someone you share a group with"
What's missing:

1. How does receiver's client determine shared groups?
   • Query local GRDB for conversations containing sender's original inbox ID?
   • XMTP API call?
2. What if sender left the group between sending request and receiver processing it?
3. Rate limiting: Can Bob spam Alice with 100 DM requests from the same group?

Recommendation: Add a "DM Request Validation" section covering edge cases.

---

Missing: Multi-device coordination
Location: Throughout
Issue: Design assumes single-device or perfect sync, but XMTP clients can run on multiple devices.

Questions:

1. If Alice approves Bob's DM on Device 1, does Device 2 auto-approve?
   • Consent state is per-installation in XMTP (lines 51-53)
2. If Alice updates select members list on Device 1, how long until Device 2 sees it?
   • Self-addressed messages (lines 137-142) require Device 2 to be online

Recommendation:

• Add "Multi-Device Behavior" section
• Consider using XMTP consent proofs if they propagate across installations

---

Group spinoffs: Invite acceptance UX unclear
Location: Lines 183-184
Issue: "The sender sees the conversation view as they would when creating any new conversation (no pending member indicators)."

Question: How does the sender know if recipients actually joined vs. ignored the invite?

Recommendation:

• Clarify that sender sees an empty conversation until first recipient sends a message
• Consider adding a "waiting for members..." indicator if zero members have joined after N minutes

---

🛡️ Security Considerations

1. Invite slug reuse attack (Group Spinoffs)
Location: Lines 178-182
Issue: Sender generates one invite slug and sends it to multiple recipients via back channel.

Attack:

• Bob invites Alice and Carol to a spinoff
• Alice accepts, gets the invite slug from her back channel message
• Alice could share that slug with Dave (who wasn't invited)
• Dave joins the group

Mitigation: Spinoff invites should be single-use OR tied to specific inbox IDs. Not clear if XMTP invite system supports this.

Recommendation:

• Verify XMTP invite semantics: Can an invite be restricted to specific inbox IDs?
• If not, note this as a known limitation

---

2. DM request replay attack
Location: Lines 110-122
Issue: convo_request messages are disappearing, but what prevents Bob from re-sending the same request?

Scenario:

1. Bob sends DM request to Alice (convo tag abc123)
2. Message expires after 7 days
3. Bob re-sends identical message with same convoTag
4. Does Alice's client create a second DM conversation?

Recommendation:

• Use a random UUID for convoTag (good)
• Client should deduplicate: If a DM with this convoTag already exists, ignore the request
• Store processed convoTag values to prevent replays

---

3. Sender can correlate DM to group via timing
Location: Lines 17-19 (fresh identities)
Issue: Even with fresh inbox IDs, timing metadata can leak the connection.

Attack:

• Bob sends DM request to Alice in Group A at 10:00:00 AM
• Bob sees a new conversation appear in his list at 10:00:05 AM
• Bob knows that conversation is with Alice from Group A (no other DMs sent around that time)

This is probably acceptable (sender initiated the DM, so they know who it's with), but worth noting.

---

🎨 UX/Clarity Suggestions

1. "From select members" is ambiguous
Location: Line 29
Issue: Users might confuse "select members" with "I select which members I allow" vs. "only select members can DM me."

Recommendation: Change to "From specific members" or "Custom allow list"

---

2. Expiration duration needs user testing
Location: Lines 266-270
Issue: 7 days vs. 24 hours is a significant UX difference.

Consideration:

• 7 days: Better for async communication (recipient checks app weekly)
• 24 hours: More ephemeral, less context lingering
• What if someone archives their DMs? Context might still be useful months later.

Recommendation: Consider making expiration configurable per-conversation (e.g., match group's explode timer?)

---

3. "Send DM" button placement
Location: Lines 36-40
Issue: Long-press avatar vs. profile tap are inconsistent entry points.

Recommendation:

• Standardize on one primary entry point
• Make it discoverable (first-time user education?)

---

📝 Documentation Gaps

1. Error handling: What happens if DM creation fails (XMTP network error, quota exceeded, etc.)?
2. Notifications: Do DM requests trigger push notifications? (Probably not, since they're auto-processed)
3. Analytics/telemetry: Should DM creation be instrumented for privacy-preserving metrics?
4. Migration: If an old client (pre-DM feature) receives a convo_request, what happens? (Probably ignored, but worth stating)

---

🚀 Overall Assessment

Quality: High. This design integrates well with existing architecture and shows strong privacy consciousness.

Readiness: Needs clarification on ~6 technical details before implementation (see bolded items above).

Recommendation: Approve with revisions. Address the proto definition, locking mechanism, and validation flow before cutting code.

---

Next Steps

1. Define ConvoRequestContent codec (JSON vs. protobuf, exact fields)
2. Specify XMTP group locking API calls
3. Add DM request validation section (deduplication, rate limiting, stale member checks)
4. Consider multi-device sync implications for select members list
5. Verify invite slug security for group spinoffs

---

[macroscopeapp]

Approvability

Verdict: Approved

This PR adds only a markdown documentation file (design one-pager for DMs) with no code changes. Documentation-only changes have no runtime impact and are safe to merge.

^{You can customize Macroscope's approvability policy. Learn more.}

Dismissing prior approval to re-evaluate f8702b6

Dismissing prior approval to re-evaluate 61975d4