DEV Community: Geetansh Vikram

I Ported a JavaScript Markdown Parser to Rust in 72 Hours — Here's What Actually Broke

Geetansh Vikram — Mon, 03 Aug 2026 13:26:33 +0000

By Geetansh Vikram | Port Mortem 2026 | Track F

Who Am I

I'm a third-year Computer Science Engineering student at NIT Silchar. I'm not a professional Rust developer. I'm not a compiler engineer. I haven't shipped a production parser before.

I'm a student who saw a hackathon about porting code between languages and thought — I know JavaScript, I've been learning Rust, how hard could this be?

The answer, it turns out, is: significantly harder than I thought. And significantly more rewarding than I expected.

This is the honest story of how I built marked-rs — a port of the marked.js Markdown parser from JavaScript to Rust — over 72 hours for Port Mortem 2026.

Why marked

The hackathon gives you a pool of eligible repos. When I saw marked.js on the list I immediately knew it was the one.

Not because it was easy. Because it was interesting.

Markdown parsers look simple from the outside. Headings, bold text, links. How complicated can it be? Then you read the CommonMark specification and discover it has 652 numbered examples specifically designed to cover every edge case, every ambiguity, every place where naive implementations break. The emphasis algorithm alone has 131 test cases and a rule — Rule 17 — that exists purely to break regex-based parsers.

I also knew the context. The Port Mortem hackathon was created because the Bun project merged a 960,000-line Zig-to-Rust rewrite with 13,044 unsafe blocks and edited their test suite to make it pass. The judges created this competition to prove AI-assisted porting can be done correctly.

I wanted to be the proof.

Day One — The Confidence Phase

I started with a prompt. A very detailed prompt for Cursor describing the exact architecture, the token types, the pipeline stages, the fuzz harness, everything. I'd done my research. I knew marked.js uses a Lexer → InlineLexer → Renderer pipeline. I knew Rust would let me model this cleanly with enums. I knew I wanted zero unsafe blocks.

The first build compiled. The first test ran.

52% CommonMark spec compliance.

I was actually pleased. 52% on day one with a fresh implementation meant the core pipeline was working. Headings passed. Paragraphs passed. Basic emphasis passed.

I committed that and went to sleep thinking the hard part was behind me.

It was not behind me.

The Emphasis Algorithm — The Six Hours That Ate Me

CommonMark §6.2 describes emphasis parsing with a delimiter stack algorithm. The spec dedicates more text to this than to any other feature. There's a reason for that.

The naive approach — regex like \*(.+?)\* — fails immediately on cases like:

*foo**bar**baz*

What should that produce? The spec says: <em>foo<strong>bar</strong>baz</em>. A regex gives you garbage.

The correct approach requires a delimiter stack — a data structure that tracks opening and closing delimiter runs, their lengths, and whether they can open or close based on surrounding characters. Then Rule 17: when both the opener and closer have lengths divisible by 3, they only match if their sum is not divisible by 3.

I implemented this three times.

The first implementation failed on mid-word underscores — foo_bar_baz was being emphasized when it shouldn't be. The second implementation fixed that but broke partial consumption — **foo* bar* was producing wrong nesting. The third implementation finally passed all 131 emphasis examples.

Six hours. One feature. 131 test cases.

I went from 64% to 80% compliance in that session.

The ReDoS Discovery — The Moment Everything Changed

Around hour 40 I had the differential fuzzer running. It compares our Rust output to Node.js marked output on thousands of random inputs per minute — 130+ runs per second. I let it run overnight.

When I woke up, the log was clean. Zero divergences.

But I noticed something in the pathological input corpus I'd built — a specific pattern:

[[[[[[[[[[[a

Eleven nested opening brackets. I ran it through marked.js:

time echo "[[[[[[[[[[[a" | node -e "const m = require('marked'); ..."

It hung. I waited. 10 seconds. 20 seconds. 30 seconds.

31 seconds for 11 characters.

That's a ReDoS vulnerability — Regular Expression Denial of Service. The bracket parsing in marked.js has O(2^n) time complexity on crafted inputs. An attacker sending a few hundred nested brackets to any service running marked.js could cause a denial of service.

I ran the same input through marked-rs:

time echo "[[[[[[[[[[[a" | ./target/release/marked-rs

1.8 milliseconds.

We had built a MAX_BRACKET_DEPTH guard early in development specifically because I'd read about this class of vulnerability. It turns out we'd accidentally protected against a real security issue in the original library.

That moment — comparing 31 seconds to 1.8 milliseconds on the same 11-character input — is the moment I understood why this work matters. It's not academic. It's not performance theater. A parser bug is a security bug.

The Numbers That Disappointed Me

I want to be honest about this because the hackathon specifically asks for honest numbers.

The throughput speedup on large files is 2.4× to 4×.

When I first saw this I was disappointed. Rust is supposed to be fast. Where was my 50× speedup?

The answer is: marked.js is a mature, heavily optimized JavaScript library. V8 JIT compiles it aggressively. On large file parsing where startup overhead doesn't matter, the speedup is real but modest.

The startup story is different. 6.6× faster cold start. For a CLI tool processing a single README.md file — which is the primary use case — the total wall-clock time difference is 16ms vs 105ms. That's felt.

And then there's the binary size story: 1.2 MB vs 47 MB of node_modules. That's 39× smaller deployment.

I rewrote the performance section of my README three times before I found framing that was both honest and compelling. The throughput number alone is underwhelming. The startup number plus the binary size together tell a complete picture.

Honest numbers over confident claims. That's the standard. I tried to meet it.

The Decision I'd Take Back

I wrote the renderer using string concatenation first:

fn render_paragraph(tokens: &[InlineToken]) -> String {
    format!("<p>{}</p>\n", render_inline(tokens))
}

Every block element allocates a new String and concatenates. A 1MB document might trigger thousands of heap allocations during rendering.

The correct approach — which I switched to midway through — is a single &mut String buffer passed through the entire render pipeline:

fn render_paragraph(tokens: &[InlineToken], buf: &mut String) {
    buf.push_str("<p>");
    render_inline(tokens, buf);
    buf.push_str("</p>\n");
}

Zero intermediate allocations. One buffer for the entire document.

I made this switch at hour 55 of 72. It improved throughput by about 15% and dropped RSS noticeably on large documents. If I'd done it from the start — which I should have, it's in the DECISIONS.md entry that tells me to do it from the start — the numbers would have been better from day one.

Lesson: write the renderer with a buffer from the beginning. The refactor is annoying and the test suite will catch anything you break, but it's better to not need the refactor at all.

What Actually Won the Hackathon (In My Opinion)

Not the code.

Well, the code matters — 97.5% CommonMark spec compliance and zero unsafe blocks are not trivial achievements. But what I think made the submission genuinely strong was everything around the code:

The cryptographic proof. The CommonMark spec test file is GPG-signed. Any judge can run gpg --verify tests/spec.json.asc and mathematically verify we never modified the test files. This is the Bun problem solved at the cryptographic level. Not our word. Math.

The honest documentation of failures. The 9 failing examples are documented in the README by category: which ones are marked.js intentional divergences, which ones require architectural refactoring we couldn't do in 72 hours, which ones are HTML block edge cases. A submission that claims 100% and can't reproduce it on demand scores below a submission that claims 97.5% and can explain every failure.

The DEFENSE.md. A file containing answers to the 5 hardest questions a judge might ask — including a full trace of the emphasis delimiter stack on a specific input. Most teams don't anticipate questions. We wrote the answers before anyone asked them.

The FUTURE.md. A letter to whoever maintains this project next. What we got right, what we got wrong, what v2.0 should fix first. It sounds small. But judges are engineers. They've all shipped something in 72 hours that they knew had rough edges. A team that documents its own limitations honestly is a team that understood what they built.

What I Actually Learned

Going into this I knew Rust syntax. I could write ownership rules. I understood the borrow checker.

Coming out of this I understand something different: what Rust is for.

The zero unsafe constraint wasn't just a hackathon rule. It was a discipline that changed how I wrote code. When you can't use unsafe, you can't paper over your bugs with raw pointer arithmetic. You have to actually understand your data's lifetime. You have to use char_indices() instead of byte indexing. You have to think about what "the middle of a string" means in Unicode.

Every time I hit a problem and thought "I could solve this with unsafe" — I found the safe solution. Every single time. And the safe solution was always more readable and caught at least one edge case I hadn't considered.

The compiler isn't just rejecting your code. It's showing you where your mental model is wrong.

I also learned what CommonMark actually is. I read more of that specification in 72 hours than most developers read in a career. I know now why emphasis is hard. I know why link reference definitions require two-pass parsing. I know the seven types of HTML blocks and which ones can interrupt a paragraph and which ones can't.

I understand Markdown now. Not just as a user. As an implementer.

Hackathon Raptors — What This Community Did For Me

I want to say something genuine here because it's easy to scroll past the thank-you section and I don't want this to be skippable.

I came into Port Mortem as a student. Not a professional. Not someone with production Rust experience. Not someone who had ever written a parser from scratch.

The Port Mortem hackathon didn't just give me a problem to solve. It gave me a reason to go deep. The judging criteria — Functionality, Behavioral Equivalence, Code Quality, Innovation — aren't arbitrary categories. They're the same criteria that matter in production systems. Differential fuzzing. Honest benchmarks with p99 and RSS. Decision logs that explain why, not just what.

I learned more about software engineering in 72 hours than in months of coursework. Not because the coursework is bad — because the hackathon gave me a real target with real stakes and real judges who would actually read my DECISIONS.md.

The $300 write-up prize being awarded "on insight, not follower count" is the sentence that made me trust this community. A 200-follower account writing something genuinely useful beats a viral thread that says nothing. That's a philosophy I want to carry into everything I build.

To Hackathon Raptors — thank you for creating a competition where the anti-Bun is the winning move. Where honesty scores higher than confidence. Where documenting your failures is rewarded more than hiding them.

You gave a third-year student from NIT Silchar a reason to read a 600-page specification at 3am. And genuinely enjoy it.

That's the gift.

The Numbers, One More Time

Because the hackathon asks for honest numbers and this is the write-up:

CommonMark spec compliance:  97.5% (636/652)
unsafe blocks:               0 — compiler enforced
Differential fuzz runs:      78,432
Divergences:                 0
Panics:                      0
Startup speedup:             6.6×
Binary size:                 1.2 MB vs 47 MB
Hours of sleep lost:         unknown, not measured

marked-rs is live at: github.com/geetanshvikram-web/Marked

Live verification portal: geetanshvikram-web.github.io/Marked
*Youtube Video : * https://www.youtube.com/watch?v=dZaQNHlthrY
Port Mortem 2026 — Track F — JavaScript → Rust

I Had Never Heard of Cognee. Then I Spent 5 Days Breaking It Wide Open.

Geetansh Vikram — Sun, 05 Jul 2026 18:00:49 +0000

By Geetansh Vikram | WeMakeDevs × Cognee Hackathon

🎥 Watch the full video demo here: ContextRot-Bench Demo on YouTube

I want to be honest with you from the first line: when I saw "WeMakeDevs × Cognee Hackathon," I had to Google what Cognee was.

I'm a third-year CSE student at NIT Silchar. I spend most of my time grinding competitive programming problems, building Android apps, and occasionally doing something reckless like fine-tuning a 1.5B parameter RL model for a hackathon. I knew what vector stores were. I knew what knowledge graphs were. But "memory layer for AI agents"? I read the landing page three times before it clicked.

And then it really clicked. And I couldn't stop.

The Moment I Got Hooked

The hackathon description had this line that stuck with me:

"Your AI wakes up every morning with no memory of last night."

I'm a CP guy. I think in test cases. And immediately I started thinking: what's the adversarial test case for AI memory? Not "can the agent remember a fact" — that's the easy case. The hard case is: what happens when the agent has been told two different things about the same subject, and one of them is wrong now?

That's context rot. And the more I read about it, the more I realized this is not a toy problem. This is the reason support bots quote outdated return policies. This is the reason coding assistants suggest deprecated APIs. This is why "AI memory" demos always show you adding facts but never show you what happens when facts change.

I decided that's what I was going to build. Not another chatbot-with-memory demo. A proof — something with a number attached to it.

Learning Cognee From Zero

I cloned the repo on day one and started reading.

Cognee's public API is beautifully simple on the surface:

await cognee.add("some text")
await cognee.cognify()           # builds the knowledge graph
results = await cognee.search("some question")
await cognee.improve()           # enriches / resolves contradictions

Four functions. I thought: okay, this is going to be a quick weekend build.

I was wrong in the best possible way.

The first thing I learned is that Cognee is not just a vector store with a nice API wrapper. Under the hood it's running a hybrid store — LanceDB for vector embeddings, Kuzu for the graph database — and cognify() is actually running LLM-based entity and relationship extraction to build a real knowledge graph from your raw text. That's not a small thing. That means when you add "Alice lives in New York," Cognee doesn't just embed that sentence — it extracts Alice as an entity, lives in as a relationship, and New York as a node, and stores those structural connections in the graph.

That was the moment I realized this was going to be genuinely interesting to explore.

The Assumption That Turned Into a Discovery

My original plan was to build a benchmark: feed two pipelines the same stream of evolving facts (Alice lives in New York → then Chicago → then Seattle), ask them "where does Alice live now," and prove Cognee gives the right answer while a naive vector store hallucinates across all three cities.

For Cognee's pipeline, I planned to use improve() — the function the docs describe as "run post-ingestion enrichment, prune stale nodes, and adapt weights based on user feedback." Perfect. That would handle the contradiction resolution.

So I built a verification script. I ingested a supersession fact. I called improve(). Then I dumped the raw graph and counted the nodes.

The stale "New York" node was still there. The count had gone up, not down.

I stared at this for a while. Then I dug into Cognee's source code.

What improve() actually does — and this is fascinating once you understand it — is LLM-side reconciliation. It adds resolution edges and enriches the graph with new context. When you query later, the LLM can reason its way to the correct answer by reading the contradiction metadata. In a lot of cases, this works fine. The LLM is smart enough to figure out that "Seattle supersedes Chicago supersedes New York."

But that's not the same as physical deletion. The stale node is still there. If you retrieve a context window with all three locations in it, you're trusting the LLM to resolve the contradiction every single time at query cost. And sometimes it doesn't — I could show that empirically with my naive pipeline, which was doing the same kind of LLM-at-query-time resolution and getting it wrong 75% of the time.

So I built the missing piece myself.

Building the Deep-Pruning Layer

This is the part I'm most proud of.

Cognee exposes its underlying graph engine and vector engine as importable clients:

from cognee.infrastructure.databases.graph.get_graph_engine import get_graph_engine
from cognee.infrastructure.databases.vector.get_vector_engine import get_vector_engine

I used these to build a custom pruning step that runs after every cognify() call when a new fact supersedes an old one. The logic:

Query the Kuzu graph for any Fact node where subject and value match the superseded values
Delete that node from the graph
Find all associated vector chunks across every LanceDB table (DocumentChunk, TextSummary, EdgeType) using the node ID
Delete each chunk individually

Two stores, one atomic operation, zero stale data.

Along the way I found another silent failure: if you install fastembed as a standalone package but don't install cognee[fastembed] (the plugin wrapper), Cognee silently falls back to building the graph without generating any vector embeddings at all. No error, no warning you'd notice, just an empty vector store. That cost me an afternoon and is now documented in the README.

I also found that Cognee's LLM extraction sometimes rephrases predicates — "lives in" becomes "resides in" or "location" — which would break naive exact-string matching on the predicate field. So instead of matching by predicate, I match by subject + the specific superseded value. That combination is unique enough to identify the stale node reliably, regardless of how the LLM phrased the relationship during extraction.

What the Benchmark Actually Shows

I built 15 synthetic fact-stream scenarios: job application statuses, user locations, subscription plans, favorite programming languages, flight statuses — domains where facts naturally evolve and contradict each other. Each scenario has a ground truth answer (what's true right now) and a set of stale values that should not appear in any answer.

The results:

Pipeline	Accuracy
Naive Vector Store	0%
Cognee + Deep-Pruning Layer	100%

But the number I find more interesting is from the adversarial test. I ran three edge cases specifically designed to stress-test the system:

Case 1 (Paraphrased query): "What city is Alice currently residing in?" instead of "Where does Alice live?"

Naive: "There are multiple cities listed (New York, Seattle, Chicago), but only one can be current. The context does not specify which is current."
Cognee: "Seattle."

Case 2 (Stable fact): "What is Alice's favorite color?" — a fact that was never updated

Naive: "Blue" ✓
Cognee: "Blue." ✓

Both pipelines get stable facts right. The failure is specifically on contradicted facts. That rules out "Cognee just got lucky" as an explanation.

Case 3 (Recency bias): "Where did Alice move to in 2025?" — phrased to give a recency-biased naive pipeline its best chance

Naive: "There is no information about Alice moving in 2025. The context only provides multiple current locations."
Cognee: "Seattle."

The naive pipeline couldn't resolve this even with a year hint. Because the raw vector chunks don't have meaningful chronological structure — they're just text — there was no signal to prefer Seattle over Chicago over New York. Cognee's graph, with the stale nodes physically absent, had only one answer available.

The Open Source Part — Which Honestly Means a Lot to Me

I've been doing competitive programming for two years. I've built Android apps. I've submitted to hackathons. But I had never actually contributed to an open-source project before this hackathon.

That changed this week.

While building ContextRot Bench, I spent so much time reading Cognee's migration source code — the GraphitiSource, Mem0Source, ZepSource classes, the COGX memory standard — that I started to actually understand the codebase. Not just the high-level API, but the internals. How import_source.py orchestrates the migration. How COGXMemory vs COGXFact vs COGXEntity map to different kinds of knowledge.

When I saw open issues asking for migration tutorials — "Tutorial: Migrate from Graphiti to Cognee," "Tutorial: Migrate from mem0 to Cognee" — I realized I was probably one of the few people outside the core team who had actually read those source files this week.

So I went and claimed those issues. I have officially submitted two Pull Requests to the main topoteretes/cognee repository for these migrations, and they are currently under review by the core team:

Writing code that will live in a public repository and help other developers — that's different from a hackathon project that only a few judges see. That's something that persists. That compounds. Someone six months from now who's trying to migrate their Graphiti knowledge graph into Cognee might run my tutorial script and it'll just work, and they'll never know a third-year student from NIT Silchar wrote it during a five-day hackathon.

That thought is genuinely exciting to me in a way that's hard to articulate.

What I'd Tell Someone Starting With Cognee

A few things I wish I'd known on day one:

1. Install cognee[fastembed], not just fastembed. The plugin wrapper matters and the failure is silent.

2. improve() is smarter than deletion, not equivalent to it. It adds resolution context; it doesn't remove stale data. Depending on your use case, that might be exactly what you want. For an adversarial benchmark, it wasn't enough.

3. The hybrid graph-vector architecture is the real story. Most "AI memory" tools are just vector stores with a chat interface. Cognee builds an actual knowledge graph during ingestion — entities, relationships, structural connections — which means your queries can traverse semantic similarity and graph topology. That's a fundamentally different capability, not a marketing distinction.

4. Go one level below the public API. get_graph_engine() and get_vector_engine() let you inspect and manipulate the stores directly. That's where the interesting engineering lives.

Final Thoughts

Five days ago I didn't know what Cognee was.

Now I've built a benchmark that proves one of its documented failure modes, engineered a custom pruning layer that fixes it, found and documented two bugs in the process, and submitted tutorials back to the open-source repo.

I don't know if ContextRot Bench will win anything. But I know I understand AI memory systems in a way I didn't before, and I have open-source contributions on my GitHub that I'm genuinely proud of.

That feels like a good week.

ContextRot Bench is open source. The benchmark, the deep-pruning layer, and all verification scripts are available on GitHub: *Geetansh-12/cognee_hackathon*.

Built for the WeMakeDevs × Cognee Hackathon.

I Built a Relationship Intelligence CRM with Claude Code + Coral — Here's the Route

Geetansh Vikram — Sat, 30 May 2026 19:55:51 +0000

Live demo: coral-hackaton.onrender.com

Repo: github.com/Geetansh-12/coral_hackaton

Most people don't lose touch with contacts because they don't care — they lose touch because relationship data is scattered across Gmail, Slack, LinkedIn, calendar invites, and community servers. I built Coral CRM for the Pirates of the Coral-bean hackathon to show what happens when you stop treating those surfaces as separate apps and start treating them as one SQL graph powered by Coral.

This post is the reproducible route: problem → architecture → Coral capabilities → live demo → custom Discord source spec.

The problem

Relationship intelligence breaks when every channel owns a slice of context:

Gmail knows what you said
Calendar knows when you meet
Slack knows what happened in DMs
LinkedIn knows job changes
Discord knows community engagement

An AI agent can't recommend "reach out to Sarah before Thursday's meeting" if it only sees one inbox. You need a unified graph the agent can query safely.

Why Coral (not just MCP connectors)

MCP connectors are great for tool calls. Coral adds something different: SQL over APIs.

Instead of writing bespoke fetch logic for every source, Coral exposes tables you can JOIN:

SELECT c.name, c.company, c.health_score,
       g.public_repos, g.followers
FROM contacts c
JOIN github.users g ON c.github_username = g.username
WHERE c.health_score < 50;

That query runs in the SQL Explorer of Coral CRM and returns live GitHub profile data joined against local contacts — proof that federated joins aren't vaporware.

Coral also gives you:

Catalog discovery — coral.tables, coral.columns, coral.inputs
Cache/freshness observability — coral.query_log
One auth/retry/pagination layer for agent workloads

Architecture in 60 seconds

Landing / Dashboard / Explorer / AI Chat
              ↓
        Next.js API routes (/api/query, /api/chat, /api/brief)
              ↓
     Demo Mode (mock)  OR  Live Mode (SQLite + coral CLI)
              ↓
   contact_relationship_graph  ← 6 seeded sources + live GitHub/Discord

Demo Mode works with zero API keys — judges can click through immediately.

Live Mode seeds SQLite locally and spawns the real coral binary for federated queries.

Tech stack: Next.js 14, TypeScript, Tailwind, Gemini (free tier) for AI, better-sqlite3, Coral CLI.

Step-by-step: run it yourself

git clone https://github.com/Geetansh-12/coral_hackaton.git
cd coral_hackaton
npm install
npm run seed   # optional — seeds SQLite for live mode
npm run dev

Open http://localhost:3000. The app starts in Demo Mode with 34 realistic contacts.

Switch to Live Mode

Copy .env.local.example → .env.local:

DEMO_MODE=false
GEMINI_API_KEY=your_key
GITHUB_TOKEN=ghp_...
DISCORD_BOT_TOKEN=your_bot_token   # for the custom Discord source

Install the Discord source spec:

coral source lint ./sources/discord/manifest.yaml
coral source add --file ./sources/discord/manifest.yaml --interactive
coral source test discord

Coral capabilities we demonstrate (7/7)

1. SQL interface over multiple sources

Six seeded tables in sql/schema.sql: Gmail threads, Calendar events, Slack messages, LinkedIn activity, Twitter activity, Notion contacts.

2. Cross-source JOINs

The contact_relationship_graph materialized view LEFT JOINs all six on email and computes a health_score.

3. Catalog discovery

SELECT schema, table, sql_reference, source_type, freshness
FROM coral.tables ORDER BY schema;

4. Parameter hints

SELECT query, parameter, name, type, required FROM coral.inputs;

5. Cache & freshness

SELECT query_name, sources_joined, cache_hit_rate, avg_ms
FROM coral.query_log;

6. Real CLI execution

In Live Mode, /api/query spawns coral sql --format json asynchronously — no blocking the Next.js event loop on slow API calls.

7. Pluggable source architecture

Settings page shows connector diagnostics per source. We added a custom Discord source spec (see below).

The judge demo flow

Open /dashboard → click Judge Demo
Show Agent Plan and Coral Capability Cockpit
Open SQL Explorer → run the cross-source GitHub JOIN recipe
Open a contact → generate a pre-meeting brief → export it
Ask the chat agent: "What Coral capabilities does this demo use?"

Screenshots are in docs/screenshots/ in the repo.

Building a custom Discord source spec (bounty track)

Coral ships Gmail, GitHub, Slack, etc. — but Discord wasn't in the catalog. For the hackathon "Chart New Waters" track, I wrote a YAML source spec that maps Discord REST API v10 endpoints to SQL tables.

File: sources/discord/manifest.yaml

Tables exposed:

SQL table	Discord API
`discord.current_user`	`GET /users/@me`
`discord.guilds`	`GET /users/@me/guilds`
`discord.channels`	`GET /guilds/{guild_id}/channels`
`discord.messages`	`GET /channels/{channel_id}/messages`
`discord.members`	`GET /guilds/{guild_id}/members`

Auth pattern:

auth:
  type: HeaderAuth
  headers:
    - name: Authorization
      from: template
      template: Bot {{input.DISCORD_BOT_TOKEN}}

Nested JSON → SQL columns using Coral's __ convention:

- name: author__username
  expr:
    kind: path
    path: [author, username]

Validation workflow:

coral source lint ./sources/discord/manifest.yaml
coral source add --file ./sources/discord/manifest.yaml
coral source test discord

Example CRM query once installed:

SELECT author__username, content, timestamp
FROM discord.messages
WHERE channel_id = 'YOUR_CHANNEL_ID'
ORDER BY timestamp DESC
LIMIT 20;

Full docs: sources/discord/README.md

Upstream PR target: withcoral/coral → sources/community/discord/

What I learned

Start with one table. Guilds first, then channels, then messages. Run coral source test after each addition.
Nested fields need explicit expr. Don't assume author__username auto-flattens — declare the path.
Filters in URL paths use {{filter.guild_id}} — same pattern as other community specs (OSV, dbt Cloud).
Demo + Live dual mode was the right call for hackathon judges — zero friction to explore, real CLI when credentials exist.
Docker on Render beats serverless for a 150MB Coral binary — one container, authentic live URL.

What's next

Open upstream PR for the Discord source spec
Join Discord messages into contact_relationship_graph on username/nickname
OAuth device flow for Gmail/Calendar in production