project status?

[pierreozoux]

When I see a project with no commit since more than a month, I'm always sad...

Can you provide us the status of your project please?

I hope everything is fine!

Best,

Pierre

[xeoncross]

Lots of great projects don't get a commit for a month. Real-world software sometimes doesn't get updates for months at a time.

I'm not sure how to say this nicely, but It's kind of vain to ask the developers to provide you with a custom update. Who are you again?

[HLFH]

Who are you again?

@pierreozoux is the amazing guy that empowers users with an ethical hosting solution: IndieHosters. If you want to contribute, don't hesitate to help here; In the French open source community, you have an article that promotes this open hosting solution in the great effort of redecentralizing the Internet.

[felixhammerl]

all i can say is that tankred, andris and me are no longer at whiteout, as you can guess from our linkedin profiles and the absence of commits...
please note that i can't speak for whiteout about how the company plans to handle this...

[pierreozoux]

@xeoncross yes, great software don't receive commits anymore. I believe it's been some month ls didn't receive any commit, and I still use it every days :)

Thanks @HLFH for the kind presentation, I would have just say, that I am an infrequent user that recommend whiteout as a mail client to people that need crypto.

I was just asking because, in my opinion a mail client should have #373 to be usable on a daily basis.

Thanks @felixhammerl, I think I got it. I hope mailpile will soon provide an easy installer :) Or maybe, I should just try mailveloppe to see if it is recommendable.

@xeoncross now you got my curiosity, who are you in relation to whiteout?

Will there be some updates on the official website/blog?

[xeoncross]

@pierreozoux I'm nobody. Your ticket title simply sparked my interest. :)

[HLFH]

@pierreozoux I know for sure that you support ownCloud hosting with IndieHosters, that ownCloud Mail will get an integration with the ownCloud CardDAV server in the 0.4 milestone and that RainLoop webmail (OpenPGP & CardDAV sync already supported) fully works with ownCloud 8.2. Mailpile is still unstable and does not support CardDAV sync.

[pierreozoux]

@xeoncross even ls get updated regularly :) http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=history;f=src/ls.c;h=2ae548d996b236660c6cea10293a31c674c21f01;hb=HEAD

@HLFH yes I'm also following closely ownCloud mail.
I'm not sure about RainLoop, I don't like much their licensing options. As I'm kind of commercial, I don't exactly know what apply to me or not.
I'm also looking forward the new roundCube.

PS: to the actual maintainer of the repo, I think we can close the issue once the situation is clarified on your blog.

[HLFH]

@pierreozoux ownCloud is under AGPLv3 license. RainLoop is under AGPLv3 license. The ownCloud Enterprise Edition is under ownCloud Commercial License. The RainLoop Enterprise Edition is under RainLoop Software License. AGPLv3 allows Commercial use. The only issue IMHO is the background of RainLoop with AfterLogic WebMail but they are now two complete different projects. Some LinuxFR guys were saying that RainLoop is not open source, they were right in the past, but since 6 months, the community edition has now good licensing options with AGPLv3. You could also read this FYI and this.

[pierreozoux]

Thanks @HLFH for the pointers, it is what I remembered from rainLoop, but indeed now it is better.

[felixhammerl]

for what it's worth: i heard that there is an official announcement in the pipeline on the future of the company and this project in particular...

[felixhammerl]

FYI: It is official, whiteout as is exists today will cease to exist by the end of the month. which will spark an even more interesting discussion about if and how this client can live on :)

https://blog.whiteout.io/2015/11/30/end-of-life-for-whiteout-key-service-action-required/

[pierreozoux]

Thanks for the follow up!

I hope somebody would be interested in continuing your action and continue developing these pieces you created

Thanks for the great work!

(I'll continue yours by hosting free software for people ;) )

[tanx]

An update from my side... Whiteout Mail under it's current name and GitHub Repository will not be continued. We're currently developing a fork named 'hoodiecrow' which is aimed at Gmail users and integrates the RESTful Gmail Apis instead of the full IMAP/SMTP stack.

Encrypting is as easy as before with PGP public key lookup via direct requests to wellknown HKP servers and a trust-on-first-use workflow. Private key sync between devices is also still possible and now optional.

Instead of being installed as a Chrome App (which have been deprecated for mobile platforms) users can install a progressive web app on their device's homescreen via the new Service Worker apis.

It's still a WIP but you can try it out and find the code here:

Homepage: https://hoodiecrow.com
GitHub: https://github.com/tanx/hoodiecrow

[HLFH]

It's not a fork. It's a completely different project that does not follow at all the same purposes, at least for the openness.

[tanx]

It's not a fork. It's a completely different project that does not follow at all the same purposes, at least for the openness.

Hence the new name ;)

No but seriously. Most users complained about performance and buggyness of the app. Building a complete IMAP/SMTP stack in JS is really hard, especially with buggy tcp-socket apis (or none at all) depending on the platform. On iOS for instance, the app was so slow that it was not usable and the App Store reviews were terrible to prove it. Rather than have an app that tries to be everything to all people, I'm trying to build something that at least a fraction of the users (Gmail in this case) can and will actually use.

The beauty about open source is though that if you disagree, you're perfectly capable of building your own fork. I just can't recommend using TCP sockets on mobile for JS apps and would advise against it.

[HLFH]

@tanx Thanks for the details and good luck for your project.

[felixhammerl]

For those relying on IMAP/SMTP and not using Gmail, I'm in the process of creating an app based on electron, although I'm kinda busy at the moment (new job) and will disclose as soon as there's something to see and try out. But this will take at least a couple of weeks.

[xeoncross]

So do you blame the Cordova TCP plugin implementation for the slow
performance? Other non-Cordova apps seem fine.
On Fri, Jan 8, 2016 at 6:37 AM Felix Hammerl [email protected]
wrote:

For those relying on IMAP/SMTP and not using Gmail, I'm in the process of
creating an app based on electron, although I'm kinda busy at the moment
(new job) and will disclose as soon as there's something to see and try
out. But this will take at least a couple of weeks.

—
Reply to this email directly or view it on GitHub
#405 (comment).

[felixhammerl]

I'm not saying it's prohibitively slow, but there no way to do STARTTLS properly. That's currently broken and the bug is not being fixed. For 2 years. Neither in Chrome, nor in cca. They just don't care enough as there's probably not enough apps out there leveraging it.

Second, IMAP was not built for mobile. If you're Apple, you can probably make it work, but if you're a 2 person engineering team that builds for multiple platforms ... not so much. IMAP is a stateful protocol with lots of overhead, it was designed for steady (albeit not necessarily fast) connections, not for flaky 2G connections that can break up at any time without you noticing. This can be worked around, but it's a bad starting point. REST is just the better paradigm...

[tanx]

Yes! On top of that Cordova on iOS still does not use WKWebView. So no JIT for you!

[felixhammerl]

FYI:

https://github.com/MobileChromeApps/mobile-chrome-apps

The Chrome Apps for Mobile Toolchain is no longer being actively developed. We intend to keep it functional, but do not intend on adding any new features.

[tanx]

This was to be expected. The Chrome team's new strategy is clearly on progressive web apps. They explained this at the Chrome Dev Summit. That's why Hoodiecrow is basically just served via GitHub pages. Anyone can fork the repo and host it on their own gh-pages branch.