I've been doing some initial testing with @radicle ... https://radicle.xyz/

First thoughts ...

  • it's an interesting idea, and I really like the concept.
  • It's a lot of new concepts I need to get used to, learn a lot of new terminology
  • I need to learn stop comparing more directly against how things works in Codeberg/GitLab/GitHub
  • it's pretty fast after all
  • Searching for existing projects on radicle seems to be an impossible task or based on pure luck. The "random" rad:z3g..... strings identifying a repository (needed for rad clone) are even worse to remember than IPv6 addresses. I'm missing a "DNS" equivalent for looking up those RID values.
  • There seems to be more URLs out there pointing at documentation for various versions. Several of them are completely outdated and examples no longer work. In other words: Confusing documentation for newcomers.

I have so much to learn, and need to sit down and read the docs way more carefully. Just need to find the right ones.

#programming #source_code #version_control #vcs #opensource #foss #git #radicle

Radicle 1.7.1

Sovereign code infrastructure.

@dazo

Regarding discoverability, there is https://search.radicle.xyz/ if you want to search for public repositories on the Radicle network by name. Also, if you know the DID of one of the repo delegates, you can find all their repositories via Radicle Explorer (e.g. in my case https://radicle.defelo.de/~defelo should redirect to a page listing my repositories).

For documentation, the guides on https://radicle.xyz/guides should be up to date.

Radicle Search

@defelo Ahhh! Awesome! Thanks a lot .... I don't know why I didn't find that search engine. I probably got lost looking for it in the other web views.
@dazo Honestly I'm not even sure https://radicle.xyz/ mentions this at all (it probably should). I only know about it because it has been mentioned on Zulip a few times
Radicle 1.7.1

Sovereign code infrastructure.

@defelo Yeah, but also something on the radicle-explorer web pages would be nice as well - from a user experience point of view.

And a related thing I find a bit confusing is how the relation between "seed hosts" (sorry, lack the right terminology) where a repository is distributed to and the repository ID (rid? rad?) is presented in the URLs on the radicle-explorer hosts.

Now it is $seed/$repoid which is the order. To me, as a novice, it would make more sense to have it the other way around. The repository is what you want to access - which is available on $seed ... So $repoid/$seed.

The way it is now, the $seed ("server") is the more weighted search key in the URL. While, to me, in a distributed environment, it is the repo ("data") being the more important search key in practice. I don't really care where the data comes from, and if it is from 1 or 50 seeds that doesn't really matter when you do a clone operation. The repo ID is then a reference to where you can find the data.

But maybe it'll make more sense when I get time to dig into the documentation and discover the gritty details 😀

@dazo This is probably because the explorer (i.e. the web frontend) only speaks to a single radicle-httpd server, so there is no p2p or anything at this point. You first have to pick a single radicle-httpd server (e.g. seed.radicle.xyz) and then all information is fetched from only this server, both regarding repositories but also node stats for example or the list of repositories seeded by this node (basically everything you see at https://seed.radicle.xyz/api/v1). The disadvantage of this is of course that after choosing a radicle-httpd server, you only see repositories and peers this specific node knows about (e.g. on my instance you will only see repositories which I have `rad seed`ed previously). This shouldn't be a problem though if you choose a permissive seed like {iris,rosa}.radicle.xyz which seed basically all repositories on the network.
@defelo Thanks once again! This helped me understand better how these pieces fit together 🙂 And your explanation makes a lot of sense, too