Perspectives Technical Documentation

With Perspectives we recognise that various participants in a context may have a different view of the same role. Consequently, each of them keeps his or her own version of it on his or her own computer. Because the distributed runtime doesn’t keep a central store of data, but instead sends updates of contexts and roles to those whom it will concern, only participants in a context will have access to data concerning its roles. This maximizes correct interpretation of data: not just anybody can see it. Thus, Perspectives is built for the fine-grained structure of society consisting of personal interactions.

But society also knows public spaces. Political debate is carried out in public; the government works in public space; newspapers, television and radio make information available to the public, indeed, by 'publishing' it.

Perspectives supports public spaces, too. For this we introduce the concept of a universal perspective. This is the perspective of a role that can be played by anyone; no restrictions apply (other than that one should have a computer with Perspectives on it to one’s disposal). This implies that this role should be calculated: the calculation should work for every member of the public. By convention, we’ll call that role Visitor. If all participants share the same perspective on a role (or context), all of them can do with the same version. This allows us to store such entities in a public store. Someone wanting to access the information on such a role will have to fetch it from that public store.

We call a context with a Visitor a public context.

How do we find a public context? For this Perspectives relies on the Domain Name System (DNS) of the internet. Concisely, the DNS is a distributed system of internet servers that allows anyone to exchange a readable name for an internet address. Ipso facto, the readable name identifies a location and, indeed, its technical name is a Universal Resource Locator or URL.

Now most of us are familiar with URLs: using a web browser program with access to the internet, we can retrieve a document 'from' the URL. Actually, we retrieve it from some internet-connected server: both the server and the document are identified by (different parts of) the URL.

Two parts of the anatomy of a URL are of interest to our purposes: the authority and the path. For example, in: https://www.nlnet.nl/somedocument.html, "www.nlnet.nl" is the authority, while "somedocument.nl" is the (very simple) path. The authority is built from simple strings of characters separated by dots. Each part is called a domain. The rightmost part - nl - is the top domain, while the parts to its left are subdomains, successively deeper nested. So "nlnet.nl" is a subdomain of the top domain reserved for the Netherlands.

What about the "www" part? Well part of the nlnet.nl domain is called "www". So www is a subdomain of nlnet.nl This sits uneasily with our intuition of the world wide web as a kind of 'umbrella' over all websites. Actually, technically, all domains that take part in the world wide web, address part of themselves - one of their subdomains - with the name "www". So really, all those domains have a bit of the world wide web that they happen to call by the same subdomain name. The world wide web is a convention, rather than a technical unit.

The path is used to identify resources in a particular subdomain. In our example the path is just the identifier of a document. However, we may construct a path of segments separated by slashes, for example: /foundation/anotherdocument.html. We can interpret "foundation" as a named collection of documents, or, in other words, as a folder holding documents and other folders.

Having studied relevant parts of URLs we can now explore how to use them in Perspectives.

First we notice that the world wide web usually is understood as a system for locating resources, like documents or programs. In Perspectives, the main concepts are on a different level of abstraction: in presenting it, we take care to avoid concepts like document, message and information. Context and role are not just different names for information objects, even if, when we discuss the operation of the distributed runtime, we recognise that instances of both are represented as documents.

In Perspectives, the end user usually visits a context by navigating to it from another context. If alternatives exist - for example, a list of chats - these will be presented with some description entered by the user himself. The identification of a document representing a context, however, consists of a GUID and is hidden from his view.

Navigating will have to start somewhere and for that the end user can choose from a small number of readable names that also identify a context. These names are defined in Perspectives models. Now, an observant reader might object that a conflict must exist between

This conflict is solved by a system of indexed names. A prime example of an indexed name is "Home". In the abstract, it means the same for everyone; but concretely, each of us points to a different dwelling (except, of course, those living together at the same address). So each end user enters the same indexed name, but, under water, these are exchanged for unique identifiers by each installation of the distributed runtime.

Back to public spaces. A public context, being the same for everyone, can be identified by the same name for everybody too. We don’t need to switch them for unique private names, like with indexed names. This is how we use the DNS in Perspectives. Domain names identify public contexts. We call such a context a named public context; we call the URL a Uniquely Identifying Readable Name (UIRN).

Suppose the NLnet organisation wants to provide a public context. What domain name should it choose? Here we would like to introduce a convention. Just like the "www" subdomain holds resources to be shared over the internet, we would like to propose to keep public contexts and roles in a subdomain, too. We’ll call it the context web and abbreviate it with 'cw'. Hence, NLnet should call its public context http(s)://cw.nlnet.nl.

