Maxim mxmzb

LLM Wiki v2

A pattern for building personal knowledge bases using LLMs. Extended with lessons from building agentmemory 20K+ Stars ⭐️, a persistent memory engine for AI coding agents.

This builds on Andrej Karpathy's original LLM Wiki idea file. Everything in the original still applies. This document adds what we learned running the pattern in production: what breaks at scale, what's missing, and what separates a wiki that stays useful from one that rots.

What the original gets right

The core insight is correct: stop re-deriving, start compiling. RAG retrieves and forgets. A wiki accumulates and compounds. The three-layer architecture (raw sources, wiki, schema) works. The operations (ingest, query, lint) cover the basics. If you haven't read the original, start there.

LLM Wiki

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

The core idea

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

How to get Telegram Bot Chat ID

Content :

Create a Telegram Bot and get a Bot Token
Get Chat ID for a Private Chat
Get Chat ID for a Channel
Get Chat ID for a Group Chat
Get Chat ID for a Topic in a Group Chat

Create a Telegram Bot and get a Bot Token

Implement user API keys with Supabase

!!!!! THIS GIST SHOULD BE CONSIDERED DEPRECATED.

This is pretty much my first crack at this. I'm sure things could be improved or done differently.

Rationale

JWTs are at the heart of Supabase authorization, but sometimes we wanna build an app that also gives users access via API keys; or perhaps only exclusively via API keys. As you may know, using JWTs as API keys makes them difficult to revoke and therefore a security issue.

We also want to ensure this doesn't significantly add to RLS polices, if at all.

Key Points

In general, binaries built just for x86 architecture will automatically be run in x86 mode
You can force apps in Rosetta 2 / x86 mode by right-clicking app, click Get Info, check "Open using Rosetta"
You can force command-line apps by prefixing with arch -x86_64, for example arch -x86_64 go
Running a shell in this mode means you don't have to prefix commands: arch -x86_64 zsh then go or whatever
Don't just immediately install Homebrew as usual. It should most likely be installed in x86 mode.

Homebrew

Not all toolchains and libraries properly support M1 arm64 chips just yet. Although

Replacing Create React App with the Next.js CLI

How dare you make a jab at Create React App!?

Firstly, Create React App is good. But it's a very rigid CLI, primarily designed for projects that require very little to no configuration. This makes it great for beginners and simple projects but unfortunately, this means that it's pretty non-extensible. Despite the involvement from big names and a ton of great devs, it has left me wanting a much better developer experience with a lot more polish when it comes to hot reloading, babel configuration, webpack configuration, etc. It's definitely simple and good, but not amazing.

Now, compare that experience to Next.js which for starters has a much larger team behind it provided by a world-class company (Vercel) who are all financially dedicated to making it the best DX you could imagine to build any React application. Next.js is the 💣-diggity. It has amazing docs, great support, can grow with your requirements into SSR or static site generation, etc.

So why

README

When Gatsby starts up, it will read gatsby-config.js first.
As you can see below, we use that file to require('ts-node').register() which registers a TypeScript evaluator that will be used when Gatsby reads all other API Javascript files. In other words, we only need to do this once in our entire codebase and not in other Gatsby files like gatsby-node.js.
Our gatsby-config.js re-exports all the exported variables available in gatsby-config.ts.

Advanced memoization and effects in React

Memoization is a somewhat fraught topic in the React world, meaning that it's easy to go wrong with it, for example, by [making memo() do nothing][memo-pitfall] by passing in children to a component. The general advice is to avoid memoization until the profiler tells you to optimize, but not all use cases are general, and even in the general use case you can find tricky nuances.

Discussing this topic requires some groundwork about the technical terms, and I'm placing these in once place so that it's easy to skim and skip over:

Memoization means caching the output based on the input; in the case of functions, it means caching the return value based on the arguments.
Values and references are unfortunately overloaded terms that can refer to the low-level implementation details of assignments in a language like C++, for example, or to memory

	# 2023-11-27 MIT LICENSE

	Here's the open source version of my ChatGPT game MonkeyIslandAmsterdam.com.

	It's an unofficial image+text-based adventure game edition of Monkey Island in Amsterdam, my home town.

	Please use it however you want. It'd be nice to see more ChatGPT-based games appear from this. If you get inspired by it, please link back to my X https://x.com/levelsio or this Gist so more people can do the same!

	Send me your ChatGPT text adventure game on X, I'd love to try it!

	type CamelCase<S extends string> = S extends `${infer P1}_${infer P2}${infer P3}`
	? `${Lowercase<P1>}${Uppercase<P2>}${CamelCase<P3>}`
	: Lowercase<S>

	type KeysToCamelCase<T> = {
	[K in keyof T as CamelCase<string & K>]: T[K]
	}


	type CamelToSnakeCase<S extends string> = S extends `${infer T}${infer U}` ?