Compare commits
No commits in common. "master" and "master" have entirely different histories.
21
.drone.yml
21
.drone.yml
|
@ -1,21 +0,0 @@
|
|||
---
|
||||
kind: pipeline
|
||||
type: ssh
|
||||
name: deploy
|
||||
server:
|
||||
host:
|
||||
from_secret: host
|
||||
user:
|
||||
from_secret: username
|
||||
ssh_key:
|
||||
from_secret: ssh_key
|
||||
clone:
|
||||
disable: true
|
||||
trigger:
|
||||
branch:
|
||||
- master
|
||||
steps:
|
||||
- name: deploy
|
||||
commands:
|
||||
- sudo -Hu www-data git -C /var/www/rfc.tildeverse.org pull --rebase origin master
|
||||
|
|
@ -1,2 +1,3 @@
|
|||
/vendor/
|
||||
composer.phar
|
||||
|
||||
|
|
11
README.md
11
README.md
|
@ -4,13 +4,4 @@ Similar to [khuxkm's previous attempt](https://github.com/tildetown/tilde-rfcs),
|
|||
|
||||
However, unlike that attempt, this system will use YAML front-matter.
|
||||
|
||||
See [RFC 0](https://rfc.tildeverse.org/rfcs/0) for more info.
|
||||
|
||||
## nginx configs
|
||||
```
|
||||
location ~* ^/rfcs/(.+)$ {
|
||||
try_files $uri $uri/ /rfcs/index.php?$1;
|
||||
include snippets/php.conf;
|
||||
}
|
||||
```
|
||||
|
||||
See [RFC 0](https://rfc.tildeverse.org/rfc.php?number=0) for more info.
|
||||
|
|
|
@ -1,11 +1,6 @@
|
|||
{
|
||||
"require": {
|
||||
"tildeverse/wiki": "dev-master"
|
||||
},
|
||||
"repositories": [
|
||||
{
|
||||
"type": "vcs",
|
||||
"url": "https://tildegit.org/ben/tildewiki"
|
||||
"mnapoli/front-yaml": "^1.6",
|
||||
"michelf/php-markdown": "^1.8"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
|
@ -1,23 +1,23 @@
|
|||
{
|
||||
"_readme": [
|
||||
"This file locks the dependencies of your project to a known state",
|
||||
"Read more about it at https://getcomposer.org/doc/01-basic-usage.md#installing-dependencies",
|
||||
"Read more about it at https://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file",
|
||||
"This file is @generated automatically"
|
||||
],
|
||||
"content-hash": "3ab3df15c4e40417f427b37691e83088",
|
||||
"content-hash": "f693531fd51bd92297c17d6a290a6f16",
|
||||
"packages": [
|
||||
{
|
||||
"name": "erusev/parsedown",
|
||||
"version": "1.7.3",
|
||||
"version": "1.7.1",
|
||||
"source": {
|
||||
"type": "git",
|
||||
"url": "https://github.com/erusev/parsedown.git",
|
||||
"reference": "6d893938171a817f4e9bc9e86f2da1e370b7bcd7"
|
||||
"reference": "92e9c27ba0e74b8b028b111d1b6f956a15c01fc1"
|
||||
},
|
||||
"dist": {
|
||||
"type": "zip",
|
||||
"url": "https://api.github.com/repos/erusev/parsedown/zipball/6d893938171a817f4e9bc9e86f2da1e370b7bcd7",
|
||||
"reference": "6d893938171a817f4e9bc9e86f2da1e370b7bcd7",
|
||||
"url": "https://api.github.com/repos/erusev/parsedown/zipball/92e9c27ba0e74b8b028b111d1b6f956a15c01fc1",
|
||||
"reference": "92e9c27ba0e74b8b028b111d1b6f956a15c01fc1",
|
||||
"shasum": ""
|
||||
},
|
||||
"require": {
|
||||
|
@ -50,51 +50,53 @@
|
|||
"markdown",
|
||||
"parser"
|
||||
],
|
||||
"time": "2019-03-17T18:48:37+00:00"
|
||||
"time": "2018-03-08T01:11:30+00:00"
|
||||
},
|
||||
{
|
||||
"name": "erusev/parsedown-extra",
|
||||
"version": "0.7.1",
|
||||
"name": "michelf/php-markdown",
|
||||
"version": "1.8.0",
|
||||
"source": {
|
||||
"type": "git",
|
||||
"url": "https://github.com/erusev/parsedown-extra.git",
|
||||
"reference": "0db5cce7354e4b76f155d092ab5eb3981c21258c"
|
||||
"url": "https://github.com/michelf/php-markdown.git",
|
||||
"reference": "01ab082b355bf188d907b9929cd99b2923053495"
|
||||
},
|
||||
"dist": {
|
||||
"type": "zip",
|
||||
"url": "https://api.github.com/repos/erusev/parsedown-extra/zipball/0db5cce7354e4b76f155d092ab5eb3981c21258c",
|
||||
"reference": "0db5cce7354e4b76f155d092ab5eb3981c21258c",
|
||||
"url": "https://api.github.com/repos/michelf/php-markdown/zipball/01ab082b355bf188d907b9929cd99b2923053495",
|
||||
"reference": "01ab082b355bf188d907b9929cd99b2923053495",
|
||||
"shasum": ""
|
||||
},
|
||||
"require": {
|
||||
"erusev/parsedown": "~1.4"
|
||||
"php": ">=5.3.0"
|
||||
},
|
||||
"type": "library",
|
||||
"autoload": {
|
||||
"psr-0": {
|
||||
"ParsedownExtra": ""
|
||||
"psr-4": {
|
||||
"Michelf\\": "Michelf/"
|
||||
}
|
||||
},
|
||||
"notification-url": "https://packagist.org/downloads/",
|
||||
"license": [
|
||||
"MIT"
|
||||
"BSD-3-Clause"
|
||||
],
|
||||
"authors": [
|
||||
{
|
||||
"name": "Emanuil Rusev",
|
||||
"email": "hello@erusev.com",
|
||||
"homepage": "http://erusev.com"
|
||||
"name": "Michel Fortin",
|
||||
"email": "michel.fortin@michelf.ca",
|
||||
"homepage": "https://michelf.ca/",
|
||||
"role": "Developer"
|
||||
},
|
||||
{
|
||||
"name": "John Gruber",
|
||||
"homepage": "https://daringfireball.net/"
|
||||
}
|
||||
],
|
||||
"description": "An extension of Parsedown that adds support for Markdown Extra.",
|
||||
"homepage": "https://github.com/erusev/parsedown-extra",
|
||||
"description": "PHP Markdown",
|
||||
"homepage": "https://michelf.ca/projects/php-markdown/",
|
||||
"keywords": [
|
||||
"markdown",
|
||||
"markdown extra",
|
||||
"parsedown",
|
||||
"parser"
|
||||
"markdown"
|
||||
],
|
||||
"time": "2015-11-01T10:19:22+00:00"
|
||||
"time": "2018-01-15T00:49:33+00:00"
|
||||
},
|
||||
{
|
||||
"name": "mnapoli/front-yaml",
|
||||
|
@ -133,16 +135,16 @@
|
|||
},
|
||||
{
|
||||
"name": "symfony/polyfill-ctype",
|
||||
"version": "v1.11.0",
|
||||
"version": "v1.9.0",
|
||||
"source": {
|
||||
"type": "git",
|
||||
"url": "https://github.com/symfony/polyfill-ctype.git",
|
||||
"reference": "82ebae02209c21113908c229e9883c419720738a"
|
||||
"reference": "e3d826245268269cd66f8326bd8bc066687b4a19"
|
||||
},
|
||||
"dist": {
|
||||
"type": "zip",
|
||||
"url": "https://api.github.com/repos/symfony/polyfill-ctype/zipball/82ebae02209c21113908c229e9883c419720738a",
|
||||
"reference": "82ebae02209c21113908c229e9883c419720738a",
|
||||
"url": "https://api.github.com/repos/symfony/polyfill-ctype/zipball/e3d826245268269cd66f8326bd8bc066687b4a19",
|
||||
"reference": "e3d826245268269cd66f8326bd8bc066687b4a19",
|
||||
"shasum": ""
|
||||
},
|
||||
"require": {
|
||||
|
@ -154,7 +156,7 @@
|
|||
"type": "library",
|
||||
"extra": {
|
||||
"branch-alias": {
|
||||
"dev-master": "1.11-dev"
|
||||
"dev-master": "1.9-dev"
|
||||
}
|
||||
},
|
||||
"autoload": {
|
||||
|
@ -187,20 +189,20 @@
|
|||
"polyfill",
|
||||
"portable"
|
||||
],
|
||||
"time": "2019-02-06T07:57:58+00:00"
|
||||
"time": "2018-08-06T14:22:27+00:00"
|
||||
},
|
||||
{
|
||||
"name": "symfony/yaml",
|
||||
"version": "v4.3.2",
|
||||
"version": "v4.1.3",
|
||||
"source": {
|
||||
"type": "git",
|
||||
"url": "https://github.com/symfony/yaml.git",
|
||||
"reference": "c60ecf5ba842324433b46f58dc7afc4487dbab99"
|
||||
"reference": "46bc69aa91fc4ab78a96ce67873a6b0c148fd48c"
|
||||
},
|
||||
"dist": {
|
||||
"type": "zip",
|
||||
"url": "https://api.github.com/repos/symfony/yaml/zipball/c60ecf5ba842324433b46f58dc7afc4487dbab99",
|
||||
"reference": "c60ecf5ba842324433b46f58dc7afc4487dbab99",
|
||||
"url": "https://api.github.com/repos/symfony/yaml/zipball/46bc69aa91fc4ab78a96ce67873a6b0c148fd48c",
|
||||
"reference": "46bc69aa91fc4ab78a96ce67873a6b0c148fd48c",
|
||||
"shasum": ""
|
||||
},
|
||||
"require": {
|
||||
|
@ -219,7 +221,7 @@
|
|||
"type": "library",
|
||||
"extra": {
|
||||
"branch-alias": {
|
||||
"dev-master": "4.3-dev"
|
||||
"dev-master": "4.1-dev"
|
||||
}
|
||||
},
|
||||
"autoload": {
|
||||
|
@ -246,45 +248,13 @@
|
|||
],
|
||||
"description": "Symfony Yaml Component",
|
||||
"homepage": "https://symfony.com",
|
||||
"time": "2019-04-06T14:04:46+00:00"
|
||||
},
|
||||
{
|
||||
"name": "tildeverse/wiki",
|
||||
"version": "dev-master",
|
||||
"source": {
|
||||
"type": "git",
|
||||
"url": "https://tildegit.org/ben/tildewiki",
|
||||
"reference": "751eb64c383cb7c6ec643eaf683b88aa1de351ea"
|
||||
},
|
||||
"require": {
|
||||
"erusev/parsedown-extra": "^0.7.1",
|
||||
"mnapoli/front-yaml": "^1.6"
|
||||
},
|
||||
"type": "library",
|
||||
"autoload": {
|
||||
"psr-4": {
|
||||
"Tildeverse\\Wiki\\": "src/"
|
||||
}
|
||||
},
|
||||
"license": [
|
||||
"GPLv3"
|
||||
],
|
||||
"authors": [
|
||||
{
|
||||
"name": "Ben Harris",
|
||||
"email": "ben@tilde.team"
|
||||
}
|
||||
],
|
||||
"description": "parsedown extensions for tilde wikis",
|
||||
"time": "2019-07-03T05:06:34+00:00"
|
||||
"time": "2018-07-26T11:24:31+00:00"
|
||||
}
|
||||
],
|
||||
"packages-dev": [],
|
||||
"aliases": [],
|
||||
"minimum-stability": "stable",
|
||||
"stability-flags": {
|
||||
"tildeverse/wiki": 20
|
||||
},
|
||||
"stability-flags": [],
|
||||
"prefer-stable": false,
|
||||
"prefer-lowest": false,
|
||||
"platform": [],
|
||||
|
|
|
@ -1,25 +1,22 @@
|
|||
---
|
||||
title: "Tilde Center Specification"
|
||||
number: 3
|
||||
title: "Standards: Tilde Center Specification"
|
||||
number: -
|
||||
author: Austin Ewens <aewens@tilde.center>
|
||||
status: Accepted
|
||||
status: Proposed
|
||||
---
|
||||
## Abstract
|
||||
## Abstract {#abstract}
|
||||
|
||||
This document outlines the core philosophy and components that the Tilde Center
|
||||
project is composed of, as well as laying out the fundation to bootstrap the
|
||||
rest of the project for future modifications and expansion to create a
|
||||
sustainable, self-reliant, decentralized network of tilde servers.
|
||||
TBD
|
||||
|
||||
## Introduction
|
||||
## Introduction {#introduction}
|
||||
|
||||
The [Tilde Center](https://tilde.center) (herein referred to as ~center)
|
||||
project was created by Austin Ewens (better known in the community as ~aewens),
|
||||
in December 2018. The goal of the project is to create a decentralized and
|
||||
federated server architecture built upon home-brewed open source projects
|
||||
(herein referred to as HBOSP) made by and maintained by its user base.
|
||||
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 {#terminology}
|
||||
|
||||
To assist in clarifying the intentions of the project, this section will
|
||||
outline the meanings behind the terminology used thought the document:
|
||||
|
@ -49,7 +46,7 @@ another.
|
|||
* Tildeverse - A loose association of like-minded tilde communities (see
|
||||
[here](https://tildeverse.org) for more details).
|
||||
|
||||
## Clarifications
|
||||
## Clarifications {#clarifications}
|
||||
|
||||
Before going any further into the specifics of the ~center project, some
|
||||
clarifications should be made.
|
||||
|
@ -61,10 +58,10 @@ 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
|
||||
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 {#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:
|
||||
|
@ -85,7 +82,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 direct decisions for another peer server).
|
||||
admin from one peer server cannot be direct decisions for another peer server).
|
||||
|
||||
* They will NOT be responsible for syncing all other user files.
|
||||
|
||||
|
@ -103,7 +100,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}
|
||||
|
||||
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 +116,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}
|
||||
|
||||
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 +144,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}
|
||||
|
||||
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 +156,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}
|
||||
|
||||
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 +195,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}
|
||||
|
||||
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 +214,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}
|
||||
|
||||
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 +309,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}
|
||||
|
||||
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 +341,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}
|
||||
|
||||
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 +369,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}
|
||||
|
||||
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
|
||||
|
@ -409,10 +406,8 @@ should have the following tables:
|
|||
* appmetadata - Describes additional information about application data. Fields:
|
||||
* id INTEGER PRIMARY KEY AUTOINCREMENT
|
||||
* appdata_id INTEGER
|
||||
* metadata_id INTEGER
|
||||
* value VARCHAR(32)
|
||||
* FOREIGN KEY (appdata_id) REFERENCES appdata (id)
|
||||
* FOREIGN KEY (metadata_id) REFERENCES appdata (id)
|
||||
|
||||
* tokens - For providing access to resource. Fields:
|
||||
* id INTEGER PRIMARY KEY AUTOINCREMENT
|
||||
|
@ -433,7 +428,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}
|
||||
|
||||
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
|
||||
|
@ -441,7 +436,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}
|
||||
|
||||
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
|
||||
|
@ -456,7 +451,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}
|
||||
|
||||
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
|
||||
|
@ -465,7 +460,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}
|
||||
|
||||
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
|
||||
|
@ -485,7 +480,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}
|
||||
|
||||
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
|
||||
|
@ -498,7 +493,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}
|
||||
|
||||
While some projects do well with having a
|
||||
[BDFL](https://en.wikipedia.org/wiki/Benevolent_dictator_for_life) to handle
|
||||
|
@ -551,7 +546,7 @@ 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 {#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
|
||||
|
@ -581,23 +576,3 @@ 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
|
||||
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.
|
||||
|
||||
For members of the tildeverse (aside from tilde.center and its peers) no
|
||||
configuration is needed to meet this RFC's request.
|
|
@ -0,0 +1,32 @@
|
|||
<?php
|
||||
include 'vendor/autoload.php';
|
||||
class MDParse implements Mni\FrontYAML\Markdown\MarkdownParser {
|
||||
public function parse($markdown) {
|
||||
return Michelf\MarkdownExtra::defaultTransform($markdown);
|
||||
}
|
||||
}
|
||||
|
||||
$parser = new Mni\FrontYAML\Parser(null, new MDParse());
|
||||
$filename = 'draft-'.$_GET["name"].'.md';
|
||||
if (!file_exists($filename)) {
|
||||
header("Location: https://rfc.tildeverse.org/");
|
||||
die();
|
||||
}
|
||||
$document = $parser->parse(file_get_contents($filename));
|
||||
$yml = $document->getYAML();
|
||||
$content = $document->getContent();
|
||||
$title = ($yml['title'] ?? 'invalid');
|
||||
$author_san = htmlspecialchars($yml['author']);
|
||||
$description = "Draft {$_GET['name']}: {$yml['title']} by {$author_san}";
|
||||
include 'header.php';
|
||||
?>
|
||||
<h1>Draft <?=$_GET['name']?>: <?=$yml['title']?></h1>
|
||||
<p>Author: <?=htmlspecialchars($yml['author'])?><br />
|
||||
<?php if(isset($yml['updates'])){?>
|
||||
Updates: <?php $arr=explode(", ",$yml['updates']); foreach($arr as $num) { echo "<a href='./rfc.php?number={$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='./rfc.php?number={$num}'>{$num}</a>"; if(next($arr)) { echo ", "; }}?><br />
|
||||
<?php };?>
|
||||
<?=$content?>
|
||||
<?php include 'footer.php'; ?>
|
12
header.php
12
header.php
|
@ -10,21 +10,11 @@
|
|||
|
||||
<meta property="og:title" content="tildeverse RFCs | <?=($title ?? 'the tildeverse RFC system')?>">
|
||||
<meta property="og:url" content="https://rfc.tildeverse.org<?=$_SERVER['REQUEST_URI']?>">
|
||||
<meta property="og:description" content="<?=($desc ?? ($title ?? 'the home of the tildeverse RFC system'))?>">
|
||||
<meta property="og:description" content="<?=($desc??($title??'the home of the tildeverse RFC system'))?>">
|
||||
<meta property="og:image" content="https://rfc.tildeverse.org/apple-icon.png">
|
||||
<meta property="og:site_name" content="tildeverse RFCs">
|
||||
<meta property="og:type" content="website">
|
||||
|
||||
<style>
|
||||
/* offset #fragments */
|
||||
:target:before {
|
||||
content: "";
|
||||
display: block;
|
||||
height: 70px;
|
||||
margin: -70px 0 0;
|
||||
}
|
||||
</style>
|
||||
|
||||
</head>
|
||||
<body style="padding-top: 70px;">
|
||||
<div class="container">
|
||||
|
|
44
index.php
44
index.php
|
@ -1,29 +1,25 @@
|
|||
<?php include __DIR__.'/header.php'; ?>
|
||||
<?php include "header.php";?>
|
||||
<h2>Tildeverse RFC system</h2>
|
||||
<blockquote>
|
||||
<p>...The RFC system for tilde boxes will be hosted at https://rfc.tildeverse.org/ and on the tildeverse gitea as <a href="//git.tildeverse.org/tildeverse/rfcs">tildeverse/rfcs</a>...</p>
|
||||
<p>...RFC documents are simply requests. They are for simple things like defining how something should work or how something should be done.</p>
|
||||
<p>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.</p>
|
||||
<footer>
|
||||
<cite><a href="./rfc.php?number=0">RFC 0: Standard 1: RFC Format and Semantics</a> by <a href="https://tilde.team/~khuxkm">Robert Miles</a> (aka khuxkm)</cite>
|
||||
</footer>
|
||||
</blockquote>
|
||||
|
||||
<h2>Tildeverse RFC system</h2>
|
||||
This system aims to help codify some things about Tildeverse tilde servers.
|
||||
|
||||
<blockquote>
|
||||
<p>...The RFC system for tilde boxes will be hosted at https://rfc.tildeverse.org/ and on the tildeverse gitea as <a href="https://tildegit.org/tildeverse/rfcs">tildeverse/rfcs</a>...</p>
|
||||
<p>...RFC documents are simply requests. They are for simple things like defining how something should work or how something should be done.</p>
|
||||
<p>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.</p>
|
||||
<footer>
|
||||
<cite>
|
||||
<a href="/rfcs/0">RFC 0: Standard 1: RFC Format and Semantics</a>
|
||||
by <a href="https://tilde.team/~khuxkm/">Robert Miles</a> (aka khuxkm)
|
||||
</cite>
|
||||
</footer>
|
||||
</blockquote>
|
||||
<h3>Submission guidelines (<a href="./rfc.php?number=0">from the standard</a>)</h3>
|
||||
|
||||
<p>This system aims to help codify some things about Tildeverse tilde servers.</p>
|
||||
<p>An RFC should be submitted as a PR to the <a href="https://git.tildeverse.org/tildeverse/rfcs">git repo</a>.</p>
|
||||
|
||||
<h3>Submission guidelines (<a href="/rfcs/0">from the standard</a>)</h3>
|
||||
<p>Until your RFC gets assigned a number, give it a draft name. For example, a draft name for an RFC to make tilde.chat allow IRC connections without SSL could be <code>draft-tilde-chat-without-ssl</code>.</p>
|
||||
|
||||
<p>An RFC should be submitted as a PR to the <a href="https://tildegit.org/tildeverse/rfcs">git repo</a>.</p>
|
||||
|
||||
<p>Until your RFC gets assigned a number, give it a draft name. For example, a draft name for an RFC to make tilde.chat allow IRC connections without SSL could be <code>draft-tilde-chat-without-ssl</code>.</p>
|
||||
|
||||
<p>Your RFC stays a draft until it is accepted. If or when an RFC is accepted, it will be assigned a number. The status must be changed to <code>Accepted</code> and the number tag must contain the assigned number. When you finish doing this, the PR will be merged.</p>
|
||||
|
||||
<?php include __DIR__.'/footer.php'; ?>
|
||||
<p>Your RFC stays a draft until it is accepted. If or when an RFC is accepted, it will be given a number (at which time it must be renamed <code>rfcX.md</code>, where X is
|
||||
the number). The status must be changed to <code>Accepted</code> and the number tag must contain the assigned number. When you
|
||||
finish doing this, the PR will be merged.</p>
|
||||
<?php include 'footer.php';?>
|
||||
|
|
12
navbar.php
12
navbar.php
|
@ -11,10 +11,16 @@
|
|||
</div>
|
||||
<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> RFCs</a></li>
|
||||
<li><a href="https://tildegit.org/tildeverse/rfcs"><i class="fa fa-code-fork"></i> Git</a></li>
|
||||
<li><a href="/"><i class="fa fa-home"></i> home</a></li>
|
||||
<li class="dropdown">
|
||||
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" aria-expanded="false">pages <span class="caret"></span></a>
|
||||
<ul class="dropdown-menu" role="menu">
|
||||
<li><a href="https://rfc.tildeverse.org/rfclist.php"><i class="fa fa-file-text"></i> RFC list</a></li>
|
||||
<li><a href="https://git.tildeverse.org/tildeverse/rfcs"><i class="fa fa-code-fork"></i> git</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</nav>
|
||||
|
||||
|
|
|
@ -0,0 +1,32 @@
|
|||
<?php
|
||||
include 'vendor/autoload.php';
|
||||
class MDParse implements Mni\FrontYAML\Markdown\MarkdownParser {
|
||||
public function parse($markdown) {
|
||||
return Michelf\MarkdownExtra::defaultTransform($markdown);
|
||||
}
|
||||
}
|
||||
|
||||
$parser = new Mni\FrontYAML\Parser(null, new MDParse());
|
||||
$filename = 'rfc'.$_GET["number"].'.md';
|
||||
if (!file_exists($filename)) {
|
||||
header("Location: https://rfc.tildeverse.org/");
|
||||
die();
|
||||
}
|
||||
$document = $parser->parse(file_get_contents($filename));
|
||||
$yml = $document->getYAML();
|
||||
$content = $document->getContent();
|
||||
$title = ($yml['title'] ?? 'invalid');
|
||||
$author_san = htmlspecialchars($yml['author']);
|
||||
$description = "RFC {$yml['number']}: {$yml['title']} by {$author_san}";
|
||||
include 'header.php';
|
||||
?>
|
||||
<h1>RFC <?=$yml['number']?>: <?=$yml['title']?></h1>
|
||||
<p>Author: <?=htmlspecialchars($yml['author'])?><br />
|
||||
<?php if(isset($yml['updates'])){?>
|
||||
Updates: <?php $arr=explode(", ",$yml['updates']); foreach($arr as $num) { echo "<a href='./rfc.php?number={$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='./rfc.php?number={$num}'>{$num}</a>"; if(next($arr)) { echo ", "; }}?><br />
|
||||
<?php };?>
|
||||
<?=$content?>
|
||||
<?php include 'footer.php'; ?>
|
|
@ -0,0 +1,74 @@
|
|||
---
|
||||
title: "Standard 1: RFC Format and Semantics"
|
||||
number: 0
|
||||
author: Robert Miles <khuxkm@tilde.team>
|
||||
status: Approved
|
||||
---
|
||||
## Abstract {#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 also defines the semantics of how the RFC system will work.
|
||||
|
||||
## Front-matter format {#front-matter-format}
|
||||
|
||||
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.](#doc-types))
|
||||
|
||||
- `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.)
|
||||
|
||||
The front-matter MAY contain the following key-value pairs:
|
||||
|
||||
- `updates`: A comma-seperated list of RFCs this RFC updates.
|
||||
|
||||
- `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`.
|
||||
|
||||
## Semantics of the RFC System {#semantics-of-system}
|
||||
|
||||
The RFC system for tilde boxes will be hosted at https://rfc.tildeverse.org/ and on the tildeverse gitea as [tildeverse/rfcs](//git.tildeverse.org/tildeverse/rfcs).
|
||||
|
||||
### Types of Documents {#doc-types}
|
||||
|
||||
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.
|
||||
|
||||
### Procedural Section {#procedural-section}
|
||||
|
||||
Every RFC and Standards document should end with a procedural information section (id tagged as [#procedures](#procedures)).
|
||||
|
||||
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.
|
||||
|
||||
- Configuration Considerations (tagged [#config](#config)) - For example, if configs need to be changed due to the RFC.
|
||||
|
||||
### Submission guidelines {#submission}
|
||||
|
||||
An RFC should be submitted as a PR to the [git repo](https://git.tildeverse.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`.
|
||||
|
||||
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 {#procedures}
|
||||
|
||||
### Security Considerations {#security}
|
||||
|
||||
There are no security considerations to this document.
|
||||
|
||||
### Configuration Considerations {#config}
|
||||
|
||||
A subdomain of tildeverse.org has been provisioned for the RFC project, and a repo has been created, in accordance with this document.
|
|
@ -0,0 +1,31 @@
|
|||
---
|
||||
title: Remembering A Dear Friend Forever
|
||||
number: 1
|
||||
author: Robert Miles <khuxkm@tilde.team>
|
||||
status: Approved
|
||||
---
|
||||
## Abstract {#abstract}
|
||||
|
||||
tilde.town member [abraxas](//tilde.town/~abraxas/) passed away in a motorcycle accident recently. He shall be missed.
|
||||
|
||||
## Clacks-Overhead {#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>
|
||||
|
||||
## Procedural Information {#procedures}
|
||||
|
||||
### Security Considerations {#security}
|
||||
|
||||
There are no security considerations to this document.
|
||||
|
||||
### Configuration Considerations {#config}
|
||||
|
||||
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).
|
|
@ -0,0 +1,43 @@
|
|||
---
|
||||
title: Standardising IRC Bot Behavior
|
||||
author: Robert Miles <khuxkm@tilde.team>
|
||||
status: Accepted
|
||||
number: 2
|
||||
---
|
||||
## Abstract {#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.
|
||||
|
||||
### `!botlist` command {#botlist}
|
||||
|
||||
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)
|
||||
|
||||
- Maintainer (e.x.; "Maintainer: khuxkm@tilde.team")
|
||||
- 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.
|
||||
|
||||
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.
|
||||
|
||||
## Procedural Information {#procedures}
|
||||
|
||||
### Security Considerations {#security}
|
||||
|
||||
There are no security considerations to this document.
|
||||
|
||||
### Configuration Considerations {#config}
|
||||
|
||||
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".
|
||||
|
||||
Bots made with [teambot](https://tildegit.org/team/teambot) will be updated to set usermode +B.
|
|
@ -0,0 +1,17 @@
|
|||
<?php
|
||||
include 'vendor/autoload.php';
|
||||
$parser = new Mni\FrontYAML\Parser();
|
||||
$title="RFC List";
|
||||
$description="A list of Tildeverse RFCs.";
|
||||
include 'header.php';
|
||||
?>
|
||||
<h1>RFC List</h1>
|
||||
<ul>
|
||||
<?php
|
||||
foreach (glob("./rfc*.md") as $rfc) {
|
||||
$num = substr(basename($rfc,".md"),3);
|
||||
$yml = $parser->parse(file_get_contents($rfc))->getYAML();
|
||||
echo "\t<li><a href='rfc.php?number={$num}'>RFC {$num}: {$yml['title']}</a></li>\n";
|
||||
}
|
||||
?></ul>
|
||||
<?php include 'footer.php';?>
|
|
@ -1,99 +0,0 @@
|
|||
<?php
|
||||
include __DIR__.'/../vendor/autoload.php';
|
||||
|
||||
$parser = Tildeverse\Wiki\Parser::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 = "RFC {$yml['number']}: {$yml['title']} by {$author}";
|
||||
|
||||
include __DIR__.'/../header.php';
|
||||
|
||||
?>
|
||||
|
||||
<a href=".">< back to list</a>
|
||||
|
||||
<h1>RFC <?=$yml['number']?>: <?=$yml['title']?></h1>
|
||||
|
||||
<p>Author: <?=$author?></p>
|
||||
<p>Status: <?=$yml["status"]?></p>
|
||||
<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="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 ($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 } ?>
|
||||
|
||||
<?php include __DIR__.'/../footer.php'; ?>
|
99
rfcs/rfc0.md
99
rfcs/rfc0.md
|
@ -1,99 +0,0 @@
|
|||
---
|
||||
title: "Standard 1: RFC Format and Semantics"
|
||||
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 also defines the semantics of how the RFC system will work.
|
||||
|
||||
## Front-matter format
|
||||
|
||||
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))
|
||||
|
||||
- `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.)
|
||||
|
||||
The front-matter MAY contain the following key-value pairs:
|
||||
|
||||
- `updates`: A comma-seperated list of RFCs this RFC updates.
|
||||
|
||||
- `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`.
|
||||
|
||||
## 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).
|
||||
|
||||
### 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.
|
||||
|
||||
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 implicitly as [#procedural-section](#procedural-section)).
|
||||
|
||||
There are 2 sub-sections to the procedural info section:
|
||||
|
||||
- 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 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.
|
||||
|
||||
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.
|
||||
|
||||
## Procedural Information
|
||||
|
||||
### Security Considerations
|
||||
|
||||
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.
|
53
rfcs/rfc1.md
53
rfcs/rfc1.md
|
@ -1,53 +0,0 @@
|
|||
---
|
||||
title: Remembering A Dear Friend Forever
|
||||
number: 1
|
||||
author: Robert Miles <khuxkm@tilde.team>
|
||||
status: Accepted
|
||||
---
|
||||
## Abstract
|
||||
|
||||
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>
|
||||
|
||||
## Procedural Information
|
||||
|
||||
### Security Considerations
|
||||
|
||||
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).
|
62
rfcs/rfc2.md
62
rfcs/rfc2.md
|
@ -1,62 +0,0 @@
|
|||
---
|
||||
title: Standardising IRC Bot Behavior
|
||||
author: Robert Miles <khuxkm@tilde.team>
|
||||
status: Accepted
|
||||
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.
|
||||
|
||||
### `!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)
|
||||
|
||||
- Maintainer (e.x.; "Maintainer: khuxkm@tilde.team")
|
||||
- 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/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.
|
||||
|
||||
### Usermode +B
|
||||
|
||||
All bots on tilde.chat MUST set usermode +B on or near connect.
|
||||
|
||||
### Rejoin-on-kick
|
||||
|
||||
All bots on tilde.chat MUST NOT rejoin a channel automatically after being
|
||||
kicked. If a channel operator wishes to remove your bot from their channel, you
|
||||
must obey.
|
||||
|
||||
An exception is made for certain mechanisms to automatically rejoin;
|
||||
specifically, if the channel operator can turn off the auto-rejoin behavior, it
|
||||
is allowed.
|
||||
|
||||
## Procedural Information
|
||||
|
||||
### Security Considerations
|
||||
|
||||
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.
|
||||
|
||||
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.
|
Loading…
Reference in New Issue