Opps, sorry I mentioned this idea a few months back and someone gave me the idea "light insertions" = "inverse passive requests". Sorry.
> > One solution that was proposed to do this was to > do > > "light insertions" or "inverse passive requests". > The > > idea is to make a new insertion message which says > the > > sender has a trail to key X. This message > follows > > the regular routing path for a normal HTL. Every > node > > on the way stores the key and from which node it > got > > the message. When a request comes along it has a > good > > chance of finding a node which knows about the > trail. > > Such a node forwards the request back along the > trail > > to your "read only node". > > Unless I am mistaking, this would completely destroy > anonymity. If there is a > trail from a file to the inserting node, then a file > can be conclusively > associated with the node that is believed to have > inserted it, and anonymity > is nullified. Well, would do this no more than the "passive requests". They seem to leave a trail going back to the requestor. You still have plausable deniablity, and they still have to gain access to serveral nodes on the trail to follow it to you. It's just a question of whose annoymity is being threatened more. Nodes can remove the trail of one of these "passive insertions" once they have the data in cache themselves to protect annoymity, just like nodes remove the trail of a normal request once they've handled it. > This would not be request based. It would be a > polled solution. You would > insert a request file saying "please upload this". > The client application > polls for such requests and inserts the files. It's > more like automated mail > bots than anything else. It is at best a near-line > protocol. Seems like it would work, but it'd be a little slow to start since the data provider has to poll for your request first. If his poll sits around for a while, and can respond later you've got about the same solution I was suggesting. > > 3) Somebody may have some neat ideas of how to > link > > this design into a design to do streaming > broadcasts > > or another messaging system like NIM. > > NIM and broadcasts already fit perfectly with the > design of Freenet. If an > entity wants to help Freenet, they can run a full > relay node. If they don't > want to help, they can just insert the data, hope > for the best, and re-insert > frequently using a transient node. I don't see the > possible benefits to > Freenet of having read-only nodes. It is pointless > at best and > counter-productive at worst. It doesn't fit with the > network topology and > doesn't fit with the design goals. Nope, I'm not try to change anybody's design or goals, just though I'd spit an idea out. Once freenet's routing does work there may be serveral "neat" things that can be done with it. The whole point is that two like messages can reach each other at some point in the network, interact and maybe return data. > > It may also help with rarer data which gets > inserted > > all the time but rarely retrieved before it > expires. > > I don't think the capacity of the network is > anywhere near it's limits. If the > storage space is running out, then then correct > solution is to add more > space/nodes or see if there are further > optimizations to be made to routing, > not breaking the network design. Please consider this, the freenet has an effective capacity that may be orders of magnitude smaller than the sum of all datastores. 1) there will be good redundancy 2) some data may not be found, or not by all At any rate C(effictive capcity) is a finite resource, we share. Right now I believe the only limit on how much of this commons I use is my bandwidth, not the space I donate to the network. Hash cache may help some with this. If I have 10TB of classic movies (boy I wish), I could never hope to insert them all into the system. If they're very rare and "unpopular" they may die off because the one someone's looking for isn't the one I just uploaded. My idea let's someone provide large unpopular data to the network, while only inserting these "advertisements" and the data as it is requested. I send out say 10,000 "advertisements" and upload as needed. This is much less taxing on me and the system in general. For the most part annoymity is there, except that I know somewhere out there someone is downloading. If many people download the file will probably be cached by others and everything will be handled normally. __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Logos und Klingelt�ne f�rs Handy bei http://sms.yahoo.de _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
