Picos and Decentralized SSI Agencies

There we go, sorry for all of the trouble and confusion. I wanted to do a live demo, which caused a staff to have the laptop and all of that. My name is Phil Windley and I'm gonna be speaking today about Pico's and decentralized SSI agencies, which is a mouthful, hopefully by the end of the talk. You'll understand what I mean by that. And you'll know what a Pico is. You'll know what an SSI agent is and an S I SSI agency, and why we might want to have one of those things be decentralized or distributed. I've got no control over this. Here we go. Okay.

We found a way, you know, on any computer, there's always 20 different ways to do everything. So you can always find one that works. So this is the agenda. We're gonna talk about what Picos are, why you might care about them. What are SSI agents? And then I'm gonna give you a demo of Pico's as SSI agents. And then we're gonna talk about a distributed agency and then finally, what it would take to make that fully decentralized. So Picos are a way of programming things on the internet, which allows us to create fully decentralized applications.

And we're gonna talk about why that is so, so Pico is a neologism, a new word for persistent compute object in 2012, Mickey McManus. And some others wrote a book called trillions in which he posited an internet of things world that had trillions of nodes on the network, not, not 50 billion like Oracle was talking about, but literally trillions. And the point of trillions was that this difference in scale is so large that it represents a difference in type that a trillion node network is a fundamentally different thing than a billion node network. And so we needed new techniques to build it.

And one of the, the things he talked about was these things that he called a persistent data object, meaning there would just be these packets of data that would be floating out on the network and they would be there persistently, and we'd be able to access them. Not, not like we think of a website, but something more like a package of data. And I picked up on that and thought, oh, that kind of matches what we're doing. Right? We are all working on something.

We call personal clouds back in those days, which you know, was we'd come to EIC and talk about personal clouds and why they were important. And persistent data object kind of felt like something very similar, but I decided, well, why should they just be data objects? Why shouldn't they just be compute objects? So this idea of a persistent compute object took hold in my mind. And I started working on this with, with a bunch of other people and Picos are persistent in three important ways.

First, they have a persistent identity, meaning that if Pico doesn't change what it is or what it does, Picos get created for something or to represent something. And they have that same identity for their entire lifetime. And that lifetime could extend over over months or years. I have Pecos that have existed over periods of years, that, that I use. I'll show you some in a, in a little while. They also have a persistent state meaning that they keep track of their state and they, they don't lose it. It doesn't have to be reset when you restart the Pico.

The peak comes up with the same state that it had before, and they have persistent availability, meaning they're always online, as long as they can find an engine to host them and, and, and be, you know, have the services they need. So Picos are an actor model programming system. So actors send messages to other actors. They can create other actors and they make local decisions based on the messages that they get. This actor model is something that was developed by a person named Carl Hewitt way back in 1973.

I, I think the best way to think about actor model is that if you imagine what Alan Kay really wanted, object-oriented programming to be, it was probably the actor model, right? That is not what we think of with Java and JavaScript and things today. It was more like what small talk was back in the day. And this gives us some very important properties. First of all, I'm probably the most important is lock free concurrency. You can create systems of decentralized Picos that interoperate with each other with no threads, no locks.

The programmer never has to think about how all of this might be working. We get isolation, meaning the state is isolated from everything else in a very, very strict way and location transparency, meaning they don't care where they're operating. They wanna talk more about that in some detail today, cuz that's an important point about what, what I mean when I talk about a decentralized agency. So I'm not gonna read all of this to you.

I actually have a blog post that talks more about why all of this might be important, but Picos have a very internet friendly programming model they're designed to be internet first actors, meaning they, they don't take the internet as something that might be there. They're always connected to the internet. Huh? And they have a cloud native architecture. And this is something which I think we often forget as programmers.

We talk about the cloud infrastructure and then you've probably all heard the term lift and shift where we just take our on-premise application and put it on this cloud infrastructure. And often that doesn't go very well because the on-premise application was not designed to be cloud native, right? Pico's help you build cloud native applications. And that's a whole thing. There's a whole reactive programming manifesto. If you're not familiar with reactive programming, it's actually a very interesting development in the last three or four years, I think is quite interesting.

And Pecos aren't the only actor model programming system, this reactive programming model, it was done by a, by a group that uses AKA, which is another actor model programming language based on scholar, Probably the most important things for what we're gonna talk about today is they provide a better model for building the internet of things. But most importantly, they are sophisticated SSI agents, sovereign sovereign self self sovereign identity agents. And we'll talk more about that. So why not Pecos? Why isn't everybody flocking to these? I just told you how great they are.

Well, they use a rule based language that I think is uncomfortable for many developers. And you know, we could have a discussion about whether that's a good design decision or not.

I, I happen to think that it introduces a programming model that is very, very useful for decentralized agents. But you know, that's a, that's a discussion that maybe we can have over coffee later, but let me show you what I mean by that. This is an example of a rule. So Picos are programmed by creating rules and a Pico's program is essentially a collection of rules and a Pico. Could we, could we ask that you keep it down just a little bit, I guess I'm moderator. I can do that. Right? So a Pico might have hundreds of these rules, probably not thousands, but certainly hundreds of these rules.

Sometimes they're very simple. They just have a few rules in them, but this is an example of a rule. So what does it say?

It says, well, this rule gets selected. That's that first line, when it gets a message of car Voyant admission status, this is actually a rule from a connected car platform I built called fused, which was all based on Picos. And when that happens, then it makes some calculations. That's all of the stuff in the pre block. And then it does a test. And if the trip ID is no, if it's not, no, then it does some things else. It does some other things. So what are those things? It does well, it raises other events.

So one of the things rules do is they raise other events which cause more rules to fire. And those might be events that get sent to some other Pico or they might get rule, be, be events that happen on the current Pico. In this case, these are being raised on the current Pico.

If, if they were on another Pico, there'd be a different syntax that, that showed us that. So this is an example of a rule. Like I said, some people get, you know, turned off by this. It's very uncomfortable for some programmers. So that's probably one of the biggest reasons why not, but let's show, let's talk about how rules combine to make something happen. So in this diagram, what you're seeing is you're seeing the event bus, which is the purple thing in the middle and over on the left hand side. And I apologize, it's a little bit of an eye chart.

There is a, an event coming in called P PDs profile updated. And when that happens, this rule on the lower left fires, because it has a PDs updated profile, updated select statement, it raises more rules, which cause other rules to fire. And so there's this cascade of rules that are firing and causing things to happen within this.

And ultimately what thought, what this does is it actually, as you can see up in the upper right hand corner, it calls out to an external API and it also sends a notice to another Pico about all of this stuff happening and what happened while it updated the profile, made sure that all of the trip data was okay. It actually needed quite a bit in response to this one event that came in. So where did Pico's get used while we've used them in a number of places we built a intention economy.

If you're familiar with that phrase, it's a doc circles phrase, an intention economy, proof of concept for, for swift almost a decade ago, which was quite a elaborate and had many people from various places were working on it. We built a guard tour application, a guard tour is, you know, when you have a building guards move around from place to place when the building's close and they have to prove that they were there. And so we built an application and each location was a Pico and the building was a Pico and we modeled it as a collection of Picos and how they responded to things.

And of course the guards were Picos and the supervisors were Picos. Everything in the system was modeled as a Pico. I talked briefly about the connected car platform called fuse. It had about a thousand devices in the wild and I think three or 400 individual vehicle owners who were part of this system. And we ran that for about two years until the company that provided the devices went out of business.

And at that point it was just, you know, too much to, to redo all of the devices, manifold, which I'm gonna show you in a minute is a kind of a general purpose Pico interface that we use for things like keeping track of things. I'm gonna show you that we use it for SSI agents as well. We've done a priority registration proof of concept. So this is, you know, students come in and they need to register for their classes and you know, they all want to register at the same time. And it turns out that when you look at what's going on in the system, they, they all hit the same database, right?

Cause that's how we build things. We have this kind of single database that keeps track of things. And could you re-architect the system? Sure. And that's, that's, that's not the point. What we did was we modeled it all where each individual class section and BYU does about 9,000 sections per semester. Each individual session section was a Pico. Every student was a Pico.

And now when a student hits a Pico, it's got an isolated state, it's not hitting some central database, but rather it's hitting the isolated state of the Pico, much more decentralized and thus much more performant for what we were trying to do. And we're also doing a domain data store, proof of concept, very similar kind of idea to what, what I was just talking about. So Picos present a fundamentally different model for how we think about data online. And so now we're transitioning into more of the, you know, why, why does, what does this mean?

And why might it look like a self-sovereign agent territory? So this is the traditional IOT model. You go by a device, say a Fitbit, you download Fitbit app to your phone and you connect to the manufacturer's API and they keep a bunch of data about you, which the app on your phone shows you, right? And of course you have an account at Fitbit. And if Fitbit, for some reason, decides that they don't want to, that you don't need an account for whatever reason, they don't need any reason. Right?

They could just decide to close your account because you have blue eyes who knows your Fitbit is useless, right? This thing that you bought now is just an, a very expensive piece of plastic, right? So this is the traditional IOT model that we've, that we use most of the time. So this is the way the model works. When we think about it as the self sovereign internet, right? Or this is how fuse for example worked. So now the manufacturer is still there and the device is connected to a Pico that's connect.

