attendance doc: https://hackmd.io/lKmW-LZ4Tw-0-RcFAxjsJA

Who am I?

Where am I?

We clearly need a third name...

We are in the “Secure Data Storage WG"

We are working on the “Confidential Storage Specification”

We are under some IPR agreement

attendance doc: https://hackmd.io/lKmW-LZ4Tw-0-RcFAxjsJA (add yourself)

Very intereesting

I had a chat with the Tangem Card folks about adding hardware support for x25519, for a similar type of scenario to support hardware protected edvs

Congrats Kaliya!

+1

Secure Data Storage WG

q+

q-

I’m in favor of moving to EDV.

q+

q+ to describe why we can’t name the spec edv

I think if we did Hubs, folks like Ceramic and Solid would be smart to develop completely independently of this group

which may be OK, but we definitely want to understand that EDV usage may MASSIVELY decline as a result

q+

because Hubs is where most applications will exist

devs don't write dapps against low-level DB-centric calls

that's not controversial, it's just reality, even today

@daniel - I agree, I look at EDV as more of a backend for Hubs and wallets and such

Why would Hubs be controllers?

they don't mutate data

and can't read encrypted data

q+

Indexes are plain text

indexes are also encrypted

^ not in hubs

ohhh right

sorry

yeah

Hence confusion

w+

q

Lets keep everyone together until we can’t :)

datashards

noted, great to know, thank you

https://github.com/decentralized-identity/confidential-storage/issues/157

? what do you mean in the document itself?

aha

The one oddity is that you're essentially writing an entirely different layer to circulate publicly exposed private keys just for the public data

^ 157 is a proposal for EDVs

Not hubs

Not be clear

*to bee

God I hate zoom chat

so you say "I want everyone to see this in plaintext", but then you encrypt that, and then need to include a private key with it, even though you never wanted to encrypt it in the first place

I agree - it’s rificulous

Take your crying to the issue

:)

https://identity.foundation/confidential-storage/#terminology

q+

https://identity.foundation/confidential-storage/use-cases/#functional-requirements

q+

q+

q+

to talk about share data

+1 what Dmitri said about authorization

Alice to Bob is more of an AuthZ use case

q+

alice to alice is sharing with 0 entities?

Its encryption and access to only yourself

thus not sharing?

The word sharing is meaningly

Meaningless cancer

“Sharing” is not sufficiently defined

For anyone to understand

q+ tp talk about backup

q+

are we talking about something that should be invisible to the client or not?

In my mind “replication” can be a means of “data sharing”

why Dave, it sounds like you want to join the queue :)

q+

orie is /never/ unclear.

Thats not true, please ask for clarity always

:)

q+

+1 to dave

To talk about visibility of replicatiton

+1 dave

"client-controlled replication"

+1

q+

to say what Orie is NOT replication

Wyoming underground citadel, FTW

data protected by buffalo

woooot, underground citadel as a service!

Replication is simply the act of replicating data to other instances of a thing

q+ to say that it is replication and provide a concrete example

0 work

"client-controlled replication" (what Orie describes -- perhaps we need a better name, naming is hard) would be a potential feature for the spec, "server-controlled replication" would not be.

literally not even flinch

I feel we need a clear distinction of layers to frame these conversations; “server” EDV, “client” EDV, Hub. We may likely have different types of replication supported at those different layers.

q+

https://guide.couchdb.org/draft/replication.html

^ wow look, a definition for replication

Alice changes nothing

q+ to discuss visibility vs controlled.

q+

@chris - great point.

all are just SE endpoints in your DID Doc

yes, magically they do their thing!

that's my goal with replication

yes

Or not in your dod document…. You don’t need to disclose them to use them.

well, magic we have to design and implement :)

q+ to object to Daniels language

I suspect magic, in terms of replication, will be more the domain of Hubs. whereas EDVs will be much more of a 'manual ditch digging' sort of thing

“We don’t know if instances are equivalent"

Orie: huh?

We should be careful to promise folks they can just use ___any__ edv thats is listed

To not *

Don't hate on me saying "Magic"

:) thats basically what I am about to do

because the section title in the CouchDB doc is literally "The Magic" LOLOL

With couch, replication can be client as well, via PouchDB

I am tremendously good at bothering people, but especially Orie - we all have our special talents

I agree that there is differential replication

q+

q+

Yep, I love pouchdb

The will get, “what they are configured to get"

And the client gets to tell them that part.

Or it won’t work :)

Filtered replication is still a SLA issue.

But is it separate service entities?

q+ to mention namespaces

filtered replication

@Orie: Yeah exactly. With pouch/couch you can use either client/server replication.

if that's what the spec sats

I’m note sure the watch will even know about filters that it won’t have.

Orie: there's a base-level map that all instances should have

@orie / chris - I would argue that with Pouch, it's /still/ "server"-controlled replication. Except that the library essentially runs a little server in the browser

so they know what to send others, and not to send

Daniel: No, there is no “base level map” :)

Or at least, not one I have seen

entities here means infra providers ?

q+ to say we should differentiate based on what the client needs to do, does it set a configuration option on the server and walk away or does it have to *do* the replication

entity is getting slippery

***insert meme: Well it would be a lot cooler if it did***

^ sure, I am not opposed to defining that…. later

Simple things first.

Then complex things

q+

Please Dave pick a “place to start”

Need to support both IMO

The Client is just one instance of the same logical thing, imo

Don’t ask this group more open ended questions

:)

so it should do the same functions

q+ to propose the simple case

+1 Dave’s framing is useful.

I think we can have the server do differential replication…

that's an important distinction

I have a proposal

q+

q+

Dave really helped me understand where this is really a thing to throw to Hubs

Orie, yes, maybe there's something we could do with encrypted indexes... would need to think about it.

don't be a half-way replication crook

Lets talk about what we have working today

And how we could make indexes work

it will be more complex to do that with half on each side

@Daniel, yes, the client-controlled replication, I think, belongs in Hub space.

q+

q-

We can’t keep avoiding the authorization issue by calling it replication.

+1 to what Orie is saying.

q+ to say we can explore what Orie is saying, it may be possible, but having not done it yet, i can't say what the pitfalls would be.

q+

+1 Orie

My proposal will work for both “filtered” and “unfiltered"

With encrypted indexes or not.

q+

You won’t always know the filter when designing the indexes, needs to be dynamic

q+ to answer the bob indy question

Yes, agree with Chris

dynamism in the index means that inbound writers need to write in a way that new objects fall into the right indexes

^ this is possible :)

but without having to know all of the reindexing logic, unless we also replication those types of things *across participants*

The only requirement is that the writer intend to be indexed.

And therefor replicated

Orie: I think your thing would require Alice's instances to actively replication index logic to Bob, so Bob can do the right thing with the objects he's inbounding

actively replicate*

I think it would be non-trivial

and assume the writer IS NOT Alice writing to Alice

the harder question is what Bob needs to do

q+

(top of the hour warning)

you'd probably want to have a number of different indexes (perhaps over the same data) using different keys to enable some "sharing" use cases here (to use the evil "sharing" term)