Re: [sds-wg] Reminder and Agenda for Confidential Storage Spec Call - Feb 25 2021

Thanks Manu for the thoughtful reply.


> Yes, this is a next step. Ideally, we'd map every feature in the spec
> today to
> CouchDB documentation. Chris, it would be good for you to volunteer to do
> this
> since you seem to be the one most driven to demonstrate that this is true.
> It's something we're going to have to document in time anyway, to
> demonstrate
> why the work needs to be done (or that W3C shouldn't waste their time on it
> because... CouchDB exists).

Once you document it (not just the list of requirements we've been going
> over
> during the last month, but all the features in the existing spec as well),
> we
> can review it as a group to see if there is consensus.
>

Sure, I'm happy to make a first pass on this. Any thoughts on the best
format / structure?


> Zooming out a bit to look at the big picture... thinking about how SQL was
> standardized may help. ... <snip>
>

Totally agree, standardizing SQL is a perfect example.


> To replay your point back to you, but in a different context:
>
> MariaDB (a popular open source relational database) covers many of the
> common
> use case needs for relational databases... so why do we need an SQL
> standard?
>

To clarify, I'm not arguing we don't need a standard. To work with the same
analogy -- if we're building an SQL standard we should be looking very
closely at MariaDB (and other prior art / SQL-like implementations) when
developing that standard.


> The process of standards are not to innovate (at least, not primarily).
> It's
> to look at everything that's out there and try to standardize the simplest
> set
> of technologies that fit a Pareto distribution... that is, what 20% of
> features meet 80% of the use cases. The goal isn't to get the standard to
> support 100% of all use cases.
>

Yes, I agree with that.

I guess one of my concerns relates to feeling like we're looking closely
enough at what's out there, but as noted above I'm happy to make a start on
that with CouchDB. Michael has mentioned some other prior-art (in the
replication context) that could be reviewed here
<https://github.com/decentralized-identity/confidential-storage/issues/162>.
I'm sure there's more and across other contexts? Is there other work to
document all the prior art that I have missed?

The point of meeting 80% of use cases is important, but there's some
subtlety in that. Is it 80% of the "total use cases" or 80% of the "most
important use cases" -- those are two very different things. And are we
dropping use cases because they're "too hard with the current spec
implementation" or because "they're not that important"?

Regardless, the ability to have a framework of modularising or extending
the capabilities seems like something we should seriously consider. That
will minimise the risk of developers ignoring the spec because they're
locked in to only working with what's provided out of the box.


> > I understand CouchDB is not a specification, but as an implementation
> it's
> > pretty darn close to what we're looking for.
>
> I have a vague concept of what your requirements are, Chris. :) I'm sure
> you
> don't have a solid concept of what Digital Bazaar's requirements are...
> or Transmute's... or SecureKey's... or Microsoft's... or Michael's. We're
> just
> scratching the surface, these discussions take a LOOOONG time to get to a
> basic understanding on everyone's *public* use cases.
>
> ... but the way we get there is to talk about it, and documentation of the
> sort you're talking about is vital to that process.


Totally agree :)