Conversation

Imagine if we had a protocol where it was required that you'd open up your SQL server to the public internet (with access control on writes, or reads on protected data, of course), and just have remote servers/clients just query straight off your database, regardless of query complexity.

So how is Solid any different than that with SPARQL, N3, Shape Trees, etc?

Every time I look at the stack of protocols to Solid ( https://solidproject.org/TR/ ), it feels like the engineering mess that was the OSI protocols, of overcomplicating a [relatively] simple problem.

I'm not saying SPARQL, semantic data, and alike don't have utility, as I'm sure it's probably used in various massively-scaled production environments; but that I don't see how you expect to have something publicly internet-facing that any entity on the internet could incur a heavy query on the server, or just with offloading so much compute responsibility to a server, instead of making a dumber server (just like how you can achieve an ActivityPub implementation in just static files, since it doesn't have a query language).

I could be uninformed (and I only periodically peek at it, and skim through some of the specs at times, I don't know it in depth), but I still don't see how this is going to be anything that could be operated cost-effectively and not be prone to trivial Denial of Service abuse.

Public

Notices

Feeds