group migration #40

Closed
opened 2018-06-11 23:04:03 +00:00 by dan · 5 comments
Owner

use cases:

  • remove user
  • prompted (probably by timer in app to promote security)
  • change server
use cases: - remove user - prompted (probably by timer in app to promote security) - change server
Owner
  • adding a user (although this could be done more efficiently through a kdf)
- adding a user (although this could be done more efficiently through a kdf)
Contributor

If no-one is taking this I can jump onto it.

I'm thinking a series of functions in cwtch_peer.go?

If no-one is taking this I can jump onto it. I'm thinking a series of functions in cwtch_peer.go?
Owner

@angus: This one needs some design before it is ready to be implemented. We have a meeting this week to go over some high level decisions and reach consensus on some which tasks are good to go and which need more design/thought - the issues should be in much better shape after Friday.

@angus: This one needs some design before it is ready to be implemented. We have a meeting this week to go over some high level decisions and reach consensus on some which tasks are good to go and which need more design/thought - the issues should be in much better shape after Friday.
Contributor

Sounds good, thanks. I'll dig around for some others I can work on.

Sounds good, thanks. I'll dig around for some others I can work on.
Owner

After much discussion on this we've decided to move forward on a group-forking model.

The idea being that given the environment we can never assure the secrecy a group once there is a member that has been determined by the members to be adversarial (or not welcome etc.) - As such any mechanism we put in place to manage membership reduces to "setup another group".

Given that we plan to make "forking" groups very easy and build the metaphor around a cwtch group being a location (and if a location gets compromised is any way, then you have to move....)

More on this soon.

After much discussion on this we've decided to move forward on a group-forking model. The idea being that given the environment we can never assure the secrecy a group once there is a member that has been determined by the members to be adversarial (or not welcome etc.) - As such any mechanism we put in place to manage membership reduces to "setup another group". Given that we plan to make "forking" groups very easy and build the metaphor around a cwtch group being a location (and if a location gets compromised is any way, then you have to move....) More on this soon.
sarah closed this issue 2019-01-21 19:05:24 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cwtch.im/cwtch#40
No description provided.