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