DEV Community: Toprak

How I made it impossible for my Mac cleaner to delete the wrong thing

Toprak — Wed, 03 Jun 2026 18:21:14 +0000

Originally written for Dusty, a free, open-source macOS disk cleaner.

I kept running out of disk on a 512 GB MacBook, and I could never tell where the space went. It was always caches I had forgotten about: Xcode DerivedData, a pile of old simulators, npm and pip and gradle leftovers. The annoying part was never the cleanup. It was that every tool I tried wanted me to trust it. You press one button, a progress bar says it freed 14 GB, and you have no idea what those 14 GB were. That works right up until the day it deletes something you needed.

So I wrote my own, and the whole thing started from one rule: it should be physically unable to delete the wrong thing, even if I write a bug. This is how that rule turned into code.

Allowlist, not denylist

The usual way to make a cleaner "safe" is a blocklist: delete anything except the things on a list of protected folders. That is backwards. A blocklist is safe until you forget an entry, and you will forget an entry. The failure mode is "oops, that one wasn't on the list."

An allowlist fails the other way. It refuses to delete something it could safely have deleted. That is the side I want to fail on. So a path is deletable only if it sits inside a known, named cache directory that someone deliberately added. Everything else is rejected by default.

One door for every delete

All of the deletion logic lives in a separate Swift package with its own unit tests, not buried in the UI. Inside it there is exactly one function that every candidate path has to pass through before anything is removed: validateDeletionPath. The UI cannot delete a file. It can only ask the validator, which returns a typed Result that is either .success or a specific SafetyError. There is no path around it.

public func validateDeletionPath(
    _ path: String,
    for target: CleanupTarget,
    allowlistedRoots: [String]
) -> Result<Void, SafetyError> {
    guard allowedTargetIDs.contains(target.id) else {
        return .failure(.pathNotInAllowlist(path))
    }
    if containsPathTraversal(path) {                 // reject anything with ".."
        return .failure(.pathTraversal(path))
    }
    let standardized = (path as NSString).standardizingPath
    let url = URL(fileURLWithPath: standardized, isDirectory: true)

    if isSymlink(at: url) {                           // never follow a symlinked leaf
        return .failure(.symlinkRefusal(standardized))
    }
    if matchesProhibitedPath(standardized) {          // Documents, Photos, Mail, Keychains...
        return .failure(.prohibitedPath(standardized))
    }
    guard isPath(standardized, underAnyOf: allowlistedRoots, for: target) else {
        return .failure(.pathNotInAllowlist(standardized))
    }
    guard isPath(standardized, underAnyOfResolvingSymlinks: allowlistedRoots) else {
        return .failure(.symlinkRefusal(standardized))   // ancestor symlink defense
    }
    if !isOnBootVolume(url) {                          // no external drives, no network mounts
        return .failure(.outsideBootVolume(standardized))
    }
    return .success(())
}

Read top to bottom, that is the whole safety model. A candidate path has to survive all of it:

Known target. The cleanup target has to be one the app actually ships.
No traversal. Any path containing .. is rejected before it is even normalized.
No symlinked leaf. If the final component is a symlink, refuse it.
Not a protected folder. Documents, Desktop, Photos, Mail, iCloud, Keychains, and unnamed Application Support are out, even as parents.
Inside an allowlist root. It must descend from a registered cache directory.
Still inside after resolving symlinks. Resolve every link on both sides, then require it to still be inside that root.
On the boot volume. Same volume as your home folder, checked with statfs.

The two checks worth explaining

Protected folders are rejected even as a parent. Your home Documents, Desktop, Pictures, Photos library, Music, Movies, Mail, iCloud Drive, and Keychains are blocked, not only on an exact match:

public static let prohibitedPrefixes: [String] = [
    "Documents", "Desktop", "Pictures", "Photos Library.photoslibrary",
    "Music", "Movies", "Mail", "Mobile Documents", "Keychains",
]

Application Support is the dangerous one, because it holds both throwaway caches and real, irreplaceable data: app databases, your actual messages, project files. So Dusty refuses all of ~/Library/Application Support unless the path ends in one specific, named cache subfolder, like /Code/Cache or /Slack/GPUCache. It will never take an app's whole Application Support directory, because that is where the data you cannot get back tends to live.

Symlinks get two passes. The leaf check rejects a path that is itself a symlink. But normalizing a path does not resolve symlinks higher up, so a symlinked directory anywhere above the leaf, say a relocated ~/Library/Caches, could otherwise redirect a delete out of the allowlist. So the sixth check resolves symlinks fully on both the candidate and every allowlist root, then requires the resolved path to still live inside a resolved root. An ancestor symlink cannot smuggle a delete outside its box.

What the rules buy you in the UI

Because the engine refuses anything off the list, the app does not need a "clean everything" button, and it does not have one. It scans, sizes every path, and shows you the list before it touches a thing. You can do a dry run. When you do delete, it can move files to the Trash instead of unlinking them, so there is an undo, and it writes a log of what it removed. The scary part of a cleaner is the part you cannot see. The point here is that there isn't one.

What it doesn't do

It will not find every last gigabyte. It cleans known caches and developer leftovers, not your 40 GB of forgotten video exports sitting in Documents, because reaching into Documents is the exact thing it refuses to do. It is not a disk visualizer and not an uninstaller. If you want an aggressive "reclaim everything" tool, this isn't it, on purpose.

It is free, MIT licensed, signed and notarized. The engine and its tests are in the repo if you would rather check the claims than take my word for it.

brew install --cask yagcioglutoprak/tap/dusty

Code: https://github.com/yagcioglutoprak/dusty

If there is a cache you would want it to recognize that it does not yet, adding one is a single entry in the registry, so that is the easiest kind of contribution to take.

I built an encyclopedia of 376 psychoactive substances with Next.js and PostgreSQL

Toprak — Tue, 17 Mar 2026 00:39:21 +0000

Finding reliable information about psychoactive substances shouldn't require 15 open tabs. PsychonautWiki for pharmacology, TripSit for interactions, Erowid for trip reports, Reddit for community knowledge — I wanted one place where all of that connects.

So I built SubstanceWiki.

What it covers

376 substances with detailed profiles
15,015 interaction pairs with safety ratings
240 catalogued subjective effects across 7 categories
2,748 experience reports from real users
23,520 aggregated community posts from Reddit and forums
21 combo guides for common and high-risk combinations
10 side-by-side substance comparisons

Every substance page includes dosage tables by route of administration, duration timelines, subjective effect profiles, interaction safety data, and community context.

The tech stack

Next.js 16 with App Router and Turbopack
Prisma + PostgreSQL (hosted on Neon)
Tailwind CSS + shadcn/ui for the interface
Vercel for deployment
Dynamic sitemap generation, JSON-LD structured data on every page, and OG image support

The database schema has 11 models covering substances, effects, interactions, experience reports, articles, and community posts. Everything is cross-linked — substances link to their effects, effects link back to substances, interactions connect pairs with safety ratings.

Why harm reduction matters

People use substances whether we like it or not. Giving them accurate, complete information is how we keep them safer. Every substance page leads with safety information because that's what matters most.

The interaction checker alone covers 15,015 pairs — you can look up whether combining two substances is safe, risky, or dangerous in seconds.

Check it out

substancewiki.org

I'd love feedback on what's missing, what's confusing, or what could be structured better. This is safety-critical information, so clarity matters more than aesthetics.

I built an open-source encyclopedia of psychoactive substances with Next.js 16

Toprak — Mon, 09 Mar 2026 10:20:20 +0000

Substance information is fragmented. You need PsychonautWiki for pharmacology, TripSit for interaction charts, Erowid for experience reports, Reddit for community knowledge. I got tired of having 15 tabs open, so I built SubstanceWiki — a single, interconnected reference where everything links to everything.

Live site: substancewiki.org
Source: github.com/yagcioglutoprak/substance_wiki

The numbers

381 substance profiles with dosage guides and duration timelines
14,967 drug interaction safety ratings
240+ catalogued subjective effects
2,745 experience reports
11,698 effect-substance combination pages
~15,000 total pages generated

Tech stack

Next.js 16 with App Router and Turbopack
PostgreSQL via Prisma (11 models)
Tailwind CSS + shadcn/ui
Vercel for hosting
@vercel/og for dynamic OG images

Architectural decisions worth sharing

1. Pre-computed interactions, not runtime calculation

The interaction checker covers 14,967 substance combinations. Each pair has a safety rating (Safe, Low Risk, Caution, Unsafe, Dangerous) with detailed notes about mechanism of action.

These are pre-computed and stored in PostgreSQL — not calculated at runtime. A SubstanceInteraction model with foreign keys to both substances, indexed for fast lookup in both directions. Querying "what interacts dangerously with LSD?" is a single indexed query returning in <10ms.

2. Programmatic SEO at scale

From 381 substances and 240 effects, we generate:

381 main substance pages
762 dosage + effects sub-pages (/substances/[slug]/dosage, /substances/[slug]/effects)
11,698 effect-substance detail pages (/effects/[effect]/[substance])
28 comparison pages (/compare/lsd-vs-mdma)
11 combo safety guides
56 editorial articles

Each page has unique content, structured data (JSON-LD), dynamic OG images, and proper canonical URLs. The sitemap regenerates hourly with all 15,000+ URLs.

3. Community insights from Reddit

We process Reddit data via the Arctic Shift archive. Posts from relevant subreddits (r/drugs, r/psychonaut, r/nootropics, etc.) are classified, scored for quality, and linked to substance pages. This gives each substance a "community perspective" section with real discussions from people who've actually used it.

4. Dynamic OG images

Every page type gets a unique OG image generated via @vercel/og. This means every link shared on social media has a distinct, informative preview — not a generic site image.

5. Internal linking as an SEO strategy

Substance pages link to their effects. Effect pages link back to substances. Interactions connect pairs. Comparisons link both ways. This creates a dense web of internal links that helps both users and search engines understand the relationships between content.

6. FAQ schema for rich snippets

Each substance page dynamically generates FAQ content from the substance's data — "Is [substance] addictive?", "How long does [substance] last?", "What are the effects of [substance]?". This is wrapped in FAQPage JSON-LD schema, which can trigger FAQ rich snippets in Google search results.

Harm reduction first

Every substance page leads with safety information. The interaction checker exists because combining substances is one of the most dangerous things people do, and having that information one click away can save lives.

This isn't a project that glorifies substance use. It's a project that acknowledges people use substances and tries to give them the best information possible to stay safe.

What's next

Multilingual support (Spanish, Portuguese, German)
User-contributed experience reports
Mobile app
API for third-party integrations

Check it out at substancewiki.org and the source at GitHub. Feedback welcome — especially on accuracy of substance data, since getting this right is literally a matter of safety.

I built an open-source encyclopedia of psychoactive substances with Next.js 16 — here's what I learned

Toprak — Sun, 08 Mar 2026 09:35:35 +0000

Live site: substancewiki.org
Source: github.com/yagcioglutoprak/substance_wiki

The numbers

381 substance profiles with dosage guides and duration timelines
14,967 drug interaction safety ratings
240+ catalogued subjective effects
2,745 experience reports
11,698 effect-substance combination pages
~15,000 total pages generated

Tech stack

Next.js 16 with App Router and Turbopack
PostgreSQL via Prisma (11 models)
Tailwind CSS + shadcn/ui
Vercel for hosting
@vercel/og for dynamic OG images

Architectural decisions worth sharing

1. Pre-computed interactions, not runtime calculation

The interaction checker covers 14,967 substance combinations. Each pair has a safety rating (Safe, Low Risk, Caution, Unsafe, Dangerous) with detailed notes about mechanism of action.

These are pre-computed and stored in PostgreSQL — not calculated at runtime. A SubstanceInteraction model with foreign keys to both substances, indexed for fast lookup in both directions. Querying "what interacts dangerously with LSD?" is a single indexed query returning in <10ms.

2. Programmatic SEO at scale

From 381 substances and 240 effects, we generate:

381 main substance pages
762 dosage + effects sub-pages
11,698 effect-substance detail pages
28 comparison pages
11 combo safety guides
56 editorial articles

Each page has unique content, structured data (JSON-LD), dynamic OG images, and proper canonical URLs. The sitemap regenerates hourly with all 15,000+ URLs.

3. Community insights from Reddit

4. Dynamic OG images

Every page type gets a unique OG image generated via @vercel/og. This means every link shared on social media has a distinct, informative preview — not a generic site image.

5. Internal linking as an SEO strategy

6. FAQ schema for rich snippets

Each substance page dynamically generates FAQ content from the substance's data. This is wrapped in FAQPage JSON-LD schema, which can trigger FAQ rich snippets in Google search results.

Harm reduction first

This isn't a project that glorifies substance use. It's a project that acknowledges people use substances and tries to give them the best information possible to stay safe.

What's next

Multilingual support (Spanish, Portuguese, German)
User-contributed experience reports
Mobile app
API for third-party integrations

Check it out at substancewiki.org and the source at GitHub. Feedback welcome — especially on accuracy of substance data, since getting this right is literally a matter of safety.

I built a macOS menu bar app in ~900 lines of Python that tracks Claude + ChatGPT limits — here's how

Toprak — Thu, 26 Feb 2026 10:18:40 +0000

I got tired of getting blindsided by Claude Pro rate limits mid-session. The solution: a menu bar app that reads the same private API that claude.ai/settings/usage calls.

Here's what made it interesting to build:

The Cloudflare problem

Claude's API is behind Cloudflare. Regular requests or httpx get 403'd immediately. The fix: curl_cffi with impersonate="chrome131" to spoof the TLS fingerprint. This was the single biggest hurdle.

Browser cookie detection

Rather than making users copy-paste cookies, I used browser-cookie3 to read them directly from Chrome, Arc, Firefox, Safari, or Brave. Key insight: try Firefox first — it uses a plain SQLite database with no Keychain prompt. Chromium browsers need a one-time "Always Allow" dialog.

AppKit threading rule

rumps runs on the main thread. All UI updates (menu rebuilds) must happen there. My background fetch thread puts results in a queue.Queue, and a 0.25-second timer on the main thread drains it. Violate this and you get intermittent crashes.

Inconsistent API scale

The API returns five_hour (session) as a 0–1 fraction, but seven_day (weekly) as a 0–100 percentage. The fix: if raw > 1.0: already_pct else multiply_by_100. Spent embarrassing time debugging this.

One-line install

curl -fsSL https://raw.githubusercontent.com/yagcioglutoprak/AIQuotaBar/main/install.sh | bash

It also tracks ChatGPT usage in the same menu bar indicator.

MIT licensed, ~900 lines Python: https://github.com/yagcioglutoprak/AIQuotaBar

Happy to go deep on any of these implementation details in the comments.