You are reading content from Scuttlebutt
@mix %zrIKdNxzueywWr4QbFhnVLn2lntu/IIOnv17tU6SSek=.sha256

Feature: have likes reinforce causal order

I've had my head in ssb-sort this week getting into causal sorting - basically the idea that you can determine the order things happened based on the things that are referenced in the past.

Background for beginners

post messages (often) includes a branch property which helps determind causaul order - it tells you the most recent messages a user knows about.

The trivial case is a chain of messages where each person posting knew about the message that had happened before. Here A posts first, then B is a reply to A, etc.
In this case branch just points to the previous message.

  A
  |
  B     branch: [A]
  |
  C     branch: [B]

But in a decentralised network it's possible for people to have posted at the same time, and to not have each others context - B and C could have happened at the same time, or at different times but not have known about each others posts yet:

   A
  / \
 B   C    both record branch: [A]

This has important implications for a conversation. C could read totally differently given that it's missing the context of B.

   A
  / \
 B   C 
  \ / 
   D      branch: [B, C]

here another person posts, and they can see that some divergence happened, and they declare that they are speaking to the context thtat includes B and C both as the most recent messages they know about.

If a person can see D, then they also can follow a the graph and know they have all the posts above this (unless there was another branch off the side). Anyway, you can know the context within which they were speaking, and you can assert things about the order in which things were said.

I opened a PR which is going to help make this (missing context) visible in the UI - https://github.com/ssbc/ssb-sort/pull/1 - which I'm super excited about

Likes as causal scaffolding

What if likes also had the branch property?

This would provide even more data about who had seen what in a thread, and when. It could provide more certainty about order, AND be a group signing of that order which would make it super resilient.

This could be overkill, could be that I'm just attracted to the poetry of likes actually doing something functional to the conversation.

Technically it would mean that likes would have to be changed a bit (e.g. maybe include the root of the thread in the like for better lookups D:)

User has not chosen to be hosted publicly
User has chosen not to be hosted publicly
User has not chosen to be hosted publicly
@Anders %wRF/lb55DlohC4pqGxe480x+Sd4HfcecZ3uMzR9Jgf4=.sha256

Yeah adding more structure to likes would be a good idea I think.

@Dominic %LQi5nmXmUpaj7D1uA7QMJNrBq7mH237sBEWRB9kMX4s=.sha256

I've also been thinking about this. @keks expresses my thoughts on it well. If likes have branch and root, should they become part of the thread? Would additional replies branch to both posts or likes?

If likes had root, this would also mean a whole thread (including all context) could be loaded in a single roundtrip. I think this would have some positive performance implications!

@andrestaltz %LEBxH/WSamm5LZRsee+6CqDd0NY7KEItIJ5bUcWTu7I=.sha256

I just thought about this a few hours ago. The way I'm rewriting ssb-threads for now ignores likes because it's inconvenient that they're not part of the thread, it would simplify if likes had root, and also avoiding more lookups.

@mix %dqtbqOP32rTdtNQtdSXggXS6Zo+DPGWeVFIp2LUqI40=.sha256

cool, seems like there's some support for this idea.

hey @andrestaltz interested to compare notes on what you're building with ssb-threads and what you hope for it (I've not looked at it yet).

>>> FORK :fork_and_knife:

Join Scuttlebutt now