It looks fantastic. Here's why I think it's better than BitTorrent, keeping in mind i've only read their FAQ, and haven't done extensive testing of it.
BitTorrent doesn't work through NAT. It actually works, but only in leech-mode. Which means, if you're an average non-techy user behind a broadband router's default-configured NAT, install BitTorrent and download files from other peers, you actually do not contribute any bandwidth back to the rest of the network, because other machines on the Internet don't have a clue on how to reach you. Of course, it's very easy for someone with a little bit of tech savvy to do the necessary port forwarding. But realistically, on a large scale, who ever bothers?
update: ok it would appear the above paragraphs are angering armies of geeks. Take a deep breath as I concede your collective point with the following: Yes, if your BitTorrent client already has an active connection while downloading from a peer, that peer will be able to get data from you, and you're therefore indeed "contributing bandwidth" back, to some extent. I've experienced this first-hand. It's nice. But if I'm behind NAT, and I don't have port forwarding, and you're behind NAT, and you don't have port forwarding either, then our BitTorrent clients won't exchange data directly from each-other. Period. Is this a big deal? Obviously not, as there are enough people out there with properly set-up connectivity to keep BitTorrent a successful and vibrant community ... of mostly geeks who know what they're doing. I'm looking at a different market. I'd like to see a peer-to-peer solution that enables a wider audience to become first-rate bandwidth contributors. With some maturation and polishing, working out a few kinks, it would appear dijjer just might get us there.It's not impossible to defeat the vast majority of NAT issues in the wild. The STUN protocol, released around 2003, tells us how to do it. Most SIP-enabled client software and devices make use of it, to avoid having to relay RTP packets between peers.
Dijjer claims to be able to defeat most NAT issues. And I wouldn't be surprised if it used many of the techniques outlined in the STUN protocol.
It also looks far easier to deploy than BitTorrent, as most of the work of finding peers seems to be handled by the clients. It may or may not be a good thing, it looks like they use some "seed peers" to establish initial contact. But they've removed the need for the content owner/deployer to create anything "special" on their server. They just need to link to their a file a bit differently. And as their FAQ mentions, the file's presence on the original HTTP server is used for policing its distribution over the dijjer network: If a file lives on your web server, and you decide to link to it via dijjer, then subsequently change your mind, you can just remove it from your server, and nobody on the dijjer network will be able to download it.
On the peer's machine, it appears to expose a lightweight http interface on a high port. When you're downloading a file, the browser actually retrieves it over normal http from localhost, over port 9115. If you've installed dijjer, try this URL: http://localhost:9115/. It seems to be a technique vaguely similar, in principle, to what certain "web accelerators" do. The fact that as a user, I don't have to "switch" to another application to merely download a file, before resuming web browsing back into the web browser, makes the whole experience more usable, less clunky, less nerdy.
It also opens the doors for 3rd-party applications to interface with Dijjer via straight HTTP, without having to write custom components that comply to a different protocol. These folks might one day likely be interested in switching from BitTorrent to Dijjer.
One thing to keep in mind is that dijjer wants to keep running in the background. When double-clicking that .jar in Mac OS X, it's not readily obvious that dijjer is running. You can easily shut it down via http://localhost:9115/, or, on the Mac, a "killall java" from the terminal. I haven't tested Linux and Windows yet. Their FAQ also mentioned that dijjer might pre-emptively start "caching" stuff on your hard drive, stuff you may have never requested, but that's useful to other people on the dijjer network. But again, a peek at http://localhost:9115/ tells you what it's doing, how much space on your hard drive is being used, and your download/upload activity. Before putting-on the tinfoil hats, remember that dijjer is 100% open-source, and verifiably crap-ware free.
In contrast, with BitTorrent, you'll only ever seed files you've previously downloaded, or are in the process of downloading. BitTorrent is very-much more of a "foreground" process.
Going forward, dijjer will likely mature and become more polished. It's already very usable, and very promising.
A few replies to some comments in the digg submission:
I *did say* you *can* make BitTorrent work through NAT to enable other peers to 1) discover you 2) connect to you without your having previously connected to them, *if* and only *if* you do port forwarding, as outlined in the BitTorrent FAQ which i linked to in the article. As i mentioned in my review, it is simple enough for us geeks, but not for your average newbie. Having out-of-the-box NAT traversal support dramatically increases your potential user base.
When you look at peer to peer frameworks, you've gotta distinguish a few aspects of the peer to peer features. Two of which are: 1) file and peer discovery. 2) distributed file transfer.
Some peer to peer frameworks have a highly decentralized file and peer discovery mechanism, and those are nicely suited for illegal sharing of files.
Other peer to peer frameworks, such as BitTorrent and Dijjer do not seek to make the file discovery aspect decentralized, because their designers didn't seek to build a rebel or illegal file sharing network. That's why it's so easy for the RIAA to go after torrent sites today. And Dijjer is even more tightly coupled to the source than BitTorrent is, as it is a feature.
There are people out there who don't use peer to peer technology to share illegal content.
The folks (Nicholas Reville, of downhillbattle.org fame and many more) behind http://getdemocracy.com/ have embedded their own BitTorrent client within their TV player to save bandwidth for the various content providers. And that's already very cool. Integrating Dijjer instead of (or in addition to?) BitTorrent into their client might make their platform even more efficient. One of their developers has mentioned to me they've indeed been looking at dijjer.
The end-game of legal use of peer to peer technologies is a new framework for content distribution. Profound disruptions of today's media. Pretend for a second that something such as dijjer, or something better, gets wide adoption, among the masses. And i'm talking about the real masses, our Moms and Dads, with their home broadband connectivity and plenty of bandwidth to share.
Say you suddenly decide to become your own movie producer and director, and you manage to make movies people are actually interested in watching, and perhaps eventually buying. In a dijjer-enabled world, you could likely serve your movie from any normal web account with a low bandwidth quota, but link to it through a dijjer-ised link.
Unlike with bittorrent, you didn't have to purchase a special hosting account at a BitTorrent provider (prodigem are cool guys), nor did you have to set-up your own BitTorrent server/tracker. You just uploaded the file to your web account, but instead of giving this url to your friends: http://someisp.com/youraccount/mymovie.mov , you gave them this url: http://dijjer.org/get/http://someisp.com/youraccount/mymovie.mov .
I'm interested in peer to peer technologies to replace traditional media. Not to illegally share the crap they shove at my TV. Hence the title of this blog post.