Hacker News Reader

Comment by buro9 | Hacker News Reader

I use Persona heavily, with over 300 sites and 50,000+ users depending on it.

The saving grace here is that what I hold for users is the email address and that gives me a path to switch to another provider so long as I get an email address back.

In many ways this is a blessing, at least I now know where I stand. No doubt my spare time is going to be used up over the next month or two.

View on HN

Sorry about that. :( Can I buy you a pint when I'm in London next June?

We tried our best to ensure that there was never any lock-in with Persona, which makes a transition away possible, but not painless.

Now that we have a formal announcement, I'm hopeful that folks on the sidelines will take this as a cue to stop pining and start building. :)

EDIT: To curtail the "I'm in SF/BOS/etc." posts: I'm in Minneapolis. Maybe we should set up a Hangout or similar early next week? If you'd like in on that, subscribe to https://lists.mozilla.org/listinfo/dev-identity and I'll post details there.

If you're in SF I'm here until Friday at the CloudFlare office around the corner from one of the Mozilla offices (are there many?!) - down near 2nd and Townsend.

I wouldn't mind getting a brain dump of how you'd do it differently were you to build it now, as well as my sharing what I'm looking for... perhaps a Persona v2 design could rise from the ashes.

I'm not local (BOS based), but I'd also be interested in having this conversation with both of you. Persona's mission is too important not to continue.

Besides, isn't rising from the ashes what Mozilla does? "And so at last the beast fell and the unbelievers rejoiced. But all was not lost, for from the ash rose a great bird..."

Hey Dan, did you get the email I sent you a few days ago? I'm not sure whether it went to spam or something.

You know you can host the code behind persona.org your self on say https://auth.myservice.com. IIRC, it is node.js code.

I know.

But then I've taken on the maintenance and security of a system that I am not familiar with the internal workings of. That seems riskier than finding an alternative.

True. But, if persona has a large and active open source community, it might be better to use that than maintain homegrown solution in the hope of "security by obscurity".

There are some strong auth/auth open source communities - https://github.com/Jasig that serve millions of users.

it would be awesome if the community could really take persona up and fix it up / make it easy to run etc.

i.e. i wish projects like this the best of luck and hope to be using them later :)

The community will never be able to implement BrowserID in the browser without Mozilla's permission. This is the missing piece that would have made BrowserID awesome, without it, there's little point, you might as well use Google/Facebook/Twitter log-in.

I am not aware of anyone ever trying to implement it. There is not even a plugin from what I know. If someone would integrate the UI in a plugin, that works and people use it, I would be surprised if Mozilla would not accept a proper Patch to Firefox implementing that.

The proposed UI was not blocking anything, not even taking space.

Given Persona survives this.

The Persona code suffered from pretty serious feature creep. It's F/OSS, but I'd strongly suggest learning from Persona's design rather than directly re-hosting the code.

Heck, some of the code still dates back to when Node.js was only on version 0.4.5. :)

Maybe the persona team had better things to do than updating the codebase to each and every node.js release. It looks like node.js will become the new state of the art for crap web platform after PHP over some CGI. It's design changes a lot on a quick cadence, the community is based on coolness and fashion, its users and developers are mostly non-professional, inexperienced persons, and its use of the IO model is obsessive and single-minded.

Comparing node to PHP is a little unfair. PHP works!

Oh sure, but it works like a shotgun jetpack pointed at your foot.

I disagree. I think node is unlike anything we've seen thus far. It's not php, it's not python and it's not ruby.

I, literally, cannot rebuild my application from a year and a half ago that is standard node + npm. The deps are broken...the code won't build with node-gyp...i mean node-waf...i mean who knows? What a mess and a HUGE regret.

> I, literally, cannot rebuild my application from a year and a half ago... The deps are broken...

Welcome to the Cloud Future Web 3.0, where every library you use is maintained like some random guy's personal homepage, and his robots.txt prevents you from caching a stable copy.

I don't understand this argument. If you know what parts of your site the deps will effect it should be trivial to update them incrementally and rollback the commit if one unexpectedly breaks your code.

Besides, there's no universal unwritten rule stating that you have to use the bleeding edge version of every dependency.

Keeping all dependencies up-to-date is mostly in the interest of widely used libraries not one-off applications.

Not sure what the OP's problem was, but I've had issues with old libraries where some dependencies have been removed from npmjs.com. It's totally ridiculous.

