move blockstore to beetswap repo

[zvolin]

Do this after we release first beetswap

[matheus23]

Hi! We also implemented a wasm-friendly blockstore interface: https://docs.rs/wnfs-common/0.2.0/wnfs_common/blockstore/trait.BlockStore.html

There's some small differences:

• Instead of a Block trait, we simply pass in bytes::Bytes and a codec: u64 in the put method.
• We use RPITIT instead of the async_trait macro, so our MSRV is 1.75.
• We generally require + Send bounds only in non-wasm32 targets. In your case the async_trait macro forces Send bounds even in wasm32-unknown-unknown, which we've found to be problematic (e.g. JsValue in wasm_bindgen is !Send).

We're starting to use this blockstore implementation across a bunch of code bases, not only rs-wnfs, but also rs-car-mirror and our server.

In the last couple years we've accumulated some useful implementations of blockstores, e.g.

• An implementation that translates get/put into kubo RPC commands: https://github.com/fission-codes/fission-server/blob/4e200bee1eff881a8a4bafd39d42007264e81b32/fission-server/src/setups/prod.rs#L123
• An implementation that caches info about which blocks are missing: https://github.com/fission-codes/rs-car-mirror/blob/2d9d5f83e97a0bb6d845337861a6884606953f77/car-mirror/src/cache.rs#L207
• An implementation that stacks a "hot" and "cold" blockstore together: https://github.com/wnfs-wg/rs-wnfs/blob/ae2a2704dfd806c2d52678426cf7b4a149fef28b/wnfs/examples/tiered_blockstores.rs#L93

I wanted to reconcile all of these things & move them into a central place. Maybe it makes sense to align.

Would you be interested in moving the blockstore implementation to its own repository?

[zvolin]

@matheus23 we'll discuss this soon, thanks for notice. For now I can't think of anything blocking the separate repo except some inconvenience, mostly ci duplication

[matheus23]

Sounds awesome. Please let me know what you think of changes that would be blocking for us to adopt the new blockstore crate. If we find a way that works for both of us, I'm happy to start contributing the above mentioned blockstore implementations to the new crate (feature-gated or in side crates of course). If needed, I'm also happy to talk live. You message me @matheus23 in the https://fission.codes/discord

[matheus23]

Hi! Any updates on this? Not that I need this right now, but I'd like to know what your position on this issue is. Do you want to create "the" blockstore crate in the rust ecosystem (given you've taken the "blockstore" crate name on crates.io, which not even the FVM team has done) and work closely with external collaborators, or would you prefer to keep iterating on your own implementation for now? Both options are totally fine by me - I just want to know so I can plan ahead :) It would be wasted work on my part if I start extracting out our blockstore work into another crate, if it turns out you're totally fine with discussing & merging our efforts.

EDIT: Nevermind me! Bad timing, this just happened an hour ago: https://github.com/eigerco/blockstore

[zvolin]

hah, yes. We were all offsite this week. There are still a few things to handle on our side and we're currently in bug hunting mode as there are few issues that bother us, so sorry for being little responsive. We would also like to release the blockstore 0.2.0 in it's current state next week