1. 79
  1. 5

    The Radicle IPFS daemon is the process that runs an IPFS daemon, bootstrapping to our own separate Radicle IPFS network.

    I know next to nothing about IPFS so this is a genuine question: why is the Radicle network separate from the main IPFS network? Does this mean that if I want to use both IPFS and Radicle then I need two daemons?

    1. 6

      For you second question: yes - they run independently of each other.

      They are separated as we don’t replicate general files, you can’t really make use of them without being in the context of radicle. A better way is to think of ipfs as the technology we picked for replication and not the ipfs network which one partakes when starting the default ipfs daemon.

      1. 3

        The main reason is that currently IPNS name resolutions take a much longer time in a larger network. It seems like we’ll soon have fixes for that, so in theory we could move back to using the main network.

        1. 2

          But can’t you use IPFS proper, while just ignoring IPNS for now? I thought the latter is just an extra layer over the former?

          1. 3

            We use both - IPFS for storing the data, and IPNS to point to the head of the list/log of expressions to a machine. Thus, when you update a machine (e.g., add a new issue), you’re adding an item to IPFS that has the new data plus a pointer to the old data, and updating the IPNS to point to that. When someone reads, they resolve the IPNS, and then read the corresponding data.

            In theory we could implement such a pointer system ourselves, or use something other than IPNS. But it seems like improvements to IPNS are happening faster than we could come up with an alternative, so we settled on IPNS.

            1. 1

              Ah, so you’re using a separate IPFS network because the normal one is too big for IPNS now, and yours is still at an early stage, thus small enough that IPNS is fast enough? If yes, then please do move to normal IPFS as soon as you find that the improvements make it feasible. And, for the sake of future generations, please don’t use an “It’s too late” argument to avoid such a move. It won’t be.

      2. 4

        Very interesting, and written in Haskell. I’ll have to try it out. If it works well… Kudos to someone actually managing to make a program that interfaces effectively with ipfs.

        1. 3

          Looks very interesting! I’m just reading about their Lisp-like ‘utility language’ (sounds reminiscent of Ethereum…)

          I self-host my git repos (and use Artemis for issue tracking inside the repos), and have been pushing them (unpacked), along with git2html pages, to IPFS with IPNS names for a while. Unfortunately I find the main Go IPFS implementation to be too resource-intensive to keep running at the moment :(

          1. 10

            Unfortunately I find the main Go IPFS implementation to be too resource-intensive to keep running at the moment :(

            We are using our own Haskell library for hosting on IPFS, would be curious to know if it works better than the Go one. They should be compatible.

          2. 3

            Oh! I really like this. I just did the tutorial and I had a problem when running rad project init. It exits with

            fatal: unable to find remote helper for 'ipfs'
            Error: git -u origin master failed.

            Apart from this, is there any easy way to apply a patch locally without accepting it to test changes? Because I guess once you’ve accepted it that is already merged for everyone.

            1. 2

              There is now documentation for patch checkout: https://radicle.xyz/docs/index.html#rad-cli-reference

              With that you should be able to accept the patch locally in a fresh checkout of the project somewhere else on your filesystem, this way exercissing the process of proposing of accepting entirely locally.

              1. 1

                Hej, glad you took it for a spin. How did you install radicle? And is the git-remote-ipfs binary in your path?

                1. 1

                  I installed it from source using stack. I don’t know right now, not home. Will check later when I arrive and get back to you. I’m installing it right now at the work computer to see if I have the same problem also.

                  There is now documentation for patch checkout: https://radicle.xyz/docs/index.html#rad-cli-reference Amazing! Will try it now.

                  1. 2

                    When installing from source you need to follow the steps on how-to install ipfs and the git-remote-ipfs helper as described in this section: https://github.com/radicle-dev/radicle#installation

                    1. 1

                      Ouch! Completely missed that.

              2. 3

                Very cool. Awesome website too, very fun design.

                1. 2

                  Why not use email as the transport layer. Already supported in git.

                  See https://lobste.rs/s/gyygl3/advantages_email_driven_git_workflow

                  1. 3

                    It has been considered piggybacking on email for the distribution of patches at least. It falls short when it comes to questions of code hosting, public visibility and generally encoding primitives of code collaboration (open/close state of issues, same for patches/pr). Where it could be leveraged in the future is for notifications of updates to projects one follows.

                  2. 1

                    I’ve only skimmed the site, but what it appears to be missing is a way for users to submit issues. That’s one of the major things (other than discoverability) that Github adds over git itself.

                    1. 3

                      Have you checked the rad issue command? It brings a lot of the issue functionality - that people are used to from github - to the table.

                      1. 2

                        Not specifically, but everything I’ve seen appears to require to you to install radicle and then use the command line. I have an OSS project on github with a couple of thousand users, many of whom aren’t particularly technical. One the main benefits I get from github is that my users can report bugs or request features very simply.

                    Stories with similar links:

                    1. Radicle: A Peer-to-Peer Stack for Code Collaboration (in beta) authored by lftherios 1 year ago | 53 points | 27 comments