Edmund Edgar 3:27 So I'm going to talk about DID PLC, which has a few sort of slightly surprising properties to it. 3:34 It's a slightly confusing system. 3:38 What does it mean? 3:39 A self-authenticating decentralized identifier which is strongly consistent, recoverable, and has key rotation. 3:48 Okay, so 4 things: strongly consistent, recoverable, self-authenticating, and key rotation. 3:56 And the slightly weird thing about this is it does have all these properties, but not all at the same time. 4:02 As far as I'm aware, it's technically impossible to have all these properties at the same time. 4:07 Let me explain what I mean. 4:08 So what do we mean when we say self-authenticating? 4:13 We mean that you can look at the data and you can confirm it's valid without looking at anything else. 4:17 Okay, so the classic example is an IPFS document. 4:22 If you have the ID of an IPFS document, that is a hash. 4:26 So if somebody you don't trust gives you the document, you can then recreate that hash and make sure that it's correct. 4:31 Okay, so how does this look in DID PLC? 4:36 Well, when you first create a new account in DID PLC, it's exactly like that. 4:43 So for your first account, you make a document. 4:47 You put in, for example, your Bluesky handle, your PDS, a load of other stuff. 4:52 And you put in the key that's going to control this account. 4:54 This is called the rotation key. 4:57 And you take the hash of this document. 4:59 And that hash is your ID. 5:02 So this is exactly like IPFS self-authenticating content address. 5:07 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 fields in there. 5:14 And then we're gonna sign it with the key that we stated in that previous update. 5:20 So this is also cryptographically verifiable. 5:22 This is also basically self-authenticating, assuming you've got the whole chain. 5:26 If I wanna check this, I can check the signature on this second one. 5:31 I can then check that it matches the key in the first one. 5:35 And then I can check the hash of the first one. 5:37 So I can authenticate the whole chain. 5:38 I don't need to ask anybody else. 5:41 But we also have this property of key rotation. 5:44 So what happens when we want to rotate the key? 5:46 So the first thing we're going to do is we're going to make a new document with our new key that we want to change. 5:52 And we're going to sign it with our old key. 5:55 And then once we've done that, we can now sign all our future updates with the new key. 6:03 And as far as normal key rotation, that means that it doesn't matter what happens to the old key. 6:09 We can leak that on the internet if we like. 6:10 It doesn't matter, it's rotated out. 6:12 You do this because you no longer trust the old key. 6:16 So that's what we've done. 6:17 The problem is, what happens if somebody does this? 6:20 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. 6:29 Okay? 6:30 So if you have this situation where somebody is in control of one of your old keys, this is no longer self-authenticating. 6:38 Okay? 6:39 It's no longer self-authenticating because we did key rotation. 6:42 So we've got these kind of really different properties. 6:47 Even though we all have DIDs and they look the same, different DIDs have really fundamentally different security properties. 6:56 Some DIDs, your initial document is self-authenticating content address. 7:00 Okay? 7:03 The one that you then updated is also self-authenticating. 7:07 Okay? 7:08 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. 7:16 Okay? 7:18 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. 7:29 So if you're on BlueSky, you've probably got their rotation key in your history, but that key, as far as we know, is still secure. 7:36 So there is only one chain of your identity, but we don't know what will happen in future. 7:41 So this situation at the top is very, very blessed. 7:45 This is wonderful. 7:46 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. 7:58 So if you run into like a Nostra enthusiast who is concerned about, like 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, 'cause the way they do it in Nostra is just don't do key rotation, you just don't lose your key. 8:13 If you're happy with the Nostra feature set, You can have Nostra-style security with DID PLC. 8:20 But once you use this feature set, in certain circumstances that are kind of out of our control, we then lose this security property. 8:27 And we end up with kind of a really differently secured system. 8:30 So right down at the bottom, we're not self-authenticating. 8:34 We've got Sadako crawling out of our TV screens. 8:37 Our DID is cursed. 8:39 We can no longer verify just by looking at it whether it's correct or not. 8:42 Okay? 8:44 So the solution in DID PLC is to use a trusted sequencer. 8:50 So the job of a sequencer is to say, this is when this update was published. 8:56 And since I know that this one was published earlier, I then know that the evil one that we did later is invalid, right? 9:04 So they can choose the canonical chain and the correct way to resolve your ID. 9:09 And there's another slightly confusing thing about the DPLC system, which is that this server actually has two jobs, and they're really, really different jobs and have kind of really different properties. 9:19 So it's a sequencer, but it's also a data publisher. 9:23 And you didn't have to do these together, right? 9:26 These are fundamentally different things. 9:28 They could have been— they're different roles. 9:30 They could have been done differently, and they have really different implications. 9:34 Okay, so what happens if this trusted server goes rogue? 9:38 And you might think, okay, why is it going to go rogue? 9:41 Give you one example of what I mean by rogue. 9:44 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? 9:57 And they didn't do this at the level of the directory. 9:59 They did this just at the level of their PDS. 10:02 But what this shows us is these well-meaning people, they are not in the tank for the Prime Minister of Turkey, right? 10:09 But well-meaning people can have pressure put on them to do things that they will not necessarily want to do, okay? 10:14 Because they live in the real world. 10:16 If they didn't do that, they couldn't change planes in Istanbul, 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? 10:27 So there's now a plan which until today, I thought was a good plan, to go with a separate organization, and then just thinking about my own talk, I realize it may not be a good plan, to go with a separate organization that's gonna run the directory. 10:42 There's gonna be a board of trustworthy people on this, you know, on this board in control of it, and they're genuinely, as far as I can tell, trustworthy people. 10:52 So let's assume that we succeed in the task of keeping psychopaths off this board, which is an unsolved problem in, like, human governance, right? 11:03 Generally, you know, the first generation may not have psychopaths, but they seem to somehow get there. 11:08 But let's assume that they're all honest, well-meaning people and they care about App Proto. 11:13 Let's look at a similar example. 11:16 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. 11:24 So if you're trying to govern a private university in the US, you've got a bunch of alumni who really care about the institution, right? 11:32 They really care about the school, and if they don't care about that, they care about their own personal reputations. 11:37 So this is a really good case for this governance that we're doing with PLC Directory. 11:42 But what happened was that the Trump administration put pressure on them and took a bunch of things that they cared about hostage. 11:51 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. 12:16 And if they compromise, then they're going to end up hurting far fewer people than if they do what they're being told to do. 12:23 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. 12:35 So if you think about this with App Proto, if you care about App Proto, there are all kinds of ways that people can put pressure on you. 12:42 Can you get proto apps into the App Store? 12:45 Are you gonna have network-level blocks of the PLC directory? 12:49 All kinds of things that you could do that will potentially put a dilemma on the people who are governing the 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. 13:03 So let's assume they go rogue. 13:06 Can we just do things? 13:07 Because I've got my— client, right? 13:10 It's free software. 13:12 We've got our relays. 13:13 We know anybody can run the relays. 13:14 We've got our own PDSs. 13:15 There's nothing that says that we have to look at the PLC directory. 13:19 We can do what we like. 13:21 So if I've got a self-authentic DID, this is probably actually OK. 13:26 So here's what we can do. 13:27 Somebody can set up the too-hot-for-PLC directory. 13:31 The records that are being messed with by the PLC directory, what we can do is we can query the PLC directory. 13:36 We can look at our own data, and if the PLC directory refuses to answer for that record, or if it's done some weird— 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. 13:55 And the great thing about this is we don't really need consensus to do this. 14:01 We can have, like, bitterly 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 gonna get to the same result. 14:17 As long as we share the data, we can all get to the same result. 14:20 So we have this property that we wanted. 14:22 I don't know if we still have strong consistency. 14:24 I think we do. 14:26 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? 14:35 And so the sequencing, it's making a decision about what time did I receive this update. 14:41 And somebody else may honestly get that update at a different time. 14:46 So sequencing requires us to just have this single directory, and that's why it's designed like this, OK? 14:52 So we can do things, but we all need to move together. 14:55 We need to do like a flag day. 14:56 We need to all say, like, from this day onwards, we're using somebody else for the directory. 15:02 So can we do that? 15:04 Maybe we can. 15:06 There are some sort of favorable precedents. 15:09 So this happens in free software all the time, right? 15:12 So Oracle took over OpenOffice and did all kinds of nasty Oracle-type things, and the developers and the users of OpenOffice just kind of all got together and decided to use a different project, different GitHub repo, different brand, and everybody moved to LibreOffice, and basically nobody uses OpenOffice anymore. 15:32 Same thing with some blockchain systems. 15:37 So Steam was one where there was this thing where the developers of a protocol, for some reason that I don't quite understand, had particular rights to do things to the protocol. 15:48 And Steam got bought up by Justin Sun, who is this kind of crypto comedy villain. 15:54 And the community, both the developers and the users, didn't want this, so they forked the project to Hive. 15:59 They said, "From this point in the history, like, from, like, 10 o'clock tomorrow, we're gonna use our own version of the software. 16:07 We're gonna take out all the special privileges that Justin Sun would have had, and we're gonna carry on." And they did that, and it worked. 16:13 And it's often been done, and it's often worked. 16:15 So what have we got to do to replace a malfunctioning PLC directory? 16:21 We all have to recognize the problem, OK? 16:23 We have to agree a new person who's going to run it. 16:26 And we have to get a snapshot of the directory from some point in time when we're going to switch over and start using the new one. 16:34 So the first problem is, do we agree that it broke, right? 16:37 So ideally, the rogue directory would say, We're going rogue. 16:42 We're going to screw you all over. 16:45 This is now the wrong picture. 16:47 This should be— is this Filippo here? 16:48 This should be Filippo. 16:49 Anyway, ideally, they will actually announce that they're going to screw us over. 16:56 But the problem is, they're the adversary. 16:59 They're not trying to be helpful to us. 17:02 And the adversary gets to pick the battle. 17:04 So if their goal is— let's say that they've decided there are a bunch of bad actors on App Proto. 17:09 and they need to get these bad actors out of the directory so that they can get that process spreading properly in corporate environments, which are stubbornly resistant. 17:16 Whatever they want to do, right? 17:18 They get to set the precedent, so they can reorg out Jesse Singal. 17:22 I don't know if you're familiar with this guy. 17:24 There's a guy who's really, really unpopular on Blue Sky. 17:26 He writes nasty things about trans people. 17:30 Blue Sky users are always badgering Blue Sky to ban this person, and Blue Sky is saying, well, he hasn't actually violated the terms of service, so we can't. 17:39 If you do something that to me looks rogue but is reorging out Jesse Singal, this is very popular among Bluesky users. 17:47 Another thing they can do is they can pick at the factional fault lines. 17:50 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. 18:07 And they can work on these, right? 18:09 They can do something to somebody who's a bad guy to one of the factions, and the other faction loves us. 18:13 Because what they've got to do here is they've got to prevent us from forming consensus. 18:17 And it's much, much harder to form a consensus than it is to disrupt a consensus. 18:23 Forming consensus is really hard. 18:25 So if we're trying to form a consensus about we're going to move over to this guy because of this problem, They get to pick at those fault lines and make it hard for us. 18:33 Okay, next problem is, do we have an up-to-date mirror? 18:38 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. 18:46 So ideally, what happens here is, you know, loads and loads of people have got their own mirrors. 18:52 People aren't really relying too much on the PLC directory. 18:56 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. 19:03 The problem is that they're the adversary, right? 19:07 They're not trying to help us, and our ability to get this mirror is dependent on the adversary. 19:13 So if you look at what any organization does before it screws the users over, the number one thing, day zero of incidentification, is to dismantle the accountability mechanisms, right? 19:26 Dismantle anything that would give your users the ability to exit. 19:30 So for example, if you're Instagram or Reddit or Twitter, then you're gonna turn off your API. 19:37 This happens before the actual— like, the algorithms go to shit and your application experience becomes useless. 19:44 First you turn off the APIs, and then you wait a bit. 19:47 And that way, nobody else has got a way to help you exit, to give you an alternative. 19:52 Another example: week 1 of the Trump administration, on the first Friday night, he fired the 17 inspectors general who were supposed to be the independent observers who would hold him accountable for corruption in his administration. 20:10 If you're actually going to do corruption, you remove the things that will hold you accountable for corruption. 20:18 So, what would it look like? 20:18 Well, the mirrors just sort of stopped working on a Friday night, you know? 20:22 Nobody seems to be able to pull from them anymore. 20:23 Don't know what's going on. 20:25 I'm hitting this endpoint. 20:26 It's not working. 20:26 It's working for me. 20:27 It's not working for you. 20:29 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. 20:35 Give us, like, a URL for some log files. 20:36 Say, "See if you can help, you know, see if you can diagnose the problem." And it's, like, 8 terabytes of just irrelevant log files, you know? 20:43 So they've got all the cards here. 20:44 Another thing they can do is they can spam the mirrors to death, because one of the amazing things about this system is that it's designed to kind of hold infinity records. 20:52 Like, there's no cost to writing to it. 20:55 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. 21:04 But in theory, as far as I know, everything is supposed to go in there. 21:09 They can allow other people's spam in there, they can turn off the rate limit until the mirrors fall over. 21:14 They can also create their own spam. 21:16 And the great thing about creating your own spam is you can do this deterministically from a secret seed. 21:20 The mirrors have to hold all the data to have a complete set. 21:24 You don't even have to hold the data, all you need is your seed and a serial number, and you can serve it. 21:29 So they've got all the cards when it comes to spamming the mirrors and just making it impossible for people to hold them accountable. 21:37 OK, so what can we do to mitigate this? 21:39 I should be clear, these aren't quite solutions, but they will help. 21:42 So we can run lots of mirrors, right? 21:46 And this is something that's already happening a little bit. 21:51 We can, when we write, instead of writing to the PLC directory, we can write to the mirror and have the mirror keep a log and share what they write, and then forward that onto the directory. 22:02 So that way, if the directory isn't giving us all its data, we should still kind of maybe be able to piece some of it together. 22:10 Try to get consensus on what the mirrors are actually showing us. 22:14 So if the mirroring stops working on a Friday, we at least wanna know that, as of Thursday, we all know what it should be showing. 22:21 There's then some technical things that I'll come to. 22:25 This is really important. 22:25 We need to figure out what is the social contract of did.plc and get this really clear and get this clear as soon as we possibly can. 22:31 Like, I read the spec with my crypto brain and it talks about avoiding censorship. 22:37 And to my crypto, like in crypto, like if you're preventing a ransomware payment from going to Kim Jong Un, that's censorship. 22:43 But like, I don't know what the rest of the, like the app prototype community thinks about this. 22:48 Like, is it, is it the job of the PLC directory to accommodate everybody? 22:53 You know, spammers, scammers, malware authors. 22:57 Are they all supposed to go in there or not? 22:58 What's the deal? 22:59 What happens to child porn or accounts linking to child porn? 23:03 What is the actual job of this directory? 23:07 What is it that would tell us if it was going rogue? 23:09 I don't know if that's clear to some people. 23:11 It's not clear to me. 23:13 And the later we leave this, the harder it is to figure it out, not least because we'll have all the factional squabbling. 23:19 So some more things, some practical things you can do. 23:23 Keep your ID self-authenticating, right? 23:25 So remember I said earlier we had the blessed DIDs where you could fully validate just from available data, and we had the cursed DIDs with Sadako crawling out of your TV screen, where we potentially had a fork in the timeline, or we had, like, potentially somebody could create a fork in the timeline. 23:42 So if you keep your own rotation key, when you sign up, you make your own rotation key, write down the seed phrase or whatever you do, and don't lose that, you probably never need to change it, right? 23:54 I mean, you know, Nostra doesn't do rotation keys. 23:56 Seems okay. 23:59 There's an obvious pattern if you're using most app process stuff where you feel like you register on BlueSky first and then you move to whatever PDS you were hoping to stick with. 24:10 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 is controlled by BlueSky. 24:18 I don't quite— okay, I put don't use it. 24:20 This is a slightly too strong a case, but there's this— remember we had recoverable in the 4 features? 24:28 So there's this feature in DIP 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. 24:42 And this is sort of useful, but it automatically creates this fork in your DID, right? 24:46 It automatically causes Saddlercode to come crawling out of your TV screen and reduces the security properties of your account. 24:55 So, one more thing. 24:57 If you are hosting PDSs for somebody else, a dead rotation key is toxic waste, right? 25:03 Plan the lifecycle of your rotation keys. 25:07 If you use— I don't know if this is still true, but when I tried it, if you use the stock PDS that Bluesky provided, It will set one rotation key for all your users. 25:17 And that means that if one of your users moves off your PDS, then you still can't delete it 'cause you need it for other users. 25:25 It'd be better to do what we do with the signing keys and create it when they sign up and then delete it if they move off, okay? 25:33 So all this just makes it— it makes the individual user safer, but it also means that that 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. 25:48 Okay, 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. 25:56 This is really cool. 25:58 So TLOGs— we heard from Filippo earlier about TLOGs. 26:03 This should make it much more reliable to mirror. 26:05 We can all tell that we've got the same mirror quite easily. 26:09 We can quite easily sync up on the same thing, and we've got, like, a log of the history of what the sequence actually sequenced. 26:17 So this is really important. 26:20 We can have loads of people with, like, very lightweight devices verifying that that log is being appended to and not, like, reorged, as I understand it. 26:30 And we can also have people run monitors who check that the rules are actually correctly applied. 26:34 So this is already great, and it will really help. 26:38 Ideally, we will push this as far down the stack as we possibly can, right? 26:41 So ideally, if the directory stops cooperating with this system, we want stuff to break. 26:49 But this is the problem of having this kind of single position of authority. 26:55 They've got the official organization, they've got the single write privilege, The problem with this is they have the ability to just kind of turn that stuff off, right? 27:05 Because if you're a developer, you know, you've got a choice between no records and invalid records. 27:10 What are you going to do, right? 27:11 Unless we can really, really quickly coordinate this flag down and move to a new directory. 27:16 And this is the difference with how certificate transparency works with certificate authorities, right? 27:21 With, like, certificate transparency for SSL certificates. 27:26 Because there, if you have a bad certificate authority that refuses to participate in the— or breaks its participation in the scheme, which apparently does sometimes happen, your users can always get a certificate from another authority. 27:42 But this is specifically the power that we don't have, at least in protocol, in this system. 27:47 You cannot move sequencer in DIDPLC. 27:50 All we can do is try to coordinate this. 27:52 Incredible Flag Day. 27:54 There's a proposal a while back by Nick, who some of you know, to make it possible to choose your directory. 28:05 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 PLC directory that is in charge of /did/plc, you potentially have a bunch of different operators. 28:20 So I really like this. 28:22 And then finally, I'm going to talk about some decentralized consensus approaches. 28:27 So there are two serious problems with decentralized consensus for this application and for a lot of applications. 28:37 The first is that, like in the American culture wars, everything must have a side. 28:42 And apparently, like an open validator set is MAGA-coded nowadays, right? 28:47 So you can't say blockchain, you have to kind of reinvent blockchain but not tell people. 28:55 So there's that problem. 28:58 And then the other problem is writing to a decentralized ledger generally costs you money. 29:06 And the reason why it costs you money is because it needs to somehow manage spam. 29:11 So if you don't want to put anybody in charge of deciding what is a legitimate transaction, and also if you want to preserve the ability to mirror the entire dataset, then the only way I think that anybody knows is to charge money to write. 29:32 So a couple of approaches. 29:35 Well, there's a BFT system that somebody wrote. 29:39 I think a lot of this stuff could probably be rewritten in the light of T-logs. 29:44 But there's a BFT suggestion using CometBFT. 29:48 I haven't looked very hard at it, but it's maybe interesting. 29:51 A couple of ideas by me. 29:53 The idea here is if we're gonna use a blockchain, we want to have to avoid writing to it all the time. 30:00 And we especially want to avoid regular users having to write to it. 30:03 So I wrote a couple of things. 30:05 P2P guardrails. 30:06 This is a suggestion where firstly you can change your sequencer. 30:09 So if the directory is bad, you can escape. 30:12 Secondly, if the sequencer refuses to sequence something for you, then you or somebody on your behalf can send it to the blockchain and we can read it off there. 30:22 And finally, we do some reorg protection based on kind of TLOG-like checksums so that you can prove that you previously had something already accepted and that it shouldn't be reorged. 30:33 And then finally, This one, DID-COW, this is a proposal for a new kind of DID. 30:40 And I actually— what set me thinking about this was I saw that people are trying to do organizational control of DIDs. 30:50 So for example, you've got a decentralized organization, you've got a bunch of different people, and they all want to share control in some way of a DID. 30:58 And this is something that some of the blockchain tooling does really, really well. 31:02 So I thought it would be useful if you had kind of an explicitly blockchain-oriented way of doing this. 31:09 And the proposal is very simply, you make an ID with the controller blockchain address that wraps your regular ID. 31:18 You don't have to do a blockchain transaction to write this, because if there's nothing on the blockchain, we're just gonna use the thing that was in your address. 31:26 And then if you want to move your wrapped ID, let's say you lose trust in PLC, or you wanna move from a cursed PLC entry to a non-cursed one, or you wanna move to a DID web or a different DID web, whatever you wanna do, you can repoint this one with a blockchain transaction. 31:44 Okay, so that's all I got. 31:46 I've put links for all the technical things I talked about up here, and I've also pinned this to my profile. 31:52 I'm goatnavy on Bluesky. Speaker B 31:54 That clock says 1 minute, but we actually have a couple minutes, so do we have any questions? 31:58 And actually, no, first, thank you. 32:00 This was amazing. Edmund Edgar 32:07 Okay. Speaker B 32:15 So why don't we just all use DID webs and then push the fight to the DNS layer? Edmund Edgar 32:20 Yeah. 32:22 If you'd asked me that a year ago, I would have said, we should all use DID webs. 32:26 But at that time, I had very naive assumptions about the nation-state-governed liberal institutions. 32:39 With a DID web, everything is under a registrar, which is under a nation-state. 32:42 And it seems like nation-states will turn to fascism even within a 3-year time span or something. 32:50 I'm not that confident having a DID web for the next 20 years. 32:53 If it was 5 years, I'm kind of cool with the DID web. 32:56 So yeah. 32:59 So I think for long term there's that. 33:01 And then the practical problem with DID web is just that people have a hard time not losing their control of their domain. 33:10 And also that the registrar will keep putting the price up of the domain as well. Speaker B 33:15 Hi. 33:16 Thank you for all of the list of things we can do to screw everybody over. 33:23 No, okay, seriously, speaking of my personal capacity, but okay, so homework. 33:30 Sounds like we should make the policies for what is and isn't going to go in explicit so they will bind us for the future. 33:41 We should like T-logs are good, so I hear. 33:45 And maybe consider T-log witnesses, T-log mirrors, T-log monitors. 33:51 Well, monitors are permissionless, but witnesses. 33:55 Anything else? Edmund Edgar 33:57 So apart from kind of changing the whole system, actually one thing that occurred to me the other day was it would make more sense to separate out the control, the reading and the sequencing, right? 34:16 So if you are writing that T-log, you don't necessarily need to be running the directory. 34:22 Does that make sense? 34:23 You need your own version of the directory, and you give proofs to people when they ask to write to it. 34:29 But anybody could be running those directories. 34:31 And I think it would be really useful if we could just avoid this social point of the PLC directory, which is clearly like the dictator of all things PLC. 34:42 That would really help. 34:43 So, like, at least potentially, you know, maybe have different organizations. 34:46 Maybe Bluesky should keep PLC directory and you should just do sequencing at the nonprofit. Speaker B 34:51 And the non-sequencing part here is just a read-only service that makes things available. 34:57 Is that right? Edmund Edgar 34:58 Well, actually, there's— I mean, there's a couple of ways to do it. 35:01 One way to do it would be just to do timestamps. 35:03 So you would literally get a message and say, what time did I give you this message? 35:08 And then you give it back to them with a signature. 35:11 But I think you could do something similar with the TLog, like some feature of TLog. Speaker B 35:15 Yeah, I think the TLog equivalent is a read-only replica, which can also choose the set of witnesses that signed that TLog. 35:22 But that can be done permissionlessly. 35:24 Anybody can spin one of those up downstream. Edmund Edgar 35:26 Anybody can spring up a mirror. 35:29 But what I want to communicate here is that the switching over from the PLC, like the PLC, it's a social arrangement just as much as a technical arrangement, right? 35:40 So who do people think runs the PLC? 35:44 And this is why earlier I said, like, until I was practicing this talk, I thought it was a good idea to move to a new organization, and now I don't, because the new organization will actually have much more authority than the old organization. 35:57 Like, if I look at those really good social recovery operations, they are all against some evil corporation. 36:04 So we can, we can totally paint Blue Sky as an evil corporation and like organize this social recovery to foil their evil plans. 36:13 But like with a Swiss organization, you know, some more members with worse reputation, worse reputation that you have to wear. Speaker B 36:22 You have to wear hoods with the robes with hoods basically. 36:25 And then yeah, okay. 36:26 Let's take 2 more. 36:28 Anybody else? Edmund Edgar 36:30 Well, this is maybe going into the weeds a bit too much, but I'm curious why the DID cow proposal didn't include a chain ID. 36:37 If I understand correctly, the address is a smart contract. 36:40 That's correct. 36:41 The reason why it didn't include a chain ID was 2 reasons. 36:44 Firstly, it's already quite long. 36:48 And secondly, the big burden, I think, actually, of those 2 proposals, and also probably the reason why they're Guardrail's proposal is actually obviously dead in the water, is that you need an RPC endpoint, right? 37:03 You need a connection to the block, a read connection to the blockchain to resolve anything. 37:08 So if we have lots of other chains there, then whoever is resolving this has got to have lots of different working RPC endpoints. 37:14 So I'm kind of like, okay, what's the simplest thing that could work? 37:17 One RPC, no chain ID. Speaker B 37:21 Okay, any other questions?