@trigun0x2 Thanks so much Jeff! Fast is focused on e-commerce companies with a streamlined checkout experience, while Magic is focused on providing a robust identity service that can be used for both startups and enterprise companies (SOC 2 compliant). The other major difference is that Fast in this case is a centralized identity provider with a SSO-like experience, which also means that developers will have to expose the Fast brand on top of their own UX (like Facebook or Google auth). Magic instead gives users decentralized identity which is self-sovereign without having to trust centralized identity providers. Magic also gives developers the ability to customize the magic link experience, giving them a lot more control over the UX! A cool secret with Magic is that every single user will be issued a blockchain key pair, which means for advanced developers, they'll be able to easily tap into the power of blockchain and cryptocurrency to build future-proof and innovative applications!

@trigun0x2 @_seanli When you say "without having to trust centralized identity providers", aren't you still trusting AWS? Afaiu, they hold all users' private keys in clear.

@trigun0x2 @_seanli @paul_mckenzie I think that's a choice for developer. like their is a concept of User Agent (It could be mobile device or a cloud) . It depends on security vs Usability what devs want more

@devishnya1 Thanks!! We are very optimistic that it's a matter of time before passwordless auth start to catch on in mainstream applications! It's already been used as a predominant form of login for companies like Slack, Medium and Substack, with great results in terms of security and conversion, and we are in conversation with many more companies ranging from startups to enterprises who wants to switch over to Magic links! Passwords introduce so much overhead and risks these days giving the current cybersecurity climate and increasing number of data breaches. There are many caveats and challenges for developers to roll their own magic link, but that's what we are trying to make easier with Magic! We will provide not only just magic link login, but other form-factors like WebAuthn and mobile authenticator apps - passwordless login is looking to surpass password login as a predominant form of login within 10 years!

@devishnya1 it's certainly growing in popularity we launched our own solution on producthunt this month https://www.producthunt.com/post... and are excited to see more people in the space.

@fumoboy007 Yes indeed! Love that you appreciate the magicalness of our Magic passwordless login!

@ianissoawesome Thank you so much for the kind words and great feedback Ian!! 💜

@morgan_leblanc Thanks so much! The default user security is actually based on their email security, so that it's really easy for users to get started with any application! But we are in the process of building out email hack protection (location, network etc.), as well as other form-factors of login such as WebAuthn and mobile authenticator app for users with higher level of security requirements! The cool thing with using decentralized identity (DID) is that developers only need to deal with DID tokens signed by keys on the backend, and the front-end key management form-factor can be very flexible without having to change the backend code!

@morgan_leblanc I thoroughly get the tech and kudos on the whitepaper. What I meant is that this is a great effort towards solving the real problem of e-ID. Got it, but not without a major impediment against it as well. It would be great for developers and platforms, set us all up towards what anyone on the industry knows we should move to. Let me call this Side 1 (platforms, systems, developers, products and services). However.. when we think of Side 2 (the users themselves) there's a huge hurdle. The pitch I heard though was "hey users, replace your passwords with magic links because it's better". To the user on Side 2, things would be a lot simpler and faster, sure. However, they would also be anything except safer nor better than the status quo when the main source of truth/access is the good old munted-mongered phishing-full email. Why not pair it with a reliable messenger to start for example, as I mentioned above? If anything, it's a dead-certain pseudo exit strategy where you'd have most of them begging for a "use X app and forget about passwords". Sophisticating the solution even more, like I also mentioned, why not biometrics and personal devices - moving away from the old and clunky IxD and all its interfaces that we know should change in the future anyway? If you're opened to a piece of advice from somebody who truly loves the concept - apart from hating the crying shame of it as soon as I read "email" - here it goes: I would strongly recommend thinking about graduating the product, instead of the user. Avoid the complication of anybody who's been phished or hacked asking you "how was this better than my old password manager" altogether. The only possible answer you'd have is "Your email mate. Your responsibility" and those are the final words anybody hears before their great unchecked ideas go to die. :) Not tomorrow. Not next. Before anything. Now. That would be new and different. That would also show that you also care about the user, sometimes not so knowledgeable, and not only about the product developer. All the very best luck with the project. It can really become.. magic. ;)

> The cool thing with using decentralized identity (DID) is that developers only need to deal with DID tokens signed by keys on the backend, and the front-end key management form-factor can be very flexible without having to change the backend code! That probably answers my last Q :) Is it safe to store token in local storage as some OAUTH / OPENID solutions do?

@stevealee Thanks for the great questions Steve! - The magic link for now will piggyback users' email provider's recovery mechanism - In the near future we will have other hardware/device login which can be added by users for added security and recoverability! Progressive disclosure is key for Magic, ease users in with magic links, and then graduate them into more advanced ways to login - Definitely looking to be able to support offline and PWAs, as well as native mobile applications (coming soon) - If you are referring to the DID token, under the storage associated to your domain, it will be up to your web app's security strength. With proper web security configuration (e.g. CSP) and watching out for the top 10 OWASP vulnerabilities like XSS, it will be safe to store it in the localstorage. In our documentation we've showed some example on how a replay attack can be prevented as well!

@_seanli soooo if a user has Yubi or biometric tha tworks on the device receiving emails? Also emails are not guarenteed delivery times (or even a tall) Are there any fall backs. I'm not criticising, just try to understand the edge cases. I'm basically excited like Elliot.

@stevealee: Thanks for the questions! Happy to take a stab at this one :) > Is it safe to store token in local storage as some OAUTH / OPENID solutions do? It is definitely very true that many things come into play to determine if it is safe to store data on the client side. It largely depends on what information a token is bearing and the current security strength of the web applications. The rule of thumb is always to avoid storing any sensitive information on the client side and handling it on the server side. OAuth's access token is a good example of a token that should be handled on the server side. The token itself has been authorized for some scopes, and it can be used to modify or retrieve user info from the OAuth providers. If this token is stolen without notice, the sensitive information can be altered and leaked. As for the OpenID Connect, since the protocol wraps OAuth to provide the identity layer that OAuth doesn't support (it is a common misconception in the ecosystem that people misuse/abuse OAuth as the identity where it should only be used as a resource authorization scheme), it provides both ID token and access token. The access token here is the same as the OAuth's, and by the best practice, it is strongly recommended to handle the access tokens on the server side. As for the new ID token, it is used to provide web applications with user info from Identity providers, serving like a client side caching layer with a TTL (token expiry). It is not indented to be used to gain access to act on behave of the users. if an ID token carries a field like `nick_name` (besides all the required fields), I would actually consider that it is safe to be stored on the client side. Having this data in the LocalStorage can improve the overall user experience because the application doesn't need to make another network call to retrieve `nick_name` when it needs to show the user profile page. It can read the info directly from the ID token. If the tokens expire, users will just have to re-authenticate again. Provided with the right balance and the intent of the token, it can be helpful to determine if it is safe to store on the client side. Even though server side handling is always recommended, developers still have the ultimate control. The application security posture will then become super important :).

@arthur_jen ooh so no refresh tokens with Magic!? \0/ \0/

@chris_lu Thanks so much Chris! With all the recent advancements in cloud infrastructure, identity, and crypto, the pieces are starting the connect, the antiquated auth and identity space is going to get super interesting very soon!

@louis_xu Thanks Louis! We aim to really push the envelope forward for the identity space. Which is why we adopted some future-proof standards like W3C's Decentralized ID (DID), as well as using blockchain keypairs to enable sovereign identity (user owns their identity and can move them to different applications anytime) - all without a centralized identity provider. Magic in this case is a key management service that helps generate these DID tokens which is an open standard for any application to do auth with regardless of how the keys are managed!

@danielque Thanks Daniel! Hahah that's such a throwback, they are definitely ahead of the curve! Lots of great shifts in user behavior have been happening, as well as improvements to identity tech. The world of auth is about to get interesting again! ✨

@jehunter5811 Thanks Justin!! The pricing model will actually be quite similar to the Fortmatic pricing model. We are finalizing the details and eventually the goal is to fold Fortmatic whitelabel SDK users into Magic, and the free base plan is going to also be in Magic!

