Please use "ldh" for variables and "Librem One" for labels
User story: I am a third-party developer. I want to interact with Librem One components in a generic way, so that I can handle users who use a different provider.
Background: We distinguish between Librem One (the flagship brand and domain for services provided by Purism SPC) and other Liberty Deckplan Hosts (which hypothetically offer identical services at different domains/brands/providers). Because these alternatives don't exist today, we make minor implementation decisions that allow us to deliver a product now without inadvertently creating vendor lock-in at a future date. To date we use this strategy:
-
For user-facing labels, we hard-code "Librem One" branding, logos etc. At a future date we will investigate options to tweak this branding at a packaging level, but GOA implementers don't need to worry about this today.
-
For developer-facing interfaces, we use the "ldh" prefix rather than "librem", "libremone" or anything like that. This means that as branding gets tweaked the implicit api does not change.
Suggested solution:
The developer-accessible variables such as provider type should be renamed to "ldh" rather than "librem_one". For example, from 9bf83a78 :
# librem.one
AC_DEFINE(GOA_LIBREM_ONE_NAME, ["librem_one"], [ProviderType and extension point name])
AC_ARG_ENABLE([imap-smtp],
[AS_HELP_STRING([--enable-librem-one], [Enable librem.one provider])],
[],
[enable_librem_one=yes])
if test "$enable_librem_one" != "no"; then
AC_DEFINE(GOA_LIBREM_ONE_ENABLED, 1, [Enable librem.one data provider])
fi
becomes something like:
# Librem One or other Liberty Deckplan Host
AC_DEFINE(GOA_LDH_NAME, ["ldh"], [ProviderType and extension point name])
AC_ARG_ENABLE([imap-smtp],
[AS_HELP_STRING([--enable-ldh], [Enable Librem One or other Liberty Deckplan Host])],
[],
[enable_ldh=yes])
if test "$enable_ldh" != "no"; then
AC_DEFINE(GOA_LDH_ENABLED, 1, [Enable Librem One or other Liberty Deckplan Host])
fi
Notes:
-
For user-facing prompts it is obviously much simpler to just refer to "Librem One" rather than the verbose "Librem One or other Liberty Deckplan Host". This is perfectly acceptable. We may revisit this in the future, but this is definitely the fairest, fastest, simplest way forward for now.
-
Prompt for credentials. In user-facing prompts we ask for "Librem One address" and "passphrase" (or just "address" and "passphrase"). We don't refer to "name", "username" or "password".
-
Validating address. The address must be a valid email address with no special characters. If your framework can already validate email addresses, just use that method. Otherwise use these simpel rules: alphanumerics, followed by
@
, followed by alphanumerics, at least one period, and more alphanumerics-or-periods. -
Determining host. We determine the host from the address by splitting at the single known
@
. Soprefix@example.com
becomesprefix
andexample.com
. Never hardcode "librem.one". -
Once you have validated and decomposed the credentials you should have:
-
Address. Full address used for authentication.
-
Passphrase. Passphrase used for authentication.
-
Host domain. Host domain, used to make online queries, attach subdomains, etc.
-
The host will handle any further validation requirements (valid characters in username/passphrase, correct subdomain, etc).
-
/cc @tobias.bernard