Announcing FURIAA

[twinspan]

I leave the Underground for a couple of days (work deadline and a killer heatwave), I come back.... and I find a brand new p2p app - dedicated to me

I love you guys!



Now for the nitty-gritty:

Anonymity: will that be IP bouncing?

Jack mentioned that Freenet has that, but I don't think it does. From what I remember Freenet only provides deniability: someone can still do an IP trace on something back to you, but the nature of Freenet means you can (sometimes) honestly say you didn't know the material in question was on your PC, as the program/network archived material in encrypted form 'published' by someone else. AFAIK only Filetopia has IP bouncing, and only then as an add-on, and you have to find & connect to a specific 'bouncer' to use that feature.

As the main oppression tactics of the copyright-exploiters are: 1. intimidate/attack the p2p app makers, 2. IP trace and intimidate the p2p sharers & their ISPs, IP bouncing is the way of the future in p2p.

(BTW, did you relocate to Sealand yet, AYB? you don't want to end up like AG...)

.NET vs. Java

I don't really have a clue on the various merits of each... which is exactly why my opinion on it matters!

The vast majority of potential F-U-RIAA sharers won't know either, but they will know that Java has been out for a while, is tried & tested and that they probably already have it. Do they really want to install some life-altering 'framework' just to try out one new p2p app? Prolly not.

In a few years time when .WTF is well-known and installed by default in newborn children, it won't be an issue having the app coded in .WTF. But for now, I am glad (and, yes, a little proud <sniff>) that you have chosen the Java route.



Now I just need to get my hands on your new app. Congratulations, best wishes and many happy returns on your app's 'birthday'!

And remember, folks... just say: "F U RIAA!"

[AYB]

Well work is coming along nicely

I honestly haven't looked at how we will achieve anonymity yet as its quite a ways down the road at this moment in time.

As far as getting attacked ourselves, with the initial release simply connecting to other networks we have very little to worry about. And as I've said b4 if there is any danger of us being closed down we will make our project open source (if it isn't already)

[SA_Dave]

Originally posted by TankGirl
Regarding the architecture my advice would be to pay attention to the issue of permanent, verifiable peer identities. It's a bit trickier to implement in the decentralized environment than on a centralized system but it is worth it.

Now if that isn't the understatement of the century! In order for this to work, you'd need a server/server-farm to maintain this or each superpeer, or at least a dependable group which will be disadvantaged in that every supernode would be as dependant on them as on a central server, would have to maintain an index of every client (as not every superpeer will be always-on & not every system can be guaranteed to be permanent or stable, this would provide a RAID structure to the database.) This would entail massive amounts of hdd space & bandwidth being used just for this purpose alone. Furthermore, each client would require some sort of unique encrypted key or fingerprint. How can you guarantee that this won't be lost in a format etc.? I'd rather those resources were dedicated to file-transfers & storage of the files instead! This may be possible in future when every1 has broadband & unlimited storage space, but this is a far-off dream.

Personally, I think that an app with a built-in web community (eg. bitzi comments, hashlinks & forums) is the best solution right now. If people could easily find ways around fakers, viruses etc. ,while learning about their favourite client, their computer & their fellow netizens, it would encourage them to become better members themselves. This would have a beneficial ripple-effect on all the communities/networks they participate in. When I first started using FT clients, I was only interested in the content. It didn't occur to me that a community even existed! This is why it should be easily accessable from the client-side. Plus, many clients with strict anti-leeching policies are failures. I suggest reading this article posted by naz yesterday. Also, you shouldn't neglect the fact that many people enjoy multiple accounts & the anonymity that today's p2p clients offer. This does cause problems as far as fakers, virus sharers & spammers are concerned. However, it does attract many decent citizens who might not otherwise participate out of concerns for the snooping phenomenon.

Originally posted by AYB
The very first release will probably only connect to OpenNap and Gnutella but bear in mind we will have the whole proprietory-to-generic system in place for this which will mean adding a network is easy - expect at least one new network with every major release.

