Shell for mutable object

[streetycat]

I have a scenario where upgrading a mutable object is a process where there may be an old version object and multiple updating objects at the same time, which is not possible in the current NOC system.

So, I want to design a shell that has the following properties:

1. Different object versions with the same ID are wrapped with a shell and constructed into a new shell object;
2. Different versions of objects have different shell object IDs, which can be stored independently in NOC;
3. The body/signature/nonce sections can decide if they lead to new shell construction according to the scenario:

• A new shell is generated only when body changes. At this time, you can add a signature to the original object, but continue to store it in the old shell
• Adding and subtracting signatures also generate new shells
• nonce changes also generate new shells

[streetycat]

This is the storage requirement for an object.

So, I think we could extend the Storage object to be able to contain both an immutable and mutable part:

// StorageObject
message StorageDescContent {
    string id = 1;
    optional bytes hash = 2;
}

message StorageBodyContent {
    bytes value = 1;
    optional bytes freedom_attachment = 2; // content without hash, you can update it with the same hash in `Desc`;
}

And, we can implment a structure for ObjectShell based on Storage:

pub struct ObjectShell<O> {
    raw: O;
    flags: u8; // FLAG_SIGNATURE_FREEDOM | FLAG_NONCE_FREEDOM
}

impl ObjectShell<O> {
    pub fn from_storage(storage: &Storage) -> BuckyResult<Self>;
    pub fn to_storage(&self) -> Storage;
    pub fn shell_id(&self) -> ObjectId;
    pub fn from_object(obj: O, flags: u8) -> Self;
    pub fn as_ref(&self) -> &O;
    pub fn as_mut(&mut self) -> &mut O; // update the raw object
}

impl RawEncode for ObjectShell {
    fn raw_encode(&self, buf: &mut [u8]) -> BuckyResult<&mut [u8]> {
        let mut raw = self.raw.clone();
        if self.flags & FLAG_SIGNATURE_FREEDOM {
            raw.clear_signatures();
        }
        if self.flags & FLAG_NONCE_FREEDOM {
            raw.clear_nonce();
        }

        let value = self.flags + raw.encode(); // save unfreedom fields in value, and check it with the Storage.hash;

        let freedom = ${exist_freedom_field_flags} // freedom and exist fields
            + [self.raw.signature] // signatures if freedom and exist, otherwise is none
            + [self.raw.nonce] // nonce if freedom and exist, otherwise is none
    }
}

impl RawDecode for ObjectShell {
    fn raw_decode(buf: &[u8]) -> BuckyResult<&[u8]> {
    }
}

[lurenpluto]

How does the cyfs-stack store multiple versions of the same object locally? According to our design principle, different versions of an object refer to different versions generated after the body is modified, identified by the body_hash_value. That is, for objects with a mutable body, object_id + body_hash_value identifies a specific version.

The storage principle for multiple versions of objects with mutable bodies is as follows:

1. The internal noc of the stack can and should only store one version, usually the latest version.
2. Multiple versions of an object can exist on the Meta chain, which can be queried via object_id + body_hash_value.

So the addition of a ShellObject object you mentioned to implement local noc storage of multiple versions is theoretically feasible. I have a few questions and suggestions for your reference:

1. Should the desc of the ShellObject include the desc and body of the object, with the signature and nonce fields included within the desc (thus encompassing the entire object), or should they be stored separately in the corresponding signature and nonce fields of the ShellObject?
2. How can a specific version of an object be quickly found using object_id + body_hash_value? If the object_id of the ShellObject can be calculated from this keypair, it can be easily found. So it seems that the desc of the ShellObject should only include the following two fields for better efficiency
   • object_id
   • body_hash_value

[streetycat]

How does the cyfs-stack store multiple versions of the same object locally? According to our design principle, different versions of an object refer to different versions generated after the body is modified, identified by the . That is, for objects with a mutable body, identifies a specific version.body_hash_value``object_id + body_hash_value

The storage principle for multiple versions of objects with mutable bodies is as follows:

1. The internal noc of the stack can and should only store one version, usually the latest version.
2. Multiple versions of an object can exist on the Meta chain, which can be queried via .object_id + body_hash_value

So the addition of a ShellObject object you mentioned to implement local noc storage of multiple versions is theoretically feasible. I have a few questions and suggestions for your reference:

1. Should the desc of the ShellObject include the desc and body of the object, with the signature and nonce fields included within the desc (thus encompassing the entire object), or should they be stored separately in the corresponding signature and nonce fields of the ShellObject?
2. How can a specific version of an object be quickly found using ? If the object_id of the ShellObject can be calculated from this keypair, it can be easily found. So it seems that the desc of the ShellObject should only include the following two fields for better efficiency
   object_id + body_hash_value
   • object_id
   • body_hash_value

// StorageObject
message StorageDescContent {
    string id = 1;
    optional bytes hash = 2;
}

message StorageBodyContent {
    bytes value = 1;
    optional bytes freedom_attachment = 2; // content without hash, you can update it with the same hash in `Desc`;
}

As the extended Storage, the desc.hash is for body.value, it will verify the body.value.
So I'll save the encoded buffer in body.value, it will include the desc and body, and the Signatures or Nonce is optional by configure in flags.

If the Signatures or Nonce is not saved in body.value, It'll encoded in body.freedom_attachment, We can change them without update the ObjectId of the ObjectShell.

I think is a bad idea to save the Signatures in the fields for ObjectShell, According to existing semantics, it should be the signatures for ObjectShell, not for the orignal object.

[streetycat]

And, save the ObjectId of the orignal object in StorageDescContent.id. The developer should organize these different versions and retrieve.

We can implement a common system to organize it when it is used frequently, but it's not necessory currently.

We just need to define the structure for these future needs.

[lurenpluto]

I have a scenario where upgrading a mutable object is a process where there may be an old version object and multiple updating objects at the same time, which is not possible in the current NOC system.

So, I want to design a shell that has the following properties:

1. Different object versions with the same ID are wrapped with a shell and constructed into a new shell object;
2. Different versions of objects have different shell object IDs, which can be stored independently in NOC;
3. The body/signature/nonce sections can decide if they lead to new shell construction according to the scenario:

• A new shell is generated only when body changes. At this time, you can add a signature to the original object, but continue to store it in the old shell
• Adding and subtracting signatures also generate new shells
• nonce changes also generate new shells

Is there a contradiction between the two you mentioned?

1. A new shell is generated only when body changes
2. signature and nonce changes also generate new shells

[streetycat]

I have a scenario where upgrading a mutable object is a process where there may be an old version object and multiple updating objects at the same time, which is not possible in the current system.NOC
So, I want to design a shell that has the following properties:

1. Different object versions with the same ID are wrapped with a shell and constructed into a new shell object;
2. Different versions of objects have different shell object IDs, which can be stored independently in NOC;
3. The /signature/ sections can decide if they lead to new shell construction according to the scenario:body``nonce

• A new shell is generated only when changes. At this time, you can add a signature to the original object, but continue to store it in the old shellbody
• Adding and subtracting signatures also generate new shells
• nonce changes also generate new shells

Is there a contradiction between the two you mentioned?

1. A new shell is generated only when body changes
2. signature and nonce changes also generate new shells

They are to two different scenarios, it will be adapted to one of the scenarios by configuring.

[streetycat]

Anyone can pay attention at this issue