Radish alpha
h
Radicle Heartwood Protocol & Stack
Radicle
Git (anonymous pull)
Log in to clone via SSH
[Feature Request] Improve ergnomics for teams with private seeding nodes
did:key:z6Mkf8A8...FoXE opened 1 year ago

Scenario

Team source-code they want to keep private and source-code they want to publish through radicle.

Requirements

  • Developers should:
    • be able to create private team repositories on seeding node
    • push private repositories if they belong to the team
    • browse the seeding node to browse its repositories
    • be able to contribute to public repositories on non-team seeding nodes
  • Private team tepositories should:
    • Not be automatically synced or pushed to public seeding nodes
    • listed on the private seeding node to be discovered by team members

Current experience

While some or all of this might be already possible, there were many stumbling stones encountered alone the way while testing this.

Creating a private seeding node is not straight forward

There are many steps required to setup a node and it's not clear from the documentation what is absolutely necessary, nor how to:

  • Stop the seeding node from communicating with other nodes and unintentionally sharing repos
  • What config keys exist, what they do, and their possible values
  • Whether external addresses are mandatory or not (private nodes could be in a VPN with no public DNS)

Missing docs on local nodes, remotes, security, ...

Coming from git, it's not clear why a local radicle node has to exist (does it? I don't know). The expectation is that there is a remote server with some kind authentication and authorization checking, that users can login and access repositories they are authorized to access, create repositories if they have the permissions to, and that this can happen using rad or some radicle command locally.

  • Is a local node necessary? Docs don't answer that
  • git push rad pushes to the local node and it isn't clear whether it is then synced
    to every seed the node knows, or whether it stays local
  • Same vein: are additional remotes necessary to push to different seeds?
    rad remote add or no?
  • Pushing to another seed requires rad node connect $nid@$ipOrHost:$port but again:
    why is a local node necessary? Why not push to the seeding node directly?

Private repositories cannot be listed on private seeding nodes

The radicle HTTP server only exposes public repositories. Private repositories can only be listed by logging onto the server via SSH or something and executing a command on the server.

Giving access to the private repository requires knowing every single team member's ID

A private repository manages its own rights, thus if a team member creates a repo, they will need the IDs of every collaborator and have to add them to the allow list. The addition of a team member will thus require editing every single repo they require access to. That's fine but there is no easy way to do so at the moment and the operation is quite manual.

Proposal

For getting all set up, the process and documentation should be easy.

Setting up a seed node should be the single, highest effort step. A developer should be able to join the team and hit the ground running without first understand everything about radicle.

Someone setting up a seed node should be able to answer:

  • Will my repositories be synced with the world or not?
  • What configuration options exist, what do they do, and what their possible values?
  • How do I add/remove access?
  • How do I assign permissions?

A new dev with the private seed node address should be able to easily:

  • Create an identity e.g rad auth create
  • Discover the projects/repositories on the private seed node e.g rad explore $nid
  • Clone a project and contribute to it e.g rad clone, git push, git fetch, ...
  • Create a new team project if necessary e.g rad init --private,
    rad remote add $nid@$host:$port,git push
  • Understand how to keep a private project private e.g local node is necessary (or not), if I do
    this then it will push to the public, if I do this then it won't, I must not do XYZ

Right now, these simple steps require a lot of reading and after multiple hours I am still not able to answer many questions.

z6MkgFWv...1Lu7 commented 1 year ago

I find this very interesting and would like to explore this a bit more.

I am curious if this is to be implemented here, or in a separate component (ie. radicle-explorer or similar). As you mention, the protocol supports all of this - it just involves quite a bit of manual work.

z6MkrnXJ...SFS3 commented 1 year ago

Hi there o/

Thanks so much for writing all this down! We are indeed very interested to better support this scenario.

Admittedly, the experience around private repositories and nodes is a little rough around the edges right now. As far as I understand it, that is because the main use case for a decentralized, peer-to-peer forge, like Radicle, is to host public open source projects.

Can you please help me better understand your scenario? I am not sure I understand why the teams described here need Radicle. To play devil’s advocate, why couldn't teams that want all of these features, including private repositories and private seed nodes, self-host one of the other open source forges (GitLab, Forgejo, etc.) ?

Is there something specific to Radicle that these teams are interested in that they can’t find elsewhere?

Thanks in advance! Your input is really helpful in shaping what comes next!