
Radicle-Link: Extending Git with Peer-to-Peer Network Discovery - lftherios
https://radicle.xyz/radicle-link.html
======
bergstromm466
Great short into by a Radicle contributor:
[https://twitter.com/abbey_titcomb/status/1237053756983959552...](https://twitter.com/abbey_titcomb/status/1237053756983959552?s=21)

------
LockAndLol
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
> 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.

~~~
asicsp
I sometimes visit [https://github.com/](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.

~~~
viraptor
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?"

------
viraptor
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?

~~~
grey_earthling
With SSB (context: [https://ssb.nz](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.

~~~
MayeulC
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.

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

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

------
aabbcc1241
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

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

~~~
grey_earthling
> Proposals such as ForgeFed and [federated
> GitLab]([https://gitlab.com/gitlab-
> org/gitlab/issues/6468](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...](https://radicle.xyz/towards-decentralized-code-
collaboration.html)

~~~
bergstromm466
> 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...](https://medium.com/holochain/holochain-reinventing-
applications-d2ac1e4f25ef)

[2] [http://eric.harris-braun.com/blog/2007/11/05/id-55](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...](https://medium.com/@AlastairParvin/a-new-land-
contract-684c3ba1f1b3)

------
interrupt_
_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?

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

------
anthonyskipper
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
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
Because if they become popular they'll be picked up by The Empire too. E.g.
.org TLD debacle.

------
hyperion2010
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
It has signing information in it, which does seem necessary to authenticate
commits.

~~~
nextaccountic
but git itself has signed commits and tags.

~~~
justincormack
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.

