q+

that would be awesome!

less holy cows!

q+

no objection

no objection, just appreciation to the editors

ToIP on Portability and Storage WG contacts:Christoph (chair) christoph@ownyourdata.eu

Paul Knowles (Input and semantics Group) - paul.knowles@humancolossus.orgNeil Thomson (ToIP contributor) neil.thomson@queryvision.com

q+

q+

q+

q+

+1 to separate pagination proposal

Would also suggest a way to return the number of pages in the response (e.g. response: first page, plus number total pages?)

and we should definitely look to existing pagination mechanisms. Things like 1) JSON-API, 2) CouchDB api, 3) ElasticSearch API, etc

vital that there be DoS notes ... asking for too many docs could result in GiBs of data in return... we have good bounds without this feature right now

q: <empty>

q+

q+

q+

q+

Ah, I get what you mean now

Not having to make two calls is better.

I missed the start of the call, apologies.

there are workflows where one call that receives 10 docs in serial is slower than 10 calls to receive 10 docs in parallel

q+

There are workflows where its faster to make one call too.

the fact that we aren't also sending the streams points to the idea that it's not always better to do everything in one call :)

This is different - it needs two sequential calls.

Get the identifier and then make a call to get the document.

Clearly there are cases where not having that extra call is faster.

IMO, those cases need to be significantly faster to justify the optionality in the API

We can’t treat everything this way.

if the multicall approach could get nearly the same performance with an abstraction in the client -- then that's preferable

It’s clearly slower by a network call.

we want to keep the API surface as small as possible -- it makes it easier to implement and mtainain

I want to optimize networks calls.

This is a small difference in the API to drop a network call.

We can’t focus purely on the API surface.

So what’s the outcome with Derek’s PR?

I agree that we can't focus purely on the API surface -- I'm just saying we need to justify additional complexity in the core spec (particularly if it could be added in clients instead)

@Troy - the full document PR? just needs an issue/warning, and it’s good to merge

@Troy I will make some changes to it based on feedback I got today

(Troy, my point is that we need a strong gating function on adding complexity ... or we will just add *all the things* :) )

q+

tobias -- is another use case to revert changes?

When I see unneeded sequential network roundtrips, I want to optimize those :).

sure ... we just may disagree on the necessity/utility in this case (e.g., better security model)

@Troy - it’s the “sequential” part that I wonder about. (vs in parallel)

Call 1 - Get IDs and wait for response.

Call 2 - Use response to request document.

sequential

ah I thought you meant the individual document calls in part 2 are sequential

I do want to point out that this two-step process plays an important role in many document stores (Cassandra, MongoDB, CouchDB, ElasticSearch, etc)

but each of those also exposes the ‘fullDocument’ flag as well.

or to put it another way - this is not about optimizing. it’s a straight-up engineering tradeoff. You’re trading longer latency for higher throughput

and it’s not always a beneficial tradeoff

also, a lot of the time you want to *do* something with the documents that come back from that call ... and you may not want to wait for every document to be returned before starting that thing

^ yep, that

q+

in this case, you almost always want to decrypt if nothing else... so you want to be using CPU cycles while you download vs. waiting.

I think it’s important to note that yes DBs have that flag for a reason ;).

::nods:: agreed

but they also have a lot of warnings around that flag.

and those databases don't do client-side encryption (that i'm aware of)

I guess no databases do client-side encryption, technically - EDV just enforces it

Something else to note - it it wasn't for CouchDB being able to return more than just the document ID, my EDV server would itself be slower...

q+

Though I believe supporting the "return full documents" feature shouldn't be too difficult

(implementation-wise)

q+

404 or a 410

+1 to Daves response

Out of scope initially

q+

q+

q+

q+

are you suuuure? (that those people never meant it to develop this way?)

.well-known can cause trouble for multitenancy

@Dave - that’s only if you don’t give your tenants their own sub-domain. which you absolutely should

heh... that is fraught with problems :)

what do you mean? it’s vastly preferable, security wise, than directory-level multi-tenancy

Ha was just about to make Dmitri’s point :)

such as the PSL (public suffix list) + cookie privacy issues that apple and facebook are fighting about right now

look at the lesson LiveJournal learned, about that

^ tell me more ?

Tenants based on url paths can be a mess too

you have to declare your top-level domain a public suffix and lose cookie access if you take that approach

oh, when LJ started, they gave each user an account in the old-school university style, like example.com/users/~dmitri/

and immediately ran into cookie security problems

and moved to subdomains, dmitri.example.com, for their multi-tenancy

q+

everything is difficult

q+

oh rt

q: Tobias, Andreas

@Dave - ok, but there’s a difference between “difficult” and “completely insecure”.

which is what non-subdomain multi tenancy is, that latter

/me raises his "burn it with fire torch" in support of Daniel.

/me wonders if livejournal is on the PSL

Put the ref into the Service Endpoints of your DID

if you really want to make it discoverable

this is how we will do it with Hubs

q+

https://publicsuffix.org/list/ <-- don't see livejournal on there

+1

the EDV *API* endpoint should be discoverable.

q+

s/the EDV/the root EDV/

I think that issue is just for the root

under "services" in a DID doc is another option

or in a VC that is shared/posted somewhere

thx all

I'd be fine w/ hogging the weekly call on it if people think it's improtant enough. :)