Michael Telatynski
Michael Telatynski
> That really sounds like a bug in the IdP. Is this a hypothetical argument, or is there an actually observed example of this? IdPs make all sorts of similar...
> Makes sense. Perhaps though it may be useful as a reference/guide for an implementation authored within the org ? We don't have the bandwidth to maintain additional native code...
I think Electron for Linux is leveraging Chromium's existing password store code for its safeStorage, so likely the fix could be made there also
> (i really miss the username and password fields directly in element) You could choose a matrix homeserver which doesn't require the use of oidc.
My outstanding comments need dealing with, e.g. property of room state and random variable name change
> What did you expect? What happened instead? Operating system No response Application version No response How did you install the app? No response Please fill in the issue template...
> Please reimplement support that does not require DBUS. We use Electron's https://www.electronjs.org/docs/latest/api/safe-storage as the alternative (keytar) was no longer maintained and a ticking time bomb for security vulnerabilities, I...
As per my earlier statement, we switched from the no-longer-maintained node-keytar https://github.com/atom/node-keytar to the supported Electron safeStorage, the latter of which may require dbus depending on which implementation it connects...
Lowering O due to most users seemingly preferring the TAC experience
I have seen comments saying that it fixed threads and stuck notifications for them