The Polygon Project is a vision of making modular open-source software more attractive than proprietary collaboration suites (such as Microsoft 365 or Google Suite) and ERP-Systems through deep integration, data soveignity with single point of truth and appealing and useful new interfaces as well as customizability to preferences and processes. While the true power resides on the simple flexible backend, revenue will come from servicing a ready-made productivity suite. The interface parts are crucial to selling as key decision people tend to have limited technical knowledge. That is why we focus the initial development on stability and user-facing components - home-grown open-source stacks are known for unreliability, but with the power of GitOps and Kubernetes we can change that - beating Google through their own technology.
This vision is to be implemented in multiple stages:
- Stackspout Toolsuite
- Prototyping Tool Integrations
- Nodal Protocol
- Smooth Novel Interface Concepts
Stackspout
For the first prototype, we extended the Stackspin open source software suite with additional apps such as Vikunja and funded development in these apps to enhance their professional usability. Since Stackspin already offers a dashboard, we collaborated with them to add enhancements.
The current Stackspin dashboard allows admins to install some additional applications, centrally manage users for the provided Single Sign-On including access to apps, and for all users links to those. We prototyped an alternative approach within Nextcloud, providing a tabbed navigation between different available tools each available both as separate page but also iFramed into Nextcloud using the external apps plugin.
This integration is an unsolved problem: iFrames are a security risk and degrade performance, but being able to quickly switch between the apps is quite handy. Maybe a custom-built browser like many Electron desktop applications with tabs for each tool could be a good option here.
Integrations
The vision of Polygon is for all tools to be deeply integrated at data-level and thus interchangeable. At any point in time, a user should be able to for instance replace the task manager with an alternative or even use two side-by-side, without any migration effort beyond tool-specific configuration. To prevent considerable development efforts in the wrong direction, we first prototype some of these integrations.
For prototyping, we use Vikunja as sole reference for all task-related integrations, because it can easily handle view transitions within its internal structure. In the future, other tools like Wekan will be incrementally integrated to provide alternatives for the all-in-one views of Vikunja. Then we use n8n (an automation tool like IFTT or Zapier, but self-hosted), which is already deployed on our cluster, and preconfigure it with flows that enhance Vikunja and integrate it with Zulip and our other central tools. This way we can test and demonstrate the synchronisation of independent task and project management with team chat software.
Nodal Protocol
The ultimate vision, however, goes much farther. Polygon is to stand upon a protocol dubbed Nodal, itself built around the nostr protocol, replacing or at least extending the application-internal storage of participating applications with nostr relays. Depending on the application a native integration or (especially for uncooperative proprietary software) a bridge may be developed. This provides single points of truth for productivity tools and enable smooth collaboration across companies, teams and individual contributors, each in their preferred tools. Tools can then focus on providing a great Interface and UX without worrying about data storage and migration. The protocol should also handle aspects such as realtime collaboration, for which nostr again is a great foundation as its primary mode of communication are websockets.
When it comes to the internals of a relay, just like with the nostr protocol, there is a lot of flexibility as long as the core protocol elements are fulfilled.
One might consider using the SOLID standard for data storage, to provide another standardised interface to access and share the data. Application-internal databases might still be needed for performance reasons, but should then solely work as caches to provide mechanisms such as indexing - which the Nodal protocol could however also provide on top of nostr or SOLID.
Tasks will have very flexible key-value attributes with some agreed-upon basics. Depending on these, tools might treat them differently:
- A calendar only shows tasks that have a start and end time set
- depending on the calendar, it might only show it when a specific time is set rather than a full day
- on the other hand, a GANTT chart which is essentially a more high-level calendar view might restrict itself to showing full-day tasks ("milestones") and including shifted estimates based on work progress of subitems
- A dicussion/teamchat tool may use the task title as subject for the discussion, with comments to the tasks as posts within that discussion
- Meanwhile not every discussion may be linked to a task, that could be determined in Zulip for example through the stream it is posted in or from keywords - this is up to the chat tool, how it forwards that information to the backend (relay).
It is important here that this is not an opt-in mechanism like existing workflow automation tools. A developer checking the task manager must be sure that all relevant information from the teamchat tool will be available with the tasks so that they can trust the application enough to solely rely on it. Yet when this is achieved, it can lead to great productivity gains, as an application focused on communication can quickly become a distraction when the goal is focused work. But in the current work environments, such is almost impossible to avoid unless considerable duplication efforts are made.
Interface
Upon the protocol, we want to actualize new application possibilities and design concepts in addition to the one outlined above within Vikunja, and with the protocol also usable across tools.
One such application is fairly simple and its development can already start independently of the other project parts: A messaging app which lets you send a task as a message - like a simple task checklist but embedded in a chat, elevating the already existing usage of many people to a new level: Frequently I have seen shopping list groups, myself jotted down tasks in saved messages, because separate tools are often too clunky and require a context switch. This application neatly solves that by integrating both intelligently.
That is already supposed to happen on top of the nostr protocol, but unlike the full Nodal concept, only requires definition of a custom task message type and subsequently implementation of an own client, which should be fairly easy using an existing NDK (Nostr Development Kit).