Hey @cft!

This looks great, I'm excited to test it out. Do you have any information on what this might do to my feed size? I'm not sure I'd like for all of my followers to have to host my content.

Sounds like an awesome project! Because I'm still a bit of an #ssb newbie, is there any way for someone following you to opt out from "wanting" the files you're putting to your log?

I can imagine if this type of thing gains popularity, people's ~/.ssb dir might unknowingly skyrocket in size if others are pushing versioned blobs to their log.

would somebody from JavaScript land be interested in reviewing the "protocol", eventually leading to a JS version of Drive?

@cft: I'd be interested. Do you have this documented somewhere or should I just read the code?

Lots of kudos for doing shs+muxrpc and ssb on top in the shadows. I had no idea this was going on! This thread regarding testing might be of interest for you as well.

The readme on tangles will be interesting to those who discussed the design of the post-message's branch property: CC @mix @Dominic @cel @keks @andrestaltz @dinosaur

Completely unrelated: @cft, have you by any chance interacted with Uwe Nestmann? I vaguely told him about ssb a year ago, but the group headed into traditional blockchain-country instead. Well, and it is still a theory chair. But it is nice to see a CS prof from the distributed systems/network community here on ssb. It would be a shame if bitcoin and ethereum completely overshadowed all the other interesting stuff happening in the wild right now.

@cft congrats on this implementation.

Nice readme on tangles too. One note:

It is noteworthy that other application in SSB do not use any chaining via tangles or otherwise, except for the inclusion in the creator's personal log.

Some applications do use similar structures, namely git-ssb, ssb-npm and dnssb.

hi @cft, i finally got around to reading the tangle paper in depth.

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.

while not documented well, as far as i understand branch is the same as your ancestors, as in it's only used for tangle-forming. @mix added a fork field (i think for TickTack?) to signal discussion flows, which is similar to your reply field: %+fBXl12.... confusingly, @matt added a reply field for Patchwork which does something different: %5mjm4vF....

For example, about records are used for implementing event-participation where peers declare that they will be attendees: However, based on the available information in the logs, it is not possible to deduce strong happened-before relations among about events i.e. who committed first

yes, while it's probably hidden, there's rough consensus that we should use root and branch (as described in your tangle paper as root and ancestors) for just about every message type: about, vote (like: %zrIKdNx...), etc.

generally, am stoked that you took the time to document this! keen to find a way to incorporate this into the overall Scuttlebutt documentation, as we've independently come to the same conclusions.

you want to check out ssb-sort which has a heads method to see how branch is calculated. Basically looks for the current heads of a causal tree....

the summary of fields I'm using is :

• root : points to the root message in a particular thread
• branch : specifies the heads / most recently seen message(s) in the thread (can be an array if there are parts of the thread which don't know about other parts when they were written
• fork : used to indicate a divergences from the main flow of a thread in 2 ways:
  • "nested reply" : this is for aside comments targeting a specifc message in a thread, so has a root of the thread it's part of and a fork pointing to the "sub-root", the message you're nesting off
  • "hard fork" : this is for signaling that you're creating a different thread but that it came from that original conversation. This is sifnigified by having a fork which points to the prohenitor thread and no root property (because it's a new root for a new fork thread)

awesome work btw !