You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 30, 2023. It is now read-only.
It seems like it could be a valuable update but I would need to know the performance tradeoff, since usually a cryptographic key verification needs to take place within canAppend.
@tabcat can you help @pashoo2 with benchmarking when you get a chance?
@aphelionz@tabcat sorry i've seen the mention today.
I meant that there is a code that apply filters to heads when a syncronization with another peer is performing, but i suppose it should be done also when reading heads from a local presistant storage to memory.
I don't remember the exact case, but it seems not neccessary to read such heads for consistency of a local statw with another peer sync logic
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
https://github.com/orbitdb/orbit-db-store/blob/2ebc0c2cbec70cc98e7cd0f45edc077853098f72/src/Store.js#L241
Why don't to filter the heads as it's already implemented within the "sync" method, that is called during synchronization with another peer?
https://github.com/orbitdb/orbit-db-store/blob/2ebc0c2cbec70cc98e7cd0f45edc077853098f72/src/Store.js#L295
The text was updated successfully, but these errors were encountered: