Improve SyncBackup implementation

[igor-sirotin]

Here's how we currently fetch the backup from store nodes:

status-go/protocol/messenger_mailserver.go

Lines 258 to 274 in 3f19972

	func (m *Messenger) syncBackup() error {
	filter := m.transport.PersonalTopicFilter()
	if filter == nil {
	return errors.New("personal topic filter not loaded")
	}
	from, to := m.calculateMailserverTimeBounds(oneMonthDuration)
	batch := MailserverBatch{From: from, To: to, Topics: []types.TopicType{filter.ContentTopic}}
	ms := m.getActiveMailserver(filter.ChatID)
	err := m.processMailserverBatch(*ms, batch)
	if err != nil {
	return err
	}
	return m.settings.SetBackupFetched(true)
	}

We request a full month of messages for the contact-discovery-<public-key> content topic.
But we could be smarter here:

1. Find the latest backup message and remember it's timestamp T
2. Fetch more messages page by page

• ignore any messages with timestamp != T
• stop fetching as soon as all backup messages with this timestamp are fetched. If some message was lost, we can detect it by facing a message with the previous timestamp.

I implemented this approach in FetchCommuntiy, as we don't really need full month there, but only the last community description. The code now allows to proceed envelopes by page and stop the request when needed.

This will fix the issue you're referencing to. And also improve the fetching logic in general, we will not need to fetch and process redundant messages.

Originally posted by @igor-sirotin in status-im/status-desktop#14139 (comment)

[igor-sirotin]

Though from code perspective it's refactoring, but it's good to keep in mind that it should greatly improve UX of restoring account. We won't need the 30 seconds delay anymore.

[caybro]

Though from code perspective it's refactoring, but it's good to keep in mind that it should greatly improve UX of restoring account. We won't need the 30 seconds delay anymore.

Does it mean we can now remove the 30s delay in master? Asking mainly in context of status-im/status-desktop#11163

[caybro]

Or, can I close status-im/status-desktop#11163 in favor of this one?

[igor-sirotin]

Or, can I close status-im/status-desktop#11163 in favor of this one?

Yes, I think so 🙂

But technically we'll still need to remove the UI delay, is's done on QML side now. So maybe keeping a separate issue for that still makes sense?

[caybro]

Or, can I close status-im/status-desktop#11163 in favor of this one?

Yes, I think so 🙂

But technically we'll still need to remove the UI delay, is's done on QML side now. So maybe keeping a separate issue for that still makes sense?

OK, I'll set it as postponed/blocked for after this issue gets solved first. Thx!