Feature: Plug-in architecture #199

New Issue

2026-10-05T02:03:16+02:00

adam commented

2026-10-05 02:03:16 +02:00

Hi all,

first off, I am a big fan of this project, thanks for the great work!
I was wondering what you think about the following idea, is it something worth pursuing?

Problem Description
If a user wants to add some custom functionality to RemoteTerm like i.e. some custom pages in the UI or additional processing logic, they currently typically need to work with a fork of the application, which can be troublesome if a new release changes modified code sections.
An example might be a custom statistics page which collects and displays statistics which RemoteTerm does not, i.e. a combined stats overview of all monitored repeaters. Or a custom MQTT integration which pre-filters data and only sends specific things to MQTT, i.e. only statistics collected from monitored repeaters.

Idea

Have a standardized approach for plugins, to integrate them nicely.
Plugins should be able to expose their own custom API endpoints and be able to integrate with the UI to add new pages.
Plugins should be able to work with raw packet data and also be able to react on all events.
Add a database access helper which would enforce a plug-in specific table name prefix, so plugins could create their own DB tables without a risk of conflicting with core tables. But read/write access to core tables should still be possible, just no schema changes. Database migration scripts for plugins should be supported.
Ideally, plug-ins could be installed/uninstalled/configured in the application settings. Maybe either as a new side bar entry under settings or maybe it could be a new entry in the MQTT & Automation section?
Define some structured plugin metadata descriptor, which would provide things like plugin name, author, version, URL and other things useful for displaying them in the settings area (maybe also an icon).

Greetings

Hi all, first off, I am a big fan of this project, thanks for the great work! I was wondering what you think about the following idea, is it something worth pursuing? **Problem Description** If a user wants to add some custom functionality to RemoteTerm like i.e. some custom pages in the UI or additional processing logic, they currently typically need to work with a fork of the application, which can be troublesome if a new release changes modified code sections. An example might be a custom statistics page which collects and displays statistics which RemoteTerm does not, i.e. a combined stats overview of all monitored repeaters. Or a custom MQTT integration which pre-filters data and only sends specific things to MQTT, i.e. only statistics collected from monitored repeaters. **Idea** - Have a standardized approach for plugins, to integrate them nicely. - Plugins should be able to expose their own custom API endpoints and be able to integrate with the UI to add new pages. - Plugins should be able to work with raw packet data and also be able to react on all events. - Add a database access helper which would enforce a plug-in specific table name prefix, so plugins could create their own DB tables without a risk of conflicting with core tables. But read/write access to core tables should still be possible, just no schema changes. Database migration scripts for plugins should be supported. - Ideally, plug-ins could be installed/uninstalled/configured in the application settings. Maybe either as a new side bar entry under settings or maybe it could be a new entry in the MQTT & Automation section? - Define some structured plugin metadata descriptor, which would provide things like plugin name, author, version, URL and other things useful for displaying them in the settings area (maybe also an icon). Greetings

adam commented

2026-10-05 02:03:17 +02:00

Thank you for the kind words!

I really like that idea. It puts a lot of extensibility in the hands of the community and reduces my role as a gatekeeper, which is awesome. It's also a massive codebase change, and raises questions about how many places to put hooks for plugins -- are they essentially custom fanout modules (i.e. frontend, some settings storage, and a backend blob?) or can they mutate state in conversations, etc. and then we become a Wordpress clone (tongue in cheek!)

So, I'm kind of at an interesting place with it. I like it, I don't want to lobotomize/mangle the codebase for it, and I'm a little light on time at the moment. But I really do like it.

I think this is something I would want to do personally, or at the least have a heavy hand in, as it dictates a big part of the future path of RemoteTerm. So, I think the answer right now is, not right this second, but I'm going to keep this open, and not in the "eh probably not but let's see if other people care" way but instead as a "I really want to do this but can't at this moment." I may have some time opening up over the next month, and would love to tackle this then.

Thank you for the kind words! I really like that idea. It puts a lot of extensibility in the hands of the community and reduces my role as a gatekeeper, which is awesome. It's also a massive codebase change, and raises questions about how many places to put hooks for plugins -- are they essentially custom fanout modules (i.e. frontend, some settings storage, and a backend blob?) or can they mutate state in conversations, etc. and then we become a Wordpress clone (tongue in cheek!) So, I'm kind of at an interesting place with it. I like it, I don't want to lobotomize/mangle the codebase for it, and I'm a little light on time at the moment. But I really do like it. I think this is something I would want to do personally, or at the least have a heavy hand in, as it dictates a big part of the future path of RemoteTerm. So, I think the answer right now is, not right this second, but I'm going to keep this open, and not in the "eh probably not but let's see if other people care" way but instead as a "I really want to do this but can't at this moment." I may have some time opening up over the next month, and would love to tackle this then.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/Remote-Terminal-for-MeshCore#199