Security vs. User Experience – can this Process still be considered to provide proper End-to-End-Encryption?

Question

I am banging my head about this for a while now and would appreciate opinions/different views.

tl;dr

There is a system that aims to provide full end-to-end encryption for information (text messages, blobs) exchanged through it. At the moment, users who want to join the system need to be a) invited, and b) approved after they completed the registration process. Between a) and b) they are unable to use the system. There is a way around it, but it is unclear if this would violate the principles of E2EE or be an acceptable compromise.

The current implementation

To outline the main mechanisms of the system let me take the analogy of a forum software, which comes close to the real thing:

• There are different sub-forums which are all invitation-only. Every message exchanged here is encrypted in a symmetric fashion, using a secret that is shared among all users of that sub-forum. However, the secret isn't persisted in plaintext per user, but encrypted.
• Each user owns a personal key-pair with a public and a private key. The forum secret is encrypted with the public key.
• The private key is encrypted using the user's password (through PBKDF2).

So when a user should be added, the process is as follows:

1. Admin A with access to the sub-forum (and its secret) invites user B. B will receive an e-mail with an invitation link.
2. Once B accepts the invitation and completes the registration, their personal key-pair will be created on the client-side.
3. Now, B still needs to get access to the secret of the sub-forum. Which isn't available at this point, as it is persisted in encrypted form per user only.
4. Thus, A needs to approve B's account in the next step. Now A can decrypt the forum's secret using their own private key, and encrypt it for B using their public key (on the client-side again).
5. Finally, B is able to access to forum's content using the secret which is now shared with them.

(This is a very much simplified version of the real implementation, but the core building blocks are there.)

The problem

As you can see, between step 4 and 5, the process is interrupted. Until A approves B's account, B cannot use the forum. In addition, A must not only initiate the invitation, but also approve it. This might become tedious and annoying to both users.

An alternative?

The goal would be to make this a non-stop thing, so a user can sign-in right after accepting the invitation and start using the forum:

1. A invites B. But now a temporary password is created along with the key-pair for B. The private key is encrypted using the temporary password, and the forum's secret is encrypted using the public key. Everything is sent to the backend, which then persists the data (except for the temporary password) and sends the invitation e-mail (including the temporary password).
2. Now B can complete the registration by basically changing their password.
   1. They provide the temporary password (could be included in the querystring)
   2. They provide their new password
   3. The private key can be decrypted using the temp password and encrypted again using the new password
3. Done.

Advantages

No interruption for B, they can immediately start using the forum. No need to approve every new user for A (which may occur quite often when a lot of new users join).

Downsides

Before, no sensitive data left the client. But now the temporary password is sent to the backend where it is not persisted but sent to the user in plaintext via e-mail. So it could be intercepted by a malicious actor outside of the forum's context or by someone with regular access to the forum's backend.

The latter I consider to be an academic problem, as anyone with access to the backend most likely also has access to the client's code where the password could also easily be extracted.

However, the transport through the unencrypted e-mail remains. So everyone could intercept that e-mail and create the account on behalf of B. However, this is also possible in the first scenario where B's account needs to be approved, but not authenticity check takes place. A second factor like a SMS sent to the phone number of B could be introduced to mitigate this.

But in both cases it would be possible to gain access to the (temporary) password. For someone with access to the backend/database, this would open up the whole content of the sub-forum.

Conclusion/Question

Can this Process still be considered to provide proper End-to-End-Encryption?

At the moment I might suffer from paralysis through analysis. So I am not sure if I am overthinking this, and if the alternative approach wouldn't be a suitable compromise. The thing is: The most secure system wouldn't provide any value if it wasn't usable.