-
Notifications
You must be signed in to change notification settings - Fork 275
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
group property support #71
Comments
|
How to use it for developers? For the client, it can commit a proposal, and view the status of the DEC: https://github.com/streetycat/CYFS/tree/main/src/component/cyfs-group/src/dec/rpath_client.rs The administrator is responsible for maintaining DEC status with BFT consensus. For APP developers, four interfaces are required:
There is the interface that developers need to implement: There is the example of the initial release I'm sorry for the uncompilable pseudo code. |
How to handle a proposal There are two important roles: member and administrator. The administrator is a group of members who have the power and responsibility to maintain the consistency of group status. Members (including administrators) drive group status changes by proposing to the administrator; The administrator synchronizes the group status to the local, and finally drives the application status display The specific flow chart is as follows |
How to view the state for groupGroup administrators maintain the consistency of their management state through BFT consensus. This state may be a tree aggregation state, called the root state. Only the root state can be verified directly, and its sub-state needs to be verified indirectly through the root state Any user with read permission can read the root status value and signature on the corresponding To which member to read the status, you can set a priority for exploratory polling. The flow chart is as follows: |
How to verify the stateConsidering that some members of the group may be malicious, the obtained status needs to be verified. The verification of the root state can be achieved only by verifying the signature rate of the corresponding block. The verification of sub-states is more troublesome. It is necessary to obtain all relevant sub-states on its relative path, and finally verify the root state obtained after the operation of these sub-states. For example, if you want to read the status of '/a/b/c', you need to obtain all sub-statuses directly under ['/a', '/a/b'], and finally find the value with key 'c' in all sub-statuses of '/a/b' There is the possibility of massive data sets, which will be a huge amount of computation and need further consideration. |
Draft for storage structureStorage for group-state:
And the cache storage in the DecAPP
The reader will read the state with the |
Show the definition of #[derive(Clone, Debug, RawEncode, RawDecode)]
pub enum GroupDescContent {
SimpleGroup(SimpleGroupDescContent),
Org(OrgDescContent),
}
impl GroupDescContent {
pub fn founder_id(&self) -> &Option<ObjectId> {
match self {
GroupDescContent::SimpleGroup(desc) => &desc.founder_id,
GroupDescContent::Org(desc) => &desc.founder_id,
}
}
}
#[derive(Clone, Debug, RawEncode, RawDecode)]
pub enum GroupBodyContent {
SimpleGroup(SimpleGroupBodyContent),
Org(OrgBodyContent),
}
impl DescContent for GroupDescContent {
fn obj_type() -> u16 {
ObjectTypeCode::Group.into()
}
type OwnerType = SubDescNone;
type AreaType = Option<Area>;
type AuthorType = SubDescNone;
type PublicKeyType = SubDescNone;
}
impl BodyContent for GroupBodyContent {
fn format(&self) -> u8 {
OBJECT_CONTENT_CODEC_FORMAT_RAW
}
}
#[derive(Clone, Debug)]
pub struct GroupMember {
pub id: ObjectId,
pub title: String,
}
#[derive(Clone, Debug, Default)]
struct CommonGroupBodyContent {
name: Option<String>,
icon: Option<String>,
description: Option<String>,
members: HashMap<ObjectId, GroupMember>,
ood_list: Vec<DeviceId>,
version: u64,
prev_shell_id: Option<ObjectId>,
}
#[derive(Clone, Debug)]
pub struct SimpleGroupDescContent {
unique_id: UniqueId,
founder_id: Option<ObjectId>,
admins: HashMap<ObjectId, GroupMember>,
}
#[derive(Clone, Debug, Default)]
pub struct SimpleGroupBodyContent {
common: CommonGroupBodyContent,
}
#[derive(Clone, Debug)]
pub struct OrgDescContent {
unique_id: UniqueId,
founder_id: Option<ObjectId>,
}
#[derive(Clone, Debug, Default)]
pub struct OrgBodyContent {
admins: HashMap<ObjectId, GroupMember>,
common: CommonGroupBodyContent,
} |
Maintain organization informationForm an organizationTo set up an organization in the
In addition to using the same methods as other objects for
Update organization informationThe method of updating the organization is the same as other mutable objects, updating
Similarly, we can use the
Examples are as follows:
The process of collecting signatures and uploading to the chain is the same as creating a Save different versions of
|
We need multiple users to collectively hold and maintain the same information, which is consistent among different members and can be verified.
The text was updated successfully, but these errors were encountered: