Optimizing Community Description

[Patryk]

@fryorcraken

In essence, only the last version of CommunityDescription matters. Which opens opportunities in terms of bandwidth and diskspace saving.

We have identified three strategies to leverage this opportunity, that could be used together:

• lazy pull: messages should not be broadcast on relay but being pulled by the users. Which is justified because only the most recent message matters. It does not make sense for a user to go online and pull all the versions of the message
• last version only: only the latest version matters, the system from which the users pulls should not store previous versions. Which implies the system being aware of the specific artefact and its versions
• update: we may want to also enable an update only from the sender, where instead of pushing the full description, could only update specific fields to save on upload

I think the strategy makes sense in general, but I want to emphasize that CommunityDescription is attached to various message types, and the periodic community publishing done by the owner might not be the biggest concern here in terms of bandwidth.

CommunityDescription is part of:

• CommunityRequestToJoinResponse, which is propagated through relay once if the owner accepts the request on their own, or twice if acceptance comes from a privileged member.
• CommunityEventsMessage, which is propagated through relay each time privileged members make changes to the community.
• SyncInstallationCommunity, which is propagated through relay each time a backup is created or a sync is performed. Backup occurs every 8 hours or on demand. Sync is performed when there are paired devices and the user either requests to join the community, joins the community, leaves the community, or opens the community on mobile (fix(communities)!: stop syncing community on `LastOpenedAt` update by osmaczko · Pull Request #5884 · status-im/status-go · GitHub).

We will need to rework all of these to not contain CommunityDescription.