So I'm going to talk about DID PLC, which has a few sort of slightly surprising properties to it. It's a slightly confusing system. What does it mean? A self-authic authenticating decentralized identifier, which is strongly consistent, recoverable, and has key rotation. Okay, so four things. Strongly consistent, recoverable, self-authenticating, and key rotation. And the slightly weird thing about this is it does have all these properties, but not all at the same time. As far as I I'm aware, it's tech technically impossible to have all these properties at the same time. Let me explain what I mean. So what do we mean when we say self-authenticating?
We mean that you can look at the data and you can confirm it's valid without looking at anything else. Okay? So the classic example is an IPFS document. If you have the ID of an IPFS document, that is a hash. So if somebody you don't trust gives you the document, you can then recreate that hash and make sure that it that it's correct. Okay. So how does this look in DidPLC? Well, when you first create a new account in DID put PLC, it's exactly like that. So you're for your for your first account, you make a document, you put in, for example, your Bluesky handle, your PDS, um, a load of other stuff, and you put in the key that's going to control this account.
This is called the rotation key, and you take the hash of this document, and that hashes your ID. Okay? So this is exactly like IPFS, um, self-authenticating content addressed. Then if you want to make a change, what we're gonna do is we're gonna replace maybe one of the, maybe replace the handle, replace one of the one of the fields in there, and then we're gonna sign it with the key that we stated in that previous update. Okay? Um so this is also cryptographically verifiable. This is also basically self-authenticating, assuming you've got the whole chain. Um, if I want to check this, I can check the signature on this second one.
I can then check that it matches the key in the first one, and then I can check the hash of the first one. So I can authenticate the whole chain, I don't need to ask anybody else. Okay. But we also have this property of key rotation. So what happens when we want to rotate the key? So the first thing we're gonna do is um we're gonna make a new document with our new key that we want to change, and we're gonna sign it with with our old key, okay? And then once we've done that, we can now sign all our future updates with the new key.
Um as and as far as for normal key rotation, that means that it doesn't matter what happens to the old key. Okay, we can leak that on the internet if we like. It doesn't matter, it's rotated out. You do this because you no longer trust the old key. Okay. So that's what we've done. The problem is what happens if somebody does this. If somebody takes the old key and they put an update chained on top of one of my earlier updates, and they pretend that these later updates didn't happen. Okay? So if you have this situation where somebody is in quote in control of one of your old keys, this is no longer self-authenticating.
Okay? It's no longer self-authenticating because we did key rotation. So we've got these kind of really different properties, even though we have this we all have DIDs and they look the same, different DIDs have really fundamentally different security properties. Um, some DIDs, your your initial document is self-authenticating a content addressed. Okay. Um the one that you then updated is also self-authenticating. Okay. Right down at the other end, if you've rotated your key and the earlier key has leaked, then this is not at all self-authenticating. Okay. And then in the middle, there's this situation that a lot of people who have migrated their PDS are in, where you have the key in your history, but that key hasn't leaked.
So if you're on Bluesky, you've probably got their rotation key in your history. Um, but that key as far as we know is still secure. So there is only one chain of your identity, um, but we don't know what will happen in future. So this situation at the top is very, very blessed, right? This is wonderful. This is just like this has the same security as like an IPFS hash or a Bitcoin or an Ethereum address, or for example, a Nostra ID. So if you run into like an Nostra enthusiast who is concerned about, like I heard about this central server that I'm gonna talk to you about, you can tell them if you are happy with the Nostra feature set, right, because the way they do it in Nostra is just don't do key rotation.
You just don't lose your key. If you're happy with the Nostra feature set, you can have Nostra style security with DidPLC, right? But but once you use this feature set, in certain circumstances that are kind of out of our control, we then lose this security property and we end up with kind of a really differently secured system. So right down at the bottom, we're not self-authenticating. We've got Sabako crawling out of our TV screens, our DID is cursed, we can no longer verify just by looking at it whether it's correct or not. Okay. So the solution in DID PLC is to use a trusted sequencer.
So the job of a sequencer is to say this is when this update was published. And since I know that this one was published earlier, I then know that the evil one that we did later is invalid, right? So they can choose the canonical chain and the like the correct way to resolve your ID. And there's another slightly confusing thing about the DID PLC system, which is that this server actually has two jobs. And they're really really different jobs and have kind of really different properties. So it's a sequencer, but it's also a data publisher. You didn't have to do these together, right?
These are fundamentally different things. They could have been different roles, they could have been done differently, and they have really different implications. Okay, so what happens if this trusted server goes rogue? And you might think, okay, why is it going to go rogue? Give you one example of what I mean by rogue. So we had this issue in Turkey, where there was a legal proceeding in Turkey that said that Bluesky had to ban some Turkish dissidents, okay? And they they didn't do this at the level of the directory, they did this just at the level of their PDS.
But what this shows us is these well-meaning people, they are not in the tank for the Prime Minister of Turkey, right? But well-meaning people can have pressure put on them to do things that they will not necessarily want to do. Okay? Because they live in the real world. If they didn't do that, they couldn't change planes in Istanbul. Um, and potentially, for example, the Bluesky app would be banned from the app store, at the very least in Turkey and potentially everywhere else. Okay. So there's now a plan which until until today I thought was a good plan to go with a separate organization.
Um and then just thinking about my own talk, I realize it may not be a good plan. Um, to go with a separate organization that's going to run the directory. There's going to be a board of trustworthy people on this um, you know, uh on this board in control of it, and they're genuinely, you know, as far as I can tell, trustworthy people. Um so let's assume that we succeed in the task of keeping psycho psychopaths off this board, which is an unsolved problem in like human governance, right? Generally, you know, the the first generation may not have psychopaths, but you they they seem to somehow get there.
But let's let's assume that they're all honest, well-meaning people and they care about atproto. Um let's look at a at a similar example. Private universities in the United States have a kind of a similar governance structure. And they're actually a really good case for this kind of governance structure. So if you're trying to govern a private university in the in the US, you've got a bunch of alumni who really care about the institution, right? They really care about the school. Um, and if they don't care about that, they care about their own personal reputations. So this is a really good case for this governance that we're that we're doing with PLC directory.
Um but what happened was that the Trump administration put pressure on them and took a bunch of things that they cared about hostage, right? So they said, if you don't do the things that we want that we don't normally have the rights to make you do, we are going to cancel grants that your researchers are due. We're going to cancel the visas of overseas students at your university. So these people were put in this dilemma where they can do the thing, they can have the policies that they think they can have or they can compromise. And if they compromise, then they're going to end up hurting far fewer people than if they they do what they're being told to do.
Um so ultimately what, for example, Columbia and a lot of other universities did was they threw trans people and Palestine protesters under the bus to protect the majority of their institution. Okay. So if you think about this with atproto, if you care about app proto, there are all kinds of ways that people can put pressure on you, right? Can you get appropriate proto apps into the app store? Are you gonna have network-level blocks of the PLC directory? All things that all kinds of things that you could do that will potentially put a dilemma on the people who are in who are governing this structure, even if they're well meaning people and cause them to do something that we may not think is what the social contract would tell them to do.
Okay. So let's assume they go rogue. Um, can we just do things? Because I've got my client, right? It's it's free software. We've got our relays, we know anybody can run the relays, we've got our own PDSs. There's nothing that says that we have to look at the PLC directory. We can do what we like. So if I've got a self-authentic DID, this is probably actually okay. So here's what we can do. Somebody can set up the too hot for PLC directory. The records that are being messed with by the PLC directory, what we can do is we can query the PLC directory, we can look at our own data, and if the PLC directory refuses to answer for that record, or or if it's done some weird weird real, or well, no, if it's refusing to answer, or if it's not giving us the whole chain of updates that we've got, then we can just serve what we've got.
Okay? And the great thing about this is we don't really need consensus to do this, right? We we can have like bitterly um mutually detesting factions of app proto, and you can make your directory and I can make my directory, but since this is self-authenticating data we're looking at, we're ultimately all going to get to the same result, right? As long as we share the data, we can all get to the same result. Um so we have this property that we wanted, I don't know if we still have strong consistency. I I think we do. The problem is, okay, what about the the sequencing part?
Because the sequencing part is something where only the directory is allowed to make a decision, right? And so the the sequencing, it's making a decision about what time did I receive this update. And somebody else may honestly get the get that update at a different time. So sequencing requires us to just have this single directory, and that's why it's designed like this, okay. Um so we can do things, but we all need to move together. We need to do like a flag day, we not we need to all say, like from this day onwards we're using somebody else for the for the um for the directory.
So can we do that? Umbe we can. Um there are some sort of favorable precedents. So this happens in free software all the time, right? Um so Oracle took over OpenOffice and did all kinds of nasty Oracle type things. And the developers and the users of OpenOffice just all just kind of all got together and decided to use a different project, different GitHub repo, um, different brand, and everybody moved to LibreOffice and basically nobody uses OpenOffice anymore. Um, same thing with um with with some some blockchain systems. So Steam was one where where there was this thing where um the developers of a protocol for some reason that I don't quite understand, had particular rights to do things for the protocol.
Um and Steam got bought up by Justin Sun, who is this kind of crypto comedy villain. Um the community, both the developers and the the user didn't want this, so they forked the project to hive. They said, from this point in the history, um, like from like 10 o'clock tomorrow, um, we're gonna use our own version of the software, we're gonna take out all the special privileges that uh that just in some would have had, and we're gonna carry on. And they did that and it worked. And it's it's often been done and it's often worked.
So, what have we got to do to to replace a malfunctioning PLC directory? Um we all have to recognize the problem, okay? We have to agree a new person who's gonna run it, and we have to get a snapshot of the directory from some point in time when we're gonna switch over and start using the new one. So the first problem is do we agree that it broke, right? So ideally, the rogue directory would say, we're going rogue, right? We're gonna screw you all over. This is now the wrong picture. This should be this should be filled for now.
Anyway, um, like I ideal, ideally they were actually announced that they're they they're gonna screw us over. Um the problem is they're the adversary, right? They're not trying to be helpful to us. And the adversary gets to pick the battle, right? So if their goal is, let's say that they've decided there are a bunch of bad actors on app proto, and they need to get these bad actors out of the directory so that they can get at process spreading properly in corporate environments which are stubbornly resistant, whatever they want to do, right? Um, they get to set the precedents so they can re-org out Jesse single.
I don't know if you're familiar with this guy. Um there's a guy who's really, really unpopular on Bluesky, he writes um nasty things about trans people. Um Bluesky users are always badgering Bluesky to ban this person, and Bluesky is saying, well, he hasn't actually violated the terms of service, so we can't. If you do something that looked to me looks rogue but is re-orging out Jesse single, this is very popular among Bluesky users. Um another thing they can do is they can pick at the factional fault lines. So right now we're at this very blessed time of a new decentralized community where basically everybody's friends, and you can just see here and there the little green shoots of what in the future will be a vast forest of bitter factional grudges.
And they can work on these, right? You know, they can they can do do something to somebody who's a bad guy to one of the factions, the other faction loves us. Because what they've got to do here is they've got to prevent us from forming consensus. And it's much, much harder to to form a consensus than it is to disrupt a consensus. Forming consensus is really hard. So if we're trying to form a consensus about we're gonna move over to this guy because of this problem, they get to pick at those fault lines and make it hard for us.
Okay, the next problem is do we have an up-to-date mirror? So right now there's loads of really good work going on in Bluesky and outside Bluesky to make it really easy to run a mirror of the PLC directory. So ideally what happens here is loads and loads of people have got their own mirrors, people aren't really relying too much on the PLC directory. But in any case, we can always get the latest data and we can say from this point in time, we're not using the old directory, we're using the new directory. Okay. The problem is that they're the adversary, right?
They're not trying to help us, and our ability to get this mirror is dependent on the adversary. So if you look at what any organization does before it screws the users over, the number one thing, day zero of in-chitification, is to dismantle the accountability mechanisms, right? Dismantle anything that will give your users the ability to exit. So for example, if you're Instagram or Reddit or Twitter, then you're gonna um you're gonna turn off your API. This happens before the the the actual like the algorithms go to shit and your and your application experience becomes useless. First you turn off the APIs and then you wait a bit.
And that way nobody else has got a way to give you to to help you exit to give you an alternative. Um another example, week one of the Trump administration, on the first Friday night, he fired the 17 administrat inspectors general who were supposed to be the independent observers who would take who would like hold him accountable for corruption in his administration. If you're actually going to do corruption, you remove the the things that will hold you accountable for corruption. Okay. So what would it look like? Well, the the mirrors just sort of stop working on a Friday night, you know?
Um nobody seems to be able to pull from them anymore, don't know what's going on. I'm hitting this endpoint, it's not working, it's working for me, it's not working for you. Um, you know, you get somebody to answer on a Tuesday and they'll say, Oh, we're looking into it, you know, maybe waste our time a little bit, give us like a URL for some log files, say see if we can help, you know, see if we can diagnose the problem, and it's like eight terabytes of just irrelevant log files, you know. Um they've got all the cards here.
Another thing they can do is they can spam the mirrors to death. Because what one of the amazing things about this system is that it's designed to kind of hold infinity records. Like the there's there's no cost to writing to it. The only limitation on putting loads of stuff in the PLC directory is that the operator is doing some rate limiting on like IPs and PDSs and stuff like that. But in theory, as far as I know, everything is supposed to go in there. So um they can allow other people spam in there, they can turn off the rate limit until the until the mirrors fall over.
They can also create their own spam. Um and the great thing about creating your own spam is you can do this deterministically from a secret seed. The mirrors have to hold all the data to have a complete set. You don't even have to hold the data, all you need is your C and a serial number, and you can serve it. Um so that they've got all the cars when it comes to like spamming the mirrors and just making it impossible for people to hold them accountable. Okay, so what can we do to mitigate this? I should be clear, these aren't quite solutions, but they will help.
So we can run lots of mirrors, right? And this is something that that's that's that's already like um already happening a little bit. Um we can, when we write, instead of writing to the PLC directory, we can write to the mirror and have the mirror keeper log and share what they write, and then forward that on to the directory. So that way if the directory isn't giving us all its data, um we should still kind of maybe be able to piece some of it together. Um, try to get consensus on what the mirrors are actually showing us.
Um so if the mirroring stops working on a Friday, we want also we at least want to know that as of Thursday we all we all know what it should be showing. Um there's then some technical things that that I'll come to. This is really important. We need to figure out what is the social contract to DID PLC and get this really clear and get this clear as soon as we possibly can. Like I read the spec with my crypto brain and it talks about avoiding censorship. And to my crypt, like in crypto, like if you're preventing a ransomware payment from going to King Kim Jong-un, that's censorship.
But like I don't know what the rest of the like the app proto community thinks about this. Like, is it is it the job of the PLC directory to accommodate everybody, you know, spammers, scammers, um malware authors. Are they all supposed to go in there or not? Like what's what's the deal? What happens to you know child porn or accounts linking to child porn? What is the actual job of the of this directory? What is it that would tell us if it was going rogue? I don't know if that's clear to some people, it's not clear to me.
So and and the later we leave this, the harder it is to figure it out. Um at least because we'll have all the factional um squabbling. So some more things, some practical things you can do. Keep your ID self-authenticating, right? So remember I said earlier we had the blessed DIDs where where you could fully validate just from uh available data, and we had the cursed DIDs with Sadakor crawling out of your TV screen where we potentially had a fork in the timeline, or or we had like potentially somebody could create a fork in the timeline. Um if you keep your own rotation key, if you when you sign up, you make your own make your own rotation key, write down the seed phrase or whatever, whatever you do, um and don't lose that, you probably never need to change it, right?
I mean, you know, Nostra doesn't do rotation keys, seems okay. Um there's a there's a there's an obvious pattern if you're using um most outprocess stuff where you feel like you you you register on Bluesky first and then you move to whatever PDS you were hoping to stick with. Um it's better if you can just go straight to the PDS and that way you don't have this rotation key in your history that um that is controlled by Bluesky. Um I I don't quite okay, I put don't use it. This is a slightly slightly uh too strong a case, but it but there's this um remember we had recoverable in the four um features.
So it there's this feature in um in DID PLC where if you have a high profile, like a high priority rotation key and a low priority rotation key, you can cancel the actions of the low priority one with the high priority one. Um this is sort of useful, but it automatically creates this fork in your DID, right? It automatically causes SADA code to come crawling out of your TV screen and and and reduces your um your the security properties of your account. So one more thing. If you are hosting PDSs for somebody else, a dead rotation key is toxic waste, right?
Plan the life cycle of your rotation keys. Um if you use, I know if this is still true, but when I tried it, if you use the stock PDS from from that Bluesky provided, um it will set one rotation key for all your users. Um and that means that if one of your users moves off the uh your PDS, then um then you still can't delete it because you need it for other users. Um better to do what we do we do with the sign-in keys and create it when they sign up and then delete it if they move off.
Okay? Um so so all this just makes it um, it makes the individual user safer, but it also means that that in in the in the case where we have to do this switch from a rogue PLC directory, we have far less ambiguous data that we have to somehow deal with. Okay, um let me talk a bit about ways that this can be more robust. And the first one I'm very pleased to say is happening. Um, this is really cool. So um so T logs, um, we we heard from um Philippo earlier about T logs. Um this should make it much more reliable to mirror.
We can all tell that we've got the the same mirror quite easily. Um we can quite easily sync up on the same thing, and we've got um, and we've got like a log of the history of what the um what the sequence actually sequenced. So this is really important. Um we we can have loads of people with like um very lightweight devices um verifying that that log is being appended to and not like reorged as I understand it. Um and we can also have people run monitors who check that the rules are actually correctly applied. Um so this is already great and it will really help.
Um ideally we will push this as far down the stack as we possibly can, right? So ideally, if the directory stops cooperating with the system, we want stuff to break. Um but this is the problem of having this kind of single um position of authority, they've got the official organization, they've got the the single right privileges. The problem with this is they have the ability to just kind of turn that stuff off, right? Because if you're a developer, you know, you've got a choice between no records and invalid records, what are you gonna do, right? And unless we can really, really quickly coordinate this flag done move and move to a new um a new directory.
And this is the difference with how certificate transparency works with um certificate authorities, right? With with like um uh certificate transparency for SSL certificates. Because there, if you have a bad certificate authority that refuses to um to participate in the um, or that, or the or that breaks its participation in the scheme, which has apparently does sometimes happen, um, your users can always get a certificate from another authority. But this is specifically the power that we don't have, at least in protocol in this system. You cannot move sequencer in in in DID PLC. All we can do is try to coordinate this incredible flag day.
There's a pro a proposal a while back by uh by Nick who summoned, you know, um to make it possible to choose your directory. Um I don't think this allows you to escape from a bad directory, but I think it potentially really helps. So that instead of having this single privileged position of the DID pl uh the PLC directory that is in charge of DID PLC, um, you potentially have a bunch of different operators. Um so I really like this. Um and and then finally I'm gonna talk about some decentralized consensus approaches. Um there are two s serious problems with decentralized consensus um for this application and for a lot of applications of atproto applications.
Um the first is that like in the American culture wars, everything must have a side. And apparently like an open validator set is MAGA coded nowadays, right? So you like you can't do it, you can't say blockchain in it, you know, you have to kind of kind of reinvent a blockchain but not tell people. Um so there's that problem. And then and then and then the other problem is um writing to a decentralized ledger generally costs you money. Um and the reason why it costs you money is because it needs to somehow manage spam, right? So um if if if you don't want to put anybody in charge of deciding what is a legitimate transaction, and also if you want to pre preserve the ability to um to to mirror the the entire data set, um then the only way I think that anybody knows is to charge money to to write.
Um so a couple of approaches, um well, there's a um there's a BFT um system that somebody wrote. I I I think a lot of this stuff could probably be written rewritten in the in the light of T logs. Um but there's a there's a BFT suggestion using comet BFT. Um I haven't looked very hard at it, but it's maybe interesting. Um a couple of of ideas by me. The idea here is if we're gonna use a blockchain, we want to have to avoid writing to it all the time. Um and we especially want to avoid regular users having to write to it.
Um so I wrote a couple uh a couple of things, P2P guardrails. This is a suggestion where firstly you can change your sequencer. So if the if the directory is bad, you can escape. Um secondly, if the sequencer refuses to sit to sequence something for you, then you or somebody on your behalf can send it to the blockchain um and we can read it off there. Um and finally, we do some reorg protection based on kind of T log like um uh checksums so that you can prove that you previously had something already accepted and that it shouldn't be realed.
Um and then finally this one, did cow. This is a proposal for a new kind of DID. Um and I I actually what what set me thinking about this was I saw that people are trying to do um organizational control of DIDs. Um so for example, you've got a decentralized organization, you've got a bunch of different people, um, and they all want to um to share control in some way of a DID. And this is something that um some of the blockchain tooling does really really well. Um so I thought it would be useful if you had kind of an explicitly kind of kind of blockchain um oriented uh way of doing this.
And the proposal is very simply um you make an ID with the controller blockchain address that wraps your regular ID. Um you don't have to do a blockchain transaction to write this, um, because if there's nothing on the blockchain, we're just gonna use the thing that was in your address. Um and then if you want to do to move your wrapped ID, let's say you lose trust in DID PLC, or you want to move from a cursed uh PLC entry to a non-cursed one, or you want to move to a DID web or different Dib web, whatever you want to do, you can re-point this one um with with a blockchain uh transaction.
Okay, so uh that's all I got. I've put links for all the technical things I talked about up here, and I've also pinned this to my profile. I'm GOAT Navy on Bluesky. That clock says one minute, but we actually have a couple minutes, so uh do we have any questions? Actually, no, first. Thank you. This was amazing.
Okay. So why don't we just all use DID webs and then push the fight to the DNS layer. Yeah. Uh the if you'd asked me that a year ago, no a year ago, I would have said we should all use DID webs. But the but that like I I at that time I had very naive like assumptions about the the nation-state governed liberal institutions.
And it seems like nation states will turn to fascism even within like a three-year time span or something. So I don't I don't feel like that confident like having a DID web for the next 20 years. If it was five years, I'm I'm kind of cool with the Dib web. So yeah. So I think for for for long term there's that. And then the practical problem with DID Web is just that people have a hard time not losing their their control of their um of their domain. And and also that the registrar will keep putting the price up with the domain as well.
Oh hey. Thank you. For all of the list of things we can do to screw everybody over. No, okay, seriously. Um speaking of my personal uh capacity, but okay, so um homework. Um sounds like we should um make the uh policies for what is and isn't going to go in uh explicit so they will bind us uh for for the future. Uh uh we should uh like T logs are good, I saw it here. Uh and maybe uh considered um T-log witnesses, T-log uh uh mirrors, T log monitors, uh monitors are permissionless, but uh witnesses um anything else.
Um right, so so apart from kind of change changing the whole system. Actually what one one I mean one one thing the um one thing that I I that occurred to me the other day was um we should it would make more sense to separate out the control the reading and the sequencing, right? So if if you are writing that T log, you don't necessarily need to be running the directory. Does that make sense? Right. You need you need your own version of the directory, and you give proofs to people when they ask to write to it.
But anybody could be running those directories. And like and I think it would be really useful if we could just avoid this social point of like the PLC directory, which is clearly like the dictator of of all things PLC. Um that would really help. So so like at least potentially, you know, maybe have maybe have different organizations, maybe Bluesky should keep PLC directory and you should just do sequencing at the non-profit. And the non-sequencing part here is just a read uh uh read-only service that makes things available, is that right? Um, actually there's I mean there's a couple of ways to do it.
You would literally get a message and say what time did I did I give you this message and then you give it back to them with a with a signature. Um but but I think you could do something similar with the T log, like some feature of T logs. Yeah, I think the T log equivalent is um a read-only uh replica, which can also choose to uh the set of witnesses that signed that T-log. But that can be done permissionlessly. Like anybody can spin one of those up downstream of the code. Anyone can anyone can s spring up a mirror, but the the what I want to communicate here is that the switching over from the PLC, the like the P the PLC, it's a social arrangement just as much as a technical arrangement, right?
So who do people think runs the PLC? And this is this is why earlier I said I said like and until I was practicing this talk, I thought it was a good idea to move to a new organization. Uh and now I don't because the new organization will actually have much more authority than the old organization. Like if I look at those really good social recovery operations, they're all against some evil corporation. So we can we can totally paint blue Bluesky as an evil corporation and and like organize this social recovery to to foil their evil plans.
But like with a a Swiss organization, it's you know some more members with worse reputations. Worst reputation is.
Anyone else? Well, this is maybe going into the weeds a bit too much, but um I'm curious why the DID cow proposal didn't have a include a chain ID, if I understand correctly the address. Yeah is a smart contract. That's correct. The the reason why it didn't uh include a chain ID was big was two reasons. Firstly, it's already quite long. Um and and and secondly the the the the b the big burden I think actually of those two proposals and also probably the reason why the the uh guardrails proposal is actually obviously dead in the water, is that you need a um you need an RPC endpoint, right?
You need a connection to the block, a read connection to the blockchain to resolve anything. Um so if we have lots of other chains there, then whoever is resolving this has got to have lots of different working RPC endpoints. Some kind of like, okay, what's the simplest thing that could work? You know, what one RPC. No, no chain ID. Okay. Any other questions?
Thank you for closing out the conference with this particular talk. Okay. Um thank you again. Um and uh we're gonna have closing.