Authentication looked straightforward when all I needed was a way for users to sign in.
It became more interesting while I was building Loomwing, ...
For further actions, you may consider blocking this person and/or reporting abuse
The split between Firebase identity, Loomwing profile, and unfinished onboarding is the useful bit. I'd keep the same honesty for contact fields: authenticated does not mean the email domain can receive mail or that the phone has a country attached yet.
Hmmm, that's a really good point. I think the authentication/profile/onboarding separation made me realize that I need to be just as careful with contact data. Having an email or phone number stored doesn't necessarily mean the contact information is actually verified or complete. That's definitely something I would tighten up as Loomwing moves beyond the current auth layer.
Thanks for pointing that out, I appreciate the observation.
That distinction is easy to lose once everything lives in one user record. Treating contact fields as their own state machine should keep auth success from silently becoming a delivery assumption.
That separation is the useful guardrail. Keeping contact completeness separate from authentication should make the later onboarding decisions much clearer.
That separation gives you a clean place to record verification state without letting it masquerade as identity data. I would keep the state explicit in the profile model and test the onboarding transitions around it.
Exactly. Keeping identity, profile completeness, and contact reachability as separate states makes the onboarding metrics much easier to trust.
Beautifully and well written. Welldone!
Thanks, really appreciate it 😁🙏
What does Loomwing do when Firebase creates the account but the Firestore profile write fails?
Interesting question. In this current implementation, Firebase can successfully create the account while the Firestore profile write fails, which would leave an authenticated Firebase user without a corresponding Loomwing profile. The app already treats that missing profile as an incomplete application state, but I haven't implemented a full rollback flow for that signup failure yet. That's definitely one of the edge cases I need to tighten up.
Thanks for asking this.
Building on the question above about the profile write failing: would a retry on next login be enough, or would you add something like a cloud function to reconcile it?