FEDAnet project

First, one thing unrelated to your question.

> type nodenets trustncc persist certhub introducer proxyuser

This node entry should not have the certhub token. This token means the daemon will offer this peer to remotes who tries to contact you but you don't know their node creds. They won't be able to connect the peer because the peer is behind the NAT.

To fix this, add another peer entry, like this:

peer home_visible
type certhub
ip the IP address of your node goes here
port 22222

Now about your situation:

> my node already tried to establish association with vetal peer and failed with `alas, we have nobody to ask`. Then adding this peer to state `gave_up`

This is definitely a problem, and I'll think how to fix this. Meanwhile, what you can do now: add vetal as the peer for your home fedaserv instance. The instance (your peer number 1) will first establish its connection with the proxy, then will contact vetal, and will request and check its cert. Once you have it, it will reside in the file named ~/.fedanet/keys/f22/6cb/f226cb6a4412d7faa2c1/node; take this file and copy it to your node, with exactly the same local path (relative to the home dir of the daemon). And restart the node.

I realize this is not too convenient way to go, and I hope this recommendation won't remain in effect for long, but right now this allows to go on.

Thank you, I listed your node at the backbone info page. Also I added it to my nodes' configs, c50809 established the association right off, but f22ff5 tried and failed. I guess your node doesn't use the known public certhubs as trustncc type peers so it can't get my node's creds, and you don't have any points capable of taking hashes so that your node can't let incoming strangers to introduce themselves.

No there is no such black list. If you think you're able to distribute a black list, what prevents you from distributing the newer point cert? There is no central authority in the network, so there effectively can not be any kind of list of revoked certs.

This error is not related to the compiler's version nor to the host system. It is make who fails.

Makefiles are written for GNU make, it is named gmake in BSD-like systems. As far as I see, it is impossible to write makefiles so that they are suitable both for GNU make and POSIX make, which is the default make in BSDs. Actually, I don't have the knowledge to write POSIX-make makefiles even from scratch. It may be a good idea to write them, so that BSD users don't have to install gmake, but, well, right now this can't be a top priority.

> Is "playing tunnels" currently the only way servers work?

I'm a bit confused with the question. What the current version of fedaserv can do is not limited by these tunnels, they can at least serve NAT checking requests (here plz). But, well, yes, right now no more useful things are implemented. Fedaserv instances are capable of serving as proxy servers to other instances, and they are capable of using service of this kind, but perhaps that's all.

> Have I misread it when I think these tunnels need a constant public IP address and domain name?

Domain names are not used by fedaserv in any way, so you don't need a domain name. As of the public IP address, well, yes, that's now the case and it will remain so until we have broadcast message exchange/distribution. Once the message distribution is implemented, nodes will be able to tell all the network where they are, so changing the IP address of a single node will no longer be a problem.

Also please note a single VPS or other machine with a permanent IP address can serve as many nodes as you wish, even with a single instance of fedaserv, thanks to that fedaproxy functionality, which is already there. There's also no problem to run several fedaservs on a single machine, they only need to have different UDP ports. User access to such a machine is sufficient to run a node there, that is, root access is not necessary.

> At home my address is constant typically for months, but it might change on every provider-plastic-router reboot. Those events typically come in clusters, and the long and stable phases between them are the rule. Will that be good enough for using FEDAnet in its final "mode"?

Absolutely. This doesn't work right now only because we don't (yet) have the message distribiution facility. Definitely it will be implemented one day.

When? Well, I don't know. Right now I'm working on the node cert exchange automation, so that new node masters will be able to join the network without human intervention of the people already there. This, in turn, will let us build up a kind of network backbone, which will later pass those messages. Once I'm done with the node cert exhange, I'm going to focus on the message passing.

> I'll probably never get a VPS again.

May be you can get a non-privileged (user) access to someone else's VPS? It is sufficient for FEDAnet even in its present state.

> and then I tried to compress the tables built so far ...

Well, they won't compress. The table file consists of 64-byte records, and each record has 32 bytes of the challenge (it is actually a public key of a random secret key which you're not going to use) and 32 bytes of the response (it is the yespower hash of the challenge). Data of this kind looks random, so no compression is possible.

If usual VPN software doesn't work for you, perhaps it means your VPS doesn't support tun/tap interfaces, which is typical for older VPSes. Unfortunately, I never saw a tool to forward UDP ports, like ssh does for TCP, despite such software solution is obviously possible.

However, there's (right now) no real reason not to run a node (that is, fedaserv instance with point number 254 a.k.a. 0xfe) on a VPS. Just keep your node master key private (preferably on cold media such as USB flash sticks), and keep the ZeroPoint key on your home machine. The keys for the point254 may be regenerated at any moment, as well as the ZeroPoint key (regeneration of the ZeroPoint invalidates all other points signed with the ZP's key, so this may take a lot of work; regeneration of the point254 requires nothing, and may be done with the ZeroPoint key, not involving the master keys).

On later stages of the project, there will be some (weak!) reasons to run the node instance at home instead of the VPS, but definitely not now.

Right on the server machine, with the archive file physically used by the Apache server to respond to the respective requests:

w_croco@milda:~/tmp$ tar -xjf /var/www/w_croco/public_html/feda/download/fedanet-0.0.31.tbz2 
w_croco@milda:~/tmp$ 
w_croco@milda:~/tmp$ tar -tjf /var/www/w_croco/public_html/feda/download/fedanet-0.0.31.tbz2 | head -5
fedanet-0.0.31/
fedanet-0.0.31/LICENSE
fedanet-0.0.31/README
fedanet-0.0.31/protocol.txt
fedanet-0.0.31/src/
w_croco@milda:~/tmp$ tar -tjf /var/www/w_croco/public_html/feda/download/fedanet-0.0.31.tbz2 | tail -5
fedanet-0.0.31/lib/sue/demo/b_sitter.c
fedanet-0.0.31/lib/sue/demo/Makefile
fedanet-0.0.31/lib/Makefile
fedanet-0.0.31/NODE_GEN
fedanet-0.0.31/NAT_TYPES
w_croco@milda:~/tmp$ ls -l /var/www/w_croco/public_html/feda/download/fedanet-0.0.31.tbz2 | tail -5
-rw-r--r-- 1 w_croco webadm 160775 Nov 23 14:25 /var/www/w_croco/public_html/feda/download/fedanet-0.0.31.tbz2
w_croco@milda:~/tmp$ md5sum < /var/www/w_croco/public_html/feda/download/fedanet-0.0.31.tbz2 | tail -5
807cec430b719f5b1dd34f7832fb34ef  -
w_croco@milda:~/tmp$ 

Please check both the size and the hash of the copy you have, it is perhaps broken.

Yeah, I'll fix it, thanks. The code of the plain C version of SUE is now pretty old, it was initilally written for a completely different project which never continued. So this piece appeared earlier than I finally realized how the C-like languages poison one's brain.

No.

Errrr... consumable files?! 8-()

I'll think about the directory though, earlier or later it has to appear.

Thanks, fixed

Thanks :-)

1) The archive published on this site is not, strictly speaking, the source, it is rather a subset of source files selected so that building the feda-ng and feda-ct binaries is possible. The Makefile is generated, and to simplify the things a bit, I decided to put everything in a single directory. Definitely once the real sources get published, there will be at least a separate directory for the libraries.

2) In the present state of the project, I don't want all this mess to be distributed anyhow. I plan to apply the license (yes, this one) to the first "real" release.

No, it isn't.

Thanks! I'll fix it in the next release.