Making it survive in hostile environments, e.g., refugee camps and disaster zones

[gardners]

Here the special challenges are extremely limited bandwidth and energy, and potentially, having groups of people in "data islands" where some kind of local mesh networm may allow local connectivity, but may be completely cut-off from the internet, or with only very intermittent connectivity.

In these conditions, Design 1 seems better than design 2, because it doesn't require hundreds of megabytes of data to be downloaded by each phone each day. Rather only ~32 bytes x number of infection-associated EthIDs need to be distributed. This could be done efficiently in a delay-tolerant networking context. Similarly, where internet connectivity exists, those could be forwarded to the relevant backend server.

I've been working on such systems for the past decade, and happy to pitch in here if helpful.

[AJamesPhillips]

Sorry @gardners can you provide a link to "design 1" and "design 2" please? Thank you.

[cascremers]

@AJamesPhillips these are the two designs currently in the DP-3T whitepaper.

[snakehand]

Some random thoughts, it would be possible to include some optional rudimentary geo-fencing information in both uploaded SK and downloaded infected keys. The simplest would be just a central longitude / latitude with an angular radius. If latitude / longitude is converted to 3D coordinates on a unit sphere, intersection can be computed by comparing a simple scalar product of request & data with the sum of the angular radii. This should not produce much load from run time filters the server side. I have not considered privacy issues that this can present thogh.

[obi458]

Like #65

[gardners]

Also see #127, where the user's device can effectively decide which backend to push the data up to.

[nfd9001]

Consider sharding the downloaded dataset instead, such that users pull numbered, cryptographically signed "chunks" of a handful of kb. Having some of the dataset is better than having none of it. If the user can only pull down a partial dataset, more of those chunks can be pulled from a new, ad-hoc, phone-to-phone meshnet. Say, reserve a bit in the BLE string that says "I'm looking for more chunks," and talk on the WiFi card/start a larger Bluetooth handshake so that the two devices can quickly share any chunks they do have. That might lower the pressure on any established local infrastructure/meshnets, and without causing people to e.g. centrally congregate around a location that's having a good-Internet-day. As a bonus, communities could just add new keys to their keyrings to track different infections/track advice from new medical agencies without necessitating a new, heavy update. Also, people who are naturally at more risk (those who end up closer to more people) will naturally recieve more of the dataset faster.

I guess a natural consequence of that strategy would be that you could spread out all of the necessary tools to set up contact tracking more cheaply for a population that has a very low rate of cellphone carry: set up satellite internet where medical care is provided, fab up some minimal devices with only the hardware needed to do effective contact tracking/notification, and let the same community close-proximities that allow contact tracking do the work for you.

[gardners]

With something like Serval Rhizome DTN this effectively happens automatically: Each report exists as a piece of data on the mesh network, and the Tree Sync algorithm will allow efficient synchronisation of these. Expiry information in the data allows old data to be automatically expunged from the system. Rhizome can already run on phones and custom relay hardware devices (Serval Mesh Extender), which can use UHF or HF packet radio to connect data islands over relatively long distances.

[nfd9001]

Looks like a neat project! Forgive my ignorance of Rhizome; most of my direct experience with meshnets came from reading about a local cjdns project back in 2012-2014 or so. Glad to see progress is marching on in fine hands :)