amirouche

Fair. The goal is eventually to convert to paid search for people with their own harness, or deep search. Preview or not, does not change the balance, when what you need is depth.

Everyone has their own challenge for generative AI. Mine was a search engine for about €150. A month or so later, here it is. Claude Code wrote most of the code; the architecture and storage layer are mine, built on years of earlier work. €150 is compute and storage at hetzner, and one month of claude pro max x5.

It needs polish here and there, but the results hold up, and some of its quirks surprised me in good ways. No ads, no tracking, no personalisation.

The corpus:

English (93M docs, 2.1 TB): Stack Overflow, arXiv, Wikipedia, Hacker News and Lobsters up to 2020

French (18M docs, 0.5 TB): theses.fr, Persée, Gallica, Wikisource, Wikipédia

How it’s built, since that’s probably the interesting part here:

Everything is Chez Scheme. The storage layer is an ordered key-value store (it implements SRFI-167/168, which I wrote) running as an LSM tree.

The C parts: libtls, liburing, picohttpparser, libc. French and English are separate indexes. Mixing them corrupted document frequencies in an earlier version, because French and English words collide after stemming.

Known weaknesses: ranking is the next big piece of work.

What would help most: a query where it failed you, or a source you think belongs in the corpus and why. I’m especially curious which corpora people would put in a “technical history” index.

The code isn’t public yet. I want to see what people actually use before I freeze the design.

There is json output: https://h9p3r.fr/?q=biological+intelligence+future+&lang=en&...

This repository was generated by Claude (Anthropic) as an experiment—to explore how Claude works and to reverse-engineer its approach. I spent a few hours discussing the idea with both Claude and ChatGPT, focusing on how to build a content-addressable, multilingual infrastructure for Python.

Two small PRs, each based on a single prompt, resulted in a CLI that captures the core idea. The goal was to make it relatable to others—let me know if it resonates with you.

Observations & Process: Claude asked a lot of clarifying questions, while ChatGPT "hallucinated" a broader "cognitive ecology" (likely because I’d mentioned the project under the name "mobius"). The final README reflects a blend of ChatGPT’s grandiose vision and Claude’s more grounded approach. It frames ouverture as a symbiotic post-LLM relationship—a bridge between existing knowledge (including code) and post-LLM AI systems.

The Bigger Picture: If ouverture succeeds, it could become an infrastructure like npmjs—but with less friction, less drama, and fewer barriers. The irony? The README’s vision remains relevant even without LLMs. The core idea—content-addressable, multilingual code—stands on its own.

Origins & Goals: This idea has been brewing for over a decade. My original goals were:

Code as a reusable resource: Write a function, store it, forget it, and retrieve it later—dependencies and all—without the hassle of reinventing wheels (e.g., leftpad or buried helper functions). Lowering cognitive barriers: Enable people to contribute to code without requiring English proficiency, aligning with the "think globally, act locally" ethos.

Inspirations: Key projects that shaped this thinking:

- Unison (content-addressable code) - Abstract Wikipedia (multilingual knowledge) - Situated Software

ouverture.py is my answer to [this Lobste.rs discussion on easing the production of micro-libraries](https://lobste.rs/s/ebbaed/how_ease_production_micro_librari...).

Proof of life should the next stop [for more people].

Note: An attacker needs to be stronger than one defense, that is unlike being stronger than the sum of all defenses.

Note2: What we now see as a collective ie. a generated reality, existed before now, and is documented, the following comes to mind 1984, Good Bye Lenin, The Village M. Night Shyamalan, and IIRC Gate to Avalon, by Mamoru Oshii.

edit: added squared brakets.

Using a dedicated on-disk file format, that is, a custom index has much advantages, optimizations opportunities. I thought using an existing OKVS would be an advantage from a time to market perspective, but it is not the case :)

I do not think that PDF is worth taking space in my personal knowledge base. Thanks for sharing.

Indeed, I jumped into PostgreSQL documentation, that's where I started reading about materialized views.

Read the whole textbook, MATERIALIZED VIEW requires a REFRESH that is outside the transaction that made the change: https://www.postgresql.org/docs/current/rules-materializedvi...

I am saddened they picked idioms from the database paradigm I invented, fixed the bugs I reported directly to ccorcos upon his request about this very project, and did not even subtly mention my work.

Hiding https://okvs.dev is an antipattern.

The user interface is inspiring.

See also https://ccorcos.github.io/filing-cabinets/

I killed my notion.so account.

Like other have said javascript makes it slow. sourcehut.org: great. twitter: unsuable. mastodon: barely. github: ok-ish. gmail: ko. protonmail: ko. I use a rpi400 with 4GB of RAM. I forgot to mention the builtin wifi does not work great. I am using Ethernet. I am using the rpi400 to write this message, and I have been using it for two weeks. I tried ubuntu 22.04, 64bit raspberry pi OS too. And I intend to keep using the rpi400, and build my projects on top of it.

surfing the web is a pain. I use a phone for webmail stuff, otherwise fallback to tui. rpi400 with alpine 64bit, external 1To SSD usb 3.

> But what you could do is take English...

Then it is not english but a subset of english. They are translation systems that work the way you describe already using restricted natural language grammars.

Scalable? Citation needed.

It is well-known wikidata does not scale. Whether it is in terms of number of data contribution or number of queries. Not only that, but the current infrastructure is... not great. WBStack [0] try to tackle that but it is still much more difficult to enter the party, than it could be. Changes API? None. That means that it is not possible to keep track of changes in your own wikidata/wikibase instance improved with some domain specific knowledge. Change-request mechanic? Not even in the roadmap. Neither is it possible to query for history of changes over the triples.

Wikidata GUI can be attractive and easy to use. Still, there is big gap between the GUI and the actual RDF dump, that is, making sense of the RDF dump is big endeavor. Who else wants to remember properties by number? It might be a problem of tooling. Question: how to add a new type of object to the GUI? PHP? Sorry.

I do not downplay the role of wikimedia.

[0] https://addshore.com/2020/01/wbstack-infrastructure/

I think, I do not understand the question.

The implementation is mostly in https://github.com/amirouche/copernic/blob/master/copernic/v...

It used in frontend/views.py

I can elaborate on how it works if you want.

Or do you mean "How a B2C or B2B product can take advantage of the change-request mechanic?". Or in other words, "How to implement change-request mechanic in another product?".

The code is at: https://github.com/amirouche/copernic

A quick tour is available at: https://www.youtube.com/watch?v=wqbYfuOhG9w

Here is the equiavlent of the following SPARQL query:

  SELECT ?uid ?key ?value WHERE {
    ?uid <http://title> "copernic" .
    ?uid ?key ?value
  }

link: http://copernic.space/query/?uid0=uid%3F&key0=title&value0=c...

It just happens that I have been working on something like that, posted on Show HN.