Fix deserialization of previous contacts

[Schmiddiii]

This caused presage to not load contacts anymore stored from previous versions.

[rubdos]

I'm not 100% convinced that this is right: possibly we need to have this as Optional, and actually handle the absence of the timer version? There's quite some migration logic to this field.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.

Project coverage is 2.20%. Comparing base (3b8656a) to head (ae03a35).
Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
libsignal-service/src/models.rs	0.00%	2 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (3b8656a) and HEAD (ae03a35). Click for more details.

HEAD has 2 uploads less than BASE

Flag	BASE (3b8656a)	HEAD (ae03a35)
	3	1

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #324       +/-   ##
==========================================
- Coverage   16.77%   2.20%   -14.58%     
==========================================
  Files          36      34        -2     
  Lines        3111    2540      -571     
==========================================
- Hits          522      56      -466     
+ Misses       2589    2484      -105     

Flag	Coverage Δ
	2.20% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Schmiddiii]

I don't know how exactly timer versions work, but I would expect the only way to handle a missing timer version is to start versioning the timer with version 1.

[rubdos]

I'm mostly wondering about what should happen if the timer is unset: should some messages be transmitted to actually trigger the creation of a timer version?

I haven't looked at this yet, but I've added it to my TODOs for my MR for WF: https://gitlab.com/whisperfish/whisperfish/-/merge_requests/627

[Schmiddiii]

Looking at the migration Signal Desktop has, they don't seem to ssend any messages.
Just set any future contacts timeouts to 1 and the current timeouts to 2 (not sure why 2, maybe this MR value should also be changed to 2).

[GranPC]

From what I learned reading the Signal Android patch (signalapp/Signal-Android@1f196f7#diff-324a17e5ee685f28454fe3086896076f7028a4dbde241922f1b71348cc3692c4R14), they seem to handle it by setting it to 1, unless there an expiration timer is set, in which case they set it to 2.

They also do not handle groups at all. I think expiration timers are not going to be versioned for groups. or at least not for the time being.

[direc85]

According to this, we should also check the recipient capabilities regarding the version. There are functions to update the timer with and without incrementing the timer.

So: 1 = recipient doesn't support the versioning, 2+ = recipient supports... Right?

[Schmiddiii]

Given that the Signal servers now enforce that capability, its probably save to say that the recipient supports this.
And I even doubt that the choice of 1 vs 2 matters too much, if the recipient does not support that field, it will probably just be ignored when deserializing the protobuf.

Also, this MR is not for doing this absolutely correctly, this is just for fixing a regression where previous stores of presage do not work anymore, allowing applications to update presage in order to finally be able to link again (after now almost two weeks).

[direc85]

I found this which explains the groups situation - the version is always one.

[rubdos]

They also do not handle groups at all. I think expiration timers are not going to be versioned for groups. or at least not for the time being.

Groups are handled by the group state machine itself, which is already a versioning system on its own.

[Schmiddiii]

What is now the status of this PR?
From what I can read in #329, this is not desired anymore?
If not, we need to keep every old version of all structs we use in the presage store forever for migration to work, or finally use a sensible storage backend.

[rubdos]

If not, we need to keep every old version of all structs we use in the presage store forever for migration to work, or finally use a sensible storage backend.

You can probably handle most of this kind of migration logic internally. But yes, some more sensible storage method would be desirable. For now, I'd just say you put the struct you propose here in Presage, and make some From and Into implementations.

[Schmiddiii]

Thinking about it some more, I don't think I actually need that patch anymore. I already shipped it out to my users once, their store should now have the new field. But I'll do something like that in the next breaking change to the store.