Extension / Plug-in Support

[kyaso]

I know that this is a big topic. But definitely one worth discussing. As Zettlr's userbase is constantly growing, so does the demand for new features. Unfortunately, not every feature request can make it into the app in the long run.

This is where extensions come in. They would allow anyone to easily customize the behavior of Zettlr to fit their needs (+ share it with others). Other benefits:

• Zettlr's codebase stays clean, and only necessary features get implemented
• Users can select only the extensions they want for their particular workflow
• More people get encouraged to contribute new functionality to Zettlr (developing extensions could be more accessible than fiddling with the main code)
• Extension could allow "in-field" testing of new features that didn't make it into the codebase. If the extension turns out to be popular, its functionality can be integrated into Zettlr directly.

A few aspects that came into my mind regarding the implementation of an extension infrastructure:

• Extension API
• Extension Marketplace
• Extension Security

I might have missed some aspects, and I also don't know the effort required for this endeavor. That's why I thought it might be a good idea to open a discussion. So that we have a central place to talk about this topic (maybe there is already one?).

[nathanlesage]

@tobiasdiez has had some very good points on plugins yes/no in the past, and I've generally stuck to his advice in this regard. Feel free to add some of your points here again, or link them, if you think that this is advisable, Tobias.

However, that being said: I'm slowly starting to see that JabRef and Zettlr differ vastly in functionality. JabRef is a reference manager, and thus there is only so much that needs to be done. But over the past four years developing Zettlr, I have slowly but steadily come to the conclusion that writing text is much more complex and requires a lot of different tools, and many people have vastly differing requirements. I think reference managers can only do that much (and that is why I stick with only two plugins for Zotero, because everything else is simply not in the scope of a reference manager), but a writing app should offer much more stuff.

That being said: Writing a plugin system is incredibly difficult, and thus we should do that extremely limited. Two very good suggestions for "trying this out" would be (a) a renderer plugin API, so that people can render whichever elements they like within the app, and (b) a language server API so that people can incorporate external services for linting code, spellchecking, and what not else.

That might keep the effort manageable at least for now. New features to the plugin API should only be incorporated after an insane amount of deliberation.

With regard to security, there may be an easy way: invisible Browser windows. Each plugin could run in its own dedicated browser window. This would ensure that it's a fully autonomous process and can only interact within that sandbox. There would be just two things we need to remember: First, the broadcastIPCMessage function would need to be scoped not to accidentally leak data into the plugin windows, and we would need extremely strong validation within the preload for these plugin windows. Also, we should prevent any network access for these. (Alternatively, because I already see people complaining that some language service requires an API access, we could implement a rights management so that the user is prompted something like "Plugin xyz wants to access website abc, allow?" — but here you can already see how incredibly difficult that could be)

So, it's worth a discussion, but we need to tread carefully.

[tobiasdiez]

I agree that my experience with JabRef cannot directly be translated to Zettlr. Still the two major points of problems we had were:

• At some points plugins are no longer actively maintained, which then gives also a bad reputation for the original app.
• Development of the main app gets slower as one has to make sure that the plugins don't break. Also testing that everything is still working is a manual process.

These issues would also apply to Zettlr I think. One should also keep in mind that Zettlr's target group is more "non-technical" writers, and those normally don't have the knowledge to code plugins. Thus while for example the Zettlr community is larger, the pool of potential plugin writers is not necessary so.

In my opinion, it make sense to have plugins if the community gets so big that they would for example jump in maintaining plugins if the original maintainer stopped doing so. For now I would advice to make it easier to contribute to Zettlr itself. Once @nathanlesage gets so many PRs about functionality that he actually doesn't want to have in the main repo, then I would say it's a good point to think about plugins. At the beginning they could also be just a collection of classes in a "plugins" folder in the main repo and giving users the possibility to switch them on/off. In this way one doesn't have to worry about extension store, security and backwards compatibility.

[nathanlesage]

I agree with your points.

At some points plugins are no longer actively maintained, which then gives also a bad reputation for the original app.

One thing we could do to both ensure proper maintenance and prevent a bad reputation would be to enforce upper version constraints. As soon as we upgrade the plugin API, we could simply disable too old plugins and give out a notice. As long as the plugin API moves slower than the main app, this could be a compromise.

Development of the main app gets slower as one has to make sure that the plugins don't break. Also testing that everything is still working is a manual process.

That's something that I would argue is already handled by having the Discord. It's easy to just drop a deprecation note there, and anyone developing plugins could look into that specific channel. As long as we're transparent that we're not taking hostages that might ensure both that plugins only get developed by people who want to commit to maintaining it.

However, I see that it's a big undertaking. Therefore, I like the approach of limited plugins (only rendering or only linting for now). This way we could very gently introduce a plugin API.

Once @nathanlesage gets so many PRs about functionality that he actually doesn't want to have in the main repo, then I would say it's a good point to think about plugins.

I would argue when the point comes that I'm overwhelmed by PRs it's way too late to start thinking about Plugins.

[deletosh]

Those said, is there a roadmap for limited plugin support?

[huyz]

At this point, I wonder how much it would make sense to offer a certain level of Obsidian API compatibility, just so that it's easier for some of the large number of Obsidian plugins to be ported…

[espipj]

Obsidian API compatibility would be super great!

[AltayYuzeir]

Especially for something like the BMO-Chatbot