Thank you, @tfa, these are really interesting proposals and use case. I need some more time to think about them, but especially the idea of using keys to divide a bigger entity into smaller is an interesting approach.
At this very moment we have only modelled MData with the idea of creating share-ability for multiple apps (hence the name appKeys at some places) and restricting on a feature level (rather than on a per-key-level) with the shared-folder-of-pictures-idea in mind. But you certainly raise some interesting features.
I am wondering if it’d be possible to have a high-level abstraction emulating of this behaviour on top of the currently proposed MData first though. That’d make it easier for us to test this and built some concrete use cases to gain a better understanding and more insight of the actual requirements of such a solution (before trying to built it into the network). What do you think would be a simple real world example that could be developed as an app and might be possible to test such an emulation?
Safecoins divisible down to 1/100 safecoins could be used as an example (a simpler variant of Using new (modified) MData to Model Safecoin). Emulation with current MDs could be done by replacing values of the proposal with MDs whose name is the hash of a serialized triplet containing:
coin number (a random number generated by the app)
fraction lower limit
fraction upper limit
For example, (1389, 0, 99), would represent a whole safecoin and (1389, 5, 11) would represent a 7 cents fraction of this coin
The correspondence between the proposal and the emulation would be:
| Concepts | Proposal | Emulation |
|------------------|-----------------|-------------|
| Creation control | by vaults | by app |
| Division control | by vaults | by app |
| Transfer control | by vaults | by vaults |
| Fraction storage | a value of a MD | a whole MD |
| Fraction owner | Owner of value | Owner of MD |
The obvious limitation of emulation is that the app can generate any number of coins. Also, an external malicious program can easily disrupt the coin database by creating overlapping fractions. But divisions and transfers initiated by the app itself should be OK.
Edit: When the app creates a safecoin, it should check that no fraction containing 0 as lower bound exists: meaning issuing 100 gets from (coin#, 0, 0) to (coin#, 0, 99). That should be “enough” because IIRC MD deletion has not been implemented.