DEV Community: Arham_Q

your feedback will keep me motivated to work more

Arham_Q — Thu, 30 Apr 2026 10:49:05 +0000

Arham_Q

Apr 28

I was tired of losing track of my AI conversations, so I built a Chrome extension

#sideprojects #extensions #browser #llm

Comments

4 min read

I was tired of losing track of my AI conversations, so I built a Chrome extension

Arham_Q — Tue, 28 Apr 2026 11:31:45 +0000

TL;DR: I built Dendrite a Chrome extension that reads your live Claude and ChatGPT conversations and auto-saves every question, code block, and link into a sidebar. No copy-paste. No Notion. It just works.

The Problem Nobody Talks About (But Everyone Has)
You ask ChatGPT to write a Python function. It does. You keep chatting.
Twenty minutes later, you need that function. You scroll. And scroll. Past the small talk, the wrong answers, the “here’s a revised version,” the “actually, let me correct that.”
It’s gone. Buried. You’re now a digital archaeologist excavating your own conversation.
This happens every single day to developers using AI tools. And the worst part? The AI already did the work. You just can’t find it.
I’ve lost:
• A regex pattern for parsing dates (took 3 back-and-forths to get right)
• A CSS trick for sticky footers that actually worked
• A link to a GitHub repo the AI recommended
All buried in chat history I’ll never scroll to again.
So I stopped complaining and built Dendrite.

What Dentrite does
Dendrite is a Chrome extension that adds a collapsible sidebar to your Claude and ChatGPT tabs. As you chat, it watches the conversation and automatically extracts:
• ✅ Every question you asked
• ✅ Every code block the AI returned
• ✅ Every link that was dropped
• ✅ A running summary of the conversation
No button clicks. No copy-paste ritual. It just syncs live as the conversation updates.

How It Actually Works (The Interesting Part)
Here’s where it gets technically spicy. Claude and ChatGPT have no public API for reading conversation content. So how do you get the data out?
MutationObserver — the browser’s built-in way of watching the DOM for changes.

// Watching for new messages as they appear const observer = new MutationObserver((mutations) => { for (const mutation of mutations) { if (mutation.addedNodes.length > 0) { debounce(captureMessages, 400)(); } } }); observer.observe(document.body, { childList: true, subtree: true });

Every time a new message appears in the chat, our observer fires. We then scrape the DOM for structured content.
Extracting code blocks, for example:

function extractCodeBlocks(messageEl) { const codeBlocks = messageEl.querySelectorAll('pre code'); return Array.from(codeBlocks).map(block => ({ language: block.className.replace('language-', '') || 'text', content: block.innerText.trim(), timestamp: Date.now() })); }

And Links:

function extractLinks(messageEl) { const anchors = messageEl.querySelectorAll('a[href]'); return Array.from(anchors) .map(a => ({ href: a.href, text: a.innerText.trim() })) .filter(link => link.href.startsWith('http')); }

The tricky part? Debouncing. ChatGPT and Claude stream their responses token by token. Without debouncing, you’d capture 200 half-finished versions of the same message. The 400ms debounce lets the message finish before we snapshot it.
———
The Hardest Part: Selectors That Break
Here’s what nobody tells you about building browser extensions on top of AI chat apps: the DOM changes without warning.
One day “div.message-content” works. A frontend deploy later, it’s “article[data-testid="conversation-turn"]”. Selectors that worked Tuesday are dead by Friday.
My current approach: use multiple fallback selectors and log which one succeeds.

const MESSAGE_SELECTORS = [ '[data-message-author-role]', // ChatGPT (current) '.human-turn, .assistant-turn', // Claude (current) '.message-content', // fallback ]; function findMessages() { for (const selector of MESSAGE_SELECTORS) { const els = document.querySelectorAll(selector); if (els.length > 0) { console.debug('[Dendrite] Using selector:', selector); return Array.from(els); } } return []; }

It’s fragile by nature. That’s the cost of building on platforms you don’t control.

The Stack (Intentionally Boring)

Layer	Choice	Why
Extension API	Manifest V3	Required by Chrome Web Store
Logic	Vanilla JavaScript	Zero dependencies, instant load
UI	HTML + CSS	No framework overhead
Storage	`chrome.storage.local`	Persistent, private, no server needed
DOM Watching	MutationObserver	Only way to read live chat updates
Bundler	None	Ships as-is, no build step

Why “Dendrite”?
Dendrites are the branching receivers of a neuron — they collect incoming signals and feed them into the cell body.
That’s exactly what this extension does: it receives the signals from your AI conversations and feeds them somewhere useful.
But the name also hints at where this is going. V1 is a flat list. V2 will be a topic graph — a visual tree showing how questions across different chats connect. Ask about React in five different conversations? Dendrite will surface that pattern.

Current Limitations (Honesty Section)
I’d rather tell you now than have you find out:
• Selectors break on site updates — I patch them when I catch it, but there’s a delay
• No cloud sync — everything lives in chrome.storage.local. Close the browser, data stays. Uninstall, data’s gone.
• No Firefox support — Manifest V3 differences make it non-trivial. It’s on the list.
• Long chats get heavy — Haven’t optimized storage for 100+ message conversations ye

What I Want to Build Next
• Export to Markdown / Notion / Obsidian
• Keyword search across all saved conversations
• Topic clustering (the actual dendrite graph)
• Firefox port
• Highlight and manually save specific messages
What would you want it to track? Drop it in the comments — I’m actively building and reading every reply.

Follow Along
The extension is in active development. If you want early access or want to follow the build:
• Follow me here for V2 updates
• Comment down your thoughts it’ll be helpful

Built with zero frameworks and a lot of frustration. If you’ve ever lost a good code snippet to the AI chat void, you know why this exists.

#1 DevLog Meta-research: I Got Tired of Tab Chaos While Reading Research Papers.

Arham_Q — Sat, 25 Apr 2026 16:03:36 +0000

Every time I sit down to explore a research topic, the same thing happens.

I open arXiv for preprints. Then Semantic Scholar for citations. Then Crossref to verify a reference. Then back to arXiv because I forgot the paper I was on. Then I lose the thread entirely.

Sound familiar?

That frustration is why I started building Meta-Research an AI-powered web platform for academic literature search, analysis, and management. It's still in active development, but I wanted to share the problem it's trying to solve and what I've built so far.

The core problem

Researching a topic today means juggling:

Multiple search engines with overlapping but non-identical indexes
No way to see how papers connect to each other visually
PDFs you can read but can't talk to
No single place to save, organize, and revisit papers

The existing tools are either paywalled, too broad, or don't integrate AI in a meaningful way. I wanted one workspace that handles all of it.

What I've built so far

1. Unified search across major databases

Instead of running the same query on four different sites, Meta-Research hits them all at once, arXiv, Crossref, OpenAlex, and Semantic Scholar and surfaces results in a single view.

# Simplified example of a unified search call
def unified_search(query):
    results = []
    results += search_arxiv(query)
    results += search_crossref(query)
    results += search_openalex(query)
    results += search_semantic_scholar(query)
    return deduplicate_and_rank(results)

Each source has its own API quirks, rate limits, and response formats normalizing them into a consistent schema was one of the trickier early problems.

2. Chat with research papers using LLMs

This is the feature I'm most excited about. You can load a paper and ask it questions directly "What methodology did they use?", "Summarize the limitations", "How does this compare to X?"

Under the hood it's using Groq (Llama) and Google Gemini, depending on the task. Groq is fast for quick Q&A; Gemini handles longer context well.

def chat_with_paper(paper_text, user_question, model="groq"):
    prompt = f"""
    You are a research assistant. Based on the paper below, answer the question.

    Paper:
    {paper_text}

    Question: {user_question}
    """
    if model == "groq":
        return query_groq(prompt)
    return query_gemini(prompt)

For cases where I don't want to hit an API, I also integrated Sumy for local extractive summarization useful for quick overviews without burning tokens.

3. Citation graph visualization

This one changes how you explore literature. Instead of manually chasing citations, Meta-Research generates an interactive graph showing how papers reference each other.

You can see clusters, find highly-cited hubs, and spot gaps — papers that cite each other a lot but aren't directly connected, which often points to an interesting research gap.

It's built dynamically on the frontend using JavaScript, with the graph data computed server-side in Flask.

4. Library and collection management

Users can save papers, create named collections ("Transformer architectures", "My thesis sources"), and pick up where they left off. Auth is handled with Flask-Login, passwords hashed via Werkzeug.

@app.route('/save_paper', methods=['POST'])
@login_required
def save_paper():
    paper_id = request.json.get('paper_id')
    collection = request.json.get('collection', 'default')
    entry = SavedPaper(user_id=current_user.id, paper_id=paper_id, collection=collection)
    db.session.add(entry)
    db.session.commit()
    return jsonify({'status': 'saved'})

Tech stack

Layer	Choice
Backend	Python, Flask
Database	SQLite via Flask-SQLAlchemy
Auth	Flask-Login + Werkzeug
AI	Groq API (Llama), Google Gemini API
NLP (local)	Sumy
Frontend	HTML5, CSS3, Vanilla JS, Jinja2

I deliberately kept the frontend framework-free for now. Vanilla JS keeps the complexity low while the core features are still taking shape.

What's still rough (being honest)

The citation graph can get slow with large paper sets need to add pagination or lazy loading
Multi-source deduplication isn't perfect, the same paper from arXiv and Crossref sometimes shows up twice
The chat feature works well on shorter papers but struggles with very long PDFs due to context limits
No collaborative features yet it's fully single-user right now

What's next

Smarter deduplication using DOI matching
Streaming responses for the paper chat (so it feels faster)
A recommendation engine based on your saved papers
Maybe: export to BibTeX / Zotero

Why I'm sharing this now

Mostly because building in public keeps me accountable. And because if you've felt the same tab-switching pain, I'd love to hear what features would actually matter to you.

Follow along if you're curious.

What's the most annoying part of your research or paper-reading workflow? Drop it in the comments.

I Built a PDF Toolkit as a Student (And Deployed It for Free)

Arham_Q — Fri, 24 Apr 2026 12:23:09 +0000

Flask, PyMuPDF, Groq, and a lot of jugaad engineering

Every student has been there. It's 11 PM. You need to compress a PDF before submitting it, convert a JPEG to PDF for a form, or quickly summarize a 40-page document before an exam. You open some sketchy website, it watermarks your file, asks you to pay, and uploads your documents to who-knows-where.

I got tired of it. So I built my own.

DocFlask is an all-in-one document toolkit built with Flask. It handles PDF merging, splitting, conversion, compression, image conversion, and even AI-powered summarization and quiz generation — all for free, hosted on the internet for other broke students.

Here's the honest story of how it got built, the problems I ran into, and the "good enough" solutions I used to ship it anyway.

What It Does

Before the war stories, here's the feature set:

Merge & Split PDFs — combine multiple PDFs or split by page ranges
Convert — PDF ↔ DOCX and DOCX ↔ PDF
Compress — reduce file size for both PDFs and DOCX files
AI Summarize — structured summary from any PDF
Quiz Generator — flashcards and MCQs generated from PDF content
JPEG to PDF — batch convert up to 30 images into one PDF
Image Convert — JPEG ↔ PNG with alpha-safe handling

The Stack

Backend:     Flask
PDF engine:  PyMuPDF (fitz)
PDF→DOCX:    pdf2docx
DOCX→PDF:    python-docx + fpdf2
NLP:         sumy + nltk
AI:          Groq API
Images:      Pillow
Frontend:    Jinja2 + Vanilla JS + Tailwind CDN
Hosting:     Vercel (free)

Nothing fancy. No Docker, no Celery, no Redis. Just Flask doing Flask things.

Challenge 1: The Ghostscript Problem

PDF compression was supposed to use Ghostscript — a battle-tested tool that gives you real compression presets (low, medium, high quality). The plan was clean:

def compress_with_ghostscript(input_path, output_path, preset="ebook"):
    cmd = [
        "gs",
        "-sDEVICE=pdfwrite",
        "-dCompatibilityLevel=1.4",
        f"-dPDFSETTINGS=/{preset}",
        "-dNOPAUSE", "-dBATCH", "-dQUIET",
        f"-sOutputFile={output_path}",
        input_path
    ]
    subprocess.run(cmd, check=True)

The problem? Vercel's serverless runtime doesn't have Ghostscript installed. And installing system packages on Vercel isn't really a thing.

The jugaad: Silent fallback to PyMuPDF compression.

def compress_pdf(input_path, output_path, quality="medium"):
    try:
        compress_with_ghostscript(input_path, output_path, quality)
    except (FileNotFoundError, subprocess.CalledProcessError):
        # Ghostscript not available, fall back to PyMuPDF
        compress_with_pymupdf(input_path, output_path)

Is PyMuPDF compression as good as Ghostscript? No. Is it good enough for a student compressing a form submission? Yes. The tradeoff was acceptable for the target use case.

Lesson: Know your user. A student compressing a 5-page form doesn't need the same quality as a print shop.

Challenge 2: Async Tasks on a Serverless Platform

Summarization and quiz generation take time — sometimes 15-30 seconds depending on PDF size. My original plan used a TaskManager with background threads:

class TaskManager:
    def __init__(self):
        self.tasks = {}

    def create_task(self, task_id):
        self.tasks[task_id] = {"status": "pending", "result": None}

    def run_in_background(self, task_id, fn, *args):
        thread = threading.Thread(target=self._run, args=(task_id, fn, *args))
        thread.start()

This works perfectly on a real server. On Vercel's serverless functions? The thread gets killed the moment the initial HTTP response is sent. The polling endpoint returns nothing.

The jugaad: Switch summarize and quiz to synchronous execution on Vercel. The user waits. The UI shows a spinner. The function either completes or hits Vercel's 60-second timeout.

For small PDFs (under ~15 pages), it completes fine. For large ones, it times out. The fix? Enforce a soft page limit on upload and set honest expectations in the UI.

Not elegant. Ships though.

Challenge 3: DOCX → PDF Is Harder Than It Looks

I assumed converting a DOCX to PDF would be straightforward. python-docx reads the file, fpdf2 renders it. Simple.

It is not simple.

The combination of python-docx + fpdf2 produces acceptable output for plain text documents. The moment your DOCX has tables, custom fonts, images, or complex formatting — it falls apart. Columns collapse, fonts substitute weirdly, images disappear.

The honest truth: good DOCX→PDF conversion requires either LibreOffice (headless) or a paid API. Neither was available to me for free on Vercel.

What I did: kept the feature, documented the limitation clearly. For simple documents it works. For complex ones, the README tells users to use LibreOffice locally.

Sometimes the right answer is just being transparent about what your tool can't do.

The Async Polling Flow (For Features That Need It)

For quiz and summarize, even in sync mode, the frontend uses a polling pattern that was originally designed for async. Here's the simplified version:

async function pollStatus(taskId) {
  const interval = setInterval(async () => {
    const res = await fetch(`/api/status/${taskId}`);
    const data = await res.json();

    if (data.status === "complete") {
      clearInterval(interval);
      fetchResult(taskId);
    } else if (data.status === "failed") {
      clearInterval(interval);
      showError(data.message);
    }
  }, 2000);
}

Even running synchronously, the task ID pattern means the frontend and backend are cleanly decoupled. If I ever move to a real server with proper async, the frontend needs zero changes.

Deployment: Why Vercel (And Why It Kind Of Works)

Everyone told me to use Render or Railway for a Flask app. They're right — those platforms give you a real Linux environment with persistent processes, system packages, and no cold start issues.

But Render's free tier sleeps after 15 minutes of inactivity. Railway has usage limits. For a portfolio project targeting last-minute student use cases, I needed something that just stays up.

Vercel with a vercel.json config works for Flask if you accept the constraints:

No system packages (hence the Ghostscript fallback)
No persistent background threads (hence synchronous AI features)
60-second function timeout (hence the page limits)

For small files and quick tasks? It handles it fine. That's exactly the use case.

What I'd Do Differently

1. Use LibreOffice headless for DOCX→PDF
It produces near-perfect output. The challenge is hosting — it's a heavy dependency. But for a proper deployment, it's worth it.

2. Add explicit file size and page limits on every route
I added them on some routes (compression: 12 pages, quiz: similar). I should have added them everywhere with clear user-facing messages from day one.

3. Show compression method in the UI
When Ghostscript falls back to PyMuPDF, the user should know. Silent fallbacks that return a different quality than advertised are a trust issue.

4. Use a proper task queue
Redis + Celery or even a simple SQLite-backed queue would make the async story clean. In-memory task state means a server restart wipes all pending tasks.

Try It

Live demo: https://ihatepdf-tau.vercel.app
GitHub: https://github.com/Arham-Qureshi/I-hate-PDFs

Best for files under 10-15 pages. Free hosted, so the first load might take a moment.

Final Thought

This project taught me that shipping something imperfect but functional is better than architecting something perfect that never ships. Every "jugaad" in this codebase is a real constraint I hit, a decision I made, and a tradeoff I understood.

That's engineering. Especially when you're broke.

Built with Flask, PyMuPDF, Groq, and the spirit of jugaad. If you found this useful, drop a ⭐ on GitHub.

Tags: #python #flask #webdev #beginners

Devlog #2 — I Hate PDFs: Why I Never Save Uploaded Files to Disk

Arham_Q — Wed, 22 Apr 2026 19:56:38 +0000

If you missed Devlog #1, I built an AI-powered Quiz & Flashcard generator that turns any PDF into a quiz using Groq AI. This is what came next.

A Decision Before Writing a Single Line
When I started wiring up the file upload logic for I Hate PDFs my student-focused PDF toolkit.I had an obvious plan:
User uploads PDF → save it to disk → do the operation → return the result.

Simple. Familiar. What most tutorials show.
But before I actually wrote that code, I paused and researched a bit. The questions I had were straightforward, what happens when two users upload at the same time? Who cleans up the saved files? What if I deploy this on a server with limited storage?
That research led me to something I hadn't used before: Python's BytesIO.

What Even Is BytesIO?
BytesIO lives in Python's built-in io module. The simplest way to think about it.It's a file that exists only in memory.
It behaves exactly like a real file. You can read from it, write to it, pass it around, but it never touches your disk. The moment it's no longer needed, Python clears it automatically.
pythonfrom io import BytesIO

How I Use It in I Hate PDFs
Almost every feature in this project involves a user uploading a PDF merge, split, compress, extract text. BytesIO handles all of it without ever writing to disk.

Text extraction for the Quiz Generator:

The uploaded PDF goes straight into a BytesIO buffer, gets passed to PyMuPDF's fitz, and the text comes out no file ever saved.
Sending a processed PDF back to the user:

What's Next
The core operations and core features are coming together. Next, I’ll focus on refining the user interface and ensuring the tool is shareable, stay tuned for a live demo soon.
If you're developing an application with file uploads in Flask or any Python backend, consider using BytesIO instead of saving files to disk. This small choice can significantly enhance the cleanliness of your code from the outset.

I Hate PDFs is still evolving, building in public.
building in public. Follow along for Devlog #3.

Devlog #1- I Hate PDFs: How I Used Groq and PyMuPDF to Make an AI-Powered Quiz Maker from PDFs

Arham_Q — Wed, 22 Apr 2026 11:14:54 +0000

*****Why I Made This*
Every student has felt this way: it's late, you have a lot of reading to do, and you have an exam tomorrow. You read it once or twice, but you're not sure if you got it.
I'm working on I Hate PDFs, a PDF toolkit for students that works in a web browser. It has the usual tools like merge, split, convert, and summarize, but the one thing I wanted most was something that could test your understanding instead of just giving you information.
That's why I made a Flashcard and Quiz maker. With Groq AI, you can upload any PDF and choose how many questions you want (5, 10, or 15). The AI will make a multiple choice quiz for you in seconds.

The Feature in Action
To utilize this feature, one must upload a PDF document, select the desired number of questions, and then click on the Generate button. The application will extract the text from the PDF, process it through Groq, and subsequently produce a fully interactive quiz.

Each question is accompanied by four answer options, providing immediate feedback: a green indicator for the correct answer, a red indicator for incorrect responses, and the correct answer is displayed promptly.

The Feature in Action

To utilize this feature, users must upload a PDF document, specify the desired number of questions, and then click the Generate button. The application will extract the text from the PDF, process it through Groq, and subsequently produce a fully interactive quiz.
Each question is presented with four answer options, providing immediate feedback: a green indicator signifies the correct answer, while a red indicator denotes incorrect responses. The correct answer is displayed promptly for the user's reference.

How It Works — Step by Step
Step 1 — Extract text from the PDF

PyMuPDF's fitz is fast and reliable for text-based PDFs. It goes page by page and concatenates the content.

Step 2 — Send to Groq with a structured prompt
The prompt is the most important part. You can't just say "make a quiz" — you need to tell the model exactly what format to return, otherwise parsing becomes a nightmare.

See the text[:4000]? This is a hard trim to keep from going over the token limit. It's a known limit.

Step 3 — Parse the response
Groq occasionally provides JSON formatted with markdown, which you need to remove before parsing:

This gives you a clean Python list of question objects ready to send to the frontend.

Step 4 — Render on the frontend
Each question is shown as a card with four choices that you can click on. When you make a choice, the app compares it to the answer field and gives you feedback right away, without having to reload the page.

NOTE: Still in the development stage, will be happy to get feedback and suggestions for improvements.
I will soon tell everyone about this.

FOLLOW FOR MORE

I couldn't find a fun way to learn CPU scheduling so I built one

Arham_Q — Tue, 21 Apr 2026 07:29:35 +0000

What Happens When You Don't Find a Perfect Tool for Learning!
Start with the exact moment you got frustrated, the lecture, the textbook diagram that made no sense, or whatever it was. Personal and specific beats generic every time.

The issue
Every CS student has felt this way. Your teacher draws a Gantt chart on the board and talks about FCFS and Round Robin. You nod along as if you understand. You open your textbook, and all you see are more static diagrams.
I wanted something that I could do. Something that really showed me what was going on step by step. I looked around and couldn't find anything that didn't look like it was made in 2003.
I made it myself.

The thought
What if algorithms could battle each other? Algo Wars is a game-like CPU scheduling simulator where you can put two algorithms against each other and watch them compete in real time.

What broke first, the Gantt chart
The first version of mine loaded the Gantt chart in a static way. The whole thing just showed up at once, which ruined the point. You couldn't see the scheduling happen; you could only see the end result.
So I completely changed it. Changed the output to JSON and sent it to the chart one block at a time. It came to life all of a sudden. You could see the CPU choose which process to run next.
That one change made the whole thing seem real.

The last boss is MLQ
The Gantt chart was like a mid-level enemy, and multilevel queue scheduling was the final boss. There are multiple queues, each with its own priority and running a different algorithm at the same time. They all work together without getting in each other's way.
It took the longest to get that logic right. The best :( part of the whole build.

A peek at the piece of Code
This code show the star feature, How the two algorithms run side by side and compare the efficiency

Try it yourself
The repo is open. Feedback, bug reports, pull requests, all welcome.
Visit https://github.com/Arham-Qureshi/Algo-wars/
live: https://algo-wars-rust.vercel.app/