Hit counter; bandwidth usage payments; storage grandmastering

[mcast]

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. Log of blocks sent to other peers? #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). Log of blocks sent to other peers? #122 is the wrong side of the transfer.
• Then I wondered how, when there are distributed copies, filecoin can even pay (How permanent is data stored on IPFS? #93 (comment)) 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.

[jackie-scholl]

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.

[flyingzumwalt]

This issue was moved to https://discuss.ipfs.io/t/hit-counter-bandwidth-usage-payments-storage-grandmastering/433