search

radicle-dev / radicle-link

The second iteration of the Radicle code collaboration protocol.
Other
421 stars 39 forks source link

Feature: replicate Person data #708

Open rudolfs opened 3 years ago

rudolfs commented 3 years ago

On a high level as a user of the protocol, I want Person data to be replicated whenever a project is replicated.

For example: a maintainer creates a project and that project gets replicated onto a seed node. Then a contributor follows this project and replicates it onto their machine. In this case I expect the maintainer's Person data to be available on the contributor's machine in the state::list_users list.

Required by: https://github.com/radicle-dev/radicle-upstream/pull/1912.

rudolfs commented 3 years ago

\cc @CodeSandwich

FintanH commented 3 years ago

I want Person data to be replicated whenever a project is replicated.

Just to clarify here, Person data is replicated it's just that when we replicate a remote that isn't a delegate we only have their Person data under rad/self. It should be the case that rad/id is created and a symref made between rad/id and rad/self.

In this case I expect the maintainer's Person data to be available on the contributor's machine in the state::list_users list.

This should be already the case. It's when a maintainer (or someone else who is not a maintainer) decides to replicate a non-delegate.

kim commented 2 years ago

Unfortunately, this turns out to be a bug-turned-feature:

let A be some arbitrary project let P be some peer let M be a personal identity

If we are fetching A, and creating M implicitly (either because A/P/self exists, or because M is an indirect delegation of A), we will be replicating all of M. This may include M's blog, collection of animated GIFs, etc.

Most definitely, this is not what we want -- the user told us to replicate A, not M.

OP asked to be able to include self claims when iterating over personal identities. This can't be done in constant memory, because multiple self pointers can resolve to the same identity. It is also rather arbitrary to expect this to work: again, A is tracked, not M. It is easy to navigate to self refs in the context of A, and read the Person metadata from there. It is also easy to ask the user if they want to track M, because it appears in A.

However, the reason we track indirect delegations implicitly is the idea that they can revoke keys without having to update all projects for which they are in the delegations set. If we want to retain this, I think the only solution is to allow partial replication akin to fetchspecs.