Project: 4th Brain — Developer’s Log, Jan 25, 2025

Project: 4th Brain is a work-in-progress platform and plugin for Obsidian that aims to create harmony between four types of intelligence — human cognition, digital note-taking systems, community wisdom, and AI. Currently being developed with Supabase as its backend, this open-source project focuses on multi-channel publishing, standardized PKM patterns, and AI-augmented knowledge management.

In my previous update, I provided the source code repo on GitHub. Even though the code is in a very early stage and there is nothing valuable for users yet, I made it public for transparency. I also hard-coded a little acid test to perform inserts on the documents table and I came up with some initial Sync with Server scenarios, written in the Gherkin language. My purpose today is to provide a quick status update to let interested parties know that things are progressing and to invite feedback and participation.

The Backend Database

In addition to the core documents table, two tables have been added to support the concept of sites (that is, the websites users publish Obsidian markdown documents to). The sites table is necessary to support multiple websites served atop the same Supabase instance and it will eventually allow users to own and publish to more than one website. The document_site_publications table ties the documents and sites together (many-to-many). Here’s what the schema looks like now…

There’s an init-supabase.sql script that creates everything necessary for your Supabase backend, which, at this point, now includes:

• An enum type for document states: draft, published, expired, removed
• Tables (as shown above)
• Indexes (to speed up data retrieval)
• Functions to perform operations on the data and to support transactions so that if any multi-step operation fails before it is completed, the transaction will be rolled back, and the database will not be left in an inconsistent state.
• Row Level Security policies

All items listed above will be created simply by running the init-supabase.sql script (in the Supabase SQL editor, for example).

The Obsidian Plugin

The Obsidian 4th Brain plugin’s settings page now looks like this:

These are the fields needed for a connection to the backend server and a slug for the website you publish your documents to. A slug is a short, URL-friendly string that will be part of the URL that loads your site (unless you map that part of the URL pattern to a website domain).

Current Plugin Functionality

Right-click a document and a Sync with Server option now shows in the context menu…

If the site slug you’ve written in the plugin settings identifies a site that does not yet exist in the backend, then you will first be given the option to create it, like this:

If the document you’re syncing has not yet been inserted into the database, then uuid and version properties are added to the document, and it is inserted. Each time you sync the document again, the version property is incremented, but the uuid stays the same. Previous versions remain on the server so that we can support compare and roll-back features in the future.

If you delete a document from your Obsidian vault and that document has a uuid property, its corresponding document (and all versions) are flagged as removed. I am not supporting a true delete for now, though I will implement a way to purge old versions and removed documents in the future (for database cleanup and performance).

Next Steps

Now that we can sync to the backend server from within Obsidian, I’m eager to start working on the part that renders your server data in a website. For that, I hope to add a web server container to the Docker compose file. In this way, you’ll be able to spin up the Supabase backend and the web server with a single docker compose up command.

I’m closing with some questions I’m still chewing on, in case you have an opinion to contribute on these matters:

• Should the site be generated into a static site for screaming-fast performance or should pages be queried at runtime and cached on the server?
• If an app server technology is used, what’s the ideal language for the server-side stuff? Java (e.g. Spring Boot), Node.js, Python?
• How will website keyword search be supported? Full-text search supported in the Postgres database or something like Apache Solr that might be more robust and better performing at scale?

Anyhoo…I’ll keep ya posted.

---

If you’re interested in following along or contributing to the vision for this platform, you can:

💬 Contact me to share your thoughts and ideas