Michael first blogged about Kube, but we apparently missed to properly introduce the Project. Let me fix that for you 😉
Kube is a modern groupware client, built to be effective and efficient on a variety of platforms and form-factors. It is built on top of a high-performance data access layer and Qt Quick to provide an exceptional user experience with minimal resource usage. Kube is based on the lessons learned from KDE Kontact and Akonadi, building on the strengths and replacing the weak points.
Kube is further developed in coordination with Roundcube Next, to achieve a consistent user experience across the two interfaces and to ensure that we can collaborate while building the UX.
A roadmap has been available for some time for the first release here, but in the long run we of course want to go beyond a simple email application. The central aspects of the the problem space that we want to address is communication and collaboration as well as organization. I know this is till a bit fuzzy, but there is a lot of work to be done before we can specify this clearly.
To ensure that we can move fast once the basic framework is ready, the architecture is very modular to enable component reuse and make it as easy as possible to create new ones. This way we can shift our focus over time from building the technology stack to evolving the UX.
Sink
Sink is a high-performance data access layer that provides a plugin mechanism for various backends (remote servers e.g. imap, local maildir, …) an editable offline cache that can replay changes to the server, a query system for efficient data-access and a unified API for groupware types such as events, mails, todos, etc.
It is built on top of LMDB (a key-value store) and Qt to be fast and efficient.
Sink is built for reliability, speed and maintainability.
What Kube & Sink aren’t
- It is not a rename of Kontact and Akonadi.
- Kontact and Akonadi will continue to be maintained by the KDEPIM team and Kube is a separate project (altough we share bits and pieces under the hood).
- It is not a rewrite of Kontact
- There is no intention of replicating Kontact. We’re not interested in providing every feature that Kontact has, but rather focus on a set that is useful for the usecases we try to solve (which is WIP).
Development
Development planning happens on phabricator, and the kdepim mailinglist. Our next sprint is in Toulouse together with the rest of the KDEPIM team.
We also have a weekly meeting on Wednesday, 16:00 CET with notes sent to the ML. If you would like to participate in those meetings just let me know, you’re more than welcome.
Current state
Kube is under heavy development and in an early stage, but we’re making good progress and starting to see the first results (you can read mail from maildir and even reply to mails). However, it is not yet ready for general consumption (though installable installable).
If you want to follow the development closely it is also possible to build Kube inside a docker container, or just use the container that contains a built version of Kube (it’s not yet updated automatically, so let me know if you want further information on that).
I hope that makes it a bit clearer what Kube and Sink is and isn’t, and where we’re going with it. If something is still unclear, please let me know in the comments section, and if you want to participate, by all means, join us =)
Finding New Ways... 
Thanks. Would be useful to reiterate (the short definition) at the top of follow-up posts. (People don’t look this kind of stuff up, they don’t understand and move on right away.) For casual readers, this makes it way easier to get familiar with the Kubes and Sinks.
“Sink is not a rename of Akonadi”, but I think it is a rename of what once was Akonadi-next, right ?
If so, is the plan to finally also move the current PIM/Kontact code from Akonadi to Sink ?
The project started with the name Akonadi Next, yes. There are no concrete plans on porting Kontact to Sink, and this would definitely result in a major effort, so I’m not currently expecting for this to happen.
So is the Akonadi Next project gone then? And does this mean if, for example, Plasma uses Akonadi for its calendar while I use Kube for everything else, I need both Akonadi and Sink running and syncing my details?
If so, it seems Akonadi’s original goal of being a one shop stop for all my PIM data needs is gone.
Yes, Akonadi Next as a project is gone (it’s called Sink now). How the desktop integration is going to look is not yet clear, but if you have to sync the same data over akonadi and sink something went wrong.
I think the options are that either the calendar plasmoid gains support for kube/sink, or there will be a kube plasmoid.
Whether you want to use a solution based on akonadi or sink is of course entirely up to you, but unless you actually want to use akonadi based applications and kube on the same dataset you won’t have to have two copies of it.
The Link for Roundcube Next, does not work, it is https://cmollekopf.wordpress.com/2016/03/02/so-what-is-kube-and-who-is-sink/roundcube.net instead of https://roundcube.net.
https://roundcubenext.com/ should be mentioned, imo 😉
Yes, thank you =) Should be fixed now.
Would you care answering some question , regarding the Kube and sink ?
I understand sink is not really akonadi , nor is kube will be a a recplament to kontact but how are kube and sink are going to work with old data ?
Today 1 mb of dIMAP will hold around 2mb of disk space (kmail dir and akonadi dir).
When a user will switch to sink+kube , can we assume data reusage from the akonadi files or should we expect a second data download ?
if what are the current disk space considuration for dIMAP and others ?
2. i18n – is kube/sink expected to support non latin script (search / show /reply / new mail etc) ?
3. will sink allow accessing the information with a standrad interface such was presented by kolab “Akonadi Control Server” or the so called ServerSideAkonadi ?
4. will sink have the posibility to interact with LDAP[s] ?
5. will sink have the posibility to interact with corporate services such as ( from Exchange / Office365 / google hosted / webdav[s] / caldav/cardav) ?
Will thes protocols will be supported (for emails) ?
POP3 ?
IMAP* ?
Malidir ?
Malibox ?
webdav[s] ?
soap based ?
Exchange ActiveSync ?
SyncML ?
6. Calendar –
will kube allow diffenrent week day format (EN_GB , he_il etc) ?
will Calendar allow syncing data from online calendars (caldav , google , outlook365) ?
1. If you have your data in a maildir or alike you can of course reuse that. We cannot reuse the indexes etc of akonadi. Generally speaking there is very little point in having the same data in both akonadi and sink, so this is not an area I’m interested in “optimizing”.
2. I would hope we can get there at some point. It’s not my area of expertise though, so we’d likely require some help with that. Also, it won’t be the focus for the first milestones, but it would be interesting to know which precautions we have to take to simplify this in the future.
3. Sink is an abstraction layer for various backends, so in principle it can be hooked up to anything. Server-side akonadi is not on the roadmap of kolab, so that specifically won’t happen I think.
4. I’m not sure yet whether LDAP support of Kube will go through Sink or not, but it might. In either case, it’s very very likely that we’ll add LDAP support to Kube.
5. The number of protocols supported will also depend on whether somebody is willing to step up and implement them. The focus is clearly on open protocols, and we’ll likely see Maildir and IMAP as the first supported ones.
6. I don’t know the implications yet of supporting different week day formats, but I’ll look into it. Calendar syncing will again focus on open protocols. I think we’ll see ical files (.ics), caldav and kolab as the first ones to be implemented.
Thank you , and a further questions .
1. what are the export/import considurations ?
I mean how hard it will be to me to import (migrate?) existing data without downloading it from the internet , and will be able to easly export it to be used by other clients ?
I mean a mobile 3Gb package cost ~₹1100 (which is apprximatly 6% of a monthly salary), and broadband can be expected to cost for around ₹2500. and If I already have the data in .local/share/akonadi/file_db_data (the cache which never get deleted ) it would be a great feature during migration to use it and not download it from the internet again.
2. Are there any plans to reuse or somehow interact with the already existing akonadi agents to inject data into sink (email content)?
3. I listed the protocols which are used in windows envoirments (some already have existing akonadi plugins), do you belive that kube for windows will be created in a way that we could use it to work with service providers.
Are there plans to support windows 7 , or you are going directly to the win10 approach (UWP) ?
1. Priority might change, but import export is not something that I consider a core feature of Kube or Sink. Sink always stores it’s data in some or the other backend, and the backend should IMO be responsible to offer import/export, respectively, this can happen over a separate tool.
If you need to save on network data I suggest you take a backend that minimizes network usage. E.g. if you have your mail available as a local maildir (i.e. via offlineimap), then you won’t run into this issue at all.
2. no
3. Not sure what you refer to with “service providers”. Kube on windows will be very much like kube on linux or mac, as a regular cross-platform application. Integration into the desktop environment will be done in a future iteration.
So, to sum it up:
If you relied on using Kmail/Kontact, we are showing you the middle finger and good luck will all the data you thought was safe and future-proofed by using Akonadi (important mails, accounts config, notes, etc…).
Well done, again.
I don’t know where you read that, but I’m happy to clarify if there are open questions.
Is Kube expected to support office365 IMAP accounts on windows ?
current stats for online mailbox are :
1. up to 50 GB
2. up to 1 million messages per folder
3. folder depth of 300
4. 10K subfolders.
https://technet.microsoft.com/en-us/library/exchange-online-limits.aspx
Will Kube support office365 addressbooks (GAL) ?
Thank you for your blog updates. I think this project is so necessary. How will this compare to the owncloud /nextcloud mail app thats being developed, in other words will it bring anything new or better? What are your thoughts on the project, and on the horde libraries they use
What’s the project license? Not sure I’d like an idea of contributing to smth with “License TBD” in the readme.
Thanks for pointing that out, I updated the readme now.
The license of Kube is GPLV2+ (so GPLV2 or later), and Sink (the data-access layer) is LGPLV2+.
Link https://api.kde.org/doc/sink/building/ returns 404 NOT FOUND
“Kube is based on the lessons learned from KDE Kontact and Akonadi”
Well, ANOTHER “hey, let’s rewrite everything from scratch” project means that no lesson has been learned at all.