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

Threads V2 #748

Open
sanderpick opened this issue May 8, 2019 · 5 comments

Comments

@sanderpick
Copy link
Member

commented May 8, 2019

Recreating this issue as the original became a somewhat unbounded conversation. This is the top-level epic for the next version of threads.

Goals:

  • Move to a standalone repo
  • Move to an interface-based module
  • Add the notion of "intent" to the data model so that other applications can understand a threads intended purpose.
  • Replace the protocol buffer based linkages with IPLD so threads can be more easily traversed by other programs.
  • Use a hybrid p2p and gossipsub orchestration pattern (details to come).
  • Break HEAD into multiple categories (peers, content, annotations)
  • Move to a role-based access model for accounts and applications.
  • Encrypt thread snapshots with one off keys that can be provisioned w/ roles.
  • Allow threads to be searchable and "followed" from a gateway.
  • Support a more traditional "feed" mechanism (1->many vs. some->some).
  • Use a single AES key as the thread secret, hash of key as ID.
  • In addition to being governed by access role, peers should not be required to download thread history.

@sanderpick sanderpick self-assigned this May 8, 2019

@carsonfarmer

This comment has been minimized.

Copy link
Member

commented May 24, 2019

To support things like threaded conversations, annotating files with additional files, etc, it would be useful to move to a model in which everything has a target. In this model, updates to the top-level thread would simply have the thread as a target (or symbolically just have an empty target list). This would also mean we could get rid of comments, which would simply be messages with a target. Messages could be children of other messages, to create reply threads. And you could add files to a sub-thread. Minor change to facilitate a whole slew of new interaction types.

@sanderpick

This comment has been minimized.

Copy link
Member Author

commented May 24, 2019

I think you mean target, right? not parents.

@carsonfarmer

This comment has been minimized.

Copy link
Member

commented May 24, 2019

Yes, good catch. Updated 'parent' -> 'target'

@Gozala

This comment has been minimized.

Copy link

commented Jun 2, 2019

* Use a single AES key as the thread secret, hash of key as ID.

@sanderpick I had a contradictory goal for my IPDF experiment based on my experience with Dat that I would like to share

  • Feed id should be decoupled from the feed. That would allow an author to share both:
    • Live feed that others can subscribe to.
    • Specific version of the feed without permission to subscribe to updates.

In Dat fact that ID of the archive is hash of the key means that if I shared with someone an archive they are able to follow all the updates that will ever occur, which turn out to be a problematic. There for in [IPDF] I used IPNS as an ID decoupling it from the Feed key itself which means that you can publish same feed with multiple different IDs and some might be temporary.

I suggest decoupling ID and Key for textile threads as well for a similar reasons.

@Gozala

This comment has been minimized.

Copy link

commented Jun 2, 2019

Having a permanent thread key worries me given that if it's compromised all of the contained data becomes compromised as well & from what I can tell there is no built-in way to fork off an existing thread.

I would also like to bring up Double Ratchet Algorithm as a potential solution for a thread key rotation. Quoting description, emphasis are mine:

The parties derive new keys for every Double Ratchet message so that earlier keys cannot be calculated from later ones. The parties also send Diffie-Hellman public values attached to their messages. The results of Diffie-Hellman calculations are mixed into the derived keys so that later keys cannot be calculated from earlier ones. These properties gives some protection to earlier or later encrypted messages in case of a compromise of a party's keys.

I have not had a chance to investigate to asses if it could be used for cases other than two party exchanges. However another reason for decoupling feed key from ID was to allow a seamless forking as in new head with new key just pointing to the former chain (which can have diff key)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.