I solve such problem for our clients by packaging every dependency we use in project as independent RPM package, so whole application can be installed using single "yum install ..." command from local repository without need to connect to internet. It allows us to precisely control version of libraries we use and also allows to apply patches to them when a problem is found.

So it's not immutable? Blinkin' egg, I'm happy I only played with node.js now. On the other hand, I guess it's always better to vendor one's deps, at least those that are not packaged by the operating systems. The language specific package managers add a lot of complexity.

I haven't seen the disappearing libraries from registry.

I did find a few libraries that have been completely abandoned...like 2/3 of the libraries I used.

I went as far as pulling the node_modules directory from production and perfectly matching the node version on my local machine. Linux -> linux and the app won't run locally. I think it's because the node-gyp influenced deps need to be built locally and linked to the right libs.

I then spent a few hours downgrading each version to isolate the issue...found a few libraries that were hard-deprecated (which was nice), found some breaking changes in the node version I'm using and then I just gave up.

Sure, but--as the traditional rant (http://blog.codinghorror.com/the-php-singularity/) goes--it works like a claw hammer with two claws and no face: sure, you can turn it sideways and drive nails with the middle part, but wouldn't it be easier to just get a hammer?

That is a bad tool only if you want to use it for driving nails. A claw hammer with two claws and no face is a magnificent tool for pulling out nails.

Rails is a hammer with a normal head but no claw. Hammering nails in is the more common case, but if you need to do both you're better off with the two-clawed one.

Comparing node to PHP is a little unfair. Node has a great package system, JavaScript is an evolving language that run almost everywhere: in all browsers, server side, in devices. PHP started as a simplified Perl, is a web page preprocessor that works well in that context: it can be used server side but almost nobody do it.

> Node has a great package system

Having used both, Node's package system is horrific compared to PHP's Composer. Composer's built-in composer.lock system is something NPM sorely needs by default.

It exists (npm shrinkwrap [1]), but it's not enabled by default, and it has some warts, such as non-deterministic sorting of entries.

There's a third-party tool [2] that is supposed to solve many of the issues, but I haven't tried it.

Of course, if you do this, there's a decent chance that if you try installing it again in 6 months, your shrinkwrapped version of at least one of the dependencies won't be available any more...

[1]: https://docs.npmjs.com/cli/shrinkwrap [2]: https://github.com/uber/npm-shrinkwrap

One wonders, why shouldn't it be 'npm lock'... I'm not that into plastic packaging, and not a native speaker, so shrinkwrap gives me as much clue about what the command does as blinktap, or pricklywarp.

Yeah, I've been experimenting with shrinkwrap.

Biggest wart I've encountered is I've got a package that installs fsevents (OSX-only) as one of its optional dependencies. When I shrinkwrap and attempt to install on a Linux server, that optional dependency is treated as a required one, and it can't install. I have to manually zap it from the JSON. :-/

Node has come a long way, and now has a responsible release cadence, including annual LTS releases, each with 30 months of security / critical patch support. The ecosystem is still crazy (especially with the ES6 features showing up in the Node 4.2 LTS), but Node itself seems to have matured nicely.

Persona may have been a bit premature in choosing Node, but we expected to share much of our code between the backend, frontend, and Firefox itself. Node offered a great opportunity to attempt that. Plus, the whole thing started as a side project between two engineers, so why not try out something crazy and new?

    annual LTS releases, each with 30 months of security

Am I alone in that 30 months feels like a "normal" release? I'm usually thinking LTS in terms of CentOS's definition.

The only people that say this kind of shit are the ones that don't use node. There are many large companies using node in production. Most community members I've interacted with are professional devs.

> The only people that say this kind of shit [...]

You do not even know how to interact with people like a proper adult. There are many companies, large or small, using PHP. Many popular blogs run on moveable type, that's Perl 5. Many companies run on Microsoft technology. And some popular websites run partially or wholly on Node.js. So what? Should I make my technology decisions with a « jump on the most brightly coloured bandwagon » approach? Node.js is a toy. A cheap chinese one.

It was incredibly easy to implement compared to other options and didn't require giving up a lifes worth of personal information to do so. I do believe that efforts like you are implying and others will push this forward to something that people will adopt.

Do you know which provider/s you'll switch to? I'm in the same position (albeit with fewer sites and fewer logins).

I know what I want it to look like, and I shall see if I can contribute to getting that created.

A Persona v2 if you will.

A few of us are chatting about it, look for letsauth on this page for details.

Reply on news.ycombinator.com