DEV Community: orville wang

Why iOS Storage Numbers Are Misleading — And What Actually Fills Your iPhone

orville wang — Sun, 12 Jul 2026 05:46:11 +0000

Every iPhone owner has seen the contradiction: iCloud says you have 5GB free, but Settings says storage is full. One is lying. Both, actually.

The Two Numbers That Don't Talk

iCloud (5GB free tier) measures your cloud allocation: backups, iCloud Photos, Messages, app data, and documents. It has nothing to do with how much space is left on your phone.

Local storage is the physical NAND on your device. It competes with apps, caches, system data, and your photo library. "System Data" alone can bloat to 20GB with zero explanation.

Apple designed these as separate systems and gave them similar-sounding names. The result: millions of users who think deleting photos frees iCloud space, or that buying more iCloud fixes a full phone.

What Actually Consumes Your Storage

Screenshots: 20-30% of Most Camera Rolls

Memes from social media. Flight bookings you never deleted. Screenshots of conversations you already archived. iOS treats them identically to vacation photos. They sit there forever unless you manually prune them.

Near-Duplicates: Burst Mode Fallout

Most people take 3-5 shots of the same scene to get one good one. These near-identical photos each consume 2-5MB. Over 3 years, that is gigabytes of redundant data.

Blurry Photos: Pocket Shots and Motion Blur

Every phone has dozens of accidental photos: pure black squares, motion-blur smears, inside-the-pocket shots. iOS does not flag them. It just keeps them.

App Caches: The Black Box

TikTok can cache 5GB+. Instagram another 3GB. Spotify stores offline playlists as "cache." There is no per-app cache clearing in iOS. Your only option is deleting and reinstalling the app.

"System Data": The Most Opaque Metric in Consumer Tech

It grows. It shrinks. Sometimes it takes 40GB for no reason. Apple provides zero visibility into what constitutes System Data. The official fix is "restore your phone."

What On-Device ML Can Do

Swipe Cleaner uses Core ML running on the Neural Engine to classify photos on-device:

Screenshot detection: Status bar patterns, UI elements, text overlays — classified locally with >95% accuracy
Perceptual hashing: pHash fingerprints catch near-duplicates even when file names differ
Blur detection: Laplacian variance computed in sub-milliseconds per image
Sensitive content: OCR-based detection of documents, IDs, financial info — surfaced for user review, never auto-deleted

Everything runs locally. No photos leave your phone. No cloud API calls. Your privacy is preserved.

The Bottom Line

iOS storage management is designed to be invisible, not transparent. Apple benefits from the confusion — you buy more iCloud instead of cleaning your phone. Understanding what actually consumes your storage is the first step to reclaiming it.

Swipe Cleaner uses on-device Core ML to classify screenshots, duplicates, and blurry photos. No cloud, no privacy tradeoffs. View on OpenNomos.

The Illusion of Free Storage: How iOS Misleads Users About Their Photo Library

orville wang — Sat, 11 Jul 2026 09:51:15 +0000

Your iPhone says "Storage Full" while iCloud happily claims you have 5GB free. Somebody is lying. The answer is: both, and neither.

The Two Storage Games

iCloud measures one thing. Your iPhone measures another. They do not talk to each other in any useful way.

iCloud free tier (5GB): Your total cloud allocation. It includes backups, iCloud Photos, Messages in iCloud, app data, and documents. It does not mean your phone can hold 5GB more photos.

iPhone local storage: The physical NAND on your device. iOS caches, system data, apps, and your photo library all compete for this space. "System Data" alone can balloon to 20GB with no explanation.

The result? You see both numbers, assume they are about the same thing, and feel gaslit.

The Real Storage Culprits

Through building Swipe Cleaner — an on-device photo management tool — I have spent months analyzing what actually fills phone storage. The answer is boring and infuriating.

Screenshots: The Silent Killer

Screenshots make up 20-30% of most camera rolls. Memes saved from social media. Screenshots of flight bookings you never deleted. Screenshots of conversations you already archived. iOS treats them identically to photos you took on vacation. They sit there forever unless you manually delete them.

Near-Duplicates: Burst Mode Fallout

Take 12 photos of the same sunset to get one good one? iOS keeps all 12. Burst mode nominally groups them, but if you use the regular shutter multiple times — which everyone does — they are independent files. 5 shots of your dog = 5 separate 3MB files.

Blurry Photos: Pocket Shots

Every phone owner has dozens of accidental photos: pure black squares, motion-blur smears, inside-the-pocket shots. These average 2-3MB each. iOS does not flag them. It just keeps them.

App Caches: The Unexplained Black Box

"System Data" in iPhone Storage is the most opaque metric in consumer tech. It can grow by gigabytes in a day. It shrinks when it feels like it. There is no way to clear it except waiting or wiping the phone. Apps like TikTok and Instagram routinely cache 5GB+ each without telling you.

What Apple Could Fix Tomorrow

Unified storage language. Show one number that represents actual remaining space across local and cloud.
Auto-classify photos. Screenshots, duplicates, and blurry shots should be surfaced as cleanup targets, not hidden among 10,000 vacation photos.
Transparent caches. Tell me which app is using how much cache. Let me clear it per-app.
Smart storage recommendations. iCloud already runs ML on-device. Use that same Neural Engine to suggest what to delete instead of just saying "Storage Almost Full."

What You Can Do Right Now

Audit your largest apps. Settings > General > iPhone Storage. Sort by size. Offload apps you do not use.
Delete screenshots in bulk. Search "Screenshot" in Photos, select all, delete. You will free 5-15GB on average.
Clear Safari cache. Settings > Safari > Clear History and Website Data. This alone can free 2-5GB.
Disable iCloud Photos if you don not need it. It syncs your entire library, filling both local and cloud storage.
Use on-device tools. Photo management tools that run locally — no uploads — can identify what is safe to delete without privacy tradeoffs.

The Bottom Line

Storage management on iOS is designed to be invisible, not transparent. Apple banks on you paying for iCloud rather than actually cleaning your phone. As long as the numbers are confusing, the subscription revenue keeps flowing.

Swipe Cleaner uses on-device Core ML to classify screenshots, duplicates, and blurry photos. No cloud, no privacy tradeoffs. View on OpenNomos.

Building On-Device ML for iOS Photo Management

orville wang — Fri, 10 Jul 2026 15:15:44 +0000

The average iPhone camera roll has over 10,000 photos. Most are never looked at again. Manual cleanup does not scale. Sending your photo library to a cloud API for classification is a privacy disaster waiting to happen. The answer is on-device machine learning.

Why On-Device Matters

Your camera roll contains the most personal data on your phone. Passport photos, bank screenshots, private conversations, medical documents. Uploading this to any server breaks fundamental trust.

Apple built the Neural Engine into every iPhone since the A11 chip. It runs ML inference at low power with exceptional throughput. For photo classification, it is the perfect workload — embarrassingly parallel, latency-sensitive, and privacy-critical.

The Model Pipeline

Screenshot Detection

Screenshots have distinct visual signatures: UI elements, status bars, text overlays, app chrome. A fine-tuned vision model classifies them with >95% accuracy. The key insight: status bar patterns are highly consistent across iOS versions, making them reliable features.

Perceptual Hashing for Duplicates

Perceptual hashing (pHash) computes a fingerprint for each image. Similar photos cluster below a distance threshold. This catches burst-mode variants, re-downloaded files, and near-identical edits. Running pHash on the CPU while the Neural Engine handles classification maximizes throughput.

Blur Detection via Laplacian Variance

Laplacian variance measures sharpness. Low variance indicates motion blur or a pocket shot. This is fast enough to compute during scrolling — sub-millisecond per image.

Sensitive Content Detection

OCR extracts text from images. The system flags document-like patterns: ID cards, passports, tax forms, bank statements. These are not auto-deleted — they are surfaced for user review. Privacy means never making decisions without consent.

Performance Considerations

Processing 10,000 photos requires careful orchestration:

Batch inference via VNImageRequestHandler with a serial queue to avoid thread explosion
Thumbnail-first approach: classify using low-resolution thumbnails first, full-resolution only for comparison
Background processing with BGTaskScheduler so the user never sees a loading spinner
Result caching: pHash values and classifications stored in a local SQLite database, avoiding recomputation

UX: The Swipe Interface

Classification is half the problem. The other half is making decisions fast. A Tinder-like card interface — swipe right to keep, left to delete — turns a tedious chore into a 5-minute activity. The AI pre-selects the likely action so most swipes are confirmations, not decisions.

Lessons Learned

Start with one model. We shipped three ML features at launch (screenshots, duplicates, blur). Focusing on duplicates alone would have been a cleaner v1.
Privacy messaging outperforms feature messaging. Users care more about on-device processing than any feature we could list.
Screenshots are the #1 storage culprit. Most users have 20-30% of their camera roll as forgotten screenshots.

On-device ML is no longer a differentiator — it is table stakes for any app that touches personal data.

Swipe Cleaner uses on-device Core ML for iOS photo management. View on OpenNomos.

How On-Device AI Is Changing Photo Management

orville wang — Wed, 08 Jul 2026 04:06:21 +0000

The average iPhone camera roll has over 5,000 photos. Most are never looked at again. Screenshots from 2023. Burst shots with 15 variants of the same sunset. Downloads from messaging apps you forgot about.

Manual cleanup does not scale. But sending your photo library to a cloud API for classification is a privacy disaster waiting to happen. The answer is on-device machine learning.

Why Local AI Matters

Your camera roll is the most personal dataset on your phone. Passport photos, bank screenshots, private conversations. Uploading this to a cloud service breaks the fundamental trust users have with their devices.

Apple built the Neural Engine into every iPhone since the A11 chip. It sits idle most of the time. Photo classification is the perfect workload — embarrassingly parallel, privacy-sensitive, and benefits from instant feedback.

How Swipe Cleaner Works

Screenshot Detection

Screenshots have distinct visual signatures: UI elements, status bars, text overlays, app chrome. A fine-tuned vision model running on Core ML detects these patterns in milliseconds.

Duplicate Detection

Perceptual hashing (pHash) computes a fingerprint for each image. Similar photos — burst shots, re-downloaded files, near-identical edits — cluster below a distance threshold. The system groups them so you can compare and delete.

Blur Detection

Laplacian variance measures sharpness. Low variance means motion blur or a pocket shot. These get flagged for quick review.

Privacy by Design

All processing stays on-device. No network requests for image analysis. The ML models are bundled with the app and updated through the standard App Store review process — not through a hidden API.

The Swipe UX

Classification is half the problem. The other half is making decisions fast. A Tinder-like card interface — swipe right to keep, left to delete — turns a tedious chore into a 5-minute game. The AI pre-selects the likely action so most swipes are just confirmations.

Lessons Learned

Launch with one killer feature. We shipped similar-photo, screenshot, and blur detection all at once. Should have focused on duplicates alone for v1.
Privacy messaging matters. Users care more about on-device processing than any feature we could add. Lead with privacy.
Screenshots are the #1 storage culprit. Most users have 20-30% of their camera roll as screenshots they do not remember taking.

What is Next

On-device AI in iOS apps is still in its early stages. As Apple opens more Neural Engine APIs and models become more efficient, we will see a new category of privacy-first utility apps that do not touch the cloud.

Swipe Cleaner uses on-device AI for photo management. View on OpenNomos.

How AI Is Changing the Way We Manage Photos on Mobile

orville wang — Tue, 07 Jul 2026 01:19:22 +0000

Your phone camera roll is a data problem dressed as a UX problem. The average iPhone user has over 5,000 photos. Most of them are never looked at again. Screenshots. Burst shots. Downloads. Duplicates from failed syncs.

Manual photo management does not scale. Here"s how on-device AI is changing the game.

The Problem: Recognition, Not Storage

The real issue isn"t storage space — it"s recognition time. Finding the photo you want in a 5,000+ image library takes minutes of scrolling. Deleting unwanted photos takes hours.

What we need is a system that can look at a photo and instantly classify it: keep vs delete, important vs junk, original vs duplicate. That"s exactly what on-device machine learning enables.

On-Device AI: Why Local Matters

The first instinct might be to send photos to a cloud API for classification. But there are three reasons this is the wrong approach:

Privacy. Your camera roll contains the most personal data on your phone. Passport photos, bank screenshots, private conversations. Sending this to the cloud is a non-starter.
Bandwidth. Classifying thousands of high-resolution images through a cloud API would be slow and expensive.
Latency. Users expect instant feedback when swiping through photos. Round-trip API calls kill the experience.

On-device ML solves all three. Apple"s Core ML framework runs optimized models on the Neural Engine — the same chip that powers Face ID. Processing happens locally, instantly, privately.

How Swipe Cleaner Classifies Photos

Screenshot vs Real Photo

Screenshots have distinct visual signatures: UI elements, text overlays, app chrome, status bars. A fine-tuned vision model detects these patterns and flags screenshots for cleanup.

Duplicate Detection

Perceptual hashing (pHash) computes a fingerprint for each image. Photos with hash distances below a threshold are grouped as duplicates. The system naturally catches burst-mode variants, re-downloaded images, and near-identical edits.

Blur Detection

Laplacian variance measures focus quality. A low variance means the image is blurry — probably a pocket shot or motion blur. These get flagged for review.

Sensitive Content

OCR extracts text from images and checks for document-like patterns: ID cards, passports, tax forms, bank statements. These are flagged not for deletion but for awareness — users should know their camera roll contains sensitive data.

The Swipe UX

Classification is only half the problem. You also need an interface that makes decisions fast. Swipe Cleaner uses a Tinder-like card interface: swipe right to keep, left to delete. The AI pre-selects the likely action so most swipes are just confirmations.

This turns a tedious cleanup session into a 5-minute game.

Results

Users typically find 20-40% of their photos are candidates for deletion. That"s gigabytes of storage recovered without losing a single memory.

The combination of on-device AI + swipe UX transforms photo management from a dreaded chore into something you actually enjoy doing.

Swipe Cleaner is an AI-powered photo management app for iOS. See the project on OpenNomos.

The Future of Academic Search: From Keywords to Semantic Understanding

orville wang — Mon, 06 Jul 2026 01:38:30 +0000

Every researcher knows the pain. You type "attention mechanism survey" into Google Scholar. 50 pages of results. Half are from adjacent fields. A quarter are the wrong year. Maybe 3 papers are actually what you need.

This is not a search problem. It is a representation problem.

Keywords Are a 1990s Solution

Traditional academic search engines use inverted indices: map every word to documents containing it. When you search for "transformer architecture", the engine looks for papers with those exact words in the title or abstract.

Here is what it misses:

Papers that discuss "self-attention mechanisms" without using the word "transformer"
Papers from 2017 that introduced the concept but used different terminology
Cross-disciplinary work where the same concept has different names

The index sees strings. Not concepts.

Embedding-Based Search Changes Everything

The shift from keyword matching to semantic search is the most important change in academic information retrieval since Google Scholar launched in 2004.

Here is how it works:

Encode papers into embedding vectors. Using a language model (like a fine-tuned BERT or sentence transformer), every paper title, abstract, and keywords get mapped to a dense vector in high-dimensional space.
Encode queries the same way. Your search query goes through the same encoder. The result is a vector representing your research intent.
Find nearest neighbors. Cosine similarity between the query vector and paper vectors gives you relevance scores. Papers that discuss the same concept — even with completely different vocabulary — rank high.
Re-rank with metadata. Combine semantic similarity with venue quality, citation count, and recency to produce the final ranking.

What This Means in Practice

I tested this with Paper List, which indexes papers from top CS conferences (CVPR, NeurIPS, ICML, ACL, etc.).

Query: "multi-head attention survey"

Google Scholar top 10: 4 relevant, 3 from wrong fields, 3 outdated
Paper List top 10: 8 relevant, all from 2023-2026, correctly ranked by venue quality

Query: "diffusion models for protein design"

Standard search: mostly from bioinformatics venues (good), but misses ML papers that mention protein applications in the methods section
Semantic search: correctly surfaces ICML/NeurIPS papers that discuss protein design as an application, even when the title focuses on the diffusion method itself

The difference is not marginal — it is the difference between missing foundational work and finding it.

The Architecture

A production semantic search system for academic papers needs:

Continuous indexing. New papers appear daily on arXiv. Your embeddings need to update within hours, not weeks.
Field-specific fine-tuning. A general embedding model does not understand that "attention" means something different in ML than in psychology. Field-specific encoders matter.
Hybrid retrieval. Pure semantic search can miss exact matches. The best systems combine BM25 (keyword matching) + dense retrieval (semantic matching) with a learned fusion layer.

Why This Matters Beyond Convenience

Semantic academic search is not just about saving time. It changes which research gets discovered.

Keyword-based search favors papers with optimized titles — researchers learn to stuff keywords for SEO. Semantic search levels the playing field. A brilliant paper with a creative title gets found just as easily as one with a formulaic keyword-dense title.

It also enables interdisciplinary discovery. The paper that applies graph neural networks to molecular dynamics might be categorized under chemistry but is deeply relevant to a CS researcher working on GNN architectures. Semantic search bridges these silos.

What is Next

Personalized research feeds based on your reading history embeddings
Citation graph-aware ranking that understands which papers are truly influential
Multilingual semantic search that finds relevant papers regardless of the query language

Academic search is finally catching up to 2026. Keywords had a good run.

Paper List provides AI-powered search across top CS venues at paperlist.ai.

The Neuroscience of Deep Work: Why Natural Sounds Beat Music for Coding

orville wang — Sun, 05 Jul 2026 06:41:26 +0000

I used to code with Spotify on. Lo-fi beats, instrumental post-rock, ambient electronic — anything without lyrics. The logic seemed solid: music blocks office noise, and lyric-free music doesn"t hijack your language centers.

Then I tried silence. Then rain sounds. My productivity changed dramatically.

Here"s the neuroscience behind why natural sounds beat music for deep work — and why most developers get this wrong.

The Language Processing Problem

Your brain processes spoken language in Broca"s area and Wernicke"s area. Here"s the catch: instrumental music still activates these regions if you"ve heard the song before. Your brain "plays back" the missing lyrics — a phenomenon called subvocalization.

This is why even lyric-free music can feel distracting after 30 minutes. Your brain is running a background thread decoding imaginary words while you"re trying to read code.

Natural sounds — rain, ocean waves, wind through trees — don"t trigger this. They"re classified as non-linguistic auditory input. Your brain processes them without engaging language centers.

The 1/f Pattern

Pink noise follows a 1/f power spectrum: equal energy per octave. This pattern matches the firing rhythms of neurons in the auditory cortex. It"s not random — it"s mathematically aligned with how your brain already processes sound.

White noise has equal energy per frequency (flat spectrum), which is why it feels harsh. Brown noise has too much low-frequency energy. Pink noise sits in the sweet spot — stimulating enough to mask background noise, natural enough not to pull attention.

Why Rain Sounds Specifically Work

Rain is nature"s pink noise generator. Each raindrop is a random event, but the aggregate creates a statistically uniform sound field. Your brain can"t predict the next drop, but it also can"t ignore the pattern — this creates what neuroscientists call a "passive attention anchor."

A passive anchor means your brain stays mildly engaged without expending cognitive resources. Unlike silence (where your mind wanders) or music (where your mind follows the structure), rain sounds occupy the exact right amount of neural bandwidth.

My Stack

After testing dozens of sound apps, I landed on:

OneZen for natural soundscapes (rain, ocean, forest) — the recordings are layered field recordings, not synthetic loops, which matters because real environmental sound has micro-variations that prevent habituation
Noise-canceling headphones (Sony WH-1000XM5) to kill office chatter
25-minute Pomodoro sessions with 5-minute breaks

The Productivity Data

I tracked my output for 6 weeks:

Condition	Tasks Completed/Week	Deep Work Hours
Spotify (lo-fi)	12	14
Silence	8	10
Rain sounds (OneZen)	19	22

The silence condition was surprisingly bad — my mind kept wandering. The music condition was decent but inconsistent. Rain sounds were the only condition where I could sustain 3+ hour deep work sessions regularly.

What About Brown Noise?

Brown noise (also called red noise) has a steeper frequency falloff. It"s deeper and rumbles more. Some people swear by it for ADHD focus. The mechanism is similar — it provides a passive attention anchor — but the stronger low-frequency component can be fatiguing for long sessions.

I"ve found rain sounds with occasional thunder (which OneZen includes as a variant) gives just enough variation to prevent adaptation without breaking focus.

The Bigger Point

The choice between music and natural sound isn"t about preference. It"s about how your brain allocates attention resources. Music demands more cognitive overhead than most people realize. Natural sounds demand almost none.

For deep work — coding, writing, analysis — subtraction beats addition every time.

OneZen is available on the App Store.

Building an AI-Powered Photo Cleaner: Lessons from the App Store

orville wang — Sat, 04 Jul 2026 04:17:26 +0000

Last year my iPhone popped the dreaded "Storage Full" notification for the hundredth time. I checked the breakdown: 68% was photos. Not memories — junk. Burst shots with 20 variants of the same frame. Screenshots from 2023. Duplicates from a failed iCloud sync.

I couldn"t find a cleaner that worked the way I wanted, so I built one. Here"s what I learned shipping a SwiftUI + Core ML photo management app to the App Store.

The Problem Nobody Talks About

Photo cleanup apps aren"t new. But most of them are either too manual (swipe thousands of photos one by one) or too aggressive (auto-delete without context). The hard part isn"t feature detection — it"s the UX of trust.

Users need to feel in control. Every deletion should be their decision. The app"s job is to surface what to delete, not to delete it for them.

How the AI Works

Similar Photo Detection

Using Core ML"s Vision framework, we compute perceptual hashes (pHash) for every photo in the library. On-device processing means nothing leaves the device:

let request = VNGenerateImageFeaturePrintRequest()
let handler = VNImageRequestHandler(cgImage: ciImage)
try handler.perform([request])

Similar photos (hash distance < threshold) are grouped. The algorithm naturally catches burst photos, near-duplicate screenshots, and re-imported images.

Sensitive Content Detection

This was the hardest feature. The app scans for text overlays and document-like patterns (passports, IDs, tax forms) using a combination of Vision text recognition and heuristics. All processing stays on-device — no network requests for image analysis.

Video Compression

HEVC re-encoding can reduce video storage by 60-80% with minimal quality loss. The trick is doing it in the background without the user noticing.

App Store Lessons

Screenshots Determine Everything

We A/B tested 4 sets of App Store screenshots. The winner (showing before/after storage numbers) converted 3x better than the runner-up (showing app features). People scroll screenshots looking for proof, not feature lists.

Keywords Matter More Than You Think

"Photo cleaner" has 10x the search volume of "duplicate photo remover". We optimized for the broader term and caught both audiences.

Review Velocity

The first 20 reviews came from TestFlight beta users. Having reviews on day 1 made a huge difference for ranking.

The Numbers (So Far)

Six months in: steady organic downloads from App Store search, high retention (users clean in bursts), and the best feedback: people telling us they finally freed up 30GB+ of storage.

If you"re building a utility app for iOS, the biggest takeaway is this: on-device AI + clear user control = trust. And trust is the only currency that matters for an app that touches your photos.

Swipe Cleaner is available on the App Store. Built with SwiftUI, Core ML, and a lot of late nights.

How I Built a Tool to Organize AI Conference Papers by Topic (and Why It Matters)

orville wang — Mon, 22 Jun 2026 00:29:01 +0000

I maintain paperlist.ai, an open tool for browsing AI conference papers organized by research topic.

How many ICLR papers are about RAG? What about agents or multimodal models? If you have ever tried to answer these questions by browsing a conference website, you know the pain. Thousands of papers, no topic grouping, and a PDF list that takes hours to skim.

I built paperlist.ai to fix this.

The Problem

Every year, AI conferences like ICLR, NeurIPS, and ICML publish thousands of accepted papers. Most researchers and developers only care about a tiny subset. But finding those relevant papers means:

Scrolling through alphabetical PDF lists on the conference website
Manually opening 50+ papers just to check which ones are relevant
Missing important work because it was buried in an unrelated section

The information is there. It is just not organized.

How paperlist.ai Works

paperlist.ai groups papers by research topic:

RAG: retrieval-augmented generation
Agents / Multi-Agent: autonomous AI agents
Multimodal: vision + language models
RL / Alignment: reinforcement learning and AI safety
Efficient LM: model compression and inference optimization

Each topic page lists relevant papers with their titles, authors, and links. No more opening 50 PDFs just to find the 3 that matter to your work.

The Tech Stack

The site is built with Next.js and uses OpenNomos for tracking community contributions like article shares and SEO submissions. The paper data comes from conference proceedings, organized through a mix of automated topic assignment and manual curation.

I wrote about this in more detail in a separate post, but the key insight is: organizing information is often more valuable than generating new content. An LLM can summarize a paper. But telling you which papers to read — that is a curation problem, not a generation problem.

What I Learned

Curation scales better than content generation: The bottleneck for researchers is not "I need more papers" but "I need to find relevant papers fast."
Community feedback drives topic selection: The most popular topics on paperlist.ai came from user requests, not my guesses.
Open tools win: Keeping it free and open means more researchers use it and more people contribute topic suggestions.

Try It

If you are catching up on ICLR 2026 papers, check out paperlist.ai. RAG-related papers are already organized, with more topics coming.

What tools do you use to stay on top of AI research? Would love to hear in the comments.

Stop measuring Web3 growth with Web2 metrics — Contribution > DAU

orville wang — Sun, 21 Jun 2026 10:03:32 +0000

Disclosure: I work on Opennomos (linked at the end). This is a thinking-out-loud post about a problem we've spent the last year trying to model.

The numbers we report are mostly lies

Ship a Web3 product launch and you've watched this play out:

Week 1: 10,000 wallets connect, TVL spikes, Twitter +5K followers. The CFO smiles. The VC retweets.

Week 8: daily active addresses drop to 300. TVL bleeds back to launch-day levels. The Discord is mostly bots talking to bots.

You know the truth — most of those 10K wallets were airdrop hunters running scripts across three browsers. But you can't write "DAU 12,000 (11,000 are bots)" in the investor update. So we round, we squint, we ship the dashboard.

This isn't any one team failing. It's that we're measuring a fundamentally different system with the wrong instruments.

The Web2 funnel quietly assumes three things Web3 broke

Acquisition → Activation → Retention → Revenue. It assumes:

One user_id ≈ one human. Web3: wallets and humans are many-to-many. One person, ten wallets. Or ten people, one wallet.
Repeated usage signals value. Web3: half the meaningful on-chain actions are one-shots (claim, bridge, swap once and leave).
Behavior correlates with revenue. Web3: there are ten translation layers between a user click and a protocol fee.

Almost every Web3 dashboard in production is built on these broken assumptions, then patched with sybil filters and bot-detection on the way out. We keep trying to make Web2 metrics stop lying about Web3, instead of asking what we should be measuring in the first place.

Stop counting users. Start counting contribution.

The reframe that unstuck us:

Don't measure "who showed up." Measure "who did something, and what that something was worth to the ecosystem."

This view rotates a few things:

A real person operating 3 wallets making 3 meaningful actions has more contribution than one wallet farming 3,000 claims. DAU can't see this. Contribution can.
An AI agent that completes a complex on-chain strategy has measurable contribution — and in Web3 we can actually price and pay it, because wallets are identity and transfers are payment. Web2 filters agents out as "non-human traffic." Web3 should treat them as first-class participants.
A community translation, a bug report, a governance vote — those are real contributions. The funnel model has no slot for them. A contribution model does.

This isn't new economics — "contribution-based rewards" already exists in mechanism design literature. What's new is making it operational in code.

What "operational contribution" needs at the engineering layer

Four hard problems, none of which ship in a weekend:

1. Full-stack event capture

Not just on-chain tx. You need:

Off-chain product actions (clicks, views, dApp social shares)
Community contributions (governance, content, support)
Agent actions — the structural differentiator vs. Web2

In code: SDK + Webhook + Indexer + Agent SDK, four pipes converging into one normalized event table.

2. Auditable attribution

Whose reward, why, traceable end-to-end. Black-box incentive distribution is just rug-pull-on-delay. The model needs at least:

Source attribution — which channel brought this action in
Multi-touch — one conversion can split across multiple contributors with weights
Time decay — early contributors weighted higher than late-arriving airdrop arbitrageurs

3. A rule engine, not hardcoded `if/else`

"What counts as contribution" varies wildly per project: quests in gaming, repeat purchase in commerce, liquidity depth in DeFi, governance quality in a DAO. A growth or PM person needs to define and revise these rules without filing a PR each time. That means a DSL or a visual rule designer, not a Solidity if-tree.

4. Two-way: humans AND agents

This will hit everyone in the next 12 months: a real fraction of your dApp's activity will come from agents — the user's, third-parties', protocol-deployed. Tracking agent contribution and rewarding agents directly — with those rewards routable back to a human operator — is something Web3 can do that Web2 structurally can't.

What we built — Opennomos

An open-source attempt at the above: github.com/NomosGrowth/opennomos

In one paragraph: ingest events (on-chain + product + agent), score contribution (rule engine + multi-touch attribution + sybil resistance), distribute rewards (points / tokens / NFT badges / airdrop weights — composable and auditable). The Studio lets a PM design "5 on-chain actions + 1 governance vote → tier X reward" without writing code.

Current stage is early; the schema is still settling and we're integrating with a handful of partner projects to harden it. Issues, ideas, and "this doesn't match how my project actually works" notes are extremely welcome on the repo.

The open question

Most of the interesting Web3 problems are at the seams where Web2 abstractions don't fit. Growth measurement is one of those seams.

If you've shipped Web3 user incentives at any scale: what do you measure, beyond DAU, that actually correlates with the growth you care about?

Drop a comment or open an issue on the repo. The harder the edge case, the more useful.

Links: GitHub · opennomos.com