181–190 of 299 posts
There should be a way to run git over i2p. Also, git over yggdrasil should be easy because there are just ipv6 addresses. And, in the worst case, I think 6to4 tunnels would work.
> There should be a way to run git over i2p. https://geti2p.net/en/blog/post/2020/03/06/git-over-i2p see "Third: Set up your git client tunnel" But like most things in the I2P ecosystem, not seamless.
That's a neat name! If "seeding" is the word for distribution in a peer-to-peer network, then a "radicle" (not a "radical"!) must be named after: - "In botany, the radicle is the first part of a seedling (a growing plant embryo) to emerge from the seed during the process of germination.[1]" https://en.wikipedia.org/wiki/Radicle
>a "radicle" (not a "radical"!) I'll just mention that etymologically both "radical" and "radicle" come from the Latin "radix", meaning "root".
Earlier quoted context omitted.
What about it? It‘s an almost completely different product. Codeberg is like GitHub.com, GitLab.com, or sr.ht: a centralized hosted solution.
The software behind Codeberg is Forgejo, which is a fork of Gitea. The team of Forgejo is working on a federation protocol based on ActivityPub. Once it is done, it will be able to exchange data with other Forgejo servers and any server supporting that protocol. So, we may expect that Codeberg will transform from centralized to federated. sr.ht chooses another approach. You only need an email to submit codes, file is…
Well, at least you don't need a name or a certificate for the server, I assume its id works as its cryptographic identity.
Earlier quoted context omitted.
Sure, but again, you've added convenience - or what you feel like it's convenience - for something that probably can be achieved right now with open source tools. A "CONTRIBUTORS" file with sign-offs by maintainers is an example of a solution for the same thing. I don't deny that your improvements can benefit certain teams/developers but I feel like there are very few people that would actually care about them and th…
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 either unless you already know who the maintainers are, and you are kept up to date (by a trusted source) when the maintainers change. This is what Radicle does, for free, when you clone a repo.
>Installation > >The easiest way to install Radicle is by firing up your terminal and running the following command: > >$ curl -sSf https://radicle.xyz/install | sh Ah.. my high hopes were immediately dashed by the trash that is curl-bash. What a great signal for thoughtless development, if this project catches on I can't wait to watch the security train wreck unfold. Maybe someday we'll get an "Open-Source, Peer-to-…
Here you go [0] - the project hasn't launched yet and there are bits and pieces to be dealt with, the current focus is a bit somewhere else. You can also build from source [1] with Rust's cargo. [0] https://files.radicle.xyz/latest/ [1] https://app.radicle.xyz/nodes/seed.radicle.garden/rad:z3gqcJ...
Hi HN. I am the co-founder of the project. If you are interested in how the protocol works under the hood, start here: https://docs.radicle.xyz/ Docs are still WIP though.
Looks really interesting! Some of us are allergic to "curl | bash" though; would you consider creating a homebrew package?
Earlier quoted context omitted.
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 either unless you already know who the maintainers are, and you are kept up to date (by a trusted source) when the maintainers change. This is what Radicle does, for free, when you clone a repo.
All good points, but now you moved the trust requirement from me having to trust the people working on the code, to me having to trust the tool that hosts the code. I'm not convinced your model is better. :P
Hi HN. I am the co-founder of the project. If you are interested in how the protocol works under the hood, start here: https://docs.radicle.xyz/ Docs are still WIP though.
I'm interested in this, but I noticed a base58 hash on the page. I'm not really interested in crypto. How much could I use this product without adopting crypto? Is this attached to some digital currency like ipfs or is it independent?
Earlier quoted context omitted.
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, which is bound to the Repository ID.
How do I verify the “original set”, or the Repository ID, if not out-of-band communication (like a project’s official website)? And then what advantage does this have over the project maintainer signing commits with their SSH key and publishing the public key out-of-band? I think there’s room for improvements in distributed or self-hosted git, but I think they exist more in the realm of usability than any technologic…
The advantage of this is that (a) it verifies that the code is properly signed by the maintainer keys, and (b) it allows for the maintainer key(s) to evolve. Otherwise you’d have to constantly check the official website for the current key set (which has its own risks as well)