Live data from Hacker News

Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

app.radicle.xyz

231–240 of 299 posts

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#231

Genuine question ... isn't there an inherent latency issue with Peer-to-Peer? and as such, it makes for a poor user experience on the web. (when you're just downloading files over P2P, this isn't an issue or noticeable - but when you're interacting with a web site, it is) EDIT: why the downvotes? I'm just asking a question.

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. You can try browsing the linked repository and see for yourself.

Even a slightly critical comment gets downvoted instantly in this thread, I wonder why ;)

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#232
post #11

Can this handle patch stacks or is this just another pull/merge request model with all the flaws that entails?

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. This is in my opinion one of the biggest flaws in GitHub's model. [0]: https://www.gerritcodereview.com/

That's indeed the biggest flaw in the Github PR model. I've been hoping for a gerrit-like code review experience in a Github alternative for years. I'll be sure to try Radicle.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#233

Their monetization strategy is pretty critical for people who’d sink their time into the service and entrust it with the code for long-running projects. So… how do they plan on making money off of this? If they can’t or won’t say, what sort of projects do they imagine they’d attract in spite of that? (e.g. ephemeral ones? Data sets about current events?) Downvoters: do you not think their monetization strategy is imp…

this is a very VC-brained comment to make on a peer-to-peer open source project. let's instead ask if there are any single points of failure to the protocol and service, and if so, are those sustainable regarding developer time, effort, and compensation?

You are commenting on the hype channel of one of the biggest VC firms in the world.

(there was a time _when that comment was the default type around here_, actually)

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#234

Earlier quoted context omitted.

Sharing arbitrary copyrighted content did not ruin BitTorrent so I don't see why it would ruin this.

Did it not? I would consider Bittorrent traffic to have a very high risk of being blocked or viewed as suspicious, and as a result almost never gets embedded in other use cases. Even the simple use case of using torrents to have peer-to-peer delivery of software updates has flopped.

It looks like there’s still an Arch Linux BitTorrent tracker; maybe I’m out of touch but I think this is not a very uncommon way of distributing distros (?).

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#235

Earlier quoted context omitted.

I read the documentation and this stands out to me: > Radicle repositories, which can be either public or private, can accommodate diverse content including source code, documentation, and arbitrary data sets. If this is, basically, a peer-to-peer file sharing application, what part of the protocol handles dealing with abuse? Otherwise, how is this different from the previous generation of file sharing applications (…

you can choose which nodes you follow and which nodes you block - you can even decide that you will seed particular repos and not the entire node. (P.S. I am working at Radicle)

so it's the same as cloning a repo locally, auto updating it, and exposing a mirror to the world?

how will this not devolve into freeNet fiasco when popular repos start to go wild on content?

edit: i see from the finance thread you will likely take on maven/npm/etc with crowd hosting+funding so I'm now more curious how cheap it will be for bad actors to push intentional malicious content, since now it's mostly about cost of having consensus over the mirrors

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#236

Earlier quoted context omitted.

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 repository id can be derived via a hash function from the initial set of maintainers, so all you need to know is that you have the correct repository id. 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…

I'm not sure how any of this solves the problem.

If I am on the internet there is no key or keys that I could definitively say came from the _real_ maintainers. I need to trust some source or sources for that.

In your model, committing to the repo requires a private key. This key claims ownership of the repo. If that key is lost or stolen I have lost ownership of that repo. With no out of band method to recover it.

If that key is unknowing stolen, ownership is switched to a new key, this is a pretty bad scenario.

Basically, I still always need to go to some other out of band source to verify that bad things have not happened.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#237

Earlier quoted context omitted.

What you say makes sense. But that trust needs to extend to the hosting platform itself, because the platform can manipulate all non-signed data. I don't see how a GitHub profile by itself is trustworthy. You need some additional, external and independent verification that that GitHub profile is really authentic and doesn't contain compromised code. There is nothing stopping me from creating the accounts IggleSniggle…

I mean... yeah, you obviously have to trust someone to vouch for the authenticity of an identity. In the case of Github, that's the platform owner. In the case of a digital signature, that's the root certificate authority. With that being said, your example feels pretty far off the mark. You might be able to phish using a similar looking identity, but that's completely unrelated to the trustworthiness of the platform…

> It's not as though you'll manage to somehow phish Github into showing someone else's trustworthy work history on a spoofed identity.

You don't need to trick github, that's just how it works by design. Anyone can upload any repo to github. There is nobody checking the repo isn't stolen or fake. Github does not claim to be vouching for anyone. At most they will delete malware and obvious scams if it happens to comes to their attention.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#238
post #42

Earlier quoted context omitted.

I mean, that definition doesn't fit with supernodes ("seed" nodes in your design) but that is a nitpick. I guess im mostly just wondering what are the properties you are trying to accomplish. Like there is talk of publicly seeding repositories that are self-certifying, but also using noise protocol for encryption, so what is the security model? Who are you trying to keep stuff secret from? It is all very confusing wh…

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 feedback. Re: seed nodes: they are running the same software and work the same way as regular nodes, the only difference is how they're deployed (with a public IP address vs. behind a NAT). But yes, a little…

> I've answered the use-case question here: https://news.ycombinator.com/item?id=39601588

I appreciate you think you have, but you haven't. Appeals to vauge lofty notions of digital soverignty and other political values is not what i'm looking for and doesn't really mean much. I'm more looking for a threat model. What does the network accomplish? What are its limits? What are its intended properties?

> Additionally though, Radicle offers a level of censorship resitance and disruption tolerance that GitHub cannot offer.

That seems unlikely (at least as it stands now). Pretty sure it would be much easier to DoS the entire radicle network than to DoS github. It all depends on who you think your attacker is. Github has an excellent track record of standing up to china (for example nytimes archive on github is primarily about bypassing the great firewall of china) it is much weaker on DRM circumvention. All these things depend on how you define them. If you don't define them, and rigorously analyze them, then your censorship resistence is probably wishful thinking.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#239
post #42

Earlier quoted context omitted.

I mean, that definition doesn't fit with supernodes ("seed" nodes in your design) but that is a nitpick. I guess im mostly just wondering what are the properties you are trying to accomplish. Like there is talk of publicly seeding repositories that are self-certifying, but also using noise protocol for encryption, so what is the security model? Who are you trying to keep stuff secret from? It is all very confusing wh…

All nodes can still have equal privilege. Data must originate from somewhere, that is a seed node. And supernode is, or at least was when I studied CS, basically just a more connected node. That said, I agree, a project like this could do with a more formal and structured definition of goals.

> Data must originate from somewhere, that is a seed node

From what i read in their docs, that is not how they are defining seed node.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#240
post #79

Earlier quoted context omitted.

That problem is social you can never be sure of that even with hardware signing of commits. No tech can ever solve that. Just get "pull requests" from contributors you know and pull from maintainers you trust. Is the social model.

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 you know the repository id is the correct one?

You have just changed the requirement from knowing the maintainers public key, to knowing a different public key. Sounds pretty much the same problem to me.

Post reply on HN