It has been explaine, don't reply instead reread those messages. This is completely unacceptable behaviour. You're sabotaging your own cause.

We spoke in a previous task about this. You cannot just reopen the same ticket again and again.

In T16730#295630, @davidedmundson wrote:

Wording like this does not help convince people to join your mission but instead close this whole issue off hand.

If so, KDE should add a clear exception to the KDE Vision for benevolent Western

We've been through this.

Not taking the bait, sorry.

In T15527#275389, @ngraham wrote:

learning some communication skills so that you become capable of convincing people of your position

Spamming these kinds of messages isn't helpful. Please stop it. If you really care about this cause, your time would be 100x better spent learning some communication skills so that you become capable of convincing people of your position rather than annoying them.

In T15527#275281, @felixernst wrote:

The last law you wanted us to oppose didn't became law either.

@felixernst, remember how you told me that the EU's privacy situation isn't as bad as I thought? Look at how quickly things can change...

In T14768#271239, @ndavis wrote:

It's just unclear what you need design help with. The videos show the current state, and it seems like it's not ideal since I can't understand any of it, but I don't know what to say or think beyond that. From my perspective as an inexperienced user, the ideal experience is that I don't even have to think about keys. It would only be something programmers and sysadmins would be concerned about. Emails would simply be encrypted when I want them to be. Maybe even by default without me being aware of it, similar to how https is everywhere by default on most important websites. I understand it's not as simple as that, otherwise encrypted email would already be far more common.

In T14768#271218, @knauss wrote:

@ndavis: What infomation do you need to help? Have you watched the videos? And looked into the subtasks? Sorry I'm a little bit lost, what you need for information to go on. As I have deep understanding in the encrypted messages I'm somehow blind about the questions from newbies.

As a first step I want to get improve the situation when sending an encrypted message. I want to remove/replace/improve all the dialogs that pop up AFTER pressing "send". I think a user should in best case not click "OK" at any other dialog after pressing "send". The user should have information BEFORE pressing "Send", if they wants to send it under specific circumstances.

@ndavis: What infomation do you need to help? Have you watched the videos? And looked into the subtasks? Sorry I'm a little bit lost, what you need for information to go on. As I have deep understanding in the encrypted messages I'm somehow blind about the questions from newbies.

@knauss: be aware that if the EARN IT anti-encryption bill passes, your efforts will all be for naught, as mail providers will begin refusing encrypted mail outright. Please spread the word!

It's currently not clear from the task descriptions what your goals are. I have next to no experience with encrypted email, but I know that PGP has a lot of built-in complexity that can be difficult to abstract away (part of why it isn't used by most people). Maybe someone else in the KDE VDG has more experience with encrypted email, but I don't know anyone in particular who does.

Hey VDG team, As the title tells you: I want to improve the current workflow of encrypted mails in KMail. At the moment focusing on the sending part of it. I need input from VDG about how to improve the current situation.

Meanwhile the Thunderbird Addon is no longer maintained and usable.

All I need right now is a tiny bit of hope...

you've already requested this and got an answer

No.

background support is now on the way to enter: https://invent.kde.org/pim/messagelib/-/merge_requests/15

How?

Well following the words of Nate.. (x)

whilst doing so with no other intention than to do his words justice. His position certainly does have merit and is one position among all those in the diverse field of positions one may find themselves arguing for.
I personally, find myself fully in line with the spirit of what I reckon it is that lead you to reaching out to Nate, as well as ex post wanting to again shed some public light on the key issues at stake following your well attentive assesment according to the best of your abilities.
Whilst only time will tell, I have a feeling Nate will in the short to medium term future find himself in the rear view mirror of a significant share of individuals, the betterment of whose Nate says he works to achieve through providing them with a better experience, were they to decide become Users of that created in the spere of his influence and this is a goal, I assume we all share - especially in the light of the corporate tankers being totally in love with subscribers these days.

In T8408#237431, @brenthuisman wrote:

@knauss Did any development occur? On NLNet I see the project is still at 'Open' status.

@knauss Did any development occur? On NLNet I see the project is still at 'Open' status.

Me get funding from nlnet to work on this. The rough ETA is to finish this in June.

any updates?

I concur with Tom on this one. We currently have a number of projects underway (most importantly, the Gitlab migration) which our resources are probably better directed towards.

Firejail would only work for applications that are not already sandboxed. We'd need a separate settings backend for flatpak and probably also snap.

I think we lack resources to work on this, especially also since there is no real alternative that brings substantial improvements.
I suggest we close this for now with wontfix status.

Separate keyrings is indeed what I meant, it's what at least some clients do. I don't think gpg supports multiple keyrings though, so you'd need to include a lib.

In T8408#197809, @brenthuisman wrote:

Regarding the externality of the PGP client: a few tools I know use an internal (OpenPGP.js I am sure) library when set to Autocrypt mode. Enigmail as of version 2, when in the default easy mode, did not appear to store keys in the external client (when autocrypt is enabled) but somewhere internal (you can find openpgp.js in the Enigmail sources). The pEp mail client's the same, and a new Thunderbird client 'AutoCrypt' that does not offer a regular PGP mode also won't use any client you may have installed.

Next step sending MemoryHole headers.

Okay with D23807 in repository, we now can display MemoryHole headers correctly.

@knauss Thanks for your elaboration.

The last bit missing is to change the order of execution, when we display a mail. The order we need is:

The basic support for the MessageViewer will end in a few days.

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]