efficiency requirements

[bblfish]

On the Wedn 27 Teleconf I brought up the importance of us keeping track of efficiency in our protocols, that takes into account how HyperApps work. These are very different from normal apps tied to a single server, as they have to open connections by following links to other servers.

We need to have a requirement that allows us to keep in mind efficiency of authorization protocols, favoring more efficient ones. For that I suggest we develop a realistic use case (something @elf-pavlik had suggested doing at some point last year).

Here is a realistic scenario for a hyper AddressBook App which I implemented 6-7 years ago in React. Such an AddressBook used for the first time, should be able to be pointed to a WebID Profile, and from the information there start drawing an initial UI, while at the same time following all the links to the profiles, hosted on other Pods. Here is an image taken from a wiki page on banana-rdf that illustrates the layout of @timbl's profile and its links to other resources.

We should count the number of links in his profile (and others) and the number of of connections required to get the content of his "foaf:knows" relations and potentially the number of connections from there on too. The first set of requests will lead to profiles or files linking to various groups. Each of these groups may or not be accessible to the client.

Let us say that TimBL has 150 foaf:knows linking to 100 Pods. Each of the resources on these Pods will return information letting the client know what credentials it can present to authenticate. With HTTP/2.0 the server could send the ACL description and related documents without needing to be asked for it if needed. In order to fill Tim's profile the client will want to download the picture, and a few other resources too, and the same for Tim's friends...

So we can imagine the client opening 1 connection to Tim's profile, then 100 connections in parallel to various servers and requesting 5 resources on each. (Of course future requests can then cache the data locally reducing the traffic). But this seems the right order of magnitude to consider.

[csarven]

Didn't want to duplicate content here about an existing public implementation (dokieli) where this is very much a concern, so linking: solid/authentication-panel#123 (comment)

[elf-pavlik]

I commented in solid/authentication-panel#123 Let's close this one and keep conversation in one place.

[bblfish]

These are two different issues. One is about efficiency of authentication, and the other about efficiency of authorization. There are different types of things we need to keep into account in both. In this case here, we may want to add a use case to the UCR, and perhaps add a requirement for it.