Sidetree implementations are susceptible to late publishing attacks, which traditionally isn't a big issue if the only vector is changing the user's own keys. But here, having an old, anchored, and unpublished fork acts as a publish undo button.
Is there a way for the ceramic client to save old forks, and can a new client request full fork history from the network? Can we build some other transparent index allowing deterministic resolution in these cases?
Sidetree implementations are susceptible to late publishing attacks, which traditionally isn't a big issue if the only vector is changing the user's own keys. But here, having an old, anchored, and unpublished fork acts as a publish undo button.
Is there a way for the ceramic client to save old forks, and can a new client request full fork history from the network? Can we build some other transparent index allowing deterministic resolution in these cases?