You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 16, 2019. It is now read-only.
Read receipts (+co. - ephemeral events in the room)
Prune storage to 50 timeline events
Prune memory timeline to 150 events
Don't store leaves (unless they are needed)
Description
This includes a fairly major refactoring of how rooms/events are represented outside the services. It should also address issues like #64 and add in supporting framework for #54.
Much of this issue is for documentation purposes when/if the system needs to be referenced in the future.
Events in room (50 most recent, 150 in memory - a later story will have these numbers be configurable)
Joined rooms
Room state (except m.room.member events of leave or kick, unless they appear in the 50/150 timeline cache)
Batch tokens for each room (for backfilling)
Account data (including per-room)
Read receipts in rooms (typing notifications are stored in memory only)
Estimated storage use (for a 1000 room account):
Timeline space (non-state, ~300 bytes/event): ~15mb (~15k/room)
Room state space (~5k events/room, ~200 bytes/event): ~1gb (~1mb/room) (it'd be really nice to trim this down)
Account data space (including room account data): ~450 bytes
Read receipts space: TBD
Evelium should use indexeddb to store this information. For further space-saving measures, we could filter out events which cannot be processed by the client before they leave the sync processing. This could cause problems down the road though if Evelium, for example, gains support for net.arasphere.temperature then historical events will be missing.
The text was updated successfully, but these errors were encountered:
Future code will also need to store things like groups data, crypto, etc. At that point it should be possible to do a one-time sync with a filter to get the misc bits of pre-state we need to continue.
Matthew's initial work at making syncs more manageable might help make storing some of this easier. The initial implementation of storing stuff in Evelium is intentionally limited in scope pending some progress on the /sync front, although it should still be okay for daily use.
Checklist
Description
This includes a fairly major refactoring of how rooms/events are represented outside the services. It should also address issues like #64 and add in supporting framework for #54.
Much of this issue is for documentation purposes when/if the system needs to be referenced in the future.
Stats reference:
Information to store:
m.room.member
events ofleave
orkick
, unless they appear in the 50/150 timeline cache)Estimated storage use (for a 1000 room account):
Evelium should use indexeddb to store this information. For further space-saving measures, we could filter out events which cannot be processed by the client before they leave the sync processing. This could cause problems down the road though if Evelium, for example, gains support for
net.arasphere.temperature
then historical events will be missing.The text was updated successfully, but these errors were encountered: