Ask HN: What do you wish someone would build?

I would like a set of handheld devices that perform these scientific readouts at or near real time with 90% accuracy:

- Offline DNA and epigentic methylation (this is almost already a thing with MinION, just not real time) [1]

- proteins, nutrients, enzymes, known and unknown chemicals found in blood, urine and stool samples

- Full spectrum breakdown of lipoprotein into particle sizes and types. (sdLDL-P, ldLDL-P, full lipid panel, A1C)

- Hormone levels in blood (All hormone types)

- Antibody tests, WBC/CD4 count, cytokines, etc..

- Preferences to set different unit measurement standards.

- Ability to export to a USB memory card in json and text output on exFAT or ext4 formatted drives.

All of this without requiring any connections to the internet. This would be for me, not a business. I suspect there are businesses that could use this too. They could submit the json output into a cloud site assuming legal compliance, etc...

Devices would be for rough preliminary screenings, to avoid repeated outsourced labs until red flags appear and to adjust dietary intake and exercise for optimal levels. Primary audience for this would likely be professional athletes, body builders, health enthusiasts, biohackers. I would pay good money for something like this. Less than 90% accuracy is fine for some tests provided it displays the estimated accuracy or range.

[1] - https://phys.org/news/2021-01-method-pocket-sized-dna-sequen...

Links to previous:

Sept 2016 - https://news.ycombinator.com/item?id=12567645

Dec 2017 - https://news.ycombinator.com/item?id=16023507

Oct 2011 - https://news.ycombinator.com/item?id=3163554

April 2016 - https://news.ycombinator.com/item?id=11592228

A generalized distributed backup system. ZFS seems like it could be a good backend for this, but the general idea would be that you have “collections” of files, and you have disks. Many collections may fit onto one disk, or maybe one collection requires many disks to hold it. The exact mechanism of storage is abstracted away from you unless you specify it manually. And then, there is a mechanism for authoring and syncing removable media like hard disks or writeable DVDs to provide backup of these files. Bonus points if you don’t need to be able to store the full collection on your main drive in order to browse/search.

Photos would be a good starting place for this, since they are easy to fingerprint.

YNAB but for actual poor people. The problem with YNAB is that it does not allow you to budget in future earnings that you “know” you will have (like salary paid on a date). The justification for this is that you should be budgeting so that you don’t rely on this. But if you are living paycheck to paycheck, you have to. The main use of budgeting in that case is to avoid overdrawing your account, since not everyone has a credit card.

I wish someone added support for sum types to Postgres. That is all.

Maybe this but only because I don't know if it makes sense https://news.ycombinator.com/item?id=25926620

Not an idea, but I wish Inbox by Google still existed. I particularly miss the intelligent "bundles".

Something like par2, but modern (Unicode, directory traversal) as a single binary (in Go or Rust?).

Id love a site that connects people capable of making good subtitles for movies and series, with people willing to pay for it.

I guess making sure the quality is high would be tricky. I imagine somehow pledging a certain amount, say $5 or $10 (or the whole amount if you want) towards the job, then the money is paid to the person who does the job, when they complete it.

It could even be a community effort. I helped translate some things on viki.com years ago, there was a huge community effort, it was great..but it seems all that work disappeared.

An open source, generic, semantically aware diff/patch toolchain.

This is a fairly big undertaking, including at least:

- A standard for representing and installing grammar information. Perhaps a file in /usr/share/grammar/ for each programming language, packaged in each language's own tools. Since not all languages are context free, the format must support more advanced grammars as well, at least indexed grammars, maybe more. Perhaps grammars should be able to depend on and extend each other (e.g. HTML can have a JavaScript node), perhaps they definitely should not.

- A new text-based diff/patch format that is less line based so that the difference can be communicated on a more semantic level, while still retaining exact reproduction i.e. B = patch(A,diff(A,B)). Add and delete should probably still be the only supported operations, but maybe not.

- A standard for representing semantic weight. The patch operation is deterministic but diff is not, i.e. given A and B, there are many possible patches that, applied to A, would correctly produce B. The job for the diff tool is to find a patch that both is guaranteed to correctly produce B, and as closely as possible describes the difference the same way a human would. Example: In Python, removal of an If condition and promotion of the contained 100 line code block should not be represented as delete 101 lines and as 100 lines. Rather, it should be represented as delete 1 line and delete 100 indents, on the correct level. The semantic weight information that allows diff to choose the best representation in most cases, might be produced using ML. Imagine a collaborative effort to produce training data using commits from open projects, where in most cases a human would simply select the patch candidate that is most easily understood. The semantic weight representation would probably have concepts for other operations than add and delete.

- The actual patch and diff tools. Patch implements only the patch format and has no dependency on grammar or semantic weight data. Diff is where the effort lies. Perhaps some languages are not best served by the generic approach with grammar and semantic weight. In these cases, diff should be pluggable. Perhaps /usr/share/diff can contain configuration for each language e.g. whether it uses a certain grammar and semantic weight file or a custom binary. It also needs some way of detecting which language to use for a certain file.

The vast majority of version control information (including git) is snapshot-based, meaning that among the many possible patches from A to B, none is preferred by the version control data. We are completely free to improve the way our tools select these patches, and it will be completely backward compatible with the existing wealth of version control history. We'd just be able to look at it with more clarity.