Potential post-MVP refactor

[FishmanL]

Something I was considering: why not refactor the API to be as follows:

SSO-requiring/Sybil requiring methods:
Register user -- paramterized with phone #/notification method user submits some SSO/OAuth style callback to server, gets assigned an ID in the backend for IDs, call returns ID + nonephemeral key.

Non-SSO requiring methods:
Add location history to user: parameterized with user ID/user token (authenticated with standard methods for authenticated API usage, e.g. ephemeral keys) + json data -- this location history is added into the encrypted backend, matches on the relevant location/timestamp chunks are returned to the user immediately.
Convert time range to infected: parameterized with user ID, start time, and end time + standard auth. Sets the user's data within that time range to be infected, detects all relevant matches, informs them.

The upside of this construction is you don't need to worry about having find-match be sybil attacked, since every match op is tied to specific users. Heatmaps could be generated by dropping a random user in each chunk (0.5 lat/long on a side, 15 minutes long) and seeing how many infections those users have.

[ainsleys]

Hi Leor, can you clarify how this maps onto / replaces the current 4 endpoints?

[FishmanL]

Sure.
Register user is a new API call entirely for user ID generation.
addLocationHistory and convertTimeRangeToInfected together replace the addPersonalData endpoint.
Under this architecture the find-match endpoint is entirely deprecated, matches get found eagerly rather than lazily (i.e. whenever a new user adds data that causes us to note a match, the matched user should be notified)