Automatic reading / saving of values?!

[kulla]

My current understanding is that enmeshed is like a key-value store. However each read / write operation must be accepted by the user. When for example a service wants to read a value it needs to send a AttributesShareRequest wrapped inside a RequestMail which need to be accepted (even when the service already has a permission for reading the value due to the onboarding). The same is true for writing a value. Here a AttributesChangeRequest need to be send inside a RequestMail which the user need to accept in the app. Is my understanding correct?

We think about storing learning outcome data in the enmeshed app. In this scenario there would be a lot of read / write operations with hopefully many services involved. Here I see obstacles when the user needs to accept each of the operations:

• Let's say we want to use stored learning outcomes to show next learning items for the user (e.g. the navigation should change due to the competencies a person already has required or there is a recommendation service). Then we would need to read the current learning status each time the user opens the navigation / wants to learn something new. It would be tedious for the user when he / she needs to accept the read operation each time.
  • A solution would be to cache the list of already required learning outcomes. However then we would need mechanisms to keep the cached value in sync with the enmeshed value especially when many services write to the same attribute. This would also mean that private data (=the list of required learning outcomes) need to be stored longer at the learning services than the user uses the page.
• The actual value will be cryptic to normal users (long and complex JSON structures for example). Will they be able to decide whether a value should be stored in the app or not? What will happen when a user acquires many learning outcomes at a session? For example a session with solving 10 exercises would result in 10 AttributeChangeRequest messages. What happens when a user does not accept all of them? What happens when a user accepts a message days later after he has used other services in the meanwhile? How can we make sure that write operations will not get lost?

Some of the above obstacles might be avoidable when a read / write operation is instant in case a service already has a read / write permission for it. What do you think about this? Is this already on the roadmap? (However when many services write to the same attribute I think we will need merge / sync algorithms for storing conflicting data anyhow)

[jkoenig134]

We are currently planning / implementing a bunch of features that will help for some challenges you describe.

1. The connector will get routes for managing Attributes of Relationships and Requests. Accepted AttributeChangeRequests will automatically appear in these Attribute routes.
2. Sharing of changed Attributes that was shared with Relationships before. This will ask the User to share a changed Attribute to all Relationships with that the user have shared these Attributes before. We also have on our list that this process can be automated if the user configured it.

The Attribute management will generally get heavy changes, we know that it isn't perfect ATM.

[kulla]

The connector will get routes for managing Attributes of Relationships and Requests

What does this mean? Is a route a way to read an attribute so that after an AttributeChangeRequest was accepted the connector has always access to the attribute value?

Another question: Is there a roadmap available? (I am interested in the possible future features of enmeshed so that we can better decide for which use cases we can use it, it is not urgent though...)

[jkoenig134]

Yes thats the plan, that routes will manage peer Attributes and maybe one time your own Attributes like in the Enmeshed-App.

No, ATM there is no public roadmap available, but we are planning to create one.