Fog "cache purge" directive

[cbeck88]

One item which is desirable for fog to have, but which was cut from the initial launch, is some sort of "cache purge" directive that the service can deliver to clients that directs them to purge cached data that they previously retrieved from Fog.

This is useful if something goes wrong with the fog database and we end up serving bad data to users, because it gives us a way to recover without pushing a client update.

For comparison, HTTP incorporates cache directives like Clear-Site-Data, for dumping the browser cache related to a site. HTTP also supports more fine-grained Cache-Control directives, which helps for managing HTTP caches which may sit in between the user and the actual HTTP server.

(What we are proposing is much simpler than this though, we want to have only a single timestamp, which controls purging of all the client's fog data.)

Besides damage control, a cache purge directive is also useful if we want to rewrite the fog database. For example there has been interest lately in coming up with a path to merge two fog databases, and having a way to purge client caches is likely needed to make that work.

---

Suggested change:

In the fog-view query response proto: https://github.com/mobilecoinfoundation/mobilecoin/blob/2a7b65c8558ff05571ce0c331e8224b9f3a0056a/fog/api/proto/view.proto#L98

We should add a field int64 valid_from.

The intended meaning is, this is a unix timestamp (Seconds since the Unix epoch). If the client has any data from fog from before this time, it is considered invalid and all the client data should be purged, (all txos, rng records, user events, etc.) and it should start the fog view protocol again to recover the correct balance.

If the client does not have any data from before this time, then they can ignore this field.

There should be a single global value in the fog sql db which is the source of truth for this timestamp, which is what the server returns in all of its responses.

The administrative CLI tool should be extended to be able to set this value.

[cbeck88]

Note that, modifying the fog-view query-response requires an enclave change, so this is a 5.0 issue.

[jgreat]

would valid_from be a global value that's set in server config and then presented to all clients in their responses?

[cbeck88]

yeah, it would be global value.

I was thinking to put it in the db so that there's a single source of truth. If you think it's simpler to do just make it like a server CLI arg I'm fine to take that approach too?

[cbeck88]

Hmm -- I guess another approach is, don't stick it in the protobuf, but stick it in an HTTP header in the grpc response?

Then we could potentially ship it without an enclave update.

I'm not sure how much that improves things -- we would still need a client update.

[jgreat]

I guess I was thinking from the description it would be updated on a range of transactions or something that would make updating complex. But its its just a single global value that's set in the db, that's fine. :+1:

Certainly should be easier to update while the service is live.

[cbeck88]

I guess I was thinking from the description it would be updated on a range of transactions or something that would make updating complex. But its its just a single global value that's set in the db, that's fine. +1

Certainly should be easier to update while the service is live.

Thanks -- I updated the description to try to make it more clear