At the moment, chain-based ranking history would just add additional complexity with a relatively small benefit.
If all they do is broadcast records as custom_json, they'd still need to keep a copy of those records in their own database. The small benefit would be that the records could be reconstructed from chain data, if need be.
A better solution would be to have a smart contract running in Steem Engine, so that the data could be queried by API, thereby reducing the need to have a copy of the records. Unfortunately, Steem Engine doesn't allow arbitrary contracts yet.
I was thinking about the custom_json part yes.
You could make it a linked list so you could even query it from the chain quickly (each new posted record references the block and tx id of the last record).
That wouldn't require for them to store it in a DB and wouldn't require smart contracts.
That's a good point. And actually, all you need is the referenced
block_numand you can infer that it contains at least one related transaction. You would avoid storing thetrx_idto save oncustom_jsonop size, which is pretty cramped right now.I guess the only problem with that is if you write records asynchronously with more than one thread. Even if there's only one thread, if that thread crashes after successfully broadcasting a valid record, but before storing the current state, that valid record will become an orphan in the list.
Yeah, the only problem is parallelism. You'd have to enforce serialization on the server which does the writing.
You don't even have to use the tx_id, you could use the tx number in the block.