Add CEN Reporting Proposal. #15
Conversation
This Sourabh's CEN reporting proposal. Co-authored-by: Sourabh Niyogi <[email protected]>
hdevalence
force-pushed
the
reporting-proposal
branch
from
49c828c to
daead34
Compare
| key: String, // Key_{j-1}. [hexadecimal form, 64 chars] | ||
| j : Int, // initial period j | ||
| jMax : Int // number of periods | ||
| ``` |
There was a problem hiding this comment.
Because the reports are downloaded by all clients, we should ensure they are as compact as possible. I think this format is not particularly space-efficient. For instance, L and key should be encoded as bytes, not hex-encoded strings, and we may want to use LEB128 to encode j and jMax.
There was a problem hiding this comment.
I think it might be worth making a separate issue to figure out exactly what data we need to include in a report.
| understand the system solely from a logging point of view. | ||
|
|
||
| CEN Clients will then write/read: | ||
| * **CEN Report Writes.** Write to a bucket endpoint with a new log line. For |
There was a problem hiding this comment.
I think we will need to have a backend server, not just writing to a bucket endpoint, because the backend should randomize the order of reports in each batch and potentially add noise.
| will write to the longest bucket prefix that covers all the geohashes | ||
| visited, e.g. someone who has been in geohashes ABCDE and ABDEF will write to | ||
| bucket AB. | ||
| * **CEN Report Reads.** Read from a time-based log system. For geohash |
There was a problem hiding this comment.
It might also be worth making a separate issue to work through details of sharding?
|
@sourabhniyogi What do you think of those concerns? |
|
Closing this for now because parts of it have been addressed in other PRs. |
This Sourabh's CEN reporting proposal.
Co-authored-by: Sourabh Niyogi [email protected]