RFC 42 - Self Contained Vaults

[SeriousBug]

This is the discussion for Self Contained Vaults RFC.

A summary of the discussion below as of 2022-02-15 can be found on the RFC page: Summary

[SR--]

An interesting proposal. It would be useful to see some use-cases described and some further detail.

• What relationships will be possible between vaults (only hierarchical)? Can one modify them? With what effects?
• How would one search across vaults?
• How will one refactor, especially cross-vault links for notes and assets?
• How will the conversion from the current system work?
• How will this affect publishing?

[SeriousBug]

What relationships will be possible between vaults (only hierarchical)? Can one modify them? With what effects?

Vaults can only include other vaults, so it's hierarchical. What I'm thinking of is the same as what's possible right now with "Workspace Vaults", but you can get rid of the unnecessary workspace. You can modify them, or use them however you use existing vaults.

How would one search across vaults?

Same as how vaults work right now. You can use lookups or use the VSCode search.

How will one refactor, especially cross-vault links for notes and assets?

Again, same as all the existing functionality. You can move notes and assets between vaults, none of that changes.

How will the conversion from the current system work?

That I'm not sure about. Conversion would require moving and changing a lot of files, so it's not something we want to do automatically. We might need to keep supporting the existing workspaces&vaults for a while, and give a "convert to self contained vault" command to do the conversion.

How will this affect publishing?

This will make publishing easier if anything, because it will now be possible to publish any vault you have by itself without publishing other vaults. Right now if you want to publish a single vault, you need to turn that vault into a workspace vault to be able to use the dendron commands with that vault. But there's no automatic or even easy way of doing that conversion, and the feature is pretty buried in the documentation.

[SR--]

Thanks @SeriousBug

But how would two separate vaults know about each other for the lookup (etc) to work across them if there is no workspace with the conguration file that lists them as belonging together?

[SeriousBug]

All vaults, including ones that we found transitively, will get added to the dependencies folder and they will all be locally available, as if you had added them to the vaults part of your configuration. While they are not actually listed under Vaults, Dendron will discover and load them by looking at the configuration files of the vaults that are listed.

[kevinslin]

dendron.code-workspace # optional

While its optional, I would still include it by default on every vault. This is because vscode is our main client and if other users open the vault using vscode, we can add dendron as a recommended extension so that they can actually navigate properly

Dendron, during initialization, will pull in any vaults that this vault depends on, whether directly or transitively. These vaults should be stored in a dependencies folder inside this vault.

What is the folder called? can you add it to the layout diagram in the RFC? how do we deal with collisions? (eg. I publish a vault named foo and you publish a vault named foo)

The local vaults will not be included in the repository for the dependent vault: each repository can only contain one vault.

Can you elaborate on how local vaults will be handled? Will they live inside the dependencies folder inside the vault (eg. copied or symlinked over)?

Dendron should warn the user if the top level vault is a remote vault, but it contains local vaults inside it. This warning can be shown when converting a vault, and also at least once during initialization.

This is if you pull in a vault that depends on a local vault?

[SeriousBug]

While its optional, I would still include it by default on every vault.

Agreed, we can create it by default but leave it optional. This would also eliminate the split between code and native workspaces. Users can just open it with or without the code-workspace.

What is the folder called? can you add it to the layout diagram in the RFC?

Added an example to the RFC.

how do we deal with collisions?

I hadn't thought of that actually. Looking at how go handles this, they store dependencies like github.com/gorilla/mux@v1.8.0/ which I think we can also do. Added a better explanation of that to the RFC as well.

Can you elaborate on how local vaults will be handled? Will they live inside the dependencies folder inside the vault (eg. copied or symlinked over)?

They will live entirely in the dependencies folder, not copied or symlinked anywhere. This is okay as long as the user is not trying to share the top-level vault that contains this. if they do, we can warn them that these vaults won't be included in what they are sharing. I think this is actually good because it allows users to easily share their entire workspace while still keeping a vault secret.

