Welcome to FISSION Fragments #7 - our regular newsletter of awesome links. Want to get them delivered straight to your inbox? Subscribe! We tweet the links after we publish on our Twitter account @fissioncodes, or join our Discord chat to see them in real time.
At Apple's developer conference, they announced their new Sign In With Apple, a user login system that will, among other things, generate a random email address per app / sign in (WWDC 2019 Session Video).
Now, the OpenID Foundation has published an open letter to Apple, asking them to comply with the spec:
It appears Apple has largely adopted OpenID Connect for their Sign In with Apple implementation offering, or at least has intended to. Known differences between the two are tracked in a document managed by the OIDF certification team, found here: https://bitbucket.org/openid/connect/src/default/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md.
The current set of differences between OpenID Connect and Sign In with Apple reduces the places where users can use Sign In with Apple and exposes them to greater security and privacy risks. It also places an unnecessary burden on developers of both OpenID Connect and Sign In with Apple. By closing the current gaps, Apple would be interoperable with widely-available OpenID Connect Relying Party software.
The Golem Project announces support for heavy compute tasks on their network using WASM binaries through their gWASM implementation.
The Textile team went to IPFS Camp and came back with a blog post of all their highlights and takeaways. This Filecoin vs IPFS tidbit was interesting:
Filecoin was not the focus of any projects I spoke with, and only came up in a few general conversations. To me, that signals that IPFS is going to be a robust and independent technology for as long as I can see, and the success of Filecoin will be independent from the success of the IPFS network.
Great tweet thread by @dschenkelman, Director of Engineering at Auth0, on internal tools teams:
1/15 For the last 2.5 years I've been working with the Internal Tools teams @auth0.
— Yenkel (@dschenkelman) July 1, 2019
Why have an internal tools team?
The typical answer is economies of scale, standardizing through code rather than just proces
This also reminded me of a 2015 post by Peter Seibel on Engineering Effectiveness at Twitter, titled "Let a 1000 flowers bloom, then rip 999 out by the roots".