wnfs-wg / deterministic-bloom

A deterministic Bloom filter with support for saturation. Suitable for distributed use cases and as a cryptographic primitive.
Apache License 2.0
0 stars 0 forks source link

Port from `rs-wnfs` #2

Closed expede closed 1 year ago

expede commented 1 year ago

Licensing test is failing — will look at it in the morning, but it's otherwise RFR

zeeshanlakhani commented 1 year ago

Licensing test is failing — will look at it in the morning

just needs BSD-2-Clause and BSL-1.0 added to the list of licenses. I didn't want to make all the opines in the template.

expede commented 1 year ago

Ah, clippy is unhappy about some stuff in the test utils. I'll look tomorrow; I have a flight so I have to get up relatively early

zeeshanlakhani commented 1 year ago

Licensing test is failing — will look at it in the morning

just needs BSD-2-Clause and BSL-1.0 added to the list of licenses. I didn't want to make all the opines in the template.

oh, derp, and CC0-1.0 :).

expede commented 1 year ago

Oh also I wasn't really sure what to wrap for Wasm. I can serialize the filter, but that seems wasteful in the normal case 🤷‍♀️ I think I want to do some stuff with WasmRefCells, but that seems like a "not this instant" thing. Thoughts?

matheus23 commented 1 year ago

Oh also I wasn't really sure what to wrap for Wasm. I can serialize the filter, but that seems wasteful in the normal case woman_shrugging I think I want to do some stuff with WasmRefCells, but that seems like a "not this instant" thing. Thoughts?

I'm thinking the most efficient way will be to expose it as Rc<BloomFilter<...>> and in some way make it so that it's available as a Uint8Array on the JS side. This would allow the Uint8Array to not be copied into the JS side, but instead the JS side would just have something that points into Wasm memory.

The Rc + something like wasm-bindgen's --weak-refs feature is how I imagine figuring out when repurposing the memory on the rust side is safe. I'm not 100% sure how that'd work.

matheus23 commented 1 year ago

do you think we'll want more in-between variations for wasm?

We'll probably want a runtime-dynamic version for Wasm, honestly. The const-based version is good for doing benchmarks & WNFS, but it's not good for e.g. CAR mirror.

walkah commented 1 year ago

@matheus23 any reason to not merge your PR #3 into this and merge this to main? I've created #4 as a follow up for dynamic sizing.

matheus23 commented 1 year ago

@walkah no reason besides it's missing a review :man_shrugging:

matheus23 commented 1 year ago

@walkah It's like I'm reviewing my own code haha I'll just go ahead and merge