This sounds interesting! As a disgruntled dial-up user, I'm frustrated at the frequent upgrades of clients, which require clean installs. This is why I, as well as many others, restrict myself to using about 2 or fewer clients. A modular design would be revolutionary! I'm not necessarily asking for an auto-upgrade feature (although it would be nice) but plugins sound like a good idea. It would be nice if people could customise their upgrades eg. I can download only the network features, ui updates or main executable patches/improvements that I want or need. As far as I'm concerned : SIZE MATTERS. This is another reason why I prefer java to .NET (which has raised a few security concerns already due to its flawed documentation, which the linux version probably won't have to deal with.) Ethen brought up some good points about the efficiency of the .NET-based apps. I can't comment however, as I tried 10 times in a row to download it last month & it failed every time almost near the end! I'm sure not all .NET apps are that small & there's every likelihood that security patches & upgrades will be required as the project evolves. I'd rather not use it right now for these reasons.

I'm going on a bit now, but another feature that I believe is important is priority. If a rare file is available, I want it to receive the utmost attention! Another thing I hate is when a common file is 99% complete, yet the client starts downloading another queued file from 0% because the temporary file is alphabetically prioritised or some other arbitrary reason! Priority for uploads is another way to ease the distribution of rare material. Right now, it requires manual editing of shares or moving partial downloads.

Finally, I think that embedded metadata, although useful, can lead to "fragmentation" of distribution. People change filenames or tags all the time for selfish reasons, without re-encoding or otherwise editing the actual contents. Swarmed downloads can become irrelevant in some of these scenarios, as hashes are based primarily on filesize (which is altered slightly when tags/filenames are changed) as well as type & name. If only multi-source downloads could actually use all the sources available & you could change the details once it completes. If you could develop a hash which ignores tags, as well as one which includes them (2 hashes per file), this might be somewhat phenomenal! Another way around this problem would be to use a simple external database (.xml file for example) which overlays details onto files for searches. The only problem is this wouldn't be compatable with most external audio/video players. We need a change in standards before this might be feasible! As others suggested, sharing of partials is another solution, but I don't think it's enough when dealing with high-speed leechers.

Okay, that's all.

[JackSpratts]

Originally posted by AYB
Well work is coming along nicely

I honestly haven't looked at how we will achieve anonymity yet as its quite a ways down the road at this moment in time.

You'll be looking at various ways to protect the identity of the users of your system, particularly the data or source originators, as they seem to be in the RIAAs' sights now. Here's some food for thought to peruse when the time is right, from a paper written some 18 months ago but still relevant. There are other ways, including full IP masking by bouncing uploads through other computers. As that can seriously degrade performance I believe it ought to be used cautiously but should remain an option for your killer P2P.

- js.

“The primary goal for Freenet security is protecting the anonymity of requestors and inserters of files. It is also important to protect the identity of storers of files. Although trivially anyone can turn a node into a storer by requesting a file through it, thus ``identifying'' it as a storer, what is important is that there remain other, unidentified, holders of the file so that an adversary cannot remove a file by attacking all of the nodes that hold it. Files must be protected against malicious modification, and finally, the system must be resistant to denial-of-service attacks.

Reiter and Rubin present a useful taxonomy of anonymous communication properties on three axes. The first axis is the type of anonymity: sender anonymity or receiver anonymity, which mean respectively that an adversary cannot determine either who originated a message, or to whom it was sent. The second axis is the adversary in question: a local eavesdropper, a malicious node or collaboration of malicious nodes, or a web server (not applicable to Freenet). The third axis is the degree of anonymity, which ranges from absolute privacy (the presence of communication cannot be perceived) to beyond suspicion (the sender appears no more likely to have originated the message than any other potential sender), probable innocence (the sender is no more likely to be the originator than not), possible innocence, exposed, and provably exposed (the adversary can prove to others who the sender was).

Against a collaboration of malicious nodes, sender anonymity is preserved beyond suspicion since a node in a request path cannot tell whether its predecessor in the path initiated the request or is merely forwarding it.

Protection for data sources is provided by the occasional resetting of the data source field in replies. The fact that a node is listed as the data source for a particular key does not necessarily imply that it actually supplied that data, or was even contacted in the course of the request. It is not possible to tell whether the downstream node provided the file or was merely forwarding a reply sent by someone else. In fact, the very act of successfully requesting a file places it on the downstream node if it was not already there, so a subsequent examination of that node on suspicion reveals nothing about the prior state of affairs, and provides a plausible legal ground that the data was not there until the act of investigation placed it there. Requesting a particular file with a hops-to-live of 1 does not directly reveal whether or not the node was previously storing the file in question, since nodes continue to forward messages having hops-to-live of 1 with finite probability. The success of a large number of requests for related files, however, may provide grounds for suspicion that those files were being stored there previously.

