I discovered today that this library (which we use to store the archive of your chat history) has been deprecated. Removing it from our codebase was really easy (and it's the cause of #88), so I have done so.
This created a complication, however, because that library used to write a 7-byte codec-identifying prefix at the beginning of a history file. Now that we're just deserializing the JSON directly, that prefix causes us to mis-parse (and causes history loading to fail).
To get around this problem, I've implemented a compatibility layer on the Populate method. If the code encounters an archive created using multicodec, it will read the seven-byte prefix and silently discard it before passing the data on to the JSON deserializer. When the client later saves its history, it will overwrite the history file with the new format (no prefix). Once we've had this in place for a while, we should no longer need the compatibility code, and will be able to remove it.
Feature/Fix explanation
I discovered today that this library (which we use to store the archive of your chat history) has been deprecated. Removing it from our codebase was really easy (and it's the cause of #88), so I have done so.
This created a complication, however, because that library used to write a 7-byte codec-identifying prefix at the beginning of a history file. Now that we're just deserializing the JSON directly, that prefix causes us to mis-parse (and causes history loading to fail).
To get around this problem, I've implemented a compatibility layer on the
Populatemethod. If the code encounters an archive created using multicodec, it will read the seven-byte prefix and silently discard it before passing the data on to the JSON deserializer. When the client later saves its history, it will overwrite the history file with the new format (no prefix). Once we've had this in place for a while, we should no longer need the compatibility code, and will be able to remove it.Review required: @arborchat/devs