Hit counter; bandwidth usage payments; storage grandmastering

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 his N -= 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

From @raptortech-js on Tue Dec 06 2016 23:20:03 GMT+0000 (UTC)

Filecoin is out-of-scope here, this repository is about IPFS. In response to you first question, if your use case is aggressively anti-cache, then I don’t know what you aim to gain by using IPFS as opposed to HTTP.