You could easily add your own backend relatively easily (the API is easy to copy), though it's not really "optimized" for that yet. It's designed with offline storage for JS in mind though, so the library itself likely won't support remote calls.
I believe the aim is to have email providers be able to auth your persona email instead of Mozilla, but Mozilla exists as a sort of polyfill if the provider (eg. hotmail.com, gmail.com, your-custom-domain.net) doesn't do persona yet.
Also, yes: people can still choose crummy passwords. Personally, I don't think the appeal is in better security; it's convenience of single sign-on without it being tied to a. identity or b. Facebook (or twitter or google or whatever other service that harvests my data).
Right, but the email providers are only authenticating you to Persona. As far as the websites using Persona are concerned, it's persona.org that authenticates you.
And the appeal that Mozilla is pushing is definitely better security (as well as a distributed security authentication versus one for-profit authority - I definitely trust Mozilla MUCH more than Facebook or twitter, but it's still a central authority). You can especially see this in the talk they gave introducing it: http://www.youtube.com/watch?v=iZBTc7iEkQY
Ah! Right. There is no Persona password if your email provider supports Persona natively. If your provider has native support, you only authenticate with them, and the site you're logging into sees a credential issued by your provider. Mozilla is completely out of the transaction in that case.
You can try this yourself with a demo identity provider we have at http://eyedee.me/
If you're looking to do remote work because you're sick of your current 9-5, you shouldn't look to remote work to fix anything.
I worked anywhere from 30%-50% a week remote at my last gig and it still requires maintaining somewhat regular hours (you still have colleagues) and a routine. I now work remotely save for trips to the Head Office every once in awhile. You still need a routine because you have other colleagues you need to interface with, at least sometimes in real-time.
If you want to set your own hours and do your own thing, start freelancing or start your own business. My ability to work remotely was an asset when I started at my new job, but if I phrased it like you did ("I don't wanna wear nice closes and drive") it would make me sound more like a sloth than a good remote worker.
And if you work remote, you best be getting out and dressed up at least a day a week anyway. Interaction is REALLY important and you'll go crazy if you don't get out and see people.
Jason is a designer by trade, and is routinely involved with the design of 37signals' products. In the same vein, DHH is a partner in the company, but still writes code (as I understand it).
To clarify... "President" isn't a title I use, it's a title often ascribed to me as the founder of the company. Whenever anyone asks for my title I tell them we don't have titles. If they require one for whatever they are writing, I say you can say president or founder if that works, but I'd prefer if they didn't say anything other than founder since founder isn't a title as much as it is a fact.
Re: design. Yes, I design. It's the primary thing I do. Design, sketch, work on product simplification, design/think about user experience, etc. DHH still codes as well (he's working on some nice enhancements to Highrise right now, in fact). Both David and I would prefer to design and code all day, but it's not always possible. Lately it's been more possible so we've bee doing it more often.
"Jason Fried is the co-founder and President of 37signals."
and
"Jason co-wrote all of 37signals books, and is invited to speak around the world on entrepreneurship, design, management, and software."
with that kind of workload, I assumed you wouldn't have enough time for anything else. I never said whatever you do is useless. Far from it. Non-technical work that is focused at growing a company is more important than any technical work. After all, what can you do with an insanely great product that you can't sell because you didn't prepare for it properly?
Really? Most of the standard web dev stuff (Ruby, PHP, Apache, etc.) comes out of the box and works quite well, and if you need either specialized versions of things (rvm, virtualenv, custom Apache, etc.) or stuff that doesn't come with OS X (lighttpd, node.js, etc.) wouldn't it be installed in /usr/local?
I don't think this will break many web dev tools. Unless you mean stuff like Sequel Pro or TextMate; even then, I can't imagine most apps won't make the transition smoothly.
With the Xcode 4 unix tools installed I had massive build problems with homebrew. Not being able to build mysql, node.js, thinking-sphinx, redis, mongo et al would constitute a pretty broken web dev environment, so if Lion requires the newer version, which most tools don't yet build cleanly under, that's a pretty big problem.
They're offering users who probably just want to use Twitter easy/quick access to an alternative client so they can get back to tweeting. Given that the app they used to use was banned for privacy violations, the fact that it's the official app is probably a good thing in terms of trust.
Fingerprints will grow back unless you get down to dermal layers of skin and that will hurt quite a bit. Permanently removing your prints is a more involved process than this, but it's certainly a cute idea.
37signals has an extensive API built around all their apps with tonnes of 3rd-party native apps for desktop and mobile. If there isn't a native app for your platform, go write one and stop complaining.
And arguing that a web app isn't useful as _a freaking web app_ on your mobile is a little wild to me. There may be deficiencies in areas like file uploads on mobiles, but largely, you interact with Basecamp through a browser on your desktop. Why doesn't a mobile work well? (I've used many iOS Basecamp clients and none were better than the mobile version launched today by 37s).
I love native apps too, and I'm glad that 37signals encourages their existence by providing a solid, well-documented API. And while they do ship some native apps, I totally buy them building really awesome web apps on the desktop, and now on mobiles.
It's frustrating to me when people say something along the lines of "go write one and stop complaining." It's hardly a useful retort. I think his main thesis is an important one to take note of. One that anyone who runs a software company should consider.
