From c8082cb9ae6a1a0f1345973be20774c4bf11220e Mon Sep 17 00:00:00 2001 From: aewens Date: Sun, 17 Feb 2019 05:44:04 +0100 Subject: [PATCH 1/8] First draft of Tilde Center RFC --- draft-tilde-center.md | 578 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 578 insertions(+) create mode 100644 draft-tilde-center.md diff --git a/draft-tilde-center.md b/draft-tilde-center.md new file mode 100644 index 0000000..869842c --- /dev/null +++ b/draft-tilde-center.md @@ -0,0 +1,578 @@ +--- +title: "Standards: Tilde Center Specification" +number: - +author: Austin Ewens +status: Proposed +--- +## Abstract {#abstract} + +TBD + +## Introduction {#introduction} + +The [Tilde Center](https://tilde.center) (herein referred to as ~center) +project was created by Austin Ewens, aka ~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 shared 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 be 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. \ No newline at end of file From ebea9485953596657a85c29ad0ec1e9256591954 Mon Sep 17 00:00:00 2001 From: aewens Date: Sun, 17 Feb 2019 16:19:58 +0100 Subject: [PATCH 2/8] Added abstract --- draft-tilde-center.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/draft-tilde-center.md b/draft-tilde-center.md index 869842c..6e22ba3 100644 --- a/draft-tilde-center.md +++ b/draft-tilde-center.md @@ -1,12 +1,15 @@ --- -title: "Standards: Tilde Center Specification" +title: "Tilde Center Specification" number: - author: Austin Ewens status: Proposed --- ## Abstract {#abstract} -TBD +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} @@ -575,4 +578,4 @@ 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. \ No newline at end of file +resilience to losing communications with the rest of the TCN. From a6e868ad1a5de0d05f0e4b6dd7cbda680c8e7b23 Mon Sep 17 00:00:00 2001 From: aewens Date: Sun, 17 Feb 2019 21:36:07 +0100 Subject: [PATCH 3/8] Fixed grammatic errors and IDs --- draft-tilde-center.md | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/draft-tilde-center.md b/draft-tilde-center.md index 6e22ba3..01184ba 100644 --- a/draft-tilde-center.md +++ b/draft-tilde-center.md @@ -14,10 +14,10 @@ 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, aka ~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. +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} @@ -61,7 +61,7 @@ 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 shared the user accounts along with select data and services +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} @@ -85,7 +85,7 @@ added to the other peer servers. * 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 be direct decisions for another peer server). +admin from one peer server cannot direct decisions for another peer server). * They will NOT be responsible for syncing all other user files. @@ -103,7 +103,7 @@ 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} +### 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 @@ -119,7 +119,7 @@ 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} +### 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 @@ -147,7 +147,7 @@ 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} +### 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 @@ -159,7 +159,7 @@ 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} +#### 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 @@ -198,7 +198,7 @@ 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} +#### 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 @@ -217,7 +217,7 @@ 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} +#### 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 @@ -312,7 +312,7 @@ 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} +### 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, @@ -344,7 +344,7 @@ 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} +### 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 @@ -372,7 +372,7 @@ 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} +### 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 @@ -431,7 +431,7 @@ 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} +### 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 @@ -439,7 +439,7 @@ 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} +#### 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 @@ -454,7 +454,7 @@ 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} +##### 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 @@ -463,7 +463,7 @@ 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} +#### 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 @@ -483,7 +483,7 @@ 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} +## 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 @@ -496,7 +496,7 @@ 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} +### Governance {#governance} While some projects do well with having a [BDFL](https://en.wikipedia.org/wiki/Benevolent_dictator_for_life) to handle From 2acd257a26cc94b8d7c762e4b80037e232510894 Mon Sep 17 00:00:00 2001 From: aewens Date: Sun, 17 Feb 2019 21:54:45 +0100 Subject: [PATCH 4/8] Added procedural information --- draft-tilde-center.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/draft-tilde-center.md b/draft-tilde-center.md index 01184ba..49afdf7 100644 --- a/draft-tilde-center.md +++ b/draft-tilde-center.md @@ -579,3 +579,20 @@ 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. From d7ab49c83655374851b9196bb27e5ced5611b67d Mon Sep 17 00:00:00 2001 From: aewens Date: Sun, 17 Feb 2019 23:07:33 +0100 Subject: [PATCH 5/8] Added further specifications on configurations --- draft-tilde-center.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/draft-tilde-center.md b/draft-tilde-center.md index 49afdf7..f78d8da 100644 --- a/draft-tilde-center.md +++ b/draft-tilde-center.md @@ -595,4 +595,15 @@ 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. +are no other required configurations to consider for the Tilde Center project. + +The configurations that a peer server needs to be a part of the TCN is a +Kademlia DHT of the peer nodes along with the UUID, GPG public key, and domain +name / IP address of the peers it communicates directly with. The configurations +needed to send valid GPG+ messages through the dispatcher are a pair of GPG +keys. For facilitate the user accounts in LDAP it needs to be configured to use +TLS for the LDAPS protocol and have the ppolicy enabled to lock accounts to +prevent internal brute force attacks. Lastly, to properly handle the messages +coming from the dispatcher the SQL database on the system should contain the +specified tables and fields within those tables so that the federated data ends +up in the correct place. From ede21b4e76a7859fd1016c5fbf5c9ab501569e0d Mon Sep 17 00:00:00 2001 From: aewens Date: Mon, 18 Feb 2019 04:40:02 +0100 Subject: [PATCH 6/8] Fixed configuration considerations to meet requirements --- draft-tilde-center.md | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/draft-tilde-center.md b/draft-tilde-center.md index f78d8da..69e0bfe 100644 --- a/draft-tilde-center.md +++ b/draft-tilde-center.md @@ -597,13 +597,5 @@ network's security. Outside of the configurations already mentioned prior in this document, there are no other required configurations to consider for the Tilde Center project. -The configurations that a peer server needs to be a part of the TCN is a -Kademlia DHT of the peer nodes along with the UUID, GPG public key, and domain -name / IP address of the peers it communicates directly with. The configurations -needed to send valid GPG+ messages through the dispatcher are a pair of GPG -keys. For facilitate the user accounts in LDAP it needs to be configured to use -TLS for the LDAPS protocol and have the ppolicy enabled to lock accounts to -prevent internal brute force attacks. Lastly, to properly handle the messages -coming from the dispatcher the SQL database on the system should contain the -specified tables and fields within those tables so that the federated data ends -up in the correct place. +For members of the tildeverse (aside from tilde.center and its peers) no +configuration is needed to meet this RFC's request. From 6df69a6330c530590dc14da57523c253fa7a0b9c Mon Sep 17 00:00:00 2001 From: aewens Date: Mon, 18 Feb 2019 18:05:31 +0100 Subject: [PATCH 7/8] Draft was approved for RFC 3 --- draft-tilde-center.md => rfc3.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename draft-tilde-center.md => rfc3.md (100%) diff --git a/draft-tilde-center.md b/rfc3.md similarity index 100% rename from draft-tilde-center.md rename to rfc3.md From 23ec7c6146de7fa2674e3d80e8e3f6c827c5ebf7 Mon Sep 17 00:00:00 2001 From: aewens Date: Mon, 18 Feb 2019 21:31:22 +0100 Subject: [PATCH 8/8] Added number, status approved --- rfc3.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfc3.md b/rfc3.md index 69e0bfe..f050e97 100644 --- a/rfc3.md +++ b/rfc3.md @@ -1,8 +1,8 @@ --- title: "Tilde Center Specification" -number: - +number: 3 author: Austin Ewens -status: Proposed +status: Approved --- ## Abstract {#abstract}