The Freenet network provides an effective means of anonymous information storage and retrieval. By using cooperating nodes spread over many computers in conjunction with an efficient adaptive routing algorithm, it keeps information anonymous and available while remaining highly scalable. Initial deployment of a test version is underway, and is so far proving successful, with tens of thousands of copies downloaded and many interesting files in circulation. Because of the anonymous nature of the system, it is impossible to tell exactly how many users there are or how well the insert and request mechanisms are working, but anecdotal evidence is so far positive. We are working on implementing a simulation and visualization suite which will enable more rigorous tests of the protocol and routing algorithm. More realistic simulation is necessary which models the effects of nodes joining and leaving simultaneously, variation in node capacity and bandwidth, and larger network sizes. We would also like to implement a public-key infrastructure to authenticate nodes and create a searching mechanism.”
http://freenetproject.org/cgi-bin/twiki/view/Main/ICSI

[TankGirl]

Hi SA_Dave and thanks for your good post!

Originally posted by SA_Dave
Now if that isn't the understatement of the century!

LOL ok ok… I admit putting it intentionally in a bit provocative way and am glad that somebody caught it so that we can discuss this interesting issue in more depth!

Originally posted by SA_Dave
In order for this to work, you'd need a server/server-farm to maintain this or each superpeer, or at least a dependable group which will be disadvantaged in that every supernode would be as dependant on them as on a central server, would have to maintain an index of every client (as not every superpeer will be always-on & not every system can be guaranteed to be permanent or stable, this would provide a RAID structure to the database.) This would entail massive amounts of hdd space & bandwidth being used just for this purpose alone.

What you are describing above is centralized infrastructure doing centralized identity management. Before we can draw conclusions about horsepower needed we need to analyse closer what is really included in a decentralized identity system with related hotlist and messaging services.

To start off, there is no need for any single peer to keep a complete index of all identities in the network. In fact this is impossible in a decentralized network where new identities appear and old ones disappear in an unpredictable way in different parts of the network. We don’t need to know and memorize the identities of a million peers that form the network but rather the identities of a few dozen peers that are on our hotlist and ignore list. In addition we might want to memorize the identities of say 1000 of our last file transfer contacts (so that we could reward sharers and restrict leeches). Instead of having a fully connected PxP identity matrix (P being the population) we are having a sparsely connected network of P nodes, not unlike the brain where each neuron is connected only to a very small fraction of the entire neuron population. The technological challenge is to develop an architecture that implements this in the decentralized environment.

Originally posted by SA_Dave
Furthermore, each client would require some sort of unique encrypted key or fingerprint.

Precisely. The public key from an asymmetric crypto key pair would make a nice public identity – easy to make unique, ready to be used for protected communications and always verifiable by the owner of the private key.

Originally posted by SA_Dave
How can you guarantee that this won't be lost in a format etc.?

By saving the identity info (key pairs, nicks, avatars etc.) into a floppy or a CD. The same media could be used to move peer identities from computer to computer.

Originally posted by SA_Dave
Personally, I think that an app with a built-in web community (eg. bitzi comments, hashlinks & forums) is the best solution right now. If people could easily find ways around fakers, viruses etc. ,while learning about their favourite client, their computer & their fellow netizens, it would encourage them to become better members themselves. This would have a beneficial ripple-effect on all the communities/networks they participate in.

All true. The various group and community tools are very useful and beneficial for any p2p network.

Identity management is a separate question but has an important impact on community tools and activities as the quality of identities determines whether trust mechanisms can be implemented in the groups or not.

Originally posted by SA_Dave
When I first started using FT clients, I was only interested in the content. It didn't occur to me that a community even existed! This is why it should be easily accessable from the client-side.

Ditto!

Originally posted by SA_Dave
Plus, many clients with strict anti-leeching policies are failures. I suggest reading this article posted by naz yesterday.

Also, you shouldn't neglect the fact that many people enjoy multiple accounts & the anonymity that today's p2p clients offer. This does cause problems as far as fakers, virus sharers & spammers are concerned. However, it does attract many decent citizens who might not otherwise participate out of concerns for the snooping phenomenon.

I agree. Access to the community should be easy, and everybody should get some good stuff easily even from behind total anonymity. It is important that newbies get good first impressions of the network and do not get knocked down by any over-efficient anti-leech mechanisms. And it is much better to use reward mechanisms which begin to enhance your life in the network as soon as you start successfully sharing your stuff.

- tg