Monday, April 14, 2014

The global recession

At the moment I am without a job, mostly due to the global recession that hit also my previous employer.
If you want to give credit to my efforts in this project, your donation will help me to bring home the bacon.

So, let me remind you that I am accepting donations through bitcoin. See the link on the right side.

I will not provide another method for supporting me with donations.
You do not own a bitcoin wallet yet? Well, you definitely should.

Thanks for any contribution.

Wednesday, March 5, 2014

Status Report

The porting of Netsukuku to Vala has been completed.

Almost! The DNS wrapper is still missing. It is a piece of code that listens to standard DNS queries and forward them to the ANDNA system. But there are tools that can query directly ANDNA.

Also, the Internet Sharing is still missing. Consider also that in the python implementation this feature was rough and poorly tested yet.

So, yes, I consider the porting really complete.

Obviously the code has to be tested, debugged, fixed, tested again, etc etc.

The daemon is misbehaving in a number of ways.
There are a number of testsuites here and there for various parts of the operations but they are not exhaustive at all. So it was really expected.

Finally I want also to introduce a tool that I made to help the debugging by providing a view of some of the status informations that can be queried to the nodes.

This node has two direct neighbours.
Look, these are the IDs of gnodes and of the entire network.
Behold! All the known destinations, and for each the entire path!
Look ma': I am the Coordinator!
Some ANDNA records.

Monday, February 24, 2014

Participation rewards

Recently I read about a fresh new project that shares with netsukuku a lot of principles.
This project aims to create a mesh-network where the collaboration of the nodes is rewarded with a crypto-currency. This currency is then used as a payment for sending ones own trafic over the network.
Francois Zard, the ideator, contacted me before going public, asking for clarifications on the status of our project.
I wish him and his project to grow up well.

His idea made me think about the possibility to exploit the features of netsukuku network protocol in order to have a similar rewarding scheme. After a few days I came out with a rough idea that I share with you.

The rewarding mechanism

A new feature of Netsukuku will allow the participants to give a reward in money to the owners of the nodes that permit them to reach their favourites contacts and services.
This is on a completely voluntary basis. The network remains free of charge for everybody.

There are many projects today that have the goal of building a self-sustaining network where participants are incentivised to improve the network. The key point in all of them is to reward not just the provider of a service, but the owner of the nodes that make it  possible in the first place the connection between client and server.
Many of the proposed payment schemes try to reproduce how the bitcoin transactions work, but with a new digital crypto-currency.

Netsukuku will take no effort to create a new currency, and not even be tied to the best payment solution that we could find. It will just make it possible for a node owner to reward the right people. More precisely, the owners of the nodes that are in a precise instant connecting him to his favourite friends.

Netsukuku will not, of course, expose their identity, but only a payment address that is at their disposition.

The actual payment processor can be anything that has the required properties. There can be at the same time more than one.

A first implementation of this will use Bitcoins, the real thing. With most probability it will use Coinbase services, because it is good for us to have a practical way of enabling micro-payments with no fees and with low delay confirmations.

At the moment I figured out 2 types of payment procedures. One is initiated by the client at his will. One is required by a service provider.

Client-initiated procedure

A node owner, say A, uses frequently a certain service hosted on the node of another participant, say B. Or she speaks with B owner via a VoIP application that contacts directly the node B.
Supposedly, A might be willing to donate, every now and then, some money to the nodes that make her communications possible. Because she wants them to keep on running their nodes and possibly improve their links.
Node A will send a particular message to node B; this will trace the nodes that make up the best route right now, and obtain from them a Bitcoin address (or other payment address, but for now we refer to this). Node B responds to A with the list of addresses and A can make the payment.
Obviously A can make this donation whenever she likes and for the amount she likes. A good strategy for A would be to make frequent micro-donations during the very same hours when she uses the most the service that she cares.

Service-required procedure

The owner of node S (S=server) provides a service to his customers. He wants to get paid for this service based on the volume of trafic that is used.
S might be willing to share (a part of) his income with the nodes that form the link from his server to his customer. Because he wants to incentivise them to stay and new nodes to arise for him to be reachable by a broader mass of potential customers. Hence, S advertises that he is providing a service through this channel with this feature.
A client C sends a particular message to S; this will trace the nodes that make up the best route right now, and obtain from them a Bitcoin address. Node S will append its own Bitcoin address and respond to A with the list of addresses and the amount of payments that he has to do to each of the addresses per unit of trafic. Furthermore, the nodes that form the link will be notified of the IP address of C and S and the amount that they are going to receive per unit of trafic. These hops might then verify every now and then the payments and (if they want) temporarily block the trafic on this flow if they don't receive the payment.
A consideration: C could "cheat" and not make the payment to the hops, because he thinks that they will not check. But for sure he will not be able to cheat S, because he will verify, of course, and deny the service. So S, if he really wants to reward and incentivise the hops, could ask for a slight bigger price for his service and then take care on his own to donate back to the bitcoin addresses that he receives with the message from the client C.


What has been briefly exposed until now is plausibly feasible with any payment processor that possesses some properties.
Now let's take the assumption that the Bitcoin network is used.
Here are some considerations about the problems that arise with this choice.

First, not all the nodes are required to participate to the service.
But only those who participate can be rewarded or initiate a payment.

When a node participate to the service, the only requirement is to be configured with a Bitcoin address where he can receive payments. It is advised to generate a new valid address for each payment, if the node is able to do it; but it is not mandatory.

