Some changes to master:

• changed the default layout of messages
  • takes more advantages of horizontal space
  • still needs some more love
• replaced message actions with symbols (like / quote / reply)
• don't show the context 'title' for which thread a message belongs to if you're in the thread. ..

Likes which reinforce causality

I've extending likes to add two new fields. Now looks like this

{
  type: 'vote',
  vote: {
    link: MsgId,
    expression: 'heart',
    value: 1
  },
  root: MsgId,     // << NEW
  branch: [ MsgId, ... ]   // << NEW
}

Why? adding root means you can pull up all post and all likes for a thread with one single query. backlinks means that now anyone liking things in threads is reinforcing the causality of the thread, because you're adding meaningful data about which are the latest messages. There's a certain poetry to likes being of service to further stablised ordering ... mmm

This functionality I've written into scuttle-thread it takes care of the root and branch for you. I'll probably merge this into @andrestaltz' ssb-threads when I learn typescript more.

#ssb-show-and-tell cc @christianbundy I'm starting in on threads helpers if you want to join

TODO (note to self) - need to teach patchcore to respect likes in sorting now ... or re-write how threads are rendered (sigh)

from feed/obs/thread.js

      replies.set(map(computed(backlinks, (msgs) => {
        return sort(msgs.filter(msg => {
          const { type, branch } = msg.value.content
          return type !== 'vote' && !isBlocked(msg, rootMessage) && (root(msg) === rootId || matchAny(branch, rootId))
        }))
      }), x => Value(x), {

@mix re causality: I've finally read into the ssbdrv description of tangles and I encourage you to do the same. In 1.4 it compares and disectes some of the messages we create right now:

However, the rules about how to fill in the branch field are vague, although we recognize some conformance rules ... These SSB rules conflate two purposes: (i) tangle weaving vs (ii) back-referencing old messages. My recommendation is to separate the reply information from the tangle-forming aspect: instead of branch there should be the ancestors field which strictly points to some recent tip nodes, and a separate discussion-specific reply field that points to one or more tangle entries which can be quite old at the time of posting.

and @cft also notes that abouts in gatherings don't have branches.

sorry if this is just %QFjcDFv... all over.. ^^

yeah @cryptix I've got my head around this. I think that write up is beautiful and the visualisation is the clearest representation I've seen of this causal ordering. I'm in total agreement.
branch is not a very clear name, personally I would prefer head or heads. Specifically it's often confusing for new people because it sounds like fork. Actually given how ssb-sort works and how there are currently know schema (that I know of) in active use for post messages maybe we should just change branch to heads or tips - @cel / @matt do you have an objection?

The one new piece of info I loved in that thread was the suggestion of being discriminatory about what we include in the branch / tips calculation. I've implemented all of those things suggested already (see here - I'm of the opinion devs should not be trusted to hand code this field and it needs to be a lib), but the one I hadn't considered was :

Is the peer having produced and signed the PTN node trustworthy? (a blocked peer's PTN will not be visible, automatically)

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

I think I actually really like the idea of calling it a 'tangle'. It's related to another project, but it's really evocative, and taps into the idea of weaving a story together more than branch or heads or anything else...

hey @alanz thanks for noticing the regression. Have fixed that and pushing it up shortly.

yeah multiple emotes would be cool. Do you want to have a go building it? I'd be happy to support you if it's helpful

hey we're all learning here @alanz!

My time is also really limited. Someone has to design a thing for it to be built. If you want to draw anything on a napkin, it will be a step forward. My imagining of the requirements would be :

• we can't have a button for every emote, so some way to hide the details
• we can see which emotes have happened

wait if this features exists elsewhere and the design feels good, can you screenshot it and bring it here?

cool, I like the idea of being able to set a palette @alanz. we could put that in the /settings page.

do you think the expressions should be 1:1 with emoji code like broken_heart shows ?

from a style perspective it would be nice to have access to emoji for this "emote" area which are a lot more flat and less eye-catching than the normal inline ones. I wonder if that's possible / wise

@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

@mix

Using this now, I love the new like icons! Really excited to check out what you've started with scuttle-thread. Currently in holiday-weekend limbo in the US so I've been offline a lot this week, but I'm looking forward to collaborating on this. Are there any big todos I should be aware of before I take a look?

whenever I've tried describing the property of branch to anyone in person it's been hard. I think it's a beautiful idea. I think ancestors or heads would make for much easier story-telling. I've incorporated branch into my head so it's not a big deal for me. I'm not suggested dropping support for those messages @cel, I just know how ssb-sort works, and I know it doesn't know a field called branch exists, it just scrapes all refs out (all refs which are values I think...). I've thought about the ability to display the branching nature of threads and really want to do that. Have you figured out how to do it yet? The first thing on my mind is to build a graph of the thread based on branches.

Perhaps the confusing could be mitigated if we adopt the story of the tangle and then a branch as in a part ... mmm no. The problem with branch (that I have) is it sounds like a verb. As in you're declaring you're branching off, whereas you're declaring which branches were before you. echhh. It's just clumsy for me to talk about.

Where's your implementation of branch + root for votes? Did you use my work or make a variant? It would be cool to consolidate this sort of logic in one place I reckon. Maybe a generalised module for these tangle / thread type things. Re: visualising it, the only influence I really want is to make the causal sorting more consistent. Likes happen at a similar frequency to posts perhaps, so I imagine it will actually linearise a lot of previoously branching graphs....

@christianbundy no pre-work required. Just get in touch when you want to jam (otherwise I'll be chipping away on it on my own / with andre). I did start this thread, but can discuss that later %iietnaH...

My recommendation is to separate the reply information from the tangle-forming aspect: instead of branch there should be the ancestors field which strictly points to some recent tip nodes, and a separate discussion-specific reply field that points to one or more tangle entries which can be quite old at the time of posting.

@cft that's what we have! root is the reply field, and branch is ancestors. We originally used the names root and branch because I wanted generic terms usable for any message types. It's been a somewhat hard fight getting app developers to include branch. No one is confused by "root". At the time I argued we should have consistent metaphores, and trees have roots and branches, and this persuaded @paul.

gatherings really should have branch, as I pointed out previously

gatherings really should have branch, as I pointed out previously

@dominic they do, see https://github.com/ssbc/scuttle-gathering/blob/master/update/async/build.js#L36 (at least if you're using scuttle-gathering, but Matt isn't yet to my knowledge)

@mixmix
Currently I'm rendering messages with the root and branch links displayed. So in this one we can see your reply branched to my message and to @christianbundy's:

These links allows for navigating through threads. Downsides are that when a page renders a full thread, these branch links become somewhat inefficient of screen space to show because they show the titles or messages that are already displayed fully on the page. Also there isn't a great way to set them when composing. I'm considering showing branch links with single character/icons, at least for votes and other messages that are rendered on a single line:

For rendering a thread I think building a graph makes sense. I'm imagining it like git log --graph where the page has a column on the left for the graph, each post has a dot within that column, and lines or paths connect the dots according to the branch links. That could allow for showing thread structure with less vertical screen space usage. But I haven't yet dedicated myself to learning/implementing that algorithm for graph drawing.

My implementation of branch + root for votes is in patchfoo commit 544a8927a47bc0e4cc2f925b0dd248668701c906 via %PenBUBH.... I referred to your work in patchbay and scuttle-thread but am not using that code. I am also using ssb-sort's heads function but calculate the set of messages a little differently, allowing for a few types of messages that link to a thread with a property other than root (i.e. types talenet-idea-comment_reply and web-root). Also, I'm assigning the branch property based on what messages are visible on the page from which the message is composed, although this might not be ideal.

I think I get now more what you meant by reinforcing the thread structure. Currently Patchwork sets only one value for the branch property, and Manyverse doesn't set any. Patchbay and patchfoo users make up for this when they reply and link to the thread heads that should have been referenced already but weren't. Now they can do so with vote messages as well, which can help us capture more causal order.

I was also thinking about git visualisations (because how many other examples do we have of branching and weaving so clearly!)

Are you sure patchwork only sets one value ? oh ... I just went and looked and it doesn't look like it does. @matt what's going on with that? I feel pretty strongy about root + branch. Can we all agree to the same behaviour?

I'm working towards a fix for Manyverse - I need to merge my work in scuttle-thread with ssb-threads, and then Andre will have easy access to it.

@mix

Are you sure patchwork only sets one value ? oh ... I just went and looked and it doesn't look like it does. @matt what's going on with that? I feel pretty strongy about root + branch. Can we all agree to the same behaviour?

Patchwork currently uses:

var sort = require('ssb-sort')

value.root = rootId
value.branch = sort.heads(messages)

oh cool. where is that exactly @matt I was looking at :
https://github.com/ssbc/patchwork/blob/master/modules/feed/obs/thread.js#L91-L93

which I think is used by the compose as part of the meta field...

@mix Yeah, sorry the code is a total mess, and I am in fact rewriting this as we speak!

The confusion comes from the fact that branchId (the code you link above) is only used if the user is replying directly to another reply. However if they post to a thread, then it uses lastId which is some variant of sort.heads(messages) (a little bit different to what I posted in my last message, but mostly does the same thing).

The code that decides which of these to use is: https://github.com/ssbc/patchwork/blob/907d2463faaf15f1664ca8d42159eb6c6924e2de/modules/page/html/render/message.js#L121

Anyway, this is all about to change. Do you have any tasty modules to share?

yeah I recommend you look at staltz's ssb-threads. I've got branch logic in scuttle-threads but I plan to move this upstream into ssb-thread for better performance and to consolidate methods in one place.

The code you linked @matt is using the branch field to do nested or direct replies. I want to strongly request that you don't conflate history building with replies. They are sometimes correlated but not always. If you're not sure what I mean I really want to talk to you. If you disagree, that's cool too, but I want to talk so we aren't building shit that fucks each others stuff up

@mix

staltz's ssb-threads seems more like rollup stuff to me, which works quite different in patchwork. Is there more to it that I'm not seeing? Are you using it for rendering message view in patchbay?

The code you linked @matt is using the branch field to do nested or direct replies. I want to strongly request that you don't conflate history building with replies. They are sometimes correlated but not always.

Okay I think we need to talk about this. Free for a chat now?

@mix Think I'm starting to get my head around this. I guess I need to completely rethink direct message replies in patchwork, and remove the sub thread message view (just redirect to the post in the root thread).

i'm not using ssb-threads yet but I want to builda module which collects all the thread-related goodness so people can' build threads easily, and don't foot-gun themselves or others.

yeah free to chat. just call me directly in the future @matt

Every other app on my computer can display emoji properly, except LibreOffice, so I assume Electron is just a bit crap

Could you explain this a bit further? I think as long as you have the fonts installed then Electron should show them correctly. Alternatively, there are emojis like :heart:, but currently I think the clients are rendering those with images rather than your system's emoji typeface. We could disable this, but I think it would cause problems for people without an emoji font installed. Maybe it should be an option in the settings?

re: %2w1H+Vo...

My mistake @Matt, I misread that code.

[correction to %GJkhDgP...]