DEV Community: Lay Patel

Who actually joined that meeting? Connecting Google Meet to cognee

Lay Patel — Fri, 30 Oct 2026 17:37:36 +0000

Google Meet knows who joined a call, but not what the call was. Google Calendar knows the title, but not who actually showed up. So I tested my connector with a question that needs both:

Who actually joined the Falcon drone sync and when?

And the answer from memory:

The participants who joined that meeting on 2026-10-17 and their times in UTC are: Lay Jokes: 16:36 to 16:39, Lay Patel: 16:36 to 16:37, and 16:37 to 16:39

Both of those accounts are mine, and I cut the line with the meeting link. The two time ranges for Lay Patel are the second account joining from my phone, leaving and coming back.

The title in that question exists only in Calendar, and the attendance exists only in Meet. What joins them is one line. This connector writes the Meeting link exactly the way my Google Calendar connector writes it, so when both sync into the same dataset, a conference and its calendar event end up linked in the graph.

cognee is an open source memory layer for AI agents. This is my fourth connector for it during Mergetober.

Status: the PR is open and hasn't had a maintainer review yet.

What I want to use it for

My test call was between two of my own accounts, so it hasn't been through a real meeting yet. I want to use it for hackathon and college project calls I organize, to answer "who actually joined, and when?" after the call is over. I also talk through ideas with a friend late at night, and that's where transcripts would really help, but my accounts are personal Gmail, so for me it's attendance only for now.

What it syncs

Every finished conference you organized, with who joined and when. Meet only lists conferences where you were the organizer.
The last 30 days at most. Meet only keeps conferences for 30 days, so the first run can't reach further back. Sync regularly if you want to keep more.
Transcripts, on Google Workspace editions that can transcribe. On a personal Gmail account you still get attendance, just no transcripts. My live test was on personal accounts, so I've only verified the transcript path against a fake API.

Signed-in participants come with a display name, no email, and all times are in UTC.

Try it

Until the PR merges, install it from my branch:

git clone -b feature/google-meet-connector https://github.com/laypatel13/cognee-community
cd cognee-community/packages/connector/google-meet
uv sync

In the Google Cloud Console, create a free project and enable the Google Meet REST API and the Google Drive API.
Under Google Auth Platform, set up the consent screen as External, keep it in Testing, and add your own account as a test user. Add only two read-only scopes: meetings.space.readonly, and drive.meet.readonly, which can only see Drive files that Meet created.
Under Clients, create an OAuth client of type Desktop app, download its JSON, and sign in once:

export GOOGLE_MEET_CREDENTIALS_PATH=~/client_secret.json
export GOOGLE_MEET_TOKEN_PATH=~/.cognee_google_meet_token.json
uv run python examples/login.py

Set your LLM_API_KEY, then sync and ask:

import asyncio

import cognee
from cognee_community_connector_google_meet import google_meet_source


async def main():
    await cognee.remember(
        google_meet_source(),
        dataset_name="my_meetings",
        primary_key="id",
        write_disposition="merge",  # makes re-runs incremental and lets deletes reach the graph
        max_rows_per_table=0,  # removes the default cap of 50 rows
    )

    answer = await cognee.recall("Who joined yesterday's meetings?", datasets=["my_meetings"])
    print(answer)


asyncio.run(main())

To get the question at the top of this post, sync Calendar into the same dataset too. Set up the GOOGLE_CALENDAR_* variables from the Calendar connector, then:

uv pip install ../google-calendar
uv run python examples/example.py --with-calendar "Who actually joined the Falcon drone sync and when?"

What happened on a real call

I used two personal Gmail accounts and a Calendar event called Falcon drone sync with a Meet link. One account started the call from the event, the other joined from a phone, left and rejoined, and the organizer ended the call. Gemini was the LLM and local fastembed did the embeddings. The PR has a video.

The first sync picked up 6 conferences and 1 calendar event, and the second picked up nothing, as it should. That sounds like a lot for one proper call. Three were short calls from my earlier checks, and two were empty conferences on the Falcon link. Meet records one whenever the link is opened, even if nobody stays.

Details I cared about

Meet has no change feed. So later runs filter on start_time, from one hour before the newest finished conference, and skip what's already done.

Calls that aren't finished wait. A running conference, or one whose transcript is still being written, stays in a pending list and is read again by id on each run. A transcript Google still hasn't written a day after the conference ended is given up on, so it doesn't cost a request forever.

A deleted transcript is forgotten, and Drive is how I know. Meet keeps listing a transcript after its Google Doc is deleted. So the connector asks Drive whether the Doc still exists, and that's the whole reason for the drive.meet.readonly scope. The transcript is forgotten and the attendance record stays.

No surprise browser pop-ups. Only the login script opens a browser. A sync with a missing or under-scoped token raises a clear error instead of waiting for a person who isn't there.

It only reads. Nothing is created or changed in Meet or Drive. Recordings are noted as yes or no and never downloaded, and smart notes and chat are never read. The conference text does go to your LLM provider during processing, like any document you add to cognee, so use a local model if that matters to you.

What I did differently this time

