[carbon8]

Basic authorization for resource access isn't the kind of thing you add later. This isn't just an issue of bugs or being in development, it's a fundamental issue with their development process.

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.

[nickbw]

For brand new/"experimental" projects with both user permissions and a non-trivial set of features, built by a small team, I've always found it easiest to work like this:

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".