I don't know how this would have occurred but wonder that in future the majority fraction could be broadcasting their checkpoints regularly in a way that others could note those in the checkpoints.json when there is a fork. Perhaps that could even be automatically fixing such forks?

I haven't got a GUI running atm to see if that is holding to the major branch and could give the checkpoint for us to adopt. I have asked a couple of times what the procedure is for fixing a fork but haven't seen a clear answer. I guess we wait for devs to confirm a checkpoint or a fix.

Also, it's not helpful that init's are not broadcasting their version.. perhaps they've upgraded to v0.7.0??

agreed, init delegates should broadcast their version, at least for us to know whether something is off with them or if the fork is a "natural" one... It's not related to 0.7.0 as this is a new BitShares version, unrelated to DevShares. The current version of DevShares about to be released (previously 0.7.0) will be renamed 0.8.0 (The current bts tag should have been 0.6.4, but as it contained a hardfork, the version number has been bumped)

I am on a 26% participation fork (it was at 40% without the init delegates), does it mean everybody is switching to the init delegates fork now? I thougt we would insist to stay there... have I missed something? Should I try to connect to another fork? what is your participation guys?

I don't know if it's possible to see the breakdown of the forking and the %'s each fraction holds. I've assumed for most of these that it's one major, one minor but at 29% there's a risk of being on the wrong one, even if as vikram suggested the major init fork is wrong and the next biggest is true. I guess at 29% I'm on the best one now.

I'm not quite expert at this yet but perhaps you can check or force your block hash to be the same as mine.

I would expect that one way to jump chains is to put that hash into the checkpoint.json and start again with --rebuild-index but that could become complicated if you have more than one correction to the normal in that.. but I might be wrong if that blockchain_get_blockhash is giving the init major fork hash and not the hash for the fork I'm on..??.. if it only replies with major fork detail, then I guess that change will not have any effect until the fork is fixed.