Ideas

~~Problem: Heavy Queries, mostly on Feed: Do we remodel or do we fix queries? More work at index time and less at query time.~~
- ~~We need to optimize the queries~~
  ~~related to moves, rename paths,~~
  ~~mentions and comments.~~
- ~~Some events cause the frontend to perform lookups.~~
  ~~We would skip this.~~
- ~~We need to model events from the business logic:~~
  ~~deletes, updates, moves, and renames.~~
  ~~How will this alleviate this:~~
  ~~We stored these events as the app needs them. So we don't need to do huge queries.~~
~~Search API was broken~~
Connect to a Peer is extremely slow and high volumes.
Improve Object Modeling.
Cancel requests when the user moves away.
Deactivate observability with a flag until we make it work.
~~Pagination Documents and Query Blocks.~~
- ~~Optmized the middelend or the daemon paginates the document.~~
- ~~renderer can't keep up with the requests. they are tiny but a lot. they can only make 5 at a time.~~
- ~~it shold be done in the frontend or~~
  - ~~Backend doesnt know the document graph. Viewport knows the resources.~~
- ~~Make the Sync Engine processes based with an WriterObject:~~
Optimize Frontend calls:
Objects receive events:
Optimized Syncing: Discover and Compute Haves
- Reconcilization Process. The server does it per round-trip and per peer.
- Queries are expensive: we not only do document changes, but also profiles and capabilities.
Domain Store
- Table of domains, frontend asks domains
- The information is cache. It has the metadata
- Background we hit the domains to make updated.
- The idea is that the user can go offline and continue working with domains.
- there is an api
- Why do we need to keep
  1. check the update loop.
  2. If the user
- we want to resolve domains, and this should be cache. and for subscription.