[shepdog]

Originally Posted by TankGirl

Hi and welcome to P2P-Zone, shepdog! It is always a pleasure to see new developers joining the p2p movement!

Thanks TG (can I call you TG? lol). The p2p space is such an interesting problem domain and is one that I feel is the most wide open when it comes to oportunities for new development. I've been drawn to it like a moth to a flame.

Originally Posted by TankGirl

As for the title of your thread, you have come to just the right place to ask your questions – this is an active and savvy p2p community with plenty of collective experience and insight.

This is becoming more and more apparent the longer this thread gets and the more I delve into earlier posts. You've had some especially thought provoking threads.

Originally Posted by TankGirl

Hashing is the obvious solution here. Hash trees are definitely worth considering as they allow you to verify files in small chunks, and the verification does not depend on the order in which the chunks are received. The latter property becomes important in multisourced environment where you may request things in a certain order but receive them in a totally different order.

Wow, what a great abstract. This is just what I was searching for. Thank you.

Originally Posted by TankGirl

This might not be a very good idea. Mixing higher quality rips to lower quality rips on the fly will just gradually degrade the average quality of the content pool and make it harder to spot original high quality releases apart from their more or less degraded versions. It is much better to try to distribute high quality releases as such, untouched, and thereby maximize the number of peers having them in the multisourced environment. If a lower quality version is needed for some reason, it should be distributed similarly untouched, so that the peers having it could form another large set of sources for downloaders.

I understand what you are saying about the degradation of quality from re-encoding. My motivation behind this was to provide more resources for slower connections to d/l files from. If they only want to d/l at 128bps and all that is available is 320bps or a vbr I could see the possibility of d/l at a lower rate. So you see 15 sources for a vbr or 320bps file but it would take you 4 hours to d/l it would be nice to have the ability to right click on the source and have it d/l at a desired bitrate. Of course these re-encoded files could be cached and tagged to point back to the original.

Originally Posted by TankGirl

I think Filetopia has used a similar approach but for an average user such a choice is needless and technically very challenging. Few WASTE users know (or care to know) which particular encryption method is being used in the software – for them it is important to know that the method chosen by the developer is 1) secure and 2) efficient enough to do the job. It is a good idea to test different encryption methods and compare their efficiency, but maybe this testing should be done by the beta testers, and at the end you would just pick the one that both you and your beta test team considers to be the best choice.

I totally agree that simplicity is the best approach for the average user, but for power users and all the tinkers it would be nice to give them the ability adjust settings. From the programming API's perspective this will be easily controlled, maybe just not from the user interface.?

Originally Posted by TankGirl

It would also be good for the end user if various optimisations (for speed, for search success etc.) would be as automatic as possible. If there is a set of parameters to be optimised for me to get my stuff faster, I would like the smart software to do the optmising in the background and just deliver me the goodies with the best speed possible from the network!

Totally agree here as well. The system will try to optimize all the time, and learn better optimizations over time. Read between the lines there.

Originally Posted by TankGirl

Here is an interesting earlier discussion on permanent identities and related stuff like trust relations. Many important points and technical details are covered in the discussion so it is worth checking for a developer. As Dave points out, permanent and verifiable identities are needed to build any sort of sustained peer relations and social structures. When you have permanent, cryptographically strong identities, you can start building 1-to-1 trust relations, trusted groups and trusted distribution networks on them. Artists and other sources of new content need permanent identities even more than average users to be able to establish a reliable and genuine presence on the network.

I totally agree with your assessment. When it comes to community you would like to be able to have permanent identities based upon a hash and have a form of 'dns' for lack of a better term to be able to locate and communicate with the given identity if online. In looking at giving tools to the content providers to set up channels to allow them to offer their content as well as allowing users to reward content providers with money a thought occured to me. It would be nice for a content provider to be able to identify the user that gave money and to target that user in the future because they donated in the past. The problem with this is that if I can tie say a paypal account to a hash for this purpose it would negate the anonymous aspect of the single hash used as identity. Because if that use ever provided a file encrypted with that hash I could tie it right back to them. I was thinking of a way around this by providing a Identity public key that the user would be known by, but also the user would have a public encryption key that would be used for all encryption related transmissions to/from the user. This would allow a seperation between the public identity of user and allow them to contriibute to things they think is worthwhile and to be rewarded by that content provider as well as remain anon when they don't want to contribute to a content provider but still want to snag content. Just a thought I was kicking around in my head on the way into work this morning. Like I said earlier, I have a hard time thinking about anything else.

Thanks for your feedback and your previous postings. Very good information.

One last question to the board in general. Do any of you think you would be interested in beta testing a new p2p app around the end of the year? I've got to start thinking about it..

Thanks to all of you for all your feedback.

John