The goal of the project is to create a decentralized overlay computer p2p network over IPv4/UDP with internal IPv6 addressing aimed at maximizing the freedom of information transfer between individuals. Simply put: a network that will allow people (individuals, specific human beings) to have mutually agreed-upon communication without the interference of an uninvited, unwanted third party. The maximization of individuals' informational freedom directly depends on minimizing informational violence against individuals, which is expressed in the following three rules: NO ONE AND NOTHING, without exception, HAS access to the information of its owner, without the direct facilitation of its owner to transfer the information (NO policies that no one ever reads, NO automatic updates, NO Client-Side Scripting, NO closed-source software; NO overcomplicated bloated programs, NO espionage whatsoever); NO ONE AND NOTHING CAN prohibit mutually voluntary transfer of information between individuals (NO CENSORSHIP IN ANY FORM, NO restriction on the dissemination of digital information due to "copyright"; the right to authorship and the privacy of information from its owner are different things that MUST NEVER be confused (the owner of the information decides for themselves whom to entrust the information to; for data to spread, it must first end up in someone else's hands; if this was facilitated by the owner of the information, it only means that the one they trusted did not need to be trusted with it)); NO ONE AND NOTHING IS allowed to initiate the transfer of information over any personal communication channel of an individual (NO passive information transfer IN ANY FORM; any unsolicited, unwanted or inappropriate information in any form, anywhere, any advertising (as a daily phenomenon it must die), and everything related to it - that is all spam; NO SPAM) without their consent, and if this information is of an advertising, commercial or agitation nature, the consent must at the very least be expressed through a personally written and signed agreement that they consent to the act of informational violence and are aware that this is informational violence.
Each node has one owner, an individual (node_master, henceforth), a unique identifier node_id, 256 points with point_id=0,...,255, and its own personal reputation (rank, henceforth). One point must belong to one individual, a participant of the FDABnet network, who uses the resources of FDABnet (point_slave, henceforth) or who may provide certain services ( point_master, henceforth). During the node generation process (masterkey_mining, henceforth), a private (master_key, henceforth) and public ( master_pubkey, henceforth) key are produced, as well as a hash for master_pubkey (mpubk_hash, henceforth).
master_key belongs to the node, which makes node_master the node_master. To put it more precisely, an individual who does not own, meaning does not have under their control their own master_key (meaning someone else has it or it doesn't exist at all) does not own the node, and a node without its node_master is worth nothing. Not to mention that each node_master decides for themselves, from a node of what minimum rank (minrank, henceforth), they will allow a connection. This means that it is not enough to have a reliable and economical node_master. The node_master must also take care of the worthiness of their node, its rank.
It should be noted that without a point that is associated with a decent node, meaning with a decent rank, you have no business in FDABnet. Well, absolutely none. You'd sooner crack. Except that a temporary client might be allowed to check their connection conditions (see below about sibling peers). True, with certain restrictions of a few seconds of using FDABnet network resources. But that's it. Don't even hope for anything more.
To join the FDABnet network, you can:
To be a node_master, you need to:
Good news for those who still dare to become a node_master: every point is at your disposal; you are even allowed to share one point with your close acquaintances whom you know well and recognize in person. But, unfortunately for you, we have some bad news for you. Let's start with the fact that you cannot use 3 points for your own needs. Don't misunderstand. They are still yours, at your disposal, and you are responsible for them. The thing is that these 3 points are reserved and used for the infrastructure purposes of FDABnet (see below about master_node, zero_point, and nodeable). So... Under your jurisdiction, there can be 253 individuals, each with one point. You have a lot of responsibility for your point_slaves and point_masters, as well as three points for deploying your node. If it turns out that your node is "open" or has paid access, then you will simply be banned by other FDABnet participants like you, but who value their personal nodes and their point_masters and point_slaves.
By the way, point_id is used, besides the address, also in certificates. A number that is a multiple of a byte is a nice number. So you shouldn't be upset that each node has only 253 clean points, BECAUSE IT HAS TO BE THAT WAY. Do you think that's too few? Then list all your offline acquaintances whom you know well, and name that number. What? So few? We could have made even fewer points then. What? Not necessary? If you insist. In FDABnet, concrete people are important, not ideas that a bunch of concrete people is not just a bunch of concrete people, but something more than just a bunch of concrete people.
Well, okay, if it's an enraged crowd of people demanding justice, then well... Demanding to rob or damage someone's private property or to maim or hang someone (an exhaustive definition of justice), then... Then yes, it is indeed more than just a bunch of concrete people. It's a bunch of marginals. If they are an organized organization - they are bandits. And we do not want to have anything to do with either one or the other. Hopefully, we understand each other. If not, leave this place.
All software for and over FDABnet must be in Plain C or in C++ (in the second case, only for programs that do not listen to ports). The answer to what can be considered Plain C and C++, in other words, what is adequate and what is inadequate, we will tactfully remain silent about for now, but in the future, this must definitely be given time and place.
The infrastructure (point_master and reserved points) is exclusively for Linux and possibly for some BSD*. The purely user base of participants, our esteemed point_slaves, will never receive support for MacOS, iPhone, and iPadOS. The only thing that needs to be added is that Windows and Android are very problematic platforms, and it is quite likely that they will also never receive support.
The address of each node looks like FDAB:(node_id)::/96, where node_id is the last
10 bytes of master_pubkey. The address of each point looks like
FDAB:(node_id):(point_id)::/104.
Points 0x00, 0xFE, 0xFF are reserved. point 0xFF for master_node, 0xFE for nodeable, 0x00 for zero_point. master_node must be located on a machine without Internet access and delegate all work to zero_point; needed for certificates to show that something is directly signed by master_key. zero_point must be located on the node_master's home machine; it signs keys. nodeable is a daemon that may likely end up on a server like VPS or VDS, as it requires being accessible from a public IPv4 address and having a UDP port. It cannot be responsible for things that are the responsibility of node_master and zero_point (they, in contrast, are under physical control, which is important), and it is (by default) intended to be deployed on low-end machines. Its computations are (by default) delegated to be done by the node_master's home machine (see below about introducer), and traffic processing (by default) also does not belong to it (see below about nodenets). In short, it is accessible.
master_key and master_pubkey are calculated using the eddsa algorithm from the monocypher library, and mpubk_hash is calculated using the yespower algorithm from the library of the same name.
Rank is measured by the length of the mpubk_hash prefix that matches the
pattern FDABFDABFDABFDABFDABFDABFDABFDABFDABFDABFDABFDABFDABFDABFDABFDAB.
The calculation of mpubk_hash actively uses 256MiB of RAM and CPU without the possibility of using swap, GPU (due to such an algorithm), ASIC (as it is unprofitable); which completely makes the situation very unpleasant where many unknown peers appear at once, and you still have to get acquainted with this bunch. Because to compare the rank of an unknown peer with your own minrank, you first need to verify the signature of mpubk_hash, calculate its rank, and then independently calculate its mpubk_hash from its master_pubkey to ensure they are identical. It is very predictable that such an approach threatens a DoS for the node infrastructure. Therefore, the following mechanism is provided: it is possible to make the acquaintance process happen with the overhead borne by the party interested in it. Instead of directly calculating its mpubk_hash upon the first request for acquaintance, you first need to verify it. It is possible to prepare a table in advance with pairs of master_pubkey:mpubk_hash ( chlgresps_tbl, henceforth) and let the peer first calculate some mpubk_hash from some random master_pubkey. chlgresps_tbl could be generated, for example, during masterkey_mining (why not use such an opportunity?) or, if your node is already deployed and you do not plan to move to a node with a higher rank, generate only them. Then it's enough to verify their response, which, in fact, might allow you to protect yourself from a plague of unknown peers with low rank.
To generate the same node_id, the cost is 2^80 (in other words, 1 << sizeof(node_id) * 8) generated and verified key pairs, which is already an unsolvable problem, but if you also take into account the computational power required for mpubk_hash, even the potential computing power of the Galaxy would not be enough for this. We already said that master_node must always be located on a machine without the ability to connect to the Internet. If this does happen, you need to proactively reformat the disk and reinstall the OS. Too much depends on master_key to allow its compromise. Only one person should have access to master_key, and that is, surprisingly, the node_master. It is highly not recommended to entrust it to anyone else, especially if you cannot vouch for that person with your own head. In case someone else gains access to your master_key, please shut down your node by sending a "node shutdown" broadcast message (see below about messages).
We do not use so-called global certificate authorities from (pseudo-)trusted entities (entities?!) of highly competent organizations (for pumping money out of people, of course). Global CAs have nothing to do with us or with the information security of FDABnet. Certificates must be intended only for participants of a closed group of people, and this is non-negotiable. Also, all cryptographic algorithms must be fixed, no "negotiate" or "generalized" algorithms. There will never be room in the FDABnet network for SSL/TLS. Rank is calculated from the prefix of a specific pattern from a certain hash, which in turn is calculated by a certain specific algorithm. This decision, made on a whim, sounds more solid than all the "standard" solutions taken together that are used by the web, email, video, etc. The goal is encryption at the level of the protocol's innards. If the used dependencies start to stink, we will simply cut them off and rewrite them.
fdabcert_info structure (u_chr is a typedef for unsigned char):
struct fdabcert_info { /* all numbers are to be stored big-endian */
u_chr fdab[4]; /* magic number 0xFDABCE87 */
u_chr node_id[node_id_size];
u_chr point_id;
u_chr signer_id; /* 0xFF if signed by the node's master_key,
0x00 if signed by the zero_point_key */
u_chr timestamp[4]; /* minutes since EPOCH, a.k.a. unixtime/60 */
u_chr key[public_key_size]; /* the key being certified */
};
Regarding the decision on minutes. With 4 bytes, this will suffice until the beginning of the 7th millennium. If these were seconds, 4 bytes would also suffice: 2^32 would overflow on February 7, 2106. There are reasons to believe that civilization by that time will no longer exist. Joke or not, but in minutes, in any case, it's enough :).
Three types of certificates:
Let's start with the fact that NAT is an abbreviation for "Network Address Translation", not for "Super Mega Firewall". Indeed, it's very easy to confuse. But what to do about the fact that individuals cannot communicate with other individuals like themselves without intermediaries whose only desire is to violate one of the rules of informational freedom? If the world were truly wonderful, it wouldn't be so expensive to maintain your own special powerful server. Or, at least, everyone would have a real address. But no. Due to Restricted and Symmetric cone NAT, it is quite problematic to have two-way communication with someone. Services with low traffic like email, with the help of external servers, have a cheap solution, but for services with high traffic, like video, it is very expensive. And here NAT turns out to be very important.
We don't even try to do anything regarding the TCP protocol or any other connection-oriented transport means. We use the UDP protocol. Under certain conditions, it is possible to establish two-way communication between two computers located behind NAT.
We do not use STUN and TURN because, firstly, any external dependencies (precisely that, dependencies, even if the majority would call it a standard protocol and say "don't reinvent the wheel"), always increase complexity (the opposite is possible only in very specific situations and provided that the library contains no more than half a dozen functions and has a simple, understandable interface), and secondly, STUN and TURN are centralized protocols created clearly for non-individuals.
Some interlocutors, i.e., points 1-254 of a node (with 254 denoting the node itself), must run, for example, as bootstrap servers, on a globally routable ip:port that never changes. Other services, like ordinary nodes, may change their address visible to the IPv4 Internet from time to time, but not very often. When running on a different address, it will have to send an announcement message about its presence in the network, and it will spread to all active nodes in the network. Each change of ip:addr will increase the number of penalty scores, which will themselves decrease over time. Exceeding a certain threshold of penalty scores will cause other nodes to reject such announcements until the penalty scores decrease (very similar to BGP dampening).
This very mechanism of announcement messages will allow a node to run at home behind NAT in the case of Full Cone NAT. For those who do not have suitable connection conditions at home, there will be interlocutors of type proxy, which must have a routable address and two UDP ports (for the node and for the Internet) and forward all traffic from the node_master's home machine to the Internet and vice versa.
A point can contact any node to find out if that point's node is online and what its IPv4 location is. Each FDABprotocol interlocutor remembers some contacts while online. If, after a certain period offline, an interlocutor finds that all its contacts are unreachable via the ip:port it knows, it turns, as a last resort, to bootstrap servers to get more active contacts to enter the FDABnet.
FDABnet requires a mechanism to avoid communication between nodes located in the same country. In that case, all traffic between such nodes must be relayed through a node physically located in another country. Details are not yet defined.
(TO WHOM)