Table Block Design
Is this a backend or frontend concern? Frontend
Transformation happens between editor state to frontend block state.
Block Tree State
TableBlock
TableColumnBlock (all of them)
TableRowBlock (all of them)
Cell Blocks (normal blocks)
Editor state
probably resembles HTML
has <td> cell wrappers
Performance questions around this "heavy" data structure
Decision: We will not use Cell blocks in the block state
Use case questions about query blocks (database) vs table blocks
Table blocks inside documents and comments should be used for smaller datasets
Optimize Expensive Operations at publish time
For large documents and tables we have possibly slow code at publish time, because we iterate over the entire content in order to determine the operations that will be sent to the backend.
Is it currently slow to publish large documents?  will investigate.
 will write a doc about event driven editor plugin
Sync Immediacy
 would like to understand what is the exact RPC between peers?
How to handle private documents? Unlisted documents? Deletes?
We currently sync from 25 random peers max, plus bootstrap peers! (Very naïve sync strategy)
We need peer reputation system (and the already-existing domain store) to decide which peers to sync from and who to frequently poll from
What is the P2P Syncing protocol
Peer A requests a Resource string from Peer B while syncing
Resource string definition.
Does it include :comments ? :profile
Peer B responds with a set of Timestamps and CIDs, using RBSR. Peer A passes the CIDs into IPFS "blockstore" for syncing
How do we sync citations? This is broken right now between self-hosted peers
Domain Store
Can be used for network dialog to show domains.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime