dSebastien

Haha, same

Never stopped publishing on mine (15+ years now). My blog is definitely an important source of credibility for my work, an important part of my sales funnel, and also a way for me to share ideas and grow.

Phew, my latest 3h30 workshop about Obsidian was saved. I recorded it this morning, not knowing about the Cloudflare issue (probably started while I was busy). I'm using Circle.so and they're down (my community site is now inaccessible). Luckily, they probably use AWS S3 or similar to host their files, so that part is still up and running.

Meanwhile all my sites are down. I'll just wait this one out, it's not the end of the world for me.

My GitHub actions are also down for one of my project because some third-party deps go through Cloudflare (Vulkan SDK). Just yesterday I was thinking to myself: "I don't like this dependency on that URL...". Now I like it even less

This is not the case. I've implemented many things differently.

The core of the transcription process is mostly the same and uses the same libraries, but I've rebuilt the UI from scratch to be fully responsive, added support for Wayland/Hyprland (with adaptive window size), implemented lazy loading/filtering/group by date/editing/search/filtering etc to the history screen, implemented history storage/handling differently, added more control over the history feature, added support for custom sounds, improved UX around managing sounds, added a loading screen, added support for model download pause/resume/cancel/delete etc.

These might seem like details, but it all takes time. I started this project 3 weeks ago and this is just the beginning.

In my roadmap I've listed many ideas I have in mind and will be focusing on: https://docs.voice-ai.knowii.net/roadmap

I want to go in a different direction than Handy, and my customers (who are mainly interested in Knowledge Management) too.

I never claimed this was fully original work. My project indeed started as a fork of Handy. I've discussed this here: https://github.com/DeveloPassion/knowii-voice-ai-docs/issues... and https://www.knowii.net/c/announcements/knowii-voice-ai. I also mentioned it in the user documentation (FAQ page) and About page within the app.

I am trying to approach this will full transparency, honesty and respect for what the creator of Handy did. I'm not a grifter.

Please consider that my project is still very young. I didn't include the third-party licenses in my first few releases (I honestly didn't know this about the MIT license, my bad!), but will fix this asap with the next release (hopefully coming out in a few days), and I'll pull the previous releases to avoid distributing versions that don't include the licenses. I'll also add information about the other production dependencies that I'm using.

If you look at my announcement, you'll see that I'm being fully transparent about this and am not interested in cloning Handy at all. My code is already very distant from the initial version I started with and I'm exploring and building features that will probably never be included in Handy. For instance, my app's UI has been created from scratch (with a lot of inspiration from Handy), it is fully responsive and now works on Omarchy (Hyprland/Wayland), which Handy doesn't support at the moment. I have added various features for my own needs and for my first customers (e.g., . In the roadmap of the product, you can see some of the ideas I intend to develop.

I also intend to contribute back to Handy over time. I already have and will continue to do so.

This is just not true. My landing page doesn't have much if anything in common with Handy's and that was never the goal. I stated explicitly that I forked Handy for a reason, it's not a secret and I'm not ashamed of it.

Of course, most of what my app does now is very similar to Handy, but isn't it normal when you fork something? Discrepancies grow over time, not overnight. I've already implemented many things differently, and am working on features that will probably never be in Handy anyway. I have different goals and ideas.

Some people only see evil in starting from an open source project and building something proprietary. But isn't the whole point of the MIT license to have full freedom? I love open source and I actually intend to contribute back to Handy.

People who request features from open source projects might never get what they want or need if it doesn't align with the maintainers vision or if they don't have the bandwidth. Most of the time, open source software comes without any guarantees, without any support, ... Which is perfectly fine since it all comes for free. What I'm doing is building a commercial product, with actual support, and long-term commitment to my customers.

I'm a solopreneur, working hard on the side, trying to build a sustainable business. And working on a project like this for a long time without any revenue is not sustainable unless you have enough runway. I did that a few years back and don't intend to make the same mistake again (https://www.dsebastien.net/2021-01-04-20-months-in-2k-hours-...).

As an example, I'm very focused on Knowledge Management & Obsidian. Integrating first-class support in Knowii Voice AI for interacting with Obsidian is one of the short-term goals I have in mind. It's not something that would make sense to add to Handy, it's too niche. But it does make sense for my app and my customers because many of them are also into knowledge management and have been following me for a long while.

Anyways. I'll build my project, find people who want to support my work, and do my best to deliver what they want and need. Sorry if it goes against the common ideas that forking an open source project to build something proprietary is wrong, that forks should be open source and that they should be vastly different from day one or be free.

I wrote a post with more background here: https://www.knowii.net/c/announcements/knowii-voice-ai

People who run tiny side businesses understand this is the only way to go. Yes I could have started from scratch, but what's the point.

If you look at Handy's website, you'll see that the author encourages forks anyway.

I'm also offering support for my customers and will build what they want. It's a different game.

I have already rebuilt the UI to be fully responsive (great for tiling window managers), added new features, improved the history, fixed hotkey handling for Wayland and many other things. I'm a solopreneur, and if I want my business to survive I need this endeavor to be sustainable

That's why I'm building Knowii Voice AI. It's a fork of Handy (handy.computer) in which I'm going to add fun features, exploring different areas of what we can do with voice on a computer.

It's local first, privacy first, one-time payment. You buy it and get lifetime updates.

Currently available for Windows and very soon for MacOS and Linux. I'm working on Wayland/Hyprland support because I'm using Omarchy;-)

https://voice-ai.knowii.net

I'm on the delete or archive + tag + clear trash every 3 months + export archive and delete every X team

