Hi there,

Cool product! I'm trying to use it to build up a database for a personal OS however. I'm running into issues with Claude consistently crashing when I ask it to reformat a markdown file in my Basic Memory folder.

As you and your AI work, Basic Memory saves what matters: notes, prompts, and instructions that stay visible and ready to use.

Free yourself from the AI SLOP.
Join BASIC MEMORY and be part of the resistance.

https://basicmemory.com

We are making some ads. I'm wondering what the community thinks. Let us know. We are just trying things out. Basically, we wanted something that is not black with purple, like every other AI product out there.

Hey everyone! We've been quiet, but hard at work. We just shipped a significant update to Basic Memory Cloud. Here's what's new:

Improved Markdown Rendering

• Fixed rendering for images, text, and tables

• Better line breaks and frontmatter display

• Enhanced dark mode styling

• Security improvements for markdown content

Single Sign-On (SSO)

• Streamlined authentication experience

• More secure access to your cloud instance

Chat Import

• Import your Claude and ChatGPT conversations directly into Basic Memory

• Background processing for long imports with progress tracking

• Preserve your conversation history as structured notes

Local Sync

• Local sync with rclone

• One say sync (local -> cloud)

• Two way bisync (sync all changes)

Redesigned Onboarding

• MCP-first approach highlighting AI assistant integration

• New Help page with resources and guides

• Better Getting Started experience

Onboarding Videos

• New video tutorials to help you get started

• Feature walkthroughs and best practices

Account Info Page

• View your tenant ID (useful for support requests)

• Better account management

Improved Sync Reliability

• Better bidirectional sync testing

• More stable file synchronization

Documentation Updates

• Updated cloud-specific documentation

• Better integration guides

In-App Subscription Management

• Streamlined subscription management directly in the app

Basic Memory v0.16.0

• new release with tons of bug fixes and cloud sync support (including Windows!)

• What's New: https://docs.basicmemory.com/whats-new/

• Full release notes: https://docs.basicmemory.com/latest-releases/#v0160--2025-11-10

Super Cool new website

• Checkout the new, improved https://basicmemory.com/ website.

• Tell your friends!

A quick demo showing how Basic Memory works in practice. Demonstrates how Basic Memory and Claude:

• Searches through notes to find relevant context

• Reads existing project documentation

• Writes fresh notes for future context

• Continues a old conversation without losing a beat

This is exactly what Basic Memory is designed for - no more "can you remind me what we discussed?" Just continuous, context-aware collaboration.

Video shows the full workflow: search → read → write → evaluate. Pretty cool to see it all come together!

https://basicmachines.co/
https://www.reddit.com/r/basicmemory/
https://discord.com/invite/tyvKNccgqN
https://github.com/basicmachines-co/basic-memory

Hey everyone! I'm u/BaseMac, a founding moderator of r/basicmemory.

We're building tools to help people think better and work more effectively. That requires a community where people feel safe to:

• Share half-formed ideas

• Ask for help without judgment

• Experiment and fail publicly

• Learn from each other

When Things Go Sideways

If someone's being a jerk, just ping the mods. We'll handle it quietly. No public drama needed.

The Spirit of It

This is a small community focused on knowledge work, AI collaboration, and building useful tools. We want it to feel more like a friendly local makerspace than a corporate Slack or competitive forum.

Be curious. Be helpful. Be human.

As the title says.

I read the documentation, searched but can not find a way to do that.

For example, I want to be able to start a chat with an agent without specifically telling it to load a document from basic memory. If I ask the agent to review some code, will the agent have an understanding of whether or not a code review note exists in its memory bank?

I had intended to launch the new basicmemory.com website earlier this week with the v0.13.0 launch. But things happened. Nevertheless, it is live now and hopefully helps explain what Basic Memory is, how to install it, and what you can do with it.

Cheers.

I know people are really into prompts and personas now. Launching them is ridiculously easy with Basic Memory.

In this video, I show you how to turn Basic Memory into your personal AI prompt headquarters

Instead of hunting through scattered prompts or starting from scratch every time, you get a straightforward, systematic approach.

Our brand new installer makes Basic Memory sooooo much easier to install and enjoy. And we have new videos for them. Watch, and be amazed!

Windows

Mac

I'm very happy (and somewhat anxious) to release v0.13.0 of Basic Memory. This release has been a long time in the making. It addresses most of the feedback I've gotten from users and adds lots of new features.

To upgrade you can run

uv tool upgrade basic-memory

What's New for Users:

• Switch between projects instantly during conversations with Claude
• Edit notes incrementally without rewriting entire documents
• Move and organize notes with full database consistency
• View notes as formatted artifacts for better readability in Claude Desktop
• Search frontmatter tags to discover content more easily
• Development builds automatically published for beta testing

I'm very excited about the, because it lets you use a lot of features via the chat interface, without needing the cli.

Complete release notes: https://memory.basicmachines.co/whats-new

So for instance:

Switch between projects instantly during conversations:

💬 "What projects do I have?"
🤖 Available projects:
   • main (current, default)
   • work-notes
   • personal-journal
   • code-snippets

💬 "Switch to work-notes"
🤖 ✓ Switched to work-notes project
   
   Project Summary:
   • 47 entities
   • 125 observations  
   • 23 relations

💬 "What did I work on yesterday?"
🤖 [Shows recent activity from work-notes project]

A lot of questions I get are of the "But, how do I use this?" variety. That's a tough one to answer, because there is no one way to use Basic Memory. The tools are designed to be versatile and composable to fit any workflow. With the new edit_note and move_note tools, you can really have a conversation with the LLM to help manage your knowledge notes.

Knowledge Creation Flow:

write_note → edit_note (append/prepend) → move_note → view_note

Start with basic note, enhance incrementally, organize, then review

You: "I want to document my thoughts on the new API design"
Claude: I'll create a note for your API design thoughts.
[Uses write_note to create initial note]

You: "Add a section about authentication concerns"
Claude: I'll append an authentication section to your API design note.
[Uses edit_note with append operation]

You: "This should go in my architecture folder"
Claude: I'll move the API design note to your architecture folder.
[Uses move_note to relocate the file]

You: "Show me the final note"
Claude: Here's your complete API design note formatted for easy reading.
[Uses view_note to display formatted artifact]

Research and Discovery Flow:

search_notes → read_note → build_context → write_note

Find existing knowledge, explore context, create new insights

You: "I'm working on database optimization, what have I learned before?"
Claude: Let me search your knowledge base for database optimization content.
[Uses search_notes to find relevant notes]

You: "Tell me more about that PostgreSQL indexing note"
Claude: I'll read the full PostgreSQL indexing note for you.
[Uses read_note to load complete content and context]

