cloudhead

7 ms·

1. 61.▲
   by cloudhead 3y ago

   It's a good question, I don't know why you're downvoted. Because the synchronization protocol (backed by Git) is operating in the background, web frontends are always just querying local data, so it's actually quite fast
2. 62.▲
   by cloudhead 3y ago

   I am a nix noob, but we are now using flake[0], I don't know if that helps! [0]: https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3gqcJUoA...
3. 63.▲
   by cloudhead 3y ago

   I do remember Mango! I didn't actually try it out, but we had experimented with Ethereum and IPFS in the past, and it wasn't a great fit for a code collab platform due to performance and cost.
4. 64.▲
   by cloudhead 3y ago

   It's a good point - I think "gateways" such as `app.radicle.xyz` will have to allow crawlers to index the full set of repositories on the network.
5. 65.▲
   by cloudhead 3y ago

   Everything that is replicated on the network is stored as a Git object, using the libgit2[0] library. This library uses hardened SHA-1 internally, which is called sha1dc (for "detect collision"). Will add to the docs, good idea! [
6. 66.▲
   by cloudhead 3y ago

   Hey there. Yes, Windows support is something we'd like to have, but focusing on less OSes is helping us ship faster. In principle, there shouldn't be any issue in porting to Windows, but since no one on the team runs Windows it wo
7. 67.▲
   by cloudhead 3y ago

   Thanks! There is no mirroring built-in yet, though this is something we're looking into. It should theoretically be as simple as setting up a `cron` job that pulls from github and pushes to radicle every hour, eg. git pull github m
8. 68.▲
   by cloudhead 3y ago

   When you fork an abandoned repo, you are essentially giving it a new repository identity, which is a new root of trust, with a new maintainer set. You'll then have to communicate the new repository identifier and explain that this is a
9. 69.▲
   by cloudhead 3y ago

   A CONTRIBUTORS file is easy to change by anyone hosting the repository - it's useless for the purpose of verification, unless you have a toolchain to verify each change to said file. "Sign-offs by maintainers" it not useful e
10. 70.▲
    by cloudhead 3y ago

    That's not quite right, we solved this in Radicle. Each change in ownership (adding/removing maintainers) is signed by the previous set of owners. You can therefore trace the changes in ownership starting from the original set, wh
11. 71.▲
    by cloudhead 3y ago

    Yeah, because for eg. I can publish the given repository from my server with an additional signed commit (signed by me) on top of the original history, and that commit could include a backdoor. You have no way of knowing whether this additi
12. 72.▲
    by cloudhead 3y ago

    We've designed Radicle with Tor support in mind, via Socks5 proxy!
13. 73.▲
    by cloudhead 3y ago

    Yes, working on it!
14. 74.▲
    by cloudhead 3y ago

    I think it's currently more likely to happen on Radicle given there is no search or discovery functionality, and repositories exist on a flat hierarchy, ie. they are not namespaced by user/org name, so harder to distinguish if the
15. 75.▲
    by cloudhead 3y ago

    Here's the problem: how do you know that the commit signers are the current maintainers of the repo?
16. 76.▲
    by cloudhead 3y ago

    I won't reveal anything about our finances, but the current code base is a little under 2 years old. We've worked on the general problem for over 4 years in total though. The team is around 12 people, split between protocol, cli,
17. 77.▲
    by cloudhead 3y ago

    I don't think there's anything "special" here. You have the same problem currently where finding the canonical location of a repository is done via some out-of-band social network or website. On GitHub, you also can look
18. 78.▲
    by cloudhead 3y ago

    If you mean collision attacks, this shouldn't be a problem with Git, since it uses Hardened SHA-1. Eventually, when Git fully migrates to SHA-2, we will offer that option as well. > Is Hardened SHA-1 vulnerable? > No, SHA-1 harde
19. 79.▲
    by cloudhead 3y ago

    Yes, these are what Radicle calls "private" repositories. They are invisible to the rest of the network, and only shared amongst trusted peers. Note that they are not encrypted at rest , which means they cannot be stored on inter
20. 80.▲
    by cloudhead 3y ago

    I've answered the use-case question here: https://news.ycombinator.com/item?id=39601588 But yes, we're not officially launched yet and the website is going through a rewrite to offer more clarity, thanks for the f
21. 81.▲
    by cloudhead 3y ago

    Good question! One of the key ideas is that each user chooses what repositories they host via pretty fine-grained policies. This means you can easily block content you're not interested in seeding, or simply configure your node to only
22. 82.▲
    by cloudhead 3y ago

    Thanks, we haven't officially launched though! Pijul is a great project indeed :)
23. 83.▲
    by cloudhead 3y ago

    We're a small team, but if there is enough demand for it, then yes.
24. 84.▲
    by cloudhead 3y ago

    In the long term, this is intended as an alternative to collaboration platforms like GitHub and GitLab for people/organizations who want full control of their data and user experience, without compromising on the social aspect of these
25. 85.▲
    by cloudhead 3y ago

    It can handle them, though we haven't built that much tooling around them. However, unlike GitHub, updates to PRs (Patches in Radicle) are non-destructive, just like Gerrit[0], and code reviews are tied to specific revisions of patches
26. 86.▲
    by cloudhead 3y ago

    I haven't seen the term misused very often - the way it is defined in Radicle and most other peeer-to-peer systems is how Wikipedia defines it[0]; specifically this part: "Peers are equally privileged, equipotent participants in t
27. 87.▲
    by cloudhead 3y ago

    While Git is designed in some way for peer-to-peer interactions, there is no deployment of it that works that way. All deployments use the client-server model because Git lacks functionality to be deployed as-is in a peer-to-peer network. F
28. 88.▲
    by cloudhead 3y ago

    See https://docs.radicle.xyz/guides/protocol
29. 89.▲
    by cloudhead 3y ago

    > The "bag of artifacts" data model used by Fossil is apparently an implementation of a particular Conflict-Free Replicated Datatype (CRDT) called a "G-Set" or "Grow-only Set". Isn’t this just by virtue of c
30. 90.▲
    by cloudhead 3y ago

    We'll hopefully have a real alternative to these centralized platforms when Radicle[0] gets closer to core feature parity with GitHub. For many, this will be sometime this year, for others it might take another year or two. It's r