marcobambini

Developing a programming language from scratch was a project that literally drained every ounce of energy I had for years. Every moment of every day, of every month, was devoted to thinking about how to make Gravity faster, safer, more efficient, and easier to embed.

Today, all of this can be done in just a few hours, with almost no mental effort.

This opens up new and limitless possibilities. Yet, although I am grateful for the entire journey and everything I learned along the way, it also makes me feel a little like a dinosaur watching a beautiful shooting star that will soon bring about its extinction.

Thanks guys for all the comments, I am going to rewrite the README (without using an LLM)

We are backed by the SQLite author, and we have the right to use the SQLite name. Please do your homework before writing such comments.

We used an Elastic license for some projects to protect our work from being used in SASS without a prior agreement. WASTE is and will always be available with a very permissive license.

I really don't understand why some people prefer to spread hate instead of just asking for clarification first.

I wrote tons of software, even a programming language by hand https://github.com/marcobambini/gravity.

I'm using my skills to orchestrate LLMs and agents, and I can write better code much faster. As developers, we can choose to adapt to new technologies or become extinct.

It is not yet available, the only way is to download the official Kimi K3 model and then convert it:

# 1. preflight: reachable? how big? does it fit? tools/fetch_weights.sh --dest /Volumes/staging/k3 --dry-run

# 2. download — resumable, safe to kill, safe to re-run tools/fetch_weights.sh --dest /Volumes/staging/k3

# 3. convert into a container uv run --with torch --with safetensors python tools/convert.py \ --src /Volumes/staging/k3 \ --out ~/models/k3.waste --jobs 3

We tried to use Metal, but for that specific project it was slower than just using NEON ARM optimizations. It is all documented in the docs.

Right, we trade speed for the ability to run a 2.7T-parameter model while preserving accuracy. It is a first version, and we plan to improve the inference performance.

M5 Pro

How a simple CRDT algorithm unlocks something surprisingly powerful: AI agents that learn from each other without ever talking to each other.

Modern AI agents need persistent, searchable memory to maintain context across conversations and tasks. Inspired by OpenClaw's memory architecture, sqlite-memory implements what we believe will become the de facto standard for AI agent memory systems: markdown files as the source of truth.

In this paradigm:

* Markdown files serve as human-readable, version-controllable knowledge bases

* Embeddings enable semantic understanding and retrieval

* Hybrid search combines the precision of full-text search with the intelligence of vector similarity

sqlite-memory bridges these concepts, allowing any SQLite-powered application to ingest, store, and semantically search over knowledge bases.

No, the library is intentionally minimal on that front. It generates and validates keys but doesn't track any metadata about them. Keys are plain C strings, so detecting "time to compact" is straightforward on the caller's side:

  - Key length is the most natural signal, just strlen(). If your base62 keys are typically 3-5 characters and you start seeing 15+, that's a reasonable trigger.

  - Max key length in the list is cheap to track if you're already iterating for display or sync.

Keeping that policy out of the library is intentional. What counts as "too long" depends entirely on the application. A SQLite column with a B-tree index cares about different thresholds than an in-memory CRDT. And the right moment to compact (sync boundary, idle tick, batch write) is an app-level scheduling decision the library has no business making.

Good question, in the current version, compaction is left to the caller.

The library does a few things to keep key growth practical:

  1. generate_n_keys_between: if you know you're inserting N items at once (e.g. a bulk paste or drag of multiple items), it distributes them evenly in a single call rather than chaining N sequential generate_key_between calls, which would produce progressively longer keys.

  2. Higher bases: base62 (default) and base95 give you a much wider branching factor per character than base10, so keys stay shorter under the same insertion patterns.

But yes, in a long-lived list with adversarial insertion patterns (always inserting at the same spot), keys will grow unboundedly, that's inherent to the algorithm. In practice, compaction is an application-level concern: you'd pick a quiet moment (or a sync boundary, if you're doing CRDT-style collaboration) and renumber the whole list with fresh, evenly spaced keys.

The library gives you generate_n_keys_between(NULL, NULL, n) which makes trivial to generate N fresh keys for the whole list in one call.

Author here... it is free for open-source projects.

What kind of license would you like more?

If you don't understand what we are building, that doesn't mean you need to post such an inappropriate comment.

Just to clarify a point that seems to come up in several comments: we are backed by SQLite’s author, and we have explicit permission to use “SQLite” in the company and product names.

We believe SQLite on the edge is a major opportunity, and our focus is on building genuinely new features and infrastructure on top of it.

Hello, SQLite Cloud's founder here. We are backed by SQLite's author, and we have the full rights to use SQLite in the company's and products' names.

We are backed by SQLite's author, and we have the full rights to use SQLite in the company's and products' names.

Hello, SQLite Cloud's founder here. We are backed by SQLite's author, and we have the full rights to use SQLite in the company's and products' names.

I sincerely apologize for that. I am not a native English speaker, so I always use LLM to polish my articles before publishing.

The algorithm has a way to resolve conflicts even if, by any chance, the Lamport clock has the same value in all peers

I understand your concerns about the license, but our goal was simply to prevent large corporations from taking our work, forking it, and offering it to their customers while we struggle to sustain development. We need to monetize our work in order to survive, though we do offer very generous commercial licenses for those who are interested.

We are backed by the SQLite author (Dr. Richard Hipp), and we have full rights to use the SQLite name.

Instead of sqlite-vec you can take a look at the new sqlite-vector extension: https://substack.com/home/post/p-172465902

I'd like to point out the following open-source SQLite project: https://github.com/sqliteai/sqlite-sync with a built-in cross-platform network layer.

P.S. I am the author of the project.

There is a new solution that is worth considering: https://github.com/sqliteai/sqlite-sync

P.S. I am the author

API naming looks similar, probably because we are based on the same scientific paper: https://munin.uit.no/bitstream/handle/10037/24430/article.pd...

1. Good point, we are going to publish more details about constraints in the repo within a few days 2. We have implemented row-level security, so you are free to easily implement any privacy role you want: https://docs.sqlitecloud.io/docs/rls. The "forbidden" rows are not synced

About encryption: all communications are over TLS.

This is not true. We are also backed by Dr. Richard Hipp, the creator of SQLite, and we have all the rights to use the SQLite name in our products.

We chose to adopt the Elastic License 2 primarily because of the significant investment we've made in developing this technology, including a robust cross-platform network layer that enables users to implement offline-first functionality with just two lines of code. This license also helps protect our work from being forked and commercially exploited by larger tech companies.

Yes, you are formally right, it is source available.