Better integration of different services

Rather than introducing new features, I would like to see current features better integrated together. Of course, this is easier said than done, but I believe the temporary lack of new features will be balanced by a sturdier interface and schema which will make future improvements more cohesive.

Here’s my dream:


Tasks ⇄ Calendar

  • Tasks that have a deadline show in calendar
  • Tasks without a deadline show in calendar as a full day task for every day
  • Possibility to hide a task or a list from Calendar
  • Tasks list show in Calendar lists
  • Calendar lists show in Tasks lists

Tasks ⇄ Deck

  • Tasks created in Tasks should show in Deck
  • Tags created in Tasks appear as choice of boards inDeck
  • Tasks moved inDesks see their tag changed in Tasks
  • Changing tags in Tasks changes the column the task appears in Deck. IF a user selects two tags (for example, bothtodo and done), the last one is considered
  • The Form for creating a task in both Deck and Task should be the same
  • Lists created in Tasks show up inDeck, and vice-versa

Tasks ⇄ Social

  • Tasks should be shareable:
    • to registered users
    • and/or as a public, obfuscated link, with optional edit rights
  • Tasks should support comments, so collaboration can organize around them (like Github issues)

Tasks ⇄ Files

  • Files should be “attachable” to a task. Files attached this way should not be duplicated on disk
  • If a task is shared/assigned, attached file(s) are similarly shared. A window pops up to warn the user that this will happen. The window has a little “do not show anymore” checkbox

In Summary

In summary, entries in Calendar, Task, and Deck should come from the same table and bear the exact same properties. Calendar, Task andDeck should be considered 3 different lenses on the same data.

This api should be carefully crafted so future improvements have as little chance of breaking compat as possible. Plugins should be able to reliably tap into the api so they can similarly interact with this without reinventing the wheel. The schema of { title, text, comments, tags, date } is suitable for most productivity apps (Carnet, Quick Notes) and would allow them to tap into the whole ecosystem while focusing on the interface, not the storage mechanism.

Stretch goal, probably not worth it: checkboxes created in Notes become tasks (with the document title used as list name)


Emails ⇄ Tasks

  • An email should be able to be transformed into a task. A task created this way should both show the email’s text, and bear a link to the email, so a user can simply click it to find themselves back in context, where they can answer/etc. Since a date can be attached to the task, the email shows also in calendar.
  • This functionality would be displayed as a button/dropdown combo. The button says “create a task from this message”, and simply takes the user to a task editing interface, with body already filled in, and link to the email. The user is free to edit the text and link.
  • Long-click, or clicking the arrow next to the button shows a “snooze” functionality. Clicking on this bring up a menu showing:
    • remind me tomorrow
    • remind me next week
    • remind me at specific date (choose)
  • Once snoozed, a task is automatically created, with the label #snooze.

Files & Text Editor

Text ⇄ Email

  • An email should be transformable to a text file in Files without having to select and copy-paste
  • A text or markdown file should have an option to Email, which opens the email interface and fills in the content of the file. If the format was markdown, the email uses a rich text format by default and renders the markdown.
  • The email body editor should be the same rich text editor used in File (users should be able to switch to a plain text format if they wish so)

Text ⇄ Notes

  • Notes should use the same text editor as Files
  • The new Text Editor should support checkboxes (Github-flavored markdown). This is not really related to Notes, but I didn’t know where to put it.


Tags ⇄ Email

Emails should be taggable. That’s different from “dragging to directory”, where directories are mutually exclusive, and closer to gmail’s “directories as tags”. Here’s the mechanism:

  1. When a user wants to tag a mail, a drop-down presents itself. This drop-down contains the same tags that are used in files/tasks/etc. The user also has the opportunity to create a tag on the fly
  2. if the tag exists as an imap folder, it is used. If not, it is created, then used
  3. a user also has the opportunity to “move” a mail to a selected tag (again, like gmail). This is similar to the existing functionality.

Tags ⇄ Calendar

  • Events should be taggable, and the calendar should be filterable by tags (in addition to lists).
  • Ideally, lists and tags are orthogonal, so you can select one list, then one or more tags to filter by, as well as just tags and show, say todo from all lists. Lists are mutually exclusive, tags are additive (“or” or “and” is an open question).

Tags ⇄ Everything

  • Tags should be applied site-wide (for one user, or for a group). Searching for a tag should turn up:
    • files
    • emails
    • notes
    • tasks
    • news
    • events
  • Tags thusly double as effective “workspaces”, allowing one to filter their entire nextcloud depending on what they’re currently working on. This could be extended later to a UI widget allowing to select tags as workspaces, which will feature in a prominent manner in the top banner.

That’s it! I realize this is a huge undertaking, but as I said in the beginning, I believe such a rearchitecture would make it:

  • easier for people to participate and create new apps by making the surface API smaller
  • letting non-official apps maintainers focus on their added features instead of reinventing the wheel
  • UI, UX, or bugfixes in the backend benefits all apps at the same time, rather than each separately re-solving the same problems
  • new features apply to all apps, official or not. Is there a new type of taxonomy instead of tags? All apps benefit. A new editor feature? All apps benefit. Etc.

More importantly:

  • Makes Nextcloud a flexible experience, where the user is very free to adopt an enormous quantity of different flows, while keeping the learnability to a minimum low. Do you prefer a date-based organization method? Mail-based? A mix? It’s up to you. If you decide to switch, there’s nothing new to learn. Your group uses Deck, but you prefer Tasks? No problem, it’s the same. Feel free to choose the view which you prefer.
  • Makes Nextcloud an integrated experience, rivaling, and, if all of the above is implementing, surpassing the likes of Google Drive & al in terms of inter-connectivity.

I don’t really hope all of the above would be implemented, but hopefully this sparks some discussion at least. Thank you for reading!


A lot of these things are active feature and pull requests on the various Nextcloud project Github pages. Take a look around and you’ll be able to dig into the nitty gritty.

Example: Deck app developing Caldav support, which will make it finally work with Tasks and Calendars.
And, system wide tags across all apps is an active disussion on server github page.
Recently announced Flow app will add automation of custom scripts via tags for NC 18.
Notes app is being prepped to use the same editor as text files.



That sounds really good, thanks! I’ll get digging. It’s just difficult for a newcomer to apprehend the project as it is huge, distributed over many repos. But I’ll eventually get a good grasp, I’m sure

1 Like

What about using the bounty system in order to see how the support is and see how big the support is?

We could support financially out of our project, though not really much.

While I normally do support financially every free app I use, I am currently not able to do so; my financial situation isn’t great. Even if it was not, and I could afford a $1 ~ $10 monthly donation, I still wouldn’t be able to offer suitable compensation for an effort such as the one I describe.

If you do not have money yet can provide time, you can try to provide useful suggestions to the developers.
This requires to identify the missing bits and to open clear to understand issues on Github.

As an example take:

about the " Tags ⇄ Everything" you suggest.

I do know that this requires time, as you can see by reading that page, yet I think it can be a worthwhile contribution to reach the goal you propose.

So if you have any spare time now I found you an hobby :slight_smile:

Bountysource is not only for recurring or large donations. Adding $5 - 10 to any request is totally fine, it just tells devs that you really want a specific feature!