Fixed grammatic errors and IDs
This commit is contained in:
parent
ebea948595
commit
a6e868ad1a
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue