Browse Source

wrap text and trim trailing whitespace

pull/11/head
Ben Harris 2 years ago
parent
commit
a67920bedb
Signed by untrusted user: ben GPG Key ID: 4E0AF802FFF7960C
  1. 82
      drafts/index.php
  2. 3
      navbar.php
  3. 37
      rfcs/index.php
  4. 65
      rfcs/rfc0.md
  5. 46
      rfcs/rfc1.md
  6. 28
      rfcs/rfc2.md
  7. 648
      rfcs/rfc3.md

82
drafts/index.php

@ -1,82 +0,0 @@
<?php
include __DIR__.'/../vendor/autoload.php';
$parser = Rfcs\MDParser::factory();
if (isset($_GET["number"])) {
$num = $_GET["number"];
} elseif (count($_GET) == 1) {
$num = array_keys($_GET)[0];
} else {
$num = "";
}
$filename = "rfc{$num}.md";
if (file_exists($filename)) {
$document = $parser->parse(file_get_contents($filename));
$yml = $document->getYAML();
$content = $document->getContent();
$title = $yml['title'] ?? 'invalid';
$author = htmlspecialchars($yml['author']);
$description = "Draft {$yml['number']}: {$yml['title']} by {$author}";
include __DIR__.'/../header.php';
?>
<a href=".">&lt; back to list</a>
<h1>RFC <?=$yml['number']?>: <?=$yml['title']?></h1>
<p>Author: <?=$author?>
<br />
<?php if (isset($yml['updates'])) { ?>
Updates:
<?php
$arr = explode(", ", $yml['updates']);
foreach ($arr as $num) {
echo "<a href='/rfcs/?{$num}'>{$num}</a>";
if (next($arr)) {
echo ", ";
}
}
?>
<br />
<?php };?>
<?php if (isset($yml['updated-by'])) { ?>
Updated by:
<?php
$arr = explode(", ",$yml['updated-by']);
foreach ($arr as $num) {
echo "<a href='/rfcs/?{$num}'>{$num}</a>";
if (next($arr)) {
echo ", ";
}
}?>
<br />
<?php } ?>
<?=$content?>
<?php
// we need to list the rfcs
} else {
$title="Draft List";
$description="A list of Tildeverse RFCs.";
include __DIR__.'/../header.php';
?>
<h1>Draft List</h1>
<ul>
<?php foreach (glob("*.md") as $rfc) {
$num = substr(basename($rfc,".md"),3);
$yml = $parser->parse(file_get_contents($rfc))->getYAML();
?>
<li><a href="/rfcs/?<?=$num?>">RFC <?=$num?>: <?=$yml['title']?></a></li>
<?php } ?>
</ul>
<?php } ?>
<?php include __DIR__.'/../footer.php'; ?>

3
navbar.php

@ -12,8 +12,7 @@
<div id="navbar" class="navbar-collapse collapse">
<ul class="nav navbar-nav navbar-right">
<li><a href="/"><i class="fa fa-home"></i> Home</a></li>
<li><a href="/rfcs/"><i class="fa fa-file-text"></i> RFC list</a></li>
<li><a href="/drafts/"><i class="fa fa-pencil-square"></i> Drafts</a></li>
<li><a href="/rfcs/"><i class="fa fa-file-text"></i> RFCs</a></li>
<li><a href="https://tildegit.org/tildeverse/rfcs"><i class="fa fa-code-fork"></i> Git</a></li>
</ul>
</div>

37
rfcs/index.php

@ -28,7 +28,8 @@
<h1>RFC <?=$yml['number']?>: <?=$yml['title']?></h1>
<p>Author: <?=$author?>
<p>Author: <?=$author?></p>
<p>Status: <?=$yml["status"]?></p>
<br />
<?php if (isset($yml['updates'])) { ?>
@ -66,16 +67,32 @@
$title="RFC List";
$description="A list of Tildeverse RFCs.";
include __DIR__.'/../header.php';
foreach (glob("*.md") as $rfc) {
$rfcs[] = [
"num" => substr(basename($rfc, ".md"), 3),
"yml" => $parser->parse(file_get_contents($rfc))->getYAML(),
];
}
?>
<h1>RFC List</h1>
<ul>
<?php foreach (glob("*.md") as $rfc) {
$num = substr(basename($rfc,".md"),3);
$yml = $parser->parse(file_get_contents($rfc))->getYAML();
?>
<li><a href="/rfcs/?<?=$num?>">RFC <?=$num?>: <?=$yml['title']?></a></li>
<?php } ?>
</ul>
<h1>RFC List</h1>
<ul>
<?php foreach ($rfcs as $rfc) {
if ($rfc["yml"]["status"] !== "Accepted") continue;
?>
<li><a href="/rfcs/?<?=$rfc["num"]?>">RFC <?=$rfc["num"]?>: <?=$rfc["yml"]['title']?></a></li>
<?php } ?>
</ul>
<h1>Drafts</h1>
<ul>
<?php foreach ($rfcs as $draft) {
if ($draft["yml"]["status"] === "Accepted") continue;
?>
<li><a href="/rfcs/?<?=$draft["num"]?>">Draft <?=$draft["num"]?>: <?=$draft["yml"]["title"]?></a></li>
<?php } ?>
</ul>
<?php } ?>

65
rfcs/rfc0.md

