Plugin System

[tangjeff0]

Currently, some Roam users download the browser extension roam-toolkit to get additional features such as custom CSS overrides and additional keybindings.

Given that Roam is a text editor, it makes more sense to me that customizations be a native experience. Can we take inspiration from Atom and VS Code to see what a modern plugin architecture looks like? This architecture ideally supports a variety of use cases:

• custom themes
• custom keybindings (e.g. Vim, Emacs)
• arbitrarily executable and composable code

Some Inspirations

• VS Code Extension API
• org-mode
  • scheduling and planning your GTD agenda
  • tracking time
  • native capture templates (as opposed to text expanders)
  • export (to HTML, PDF, LaTex, slideshow)
  • literate programming
• Smallest Federated Wiki
  • data viz with d3.js. With sci.web, we can import arbitrary npm packages on the client. A use case for this would be importing data visualization libraries and having ObservableHQ workflows inside your Athens. See #67.
  • arduino sensor data. Imagine ingesting actionable live data from IFTTT or Zapier into your Athens.
• https://www.dokuwiki.org/plugin:struct
• https://joplinapp.org/plugins/
• roam/css and roam/js
• https://tiddlywiki.com/static/Plugins.html

[tangjeff0]

Will re-open when after v1 is complete

[jeroenvandijk]

TODO

• [ ] Collect keycodes
• [ ] Demonstrate activation of keycodes with devcards (write on-keypress event listeners)
• [ ] Use event listeners in components

[thesophiaxu]

Related: #291 It contains a sample plugin API of using custom event hooks w/ custom components and slash commands. Closing that one (^) because we already have this.

[thesophiaxu]

Agree a lot with @tangjeff0 's vision of building an extension architecture like VS Code. Here's its extension architecture and philosophy for reference: https://vscode-docs.readthedocs.io/en/stable/extensions/our-approach/ It basically has an extension host that is in a seperate worker thread which communicates with the parent thread primarily via events. Because VS Code is a desktop app, its plugin host is in a Node.js thread; but Athens could decide whether to use web workers (directly inside browsers) or build it into our Electron app.

What are your thoughts? @tangjeff0 @jeroenvandijk @itsrainingmani

[alaq]

Ideally extensions should be compatible with the desktop version as well as the web based version so maybe web workers are more appropriate? I believe you can also use web workers in Electron.

I also like borrowing VS Code's vision. It's encouraging that other applications are able to share extensions with VS Code, like onivim 2.

In terms of distribution, I like how Ulauncher is doing it. You can simply give it a git repository (so GitHub, GitLab, or self hosted git all work well), which doesn't prevent us from having a plugin registry. The plugin registry is another good project for learners (cc @tangjeff0 @itsrainingmani).

[thesophiaxu]

@alaq Great input! Yes, web workers work in Electron as well. I am also thinking about talking to the devs of Obsidian to see how we can build a partially common API so that some plugins could be shared between Athens and Obsidian.

In terms of distribution, I think it's a bit too early to think about a full extension registry, but I do like your idea of using git repositories for extensions. In the relatively short term, we can have a temporary manual "featured" extension registry, while enabling custom extension imports via git repositories or zip files.