How would you manage identities in decentralized p2p?

[alphabeater]

when managing identities in a decentralized p2p system, it's important to note the difference between user indentification and user location. the public/private key system is good for protecting anonymity and verifying identities, but only once you've found your peer's computer on the network. just doing a search for a specific user out of a whole network is unlikely to return a result.

so your current system goes:

1) find peer on decentralized network
2) you and peer become friends and add each other to trusted lists
3) you both disconnect from the network
4) you both reconnect (perhaps with changed ip addresses)
5) ?
6) you can identify each other reliably using the keys.

when you log on to the decentralized network and look for the people on your hotlist, how are they found? you could store an ip address for each person along with the various bits to verify their identity, but if that ip changes, how do you find them again? you could query each user you can find, i suppose ('hey peer, have you seen so-and-so?'), but on a network of millions it could take a little while to find your friend.

the only solution i can see is to establish a system of groups and sub-groups, with reliable, high-bandwidth computers with static ips sharing the work of 'managing' each group. upon joining the network, you would be assigned to the group and sub-group nearest to you, and this information would be stored and sent out with that verifiable identity.

this would then mean that, when you couldn't find your friend using their last-known ip address, you could connect to peers on the network and ask 'where is one of the heads of sub-group xyz of group pqr?'. this would be far more likely to return a result, but if it didn't, the client could go around asking 'where one of the heads of group pqr?'. almost all peers would know this, and the head of the group could then be asked for the head of the sub-group.

once the sub-group was found, the client could ask it where its friend is, and the heads of the sub-group could talk about it amongst themselves with one hopefully knowing. more sub-group layers could be added as necessary.

a system like this is still flawed, however - it introduces an element of (albeit reasonably dynamic) centralisation, would eat bandwidth and would have a less than 100% success rate, which to me that is unacceptable when talking about hotlisting.

gnutella identifies its users simply by ip address. this makes for 100% success on static ips, and none on dynamic ones... which unfortunately comes out at about 0% overall as the two types can't easily be told apart. what it teaches us, however, is that if you build your identification on a basic protocol of the internet, it's very hard to shut down.

my favourite idea, as i've mentioned before, is to use the dns for this. if you don't know what dns is, it's like a step up from ip - dns is what lets you have a .com, .org, .net or whatever else domain registered in any country and then have it locatable from pretty much anywhere in the world within about two days. i know it's a little excessive to ask people to register domains just to use a p2p, but there are lots of services around that will give you a subdomain of their own (you.dtdns.com, you.no-ip.com, etc.) for free, and then let you update it dynamically.

dynamic dns update means that whenever your ip changes, a program either running in the background or manually run by you will update your subdomain with your new ip address. within about five to ten minutes (this time depends on which site you get your subdomain from) anyone, anywhere on the internet can do ask their isp for a dns lookup on you.no-ip.com (or whatever) and find you.

i can already hear (uh, read) people saying "but that'll give your isp a list of all the computers you've connected to for p2p". your isp, even going by ip address alone and asking other isps who was using that address at that time, can always track everywhere you connect to. however, connections by themselves mean nothing. millions upon millions (probably billions) of dns lookups are handled every day by isps - they're generated by web surfing, email, online gaming, and any other internet-enabled program that locates a server or computer on the internet using the dns' abc.def.tld format. sorting through everything you've done today for possible p2p connections becomes like finding a needle in the largest haystack ever, and isps just won't want to take the time to do it.

by building a hotlist of people's domains/subdomains as you go around the p2p network, you can fill in step five in the verifiable keys technique. the existence of the keys also means that, if your free subdomain provider pulls the plug on you, you can simply register somewhere else, go back to your hotlisted peers and have your client say 'this is my new dns'. your client will be able to answer their key challenge and they can update their peer list with your new dns, allowing them to find you in future.

at this point i believe you have a proper verifiable, persistent user identification system - even more reliable than a centralized system in many ways, as your address on the network can change and your friend can still be sure that you are who you say you are.

[kento]

okay i can't help but feel a little outmatched here by the awe-inspiring intelligences of my fellow napsterites TG you have "dumbed it down" enough so that I can now understand it (yet without patronising me for not getting it earlier....so thank-you for that kindness) Now with that said i MUST say this:

there is just so much RELEVANT and good information here that it is going to me a GREAT DEAL of time to fully digest it all (my estimates so far...it will take me a month to fully take in all the GREAT ideas being shared here)



