Design Philosophy

Trust Minimization

The primary design objective of Sovereign Stack is to create an application that DOES NOT rely on any trusted third party for operation. The focus is always on trust minimization. Bitcoin is an essential part in achieving this since it eliminates the need for trusted third parties in financial transactions.

Self Hosting

Eliminating third parties implies self-hosting all your back-end services and running those services on trusted hardware you own and control. Sovereign Stack is designed to be executed under these circumstances.

💯
"The Cloud" is often a euphemism for "someone else's computer". Involving someone else in the execution of your Information System necessarily introduces a third party in your system architecture, and that represents the introduction of a security hole.

Existing Problems

Email

Sovereign Stack seeks to AVOID the use of Email (i.e., SMTP). There are several reasons for this including the lack of default confidentiality, complexity of the email stack, and vulnerability to unsolicited email and spam.

Due to the complexity of the protocol, many companies rely on a trusted third party for email infrastructure. Unfortunately, these email providers get hacked leaking PII.

In general you should instead use service endpoints for functionality (e.g., RSS, webcal, etc.) Ghost, the software that enables the website portion of Sovereign Stack, automatically maintains an RSS feed for clients to subscribe to. We generally recommend you configure your RSS reader to create OS notifications which link back to the website article.

❓
Did you know that the Sovereign Stack git repository has an associated RSS feed that keeps you informed of changes to the master branch? Very thoughtful.

Domain Name System (DNS)

At this time, Sovereign Stack relies on the Domain Name System (DNS) for public Sovereign Stack instances. This requires the use of a TPP.

The current public DNS unsatisfactory due to its hierarchical nature and the fact that it is censorship-prone. This is reflected in the fact that you need to have a relationship with a trusted third party (i.e., your DNS providers: Namecheap, GoDaddy, etc.)

The recommend mitigation(s) for using the public DNS includes

  • adding multiple DNS domains from multiple providers based in multiple jurisdictions,
  • exposing services as onion endpoints.
  • We will also explore other DNS alternatives that anchor into Bitcoin.

Exchange Rate Providers

Integrating any monetary system besides Bitcoin is considered an anti-pattern since fiat monteary systems introduce a TPP and is vulnerable to inflation! Get used to using sats as your numeraire because exchange rates make the system slow and prone to error! Why? Because you have to ask a third party what the exchange rate is.

Availability

Although each Sovereign Stack deployment attempts to maintain high levels of uptime at each deployment, some operations such as TLS enrollment/renewal REQUIRE that all services be taken down temporarily. Taking services down for troubleshooting may also be required at any given data center.

Geographic Redundancy

If you're operating a business where service interruptions have a large impact on revenue streams, it may make sense to deploy two or more Sovereign Stack data centers separated by a reasonable physical distance, perhaps in different legal jurisdictions. Geo-redundant configurations help companies meet their business continuity objectives.

The management machine deploys software to one or more cluster hosts across your various data centers. You decide what is deployed at each site, but the general approach is to deploy read-only caching proxies which mirror a primary writable location.

Disaster Recovery

Disaster Recovery is achieved by reestablishing data center hardware, then performing a restoration. Sovereign Stacks keeps encrypted duplicity archives on the management machine which form the basis for recovery of user data.  

Each time you execute Sovereign Stack, a backup archive is created and stored on your management machine.

If a data center suffers a disaster, that data center should be removed from DNS so clients aren't directed to the affected data center. (Automating this is future work)

You can then work on restoring service by repairing the offline data center and restoring from backup.

✴️
Note! Lightning Channel State is handled differently from application backup state. We are thinking hard about how to handle that. Watch Towers? Distributed file system? SqlServer replication?

Local High Availability (Local-HA)

Sovereign Stack currently does not support Local-HA. This is future work. The application has been architected to support Local-HA operation.

The idea with Local-HA is you have a set of three or more physical cluster hosts all sitting behind a load-balancing Virtual IP. We might consider adding a redundant upstream ISP connection and firewall+switch combination w/failover as well. This is future work.

Sovereign Stacks scripts attempt to perform backup activities in a noninvasive way, but does require services to be turned off periodically (e.g., certificate renewal). Just running the script normally DOES NOT result in service downtime due to networking and caching strategies at the reverse proxy.

Scalability

Native ways to scale the system include 1) adding additional cluster hosts at each data center and situating them behind a round-robin VIP at the firewall, and 2) by running multiple geographically separate data-centers using Geographically-sensitive DNS resolution. Item (2) is essential for achieving 100% service up-time.

✴️
You have a unique Lightning Node at each data center. That means channel/liquidity management, balancing, etc! Each data center is built to operate independently from other data centers.

You should avoid using any trusted third party to scale your system (e.g., caching CDN). Introducing a Trusted Third Party represents a vulnerability in your system design.