hyperreal

I'm currently trying to wrap my head around setting up Radicle. The decentralization is kind of confusing when I'm used to centralized git hosting.

I have a selective seed node on my public-facing server, along with the radicle-httpd service which is reverse-proxied via Caddy. As I understand, this means I can seed (replicate) selected public repos to keep them in sync with the network. And the radicle-httpd service makes them available in an HTTP JSON API(?).

I also have a regular node on my workstation, with my dotfiles repository added to it for testing purposes.

I'm not sure how a regular node differs from a seed node. Do regular nodes also seed repositories like a seed node does, while a seed node's purpose is solely for seeding? If regular nodes also seed, is there still any reason to run a seed node separately?

I'd also like to get the radicle-explorer web UI set up on my public-facing server via reverse proxy. I'm not sure how that fits in with the rest of this. Does the radicle-explorer have to point to my seed node's HTTP endpoint to display the repositories I'm seeding?

I might have to go bother people in the Zullip chat.

#radicle #git #selfhosting

May 10 at 8:16pmWeb
Show threadRadicleMay 10
@hyperreal Welcome! Calling some nodes "seed nodes" is more of a convention, and also not very well-defined. It suggests that the node has a stable and public address and probably good uptime. But the code that a "seed node" runs, is the same as any other. This also answers your question: Yes, the node on your workstation also seeds repos.
Show threadRadicleMay 10
@hyperreal The reason to run a "seed node" separately is mostly for better uptime and connectivity. How important that is depends quite a lot on your use-case. For public repositories that get seeded by many other nodes that are (in aggregate) up a lot, it is not very important. If you use private repositories, which you want to replicate on a very small set of nodes, then you might want to consider running a node you trust with good connectivity for replication.
Show threadRadicleMay 10
@hyperreal Regarding reverse proxying Radicle Explorer and Radicle HTTP Daemon via one Caddy, please refer to https://radicle.zulipchat.com/#narrow/channel/369873-Support/topic/Need.20help.20with.20seeder.20node/near/592293005
Public view of Radicle | Zulip team chat

Browse the publicly accessible channels in Radicle without logging in.

Zulip
Show threadNic Roland May 10

@hyperreal oh wow, never heard of Radicle before. Interesting idea, especially with all the #enshittification going around

I see it implements PRs and issues in git too... I wonder if it's got any ci features cos lots of people like GH actions and get their build artifacts from GH and verifiable providence seems to be a big driving factor for radicle...

Show threadShawn WebbMay 10

@hyperreal Hey! I've been toying with #Radicle recently, too!

A seeder is simply a (generally speaking, public) Radicle node that accepts inbound connections and simply provides a system from which others can sync from. Kinda like seed nodes on bittorrent, but also kinda not. Generally, seed nodes do not perform commits, open issues, or create patches.

They're simply there to provide access to the repos configured in the node's policy.

#HardenedBSD has a dedicated seed node, too: https://radicle.network/nodes/rad.hardenedbsd.org

Lemme know if you have any other questions. I'm still learning the Radicle ropes, but I've been learning a lot along the way.

Radicle Explorer

Explore the Radicle network

Show threadhyperrealMay 10

@lattera Thanks!

So it looks like I don't need to run my own instance of the Radicle Explorer. I can view my seed node by appending my domain to radicle . network, as long as I have the radicle-httpd reverse proxied publicly.

Show threadShawn WebbMay 11
@hyperreal Correct. The #HardenedBSD seed node runs only the #Radicle node and the radicle-httpd. That should suffice for the majority of cases for seed nodes (or any node needing HTTPS access to repos.)