Description
In ThreadViewModel.rebuildTree(), blocked notes are filtered out before the parentToChildren map is built:
if (muteRepo?.isBlocked(event.pubkey) == true) continue
Because the note never enters the tree, any replies nested under it are orphaned — including the user's own replies to that note — and disappear from the thread entirely.
iOS counterpart
Fixed in barrydeen/wisp-ios#388 (follow-on to barrydeen/wisp-ios#380). The iOS fix renders a "Post from blocked user" placeholder row and continues the DFS walk into children, so subtrees under a blocked note remain visible.
Fix
Rather than skipping blocked notes pre-build, add them to parentToChildren with an isBlocked flag, render a placeholder in the UI, and continue dfs() into their children — matching the WoT-hidden placeholder behaviour already present in the thread view.
Related
Description
In
ThreadViewModel.rebuildTree(), blocked notes are filtered out before theparentToChildrenmap is built:Because the note never enters the tree, any replies nested under it are orphaned — including the user's own replies to that note — and disappear from the thread entirely.
iOS counterpart
Fixed in barrydeen/wisp-ios#388 (follow-on to barrydeen/wisp-ios#380). The iOS fix renders a "Post from blocked user" placeholder row and continues the DFS walk into children, so subtrees under a blocked note remain visible.
Fix
Rather than skipping blocked notes pre-build, add them to
parentToChildrenwith anisBlockedflag, render a placeholder in the UI, and continuedfs()into their children — matching the WoT-hidden placeholder behaviour already present in the thread view.Related