I am an open-source developer, a teacher, a solarpunk, and a community gardener. I'm keen to talk to you today about interoperability. Interoperability, if you haven't heard the word, just means the ability to interact with other things or other people, other systems.
So I'd like to shift the focus from APIs to interoperability. So to do that, I want to roll back, talk about a little bit about the prior art, the history of APIs, before rolling forward to look at the future and what's beyond APIs.
APIs are not an emerging tech. They've been around for a decade, two decades. I haven't really been keeping track. So we should be learning from them, learning from the mistakes that people have made with APIs, before we try and implement things for government and citizens.
So really quick recap on what an API is. It sounds really jargony. There might be some less technical people in the room, I think we mentioned.
This is my best analogy. We're at the bank. An API is just an interface. It's a way of interfacing with another entity, like the bank. So here I am. I'm a client. Come on in. Here's the server, or the person serving me is the server, the clerk. And the API is this interface here.
I might make some queries. I might ask them some questions. "Can I have my bank statements, please?" So there's a list of queries and legal requests that you can make of that server. And they'll go away and check in their filing cabinet. This is their database.
And there are also, like, a list of legal requests I could make, like "Could you give me Pia's money, or Pia's account details?" And they could say, "No. Who are you? What? Please leave". Also, non-relevant questions-- "Can I buy a dog here?" Like, that's not what this interface is for.
So mapping that into a digital sense-- an API is a just a digital, programmable interface, and it involves robots instead of people. But it's the same language. We've got the client here, which could be my phone. And I've got my Kiwibank app. And I'm making a request of the server. This is the Kiwibank server, who goes and checks their filing cabinet, which is their database, and shows me my bank transactions, or lets me initiate transfers.
So APIs are really exciting, because when you make these things programmable, you give people the ability to display data in different ways. We've really seen some great examples of that today. For example, the-- what was it called? The cruise-- the Marlborough Sounds cruising and interaction is really amazing.
Here's a really simple example with bank accounts. This is Kiwibank. This is my Kiwibank, my well-being account. And I use this to spend things that should be enabling my well-being. And I've got a maths degree, but this is just like numbers. It's like, no good.
So with an API, I can do something like this. I can add a little graph in here, and go, oh, look, the money is building up in my well-being account. Maybe I should up my well-being spending, or whatever, you know?
The frustrating thing is that I know that Kiwibank has an API, because my phone, which is a robot, is able to talk to their robot, and display data. This thing that I made here, I had to, like-- they don't make their API public, so I had to build this manually, teach my robot to go through and scrape this data out of this column, and then build this graph.
And that's like, incredibly annoying as a developer, because I don't just have one bank account. I've got cards attached to Kiwibank, and I've got a mortgage with ASB. And I actually want to dream a little bit bigger. I want to make an interface for Mix which interfaces with both of these and gives me a dashboard that helps me dream about and plan an excellent future. And I can't do it. Like, the banks won't let me do it.
So what's the problem here? The problem is, everyone's building castles or silos. And here's little old me, trying to interface with Kiwibank, which has this big castle wall around it. I didn't have time to draw a moat. Thought it might be a bit messy. But that's basically what's going on.
And it's awkward to get data that's consistent from both of them. They don't really want me to do it. They probably don't want me understanding how much I'm spending on my mortgage and how that's affecting my well-being. So the interests just aren't really aligned.
Here's another way of looking at exactly the same thing. Here's Kiwibank, which is a little bit smaller than ASB. They're just glorified filing cabinets. My data is in those filing cabinets. I'd like it out, please. Can I look at it and interact with it, and weave it together in exciting ways?
So the filing cabinets are going to be a little bit of a theme of this talk, unfortunately. Here's the situation we've got. We've got content bound in a location. We have my data, stuff about my identity and my transactions, stored away in a particular location with some sort of wall around it. And then here's me interacting. Here's other people.
So we've got this situation where people are orbiting these locations. It's this content-centric model that we're stuck with at the moment. And this is all right. What gets difficult is that there isn't just one location that we're circling. There are many.
And so these could be multiple banks that I'm trying to interact with. I believe government's exploring sort of-- I can't remember what you're calling them, but user journeys, where like, I might like to apply for a student allowance as a student. And I want to-- and I don't know where to start. So maybe I start here. I come to WINZ? I don't know where to start. I knock on WINZ's door, and they tell me that I need to get my tax stuff signed off. So I have to go over here, but they've got different forms. So I fill those forms in, but then I need to go over here, which is the university. And they've all got different versions of my identity and records. And it's all quite confusing. So you end up with this a bit of a goose chase around these filing cabinets.
So what have I got written here? Yeah. So siloing of data, having to deal with duplication and de-duplication of like, different versions of the same data about who I am and what is relevant. Debating API formats and specifications-- I think we heard a little bit of that earlier today.
And authorization-- everyone's going to want to know who you are and have different requirements. There are different solutions to that. You could go down the-- well, let's just build another one, another filing cabinet, which tracks who you really are, and then have that talk to these, and hopefully that will work.
Or you could go the route that China's gone, which is like, make the mega platform that everyone plugs into, but the state controls that, which has got interesting, different side effects. But it's interoperable, right? So that's pretty slick.
So we have this content-centric paradigm that we're dealing with, and it's all founded on this assumption that data has to be bound to a location. I have to go down to Immigration New Zealand and knock on them and ask them to access their paper files, or go to immigration.govt.nz, and access the files through some API or some form. It's all about having to go somewhere to get something.
But there's a possibility that we don't necessarily need to live in that world. So this is a bit of a shift sideways. There's a bunch of cryptography which has come out in the last 10 or 20 years as well. Easiest way to describe it is Rumpelstiltskin.
Quick primer or refresher on the story of Rumpelstiltskin-- it's a fable about a cheeky imp who makes a deal with someone. The details of it don't matter too much. But basically, he's going to take the firstborn child. And he's like, unless you can guess my name. And she discovers Rumpelstiltskin's name and says, perhaps, she said, your name is Rumpelstiltskin. And with that, because she knows his "true name", she can undo the magic of this agreement she's made.
So it turns out that there's also a thing of like, true names, more generally in fantasy writing, where there is the true names of people, but there's also the true names of objects, so that if you know the true name of a rock, you have magical power over it. If you know the true name of the wind, you can shape the wind.
Thanks to the magic of mathematics and cryptography, these things really exist. For people, it's public/private key cryptography, and for objects, there's this concept of hashing algorithms. You don't need to know what they're called.
But it means that we can now tell stories like this, where instead of having to think about me filling a form and it being filed in a particular cabinet, I can apply for a student loan by saying, I would like to apply for a student loan, into this sort of conversation circle. And this piece of content has a true name. It's the form that I filled in. And anyone who knows that name can summon it to them from the peer-to-peer cloud.
And it happens that the relevant parties-- could be WINZ or IRD-- are listening to me. And they say, "Oh, that's interesting. Yeah, that's all good. Go ahead." So there are no filing cabinets. And I didn't necessarily even need to know where to go.
More details about privacy and security-- don't have time in 10 minutes.
So what this can look like at a bigger scale is, people all around New Zealand saying things or preparing documents or forms or whatever like that, and then people listening to those and interacting with them, and in quite a conversational way. And so this is a shift from a content-centric to a sort of more people-centric data flow.
And because there are no filing cabinets, this also has really interesting things here-- resilience side effects. So this isn't a fairy tale. It's not fantasy. People in New Zealand are already building this. This is a blogging platform built on this, on the internet.
People have got content that they're already writing. I'm having a conversation about accessibility with interfaces with someone in Australia. And I'm having conversations with other dads about how to be a new parent, because I'm a new parent.
People are running workshops on mycology, and building things with mycology. I've got my talk also running on this system. So if anyone wants to use any of the resources or sweet drawings that I've done, that's all open-source. So it's out there, not in a filing cabinet, but drifting around.
So in summary-- so that's called Scuttlebutt, by the way. Happy to talk more about that afterwards. In summary, let's learn from the past. Don't build APIs where you have to like, build meta APIs to use the APIs. We can do something better.
Let's build people-centric platforms. Let's build systems that are more resilient. If you build in a different way like this, it'll be resilient to earthquakes. You don't even need the internet to run it. And it'll be more flexible. Thank you.