Radicle-Link: Extending Git with Peer-to-Peer Network Discovery | Hacker News Reader

Radicle-Link: Extending Git with Peer-to-Peer Network Discovery

radicle.xyz

138 pointslftherios37 comments

Great short into by a Radicle contributor: https://twitter.com/abbey_titcomb/status/1237053756983959552...

Really like the idea of decentralizing projects and their social artifacts. Getting rid of github for project discovery is a great goal.

Additionally running all of this on top of I2P would counter any embargoes that centralized forges like Github have to abide by. Projects by Iranians wouldn't suddenly disappear from radicle and neither would things like PopcornTime.

I'll be checking this out. I hope they have an executable with a good CLI. The GUI or embedded webserver for the social part of radicle can come later (unless they already have it)

> github for project discovery

Honestly I don't think I've ever "discovered" a project simply by searching/browsing github itself. Usually it is through places like reddit and HN, and blog posts when searching for how to do something. I've never gone to github and just searched for some random project name...

On the other hand I also don't use github "stars", which I see more and more people talk about, so maybe some people use github differently than I do.

Follow interesting people. They star repos that pop up in your feed. I have found that to be a good way to find specific projects. A rust contributor is going to star other rust projects. They will go beyond the trending repos and that's how you find something interesting. I maintain a separate GitHub account just for curating a rss feed.

I sometimes visit https://github.com/ and the three "Explore repositories" in the sidebar seems tailored based on my activity. I've clicked a few, bookmarked some and even submitted PRs.

It's interesting. I feel like for each repository I understand why the recommendation is made, but the repos are completely disconnected from what's useful to me. It's a bit like "you bought milk, would you like a milking machine cleaner as well?"

I never noticed this. Very cool, and very accurate

To improve the discovery of better alternatives to popular products and services, some of us are building a browser extension. It uses an in-page pop-up based on URL patterns to make community-curated suggestions: https://github.com/nileshtrivedi/better

Another great source for discovering FOSS projects is https://opensource.builders

github "stars" are a very poor measure of popularity and in no way a measure of quality.

I2P is really slow, though.

Ssb itself does initial sync which requires a few GB of download to use (and will keep growing AFAIU). Does radicle-link have the same issue? Or is it relying on gossip and transient data?

With SSB (context: https://ssb.nz), most of those few GB are blobs — arbitrary files, like email attachments. They aren't needed to confirm that the feed is complete, and clients can choose whether to download them.

SSB downloads the whole feed so it can guarantee that a peer hasn't maliciously withheld certain previous messages from the feed.

I guess (waves hand vaguely) that constraint probably isn't relevant for version control, because subsequent commits would fail to apply…? Not sure. But if you're only interested in recent history, you could probably do something like a shallow clone.

What is the rationale for making them part of the chain, instead of just making their hashes part of that chain, like with git LFS?

This way, you would know about all the messages and blobs, but only download those you want, and match their content against the hash. Of course, this comes with less replication, therefore less availability.

+1, SSB is basically Git with the constraint that each commit only has one child (no branches) and instead of a tree you can publish arbitrary JSON. Shallow clones are completely possible, it's just that the reference implementation demands the full chain for verification.

That's not true. The SSB sync downloads whatever you request. This is like saying that HTTP downloads are all a few MB. :/

https://scuttlebutt.nz/get-started/

> The first time you join the network there will be a lot to download and process. For real, this “inital syncing” process can take up to an hour and use a couple of gigabytes.

Are you saying the ssb project's website is wrong here? (I don't use ssb, so I'm going by what's documented only)

The docs aren't wrong; they just make a few assumptions, which are mostly true for existing implementations:

- Your SSB client downloads feeds you follow, plus feeds they follow, and possibly feeds they follow too

- When downloading lots of new feeds at once (for example, the first time you sync) your client makes no attempt to prioritise which feeds it downloads first

- Your client downloads all blobs (attachments) greedily

- Your client indexes downloaded messages (for example, to find the recent messages from all feeds); its implementation of indexing is slow and heavy; until indexing is complete, the app is unresponsive

None of these assumptions is necessarily true of an SSB client, but they're generally true of popular existing clients.

It’s not wrong, it’s just generally but not exhaustively true.

SSB doesn’t have a root node, so if you think of yourself like an island the data transfer required from your first “bridge” is going to depend on what you are bridging to.

In practical terms, if you join one of the SSB pubs published in their documentation, you’ll sync whatever is on that pub.

They have an eth smart contacts repo "radicle-contracts" on their org. Anyone know what that bit's about?

from a user session a friend did with their team, they are working on a bunch of stuff including funding features for maintainers.

From the first look it sounds like GitCenter (git over zeronet), but a closer looks seems radicle is more efficient and has unique (and probably better) way for discovering new content. Still not very clear about the actual design of radicle, will checkout more about it

Surprised that it doesn't mention ForgeFed (earlier GitPub). https://forgefed.peers.community/

