This might be a good example of what you're talking about.
No one would have any reason to suspect this interesting little chat, that belonged in ~meta, was in a ~Stacker_Sports post, but it would have been nice for more people to have weighted in on it.
Perfect illustration, thanks for providing one. It's fun to imagine how one could display this on some kind of feed, and how its candidacy for such a feed could be determined. First thing that comes to mind is a weighted-subtree thing, e.g., sum up the zaps of the whole subtree, and then show the highest ones; or the subtree up to some depth, or only top-level sub-trees bc the first thing I said is computationally unfeasible...
And then what to show for it? The parent comment? An LLM-summary of the subtree? The parent comment + a summary? Lots of cool things you could pilot. Harder to figure out how to do user influence on top of it, though -- graph embeddings beyond my paygrade, but maybe some simpler way would be 60% as good.
reply
And then what to show for it?
That's tough, because the interesting topic could have started anywhere in the tree. Just showing the parent comment might not give any sense of why that subtree generated so much value.
Even if there are good LLM summaries of the conversation, they will still have to decide where to send users who want to check out the thread.
reply
If there's a high-value embedded comment lower in the subtree, it would hopefully have been zapped appropriately, though, right? And practically speaking, it's not usually that onerous to read a subtree. It's rare for them to cross the "see more replies" boundary, empirically. Or at least, that's my sense.
reply
I think you're probably right. I haven't thought about what kind of metric to look at, but it should be pretty easy to at least get close to where the interesting conversation started.
reply
1656 sats \ 1 reply \ @k00b 14 Jan
top-level sub-trees
This is something we've been planning to do, ie rank sub-tree roots by their sub-tree's zap sum. Posts, being sub-tree roots themselves, could also see their ranking enhanced when they contain a great sub-tree.
We'd do this when writing the zap at a cost log(zap_depth), ie one update for every ancestor.
reply
lol subconscious alerted me to my error on my walk this morning. It's zap_depth not log(zap_depth). Sometimes I wish I were an exacting person.
reply