I thought one of the biggest uses of JSON-LD is SEO, and schema also provides a descent framework for common API structures. I am confused why this attempts to argue that somehow using JSON-LD might be a bad thing. What is bad is when too much data is exposed, like as you mentioned, GPS coordinates. However, you can also expose very little and if the information is already public using HTML tags to display data might be harder but won't prevent scraping. Scraping for federated networks isn't necessary a bad thing either if people want different interfaces without having to register for developer keys. Again, the information is usually public already and so letting people gather data through JSON is going to be a lot less taxing than encouraging scrapers to parse.

> I thought one of the biggest uses of JSON-LD is SEO, and schema also provides a descent framework for common API structures. I am confused why this attempts to argue that somehow using JSON-LD might be a bad thing

I am not the author but I found it a counterintuitive but legitimate point that as much structured data as possible is not inherently good (even if that's my natural tendency to think so).

It's okay if someone scrapes a web UI but keeping in mind use cases (SEO is not among them?*), not wanting to make extra accommodations for machine consumption and wanting to keep data fidelity as low as possible without hurting interoperability between clients sounds as a reasonable goal, and applicable to protocol design too.

* From LitePub docs:

> An important property of LitePub verses ActivityPub is that messages are intended to be transient, when message handling is properly implemented in this way, significant security advantages over the original ActivityPub approach are achieved, such as message deniability.

You can't want both transience and SEO. Those who want the latter may be better served by another solution.

> Scraping for federated networks isn't necessary a bad thing either if people want different interfaces without having to register for developer keys.

i’m not sure i understand all of this, but i don’t think you generally need developer keys to use your own interface in this space. in the case of Pleroma (the focus of this article), the default interface is a SPA that i think doesn’t get fed any special state but just populates the interface using documented API calls. so 3rd party apps don’t usually need any special approval.

It's a bit disheartening to watch the whole Semantic Web idea go from lofty vision ("wouldn't it be cool if the entire web were machine-readable?") to well-meaning but naive and impractical ("no one has any incentive to implement this; and even if there were, spammers and blackhat SEO would instantly abuse it") to now being an explicit non-goal ("publicly available machine-readable data is a security breach").

But of course she's not wrong. We have learned a whole lot about the effects and risks of data collection since the whole semantic web idea was started. I hope something can be learned from this.