In this case you still trust Mozilla and the JS code they serve to your browser every time you visit this URL (in contrast to e.g. mobile apps), so I don't think it solves much: you still trust a third-party.
Of course it's still better than the default, since your data sent at time t_A won't be compromised by an attacker compromising Mozilla's servers at time t_B with t_A < t_B (well, you try to retrieve your data and they steal your passphrase by serving some new JS code).
There's nothing technical to prevent Firefox Send from using a native client instead of a web page. The client could have the same trust model as everything else on your system, while still embedding the key into the final URL or link you share with other users.
It wouldn't even need to be complicated -- a wrapper around libsodium that pushed encrypted data to a couple of REST endpoints would do the job.
> As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being MITM on encryption? Especially since if you have their keys you already could.
I understood that you meant that Firefox Send solves this problem and does not handle users' keys. My point was that the trust model is still the same, so you might as well just stick to the current model where you already trust Jitsi. Firefox Send solves the UX problem because it doesn't completely address the encryption key handling problem.
To be fair, I still think Firefox Send is slightly better than traditional file hosting, just not significantly.
Yeah I guess you're right, in the sense that it's still a web application. Still, I don't think the general approach is limited to that. For example, Jitsi also has an Electron app. I haven't tried that, but I presume that would work in a similar way to e.g. Zoom, i.e. you paste an invitation link in there. That could just include the key, without it being sent to the server, and without it being a significant extra hurdle to the user.
Note that I'm not saying that that's necessarily the best solution; just that I don't believe that
> You can't solve the UX on that
is true, i.e. that there's nothing particularly inherent to the problem that results in there being exactly 0 good solutions to it.
Of course it's still better than the default, since your data sent at time t_A won't be compromised by an attacker compromising Mozilla's servers at time t_B with t_A < t_B (well, you try to retrieve your data and they steal your passphrase by serving some new JS code).