Skip to content
This repository has been archived by the owner on Jul 10, 2019. It is now read-only.

project status? #405

Open
pierreozoux opened this issue Oct 6, 2015 · 22 comments
Open

project status? #405

pierreozoux opened this issue Oct 6, 2015 · 22 comments

Comments

@pierreozoux
Copy link

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
Copy link

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
Copy link

HLFH commented Nov 8, 2015

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
Copy link
Member

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
Copy link
Author

@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
Copy link

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

@HLFH
Copy link

HLFH commented Nov 8, 2015

@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
Copy link
Author

@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
Copy link

HLFH commented Nov 8, 2015

@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
Copy link
Author

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

@felixhammerl
Copy link
Member

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
Copy link
Member

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
Copy link
Author

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
Copy link
Member

tanx commented Jan 8, 2016

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
Copy link

HLFH commented Jan 8, 2016

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
Copy link
Member

tanx commented Jan 8, 2016

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
Copy link

HLFH commented Jan 8, 2016

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

@felixhammerl
Copy link
Member

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
Copy link

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
Copy link
Member

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
Copy link
Member

tanx commented Jan 8, 2016

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

@felixhammerl
Copy link
Member

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
Copy link
Member

tanx commented Jan 9, 2016

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants