p2p email: Virtual Email Institutions for Thunderbird
pidgeot18 at gmail.com
Mon Aug 4 19:37:14 UTC 2014
On 8/4/2014 1:10 PM, Randolph wrote:
> Dear Kent,
> yes, maybe the wikipedia entry gives already some information
> you look at the gui presentation:
> or just compile it with Qt from SVN to test it yourself:
None of those links do an adequate job of answering the question Kent
asked. Reading 50 slides of very dense text mostly covering protocol
details is not an answer to either "what is it" nor "why should I care?"
(Apologies for being very blunt about this).
> From the operational view Mozilla could set up one or two servers
> running this kernel, to make sure, each User has the option to connect and
> exchange emails.
Somehow, I don't imagine Mozilla is particularly willing to set these
servers up only for Thunderbird.
> (A6) COMPILING AND LIBRARIES WITH QT: As libraries OpenSSL and
> libgcrypt are used as is. SQLITE Databases are used to store the
> encrypted data. I dont know, if XUL needs to address these all new
> with a the c++ gui code or if the Qt gui c++ code an easily be used
> to be written new for a XUL binding. In Detail there are some DBs
> created (maybe by the kernel!) and then the GUI can store data into
> the DBs.
At this stage, I think we'd prefer code written in JS. Even were we to
accept C++-written code, dependencies on OpenSSL and libgcrypt are
non-starters (you'd need to support NSS instead), and using QT for the
GUI is also likely to be a non-starter.
> (B) GUI Elements Information
<snip lots of information>
Security UX is mind-boggingly hard, and I am by no means a UX expert.
From the supporting documentation, I've read this as a "replacement for
email" protocol, and I already find several respects in which it fails
to be usable replacement from a UX perspective, e.g., cumbersome
You also describe a lot of addition to Thunderbird--are you willing to
maintain that code? Thunderbird is desperately short of people to
maintain its existing code, and the proposed addition would be a very
significant amount of code that needs a maintainer.
> (C) WHY - Strategy Information
When pondering new features, I like to ask myself: "Why should 10
million users be forced to pay the costs of having this feature
installed?" All features come with costs--in code size, maintenance
costs, related library issues, etc.
> (C1) COMMUNITY APPROACH: T-Bird once was declared as optional and dead
> and lost the established developers. The new strategy was to make it
> more convenient, maybe add chat to is, but neither the messaging
> plugin nor the calendar plugin has been added as default.
Actually, chat is built into Thunderbird, and we have at times discussed
folding Lightning directly into Thunderbird. IIRC, the biggest stumbling
block to integrating Lightning was that the Lightning developers didn't
feel they had sufficient maintainers. Support for libpurple in chat is
not included in Thunderbird, I think, largely because of licensing
issues (libpurple is GPL).
> A p2p
> community could bring a new direction to T-Bird, as the development is
> currently the community development and not the company or core team
> of 2 developers. BE what your shape is. T-Bird is not company, T-Bird
> is community. Let' s bring T-Bird into the hand of the community for
> p2p email. Just fill your share what you are already. Give it a new
> start a new direction and we create a new market entry with that.
I can't figure out how to say this without being blunt. Based on the
links you've posted, the code in question is maintained by effectively
only one or two people, and the total community is maybe on the order of
a few hundred people. I get the distinct impression that you're trying
to leverage Thunderbird to gain a community for your own project. I
don't find anything wrong with that, but I think that predictions of
being able to measurably grow Thunderbird's community should this
project get incorporated are unrealistic.
> (C2) EVERONE ENCRYPTS AFTER SNOWDEN: In the age after Snowden
> encryption is essential. All teams, all IT departments and all Apps
> are thinking about encryption. See the automotive development, it is
> in slow steps, but it is continuous, T-Bird cannot close the eyes for
> encryption. If you don't decide for the echo p2p encryption, these
> thinking together might have an effect for a better enigmail
> integration - what the hell. That´s good too but not what is suggested
> here and I tested a lot with the p2p email suggested here and would
> like to test with you as well the T-Bird integration. It is really a
> cool out of the box tool, which allows to have some cool features and
> modern encryption details. T-Bird should think about the overall
> surveillance and add more encryption. It is the image of a social
> responsibility we want to mirror to the community.
Why is it better to have developers spending time working on your P2P
email solution than spending that time improving S/MIME or PGP support?
If encryption is the end goal, why are the current encryption solutions
insufficient? I've already spent a lot of time thinking about the merits
of S/MIME and PGP and have been working on a proposal to improve those
(it's not finished because other obligations have intervened).
> (C3) FUTURE PERSPECTIVES BASED ON NEEDS OF GENERATION Y: Further
> development: Next to the EMAIL-XUL gui, which would be the first step,
> we could think to add as well presence and Instant Chat to the Email
We already have chat and I think presence information in Thunderbird.
> And this would be serverless (in thinking of a central server
> dictation) and uses the same spot-on kernel. Or does instant bird tell
> you that their chat servers do as well the emailing? Next to Chat as
> well group chat would be a perspective. But that is just thinking, as
> T-Bird currently stands for Email and not Instant Chat, but who know
> the customer needs of today exactly ? mobile and cloud first? Whatsapp
> instead of SMS first? and Whatsapp instead of Email? T-Bird must stay
> attractive for the Generation Y and Twitter generation. Currently the
> Email generation is still there and has the power to implement p2p
> email - which later could be discussed to extend with given client
> kernel and set up email server structure to use this as well for 1:1
> or group chat.
> (C4) ENCRYPTION EXCLUDES WEBBASED EMAIL GUIS -TAKE THE BALLON FOR
> T-BIRD CLIENT:
I read this as "breaks email for 40% of the worlds users" (I don't know
exact numbers, but I heard 40% once, so I'm sticking with that).
Quite frankly, as much as I hate web guis, they are a very common means
of access to email (I myself use them a lot, despite having Thunderbird
be the second program I install on a new machine after Firefox). Saying
"screw webmail, they're idiots" is no more tenable a statement than
saying "screw Outlook" or capability with other programs.
> (C5) BE FLEXIBLE AND START FROM SCRATCH EVERY DAY: Development never
> stops, Nokia has and soon MS will be gone, because the old tanker was
> not adjusting to new needs. Just start writing T-Bird from scratch
> new, like VLC has done for the Qt Framework. Well, Gecko is still the
> old? Or was it webkit, which has been abandoned? we have with one
> kernel added and a few gui elements just a small need for adjustment
> with a great effect - It defines a totally new T-Bird experience,
> identity philosophy and community involvement, if the presentation is
> then done right based on the new codings.
We've had too few discussions in the past about the way Thunderbird
should be going in development; it's not helped that trying to herd an
open source community is, in some ways, like trying to herd cats. One
thing I think that has reached some sort of community agreement is that
we ought to be restructuring Thunderbird to run on top of JS, HTML, and
web APIs (and, naturally, using less C++)--and I think your proposal is
moving against that goal. I've also been trying to push for greater
coordination with Gaia Email folks and some other open source projects,
seeing as how mobile support is increasingly important, and that's
really our only route to supporting mobile.
Development is also more than shiny new features. Shutdown hangs are or
slow mailbox performance are, quite frankly, embarrassing in this day
and age, and we certainly have a lot of quality issues in our core. Lack
of support for TNEF or CardDAV are practically unexcusable at this
point--those features certainly have very high value for our current
Overall, I'm not persuaded that Thunderbird should incorporate this
code. I would encourage you to try building an extension first if you're
still interested; and if that extension starts to see substantial usage,
then perhaps we can talk about integrating it, just like we have talked
about integrating Lightning or Enigmail into Thunderbird.
News submodule owner
More information about the tb-planning