I opened this PR on October 17. Three days later, the Dropbox and Outlook reviews landed, and a lot of what they found applied here too. So I didn't wait for someone to find it again. I went through those review notes and fixed what fit while this PR sat in the queue:

Retries moved out of the Google client. Its own retries could sleep about a minute per request while cognee holds a staging lock, without asking if the sync should still be running. Now a 429, a 5xx or a dropped connection is retried after 1, 2 and 4 seconds from one 2 minute budget per run, and a 400 or 404 is never retried.
Waits are slept in 1 second steps, with check_active asked in between, so a revoked connection stops a long wait within a second.
Rows stream per conference, so a first sync of 30 days keeps one conference in memory at a time.
Wrong option types are refused, so include_transcripts="false" no longer reads as True.

The tests went from 68 to 100, and I made sure they can fail: with the Drive check turned off, the forget test goes red.

The earlier connectors taught me to ask the questions a reviewer would ask before anyone else has to. That's a better use of a maintainer's time than making them find the same bug in a fourth connector. I'm sure the real review will still find things I missed, but they should be new ones.

Looking back at the month

This is the last post in my Mergetober series. Four connectors and a lot of review rounds in one month, and I only started coding in May. The hard part for me was sticking with it the whole month. I enjoyed it, but managing my time was rough, and I'm proud that I managed it somehow.

Removed doesn't mean deleted: syncing Outlook mail and meetings into AI memory

Lay Patel — Fri, 30 Oct 2026 17:37:20 +0000

Microsoft Graph tells you a calendar event was removed in two very different situations: someone deleted it, or it just slid out of the date window you asked about. Treat those the same and your AI memory forgets a meeting that still exists.

Almost everything hard about this connector looks like that. Outlook says one thing, and the safe move is to check what it really means before you delete anything.

cognee is an open source memory layer for AI agents. For Mergetober I built an Outlook connector that syncs mail folders and your calendar through Microsoft Graph into one memory.

Status: the PR is still open as I write this. It has been through three review rounds, and I pushed the fixes for the latest one on October 30.

What I want to use it for

My college actually uses Outlook, so this is the connector that would really help me out: work, events, dates, all in one place I can ask.

My live test was on my own Outlook.com account, but with test emails and meetings, so I haven't run it on real mail yet. One question I want to ask needs both sides: "what did this person email me before our last meeting?" Mail search finds the email and the calendar finds the meeting, but neither connects the two. To run it regularly I'll need an app registration, because a Graph Explorer token only lasts about an hour, and on a college account an admin may have to allow it.

What happened on a real account

I tested on a personal Outlook.com account with 4 test emails and 3 test events about a made-up drone project, one of them a daily recurring meeting. Gemini was the LLM and local fastembed did the embeddings.

I asked who leads the project, how long the battery lasts, and how much money was spent:

Project lead: Meera Joshi. Battery duration: 55 minutes. Money spent: 12 lakh rupees on batteries, plus 8 lakh rupees approved for solar panels

Then, in Outlook, I moved the kickoff email to Archive (one of the synced folders), and deleted the Budget update email and the Budget meeting. Same question after the next sync:

Project Falcon is led by Meera Joshi, the battery lasts 55 minutes, and the provided context does not mention how much money was spent.

Run	What happened	Sync stats
1	First sync	mail 4, events 3
2	Move kept as an update, deleted email and meeting forgotten	mail 1, mail deleted 1, events deleted 1
3	No changes	all 0
4	Asked only about the deleted money: not in the context	all 0

The live test also caught a bug before I recorded it. The daily meeting came back as the series plus 3 bare occurrences with no title. Now a series is one document and the bare entries are skipped. The PR has a video of all four runs.

Try it

Until the PR merges, install it from my branch:

git clone -b feature/outlook-connector https://github.com/laypatel13/cognee-community
cd cognee-community/packages/connector/outlook
uv sync

The quick way, no app registration. This is how I ran my live test. Sign in to Graph Explorer, consent to Mail.Read and Calendars.Read, and copy the token from its Access token tab. It lasts about an hour and is never refreshed.

export OUTLOOK_ACCESS_TOKEN=<token>
export OUTLOOK_MAIL_FOLDERS=inbox,sentitems,archive
export LLM_API_KEY=<your key>
uv run python examples/example.py "What are my recent emails and meetings about?"

The long-term way. Register an app in the Microsoft Entra admin center for any directory plus personal accounts, turn on public client flows, and add the delegated Graph permissions User.Read, Mail.Read and Calendars.Read. Then sign in once with a device code:

export OUTLOOK_CLIENT_ID=<application id>
export OUTLOOK_TOKEN_CACHE_PATH=~/.cognee_outlook_token_cache.json
uv run python examples/login.py

To be upfront: I haven't run this path live. Registering an app on a personal account needs an Azure subscription, which I don't have as a student, so the device code login is only covered by unit tests.

Once you're signed in, syncing looks like this:

import asyncio
import os

import cognee
from cognee_community_connector_outlook import outlook_source


