From 807d546b122401b2c1b9c7a613aeef1b2e768edf Mon Sep 17 00:00:00 2001
From: Andrew Godwin
Date: Wed, 23 Nov 2022 13:05:14 -0700
Subject: Write some more docs

---
 docs/principles.rst | 59 -----------------------------------------------------
 1 file changed, 59 deletions(-)
 delete mode 100644 docs/principles.rst

(limited to 'docs/principles.rst')

diff --git a/docs/principles.rst b/docs/principles.rst
deleted file mode 100644
index 737c5f9..0000000
--- a/docs/principles.rst
+++ /dev/null
@@ -1,59 +0,0 @@
-Design Principles
-=================
-
-Takahē is somewhat opinionated in its design goals, which are:
-
-* Simplicity of maintenance and operation
-* Multiple domain support
-* Asychronous Python core
-* Low-JS user interface
-
-These are explained more below, but it's important to stress the one thing we
-are not aiming for - scalability.
-
-If we wanted to build a system that could handle hundreds of thousands of
-accounts on a single server, it would be built very differently - queues
-everywhere as the primary communication mechanism, most likely - but we're
-not aiming for that.
-
-Our final design goal is for around 10,000 users to work well, provided you do
-some PostgreSQL optimisation. It's likely the design will work beyond that,
-but we're not going to put any specific effort towards it.
-
-After all, if you want to scale in a federated system, you can always launch
-more servers. We'd rather work towards the ability to share moderation and
-administration workloads across servers rather than have one giant big one.
-
-
-Simplicity Of Maintenance
--------------------------
-
-It's important that, when running a social networking server, you have as much
-time to focus on moderation and looking after your users as you can, rather
-than trying to be an SRE.
-
-To this end, we use our deliberate design aim of "small to medium size" to try
-and keep the infrastructure simple - one set of web servers, one set of task
-runners, and a PostgreSQL database.
-
-The task system (which we call Stator) is not based on a task queue, but on
-a state machine per type of object - which have retry logic built in. The
-system continually examines every object to see if it can progress its state
-by performing an action, which is not quite as *efficient* as using a queue,
-but recovers much more easily and doesn't get out of sync.
-
-
-Multiple Domain Support
------------------------
-
-TODO
-
-
-Asynchronous Python
--------------------
-
-TODO
-
-
-Low-JS User Interface
----------------------
-- 
cgit v1.2.3