15:[[47794703,{"by":"udit99","descendants":8,"id":47794703,"kids":[47795335,47851834,47824952,47797501],"score":5,"text":"I’ve spent a year building a theory learning path that starts from scratch and goes all the way up to topics like Secondary Dominants and Borrowed Chords. It uses a combination of games, interactive lessons and spaced repetition to help you understand and remember concepts. Not just learn something new and forget it in a few days.

I’m trying to figure out:\n1. Is the progression logical?\n2. What am I missing that you’d like to see in there? \n3. Where does it get confusing and could use more clarification?","time":1776353342,"title":"Show HN: I built a music theory course with games and spaced repetition","type":"story","url":"https://www.gitori.com/themes/music-theory?showTheoryTour=true"}],[47611573,{"by":"cui511511","descendants":5,"id":47611573,"kids":[47671555,47611791,47611705,47612150],"score":4,"text":"Hi HN, I'm Edan, the creator of ElimKeys.

I've always loved ergonomic split keyboards, but I hated the desk clutter. Most splits on the market either require that annoying TRRS bridge cable between the two halves, or if they are wireless, they are often housed in bulky 3D-printed or plastic cases.

I wanted something that felt premium like a custom mechanical keyboard but was light enough to throw in a backpack. So, I built the Elytra.

A few technical details:

Truly Wireless: No cables between the halves or to the computer.

Material: CNC-machined aluminum chassis. We used a biomimetic design on the underside to shave off weight without losing structural integrity.

Weight: It weighs only 420g (0.93 lbs), which is weirdly light for a full-metal board.

Firmware: Powered by ZMK.

I would love to hear your feedback on the layout, the industrial design, or any questions about the manufacturing process. Happy to answer anything!","time":1775118707,"title":"Show HN: Elytra – A 420g CNC aluminum, wireless split keyboard","type":"story","url":"https://www.elimkeys.com/"}],[47609117,{"by":"txtsd","descendants":37,"id":47609117,"kids":[47648277,47645691,47648374,47648003,47614830,47648575,47648047,47648204,47685793,47668817,47649401,47652839,47648190,47651325,47648372,47652619,47648252,47649714,47653375,47648336,47648720,47657361,47648053,47656626],"score":36,"text":"$16","time":1775094791,"title":"Ask HN: Is there any interest in a native Qt/C++ Discord client?","type":"story"}],[47519302,{"by":"isaachinman","descendants":7,"id":47519302,"kids":[47668811,47522653,47580097],"score":6,"text":"$17","time":1774454822,"title":"Show HN: Marco, a privacy-first, offline-first email client (IMAP-native, no AI)","type":"story","url":"https://marcoapp.io/"}],[47600147,{"by":"heythisischris","descendants":4,"id":47600147,"kids":[47668803,47600688],"score":4,"text":"I've been running client email on WorkMail for a few years. When AWS announced the sunset (March 2027), they suggested switching to Zoho, Kopano, and Zoom Mail- none of which keep your data in your own AWS account.

So I'm building a replacement. inbox.camp sits on top of your existing SES, S3, and Route 53. Mail storage stays in your S3 bucket, sending/receiving goes through your SES, DNS is auto-configured in your Route 53. We're the thin client- IMAP, SMTP, and a web interface.

Stack: Hono + HTMX on Lambda for the web UI, Stalwart Mail Server (Rust, AGPL) for IMAP/SMTP/JMAP, client's own SES/S3/Route 53 for infrastructure. Cross-account IAM role for connectivity, fully revocable.\nLaunching this summer. Happy to talk architecture, answer questions, or hear why this is a terrible idea.","time":1775047807,"title":"Show HN: Inbox.camp, AWS WorkMail Replacement","type":"story","url":"https://inbox.camp"}],[47650019,{"by":"xDmytri","descendants":1,"id":47650019,"kids":[47668085],"score":2,"text":"I made a tool called `hipp` to eliminate 'chore: version bump' commits for npm packages, and I included simple content integrity as a bonus.

The idea is to keep the package.json version at 0.0.0, tag your release in git (e.g., v1.2.3), and publish.

HIPP rewrites the version on the fly and appends a signed manifest to the README with a disposable key.

Is there something I haven't thought of that makes this a bad idea? It simplifies my workflow and also provides a way to prove that what's in npm is the same as what's in git for that version. It also ensures that the person who published to npm is the same as the person who made the commit tied to that version.

No dependencies on anything other than git and npm.

TL;DR

git tag v1.0.0

git push origin main --tags

npx @dk/hipp

npx @dk/hipp verify

https://www.npmjs.com/package/@dk/hipp","time":1775400570,"title":"Ask HN: Is it time to stop putting the version in package.json?","type":"story"}],[47645025,{"by":"waveywaves","descendants":56,"id":47645025,"kids":[47648895,47647018,47646383,47645779,47663649,47648197,47647284,47647410,47648353,47645566,47654920,47657272,47657433,47646893,47646067,47652541,47647680,47645055],"score":118,"text":"$18","time":1775349618,"title":"Show HN: Contrapunk – Real-time counterpoint harmony from guitar input","type":"story","url":"https://contrapunk.com/"}],[47496652,{"by":"_alternator_","descendants":4,"id":47496652,"kids":[47496653,47522441],"score":9,"time":1774309156,"title":"Why your guitar goes sharp when you play hard: the Kirchoff–Carrier equation","type":"story","url":"https://mbmccoy.dev/posts/nonlinear-vibes/"}]]

user:	mike_strings872
created:	March 25, 2026
karma:	3