NIP-101h Health and Fitness Data Framework - Caloric Data and Workout Intensity

This is the 2nd article I've written regarding my thoughts around the nostr health and fitness ecosystem and how something like NIP101h could play a part in enabling an ecosystem of highly specialized apps benefiting from nostr inherent interoperability. I've posted the last article on Wikistr and have continued experimenting with the NIP in a couple of clients. Recently I've been focused on extending the NIP to include calories and workout intensity.

Caloric Data

Let's talk about calories for a minute. Seems simple, right? You burn some, you consume some. But as I started implementing kind 1357 for caloric data, I quickly realized this was too simplistic.

The reality is tracking calories burned through a 10K run is fundamentally different from logging the calories in your morning avocado toast. Different contexts, different metadata, different user flows. Trying to cram both into one kind felt like forcing a square peg through a round hole.

So I split them:

• Kind 1357: Calories expended (your run, your workout, even just existing)
• Kind 2357: Calories consumed (your meals, snacks, that beer you "forgot" to log)

This wasn't just a technical decision. It reflects how people actually think about and track their health. Nobody mentally lumps "I burned 350 calories on my run" with "I ate a 650 calorie lunch" as the same type of data point. They're related but distinct.

Workout Intensity

Speaking of workouts, RUNSTR has been sending workout data for a while now, but workout intensity (kind 1356) is something I've been particularly excited about.

Why? Because intensity is the secret sauce that makes fitness data meaningful. Two people can run the same distance, but one might be casually jogging while catching up on podcasts, and another might be doing high-intensity intervals that leave them gasping for air.

Same distance, totally different physiological impacts.

Intensity gives context to duration. It turns "I worked out for 45 minutes" into a meaningful metric about how hard you pushed. And this isn't just for the fitness obsessed—it's essential for things like heart rate zone training, progressive overload, and recovery monitoring.

The Bigger Vision: Why I'm Building This

I'm not building NIP-101h because I think the world needs another fitness standard. God knows there are plenty already. I'm building it because I believe health data belongs to people, not platforms.

Right now, your Apple Health data lives in Apple's ecosystem. Your Fitbit data lives in Fitbit's walled garden. Your Strava data? Yep, siloed there too. These companies have built incredible products, but they've also created digital gulags.

Nostr gives us a chance to flip the script. What if your health data lived on the internet rather than the platform? What if you could:

• Track your runs in RUNSTR
• Encrypt sensitive data
• Store data in relays or blossom servers
• Use the data across an open ecosystem of interoperable apps

...all without asking permission from some corporate overlord?

That's pretty much the vision. I've also spun up HealthNote Relay to support some of the new NIPs and Kinds while I continue to flesh out NIP-101h.

The Power of Specialization

One thing I've realized is that the real magic happens when we get specific. A diabetes management app needs different data structures than a strength training app. But they both benefit from a common language for the overlap.

So I'm intentionally designing the NIP-101h series as a collection of highly specialized kinds rather than a monolithic standard. This lets developers pick and choose exactly what they need, while still ensuring interoperability where it matters.

Take our calorie example—by splitting into two kinds, we allow for specialized nutrition tracking apps that might never care about workout calories, while still ensuring they can talk to fitness apps when needed.

What's Coming Next

I've got a growing list of kinds I want to tackle:

• Sleep data (duration, quality, phases)
• Strength training specifics (sets, reps, weight)
• Hydration tracking
• Mental health metrics

But I'm equally excited to see what others build. Maybe someone will create specialized kinds for pregnancy tracking, or chronic illness management, or physical therapy progress.

That's the beauty of this approach—I don't need to anticipate every use case. The framework lets the community evolve it organically.

Join the Health Data Revolution

If you're a developer interested in health and fitness on Nostr, I'd love to hear from you. What kinds would help your use case? What are you building? What am I missing?

And if you're just a Nostr user who cares about your health data, check out RUNSTR (Alpha) or Npub.health (super alpha) to see what we're building.

You can find information the specification here NIP 101h.

See you in volume three, where I'll dig into NIP101h format details and share what I've learned from the early experiments.

Lets Go!