[HN Gopher] Radicle-Link: Extending Git with Peer-to-Peer Networ...
___________________________________________________________________
Radicle-Link: Extending Git with Peer-to-Peer Network Discovery
Author : lftherios
Score : 119 points
Date : 2020-09-05 10:08 UTC (12 hours ago)
(HTM) web link (radicle.xyz)
(TXT) w3m dump (radicle.xyz)
| bergstromm466 wrote:
| Great short into by a Radicle contributor:
| https://twitter.com/abbey_titcomb/status/1237053756983959552...
| hyperion2010 wrote:
| 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?
| justincormack wrote:
| It has signing information in it, which does seem necessary to
| authenticate commits.
| nextaccountic wrote:
| but git itself has signed commits and tags.
| justincormack wrote:
| 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.
| LockAndLol wrote:
| 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)
| radarsat1 wrote:
| > 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.
| mathnmusic wrote:
| 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
| asicsp wrote:
| 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.
| someperson wrote:
| I never noticed this. Very cool, and very accurate
| viraptor wrote:
| 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?"
| searchableguy wrote:
| 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.
| ex_amazon_sde wrote:
| github "stars" are a very poor measure of popularity and in
| no way a measure of quality.
| anthonyskipper wrote:
| 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.
| mathnmusic wrote:
| 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.
| dboreham wrote:
| Because if they become popular they'll be picked up by The
| Empire too. E.g. .org TLD debacle.
| orthecreedence wrote:
| > 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?
| SXX wrote:
| 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.
| Ericson2314 wrote:
| 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...
| outsomnia wrote:
| > better centralized
|
| What is "better centralized" and what advantages do you think
| centralizing it brings? Git itself is literally a reaction
| against having centralization.
| viraptor wrote:
| 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?
| jhardy54 wrote:
| That's not true. The SSB sync downloads whatever you request.
| This is like saying that HTTP downloads are all a few MB. :/
| viraptor wrote:
| 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)
| grey_earthling wrote:
| 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.
| joshuakelly wrote:
| 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.
| grey_earthling wrote:
| 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.
| jhardy54 wrote:
| +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.
| Valodim wrote:
| They have an eth smart contacts repo "radicle-contracts" on their
| org. Anyone know what that bit's about?
| captn3m0 wrote:
| Surprised that it doesn't mention ForgeFed (earlier GitPub).
| https://forgefed.peers.community/
| grey_earthling wrote:
| > 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...
| bergstromm466 wrote:
| > 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...
| interrupt_ wrote:
| _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?
___________________________________________________________________
(page generated 2020-09-05 23:00 UTC)