How we built Watsi Coverage without stable electricity, WiFi, or email | Hacker News Reader

How we built Watsi Coverage without stable electricity, WiFi, or email

blog.watsi.org

135 pointsnecrodome25 comments

I wish all app designers would consider designing apps that function offline. It's infuriating to visit a web page that has been read before only to find that the browser won't show it because the network is unreachable.

Up until less than a year ago, offline web apps were not really possible. Until service workers became commonplace, the only option was AppCache, which is one of the most broken and convoluted specs ever to weasel its way into the web platform.

You should start to see more and more offline-ready web apps making an appearance as the tooling around service workers improves!

Nice.

Would have been more helpful if specifics were mentioned. E.g what Remittance service was used to pay with your US bank account? What network of telco? What did you use to build your app. PWA?

That way people that are well versed with Uganda can give feedback.

I never thought of the idea of using PIN terminology rather than password. I'll have that in mind.

I'm quite surprised that 100GB is $450. Uganda is known to have better rates. MTN is less than half of that [1]

[1] http://ugbusiness.com/1183/looking-for-the-best-internet-pla...

Wow, we came across the same thing while building epimetrics.in back in 2014-2015. We built the analytics engine and tested it in one mega Indian festival called "Kumbh Mela" with over 20 Million people gathering at one place. In our case, we had to struggle with the sheer amount of people as well.

We learnt a bunch of stuff and right away decided to have offline storage option and send data back to db when connection resumes. We also did the research on how to save battery life and use muscular memory to enable our users to use our system in that setup as efficiently as possible.

But at the end, it was very satisfying when we were leading on the front to spot the diseases. We helped attend over 2 million patients efficiently. If interested, I would love to share our insights plus few decisions which were very helpful for our adoption from health workers as well as govt health department officials.

Good work guys! Keep plugging! :)

Edit: Added festival name.

Nice. Would love to read blog post around this. If you have one

Unfortunately not as of now. But I will write it down and share here over the weekend.

If this sounds fun, we’re hiring a senior engineer: http://blog.watsi.org/engineers/

Out of interest, what stack are you using to achieve offline first?

Where I work[1] we are currently using CouchDB + PouchDB, with our app being a SPA webapp wrapped in an android wrapper[2]. I'm interested what your approach is and how it differs.

[1] https://www.medicmobile.org

[2] We bundle something called Crosswalk because a) it's a way to get a newer webview on older phones and b) it allows us to get around the webview offline idb data limit of 5% of available disk space

Hey Chase!

Do you have plans to open source Watsi's universal healthcare delivery platform?

If they have to buy data 1Mb at a time, which websites or apps do they use that load with the smallest download?

Not shitty modern SPAs that load content dynamically and modify the DOM to save bandwidth, but load 30MB of js libs first on every visit to make all this crap possible in the first place.

If anybody from Watsi sees this, we've spent years working on and perfecting offline-first distributed data sync, we've released it as MIT/ZLIB/Apache2.

We've had navy warships running the system on ancient hardware, and lots of people in the Open Source community have run it on low power devices, like raspberry pi and dirt cheap android phones.

Would love to chat, my email is in my profile.

Not from Watsi, but I’m curious about this. Is there a link to learn more?

From marknadal's profile page I gather that this is the link. Looks pretty cool. http://gun.js.org/docs/Introduction

I'm sure I'm misunderstanding this, but it sounds like their entire user database for a medical system is copied onto every phone, and it's guarded by a six-digit pin? That can't be right?

Per clinic I suspect

The article mentions enrollment, so each phone has a tiny shard for writing to the actual DB when the network is available.

Great read! The bit about the time stuck out at me. With Internet access comes `ntp`, but without it... just how well tuned is the timekeeping circuit in cellphone chipsets, and how much did that even matter?

Cell phones can receive GPS signals which are a very accurate source of timekeeping.

Is that right? The way I understood it, GPS works like a kind of triangulation, with your distance from the satellites being calculated based on how long the time-stamped signal takes to travel to you. Meaning your device has to keep its own very accurate time in order to be able to compare.

But the phone can get the time from the cell towers.

I may be wrong, this is just a layperson's understanding :)

As far as I understand it, the only things a receiving device needs to work out where it is are a stable timer, a good view of the sky and time.

Each satellite transmits where it is and the current time in UTC, which means you can get a pretty good idea of what the time is (presumably to within a second) by picking up a single satellite's transmission, then work out what the actual time is once you've got all the other satellites and triangulated yourself.

Phones can do this a lot faster by connecting to the internet to figure out what the time is, what the satellite orbital parameters are and where they all are right now.

(Sources: A friend explained this to me once and I just skimmed the wikipedia page)

If you have an atomic clock in your GPS device, you need to see 3 satellites to get a fix. As you said, you calculate travel time for the signal from the atomic clock on the satellite to the one on the receiver and that puts you somewhere on the surface of a sphere. Two spheres intersect to give you a circle, and a third gives you a point (technically 2, but one is probably in space).

Doing it like that would require you to have an atomic clock in every receiver though, which isn't feasible (and anything less accurate would make the fix too inaccurate). Instead you add one extra variable (current time) and one extra constraint (extra satellite) and the equation is solvable again. This is why you need 4 satellites for a fix. The solution to the equation not only gives location but also precise time, which is why GPS receivers can be used as standalone time references.

The other thing you need to know to do all of this is where the satellites actually are: this information is called the ephemera and the almanac. You can download this from the satellite signal, but it is very low data rate and takes several minutes. This is why handheld GPS receivers can take time to get a fix. Mobile phones instead download this from the network which is why they can make very fast fixes - they just need to scan frequencies to get a lock while doing the download and then do a bit of maths.

Cell towers require precise timing for a variety of reasons and phones can synchronise to that time source. Phone clocks are good enough that as long as you don't go too long between seeing cell towers then your signal isn't going to have walked too much.

The way they're using them, it sounds like 1 second resolution is easily sufficient. That would be achieved by a 1 ppm accuracy crystal (fairly standard) that is synchronised once a week.

Way to go! Can you explain more about Watsi coverage actually does? Very cool article and process.

Reply on news.ycombinator.com