Algorithmically feasible: blocknotify.py checks the notified block's prevhash against the hash of the last-recorded block in the graph. If they differ, it implies that a re-org has occurred and blocknotify flips into re-org mode, iterating down from currentheight, checking the recorded nexthash value against the node's nexthash value and, until they match, removing the orphaned blocks from the graph and then finally, when the nexthashes match, catching up from there to current.
Looks like a good idea! Have you already wrote some code for it? Otherwise, I can try to implement it myself - also as a coding exercise for me.
feeding through to Jena's TDB cli.
Yes, that's maybe the best way for the initial block sync. I missed it initially (and so my local node took weeks to catchup), but then for the public node I recurred to this technique.
The unit test inclusion is just my perverted interpretation of TDD
I had suspected something like that - that's still far away for a noob like me. Well, I'll for now will to continue to use my "blocknotify-cli" fork without unittest. I haven't really changed the code, only reorganized it a bit, so loops and command line arguments are possible.
BTW: Are you OK with the name "Slimweb" or do you have a better proposal? Your opinion would be important, as you had the web2web idea initially.
That's what Kilari told me, about eg. putting wikipedia on Slimweb:
I just found a way to put the entire Wikipedia on Slimweb (at least almost all of it) in such a way that no one has to seed the entire wikipedia dump.
It works by having a mirror of Wikipedia where it is designed such that every person browsing the page in the normal way also seeds the article he/she is reading.
How would the versions of articles be stored on the blockchain? If every article had a Slimcoin address for the torrent hash, that would lead to significant blockchain bloat.
I had already thought a bit about that problem - one could develop a kind of standard for multi-page torrent hashes. In that model, there is only one Slimcoin address used for the whole site (e.g. Wikipedia) and the hash leads to a "start page" that contains the updated hashes to the single articles. But even then, a million-subpage-site like Wikipedia would be a challenge and a "sub-structure" would be needed. If you have found a solution for that issue, that would be a huge advance ...
There is already a similar project that uses
IPFS to seed Wikipedia - maybe one can learn from it, although they use a whole snapshot. IPFS is a much more complex system than web2web, but as nearly all other similar projects, it has the disadvantage that the end user has to user a "non-standard" software to access it, so a web2web version would have advantages.