another thing i wanted to point out is this...we are acting like a "sounding board" for our own and other's ideas...almost like a resonance of thoughts instead of sound the vibrations of inspiration are being moved about here during this discussion.

next

i have been tempted to ask some of my 'stupid questions' off the board (particuliarly where i ask TG or others to elaborate a little more) so that I want sound more dumber than i really may be...but yet i put my pride aside for joy of knowledge I may gain by associating with my peers who have a little more (going on upstairs) than i do. :-)

oh and the MOST important point i would like to make is this:

I am willing to bet that THIS Disscussion and OTHERS similiar or just like it that go on here...have a more FAR-reaching IMPACT than any of us even realise...while many of us (maybe I should just say me) can't really REALISE or achive these concepts....SOMEBODY out there listening to and reading this CAN.....so we are basically "brainstorming" for them and theorising together the "concept" and leave the actual blueprinting, diagrams and fruition of the FINAL idea to that 'unknown other entity' present here...always watching looking for the spark to flame their inspiration into red hot action and possibly the summation of all our hopes and dreams: the really kick ass p2p client (unstoppable except by us J Q. Public)

thanks, everyone,

-kento :-)

[SA_Dave]

alphabeater brought up an interesting point. I envision that a modified version of this dynamic "DNS" system is possible in a decentralised p2p network, although only in future when the Internet Version 3 reaches mass availability worldwide, which will allow you to download a movie in 45 seconds. Of course, the current dynamic DNS services are exactly that ie. you're dependant on a company with centralised servers & limited resources. It would be extremely impractical & costly to register domain names, make DNS lookups & accomodate dynamic ip-table updating all on one or a few limited servers with limited resources, especially for p2p purposes. Imagine if even 5% of p2p users were constantly or even sporadically connected to & making use of these services!! It would be chaotic, unreliable & potentially akin to a DDoS attack in the eyes of the law. Remember that these services are designed for specific, relatively niche purposes; even in the U.S. where broadband connections are common.

The cryptographic keys proposed by TankGirl could go a long way in solving these problems. If the supernodes could maintain dynamic ip-tables which correlate to specific keys (and thus specific users with specific content) and they cross-referenced each other sporadically, then the problems with fragmentation could be a thing of the past. The supernodes should bear the brunt of this as they are the most capable in terms of hdd space, bandwidth, cpu power etc. The only problem is that Supernodes, like regular nodes, are often unpredictable, temporary or unreliable. How do you maintain the reliability, accuracy & performance you need for this system to work? A master-mega-ultra-maxi-supernode-database-server or farm thereof would be possible, but far too centralised for certain purposes! The relevant database would need to be distributed in a RAID structure, ie. in order to allow for the temporary or fleeting connection statuses of all nodes & supernodes, to as many nodes as is possible in the most stable way possible, in a similar fashion to FreeNet's content-distribution system. This presents a lot of challenges, whch is why I agree with pod on this & that's why I believe it'll happen in this manner in the near-future. The benefits are good, but at the moment too difficult to warrant.

I do understand both TankGirl's and jaan's view on needing permanent verification for a select few peers. Personally, I believe that this has too many flaws. Firstly, companies like Overpeer, RangerInc, RIAA, MPAA, CyberVeillance and all those other spoofers, child pornographers, advertisers, spammers, virus cultivators etc. would continue to thrive and frustrate ordinary users. They are hiding behind the mask of anonymity that the current networks cultivate and this proposal would do nothing ,or at the most very little, to thwart them! Secondly, what about all the situations where people wouldn't want to use this feature? Reasons for this are that you want to share different collections under different logins, you share a computer with other family members whom you do not want to inconvenience by binding their identitiy to that of the machine or simply that you are antisocial & do not want to participate (in this case it could be to the benefit of the community if you share virii & fakes or not if you are just a "fly on the wall".) I'm sure that many users fall into this "stealth" category, and they like it that way. Third, you are assuming that the user is very savvy. Would they really backup all their keys to a floppy, as tg suggested in another thread? Formats seem to be an almost communal experience nowadays. What's to prevent malicious users from remotely deleting keys or formatting drives, installing trojans, backdoors and the like or even using a compromised "trusted" system to cause major damage to communities, friendships, trusted states and even data?

The distributed database sytem, as suggested by pod, although not without its problems, seems much more ideal considering the above scenarios. In this way, there could be a degree of data integrity & security, even if a user has to perform a format! This is why I believe it'll only be possible in the future.

As for the here and now, there are other more reliable channels for distribution. I personally believe that content-centered community tools, such as quicklinks, forums, centralised chat, bitzi or similar services which are integrated into p2p-clients is the best way to go. P2P clients which are based on communities & relevant content collections eg. eDonkey, DirectConnect are generally more effective as content-distribution channels than popular "content is King" networks eg. FT & Gnutella. All of these networks are relatively fragmented (with the exception of DC), yet eDonkey is better than Kazaa because of the way it intelligently groups likewise-minded peers.

Furthurmore, the RIAA cannot shut down IRC, which is essentially centralised, especially if it's used only for chatting purposes. IRC , or a similar centralised chat network, could be a good place to test out the content-distribution methods envisioned by tg. Force all clients to use Nickserv or a similar service for verification. Then allow specialised bots to send & receive the encrypted keys. They could also allow for real-time ip & port information of a trusted contact to be distibuted between "trustees" in secured channels. The p2p-client could then use this data in a meaningful way, ie. maintain real-time connections which prevent the available content from fragmenting due to 'netsplits', to aide in relative content allocation. This is a forseeable method right now, even though it isn't strictly the long-term, decentralised system that is the ideal!

Sorry for causing eye-strain!

[kento]

no apologies necessary SA_Dave that was a well thought out and intelligent post...much greatly appreciated i am sure.

