_   _ _     _                      _            
 | |_(_) | __| | ___   ___ ___ _ __ | |_ ___ _ __ 
 | __| | |/ _` |/ _ \ / __/ _ \ '_ \| __/ _ \ '__|
 | |_| | | (_| |  __/| (_|  __/ | | | ||  __/ |   
  \__|_|_|\__,_|\___(_)___\___|_| |_|\__\___|_|   
                                                   
                

Philosophy

The Tilde Center (~center) project consists of three core elements:

The current goal for this project is to create a system that will allow maintainers to easily setup and deploy their own ~center servers to join its network. To help explain the focus of the project, the following will outline the meaning behind the three core elements.

Decentralized

The decentralized factor means that user’s experience from being on one server should not differ from another. Any user that has joined the ~center network will be able to log into all ~center servers, access any share data they set, and have access to the services they were using on another. In this way, if a server maintainer stop hosting their tilde server there will be nothing lost to the ~center users, they would just login from a different node in the network.

Accounts

As mentioned above, having an account on one ~center server means having an account on all ~center servers. This will be accomplished using an LDAP database, which can also be leveraged as a single sign on (SSO) solution for any services made for the platform.

Storage

To help mitigate against any barriers of entry to being a ~center server, user data will also be distributed but through a size limited shared directory for each user (e.g. in each user’s $HOME directory, they will have a directory that can hold X megabytes of data). These shared directories will sync changes to the other servers (probably through rsync or something like it) so users can carry dotfiles and other kind of files / configurations to the other ~center servers. For larger files, the mechanism for doing so will be decided later on.

Services

There will also be a shared SQLite database(s) that will be synced across the ~center servers for services to utilize, along with the services / programs / scripts themselves being synced across as well.

Federation

To keep the ~center experience across the servers continuous they would need to communicate with one another. This will be accomplished through TCP socket servers and clients that adhere to the same specification (the details of which will be determined later) to dispatch intentions and requests from other servers. The dispatcher can then hand-off the intentions and/or requests to the appropriate services / programs / scripts to perform the needed actions (e.g. calling user creation scripts, heartbeats, informing a new server joined the ~center network, etc).

Accounts

While creating an account on ~center gives you an account on all the servers in its network, each ~center is run by its own server admin. For this reason, a server admin for a ~center instance can choose to ban a user from their node, the reason for which can then be sent to the other admins of the ~center network to decide if they want to take the same action (e.g. to prevent things like spam bots getting out of control).

Synchronization

For components like the LDAP user database, to allow for server admins to ban a user from their instance without automatically banning them from all instances, the LDAP database cannot just be synced across all nodes. Instead, actions performed against the LDAP database can be dispatched to the other servers to be applied to their own LDAP databases.

To ensure events like password changes do not expose sensitive data to security threats like man-in-the-middle attacks, these communications through the dispatcher will be encrypted and signed so that the receiving server can both verify the authenticity of the message and keep it’s contents safe from attackers.

Governance

No system is perfect, and with anyone being able to join the ~center network it allows for “bad agents” to join the network that could try to send malicious intents / requests to the dispatchers of other servers or act against the wishes of the community. For this reason, a governance system will be put in place so that the community and/or server administrators can vote to block / ignore messages from nodes run by bad agents as a means to police the ~center network.

Home-Brewed Open Source Projects

Richard Feynman said:

“what I cannot create, I do not understand”

and this philosophy is at the core of the ~center project. The intention behind the ~center project is not to try and create a perfect machine that you can bravely run in a production environment, but rather to embrace the joy of creation and make something amazing together. It may become a monstrosity of buggy scripts all haphazardly cobbled together, but it will be our monster. The ~center project belongs to its community, so it is so important that it is also created by its community. In this way, a piece of it will belong to each of us as we can know it is here because of something we did. While decentralization and federation are goals the community can strive for, the HBOSP factor of the project is what ultimately brings the community together towards a common goal, making it ourselves.

Also, it’s more fun to try and reinvent the wheel for its own sake.

~aewens