async def main():
    await cognee.remember(
        outlook_source(
            mail_folders=["inbox", "sentitems"],
            client_id=os.environ["OUTLOOK_CLIENT_ID"],
            token_cache_path=os.environ["OUTLOOK_TOKEN_CACHE_PATH"],
        ),
        dataset_name="my_outlook",
        primary_key="id",
        write_disposition="merge",  # makes re-runs incremental and lets deletes reach the graph
        max_rows_per_table=0,  # removes the default cap of 50 rows
    )

    answer = await cognee.recall("What are my emails about?", datasets=["my_outlook"])
    print(answer)


asyncio.run(main())

If you only want headers, pass include_mail_bodies=False and Mail.ReadBasic is enough.

The interesting parts

Removed events are checked first. When Graph reports an event as removed, the connector looks it up by id. A 404 forgets it. Anything else means it only left the window, which is 180 days back and ahead by default, so it stays.

Moving mail is not deleting it. Every request asks for immutable ids, so a message keeps its id when it moves, and the connector tracks which synced folders each message is in. Inbox to Archive, with both synced, is an update. Deleting moves mail to Deleted Items, which is never synced, so the message is in no synced folder and gets forgotten. The same goes for mail moved to any folder you don't sync.

Later runs only fetch changes. Each mail folder and the calendar use Graph delta queries. The delta link only arrives on the last page, so it's saved once the whole round has finished.

People connect across mail and meetings. Sender, recipients, organizer and attendees are written into every message and event, so cognee's entity extraction can link someone's emails to their meetings. That comes from the LLM reading the text, not from a hard identity mapping.

Errors never delete. Only a 404, a cancellation, or mail leaving every synced folder forgets anything. A Graph outage, throttling or one unreadable event removes nothing, and one failing folder doesn't stop the others.

It only reads. It never sends, moves or changes anything. Attachments and Bcc are never read, and the logs hold counts only. Your mail text does go to your LLM provider during processing, like any document you add to cognee, so use a local model if that matters to you.

What three review rounds taught me

goran-radonic reviewed this PR the same way as my Dropbox one: real dlt, real cognee, failures injected on purpose. The test count went from 65 on October 18 to 164 on October 30.

Round one was 20 points. Three of them could lose data or fail without a clear reason. Deleting a series reported every occurrence, and each one was looked up. A failing lookup could wait through Retry-After with no limit: 20 events answering 503 with a 60 second wait, while cognee holds a staging lock. Now all the waits in a run share a 2 minute budget. For this round I reverted each of the 38 guards in the commit, one at a time, to check that a test went red.

Round two found mail and meetings that could never be forgotten. I stream rows page by page, but I only saved state at the end. If page 2 failed, the rows from page 1 still loaded, and the state didn't know about them. Delete one of those later and it stayed in memory for good, with no error anywhere. Yielded ids are now kept in the state even when a part fails.

That round also caught a test that couldn't fail. Graph names all-day time zones the Windows way, like Tonga Standard Time, and my test used Pacific/Tongatapu, which Graph doesn't send. So an all-day event on November 8 could be written as November 7, and my test stayed green. The names are now mapped with tzlocal.

It also showed that a short outage could forget live events. I counted a 5xx as a failed attempt, and after 3 attempts I forgot the event. So a 5xx stopped counting, and giving up now keeps the event.

Round three was caused by that fix. If a 5xx doesn't count, it has no limit. A series master that kept answering 500 stayed in the retry list forever and held up the lookups behind it. Over six runs in a row, nothing moved. Now outages are counted per id, separately from real failures, an id in an outage goes after the others, masters and removals are looked up separately, and after 3 runs in a row the id is given up on and kept.

What I took from this one: a fix is new code with its own failure modes. "This doesn't count as a failure" sounds like a safe rule until you ask what stops it. Every retry, wait and skip needs a limit, and every limit needs a decision about what happens when you reach it.

Limits so far

Only the primary calendar, since Graph v1.0 event delta covers that one.
Attachments are flagged, not ingested.
Subfolders of a selected folder are not synced.

My Google Calendar connector got merged. Then the maintainer fixed 8 things in it

Lay Patel — Fri, 30 Oct 2026 17:37:00 +0000

I filled a Google Calendar with test meetings for a made-up drone project, synced it into AI memory, and asked who leads the project, how long the battery lasts, and how much was spent on batteries.

Project Falcon is led by Meera Joshi, the battery lasts 55 minutes, and 12 lakh rupees were spent on batteries.

Then I deleted the Budget meeting, and deleted one occurrence of the daily sync with "This event". I synced again and asked the same question.

Project Falcon is led by Meera Joshi, the battery lasts 55 minutes, and the provided context does not mention how much was spent on batteries.

The money is gone, because it only lived in the deleted meeting. And deleting one occurrence didn't take the series with it. Asked what the daily sync covers, it still answered:

The daily sync covers the daily stand-up for Project Falcon, where the team tests drone navigation over the Pune test field

cognee is an open source memory layer for AI agents: it turns data into a knowledge graph you can query in plain language. This connector was my first merged PR of Mergetober. PR #370 went into cognee-community on October 15, four days after I opened it.

The same day, the maintainer moved it into the cognee SDK. It now ships with cognee itself, and the SDK file credits PR #370 at the top. That port is the best part of this story, so I'll come back to it.

