1. 36

  2. 5

    I wonder what the author thinks of radicle, seems to hit a similar niche and has code to show. Though it’s based on ipfs not ssb.

    Previous discussions: https://lobste.rs/s/mdtmek/radicle_architecture http://www.radicle.xyz/

    1. 4

      Apart from crypto parts fossil already handles distribution of all project related communications quite well.

      1. 3

        I’ve tried SSB before - the frontends are hit and miss and the mobile app, Manyverse, is an unresponsive buggy handwarmer most of the time. It’s the same problems as decentralized tech we’ve seen so far (log sizes, processing power, chattiness and thus power consumption) and no one is addressing any of them, instead being content that it works…? I don’t get how it’ll get to a mass usable state. Mind you, lots of people like how underground it is, but it makes you think how much of what made the Web a success was the commercial aspect most neckbeards think killed it :(

        1. 2

          Last time I ‘tried’ SSB, it was x86 only, the main implementation depended on a single specific version of node, and the implementations in other languages which I looked at were incomplete because they weren’t able to tell whether an odd quirk of said node version was a bug or part of the protocol.

          1. 1

            I agree with the usability issues. My main gripe is the amount of data SSB uses. Manyverse will happily use a gigabyte of your precious mobile data bootstrapping itself without warning you that it’s going to.

            The other problem is the level of complexity. SSB really doesn’t do anything that Usenet News-over-UUCP didn’t do, other than having digital signatures on every message, but it’s built on top of an append-only cryptographic log, implemented in node.js, exchanging messages in JSON, and because of the complexity there are very few independent implementations. I’m really not sure it needs to be this way.

            1. 1

              I think the complexity is inherent if you want to have a decentralized system in which impersonation is impossible. Not sure about other languages, but the core components of SSB are libraries that are easy to incorporate into your own nodejs projects. I just wish some I could see more progress on the usability and data consumption front.

          2. 1

            I think this vision can and should be divided into several sub-problems that can then be solved independently and in several ways.

            1. How to represent project data: The author suggests a new protocol using signature chains and point out how they are very similar in concept to git. I suggest they shouldn’t be just similar, but that the protocol to represent project data should be implemented in terms of actual git concepts. Such a protocol could for example make use of special rules for branch names, filenames, commit history structure etc to represent project data. Another thought is that it could be represented as a standardized directory structure with special merge rules, so that it becomes independent from the version control system.

            2. How to distribute project data: The author suggests SSB. Even if this could work out, trying to push a standard that is incompatible with existing workflows would probably not succeed very widely. Yes, web bridges are possible, but unless and until such bridges are implemented the use of the protocol would be proportionally hampered. I suggest using existing infrastructure and workflows albeit for new purposes, e.g. opening an issue using a pull request. If the project data is encoded in git concepts, then anything able to distribute git data can also distribute project data. This already includes git..b, http etc. With no change whatsoever, these protocols and platforms would already be compatible. Adding SSB to achieve some proposed higher level of decentralization would be a separate issue that could succeed or fail independently.

            3. How to authenticate project data: The author suggests developer signature chains, while I have suggested implementing something like signature chains using git concepts. A signature chain could be implemented as a git branch with signed commits, but authentication of project data could be provided in one of several ways. For example, github could be used as a web bridge if someone is authorized to authenticate data added by *@github users.

            What do you think, would this be viable and desirable?

            1. 0

              The idea is extremely interesting and I do feel the author’s pain.

              After trying out all available git workflows (PR, e-mail submission) I did come to a conclusion that neither of them have all benefits. For example Github PRs or Gitlab MRs are inherently centralized while e-mail is basically unstructured. While it is possible to bring some structure to e-mails via extensive tooling (basically what sr.ht does) it still is a “product” not a “standard” that one can build upon.

              I do see the same problem but I’m not certain that SSB is “the” solution. It definitely is far more complex solution than simple protocols such as e-mail and I’m not certain what are the benefits of “immutable activity record choosing how much to share publicly, how much to share with specific individuals”.

              Why not something based on HTTPS with simple semantics, so that forges can implement and/or provide the same API used by humans and tooling? With resources based on URIs so that entries can be cached locally (basically replicating “offline e-mail” workflow) but with standardized way of working with basic things, such as tracking multiple versions of the same patch.

              git appraise also seems to be relevant here as it provides a way to review git changes using git objects as a storage medium.