That's keeping all of the data about you, but the gray box represents that this is all within your control, right? So infuse, for example, everybody had their own little sphere of control that they could have taken somewhere else. They could have run this on their own computer somewhere if they chose to, because it all could be moved without any loss of functionality. So this all runs on something. We call the Pico engine. This is talking about some of the changes we've made recently. Pico engine is a fairly mature piece of technology.

Hundreds of people, hundreds of people have programmed on it and used it. We have pretty good documentation for it. And it it's all based on, on nodes. So fairly robust platform underneath. Now why that matters is because Picos get hosted on engines. And so this diagram is meant to show what we have is we have a number of Pico engines and those Pico engines are hosting different. Picos you'll notice that the Picos have connections to each other, that don't rely on the engines.

So while the green Picos are running on the green Pico engine and the pink Picos are running on the pink Pico engine say that fast that their connections to them don't depend on any connections between the engines. In fact, they have independent connections between each other. Now we're starting to get into this idea of self-sovereign agents, right? That these things are acting independently. And in fact, what we're gonna talk about later is we could take one of these Pecos off the green PECO engine and move it over to the blue PECO engine. Nothing would change.

Everything would continue to function exactly as it had before, without us having to do anything other than just follow the import export rules for the Pico. So now I'm gonna do a demo. So let's hope this all works that I can make this happen. And There we go. It is working. So this is just a brief demo. I've got another longer one later. I just wanted to show you what the Pico engine developer experience looks like. So this is some Picos running on my laptop and you'll see that there are five of them here. There's always a root Pico.

And in this case it has a child called the sensor community. And if we click into that, you'll see that it has three children, which of course we can see here as these three children. And there are black lines and pink line pink dotted lines up here, the black lines represent parent-child hierarchies, cuz an actor model always has parent-child hierarchies kind of like object oriented programming, very similar idea. But the parent child hierarchies are just how the Picos are managed, how they're created. They're not actually the connections that Pico's used to talk to each other.

Those are the pink lines, right? So in fact the, the, the sensor route is connected to both the sensor movie and sensor orange. Those are just random names that got created when these things were created. And those pink lines represent the lines of communication that those Picos have with each other. They're they're the same things that I was showing you earlier that, that had the, you know, different, different lines between Picos on the engine. So I won't go into detail here about how this, how the whole developer experience looks, cuz we are running out of time, but I will. Let's see.

I'm just trying to find my presentation. There we go. All right. So how's this all relate to self sovereign identity agents. So if you're familiar with self sovereign identity, the basis of self-sovereign identity are these things called decentralized identifiers. And without going into too much detail, a decentralized identifier is essentially an indirect reference, a pointer to a public key and a location, right? There are lots of details about how that works, but the fact that they represent public keys means that Alexei and Bob can exchange DIDs, which they've done here. Right?

Alice has given Bob a did. Bob has given Alice, did they keep track of this interchange in what we call the key event log? And that allows them to know what's happened. So if Alice rotates her public key, Bob will know about that.

These are, think of them like Google docs. They work like Google docs, right? If Alice rotates her public key, Bob sees that change because he has a copy of it.

You know, as, as a conflict free represented data type. So what can they do with those once they've exchanged DIDs because DIDs are pointers, do public keys, they can now sign things. They can encrypt things. And they have a secure messaging channel that is just peer to peer between Alice and Bob. We can create lots of relationships. So in this case, Alice has a relationship to Bob has a relationship to Carol has a relationship to Bravo Corp and a tester Corp and certify Corp. And she can have a relationship to things. So in this case, she has a relationship to her coffee grinder.

That's represented by the coffee grinder, Pico, and they both have relationships to with Barraza. This is actually a discussion we had with doc STS. That's where this, this came from. So now let's show what that means inside Picos. So this is a different interface than I showed you before. This is called manifold, but each of these square cards represents a Pico and they have different rule sets running on them.

And so, in fact, I I'm using these to keep track of things that I own, like my, my bag for my bike and batteries for it and other things. But what we're gonna do is we're gonna create a Pico and we're gonna call it Alice, I'm gonna create another Pico. I'm gonna call it coffee, grinder. Excuse my I'm doing this with one hand. So it's a little harder. Okay. And then what I'm gonna do is I'm gonna install on both of these, an application. I'm gonna install the manifold cloud agent On both of these. So I'm now installing an app. I'm installing a rule set, right?

That's essentially what's happening on each of these Picos And you can see what apps are installed down here at the bottom. So I'm gonna click that. I'm gonna enable connections for that one. I'm gonna enable connections for that one. Okay. So now I've got Alice and I've got her coffee grinder and we're gonna have Alice connect to her coffee grinder.

Now, normally what had happened is the coffee grinder would come and have a QR code or something on Alice scan, the QR code. And that's how this would work, but we're going to do this a little bit manually. So I'm just gonna create this invitation. I'm gonna come up here to the coffee grinder and the coffee grinder is going to accept it. And now you can see that both Alice and the coffee grinder have a relationship with each other. So Alice has a relationship with the coffee grinder. The coffee grinder has a relationship with Alice.

And if I click into this, one of the things I can do is I can send messages. So this is not, you know, I'm, I'm not showing you an IOT protocol here, right?

But, but imagine that this were a protocol, right? And, and in this protocol, Alice sends the message. I want fine Grind at 9:00 AM. And she sends that message. And you can see up here, the coffee grinder just got that message, fine grind at 9:00 AM. Now these two Picos could be operating on different Pico engines, a world away that connection is a did come connection. So it fully encrypted by the did com they exchanged DIDs. I can come in here and look at this advanced section and you can see, you know, there's, there's the DIDs that, that got exchanged by these things.

They could create as many interactions as they wanted and have this fully self-sovereign interaction. And they could be doing something very sophisticated that that involves some protocol. In this case, they're just sending messages back and forth. So I just demonstrated that Pecos can operate as self sovereign identity agents. But unlike many of the agents we think of in self sovereign identity, they are fully computationally.

They, you can put rules on them and do almost anything you want on top of this SSI agent. Now I'm sure that other SSI agents are gonna get there, right? They're they're gonna have to, but, but the point is right now, Picos are, as far as I know, the only programmable agent SSI agent that's available, and you could program them to use that SSI connection for almost anything you want. Like I said, we showed how you can use them to exchange messages. You could use them to issue and verify and prove things from verifiable credentials, right?

Cuz that's another protocol we have implemented the tic-tac toe protocol on them. So you can use them to play tic-tac toe. That's probably not a very useful way to, to do it, but you could could do almost anything else you wanted to do on top of an SSI did come connection. So we now have SSI agents. And what do I mean when I talk about a distributed agency, I don't want the, by the way, an agency is somebody who hosts and run agents, right?

So if you're familiar with ever M they're an agency east O is an agency, all of these companies that are hosting SSI, wallets and cloud agents, they're all agencies, right? And that comes with a certain responsibility. But what if we wanted it to be more distributed than just a single company? What if we wanted to have multiple companies, running agencies, running an agency that all of these agents could operate on. You could imagine each of these Pico engines being run by a different company and the Picos being agents on top of them.

And because it's a single agency, you ought to be able to have your, your Pico running on any of these engines without you, you don't care, you don't care where they run. So maybe you want your agents, agents to follow you to Germany because you don't want the latency that's involved in wherever your agents happen to be hosted like the us or Japan or something like that. Maybe you found a cheaper place to host them.

And so, so you might want to move them around. So what does it take to make this distributed few, few pieces of work? And this is some of this is gonna make sense if you're familiar with Aries, some of it won't, but we need better Aries library support we're like on did com 1.0, we need to be did com 2.0, we need CDTs for the did exchange. We're not doing that. Right. DHT for indexing. There's some engine performance issues, immigration protocols, and APIs, so that they can move between engines freely without having to be a manual import export.

And we need to figure out what it means to have pools of engines so that engines can know what what's happening. Okay.

So, so that's what it takes to be distributed. Now from a distributed agency standpoint, you can imagine it being governed, right? So there's some agreement that all these companies have that they're gonna use. What if we wanted to be fully decentralized, right? So to make it fully decentralized, we need a few things.

One, we need to have DIDs the, the main way that Picos get addressed so that they have addressing independence. We need the Pico data to be on IPFS that could be cashed in the engine, but we want it to be on something like IPFS so they can move between engines without, without worry. The next one is really important. We need the engine not to be able to see what's happening in the Pico. I don't know exactly how to do that. I have some ideas, but that's a big, that's a big lift that we could use some help with. And finally, we need ways to compensate engines.

We need Pecos to be able to make payments, right, so that they can pay the engine so they can pay each other. So that's, that's another one. So a few things as I wrap up first, come contribute. If you want, we have monthly meetings, contact me. If you're interested in working on this or playing with it, be happy to have you have, have you help. Here are some resources, an introduction to the after model programming, the labs for learning about Picos.

And finally, the documentation I'll leave that up for just a second, because the only other thing I want to do is just tell you that I'm gonna talk about did come messaging this afternoon at five 40, it would actually have been better. If I talked about did come messaging and then gave this talk, but I didn't make the schedule. So if you're interested in did come messaging and understanding the self-sovereign internet, come at five 40 in Bondi over, over, up on the second floor of the hotel.

And, and we'll talk more about that. And that's, that's all, so thank you. We're probably out of time probably no time for questions, but you can catch me at the conference and ask me anything you like.