What I want to use it for

My calendar has college and hackathon dates, and sometimes submission deadlines. So far I've only run this on the test meetings in this post, but on my own calendar I'd ask things like "what do I have coming up before my next hackathon?" or "how many days do I have left to finish this?" A calendar app shows me the days, but it can't answer that in one line.

Try it

In the Google Cloud Console, create a free project and enable the Google Calendar API.
Under Google Auth Platform, set up the consent screen as External, keep it in Testing, add your own account as a test user, and add only the calendar.readonly scope.
Under Clients, create an OAuth client of type Desktop app and download its JSON.
Install cognee with the Calendar extra and point it at that file:

pip install "cognee[google-calendar]"
export GOOGLE_CALENDAR_CREDENTIALS_PATH=~/client_secret.json
export GOOGLE_CALENDAR_TOKEN_PATH=~/.cognee_google_calendar_token.json
export LLM_API_KEY=<your key>

Run this. The first run opens a browser for consent, and later runs reuse the saved token:

import asyncio

import cognee
from cognee.tasks.ingestion.connectors import google_calendar_source


async def main():
    await cognee.remember(
        google_calendar_source(calendar_ids=["primary"]),
        dataset_name="my_calendar",
        primary_key="id",
        write_disposition="merge",  # makes re-runs incremental and lets deletes reach the graph
        max_rows_per_table=0,  # removes the default cap of 50 rows
    )

    answer = await cognee.recall("Who is in my Thursday meetings?", datasets=["my_calendar"])
    print(answer)


asyncio.run(main())

Two things to know before you run it. The first run reads each calendar's whole history, because sync tokens don't allow a time window. And apps left in Testing get refresh tokens that expire after 7 days, so sign in again or publish the app for longer use.

What happened on a real calendar

My live test used the community package on a real Google account, with Gemini as the LLM and local fastembed for embeddings. The calendar had 3 test events and a daily sync repeating 3 times.

Run	What happened	Sync stats
1	First sync: the 3 events, the daily sync series, and one occurrence Google keeps as changed	scanned 5
2	Budget meeting and one daily sync occurrence forgotten, the series kept	deleted 2
3	No changes	all 0
4	Asked about the deleted money and the daily sync: the money isn't in the context, the series is	all 0

The PR has a video of all four runs.

Why a calendar is harder than a folder of documents

A series is one document. Events are listed with singleEvents off, so a recurring meeting is one document with its RRULE. An occurrence you changed becomes its own document.
One deleted occurrence isn't a deleted series. Google sends back a cancelled entry for it, and only that occurrence is forgotten. Deleting the whole series forgets the series and its changed occurrences.
Sync tokens expire. Later runs only fetch what changed. When Google answers 410 Gone, the calendar is listed again and compared against what's stored, so events deleted in the meantime are still forgotten.
People live in the text. The calendar name, organizer and attendees with their responses are written into each event, so cognee's entity extraction can connect the same person across meetings. That comes from the LLM reading the text, not from a hard identity mapping.
It only reads. The only scope is calendar.readonly, attachments are never read, and the saved state holds sync tokens and ids, not titles or descriptions. The event text does go to your LLM provider during processing, like any document you add to cognee, so use a local model if that matters to you.

The 8 things I missed

PR #370 had no review comments. It was merged as it was.

Then the maintainer ported it to the SDK and fixed eight things along the way, so the SDK wouldn't ship them. The list is in cognee#5912, and reading it taught me more than the merge did.

Wrong data:

All-day events came out a day too long, because Google's end date is exclusive.
primary and the calendar's real id produced two sets of documents.
Hidden calendars dropped out of the list, which changed the ids and names of everything under them.
Attendees were written in whatever order Google returned them, so a reorder sent the event through LLM extraction again.

Failure handling:

A 404 on one calendar forgot it, even when the same run still saw it in the calendar list.
A 403 with a rate-limit reason wasn't treated as a rate limit.
check_active, the callback that lets a host stop a sync, only ran once per sync. Now it runs before every API call.

Privacy:

Calendar ids, which are usually email addresses, ended up in logs and error messages.

None of these showed up in my 35 tests or my live run. My tests even covered all-day events, and they still passed.

What I did with it

I went through that list and applied what fit to the connectors I still had open. Dropbox got it on October 17 and Outlook on October 18: check_active before every request, no ids in logs or errors, stable attendee order, all-day events ending on the right day. My Google Meet connector was built on the same layout.

So the lesson from my first merged PR of Mergetober is that a merge doesn't mean your code is finished. When someone fixes your code, read the diff. It's a free review, and it's specific to you.

Forgetting is the hard part: giving an AI agent a memory of my Dropbox

Lay Patel — Fri, 30 Oct 2026 17:36:41 +0000

I asked my AI memory three things about a project: who leads it, how long the drone battery lasts, and how much was spent on batteries.

Project Falcon is led by Meera Joshi, the drone battery lasts 55 minutes, and 12 lakh rupees was spent on batteries.

Then I opened Dropbox, deleted a PDF and a folder, and moved one file somewhere else. I synced again and asked the same question.

