The Developer Case for Using Tim Berners-Lee’s Solid
It’s been slightly over a year since Sir Tim Berners-Lee, the inventor of the World Wide Web, introduced the Solid open source data protocol during his keynote at the virtual WeAreDevelopers World Congress. The New Stack checked in on Solid’s progress recently, speaking with programmer and consultant Jackson Morgan, who is an administrator with Solid’s team and a freelance Solid developer for o.team.
Solid is a chance to fix a lot of what’s wrong with data online by giving end users control of their personal information. It’s built on an HTML protocol that uses datastore or pods, which can be created and self-hosted — or at least owned, if you use a third-party for deployment — by the individual, who can grant or revoke access at will. It’s exactly the kind of digital identity solution that we’ll need if we’re to unlock what former Twitter co-founder and CEO, now Block (formerly Square) founder and CEO, Jack Dorsey described in his vision of Web 5.0, which called for self-owned digital identifiers and decentralized web nodes.
“It sounds conceptually like Solid. They might be creating their own decentralized web nodes thing,” Morgan said of Dorsey’s outline. “But the thing about this is, it’s not necessarily any kind of new concept.”
Solid calls for pods, which are both a standardized identity and a repository of personal data that anyone can access, but only an individual owns. From a developer’s perspective, all that coding so you can get data about your user? You could reduce it by using Solid.
At a minimum, a use case would be to replace Gmail or Apple iTunes or any of the other proprietary, app-based sign-on protocols with Solid’s open source protocol. A more robust use case would be a repository of, say, personal medical data that are owned and maintained by the individual end user, but accessible with permission to all systems — which, frankly, cannot come soon enough for those of us tired of asking doctors to fax (gasp!) medical records to another doctor ahead of medical procedures.
An Awareness Problem in the U.S.
Of course, those of us most concerned with this eventuality tend to be in the U.S., with it’s highly decentralized, application-siloed, and — dare-I-say-it — archaic medical record system. And just my luck, it turns out the Solid adoption has been super slow in the U.S., Morgan said.
“Wouldn’t it be awesome if no matter where you went in the world, you could just walk into a hospital or a clinic and say, ‘Here are my healthcare records,’” Morgan said. Why, yes it would, Morgan. It totally would!
Apparently, the U.S. has an “awareness problem” when it comes to Solid.
“The tech culture in the U.S. is a lot less suspicious of companies that are looking to centralize their data, because they can see a way to make money off of that,” Morgan said. “Europe’s culture is very suspicious of that. So already, whether it’s in the public or private ecosystem, most people in the US aren’t even thinking that that’s a problem, or at least most business administrators, or government administrators in the US aren’t.”
Europe Pilots Solid Adoption
Meanwhile, early adoption is happening, but primarily in Europe, where consumers and governments alike are more wary of large corporations gathering personal data, Morgan said. Although to be fair, those large corporations tend to be based in the U.S. and thus are seen as more of a foreign threat to European citizens. The General Data Protection Regulation is one way Europe has attempted to regulate the influence of Big U.S. tech. Solid, Morgan contends, is the technical answer to the question asked by GDPR.
He rattled off a list of the year’s wins for Solid, which include working with:
- The Belgium government (TNS found an informational PowerPoint on a Flander’s pilot with an interesting segment about problems created by APIs);
- The UK Government conducting a National Health Services pilot in Manchester to move healthcare data to Solid; and
- The Norwegian government using Solid to keep data sovereignty among its citizens
The Question for Developers
The question for the U.S. maybe shouldn’t be “why would we do this,” but why wouldn’t developers want this? Right now, much of the data that apps are requesting is the same data, and obtaining it is expensive and creates security risks. It’s still an emerging protocol, though, with tools being developed that will make deployment easier and thus perhaps more compelling for developers.
“When it comes to frontend developers and web developers, I at least am of the impression that if good tools are built, then they can start building things,” Morgan said. “The concept of owning your own identity isn’t that hard to think about. So to wrap your head around, […] instead of storing things in another person’s database, I keep my identity and my pod or my data on a database that I control, or a cloud host that I trust.”
For frontend developers, that basically removes backend problems. Instead of an on-premise database, they can think of it as connecting to a global, albeit decentralized, database, Morgan said.
“The basic concepts are relatively simple to learn,” he said. “It is incumbent on people like me, or maybe super zealous frontend developers who want to do things like read specifications, to build the tools that make it easy for everyone to use.”
Morgan has even created a development tool called LDO (Linked Data Objects), which attempts to make it “as easy as possible” for developers to navigate RDF graphs with just JSON. Developers might want to start with this tutorial that creates a JavaScript app. Morgan has also written a tutorial for using Solid with React.
But for now, the project seems to have a bit of a chicken and an egg problem. Solid will be used when there are users for it… which may not happen until end users need to have a pod to connect with applications that, so far, are few and far between.
