Is it? One of the unfortunate realities of running an online service is having to deal with cp. With centralized services, it's a mitigable annoyance - you, as the operator, can employ various hash blacklists and the like. However, this isn't always sufficient; I assume the parent was referring to Tumblr getting purged from the iOS app store over doing too little too combat cp[1].

With federated services, the problem is more difficult. For one, if a centralized service can't clamp down on cp to Apple's standards (as unrealistic and inconsistently applied as they may be), what chance does a decentralized system have, where individual instance operators have to collaborate to keep their own instances clean and not federate with poorly-janitored instances?

It also increases the barrier to running an instance. Dealing with cp is not fun and having to manage that on top of usual mod/maintenance tasks has the potential to escalate running an instance from reasonable hobby to hellish timesink. If running instances is too hard, your federated system is probably DOA.

Of course, if a federated system were created with strategies for dealing with cp and other cannot-host content in mind, that would be a genuine improvement over existing designs that'd be worthy of discussion.

---

[1] https://news.ycombinator.com/item?id=18494137

Agreed. Email is the canonical federated service, but the App Store allows plenty of email apps even though they could be used to send CP.

What does cp blocking mean?