Search Ideas
It’s cheap. Claude says Haiku could do this for fractions of a cent. Opus for roughly 20 cents per discussion summary.
Veritula for Programmers

Programmers already know the rule Veritula runs on. A pull request with unresolved review comments shouldn’t get merged. On Veritula, an idea is rationally adoptable only if it has no pending criticisms, and a criticism is pending if it has no pending criticisms itself. Code is an idea like any other, so you can post it, criticize it, and improve it here.
GitHub and GitLab only go so far with that rule, though. You can comment on a gist, but not on a line of it. You can comment on a line of a pull request, but not on half of one. And a thread ends when someone clicks ‘Resolve conversation’, whether or not anyone answered it. Replies in GitHub discussions can’t even be deeply nested (more on that below). Veritula, on the other hand, is built around the simple rule above. Here’s what that means for your code.
Post a snippet, beautifully highlighted
Veritula doesn’t host repositories, at least not yet. It’s for snippets: the function, pattern, or fix you want criticized, with your reasons around it. Unlike GitHub gists, Veritula snippets can be surrounded by prose. Write a sentence or two, put your code between three backticks, name its language, and post. Veritula highlights over 200 languages, numbers the lines, and adds a button to copy the code. Here’s a function to try it on:
// Calls `call` until it succeeds, waiting twice as// long after each failureasync function retry(call, attempts = 5, delay = 500) {for (let attempt = 0; attempt < attempts; attempt++) {try {return await call();} catch (error) {if (attempt === attempts - 1) throw error;await sleep(delay * 2 ** attempt);}}}function sleep(ms) {return new Promise(resolve => setTimeout(resolve, ms));}
The editor above has all the features you’ve come to know and love as a programmer. It colors code as you type, the same way the final page will: what you see is what you get. Tab indents and Shift-Tab outdents. Return keeps the line’s indentation, and indents further after an opening bracket, Ruby’s do, or Python’s colon. ⌘/ comments lines out, ⌥↑ and ⌥↓ move them, and pasted code lands at the caret’s indentation. Put your cursor next to a parenthesis or bracket and it highlights the matching one. What you write is saved as a draft as you go, and ⌘S saves it right away. Code you need to keep private can go in a private discussion, which costs a one-time USD 3.00.
Criticize code, with unmatched precision
GitHub ties a review comment to whole lines. That’s a rather blunt tool. On Veritula, you select exactly what you mean – one keyword, half an expression, or a passage across several lines – and choose ‘Criticize…’ from the menu that appears. Your criticism opens with that code quoted, in the same colors it has in the block, even if your selection starts in the middle of a string or a comment.
Once submitted, the passage is marked in the original: red for pending criticisms, gray for addressed criticisms and comments. Hover over a marked passage to see the replies that quote it; click it to go to them. Hovering over a quote does the reverse, and clicking it takes you back to the corresponding part of the code.
The retry function above, once three readers have replied: a pending criticism of how it catches errors, a comment, and an addressed criticism of its numbers.
No button resolves a criticism – the rule does, automatically
On GitHub and GitLab, a thread is resolved when someone clicks a button. Veritula has no such button. A criticism of your code stands until it’s addressed with a counter-criticism or a revision. That answer can be criticized in turn, as deep as the argument goes, and whether your code is rationally adoptable follows from the whole tree, worked out the same way at every level.
Review threads on GitHub are flat: every reply goes at the end of one list. But Veritula is deeply nested: every reply can get replies of its own, so two objections to the same answer don’t get tangled up with each other and criticisms are evaluated recursively.
Revisions that know what they addressed
When a line changes on GitHub, the comments on it are marked ‘Outdated’, whether the change addressed them or not. On Veritula, a revision is a new version, and you choose which replies still apply to it. Those carry over; the criticisms it addressed are credited in it by name, notifying their authors that their criticism led to the change. It’s like naming your reviewers in a commit message, except Veritula does it for you.
Anyone can compare the versions. For code, it’s like a git diff: the lines added and removed, the words that changed within them, and the unchanged lines folded away.
A revision addressing that criticism, compared with the version before it.
When criticisms pile up, a guide takes you through them one at a time. For each, you can address it, revise your idea, or move on for now.
Replay the argument
Each discussion is drawn as a tree beside the text, with pending criticisms in red. A timeline along the bottom of the page goes back through its history, one point for each idea and revision. Drag it back, and the page shows the discussion as it was then: the code before it was revised, and only the replies posted by that time.
The same discussion as a tree. Hollow ideas aren’t rationally adoptable: the retry function (blue) shown through several historical states, with and without pending criticisms.
Share it anywhere
Post a link to an idea with code on X, Slack, or iMessage, and its preview shows the code, highlighted:

Email notifications highlight code as well. Refer to another idea by its number, like #5114, and it links there. Your idea also shows up on the referred idea’s page, much like GitHub’s ‘mentioned this’ links.
Put money on it
Want more eyes on your code snippet? Offer a bounty for criticism, like a bug bounty: name an amount and your terms, and pay out for the criticisms you accept. Others can add their own funding to yours.
Bring your assistant
Veritula has an MCP endpoint at https://veritula.com/mcp. Add it to any coding agent that supports MCP, and it can search and read discussions. Once you sign in, it can also post ideas and replies for you. Everything it posts is properly disclosed as written with AI, automatically.
Try it here
This article is an idea like any other, so the rule applies to it too. If you think the retry function above is wrong, or anything else in this article, select it, choose ‘Criticize…’, and say why. Until someone addresses your criticism, this article isn’t rationally adoptable. The rule decides automatically. It is, in fact, simply expressed in the following code snippet:
def should_adopt? ideapending_criticisms(idea).none?enddef pending_criticisms ideacriticisms(idea).filter { |c| should_adopt?(c) }end
For more details and a discussion of this rule, see #5114:
def should_adopt? idea
pending_criticisms(idea).none?
end
def pending_criticisms idea
criticisms(idea).filter { |c| should_adopt?(c) }Big week on Veritula 🚀
✍️ A new editor: what you see is what you post.
📰 Long-form articles on your profile. Write one here.
🖼️ Pictures: drop or paste them into the editor; caption them.
💾 Drafts that save as you type and on cmd + s.
🙌 Revisions credit the critics who inspired them.
😎 Profile pictures. Set one here.
@moritz-wallawitsch has already posted his first article:

Comes to iOS Safari
Sadly, as of a recent iOS update, Apple removed the ability to trigger haptic feedback in Webkit browsers.
Should still work on Android, though.
web-haptics: Haptic Feedback Finally Comes to iOS Safari
Photo by Andrew Kliatskyi on Unsplash
lochie just published a package bringing haptic feedback to the web on iOS: web-haptics. I spent four years at Apple working mostly on UIs, so I pay close attention to design and UX. In terms of presentation, use case, and attention to detail, this package comes as close to perfect as I’ve seen.
The problem
On Android, haptics have been available through navigator.vibrate(), but iOS does not support this API. There is a workaround, though – the input element with the switch attribute:
<input type="checkbox" switch>
See this switch input in action here. On iOS, the input renders not as a regular checkbox but as a switch that can be toggled on or off:

Open the link on your iPhone, tap the switch, and you’ll feel haptic feedback. As far as I know, this is currently the only known practical workaround to trigger haptic feedback on the web in iOS.
Implementation
lochie cleverly bases his package on this single workaround and pushes it to its limits. The key lines are here, creating a switch input on the fly:
js (rendered as javascript)const hapticCheckbox = document.createElement("input");hapticCheckbox.type = "checkbox";hapticCheckbox.setAttribute("switch", "");
The package also creates an associated label and clicks it to trigger haptic feedback on the connected input:
js (rendered as javascript)this.hapticLabel.click();
(My understanding is that iOS will not trigger the haptic feedback when the input is programmatically clicked – so the ‘workaround within the workaround’ is to click the associated label instead.)
Custom haptics (!)
But web-haptics can do more than just trigger a single haptic ‘pulse’. The trigger function lets you pass in your own patterns with pulses of different duration and intensity, and even delays.
Want a simple success haptic? Trigger two pulses, as shown on the package homepage:
js (rendered as javascript)trigger([{ duration: 30 },{ delay: 60, duration: 40, intensity: 1 },])
Or simply call trigger('success') as a shortcut.
Here’s an error haptic I made based on Apple’s human interface guidelines:
trigger([{ duration: 40, intensity: 0.7 },{ delay: 40, duration: 40, intensity: 0.7 },{ delay: 40, duration: 40, intensity: 0.9 },{ delay: 40, duration: 50, intensity: 0.6 },])
lochie’s website even gives you an editor to make custom haptics. As you click and drag, both pulses and code update in real time. This experience is developer bliss:

Usage
Importing the package is easy. In Rails, for example:
# config/importmap.rbpin "web-haptics", to: "https://esm.sh/web-haptics@0.0.6"
import { WebHaptics } from 'web-haptics';// In a Stimulus controller somewherelet haptics = new WebHaptics();haptics.trigger('success'); // or 'error', 'warning', etc for built-in hapticshaptics.trigger([{ duration: 40, intensity: 0.7 },{ delay: 40, duration: 40, intensity: 0.7 },])
Pass a debug option to the constructor to hear clicks in development/on desktop:
new WebHaptics({ debug: true });
Again, this package comes as close to perfect as I’ve seen. In fact, I already use it on Veritula: as you type in a text field, an error haptic plays when you exceed the max length (#4473).
I highly recommend web-haptics by lochie.
Preference formation is a computational task. (#5255) To claim we’ve understood a computational task, we must have programmed it (Deutsch). Popper never programmed it, so he didn’t understand it. (To Popper’s credit though, he got pretty technical in defining verisimilitude, logical vs. empirical content, etc.)
Satisfying Deutsch’s yardstick means, in my professional opinion as a software engineer: writing working code to industry standards. It must compile, implement the desired feature with no known bugs, be as performant as the feature reasonably requires, have clean syntax, etc.
Not having programmed preference formation doesn’t show that Popper understood nothing about it.
#5256 doesn’t say Popper understood nothing about it. I think he understood it fairly well, far better than other philosophers, but we now understand it better today than he did.
I understand aspects of how capitalism works
Capitalism isn’t a computational task.
Again I think it depends on the test. I don’t think it’s a fundamental problem for the theoretician, more so for the applied epistemologist. But in general terms, you can just guess that one is more severe, and if nobody has a pending criticism of that guess, you can rationally go ahead with it.
I purposely avoid drinking any water past 8pm so I don’t wake up in the middle of the night having to answer nature’s call. But sometimes that still happens. How can that be?
According to this article, elevating your legs helps with fluid distribution. My understanding is that, as you get older, your body gets worse at fluid distribution. If you’re never horizontal during the day, fluid gathers in your legs. And if bedtime is the first time you’re horizontal, the fluid redistributes as you sleep, some of it gathers in your bladder, and you need to pee.
That explains why I had to use the bathroom in the middle of the night even though I don’t drink anything past 8pm. So I tried elevating my legs the next day, working from the couch for a bit in the evening. It worked! I didn’t wake up having to use the bathroom that night. (I still woke up for some other unidentified reason, but at least I can now rule out this cause.)
They can introduce subjects worth exploring further. Not every useful encounter needs to be exhaustive.
Short videos prevent the depth of explanation that long-form content can provide.
Which conflicting preferences are involved? Why assume stopping expresses the person’s real preference, rather than treating both preferences as ideas to examine?
People sometimes keep watching these feeds while also wanting to stop. That conflicts with the claim that the feed is serving their interests.
True, but serving curiosity is one way to sustain engagement. What separates engagement that serves curiosity from engagement that does not?
Recommendation engines optimize engagement and time spent, not curiosity. Engagement is not always curiosity.
Personalized short-video feeds such as TikTok, Reels and YouTube Shorts are better at serving curiosity than fixed, long-form films. They adapt to your interests instead of fixing a sequence.
I was tired of slow, bloated Spotlight.
Then it hit me: I didn’t have to wait for Apple to fix it. I could just have Claude whip up an alternative.
Meet Blink: results in under 17ms vs. up to 1,083ms for Spotlight. Free and open source.
Download and install:
See demo:

How do we decide which test is more severe? That judgment seems to do the work of forming the preference here. The criticism tree records the judgment, but what explains how we reach it?
The requirement to have ‘programmed it’ is imprecise. Would precise pseudocode count, or must it be executable code? If pseudocode fully specifies the procedure, what additional understanding does translating it into Python require?
This rules out partial understanding. I understand aspects of how capitalism works even though I couldn’t build a faithful simulation of a capitalist economy. Not having programmed preference formation doesn’t show that Popper understood nothing about it. What specific part did he fail to understand?
New on V: a guide that walks you through your rejectable ideas and helps you rehabilitate them.
Check it from time to time to ensure harmony between your thoughts and your actions.
In addition, every rejectable idea on the site now has a ‘Rehabilitate’ link to the same guiding mechanism so you can help other people rehabilitate their ideas.
Try it today: https://veritula.com/guide
New on Veritula: criticized passages get red, overlapping highlights. Comments get gray.
See at a glance which parts of an idea are problematic:

Tags on discussions would solve the same problem with less. A discussion could carry several tags, and nothing would need its own pages, moderators or membership. Subreddits come with all of that.