> Proposals such as ForgeFed and [federated GitLab](https://gitlab.com/gitlab-org/gitlab/issues/6468) are a step in the right direction, but implementations are underdeveloped or lacking. In addition, federation is dependent on domain names which can and are regularly seized by governments.

— https://radicle.xyz/towards-decentralized-code-collaboration...

> federation is dependent on domain names which can and are regularly seized by governments

This is exactly what Arthur and Eric from the MetaCurrency Project aimed to confront. Protocol Cooperativism (not Platform Cooperativism) means direct, fully transparent, distributed, and mutually-sovereign protocol negotiation in all areas of our new digital world/life [1], making invisible the dogmatic legacy 'wealth acknowledgement systems' now in place [2]. Even Banking 'apps' and things like land-registry [3] and more can be re-invented (I'd argue that banks are one of the earliest forms of software).

[1] https://medium.com/holochain/holochain-reinventing-applicati...

[2] http://eric.harris-braun.com/blog/2007/11/05/id-55:

"When I was growing up in Ecuador, I remember in the market place there would always be a couple men sitting by tiny tables with pen and paper and a line of people waiting for them to write letters, for which they would pay a small fee. This is a common sight wherever literacy isn’t universal. This situation is almost exactly the same we are in today with respect to money. We, and by we I mean our communities (not ourselves as individuals) are monetarily illiterate, and therefore we need others to make our wealth acknowledgment statements on our behalf (and we pay a pretty penny for it) when in fact, we could simply learn to write.

Learning to write in the monetary context, is simply issuing a currency. Or, more precisely, creating the symbols and rules that a community will use to make wealth acknowledgment statements. But the problem is that we don’t have an alphabet, a grammar that we can follow with which to make such statements. Our monetary system and the financial world behind it is essentially that 40,000 character dictionary and the scribes who can interpret it. It does work. It creates a system in which we can make wealth acknowledgment statements at a global scale. But it does so at a direct cost like paying the scribe in the marketplace, and also a systemic cost, that of allowing an elite who control that system to grow and take advantage of those who do not."

[3] https://medium.com/@AlastairParvin/a-new-land-contract-684c3...

In fact, Git was only created when Linus’ free Bitkeeper license was revoked after a Linux kernel contributor tried to reverse engineer its networking protocols

Bit-who?

So by revoking Linus‘ license bitkeeper set in motion a development that would make bitkeeper obsolete. This is funny.

I have to say that reading the Radicle designers observations about git on IPFS I think they solved the wrong problem. I would love to be able to save and work with git repos on ipfs.

Most of the other things radicle aims to provide seem like they are better centralized. There is a reason we all use gitlab/github for collab services. It is that centralization is better for that kind of thing.

> There is a reason we all use gitlab/github for collab services. It is that centralization is better for that kind of thing.

No, it is not because centralization is better. It is because centralization is easier.

I've many, many times wished for a way to collaborate on a git-based project without having to centralize the collaboration on a platform that I ultimately fear will censor the project. radicle-link is exactly what I'm looking for, and it's bizarre to me that someone would look at this project and say "hmm, it should just be centralized." Why should it be?

See [old-roadmap], on the challenges they had. But I agree that they should be overcome.

In particular, the essence of the packfile format and protocol --- storing and exchanging patches from one content-addressed atom to another --- would be good for IPFS as a whole, so I think the issue is not some incompatible priorities, but rather just human/org coordination difficulties. (C.F. [eth2-report] for about Ethereum 2 working with libp2p.)

It's always harder to reuse code developed by different teams in the short term, but I firmly believe it's worth it, making both sides better --- better than they would be had they gone their separate ways --- in the long term.

The immediate challenge with Git is that git objects (blobs, trees, and commits) can be arbitrary large, which is bad in general, but especially bad for p2p networks where you don't to waste arbitrary large bandwidth and storage with some untrusted peer before verifying whether the data they've sent you is what you wanted. But I think I and a friend found a solution to this [git-chunk]. With that, it's at least possible to negotiate who has what git object without an awkward trustful identifier translations. That I think is good enough to get the ball rolling, after which the improvements to the protocol taking inspiration from the packfile format/protocol can be pursued.

[old-roadmap]: https://github.com/radicle-dev/radicle/issues/689

[eth2-report]: https://discuss.libp2p.io/t/report-a-study-of-libp2p-and-eth...

[git-chunk]: https://discuss.ipfs.io/t/git-on-ipfs-links-and-references/7...

Might be I didn't get your point; sorry then.

But centralization is good until someone gonna try to censor and deplatform your project or it's contributors. And this can happen for all kind of reasons starting with non-exiting copyright infringement (like with popcorn-time), bypassing some DRM or creating tools that can be used for malware development or even breaking ToS on some API.

Today people think it's good idea to deplatform people for their political views or ban them based on region where they living, but tomorrow that's can happen with software projects too.

> better centralized

What is "better centralized" and what advantages do you think centralizing it brings? Git itself is literally a reaction against having centralization.

I was wondering the same. If the Microsoft monopoly is the problem, why not just use non-profit Git hosting sites like codeberg.org? They run a Gitea instance and are being adopted by more and more FOSS projects.

Because if they become popular they'll be picked up by The Empire too. E.g. .org TLD debacle.

Any approach to sharing and collaborating around a git repository that requires some convention inside that repository seems fundamentally broken to me. I understand why people want to do it that way -- self describing artifacts are quite handy. Having something like fossil that can live inside a git repo itself is a big plus, for some workflows. I would be shocked if the linux kernel tree ever has a project.json file added to it. All the identifiers you need are already there in the commit hashes, why create another layer of complexity inside the repo itself?

It has signing information in it, which does seem necessary to authenticate commits.

but git itself has signed commits and tags.

Yes, but it does not tell you which signatures are valid in this repo, this is something that is external, eg GitHub lets you manage a list. You need this information to validate the signed commits.

Reply on news.ycombinator.com