FEDAnet project

Ladies and gentlemen,

I'm pleased to announce the source tarball for the version 0.0.50; the tarball is available in the downloads section.

Long things short, this time the fedaserv daemon instances just became capable of exchanging node keys, checking them and storing the results.

The problem I had to solve is that taking a yespower hash is a resource-consuming thing; low-end VPS machines are barely capable to perform it and it is too much stress for them, and older 32-bit computers can not do it at all. Besides that, even for a more or less powerful hardware this hash taking is obviously risky in respect of DoS attacks. So, first, it should be possible to delegate the tasks involving hash computation to a physical computer other than the one running the node, and, second, in case we're asked by a stranger from the Internet to verify a previously-unknown node's hash, we should let the stranger demonstrate some proof-of-work... well, technically in the present version it means we let the stranger take four hashes of things we supply, and only then we agree to take one hash of a thing the stranger supplies.

Three new peer types are implemented; from the doc/peer_types.txt:

******
TYPE: trustncc

Trusted node certificate center.

Basically, we trust this peer (its node+point's key) in the sense of
accepting foreign nodes' keys _without_ _computing_ _their_ _hashes_;
furthermore, in case an unknown node tries to connect us, we can ask all
(or some of) known&active trustncc peers whether they know the node, and
they might send us the node's master cert (signed by them) so we can accept
that node without computing the hash.

For a point, it may be useful (although not necessary) to declare the
point's own node as trustncc, specially if the point has good conectivity
conditions and plans to establish direct connections with others.  Besides,
it may be useful for a node to declare some friendly peers as trustncc,
just to save time and the CPU power.  It is not strictly necessary to get
their permission to do so; presently all fedanet instances respond to the
respective type of requests properly.  However, it might be a good idea to
ask if they really don't mind.



******
TYPE: certhub

This peer (which possibly belongs to another node, although this is not
necessary) works as a ``hub'' for distributing node certs.  This means it
generally accepts introductions from new nodes, checks their hashes, saves
checked keys in its local database and responds on requests for the stored
certs.  Technically, specifying this flag means our daemon will suggest
newcomers with unknown node IDs to introduce themselves to this peer;
hence, peers of this type must be specified as ip:port.  You might want to
always use the ``trustncc'' flag for peers of this type.

At that peer, the fedaserv daemon must be configured accordinly, which
means it must have the lines 'allow_nodehash yes' and 'intro_accept yes' in
its configuration file, AND the properly generated challenge-response table
file.



******
TYPE: introducer

This peer, typically a more powerful machine working within the same node
(e.g., a home machine of the node master), agrees to act as an introducer,
which means that we can ask it to introduce our node to the given instance
of fedaserv, so that we don't have to do this on our own.  Besides, this
peer checks foreign node certs forwarded by its siblings (that is, points
of the same node), primarily the node itself.  This is intended primarily
for nodes that run on low-end machines, so that they can delegate
introducing work to something powerful.

This peer type may (and should, although is not obliged to) be specified by
the node.point pair, not by the ip:port, so that the introcuder machine may
run behind a NAT of any type, and once it establishes the cryptographic
association with the node, the node becomes able to use its service.

You might want to use the ``trustncc'' flag for peers of this type.  If
this flag is not specified, an introducer peer is still able to introduce
its node to others, but its cert-checking job is fruitless.

Please note the introducer peer MUST run as a point of the same node,
otherwise it won't accept our requests.

The intended use for them is something like the following. Nodes are still run mostly on VPS machines. To change this, another major piece of the functionality must be implemented, namely network-wide broadcast messages; those messages will carry announces of the nodes sitting on temporary ports; well, we don't have the thing yet. So let's stick to VPS machines as of now, assuming they are not capable of computing the hashes. Every nodemaster perhaps has a more or less powerful computer at home, for which it's not a problem to take a hash or two, but the problem is that such computers are typically not accessible from the Internet.

So, to run your own introducer/certhub, you just configure a dedicated fedaserv instance on such a machine (it is strongly recommended to use a dedicated pseudo-user for this purpose); let this instance be visible for the Internet using the fedaproxy feature on your node instance; and configure it to be the introducer peer for your node, basing on the node.point pair. Be sure to enable the functions in your serv.conf; see the options allow_nodehash, intro_issue and intro_accept, a self-documented example of the file is doc/serv.conf.

To give you a real-world example, I run my main node at 45.13.38.102:5080, that's the c508097bd6c347a4a317.254 instance; the same daemon provides a proxy port for one of the points, namely c508097bd6c347a4a317.206 (206 is 0xCE in hexadecimal), and the proxy port number is 52871 (0xCE87). The point itself runs at my home machine behind NATs. Here's the respective point configuration on the node instance:

peer c508_ce
type proxyuser trustncc introducer
node_id c508097bd6c347a4a317
point 206
proxyport 52871

The point itself has the following in its serv.conf:

peer brizo
type mynode proxy
ip 45.13.38.102
port 5080

#     [ . . . ]

allow_nodehash yes
intro_issue yes
intro_accept yes

Everyone's welcome (well, let's say "as of now") to use it as their certhub/trustncc; to do so, add the following to your serv.conf:

peer c508_ce
type persist trustncc certhub
ip 45.13.38.102
port 52871
node_id c508097bd6c347a4a317
point 206

Your daemon will then, first, ask this instance about unknown nodes whether the instance knows them, and will trust node certs signed by this point, without actually computing the hashes; second, your daemon will recommend strangers from the Internet to introduce their nodes to this instance.

However, I hope this certhub will not remain alone for long; please run your own certhubs and share their ip:port locations and node.point IDs.

The daemon's control console (that fedactl thing) now allows to order your daemon to introduce your node to a hub at the given ip:port. See the intro command.

Unfortunately, we are still unable to grow the network without human intervention; broadcast message distribution is needed for that. However, we don't have to manually exchange node cert files any longer, and any new network member can connect to existing nodes without asking their masters to do anything; once ready, such a new member can announce the new node (e.g. here on the site, in comments), so we add his/her node as a peer.

Doing this way, we can build a kind of a backbone, which we will need to distribute the broadcast messages (including node location announces). I think 10-12 nodes connected each with all others, running 5-6 publicly available certhubs, will be sufficient for the network to start functioning once I manage to implement node announce distribution.

Thanks to everyone who follows the project and specially to those who supported it with donations!