Congrats on the launch. I never understood why an AI meeting notetaker needed sota LLMs and subscriptions (talking about literally all the other notetakers) - thanks for making it local first.
I use a locally patched up whisperx + qwen3:1.7 + nomic embed (ofcourse with a swift script that picks up the audio buffer from microphone) and it works just fine.
Rarely i create next steps / sop from the transcript - i use gemini 2.5 and export it as pdf. I’ll give Hyprnote a try soon.
I hope, since it’s opensource, you are thinking about exposing api / hooks for downstream tasks.
> I never understood why an AI meeting notetaker needed sota LLMs and subscriptions
I’m the opposite: If something is expected to accurately summarize business content, I want to use the best possible model for it.
The difference between a quantized local model that can run on the average laptop and the latest models from Anthropic, Google, or OpenAI is still very significant.
registering an MCP server and calling an MCP tool upon transcript completion (and/or summary completion) would help (check out actionsperminute.io for the vision there).
Calendar integration would be nice to link transcripts to discrete meetings.
Speaking of implementation, i don’t mind if a browser extension forward cookies from my browser to the automation (privacy and security is an issue of course, and i’d ideally want the cookies to not leave my device, but personally i’m okay with some trade off).
This is really interesting. At my previous company, I built a data lakehouse for operational reporting with recency prioritization (query only recent data, archive the rest). While there was no LLM integration when I left, I've learned from former colleagues that they've since added a lightweight LLM layer on top (though I suspect Dustt's implementation is more comprehensive).
Our main requirement was querying recent operational data across daily/weekly/monthly/quarterly timeframes. The data sources included OLTP binlogs, OLAP views, SFDC, and about 15 other marketing platforms. We implemented a datalake with our own query and archival layers. This approach worked well for queries like "conversion rate per channel this quarter" where we needed broad data coverage (all 17 integrations) but manageable depth (reasonable row scanned).
This architecture also enabled quick solutions for additional use cases, like on-the-fly SFDC data enrichment that our analytics team could handle independently. Later, I learned the team integrated LLMs as they began dumping OLAP views inside the datalake for different query types, and eventually replaced our original query layer with DuckDB.
I believe approaches like these (what I had done as in house solution and what definite may be doing more extensively) are data and query-pattern focused first. While it might initially seem like overkill, this approach can withstand organizational complexity challenges - with LLMs serving primarily as an interpretation layer. From skimming the Dustt blog, their approach is refreshing, though it seems their product was built primarily for LLM integration rather than focusing first on data management and scale. They likely have internal mechanisms to handle various use cases that weren't detailed in the blog.
Point and click to navigate is pretty slow compared to keyboard driven approaches. Realized after switching to vim. Probably because, after certain point, it just the reflex which drives vim.
Can you give a bit more flavor to "not very fast"? I'm on a measly chromebook and scrolling, selecting text, expanding directories, everything is smooth and high framerate.
Is there a specific operation that is not fast? Opening it for the first time took a few seconds but afterwards it was pretty buttery.
Makepad kinda has a minimum GPU spec. It's aging-out for the people who don't have this, but some people still don't have gpu's that can bitblit their screen with a solid color.
In our org we have video tutorial for env setup, how to use tools etc. Used to use native video recorder + notion.
Now we use https://www.letsflyby.com/. It's a general purpose recording and annotation tool (which helps bookmarking a section of the video of the codebase).
The issue I faced writing JS based Server is the amount of validation that goes behind request payload. Validation includes
- if the key is present
- if the value of the key is in given range (any filter function you can imagine)
- conditional key presence (Ex: if key1 is present key2 should be less than 10)
- complex nested structure of the payload
- array validation (length / type / property)
I end up write a significant amount of if else block just to validate if the payload is acceptable. So I wrote a tool a long time back which I use in all my JS based server project (My gateway servers are always in Node for past 3-4 years because of the amount of instrumentation / ease of debugging)
I wrote helson 2 years back, where a dev would define schema of a payload
with primitive type support of str, bool, number and compound type support array, enum, ref (https://github.com/adotg/helson/blob/develop/test/helson.tes...) for type checking and custom function (strShouldNotBeEmpty, shouldBeOfMinimumLength above example) as value checking
And it tests against incoming payload
``` { url: '#/e/hash-of-a-link', tags: ['a1', 'a2', 'a3'], content: { body: 'This is a body', } ```
Now that I use typescript, I was in the verge of deciding (I don't have enough time solving just for myself as the value addition is not justified for myself, but if enough people wants it I'll build it) should I also build a typescript supported workflow. Like from a schema like above generate interfaces (and vice versa). Or is this lib meaningful to you at all.
It also throws meaningful error automatically (which you can override) to return to client directly
What I have realized over past few years, organising code for future is a function of a characteristic of an engineer.
I have noticed people who are extra organized in real life, who keeps every single file in a right directories after download tend to have inclination for prematured code refactoring for future use.
If these guys become code architect then i end up doing so many unnecessary things. The fundamental assumption of the refactoring gets changed very fast and the code needs to be rewritten for the majority of the cases.
From a company level I find the instructions are clear, mostly holding the same contract between services as long as possible and less schema change.
Its the engineer with subjective idea of perfect code / supporting future work makes it even more complex
I've seen this tendency in other areas. There are travellers who plan everything, afraid of encountering a situation that they haven't planned for. And there are travellers who trust in their ability to cope with any situation.
As the GP says, this is about fear. Fear that if you don't plan for it now, you won't be able to deal with it if it happens. Or in architecture terms, fear that your system will be faced with a requirement that it can't cover.
Trying to plan for every eventuality is usually wasted effort. Better to build robustly, and trust in your ability to adapt.
I'm only probably a month ahead of you but with my research and initial testing I've liked https://stoplight.io/open-source/prism/ so far. There are a lot of other options out there too if you are willing to make a swagger/open api spec
I hope, since it’s opensource, you are thinking about exposing api / hooks for downstream tasks.