Justin Bingham

> I like the direction where this is going; but we might want to emphasize that the spec is a contract between app and servers. I.e., it's not just useful...

> We should also keep in mind the general architectural principle of [orthogonal specifications](https://www.w3.org/TR/webarch/#orthogonal-specs). That is to say, there is not _one_ Solid spec, but a group of orthogonal specifications...

> As such, I propose to start from scratch with a Solid spec in a W3C template, where we pull in curated parts of the current Solid v0.7 spec, with...

> Would it be interesting to align our responses to the above questions (especially adding, deleting, and the number of constraints) with how we would approach [ShapeTrees](https://shapetrees.org/TR/specification/)? As you start...

> That's an interesting problem; let us create an extra issue for that: How to edit a resource's metadata? Speaking from experience doing the shape tree implementation, @ericprud and I...

> I'll also vote for SCS as I believe seo is more important than consistent naming convention. Assuming that we stick with the name community-server, then +1 for SCS as...

> I suggest to keep it simple by updating (relaxing) the current definition to any resource. For clarity, are we only suggesting to relax the domain so the property can...

From an implementation standpoint, my organization's software currently has to maintain special support for storage provisioning for each server type. This is not ideal, and likely to become more problematic...

> * Servers MUST support `INSERT/DELETE WHERE` with just BGPs in the `WHERE` clause This seems like a reasonable minimum. * Implementer feedback: _Fairly simple to support_ ✅ * Developer...

> OK, sorry I wasn't aware. What are the steps? The proposal would need to be documented in the form of a change submission to the solid protocol specification, and...