Proposal: A Plugin Architecture to Foster Innovation and Community Growth #235

Closed
opened 2026-07-10 17:44:24 +00:00 by nienty · 3 comments
nienty commented 2026-07-10 17:44:24 +00:00 (Migrated from codeberg.org)

Hello,

First of all, congratulations on the remarkable progress of Holos. The application has improved tremendously, and its continuous evolution is truly impressive.

Since Holos is an open-source project, I would like to suggest taking it to the next level by introducing a plugin (extension) architecture.

Technology evolves at an incredible pace. By preparing the application today to support extensions, Holos would be able to adopt new ideas and features much more easily in the future, without requiring major changes to its core.

The idea is to create a modular system where users can install only the extensions they need. These plugins could be developed not only by the Holos team but also by independent developers, whether they are hobbyists or professionals.

Such an architecture would offer several important benefits:

Enable users to customize Holos according to their own needs.
Accelerate innovation through community contributions.
Expand the Holos ecosystem with new services and features.
Keep the core application stable while allowing rapid functional growth.
Encourage developers to experiment and share their ideas without affecting the main codebase.

A well-designed plugin system could become one of Holos's greatest strengths, fostering a vibrant ecosystem and empowering the community to shape the future of the project alongside its core developers.

Thank you for your dedication and the outstanding work you've done so far. I hope this proposal will be considered as part of Holos's long-term vision.

Hello, First of all, congratulations on the remarkable progress of Holos. The application has improved tremendously, and its continuous evolution is truly impressive. Since Holos is an open-source project, I would like to suggest taking it to the next level by introducing a plugin (extension) architecture. Technology evolves at an incredible pace. By preparing the application today to support extensions, Holos would be able to adopt new ideas and features much more easily in the future, without requiring major changes to its core. The idea is to create a modular system where users can install only the extensions they need. These plugins could be developed not only by the Holos team but also by independent developers, whether they are hobbyists or professionals. Such an architecture would offer several important benefits: Enable users to customize Holos according to their own needs. Accelerate innovation through community contributions. Expand the Holos ecosystem with new services and features. Keep the core application stable while allowing rapid functional growth. Encourage developers to experiment and share their ideas without affecting the main codebase. A well-designed plugin system could become one of Holos's greatest strengths, fostering a vibrant ecosystem and empowering the community to shape the future of the project alongside its core developers. Thank you for your dedication and the outstanding work you've done so far. I hope this proposal will be considered as part of Holos's long-term vision.
nienty commented 2026-07-10 18:41:44 +00:00 (Migrated from codeberg.org)
Here are a few examples of plugin categories that could help expand the Holos ecosystem:
    Synchronization: support for Nextcloud, WebDAV, Syncthing, and other synchronization solutions.
    Integrations: connectors for services such as calendars, cloud storage, communication tools, and decentralized social networks. This could include Fediverse platforms as well as independent decentralized networks like Bluesky (AT Protocol).
    Customization: community-developed themes, widgets, dashboards, and user interface modules.
    Security: encryption, advanced authentication, logging, and data protection tools.
    Automation: workflows and automated actions between different Holos features.
    Accessibility and communication: translation tools, text-to-speech (TTS), automatic image description (alt text) for posts, and other accessibility-focused features.

These are only examples. The main goal is to provide a flexible plugin architecture that enables the community to easily develop and share new features as Holos continues to evolve.
Here are a few examples of plugin categories that could help expand the Holos ecosystem: Synchronization: support for Nextcloud, WebDAV, Syncthing, and other synchronization solutions. Integrations: connectors for services such as calendars, cloud storage, communication tools, and decentralized social networks. This could include Fediverse platforms as well as independent decentralized networks like Bluesky (AT Protocol). Customization: community-developed themes, widgets, dashboards, and user interface modules. Security: encryption, advanced authentication, logging, and data protection tools. Automation: workflows and automated actions between different Holos features. Accessibility and communication: translation tools, text-to-speech (TTS), automatic image description (alt text) for posts, and other accessibility-focused features. These are only examples. The main goal is to provide a flexible plugin architecture that enables the community to easily develop and share new features as Holos continues to evolve.
nienty commented 2026-07-10 19:42:50 +00:00 (Migrated from codeberg.org)

I would like to propose another idea that could naturally fit into Holos’ future plugin architecture: a voice interaction plugin.

This plugin could even be placed at the top of the priority list, as it would immediately bring significant value in terms of accessibility, user experience, and innovation.

The goal would be to allow users to interact with Holos through voice commands, making the platform more natural, intuitive, and convenient to use.

Possible features could include:

  • Reading publications and content aloud using text-to-speech (TTS).
  • Reading notifications, mentions, and received messages.
  • Dictating and composing messages through voice with automatic speech-to-text conversion.
  • Creating audio posts with optional transcription.
  • Improving accessibility for users with specific needs.

This plugin could remain independent from the Holos core and evolve through community contributions, while prioritizing privacy-friendly solutions, including local processing whenever possible.

A voice extension like this could become one of the first building blocks of a more accessible, modern, and innovative Holos, opening the way to new forms of interaction with digital platforms.

I would like to propose another idea that could naturally fit into Holos’ future plugin architecture: a voice interaction plugin. This plugin could even be placed at the top of the priority list, as it would immediately bring significant value in terms of accessibility, user experience, and innovation. The goal would be to allow users to interact with Holos through voice commands, making the platform more natural, intuitive, and convenient to use. Possible features could include: * Reading publications and content aloud using text-to-speech (TTS). * Reading notifications, mentions, and received messages. * Dictating and composing messages through voice with automatic speech-to-text conversion. * Creating audio posts with optional transcription. * Improving accessibility for users with specific needs. This plugin could remain independent from the Holos core and evolve through community contributions, while prioritizing privacy-friendly solutions, including local processing whenever possible. A voice extension like this could become one of the first building blocks of a more accessible, modern, and innovative Holos, opening the way to new forms of interaction with digital platforms.
tom79 commented 2026-07-17 08:11:57 +00:00 (Migrated from codeberg.org)

A plugin system is not a direction I want for Holos. The app runs an embedded ActivityPub server and keeps your signing and E2EE keys on the device. Running third party plugin code next to those keys would change the security model, and keeping a stable plugin API is too much for a project this size.

If you have a specific feature in mind, open a separate issue for it.

Closing as out of scope.

A plugin system is not a direction I want for Holos. The app runs an embedded ActivityPub server and keeps your signing and E2EE keys on the device. Running third party plugin code next to those keys would change the security model, and keeping a stable plugin API is too much for a project this size. If you have a specific feature in mind, open a separate issue for it. Closing as out of scope.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
tom79/Holos-App#235
No description provided.