FEDAnet project

The goal of the FEDAnet project is to build an (overlay) computer network to let people (which means individuals) have mutually agreed communications with no intervention from any uninvited (and unwanted) third party. This means there must be no central authority of any kind, and all communications must be encrypted at the infrastructure level.

FEDAnet is supposed to use IPv6 internally, connecting its nodes by encrypted tunnels over the IPv4 Internet; 80 bit long node ID, derived from the node's public key, is to be a part of IPv6 address prefix used by the node, thus making any centralized IP registry unneeded, with virtually impossible address collision.

Every network needs its own servers and infrastructure, but only a small fraction of users are capable of running the infrastructure. From the other hand, entities that serve a lot of people become what is known a single point of failure; furthermore, they tend to use the power (gained along with their userbase) to impose their own rules. Hence, in FEDAnet the number of users (points) per node is technically limited. Strictly speaking, the limit is 253 individuals using a single node (the point ID is an unsigned 8-bit number, with 3 values reserved for special purposes). Node masters are expected to provide the access only to their friends and relatives, or at least to people they know in person (internet "friends" are not considered as being personally known). No “open” nodes must appear, and no paid access is expected as well; a node providing point access to arbitrary people should expect to get banned by other nodes. So, a person willing to connect to FEDAnet will have three choices:

• run his/her own node;
• find a friend, a relative or a colleague who already runs a node and ask for a point access to the node;
• find a computer networking hobbyist among friends and relatives, and convince him/her to run a node.

Running a node will require certain level of knowledge and some effort, yet it is important to make it possible for any individual who's dedicated enough. To achieve this, all software must be written in plain C (some C++ is acceptable for programs that don't listen to network ports), must have no external dependencies, neither at compile time nor in runtime, and must link statically, so their “installation” turns to be simple copying of an executable binary to an appropriate location.

In order to run a node you will need:

• A Linux machine; node software will only run on Linux (and maybe some *BSD systems as well, but definitely not on Windows nor on Mac). Please be prepared to keep the machine running and being online 24x7, it is very important.
• Ability to get a UDP port accessible from Internet, and hold the port for long time, like several days. Hardly you have a routable IP address at home nowadays, but if your I.S.P. uses a so-called full-cone NAT, this will be sufficient. Restricted-cone NAT should be sufficient for a single-person node, but not for a node which serves other people. Symmetric NAT, unfortunately, won't suffice even for that. In case your home connectivity has insufficient capabilities, you'll need to find a Linux machine with a routable IP address (e.g., like a VPS or a VDS) where you'll be allowed to run a program called fedaproxy: it will take a UDP port and forward packets to/from your home machine where the node actually runs. The program which tests your connectivity conditions, named natcheck, is available in the published source code archives since the version 0.0.03, but you're strongly adviced to use the latest version.

Besides that, you'll need to generate your very own node key. This may take several weeks on a reasonably fast computer.

Depending on a hash of the public key, a master node key is assigned a rank; the higher the rank is, the more (average) time it takes to generate the key. Each node makes its own decision what minimal rank must other nodes have in order to be recognized. This makes a node to be of some value for its owner.

For internal addressing, IPv6 address block FEDA::0/16 is going to be used (hence the name of the network). This block is a subnet of FEC0::0/10, which was defined by rfc3513 as “site-local addresses”, but was “deprecated” in this role a bit later by rfc3879. As the time of this writing (last checked June 2025), IANA whois server says the following about the block:

inet6num:     fec0:0:0:0:0:0:0:0/10
descr:        Reserved by IETF

remarks:      http://tools.ietf.org/html/rfc3879

source:       IANA

