 decentral Update and Distribution System
I just had an idea how LimeWire updates could be distributed more easily for Users and far less resource hungry for developers (and with which Upgrading would also become more natural for Users).
It is to distribute New major Versions just like your distribute QRP-Tables. For this, LimeWire needs to have a signature-checking mechanism integrated, so only trusted content (the program-updates) are being sent actively through the network.
I got to that Idea, because a senator in california wants to make distributing p2p-software without a way to censor it illegal. So I thought: Do the programmers need to be exposed?
Any program which gets a new Version automatically begins distributing it to its peers, but it also contacts random nodes from the HostCatcher, so that determining a first source gets pretty hard (most files travel the standard Query-Tree, but there are at all times other trees springing to life).
It would need have more than one key, so that multiple key together, maybe three or so, can revoke another key (which the owner of that key should also be able to do) and at the same time multiple keys together should be able to introduce a new key.
But I don't want to go to deep into details.
This would make the network somewhat more homogenous (updating gets far easier) and would completely avoid reliance on any central source, because even updates would be done via a decentralized structure.
That way even shutting down the LimeWire website couldn't disrupt the developement of LimeWire, and there would be far less incentive for the music- and film-industry (RIAA and MPAA) to try it.
As a far fetched thought it might even be possible to build a CVS-System (maybe relying on patches) on top of Gnutella, so that even the developement would become decentral (and mostly unstoppable, because files are being pssed through the network and also randomly, so you can only find the first source with very much effort, and thhen you can't be certain it really is the first source. |