Starsheep fully bases on dinemic framework and is its extension enabling model, listener and data definition with YAML. Before you jump into designing your own applications, check this five rules:
1. Data triggers action
In common applications you design URL for API, which is connected to logics, which checks all permissions and updates data model.
In Dinemic and Starsheep you define data model and connect listeners which should be performed after data change, or just to prevent data modification
2. Keys are for everything
All objects created with Dinemic or Starsheep have assigned cryptographic keys. All object IDs are related to public keys of object. All changes made in data are digitally signed by keys related to objects which are acting as author of change.
3. Changes are verified everywhere
If change in database is broadcasted, there is no central authority to say that it is valid. Instead, data model and Dinemic defines (by reject listeneres) what changes should be applied on local copy of database and which not. This causes that any subset of nodes, of cluster will work independently with ability to succesfully verify new changes, even without presence of changed object owner.
4. Data triggers action everywhere
Once you create object in Dinemic or Starsheep, it is known everywhere. Dinemic broadcasts information about this object to all peering nodes. Difference between your machine and others is object’s private key. Only machine, where obejct was created has its custom private key related to object. Each object of model in Dinemic and Starsheep will have individual private key.
If update is done, it is signed by digital keys. Broadcasted changes are constantly being processed by all nodes in network. That is why it is so important to store up-to-date yamlm on all nodes at the same time.
If change arrives to any node, it triggers action. On every single node. It is your responsibility to decide if such change should be applied locally do the database, or if it is necessary to perform some actions on your local resources.
5. Permissions are based on cryptography
If object is authorized to make changes in another one, it means that any change made by this object in another will be digitally signed and verified by all nodes.
If any update is signed by unknown key or not listed in authorized keys, related to object, it will be considered as unsigned.
Again, it is your responsibility to define which updates could be applied, by defining custom model’s fields.
Read permissions are realized by encrypting model’s data by set of cryptographic keys related to read authorized objects.
And one more…
Starsheep application definition in YAML defines how data model should behave, with its listeners. It should be the same everywhere unless you know what you are doing.
Starsheep data definition in YAML injects certain objects into database. It doesn’t have to be same everywhere. It could be related to your node or role.