However, given that MyContexts is served from a secure domain, Cross Origin Resource Sharing (CORS) requires that we should use the https scheme rather than http. In other words, a server operator would be required to obtain security certificates for the "cw" subdomain (and in what follows we’ll see that quite a few more are required). This is a practical (financial) obstacle. For that reason we’ll introduce another convention. Instead of using a subdomain, we’ll introduce a convention for a particular way to create path names. To continue the example, NLnet would store its public contexts at the location https://nlnet.nl/cw_nlnet_nl/. See [Model description: a public context] for an extended example.

The concept of public contexts stored in a publicly accessible location - a public store - presents us with the notion of multiple locations where the distributed runtime can store contexts and roles. In versions of the system up to v0.11.0 all resources went into a single local store. As we introduce the notion of multiple stores, this local store will become the default private store. The current code base realises this through Pouchdb, where the default private store goes by the identifying name "{systemIdentifier}_entities" (where {systemIdentifier} is replaced by the unique system identifier for the installation).

This store may be based in the IndexedDB of the browser, or it may be a database of a Couchdb installation anywhere.

Multiple stores present us with the following questions:

To author a context (instance) that will be available to the public, requires three things:

That’s all. Just create the context in whatever way the author of the model you’re using, has made available. After creating it, each modification will be published automatically.

This requires some planning. As soon as you put up your contexts and roles, they are available. That may not be prudent; you may want some time for yourself to edit your contexts and roles until you’re satisfied with them. This is where the best practice described above comes in handy. Associate your types with a symbolic name that represents a place to work, and have it point to your default private store. Then, when the time comes to publish, point it to its definite public location.

Notice that while this gives you some breathing space, it is a trick that cannot be repeated for more instances of the same type after publishing the first instances. Should you publish something like a periodical, you’ll have to find another way to temporarily bar the public from work in progress. A good way is to prevent the public from navigating from accessible public contexts to the stuff you’re authoring, until you’re ready. In effect, they are then hidden from the public eye (As you are creating a new public context, by remembering its public name you yourself can revisit it before publication!).

A public context can be useful in the same way that a static web page can be useful. But Perspectives is not primarily a system to publish information; it is a system to co-operate. If the Visitor cannot change a public context, how can she ever enter in a co-operation starting from such a context?

It turns out that Perspectives already has a provision for this situation, in the form of the unlinked role. An unlinked role instance refers to its context, but the context has no pointer to the role instances of an unlinked role.

Hence, a Visitor can create, for example, an instance of an unlinked Context role. The context role, the external role of the context and the context itself are all stored in private store. By providing a role for the author of the public context - let’s call him Admin - in that new context, the distributed runtime of the Visitor will send deltas to the Admin so he can construct the new roles and context, too. This way, Visitor and Admin participate in a private context that was created from the public context. The author of the public context can have a perspective on the context role; his runtime will retrieve the instances by database query.

This is a good general scheme for subscription, where a Visitor explores public contexts and decides to subscribe by creating a (private) contract context between herself and the Admin. Creating the private instances may be done by providing the Visitor with an Action that can be accessed through the GUI.

How does the Visitor (re)visit his Contract? To navigate to it from the public context would require a perspective for him on Contracts. But this would disclose other contracts, too, a privacy breach. Instead, the Contract is modelled as a context with an IndexedName. Consequently, he can visit it by entering that name (it may be given on the public context page; indeed, after it has been constructed, a link may appear). Remember that, under water, the runtime creates a unique identifier for an indexed name

An alternative to indexed names comes into being as soon as we make filters work on inverted queries. We can then give the Visitor a perspective on the contracts filtered with the criterium that he himself plays a role in it. The PDR of the Admin would apply this filter on the inverted query and this would cause a contract to be sent to just the relevant Visitor (the version that exists currently, v0.11.0, does not support inverted query filtering).

In a different approach, we would allow the Visitor create a new user role – let’s call it an Account- with more perspectives. Usually, restrictions on Accounts apply. Because the Account will be an enumerated role, an end user visiting a context in which (s)he plays the Account role, will use the perspectives that come with that role (because enumerated user roles have precedence over calculated ones, when the client establishes the perspective for its end user). See the text The Body-with-Account Pattern for more details.