summaryrefslogtreecommitdiff
path: root/doc/todo
diff options
context:
space:
mode:
authorGravatar http://lj.rossia.org/users/imz/ <http://lj.rossia.org/users/imz/@web>2012-09-25 20:39:39 +0000
committerGravatar admin <admin@branchable.com>2012-09-25 20:39:39 +0000
commita005ff618b5e12d388b4ffe0e169e8c5ac101b64 (patch)
treedc9c26cde9c4b5362c8a02ae4de39b5d0c9e75e1 /doc/todo
parent41051a237e6bc39948ee421e36cc28d207d4bfb6 (diff)
A scenario of how this would be useful.
Diffstat (limited to 'doc/todo')
-rw-r--r--doc/todo/wishlist:_backends_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn4
1 files changed, 4 insertions, 0 deletions
diff --git a/doc/todo/wishlist:_backends_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn b/doc/todo/wishlist:_backends_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn
index c568bea5e..bfb35c47c 100644
--- a/doc/todo/wishlist:_backends_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn
+++ b/doc/todo/wishlist:_backends_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn
@@ -6,4 +6,8 @@ Before dropping a file locally, the BitTorrent client should check that all part
Of course, there is no guarantee assumed that the content won't disappear from the peer network in future: they act more like a cache rather than an archive on whose lifespan you decide. (I'm only not sure about gnunet now: whether there is a rule of dropping unused content from it, like in freenet.)
+So, a copy in peer networks shouldn't be counted on by git-annex as much as a copy on a storage you control: probably, by efault, it shouldn't let you delete the local copy if there is a copy in a peer network unless you saved it somewhere else.
+
+(Think of such a scenario: I could save some of my public large data on external disks/DVDs and keep them at home, and also put them onto peer networks with the same nterface of git-annex which I would be used to; I would also use the git-annex interface to check from time to time that the content is still present, i.e. "cached", on the peer networks. Whenever I'm away from home, and unexpectedly need to show this content to someone, or have a look at it for some reason, I could get it from the peer network "cache".)
+
Also networks like namecoin (derived from bitcoin) can be used as a key-value store. Despite being a peer network, a system like namecoin actually could offer the publisher more control over the lifespan of the content: he should be able to offer "financial" reward for others processing his key-value data. (But I'm not sure namecoin is designed reasonably for this reward system to work actually; but there might be appearing other similar systems.)