 I'm Hannah from bedrock and I'm excited to introduce an effort our team is exploring to supercharge the ways we are able to move data around our networks. First of all, I want to help folks understand what we have today. You've probably heard of the words bit swap and graph sync. I want to talk briefly about what they are and how they're different. Both of these protocols move IPLD data around live PDP networks. The analogy I've been using to help non programmers understand is this bit swap is roughly designed like BitTorrent while graph sync is roughly designed by like HTTP. That means they shine best in different scenarios bit swap like BitTorrent is good for moving highly distributed content from many peers where each individual peer might have low bandwidth like a home computer. Graph sync like HTTP functions great for downloading data from high bandwidth servers like storage providers. The other big difference between the protocols is a historical artifact of how they were built. BitSwap is the bread and butter of IPFS while graph sync was written in the course of file coin development. This has led to some big difference in the implementations we produce. These aren't differences that are inherent to the protocol, but they're nonetheless quite significant. Graph sync supports layers for payments and authorization while Go BitSwap keeps everything free and not only that but Go Graph sync provides multiple layers of control to our operators while Go BitSwap has very little, has a lot less configurability. This has led in newer situations to a kind of a difficult trade off. We are starting to see in like retrieval markets. It would be nice to be able to reach for either protocol without having to think about what is and isn't supported in terms of things like payments and authorizations. It's a tough trade off right now. Retrieval markets for example needs multi-peer transfers, but also they're going to need payments eventually. What do they use? And this is what Project Thunder is trying to answer. The why not both? We want to make each protocol more powerful and flexible so it isn't really a choice. I shouldn't have to say if I build for file coin I use graph sync, if I build for IPFS I'm kind of stuck on BitSwap. Or if I use BitSwap I can't use have payments. The auto retrieve project you'll hear about next is great for bridging IPFS and file coin, but in a long term one shouldn't need to run a server to translate transfer protocols. And it's not just about making these choices easier. We can actually use one protocol to fill in the gaps with the other. BitSwap lags behind BitTorrent in performance sometimes because BitTorrent starts with more information at the start about the structure of data you're downloading. So what if graph sync could be used to quickly discover that information? How much faster could BitSwap be? These are the kinds of questions we're aiming to answer. So anyway, how are we going to do all this? Well, this is what you're going to get for the five minute version. No, seriously I tried to make like a super simple architectural guide and no matter how much I cut it down the answer will be unsatisfactory unless I'm taking the other deep dives time and I'm not going to do that. That's not what you do to teammates. Suffice to say it's complicated. In terms of what we're doing right now, we have two protocols and several layers of payments that only work with graph sync. In our current work, BedRock is re-architecting the higher level layers to be fully protocol neutral while IPFS stewards are building the hooks in BitSwap to make it possible to support payments. This is complicated, slow work, but you will see hopefully a grow re-architected go data transfer v2. It says in a month or so, but I just heard two weeks. So in two weeks it will be here. But here's a ton of more information. You can read the detailed project proposal and roadmap, it proposes extensions to BitSwap, watch a video on how we're re-architecting go data transfer. You can also follow progress with hashtag data transfer interop on Phil Slack and you can check the slides to dig into these. I might maybe do a deeper dive for programmers at some point. One last thing. We may not get this work done super soon. These kinds of protocol changes are really hard. They're always hard every time we do them. They're long-term investments and they don't always have super visible like immediate wins, but they have very big long-term wins. So our team, it's possible we may need to get reallocated at some point for immediate priorities, but my hope is we're going to get there and we're going to invest as an organization in this kind of low-level work to unlock these key long-term benefits for our network. That's all.