@mixmix I have also wondered if there could be a better name for what the branch property represents. However, I find it makes sense if I think of it as "what is this message branching from" (or branching to, or branching off of). For new message schemas, a different one could be used, like heads, or maybe something based on previous - but I might still use branch, to provide conceptual continuity. So far, when I have been designing schemas, I have taken branch as part of the nomenclature and tried to build on the concept by building on the name for new properties, like how revisionBranch was used in the post-edit schema, in git-ssb I used repoBranch and refsBranch; in ssb-npm, dependencyBranch and versionBranch.

The branch property is useful not just for sorting a thread, but for UIs to show to the user to expose the thread structure and allow for traversing it. If there is another property with the same meaning, such applications have to be changed to handle both. There is no transition to only needing to use the new way, because the existing messages are permanent, and existing clients may continue producing the old way. There are other message types besides post that use have a branch property with the same or similar meaning. There is a plurality of SSB applications producing all these. Part of the value of the network I think is the corpus of message content, the data-lake, so to deprecate large amounts of existing content I would consider a shame. Other concerns should be weighed of course, but in this case it doesn't look to me like breaking compatibility is required. @mixmix where are you seeing new people confused by branch? Could the confusion be addressed another way?

Anyway, kudos for adding backlinks to votes. I've implemented similar functionality now in patchfoo to add root and branch to vote messages, although these links are not displayed outside the raw message view: %PenBUBH....

Aside: If I were designing this I might just link to other vote messages targetting the same target id rather than the target message's thread root. If I upvote something maybe I don't need to reinforce the thread, I might not care about the thread but just the target message. And what about upvoting something that is not a post? Treat it as a thread root or follow its root property, I guess. For an application, if I wanted to show votes for all messages in a thread I probably would still do a query for each reply in a thread, since votes without the thread links would otherwise not show up - but getting the votes for replies in the root backlinks query could help to display some of the votes faster. Also, it's okay if different applications show different sets of upvoters, it's just part of the collective subjectivity.

i.e. if a message author is blocked, then I should decline to include them in my tangle weave.

+1