thanks for the general infos and outlook!
we will need to have a workaround. here is a sketch of my current thinking on this.
the core issue is UX related. when a user does a call to our service to create some object (here, a data market with user defined ToS):
create_market(..., tos_hash, ...)
this call should a) return quickly, but b) also only accept a tos_hash
that does actually point to a file existing on IPFS.
therefor I think we should provide an additional helper in our service:
does_exist(hash, recheck=False) -> true|false, last_checked, mime_type, size
this function should cache the IPFS stuff in our service (either only the metadata, or also contents).
a user should then call does_exist
before calling create_market
. the latter does immediately know if the file exists by looking into the cache in our service.
calling does_exist
- when no cache info exists - the UI must be prepared for return taking a longer time (any timeouts are defined internally in our service or enforced by the IPFS gateways like in Infura).
calling does_exist
- when a cache entry exists - the UI will get an immediate return (from the cache in our service).
having called does_exist
before when a hash didn’t exist yet, and hence a “negative cache line” exists, a user must set recheck=True
to enforce a rechecking for the now supposedly existing file.
thus, a cache line can move from “nonexistent” to “existent” or “cached”, and from “existent” to “cached”, but never from “existent|cached” to “nonexistent”.
as a addon, we can provide upload_file()
in our service, which immediately marks the file as “cached” in our service, submits the file to IPFS via Infura in the background, and returns immediately.