keeping track of efficiency

[bblfish]

On the Monday 25 Jan Teleconf I presented a protocol, that looks like it has some efficiency advantages on first sight.
We should be able to tell by considering a use case that takes into account how HyperApps have to work. These are very different from normal apps tied as they are to a single server, as hyper-apps have to open connections by following links to other servers.

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.

We should be able to estimate how many connections this would require for different protocols.
At this point we should already be able to estimate the number of connections for OpenID Connect. I could try to develop the HTTP-Signature version to estimate the number of connections it would require.

[csarven]

FWIW, I suppose dokieli is a "hyper app" as per your description as few features are implemented with those characteristics. Off the top of my head:

• fetch inbox, fetch each contained resource, fetch one or more linked resources (eg. to discover decentralised annotations as part of the Annotations feature)

• authenticated user -> fetch WebID Profile Document, fetch all of its sameAs's (and follow); fetch all user's WebID's contact's WebIDs across all profiles (eg. to discovery their inboxes as part of the "Share" feature) - this is a deep traverse without revisits.

• above, plus: fetch their a) storage b) outbox, and if found, fetch each contained resource (eg. to discover relevant annotations/social activities as part of the "Activities" feature).

Feel free to scroll through https://csarven.ca/linked-research-decentralised-web#decentralised-linked-research-application for diagrams, descriptions, screencasts etc touching on the above.

Aside: re inbox/decentralised annotations.. that was particularly an annoyance (depends how you look at it of course) when requests were made against WebID-TLS based servers.. so the browser prompts the user with the certificate selection per server/annotation request - there was the browser feature to always submit without prompting but that's generally not deemed to be a good idea - you don't want to remain anonymous when desired.

[bblfish]

Re: TLS client certificate requests. My hope was at the time that the browsers would fix that. But I think it was too much change at the TLS level, and not very easy for the TLS server to express what kinds of certificates would be acceptable (they could only specify some Certificate Authorities that they accepted certs from).

When we re-implement authentication with HTTP-Signatures things are very different (see the Sequence Diagram I presented on Monday 25th Jan). There it becomes possible for the client to keep policies (expressed potentially in RDF) on when it is ok for it to send certificates automatically to a server in the Sig header. If the client can also get the ACL/ACP rules from the server telling it what it needs to show, it can then use those client policies to work out what certificates to send, and just ask the user in more complicated cases.

[elf-pavlik]

I think it would be interesting to keep network overhead in mind. Few quick observations:

• WebID Documents are intended to be public so we don't need authenticated requests for those, we could possibly pick use case discussed during last week interop panel https://git.startinblox.com/applications/trust/interop-hubl where 'cirecles' may be access controlled.
• If client would need to get 20 different capabilities for 20 different resource servers, HTTP/2 still seems helpful here since it they all would be requested from user's capabilities provider.
• If we talk about requesting protected resources, in scenarios like hubl circles, user would have something like Remote Data Registrations which application (if authorized by the user) would be able to use to discover existence of that protected data. As application gets links to that data from those registrations, i could as well get capabilities needed for accessing it.

[bblfish]

@elf-pavlik wrote:

WebID Documents are intended to be public so we don't need authenticated requests for those,

For the simple AddressBook example, it is easy to imagine that every WebID links to 3 to 5 groups with different protection levels:

• 1 public group
• 1 group for family members
• for colleagues
• 1 for business contacts
• 1 for foaf (so requiring a proof that one is a foaf)
• another based on some attribute

[gibsonf1]

@bblfish So the actual resources in this example would all likely be public, however, the groups listing the webid may not be?

[bblfish]

@gibsonf1 currently all RDF is open, so we need to imagine what the web would be like if it acted like a decentralised SN which a realistic number of open and closed resources. I think realistically everyone would have various closed groups. 5 to 10 perhaps? Those would link to discussions and content that is protected (for family, buisness, personal, ... ) I guess once authenticated for a resource you would not need to re-authenticate again that often for other linked-to resources, but still you could have groups within groups, like family, close family, adult family, etc...

If we follow CSarven's idea of people sending notifications about links on other servers that may be protected, then going through your notification inbox may result in each ping pointing to a protected resource on a different server. Clearly having good metadata in the ping will be important, as you may not want your agent to follow every link.

We should probably start simple to get some ballpark ideas, and then come up with some more complex examples.

[bblfish]

Another question on my mind is if HTTP/3 (Quic) would help. How much? (see recent research I did on Quic)