Really nice to see BFT starting to be taken seriously in CRDT research. I had done some research in this area last year and came to a lot of the same solutions (i.e. BRB protected CRDTs when dealing with VClock based CRDTs):
We ended up moving away from VClock crdts entirely for our work and going with grow-only hash-graph CRDTs as they have don't need the BRB overhead (as Martin has found in his research as well).
I will stop looking into this now, I have to get back to my work. The colorful language doesn't make it easy for someone who follows the literature to review your idea.
I still have doubts that you can handle a dropped message or how much control a faulty node has over decisions, but I'll leave that to you to work out.
> n ∈ N (p), where N (g) is the set of gnomes who can hear g, including himself. Note that h ∈ N (g) ⇐⇒ g ∈ N (h).
> Each gnome g tracks the spread of the proposal in the following way: once all his neighbors n ∈ N (g) say their k-neighborhood (or bigger) is aware of the proposal
If I understand this correctly, a single node crashing would stall it's entire neighbourhood. @gritzko, can you confirm?
I'd say the chance is much higher for B2B businesses. Say my Shopify store fails so I cancel my subscription. But I'll likely come back and try my luck again with Shopify on my next idea since I've learned the platform.
These companies should realize they are playing an iterated prisoners dilemma game with their customers. Just because your services aren't right for me today, doesn't mean I won't come back in the future and pay for your services again now that I know what you do.
But I doubt I'd come back if my last experience with a company has been a bad cancellation procedure.
3% conversion on a product that costs $20k is normal? I don't think so.
As to your cynical meta-analysis, these people are doing something really difficult. I'm very happy to celebrate with them in any of their little victories, good on them! I hope to see more from them in the future
Maintainer here, it's meant to be a visual representation of a 2-tuple of natural numbers.
But I get your point, there was another commentator here who expressed similar frustrations. When I find some time, I'll see about picking a clearer example for the README
Sounds like you avoid the problem entirely, wish we could do the same but we've committed to a working in a ecosystem that is still quite nascent which leads to a lot of churn in our deps.
I see, I've set my browser to block third party javascript, on inspection, it seems the author has decided to download the markdown render script from what looks to be an analytics firm.
(https://casual-effects.com/markdeep/latest/markdeep.min.js)
I've been working on this distributed offline-first datastore that uses the Git protocol as the network layer. I'm calling it GitDB (but the Git trademark is getting more strictly enforced these days so that'll need to change).
The idea is that we should be able to build tools where the user can understand and manage where data is stored while at the same time keeping many of the conveniences of modern apps, like cross-device sync.
As a user, you can decide if you trust Github, Gitlab, Bitbucket, etc. and pay them to host your data.
The first tool I wanted to build with GitDB was a password manager but seeing this post made me wonder if there would be enough people who wanted this level of control over data, does this sound like something you'd be into?
This work is all super early, but would love to gauge the interest from others.
