diff --git a/rfc3.md b/rfc3.md new file mode 100644 index 0000000..f050e97 --- /dev/null +++ b/rfc3.md @@ -0,0 +1,601 @@ +--- +title: "Tilde Center Specification" +number: 3 +author: Austin Ewens +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.