 Okay, so the idea was basically you want to be able to like privatize data on your, your IPFS node. So right now data on IPFS is replicated across nodes anyone you connect to anyone can request it, they receive the node, or sorry they receive the block. But the idea of like saving private data is currently a challenge. And right now I think the intended solution is to create like a private network where your nodes only talk to nodes that you own, or using swarm to then pass sanctioned keys to excuse me to all the nodes that you trust. So the idea was to create a configuration IPFS to accept certain blocks or to pass certain blocks to certain peers when requested, basically using it as a filter. So if a peer of yours asked you for a block but you have, you know, this peer is a like allowed to see this block, then they get it otherwise they don't get it. And so you're, you're able to have this kind of like self configured set of data that you don't want replicated across nodes. Lauren gracefully put this demo together on a GitHub repo that we could go check out I think there's, there's images to it later. We did a certain number of things before creating the demo so initially this was implemented in a JS IPFS repo, because JS was the easiest thing to hack on at the time. This was later than discussed, and then we were directed to go put this into a go bit swap PR. So decided where to put that in the bit swap protocol. We tried to come up with a method that wasn't not a heavy implementation so this was something that was lightweight supposed to be very minor and easily to get PR didn't put through into the system. I didn't have a lot of changes doesn't affect a lot of other things. And then I think there's a spec recently that is talking about authoring IPFS data content IPFS is globally index and replicated so if if you have something on your node it's assumed to be public. You could create a private network again but like you still want to be able to participate in the network without blocking yourself off from the entire public. You know the same way that I could give access control to my data. We were trying to replicate that minimally. So this is a bunch of previously discussed issues and PRs that have come up, as well as implementations. We noticed there was a lot of other people either requesting this or creating implementations for it. One of the implementations I think we actually talked to one of the developers of it, but a pure ghost has an implementation that changes like the bit swap spec. It actually has continuous access across or sorry continuous access control across nodes so if you don't want access. If you don't if you don't want other nodes to have access to your block, they can still request that block. But it has to do something with like a past key. That's a very heavy spec and that's a very heavy change for the protocol. But it's still the same idea right like they still want to be able to have access control for their own data on their node. The great thing is that so far there was no like no one shared any pull request to implement this feature. Like a lot of people have been talking about this one of this, but we're basically the first one to have a pull request that is this close to get merged. I'm too IPFS. So I think this is great. What happened is that right now there is also a move towards implementing this, like creating a new bit swap specification to implement this. With like the fancy off token and etc that I was talking about. And so I think like I will and I think Kyle Kyle and I will assume like 0.1% responsibility into triggering this new specification and like energizing this discussion around. Implementing authentication like the headers basically and privacy into bitswap. So this is a very exciting time to be to to to like be part of seeing the specification changes. These are some images to the demo. These first couple images are the actual configuration of the IPFS node to take what we call a pure request filter. And that pure request filter is basically just a predicate in which returns true or false. And it's given the CID and the pure ID. You can do with it what you will. You can say whether or not that combination of pure ID and CID passes or not. If it does pass the bitswap protocol basically sends a don't have, I believe. And then basically acting like your node doesn't have that data, even though it does. This was a very minimal implementation so things that this doesn't do. If the node replicates that data, right, somehow your predicate is messed up or something or up here got to it before and you didn't want them to. It's kind of too bad. It's now on a public network. So this really only solves the idea that the information on your node while it's on your node is yours. If it gets out, it gets out. It's public. Yep, also making the feature official. So there's that go IPFS and the go bitswap PR. We have the implementation in JSI PFS. I think it might need to be altered a little bit based on what we did to the go IPFS or sorry, the go bitswap protocol rust, if it ever gets there. And then also like just there's a lot of other conversations around like how they should be implemented. Are there different things that we can do possibly building on top of that make this a little more solid of a feature. So anything like authentication headers something something along the lines of what period of implemented with the keys being passed and forth with blocks or a general content policy that get operators can subscribe to. So basically if like someone else has a content policy that you want to align with say, you know, maybe it gets rid of all the bad images on the internet or something. Then you can basically say like okay I don't want this list of CIDs and I never want to share this list of CIDs with other people. Better build tools around something like this. So one of the things we thought of was like basically a configuration for setting this up with the CLI rather than having to actually like create your node and build your node first. So things to make this more useful. I mean if you can restrict it was just a way to get a unconditional security information very security somewhere. I mean if you can restrict access to data on IPFS. Then you can start building like decentralized and conventionally secure system which are which are like fancier way to protect protect data.