I haven't read the code myself, but the OP is claiming "really, really bad security holes", and calls out the encryption code.
Security is not something that can be bolted on after the fact; it needs to be baked in from the start, in a product like this. And, remember, security/privacy was Diaspora's raison d'etre.
No one expects the first code dump to be polished, or feature-complete. But if there are serious flaws there, of the magnitude described, pointing it out isn't just "trash talk."
In fact, this is how it happens in the vast majority of cases, including the case of Facebook.
...which is Diaspora's claim to existence.
Facebook probably isn't the best starting point because anything working at that scale is a challenge no matter what.
(Edit: Though if one measure's Diaspora's eventual size if it reaches its goals and considers what percentage of the man-hours have been put in to date, this is still early in the process and major rearchitecting of every component was inevitable anyhow, so hopefully with one of those they can install some security too.)
I'm afraid that Diaspora might be in an impossible position. If they release something early, they'll get a lot of bad press from knuckleheads like this one that the quality is no good. If they release late, everyone will be clamoring over the wasted $250k in the interim, demanding: "when will we see something?".
Now growing it over time, standing up to public scrutiny, hardening, balancing, monetizing -- those are much harder problems. Getting code out? Not really, in my opinion.
Their code is out there, they have openly said it is full of bugs and they now have a hell of a lot of eyes, They will get a massive benefit from this being opened early and it really isnt their problem if people refuse to ignore all their and everyone elses advice and give out their banks password
The question is, do the problems in the code establish beyond doubt that this team is not capable of delivering a final product that will see some level of acceptance? I really hope not.
1: I'm assuming that - I would hope they didn't think this was release-ready material.
Furthermore, one of the primary goals of the project was to make something more privacy-conscious than Facebook, and so far they show they have a development process that pays less attention to access control than any Rails app I'm aware of.
1. Build features, ignoring permissions entirely.
2. When the feature set is relatively stable, default to disallowing everything.
3. Re-enable one feature at a time as you add appropriate permissions checks.
Step 1 looks horribly irresponsible if you don't know 2 is coming. But if you do, it avoids a false sense of security from half-finished permissions in rapidly changing code, and it keeps up early motivation since you're rolling out "exciting" features right away. And counting on step 2 ensures you're always checking whether something is allowed, instead of foolishly checking whether something isn't allowed.
Whether this scenario applies to Diaspora at all ... I don't know. Time and another release will tell. But I do think there are valid situations where authorization is "the kind of thing you add later" for appropriate values of "later".
And may I add, I think it is really great that many public seeds are being deployed, this is the only and best way to test a social federated network, pre-alpha or not.
There's some stuff that good/experienced developers do upfront naturally. There are some security, design and performance things that are clearly a case of bad development versus "this is an early release".
Fundamentals.
"Fundamentals" are things like: there's no identifiable data model, the code is pure spaghetti and structure is a fleeting concept.
From my very quick scan of their code, it's readable, the parts of the data model I looked at are fairly obvious (thanks Rails), dependencies are identified, crypto seems fairly localised. Correction of bugs seems definitely doable. Extra features shouldn't require a total refactoring. Looks good to me for an alpha drop.
Next up: posts criticising the spelling in the comments in the Diaspora code.
And I'd say having no authorization in a project that's supposed to be about privacy is missing a fundamental.
The fact is, the implementation is obviously problematic. I won't go as far as saying that the design is flawed, although some security vulnerabilities are certainly pointing that way. It's obvious that Diaspora's developers are inexperienced, and therefore could use all the help they can get from us. This is one point in favour of an early release, in my book. On the other hand, early design and implementation decisions have profound implications during the lifespan of a project (this is especially true when it comes to security), and I will not trust my personal details to Diaspora in its current form; the project still has a (very) long way to go before being technically up-to-date.