Updated license file information, added initial concepts
This commit is contained in:
parent
797239f6be
commit
ad0940eeb9
2
LICENSE
2
LICENSE
|
@ -1,4 +1,4 @@
|
||||||
Copyright (c) <year> <owner> . All rights reserved.
|
Copyright (c) 2018-2019 Austin Ewens. All rights reserved.
|
||||||
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
|
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
|
||||||
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
|
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
|
||||||
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
|
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
|
||||||
|
|
112
README.md
112
README.md
|
@ -1,3 +1,113 @@
|
||||||
# concepts
|
# concepts
|
||||||
|
|
||||||
General concepts for the tilde.center architecture
|
The tilde.center (**~center**) project consists of three core elements:
|
||||||
|
|
||||||
|
* Decentralization
|
||||||
|
* Federation
|
||||||
|
* Home-brewed open source projects (HBOSP)
|
||||||
|
|
||||||
|
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](https://tildegit.org/center/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.
|
||||||
|
|
||||||
|
## HBOSP
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
----
|
||||||
|
|
||||||
|
As with all components of the ~center project, if you have any changes you
|
||||||
|
would like to contribute to the above, just open an
|
||||||
|
[issue](https://tildegit.org/center/concepts/issues/new) or submit a
|
||||||
|
[pull request](https://tildegit.org/center/concepts/pulls).
|
Loading…
Reference in New Issue