jchanimal

What’s MOND really mean? Here’s the Wikipedia entry https://en.wikipedia.org/wiki/Modified_Newtonian_dynamics

We've been using this at work to get inside of our customer's perspective. It's helpful to throw eg a bunch of point-of-sale data sync challenges into Notebook LM and eg pass a 10 minute audio to the team so they can understand where our work fits in.

If you like, solving these sort of problems, we are tackling them at Fireproof.

Our database API is modeled on CouchDB and MongoDB, but our storage abstractions are along the lines of what you need to build the multi writer WAL you describe.

More details here https://jsr.io/@fireproof/encrypted-blockstore

We are wrestling with questions like this on the new document database we’re building. A database should correspond to some administrative domain object.

Today in Fireproof a database is a unit of sharing, but we are working toward a broader model where a database corresponds to an individual application’s state. So one database is all the shared documents not just a single unit of sharing.

These small changes early on can have big impact later. If you’re interested in these sort of design questions, the Fireproof Discord is where we are hashing out the v0.20 api.

(I was an early contributor to Apache CouchDB. Damien Katz, creator of CouchDB, is helping with engineering and raised these questions recently, along with other team members.)

Fireproof (new local first database) is hiring.

Fireproof is taking the lessons of cloujure and Ipfs and applying them to the browser, to create a realtime database that runs anywhere.

As cofounder of Couchbase I got to meet Rich Hickey, whose work was a big inspiration to Fireproof.

Content addressing makes causal consistency easy to implement. We are fast approaching readiness for consistency checks and ACID characterization.

Yes that’s what you’d do. Makes sense to partition eg one chat per database file / proof chain, for lots of reasons including that.

Does this roughly equate to a 99.9% margin? Using comparable analysis if it was a company.

The full op-log plus deterministic merging is a great fit for immutable block storage, which can have other security, performance, and cost benefits. I'm building Fireproof[1] to take advantage of recent research in this area. An additional benefit to content addressing the immutable data is that each operation resolves to a cryptographically guaranteed proof (or diff), enforcing causal consistency and allowing stable references to be made to snapshots. This means your interactive, offline-capable, losslessly-merging database can run on the edge or in the browser, but still have the integrity you'd have looked to a centralized database or the blockchain for in the past. (Eg you can drop a snapshot CID into a PDF for signature, or a smart contract, and remove all ambiguity about the referenced state.

[1] https://github.com/fireproof-storage/fireproof

Seems like a reasonable way to solve the packing problem. You could override to set priority levels for people, but the background process makes sure no one person goes too long without a meetup.

Is anyone building a personal social friend graph / calendar hangout maximizer with spaced repetition?

It's fun to think about the theoretical maximum in a multi-link scenario. One thing that pops out of the analysis -- there are diminishing returns to capacity from adding more links. Which means at some point an additional link can begin to reduce capacity as it starts to eat more into maintenance and uptime budget than it offers in capacity.

Thanks, we recently started working with a designer, I can't way to share the new homepage soon.

In the same way SQL encourages you to normalize your data for DRY representation, NoSQL encourages you to denormalize for fast retreival. I wrote about this more than a decade ago, and the basics haven't changed: https://web.archive.org/web/20160312130429/http://blog.couch...

[Note] I'm a cofounder of Couchbase, my new project is a realtime embedded JavaScript database with local-first sync: https://fireproof.storage

Is anyone using this as the eyes and mouse of an AI copilot yet?

It fits on your phone, and your phone can offload battery burning tasks to nearby edge servers. Seems like the path consumer-facing AI will take.

I liked your comment but then I "fact-checked" it. OT but curious how wrong this is: https://chat.openai.com/share/638e5461-7a4d-4c12-9103-da1b81...

I can't help but think of https://en.wikipedia.org/wiki/Seveneves about the aftermath of the splitting of the moon.

Having founded a database company that IPO'd (Couchbase) and seeing the kinds of customer relationships Supabase is making, an IPO seems a reasonable outcome.

If you like the idea of the Dolt prolly trees[1], I'm building a database[2] that uses them for indexing, (eventually) allowing for shared index updates across actors. Our core uses open-source JavaScript[3], but there are a few other implementations including RhizomeDB in Rust[4]. I'm excited about the research in this area.

[1] https://docs.dolthub.com/architecture/storage-engine/prolly-...

[2] https://fireproof.storage

[3] https://github.com/mikeal/prolly-trees

[4] https://jzhao.xyz/thoughts/Prolly-Trees

We love PartyKit as a real time sync connector for Fireproof. This lets us offer CouchDB or Firebase-like experience with only a browser and less than 100 lines of JavaScript on the backend. Here is what our PartyKit server looks like for the curious: https://github.com/fireproof-storage/fireproof/blob/main/pac...

I describe this idea of an executable feature spec in my roadmap blog post from earlier this year. I agree it’s a great way to think about it.

https://fireproof.storage/posts/roadmap-to-1.0/

We’d define 1.0 in exactly the way you describe, where we can add tests for 1.1 but not remove them without triggering 2.0

Fireproof uses a 2-layer CRDT (the inner CRDT is encrypted). We also use prolly-trees for indexing. You can read more about the storage engine here: https://fireproof.storage/posts/remote-access-crdt-wrapped-m...

Edit to add: we extracted the outer blockstore so anyone doing immutable data or ipfs can take advantage of our sync connectors. https://www.npmjs.com/package/@fireproof/encrypted-blockstor...

Less than 100 microns! You can lithograph on Proxima Centauri with that setup. Maybe PKD…

Size of a Texas ranch. Call it “reverse solar” and you might have a winner.

You can use this approach to make complex behavior from simple rules https://en.wikipedia.org/wiki/Subsumption_architecture

According to the JSON spec it's also legal to round all numbers to zero.

Creator of Couchbase Mobile here — I’m doing a new web-based thing[1] with a similar reactive API. I’m hoping that my encrypted block replication makes it more of a “data anywhere” solution than a “local first” database. But the paradigm of powerful databases in the browser is definitely one I’m glad to see becoming popular.

[1] https://fireproof.storage/

This is basically how Fireproof works: files to S3, reads from any cache, encryption metadata in your session store. All of this becomes “easy” if you write a storage engine from scratch for immutable content addressed data.

Insane argument that regulatory capture is the best possible outcome. Are you suggesting anything more just would undo society?