Personal Data Stores (PDS) like SoLiD is an emerging data and knowledge management solution in recent years. They promise to give back ownership and control of data to the user, and provide protocols for developers to build applications using the data. However, existing Solid-based applications often focus on using a single-user's data. In this article, we use a simple but realistic calendar-and-meeting-scheduling scenario to demonstrate the feasibility and design considerations for enabling cooperative data-use across multiple users' SoLiD Pods. This scenario identifies the bottleneck for certain cooperative use cases, namely those involving ofline-changing and synchronization of knowledge information. We demonstrate a viable approach to mediate this issue, introducing a long-living thin service, the orchestrator. We describe our implementation and discuss its applicability to other ecosystems. We conclude by discussing the implication of such services, in particular their risks and challenges for building decentralised applications.
condition through analysing many ‘gig’ workers’
individual pay rates[
With the increasing awareness of the importance and We argue that the realization of cooperative data use
value of personal data, legal and technological solutions raises not only privacy challenges but also a series of
are being pushed forward for supporting such concerns practical design challenges. In this paper, we will use a
of the individuals, such as the EU GDPR [
However, research and applications ([
Trusting Decentralised Knowledge Graphs and Web Data Workshop, to schedule events (especially meetings) with others by aGtrEeeucreopean Semantic Web Conference, May 28 - June 1 in Hersonissos, ifnding joint availability of time slots, which requires $ rui.zhao@cs.ox.ac.uk (R. Zhao); jun.zhao@cs.ox.ac.uk (J. Zhao); sharing some information from everyone’s calendar. ExZ.Zhou-45@sms.ed.ac.uk (Z. Zhou) isting calendar services often support this requirement by https://renyuneyun.github.io/ (R. Zhao) allowing the sharing of the original and the busy-or-free 0000-0003-2993-2023 (R. Zhao); 0000-0001-6935-9028 (J. Zhao)
© 2023 Copyright © 2023 for this paper by its authors. Use permitted under Creative Commons projection of the calendar.
CPWrEooUrckReshdoinpgs IhStpN:/c1e6u1r3-w-0s.o7r3g LCicEenUseRAttWribuotironk4s.0hIontpernPatrioonacl e(CeCdBiYn4g.0)s. (CEUR-WS.org) The situation will be similar to store calendar data in
the active party to find the availabilities (and make the decision), and others receive the decision, assuming the calendar information already exists. We call the active party the activist while the rest the passivists.
In existing centralized calendar systems, to find the joint availability, the users need to: data store (i.e. Pod). In this context, most steps can be mirrored, where the activists and passivists are the Pod owners, and sharing of calendar is the sharing of the calendar resource. An advantage for SoLiD storing data in Linked Data format is that one can organize/advertise their calendars together, and share that to others, instead of sharing each calendar separately, given an agreed common schema2.
However, there is a problem for Step 5 and 6 in SoLiD or other similar systems: where should the activist send the meeting information to, and how can the calendar information be merged to the calendar information in the passivist’s Pod while ofline (i.e. no App open)?
This is not a consideration in centralized settings,
be1. (Passivists) Share all calendars to each other user cause the central service will always be online (or no
who may schedule meetings with them; service) and can receive and operate on behalf of the
2. (tAhecmti v;ist) Import others’ calendars shared to
epmnaesdrsagirviniosgftsto.hfTeinhpceaorsemsfioivnriesg,tsmt,heeisveteoinnnlgwinihneefsonerrtmvhiaectyeioacnraenwohiflitanhnet.dhBleeuctthael3. (Activist) Update their local cache (of everyone’s this does not hold in SoLiD or other decentralised data
calendar) to the latest; architectures, which are designed with general
mecha4. (Activist) Look at the calendars and find the joint nism as data and information stores, not specialized for
availability; calendar actions.
5. (Activist) Sends the meeting information to all The mechanism in SoLiD for dealing with incoming
passivists; information is to use the inbox, a dedicated location for
6. (Passivists) Update their calendar with the re- others to write/append information to, implementing
ceived information. the Linked Data Notification (LDN) specification [
However, it is a generic mechanism – the Pod will only store the notification to the inbox, and processing of such information is due to the specification of each App. This routes back to requiring the Pod owner to be “online” (having appropriate App opened). Therefore, for the meeting notification, this mechanism does not help when a passivist is ofline.
There are naive solutions such as giving write permission to the calendar information directly to the activists, or giving everyone read permission to the inbox. However, they can easily form a bad pattern as there are many potential activists, which may result in malicious or incorrect writing due to various reasons, or reading sensitive notifications in the inbox from other applications. Trusting many users and keeping data privacy and integrity forms a challenge.
The problem becomes more complicated if we also consider a hybrid or transitional scenario, where both existing (centralized) calendar services and decentralized data architectures like SoLiD are used simultaneously.
This may be inevitable for the time being because some existing workflow or tools only integrate with the centralized calendar services. This is also the requirement to avoid a cold-start of decentralized data architectures.
In this scenario, one must keep synchronization of the
on relevant actions, where in practice not all steps need to be repeated every time (i.e. Step 1 & 2) and some steps are usually automated (i.e. Step 3, 5 & 6). In particular, Step 5 and 6 are critical for meeting scheduling if multiple activists want to schedule meetings while the passivist is ofline, otherwise there can be a clash in slot selection by the diferent activists.
In practice, Step 1 and 2 both involve manual actions and can be boring and time-costing simultaneously, if the user has many calendars and there are many participants; it will also need to be repeated when a new participant joins. Some (third-party) services exist (e.g. Doodle1) to simplify this process. Their working model mainly involves requiring every user to deposit their calendars to this service, and share or compute internally the time slots. Basically, this keeps a local (to their service) copy of the original calendars and maintain sharing and permission within the (third-party) service itself. This poses a potential privacy concern, as well as a redundancy of data.
Assume that a Solid Calendar App exists that provides individuals to manage their calendar data stored in their 1Doodle: https://doodle.com/ 2To simplify the discussion, we assume there is one combined calendar information entry for each Pod owner. calendar within their Pods and that in external calendars the companion App for registering users to the orches(and gradually migrates to Pod-only scenarios). They give trator and creating configuration files in the Pod. This permission and use calendar App as above. But instead works for scenarios even when an actor is doing actions of storing the meeting information in their Pods, they based on information in external calendars and another must also store the information to the external calendar. doing actions based on information in the Pod. This would keep compatibility and solve the cold-start The main advantage is that the write operation is only issue simultaneously, but also poses challenges on the performed by the orchestrator, so the user only needs to synchronization mechanism while the user is ofline. trust it, rather than everyone as in the naive solutions;
Thus, we observe the requirements to enable this coop- in the meantime, the orchestrator does not have write erative data usage involving updating data in passivists’ permission to external calendars, so it will never pollute Pod: 1) enable access control of calendar data; 2) inter- the information source even if becoming malicious. If for operate with existing calendar systems; 3) maintain the some reason the orchestrator becomes malicious or not calendar in synchronization, even when the passivists functioning, the user can simply revoke the permission are ofline. Requirement 1 is already supported by Solid, on its own Pod; de-registering on the orchestrator is and the rest needs to be address properly. not indispensable for the user to block access from the orchestrator.
Because the orchestrator has a clear role and function3. A solution using orchestrator ality, it is easy for others to provide alternative orchestrator services for competition, or the calendar owner We propose to use a dedicated long-living thin service, to self-host. This is the possibility that decentralization called the orchestrator3, to mitigate this issue. The or- and openness brings. The competition may bring multichestrator is dedicated to one main functionality: to fetch ple benefits, in particular stimulating the orchestrator to and transform (external) calendars into the calendar in- provide better and trustworthy service in the long run, formation stored in the user’ Pod. and to prevent vendor lock-in of a particular orchestrator provider thus centralization back to the orchestrator 3.1. Orchestrator in the hybrid scenario provider.
Putting them together, by introducing the orchestrator, the user only needs to trust one agent rather than a large number, controls the critical permission from the Pod, and can switch the orchestrator provider easily. We believe this is a sensible approach with limited drawback to tackle the problem.
where the external calendars are the main source of the calendar information in the Pod; later we will discuss how it works for other scenarios, in particular the SoLiD-only scenario.
With the orchestrator, the users still need to grant relevant permission and share information. In the meantime, the relevant synchronization and transformation jobs 3.2. Implementation with Knoodle are performed by the orchestrator. In particular, as the We implemented an alternative version of Knoodle4 with external calendars are the main source, the orchestrator the orchestrator5. Knoodle is a SoLiD App for calendar fetches the specified external calendars, combines them, viewing and meeting scheduling, originally developed by and stores them into user’s Pod. They are controlled by the Ghent University. Our version keeps Knoodle as the the configuration specified by the user, stored in their core user-facing App for meeting scheduling, but also Pod. developed the orchestrator to accomplish the full picture,
When scheduling a meeting, the activist picks the time as reflected from Figure 1. We also did some functionality slot, and sends them through the external centralized and UI improvements, which are omitted in this paper. calendar services. The orchestrator will later pick this In the original version, a modified server implementaup, and synchronize them into the passivists’ Pods. This tion (based on Community Solid Server, CSS)6 was used. mechanism can also be extended to the inbox-based sce- It serves a very similar purpose to the orchestrator, and nario, as to be discussed later. performs real-time fetching and transformation of ex
Figure 1 illustrates the architecture and working pat- ternal calendars upon request. But it is configured and tern for using the orchestrator, based on our current tightly coupled with the SoLiD service itself. In particuimplementation. KNoodle is the relevant calendar and lar, the user needs to modify the service’s configuration meeting scheduling App; the Orchestrator Configurer is 3Sande et al proposed the concept of orchestrator as an autonomous agent based on triggers; we borrow the name. However, they did not discuss the necessity of orchestrators in depth, and it lacks a direct way of supporting the calendar case discussed in this paper.
5Calendar Orchestrator https://github.com/renyuneyun/ calendar-orchestrator 6Solid Calendar Store https://github.com/KNowledgeOnWebScale/ solid-calendar-store RSecqhueedsutlecamleenedtianrgsinformation CEaxletenrdnaarls Legend LUosnegAAr--rppfuappncniningg tsuhesreevcLiacDleeN.nTdinhaberoonxrocathisficeaasttrireoapntlsoarcineamcthtesenatisnobtfhotehxec(oiennxsttuehrmenPearlo,cdra)e,laeadnniddnagr Solid(KCNaoleonddlea)r App Orchestrator Sync calendars into Pods DoFcuilem/ent merge that to the calendar information in the Pod. Simi
Cseenrvtriaceliz(se)d larly, the calendar App, as the sender, sends the meeting PoCdonfig OCrcohnefisgturaretorr DUfloaswetar ihnyfAborrimmdaoctariesoenc,owamshnpeorlietcitafichateetidoinnsfscoertnomatarhtiieooininsbnfoeoexrd.sthteo bSeoLsyiDn-cfirhsrto(SUent-s)Rynecgicsotenrfiwgiftohroorrcchheessttrraattoorrs nized for both directions. For the SoLiD-related part, the LDN inbox is required; for the external part, the synchrocFhigesutrreat1o:r.Architecture for the calendar system with the or- nization mechanism discussed earlier is required. Apart from them, an additional function should be implemented for pushing/synchronizing the new meetings from the LDN inbox to external calendars. Diferent implementaifle and restart the service to make changes, even if just tion details (or configuration options) can be provided, changing external calendar’s URL. The reason it was de- such as keeping a separate calendar resource in Pod dedveloped in this way was that it allows some advanced icated for those from inbox and synchronize to external transformations (e.g. time filtering) and aggregation of calendar, storing it an ICS calendar in Pod to act as a external calendar. However, it posed many user expe- “remote” calendar, or using a separate remote calendar. rience challenges, particularly with the configuration In general, the proposed orchestrator mechanism can complexity and portability. be extended or adapted for future with the migration
In our version, the orchestrator is deployed as a sepa- progress in decentralized personal stores. It is still
essenrate service, not coupled with the SoLiD Pod’s service. A tial in those scenarios.
companion configuration App is developed to facilitate
the user to manage the configuration (stored to user’s
Pod) and to manage the registration to the orchestra- 4. Application to related work
tor. The configuration App talks with the orchestrator
through its API, thus can be deployed as a normal SoLiD SoLiD is a good example of decentralized knowledge
App. Upon registration, the orchestrator obtains an ac- graph and PDS. It has clear separation of roles, and
therecess token from the Pod service, and routinely fetches and fore we anticipate the designs working on SoLiD would
updates the calendar information in the Pod. Only the also work on other ecosystems as well (with appropriate
user’s basic information (e.g. WebID, identity provider) modification), discussed in this section.
and the access token is stored on the orchestrator’s local The key observation above is the necessity of
longstorage. Naturally, one orchestrator can support multiple living services for certain tasks. This needs to be made
users simultaneously. Both the orchestrator and the orig- explicit because SoLiD’s PDS service is designed to not
inal implementation on modified CSS uses RMLMapper 7 run custom code (and only Apps can, with or without UI),
to convert the representation of calendar data. One can and therefore can not be used as the orchestrator. Some
also view the orchestrator implementation as a SoLiD other PDSs also possess the same design, e.g. myDex9 and
App without user interface8. openPDS [
We are working on improving the orchestrator and services also exists for them. Databox [
calendar-and-meeting-scheduling use case on SoLiD, as an example of cooperative decentralized knowledge use. We showed the problem and proposed the use of longliving service like the orchestrator to support such cases, and presented our implementation and its application to related work.
Bringing up the long-living service like the orchestrator into a decentralized context poses opportunities and threats. On one hand, it is essential for certain tasks for decentralized knowledge use. On the other hand, it poses a potential challenge of re-centralization if the service becomes too big to switch. There is also currently no guarantee that the orchestrator will not be malicious, as they have access to sensitive information either in the configuration or the data obtained. A methodology or mechanism is needed to restrict or mitigate such potentials. In the meantime, there are also business opportunities on running such services and therefore accelerate adoption of SoLiD or any other decentralized systems.
Apart from investigating the technologies to constraint centralization and improving trust, one may also explore alternative designs that do not involve a third-party longliving service. In particular, one may want to study how to extend the access control model to express the necessary permission for such use cases, thus eliminating the needs.