I'm going to test this with Voice AI to see how it works compared to Whisper and Parakeet

https://voice-ai.knowii.net

I'm Building a Speech-to-text app with AI workflows. Building with Tauri, Rust, TS, React and Tailwind.

The first version is out: https://voice-ai.knowii.net

Prompt injection must be a really lucrative activity. I wonder how many hidden prompts will be detected on GitHub in the coming years and how many devs dare point LLMs at GitHub issues

Reminds me of f.lux: https://justgetflux.com/

Agreed. I just launched https://voice-ai.knowii.net and am really a fan of Parakeet now. What it manages to achieve locally without hogging too much resources is awesome

Create 2025-10-25.md. There's my perfect space for my private thoughts

Community plugins and the way they're approved and not reviewed over time due to limited resources is the main problem.

There are many facets to that. Plugins have unrestricted access, they can start servers, make http calls, read/write files ...

Plugins get approved once, but are never checked again.

And plugins are now increasing in number more rapidly, ...

What I love about those tools is that you get the best of both worlds when you use them right. If you apply auto formatting in a pre commit hook, then you can format any way you want locally but whatever is in the repo is formatted uniformly. Fewer noise in diffs and total freedom

A collection of resources about Knowledge Management

Very close to releasing V3 of my Obsidian template vault with huge improvements, first class AI support, included Bases, a solid productivity system, and a ton more.

https://obsidianstarterkit.com

I continue to hope that SOLID gains more traction in the future. It has great potential to enable a better future

The one journaling approach that has worked for me (and still does after multiple years) is interstitial journaling. It's now the very center of my personal organization system. That's how I organize my work, how I capture new things, how I organize my ideas etc. Everything goes through my daily notes (in Obsidian).

Details details: https://www.store.dsebastien.net/l/knowii-journaling-deep-di...

I'm working HARD on this problem for v3 of my Obsidian Starter Kit (https://obsidianstarterkit.com).

For now I'm keeping (and even adding!) folders because (1) AI is still not good enough at finding what it needs (2) context window is too limited with current gen LLMs and reading everything doesn't work at scale (3) few folders imply too many files in a folder, name clashes, etc.

I'll revisit that choice later, but for now my approach works, scales well and helps AI find what it needs (in general).

I've documented/shared my approach in great length in my course (https://knowledge-management-for-beginners.com), but it boils down to:

- A clearly defined set of note types (eg daily note, meeting note, literature note, etc etc)

- A specific tag for each note type

- A template for every note type (consistency for type tags + metadata)

- A root structure that combines PARA + Johnny Decimal (mostly shared across tools & platforms; not only Obsidian to reduce cognitive overhead & consistency)

- A structure that maps note types (e.g., folders for periodic notes, folder for meeting notes, etc). This works great because a note only has one type and the number of types is very limited

- Daily notes as the entry point of EVERYTHING. Every idea gets in there first

- Periodic reviews as the way to extract raw notes in daily notes into separate notes with tags, links, metadata, etc ...

I have 10+K notes and I can find almost anything in seconds. And with AI, I combine the REST API plugin with an MCP server & docs to clearly describe the note types/structure, conventions, etc. That way AI can find everything easily, create notes where they belong with the right templates, ...

With v3 of the starter kit, I'm adding new types, but most importantly, adding Obsidian Bases for all sorts of needs. This is the killer feature of Obsidian to leverage knowledge at scale. I'm busy publishing different posts about the design over here in my community: https://www.knowii.net/c/show-off-your-garden/

My goal with knowledge management is not to hoard stuff and waste time. It supports everything I do, and I intend to keep/leverage the knowledge for the rest of my life.

Also, I'm not fiddling with the system most of the time. V3 of my starter kit is the first time I do a major overhaul in the last 3 years. It's been super solid/stable. Just now, I believe there are major opportunities to better support/leverage AI, Bases and visual thinking.

I'll later revisit the structure again once the API for Bases is available, as it's going to be a huge enabler for simplifying things; cfr: https://x.com/dSebastien/status/1966456879606861883

I think that vibe coding shines bright right now when it comes to creating such little/simple tools.

Saw this posted earlier pointing to a broken site. Reminded me of this note

It's been my experience too, already prior to support for sub-tasks/agents.

I've been exploring the ways in which I could "lazy load" context depending on the task at hand. I've approached this by defining an AI "receptionist", a set of roles and a set of tasks.

The receptionist is the entrypoint of the system. It knows where to find roles/tasks but only loads very basic information about the roles.

Depending on the role I ask for, it then loads the right role file, which in turn loads additional context. Then I ask for whatever i want to do, and it loads specific task files based on what I asked. And the task files load additional context etc.

This works quite well because I end up with just the right context for the task at hand. And each role/task can actually be executed as a sub-task/agent

Knowii, a community of knowledge workers who want to stay relevant with or without AI:

https://store.dsebastien.net/l/knowii

It never stopped being a thing!! :)

A few years ago I spent an unreasonable amount of time creating a RESTful API design guide for my employer. The goal was to standardize the way APIs would be created for all systems. We argued over HATEOAS, true REST with hypermedia, custom media types, status codes etc.

We ended up with what I consider to be a solid design guide rooted in the correct use of Web standards. Not REST but RESTful. Clear and understandable, uniform, etc.

At the end of the day though the real challenge was more to make people adhere to those conventions. Why? Because most developers don't care at all. They want to finish their "Agile" sprint on time. They don't care about architecture, correctness, enterprise-wide homogeneity etc. Beyond the lack of ONE actual standard, that's the other real major problem.

https://github.com/NationalBankBelgium/REST-API-Design-Guide...