depoll

In .net world, the C# "this" syntax is itself just syntactic sugar over an annotation (attribute in .net parlance): https://learn.microsoft.com/en-us/dotnet/api/system.runtime....

While it is a risk, it can be a calculated one. Most household goods require the "platform" of a supermarket or other merchant to actually reach customers. Is this so different? As a consumer, there are lots of benefits to being able to find and discover goods in one place, and as a seller, access to those potential customers can make or break your business, but might not be something you can actually establish effectively on your own without those distribution channels. The same is true of infrastructure - one always has to weigh the risks involved against the costs of trying to do things yourself.

I was an early Parse engineer (4th engineer to join the company) and now am the SDK engineering lead for Firebase.

The experience of working on Firebase at Google is vastly different from Parse at Facebook, and it shows in Google’s continued commitment to building and expanding Firebase, integrating it with its Cloud Platform products, and otherwise pouring huge amounts of effort into making Firebase great for developers. Open sourcing our SDKs gives us even more ways to engage with the developer community and allows us to be more transparent with the progress we’re making.

This announcement is just a first step down the path toward more transparency with our SDKs, but we hope to foster community and build trust in the tools we’re developing, and welcome your contributions!

s/shouldn't discuss them over email./shouldn't.

Consider, briefly, that the relevant question is what it meant to the OP, and clearly for her it had that impact. Having been through many of the same experiences (I, too, was an early Parse engineer, though I left about a year after the acquisition), I can tell you those feelings are real, and that it's definitely possible to form that kind of attachment to your work in well under 5 years.

Parse is a backend as a service provider -- originally for mobile apps, but eventually for all kinds of applications. You could store data, manage users, target and send push notifications, gather analytics, etc., all without having to build your own backend.

That's a very dismissive attitude toward real emotional attachments. The loss of something you've poured your life into can genuinely be traumatic, shocking, and dismaying.

I don't like the notion of applying the "first-world problem" dismissal to things that aren't trivialities. It's one thing to laugh about how you have to get up from the couch to get a remote. It's another thing entirely to talk about major changes to one's career, wiping away years of their work, or the loss of something they care deeply about as a "first-world problem".

Sure, getting acquired might be a "good problem to have", but it doesn't make its toll any less real.

There's definitely a benefit to developers. Hoomi provides an alternative to social login as well as an easy way to get single sign-on across their suites of applications. Furthermore, developers can adopt Hoomi rather than adding their own email/password-based login mechanism and avoid having to build screens for login, signup, email/phone verification, password reset, account management, etc. Essentially, developers can treat Hoomi as their login-as-a-service provider.

You're exactly right. We don't require email addresses or phone numbers to be requested from users by apps. Those are just ways to get and verify a Hoomi account. Once a user authorizes an app, the app only gets a stable, unique identifier (unrelated to the email address or phone number on the account).

Thanks for the interest!

We're encouraging developers to use this alongside social login (or as a replacement for building their own email/password-based login). Developers can avoid having to build and design large amounts of UX around login, registration, email/phone verification, password resets, etc. by adopting Hoomi, while still giving their users an alternative to social login.

We plan to add a number of compelling features for both users and developers. These will increase the value of a Hoomi account as well as the benefit of adding Hoomi login to your applications.

We will eventually have some premium services that developers can get access to that will help them engage with their users or administer their services.

As for "Anonymous" login, that's Facebook's term for the service they promised (and we don't use it in our own description of the product for exactly the reasons you mentioned). We act as brokers between apps and users for their data, which includes an identifier that can be used for login. When an app chooses not to ask for personal data, we let the user know that we won't be sharing any of their information with the application.

Hoomi sits somewhere between email/password login and social login. Users still get the benefit of Single Sign-on (that grows as more developers adopt), but don't have to have (or tie their account to) a social profile. You're also welcome to use your phone number to create a Hoomi account.

As far as Persona goes, one of the major differences is the primacy of mobile as a medium for login. And while Persona focuses on using email addresses as identifiers, we go one step further than that, isolating users/apps into their own ID spaces that aren't tied to any particular existing identifier. As a result, a user can change their email address with us without disrupting their service or updating their applications (https://developer.mozilla.org/en-US/Persona/The_implementor_...), and users don't have to divulge this information if it's not necessary, as with apps that just use login for personalization.

We're rapidly building and adding features to Hoomi, and you can expect to see the benefits to users and develoeprs grow as we flesh out users' ability to create profiles for themselves that they can give their apps access to.

OP here. Excited to start showing this stuff to the world. We think identity and login are really broken today, especially on devices that are becoming smarter (mobile, TV, etc.), and we are hoping to provide a solution that lets you take an identity with you wherever you want/need it.

Since we're not a social network, we can avoid a lot of the risk and confusion about how to use the product without accidentally sharing too much information, and really focus on building a first-class identity product.

We're happy to answer questions if you have them. There's more to come, soon!