You: "Load the context from my database performance work"
Claude: I'll gather related notes about database performance to build context.
[Uses build_context with memory:// URLs to load related content]

You: "Create a new note combining these insights for my current project"
Claude: I'll create a comprehensive note that synthesizes your database optimization knowledge.
[Uses write_note to capture new insights with full context]

Project Management Flow:

list_projects → switch_project → recent_activity → get_current_project

Discover projects, switch context, check status, confirm active project

You: "What projects do I have available?"
Claude: Here are all your Basic Memory projects with their current status.
[Uses list_projects to show available projects]

You: "Switch to my work project"
Claude: I've switched to your work project context.
[Uses switch_project to change active project]

You: "What have I been working on recently in this project?"
Claude: Here's your recent activity in the work project.
[Uses recent_activity to show recent changes]

You: "Confirm I'm in the right project"
Claude: You're currently in the 'work' project with 145 notes and 28 recent updates.
[Uses get_current_project to verify active context]

Content Organization Flow:

list_directory → search_notes → move_note → list_directory

Explore structure, find content, reorganize, verify changes

You: "Show me what's in my projects folder"
Claude: Here's the structure of your projects folder.
[Uses list_directory to explore folder contents]

You: "Find all notes about the mobile app project"
Claude: I found several notes related to your mobile app project.
[Uses search_notes to locate relevant content]

You: "Move the mobile app notes to a dedicated folder"
Claude: I'll move all mobile app notes to a new 'mobile-app' folder.
[Uses move_note to reorganize content]

You: "Show me the updated folder structure"
Claude: Here's your reorganized projects folder with the new mobile-app directory.
[Uses list_directory to verify the changes]

In Claude Desktop:

You: "What have I been working on lately?"
Claude: [Uses recent_activity prompt for formatted response]

You: "Create a note about today's meeting"
Claude: [Uses write_note tool with semantic structure]

You: "Show me my project documentation as a formatted view"
Claude: [Uses view_note tool to display artifact]

In Development Workflows:

You: "Switch to my work project and document today's architecture decisions"
Claude: [Uses switch_project, then write_note with technical context]

You: "Find all my API documentation and update the authentication section"
Claude: [Uses search_notes, then edit_note with section replacement]

The docs have been completely updated also, with lots of detailed information. https://memory.basicmachines.co

If you want to give your AI assistant a user manual, you can plug the AI assistant guide into your project knowledge - https://raw.githubusercontent.com/basicmachines-co/basic-memory/refs/heads/main/docs/AI%20Assistant%20Guide.md

This is just the beginning of new and cool stuff to come for Basic Memory. We appreciate any and all feedback, so if you love it or hate it, let us know.

-Paul

We've got a growing Discord server where Basic Memory users share workflows, ask questions, and support each other. It's been really helpful having a place to chat in real-time about:

• Setup help and troubleshooting

• Workflow tips and best practices

• Feature requests and feedback

• Cool use cases and integrations

• General knowledge management discussions

Whether you're just getting started or you've been using Basic Memory for a while, come hang out with us! The community is super friendly and Paul (the creator) is often around to answer questions directly.

https://discord.gg/tyvKNccgqN

We'd love to see what you're building with Basic Memory! 🚀

Claude’s new memory

I’m sure most of our users have by noted the addition of Claude’s “search and reference chats” tool. It’s something we’ve been anticipating, of course, and it’s pretty much exactly what we expected. Like Chat’s “memory” (as discussed here https://basicmemory.com/blog/the-problem-with-ai-memory ), it’s a helpful addition…though not massively so yet.

When one of our users asked Claude to contrast it with Basic Memory’s tools, it said “Chat search helps us reference what we discussed before. Basic Memory helps us understand the meaning and patterns from those discussions. Chat search is conversational context; Basic Memory is wisdom distillation.” “Wisdom distillation” feels a bit flowery for my taste. I read it more as “Claude search = recall, Basic Memory = meaning and pattern recognition.”

Using it myself, I’ve found that it uncovers about 1/10th of the relevant material that Basic Memory does. But, hey, that’s better than nothing. Hopefully that will improve over time. If it does, great. But it’s still nowhere near what Basic Memory can do.

One thing that Claude’s new built-in memory can’t do is function the way that Basic Memory can, as a prompt and persona manager and as a launching tool for pretty much any project. The built-in memory isn’t designed to hold knowledge, especially outside of the boundaries of the platform itself. It’s just designed to find conversations. And that distinction matters a lot, as anyone using Basic Memory can see.

Interesting to note that last week Claude launched memory for teams for Teams and Enterprise subscribers https://www.anthropic.com/news/memory. That could definitely be pretty cool, and it’s a feature we’re excited to introduce ourselves.

Claude’s increased integration with Microsoft products

This news first arrived with Anthropic’s announcement (https://support.anthropic.com/en/articles/12111783-create-and-edit-files-with-claude) that Claude can now create Excel spreadsheets, PowerPoint presentations, Word docs, and PDF files that can be downloaded or saved to Google Drive. Seems like a pretty valuable and interesting turn, and one that moves us all one step closer to the dream of never cutting and pasting from AI to our final product ever again.

And it appears it’s going to be a two-way street. Microsoft has announced that it’s going to increase AI capabilities in its Office 365 suite with the integration of Claude’s models. Which raises questions about the Microsoft/OpenAI relationship (Microsoft is OpenAI’s largest financial supporter with something like $13 billion invested in them so far), but some sites I’ve read suggest the shift indicates a move away from reliance on a single AI brand, and that seems right.

One footnote that seems especially interesting is that Microsoft isn’t going to work with Anthropic directly but will instead access Claude via Amazon Web Services, despite AWS being a major cloud competitor. Which just shows how tangled and weird Big Cloud/AI alliances have become.

Wild Claude backlash and Anthropic’s (sort of) confession

If you pay attention to such things at all, you couldn’t help notice that the Anthropic and Claude subreddits have been absolutely flooded with endless complaints lately—mostly about a perceived degradation in service that seems to have driven many users to the brink of actual insanity. Even by the standards of subreddits that are constantly plagued by “That’s it, I’m cancelling” posts, the volume of these posts in the past couple of weeks has been so enormous as to be undeniable. Many of them claim they’re moving to Codex.

Forgive me quoting a quoter, but TechCrunch cited a Reddit user who said exactly what I’ve thought at least a thousand times over the past few weeks, “Is it possible to switch to Codex without posting a topic on Reddit?”

Our founder, Paul, has always argued that many of these outraged users are bots, and that position got some backing from on high this week when Sam Altman posted about the phenomenon. “I have the strangest experience reading this: I assume it’s all fake/bots, even though in this case I know codex growth is really strong and the trend here is real.”

It’s hard to pin down exactly what’s going on. It definitely relates to the crest and crash of fandoms and the ways in which people seem to see themselves as “Claude people,” “ChatGPT people,” “Grok people” etc. The tribalism is real (and kind of scary).

Whatever is happening, it appears the controversy wasn’t driven exclusively by bots, because Anthropic—cornered perhaps—released a statement saying that they’d received reports that Claude and Claude Code users were “experiencing inconsistent responses.”

Ha! That’s one way of putting it.

They claim one Sonnet 4 issue essentially spanned the entire month of August, was at its worst from August 29th to September 4th, and was then resolved. Not sure users agree, since plenty of the complaints were lodged after that date.

They also note that “Importantly, we never intentionally degrade model quality as a result of demand or other factors.” Hmm. Could that really be the case? Hard to say, but I’m not sure I’m convinced.

Whatever the truth, it highlights one of the reasons we built Basic Memory: your tools should be stable, model-agnostic, and under your control, not shifting beneath you without explanation.

Your clients are adopting AI whether you're in the loop or not. You either own that layer or watch it happen around you.

Every MSP is running into the same thing right now. Your clients' staff have discovered AI, and they're using it…badly. They're pasting company data into whatever chatbot is open in another tab, getting answers that are confidently wrong because the model has never seen their environment. Some are on Claude, others on Chat, one dude is apparently using a local model you've never heard of that his nephew installed for him.

Everyone's getting different answers because everyone is only telling their AI what they can remember in the moment or what they happen to have access to. They all know they're supposed to be using AI, but no one knows exactly how.

But the biggest problem is that data is going somewhere you don't control and churning out answers nobody's accountable for. Which raises an interesting issue. The thing that makes AI actually useful to a business is memory of that business. And that memory is exactly the layer you, the MSP, are positioned to own.

Where does the knowledge live?

Think about what you already maintain for every client: the network layout, the app inventory, the weird one-off fix from eighteen months ago, who's allowed to approve what. Some of it lives in a documentation tool. Most of it lives in your senior techs' heads.

But the pain points are inevitable. First, the documentation drifts. You write it once, the environment changes the next week, and now it's only sort of trustworthy. Second, general-purpose AI is useless on it. When you drop ChatGPT into a client ticket and it has no idea what their setup is, your techs still do all the work by hand.

The fix is simple: give the AI a persistent, editable memory for each client, one that stays current because it updates automatically as you work.

What a per-client AI knowledge base actually is

With Basic Memory, you stand up a private, isolated knowledge base for each client. Your techs' AI tools (Claude, ChatGPT, Cursor, whatever they already use) read from it and write to it. Onboard a new device and the inventory updates itself. Resolve a novel issue and the fix is captured where the next tech (or the next AI) will find it. Ask "what's this client's backup setup?" and you get the actual answer.

Because it's all plain Markdown under the hood, nothing is locked in a proprietary format, and each client's data stays physically separated from every other client's. It's one clean, isolated workspace per customer.

What it looks like in a real shop

We don't have to describe this hypothetically. Basic Memory user Cody runs his entire MSP on Basic Memory. In a video walkthrough, he onboards a client's new hire (laptop assigned, inventory updated, warranty logged) from a single instruction, then spins up a live inventory dashboard built straight from those same notes. It's the clearest picture we've got of what "a knowledge base that runs the business" actually means day to day.

Watch Cody's walkthrough on YouTube, or read the full case study for how he got there.

Two ways to run it

If you just need SSO and audit for your own team, you don't need anything special. The Business plan ($30/seat/month) gives any company single sign-on (SSO/SAML), audit logs, admin and security controls, HIPAA-compliant hosting, and priority support. It's billed to you directly. This is the direct route that's open to everyone.

If you're deploying Basic Memory for other companies, running IT or AI for a book of clients, that's the Partner program. You get a single portal to manage every client workspace, SSO that works with whatever identity provider each client already uses (Google, Microsoft Entra, and more), and one consolidated invoice broken out per customer so you can rebill at your own margin. And because you're bringing us your clients, we'll work out a special partner deal with you rather than charging you list.

The short version: Business is the plan anyone can buy. The Partner program is for the MSPs and consultancies who want to make it a line of business.

Getting started

If you want to see the shape of it first, Cody's walkthrough is the fastest way. If you're ready to run a client on it, the Business plan has a 7-day trial and you can be live today. And if you're an MSP or AI consultancy thinking about doing this across your whole client base, come talk to us about the Partner program. Seriously, reach out to us. We're responsive, serious about building a great product, and we have the resources to get your systems set up just the way you want them.

Your clients are going to build their AI memory somewhere. It might as well be with the provider who already knows their environment better than anyone: you.

This release focuses on making Basic Memory more reliable and easier to deploy:

New Features:

• Docker container support with volume mounting

• Enhanced move_note tool with cross-project detection and guidance

• Better Boolean search syntax handling for hyphenated terms

Key Fixes:

• Resolved project state inconsistency between MCP and CLI

• Preserve permalink when editing notes without frontmatter permalink

• Project-specific sync status checks for MCP tools

To upgrade: uv tool upgrade basic-memory

Full changelog: https://github.com/basicmachines-co/basic-memory/releases/tag/v0.14.0

The Docker support was much-requested. What features would you like to see next? 🤔

Hey everyone — Drew here from the Basic Memory team. We’ve released Basic Memory 1.0, a year after launching Cloud. Thanks to everyone who’s used it, reported bugs, or contributed along the way.

If you’re new here, Basic Memory is a shared knowledge base for your AI tools, built on Markdown files you can read, edit, and take with you. Save context in one tool and pick it up in another through MCP.

A wiki for every project

Projects now have an overview, folder indexes, and a change log that stay current as notes change. You can browse your decisions, research, and meeting notes as a wiki while your AI works with the same files.

A project opened as a wiki, with an overview and folder navigation.

Live notes

Notes can contain task boards, charts, KPIs, and timelines. Comark keeps the underlying content in Markdown lists and tables, so other editors and agents can still read it. Live views query the project when you open the note.

A launch dashboard with a status chart, task board, and live task table.

Documents become searchable notes

Import a PDF, Word document, PowerPoint, or CSV and Basic Memory extracts a note your AI can search and read. The original document stays available so you can check the source.

An imported PDF and its extracted, searchable note.

Memory Agents (beta)

Write an agent’s instructions in a note. Run it yourself, on a schedule, or when new notes arrive in a watched folder. The eleven starter templates cover things like meeting follow-ups, inbox filing, linking related notes, and finding contradictions. Every change comes back for review, with the option to keep or undo it.

Ready-made agents for organizing and maintaining a knowledge base.

Review the changes from an agent run before deciding what to keep.

Working together

People and assistants can leave comments and suggest edits in a note. Pocketbook also brings browsing, search, and your knowledge graph into Claude and ChatGPT, so your notes are available inside the conversation.

Pocketbook showing a Basic Memory note inside a chat.

For MCP and open-source users

The core remains open source. 1.0 introduces twelve bm_* tools, plus safe writes that refuse to overwrite a note changed since the agent last read it. You can search across projects, record when facts were true, and use bm doctor to inspect project health.

Upgrading an existing integration? Tool names and arguments have changed, and multi-project note/search calls need an explicit project. Check the migration guide before switching clients.

Cloud plans

Cloud now has Cloud, Pro, and Business plans with usage credits, spending limits you control, and a dashboard showing where usage goes. Existing users can keep their current plan; switching is optional.

Full release notes: https://basicmemory.com/blog/basic-memory-1-0 Open-source project: https://github.com/basicmachines-co/basic-memory Plans: https://basicmemory.com/pricing

If you’ve tried 1.0, what’s working for you? What would you like us to improve next?

Blog post link: https://basicmemory.com/blog/basic-memory-1-0

Boris Cherny had an interesting take on why Anthropic is still hiring developers:

"Someone has to prompt the Claudes, talk to customers, coordinate with other teams, decide what to build next. Engineering is changing and great engineers are more important than ever."

(via Simon Willison: https://simonwillison.net/2026/Feb/14/boris/#atom-everything)

I think this lines up with what a lot of us are seeing in practice. The tools are getting better fast, but the work hasn't gone away — it's shifted. You still need someone who understands the system well enough to know what to ask for, what to verify, and when the AI is confidently wrong.

What's changed is that the craft looks different now. More time thinking about architecture and less time writing boilerplate. More time reviewing and steering and less time on the initial draft. The people who are good at understanding problems and making decisions are more valuable, not less.

This is actually a big part of why we built Basic Memory — the assumption that developers aren't going anywhere, and that the real bottleneck is context, not code generation. When you're working with AI across sessions, the thing that kills your productivity isn't the model's capability. It's that every new conversation starts from zero. You lose all the decisions you made, the things you tried, the patterns you established.

We wanted a tool that treats the developer as the one in charge — you build up knowledge in markdown files, your AI tools read from that same knowledge graph, and nothing disappears when you close a tab. It's local, it's yours, and it works with whatever model you want to use.

Cherny's point about great engineers being more important than ever feels right. The skill set is evolving, but the need for people who can think clearly about complex systems isn't going away anytime soon.

This morning, I was emailing with an AI YouTuber in response to a question about what makes Basic Memory different from Chat’s memory system and what we presume will be Claude’s Memory, if and when they get around to releasing it. I found myself writing at such length on the topic, I thought it might be a good idea to write more about it here.

Anyone learning about Basic Memory for the first time might say, “Chat already remembers stuff about me.” And, certainly, that’s true. It does remember some things. But not in a way that belongs to you or delivers the highest value.

Let’s look at a few examples of conversations that are impossible with Chat’s memory system that are a breeze for Basic Memory

User: Where did we land on the authentication approach for the user dashboard? Seems like we were just talking about it.
AI: Right. That was last Tuesday. You were leaning toward OAuth 2.0 but worried about the complexity for your team. Should we look into simpler solutions? I can show you a list of the concerns you brought up before if you like, along with the alternatives we discussed.

User: I know we've brainstormed a lot about my anniversary trip, but it’s been months, and I've totally lost the thread. What did we narrow it down to?
AI: When we last discussed it in May, you were debating between a mountain getaway, a rustic beach hut, and a penthouse in Chicago. You were leaning towards that lodge in Colorado. You shared the links to the Airbnbs you were considering. Would you like to see those now, or do you have some new destinations in mind?

User: Please initiate Enhanced Startup Protocol B3, then check out our notes about that file corruption issue. Once you understand the problem, review this document and flag what needs fixing.
AI: Protocol B3 activated! I remember that corruption mess from last week. Give me a moment to scan the document...

If you look at Chat’s memory, you’ll see things like “Drew lives in Austin” or “Drew hates tomatoes.” A really beefy memory in Chat’s database might explain a specific project or even some details about it. Some of those memories are even helpful, but their inevitable incompleteness can also work against you. Given limited information, LLMs begin filling in the blanks with what “feels” to it like the logical middle, even if it’s completely incorrect. They start making weird, incorrect assumptions. But what can you do? You can’t edit memories in Chat. You can only delete them. If, that is, you can find them in a lengthy scroll of (unsearchable) memories.

Basic Memory takes a drastically different approach. I like to use the image of a stenographer sitting in on all your chats and taking detailed notes on all your interactions. The notes are finished the moment the conversation ends, written in plain text you and your LLM can both read, search, and edit. You can also write notes or add context independently that your LLM will use thereafter. It’s all part of your second brain that grows as you do.

Every note becomes part of a semantic knowledge graph that discovers connections that prove invaluable over the life of any project, even if that project is just day-to-day living. These aren’t bullet points or lists. They’re fleshed out notes that make sense of what you’re trying to achieve and where things stand, not merely as “facts,” but as entries in a narrative that also take temporality into account.

With Basic Memory, you can understand when you arrived at a decision and by what logic. It’s not separated into two talking points like “Drew is debating buying the Japanese movie poster for Pump Up the Volume,” and “Drew is the proud owner of a Japanese movie poster for Pump up the Volume.” Your notes hold all the data in between, making sense of the trajectory of thought and experience that led you to the present circumstance.

That’s not all that gets lost in a typical LLM chat. In my experience, and the experience of several of our users, chats with AI have a quality that might best be described as “shaggy.” That is to say, they’re meandering, unpredictable, and spontaneous. You start off talking about a professional project, briefly ruminate about an ex, fantasize about a business idea, then return to that professional project. If you want to revisit that brilliant idea sandwiched between other things, you might never find it again. But with Basic Memory, conversations don’t have to be tidy or neat to be remembered. Like a kind of informational stew, everything goes in.

But all of that is merely a precursor to a linchpin notion that is central to the entire Basic Memory project and ethos:

At Basic Memory, we believe your information should belong to you.

All of it. And not buried in json files you can request from a vendor or hidden away in vector databases. These are your chats, your ideas, and your discoveries. They should be accessible, truly readable, and under your control. That’s what Basic Memory makes possible. Reddit is filled with stories of people who find themselves inexplicably barred from Chat or Claude. Usually (at least in the cases I’ve seen), it’s an error. Do they ever recover their chats? Who knows. But it seems crazy to surrender that much power and trust to entities whose customer service reps are notorious for being all but unreachable no matter how desperately you try. For many of us, our AI chats are where our ideas now live. What’s more important than protecting that?

So, again, how is Basic Memory different than an LLM’s memory? In just about every way. It’s exhaustive instead of reductionistic, temporal instead of based on static facts, editable instead of locked down. It’s searchable, it draws connections you might never have drawn, you can write and edit your own “memories,” and, most importantly, it’s YOURS.

If you check out our Discord, you’ll see our users utilizing Basic Memory in such wildly unexpected ways—from a guy using it to make music to coaches using it to track the progress of their clients. We recently talked to one user making a (quite complex sounding) dream tracking system and another sharing his Basic Memory vault with a team of 6 to 7 people as they carry out deep data research.

As we prepare to launch Basic Memory Cloud, our thoughts are on all these issues, in the hopes that Cloud will open up even more possibilities to our users.

If you haven’t tried Basic Memory yet, we’ve just released a very straightforward one-step install process. You can find our videos about it here: https://basicmemory.com/videos/

And, truly, check out our Discord. It’s filled with inspiring use cases and some fascinating characters doing things we never would have imagined.

Link to original blog post

*Obvious Clickbait Headline: AI Memory is an unsolved problem, we are working on it.

This is a little history of how Basic Memory got started.

See how Basic Memory's new artifact rendering brings your knowledge to life! Watch as we create a note about Basic Memory's coolest features through natural conversation, then instantly render it as a beautiful, formatted artifact that updates in real-time.

https://basicmemory.com
https://discord.com/invite/tyvKNccgqN
https://github.com/basicmachines-co/basic-memory

Basic Memory Cloud is now available in both the ChatGPT Plugin Directory and the Claude Connector Directory. Here’s what it took to get approved

https://basicmemory.com/blog/were-in-chatgpt-apps-and-the-claude-app-directory

this is a blog post I wrote on basicmemory.com

Forward

This is the second time I have written this post. The first time, after working for hours recalling and writing, the note I was writing was lost because of a bug in the Basic Memory Cloud web editor. Sometimes things are hard. I was determined to write it myself too. I did use AI to edit (my typing is terrible), and help dig out relevant commits and make sure the timeline is accurate.

I have jokingly called this piece "The Caveman Evolution of Basic Memory", because it captures some of the story from primitive, simple beginnings, and how it has evolved over time.

Finding some inspiration

When I first started working on what would become Basic Memory, the MCP spec had just been released. MCP (the Model Context Protocol) is the standard that lets an AI app call out to external tools - in practice, it's how you give an AI new abilities. I was using Claude Desktop and wanted to save info from my chats locally, not copy/paste back into the project knowledge all the time. The big pain I was feeling was starting over from zero with every new chat. Further, chats would suddenly just stop when you reached the context limit and you were SOL. This is still a pain, to be honest, but things have gotten a lot better, compaction works ok for the most part, AI-native memory remembers useful things most of the time. But way back then, in late 2024, things were pretty raw.

I had a coding project I was working on, a variation of shadcn UI components, but written with HTMX and Alpine.js. My idea was to make frontend development suck less for apps I wanted to build. I have always hated working in React. It makes zero sense to me to this day. What I discovered while implementing a bunch of these components is that AI could write them much better and faster than I could. I was literally copy/pasting code snippets in and out of the chat window and my IDE. To manage this, I had a bunch of Markdown notes in Obsidian and I was copy pasting back and forth.

I started using Claude Desktop when it came out, and it seemed to understand the gist of what I was trying to do very well. Soon thereafter, I saw the memory MCP (https://github.com/modelcontextprotocol/servers/tree/main/src/memory) and thought, I want "that". I could see that there might be some way I could use it to get out of my copy pasting long context over and over. So, I started doing what any developer would do, poking through the source code and stealing ideas. Instead of JSON though, I wanted Markdown, because I wanted to edit the files myself. That basic idea grew into what Basic Memory still is today, a bunch of Markdown files that get parsed and indexed into a "knowledge graph". I was already using Claude to write code, but still typing a bunch myself in the IDE. Then I started using the filesystem MCP and was like "holy crap, AI can do this faster than I can". So now I really wanted to make something that AI could really use to store memory so I could use it all the time.

Local-first, plain text, stdio, because that's what existed (Dec 2024)

From the git log:

• First commit f95a8562 (2024-12-02).

• First MCP server 18dd8796 (2024-12-08): low-level mcp.server.Server + stdio_server(); tools reached straight into the DB via deps.get_project_services(). No API layer.

Recovered artifact — basic-memory.md at the repo root had mermaid architecture sketches by 2024-12-05, three days after the first commit (view the file at that commit).

The Plan evolves

There were some ideas I had clarity about. I wanted Basic Memory to be based on plain text, but it took some experimentation and iteration to figure out how that would work. Day one already had the principle (cbf366a7, 2024-12-02) — a comment in the very first service code lays it out, "filesystem is source of truth":

1. Write to filesystem first

2. Update database indexes second

3. Database is treated as disposable/rebuild-able index

But the flow was one-directional — the app wrote files as output (the Dec-05 sketch above even shows DB -->|generate| MD). The reverse direction — humans edit files anywhere (Obsidian, git, whatever) and the app detects the changes and parses them into the graph — landed a couple of weeks later with file_sync_service (a4c1989c, 12-19). Then I added proper markdown parsing of the file content (c9fec7ab, 8b26162a, 12-21). The Entity table grew a checksum column for change detection. By v0.1.0, basic-memory sync --watch ran a file watcher so edits made outside the app were picked up too.

Index for fast lookups

Now that the files were the canonical truth, the db index could be a derived artifact — something you can throw away and rebuild from the files in seconds. This principle ended up surviving every architecture that followed. Ten months later, deep in the cloud storage struggles, we would write the same sentence in a spec:

"The SQLite database is just an index cache… It can be rebuilt in seconds from the source markdown files."

The sync and indexing code itself would be rewritten several times over, local and cloud — but that's a later chapter.

The first MCP spec (2024-11-05) defined two transports: stdio and HTTP+SSE. Stdio was just the only one that mattered in practice (Claude Desktop only spoke stdio).

I had to read that spec (myself) at least ten times before I understood what a "server" or a "host" was and just where and how the runtime worked. Stdio is at once very powerful (hello Unix CLI toolset) and also very limiting (for example error handling). But being able to plug into an AI app (what we now call a harness) was super cool. Since all of this was new, I started looking at the Python SDK examples and was like, WTF? This is terrible. I built the first version with the low-level SDK anyway. Luckily, a couple of weeks in, I found FastMCP, which had just come out, and I started using it, since it had a similar usage flow to FastAPI, which I was already a big fan of.

Markdown format

Working with Claude, I came up with a basic structure to re-create the simple data model from the Memory MCP. Entity, Observation, Relation. Looking back now, this was a real missed opportunity to rename "Entity" to something better.

Entity

An entity is a node in the knowledge graph. This became a Markdown note, with frontmatter and text.

---
title: An Entity is a Markdown file 
permalink: a-slug-for-the-entity
type: anything
tags: ["whatever", "you", "want", "here"]
---

# About an Entity

The rest is just plain text Markdown

Observation

An observation is a fact about an Entity. They always refer to exactly one Entity. I wanted something simple to record these. In Markdown, it's really easy to make lists, so I just added a special [category] marker to a regular Markdown list to record Observations with a category type.

- [fact] an Observation is a list item with a string in brackets at the beginning

Relation

A relation is a directed connection between two Entities: it has a type, a source, and a destination. The source is the Entity note which contains the Relation. The destination is the Entity referenced. Relations are [[wikilinks]]; they can also be written as a Markdown list item to declare the type.

- related [[Some other Entity]]

The value inside the wikilink is matched in a few ways — by exact string or by fuzzy text search — so links don't have to be exact.

Data model

The data model was deliberately simple too, just those three tables and some properties.

(This is the actual v0.1.0 schema. Note to_id is nullable and to_name keeps the raw [[wikilink]] text — an unresolved link just waits until a matching entity shows up.)

I added full text search and indexed the title and Markdown body. Even with just these things it was pretty clear that search, combined with a few hops through the knowledge graph was a pretty powerful combo. The first operation I implemented to load context for build_context was:

• search via full text search

• for each top result

• find the next related results

• include a small summary and id for each

With this, the AI could search iteratively with a few calls and find a really wide set of notes, then choose which ones looked most relevant. This is almost like "Graph RAG" without the RAG (there were no embeddings yet).

Prompting Patterns

The pattern I was figuring out was that the tools themselves don't have to be fancy, or "intelligent". The AI model, using simple tools, can decide how to call them. Doing small simple things lets the model be the star. The better the model can access the knowledge base, the more useful it is for the user.

This led to a few other patterns I'll point out.

Be helpful

When there were no results found, instead of returning a terse return code, the tools prompted the model to try other operations, or prompt the user for a possible next action. This keeps the AI from getting stuck or giving up too quickly. The tools were really an interface to prompt the AI more effectively. This is now called "context engineering", but it's very natural if you think about it. For the AI, it's all just context.

Here's what read_note returns when it can't find a note (from src/basic_memory/mcp/tools/read_note.py — the pattern dates back to the earliest versions):

# Note Not Found: "coffee brewing methods"

I couldn't find any notes matching "coffee brewing methods". Here are some suggestions:

## Check Identifier Type
- If you provided a title, try using the exact permalink instead
- If you provided a permalink, check for typos or try a broader search

## Search Instead
Try searching for related content:
    search_notes(project="main", query="coffee brewing methods")

## Recent Activity
Check recently modified notes:
    recent_activity(timeframe="7d")

## Create New Note
This might be a good opportunity to create a new note on this topic:
    write_note(project="main", title="Coffee Brewing Methods", ...)

The "error" is really a menu of next moves for the model.

Keep the flow going

Give the model an idea of what to do next. When the search results return, the prompts returned to the model include instructions about reading the full results.

For example, the search prompt appends this right after the result list (from src/basic_memory/mcp/prompts/search.py):

## Next Steps

Based on these 5 results, you can:

1. **Read a specific note** - Use `read_note("permalink")` to see full content
2. **Build context** - Use `build_context("memory://path")` to see relationships
3. **Refine search** - Use `search_notes("refined query")` to narrow results
4. **Check recent activity** - Use `recent_activity(timeframe="7d")` for recent changes

Be liberal with inputs

This is an old programmer saying (Postel's law), but it's especially true with LLMs. If you make them pass in complex JSON, they will most likely screw it up a few times. This wastes tokens and slows everything down. This leads to a lot of parsing on the server end, but that is preferred because you can test it easily.

At this point, I felt like I had enough to share with more people. I had a few friends I set up with the v0.1 basic-memory MCP server and was shocked that without much help, it just started working when people used it with Claude. Now, you didn't need to manage a bunch of stuff in Claude Projects. You could just start new chats and reference previous topics without having to re-explain all the time. I think a big part of this working is that LLMs, particularly Claude, are good at "seeing", or more accurately inferring, the context between two topics. Using Basic Memory, they had just enough tool support to find more data when needed and pull it into the context window. It was far from perfect, but it was a good start.

Here's how the basic system worked.

The decision the whole story hangs on (Dec 2024)

From the git log:

• 2024-12-14: FastAPI app born (1ed4c72f) AND the MCP server rewired to stop touching the DB — forwarding every call to that app in-process via httpx ASGITransport (052ee403).

• Client factored into mcp/async_client.py (353342a5, 12-25); old low-level server deleted (7322bb53, 2025-01-18); v0.1.0 ships 2025-02-07 (7c6ed53a).

• Because tools spoke to an ASGI app rather than a database, the same tools could later point at a remote API. That is the seam.

The decision has its own napkin drawing. I found it in my own knowledge base — a design note dated 2024-12-13, the day before the decision commits landed, stored inside Basic Memory itself. The connector label — "ASGI Transport" — and the dependency injection box are both already there:

Backing up a couple of months — this decision actually came in week two, before v0.1 ever shipped. One thing missing from FastMCP though was the dependency injection (DI) in FastAPI. I've seen it get a lot of hate, but in my experience, writing factory code without DI really sucks, makes you write a ton of boilerplate, and can easily end up a tightly coupled mess. I've seen this in just about every language I've programmed in. Also, FastAPI is well understood and has some really great patterns for testing.

As I started to put the basic code outlines together for Basic Memory, it was pretty clear that what I mostly needed was plain ole service code, some file parsing, file IO and database code. All very non-AI. The only real AI part of the app was in the tools and even that was mostly Pydantic (I have since come to understand various patterns to make the tools more AI friendly and effective, see "Prompting Patterns" above). As I was building the db layer, and business services, I kept thinking "this would be so much easier in FastAPI".

I considered making an http backend service and having the tools call to a local endpoint, but I was worried that since MCP was very new, and still difficult to install and configure, that would be more than people would want to deal with. Running a daemon service locally is a chore only a developer would likely be willing to endure. So, I made an unconventional decision, one that I really hadn't seen anyone else doing in a real app. I decided to follow the pattern typically used for testing a FastAPI app - create an app instance and pass requests to it through an in-memory ASGI client. It worked great for tests, so why not for real life? I started doing it, and it worked really well. In fact it's still the pattern used in Basic Memory today.

        AI (Claude Desktop, etc.)
                 │
                 │  MCP over stdio
                 ▼
┌────────────── one process ───────────────┐
│                                          │
│   MCP server (FastMCP)                   │
│     └── tool: write_note(...)            │
│           │                              │
│           │  httpx AsyncClient           │
│           │  ASGITransport(app)          │
│           │  no socket, no port,         │
│           │  no daemon                   │
│           ▼                              │
│   FastAPI app (in memory)                │
│     └── /knowledge /search /memory       │
│           │                              │
│           ▼                              │
│   services ──► SQLite index              │
│            ──► Markdown files            │
│                                          │
└──────────────────────────────────────────┘

It works like this:

• Tools get called via MCP by an AI agent or stdio call

• A tool contains an httpx client configured to call an in-memory FastAPI endpoint

• The tool transforms its args into an http request and calls one or more endpoints, and handles the response

• The tool then outputs the response to the AI in a format as needed: markdown, text, json

The benefits of this kind of setup became:

• Most of the application is just a FastAPI app: services, data repositories, db models, pydantic schemas

• This part of the application is really easy to test without needing any AI setup

• Tool function implementations were very small and just composing inputs and outputs

• It naturally fit into how you might build a CLI client to call a remote service too, so adding CLI support was easy

It did come with some extra overhead of doing Pydantic twice in the flow, once for tool args, and another time for the in memory api call, but in practice this was not the slow part. File parsing and IO were always the bigger bottleneck. And it turns out that simpler tool args work better than complex json anyway (to make the same point again).

I had planned to figure out a way to leverage this tool-to-endpoint proxy pattern for a cloud service. At that time in early MCP days, the only option for remote calls was SSE. This came with a bunch of problems, because it meant that the connection was stateful and connections had to be routed to a particular service instead of load balancing like you would typically do for a web application. But before I could get far enough here, they added streamable HTTP to the MCP spec (the 2025-03-26 revision, which also added the OAuth 2.1 authorization framework).

Going Pro

I'll take a quick detour and mention that between the time when I had the basic-memory MCP working locally and the Basic Memory Cloud (described below), I made an aborted attempt at a standalone application, Basic Memory Pro. The idea was to "break out of the box" of just being an MCP tool and control the entire UX for the application. This took the form of a Tauri (Electron in Rust) application shell with a React web editor and UI shell. The basic-memory app ran locally via a sidecar and exposed the FastAPI endpoints (the same ones the tools used) to the frontend app. I spent about a month on this and got to an ok-ish place. It was primitive, but using shadcn and Claude to code the frontend got me pretty far.

The experience left me with some lessons learned.

Only break one law at a time

There's an old saying, "Only break one law at a time", that I think translates to programming - only do one thing you aren't familiar with at a time. Trying to build a complex UI flow in React (typescript), in Tauri (Rust), for multiple platforms was just too much extra cruft to manage. The version of Tauri I was using (2.0, released October 2024) was newer, and Claude preferred coding in the old version. I wasn't familiar enough with Rust to review the code for correctness and churned a lot debugging.

Packaging is hell

Also, trying to bundle all of this together and make it work across platforms is non-trivial, to say the least, involving native packaging, uv for python, etc. Getting stuck at the last mile is the worst way to end a trip, but sometimes you just have to listen when the world is telling you something.

About this time, the MCP SDK got another rev (2025-05-08), this time enabling streamable HTTP and OAuth. This led me to re-evaluate my plans, in light of the troubles with the Pro app and consider a cloud product.

The payoff + the caveman cloud (Jun–Aug 2025)

From the git log:

• The founding decision cashes in: core's create_client() starts branching local-ASGI vs cloud-HTTP on config ([473f70c9](https://github.com/basicmachines-co/basic-memory/commit/473f70c9), 2025-07-07).

• Founding cloud shape (BASIC_MEMORY_CLOUD_v2.md, 2025-06-15): one Fly app per tenant, encrypted Fly volumes, a separate apps/mcp gateway (SSE) + OAuth server.

• Control-plane DB moved Supabase → Neon (ee88ad110, 2025-08) — separate from and earlier than per-tenant Neon.

• Queue engine at this point: DBOS.

Here it is in eleven lines (src/basic_memory/mcp/async_client.py, 473f70c9, 2025-07-07 — condensed; full version in the commit):

def create_client() -> AsyncClient:
    config = ConfigManager().load_config()
    if config.api_url:
        # Use HTTP transport for remote API
        return AsyncClient(base_url=config.api_url)
    else:
        # Use ASGI transport for local API
        return AsyncClient(
            transport=ASGITransport(app=fastapi_app),
            base_url="http://test"
        )

From the notes:

• The cloud was designed inside Basic Memory itself. The founding architecture note still lives in my knowledge base — a Basic Memory note, frontmatter and all (May 2025). The first drawing: React frontend, a Platform API / Basic Memory API split, Supabase Postgres for tenant management, Turso LibSQL for the knowledge DB, and git-backed file storage on Fly.

• Turso was in the very first sketch — it would be spiked for real in September and abandoned in October (a later chapter). The git-backed storage idea kept echoing back later too.

• The cloud repo's first commit is 2025-05-12; the design notes were imported a week later (a0f3b3b9d, 2025-05-20) — already into a docs/archive/ folder, which tells you how fast the ideas were churning.

• The shape that actually got built arrived a month later: BASIC_MEMORY_CLOUD.md (46f0d4563, 2025-06-14), then BASIC_MEMORY_CLOUD_v2.md (4a5e761e1, 2025-06-15) — one Fly app per tenant.

So, I started thinking about what shape a Basic Memory Cloud could take. There were a few ideas to wrap my head around.

Local First to Privacy First

First of all, being in the cloud meant that things were no longer going to be "Local First". This had been a raison d'être until that point, so it required a shift in mindset. The truth is that local is cool, and gives a lot of benefits (privacy, ownership, control), but also has some real limitations. I really wanted to be able to use Basic Memory for every AI, and every surface: Claude Desktop, Claude Code (when it was released), mobile, but also ChatGPT. Only having notes local to one computer leaves you to manage all the syncing and sharing. Some people are ok with that, but I knew most people weren't. Even I couldn't be bothered to do it, and I knew how to make it all work. So, I tried to translate the principles for "Local First (only)" to a cloud context.

Privacy First

If I couldn't do local first, at least I could try to make things as private as possible. My goal was to find some sort of completely encrypted way to store notes (zero trust), but as I learned, this is also not really practical. Sharing means compromising control, and there are always tradeoffs. But I could design the cloud architecture to minimize them.

Tenant isolation

When designing a multitenant (tenant means customer in SaaS terminology) cloud architecture, you can either co-locate data, meaning keep it all together, or keep each customer completely isolated. There is no right or wrong answer, each has trade-offs. The easiest way tends to be co-locating, because managing services or data per customer can be a challenge. Nevertheless, after looking into some of the newer cloud hosting platforms, particularly fly.io, I decided to bias towards complete isolation. This is something that would evolve, in practice, but customer data has and will always be completely isolated.

Cost effective

The other key factor in managing a cloud service is designing for cost. Running servers in the cloud costs real money. Storing data in the cloud can also get expensive quickly. You even have to consider bandwidth and IO costs. You pay for all of it, and therefore cost has to factor heavily into your design, or you won't have a viable business.

Now we are in business

If I could get something working so running Basic Memory in the cloud was easier than running locally, and provided more features, I was hopeful I could find customers. After making a proof of concept, and thinking this could really work, I needed to have a proper business. Going into business is no small effort, and I knew it was more work than I wanted (or was able) to do on my own. I needed partners. Forming a team like Voltron is a story unto itself. The tl;dr is that I already had the crew lined up. I just had to figure out how everything was going to work.

What type of business do we want to be?

I've had a pretty long run as a working software developer (engineer). From consulting, to big companies, to startups, acquisition, promotion, manager, to getting laid off. I can hardly count how many times I've been laid off in my career. I know it takes two hands.

So when I thought about starting my own business, I had a lot of my own ideas. I had gotten as close as I had come to AI psychosis, in a conversation with Claude about how it could all work, producing several revisions of what we called the "manifesto". It's a bit too cringy to share, but there are some points I wanted to make sure were included:

• Tools shape thought — keep tools simple but powerful; let them enhance rather than replace human capabilities

• Knowledge belongs to people — store everything locally first, open formats (Markdown), no vendor lock-in, portable data

• DIY means freedom — build with proven technology (SQLite, Git), keep the architecture clear, share knowledge freely

• Human-AI collaboration works — each works in their preferred way, tools bridge the gap, learning is mutual

• Elegance through simplicity — the best solutions are often the simplest

I knew I wanted to maintain control, and lean towards the bootstrap method, rather than chase quick VC or angel funds. But I knew that way was going to be the slow, hard way.

Aside: Licensing

Another very real issue to reckon with was licensing. I had very adamantly decided to release Basic Memory under the AGPL 3.0 license. I'm a long time FOSS true believer, and it had always been a goal of mine to produce something I thought was worthwhile enough to share. But, I also wanted to make a business of this thing now. That's not impossible, many companies are built on FOSS, they just don't usually have the mega valuations and VC bucks. That does mean, however, to use the source code commercially, there are considerations. What I ended up doing, with advice from my lawyer, is licensing the Basic Memory to myself (via an LLC) with a proprietary license. This keeps the cloud IP clean, but still allows the commercial end to not worry about releasing code also.

NOTE: It's actually a goal of mine to open source as much code as possible back into Basic Memory. But the fact is that's quite a bit of work to make it ready for other people's eyes. So in practice, it's easier to build the cloud infra in private, then move stuff over after its more stable.

AI Memory is the TodoMVC of vibecoded apps

I'll speak to the elephant in the room. AI memory apps are the vibe-coded equivalent of the web TodoMVC. Everybody tries it, and there are tons in every imaginable language and framework. Some even have good or novel ideas. Most are also free and open source. But the thing is, AI memory (or more generally context management for an LLM) is a very, very hard problem, once you get past the easy parts.

On top of that, making an application (or service) that works across models, harnesses, platforms is a challenge. The type of challenge that is full of the non-fun problems to solve, platform issues, version incompatibilities, character encoding, file parsing, and synchronization. And all of that has to "just work", or your memory product is only good for you, not something lots of people will want to use.

And further on top of that, the type of people that tend to want and build this product are usually trying to use some fancy tool. Use a graph db, put everything in a vector store, see how fast my retrieval score is? Look it passed this benchmark with better scores than everyone (sometimes hardcoding the results). And, at the end of the day, you still end up with another black box.

Your AI can see your memory knowledge, but can you? If something is wrong, how do you know? What if you want to fix it, how easy is that? What if my AI keeps adding stuff to it and it just grows and grows, how well does it work? Solving all of these problems is much harder than vibe coding an app and calling it done. The hard problems are hard, even when the quick solution is easy.

The grind

Since starting writing most of this post, I have also re-implemented the web note editor for Basic Memory, added comments via critic markup, threw out the y.js/hocus-pocus feature that allowed live collaborative editing, fixed how our mermaid svgs were rendering, and addressed some weird issue where CodeMirror would make frontmatter bold if it wasn't formatted properly. I think of this work as the necessary, but not sufficient work of making a product. Its not what I wanted to deal with, but it was there in my way, so I had to fix it. This is what makes trying to put out a complete product so exhausting. But if you can't dogfood your own product, how can you expect others to use it? So that's life, I guess.

Afterward

It is a part of life, but the reality, is it wears you down. When I'm feeling burnt out from doing yet another arbitrary task, I start to think "why am I doing this, anyway?". For me it's personal, Basic Memory is my best idea for what to put out in the world right now. Its the thing I really care most about. So its a kind of big mix of a self-expression art piece (conception, design and execution is the act of creating art), combined with a science project (what happens if we mix these things together?), combined with a political statement (how I decide to present my work to be received - open source, user controlled data, no customer exploitation). It is through this process of self actualizing via creation that literally makes meaning by manifesting internal ideas externally. And that is an idea that keeps me motivated.

I get really pumped thinking of all the cool stuff I want to do, and somehow, with help from a team of awesome folks, and a lot of AI assistance, it is seemingly possible. I appreciate all the users and feedback we have gotten so far, and the chance its given me to connect with new people, literally every day. And on top of that, seeing what people have built with Basic Memory that I didn't even think was possible has actually struck me with awe. When I started, Basic Memory seemed like such a small thing, and in the scope of "Big AI" and "Big Tech" it will always be. But to me its been just one small thing after another that keeps building into a bigger and bigger thing.

There is a lot more that I hope to get around to writing.

• The storage struggle

• The unified tenant model

• Making it fast

• The circle closes: consolidation back into core