It is highly unlikely the block will get reused for any other "special" purpose; anyway, FEDAnet's internals are not Internet so perhaps we'll be able to use these addresses even then. In the worst possible case they may decide to give the addresses a role special enough that routers will threat them in some special manner, like they do right now for link-local addresses. If such a horrible commitee-made decision will ever get into effect, we'll perhaps have to switch, e.g., to FCDA::0/16, and our usage will even be (partially) compliant with rfc4193, at least making no conflicts. Never mind, let's just hope they will not come up with another brilliant idea which effectively steal huge amounts of time from thousands of innocent developers (the very usual thing for commitees, but let's just hope for the better).

A node ID consists of 10 bytes (actually, these are the last 10 bytes of the node's public key, so they look pretty random). In FEDAnet, the node ID is used as a part of every IP address. For example, if your node has the ID 49feb618794a8e1e4439, then your node will use the address block FEDA:49FE:B618:794A:8E1E:4439::0/96. This leaves you 32 bits for the address' node-local part, but don't get too impatient. There are also points who use the node, and the point number is a 8-bit unsigned. So, the next byte in the address will be the point number; e.g., if you assign someone with the point number 139 (hexadecimal 8B), then your poor user will have to use addresses from FEDA:49FE:B618:794A:8E1E:4439:8B00:0000/104. Don't worry, a /104 subnet still contains 2²⁴ = 16777216 IPv6 addresses. Looks more than enough for an individual, and your point definitely must be an individual.

You, being the node master, will need a point number for yourself, too; usually this will be the number 1, but you, at your option, can pick any other point number, they are all yours. Only keep in mind there are 3 reserved values: 0x00, 0xfe and 0xff. These must not be assigned to points. The point number 0 (ZeroPoint) will be used to refer to the node itself; for instance, ZeroPoint's key may be used to sign other keys and otherwise act on behalf of the node, which makes it possible to use the master key on rare occasions only. Within the IPv6 addresses, ZeroPoint will perhaps be used for the node's own infrastructure.

A lot of technical decisions are still to be made for FEDAnet; however, some decisions are already made, so here they are:

• The Monocypher library, version 4.0.2, will be used for all the cryptography (except for the proof-of-work hash). Later versions may only be used in case they maintain 100% backward compatibility. The set of cryptographic algorithms used in FEDAnet is not subject to change even in case someone manages to break them; if FEDAnet will become insecure one day because of broken cryptography, it will mean the whole project has to be abandoned. Yes, this is far better than to waste time and effort trying to make the cryptography framework “replaceable” and/or “pluggable”. We've got enough of SSL/TLS, no?
• To compute the hash of a node's master public key, the yespower hash implementation, version 1.0.1, will be used, with the hash size set to 32, the parameter r set to 32 and the parameter N set to 65536. This means a single hash computation will take 256 MB of RAM, used actively enough that swapping of that memory is not an option. The personality string is set to NULL.
• The rank of the node key is the number of first bits of the hash, that match the pattern 0xFEDAFEDAFE....
• Cryptography certificates used by FEDAnet will be of exactly three types:
  • A node's master “certificate” contains the node ID, the public key, the yespower hash of the public key and the signature of the hash, made with the master key of the node, so it can be checked using the public key. Actually, it could contain only the public key and the signature because both the node ID and the hash are naturally derived from it. Strictly speaking, this is not a certificate at all, as it doesn't contain anything like dates, because there's nothing to “reissue” here; the node itself only exists as long as its master key remains private and its public key is recognized around the network.
  • A point's key certificate signed by the node's master key contains the node ID, the node public key, the yespower hash of the key, the signature for it, the point ID (an integer from 0 to 254), the issuing date (in minutes (sic!) since EPOCH), the signed_by value set to -1, and the master's digital signature for the feda_cert_info data structure (see below).
  • A point's key certificate signed by the PointZero key contains the node ID, the node public key, the yespower hash of the key, the signature for it, the point ID (an integer from 1 to 254, as the PointZero can't sign certs for itself), the issuing date (in minutes since EPOCH), the feda_cert_info data for the PointZero, the master's signature for it, the signed_by value set to 0, and the PointZero's digital signature for the feda_cert_info data structure of the point being certified.
  Those who watch the project from its early stages might notice that initially there was no signature for the master hash. It was added for a reason. Without it, any node master public key presented by someone to someone else on the network (and previously unknown), whould have to be trusted, provided that its yespower hash has enough bits matching the pattern. This makes it possible for some evil people to try generating a random 32-bit sequence which matches someone else's node ID, and its hash contains enough matching bits. For such a "public key", there would be no matching private key: the task of generating a pair of a valid public/private keys that match an existing node ID would effectively cost an estimation of 2⁸⁰ key pairs (in average) generated and checked, which is unsolvable already, but adding the requirement of the yespower hash matching the power, we may rest assured nothing like this will ever be possible, having an entire computational power of the Galaxy. If, however, the attacker only wants to generate something that looks like a valid master public key for a particular node, it takes no more time than generating a node key of a desired rank. Certainly, one can't really run a node having no private key for it. Even creating a ZeroPoint certificate is impossible without the key. But, well, in some circumstances trusting such a fake, even temporarily, may cause some difficulties for the real owner of the node. So let's just make and check one more signature, okay? With monocypher, this doesn't take any long.
• The feda_cert_info structure is as follows (u_chr is a typedef for unsigned char):

  struct feda_cert_info { /* all numbers are to be stored big-endian */
      u_chr feda[4];              /* magic number 0xFEDACE87 */
      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 PointZero's key   */
      u_chr timestamp[4];         /* minutes since epoch, a.k.a. unixtime/60 */
      u_chr key[public_key_size]; /* the key being certified */
  };
  

• Certificate issuing date is stored as a 32-bit integer containing minutes since EPOCH, which means the traditional unixtime divided by 60 (dropping the remainder). This allows not to waste extra 4 bytes making the date field 64-bit.
• A certificate is to be considered valid as long as its master public key hash has the appropriate prefix (rank no less than the minimum set for the checking node), the digital signature(s) are valid and there's no certificate for the same node+point with a later issuing date. There's no such thing as a “certificate lifetime” a.k.a. “validity period”; a certificate can be rewoked by issuing a new certificate for the same point, but remains valid for any checking party who haven't seen the newer certificate yet.

FEDAnet participants are supposed to communicate to each other using the FEDAprotocol, which is build atop of UDP. FEDAprotocol speakers include nodes, points (meaning an individual using the network), services and temporary clients. All speakers but temporary clients are expected to be able to establish long-lasting cryptographic associations and talk to each other in a secure manner. Temporary clients (such as people testing their current connectivity conditions) are not supposed to remain on the network for more than few seconds.

Every FEDAprotocol speaker wishing to do anything beyond several seconds, e.g., to connect to someone through FEDAnet, provide some services etc., must have its distinct (unique) point ID, which means the node ID, the point number (0 to 253, with 0 denoting the node itself) and the respective cryptographic credentials issued by the node master.

Some speakers (such as boostrap servers), due to their nature, should run on globally-routable IP addresses, so that their ip:port addresses never change. Other services, including ordinary nodes, may from time to time change their addresses visible to the IPv4 Internet, only not very often; being run from a new IPv4 location, they would announce their presence to the network, and the announce will be quickly distributed to all active nodes on the network. This allows to run a node at home behind a NAT, provided that it is a Full Cone NAT (see the NAT type discussion here).

For those who don't have the appropriate conectivity conditions at home, there will be FEDAprotocol speakers of a special type named FEDAproxy servers. Such a server runs on a VPS or other type of a Linux machine having a routable IP address, and, occupying exactly two UDP ports (one to communicate with its master, and the other to talk to the rest of the Internet), forwards all its master's traffic where it is told to, while forwarding all responses (and, generally, all datagrams) received from the world, back to the master. For all the world, this looks exactly as if the node was running in the place where the proxy runs, despite in reality the node is still being run on your home machine (which is highly recommended, as the machine actually running the node contains a lot of information you wouldn't like to get grabbed without your notice, and this is a highly likely event for a rented server of any kind and, generally, for any computer you don't fully control physical access to).

Every change of the ip:port pair of a node is supposed to give the node some penalty points, which dissolve on their own as the time passes; penalty above certain threshold would cause other nodes to refuse announces from that node until its penalty value lowers, much like BGP dampening.

A point is supposed to be able to contact any node to discover if his/her own node is currently online and at which IPv4 location it can be found. Every FEDAprotocol speaker is expected to remember some locations to contact while they are online; if during the period a particular speaker was offline, all ip:port pairs it remembers become unreachable, it should as the very last resort contact some bootstrap servers to gain more (active) locations to enter the network.

In future versions of the protocol, there will be some mechanics that makes it possible to avoid direct communication between nodes located in the same country; such nodes should relay all traffic to each other via a third node, physically located in a different country. Details are yet to be determined.