# Plugin architecture discussion **URL:** \ **Category:** Feature Requests\ **Tags:** Plugins\ **Created:** [July 19, 2022, 10:31am UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790 "2022-07-19T10:31:02Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![Filip](https://community.anytype.io/user_avatar/community.anytype.io/filip/32/22248_2.png) [@Filip](https://community.anytype.io/u/Filip)\ **Post date:** [July 19, 2022, 10:31am UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/1 "2022-07-19T10:31:02Z")
I’d love for Anytype to go the Obsidian route where pretty much everything is a plugin. The plugins released by the Obsidian development team are called Core Plugins, and by disabling all of them, you end up with just a barebones markdown editor. Some examples of the core plugins are: - Backlinks - Graph - Search - Command palette - Daily notes - File explorer - Tags - etc. With this approach, the user can customize the whole app to their liking and they don’t end up being stuck with unnecessary features that clutter the workspace. ---
**Author:** ![qualquertipo](https://community.anytype.io/letter_avatar_proxy/v4/letter/q/ecae2f/32.png) [@qualquertipo](https://community.anytype.io/u/qualquertipo)\ **Post date:** [July 19, 2022, 5:50pm UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/2 "2022-07-19T17:50:04Z")
I agree that’s a much more elegant approach. However I have a feeling it’s not how Anytype will work. Unless anyone knows better? 🙏 ---
**Author:** ![Filip](https://community.anytype.io/user_avatar/community.anytype.io/filip/32/22248_2.png) [@Filip](https://community.anytype.io/u/Filip)\ **Post date:** [July 19, 2022, 5:56pm UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/3 "2022-07-19T17:56:40Z")
I don’t see a reason for it not too. It’s just giving people options. ---
**Author:** ![Narvey](https://community.anytype.io/letter_avatar_proxy/v4/letter/n/e9a140/32.png) [@Narvey](https://community.anytype.io/u/Narvey)\ **Post date:** [July 28, 2023, 7:46pm UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/4 "2023-07-28T19:46:03Z")
Yeah, if anyone has an objection as to why it **shouldn’t** work that way, speak up, otherwise it sounds like a great idea to me and it seems the others on this thread! Let’s do it! ---
**Author:** ![callumgare](https://community.anytype.io/user_avatar/community.anytype.io/callumgare/32/10242_2.png) [@callumgare](https://community.anytype.io/u/callumgare)\ **Post date:** [August 12, 2023, 10:32am UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/5 "2023-08-12T10:32:11Z")
I’m gonna provide a little bit of push back to this. I personally hope Anytype doesn’t lean into plugins to that extent where core functionality is implemented as plugins. There’s a few reasons I’m hoping that’s the case: - **It tends to provide a less seamless experience** When core functionality is implemented as a plugin often users can disable that plugin (after all that’s one of the main reason you might choose to implement it as a plugin in the first place). But this means that a plugin which implements a particular feature can’t rely on the existence of some other functionality provided by a different plugin. It is possible for plugins to be written defensively so that they only provide some integration with another feature if that feature is available. However this increases complexity and so discourages adding such integration. - **Increased development/testing complexity means the dev team’s limited time is used less efficiently** Software development is hard. There’s a million things things that can go wrong or break which is why testing is so important. But for testing to work well it needs to have good coverage of the different possible states an application can be in. - **Platforms that go this route often end up relying community plugins for the implementation of a greater amount of core/general functionality than they might otherwise** If a community plugin is made for some feature that has broad appeal and that plugin becomes popular because of the usefulness of that feature then even if the actual UX provided by that plugin is pretty “meh” it’s harder for the app devs to justify putting time into developing an officially supported core plugin to do implement that since there’s already something that mostly works + you risk upsetting the community by [sherlocking](https://en.wikipedia.org/wiki/Sherlock_(software)#Sherlocked_as_a_term) that functionality. The result of this greater reliance on community supported plugins for a lot of basic/very popular functionality can have some major downsides: I know a lot of the above is based on personal observation and is somewhat opinionated. But I’m not trying to argue that the approach suggested in this topic is bad idea or shouldn’t be done, just that while it might seem like there are only upsides at first glance I do think there are some major potential downsides to consider carefully before exploring such an approch. I don’t want to some across as too negative towards plugins especially community developed ones, plugins can be great! That one niche piece of functionality that only you and two other people want is not likely to be ever be built in the app by the core dev team. But with plugins there’s a good chance someone in the community might have made a plugin for it. However that is the use case where plugins tend to shine the most so while I’m definitely not anti-plugins I do want to push back on the notion that there are no downsides to implementing a lot/most of an app’s general functionality using plugins. ---
**Author:** ![rocklobster](https://community.anytype.io/letter_avatar_proxy/v4/letter/r/d2c977/32.png) [@rocklobster](https://community.anytype.io/u/rocklobster)\ **Post date:** [August 13, 2023, 6:27pm UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/6 "2023-08-13T18:27:53Z")
#### WHAT DO YOU RECOMMEND why is the date backwards? there should be options on how a person preferes to enter and display the date, i.e. yyyy-mm-dd or mm/dd/yyyy or dd/mm/yyyy also, i hate emojis, can there be an option to remove them entirely? why can’t i edit the built in objects? i can’t remove emojis myself or remove object types that i will never use. #### HOW COULD IT BE DONE The date options should be built into the settings and built in objects should be allowed to edit. ---
**Author:** ![Narvey](https://community.anytype.io/letter_avatar_proxy/v4/letter/n/e9a140/32.png) [@Narvey](https://community.anytype.io/u/Narvey)\ **Post date:** [August 14, 2023, 2:36pm UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/7 "2023-08-14T14:36:51Z")
Thank you, I always appreciate healthy pushback (which yours certainly is) as it helps us understand the ins and outs better. However, I think this one could actually tip in favor of everything-is-a-plugin: > [@callumgare](#): > > Increased development/testing complexity means the dev team’s limited time is used less efficiently As a Software Engineer, I liked being able to test things in a modular fashion. ---
**Author:** ![callumgare](https://community.anytype.io/user_avatar/community.anytype.io/callumgare/32/10242_2.png) [@callumgare](https://community.anytype.io/u/callumgare)\ **Post date:** [August 14, 2023, 10:52pm UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/8 "2023-08-14T22:52:43Z")
@rocklobster i think you probably want to open a new thread for that. This one is for discussing how a plugin system could work. @Narvey yeah that’s a good point. There’s nothing stopping you writing non-plugin code in a modular and unit testable way but writing it as a plugin will probably make it simpler to keep modular in some ways. ---
**Author:** ![Narvey](https://community.anytype.io/letter_avatar_proxy/v4/letter/n/e9a140/32.png) [@Narvey](https://community.anytype.io/u/Narvey)\ **Post date:** [August 15, 2023, 12:16am UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/9 "2023-08-15T00:16:09Z")
lol, the hate emojis thing would be related if emojis were a core feature developed as a plugin. But yeah, does seem like it was supposed to be separate. ---
**Author:** ![Filip](https://community.anytype.io/user_avatar/community.anytype.io/filip/32/22248_2.png) [@Filip](https://community.anytype.io/u/Filip)\ **Post date:** [August 15, 2023, 7:01am UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/10 "2023-08-15T07:01:04Z")
It’s somewhat related, hence why it was merged. The original FR was a bit of a mess to say the least. ---
**Author:** ![crystaln](https://community.anytype.io/letter_avatar_proxy/v4/letter/c/dec6dc/32.png) [@crystaln](https://community.anytype.io/u/crystaln)\ **Post date:** [January 25, 2024, 9:37pm UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/11 "2024-01-25T21:37:33Z")
To chime in here, one of the reasons I have used Notion and now Anytype instead of Obsidian or LogSeq is the lack of need for tinkering with third party plug-ins. The last thing I want is to spend days on end researching plug-ins, evaluating the subtle differences and interactions between them, reading about reviews and bugs, deciding which has adequate developer support, etc etc. I very much want there to be an API and the ability to integrate and the ability to add custom integrations. In general tho, I’d rather have an imperfect and unified system where development effort is focused and UX is consistent, rather than chasing perfection through a dark muddy world of third party plugins for core functionality. ---
**Author:** ![crystaln](https://community.anytype.io/letter_avatar_proxy/v4/letter/c/dec6dc/32.png) [@crystaln](https://community.anytype.io/u/crystaln)\ **Post date:** [January 25, 2024, 9:40pm UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/12 "2024-01-25T21:40:43Z")
There is also a significant part of me that disagrees with what I said above. I considered trying Obsidian with Make.md instead of Notion, and maybe I should! ---
**Author:** ![Filip](https://community.anytype.io/user_avatar/community.anytype.io/filip/32/22248_2.png) [@Filip](https://community.anytype.io/u/Filip)\ **Post date:** [January 26, 2024, 11:53am UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/13 "2024-01-26T11:53:21Z")
> [@crystaln](#): > > The last thing I want is to spend days on end researching plug-ins, evaluating the subtle differences and interactions between them, reading about reviews and bugs, deciding which has adequate developer support, etc etc. I never really understood this argument against plugins. No one is forcing you to use plugins. 😅 You can just keep on using the app without them while people who would like to use plugins, now can. ---
**Author:** ![crystaln](https://community.anytype.io/letter_avatar_proxy/v4/letter/c/dec6dc/32.png) [@crystaln](https://community.anytype.io/u/crystaln)\ **Post date:** [January 26, 2024, 9:03pm UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/14 "2024-01-26T21:03:00Z")
> [@Filip](#): > > I never really understood this argument against plugins. I think others covered this pretty well. When they become dominant they can crowd out core feature development, and their development is dependent on third parties whose incentives aren’t the same as the core team. I think plug-ins are great except when they basically pre-empt and displace core feature development. Of course, they can also serve an experimental ground for new features. There are positives and negatives. I guess what I mean is I want the core product to address my needs, and plug-ins to be extra nice-to-have features. If plug-ins are a NEED for me, then the product isn’t right for me. ---
**Author:** ![crystaln](https://community.anytype.io/letter_avatar_proxy/v4/letter/c/dec6dc/32.png) [@crystaln](https://community.anytype.io/u/crystaln)\ **Post date:** [January 26, 2024, 9:05pm UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/15 "2024-01-26T21:05:34Z")
This of course don’t apply also to different applications, like for instance if someone developed an accounting system in Anytype, that would be awesome and useful, and not something the core team will probably ever develop. In Obsidian tho, to make it meet my basic needs, I would need third party plugins like Make.md. ---
**Author:** ![yzd](https://community.anytype.io/user_avatar/community.anytype.io/yzd/32/15085_2.png) [@yzd](https://community.anytype.io/u/yzd)\ **Post date:** [February 6, 2024, 4:55pm UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/16 "2024-02-06T16:55:09Z")
I think @callumgare makes a good case for approaching plugins with caution. That being said, part of my rationale for being so in favor of plugins is that Anytype is almost feature complete when it comes to “core functionality.” Yes, there are some workflows still in desperate need of some tweaks, but overall, the current version has the basics of [PIM](https://en.wikipedia.org/wiki/Personal_information_management) tied down. So where do I think plugins would be useful? **1. Creating custom views to interact or visualize data from a source (e.g. study cards + custom calendar widgets):** ![2](https://community-static.anytype.io/original/2X/b/b934cdce4123bf5ce054c2969cc1c242bcb6cb2f.jpeg) **2. Adding interesting ways to interact with your files (e.g. reproducing voice notes / audios from your local files):** ![1](https://community-static.anytype.io/original/2X/0/0a3dcbf5511d582ccfffae6e27237fb2d5eccf4a.jpeg) **3. Creating custom workflows to quickly edit/format your data (e.g. in-line data formatters):** ![3](https://community-static.anytype.io/original/2X/b/ba710e74fe839799803f77b62b6ac484be85da3d.jpeg) Personally, I’m looking forward to it. 🙂 Btw, a good example of what community involvement would look like, IMO, is Figma. The product stands on its own pretty well, but the minute you need to extend it with some weird use case, someone already implemented it and made it conveniently available through a plugin. ---
**Author:** ![SimonF](https://community.anytype.io/letter_avatar_proxy/v4/letter/s/f08c70/32.png) [@SimonF](https://community.anytype.io/u/SimonF)\ **Post date:** [February 8, 2024, 9:50am UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/17 "2024-02-08T09:50:07Z")
I would counter this by saying that _it depends_ on what users want to do. Too many features can be distracting / bloating your workflow - depending on your use case. For starters, simplicity / minimalism by itself is a feature. Building towards specificity alienates part of the potential user base. I myself am updating and waiting for some features to even consider using it, yet some features that are already implemented I would never install. ---
**Author:** ![micklat](https://community.anytype.io/user_avatar/community.anytype.io/micklat/32/15411_2.png) [@micklat](https://community.anytype.io/u/micklat)\ **Post date:** [April 2, 2024, 11:39am UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/18 "2024-04-02T11:39:28Z")
People who want plug-ins to happen - please chime-in in [this discussion](https://community.anytype.io/t/language-based-security/19381). Might anyone be willing to pool resources to make plug-ins safe for users and happen sooner rather than later? ---
**Author:** ![turquiseblue](https://community.anytype.io/user_avatar/community.anytype.io/turquiseblue/32/1614_2.png) [@turquiseblue](https://community.anytype.io/u/turquiseblue)\ **Post date:** [November 29, 2025, 5:51pm UTC](https://community.anytype.io/t/plugin-architecture-discussion/6790/19 "2025-11-29T17:51:58Z")
I get that a plugin system can be messy, I don’t like a extension/plugin system when there are even many ‘outdated’ plugins to choose from. **Solution** could be: A comment by the developers about a plugin if it is covered by the core system already (inside the plugin store). No need to have it as an up-to-date comment system, but just when some plugin appears in a bug report or when a plugin is mentioned somewhere else to the core developers, then a comment could be made about a plugin.