@ -4,9 +4,12 @@ number: 0
author: Robert Miles <khuxkm@tilde.team>
status: Accepted
---
## Abstract
This RFC defines the format used by an RFC. RFCs in this system are stored as Markdown files with YAML front-matter. RFC files MAY be stored with any extension commonly used by markdown files.
This RFC defines the format used by an RFC. RFCs in this system are stored
as Markdown files with YAML front-matter. RFC files MAY be stored with any
extension commonly used by markdown files.
This RFC also defines the semantics of how the RFC system will work.
@ -14,13 +17,18 @@ This RFC also defines the semantics of how the RFC system will work.
The front-matter MUST contain the following key-value pairs:
- `title`: The title of the document. Standards documents should be titled in the format `Standards X: Y` where X is the standards number and Y is the title of the standard. ([See below for an explanation of standards.](#types-of-documents))
- `title`: The title of the document. Standards documents should be
titled in the format `Standards X: Y` where X is the standards number
and Y is the title of the standard. ([See below for an explanation of
standards.](#types-of-documents))
- `number`: The canonical number of the RFC. Starts at 0 (this document) and counts up in decimal.
- `number`: The canonical number of the RFC. Starts at 0 (this document)
and counts up in decimal.
- `author`: The author of the document. May contain email.
- `status`: The status of this document. Should be `Accepted` or `Proposed`. (Rejected documents are not made a part of the repository.)
- `status`: The status of this document. Should be `Accepted` or
`Proposed`. (Rejected documents are not made a part of the repository.)
The front-matter MAY contain the following key-value pairs:
@ -28,40 +36,56 @@ The front-matter MAY contain the following key-value pairs:
- `updated-by`: A comma-seperated list of RFCs that update this RFC.
Note that the two lists should be added to in sequence; if RFC 2 updates RFC 1, then RFC 2 needs to have 1 in its `updates` and RFC 1 needs 2 in its `updated-by`.
Note that the two lists should be added to in sequence; if RFC 2 updates
RFC 1, then RFC 2 needs to have 1 in its `updates` and RFC 1 needs 2 in its
`updated-by`.
## Semantics of the RFC System
The RFC system for tilde boxes will be hosted at https://rfc.tildeverse.org/ and on the tildeverse gitea as [tildeverse/rfcs](https://tildegit.org/tildeverse/rfcs).
The RFC system for tilde boxes will be hosted at
https://rfc.tildeverse.org/ and on the tildeverse gitea as
[tildeverse/rfcs](https://tildegit.org/tildeverse/rfcs).
### Types of Documents
RFC documents are simply requests. They are for simple things like defining how something should work or how something should be done.
RFC documents are simply requests. They are for simple things like defining
how something should work or how something should be done.
Standards documents are like mandates. They require something. For example, this document requires a would-be submitter to follow this
format for RFCs. A Standards document can be amended by RFC documents, and any RFC documents in violation of a Standards document,
unless otherwise stated within the Standards document, are invalid.
Standards documents are like mandates. They require something. For example,
this document requires a would-be submitter to follow this format for RFCs. A
Standards document can be amended by RFC documents, and any RFC documents
in violation of a Standards document, unless otherwise stated within the
Standards document, are invalid.
### Procedural Section
Every RFC and Standards document should end with a procedural information section (id tagged as [#procedures](#procedures)).
Every RFC and Standards document should end with a procedural information
section (id tagged implicitly as [#procedural-section](#procedural-section)).
There are 2 sub-sections to the procedural info section:
- Security Considerations (tagged [#security](#security)) - If there are any security reasons/concerns for the document, they MUST be subsections of this.
- Security Considerations (tagged implicitly as
[#security-considerations](#security-considerations)) - If there are any
security reasons/concerns for the document, they MUST be subsections of this.
- Configuration Considerations (tagged [#config](#config)) - For example, if configs need to be changed due to the RFC.
- Configuration Considerations (tagged implicitly as
[#configuration-considerations](#configuration-considerations)) - For example,
if configs need to be changed due to the RFC.
### Submission guidelines
An RFC should be submitted as a PR to the [git repo](https://tildegit.org/tildeverse/rfcs). RFCs MUST come with a draft name.
An RFC should be submitted as a PR to the [git
repo](https://tildegit.org/tildeverse/rfcs). RFCs MUST come with a draft name.
For example, a draft name for an RFC to make tilde.chat allow IRC connections without SSL could be `draft-tilde-chat-without-ssl`.
For example, a draft name for an RFC to make tilde.chat allow IRC connections
without SSL could be `draft-tilde-chat-without-ssl`.
The only time an RFC can omit the number tag in its front-matter is when it is a draft. Drafts do not have numbers and are of the
status `Proposed`. If or when an RFC is accepted, it will be given a number (at which time it MUST be renamed `rfcX.md`, where X is
the number). The status MUST be changed to `Accepted` and the number tag MUST contain the assigned number. When the former draft
meets these requirements, the PR will be merged.
The only time an RFC can omit the number tag in its front-matter is when it
is a draft. Drafts do not have numbers and are of the status `Proposed`. If
or when an RFC is accepted, it will be given a number (at which time it MUST
be renamed `rfcX.md`, where X is the number). The status MUST be changed to
`Accepted` and the number tag MUST contain the assigned number. When the
former draft meets these requirements, the PR will be merged.
## Procedural Information
@ -71,4 +95,5 @@ There are no security considerations to this document.
### Configuration Considerations
A subdomain of tildeverse.org has been provisioned for the RFC project, and a repo has been created, in accordance with this document.
A subdomain of tildeverse.org has been provisioned for the RFC project,
and a repo has been created, in accordance with this document.

46
rfcs/rfc1.md

@ -2,23 +2,43 @@
title: Remembering A Dear Friend Forever
number: 1
author: Robert Miles <khuxkm@tilde.team>
status: Approved
status: Accepted
---
## Abstract
tilde.town member [abraxas](//tilde.town/~abraxas/) passed away in a motorcycle accident recently. He shall be missed.
tilde.town member [abraxas](https://tilde.town/~abraxas/) passed away in a motorcycle
accident recently. He shall be missed.
## Clacks-Overhead
In Sir Terry Pratchett's Discworld series, the clacks are a series of semaphore towers loosely based on the concept of the telegraph. Invented by an artificer named Robert Dearheart, the towers could send messages "at the speed of light" using standardized codes. When Dearheart's son John died due to an accident while working on a clacks tower, Dearheart inserted John's name into the overhead of the clacks with a "GNU" in front of it (meaning, basically, to send it on, unlogged, and turning around at the end of the line) as a way to memorialize his son forever (or for at least as long as the clacks are standing.) (explanation paraphrased and plagiarized from [GNU Terry Pratchett](https://gnuterrypratchett.com/))
Sir Terry Pratchett himself passed away a few years ago. To commemorate him on the web, the users of the DiscWorld subreddit came up with the idea of a non-standard HTTP header, `X-Clacks-Overhead`, which, much like the overhead it simulates, is virtually invisible unless you're working with HTTP and looking at headers.
In this spirit, I propose that we honor our dear friend abraxas, a true townie, through putting `GNU ~abraxas` in the `X-Clacks-Overhead` header.
> 'We keep that name moving in the Overhead,' he said, and it seemed to Princess that the wind in the shutter arrays above her blew more forlornly, and the everlasting clicking of the shutters grew more urgent. 'He'd never have wanted to go home. He was a real linesman. His name is in the code, in the wind in the rigging and the shutters. **Haven't you ever heard the saying "A man's not dead while his name is still spoken"?'**
>
> -- <cite>Sir Terry Pratchett, Going Postal</cite>
In Sir Terry Pratchett's Discworld series, the clacks are a series of semaphore
towers loosely based on the concept of the telegraph. Invented by an artificer
named Robert Dearheart, the towers could send messages "at the speed of light"
using standardized codes. When Dearheart's son John died due to an accident
while working on a clacks tower, Dearheart inserted John's name into the
overhead of the clacks with a "GNU" in front of it (meaning, basically, to send
it on, unlogged, and turning around at the end of the line) as a way to
memorialize his son forever (or for at least as long as the clacks are
standing.) (explanation paraphrased and plagiarized from
[GNU Terry Pratchett](https://gnuterrypratchett.com/))
Sir Terry Pratchett himself passed away a few years ago. To commemorate him on
the web, the users of the DiscWorld subreddit came up with the idea of a
non-standard HTTP header, `X-Clacks-Overhead`, which, much like the overhead it
simulates, is virtually invisible unless you're working with HTTP and looking
at headers.
In this spirit, I propose that we honor our dear friend abraxas, a true townie,
through putting `GNU ~abraxas` in the `X-Clacks-Overhead` header.
> 'We keep that name moving in the Overhead,' he said, and it seemed to
> Princess that the wind in the shutter arrays above her blew more forlornly,
> and the everlasting clicking of the shutters grew more urgent. 'He'd never
> have wanted to go home. He was a real linesman. His name is in the code, in
> the wind in the rigging and the shutters. **Haven't you ever heard the saying
> "A man's not dead while his name is still spoken"?'**
>
> <cite>Sir Terry Pratchett, Going Postal</cite>
## Procedural Information
@ -28,4 +48,6 @@ There are no security considerations to this document.
### Configuration Considerations
Conforming tildes must add a configuration block to their web server to serve the message. Examples for most servers can be found [here](http://www.gnuterrypratchett.com/#servers).
Conforming tildes must add a configuration block to their web server to serve
the message. Examples for most servers can be found
[here](http://www.gnuterrypratchett.com/#servers).

28
rfcs/rfc2.md

@ -6,27 +6,33 @@ number: 2
---
## Abstract
IRC bots are programs that communicate with users through Internet Relay Chat. These bots can do a wide assortment of things,
from getting weather information to running games. We accept IRC bots on tilde.chat, but we ask that any prospective bot operator
follow these rules.
IRC bots are programs that communicate with users through Internet Relay Chat.
These bots can do a wide assortment of things, from getting weather information
to running games. We accept IRC bots on tilde.chat, but we ask that any
prospective bot operator follow these rules.
### `!botlist` command
The botlist command is our answer to not knowing the functions a bot provides.
All conformant bots MUST respond to `!botlist` with: (examples from [minerbot2](https://tildegit.org/khuxkm/minerbot2), my personal IRC bot)
All conformant bots MUST respond to `!botlist` with: (examples from
[minerbot2](https://tildegit.org/khuxkm/minerbot2), my personal IRC bot)
- Maintainer (e.x.; "Maintainer: khuxkm@tilde.team")
- Small description (optional) (e.x.; "A utility bot that does some other cool things too!")
- Small description (optional) (e.x.; "A utility bot that does some other cool
things too!")
- Command list (e.x; "Commands: !foo !bar")
For conformance with [previous standards on other tilde boxes](https://tilde.town/wiki/bots/ircbots.html), bots SHOULD also respond to `!rollcall` with at least the command list.
For conformance with [previous standards on other tilde
boxes](https://tilde.town/wiki/socializing/irc/list-of-bots.html), bots SHOULD
also respond to `!rollcall` with at least the command list.
Please note that the prefix of `!` is constant: no matter the usual prefix of the bot, it MUST respond to `!botlist` and/or `!rollcall` with the given prefix.
Please note that the prefix of `!` is constant: no matter the usual prefix of
the bot, it MUST respond to `!botlist` and/or `!rollcall` with the given prefix.
### Usermode +B
All bots on tilde.chat must set usermode +B on or near connect.
All bots on tilde.chat MUST set usermode +B on or near connect.
## Procedural Information
@ -36,8 +42,10 @@ There are no security considerations to this document.
### Configuration Considerations
IRC bots on tilde.chat MUST be updated to follow the botlist convention and set usermode +B on connect.
IRC bots on tilde.chat MUST be updated to follow the botlist convention and set
usermode +B on connect.
For bots on tilde.chat coming from tilde.town, maintainer info must be added, as well as an alias from "!botlist" to "!rollcall".
For bots on tilde.chat coming from tilde.town, maintainer info must be added,
as well as an alias from "!botlist" to "!rollcall".
Bots made with [teambot](https://tildegit.org/team/teambot) will be updated to set usermode +B.

648
rfcs/rfc3.md

@ -2,170 +2,170 @@
title: "Tilde Center Specification"
number: 3
author: Austin Ewens <aewens@tilde.center>
status: Approved
status: Accepted
---
## 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
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
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
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
To assist in clarifying the intentions of the project, this section will
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
* 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 - 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
* 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
* 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
* 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
* Tildeverse - A loose association of like-minded tilde communities (see
[here](https://tildeverse.org) for more details).
## Clarifications
Before going any further into the specifics of the ~center project, some
clarifications should be made.
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
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
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
To better understand the peer servers in the Tilde Center Network (herein
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
* 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
* 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)
* 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
* 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
* 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
* 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
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
The next few sections will outline some more of the specifics for the points
listed above.
### 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
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
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
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
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
* /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
* /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
* /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
* /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
* /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
* /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
Aside from /center/home, all other sub-directories under /center will be
synchronized with the other peer servers.
### 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
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
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
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
@ -185,43 +185,43 @@ format:
```
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
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
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
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
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
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
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
@ -246,27 +246,27 @@ existing peer servers:
```
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
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
@ -286,102 +286,102 @@ message in the following form:
```
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
@ -423,181 +423,181 @@ should have the following tables:
* 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
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
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
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
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
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
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
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
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
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
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
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
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
[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
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
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
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
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
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.
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
### Security Considerations
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
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
Outside of the configurations already mentioned prior in this document, there
are no other required configurations to consider for the Tilde Center project.
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
For members of the tildeverse (aside from tilde.center and its peers) no
configuration is needed to meet this RFC's request.

Loading…
Cancel
Save