In other forges, there is the concept of “orgs”. In the context being discussed here, orgs have a group of users and each user can create as many repositories within that org. The server the forge is then running on will offer always-on, 24/7 hosting of that repository.

We don’t have the notion of “orgs” in radicle yet - and perhaps there is little sense in having it even in the mid-long term.

We should try to satisfy that same need however for “org users” / “team members”: have some public, always-on, seed node seed their radicle repositories.

As already discussed on zulip ( 1 ), one way to satisfy this need would be to allow node operators to specify a new combination of seeding policy and scope such that the public seed node could “seed every repo it comes across, from these team members”. This could be achieved, for example, with an optional parameter to rad follow to indicate this additional intent.

A problem with the above approach is that it would force the “team members” to maintain separate radicle identities when working on “team projects” vs. when working on personal projects. Otherwise, the “team node” could end up seeding their personal repositories.

Another approach would be to allow the node operator to define a list of Node IDs that have some kind of elevated permission on the public seed node, such that they can remotely request a specific repository to be seeded by the team node. For example, this could be by invoking a new HTTP API endpoint (e.g. api/v1/node/seed) - or using the web UI to achieve the same thing.