@coderberry Thank you so much Eric!! Simplicity will be our focus - we'll carefully and gradually introduce more amazing web 3 features to web 2 in a super accessible way!

@sunghong_sch Thanks!

@duncan_cock_foster1 That's a very good question Duncan! We designed Magic to be able to integrate seamlessly with existing applications too and not just for new projects. You should be able to plug Magic into your existing session management (if there's any) and get rid of passwords by only requiring user magic links. You can take a look at the following tutorials for how that can be done: Express + PassportJS: https://docs.magic.link/tutorial... Firebase Auth: https://docs.magic.link/tutorial...

@_seanli can it work along side passwords? for example, could we present users with the ability to log in with a password, and then also use magic if they would like to do so?

@_seanli @duncan_cock_foster1 I think the technical answer to that is yes, but passwords come with very serious security, privacy, and financial risk hazards for your users due to the risk of password database theft. I've covered this topic in depth in many other places so I won't go too deep here, but the short version is there is no really safe way to store passwords, even hashed, salted, peppered passwords, and most users reuse the same passwords on multiple sites. That means providing a password option on your site could be endangering your user's bank account, or medical records, or identity, and that could open you up to liability you don't want. Passwords are obsolete.

@alex_kim4 Thanks so much! It's awesome that you noticed it and asked, we log users into the "original context" after the magic link is clicked, and we do this for several reasons: * Taking modern user behaviors into account with users going between laptop and phone. Users are gravitating more towards their phone. Generally with web applications like Medium, users are logged into the tab where the magic link is clicked, but this may be a problem when users clicked on the link on their phone and is logged with the phone rather than the laptop, making editing very inconvenient. With Magic's model we can get through complications with Incognito mode too. (Though we will be exploring deep linking with our mobile SDKs) * If the magic link URL get hijacked somehow, the hackers will only be able to login users into their original tab, which can mitigate damages. * Training user behavior to gradually shift to user an authenticator app like DUO on their phone by subtly encouraging users to use both laptop and phone to authenticate

@_seanli I see. I was able to figure out that I had to go back to the original tab. For non tech-savvy users that may not be able to figure this out, how are you planning on improving your UX to make sure they know / learn that they need to use their original tab? I remember the error showed "magic link expired", not "You closed your original tab, try again" P.S. I really like how you guys are tackling passwordless login from UX and security point of view.

@alex_kim4 I'd be really interested to see how this turns out. At did.app we used to direct users back to the original tab, we even tried using alerts to pull the focus. In the end though we moved away from it because non-technical users kept getting frustrated. Like I said tho interesting to see if they can polish the UX

@stevealee Really appreciate these questions, it's what helps us move forward! Arthur added more to the token in localstorage question too. Regarding logging in with Yubi or our own mobile authenticator app, once that's paired with an user account, no more email link will be required, login can be achieved by tapping Yubi key or a mobile notification (similar to DUO). For users going to be using our own mobile authenticator app, there will be a special recovery process involved (inspired by crypto wallets) for users who have locked themselves out by losing their device etc.

@_seanli I guess I'm stuck when I leave my phone in the car and my partner drives off in it :) Mind you without my phone lots of pain ensues anyway.

@vikrampatankar Sorry for not being able to include that before launch! It'll be available very soon! There will be a free tier, and we'll be carrying over the pricing from our existing key management product (fortmatic.com/pricing) and make slight adjustments. Love to hear your feedback on the price range as we are trying to make this an optimal choice for startups and growing companies too!

@felice_feng Thanks Felice! Super excited for what's next to come and bringing decentralized finance to the mainstream 🔥🔥🔥

@felice_feng Do you have a link to TokenSets, I'm really curious to see how more people are using magic links in their sites

@omidborjian Thanks so much!! Magic links are definitely starting to pick up in popularity, we've gotten quite some inspiration from the results from companies using magic links like Slack, Medium, and Substack!

@haolee Email links are just the easy starting point for many users. We will be graduating more users to more sophisticated login methods such as webauthn and mobile authenticator apps. The benefit with our DID architecture is that developers can easily add other form-factors of login without having to change the backend code!