Diagram Why have a secure client and web browser? Why wouldn't both interfaces only be via the web and secured with TLS? Doesn't the local "secure" client provi

Diagram Why have a secure client and web browser? Why wouldn't both interfaces only be via the web and secured with TLS? Doesn't the local "secure" client provide a backdoor and increase attack surface? I could understand an out or band channel eg a management interface or SMS for two factor authentication and out of band messaging. I'm not sure that in social networking adding client into the permissions for Data, Posts and Comments make much sense What interface is the seeds outside the pod communicating on? Should in not be via the web or secure interface? Or is this another API for seeds in different pods to communicate? Why is there a database per pod?  Think the goal of encrypting only sensitive data and depending on the users risk appetite makes sense but it is not compatible with your low complexity goal. Also it is harder to explain to users and when security is left unto users in practice the  lowest or default security option generally gets chosen. So this may work if encrypted and no access is the default Minor point - why invent aspect when group works? The security model looks like standard mandatory access control. I'm not sure this works well in social networking. A better model maybe discretionary access control with inheritance of permissions and management by Aspect, Audience and User. Permissions should be able to be granted or revoked at the Data, Post and Comment level "Dual authentication is required. Users authenticate via a login name and password." If by duel authentication you mean two factor, this does not achieve that.  "Audience Seeds must request the Post and any encryption key from the Owner Seed." This sounds like manual key exchange, a better approach maybe any posts to an Audience is encrypted to the public keys of all members, so when the notification is received posts can be automatically decrypted by the private key of each Audience member "However, this has the ramification that any change in Audience of a Post would also change the Audience of any Comments by other Users. This would suggest that Audience changes should not be allowed, but a easy method for enforcing this is not evident" You could let each Owner who comments change the access level of their comment. If this is set to a higher level than the post the comment is not visible to the additional audience I would also be interested in the high level requirements that drove this architecture eg for a secure distributed social network some basic requirements I would have thought are: [+] least privilege access to data posts and comments based on explicitly authorized access for the audience set by the data owner. [+] the most restrictive permissions set by a owner, aspect or audience of the data to apply [+] secure in transit all data [+] secure in storage and backup unless owner sets as insecure [+] access to all data shall be authenticated and authorised and limited to least privilege on each access request for data (a vulnerability in the first release where simply by changing user ID other users content could be accessed [+] authentication and authorisation shall be based on open standards and federated eg open ID and oAuth [+] Multi factor authentication shall e supported [+] Sharing of of Data and access to functions with authenticated users, aspects and audiences shall be simple [+] Access granted to Audiences and Aspects shall be inherited by users belonging to those [+] Ideally the creation of Aspects and Audiences shall be self forming based e.g. on algorithmic analysis of common interests and existing connections