<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">31.01.2018 u 21:20, R Kent James je
napisao/la:<br>
</div>
<blockquote type="cite"
cite="mid:4d192054-e407-356e-c58e-f52a31113c24@caspia.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p>What do people expect of their email client in the modern
world?</p>
<p><b>Big question #1: Overall scope.</b></p>
<p> I would say that the product needs to work reliably and
consistently in two dimensions:</p>
<p>1) Platform. Users expect to be able to access their
personal information on a desktop platform (at least Windows and
OSX, but we would undoubtedly also want to include Linux), on
mobile devices (at least Android, iOS if possible), and from a
web browser. (Currently Thunderbird users do this with different
apps on each platform, but there are little inconsistencies in
the behavior that makes that awkward and unsatisfying).</p>
</blockquote>
I think you are aiming to wide. Stick to desktop and do it best.<br>
If you want to expand to mobile / server, start from scratch (or
fork other open source app) with platform native environment and try
to mimic Thunderbird ideals as much as possible.<br>
<br>
<blockquote type="cite"
cite="mid:4d192054-e407-356e-c58e-f52a31113c24@caspia.com">
<p>2) Protocol. Users have a wide variety of primary sources
for information, and they expect their email client to work well
with all. That includes both open protocols (IMAP, POP3, and
SMTP for email, iCalendar and calDAV for calendar, cardDAV for
address book) as well as proprietary protocols, including the
Google suite as well as Microsoft and Exchange Web Services.
(Currently in Thunderbird, some protocols are supported in core,
others are supported inconsistently and frequently unreliably in
addons).</p>
<p>Is the goal for a future Thunderbird a product that satisfies
both of these dimensions as primary (core) goals? Personally, I
don't see that you can shoot for anything less if you hope to be
competitive. (Whether we can marshal the resources to pull that
off is another question, but related - if there is no vision
there is no hope for the resources either).</p>
</blockquote>
<br>
Make it easier to support new protocols via addons. Implement open
protocols and maybe activesync, leave rest to addons.<br>
<br>
<blockquote type="cite"
cite="mid:4d192054-e407-356e-c58e-f52a31113c24@caspia.com">
<p><b>Big question #2: Security.</b><br>
</p>
<p> Of course anything that we do would need to be immune to
malware attacks, but the issue here is advances in communication
pointed toward end-to-end encryption. There have been a variety
of attempts to provide working products and protocols to this
end, but this has not been a focus of Thunderbird. Should we
re-prioritize our efforts toward accomplishing the goal of
reliable, convenient end-to-end security? (There have been at
least two third-party attempts to implement this in Thunderbird,
which we so far have only hesitatingly encouraged. This priority
could be accomplished in partnership with more commercial
entity, but keeping in mind the backlash against such
partnerships that Firefox has faced).</p>
<p>In addition to the end-to-end encryption issues, closely
related issues hinted at by Ben are the issues of privacy and
dependency resulting from dependence on central servers. Local
storage on Thunderbird is not really prioritized currently as an
alternative to server storage, and there are many details that
would need to be attended to before that was really viable and
reliable.<br>
</p>
</blockquote>
<br>
Use something like Signal protocol for easy E2E encryption.<br>
<br>
<blockquote type="cite"
cite="mid:4d192054-e407-356e-c58e-f52a31113c24@caspia.com">
<p> </p>
<p><b>Big question #3: Implementation polish.</b></p>
<p>This may seem like an odd big picture question, but really a
focus here would be in direct conflict, in the short term, with
the other big-picture priorities.</p>
<p>There are many, many details of how Thunderbird currently works
that really could use improvement. I'm sure everyone has their
pet peeves that they would like to see improved. So the question
is, should Thunderbird remain as primarily a desktop product
focused on existing open protocols (IMAP, CalDAV, and CardDAV)
and focus new efforts on performance, usability, and reliability
within that restricted scope?<br>
</p>
</blockquote>
I think this is first thing TB team should do with Thunderbird now.
Increase performances.<br>
<br>
<blockquote type="cite"
cite="mid:4d192054-e407-356e-c58e-f52a31113c24@caspia.com">
<p> </p>
<p><b>Big question #4: Betting on Gecko.</b></p>
<p>An issue that we have not come to consensus on is whether we
believe that continuing life as a binary rebuild of Firefox is a
viable future for Thunderbird. If we really wanted to follow
Firefox, we would be moving into Rust and focusing on
reliability and performance. Is that even viable? (I predicted
two years ago that our upcoming release, Thunderbird 59 now 60,
would be the last Gecko release we could successfully achieve.)
Where someone stands on this technical question has largely
dominated discussions of what steps to take next.</p>
<p>As we are currently contemplating a major investment in a
future Thunderbird, I think that we as a community (or as
potential Thunderbird Council members) need to have a clear
understanding on where we stand on this. Without that, we have
no clear direction and no vision that anyone could get behind.</p>
</blockquote>
Fork FF60 and start investing more man hours into increasing speed
and stability, then to patch TB to work with new FF base.<br>
<br>
Best regards,<br>
Mihovil<br>
</body>
</html>