DGrechko

Hi HN,

I’m building Waycore, an open-source project exploring what a flexible, offline-first field computer should look like for outdoor, survival, and off-grid scenarios.

The core goals are adaptability and resilience:

modular hardware (external sensor/tool modules)

extensible OS with support for external apps (guidelines in progress)

no required internet connection — maps, models, and knowledge work offline

optional LTE/Wi-Fi when available and explicitly enabled

A major focus is on-device agentic AI, not just chat or image recognition. The AI is intended to:

read live sensor data (GPS, compass, environment)

reason over offline knowledge

use apps and core APIs

assist with navigation, safety checks, logging, and communication

Main project repo (OS & architecture): https://github.com/dmitry-grechko/waycore

There’s also a separate repo curating freely downloadable survival & outdoor PDFs for offline use: https://github.com/dmitry-grechko/waycore-knowledge

I’m looking for feedback and contributors around:

UI/UX for rugged touch devices

hardware modularity & interfaces

offline/edge agent architectures

small models that work well without internet

high-quality public-domain or permissive survival knowledge sources

Happy to answer questions or hear critique.

Hey HN, We’re the team behind Deskree, and we just open-sourced Nanoservice TS (https://github.com/Deskree/nanoservice-ts), a TypeScript framework for building single-responsibility containerized services—aka nanoservices. Basically, if you know the pain of working with microservices, this one is for you.

A couple of years ago, we started Deskree as a BaaS product. Eventually, our tiny team of three engineers was managing 20,000 microservices. And as you might know, microservices at that scale suck to manage. Every change meant updating dozens of repos, rolling out updates across services felt like herding cats, and when something broke, it took forever to figure out where.

At some point, we figured we can create small reusable nodes, each handling just one task. No need to rewrite the same logic across multiple services, updating a node propagates changes everywhere it’s used. Add built-in monitoring and observability, trace things on a code-level and then debugging gets so much easier.

Turns out, this concept already existed. Apple and IBM have been using nanoservices internally for years, but somehow, no one ever released an actual framework for it. So, we built one.

Each nanoservice is just a function running in an isolated container. Built-in protocol for inter-service communication gives low latency, and you can run this with Docker, Kubernetes, Serverless, or anything really. Deploy as monolith or microservices, and then change it up if you need to. Built-in monitoring and observability also makes debugging easy. Adding Python library soon for AI/ML workflows.

To get started:

npx create-nanoservice my-service

Check it out, would love to know what’s broken, what’s missing and what would make it better:

GitHub repo: https://github.com/deskree-inc/nanoservice-ts

Docs: https://nanoservice.xyz/docs/d/introduction/welcome

Website: https://deskree.com

X: https://x.com/nanoservice_ts

Excited to share this with everyone here, let us know your thoughts!

Hi all,

I wanted to get community opinion on one of the thoughts I had for a long time now. I am thinking of turning my startup (https://deskree.com) open source, but it is my internal belief that contributors should be compensated for their input. As an early stage startup, fiscal compensation is tough. However, I was think about some sort of equity compensation system based on the level of contribution.

What do you think about this idea? And what might the best way to measure the contribution against the stock options in such case?