From @mcast on Thu Sep 08 2016 21:58:43 GMT+0000 (UTC)
I think there’s a common thread in here, possibly about how a GET request ideally has no side-effects; a pure function of the input request.
- I wondered whether it’s possible to implement the (very 1990s idea of) a hit counter on a page or other data item.
- Of course if it’s fetched from a cached copy, then “no” because the “server” (who has it pinned) doesn’t see the second fetch.
- It’s like HTTP with caching. No surprise yet, except that in http we usually don’t share caches much.
- If small data is marked with “this is a tiny backwater, pretty-please don’t serve it from your cache” we get back to self-hosting HTTP semantics, where reading the
access.log(cf. #122) still means something. - Presumably also relevant to advertisers? Will they serve custom one-per-viewer ad images to get round the cache?
- I wondered how a filecoin thing would give payment for transfers (to third parties). #122 is the wrong side of the transfer.
- Then I wondered how, when there are distributed copies, filecoin can even pay (https://github.com/ipfs/faq/issues/93#issuecomment-178945882) for the (n+1)th copy in the face of the grandmaster problem.
- You couldn’t use response time.
Suppose the honest disk needs to spin up, or a media robot is fetching the BD-R?
Meanwhile the cheat is fetching a copy from elsewhere, to hide hisN -= 1. - Encrypt each paid copy with a different key? Then you can’t use the distributed copies as webserver.
Copied from original issue: https://github.com/ipfs/faq/issues/177
- You couldn’t use response time.