Doug Hoyte

Am I misreading the benchmark? IH: `Object: write (x100000): 382 ms` UI: `Object: write (x100000): 125 ms` IH: `Object: deep write (x100000): 448 ms` UI: `Object: deep write (x100000): 202...

Hehe yes I figured that's what you were looking at :) I think the total is a bit misleading since it's heavily skewed to the longer running tests and the...

Yes that is true: One of the advantages of the react update() system is that the overhead of the recursive traversal and shallow copying can be amortised over a number...

Hmm interesting. What do you see as being the use-case for this? My concern is if this would break backwards-compatibility of the react update() interface.

I think I understand, but just to clarify, what is the advantage over doing something like: const nextTodo = await loadTodoFromServer(); this.setState(update(this.state, { todos: { '$set', nextTodo } }));

Yes it's an interesting concept, although I'm wondering if there could be a way to implement it as a wrapper around update() instead of modifying its internals.

Hi! Sorry for the late reply. I did consider many different protocols for syncing of nostr events, and in fact I previously was using an entirely different approach: https://github.com/hoytech/quadrable#syncing I...

I found a paper that describes a scheme that uses bloom filters, in addition to an Invertible Bloom Lookup Table (IBLT): https://people.cs.umass.edu/~gbiss/graphene.pdf

I did a bit more reading, and found a good summary of the issues here: https://www.sciopen.com/article/pdf/10.1109/TST.2016.7442499.pdf "For the SBF-based set reconciliation method, due to false positives, some different objects unique...

I've built an IBLT (invertible bloom lookup-table) implementation. More info here, in case anyone is curious: https://github.com/hoytech/riblet