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 an OwnIdentityAttribute. It is created for the Identity’s private repository of Attributes.
When sharing an OwnIdentityAttribute with a peer, associated AttributeForwardingDetails are created.
Receiving a shared IdentityAttribute from a peer leads to the creation of a PeerIdentityAttribute with according content for the Recipient.

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 an OwnIdentityAttribute

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 an OwnIdentityAttribute.

In the following examples, some properties of the occuring LocalAttributes will be omitted if they aren’t required for the explanation.

Now, in order to share an OwnIdentityAttribute, you need to send an according Request to the peer you want to share it with. If they accept your Request, a new PeerIdentityAttribute will be created at the peer’s side. This PeerIdentityAttribute has the same content like your OwnIdentityAttribute and, in addition, defined peer and sourceReference properties. They store 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, AttributeForwardingDetails associated with your OwnIdentityAttribute will be created at your side. They store the same sourceReference and the peer’s address.

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

Succeeding an OwnIdentityAttribute

Next, let’s consider the case that the value of your IdentityAttribute changes and you want to update it. To succeed the OwnIdentityAttribute, a new OwnIdentityAttribute 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 an OwnIdentityAttribute created by Attribute successions make up a doubly linked list.

Notifying a peer about an OwnIdentityAttribute succession

After succeeding an OwnIdentityAttribute, 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. AttributeForwardingDetails associated with the successor will be created for each chosen peer. Then, a Notification is sent to the peers, containing a PeerAttributeSucceededNotificationItem. 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 PeerIdentityAttribute 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. The LocalAttribute of the owner is an OwnRelationshipAttribute and the peer’s LocalAttribute is a PeerRelationshipAttribute.

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, a PeerRelationshipAttribute with the RelationshipAttribute as content will be created at their side and, after you receive their Response, an OwnRelationshipAttribute will be created at your side. Hence, you and your peer will always have an identical shared RelationshipAttribute, only differing in the 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 OwnRelationshipAttribute will be created at your side. The succeeds property of this OwnRelationshipAttribute 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 PeerRelationshipAttribute at their side, such that their PeerRelationshipAttribute 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