> Everything you're saying resonates, though I'm in that "10 years" zone, ahead of you, in regards to parenting.

> I'm here to talk about the problems of adolescent girls in this era, if you ever want to reach out. A horrible reality I've lived as a parent.

This is heartbreaking and I'd love to talk... Permission to reach out via email?

> I'm not convinced that [peer to peer] is as important as it is to refocus on control/ownership, intimacy, and moderation?

I believe these are synonymous.

> control/ownership

When you invert control/ownership, the user controls their data. The application is delegated access to it. This is a peer-to-peer data structure.

Instead of generating the data on an ASP's server, the user generates their data and stores it in a data structure they have control over. They can _delegate_ generation of data to an ASP style app, but ultimately the app is taking actions _on their behalf_ which the user owns.

They can pull that data down to their laptop, push it up to a peer-to-peer enabled NAS (purchased from the big box store) that they plugged into their router, etc.

The app can't revoke access to their data if they've backed it up. The app can refuse to continue mirroring it or modifying it, but it can't _lock them out_. It's the user's data.

That data is sharable and discoverable without the app's permission. The app can participate in sharing and discovering the data, but it can't _block_ the user from interacting with other users on the web.

The user isn't _forced_ to interact with other users either. They are in full control of who they associate with.

Right now we are solving this with a hash-tree. Every time a user takes an action ("creates a post", "uploads a picture", etc.) it's added to their hash tree. When you add a new device, the tree "branches" and you get two branches, one for each key to sign and add next blocks. This solves concurrent writes much like a CRDT.

That hash-tree is an append-only database. Anything you want to record goes into the database. The nodes in the tree do not store content, only a _reference_ to the content. This keeps the tree very small (1M nodes can fit in less than a GB of storage). You can backup the entire tree without backing up all of the content. And you can "delete" large files without having to rewrite the tree.

The tree itself isn't the user's identity though. That's fiat. If a key is compromised, users can flag content and say "hey, this isn't Alice, Alice wouldn't send me a crypto scam." Users can take two trees and "merge" them under the same identity (these are both Alice, but Alice lost her login and got locked out of her account, so has a new tree). This can be done without appealing to some application owner to "permit" you to fix Alice's social identity from your perspective on the web.

Then we use a capability system to delegate rights to keys added to the tree. So you can add an app (like iCloud) to your tree, and that app can now take actions within the scope of the capability it was granted.

> intimacy, and moderation

Intimacy, to me, means letting users decide how they want to model their social interactions. Who they pull in content from, how that content gets aggregated and displayed, etc.

Moderation, to me, means deciding what the user gets to see.

Those decisions are for communities, not for some remote disinterested platform operator.

You solve intimacy and moderation by allowing communities to form and moderate themselves.