Freedom with a twist: micro-states

This is an idea sitting dormant at the back of my mind ever since i started this P2P OS project (well, should i ever be able to make any real money out of it :p): http://www.washingtonpost.com/blogs/blogpost/post/peter-thiel-founder-of-paypal-invests-124-million-to-create-floating-micro-countries/2011/08/17/gIQA88AhLJ_blog.html

PS
Just to make things clear from my personal opinions' point of view: when i say "this is an idea sitting dormant at the back of my mind" i mean the independent [micro-]states idea, but i don't have any specific form of government/society in mind just yet. My reasoning behind the micro-states idea is to allow people to build and trade things inside a small-business-friendly legislation, but i can hardly see any appeal for someone in her right minds to actually be living on a boat somewhere in the middle of the ocean.

A few words on privacy

Just stumbled upon an article discussing skype's alleged security and how it was built into skype from day one (as opposed to being an afterthought), and felt like throwing my 2 cents on this.

For some bizarre reason, it is commonly thought that a skype p2p link offers anything and everything that can translate to "ultimate privacy" and some more, but this is... anything but. Here's the drill:

1. privacy has two major components, the first of which is protecting your communication from potential eavesdroppers. On this front, skype praises itself with unbeatable encryption, which is technically true, but what skype omits to say is that a good encryption only servers to protect a link that already exists; in other words, if you talk to someone and wish to know that your communication is shielded from eavesdropping, then skype might be the real thing. However, what skype does not, and cannot, guarantee, is that you are indeed talking to the person you think you are: specifically, when you set up your communication link with your peer, the link setup stage is vulnerable to what is called a "man in the middle attack" which essentially means that someone has just placed a listening device between you and your peer, and everything that you'll be talking with your peer will in effect go through said man-in-the-middle eavesdropper. In the security world, this is called "the authentication problem" (i.e. making sure that what you're so carefully whispering to your peer indeed goes to your peer and not to someone else), and this is the hardest part (and philosophically unsolvable in the absence of a trusted third-party authority which knows you both) of the secure communications problem.
• note: without entering into too many technical details, it may be technically true that skype itself cannot eavesdrop on your communication by having one of its engineers flip some switches at their headquarters, but what skype does not explicitly say is that what it can do if it so wishes (or is legally forced) is to provide third parties with a technical equipment (i.e. a piece of skype-certified software) that can eavesdrop on any communication whatsoever if some conditions are met (e.g. if this eavesdropping software is placed on your ISP's routers then there is absolutely no problem whatsoever to wiretap your communications)
2. the second big issue related to communication privacy is whether or not a third-party can know who you're talking to, even if it won't be able to actually listen into your conversation. On this front, skype not only does not offer any protection, but its algorithms actually don't even make any effort whatsoever in this direction (e.g. along the line of Tor and the likes); in other words, there are absolutely no provisions in skype to even attempt to address the issue of protecting the identities of the two ends of a skype link.

To rise, none of the two fundamental attributes that could together label a communication link as "private" are present in skype, and while the "skype is encrypted" mantra is technically true, this mantra is blown out of proportions in terms of communication privacy.

P2P OS is different. I will not say much about the cornerstones (or implementation details) of P2P OS' security framework at this stage, but i will just say that it addresses both of the privacy issues described above, and it will [attempt to] provide the highest level of communication privacy that is philosophically achievable within the technical limitations of a given digital communications equipment.


Later edit
As i said in the post above, i don't want to get [too] technical here, but in light of some new developments i'll just mention that the cornerstone of skype's security model (and just about any security model out there for that matter) are the security certificates, and if a bunch of geeks can do things like this just imagine what a more potent attacker can do. And don't take my word on this, just look at what they say.
Needless to say (since i'm hereby flaming this model), P2P OS will not use this model.

Project status in a nutshell

The current client algorithm can log on to a server when it runs behind just about any type of home modem/router, with the notable exception of some 3G connections which purposefully use port-hopping algorithms in an attempt to make persistent P2P connections impossible (a partial solution to this problem exists, but implementing it is very low on my priority list).

In terms of connectivity, a client can currently connect to another client directly (i.e. P2P, without any relays) if at least one of the client's connections is BEHAVE-compliant; specifically, if both connections are BEHAVE-compliant, then the connection is quasi-instantaneous, while if one of the clients uses a Non-BEHAVE connection then the BEHAVE client will perform a port-scan on the Non-BEHAVE client and will find the P2P connection port.

The image below shows a simulation of a BEHAVE-to-Non-BEHAVE P2P connection.

• note: in order to simulate the BEHAVE-to-Non-BEHAVE connection, the automatically-detected connection settings on the clients had to be manually overridden, and this is the reason for the warnings in the clients' main windows.

Currently a client can only have one active P2P connection, i.e. a client cannot connect to two (or more) other clients simultaneously. Eliminating this limitation is the next planned milestone.

On the server side, the current server algorithm is very basic and only aims at supplying the clients with the information required for them to establish a P2P connection. The identity-related functionality (e.g. user registration, login authentication, etc) as well as any other advanced features (e.g. server-side contact lists, offline message buffers, third-party services integration API, etc) are not implemented, but the server software framework has been designed with these functionalities (as well as expandability) in mind from day one, such that incorporating new features (when the time comes) should be rather straight-forward.