Issue with new auth flow
Closed this issue · 8 comments
Encrypted keys are only present in the local ipfs node, not the global one.
This is the reason Safari isn't working, because Safari is the only browser that doesn't use the shared worker setup (no browser support for it).
Current solution: Add it to the public filesystem under /Apps/Fission/Lobby/Session
.
To do: Delete this Session
file when appropriate in the SDK.
Deployed lobby fix to staging & production, seems to work ok. Still need to make the SDK changes.
I think we should optimise for the shared worker case when available, that makes the auth process a lot faster. But how do we tell if the auth process is done through a shared worker 🤔 We can't simply do feature detection (eg. for Safari), because the app might opt for a standalone js-ipfs node. Needs investigation.
@icidasset there are lots of "maybes" here. We should optimize for how to make this work by default and out of the box across browsers. Do we give up on Safari / iOS in the short term? If we do, then I am concerned about being farther in compatibility deficit.
So "maybe an app will opt for a standalone" is not a problem we have today: assume developers will use the defaults in the webnative SDK.
Also I don't find speed differences across Safari and Chrome right now. It's all pretty slow.
Also I don't find speed differences across Safari and Chrome right now. It's all pretty slow.
Yeah there are no differences today, I've put everything on the same level. I too want everything to just work. Definitely not exclude Safari, just use the faster path when available. Just have to take some time to figure out that faster path
assume developers will use the defaults in the webnative SDK.
Aye captain 👍
@icidasset you and I should take a look together at how this whole flow works. There's no bottleneck here from a purely information perspective, so it's all browser features and flows. We may be able to stick our heads together and find a flow that works better cross browser.