Crate structured_data [] [src]

Example of Proposed Structured Data for the SAFE Network

This is an extension of the proposed implementation described in RFC 0000. It conflicts with the "Detailed Design" section, but is in alignment with the other main sections of the RFC.

It may be helpful to view the raw source either on GitHub or in the docs while reading this, since it shows all the elements together in one place.

The main differences between the original proposal and this are:

This proposal is slightly more complex than the original, but not largely so. This added complexity provides greater ease of use and extensibility of rules.

Authorisation of Mutating Requests

This is more flexible than the process described in the original proposal. The idea is that each owners' public key is given a weighting. To authorise a mutation, enough signatures must be provided so that the combined weight of the corresponding public keys exceeds a limit. The limit can itself be changed via an authorised request.

This basic system works well for a single owner (where the calculation is almost a no-op), but also is fairly simple to understand in the case of multiple owners. The rules for the network to implement this are as simple as in the original proposal, and the cost in terms of data size is minimal; a u64 plus another u64 per owner. For a single owner, both of these elements could be removed from the serialised Data, giving no additional cost.

I have also not included the signatures as part of the Data since these only need to be examined by the network at the point when the Data is mutated, i.e. when the request is received. This may be an oversight though, in which case they can be added where required.

Immutable Part of Data

The FixedAttributes are immutable for the lifetime of the Data. As well as the original type_tag and id whose meanings are unchanged, I have added the following fields:

Mutable Part of Data

The MutableAttributes can be changed if enough owners sign a request to change them. Such a request would need to also come with an incremented Version to avoid synchronisation issues.

The owner_keys and min_weight_for_consensus relate to the authorisation process described above. The remaining fields are:


Another major departure from the original proposal is to hold a Vec<Version> rather than a single one. This would comprise the most recent versions, but may be only one if FixedAttributes::max_versions == 1 or may be all versions if total Data size permits.

In at least two of our own use-cases (session packet and directory listings), we need to be able to store and retrieve more than just the most recent version. This can be done in the original proposal by serialising this information into the single data field, but this proposal makes that task more obvious and less error-prone.

Furthermore, by exposing the versions in this way, it leaves scope for the network to be able to handle archiving old versions without any client interaction. This wouldn't be possible if the network weren't able to access the list of versions, as is the case in the original proposal.

The Version struct comprises two elements:


There would still be a hard upper limit on the total size of a Data instance as described in the original proposal.

While some of the rules can be ignored in the initial implementation of this (e.g. handling archiving) I don't envisage this being more difficult to implement than the original proposal. This also leaves room for eventual improvement in efficiency, for example by allowing clients to send only a new Version rather than always sending a full Data packet.



Structured Data implementation.