FEDAnet project

> 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.