Liberty

Definitions

Regular services are implementations of networked software, typically lightweight clients or browser interfaces that deliver messages to remote applications operated by a third party.

An ethical service is one that explicitly protects users from exploitation in this scenario. (See the Digital Bill of Rights🔗.)

The Liberty Deckplan is our concrete configuration plan for a well-defined suite of ethical services.

A Liberty Deckplan Host (LDH) is a single domain implementing the deckplan to provide ethical services.

Librem One🔗 is the flagship LDH installation.

Privacy levels

Public. Published publicly for everyone to see and share.

Private. End-to-end encrypted for intended recipient(s) only.

Temporary. If it's not public, and it's not private, it's temporary and deleted after 30 days.

See https://librem.one/policy/ for related details.

Scope

This is a non-exhaustive non-prioritized list of ideals and limitations on the scope of the project. They may change over time.

One set of credentials. The full address and passphrase will be used as credentials everywhere. The user will not have to remember variants and special cases.

Fair value and sustainability. An operator is assumed to be running a for-profit business charging a fair price for labor (development, maintenance) and tangible goods (storage, bandwidth). Artificial restrictions like throttling or restricted licensing will not be directly supported.

Upstream first. Wherever feasible and welcome we will contribute changes to upstream projects, minimizing the delta between our fork (if any) and upstream.

Flagship-friendly but vendor-neutral. We will implement defaults and humane branding to improve user experience on the flagship domain, but will actively enable the use of alternate domains, and provide mechanisms for re-branding.

Engineering not advocacy. This is a software engineering project managed within the already-defined framework of Purism's social purpose🔗, Digital Bill of Rights🔗 and service policy🔗. We refer to subject-matter experts for further guidance. Discussion around these issues is out of scope in the context of this project, but welcome on the Purism forums🔗.

Single end-user, multiple trusted devices. We consider use-cases where the end-user has one or more trusted devices where they are the sole user/owner, like a laptop and a phone. In general, the end-user should be able to perform task A on one device, and immediately perform task B on a second device. We do not consider shared devices, shared sessions or shared accounts.

Two accounts is a fair solution. Using two or more accounts solves some user stories, especially those dealing with operations security. Where a two-account-solution exists, solving the problem with one account will be indefinitely deprioritized.