Seems like, as I've been myself for quite some time deliberating along similar lines, social media and social networking is becoming one of the next frontiers (beyond finance) targeted for decentralization. We've already talked about and covered in varying depth Holochain, Scuttlebutt, Solid and others — which tend to be architected around DHTs (distributed hash tables) as the public space and user-associated hashchains as the private one (as a sort of append-only feed or personal blockchain).

IOTA's tangle, an idiosyncratic DAG (directed acyclic graph), altogether differently modeled than blockchain (e.g., it consists of many chains of interdependent events and the ledger keeps the records of their trajectory).

SOCIETY2 (founded by Ben Royce, who is also head of development) is the first one to build on IOTA's tangle (for data storage and as data transport layer) and is likewise meant to give back control over one's data and content ownership. Everything in SOCIETY2 is meant to be universally portable and central to it (and to many other IOTA-related projects) is the notion of Decentralized Identity (DID), which makes it so that you manage a single global identity (shared, in part or whole) for all related apps, services and sites. This is meant to "encourage a healthy marketplace of platforms ready to compete for our content or attention.”

SOCIETY2 also uses IOTA Streams as a framework for cryptographic applications, working on extending its functionality to serve as a toolbox of standard social media functions (with those extensions collectively packaged as a software framework for platforms). Streams replaces Masked Authenticated Messaging (MAM) and is specifically meant for app-related protocols. Rust libraries in alpha are currently available and consist of the following components:

• Channels Application (which builds on and extends Masked Authenticated Messaging v0 and v1.0 and allows developers to build applications for their specific needs — not unlike how app DNAs and app-specific validation rules work in Holochain)
• Core layers (basic IOTA-specific cryto utils)
• Merkle signature (implementation of the IOTA Streams Merkle signature over Winternitz one-time signature) and traversable Merkle tree
• Protobuf3 layer as a cryptographic message definition language
• Application layer with common application definitions

Royce has described Streams in Twitter so:

To use it you need to add it as a dependency in your Cargo.toml (from the Git repository since it is not on crates.io yet) like that:

[dependencies]
iota-streams = { git = "https://github.com/iotaledger/streams" }

Now the Streams Channels Application functionality can be used in code like this:

use iota_streams::app_channels::api::tangle::{Author, Subscriber};

fn main() {
    let author = Author::new("AUTHOR_SEED", 3, false);
    let subscriber = Subscriber::new("SUBSCRIBER_SSEED", false);
}

Messages are declared in Protobuf3 syntax and processed according Protobuf3 rules. Streams Message consists of Header and Application-specific Content. There are two roles in Channels Application: Author and Subscriber. Author is a channel instance owner capable of proving his or her identity by signing their messages. Subscribers in this case are anonymous as their public identity is not publicly revealed. Author can share session key information (Keyload) with a set of Subscribers allowing them to then interact with him/her privately and securely.

A more comprehensive example of using the Streams Channels Application can be found here and other examples of using Channels Application here. 

Definitely promising and worth looking into I'd say. IOTA's tangle is a kind of DAG-valued (directed acyclic graph) stochastic process and DAGs are how complex systems are usually modeled — this kind of data structure or model allows for the data itself to be processed, analyzed and made use of in many different interesting ways, mapping and revealing things that might otherwise never really surface (though Holochain's agent-app/DHT-bridge relationships also similarly form a massive DAG). A lot is not quite yet clear to me in terms of further technical and implementation details, but taken a note of to keep an eye on future developments and perhaps keep in consideration for possible applications that it might be the ideal fit for.