As such, I ended up at a party last night, somewhat by accident, and it turned out to be quite an interesting experience indeed, immersion in the 20-something culture of alt-culture - see, this is a sign of my age, perhaps, I call them kids. Fact is they are all very young.
But I bumped into someone who immediately recognised the plausibility of my Impulse and Scavenger coils, and as a kid he'd tried to create an electromagnetic projectile launcher, so it was something near to his heart when I talked about the electromagnetic impeller concept I have (like a coil gun, but it pushes the projectile the same way as a bowstring launches an arrow).
So I made one definite new connection from it, and I got to spend some time away from the computer, I had a good dance for some of the evening, and now I am home, rested and recovered, I have the answer to a puzzle that has been on my mind since at least may 2013.
What has been on my mind is this:
How do you compensate ad-hoc content hosts and other intermediaries for such as database services for their service to the network?
First of all I want to clarify that what I realised last night is that a Bittorrent Seed and a Steem RPC (for example) server, both produce replicated data that was originated elsewhere, and requested by the user. Whether it's static or dynamic content is irrelevant, because database queries can have a high processing load with low data in the reply, or a low processing load and a high quantity of data in the reply.
On average it probably balances out to some kind of statistical normal. So we can ignore the compute part of the service and just measure the traffic. Really the same even applies with providing pure computation - such as a cloud provider. The differential between processing cost and data output is isotropic, it can be low cost high load, or high cost low load (cost of data, load of processing).
So, in order to have the concept registered somewhere so that nobody can claim that they created this scheme and try to come at me with a patent lawsuit (or Dawn) - assuming they can find a way to claim jurisdiction or build a partition in the network on national jurisdiction basis, I am explaining it here, where all the witnesses have faithfully recorded that the controller of my account key produced this content first.
Structure of the data of a Proof of Service receipt
First, we have the content creator's product. This can be a string of text, a media file, which includes compound documents, and the generated result of a query on a database that was created by a content creator, and processed by an intermediary who delivers the result to the end user.
For static content like text or media or compound documents (and this includes source code and binary code) it is simple enough to record the unique hash identifier. For a database, this hash is the hash of the entire database at the time the query is processed, which may not be precisely the same in its structure, but it will be the same in that it uniquely identifies the source. This probably will be then the fingerprint of the database at the time it was processed.
The content creator signs the identifier. As I mentioned, this is a little more complex for 'dynamic content', I will not cover that point right at this moment, because this covers everything from tweets, blog posts, compound documents with associated content (this can be referred to by documents using a URL scheme also) and can also include source code and binaries generated from them.
The service provider (intermediary) then adds the quantity of bytes of the data to this chain, and then signs it.
The user signs this indicating that the data was received as described, and then broadcasts this receipt to the Validators of the network, who calculate how to divvy up the pool of virtual tokens to be paid out at any given time, based on the existence of these receipts for service.
The Validators then generate counts of the number of requests for content, which is multiplied by the amount of data, to generate a weighting that can be compared between all pending payout requests.
They create an account which shows how many bytes of data was transmitted by the intermediary, and all intermediaries output is then summed and the proportion of tokens to issue them is based on the percentage of due payments out of the pool at the time of calculating it.
Then finally, the validators keep a record of the sequence of different user's requests for this content, which is then assigned a weight that decays the greater the number of requests made by users for a particular content source.
I'm not sure if there is a way to commute these three values so that the proportioning is dynamic, it may be simpler to simply split the pool into 3, which is creator, deliverer and curator reward pools. Any dynamic scheme would add quite a significant load to how to calculate the relative change of assignment to pools.
Since it seems to be a workable scheme in Steem, that you divide the total pool of new tokens up by Witnesses, Creators and Curators, in a fixed ratio, this is simply extending this to include the content deliverer's contribution.
This eliminates any need to get users to vote on stuff, because they can vote by what they download, and the amount from a particular creator creates a ranking.
However
There is nothing stopping anyone from creating any combination of consumer, deliverer and producer, and pushing this across a private network. How do we eliminate this?
Well, I am working on this still, but I know there is a solution, expect it in the near future...
update
The solution I think might be key to this is in requiring intermediaries, proxies. The proxy between deliverer and consumer has to be isolated in their network location from the deliverer and consumer, proving that the traffic went across a public network. There is more elements to add yet, I think, but this is the next part to add to prevent the creation of sybil creator/deliverer/consumers from simply using internal routing.
Follow the Money
The graph of associations between accounts, especially on the ledger, builds a profile of the associations between nodes that we can use to weight the proportion of rewards to be issued from a proof of service receipt. If the proxy is close to the consumer, OR deliverer, the lowest graph distance between them becomes the coefficient that generates the value that is then summed of all pending claims.
The curation reward from requesting the content only goes to the first query from the same data source (payload fingerprint, and the query fingerprint) Anytime these fingerprints reappear, only the first one can be counted. This is the same as 'you can only vote once on content'.
As @frankbacon likes to repeat, the number 5 is key. In this scheme we have Creator, Deliverer, Proxy, Consumer and Validator, the magick 5.
This scheme should enable the monetisation of each part of the process in a way that cannot be gamed by sybil puppets playing multiple roles in a chain, which we cannot prove, but the cost goes up as they have to cover the bandwidth costs, the processing to generate the content fingerprints, and while Sybils can take 3 positions, they can't take 4. The 4th, the proxy/intermediary, reduces the weighting according to the number of hops between the deliverer and the consumer over time. This would be represented in a database as a frequency value that changes when there is a convergence of transactions closer to the proxy between either the consumer OR the deliverer.