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

Forking #24

Open
ghost opened this issue Jan 10, 2019 · 4 comments
Open

Forking #24

ghost opened this issue Jan 10, 2019 · 4 comments
Milestone

Comments

@ghost
Copy link

ghost commented Jan 10, 2019

How does a Dat become forked? How is this related to hash/signature verification?

@martinheidegger
Copy link
Contributor

My understanding is that forking doesn't exist in DAT, only exists in Beaker browser.

@ghost
Copy link
Author

ghost commented Jan 10, 2019

Ah yes, good clarification @martinheidegger. I guess there are two different concepts of forking in Dat:

  • Copying the files from one Dat into another that you own, making an editable copy like in Beaker.
  • Accidentally signing and distributing two different versions of the same chunk, resulting in different peers on the network having different copies and being unable to reconcile.

Is the concept of forking you have in mind the first one?

I’m thinking about the second one and want to try answering questions like:

  • How does this happen? (copying the secret key to a different device or restoring from a backup)
  • What are the implications? (don’t share secret keys between devices)
  • How to mitigate? (can you ask the network to get you up-to-date after restoring from a backup?)
  • What to do if it happens? (stop using that secret key and make a new Dat?)

@martinheidegger
Copy link
Contributor

Alright second case: "Accidental forking"

How does this happen?

There are various ways how this can happen, basically it comes down to:

  1. A dat needs have been replicated in the network
  2. The local replication needs to be reverted to a non-latest version. This can happen through...
    • not having entirely replicated to the latest version
    • having reversed to a previous version by hand or through a restoring a hard-disk backup
  3. An entry is added to the non-latest state.
  4. That entry is replicated to other peers.

What are the implications?

  • When you append to a hypercore, make sure it is the latest version.
  • When you move the secret keys, make sure that wherever you move them holds the latest version.

How to mitigate?

  • DAT clients could be improved to support timestamps. With timestamps, clients could choose the tree with the latest timestamp.

What to do if this happens?

  • Delete all known replicas
  • (if you can't do that or its too bothersome) create a new DAT

@ghost
Copy link
Author

ghost commented Jan 10, 2019

Nailed it @martinheidegger! Thank you for the pointers, especially about timestamps.

@ghost ghost added this to the v2 milestone Jan 16, 2019
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

No branches or pull requests

1 participant