ARPA2 Common Libraries

The ARPA2 Common Library package offers elementary services that can benefit many software packages. They are designed to be easy to include, with a minimum of dependencies. At the same time, they were designed with the InternetWide Architecture in mind, thus helping to liberate users.

Also see: Installation Instructions based on CMake.

The functions provided by these libraries cover:

• Identity in the form of a user@domain.name which can be widely used, without being constrained to a protocol du jour. Designed to support Realm Crossover and inidividually controlled online identity. Control includes aliases and even signatures that invalidate identities at an expiration day, or in non-intended contexts. Completely redesigned in the 2.0.0 release.
• Selectors are a form of pattern that matches against Identity. Both the user name and the domain can be generalised, which we actively use in applications like Access Control and Groups. Completely redesigned in the 2.0.0 release
• Policy Rules are a generic grammar for capturing instructions for applications such as Groups and Access Control. The generic facilities provided are % flags, = variables, ~ ARPA2 Selectors, ^ triggers and # comments/markers. These are grouped into Rules, which in turn form an unordered Ruleset. Policy Rules can be supplied by an application from its local configuration, or they can be stored in a database that is updated as part of automated configuration management. The system is general and powerful, but surprisingly easy in use for any given Access Type; we define Communication and Document Access as initial Access Types but this can easily be extended by us or others.
• Acccess Control for Actor Identities is a set of functions that let a user switch to another identity for continued acting on behalf of those. This is useful for aliases, group member identities and pseudonyms. This can be requested at the wish or whim of a user, to migrate from an original login_id to one that is a better for passing through Access Control, or to improve privacy and/or traffic filtering.
• Access Control for Communication derives rights for remote users trying to gain access to a local user or service. Communication is considered as a general mechanism, independent of software or protocol, to span between a remote user like mary@example.org trying to access a local user like john@example.com under the local party's acccess constraints. Aliases each have their own access control, so users can benefit from sorting their contacts into different inboxes.
• Access Control for Documents derives the access rights for (remote) users trying to read, write or otherwise manipulate a document or folder. Documents and folders have a path on a volume, and may take a user to specify a view on the volume. When no volume is given, the logic reverts to the shared information of ARPA2 Reservoir.
• Actors redefine a (local or remote) address as an ARPA2 Identity under the local domain. These can be used for one-on-one translation in support of address privacy. One possible use of this is better (email) forwarding, where the use of a local identity as a sender address procures flawless DKIM and flawless SPF.
• Groups are sets of users, but otherwise have a normal user Identity. Aliases are used to give group members an Actor address that conceals them, and helps to avoid problems for members from other domains. Groups' use of Actor addresses help any forwarded traffic, such as on an email list, to pass through DKIM and SPF without flaws. It also benefits the privacy among members, because the actual address of a user can be concealed.
• Pseudonyms allow users to change their identity to another one that appears like a completely distinct login user. Unlike an alias, which adds one or more +word to the original user identity, the relation between a pseudonym and the original login is not externally visible. Internally however, there is a clear relation, so there is an option of abuse handling. Since a pseudonym is not anonymous, their external identity can be traced and so they can build up a history with external sites.

The intention is to allow two kinds of hosting providers, both of which benefit from these libraries and their tight control of the authority to access Identity and Access information,

• Identity Providers allow users to express the users, groups and aliases that make them happy. They also allow management of Access Control.
• Service Providers offer hosted applications that plug into a domain (usually as a hostname underneath it) with full support of Identity and Access Control that is centrally arranged for many protocols, many services and, especially, many service providers.
• We believe this separation in functionality can resurrect the market that pretty much grinded to a halt around LAMP service only, and got taken over by a few "central" providers that we all use in spite of their devastating impact on online freedoms like privacy and control over our online presence.
• For Identity Providers, there is an option to explore diverse service levels; tightly controlled, secure and redundant for high-end users, or simple and cheap for others.
• For Service Providers, there is an option to provide specific services that they specialise in. There is no need to go all the way, nor to desire the control of all users in the World, especially when open protocols are used. The added value that Service Providers generally bring is diversity in user experience, including such things as the user interaction. This tends to be what makes users prefer applications, but this taste is also individual and open protocols help to pull them away from the mediocrity of "general" and "free" providers.

We aim high, but when it comes to code we try to be minimalists and to provide just the little piece that makes sense to everyone and yet, has not been made to enable these ideals that many of us seem to agree on.

This software was designed to liberate you. And to liberate your users. Please consider integrating it into your sofware!