Under development
The item concept is a very common. It is a random data, stored in the Attesta cloud. Most evident samples are: communication block (tagged as comm
), send between parties, or keys registry (see [registration]).
Receiving items are packed in the Item
object with following properties:
id
is a unique identity for any Item in the attesta could. It never changes.
readonly
true means that it can not be changed and only unlined (see below) removed, what means for other sharing parties it will not be changed.
created_at
creation timestamp. As JSON has no timestamp data type, it is presented in
Typed JSON format.
updated_at
last update timestamp.
expires_at
expiration timestamp. After expiration time the object is not valid and should be removed by all clients from all storages. Note, that if expiration is not set, the system defaults it to 5000 years from creation. The advanced investigation of the future shows that such a limitation will allow attesta to function at least during 10k years, after what our distant descendants will surely upgrade this code.
tag
item tag means its purpose. comm
for example means that this is communications between parties. Tags are used to get only subset of objects stored in the cloud. See tags section below.
serial
constantly growing serial number that grows across all Items. If the Item will be updated, its serial
will become larger (to some random increment). As it always grow and is always different, it simplifies getting new and updated items by specifying last known serial
.
data
the data itself. It is almost always the standard attesta protected block, signed and encrypted, and absolutely unavailable to the server stuff. As JSON has no type for binary data, it is also encoded as Typed JSON.
Note, that we normally use BOSS format to transfer the data where all these types are supprted natively and effectively. Also, there is another type conventions for XML format.
{
"id": 79,
"readonly": false,
"created_at": {
"__t": "time",
"__d": 1480377870
},
"updated_at": {
"__t": "time",
"__d": 1480377870
},
"expires_at": {
"__t": "time",
"__d": 95617584000
},
"tag": null,
"serial": 90,
"data": {
"__t": "b64",
"__d": "ZHVtbXkgcmVxdWVzdCBjb25uZWN0aW9uIGRhdGEgb2YgaW1wcm9wZXIgc3Ry\ndWN0dXJl"
}
}
<item>
<id type="integer">101</id>
<readonly type="boolean">false</readonly>
<created-at type="dateTime">2016-11-29T01:14:15Z</created-at>
<updated-at type="dateTime">2016-11-29T01:14:15Z</updated-at>
<expires-at type="dateTime">5000-01-01T00:00:00Z</expires-at>
<tag>comm</tag>
<serial type="integer">114</serial>
<data type="b64">
ZHVtbXkgcmVxdWVzdCBjb25uZWN0aW9uIGRhdGEgb2YgaW1wcm9wZXIgc3Ry
dWN0dXJl
</data>
</item>
The binary, most commonly used representation. It is not humand-readable, so there is no example here, but bit- and cost-effective. See BOSS for more.
Tags allow application to get subset of all stored information from the attesta cloud. For example, communication program can limit its access to the comm
objects, while the enhanced application might also keep notes and even photos in the could and use different tags to not to mess up with others.
Tag values with fixed purpose:
tag | purpose |
---|---|
comm | communication block of any type: message, contact request (aka HELLO block), group message, and lile |
registry | special record. Only one object of this type exist for each party. It holds encrypted keyring of a party and allow password based login for it |
items_load(after_serial: 0, tags: ['comm'])
-> { items: [{ item, ... }], has_more: <boolean> }
This function get a portion of new and updated items with specified tags. The application should pump updates calling this method until there is no more queued items.
after_serial
: only items with serial
bigger than this will be included.
tags
: array of at least one tag string.
has_more
: true means that there are more items to pump out. Adjust after_serial
and call it again.
Returns the array of items as described above. The number of returned items varies and depends on the item size and server load.
There is a way to store and retreive data from attesta clould much like the usual cloud, but with very primitive set of functions, because unlike usual cloud storages Attesta can not access the stored data, therefore it can not organize and analyze it, search it and all other nice modern functions. This is the price of your privacy.
This API is to be descibed.
Items could be sent and received using connectors. This way all communications work in Attesta.