Add RFC 3: Tilde Center Specs
commit
21e7413997
|
@ -0,0 +1,601 @@
|
|||
---
|
||||
title: "Tilde Center Specification"
|
||||
number: 3
|
||||
author: Austin Ewens <aewens@tilde.center>
|
||||
status: Approved
|
||||
---
|
||||
## Abstract {#abstract}
|
||||
|
||||
This document outlines the core philosophy and components that the Tilde Center
|
||||
project is composed of, as well as laying out the fundation to bootstrap the
|
||||
rest of the project for future modifications and expansion to create a
|
||||
sustainable, self-reliant, decentralized network of tilde servers.
|
||||
|
||||
## Introduction {#introduction}
|
||||
|
||||
The [Tilde Center](https://tilde.center) (herein referred to as ~center)
|
||||
project was created by Austin Ewens (better known in the community as ~aewens),
|
||||
in December 2018. The goal of the project is to create a decentralized and
|
||||
federated server architecture built upon home-brewed open source projects
|
||||
(herein referred to as HBOSP) made by and maintained by its user base.
|
||||
|
||||
## Terminology {#terminology}
|
||||
|
||||
To assist in clarifying the intentions of the project, this section will
|
||||
outline the meanings behind the terminology used thought the document:
|
||||
|
||||
* Decentralized - As opposed to the centralized server model where multiple
|
||||
clients all connect to a singular server, ~center will be a series of servers
|
||||
that all provide its users access to the same shared tilde server experiences.
|
||||
|
||||
* Federated - In tangent with being decentralized, to ensure that a user has
|
||||
access to the same shared services and resources as they would on any
|
||||
other ~center peer server all that data would need to by synced together, i.e.
|
||||
federated.
|
||||
|
||||
* Home-brewed - For our purposes here there are two types of software: software
|
||||
written by you and your peers and software that was written by someone else.
|
||||
In this document, home-brewed software or HBOSP refers to the former and not
|
||||
the latter.
|
||||
|
||||
* Tilde Center or ~center - The project itself and the collective of the peer
|
||||
servers that make up the ~center network.
|
||||
|
||||
* Peer servers - Due to ~center being decentralized and federated, the
|
||||
relationship the servers have with one another is being peers in the ~center
|
||||
network, ultimately meaning that they will share data and communicate with one
|
||||
another.
|
||||
|
||||
* Tildeverse - A loose association of like-minded tilde communities (see
|
||||
[here](https://tildeverse.org) for more details).
|
||||
|
||||
## Clarifications {#clarifications}
|
||||
|
||||
Before going any further into the specifics of the ~center project, some
|
||||
clarifications should be made.
|
||||
|
||||
Firstly, the Tildeverse and Tilde Center are two distinctly different
|
||||
organizations (for lack of a better word). While the initial ~center server
|
||||
created by the project's founder, ~aewens, the other peer servers do not need
|
||||
to be members of the Tildeverse to be a part of the ~center project.
|
||||
|
||||
Secondly, the peer servers in the ~center project are not clones of each other.
|
||||
They are unique servers managed by their own system administrator (aka
|
||||
sysadmin), but they share the user accounts along with select data and services
|
||||
with other servers to create a decentralized network of services for its users.
|
||||
|
||||
## Peer Servers {#peer-servers}
|
||||
|
||||
To better understand the peer servers in the Tilde Center Network (herein
|
||||
referred to as TCN) it helps to define what they will and will not do:
|
||||
|
||||
* They WILL have an account for all users within the TCN.
|
||||
|
||||
* They WILL provide a (size limited) directory for each user that will be
|
||||
synced across the other peer servers.
|
||||
|
||||
* They WILL maintain a database that will sync transactions across the other
|
||||
peer servers.
|
||||
|
||||
* They WILL sync any and all approved scripts (either for users or admins)
|
||||
added to the other peer servers.
|
||||
|
||||
* They WILL provide any and all services created for the ~center platform.
|
||||
|
||||
* They WILL provide any and all services expected of a tilde server.
|
||||
|
||||
* They WILL only be managed by that server's system administrator (e.g. an
|
||||
admin from one peer server cannot direct decisions for another peer server).
|
||||
|
||||
* They will NOT be responsible for syncing all other user files.
|
||||
|
||||
* They will NOT be expected to distribute server specific services to the rest
|
||||
of the network.
|
||||
|
||||
* They will NOT be required to keep all user accounts unlocked (e.g. users can
|
||||
be kicked / banned from specific peers).
|
||||
|
||||
While this list may grow and/or change in future revisions of this document, in
|
||||
general a server in the TCN will share fundamental components with its peers
|
||||
while still having the ability to have unique characteristics (i.e. the peers
|
||||
will not be direct clones of one another).
|
||||
|
||||
The next few sections will outline some more of the specifics for the points
|
||||
listed above.
|
||||
|
||||
### Prerequisites {#prerequisites}
|
||||
|
||||
Due to the nature of the project, it would preferable to have more rather than
|
||||
less peer servers in the TCN for the sake of decentralization (the more peers
|
||||
in the network, the more resilient it is). For this reason, it is in the best
|
||||
interest of the project to minimize any factors that would inhibit potential
|
||||
servers from becoming peers in the TCN. This is one of the reasons why peer
|
||||
servers are not just clones of each other because this would at the very least
|
||||
require all peers in the network to upgrade the hardware for their storage to
|
||||
meet the demands of new users joining the network.
|
||||
|
||||
With this in mind, all current and future services that will be federated
|
||||
across the TCN should aim to minimize the data that actually needs to be stored
|
||||
and processed by all of its peers to make it easier for new peer servers to
|
||||
join the network.
|
||||
|
||||
### Center Directory {#center-directory}
|
||||
|
||||
On all peer servers there will be a /center directory that will contain the
|
||||
bulk of the ~center related files. Within this directory will be the following
|
||||
sub-directories:
|
||||
|
||||
* /center/bin - Any scripts created by users to be shared across the TCN will
|
||||
be stored here.
|
||||
|
||||
* /center/sbin - Holds all administrative scripts for the system administrators
|
||||
to better manage their peer server.
|
||||
|
||||
* /center/etc - Holds all configuration files used for anything ~center
|
||||
related. To help keep this directory clean, files should be group into
|
||||
sub-directories to make it clear what they belong to.
|
||||
|
||||
* /center/lib - Holds all library code used for ~center related services. As
|
||||
with /center/etc, this should be organized into sub-directories.
|
||||
|
||||
* /center/home - The $HOME for user accounts. The directories under /home/$USER
|
||||
will be a symbolic link to this directory.
|
||||
|
||||
* /center/data - The location for the size limited shared directories for
|
||||
users. This will be linked to $HOME/.center for convenience.
|
||||
|
||||
Aside from /center/home, all other sub-directories under /center will be
|
||||
synchronized with the other peer servers.
|
||||
|
||||
### Dispatcher {#dispatcher}
|
||||
|
||||
Arguably one of the most important components of the ~center server components,
|
||||
the dispatcher will be in charge of federating data across the TCN and handling
|
||||
the logistics of any mention of syncing data in this document. This will be
|
||||
accomplished by having a socket server and client combo that can read and
|
||||
execute a set of instructions sent from other servers. To reduce the
|
||||
possibilities of this becoming a security vulnerability for remote code
|
||||
execution (RCE), it is important that the dispatcher only receive requests and
|
||||
deliver them to the appropriate targets without ever directly executing the
|
||||
instructions.
|
||||
|
||||
#### Communication Model {#communication-model}
|
||||
|
||||
For this to work, dispatcher will use a publish-subscribe communication model
|
||||
where services can subscribe to specific events from the dispatcher and, if
|
||||
approved by the dispatcher (which will most likely be handled via an action
|
||||
from the sysadmin of the peer server), will receive those events upon being
|
||||
received. The messages the dispatcher will handle will be JSON in the following
|
||||
format:
|
||||
|
||||
```json
|
||||
|
||||
{
|
||||
"name": "name-of-event",
|
||||
"meta": {
|
||||
"from": "uuid-of-sender",
|
||||
"to": "uuid-of-receiver",
|
||||
"iat": "timestamp-when-message-sent",
|
||||
"exp": "timestamp-when-message-expires"
|
||||
},
|
||||
"data": {
|
||||
...
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
Along with this message will be a GPG signature of the message prefixed with
|
||||
the code "GPG+" and the message itself will be encrypted with a key made from
|
||||
the [Double Ratchet](https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm)
|
||||
algorithm (the logistics of which will be explained in a moment). The message
|
||||
format provides the name of the event being sent, where it came from, who the
|
||||
message was meant for, when it was sent, when it should expire, and all the
|
||||
data that should be passed on to the subscribers. Since the messages are sent
|
||||
and received over a socket, the dispatcher will already know the IP address of
|
||||
the sender to verify the signature of the message and know which key to use for
|
||||
decrypting before parsing its contents, but should still verify that the
|
||||
metadata in the message is valid before making any additional actions on the
|
||||
rest of the message.
|
||||
|
||||
#### Stored Information {#stored-information}
|
||||
|
||||
For the dispatcher to properly handle communication with the other peers, it
|
||||
will need to maintain a list of all known peer servers via their last known IP
|
||||
address, their universally unique identifier (aka UUID), the GPG public key of
|
||||
the server, and the shared secret key used with that peer server. While the
|
||||
shared secret key chain should be stored safely and securely, the IP addresses
|
||||
and UUIDs of the peer servers should be stored in a distributed hash table (aka
|
||||
DHT), specifically a [Kademlia](https://en.wikipedia.org/wiki/Kademlia) DHT, to
|
||||
optimize the fact that the TCN is a decentralized network with the dispatcher
|
||||
communicating in a peer-to-peer (aka P2P) system.
|
||||
|
||||
As well, the dispatcher will locally need to maintain a list of services
|
||||
subscribed to its feed, what events they are allowed to receive, and what
|
||||
events they are allowed to send. Each of these will need to be approved by the
|
||||
sysadmin to ensure only valid services are listening to the dispatcher, only
|
||||
receiving appropriate events, and only sending out appropriate events to the
|
||||
peer servers.
|
||||
|
||||
#### Adding New Peers {#adding-new-peers}
|
||||
|
||||
To facilitate the process of authenticating messages from server-to-server,
|
||||
when a new peer server is created it will generate a UUID and GPG key pair for
|
||||
itself followed by sending out a message in the following format to one or more
|
||||
existing peer servers:
|
||||
|
||||
```json
|
||||
|
||||
{
|
||||
"name": "new-peer-server",
|
||||
"meta": {
|
||||
"from": "uuid-of-sender",
|
||||
"to": "uuid-of-receiver",
|
||||
"iat": "timestamp-when-message-sent",
|
||||
"exp": "timestamp-when-message-expires"
|
||||
},
|
||||
"data": {
|
||||
"admin": "username",
|
||||
"server": "subdomain.domain.tld:ip-address",
|
||||
"secret_file": "secret_file_name",
|
||||
"dh_pub_key": "diffie-hellman-public-key",
|
||||
"gpg_pub_key": "gpg-public-key",
|
||||
"signature": "gpg-made-signature"
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
The message will be sent in plain-text and in place of the signature it will
|
||||
instead send a string of 64 zeros (i.e. an empty SHA256) with the prefix code
|
||||
"NEW" so that the dispatcher knows to handle the message as a new peer server.
|
||||
Additional logistics to how the on-boarding process behind new servers joining
|
||||
the TCN can be found at [Joining The Network](#joining-the-network) but for the
|
||||
sake of this section the "admin" field is the username of the sysadmin on the
|
||||
peer server the message was sent to, "server" is the domain name and IP address
|
||||
of the server sending the message, "secret_file" is the name of a file under
|
||||
the $HOME directory of the username specified by "admin", "dh_pub_key" is the
|
||||
public key used in the Diffie-Hellman key exchange process (this should be
|
||||
different for each peer server the message is sent to), and "gpg_pub_key" is
|
||||
the public GPG key generated earlier, and "signature" is the phrase contents of
|
||||
the "secret_file" signed using the GPG private key. The secret file will be
|
||||
readable only to the "admin" user as well as contain a value known ahead of
|
||||
time by the peer server sysadmin through prior communications and will be used
|
||||
to validate that the sysadmin of the new server is indeed the same user the
|
||||
sysadmin of the existing peer server expects. If there is any doubt that the
|
||||
sender of the message is not from the expected user / server, this process can
|
||||
be repeated using different secret files to employ a zero knowledge proof (aka
|
||||
ZKP) to raise the confidence that the sender is who they claim to be. Once the
|
||||
sysadmin of the peer server trusts the new server, it will send out its a
|
||||
message in the following form:
|
||||
|
||||
```json
|
||||
|
||||
{
|
||||
"name": "add-peer-server",
|
||||
"meta": {
|
||||
"from": "uuid-of-sender",
|
||||
"to": "uuid-of-receiver",
|
||||
"iat": "timestamp-when-message-sent",
|
||||
"exp": "timestamp-when-message-expires"
|
||||
},
|
||||
"data": {
|
||||
"dh_pub_key": "diffie-hellman-public-key"
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
With the signature used being the message encrypted and signed using the peer
|
||||
server's private GPG key with the prefix code "GPG". Since the new server
|
||||
joining should have the GPG public key ahead of time for the peer server, the
|
||||
dispatcher can use this to verify the authenticity of the peer server. After
|
||||
this message, both servers now can use the Diffie-Hellman public key to of the
|
||||
other and can now create a shared key to communicate with each other. All
|
||||
responses proceeding between the two servers will be signed using the key
|
||||
created through the Double Ratchet algorithm and the servers can now add the
|
||||
other to their roster of peers. Once the peer server receives back a response
|
||||
from the new server using the GPG+ method, it will send to the new server its
|
||||
DHT of peers to the new server along with sending out a message containing the
|
||||
domain name, IP address, UUID, and GPG public key of the new server to its own
|
||||
peers so that they can issue their own "add-peer-server" event to the new
|
||||
server to establish communication with its dispatcher. From which, the new
|
||||
server will reply with its own "add-peer-server" message and will add the peer
|
||||
server if it responds with a valid GPG+ message.
|
||||
|
||||
It is, of course, up to the sysadmins of the other peer servers whether they
|
||||
send the "add-peer-server" message to the new server, but since these servers
|
||||
will now have the information about the new server already the new server can
|
||||
always issue its own "add-peer-server" or "new-peer-server" message to the
|
||||
other peers manually if it wants to proactively establish communication with
|
||||
the other peers. However, the dispatcher must communicate the new peer server
|
||||
to the rest of its peers so that other peer servers in the TCN can receive
|
||||
dispatcher messages from the new peer server.
|
||||
|
||||
### User Accounts {#user-accounts}
|
||||
|
||||
When a user joins the TCN, an account is created on the peer server the joined
|
||||
from, which is then subsequently created on all other peer servers. Also,
|
||||
when a new peer server joins the TCN, all existing user accounts will need to
|
||||
be added to their server prior to becoming a full-fledged peer server (this
|
||||
will of course be an automated process).
|
||||
|
||||
The user accounts themselves on the peer servers will be stored in an LDAP
|
||||
database and their SSH keys will be stored inside their shared directory. To
|
||||
preserve security of the LDAP database, it will use TLS from SSL certificates
|
||||
signed by a customer certificate authority (thus isolating the usage of the
|
||||
LDAP database to just the server itself). Additionally, the ppolicy in LDAP
|
||||
should also be applied to lock the account after a certain amount of failed
|
||||
authentication attempts to prevent any brute force attacks by the servers own
|
||||
users. For supported distributions, this setup will of course be automated.
|
||||
|
||||
The rationale for using LDAP is that it provides a resource that users can take
|
||||
advantage of when creating services on the ~center platform. There would be no
|
||||
need for users to create an account for every service on the server, but rather
|
||||
they can simply use their existing account by having the service just
|
||||
authenticate against the LDAP database. However, should a user create an
|
||||
alternative to LDAP to provide the same features utilized here, it can be put
|
||||
to a vote to use this service instead in favor of the HBOSP philosophy of the
|
||||
~center project.
|
||||
|
||||
Additionally, during the process of new users being added into the TCN the peer
|
||||
server the user joined from along with the date they were added should be
|
||||
logged within the ~center database on the peer node. This can be useful for
|
||||
both observing how the TCN is growing along with help to investigate or protect
|
||||
against any rogue peer servers.
|
||||
|
||||
### Shared Directory {#shared-directory}
|
||||
|
||||
When a user gets an account on a peer server, they will be provided with a size
|
||||
limited directory to store any files they wish to be available across the other
|
||||
peer servers. The reason the directory is size limited is to keep with
|
||||
minimizing the prerequisites for peer servers as the number of users in the TCN
|
||||
grows. The size of the shared directory will initially be five megabytes per
|
||||
user with the potential to grow if decided later on by the user base (see the
|
||||
later section on [Governance](#governance)). This size was chosen because it is
|
||||
large enough to hold dotfiles, emails, and a few images while still scaling
|
||||
relatively well as more users join the network (e.g. even if the TCN reaches
|
||||
1000 users, only ~5GB of space will be needed to provide this feature).
|
||||
|
||||
The actual mechanism to employ this feature can be achieved using file system
|
||||
quotas. Like the other features outlined in the ~center project, this will of
|
||||
course be automated to simplify the deployment process as new users join the
|
||||
network. Additionally, the contents of these directories will sync all changes
|
||||
made to the rest of the peer servers (as opposed to periodically copying the
|
||||
directory as a whole which would quickly congest the network as users / peer
|
||||
servers join the network).
|
||||
|
||||
Additionally, while the creation / deletion of the shared directory on other
|
||||
peer servers for users will be facilitated using the dispatcher, the actual
|
||||
syncing of changes to the directory will be initially handled through rsync to
|
||||
the peer servers. Should a service be created by one of the users to replace
|
||||
the functionality rsync for this process, it can be put to a vote to use this
|
||||
service instead in favor of the HBOSP philosophy of the ~center project.
|
||||
|
||||
### Database {#database}
|
||||
|
||||
While the LDAP database takes care of handling the user accounts, peer servers
|
||||
will also need to maintain an SQL database to be used holding the data utilized
|
||||
by the services used throughout the TCN. Also, while the system administrator
|
||||
can choose to use a different SQL database than the one setup by default using
|
||||
the sysadmin scripts, any changes needed to support this SQL database would
|
||||
initially need to be done by the sysadmin wanting to employ this change.
|
||||
|
||||
For the SQL database to be compliant with the ~center project, the database
|
||||
should have the following tables:
|
||||
|
||||
* resources - Anything consumable by a token or service. Fields:
|
||||
* id INTEGER PRIMARY KEY AUTOINCREMENT
|
||||
* type VARCHAR(32)
|
||||
* value VARCHAR(32)
|
||||
* meta BIT DEFAULT 0
|
||||
|
||||
* metadata - Describes additional information about a resource. Fields:
|
||||
* id INTEGER PRIMARY KEY AUTOINCREMENT
|
||||
* resource_id INTEGER
|
||||
* value VARCHAR(32)
|
||||
* FOREIGN KEY (resource_id) REFERENCES resources (id)
|
||||
|
||||
* appdata - Any data that belongs to a specific resource. Fields:
|
||||
* id INTEGER PRIMARY KEY AUTOINCREMENT
|
||||
* resource_id INTEGER
|
||||
* owner_id INTEGER
|
||||
* type VARCHAR(32)
|
||||
* value VARCHAR(MAX) or TEXT
|
||||
* meta BIT DEFAULT 0
|
||||
* FOREIGN KEY (resource_id) REFERENCES resources (id)
|
||||
* FOREIGN KEY (owner_id) REFERENCES resources (id)
|
||||
|
||||
* appmetadata - Describes additional information about application data. Fields:
|
||||
* id INTEGER PRIMARY KEY AUTOINCREMENT
|
||||
* appdata_id INTEGER
|
||||
* value VARCHAR(32)
|
||||
* FOREIGN KEY (appdata_id) REFERENCES appdata (id)
|
||||
|
||||
* tokens - For providing access to resource. Fields:
|
||||
* id INTEGER PRIMARY KEY AUTOINCREMENT
|
||||
* token BINARY(32)
|
||||
* resource_id INTEGER
|
||||
* created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
|
||||
* expires TIMESTAMP DEFAULT NULL
|
||||
* revoked BIT DEFAULT 0
|
||||
* FOREIGN KEY (resource_id) REFERENCES resources (id)
|
||||
|
||||
This is designed to provide the minimal amount of database tables for most
|
||||
services without any additional tables needed to be added in after-the-fact.
|
||||
The resources table can hold various key/value pairs such as usernames, names
|
||||
of services, etc with any additional information that may need to be attached
|
||||
to these values to be placed in the metadata table. Then any application data
|
||||
for a service can be stored in appdata with any additional information about
|
||||
this data stored under appmetadata. The tokens is to provide services access to
|
||||
the data they own while also offering a simple system to for services to share
|
||||
data amongst themselves without needing to duplicate entries.
|
||||
|
||||
### Services {#services}
|
||||
|
||||
Regardless of the efforts that go into providing the ~center project with the
|
||||
architecture to decentralize or federate itself, the true value in the project
|
||||
is the services provided by the servers. Of which, there are two types of
|
||||
services that the server's users can anticipate: tilde services and ~center
|
||||
services.
|
||||
|
||||
#### Tilde Services {#tilde-services}
|
||||
|
||||
Due to the ~center project being a decentralized network of tilde servers at
|
||||
its core, the peer servers will need to provide services expected from a tilde
|
||||
server to become a full-fledged member of the TCN. While it would seem at first
|
||||
that these services would be automatically setup and standardized among the
|
||||
peers like the other components, this is actually not the case here. One of the
|
||||
unique joys of being the sysadmin for a tilde server is going through the rite
|
||||
of passage of choosing and setting up the services that will make up the tilde
|
||||
aspect of the server. So in this instance alone, it will be up to the sysadmin
|
||||
to fulfill this section on their own. However, for the sake of defining a
|
||||
standard, at the bare minimum the peer server should provide its users a shell
|
||||
account and access to an IRC server to communicate with the other users on the
|
||||
TCN to be considered an acceptable tilde server to become a peer server.
|
||||
|
||||
##### Tilde Chat {#tilde-chat}
|
||||
|
||||
During the bootstrapping process of the ~center project, the IRC server
|
||||
currently used in the TCN is [Tilde Chat](https://tilde.chat) since it is an
|
||||
existing decentralized IRC network for tilde servers (in particular, those who
|
||||
are members of the Tildeverse). However, this server can be changed later to a
|
||||
~center operated decentralized IRC network if decided by the users through a
|
||||
vote.
|
||||
|
||||
#### Center Services {#center-services}
|
||||
|
||||
With one of the core philosophies of the ~center project being the development
|
||||
of HBOSPs by users of the TCN, one of the offerings that will bring value to
|
||||
the peer servers will be services created by its users. This can be anything
|
||||
and everything created by its users and will be able to utilize the ~center
|
||||
database if authorized by the sysadmin (primarily to prevent any malicious
|
||||
or ill-intentioned services from accessing the database). Once a service is
|
||||
accepted by a sysadmin, it will be shared to the other peer services so that
|
||||
users can access them from any peer server.
|
||||
|
||||
However, much like how sysadmins of peer servers can choose the kick / ban
|
||||
specific users from their server, they can also make the same decision for
|
||||
services if they find some issue to it running on their server. If this happens
|
||||
to take place, the dispatcher can also reject any transactions from the ~center
|
||||
database related to the rejected service by checking if the resource /
|
||||
resource_id of the transaction belongs to the service. However, realistically
|
||||
this will be done more efficiently by unsubscribing from the events related
|
||||
to the service in the dispatcher so they are never processed to begin with.
|
||||
|
||||
## Proposals {#proposals}
|
||||
|
||||
While this specifies many factors of the ~center project, as time goes by there
|
||||
will likely be a desire to make amendments to the specification of the ~center
|
||||
project. For these circumstances, the Center Enhancement Proposals (CEP) system
|
||||
should be used to propose these changes. A CEP will be to the ~center project
|
||||
what [PEPs](https://www.python.org/dev/peps/) are to
|
||||
[Python](https://www.python.org/), an RFC document isolated to Tilde Center.
|
||||
These documents will of course be federated across the TCN using the dispatcher
|
||||
once a draft is published and will be canonized once agreed upon by the
|
||||
leadership assigned to making these decisions by the currently used governance
|
||||
model.
|
||||
|
||||
### Governance {#governance}
|
||||
|
||||
While some projects do well with having a
|
||||
[BDFL](https://en.wikipedia.org/wiki/Benevolent_dictator_for_life) to handle
|
||||
all the decision-making, this does not scale well with a decentralized model.
|
||||
For this reason, the ~center project will need to establish a governance model
|
||||
to make decisions for itself moving forward as the project and TCN grows. The
|
||||
potential governance models can be proposed using the project's proposal system
|
||||
and the initial governance model chosen will be decided by a vote from the
|
||||
TCN's users using the
|
||||
[Single Transferable Vote](https://www.youtube.com/watch?v=l8XOZJkozfI) system
|
||||
of voting and can be changed later in the future using the same method. This
|
||||
voting system is used to ensure the system that makes the most users content is
|
||||
selected. The ability to change the governance model using the same method at
|
||||
any time is there to prevent the ~center project from being stuck with an
|
||||
undesired governance model and to permanently keep the power to change the
|
||||
governance model in the hands of the users. However, to prevent superfluous
|
||||
elections for new governance models from wasting the time of the community,
|
||||
this election can only be initiated by either having a petition signed by at
|
||||
least 25% of the TCN's user population (i.e. unique users), through a decision
|
||||
from whatever leadership is led by the current governance model to hold a new
|
||||
election, or if a majority (i.e. 50% or more) of the current governance model's
|
||||
leadership resign from their positions and are not replaced through the proper
|
||||
channels within 30 days (with the countdown beginning when the filled
|
||||
leadership positions reaches or goes below 50% and resets whenever the filled
|
||||
leadership positions returns above 50%).
|
||||
|
||||
During elections for new governance models for the ~center project, the voting
|
||||
day must be announced publicly in a manner that is easily accessible to the
|
||||
users in the TCN and be at least two weeks after the decision for a new
|
||||
election to be held is made. The candidates for new governance models must be
|
||||
submitted in the form of a CEP and must have been submitted before the day of
|
||||
the election. For an election to be valid, there must always be an option to
|
||||
vote for none of the proposed governance models and if the option for none of
|
||||
the governance models wins the election, another can be held in two weeks.
|
||||
|
||||
While the voting mechanism can change it must keep the user's vote anonymous,
|
||||
only allow unique users of the TCN to vote once, be stored using a
|
||||
blockchain or a tamper-less append-only log, and must be conducted over the
|
||||
dispatcher so that the results are publically available to all peer servers to
|
||||
verify the results.
|
||||
|
||||
In the event that the ~center project is holding an election for a new
|
||||
governance model, the first election held resulting in no governance model
|
||||
being passed, and over 30 days since the TCN decided to hold an election for a
|
||||
new governance model has passed the TCN will enter an emergency state. During
|
||||
an emergency state, any critical decisions that need to be decided can be made
|
||||
by either the ~center's current project leader (which will initially be the
|
||||
project's founder) but can be vetoed via a petition signed by 25% of unique TCN
|
||||
users within the next two weeks or the new leadership (whichever occurs first).
|
||||
Should the decision be vetoed via petition, the issue cannot be brought up
|
||||
again until the project is no longer in an emergency state.
|
||||
|
||||
## Joining The Network {#joining-the-network}
|
||||
|
||||
Given the unique privileges and influence that peer servers will have in the
|
||||
TCN, peer servers will need to invited into the network by at least one other
|
||||
sysadmin of an existing peer server. Until the first governance model is
|
||||
chosen, sysadmins can do so from their own judgment but this can be changed
|
||||
using a CEP. Should it be discovered that a sysadmin is intentionally adding
|
||||
malicious peer server and/or users to the TCN, their peer server will be
|
||||
ex-communicated from the TCN, they will be removed from any position of
|
||||
power they hold in the leadership, and their account will be banned from the
|
||||
TCN. Should any other sysadmin be found adding this sysadmin back into the TCN,
|
||||
their privileges in the TCN will be suspended until the current leadership
|
||||
decides how to address the situation.
|
||||
|
||||
To add a new peer server to the TCN, the sysadmin of the new server must have
|
||||
an existing account in the TCN and have an existing sysadmin agree to add the
|
||||
new server as one of their peers. To prepare the dispatcher of the existing
|
||||
peer server for the new server, the existing sysadmin must place a random
|
||||
SHA256 hash into a randomly named file in the $HOME directory of the new
|
||||
sysadmin's on the existing peer server. The new sysadmin will then encrypt the
|
||||
value stored in this file using their private GPG key followed by obtaining the
|
||||
UUID and public GPG key of the existing peer server from the sysadmin or public
|
||||
records (neither of these two values need to be hidden from the public). The
|
||||
sysadmin of the new server can then provide the dispatcher with this data to
|
||||
request the existing TCN to join the network.
|
||||
|
||||
Once a new server has been accepted by at least one peer server in the TCN it
|
||||
is officially a member of the ~center project, but it is recommended to have
|
||||
more than one peer server that it communicates with to strengthen its
|
||||
resilience to losing communications with the rest of the TCN.
|
||||
|
||||
## Procedural Information {#procedures}
|
||||
|
||||
### Security Considerations {#security}
|
||||
|
||||
The certificate authority used to sign the SSL certificate for the LDAP
|
||||
database, the signed certificate itself, credentials to the LDAP root user,
|
||||
credentials to the root user of the server, and the private GPG key should
|
||||
NEVER be made publicly available or be accessible by anyone aside from the
|
||||
sysadmin(s). Should any one of these be exposed in any way, they should be
|
||||
changed as soon as possible to retain the integrity of the server's and/or
|
||||
network's security.
|
||||
|
||||
### Configuration Considerations {#config}
|
||||
|
||||
Outside of the configurations already mentioned prior in this document, there
|
||||
are no other required configurations to consider for the Tilde Center project.
|
||||
|
||||
For members of the tildeverse (aside from tilde.center and its peers) no
|
||||
configuration is needed to meet this RFC's request.
|
Loading…
Reference in New Issue