Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: replicate Person data #708

Open
rudolfs opened this issue Jun 18, 2021 · 3 comments · Fixed by #709
Open

Feature: replicate Person data #708

rudolfs opened this issue Jun 18, 2021 · 3 comments · Fixed by #709
Assignees

Comments

@rudolfs
Copy link
Member

rudolfs commented Jun 18, 2021

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: radicle-dev/radicle-upstream#1912.

@rudolfs
Copy link
Member Author

rudolfs commented Jun 18, 2021

\cc @CodeSandwich

@FintanH
Copy link
Contributor

FintanH commented Jun 18, 2021

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
Copy link
Contributor

kim commented Sep 22, 2021

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.

@kim kim reopened this Sep 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants