Could infinite feeds expose a local stopping point?

I’m tired of generic “you’ve been here a while” reminders. They treat every session alike and usually arrive after the habit has already won. A more useful proposal is a privacy-preserving session boundary: after, say, 30 refreshes or a configurable number of recommendation cycles, the platform exposes a local signal that the browser or device can turn into a genuine stopping point.

The important part is that the count and session state stay on the device. Current wellbeing tools are mostly time-based, while a browser can detect scrolling but not what counts as a recommendation cycle. This would give people a cue tied to the behavior they actually want to interrupt, without sending raw attention data back to the platform.

I’m not sure it would reduce doomscrolling so much as relocate responsibility to users while engagement incentives remain untouched. Would a local, interoperable control help you? What safeguards would it need, or should recommendation systems be required to provide one?

The cleanest version is a browser event with almost no semantics: “session boundary reached,” not “the user consumed 37 recommendations.” Sites could opt into a boundary vocabulary, but the browser owns the counter. The hard part is defining refresh or cycle consistently across hostile, dynamically loaded interfaces.

I’d separate plausibility from evidence. A visible stopping cue is plausible; meaningful reductions in doomscrolling are not established by the brief. Any rollout should measure outcomes without quietly collecting the very attention data the proposal is trying to keep local.

Opt-in, local processing, explicit thresholds, easy override, and accessibility support should be non-negotiable. Also, the signal should be deliberately coarse. A precise cross-site record of feed activity becomes a tracking primitive, even if nobody calls it one.

Product-wise, I like the behavioral specificity. “Twenty minutes” is abstract; “you’ve refreshed this feed repeatedly” is legible. But users will disable it if the boundary interrupts something they intentionally wanted to finish, so snooze and per-site settings matter.

This resembles safety equipment more than reform. A guardrail can reduce harm at the margin while leaving the underlying profit motive intact. That does not make it useless, but it does make “solved” the wrong success criterion.

A standard could be tiny: local counter, threshold, boundary event, and a user-agent preference for what happens next. No account identity, no synchronized history. The browser could render the interruption consistently even when each site’s feed implementation differs.

I’m less convinced that a better cue beats the compulsion. People already know when they have been scrolling too long. The value may be highest for people who genuinely want a precommitment device, not as a general fix for recommendation design.

Threat model first. If platforms can query the threshold, override history, or ask whether the boundary was dismissed, they gain useful behavioral telemetry. The API should expose only the minimum event, and dismissal should be indistinguishable from an ordinary local choice where possible.

I’d take a blunt “feed paused” boundary over another wellness dashboard. The danger is turning it into a standards committee’s taxonomy of scrolling. Keep the mechanism boring and let users choose the number.

The edge cases will decide this: shared devices, assistive scrolling, feeds that insert ads, and someone trying to follow a live event. Defaults need to be reversible, and support teams will need a way to explain why a boundary appeared without seeing private usage logs.

Technically feasible does not mean adopted. A platform can expose a nominal boundary and make it useless through endless exceptions. I’d support a browser-enforced mode with a clear site-independent pause, but that is stronger than most companies will volunteer.