Deduplication of section 1.3 & use case document

[ewelton]

Section 1.3 begins with the text

Issue 2

These should be in a USE-CASES document.

In addition, the use case document and the spec have diverged - for example, use case 2.5. There are also discrepancies between this portion of the document and the ecosystem overview diagram that need to be cleared up.

Assuming we want to maintain a single source of use-case information, is the appropriate next action to submit pull requests against this spec, and resolve issue 2 by not having a use-case document, or is the next pull request an excise of section 1.3 and a pointer to the use-case document?

[gobengo]

https://docs.google.com/document/d/18UdEjA2kQRnILnBEnWijNho0YMJ93dbjKntx0NQzapI/edit

[ewelton]

So have we decided whether we are going into the spec document or the use case google document? It was going a little crazy at the airport with my Uber driver right at the end and I could not figure out what we decided.

[dmitrizagidulin]

@ewelton The overwhelming consensus on the call was - we're going to move the contents of the google doc into a separate document in this repo.

[ewelton]

@dmitrizagidulin Great - I had connectivity issues right at the end.

There is quite a bit of additional work, discussion, and effort relating to section 1.2 and 1.3. For example, issue #50 is related to issue #53

Also - @OR13 what does this have to do with layers? The question is "do we have a separate use case document" - the thinking was

1. figure out where the use cases live
2. make a PR

but it seems that flow is not right - but very confused about how that relates to layers.

[OR13]

There is a PR for adding the use cases document to the repo here: https://github.com/decentralized-identity/secure-data-store/pull/53

Seems like after that is merged, this can be better addressed.

[OR13]

@ewelton I added the layers tags to things that you said were related to layers on the WG call. So that we could focus on those issues first, in our next issue review.

cc @dmitrizagidulin

[OR13]

Latest use case document: https://github.com/decentralized-identity/secure-data-store/blob/master/use_cases.md

[msporny]

The use cases in the core spec was never meant to stay in the core spec... they should be moved to the use cases document. The core spec should point to the use cases document.

[OR13]

We need volunteer to move use cases from respec (specification) to markdown (use cases).

and cross check the use cases...

[EvanTedesco]

I am taking a look at this issue now and was hoping to get clarification on a couple things.

1)I am a bit confused by this line in the google doc sec 1.5: "Alice wants to be able to store data that is plaintext anonymous visible, but authenticated. Alice does not want anyone to prevent Alice from publishing public plaintext data."

what does plaintext anonymous visible mean in this context?

2) Is "Masterless synchronize" jargon or a term we need to add in the terms, or would rewording to "synchronize in a masterless manner" be acceptable? Reading it as written just seems off to me.

3) Is location used synonymously with instance in some of these use cases or do they denote 2 different concepts? In my mind location refers to the physical location of the storage device which I don't think is the intent.

Additionally, something worth considering is standardizing the format of the use cases where possible. I realize this document is still young but I am happy to create another issue if we think this is worthwhile. There are a lot of first person references("I will store a large amount of data.") which add ambiguity to the use cases. There are also multiple Alice/Bob style use cases, as well as "As a user, as a developer" examples.

[msporny]

what does plaintext anonymous visible mean in this context?

No idea, it's a terrible sentence, isn't it. :)

1. Is "Masterless synchronize" jargon or a term we need to add in the terms, or would rewording to "synchronize in a masterless manner" be acceptable? Reading it as written just seems off to me.

Let's avoid the whole "master / slave" language. Alternative: leader-less replication.

Might look here for insight:

https://en.wikipedia.org/wiki/Replication_(computing)#Replication_models_in_distributed_systems

2. Is location used synonymously with instance in some of these use cases or do they denote 2 different concepts? In my mind location refers to the physical location of the storage device which I don't think is the intent.

No idea, I'm also confused by this.

Additionally, something worth considering is standardizing the format of the use cases where possible. I realize this document is still young but I am happy to create another issue if we think this is worthwhile. There are a lot of first person references("I will store a large amount of data.") which add ambiguity to the use cases. There are also multiple Alice/Bob style use cases, as well as "As a user, as a developer" examples.

Agree that we need to remove the "I" language. Also agree that each use case needs different names. See this document as a good way to put together a use cases document: https://www.w3.org/TR/vc-use-cases/

[EvanTedesco]

I agree that https://www.w3.org/TR/vc-use-cases/ is a good model. It is worth mentioning that on the last meeting I remember it being mentioned that we should be rewording with more concise language "As a developer" for use cases which could be a step in the right direction but we should consider working toward your model which is more "Alice and Bob".

Ultimately I think "as a" works well for user stories "As a , Given that , When I , Then " but lacks the nuance required for some of the more complex use cases(Especially multiparty ones).

[OR13]

@bumblefudge did this.