Migration mechanism

[boreq]

The data stored by go-ssb seems to be stored in a different format and is not loaded correctly.

ts="2022-02-22 17:13:00.7892220 (UTC)" level=info msg="repo already updated" v=1
ts="2022-02-22 17:13:00.7952160 (UTC)" level=warn index=timestamps event="index stopped" err="error decoding data for seq(0) (ofst:0): multiMessage: legacy decoding failed: cbor decode error [pos 3]: invalid number loading uint64, with descriptor: 88 (bytes)"
ts="2022-02-22 17:13:00.8869470 (UTC)" level=warn index=get event="index stopped" err="error decoding data for seq(0) (ofst:0): multiMessage: legacy decoding failed: cbor decode error [pos 3]: invalid number loading uint64, with descriptor: 88 (bytes)"
ts="2022-02-22 17:13:00.8872080 (UTC)" level=warn index=combined event="index stopped" err="error decoding data for seq(0) (ofst:0): multiMessage: legacy decoding failed: cbor decode error [pos 3]: invalid number loading uint64, with descriptor: 88 (bytes)"
2022/02/22 17:13:00 adverstiser using local address :8008
ts="2022-02-22 17:13:03.8900090 (UTC)" level=debug event=update-replicate feed-want-count=0 hops=1 took=1.630375ms

The data storage format appears to have changed. There appears to be no automatic data migration triggered when reading the data so it is possible that it needs to be triggered manually or the migration code has to be written from scratch.

See ssbc/go-ssb#142.

[boreq]

The proposed solution is to simply drop the go-ssb storage as well as sqlite and use the fact that we stored the sequence number for the user's main feed in the keychain. This would allow us to wait for the messages to resync before allowing the user to publish anything.

Some nice UI would be useful to guide a user through the migration/resync process.

Another problem is that we need to make sure that after installation the app must talk to our pubs even if has a clean main feed.

[mplorentz]

This has been implemented and deployed to TestFlight 1.2.0 (321). There are some problems with it, but they have been documented in separate tickets (#524) so I'm closing this one.