When the outbreak of COVID-19 started, Michael Corning, the Cryptocosm Architect at Secours.io, wanted to build a self-sovereign identity (SSI) based app that would help reopen his local economy in Sisters, Oregon without reopening the pandemic. As we all know, how easy it is to adopt a new technology or software plays a key role in its ultimate success.
The first version of his app proved to be too complicated and idealistic for businesses and organizations to adopt. He quickly reevaluated his strategy and built a more simplified app, called Safe in Sisters, which was built with adoption in mind. The Q&A below is our interview with him to learn more about the changes he made to create an SSI-based app that was “adoptable”.
What is the Safe in Sisters project? What is its purpose?
After the COVID-19 pandemic hit the state of Oregon and we shuttered shops and public places, here in my little piece of heaven—the city of Sisters—I went to some of my friends at Economic Development for Central Oregon and told them how I wanted to reopen the Sisters economy without reopening the pandemic. They both loved the idea. Two of my physicians heard me explain how I was planning to accomplish this mission (I wanted to know how medical providers would react). One doctor was enthusiastic, and the other had an arguable HIPAA-allergic reaction.
Armed with this mix of reactions, I set out to build a set of tools that would provide users with local contact tracing, a COVID symptoms scoring sheet (based on data published by Oregon Health Authority), and verifiable presentations. The verifiable presentations would do something as simple as check a zip code (Sisters had zero COVID cases at the time, but counties nearby glowed purple with the afflicted) or as complicated as checking for a positive COVID test result and two subsequent negative results within a two-week window.
Early on, I realized that writing the code was the easy part. Socializing the protocol and getting people to understand, value, and use the technology would be the hard part.
Turns out, I was correct.
Working with my Enduring Net COVID comrades across the pond, we took the prototypes to a large care center in Manchester, England. We showed them all the fancy stuff, and their first response was, “We have six entrances to our facility and handle over 600 people per day. We can’t spend time exchanging QR codes with visitors.”
I learned two valuable lessons (actually, I knew the lessons but had never seen their consequences in action quite so starkly):
- My passion for complex solutions usually does not meet with equal user enthusiasm.
- The second lesson was best taught by Professor Edwin Jaynes in his Probability Theory: The Language of Science. He notes, “The simplest solutions aren’t best because they’re simple. They’re best because simple solutions are more likely to succeed.”
So, I set aside the techno bling, and I started over. I was bound and determined to provide the world with a solution simple enough to succeed.
What makes this project unique from some of the other SSI & verifiable credentials projects that are designed to combat the threat of COVID-19?
The first difference is that we focus on local ground conditions. People in Sisters don’t care about COVID prevalence in Manchester. They care about the prevalence at the Sisters High School or the Five Pine Lodge. They don’t care about the prevalence at Heathland Care Center in Manchester, but they care about The Lodge in Sisters care center across the street from the Fika Coffeehouse.
A second difference follows from the first: Local contact tracing is just the first line of defense. If a COVID carrier gets into a room and exposes other healthy people, at least those now at risk know about their invisible condition in time to do something to stop further spread. Once a room has carried a carrier, the room needs to bring out the big guns. The room and its visitors need other tools to access the risk of exposure. This is where symptom tracking and verifiable credentials come into play.
The third difference is that we focus on measuring risk. This may turn out to be the most important difference. We understand that a measurement is a set of observations that reduce uncertainty. We don’t guarantee safety; we don’t reduce risk by 100%. But we do use all available data as a set of observations that reduce the uncertainty that plagues us about the virus. Our tools provide users with consistent metrics they can use to make informed decisions about who is safe enough to interact with. No more controversy. No more excuses. No more virus.
Our job as technologists is not to show how cool our technology is. It’s to save lives. It’s to stop the virus in its tracks. My job is to make Sisters the COVID Hotel California—the virus can check-in, but it will never check-out.
Why have you focused on a local contact tracing solution? What is the difference between contact tracing and local contact tracing?
All politics are local. All battles with the virus are local. Most of those affected by the virus are local. Local contact tracing is far simpler and more reliable than conventional contact tracing. We can control the virus in our town without help from the government or from Apple and Google. We don’t need GPS. We don’t need Bluetooth. But we do need common sense, privacy, and secure messaging.
Since local contact tracing is local and not centralized at scale, and since the code and infrastructure is neither complex nor expensive, we expect rapid replication across the planet, not of the virus, but of the tools to kill it.
Can you go into detail of how the Safe in Sisters app works?
Since local contact tracing is a free service, I moved development to my nonprofit counterpart of Secours.io, the Soteria Institute. The Soteria Local Contact Tracing tool is a Progressive Web App (built with VueJS on the front end and socket.io on the backend). Once you’re on https://soterialct.z22.web.core.windows.net/, you can add the app to your phone’s home screen and it looks and acts like a native mobile app.
The app has two views: Room and Visitor.
People responsible for a public space manage a Room. Visitors choose that room and check-in when they enter and check-out when they leave. Rooms and Visitors store each of these decisions (to enter a Room or to be allowed to enter a Room) in local storage (IndexedDB) on their phone. Visitors send check-in socket messages to the server, and the server forwards those messages to the Room.
If a person sends a COVID exposure alert to all the Rooms stored on their phone, the Rooms can pick up the message from the server, list all the Visitors who occupied the room at the same time in the past two weeks, and can send alerts to the server that forwards them on to each of the other Visitors.
In the simplest scenario, Rooms don’t have to do anything (the alert protocol can be fully automated), and all a Visitor has to do is click a button on the app to log Rooms and another button if they go into quarantine. No QR codes. No room staff overhead. No cost of service.
If that’s still too complicated for people, I’m going into another line of work.
Below is a short demo video that shows how the process works:
How has this project evolved since you first started? What are the obstacles you have run into?
To summarize the evolution of my work:
- The Secours app started as a full-blown application based on Trinsic.
- I separated out the simplest capabilities of that original design to focus on local contact tracing using Aries messaging.
- I stopped using Aries messaging and refactored LCT with Socket.io (this is the base Service Level Agreement, SLA-0), and I assigned that development to Soteria.
- I refactored the Trinsic capabilities into two additional Secours SLAs:
- SLA-1 adds personal credentialing and additional risk management tools.
- SLA-2 adds COVID test credentials and rich Verifiable Presentations.
- I plan to augment Socket.io with more powerful assets like Redis, so I can develop artificial intelligence asserts that will transform my Soteria/Secours-based digital twins into intelligent and helpful digital partners.
How has Trinsic helped you along in the process?
Trinsic was mission-critical for three reasons.
First, making something simple that’s complicated is difficult. Trinsic has met that challenge. Back in the Spring, I was able to get up and running in a few minutes. Trinsic assets are generally well-documented now, and development tools are even simpler than a few months ago. This meant I was able to build my verifiable credential exchange (VCX) prototype in record time. And while I was disappointed that the world wasn’t quite ready for all these new capabilities, it was a forcing function that changed my marketing strategy from push (see how cool this tech is, don’t you want some?) to pull (see how easy it is to do something you couldn’t do before?).
And because I built so much in so little time, I was able to set these powerful Trinsic solutions aside and spent one more month getting a simple and stable web socket messaging platform ready for our fist offering: local contact tracing. Having all the rest of the heavy iron waiting in the back room means I can respond immediately to early adopters who quickly needed more power than messaging provides. At each stage of the VCX adoption process, we stay as simple as possible and no simpler. We give our users all the power they need now and no more (until they need it).
Second, local contact tracing goes global only if thousands of people like me can get their hands on technology that is simple and easy to implement and extend. Trinsic was built on the lowest barrier to entry. All our Trinsic API code is in a public GitHub repo, and we will provide later local contact tracing adopters with training material that will ensure many other communities around the world can stay safe from the virus.
Finally, I realized something else during this early development phase: As cool as connectionless credentials are, they are not the most important part of the Trinsic platform. Credentials keep your data safe. Verifiable presentations make your data valuable. Trinsic’s implementation of verification policies took all the mystery out of this critical step in VCX; so, again, our users can tell us what they need for verification, and we can respond on the spot.
Next time you ask me this question, I may have a third reason to love Trinsic: I suspect verification policies will enable me to implement decentralized semantics with relative ease.
What stage of development are you in? How big do you see your solution getting, and how do you see it scaling?
I am nearly ready to take the tool back to the UK and see if it is simple enough to be effective. If the app passes acceptance testing, I will recommend a British colleague to fork the GitHub repos (client and server), setup the necessary server assets (static Web App, Ubuntu VM), and take it from there.
At the same time, I will make it available to my friends and family here in Sisters. And if that works, I will recruit others in Oregon to replicate our success in Sisters.
Once my users build muscle memory on Service Level 0, I will continue field testing at SLA-1 and SLA-2. Someday, soon—I hope—I will have the resources to focus on SLA-3: a personal artificial intelligence.
If I do my job and our local approach scales effortlessly, then I expect there will be 7 million localities each serving 1,000 users.
Anything else you would like to add?
To my fellow Sisters residents: For our strategy to work, people must care about each other just enough to push two buttons on their phone, maybe three.
For a few people in other cities and towns: You can do your part, too. Replicate Safe in Sisters where you live and work. Stop the virus in its tracks.
Together, we can relegate COVID-19 to a display at the Natural History Museum.
And stay safe out there…
(end of interview)
We, at Trinsic, are currently offering our platform free-of-charge to those working on SSI projects related to COVID-19. If you are interested in learning more about this offer, contact us or get started with a Trinsic Studio account for free today.
