Slashdot Mirror
MUTE: Simple, Private File Sharing
oohp writes "MUTE is a new file sharing network that provides easy search and download functionality while protecting your privacy. It does this by routing all messages through a network of neighbour connections, using virtual addresses and encrypting all the traffic (using RSA for public/private keys and AES for the actual encryption). MUTE's routing mechanism is inspired by ant behaviour. The program is available for Linux, Windows and Mac OS X."
Well, I just installed it at home (thanks, VNC!) and did a search for "mp3" assuming that would generate a lot of hits but haven't seen anything happen. The docs are sparse, to say the least. "Is this thing on?"
Trolling is a art,
All I got was a 404 when I tried to find the Crowds homepage (AT&T research labs), but it was one of the privacy-enhancing technologies I looked at while doing my thesis. It's a similar concept with connecting to many different nodes than directly with who you want to communicate with, download files from, etc.
People say I'm crazy, I got diamonds on the soles of my shoes...
Here, CPD isn't looking for plagiarism; instead, it's looking for opportunities for refactoring.
True, I haven't tried it, but I've read the spec. You should do the same before commenting further.
The privacy arises from the fact that the file you request isn't sent directly to you but through a chain of other systems running MUTE on the Net. This means that for every file delivered, more than one node is labored with the uploading of this file, and given that, for most people, upstream bandwidth is a rather limited resource, the ultimate consequence will be that the system will be slow as compared to one where the files are sent directly, e.g., FastTrack or gnutella.
Is this truly the only Earth I can live on?
WASTE, on the other hand, is for small, private networks in which users know or trust each other. Both the sender and recipient know each other's IP addresses. This is far more efficient as users can download files directly from each other.
Both MUTE and WASTE encrypt data, thereby making it far more difficult for ISP's to determine exactly what is being transferred. WASTE has the additional benefit of being a "by invitation only" system - you can't get in unless your public key has been accepted by other users.
There is an algorithm for several parties to have a conversation while keeping the actual sender of each message anonymous.
It is called the Dining Cryptographers Problem.
Only I have more specific questions. The major problems with WASTE are as follows, in no particular order:
This is the big one. I cannot specify (by public key) who can access an individual shared directory. Since it already doesn't have any anonymity between users of the network, you don't lose anything by implementing this.
WASTE was designed to be used without centralized management, but has no access control. This is dumb. It means that anyone on the network can add people who can then download your files and suck up your bandwidth when you would rather give priority to people you actually know and care about. As such it is only useful amongst very small groups of people who are all good friends.
I plan to test MUTE very soon, perhaps as soon as this evening, but it would be nice to know if any of these problems with WASTE are addressed in MUTE.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Yep. This appears to be correct.
Lalala
1. Because if we don't, we can be fined, shut down, or go to jail. Yes, really.
2. To stop people from spamming you (intentionally or as zombies).
3. To identify viruses and inform customers (some of them, e.g. Welchia, wreak havoc with an extremely common brand of routers).
4. So our upstream providers don't drop us like a rock when we can't handle abuse reports.
5. For bandwidth metered billing (we don't, some do).
6. So when customer X calls and says "why can't I connect/get a DHCP lease/get to the web/etc" we can actually help them.
7. So we can catch and resolve problems with RADIUS or dhcpd.
If none of the above applied I wouldn't waste the disk space, because it's just not that thrilling to know that user jsmith had IP 1.2.3.4 yesterday at 15:00GMT. Of course, if you're paranoid, feel free to use Freenet, MUTE, or whatever.
These contents may be more useful than the defaults
202.52.36.144 4900
68.61.112.22 4900
24.208.214.50 4900
150.101.30.106 4900
65.71.169.148 4900
68.111.211.154 4900
>efnet #mute-net
/usr/local/bin/bash for MUTE/configure.
The conclusion of everyone who is talking in the channel is that this version is not usable due to frequent crashing. We can't tell if the routing works because the mesh constantly changes as clients crash.
Files are only shared if they are actually in the files directory, it does not search subdirectorys.
The connection list in the program often shows fewer connections than are actually open.
To compile on FreeBSD 5.1, you have to change all 'make' to 'gmake' and remove "typedef int socklen_t" and change the path of bash to
This uses broadcst search. It is disapointing that people keep reinventing the horribly inefficient original gnutella. Broadcast search will severely limit the search horizon (and probably overall size) of a mesh. We need a filesharing program that combines anonymity with an efficient search function, the state of the art is a distributed hash table with querys and results sent by UDP.
It is a pity that this ended up on slashdot now. If this had been announced when a working version is available slashdot might have given it the critical mass of users to get it rolling.
This has lots of potential and will be worth another look when it is stable