Skip to content

feat(desktop): pin open threads in a persistent switchable rail #4266

Open

Description

@EmpireOperating

Problem

Deeply nested work threads are hard to follow while moving between channels. Opening another thread replaces the current thread panel, so active conversations cannot be kept close at hand.

Proposal

Add a desktop Thread Rail to the standard Buzz UI:

  • Keep the existing inline thread opening behavior.
  • Add a Pin to thread rail action to an open thread.
  • Show pinned threads in a compact rail beside the main content.
  • Switch directly between pinned threads, including threads in different channels.
  • Close/unpin a thread without deleting or altering the underlying conversation.
  • Persist the rail locally per identity/community across reloads.
  • Keep canonical Nostr thread identity unchanged: the rail is another view over the same channel + root event, and replies retain the existing root/reply tags.

MVP acceptance criteria

  1. Pinning is idempotent and stores one entry per (community, channel, thread root).
  2. Clicking a rail entry navigates to that channel and opens the canonical root in the existing thread panel.
  3. Active entries are visually distinguished.
  4. Unpinning removes only the rail entry.
  5. Reload restores valid pinned entries without crashing on malformed/unavailable local storage.
  6. Standard inline thread behavior and reply tagging remain unchanged.
  7. Narrow/mobile layouts do not regress; the first slice may hide the desktop rail below the existing two-pane breakpoint.

Related work

PR #3459 has developer-mode split side chats and channel pins, but this proposal is for the standard desktop UI and reuses the existing MessageThreadPanel/channel route rather than introducing a separate conversation model.

This issue was developed from a live Buzz workspace discussion.

Activity

  1. Shivang9983 commented on Aug 2, 2026

    @Shivang9983

    Hi @EmpireOperating 👋

    I would love to work on this! I've reviewed the proposal and MVP acceptance criteria for the persistent Thread Rail component. I can implement the pinning, local storage persistence per identity/community, and navigation switching while ensuring mobile layouts remain unaffected.

    Could you please assign this issue to me?

  2. EmpireOperating commented on Aug 2, 2026

    @EmpireOperating
    Author

    Thanks for offering! An implementation is already underway, so please hold off on starting a parallel implementation for now. Once the PR is ready, help with review and testing—particularly persistence, cross-channel switching, and layout behavior—would be very welcome. I’ll update this issue when it’s ready.

  3. kalensr commented on Aug 17, 2026

    @kalensr

    I would find pinned threads very valuable. I use threads to manage distinct, ongoing workstreams, and need to return to selected conversations over days or weeks without searching through a busy channel.
    A personal, persistent thread rail, with easy pin/unpin and quick switching, would make Buzz much more practical for sustained research, planning, and agent-assisted work. I’m happy to test it and provide feedback.

  4. kalensr commented on Aug 17, 2026

    @kalensr

    Looks like there hasn’t been much movement on this, unless this has been moved to another issue, etc. Any new updates this feature?

    Appreciate everyone’s great work on Buzz! I’m getting serious in utilizing this tool. I’m expecting this to my Grok Bot, killer/competirot/alternative! :-)

  5. EmpireOperating commented on Aug 19, 2026

    @EmpireOperating
    Author

    Hi @Shivang9983 and @kalensr — thank you again for offering to help test this.

    A desktop tester-preview PR for the persistent Thread Rail is ready here: #6350

    It is intentionally marked draft while we collect feedback; it does not close this issue.

    The rail is personal and local to the active identity/community. It supports pin/unpin, persistence across restart, cross-channel switching, nested return anchors, expanded-branch restoration, local titles, collapse/expand, and unread indicators. Mobile layouts are unchanged.

    We would especially value feedback on:

    • pinning several ongoing threads and switching between them;
    • returning to a nested reply after changing channels;
    • restart persistence and identity/community isolation;
    • unread dots after a new reply in a pinned thread;
    • ensuring no stale Replying to… or Jump to latest state carries over from the previously open thread.

    Please use non-sensitive test data and include your OS/build details, exact repro steps, and a screenshot or short recording for any issue. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions