nick-garfield

Nick here, one of the developers behind Feather.

When we set out to build an auth API, one of the first big challenges was just wrapping our heads around all the various acronyms and protocols. Despite the existence of standards like OAuth, OIDC, JWTs, SAML, etc., authentication is anything but standard. As hobbyist devs, we wanted the interface to be simple. RESTful. Leverage HTTP verbs. We wanted an auth API that we wouldn't have to think about and would save us time.

After a lot of consideration, we settled on creating an abstraction for /credentials. With this, we've been able to abstract away sign-in flows for email+password and passwordless auth. "Just create a credential!" As Josh Bloch once said, “Good names are the API talking back to you”. We're super glad with how credentials abstract turned out. In the future, we plan to extend it for supporting protocols like OAuth as well.

Feather has saved us a ton of time while building other projects these past couple months, and we're happy to share it with everyone today :)

wow, just reading that term "line of business" makes me anxious. I used to work on a global payments platform that supported "multiple LOBs", and it was a nightmare of ifs and switch statements all the way down. The situation was made more difficult by the fact that our org couldn't standardize the LOBs into a common enum.

If you're in the "talking with customers" phase, you should also check out "The Mom Test" by Rob Fitzpatrick.

http :// momtestbook .com (EDIT: I just noticed this is an http site... breaking up the link into pieces for now. Sill recommend Googling the book)

The tldr; is that as soon as you tell someone about your idea, it's going to bias their subsequent answers. They're going to lie to, try not to hurt your feelings, want to get rid of you, etc. So if you're trying to validate an idea, the most important rule is "Don't talk about your idea".

What "The Mom Test" recommends is to instead ask prospective users about their lives and specifically to recall individual moments when they had the problem your idea will supposedly solve. With this "unbiased" recollection, you (as the entrepreneur) have to put 2 and 2 together to figure out if people 1) really have a problem and 2) are open/looking for a solution.

Hmm that's a bit disappointing.. I feel like Ive and Cook could be wrong on this one. If desktop/mobile is an appropriate parallel, then it seems like they've decided to undercut their desktop machine to have the "ergonomics" of a mobile device while still not being mobile. If the VR headset is a stationary experience, then what's wrong with having a hub sitting around nearby?

This is interesting.. I've never heard of the term "tacit knowledge" before, but it makes a lot of sense to me. It particularly reminds me of my experience being on-call at my last company.

Our systems were pretty unstable, and the most stressful part of the job was getting paged at 4am when everything was falling apart, customers couldn't use the app, multiple analysts would be sending messages asking "what's going on?", and as the on-call engineer, I happened to be the last line of defense (the system wasn't managed by a devops team).

In that moment, there's a lot of stuff that has to be done quickly: - orient yourself and figurate out what's going on (even in a sleep-deprived state) - prioritize mitigation over root-cause analysis - communicate early and often with the stakeholders present

This isn't stuff one can pickup by reading a "runbook". It took years of working with the systems, absorbing knowledge from my senior co-workers, and learning from past mistakes to get to a point where these priorities became in-grained in the way I approach outages.

So from my own experience, I would disagree with the definition that tacit knowledge is purely muscle memory or that it can't be improved. One's mindset can certainly evolve and I would consider that as "gaining" tacit knowledge.

I would even say something like music theory can be tacit knowledge. If you talk with musicians that do a lot of improvisation, they can certainly talk to you about music theory, but they're rarely "thinking" about music theory when they play. Just intellectually telling someone how notes/chords relate to one another doesn't transmit that "feeling" one needs to create great music.

What do you mean by DNS-based PKI? That sounds interesting, but I can't quite visualize what that is.