okay I hope no one will take offense at me resposting this here but it really seems it should be resposted here as it helps to "bring together" the thoughts and ideas of TG a little more clearly for me and its obvious now that her ideas are full of merit (a worthy one of praise fer sure.

okay here it is

from the thread

yes, leeches are still a problem on WinMX, especially on WPN (OpenNap servers are much better in this respect). They are not a fatal problem as the network is well alive and kicking but they contribute to the long queues by stealing bandwidth from the sharing users. In a multisourced environment leeching means also less sources for movies and music and thereby lower download speeds for everybody. Some sort of leech control mechanism - or rather a mechanism to favour sharers - would therefore be very welcome to WinMX but it will not be easy to implement.

Leech control needs to be intelligent and reliable, otherwise it will easily harm the network instead of benefiting it. A simple blocking mechanism based on the number of shared files or the amount of shared material in megabytes is not good as it will make it difficult for the newcomers to enter the network and easy for the leeches to fool the system by sharing trash files with filenames that are guaranteed to produce no search hits. This kind of system would also totally mistreat the users that share generously from e.g. their workplaces but can't do the same from their homes or vice versa.

Here's my quick sketch for an intelligent leech control system:

A person that you download succesfully from is clearly not a leech from your point of view. The more you download from somebody the more your p2p program should classify this person as a sharer and favour him/her with good bandwitdh and fast queuing should he/she want to get something from you. This would be a good first step that would encourage sharing even if it does not yet take into account the wider social dynamics of a p2p network.

The next step would be to share your sharer/leech information with the peers you trust. For example, an unknown person (say B) might download a lot from you (A) but as you would not find anything interesting in B's library you would lack first-hand experience of his/her sharing. However, a trusted contact of yours (say C) might have downloaded plenty from B and could 'testify' to you that B is a true sharer. You can easily imagine more complex scenarios where none of your direct contacts would have experience of a particular user but some of their second hand contacts would. In such a trust network you would naturally put most weight to your own experience, then to your directly trusted contacts etc. The exchange of evaluation information could be handled fully automatically by your p2p client and even a modest version of the sketched system would be a strong leech control tool when applied to bandwidth allocation and queue management. Leeches and newbies would still be able to enter the network and the control system would allow them to download even at good speeds when there were no merited sharers competing for the bandwidth. But especially with the most popular downloads the leeches would know that their non-sharing would cost them longer wait times and thinner bandwidth. Similarly the newbies would be encouraged to start sharing as quickly as possible as this would only enhance their access to the network and its content.

However - and here come the bad news - WinMX lacks a critical element that makes it impossible to build any trust networks or peer evaluation mechanisms on it. This missing element is permanent and verifiable peer identities. On WPN (and OpenNap for that matter) you cannot really know that a person with a specific nick is the same one you talked with a day or an hour ago. Your client should be able to do this kind of identity verification for all your trusted contacts automatically and peer-to-peer without any possibility of supernode tampering even if a supernode would act as a message broker between you two. As this would require rather deep architectural changes in WinMX and is probably not too relevant to their business plans we may have to wait for the next generation p2p programs to see something like this implemented in the public filesharing networks. It is certainly possible and has already been done in e.g. Groove which - being an enterprise-oriented p2p application - would not work without reliable peer identification.

Basing the treatment of peers in a p2p network on their identity and sharing history would also solve the dilemma for people accessing the network from several places with different sharing facilities. Should your workplace firewall block uploads from your office computer you could still prove your identity and benefit from the sharing you have done from your home computer. The benefits and prospects of permanent and verifiable peer identities are by no means limited to leech control but as this was just a brief sketch I will address the other issues on another occasion.

- tg

that was Magnificient TG but please if you would clarify one word for me...what is meant by WPN? (hehe sounds like a tv channel acronym or sumthin :P)

[TankGirl]

Originally posted by kento
what is meant by WPN? (hehe sounds like a tv channel acronym or sumthin :P)

WPN = WinMX Peer Network = WinMX's own serverless network.

- tg

[SA_Dave]

kento you might want to read this too. VLAIBB's Bubble2Bubble idea has alot to do with my idea of incorporating centralised chat into this "trust" system.

I did read that original thread before and I reread it just before I posted. The only problem with this is how to accomodate mobile users ie. people using a pc at work & one at home, whilst providing the greatest security. It makes sense for me for the key to be related to the processor. This would make it unique as no two computers will have the same fingerprint. However, if the key could be freely copied & used from one pc to the next, then it would either need another means of verification or it would be a rather weak measure. This would ultimately leave all the security of the system in the hands of the end-user. The end-user is the weakest link in any security system, no matter how secure, although I'd like to think that most p2p users have the requisite smarts!

Perhaps it would be best to have some sort of alternate identity or alias, but then how would this be "pooled" with any others that actually accrue "community credits"? For example, someone could be downloading at work & sharing from home via cable simultaneously. Apart from biometric identification methods, which aren't widespread amongst home pc users in general, there's very little I can think of offhand to allow for this. Maybe a private key uploaded to a password-protected ftp from work, assuming the "trust" account was established there, which could be decrypted at home with the relevant password. This could allow the user to temporarily bypass the cpu-fingerprinting mechanism and later generate a "new" key for the current processor, with the relevant details from the original identity embedded into this "alias" key. If a motherboard/cpu upgrade was performed, the program itself could theoretically do all of this automatically, assuming that the key wasn't lost in the process. Of course it might require a password lock or something similar.

I'm sure someone can think of something a little simpler! I tend to overcomplicate things.

[kento]

thanks TG for clarity once again on WPN and darn you, SA_Dave you have now "prolonged my gestation period (the amount of time its gonna take me to actually have all these good ideas "sink in" and be fully understandable) by another 15 days...lol

okay now one more thing...(i'm a "plain talker" so here it is)

Perhaps it would be best to have some sort of alternate identity or alias, but then how would this be "pooled" with any others that actually accrue "community credits"?

this left a bad taste in my mouth somehow because it reminded me of RATIO ftp sites and i friggin hate ratio FTP sites....and it would appear that I/you/me/we have been discussing turning a "globally anonymyous peer 2 peer FTP client" into just that:

nothing more than a "glorified" RATIO p2p client?

please someone say it isn't so...if no one else is experienced with ftp RATIO sites i will explain the horrors of them and how they have failed miserable for me and the times i have "lost credits" for files shared...if it happens so easily on these "ratio ftp sites" just imagine the utter failure it will experience in DECENTRALISED p2p without enforcements for "fair play"

at this point...i think it might be wise to rethink the concept and get away from "rewards and merits" otherwise you will have what is experienced with the WinMX client now which is:

Too much control like "too many cookes...spoiling the pot"[/b] when you have a client that allows EACH INDIVIDUAL to set their own perceived limits to bandwidth/queuing etcetera based on their MORAL ideals nothing inevitably ends of being shared due to the inconsistency and DISCRETION of the individual user.

Does anyone agree that winmx's only merit is its ability to connect to the OpenNap servers and nothing else?

I put this idea about before you now:

we don't need another WinMx -"Tina Turns Me On"

(aka "we don't need another hero" -Tina Turner)

kento

[TankGirl]

Originally posted by kento
please someone say it isn't so...if no one else is experienced with ftp RATIO sites i will explain the horrors of them and how they have failed miserable for me and the times i have "lost credits" for files shared...if it happens so easily on these "ratio ftp sites" just imagine the utter failure it will experience in DECENTRALISED p2p without enforcements for "fair play"

Kento, I think there are very few people who would like to have anything like ratio FTP recreated in p2p. Leech control is a good and much needed functionality but there are way more intelligent ways to implement it than ratio FTP's mechanical requirement to upload a certain amount of stuff to be able to download a certain amount of stuff. First, it deals only with 1-to-1 relations, missing the inherent power of p2p to match the needs and offerings of multiple people. Second, it does not take into account the quality and desirability of the content at all.

I won't go deeper into this here as this thread is about identity management. Just to sum it up, a reliable identity system is needed to have a reliable leech control system. There are numerous ways to proceed with leech control once you have reliable identities but that technology deserves a separate dedicated discussion.

- tg

[kento]

There are numerous ways to proceed with leech control once you have reliable identities but that technology deserves a separate dedicated discussion.

i agree, TG

still digesting this stuff, kento

[pod]

Yes, TankGirl, I see what you are getting at. But you are still describing what ultimately is a hot list. Basically, people who know you (in the cryptographic sense), know who you are when they see you, is what it boils down to. I never said THAT was difficult or impossible or impractical, and has been done for content in the form of FreeNet. There only two tricky things here: uniquely and permanently idenfifying users so there are no collisions, and doing it securely so you can't be impersonated, via some private/public key scheme. And second, actually finding users on the network in an efficient way. I think it just hasn't been done on a large scale yet because there was no demand for it (and I'd say, still isn't).

But expanding this idea to identities, where ANYONE (not just people who know you) can determine and verify your identity. I'm sure there is much research and development going on in that area.

[SA_Dave]

I think you misunderstood this system slightly kento. Basically tg wants to eliminate the problems with elitism, judgementalism and sheer arrogance that the current user-controlled systems generate. This includes Direct Connect, ftp ratio sites and similar clients or distribution channels. The proposed trust model would do this automatically, with the community's interests and needs being the supreme mandate. These keys, like any file, could be time-stamped for reference by the network. This would give a grace period to newbies, yet at the same time reward good peers.

When I used the term "community credit", I was referring to a trust or reliability status assigned by other peers. However, this designation wouldn't be totally in the user's hands, as this leads to abuse! This status would be based on performance, reliability and 'behaviour' towards other community members; all within the context of that peer's technical limitations. Things like Direct Connect's 20Gb share minimums are not feasible for all nodes, and a node shouldn't be discriminated against due to an inability to meet strict requirements.

Think of it in these terms : What if WinMX had a permanent hotlist? What if you could automatically determine the trustworthiness of a new contact? Say you've had a long-term online relationship with UserA, from whom you've downloaded reliable, high-quality & even rare files. This user therefore has a high trust rating by default, especially if these files could somehow be rated against some sort of integrated database (like a decentralised version of Bitzi or ShareReactor.) Obviously someone sharing many fakes, virii & the like would be given a rating of "doubt" or "suspicion". Of course this again raises many questions, as not everyone carefully checks everything & the fact that they are sharing anyway might indicate good intentions. Also not everone has the same criteria eg. some people put up with 128kbps mp3s & poorly-encoded videos, but others would consider these files to be of poor quality or even useless!

To continue the hypothetical analogy : UserA then introduces you to UserX, whom he gives a high trust rating for similar reasons. As you all share similar interests, you're more likely to aggregate in this fashion into themed sub-networks of the whole. It could greatly reduce search & general network traffic if peers could be intelligently & deeply linked in this manner. This would make transfers & searches more reliable, as the client would know exactly in which "virtual subnet" to find the content. I use the word "virtual" because this wouldn't in any way be centralised. In fact it would be the best way to maintain relative stability & maximum connectivity in a highly dynamic system. This doesn't mean you'd be limited to only one of these regions if you have broad tastes.

If you receive a new file, and both UserA & UnknownUser1 request it, you're more likely to send it first to the one you deem the most trustworthy based on your own personal experiences. UserA is a known sharer & contributer, therefore he/she would receive priority in the queue as this would most likely create more sources in the longterm for other users. So basically, think of what would happen if WinMX had prioritised queues! Known sharers would get the files first, and they'd distribute it to other known "trustees". The content would spread in the fastest way possible, to the fastest & most trustworthy nodes. It would then have a ripple & trickle-down effect. This method of distribution would be great for broadly allocating rare & in-demand content. Queuing would almost become a thing of the past. Just think how great it would be if partial-file sharing could also be accomodated!

In conclusion, there would only be discrimination against the most malicious peers. I personally believe that the effects of "leeching" are blown way out of proportion! The method of assigning trust levels to verified nodes is mostly just a way to accelerate & maximise content availability. It could also accrue other benefits such as reducing search traffic and eliminating many of the frustrations in current p2p-technologies. Most p2p-users are benign. The only people who'll lose out are those with destructive goals. The spoofing companies & trojan spreaders are included in this category.

I really think it is an admirable goal to strive for!

[kento]

you are right SA_Dave i did misunderstand "the intent" sorry TG...i think i am gonna be quiet for a while now and just read your ideas....ALL of your ideas (TG, SA_Dave, Alphabeater, Red and others) are wonderful...please keep them comming.

hushing up now,

-kento

[TankGirl]

Excellent posts, alphabeater and SA_Dave!

Originally posted by alphabeater
my favourite idea, as i've mentioned before, is to use the dns for this.

Dynamic DNS makes a good route via a public namespace to the fluctuating IP configuration of the p2p network. It should definitely be utilized as one of entry mechanisms when possible. Note that we don’t have to limit the use of DNS merely to mapping IP numbers of single peers. We can as well publish lists of active peers (with identity, IP and port data) on any DNS-mapped public space, your homepage being the natural candidate. Millions of people have FTP-accessible webspace at their disposal. With a simple FTP interface this public DNS-mapped webspace could be used to open an arbitrary number of public gateways to the network. You wouldn’t even have to reveal your own p2p identity while allowing your webspace to serve as a gateway. It would be enough to list a random selection of active and willing entry point peers.

Originally posted by SA_Dave
Secondly, what about all the situations where people wouldn't want to use this feature? Reasons for this are that you want to share different collections under different logins, you share a computer with other family members whom you do not want to inconvenience by binding their identitiy to that of the machine or simply that you are antisocial & do not want to participate (in this case it could be to the benefit of the community if you share virii & fakes or not if you are just a "fly on the wall".) I'm sure that many users fall into this "stealth" category, and they like it that way.

The solution here is to bind the identities to user profiles rather than to the machine the client is running on. If each user profile has its own independent shares, hotlists etc. there is no reason why family members could not run simultaneously their own instances of the client on the same computer (perhaps using different ports). You yourself might want to use different identities to access different communities (movies, music etc), each identity having its own specific shares and social history.

Originally posted by SA_Dave
Third, you are assuming that the user is very savvy. Would they really backup all their keys to a floppy, as tg suggested in another thread? Formats seem to be an almost communal experience nowadays.

If you have a HD failure and have no backups, losing your p2p identity is probably the least of your worries. There are people who trust their luck and people who make backups. It usually takes a major HD crash to convert somebody from a truster to a backupper...

Originally posted by SA_Dave
What's to prevent malicious users from remotely deleting keys or formatting drives, installing trojans, backdoors and the like or even using a compromised "trusted" system to cause major damage to communities, friendships, trusted states and even data?

I think this is a general security issue that applies to all computing and networking. If a malicious outsider owns your box, there is not much to do but to clean it up and protect yourself better next time. The only countermeasure that comes to mind is to store all identity data as encrypted so that possible intruders cannot use it without knowing the correct password. But there is no real security on a compromised computer. The hacker might be able to monitor all your actions, including the keystrokes you type when entering your password.

- tg

[Mowzer]

"The solution here is to bind the identities to user profiles rather than to the machine the client is running on. If each user profile has its own independent shares, hotlists etc. there is no reason why family members could not run simultaneously their own instances of the client on the same computer (perhaps using different ports). You yourself might want to use different identities to access different communities (movies, music etc), each identity having its own specific shares and social history."

Good posts tankgirl. I always had the same kinda thought regarding users of p2p apps and identities. Except the layer of any kinda actual cleint is one step removed in my vision.

[SA_Dave]

Okay TankGirl, I understand this concept of assigning multiple "aliases" to a trusted node , possibly with different ratings in the case of different users. I also understand that this verified identity wouldn't discriminate against those who aren't really interested in community, but who contribute anyway by default. This would allow for profile-switching & even the use of multiple pcs by a single trusted user. However, as I posted above, this presents a new challenge as far as verification is concerned. How do you absolutely ensure that someone is who they say they are, without using unique biometric patterns such as fingerprints, retina & facial profiling, voice-printing & genetic markers?

As most people are probably aware, sophisticated biometrics systems cannot be bypassed by cutting off someone's fingers to gain access to a secured facility, as is commonly depicted in Hollywood movies! I assumed that using a cpu fingerprint or similar would be the most reliable method of tracking identity. I guess what I'm asking you is : how would you translate this into practical computer terms? I don't believe that encryption is enough & passwords would probably be a weak point, as it relies on the end-user. Your proposed "hotlist" idea isn't very all-encompassing either and a zone of absolute trust wouldn't work in these conditions. I think it should be implemented across the board or not at all! At least, that's what I understood by your references to Thawte, Verisign etc.

Perhaps it's best to refer to your concept more as a "performance review", as this system would seem to apply more to content-distribution than to chatting & searching! The score is influenced by characteristics such as reliability, performance, stability and behaviour under 'real-world' conditions; which could be positively influenced if that particular node or user had a "dynamically permanent" cyber-address. The actual identity of the peer seems irrelevant if you look at it from this perspective.

These problems can be solved once more intelligently-structured networks arise Phoenix-like from the ashes of the current crop. The frustrations with the current decentralised topologies could be eliminated with a little foresight. The increases in bandwidth should help, but more efficient protocols would also be benificial. I believe that clients which have integrated community-friendly tools and features are the best solution, now & for the forseeable future. It's no good tacking a "peer rating" system onto an otherwise outdated or useless client!

You should also consider that many people might balk at this kind of profiling occurring on p2p networks. What with cookies, spyware/malware, ISP monitoring, the government passing anti-terrorism laws which give them free reign, Microsoft's .NET and similar scandals, notwithstanding the RIAA, MPAA & their spoofing pals, wouldn't people be a bit suspicious & might this not be seen to be in the RIAA's and advertisers' best interests? The internet and P2P are so popular because they give you comparative freedom & anonymity. Most people don't want to live in episodes of the X-Files for the duration of their natural lives & decentralised p2p networks would be useless if someone managed to introduce an oppressive, invasive or uncomfortable atmosphere. If mere suggestions can scare people away from trying things out in the first place, imagine the possible effect this could have on p2p populations! Of course, this is assuming that the news wouldn't be censored by the mass-media or that another BDE/altnet scenaria wouldn't occur (which didn't affect official Kazaa downloads in any negative way whatsoever as far as I could tell!)

Maybe you're sick of my rambling by now TankGirl, but I'd like to know how you envision & plan to implement your proposed sytem, now & in the future. Perhaps a point-by-point rundown of the features, with a brief explanation of why you deem each one necessary or at least ideal for the future of p2p-networking "according to TankGirl". It would help me and others understand exactly why it is you're proposing this & whether it is possible to implement another, less complicated solution.

I understand the what?, where? and why?, it's just the how? that needs a bit of clarification. If it's not too much trouble O Great Tanked Dungeon Mistress!

[kento]

SA_Dave maybe "skidmonk" or dkchip has the answer...useing the compid to do this (although it won't allow for user profiles as each comp id is unique to and individual computer)

hey does anyone know how dietK derives this "comp id"? is it merely the cpu id number that i've heard about on pIII's or is this something different?

how is it calculated? could be interesting and useful 2 know.

TA, kento

[TankGirl]

Originally posted by SA_Dave
Okay TankGirl, I understand this concept of assigning multiple "aliases" to a trusted node , possibly with different ratings in the case of different users. I also understand that this verified identity wouldn't discriminate against those who aren't really interested in community, but who contribute anyway by default. This would allow for profile-switching & even the use of multiple pcs by a single trusted user.

Yep, that is so.

Originally posted by SA_Dave
However, as I posted above, this presents a new challenge as far as verification is concerned. How do you absolutely ensure that someone is who they say they are, without using unique biometric patterns such as fingerprints, retina & facial profiling, voice-printing & genetic markers?

The p2p identities discussed here have in themselves nothing to do with real world identities, nor should they. They are just to make sure that a peer we suppose to be A really is A. We want the best possible real world privacy together with a lasting, reliable online identity (or identity set) of our choice. It will be our personal choice whether we pass some personal real world information to our online chat companions or not. Reliable p2p identities (together with protected communications) do not weaken our real world privacy but strengthen it. They prevent impostors and malicious third parties from getting access to confidential data and from eavesdropping communications with trusted peers.

Originally posted by SA_Dave
Perhaps it's best to refer to your concept more as a "performance review", as this system would seem to apply more to content-distribution than to chatting & searching! The score is influenced by characteristics such as reliability, performance, stability and behaviour under 'real-world' conditions; which could be positively influenced if that particular node or user had a "dynamically permanent" cyber-address. The actual identity of the peer seems irrelevant if you look at it from this perspective.

Right. Actual (real world) identity is irrelevant and has nothing to with peer identity. But there’s more to it than the content only.

Purely objective performance measures and transfer statistics are indeed useful in optimising the network for content distribution. But similarly you can measure search success rates (searches leading to consequent downloads) and use them to optimise the network for peer proximity so that similarly minded peers migrate topologically close to each other (under the same supernodes). This already introduces the element of social adhesion to the network and can be handled as automatically as the distribution optimisation.

With tools like chat and browsing things get much more personal, and there will be social life on the network. The same permanent identities that see gracefully at the technical level that the performance statistics will get assigned to correct peers will see also at the social level that chat logs and privileged shares get assigned to correct peers.

Originally posted by SA_Dave
These problems can be solved once more intelligently-structured networks arise Phoenix-like from the ashes of the current crop. The frustrations with the current decentralised topologies could be eliminated with a little foresight. The increases in bandwidth should help, but more efficient protocols would also be benificial. I believe that clients which have integrated community-friendly tools and features are the best solution, now & for the forseeable future. It's no good tacking a "peer rating" system onto an otherwise outdated or useless client!

Ditto. You have got it.

- tg

[SA_Dave]

That answers all of my questions!

It's obvious to me now that I really was overcomplicating the issue! It would be interesting to see how this could actually be implemented. I think that there should be some sort of middle-ground between automation & user-feedback/intervention, without sacrificing ease of use. Clearly the current user-controlled systems like DC (and even the WinMX trading phenomenon) are somewhat restrictive & frustrating. However, if everything were left up to a central authority, it could somehow be exploited or manipulated and make the network as vulnerable as if it were purely centralised!

Thanks again TankGirl!

[multi]

a good read everyone.....
so the way i see the key thing...
a user makes an account
chooses to become anonymous or to have an identity
(would the anonymous user have a key?, me guessing so..)
the identidy key would store
nick ,avatar,forums,contact,credits..ect

on searches could the identified users
have the option to browse identified uses
trusted users or anonymous users or all users?

but the anonymous users would only be able to browse each other..

if persistent malicious users keep creating identities to try to destabilise the regular identities and super regular identities
some sort of moderation may be needed
as in a way to kick that user from your identiy keys and not recieve a key from that ip for x amount of days?
i gues what im suggestion is maybe some sort of identity spamming...

would there be some thing like a requester
that says "identityA is sending you an encrypted key accept or decline?"
or thru an interaction say on a board
maybe ,could one be sent via pm?
some how these keys must not be able to be messed about with debug or some sort of decompiling activity;]

[donaldducko]

Originally posted by TankGirl
Decentralization means that there will be no outside authority – VeriSign, MicroSoft or Napster - to keep books of who is who in the network. No trusted third party will be there to guarantee that peers really are really whom they claim to be. We have to know it and remember it ourselves. To do that we need unique, permanent and verifiable peer identities. Nicks (even with random additions such as we have seen in WinMX's WPN) are unsuitable for this as peers can pick and change their nicks freely, and there will be no outside authority to prevent nick collisions.

Decentralization does not necessarily mean that there cannot be any authority at all, even if not an "outside" one.
Decentralization, to me, means that the functions normally assumed by one central server, or several ones, should simply be taken over by *every* peer in the network.
This means that these functions will have to be inbuilt in the p2p software itself so that it is actually its *own* central server.
Problems like those arising from nicks, queueing, and so on would be treated by the very software you are using on your computer. That, to me, is true "decentralization".
Just eliminating the central server(s) does not make a decentralized network ; it results in an *uncontrolled* network, which is different.