MVP Support for data in Motion, but not yet backed up to Filecoin?

[davidd8]

Let's decide on the behavior of a GET to a blob in Motion, but not yet in Filecoin. A couple of options:

1. No support - easiest, but worst UX, as it can take a few days to have the data fully backed up.
2. Return the blob's status, but not the blob itself, i.e. stored in Motion, backing up soon... and maybe add a few more states to the status call. Provides more information, but blob is still inaccessible, though it reduces a set of concerns for the motion db.
3. Full Support - Return the blob and its Filecoin status. Adds more logic to the GET call and potentially adds a lot of load to MotionDB, so this may need to be rate-limited.

My understanding was that (3) was going to be in the MVP, but want to confirm since https://www.notion.so/ecosystem-wg/OUT-OF-DATE-MVP-Product-Specifications-f3dc1c0a5e8241a4ab3266eabf8f147d is no longer being kept up-to-date.

[masih]

Option 3 is the one that I find reasonable. Because:

• if a blob is not offloaded to FileCoin yet then it means it is locally present. Why wouldn't we serve the data that we have.
• we need to support retrieval from local store anyway since blob may be cached after having been offloaded to FileCoin for faster retrievals when a blob is fetched repeatedly in short interval.

Question: Why would option 3 put load on the Motion database? It seems there is some database interaction that you are imagining which is not entirely clear. Can I ask you to expand on this please?

[davidd8]

Perhaps "a lot of load" is too strong a phrase, and something we shouldn't even worry about for MVP. I'm assuming if MotionDB is serving a lot of clients, and a few clients happen to request a lot of data via GET, that could lead to service degradation to other clients during uploads to motionDB. In either case, I do think Option 3 is the most reasonable , and glad we've confirmed that.