Property to indicate an agent's preferred proxy endpoint for applications to use

[csarven]

This issue was originally raised at https://gitter.im/solid/node-solid-server?at=59f0b46501110b7231fd132e with some interest in its use:

In order for applications to respect a user's privacy (to some extent [*]) an agent's profile description can signal their preferred proxy endpoint. Applications upon discovering this property (eg solid:proxyUrl or solid:preferredProxy ?) can use it where applicable. When this piece of information in not available, applications would typically use their built-in proxy endpoint as default. Hence, once the agent's preferred proxy endpoint is known, cool applications can override the default (eg dokieli/dokieli#230 )

solid:preferredProxy
  a rdf:Property ;
  rdfs:label "preferred proxy" ;
  rdfs:comment """An agent's preferred proxy endpoint for consuming applications to use. The value of the property is intended to be used as the base URL for the request eg. the preferred proxy as literal: `https://example.org/proxy?uri=` would be used to request `https://example.net/profile/card#me` as `https://example.org/proxy?uri=https://example.net/profile/card%23me`"""@en ;
  rdfs:domain foaf:Agent ;
  rdfs:range rdfs:Literal
  .

domain and range could be omitted in the vocabulary definition document. Range is a literal because we want the application to use that as the base URL for the intended request.

Example profile statement:

<http://csarven.ca/#i>
  solid:preferredProxy "https://example.org/proxy?uri=" .

I could not find an existing vocabulary that would indicate this, so I'm raising it here.

[*] Obviously applications do not have to care about this nor should agents rely on the application to use their preferred proxy endpoint. The bottom line is of course the level of trust an agent puts on the application that they use - which could very well mean that the application will use their built-in proxy endpoint for certain operations.

[megoth]

1. In your example

<http://csarven.ca/#i>
  solid:preferredProxy "https://example.org/proxy?uri=" .

How should the Solid server interpret this? Redirect to the given URL for a resource with instead of opening it with the default data browser?

2. Could another example be the following (in publicTypeIndex.ttl):

@prefix : <#>.
@prefix solid: <http://www.w3.org/ns/solid/terms#>.
@prefix pub: </settings/publicTypeIndex.ttl#>.
@prefix bookm: <http://www.w3.org/2002/01/bookmark#>.

pub:id1559824551029
    a solid:TypeRegistration;
    solid:forClass bookm:Bookmark;
    solid:instance </profile/bookmarks.ttl>;
    solid:preferredProxy "https://example.org/proxy?uri=" .

I'm sorry if these are faulty examples, just trying to understand the use cases for this.

[csarven]

The server doesn't do anything other than responding to a GET request like:
https://example.org/proxy?uri=https://example.net/profile/card%23me

A server (like NSS, see eg corsProxy in config) announces a proxy service at /proxy?uri=

The domain of solid:preferredProxy is intended to be an agent (person or software). So, I don't think pub:id1559824551029 works here.

[Otto-AA]

Would it be possible to create a proxy where the url is inserted at one specific place in the proxy rather than the end?
I don't have a particular use case, but I could imagine that some applications don't expect the target uri at the end, but somwhere in between. For instance: solid:preferredProxy "https://example.org/proxy?uri=${URI}#anchor" . or solid:preferredProxy "https://example.org/proxy/${URI}/path/ ..

[csarven]

@Otto-AA Good point. We need to find a useful balance. I like the idea of preferredProxy value being a URI Template (RFC6570). As long as there is agreement on the variable (mentioned in property's comment), it should work™.

[csarven]

Just dumping some initial thoughts before I forget. Will revisit.

Multiple 'trusted' proxies sounds good to me. If a preference is indicated, apps can use that. Otherwise, they can select one at their discretion.

Okay to go through trusted proxies/services where it describes itself (eg. eventually having solid:proxyTemplate). Perhaps use solid:preferred (applicable to any, not only proxies) as a boolean? Alternatively, have solid:preferredProxy refer to a trusted proxy/service (IRI).

I suppose the next question is the discovery itself. I'm not sure if solid:trustedApp makes sense here. Kind of feeling, no. So, maybe the notion of solid:trustedService makes sense, if we also want to factor in other stuff, like query endpoints.

I think the notion of trusted is fine, but it is still a part of general declaration of preferences I think. Perhaps going through space:preferencesFile makes sense instead of solid:trustedService from the WebID. preferencesFile will still need to list trusted proxies/service. So, solid:trustedService(s) may work out somewhere in the end.

Thoughts?

[csarven]

Alternatively, the domain of this property is unspecified, and the term can be generalised to something like solid:proxy so that it can be advertised as part of a storage's communication options ( solid/specification#355 (comment) ). Different ways to model, e.g., solid:preferredProxy could still be a subPropertyOf solid:proxy. I'm more interested in having something in place than not having anything...