This is if you pull in a vault that depends on a local vault?

No, if your top-level vault (your workspace) includes a local vault, and you are trying to share your top-level vault. The local vault won't be included in this, so we can warn the user that it won't be included.

[ScriptAutomate]

+1 on dendron.code-workspace included by default

[kevinslin]

Also, can we apply the full RFC template to the RFC doc? [[RFC|dendron://dendron.dendron-site/templates.rfc]]

[SeriousBug]

What's the document missing from the RFC template? Or are you referring to the incomplete sections? I'm still working on the RFC

[kevinslin]

got it - could you mention that in the RFC? (eg. still work in progress, kind of like a draft pr)

[SeriousBug]

There's a warning right at the top 😅

"This proposal is currently a draft and is not yet finalized."

[kevinslin]

ah, i’m blind 🥲

[kevinslin]

Also - how will we support mixing and matching vaults depending on use case?
Do we want to support vaults that are similar to vscode's extension packs: https://code.visualstudio.com/blogs/2017/03/07/extension-pack-roundup ? That is to say, they are a vault with no notes but just define a list of other vaults that work well together?

[SeriousBug]

We can make the notes optional, which would allow collections of vaults without any notes in it. Adding that to the RFC.

[ghost]

Greetings,

Since this would affect Native Vaults in some way, I would like to ask if the following would be possible:

I have a Native Vault in Project A:

.   Project A                                                    
+-- docs                                             
|   +-- Native Vault content 
+-- project folders
|   +-- Dendron unrelated stuff
+-- Workspace.code-workspace
+-- more unrelated files

And I have a Native Vault in Project B:

.   Project B                                                   
+-- docs                                             
|   +-- Native Vault content 
+-- project folders
|   +-- Dendron unrelated stuff
+-- Workspace.code-workspace
+-- more unrelated files

Could I add the Vault from Project A as a dependent for Project B?
If Project A is a Library that Project B uses?
Would Project B need to check out the full Project A?
Or Partially only Checkout the folder that contains the Native Vault?
Autodetection or Manually telling dendron that the Vault that should be added is inside folder xyz

Or another case We have a Monorepo with the following structure:

.   Monorepo A                                                    
+-- docs                                         
|   +-- Native Vault content 
+-- Components 
|   +-- A
|   |   +-- docs
|   |   |   +-- Native Vault content 
|   |   +-- Dendron unrelated stuff
|   +-- B
|   |   +-- docs
|   |   |   +-- Native Vault content 
|   |   +-- Dendron unrelated stuff
+ -- Workspace.code-workspace
+ -- more unrelated files

Could I Add the Vaults of the Components A and B to the Vault of the Overall Monorepo?
Would this be done through symlinks or would I need to place the Vaults of the Components into the Vault of the Monorepo with a hierarchy indicating what they are part of?

I Hope what I wrote makes at least some form of sense for someone besides my brain, if you have further questions feel free to ask.

[SeriousBug]

Thanks for looking over the RFC!

Could I add the Vault from Project A as a dependent for Project B?

You could, but that would mean cloning the entire Project A into Project B. To only check out the documentation, you would want to create a remote vault and then add that as a dependency to both A and B.

Could I Add the Vaults of the Components A and B to the Vault of the Overall Monorepo?

The components here would be in the same repository as the monorepo right?

I think in that case the right way to go would be to create their own repos for these vaults, then add them as dependencies to the native vault at the root of the monorepo. They will automatically get pulled in for anyone that opens the workspace and has Dendron installed, and can be synced with "Dendron: Workspace Sync".

I can see how that might not fit all use cases though. Relaxing the requirements on how the vaults should work might be necessary to allow setups like this if you want all the documentation in the monorepo as well.

[ghost]

For the Adding of Project A Vault to Project B, Git Sparse Checkout could be something to look into, to remove the need to clone the full Project.

Could it work per Symlinks for the Monorepo situation?

Either per manual creation or Telling dendron to create Symlinks for it?
Dendron first would need to be able to handle Symlinks to handle this way of doing it.

[kevinslin]

I can see how that might not fit all use cases though. Relaxing the requirements on how the vaults should work might be necessary to allow setups like this if you want all the documentation in the monorepo as well.
For the Adding of Project A Vault to Project B, Git Sparse Checkout could be something to look into, to remove the need to clone the full Project.

I see different ways we could make this work. I would save this for a phase II though, and not have it be part of the initial launch.

[kevinslin]

The current vault is called the dependent vault, and the vaults listed are called depended vaults. Depended vaults may have their own dependencies.

For new concepts, can we have a section called # Concepts that lists out new terms introduced?

Read-only vaults

Should be added as a concept. Can we have an example of what this looks like?

Migration

What do we do for people that don't want to upgrade? Do we support the legacy vault format forever? Or do we do a cutoff date?

Dendron adds support for self contained vaults, but largely hides the feature from users. Self contained vaults will maintain backwards compatibility with existing vaults (e.g. a self contained vault can list an old vault as a dependency).

At this phase, can users create self contained vaults? Would it be part of initialize workkspace?

Dendron will start creating new vaults as self contained vaults, and offer a command to convert existing vaults into self contained vaults.

What are the details of converting into this format?

With self contained vaults, the configuration for a vault that is being published can be changed without changing the configuration for the workspace. Changing the editor settings can also be done by creating a new vault, and adding the other vault as a dependency.

Ideally, to support editor configuration changes we will support a local override that is outside of version control. Eg. editor.loca.json. Might fall outside of the scope of this RFC but just wanted to emphasize that creating a new vault should not be needed to support custom editor configuration

Name conflicts with dependencies and x-vault wikilinks

Today, xvault link is dendron://{vaultName}/{filename}. I wonder if we shouldn't update this format to be destination specific?

Eg: dendron://github.com/@dendronhq/dendron-docs@main/{filename}

Might be a little unwieldly. The other solution is import maps -> https://deno.land/manual/linking_to_external_code/import_maps

---

Some questions that I wasn't too clear on.

1. What would "Workspace Sync" do in a self contained vault?

Lets say we make org-private into a self contained vault. When I run workkspace sync, does it sync all my dependencies? This would be necessary in the Dendron internal use case where we do want that beahvior.
But this would not be wanted in the regular use case. Maybe this is where marking a vault as readonly will be helpful?

org-private/
| notes
| dependencies/
|  ├── github.com
│  ├── dendronhq
│  │  ├── dendron-docs@main      # depends on github.com/dendronhq/dendron-docs, on main branch
│  │  └── dendron-site@master    # depends on github.com/dendronhq/dendron-site, on master branch
│  └── SeriousBug
│     └── recipes@3e497db338f0f  # depends on github.com/SeriousBug/recipes, targeting a specific commit
├  |── gitlab.com
│  └── example
│     └── vault@main   

[kevinslin]

Yes it would. It would even sync them if they are marked read only.

I think right now, its hard to predict what the expected behavior should be. By default, can we have no sync on dependencies? Then we can see what people do.

[ScriptAutomate]

I think, in the case of x-vault links, that we could use either generated IDs or remote git vault location paths - as suggested. If going the generated IDs route, could have VS Code / Dendron render the link to show the vault name? Kind of like how task notes add extra info (owner, status, etc.)?

[SeriousBug]

Dendron render the link to show the vault name

Yes, we could even overlay the rendered text over the actual link I believe. You just hide the overlay when the link is selected so the user can edit the link.

My concern is that it makes Dendron flavored markdown hard to work with outside of Dendron, but maybe that's an acceptable tradeoff.

[SeriousBug]

Can we launch self contained vaults under the preview flag with lots of caveats and warnings?

That makes sense, I was thinking of converting our internal vaults so we can test but we should let everyone help us test too if they want to.

By default, can we have no sync on dependencies?

Sure, we can start with sync: skip by default then iterate on it.

[SeriousBug]

Might be a little unwieldly. The other solution is import maps -> https://deno.land/manual/linking_to_external_code/import_maps

I think I came up with an elegant solution for import maps: allowing vaults to override the dependency settings for transitive dependencies.

For example, say vault A depends on vault B, and vault B depends on vault C. The owner/user of vault A can add vault C as a dependency to vault A, then change the settings such as vault name.

This is elegant because it can also be used to override other settings. We can also allow vault A to add vault C as a dependency, but mark it to not be cloned. This could be used to block vaults that are transitive dependencies.

[jonathanyeung]

Nice write-up! It'll be exciting to see how this pans out. A few comments below:

Vault Dependencies

On Format

dependencies
├── github.com
│  ├── dendronhq
│  │  ├── dendron-docs@main      # depends on github.com/dendronhq/dendron-docs, on main branch
│  │  └── dendron-site@master    # depends on github.com/dendronhq/dendron-site, on master branch
│  └── SeriousBug
│     └── recipes@3e497db338f0f  # depends on github.com/SeriousBug/recipes, targeting a specific commit
├── gitlab.com
│  └── example
│     └── vault@main             # depends on gitlab.com/example/vault, on main branch
└── localhost                    # a local only vault
   └── secret-diary

How do we go from this format to actually resolving the URL from which to do a git clone? i.e., what if gitlab and github have different formats? Should we flatten out the structure to just the URL's? I think deno does something similar.

On Choice

I think we should offer an option to the user whether to download dependencies or not. The use case is quite different than with code - for example, if not all dependencies are met, your code won't compile / run. But that's not the case with notes. Say you bring in a vault that has 100 notes, only 1 of which contains a ref to a different vault. That different vault contains tons of dependencies. You may mostly just want to browse the 100 notes of the original vault, and you may never even come across that link. But then you'd be forced to bring in x additional vaults just to read those 100 notes that you wanted.

To be fancier, at some point we can even choose to 'lazy load' - we only bring in additional dependencies when the user actually clicks on the link or wants to view the ref.

Read-only vaults

I like the concept and proposals. One thing - we should consider maybe a way to have the vault only become read-only once it's 'published' (here, I'm using the word published loosely). That way, when the original author is working on the vault, they won't get prompted with read-only warnings, but only other folks get that warning when they pull down the published version. Mostly an edge case, not a big deal.

dendron.yml

I think we need to add a section to the spec detailing how dendron.yml will work. This is alluded to in earlier comments, but right now dendron.yml mixes both workspace configuration with editor configuration. If a user has multiple vaults, each with their own dendron.yml, I'm worried users may find it confusing on knowing which one to edit for each scenario. And even for some editor experience commands - would we ever want the behavior to be different depending on which vault you're in? Or do we say that your root vault's settings always take precedence in the editing experience. For example:

preview:
    enableFMTitle: true

Potentially, this can be either a user-desired behavior (I always want my notes to look a certain way in preview) or it could also be a vault behavior (the notes in this vault have been written such that the FM titles are formatted nicely, so the preview should use those).

We may also need to enhance some of our commands to make working with settings in a multi yaml setting more intuitive.

Broader Discussion on Dependency Management

How dependency management should pan out requires some more thought. It's easy to look to try to mimic how we do it for code and use npm as an analogy, but the more I think about it, the use cases around vaults/notes is quite different than modules/code-files. We should take inspiration from how we manage code and apply it to how we manage vaults/note, but when the analogy stops making sense, we should probably diverge.

For example, we mention having the ability to check out a dependency at a specific commit, for example recipes@3e497db338f0f. Presumably, we want to do this because we don't want our referenced data to change. But if this is the case, why don't we just statically-inline the referenced content and not add a dependency at all?

Another related issue is with cross-vault refactoring. This works well today with Dendron when I own (or can edit) all vaults that depend on me. But what if I can't? If I have a published vault, how can I rename my note without potentially breaking reference links to that note in other people's vaults? Does this imply that we basically should always depend on a commit hash for a public vault?

In software, we can maintain back compat by guaranteeing an interface or an API. But here's where I think the analogy breaks down for us. What does 'guaranteeing' an interface mean for notes - that our note names and headers can never change? That's most likely going to be too restrictive - but maybe schemas can help us here.

[SeriousBug]

Thanks for the insightful comments!

How do we go from this format to actually resolving the URL from which to do a git clone

That actually flows in the other direction, we get the URL to clone from the settings file, then the clones vaults are stored in these folders. The folders are there to avoid name clashes between different remotes.

On Choice

Lazy loading sounds interesting, but I would say it's outside the scope of this RFC. The RFC does(should?) contain language that if a vault couldn't be cloned, Dendron should still continue to function. We could extend that further and allow users to block certain vaults, including transitive dependencies, from getting clones.

Read-only vaults

The way I'm thinking about the feature is that the read-only is just a suggestion. If you add a vault with "Add Vault" and that vault has marked itself that it should be read-only, then the read-only flag gets set in the cloning users settings. The user is still free to remove that flag to get rid of the warnings. I think there can be more lower level discussion when we're implementing the feature about the UX around this.

dendron.yml

I agree with all your points, but I'm not sure how to proceed with that. My main concern is that we want every vault to be openeable as a workspace too, which means there can be workspace options set in each vault even though those options only apply if the vault is opened standalone.

we mention having the ability to check out a dependency at a specific commit

I was mainly thinking about being able to check out different branches, but once you add git checkout X the X can be not just a branch but a commit or a tag too. This could be something we want to avoid emphasizing in our documentations if it's an anti-pattern.

Another related issue is with cross-vault refactoring

That's true, and I'm not sure there's a perfect answer here, especially in terms of short-term actionable items for this RFC, other than perhaps adding support for wikilinks linking to notes via IDs. My concern would be that the wikilinks would look quite ugly, but perhaps hiding the actual link with some decoration might help with that.

What does 'guaranteeing' an interface mean for notes

I'm not sure that it's that restrictive. Following the analogy of software APIs, having a stable API restricts you in terms of being able to change names of stuff in your API. I don't think it's unreasonable to have the same in public shared knowledge bases.

Like you said, perhaps one thing that could help here would be schemas. You could consider the notes matching a schema to be the public API of the knowledge base, while allowing internal changes to happen. Maintainers of the knowledge base can use links and references in the "API" notes to link to the actual knowledge while being able to change their internal notes. Our tools could limit the consumers of the knowledge base to only link to the "API" notes.

[jonathanyeung]

That actually flows in the other direction

Got it - makes sense.

Lazy loading

Yep - I didn't mean that we should target for v1, but something to think about later - maybe worthwhile noting it down for future reference.

other than perhaps adding support for wikilinks linking to notes via IDs

I think having more complex link syntax seems unavoidable at some point - I agree that decorations can probably do most of the work here.

dendron.yml

Yeah, this one is not easy, but it's the one that concerns me the most and I think we should come up with a solid plan before proceeding. Maybe worth a sync meeting on it.

I think a good way to start would be to go through each setting individually, and categorize it as vault specific or workspace specific, and then perhaps a third category of 'in-between' which we can discuss further. For example:

vault specific:

• site.*
• ...
  workspace specific (editor experience):
• preview.automaticallyShowPreview
• ...
  in between:
• preview.enableFMTitle (?)
• ...

I think this thought exercise should help us get a clearer idea of which settings are essential, and which ones may cause potential confusion. Then - we can brainstorm futher - is it potentially worth it to separate these out into different setting files? or should we at least rework some of our setting categories?

It'd also be good to define how the workspace.* and workspace.vaults.* settings will change, if at all.

[hikchoi]

With the dendron.yml problem, I'm seeing some patterns that resemble how dockerfiles and docker-compose works.
Like how dockerfiles are describing how an image should look like, and docker-compose orchestrates how each of them should run and communicate. I don't have much more to offer here though as I can't quite imagine how exactly these concepts could map to our case. Just a passing thought.

[kevinslin]

I think we should offer an option to the user whether to download dependencies or not.

I think it should be an option but probably v2. Also, the way I think about vault dependencies - most vaults should not have dependencies but rather map closer to vscode plugins. In vscode, plugins can depend on other plugins but that happens very rarely in practice.

I think we need to add a section to the spec detailing how dendron.yml will work.

I think we should go with Or do we say that your root vault's settings always take precedence in the editing experience.
In phase II, we can be smarter about doing vault specific logic. A separate project will tackle splitting editr config from vault config. But to narrow the scope, we should just keep existing behavior (top level workspace/vault defines all settings)

For example, we mention having the ability to check out a dependency at a specific commit, for example recipes@3e497db338f0f. Presumably, we want to do this because we don't want our referenced data to change. But if this is the case, why don't we just statically-inline the referenced content and not add a dependency at all?

I disagree about statically-inlining. That will make it hard to refactor in the future. In terms of refactoring across multiple vaults, long term, the way we solve this is the same way that databases do: using a transaction log. Every time you perform a hierarchy mutating action, that action gets recorded in the transaction log. pseudo example below:

- ts: 2022-02-10 07:57: 
  action: rename
  inputs: foo.md
  output: bar.md
  data: ...

This transaction log is then consumed by downstream vaults and can be replayed so that the downstream vaults can catch up to the most recent state. There's actually prior work in this that we can also leverage: https://www.inkandswitch.com/cambria/

I would put this as out of scope for the current project. Today, if you want to refactor, we make no guarantees about links not breaking in downstream vaults.

[hikchoi]

This might be just creeping in more things to the scope than needed, and is an complete antithesis of vault dependency management, but would vendoring in vaults be something that can be done? (so that they aren't under dependencies, but rather exists locally with the vault somehow).

[kevinslin]

Does #2349 (comment) address this issue?

[SeriousBug]

vendoring in vaults

I don't think we should have built in support for this. Since the vaults are just repositories, the user can fork the repository then use the fork as a dependency if they would like to vendor in the vault.

[hikchoi]

That makes sense. thanks.

[ScriptAutomate]

This looks great, and I have a ton of questions:

• How is this different from making everything function as a Workspace Vault? Is the major difference mostly just being the directory layout, and no longer needing to support x amount of vault/workspace types?
• Dependencies: Are these all configured withing the dendron.yml, which then populates the dependencies subdirectories? And if so, would dependencies be a default entry in .gitignore?
• Extra note on dependencies: I like this treatment of docs vaults like working with modules/packages in programming!
• This update should help a lot with people wanting to create remote vaults, but running into confusion with how to turn a local vault in their workspace into a remote one.
• Does this mean that if I want a vault to contain a mix of public and private vaults, that I just create an empty vault (like a bare workspace), and then add each vault I'd like as a dependency from there? Then treat this minimal vault as my way of working on personal, work, etc. notes?
• Does this mean that all vaults will carry their pod configurations within them? Will those be ignored, except for the top-level vault configs?
• One bonus I really like about this idea: Vaults would have standard community docs (README.md, CONTRIBUTING.md, LICENSE, etc.) in the root without having clashes with Dendron notes themselves.
• We'd have to be aware that this will impact many other feature: how seeds work, how pods work, etc. due to where things would be looking, paths, etc. Would seeds just be handled the same way as dependencies? Especially if seeds exist in other vaults, meaning that they now have those as dependencies? Would it make sense for "Add Vault" (remote) and Seed functionality to be combined into a single UI/UX, where you can add a remote vault from a custom location, or as a seed from an existing known locations from the registry?
• For publishing: Will this mean that cross-vault links, to other docsets, could auto-convert into their equivelant URLs? As in: I have a vault that uses dendron-site as a dependency, but I'm only publishing notes from my blog vault. Would cross-vault links be able to auto-convert into the target vaults URL equiv?

---

Dendron should warn the user if the top level vault is a remote vault, but it contains local vaults inside it. This is important since in previous Dendron versions, placing the workspace in a repository would add all local vaults to the repository as well.

• I'm not sure I follow what this means: local vaults should exist in remote vaults, correct? Much like how local vaults exist in Workspace Vaults?

---

One last item: I think we've talked about a feature that we haven't yet implemented, and that is refactoring logs. As in, a machine-readable list of refactors in a repo. This is because cross-vault links are rather fragile right now, and break in the event that a refactoring is done on a vault outside of different workspaces. We'd likely want this as a feature request if there isn't one somewhere, but it could be designed with however this approach to vaults is implemented.

[SeriousBug]

How is this different from making everything function as a Workspace Vault?

That's effectively what it is, plus all the stuff you said.

Are these all configured withing the dendron.yml, which then populates the dependencies subdirectories? And if so, would dependencies be a default entry in .gitignore?

Yes to both! It's basically the same as how we handle it right now, with the only differences being where we store the directories, and allowing nested vaults (right now workspace vaults don't recursively pull in vaults).

Does this mean that if I want a vault to contain a mix of public and private vaults...

Yes, that's how I'm thinking about it right now. For example for our team, you could create a vault that has your personal notes and such, then add org-workspace as a dependency and you'll get all the vaults in it. (We might want to hold off on doing that internally though until we figure out how the V2 pods configuration integrate with this)

You can also delete the notes folder if you are not going to put any notes in your top-level vault. I'm not sure how the UX of that feature will work, but that's basically what a workspace is right now.

Does this mean that all vaults will carry their pod configurations within them? Will those be ignored, except for the top-level vault configs?

Good catch, I hadn't though of that! I think it makes sense that the pod configurations from the dependencies to be included in the vault and passed along to dependent vaults, although we need to be a bit careful since some pod configurations can contain secrets.

how seeds work ... Would it make sense for "Add Vault" (remote) and Seed functionality to be combined

Agreed. The only feature special to seeds right now I believe is that seeds copy the right publishing URL when you use "Dendron: Copy Note URL". Apart from that, I think we can treat seeds as regular vaults. It can simply be a registry where you can discover shared vaults.

I think having a separate UI for it might make sense, because we should eventually improve the seeds UI so one can browse and search a rich UI to discover new seeds.

For publishing: Will this mean that cross-vault links, to other docsets, could auto-convert into their equivelant URLs?

I think that's possible right now for seeds only, and only for "Copy Note Link". I think it makes sense to make that more generally available and have publishing support it as well. For example I have noticed a few links I had to fix that linked from dendron-site to dendron-docs or vice versa. It would be nice if those were generated correctly.

I'm not sure I follow what this means: local vaults should exist in remote vaults, correct? Much like how local vaults exist in Workspace Vaults?

No, that's one of the key differences. I think one of the confusions with remove vaults is that you can have multiple vaults within a workspace and have all of them within the same vault. While this is flexible, I think it causes issues like:

• If you put your workspace in git, your local vaults are technically workspace vaults so they won't follow the default sync configuration
• If you want to just share one vault and not another (for example if you don't want your personal vault to be synced to your work machine, or if you don't want your personal vault to be published along with your public vault), then you have to manually remove either vault from git, turn it into a workspace vault, then share that.

What this RFC proposes to solve this is more-or-less enforcing one vault per repository. This is a simpler mental model, the only caveat is having to create multiple repositories for your workspace and the potential issues with sync for local vaults (i.e. they are not included unless converted into a remote vault).

refactoring logs

I saw the other discussion here, it is definitely an interesting idea. I'll actually create an RFC draft to preserve those discussions.