proof of concept: assets as references to blobs in indexedDB, not directly as base64 in store

[mimecuvalo]

As I look at LOD holistically and whether we have multiple sources when working locally, I learned that our system used base64 encoding of assets directly. Issue #3728

The motivations and benefits are:

• store size: not having a huge base64 blobs injected in room data
• perf on loading snapshot: this helps with loading the room data more quickly
• multiple sources: furthermore, if we do decide to have multiple sources locally (for each asset), then we won't get a multiplicative effect of even larger JSON blobs that have lots of base64 data in them
• encoding/decoding perf: this also saves the (slow) step of having to base64 encode/decode our assets, we can just strictly with work with blobs.

The benefit here is clear! I created an AssetBlobObjectStore which probably needs some thought (again, this is proof-of-concept), so if we decide to move forward, let's discuss how best to integrate that part.

Todo:

• decodes video and images
• make sure it syncs to other tabs
• make sure it syncs to other multiplayer room
• fix tests
• have backup for existing editors instantiated without assetBlobStore

Change Type

• sdk — Changes the tldraw SDK
• dotcom — Changes the tldraw.com web app
• docs — Changes to the documentation, examples, or templates.
• vs code — Changes to the vscode plugin
• internal — Does not affect user-facing stuff

• bugfix — Bug fix
• feature — New feature
• improvement — Improving existing features
• chore — Updating dependencies, other boring stuff
• galaxy brain — Architectural changes
• tests — Changes to any test code
• tools — Changes to infrastructure, CI, internal scripts, debugging tools, etc.
• dunno — I don't know

Test Plan

1. Test the shit out of uploading/downloading video/image assets, locally+multiplayer.

• Need to fix current tests and write new ones

Release Notes

• Assets: store as reference to blob in indexedDB instead of storing directly as base64 in the snapshot.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
examples	❌ Failed (Inspect)		May 13, 2024 8:32am

1 Ignored Deployment

Name	Status	Preview	Updated (UTC)
tldraw-docs	⬜️ Ignored (Inspect)		May 13, 2024 8:32am

[steveruizok]

secret style guide nit: whenever editor is an argument to a function, let's make it the first argument

[steveruizok]

TIL our weakmap caches can work with async stuff

[SomeHats]

left some other thoughts on this here: #3764 (comment)

my take on this is that I like what we're doing with this, but i'm not sure it belongs quite so core as this makes it. i think blob storage is quite niche - it's really only relevant if you have an editor saving locally in the browser, whereas most people either have a multiplayer room or some sort of other saving mechanism. i certainly don't think it should be the default as this PR makes it.

instead, i would love to see a slightly more general system for making asset storage/retrieval more flexible. what would it look like for this to be build entirely in userland on your asset rewriting hook from #3764, for example?

[mimecuvalo]

my take on this is that I like what we're doing with this, but i'm not sure it belongs quite so core as this makes it. i think blob storage is quite niche - it's really only relevant if you have an editor saving locally in the browser, whereas most people either have a multiplayer room or some sort of other saving mechanism. i certainly don't think it should be the default as this PR makes it.

yeah, totally fair to not make it core, definitely would make sense more as a sidecar kind of option.

instead, i would love to see a slightly more general system for making asset storage/retrieval more flexible. what would it look like for this to be build entirely in userland on your asset rewriting hook from #3764, for example?

i see the overlap for sure, but i think in my head they're quite different (as far as storage vs. dynamic retrieval). i'd avoid making a system that tries to address them both perhaps because they're trying to address two different problems. (it's maybe a coincidence that I'm working on both at the same time heh)

let's discuss more tomorrow!

[mimecuvalo]

(closed in favor of #3836)