Over the past two years we’ve been laying the ground work towards the first goal of a simple and beautiful mail client.
By now we have the first few releases out, and the closer we get to our goal, the less clear becomes what the next goal on our roadmap is.
So here’s something that we’ll be focusing on:
An obvious reason why we picked Kolab Now is because it is what sustains the larger part of the Kube team, allowing us to work on this project in the first place. However, it’s also a prime example of a completely Open Source and standards compliant service. Improving the Kolab experience means improving IMAP support, improving the CardDAV implementation, perhaps even adding CalDAV. It also means implementing proper GPG support, and pushing the user experience edge by edge to where we expect it to be. Things that all standards compliant services will benefit from. The Kolab Now service ensures we can focus on the relevant problems by taking variables out of the equation by being essentially the reference installation of Kolab.
Now, this means that we’ll be putting a little more focus on the single account experience, it does not mean we’ll be dropping support for multi-account setups though. The develop branch (which will lead to the next release) will continue to support multiple accounts and account types. What we will do though is acknowledge that very little testing is happening with other services than Kolab, and that we will probably not prioritize any features that are exclusive for other services (such as GMail’s non standard IMAP behavior) in the near future. It’s about focus, not exclusion.
There are many other goals ahead of course, that’s not the problem. Various platforms to be conquered, CalDAV access to our calendaring data, perfecting the mail experience, a beautiful calendar view, working out the grand scheme of how we tie all these bits together and produce something unique… Lot’s of exciting stuff that we’re looking forward to be working on!
However, it’s also easy to get lost in all those possibilities. It’d be easy to hack together some half-baked implementations for a variety of those ideas, and then revise those implementations or just pick the next bit. But that doesn’t lead to what we want. We want a product that is actually used and just works, and that requires focus. Especially since we’re a small team, it’s more important than ever that we maintain, if not increase, our focus. Kolab Now gives us something to focus on.
Kube for Kolab Now
With that said, I’d like to announce the Kolab Now edition of Kube, that we’ve made available as an early access release.
This is a completely separate release-stream that supports Kolab Now exclusively, and does not replace general purpose Kube releases. But it is not a separate codebase (For simplicity there exists a kolabnow release branch with a two-line patch, but that’s all there ever will be).
We’ll regularly update this release to share our latest developments with you.
If you already are, or would like to become a Kolab Now user, then you’re welcome to join us on our journey to bringing you the best possible Kube experience to your desktop. You’re not only going to profit from a great service, but you’ll also help sustain the development of Kube.
For future updates, keep an eye on blogs.kolabnow.com
Finding New Ways... 
Is there already a place to report bugs?
After configuring my 3 accounts (gmail+ymail) and restart the computer, I can not use kube anymore. There is just a non working “login” button and on the terminal:
Log: {aca028a3-f7f8-43e3-9307-dbdb16f25640}.synchronizer : Secret not available but required.
Log: {d05b9960-3b18-412e-928c-7998f975ab15}.synchronizer : Secret not available but required.
Log: {73f444c3-4cff-438e-afc7-0b53364439c2}.synchronizer : Secret not available but required.
Log: {700c147e-5556-439b-835a-1ddcc47f63f8}.synchronizer : Secret not available but required.
Log: {c92e9b6a-9e46-4446-afbb-56d613ada1fe}.synchronizer : Secret not available but required.
Log: {02c52d2b-f987-4fc7-a685-faff95c60e1b}.synchronizer : Secret not available but required.
Log: {02c52d2b-f987-4fc7-a685-faff95c60e1b}.synchronizer : Secret not available but required.
You can report bugs here:
https://phabricator.kde.org/project/view/238/
This is interesting.
I’d strongly suggest testing accounts against Fastmail too as much like Kolab Now provide a rock solid implementation of imap, complete with special-use, carddav and caldav as they run CyrusIMAP.
Sticking to open standards and the specifications which benefit everybody is definitely the way forward rather than catering for obscurities like gmails non standard way of imap support.
+1 to FastMail support too. And for a Snap or AppImage package.
Yes. But then by following open standards, and not making things Kolab specific, kube should work with both fastmail and Kolab.
Kolabnow isn’t the perfect imap server
1) weird groupware Folders
2) where’s special-use?
3) where is the archive folder?
While there is no perfect imap implementation fastmail comes pretty damn close.
So testing across multiple candidates which follow good standards is the way forward rather than choosing only one benchmark. Point in case: Christian has a fastmail Account
Kolabnow and Fastmail use the exact same IMAP server, which is cyrus imap. Certainly every service has it’s pros and cons, and Fastmail is a great service too, nobody is disputing that.
I think I’ve made clear that this is not about exclusion, but picking our battles. If somebody feels inclined to test other services, carry on, it certainly helps the overall product quality.
I also happen to know that Kube in fact works with Fastmail, so maybe I’m just missing the point.
The point i’m Trying to make is that by building a standards-compliant client, it ought to work with any standards-compliant service.
I’m not sure from your blog if you’re trying to build a Kolab client which just happens to work with other services, and whether testing with other services will come later as Kube reaches a wider audience or a standards compliant client but Kolab just happens to be the one you test with most for convenience
What would be a Shame is I see concessions made for Kolab where it falls short, so for instance would Kube not support archive folder and also special-use because Kolab Now doesn’t for instance? Hope it’s clarifies as it’s not explicitly clear
We’re not building a Kolab Now specific client.
There’s however a myriad of standards that we can support, so just saying that because Fastmail supports a certain feature Kube therefore has to as well is not really an acceptable argument either.
We’re going to keep working on a good user experience, and we’ll try to keep it working as best as we can with services complying to standards, but we have to put our focus somewhere and that’s going to be on the service that actually ends up funding the development of the client.
Thanks for your clarification. I agree with what you say – if you were to incorporate features of every service, you would end up with a very bloated client, and as you say you are focusing on a inclusivity rather than exclusivity. Supporting Gmail’s non-standard IMAP implementation is not a good use of resources, and stands to benefit.
But then implementing IMAP/CardDAV/CalDAV specs should simply mean inter-operability with a service which supports these implementations, but then again there are certain service specific features.
What I’m trying to get at though, is that, where possible, Kolab should also improve in such a way that it implements open standards too in such a way that it benefits everybody – not just users of Kube. SPECIAL-USE (RFC 6154) makes configuring clients considerably easier (particularly iOS mail) and prevents duplicate folders for Sent, Trash, etc being created. It also means that you don’t have to take into account specific metadata for Kolab in Kube, because it uses an RFC.
Also, an archive folder is a service which most IMAP accounts come with by default, so this should (hopefully be a non-negotiable). Kolab Now is a great service, but hopefully building Kube using IMAP/CardDAV/CALDAV principles will also benefit Kolab Now to become a service which supports open standards than it does now (and it does a pretty good job as it does already) by pushing Kube to follow the specifications. But the occasions where Kolab hasn’t followed a standard is far and few between. Anyway, standards like JMAP are catching on and I’m sure this will make things better.
And by optimising things for Kolab Now, such that account creation is particularly easy is by no means a bad thing. But please pass my feedback on regarding RFC 6154 and Archive folder.
Hope this clears things up now.
So, we won’t see a situation like OUTLOOK which supports EXCHANGE, but does IMAP in such a bad way, that it probably shouldn’t even bother doing so (joking haha). So far more and more people set their gaze on open standards… 🙂
But taking a look at the mess we now find ourselves with, with the need to invent GUAM, and the fact that it is struggle to get it running in production, because Kolab exposes groupware folders over IMAP. Though an extreme example, and granted there is an RFC for this, this sort of situation arising again can be avoided by following common/open standards.
And since you mention funding, it’d be cool to see users being able to donate. I for one haven’t got a problem giving $50 a month to something which is going to benefit a whole lot of users, improve the Kolab service, etc. Roundcube does this, and look where we are at now. A great client, and though the elastic skin is in very early development, it is beautiful. When all Kolab plugins are updated, this will be a game-changer. (though I digress, Roundcube Next is somewhat of a sore subject)..
Anyway, Kolab is doing great right now, and since Jeroen has taken over as CTO there have been improvements almost weekly.
Rest assured this is what we’re working on. Kube for instance uses CardDAV instead of the Kolab folders to get access to contacts, for that exact reason. There’s certainly room for improvement on the server side as well, we’re working on that.
Right now we don’t have a way to accept donations unfortunately, so the best way for the time being is using Kolab Now and supporting us through that, or donating to some of the sprints we’re being part of. I’ll look into improving that situation.
Have tried the Kolab edition on a friend’s Ubuntu machine and I greatly enjoyed using it for 20 mins.
The UI is very intuitive and pleasant to use.
I noticed Kube filters out my Kolab Now groupware Folders even though guam isn’t running? Does it understand to filter them out natively? Weird.
Glad you liked it =)
Yes, the IMAP resource filters out groupware folders. Not ideal that we require that, but it’s simple enough to do and we currently do require it, as you know.
Really enjoyed using it, now thinking of running a virtual Ubuntu machine on my Mac just so I can test further though it’s a lot of work…
So potentially, when GUAM is running in production – this code can be removed/made redundant? I can’t see that it would add any performance issues to Kube 🙂 In the meantime though, it doesn’t make much difference as it won’t make much difference for non-Kolab IMAP servers, but certainly a better experience for those who use Kolab Now 🙂
Keep up the good work!!
If you have any experience with building stuff on Mac, help is welcome to accelerate that process =)
Yeah, the folder filtering is a stop gap solution for the time being, which makes sure that Kube works as expected with all deployments, with or without GUAM.
I would also be happy to donate to Kube much in the same way I can do to with Roundcube, even if was 100 Euros a month, if this helps, even if it’s just for Pizza.
So far, I am enjoying using Kolab Now and the Elastic skin being developed by the roundcube guys is one of the best I’ve had the joy of using, and to think this is the beginning is exciting. Further, a lot of new features to Kolab Now have been coming in like 2FA, CloudSuite integration, (Guam – in progress), three-column view, and to think this is all opensource software is great.
Do you foresee Kube implementing JMAP support in the future or is this more likely to come later on when Roundcube Next is further along in development and Kolab Server has some JMAP support (if it doesn’t have already). I understand CyrusIMAP 3.x is finalising JMAP support as the spec reaches finalisation, and so i’m not sure if this means Kolab will natively get support for JMAP (or at least the mail part, anyway – as I’m aware that the DAV implementations were added to Kolab when CyrusIMAP didn’t already have these, and so now they are fragmented)
The future is exciting – keep up the good work, and yay for free software!
Thanks for the offer =) For now supporting Kolab Now is definitely the best way you can help Kube (and Kolab Now of course).
JMAP is definitely further out on the horizon. For now we focus on more widely available standards such as IMAP and DAV. There is indeed consolidation potential on the Kolab server now that Cyrus IMAP has native DAV implementations, it would mean getting rid of the Kolab groupware folders though (not a bad thing IMO, but work ;-).
Thanks for your input!
Regrettably no experience buildig on Mac.
Supporting IMAP and DAV is the way forward. JMAP is still developing, but apparently supposed to be more sever-friendly and less server resource-intensive.
Merging Kolab with Cyrus and thus combining using the Cyrus DAV implementations sounds good – it would mean no Groupware folders, no GUAM sitting in front of Cyrus (apparently very server resource-intensive.) Read something on the Kolab Hub where 28GB RAM was almost full (presumably on the server side) due to GUAM, but then dropped to 4-6GB when disabled.
Has the idea of merging Cyrus and Kolab been internally floated? It would mean that Kolab can focus on adding real value in terms of Roundcube, improving Collaborative editing, activesync though would be a massive task, and could possibly even mean that Kolab Enterprise users may not be able to upgrade with all the under-the-hood changes. I, for one would be a massive advocate of this, and I’m sure Jeroen possibly too given that he’s the Cyrus release manager. I’d love to hear more on this if it’s up for debate.
Hi Christian
Having tried to use CardDAV implementation of Kolab Now with OS X Address Book, I noticed that groups created in Roundcube don’t filter down through the CardDAV client, but ones created in CardDAV push upwards into Roundcube. I have tested this with Cyrus IMAP native implementation and this issue doesn’t appear to occur, but not with other clients.
It is also worth mentioning that Kolab’s implementation of CardDAV doesn’t support custom fields, which Cyrus IMAP implementation does, which causes havoc with the contact in Roundcube, either it showing the custom field, and then being renamed, and just generally not working well.
These issues don’t occur in Cyrus IMAP native CardDAV implementation – have you come across them? I haven’t tested with other CardDAV clients.
I most certainly understand the benefit of testing with Kolab Now, and whilst the server implementations of protocols are not bad, it does concern me that if a bug isn’t uncovered in Kolab’s IMAP/CardDAV/CalDAV implementation – it could mean that the Kube implementation of IMAP/CardDAV/CalDAV becomes bent, as it was only tested with Kolab.
I note some comments above about Cyrus IMAP Server consolidation, – Jeroen has also said in the past:
“Side-note: Cyrus IMAP has added CalDAV, CardDAV and WebDAV capabilities, encroaching on the territory Kolab otherwise occupied, rather exclusively, for as far as the world of Free Software is concerned. As such, Cyrus IMAP provides more of the groupware functionality than I initially stated, but does not provide ActiveSync capabilities, a web-mail client interface, Resource Management, and many other facilities included with Kolab Groupware. Inversely, however, Kolab is going to need to show to be the most adaptable, and applaud and welcome and embrace these developments in Cyrus IMAP, rather than attempt to compete with it somehow.”
Put in the politest possible way, I would very humbly suggest that testing for Kube is done a handful, maybe three services – Kolab being one of them, perhaps a generic Cyrus IMAP server with CalDAV/CardDAV running, and perhaps another good quality of implementation. This will give you more opportunity to find bugs, and of course improve the Kolab Server for everyone too. I hope you will take kindly to me saying that testing with one reference model for protocol implementations is generally bad practice, but I appreciate that too many cooks spoil the broth. At the end of the day GMAIL would be a poor example of standards implemented correctly, but two or three candidate servers for testing sounds just optimum 🙂
Hope my humble feedback can be of assistance