Meera Joshi leads Project Falcon. The provided context does not contain information about how long the drone battery lasts or how much was spent on batteries.

That second answer is what I spent most of October on. Getting files into memory is the easy part. The hard part is getting them out at the right moment, and never by accident.

(Project Falcon is made up. I wrote those files for testing.)

cognee is an open source memory layer for AI agents. You hand it data and it builds a knowledge graph plus vector search on top, so you can ask questions across everything. For Mergetober I built a Dropbox connector for it, and it was merged into cognee-community on October 30.

A bit about me: I'm studying CSE (AI/ML), I started coding and using git in May 2026, and I had some open source experience before this. I joined Mergetober because it was something related to AI, and I mean, you can give it memory. Who wouldn't love that?

What I want to use it for

So far I've only run this on the test files below, not on my own, and honestly I rarely use Dropbox. If I sync something real, it'll be my college technical reports, like FASTag and smart dustbin. They're PDFs, so the connector can read them, and a question like "which of my reports use RFID, and what did I say about it?" needs an answer across all of them, which a plain file search won't give me.

Try it

The package isn't on PyPI yet, so install it from the repo:

git clone https://github.com/topoteretes/cognee-community
cd cognee-community/packages/connector/dropbox
uv sync

Create a Dropbox app with Scoped access. Pick App folder if you only want it to see Apps/<your app>/, or Full Dropbox if you want everything.
In the Permissions tab, enable files.metadata.read and files.content.read, then click Submit. Nothing else is needed.
Copy the App key and get a refresh token once. This uses the PKCE flow, so there's no app secret and the token doesn't expire:

DROPBOX_APP_KEY=<app key> uv run python examples/get_refresh_token.py

Set DROPBOX_APP_KEY, DROPBOX_REFRESH_TOKEN and your LLM_API_KEY, then save this as sync.py and run it with uv run python sync.py:

import asyncio
import os

import cognee
from cognee_community_connector_dropbox import dropbox_source


async def main():
    await cognee.remember(
        dropbox_source(
            folder_paths=["/Notes"],
            refresh_token=os.environ["DROPBOX_REFRESH_TOKEN"],
            app_key=os.environ["DROPBOX_APP_KEY"],
        ),
        dataset_name="my_dropbox",
        primary_key="id",
        write_disposition="merge",  # makes re-runs incremental and lets deletes reach the graph
        max_rows_per_table=0,  # removes the default cap of 50 rows
    )

    answer = await cognee.recall("What are my notes about?", datasets=["my_dropbox"])
    print(answer)


asyncio.run(main())

Run it again whenever you want to sync. It reads txt, md, csv and PDF files and exports Paper docs. Anything else is skipped and counted.

What happened on a real Dropbox

I tested on a free Dropbox account with an App folder app, Gemini as the LLM and local fastembed for embeddings. These are the four runs behind the answers at the top:

Run	What happened	Sync stats
1	First sync of 5 files, `logo.png` skipped as unsupported	scanned 5, skipped 1
2	After deleting `budget-report.pdf` and the Meetings folder, and moving `project-falcon.md` into a new Archive folder	scanned 1, deleted 2
3	No changes, and the access token refreshed by itself	scanned 0
4	Asked only about facts from the deleted files	scanned 0

The battery facts lived only in the deleted files, so they're gone. Meera Joshi survives because that name was also in the moved file, which was updated in place and not forgotten.

Here's run 4. cognee says the facts are no longer in its context, and the sync stats are all zero:

The PR has a video of runs 1 and 2, with the changes being made in Dropbox.

Four things that make forgetting hard

Only what changed is fetched. The connector saves Dropbox's list_folder cursor, one per folder, so the next run gets just the changes.

Deletes arrive without an id. Dropbox reports a deleted file by path, but memory is keyed by id. So the connector keeps a path to id index and turns deleted paths back into ids. A deleted folder forgets everything under it: /notes/ matches, /notes2 doesn't.

A move looks like a delete. A rename shows up as a deleted old path plus the same id at a new path. Deletes are held until every folder has been read, so a moved file is updated in place. It isn't forgotten and learned again.

A passing error never deletes. A network error, a 5xx, a rate limit, a bad token, or a folder Dropbox reports as locked or restricted removes nothing. Data only goes when Dropbox says it's gone, when a file leaves the synced folders, or when a stored file turns unreadable for good: skipped now, or failed on 3 runs in a row. Old text shouldn't stay in memory as if it were still current.

What the review taught me

I opened the PR on October 8 with 35 tests, an in-memory fake of Dropbox, and the live test above. It merged 22 days later with 125 tests. Most of that gap came from review. goran-radonic ran my code through real dlt and cognee and injected failures on purpose, round after round.

Four of the things that came up:

A file written over an old path. Delete a file and create a new one at the same path, and between two syncs Dropbox may report only the new file. My index overwrote the old id and nothing ever forgot it. Through real cognee, the dataset ended up with 2 documents and both versions in the graph.
A file edited down to nothing. An emptied file gets skipped, and a skipped file emitted nothing, so the old text stayed in memory. The same went for a file that grew past the size limit or got renamed to a type I don't read.
The third sync after a folder delete. The folder was forgotten correctly, but I lost track of it. The next run read it as never synced and raised a folder not found error.
One locked folder. This was the last round, on the day it merged, and it's the comment that stuck with me most. I was treating every lookup error on a synced folder as "the folder is gone". That included locked, which is temporary, and other, the SDK's catch-all. One injected locked error made the run forget that folder's files, and the next run learned them again, paying for LLM extraction twice. It also made my own README line, "A passing error never deletes", false. Now only not_found and not_folder forget a folder.

The other half of the review was about my tests. The maintainer would remove code and check whether anything went red. In the first round, a whole filter could be deleted and all 56 tests stayed green. That's mutation testing. I already checked that each new test failed without its fix, but I hadn't asked the same of the code I'd written earlier. From then on, I reran each mutation myself before pushing.

What I took from it:

A fake only knows what you told it. Mine passed because it shared my assumptions. As I said in the PR, the real pipeline "found things my fake never would".
A green test means nothing until you've seen it red. Remove the fix, watch the test fail, put the fix back.
Ask "what if this fails halfway?" about every line that touches state. And never write "any error means gone". List the errors that really mean gone, and let everything else stop the run.

I've carried all three into my other connectors. Thanks to goran-radonic for the time put into these rounds.

Limits so far

Team spaces aren't supported yet.
Paper export is unit tested, but I haven't tried it on a live Paper doc.

One phished login, 18 poisoned packages, 74 minutes of silence: so I built a graph that asks who can poison your app

Lay Patel — Sat, 17 Oct 2026 12:15:52 +0000

On September 8, 2025, someone phished the npm login of one well-known maintainer, @qix.

Within minutes, poisoned versions of 18 packages went out: debug, chalk, ansi-styles, strip-ansi… packages with around 2 billion downloads a week between them, sitting deep inside millions of apps.

The first public advisory showed up at OSV 74 minutes later. Until then, every scanner that works from advisories said the same thing: all clear.

That stuck with me. Those scanners weren't broken. They were answering the wrong question.

The question nobody was asking

Security tools ask "is this version known to be bad?" That only works after someone has noticed, investigated and published an advisory.

But the danger on Sept 8 wasn't one package. It was one person's account. The better question is:

Who can push code into my app, and how much of it can each of them reach?

No advisory database can answer that, because the answer isn't a fact about a package. It's the shape of your dependencies: you → your 90 direct dependencies → a thousand hidden ones → the hundreds of people who can publish them.

That's a graph question. So for Graph Hacks I built Chokepoint on FalkorDB.

chokepoint.onrender.com

The graph

Chokepoint reads your package-lock.json, asks npm who maintains each package and asks OSV about advisories. Then it builds one FalkorDB graph per project:

(Project)-[:DEPENDS_ON {range, dev}]->(Version)
(Version)-[:DEPENDS_ON {range}]->(Version)
(Version)-[:VERSION_OF]->(Package)
(Maintainer)-[:MAINTAINS {current, at_install}]->(Package)
(Maintainer)-[:PUBLISHED]->(Version)
(Advisory)-[:AFFECTS]->(Version)

For the replay I used webpack-dev-server's real lockfile from Aug 25, 2025, two weeks before the attack: 1,423 versions, 90 direct dependencies, 685 npm accounts, 3,108 links.

(One rule I kept from day one: maintainers are stored by npm username only. Emails are dropped the moment they're read.)

"Who could poison me?" in one query

Here's the heart of it. For every npm account: how many of my direct dependencies eventually pull in a package that account can publish?

MATCH (p:Project)-[r:DEPENDS_ON]->(d:Version)
CALL algo.BFS(d, -1, NULL) YIELD nodes
UNWIND nodes AS pkg
WITH r, d, pkg WHERE pkg:Package
MATCH (pkg)<-[m:MAINTAINS]-(u:Maintainer)
WHERE ($when = 'now' AND m.current) OR ($when <> 'now' AND m.at_install)
WITH u, d, r
RETURN u.username AS maintainer,
       count(DISTINCT d) AS reach,
       count(DISTINCT CASE WHEN r.dev THEN NULL ELSE d END) AS prod_reach

On the replay project, @qix comes out at 43 of 90 direct dependencies. One phished login could reach almost half the app.

Ties are broken with algo.betweenness (accounts sitting on the bridges many paths pass through) and algo.pageRank (how influential the versions they control are).

The lesson that cost me an evening: BFS, not `[:DEPENDS_ON*]`

My first version used a variable-length pattern, (d)-[:DEPENDS_ON*]->(pkg). It looked elegant and timed out.

A variable-length match walks every possible path, and real dependency graphs have exponentially many of them (diamonds everywhere: a → b → d and a → c → d…). algo.BFS visits each node once. Same answer, and it actually returns.

The opposite turned out to be true for "how many things depend on this one version?": a single walk backwards with count(DISTINCT …) was about 10× faster than a BFS from every node. Graph work is a lot of measuring.

Meet Nightjar 🐦

Knowing who could poison you is half the story. The other half is noticing when someone does.

Nightjar is Chokepoint's watcher agent (a nightjar is a night bird with huge eyes that hides in plain sight). Every minute it looks for new releases of your app's packages, and for each one it runs a loop:

watch → investigate (in the graph) → decide → act → remember

The decision is plain rules, no AI, because a security verdict should be explainable and checkable:

Signal	Points
A fresh install would take it (inside your declared ranges)	+3
A burst: 3+ releases from one account within 10 minutes	+3
A new install script	+3
Publisher isn't in the package's maintainer list	+3
Provenance dropped	+2
Publisher reaches much of your app	+1
The account already triggered alerts (memory)	+1

3 points is a WATCH, 6 an ALERT.

Replaying npm's real publish times from Sept 8:

13:12:10 ansi-styles@6.2.2: WATCH
13:12:39 debug@4.4.2: WATCH
13:13:05 chalk@5.6.1: ALERT. Inside 6 of the app's ranges (+3), the third release from @qix in 54 seconds (+3), from an account reaching 43 of 90 dependencies (+1). Score 7.

The first advisory arrived at 14:26. Nightjar would have raised its alert 73 minutes earlier, without knowing anything about malware: just from the shape of the graph and the rhythm of the releases.

And on an ALERT it acts: it pins the version your lockfile already had (only for the poisoned release) under overrides in package.json, can open a fix PR on your repo, and notify you on the desktop, Slack or Discord.

Memory, in the graph too

This was the Track 02 part, and my favourite design decision: Nightjar's memory is a FalkorDB graph of its own, one per project (memory:<project>):

(Alert)-[:ABOUT]->(Package)
(Alert)-[:PUBLISHED_BY]->(Maintainer)
(Decision)-[:BASED_ON]->(Alert)

It lasts: rebuilding a project's graph never touches its memory.
It changes: open alerts are re-checked against OSV every cycle and move to CONFIRMED or CLEARED, each move a new Decision, so the history stays.
It feeds the next decision: earlier alerts on an account raise the score of its next release. On Sept 8, every release after chalk carried @qix already triggered N alert(s).
It's shared: Nightjar writes it; a second agent reads it.

Any AI can use it: MCP

Every question Chokepoint answers is a function in one file, tools.py, and the same functions are served by an MCP server. The website's "Ask" box is an MCP client of that server: your LLM picks a tool from the list, the call goes through MCP, and the graph computes the answer. The LLM only translates it into plain words, and it never writes Cypher.

So "what did Nightjar flag?" picks the recall tool, reads Nightjar's memory graph and lights up every flagged package on the graph. No LLM? Keyword rules pick the tool instead. Nothing in Chokepoint needs AI.

(A bug I found while recording the demo: my MCP server stripped the "what to light up" field from every result to keep it lean for outside clients, so the website's own Ask answers never lit up the graph. Fixed by letting Chokepoint's own agent ask for it. Recording a demo is the best QA I know.)

Replay vs the real thing

The website is a replay of Sept 8 on real data: npm's real publish times, OSV's real advisory times, a real lockfile. At the end it even opens a real pull request on a sandbox fork, and Nightjar leaves a note for each visitor.

But the real product runs on your machine:

pipx install --python 3.12 ckpoint
cd your-app
chokepoint            # builds the graph from package-lock.json
chokepoint who        # who can poison you, ranked by reach
chokepoint check debug@4.4.2
chokepoint nightjar --drill --act   # the real Sept 8 releases vs YOUR app

It uses an embedded FalkorDB, so there's no Docker, no account and no server, and nothing leaves your laptop. If you plug in an LLM or a GitHub token, they stay on your machine too. That one mattered to me more than any feature.

What I'd tell myself on day one

Ask the question your tools can't. The interesting security question wasn't "is it bad?" but "who could make it bad?", and only a graph could answer it.
Let the graph reason; keep the AI as a translator. Explainable rules for the verdict, Cypher for the facts, the LLM for the words.
Measure your traversals. [:DEPENDS_ON*] vs algo.BFS was the difference between a timeout and an instant answer.
Memory belongs in the graph. Alerts, decisions and accounts are relationships, so storing them as a graph made "has this account done this before?" a one-hop question.
Record your demo early. It found three real bugs for me, including one in the published CLI that only showed up on an older Typer version.

Try it

🌐 Live replay: chokepoint.onrender.com (free tier, so give it a few seconds to wake up)
🎬 Demo video: watch the 5-minute demo
💻 Code: github.com/laypatel13/chokepoint
📦 CLI: pipx install --python 3.12 ckpoint

@qix didn't do anything wrong: their account was phished, and it could have been anyone's. The point isn't blame. It's knowing, before it happens, how much of your app sits behind one login.

Built for Graph Hacks (WeMakeDevs × FalkorDB), Tracks 01 + 02.

SQL Doctor: An Offline Tutor That Explains PostgreSQL Errors to My DBMS Lab Classmates

Lay Patel — Sun, 04 Oct 2026 16:12:41 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

This semester I'm taking a DBMS lab where we write PostgreSQL queries every week. Writing the queries isn't the hard part. Understanding the errors is.

column "instructor.name" must appear in the GROUP BY clause or be used in an aggregate function makes perfect sense once you know SQL. A few weeks into your first database course, it reads like a riddle. So I built something for my friend Jay Patel and my lab classmates.

SQL Doctor is a small web app. You paste the query that failed and the error PostgreSQL printed, and it tells you:

What went wrong, in one or two plain sentences
Where, quoting the exact part of the query that broke
The fixed query, changing only what's needed
A tip so the same mistake doesn't happen again

It can explain in English, Hinglish or Gujarati, because that's how my classmates and I actually talk. You can also paste your CREATE TABLE statements for more accurate answers, and there are four built-in examples of the mistakes we make most often.

Demo

Try the interface at sql-doctor.onrender.com. The hosted copy is a preview of the interface. The real answers come from Gemma running locally on your own laptop, which is the whole point, so clone the repo below to run it yourself.

Code

laypatel13 / sql-doctor

SQL Doctor

Paste a PostgreSQL query that failed and the error it gave you. SQL Doctor explains what went wrong in plain words, points to the exact part of the query that broke, and shows the fixed query. It can explain in English, Hinglish or Gujarati.

I built it for my DBMS lab classmates, who lose a lot of lab time staring at errors like column "x" must appear in the GROUP BY clause.

It runs entirely on your own laptop with Gemma 4, an open-weight model, through Ollama. Your queries never leave your machine, it works without internet, and it costs nothing to run.

Run it

Install Ollama and download the model:
```
ollama pull gemma4:e4b
```
On a slower laptop, use gemma4:e2b instead and change the model name in the app's sidebar.

Install the Python packages:

python -m venv .venv
source .venv/bin/activate      # Windows: .venv\Scripts\activate
pip install

…

View on GitHub

How I Built It

SQL Doctor runs entirely on the laptop:

Gemma 4 (gemma4:e4b) does the explaining. It's an open-weight model small enough to run on an 8 GB laptop.
Ollama serves the model locally.
Streamlit is the interface, about 300 lines of Python in a single file.

Most of the thinking went into the system prompt. It forces every answer into the same four sections, so answers are consistent and easy to skim. It runs at a low temperature so the fixes stay steady. And it has two rules I care about most: never invent tables or columns the student didn't mention, and say "I'm not sure" instead of guessing. A tutor that confidently gives you a wrong fix is worse than no tutor.

The answer streams in as Gemma writes it. Once it's done, the sections turn into small badges: red for what broke, green for the fix. The design reuses the theme from Netra, another project of mine: neutral greys everywhere, blue only for things you can click, and color only where it carries meaning.

Why Does Open Innovation Matter?

For a student tool, open models are the whole point.

It's free. None of my classmates is going to put a credit card on an API account to debug a lab query. Gemma runs locally at zero cost per question.
It works offline. Once the model is downloaded, it doesn't need the internet at all.
Our work stays on our laptops. Lab assignments never get sent to someone else's server.
It fits the hardware. If a friend's laptop is older, they can switch to gemma4:e2b in the settings.

A closed API would have meant keys, usage limits and a bill, and I couldn't hand it to a friend without handing over my key too. With Gemma and Ollama, sharing it is just git clone.

What Jay Said

I showed SQL Doctor to Jay, and his reply was one word: "Crazzy! 🔥"

My Agent Session

I built this with help from Claude, which helped me scaffold the Streamlit app, shape the system prompt and restyle it with my Netra theme. I then tested it on errors from my own lab work.

Prize Categories

Best Use of Gemma: SQL Doctor runs on Gemma 4 locally through Ollama, and Gemma does all of the explaining.

DEV Community: Lay Patel

Who actually joined that meeting? Connecting Google Meet to cognee

What I want to use it for

What it syncs

Try it

What happened on a real call

Details I cared about

What I did differently this time

Looking back at the month

Links

Removed doesn't mean deleted: syncing Outlook mail and meetings into AI memory

What I want to use it for

What happened on a real account

Try it

The interesting parts

What three review rounds taught me

Limits so far

Links

My Google Calendar connector got merged. Then the maintainer fixed 8 things in it

What I want to use it for

Try it

What happened on a real calendar

Why a calendar is harder than a folder of documents

The 8 things I missed

What I did with it

Links

Forgetting is the hard part: giving an AI agent a memory of my Dropbox

What I want to use it for

Try it

What happened on a real Dropbox

Four things that make forgetting hard

What the review taught me

Limits so far

Links

One phished login, 18 poisoned packages, 74 minutes of silence: so I built a graph that asks who can poison your app

The question nobody was asking

The graph

"Who could poison me?" in one query

The lesson that cost me an evening: BFS, not [:DEPENDS_ON*]

Meet Nightjar 🐦

Memory, in the graph too

Any AI can use it: MCP

Replay vs the real thing

What I'd tell myself on day one

Try it

SQL Doctor: An Offline Tutor That Explains PostgreSQL Errors to My DBMS Lab Classmates

What I Built

Demo

Code

laypatel13 / sql-doctor

SQL Doctor

Run it

How I Built It

Why Does Open Innovation Matter?

What Jay Said

My Agent Session

Prize Categories

The lesson that cost me an evening: BFS, not `[:DEPENDS_ON*]`