Hello all! This is the third update from the Haiku Promotion Team.
As you have noticed, Beta3 has been released! Huge shout out to kallisti5, who was the release coordinator for Beta3. Making a major release of Haiku is a daunting task to all involved!
Hello!
Aren’t Atlassian tools closed source? Personally I prefer if Haiku work is done using open source software when possible.
For example (and if Trac really doesn’t work for what you want to do), what about https://kanboard.org ?
We could set this up on the Haiku infrastructure or I can host it on my personal server if you want (in fact I already have it set up there).
I see that you mention that Mail uses “an older protocol” and I’m curious about it. As far as I know we implement both IMAP. POP and SMTP, and these are still the protocols in use by mail servers everywhere. Sure they are old, but they are not outdated. (and also I find it strange that the promotion team gets to talk about such technical things and blames the developers for not caring enough about the applications 
)
Not speaking for/agreeing with them, but vis-à -vis mail, I figure they mean the encryption/security is quite outdated on Haiku’s in-built mail app, so many modern services like GMail refuse to work with it or require warning-laden security exemptions before they will connect.
Edit: It seems GMail’s protocols are actually nonstandard, and this is why Haiku Mail has issue with it. Obviously it would still be nice if it worked, since it’s the biggest provider in the world, but still, more Google’s fault than Haiku’s.
GMail does not use standard authentication methods (sending a password over an encrypted SSL connection) and instead requires to open a web page in a web browser to log in. This is not Haiku’s fault, they use a non-standard method.
Yes, but preferably we used something that is FOSS.
Well, Trac actually has a kanban plugin we can use (it hasn’t been updated in years though), so that’s one option. Trac is preferable since we can just use something that is already maintained by our sysadmins and not have to install/maintain something else.
It was never my intention to blame any developers, just saying that the apps have been neglected and need some attention. There are many aspects of Haiku needing attention and developers are understandably really busy.
I probably should have noted what the actual message from Google was, but I’m pretty sure it’s what @pakyr mentioned about encryption/security since Google required me to enable access for insecure apps.
In hindsight, maybe that wasn’t such a good example. In regards to UI, I remember searching everywhere for a button to attach a file and remember it being called something really strange.
Quite honestly google is just wrong here, we support tls 1.3 and 1.2 with smtp and there is nothing wrong with that, “your app is insecure” is a great way to try and get you to use their clients.
I’d agree here, I wouldn’t be happy about any call for contributions trying to direct devs, and I don’t like the promotion team trying to set a focus for the next release either. I’ll work on what I want, which will probably include the mail app, but most of it will be stuff I care about personally.
Google does not actually require this; they also allow IMAP connections (see here), and I currently use GMail with Sylpheed, a client that does not support Google’s online sign-in. Haiku’s Mail also does not work with Outlook (which also does not require web sign-in). So that’s the two most popular email services in the world, which Haiku’s default client does not support. I understand that there is little developer time to fix things like this, but nonetheless they are issues.
Edit: After checking, I am partially wrong about Outlook. The reason it never worked for me is because the server addresses the client automatically fetches when you type in your address are completely wrong. However, if you correct these yourself using info from the MS website, then it starts to work. In any case, whatever mechanism that fills in the server addresses seems to be broken. This did not fix GMail, though.
As I said earlier, I’m not blaming developers but just saying that a couple of the apps could use some attention 
Personally, I’m still trying to understand how exactly the development process in Haiku works, I always assumed the devs decided what was in each release etc. and followed some sort of development list so I apologise, it was never my intention to trod on anyone’s toes.
Of course, the Team aren’t trying to set a focus for the next release, but asking others to think about what they’d like in the next release.
The call for contributions idea was not intended to direct developers but rather try and see if any new contributors were interested in helping out.
I mentioned that Mail app is designed in a POP logic way. IMAP works but in a strange way I think.
I don’t care at all about Gmail. For me it’s the last thing to worry about. I don’t use FOSS apps and keep stuck on GAFAM services… It’s nonsense for me.
Here is the documentation from Google: OAuth 2.0 Mechanism  | Gmail IMAP  | Google Developers
The idea is:
So, it’s just a more complicated way to send the password.
Why they do this? Because it allows them to more easily send a notification to your android phone saying “hey, this new app wants to connect to your account, do you want to allow it?”. The HTTP request contains more info and allows to identify the app. It does not mean you have to see a webpage and enter your login there, still. The app knows your password and can send it directly. This also allows them to do two-factor authentication if you have enabled that, etc.
Still, it is not the standard POP/SMTP/IMAP mechanism. Other apps have complied with Google non-standard choices. We have not done the work yet.
I agree it should be done, but saying we use outdated protocols is incorrect. It’s Google using non-standard protocols, and adding extra work for us. And they blame us by saying our application is unsecure, when in fact, it isn’t, it’s just that they were too lazy to implement something in their mail server that could trigger the same things they trigger when an app goes through the HTTP route. But instead they decided that everyone should change how to write an email client. And since they have a huge market share, all email clients had no real choice but to do it.
Fair enough, mea culpa for using the word outdated. Obviously it would be nice if it worked, but I guess it’s understandable that there isn’t yet a nonstandard implementation for a single service, even if it is GMail. That said, I think it would be a good idea for the autofilling of the servers when you enter an address to be either fixed or disabled, since it doesn’t seem to work properly. I would never have thought Outlook didn’t work if it hadn’t filled the wrong servers in.
The mail app can indeed use a better autoconfiguration.
For example I think we should try TLS per default, first in strict mode and then in plain+startssl mode and just remember which worked and set that.
Also prepending smtp. and imap. to the domain should be the second step for domain config, with the naked domain beeing the first etc. In general we should just try severall things instead of trying to prefill server fields with a single best guess that users might not have any idea how to use.
And if we’re writing a wish list, then HTML email would be nice as well. I know this is a long way off, since (if my understanding is correct) other applications can’t really use HaikuWebKit yet, but it would still be a nice modernizing feature when it becomes possible.
Yep, other items that will be able to use haikuwebkit are a epub reader (it’s “just” zipped html files), aswell as MediaPlayer (for WebVTT subtitles, they kind of have inline css and html)
We can probably do this when we have a native api utilizing the webkit2 api and multiprocess architecture.
I’d agree here, I wouldn’t be happy about any call for contributions trying to direct devs, and I don’t like the promotion team trying to set a focus for the next release either. I’ll work on what I want, which will probably include the mail app, but most of it will be stuff I care about personally.
Personally, I like the promotion team’s idea. I feel like just showing what needs to be done will attract contributors. I think this idea is directed towards new people joining, more than towards already existing developers.
Some of the tasks seems small. For people that aren’t quite familiar with the codebase and want to contribute, that seems to be a great starting point. Also, working in details polishes the overall experience in Haiku.
That would make sense to me. People who want to do something, but aren’t confident enough to dig into the guts of the OS.
This is badly wrong. GMail needs OAUTH2 bearer tokens, but these are a completely standard authentication method. RFC 7628 explains how to authenticate to GMail or other services that need OAUTH2 bearer tokens for SASL using OAUTHBEARER. That document is a six year old product of KITTEN. If Haiku took security seriously somebody would have maybe noticed that work during the eleven years since it was first written up for KITTEN.
For Haiku - with at least a somewhat usable web browser and little else to speak of - it may be easier to just spin up a whole web browser to “log in” to GMail. Millions of GMail users are used to systems where it’s much less painful to do this. It wouldn’t work for people like me anyway (without setting an exemption to allow Haiku to access my mail insecurely) because Haiku’s “WebPositive” lacks the features needed to authenticate me, but most Haiku users won’t notice. None of this is because of GMail using “a non-standard method” it’s just that once again Haiku is catching up to the state of the art circa 1995 and everybody else moved on.
Blurting out passwords was a reasonable authentication mechanism in the 1970s, but fifty years later you need to do better if, as other threads indicate, Haiku developers think real users should choose Haiku.
Thanks, it’s good to know that at least they documented the process in an RFC.
No, we should do the real thing and there is no problem in doing it. Just someone needs to do the work.
I probably won’t do it for two reasons:
I think the developers are pretty clear about the fact that we are in beta phase and clearly not ready for a R1 release. But users seem to ignore that and put “unreasonable” expectations (from the point of view of available developer time to do things). It’s the difficult situation of being “almost there”, you know, when a project is 80% done and all you need to do is the other 80% of the work.
No one had created a ticket about this (maybe it is not all that important after all, if no one put the minimal effort of creating a ticket?), so I did it: #17149 (Implement oauth login for GMail and other modern providers) – Haiku