For the past few months, I have been working on a free software project called Spaghetti Nodes, or Snodes for short. The impetus for Snodes, and a brief “sketch” of the idea, was first described in this post from October 2007.

The post is a bit vague, so let me take a moment to elaborate. At the time, a few students at Bucknell ran a DC++ hub for sharing all manner of files. This DC++ hub was shut down in October 2007, which led to a vacuum in the free sharing of multimedia files.

Enter Snodes. Snodes was designed to be a completely decentralized, secure method of sharing files. In order to achieve this goal, Snodes was designed to operate in roughly the following manner:

• Unlike services like DC++ or even BitTorrent, there was no central server. Every node was both a peer (client) and a server.
• Clients connected to each other based on IP address. You entered an IP address as a “buddy” or contact.
• The entire session was encrypted, first using a shared passkey (more on this later), and then by a session key. Encryption was achieved using the Twofish algorithm.

Work began on a Java implementation of Spaghetti Nodes in October 2007. Michael Schoonmaker headed up the Snodes development team. I was responsible for the networking code, which including designing and implementing the protocol over which the Snodes peers would communicate.

---

Long story short, it is now five months later, and the project has been all but abandoned. Why?

Well, there are a couple key reasons. One is that interest in the project has been lost, namely for the following reasons:

• The need for the software is no longer as pressing.
• I’ll be at William & Mary next year (more on that in a future post), so I don’t personally need the software.
• My personal area of interest is in computer simulation (think SWAN) and scientific computing. Thus, engineering a large software system and designing and implementing a networking protocol is outside my area of expertise.
• The rest of the team has little interest in pursuing the project, likely for similar reasons.
• In my opinion, we’re reinventing the wheel. Why develop a new filesharing protocol and software when we have systems such as DC++, BitTorrent, or even SFTP at our disposal?

More importantly, I have no interest in finishing the project because I think there are fundamental flaws in the basis of the design:

1. Our authentication implementation was shoddy at best. The project leader wanted a system in which two people exchanged a shared text-based passkey that was used to set up a session. Shared secrets are always insecure, and when your shared secret is essentially a password, reliability of the security of the system drops dramatically.

2. Nodes (i.e., users) were identified solely by IP address. Connecting to peers was cumbersome. Sure, whenever I’m connected to Bucknell’s residential network, I have the same IP address and hostname; but if I connect to the wireless network, I have a different IP—and if I go home, or go to the public library, or my girlfriend’s house, I have yet another IP. IP-based identifiers are a bad idea.

   (I wanted to modify this system to use a public key-based authentication scheme, similar to SSH. This would give each user a unique fingerprint identifier. This idea was shot down as “too inconvenient”.)

---

The biggest thing I’ve come to realize is that a completely decentralized system with no central coordinating server is very, very difficult to implement. Even BitTorrent uses a tracker to manage the distribution of files.

But there is a solution: A semi-decentralized setup, similar to email. (Actually, my inspiration stems more directly from Jabber.)

The file sharing network would be a system of servers, similar to email servers, to which users would connect and through which they would communicate with users on other servers. Thus the problem of one central server would be avoided, but the system would be more flexible than one in which there is no server.

Users would still be authenticated using public keys (again, similar to SSH), and the transmission stream itself would be encrypted in a manner similar to BitTorrent, but stronger. The protocol itself would be XML-based, like Jabber’s XMPP, but compressed so as to restrict bandwidth. (Minimizing bandwidth usage was also a top concern of mine, if only to appease network administrators.)

So basically, instead of a fully decentralized system, we would have a mostly decentralized system like email.

I’d like to develop a reference implementation of this idea (most likely in Python), but I most likely don’t have the time, so for now, the idea is only fleshed out in my head.

---

The original Spaghetti Nodes code still exists as a Git repo at GitHub. The code is released under the GPL. Feel free to check out the project and poke around. Here’s how you can get the Spaghetti Nodes source code (using Git):

$ git clone git://github.com/mdippery/snodes.git