With the frequency they're on here it feels like a guerilla marketing campaign. Everyone anyways points out they're a crypto scam and then they pop back up a month later and try again.
Was just going to comment something similar down here. Funding FOSS is good, but someone could say that 'giving donations' in crypto to a project that doesn't take crypto donations, and then making them make a crypto wallet to claim the funds, seems just like a convenient way to grow a crypto network. Depending on the conduct afterwards, that could work like any sort of financial scheme common in the space. Hard to know beforehand.
Drips and the infrastructure for that may or may not be a crypto scam. But radicle can't be, because it doesn't involve any coins. Yes, there's $RAD. No, you don't need to use it or even know about it when you're using the radicle project itself.
Firstly, people working on crypto are either the most wide eyed idealistic (to the point it approached willful stupidity), or dubious scummy people I’ve ever met. That doesn’t bode well for the software.
Secondly, because of the first, crypto will eventually make it’s way into the product.
Radicle is a true peer-to-peer protocol. It doesn’t use nor
depend on any blockchain or cryptocurrency.
Radworks, the organization that has been financing Radicle is
organized around the RAD token which is a governance token on
Ethereum.
which part is a scam, again? I see interesting open source software and them funding open source with real world money. If this is what scams look like I hope we see more of them.
The part where you discuss Radicle on Hacker News. The commentators here are not always open minded, and they often love to bash everything which they think is cryptocurrency related.
It's a bunch of crypto bros aggressively marketing a product with no clear use case. If you ask about how the monetization works they frantically wave their hands. They also have been trying to obfuscate their connections with their radicle now rad coin and keep claiming it's unrelated despite the old naming.
Looking forward to the fediverse posts later today, it'll be a good time.
The Radicle project doesn't involve the crypto token, started by Radworks, in its technology.
It's also stated in the FAQ on the website (https://radicle.xyz/faq) that the project is funded by Radworks and also provides a link to the funding page.
I, for one, work on Radicle and what I care about is the data sovereignty and local-first code collaboration. We're building on top of Git to provide a local-first, extensible collaboration experience -- avoiding walled gardens like GitHub :)
As a project team, we only posted once on HN when we were announcing our v1.0 release candidates. The other two posts have been from other people outside of the organisation, so it's nice to see there's interest in the project but don't blame us for that kind of hype :')
How does Radicle handle the following situation?: A non-programmer user wants to submit a bug report. The user has previous experience with submitting bug reports on GitHub and they would not mind creating a new account to submit a bug report on Radicle. Can the user submit an issue on Radicle without running their own node?
At the moment there isn't any mechanism for that kind of drive-by action. The current mechanism for creating an issue requires that a Git reference is created (the COBs structure) for replicating by other nodes.
Perhaps in the future, a user could use a web interface for a Radicle node and they post it directly from their browser. Some questions about that would the verifiability of that action though. Definitely some food for thought here!
Do non programmer submit bug reports on Github...? It must be a vanishingly small minority. I've only seen that at on Mozilla repos with their useless middle managers
Yes? There are plenty of individuals that are technical enough to handle a sign up form and a issue form but not programmers. The bar isn't that high lol.
But then again my username is all non-software engineers :shrug:
One of the problems of self-hosted forges is that spontaneous collaboration is cumbersome, because you need to keep track of your accounts across different self-hosted forges. Some people are working on https://forgefed.org/ to make this less of an issue, but Radicle is a different approach, where the entire repository ecosystem becomes distributed and people identify themselves with cryptographic identifiers to interact with the network as a whole instead of individual forges.
Git was already designed from the outset specifically to be peer to peer. The central server is the addition to that model, not the other way around. I have not looked into this project, but pitching whatever it is as P2P for Git just sounds like the devs learned about Git though GitHub and don't fully understand it.
We're quite aware that Git is a distributed code collaboration tool, even trying out the email based flow in the past :)
You may notice that the title is "peer-to-peer code collaboration stack built on Git", emphasis on "built on". We're using Git as a storage and transport mechanism for code collaboration data. So we're building a local-first tool for the social data, e.g. patches and issues.
Alternatively, the fact that the very first thing basically everyone who isn't Linus has done with vanilla git is introduce some kind of central authority might suggest that what git was "specifically designed for" is more of an outlier than you want to admit.
Everyone knows Linus invented and "specifically designed" git as a drop-in tool for his existing email-patch-based kernel development workflow, which is not how 99.9% of the rest of the world prefers to operate these days.
The difference there is that code can still be pushed (or pulled) between the git repo and the new centralized instance after forking. Anyone coming from pre-git centralized source control (or shudder the NAS of periodically rsync'd folders) recognizes that this represents a significant difference from that earlier world.
On topic, though, I have no idea what Radicle's value-add is, though.
According to their documentation "nodes can run on a personal computer without requiring a server". That sounds better than self-hosting to me, which requires the installation of various components like Apache, SQL, PHP, etc. Seems more like bittorrent for code, which sounds like it could actually be useful.
Ideally, we would have a solution to collaborate on projects peer-to-peer that handles some basic Github-style stuff without having to use Github at all.
But git is not user-friendly. You have to figure out how to push to people directly, and that isn't obvious to a commoner like myself. It would be great to have a nice front-end like Transmission is for bittorrent that makes the experience seamless.
Git works over email; it works across folders (including remote ones); it can read/write several standalone file formats (patches, bundles, etc.) that can be sent via carrier pigeon, etc. As far as I'm aware, there are no technical problems with "push[ing] to people directly" (or likewise allowing others to pull from you).
There is a technical problem in the P2P setting, where it's not just one individual connecting to another. P2P protocols which just replicate data, like Bittorrent, can't negotiate a delta when pushing/pulling, so users have to keep pushing/pulling the entire repo. Radicle's network is smarter, allowing deltas to be calculated.
They also seem to be proposing many other things, which I'm more skeptical of; but at least that point seems valid.
what do you mean by that? as long as you don't recompress the git storage, bittorrent will only transfer the missing blobs. the only problem is that for each change a new torrent hash needs to be created. but you can stuff a new torrent with the git repo you already have and then bittorrent will only transfer the missing blobs just like git does.
Yes, only the missing file data needs to be sent. Working out what's missing is the problem, since protocols that aren't aware of git's structure (blobs, trees, commits, etc.) cannot exploit that knowledge to e.g. walk up from each ref and stop when we hit existing ancestors. Instead, they're stuck comparing the file contents of two entire copies of a repo (via their Merkle trees). That's probably not a big deal for smaller projects (e.g. I've played with hosting my own git projects on IPFS), but it's a lot of overhead for projects like the Linux kernel with massive histories, lots of refs, many developers frequently pushing and pulling many changes, etc.
I agree. However there are already plenty of frontends to git and this isn’t marketed as one of them. Perhaps intentionally because of my earlier point that there are lots of frontends already? But focusing on the p2p aspect doesn’t do any better of a job explaining what this project does.
Since Radicle does not interoperate with Git servers (it uses “Radicle nodes”, and you must run one in order to use Radicle), adopting it is approximately as good as adopting a new VCS; so if there is a VCS that addresses the pain points without involving the crypto nonsense, then that’s the winner. One can potentially even implement a script that populates a Fossil repository history from Git’s and a Git-like front-end CLI/GUI abstraction on top of Fossil’s, making migration as easy as pull from one remote remote and push to another.
Who are "they"? Submitter seems unrelated to Radicle. And what you mean "advertising"? It's a normal HN item, posted like all the others, upvoted to the frontpage like all the other frontpage items.
> ie. what real world problem is it supposed to solve?
Seems pretty clear from the submitted page.
Problem: centralized code hosting platforms [...] single entity(ies) controlling the network(s)
Solution: Repositories are replicated across peers in a decentralized manner, and users are in full control of their data and workflow.
Nothing that requires the user to keep knowing your new URL is ever going to be peer-to-peer: the domain name system is fundamentally and irretrievably a hierarchical system; the ramification of this, of course, being that it supports your well-known URL being attacked or censored and your only workaround is to try to rapidly change your URL constantly... but now, no one can find you consistently, and so you cannot collaborate with anyone over time.
Guys, I know xyz domains are cheap to get but I highly suggest to not use them for anything serious. The XYZ TLD has a very bad reputation and will lead to situations where your domain gets flagged, emails from the domain appears in the spam folder etc.
I didn't know it was cheap or had bad rep—it just seemed cool to me and I thought about putting my personal site under that domain. Might have to reconsider.
From their documentation: "Radicle adopts a local-first, peer-to-peer (P2P) architecture, which draws inspiration from Secure Scuttlebutt (SSB) and Bitcoin’s Lightning Network.
Nodes on the Radicle network subscribe to repository data they are interested in, and peers announce updates that in turn trigger fetches for the underlying content. Just like SSB and Lightning, updates are gossiped on the network until they reach all interested peers."
See Drips on https://docs.radworks.org/#projects
I'd first heard of Radicle from this post: https://blog.orhun.dev/open-source-funding-with-ratatui/
Secondly, because of the first, crypto will eventually make it’s way into the product.
UPDATE: Found this in the FAQ https://radicle.xyz/faq#what-is-the-relationship-between-rad...
Looking forward to the fediverse posts later today, it'll be a good time.
It's also stated in the FAQ on the website (https://radicle.xyz/faq) that the project is funded by Radworks and also provides a link to the funding page.
I, for one, work on Radicle and what I care about is the data sovereignty and local-first code collaboration. We're building on top of Git to provide a local-first, extensible collaboration experience -- avoiding walled gardens like GitHub :)
As a project team, we only posted once on HN when we were announcing our v1.0 release candidates. The other two posts have been from other people outside of the organisation, so it's nice to see there's interest in the project but don't blame us for that kind of hype :')
[0]: https://news.ycombinator.com/item?id=39600810 [1]: https://news.ycombinator.com/item?id=39837117 [2]: https://news.ycombinator.com/item?id=39868504
Perhaps in the future, a user could use a web interface for a Radicle node and they post it directly from their browser. Some questions about that would the verifiability of that action though. Definitely some food for thought here!
Sometimes yes, sometimes no.
Sometimes they flip out about GitHub and go on Reddit instead and write something like this: https://www.reddit.com/r/github/comments/1at9br4/i_am_new_to...
But then again my username is all non-software engineers :shrug:
Everyone can already self-host Gitea or Gitlab, and Git repos are super easy to clone, so what’s the point of all the peer to peer stuff?
ie. what real world problem is it supposed to solve?
Ah, that’s not that much of a problem these days, where password managers (and failing that, SSO with Facebook/Google/etc.) has become wide-spread.
And unless everyone moved to Radicle, it’s just one more system you need to track authentication info for.
You may notice that the title is "peer-to-peer code collaboration stack built on Git", emphasis on "built on". We're using Git as a storage and transport mechanism for code collaboration data. So we're building a local-first tool for the social data, e.g. patches and issues.
Everyone knows Linus invented and "specifically designed" git as a drop-in tool for his existing email-patch-based kernel development workflow, which is not how 99.9% of the rest of the world prefers to operate these days.
On topic, though, I have no idea what Radicle's value-add is, though.
Ideally, we would have a solution to collaborate on projects peer-to-peer that handles some basic Github-style stuff without having to use Github at all.
I’m sure this project brings something new to the table but they’d need a better elevator pitch than “peer-to-peer” to explain that.
There is a technical problem in the P2P setting, where it's not just one individual connecting to another. P2P protocols which just replicate data, like Bittorrent, can't negotiate a delta when pushing/pulling, so users have to keep pushing/pulling the entire repo. Radicle's network is smarter, allowing deltas to be calculated.
They also seem to be proposing many other things, which I'm more skeptical of; but at least that point seems valid.
what do you mean by that? as long as you don't recompress the git storage, bittorrent will only transfer the missing blobs. the only problem is that for each change a new torrent hash needs to be created. but you can stuff a new torrent with the git repo you already have and then bittorrent will only transfer the missing blobs just like git does.
> ie. what real world problem is it supposed to solve?
Seems pretty clear from the submitted page.
Problem: centralized code hosting platforms [...] single entity(ies) controlling the network(s)
Solution: Repositories are replicated across peers in a decentralized manner, and users are in full control of their data and workflow.
Literally the first paragraph on the page.
But self-hosting limits exposure, that Github.com/Gitlab.com provide.
>Git repos are super easy to clone
Git is meant to version your code, not issues, pull requests, etc.
https://radicle.xyz/guides/protocol#introduction
This provides comparison and reasoning.
having to self-host anything?
If you're trying to launch a product though, it's something to keep in mind.
Anyways, a good introduction to git-ssb would be this document: https://github.com/hackergrrl/git-ssb-intro
Nodes on the Radicle network subscribe to repository data they are interested in, and peers announce updates that in turn trigger fetches for the underlying content. Just like SSB and Lightning, updates are gossiped on the network until they reach all interested peers."