Fantastic. Okay, hi, I'm Filippo. I do a few things. In my day job, I'm an open source maintainer. I'm one of the maintainers of the Go Cryptography Standard Library. And I used to be the lead of the Go security team at Google. And then in 2022 I quit because I had opinions on how you could fund open source maintenance and people said it was never gonna work, and I'm that kind of person. Anyway that's a completely different story, and that's what Jom is uh is about now. It's a small organization of open source maintainers. Uh but it's not what we're here um uh talking about.
You might have also heard that I am uh on the uh board of the PLC organization that was just formed. Woo! Exactly. Uh yes. And that is uh closer to what I'm uh going to talk to you about because I'm going to uh tell you about transparency logs. Transparency logs are something I am really really into because they meet the moment for uh providing accountability for uh this the systems that we have and that we can uh we can make for users. But a step back. What is a transparency log? A transparency log is a Merkle tree.
Stop me if you heard this one. Uh is a Merk uh append-only Merkle tree, too. It's not a Merkle search tree, it's just a Merkle tree that keeps growing uh of entries. And the entries are things that you want uh to have a list of visible to everybody and where everybody has the same list of uh things. That is a very useful primitive. Because for example, think about uh package management. I'm involved in Go, and um usually how package management works is that you have a registry and you make an account, you upload a thing, uh, but that's very centralized.
Uh Go has a completely different thing, has uh the decentralized system where the name of the module is where you fetch it and there's a mechanism of uh for fetching that data. Stop me if you heard this one. Uh but the problem uh with that is that then you have problems like left pad, you have the problem that uh if you connect to that website in uh it knows that you connected to it and that you're using it, which is not great. You can fix those things with a centralized system because you can put you know something that saves those uh modules uh and uh keeps them available.
So sometimes having a centralizing relay, stop me if you heard this one, uh, is is useful. Uh however, the problem is that now you need to trust that centralized party, just like you needed to trust PyPI and and NPM. Well, that's what we use uh transparency logs for. Uh a transparent there's a transparency log called the Go Checksum database, which is just a long list of every Go module version and it's hash. It's append only, everybody sees the same uh list. And a client will only install uh uh Go module if it has a cryptographic proof of inclusion in that list.
Uh this already works. This you are using this if you're developing in Go. And a lot of people don't know because that's the beauty of T logs that you can build them on top of a centralized uh experience and they just work. Python has tried so many times to get uh package outers to sign their thing and it never works because either people don't check the signature, or if people check the signature, now you're terrified of losing your key, so nobody signs and you don't go anywhere. Uh in T logs, one day we turn them on, they're on.
Uh and uh that works, and that's what uh check uh the custom database is. Uh this is uh derived from certificate transparency, which is what Sunlight was about, and there's uh links later. Now what uh so the point uh the the point of this is that you can use transparency logs to provide accountability where it's hard to provide decentralized trust. So instead of saying uh we um uh we are going to make a decentralized system where you have to connect to different package outers and there's all uh this problem, we said Google runs a proxy mirror.
But then we also said that proxy mirror is uh held honest by the Shacksum database so that if they ever put a fake module in there, the outer of that module can notice because the same list that every client uh checks inclusion in is the same list that you can just sign up, download the whole thing, go like, yeah, that's my module. Wait, that's not the mod the module version I developed. Google, what are you doing? Uh and Google is staking its reputation uh on uh the system. Uh to a cryptocurrency uh crowd, sometimes I describe it as there's proof of work, proof of stake, and uh uh proof of um reputation.
T logs remove all of the crypto economics, remove uh all of the uh extra work and instead say, look, are you willing to uh be accountable for the content of this date for all this data set? If yes, great. We will make a system such that uh if a client trusts something, it means it's forever in a public list where it can be audited. And if you put something wrong in there, you will be held accountable for that. Which in practice would probably mean somebody forks go to change what the uh checksum database operator is because they're cryptographic proof that it's steward uh uh abused that power.
Cool. So that's why I like uh transparency logs. I also like atproto. So can we build transparency logs for atproto collections? Uh what is an example use case? For example, if you're making a package manager on top of atproto. Uh but also if you have any other situation where you would like uh all of your uh collections to be append only, never change, and be auditable forever. That is not the case for likes and posts. That's fine. Like sometimes you want to delete the cringe post from yesterday or undo the like that you did while scrolling somebody's profile without realizing it was not your following feed.
Uh so those are deletable, fantastic. But but instead there are other applications where it makes sense to not want deletions, not what uh things to change. So let's see that let's say that uh you made some uh foo collection and ABC collection that you would like uh as a client to use knowing that those records can't go away. Here's a sketch of how that uh could work in protocol. Uh Alice is developing a client that wants to consume foo and ABC uh records, and uh she requests for a T log to be operated. So she makes uh a record called a T log config and says, hey, here are some collections, some NSIDs, some uh some DIDs.
Scan somebody please run uh a T log out of uh these. And a T log operator, which can be multiple ones because permissionlessly allows picking different uh operators, like Geomist could say, sure, we'll run uh T logs for free up to a million uh uh entries in the T log. It's gonna be what? Uh how much can a banana cost? 200 megabytes. Uh and it will uh create a T log, so it will take all of these records using tap, put them into that append only uh Merkle tree, publish that uh Merkle tree using the uh C2SP T log specifications, which are already an ecosystem that the GoChecksum database uses that uh static CT uses and so on.
And uh after publishing that, it makes a record saying, yeah, all right, I'm operating an instance for that T log config. It's the T log instance record, it has a strong ref to the config and the URL where you can find that T log. Alice uh uh goes like great, okay, I'm going to configure my clients to require an inclusion proof, cryptographic inclusion proof in this T log before they trust uh um a record. And this is nice because even if our tap instance uh uh messes something up and we lose this record over here, it doesn't end up in the T log.
So it's as good as if it didn't exist. Because the client will not accept that record, will not process it, will not trust it, will not install it if it's a package, will not show it if it's uh a testation or a blue note or something like that because it doesn't have an inclusion proof. So all of the things that get actually consumed by the client, you can be sure that they're in that list. And then someone else can go and monitor that list. Uh and if they're the package outer, they can be like, hey, no, wait, wait, wait, my PDFs published something I didn't want to publish or anything of the sort.
The leaves of this um uh T log, so the actual things in the Merkle uh tree would be the hash of the DID, the hash of the NSID, why hashes? Because it's uh you can never change the stuff in here. And it's really nice not to get user controlled data in places where you can't delete it. Enough said. Uh and then the R key, which probably would have to be a uh time sub ID for the same reason, uh, and the SID. The con the records are not actually in there, uh, but the you have all of the cryptographic pointers to the records, and if a record ever gets deleted, sure, this collection becomes an auditable, but the other ones are still standing because you can still check what the full uh the full set of those uh were by monitoring the the T log.
And then I guess we can also put uh the the checkpoint back into the protocol because why not? I mean. Uh so yes, uh this is a thing that we can build very easily because T log uh uh tooling, we've been developing it now for years to make it uh easy and cheap to run, and there are a bunch of libraries now. Uh there is uh the deployed uh software that uh already uses this Go checksum database, Sigsam, Sig Store. Um probably Merkel Merkle tree certificates, which will probably replace the Web PKI because quantum computers are coming.
Different story, different talk. So bunch of links, uh it's uh just uh uh loose leaf from Leaflet because this stuff works. Right? I uh love it. Uh and yeah, you can find a bunch of links and uh reach out if you uh what I'm looking for next is somebody that has an atproto use case for this, somebody that has an atproto collection that they would like to be uh able to say the list is uh universally known and anybody can audit all of the things that a client could ever have trusted. Thank you.