Oh shut up you sanctimonious prick. You're confirming all of the negative stereotypes about this website.
Do you think I, in 20 years of working in the industry, haven't dealt with bad board members? How about a little curiosity instead of whatever the hell you're dishing in this thread.
Let me help you out: you're a stupid little troll and your contributions to this discussion are like little turd droppings that just stink up the room. Please kindly contribute constructively or fuck the hell off.
I find your tone dismissive, condescending and snarky. I made a (hedged) statement that turned out to be incorrect, updated the blog post, and moved on. I didn't think it was a statement of great consequence, certainly nothing to fixate on.
Please review the HN Guidelines and ask yourself if posting your comment added to or detracted from the value of this discussion:
> I continue to believe that corporations and startups, even friendly ones like Honeycomb, are not pleasant places to work at.
I have lots of thoughts about the necessity to work and how that can drain a lot of enjoyment out of intellectual pursuits, but I will say that, of profit motivated companies, Honeycomb is an exceptional one to work for filled with wonderful humans who care about each other. I really enjoyed my tenure there, made lifelong friends, and became a better engineer. It's a really special place and I hope they keep that up as they grow.
Added a clarification: first non-founder/executive employee to sit on a board. If there's another venture-backed software company in North America who's put a rank and file employee on their board, I'd love to hear about it!
Author here, thanks for your comment! Can you elaborate on what you’d hope to see in such a case study? Maybe I can file that away for a future post. I mentioned incident analysis as one way to put these perspectives to _use_, would a case study of applying lessons learned from incident analysis towards roadmap / work planning fit the bill? (As an aside, there’s lots of that at https://www.learningfromincidents.io/).
Also curious to know what you believe the more common framework looks like.
"Sure, every website can implement this flow, and users could could go to every website they've ever logged into and update their email address... assuming it all works properly even though they might not have access to the old email address anymore."
And how is this different than the current situation? Nearly all web sites require an email address. With BrowserID, you at some point confirmed ownership of that email address, so you could continue to use it to login, then change when you're ready.
"At the very best this technology offers considerably less value to websites and more hassle to users than Facebook or Google. And it's about 5 years too late."
Tell that to users who a) don't have Facebook accounts or b) don't want to use Google or Facebook with their identity. Far more people have email addresses than Facebook or Google accounts.
I agree that email address != identity, but nothing would stop a site that uses BrowserID from allowing a user to change the email address that they use on that site.
It's very similar to the countless existing services that rely on email for identity... you'd just have to verify ownership of the new email address (usually through a confirmation email).
Exactly. And the point of standards like OStatus (and it's component specs) is that we don't all have to be using (or contributing to) the same software... instead we can build a myriad of apps that work together.