Multi site RFC#339
Conversation
|
A third way of solving this is to consider #50 but in local context. Suppose there are two local zettelkastens -- private & public -- we could make it possible for one zettelkasten to (cross) link to another (but not vice versa). So "public" zettelkasten would be independent; but the "private" zettelkasten can cross link to the "public" zettels. Coming up with a spec to make this work doesn't seem exactly easy though. EDIT: The main advantage of this approach is that the two zettelkastens are generally decoupled; any coupling that happens is done via one-way cross-linking, and there is no risk of private zettels leaking into the public zettelkasten. |
|
Thinking more about cross-linking ... instead of having sub-zettelkastens, we now think in terms of composing (otherwise independent) zettelkastens. So, if you have a zettelkasten called "public" -- and it exists as a sub-directory (or git submodule) as ./public/neuron.dhall -- then you can have another zettelkasten's neuron.dhall "point" to it as This also solves the problem of public/index.html being in conflict with the master zettelkasten's zettel of same ID. And it solves the constraint of "public" zettelkasten being allowed only to link to itself (unless it is configured to have cross-links) |
|
How does this affect querying? If I query by a tag, is it supposed to query cross-links as well or is there a special syntax for choosing an ID prefix? |
|
Since both the zettelkastens will be part of the same graph, if you say query by tag - it will include zettels from both of them. To be more precise, it is not exactly cross-linking - rather, more of "embedding" another zettelkasten into your graph ... but with IDs namespaced. Here, you would be embedding your blog zettelkasten onto your private zettelkasten. |
|
Closing in favour of #355 |
Rendered
Addresses #222