The Anselus Platform Specification
- Anselus APIs
- Introduction to the Anselus APIs
- Specification Versions
Introduction to the Anselus APIs
Anselus is set of APIs for groupware communications intended to replace e-mail in its current form and expand capabilities to include calendar management, tasks, contact management, and note-taking. This specification is a reflection of efforts construct and revise standards of communication for the platform.
The principles used to guide the decision-making process for the Anselus platform are as follows:
- Server has near-zero knowledge of user data
- Open standard - documented and unencumbered by patents or IP
- Open source - reference implementation licensed for any purpose with guarantees that it stays open
- Open federation - anyone can run a server
- Playing well with others - compatibility with other standards where possible
- Avoidance of overengineering - complexity is a burden
- Leverage existing standards - utilize existing proven technologies and adapt concepts from others where necessary
Functionality that the Anselus platform provides:
- Creation and management of workspaces which provide storage and synchronization of encrypted data
- Sending and receiving messages to users on other servers
- User management (permissions, addition, removal) by way of a privilege system
- Flow control of messages, both inbound and outbound
The mission of Anselus is to provide to people the ability to organize their lives with privacy-respecting digital tools and to connect with one another.
Anselus is built such that the server is little more than a file synchronization and message delivery daemon – most of the real work is handled by clients. This has multiple benefits, but the main two are offloading CPU-intensive encryption processes to the client and forcing the server to know as little about the contents of client data as possible.
Workspaces, Users, and Identity
Workspaces are the central concept of the platform. They are collections of user data, similar to mailboxes, but they can hold many possible kinds of encrypted data, including tasks, messages, files, and calendar events. A filesystem hierarchy defines locations for different types of data within the workspace.
Workspaces have two types: individual and shared. Identity is linked to individual workspaces. Shared workspaces are spaces for collaboration. They are unable to send messages and provide no such identity.
Devices are merely different access methods to Anselus servers. Each user has a list of associated devices for their workspace, each identified by a device ID. Each application may utilize its own device ID. Thus, an Android phone with separate applications for accessing calendar, contacts, messages, notes, and tasks could have 6 different device IDs whereas a desktop PC running an all-in-one client could just have one. At the same time, this is not a requirement.
In addition to e-mail-like messages sent by users, servers use system-level messages to perform platform-level tasks, such as sending contact requests and managing encryption keys in a shared workspace.
API versions take the form of X.Y.Z: X is major version, Y is minor version, Z is patch level.
- Major version changes indicate breaking changes in the API – a client running 2.5.1 will need source code changes in order to be compatible with version 3.0.0.
- Minor version changes are for adjustments in an individual API, such as for tasks. Potential breaking changes may or may not be included in minor version changes, but such changes should require only minor adjustments.
- Patch level changes are backwards-compatible API changes.
The Anselus specification is distributed under the Apache License, version 2.0.