|
Peer to Peer The 3rd millenium technology! |
|
Thread Tools | Search this Thread | Display Modes |
06-09-02, 03:55 PM | #21 |
Registered User
Join Date: Jul 2002
Location: uk
Posts: 97
|
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. |
06-09-02, 05:45 PM | #22 |
Apprentice Napsterite
Join Date: Aug 2002
Location: Germany
Posts: 88
|
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 :-) |
06-09-02, 08:04 PM | #23 |
Guardian of the Maturation Chamber
Join Date: May 2002
Location: Unimatrix Zero, Area 25
Posts: 462
|
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! |
06-09-02, 08:56 PM | #24 | |
Apprentice Napsterite
Join Date: Aug 2002
Location: Germany
Posts: 88
|
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 Quote:
|
|
06-09-02, 09:55 PM | #25 | |
Madame Comrade
Join Date: May 2000
Location: Area 25
Posts: 5,587
|
Quote:
- tg |
|
06-09-02, 10:53 PM | #26 |
Guardian of the Maturation Chamber
Join Date: May 2002
Location: Unimatrix Zero, Area 25
Posts: 462
|
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. |
07-09-02, 06:52 AM | #27 | |
Apprentice Napsterite
Join Date: Aug 2002
Location: Germany
Posts: 88
|
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) Quote:
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 |
|
07-09-02, 07:22 AM | #28 | |
Madame Comrade
Join Date: May 2000
Location: Area 25
Posts: 5,587
|
Quote:
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 |
|
07-09-02, 11:07 AM | #29 | |
Apprentice Napsterite
Join Date: Aug 2002
Location: Germany
Posts: 88
|
Quote:
still digesting this stuff, kento |
|
07-09-02, 01:58 PM | #30 |
Bumbling idiot
Join Date: Feb 2002
Location: Vancouver, CA
Posts: 787
|
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. |
07-09-02, 05:26 PM | #31 |
Guardian of the Maturation Chamber
Join Date: May 2002
Location: Unimatrix Zero, Area 25
Posts: 462
|
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! |
07-09-02, 08:05 PM | #32 |
Apprentice Napsterite
Join Date: Aug 2002
Location: Germany
Posts: 88
|
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 |
07-09-02, 08:59 PM | #33 | ||||
Madame Comrade
Join Date: May 2000
Location: Area 25
Posts: 5,587
|
Excellent posts, alphabeater and SA_Dave!
Quote:
Quote:
Quote:
Quote:
- tg |
||||
07-09-02, 09:51 PM | #34 |
'
Join Date: Jan 2002
Posts: 209
|
"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. |
08-09-02, 02:38 AM | #35 |
Guardian of the Maturation Chamber
Join Date: May 2002
Location: Unimatrix Zero, Area 25
Posts: 462
|
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! |
08-09-02, 05:13 AM | #36 |
Apprentice Napsterite
Join Date: Aug 2002
Location: Germany
Posts: 88
|
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 |
08-09-02, 05:37 PM | #37 | ||||
Madame Comrade
Join Date: May 2000
Location: Area 25
Posts: 5,587
|
Quote:
Quote:
Quote:
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. Quote:
- tg |
||||
08-09-02, 10:07 PM | #38 |
Guardian of the Maturation Chamber
Join Date: May 2002
Location: Unimatrix Zero, Area 25
Posts: 462
|
Thanks TG!
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! Last edited by SA_Dave : 08-09-02 at 10:35 PM. |
12-09-02, 06:22 AM | #39 |
Thanks for being with arse
Join Date: Jan 2002
Location: The other side of the world
Posts: 10,343
|
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;] |
12-09-02, 01:06 PM | #40 | |
Registered User
Join Date: Sep 2002
Posts: 4
|
Re: How would you manage identities in decentralized p2p?
Quote:
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. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|