Instead of specific ad hoc mutable data types for each use case, variants of a common base type could be defined because many parts in their management don’t depend on the variant and only need to know the type tag, the xor name and the data part. But I don’t have a strong opinion on the matter, if Maidsafe prefers distinct types, then let it be.
Notes:
-
Version number is excluded from this base because in many use cases MDs don’t have a global version.
-
Owner keys are excluded from this base because in many uses cases the ownership unit is the individual value.
-
I have edited my proposal and changed the set of owners to only one owner in all but HistoricalData variant (I took model on current MD structure but I doubt that multi ownership can be handled without signatures).
PartialOwnership variant can be used when an initial owner creates a fixed set of related objects that can be transferred individually. At any point in time such an object has one owner. This owner can bring a modification in the data part. It can also decide to transfer the ownership to a new owner. Concrete examples are corporation shares, condominium units, pre-mined altcoins … anything that is collectively owned and that needs to record its individual owners. The key can identify the object in the real world (for example “flat 205”) or just express an abstract identification (for example “coin 198”). The data doesn’t play any role in the registry itself but can be useful for other purposes like personal data storage, or individual vote storage when a collective decision is to be made. In this variant, each unit weight can be handled implicitly with an agreed convention among the parties (for example flat 205 has 100 m2 living area and so has more weight than flat 206 that has only 75 m2).
DivisibleOwnership variant is a subcase of previous variant where each unit can be divided. It also handles units’ weight explicitly. In this variant, a key conveys both an abstract identification and a weight. One use case is land registry of a city which registers land plots that can be divided. Another one is divisible safecoins. The difference between the later and all the other use cases is mainly in the way they are created: safecoins are generated by the network whereas the others are created by users. After initial creation, users can transfer them, divide them and transfer the generated sub-parts in the same way. They can be deleted the same way, though in case of safecoins, the network can automatically trigger the deletion when the user stores a file in the network (but deletion is still controlled by the user public key).
HistoricalData variant is a totally different one. It describes the history of a single object: history of its modifications and of its owners. At any point in time such an object has a set of current owners. A majority of them can bring a modification in the data part. It can also decide to transfer the ownership to a new set of owners. The new version must be signed by all the new users and by a majority of previous owners. Contrary to other variants, no deletion is possible for this one (neither at the MD level, nor at the value level). The use case for this variant is legal applications like a notary service that registers the successive owners of an object. It can be a real-world object like a real estate but not necessarily: an altcoin could use this variant for users wanting traceability of transactions.