Update Attributes by succession

The way enmeshed handles updates to your personal data is by succeeding old Attributes with new ones. Instead of simply replacing old data, a completely new Attribute is created which succeeds its predecessor. Thus, you and your peers are provided with a coherent history of all past versions. How the Attribute succession works in detail depends on the type of Attribute.

Succeeding own IdentityAttributes

When talking about IdentityAttributes, we need to distinguish three cases:

The Identity maintains an unshared Attribute about itself. This IdentityAttribute is stored in the content field of a LocalAttribute, whose shareInfo is undefined. Since this LocalAttribute is created for the Identity’s private repository of Attributes, it is referred to as RepositoryAttribute.
When sharing a RepositoryAttribute with a peer, a copy of the IdentityAttribute is created for the Sender and stored in the content field of a LocalAttribute with a defined shareInfo. We call this LocalAttribute an own shared IdentityAttribute.
Receiving a shared IdentityAttribute from a peer leads to the creation of a LocalAttribute with according content and a defined shareInfo for the Recipient. We call this LocalAttribute a peer shared IdentityAttribute.

Discussing the succession of IdentityAttributes requires some background knowledge about this differentiation and the behavior of shared Attributes. Hence, we will look at the process of creating, sharing and succeeding an IdentityAttribute step by step.

Creating a RepositoryAttribute

enmeshed allows you to store data about yourself in the form of IdentityAttributes. When creating an IdentityAttribute, it is not necessary to share it immediately with a peer. Instead, it will be stored in the content property of a LocalAttribute with an undefined shareInfo. We refer to these unshared LocalAttributes as RepositoryAttributes, since they make up your private repository of Attributes.

In the following examples, the createdAt and deletionInfo properties of all occuring LocalAttributes is omitted, since they aren’t required for the explanation.

Now, in order to share a RepositoryAttribute, you need to send an according Request to the peer you want to share it with. If they accept your Request, a new LocalAttribute will be created at the peer’s side. This peer shared IdentityAttribute has the same content like your RepositoryAttribute and, in addition, a defined shareInfo property. It stores the address of the peer who shared the Attribute with them, i.e. the address of your Identity, and a reference to the Request that was used to share the Attribute. Receiving the Response, an own shared IdentityAttribute with equal content will be created at your side. Its shareInfo stores the same requestReference and the peer’s address, as well as the id of the RepositoryAttribute, whose content was copied, in the field sourceAttribute.

Concluding, sharing an IdentityAttribute will create an own shared IdentityAttribute copy for every peer you shared the Attribute with at your side and a peer shared IdentityAttribute copy for each peer at their side.

Succeeding a RepositoryAttribute

Next, let’s consider the case that the value of your IdentityAttribute changes and you want to update it. To succeed the RepositoryAttribute, a new LocalAttribute with the updated content will be created. This successor stores the id of the old version, the predecessor, in its succeeds property. The predecessor is updated, too, such that its succeededBy property links to the successor. Consequently, the different versions of a LocalAttribute created by Attribute successions make up a doubly linked list.

Note: During the succession of a complex IdentityAttribute implicitly all its children will be succeeded, so it isn’t possible to succeed a child of a complex IdentityAttribute on its own.

Notifying a peer about a RepositoryAttribute succession

After succeeding a RepositoryAttribute, you can check with which of your peers you have previously shared the succeeded Attribute to choose those, you’d like to notify about the succession. Your own shared IdentityAttributes associated with the peers chosen will be succeeded in the same manner as your RepositoryAttribute before. Then, a Notification is sent to the peers, containing a PeerSharedAttributeSucceededNotificationItem. In the successorContent property of the latter the updated IdentityAttribute is transmitted and automatically a likewise succession at the peers’ side will be triggered, such that their LocalAttribute versions replicate the succession chain at your side. Please note that the Notification is queued if the Relationship is currently terminated but not yet decomposed. It can then only be received and processed if the Relationship is reactivated. The Notification is also queued if the peer is currently in deletion but not yet deleted. It can then only be received and processed if the peer cancels its deletion.

Succeeding own RelationshipAttributes

RelationshipAttributes are, as the name suggests, always associated with a Relationship. Thus, it is not possible to have unshared instances of them. Instead, you and your peer will always each have a LocalAttribute with the same RelationshipAttribute as content. We refer to the LocalAttribute of the owner as own shared RelationshipAttribute and to the peer’s LocalAttribute as peer shared RelationshipAttribute.

Wanting to create a RelationshipAttribute always involves sharing it directly with a peer. To this end, a Request containing a CreateAttributeRequestItem with the RelationshipAttribute will be created and will be sent to the peer. Only if the peer accepts this Request will a LocalAttribute with the RelationshipAttribute as content be created at their side and after you receive their Response, at your side, too. Hence, you and your peer will always have an identical shared RelationshipAttribute, only differing in the LocalAttribute’s shareInfo.peer property.

Succeeding a RelationshipAttribute and notifying the peer

Equally to IdentityAttributes, again only the owner can succeed a RelationshipAttribute to update its value. Doing so, a new version of the own shared RelationshipAttribute will be created at your side. The succeeds property of this LocalAttribute links to the old version, whose succeededBy property in turn is updated to the id of the newly created successor. Then, a Notification is sent automatically to the peer, which triggers the creation of a new peer shared RelationshipAttribute at their side, such that their LocalAttribute versions replicate the succession chain at your side. Please note that the Notification is queued if the Relationship is currently terminated but not yet decomposed. It can then only be received and processed if the Relationship is reactivated. Furthermore, the Notification is also queued if the peer is currently in deletion but not yet deleted. It can then only be received and processed if the peer cancels its deletion.

What’s next?

As we have seen, succeeding an Attribute allows you to mark a version of the Attribute as outdated and lets you specify an updated version that is to be used instead. However, you might also find yourself in a situation where you want to delete an Attribute altogether. To do so, proceed as described in the guide on how to delete Attributes.

Integrate enmeshed