Thanks @User @User and @User on the input. I ended up ditching the top level

archive.*

domain and just move my archived projects into

projects.archived.*

. Also removed the barely used tags hierarchy and made

projects.active.*

projects.backlog.*

, etc. I can't seem to get used to tags/backlink explorers.

nice find. i've used prosemirror in the past. do you know how editor.js stacks up against it? https://prosemirror.net/

This doesn’t answer your q but if someone does a comparison of all these ecosystems, you might also want to consider Draft.js . The API can get a bit verbose but the typescript definitions are good and like the others has a plug-in ecosystem https://www.draft-js-plugins.com/

I've asked elsewhere, but I'm really struggling with this. I just edited my workspace.code-workspace file to include this in the settings block: "dendron.dailyJournalDomain": "journal", however, when I create a new daily note, it's not using the journal schema (and associated template) am I doing this wrong?

can you run

> Diagnostics Report

and send me the output? it'll be easier to figure whats going on with the report

Does someone have a dendron.yml example where there are two vaults, and both are published, but they're separate static sites. It's not difficult to put two vaults into a single site. The difficulty is turning them into separate static sites.

If you are keeping them in a git repository, you could clone the repo into two other locations and set each one up to publish a single static site.

I'm new to Dendron. Is this documented somewhere? AFAICT, you run one Dendron instance in VSCode and control all your vaults from there. I'm not understanding how you can publish from a particular repo.

You can have multiple workspaces. So given that you have vault A and vault B, you can create a second workspace, use

vault add

to add only vault A to that workspace and set up

dendron.yml

to publish only vault A. Then you can do the same thing with vault B with a third workspace.

Thanks. I will read about workspaces.

Sorry for being a bit vague. 😅 I'm on my phone using my non dominant hand while my right hand is getting treated

Hello, just wanted to put an idea out there and see what others think: I've seen some people ask about what to do with notes they're not sure where to put in the hierarchy yet. I too would like to have the app facilitate this aspect of note-taking. A potential idea is to make all root-level titles "orphans" and "orphan subtrees". The rest of the canonical hierarchy would then explicitly prepend 'root' in their titles. Thoughts?

hmm, what would you think about covering canonical hierarchies using schemas and keeping non-canonical hierarchies "untyped"? we'll be working on improving the ergonomics of using schemas over the summer so that they'll be easier to work with

Perhaps -- in general having more tooling to support notes/ideas that are in flux is definitely desirable. (Yet I'm a fan of strict types and all warnings on. Go figure...) I'm currently thinking of ways to identify the hierarchy only from filenames (which is hacky, but doable atm). So relying on identification via schema would break that.

got it. i guess dendron is most of the way there in terms of filenames, you just need a way to tell apart "canonical" hierarchies with "non-canonical" ones

telemetry should be opt-in, not opt-out. To proceed otherwise is to invite speculation as to sinister intent

The goal of telemetry is to make data driven decisions about features and use cases that can make the most difference to our users. One way we could collect data is to conduct surveys but traditionally, these had very low participation and are also biased towards users that are already active in our community. Having telemetry allows us to collect feedback from our larger user base and avoids this bias. Opt-in telemetry, at best, gives us a narrow and biased set of users. At this point, we are back to make decisions based on limited data. Opt-out telemetry that is limited in scope is the tradeoff we made in terms of preserving user privacy while still gathering meaningful data that can help improve the product. In terms of intent, we are very clear about what data we are collecting and why we are collecting it in our telemetry docs: https://wiki.dendron.so/notes/84df871b-9442-42fd-b4c3-0024e35b5f3c.html You also don't have to take our word for it - you can inspect the source code to see where telemetry is being collected: https://github.com/dendronhq/dendron/commit/0a08e7b5e8189f958ecccb0559807659d933e4ea

The telemetry data looks very basic, so that's good

But I think

numNotes

could be risky

For performance estimation it should be enough to just send an estimate, for example 10, 100 or 1000+

Not interested in sharing my note hierarchy structure, which by design contains actionable metadata

2 red flags = moving on

no worries.

although telemetry isn't needed to get to the same ends -- it is just convenient. And monetizable.

is the code base auditable?

The full dendron codebase is readable on GH if I'm not wrong but @User will surely correct me if I'm wrong.

@User we don't collect data on your hierarchy structure @User yep. you could build dendron from the contents of the repo today

your logs do

those logs are stored locally. the only times we have access to those logs is if you message them to us. the reason we log that data is to help diagnose issues when you send us the data

right. I was faced with the chore of redacting the logs for support already