yonl

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 would agree to this point as well.

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.

For me, it's not very fast in chrome.

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

``` typedef Payload { str "url": pass, []str "tags": pass, bool "isCollection": pass, obj "content": { str "body": strShouldNotBeEmpty | shouldBeOfMinimumLength 15 | shouldHaveMinimumWordLength 5, }, } ```

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

Looks really polished. Great job. I didn't see any pricing in the hosted version. Are you not gonna monetize the hosted version?

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

One of the major overhead for me was writing tests. I used to get so frustrated because there are so many, so many things to mock / stub.

Do you have any suggestions for testing (Mostly service API testing) ?

You are absolutely correct the propagation for us is O(n) as the graph is directed. But the problem there is multifold. Once a node receives propagation pulse it tries to figure out the affected subset using the dimensions received as propagation pulse. This requires joining, hence a chance to build a O(mn)cartesian product. If you see https://www.charts.com/muze/examples/view/crossfiltering-wit... example the contribution bars are drawn when the first chart is dragged requires joining follower by groupBy.

Which is why performing this in browser env even for low amount of data (say 10k) is nightmare. There are ways you can address this but while in browser you hit the limit pretty soon.

We wanted the concept to be validated first hence we have build it for browser only. But would love to hear / learn / discuss with you on this before we go ahead and build the data model in server.

Another ambiguity with the interaction is visual effect of interaction. Questions like do you really want all your chart to be cross connected. A in house survey showed us there is no certainty of the answer. And what kind of visual effect should happen on interaction differs person to person and is a function of use case. Which is why we have chosen go for chosen behaviour like

``` muze.ActionModel.for(...canvases) / for all the chart in page / .enableCrossInteractivity() / allow default cross interactivity / .for(tweetsByDay, tweetsByDate) / but for first two canvas in the example / .registerPropagationBehaviourMap({ select: 'filter', brush: 'filter' }) / if selection using mouse click or brushing happens filter data / ```

we are still writing docs for this. We hope to finish all the these docs in two weeks time.

hey here is the full code starting from data loading to housing the viz on a dom node.

https://jsfiddle.net/adarshlilha/8n5a94j1/20/

Does this help?

Hey it does work on mobile. However, remember visualizations like crosstab, splom are not meant to be displayed in a space constrained area as is. There are multiple way to handle this situation. At this point of time Muze does not changes layout based on space.

The web framework fetches data, does some additional checking on data and schema, process visible code and render it. That is probably the reason you are seeing lag.

Also there are few areas where Muze performance needs to be improved. We are doing a release to address this soon.

Depends on your use case. Can you share any pointers where

- you feel you had hard time achieving with Plotly? - a feature you wanted is not supported by Plotly?

I'm glad you asked this.

So here is the thing with our DataModel. Every time you perform an ops on DataModel it create another instance. Now performing multiple such actions create a DAG where each node is an instance of DataModel and each edge is an operation.

We have auto interactivity, which propagates data (dimensions) pulse along the network. Any node which is attached to visualiztion receives those pulses and changes the visual.

So far I have not found any relational interface which exposes this DAG graph and api to user. Hence we though of building this.

Having said that, we might use some established relational interface and do the propagation ourself.

Just had a look, looks amazing.

WebAssembly is on our radar and is coming soon. But we just wanted to release a super early version of what we build so far.

It was a handwritten svg animation with d3 later enhanced using adobe illustrator.

We have used fider https://github.com/getfider/fider

Hey, we started porting DataModel (where all the data ops happens) in Scala but then put it on hold.

Will figure out the effort and roadmap and then keep you updated on the plan.

Yup cross connection could be configured using API to change the default behaviour Example: https://www.charts.com/muze/examples/view/crossfiltering-wit...

Will upload the docs for this soon.

Hey we noticed https://www.charts.com/muze/examples/view/bubble-with-tempor... is a slow one but should not as bad as you are saying. However we are making some changes for performance and gonna release in few weeks. But i’ll double check the scenarios you mentioned.

Hey I think you are Dominik (guessed from your handle). Thanks for the reply.

Vega-Lite paper and layered grammar of graphics are the biggest motivations to write Muze. Vega-Lite is still my goto viz library for my ipython and JS work. Hence there are healthy intersections between vega-lite and muze terminologies and concepts.

Would definitely love to check new development.

Makes sense. Will keep you posted on the plans.

Ahh. Will fix this.

For the time being, you can click on the play button on top right corner of the code section.

Hey, which linux distribution are you talking about? We have checked in chrome/Ubuntu and seems it works alright.

However, will make sure it gets tested with all linux dist before next release.

Are you looking for integration? > Also what is the Reactjs story here ?

Just saw plottablejs. I can make an informed comparison without using it.

However https://www.charts.com/muze/docs/composing-layers explains some part about muze's composability. And this is an example https://www.charts.com/muze/examples/view/composition-of-lay...

Apart from composable layers Muze has - tabular layout (visual crosstab) created from data facets https://www.charts.com/muze/examples/view/crosstab-chart - auto interactions https://www.charts.com/muze/examples/view/crossfiltering-wit... - Legend on any chart https://www.charts.com/muze/examples/view/gradient-legend

etc...

We had plans to move DataModel (manages all data ops) to serverside. We even have a half baked DataModel in Scala which we thought we would do it once we understand some usecase. But currently we have put it on hold.

We would love to know your - use case - number of data points - ops on data on serverside

You can mail us to eng@charts.com

So we create instance of DataModel once and then we perform operation like filtering, projection of columns, sorting etc. Everytime an operation is performed a new instance of DataModel is returned. Hence its immutable. But under the hood there is only one copy of data resides in the system shared by all instance of DataModel, for every operation we just record a formula and save it on DataModel instance. The data for that particular instance is computed on demand based on the formula. Its not a pure immutability by definition. Hence pseudo-immutable.

However, every operation does not support formula storing. Operation like joining, grouping creates new data.

We are updating the docs rapidly. All this info would be on the docs soon.

Voyager is a recommendation system based on variables characteristics present in data. User is mostly limited by the offerings of voyegar (same story of https://github.com/vega/polestar).

Vega is descriptive version of d3. We find it hard for debugging and creating complex viz.

Vega-lite is concise and more intuitive version of vega though.

However Muze was created to start directly from data, creating layout, composable layers, automatic cross interaction and a robust interaction mental model. Muze is inspired from VegaLite-InfoVis and Snap together viz paper.

yes we have also noticed that and fixing that.