If a node wants to be able to check the payments then he needs to get connected to the bitcoin network. Or at least to get connected from time to time to the Internet and use some host which provides informations, such as This requirement is not particularly hard to satisfy. For example it's enough if the owner of the node has got also a computer which is connected to both the netsukuku network and to the Internet.

If a node has trouble to get to the Internet but wants to participate he can do. It will not be able to check the payments, so it shall never block the trafic. Nevertheless it will probably receive payments, because when the network is highly dynamic it's hard for the client to know in advance which hops will verify the payments and which ones will not.

A node that wants to pay (or donate) could do this by having a bitcoin client and having access to the Internet. Anyway this requires big computational and memory resources. Further, it would be prohibitive to send micropayments because of the fees built into the bitcoin network.
There is a better alternative if the payment address of the sender and the receiver are both accounts of Coinbase service. In this case micropayments with low delay and no fees are possible. Furthermore the client just need to use the API of that service and this can be done with very low computing resources.

Final note:
The porting goes on steadily. I presume to have a first version ready for the masses before summer. I hope obviously to be able to implement also the rewarding system.

Friday, December 13, 2013

A Short Report

This is a shot at a spreadsheet where I have enumerated all the functions in the Python code of netsukuku. Those marked green have been ported to the Vala version, the red ones are still to-do.
I thought to share that bit of info, so you can have a vague idea of the progress with this task.

The bottom part of the list (the red pile) contains functions that implement ANDNA and the DNS wrapper. These aspects are vital for end users; but they are not essential in order to conduct preliminary tests on the routing engine. Therefore I think that after a few more code I will be able to stress test the netsukuku daemon in Vala.

In the meantime I have isolated the part of the code that handles the RPC mechanism of the program. That is what make possible for the nodes to communicate and interact with their direct neighbours. I packaged this code in a library; by using it one can create useful tools for monitoring the network. As an example I made a graphical utility that shows the neighbours that run netsukuku.

Tuesday, July 3, 2012


A significant change is going to happen in my life. I am temporarily leaving Italy. I am going to stay in Israel for a year or so.
Thus I will cease any activity on the network that I was experimenting with with my neighbors.
But I think that during my stay in Israel I will still be able to spend a tiny fraction of time to develop the software.

Monday, May 14, 2012

Funding - future directions

These are my thoughts about the results of the funding proposal.

In a few days circa 250 pageviews on the blog, and 7 comments. The voice spread quite a lot and soon.

Through the mailing list, circa 20 people have let me know their approval and that they could have pledged 20 euros or more.
It is worth something around 400/500 euros.

Someone could very well have read the proposal and be willing to pledge, but he just did not send a response/comment.

Anyone of those, at the moment of a real crowd-funding effort, could be able (and more willing than now) to spread further the voice and convince more friends of theirs.

I was skeptical about this idea. But in the end, I believe that the response of the community has been good.

Anyhow, I've the feeling that at the moment it's not worth the effort of registering the project on a crowd-funding platform.

I assume that the reason is that we currently have too few results that can be presented to non-techy audience.
We have the working prototype written in python, which is not very simple to deploy and suitable only to desktop-class nodes.
We are not much far from having a prototype in vala, which can run on a router. But we're not quite there, yet.

I think that we have to settle for some more work on a spare-time basis.
I hope that we will succeed to produce soon a working prototype with just the very basic functionalities of netsukuku runnable on many models of affordable routers and access point.
When this will be the case, I will test the waters again for a crowd-funding, because we will still need a lot of work for the other features.

In the meantime, I decided to start accepting donations on my blog, with the aim of putting aside money for the next tentative.
I assure I will report on the blog the current amount of received donations, and I will not use any of them until we make another tentative of crowd-funding.
The aim of the crowd-funding, I confirm, will be to free a part of my daily duties with my current employer and let me concentrate on netsukuku for more time per day.

I decided, also, to use Bitcoin as the mechanism to receive donations.  So you don't need to pay fees to banks.

In other news, look at the situation in Europe.
The financial markets crisis and the many corruption cases in various kinds of centralized authorities.
This makes me more convinced than ever that we do have to find new ways of freeing us from the need of centralized control in as many aspects as we can, of our lives.

That is why I also looked for some informations on Bitcoin.

Thursday, May 3, 2012

A proposal


The project Netsukuku is alive, and under active development.
Nonetheless it is a fact that advancements with the development of the software come at a very slow pace, though they are real and quite continuous.
I think that it is important that the fundamental features of the project may be implemented more quickly; those features are also realistically feasible.

The idea

For quite some time I think about trying the way of crowd funding as a means for me to be able to devote myself to the development continuously. Crowd funding is a mechanism to raise funds for a project by donation pledges, that are usually of low amount. These pledges become real donations only if, within an expiration period, their total amount grows up to the minimum requirement for the project.


I evaluated that, if I can reach an amount of 15,000 € (circa 20,000 $), I would be able to work on the project part-time (4 hours a day) for one year. This would imply, indeed, that I cannot work full-time for my current employer.
The reason why I thought that I could make this proposal is that, if we focus on the aspect of the production of the software in Vala and consequently its installation on embedded devices with OpenWRT, that I am the only developer working on it. This continuously for over 18 months, though only in my spare time.
I still have to choose the funding platform (,,,, ...) and make all the steps for the presentation of the project. Anyway in the meantime, I wanted to test the waters on this community and with some contacts of mine. Soooo, what do you think?