Enabling follow your nose when the application does not have or want a new data grant

[josephguillaume]

When restricting data access by application as well as user, a user might want to follow a link to a resource that they have access to, but that the application does not - and does not wish to support.

An app developer would want confidence that if they support arbitrary links, SAI/Solid provides a consistent and acceptable user experience of handing over to another application.

If Alice follows her nose from a non-Solid app, Alice would also expect to be provided some kind of user interface

I believe this has implications for a spec, though it is not yet clear which.

Here are some options, mostly based on conversation at #237

1. Just show a 401 error, as already spec-ed
2. Accessing resources on Solid storages MUST offer a user interface for the user.
   2a) Resources offer a default view of themselves
   2b) Minimal login, e.g., via FedCM
3. hand it off to an app with universal access, which the user's profile(?) MUST define
   3a) hand it off to AA
   3b) hand it off to a "launcher app", which is not the AA but does have universal access.
4. AA is registered at OS level as a handler, e.g. web share target
5. Apps shouldn't link to resources they don't support

[josephguillaume]

My current personal preference is for 2a+3a, where my AA is a fully featured pod browser accessible directly through the resource uri, with the ability to redirect straight to another app if set up to do so.

As an app developer, I think I would want 2 to be spec-ed, with behaviours 2a, 2b, 3a, 3b open to the user's storage's implementation.

From the point of view of SAI, I think I would want it to be left open that a pod browser can be an AA or a launcher app.

[elf-pavlik]

Thank you, @josephguillaume, for summing up various conversations.

My current personal preference is for 2a+3a, where my AA is a fully featured pod browser accessible directly through the resource uri, with the ability to redirect straight to another app if set up to do so.

I just wanted to clarify if we are discussing a special case where End user == Resource Owner; for example, Alice accesses data on one of her own storages. Or a general case where End user != Resource owner; for example, Alice accesses data on one of the storages owned by one of the organizations she collaborates with, say ACME.

The more general case usually comes with more complexity. If Alice accesses data on one of ACME's storages, I don't see how Alice's AA / pod-browser could be accessible directly through the resource URI.

[josephguillaume]

Thanks for picking up on that.

I'm interested in the general case but my description of consequences was indeed for the special case.

I think my preference is still that the resource uri provides a pod browser interface, but if Alice accesses data on an ACME storage, this would mean that ACME's pod browser would be shown.

This is similar in experience to following a link from a One Drive document to a Google Drive document.
The assumption is that web users tend to be used to different UIs when crossing website boundaries.

(Edit: This seems to be more 2a+3b, but bypassing an extra AA step when the resource is on Alice's storage)

Again, 2 would be spec-ed.

For SAI, I think ACME's pod browser would require Alice to login and an access grant needs to be in place in relation to that resource+ACME's pod browser+Alice?

ACME's pod browser doesn't need universal access to all of Alice's data, but presumably does need universal access to all ACME's data that Alice has access to?

If Alice's pod browser is her AA, it's not clear to me whether it could also be a non-AA app for Bob, when he follows his nose to one of Alice's resource URIs?

[josephguillaume]

Arguably an argument against 2a)
https://fosstodon.org/@justinfagnani/113409454642963587

Mastodon's federation seems fundamentally slightly broken to me, like the concept of links haven't been fully thought through.

The fact that you can click a link to a Mastodon post on another server, have it look like a post your server, but not be able to interact with it properly, is just terrible DX.

You have to have an accurate mental model of how the network is implemented for it to make sense. Even if you do it requires more attention and causes friction.

Link to other Mastodon resources are really two things:

1. A link to a piece of content, profile, etc., that can be viewed from any server.
2. A link to that content on that specific server.

I would argue that (2) is rarely useful. I always want links to Mastodon content to be viewed on my server, where I'm logged in.

It would seem better for users and the network to be able to distinguish Mastodon-specific links. Is this not part of the protocol? Why doesn't it work end-to-end?

Solid is different to Mastodon in that Alice can be logged in to Bob's storage's pod browser, but there still seems to be a preference for a link being opened locally.
This is perhaps a vote in favour of 3a or 3b.

The flow would perhaps be that the app tries to dereference the uri and through headers(?) discovers that it's a Solid resource or simply a resource it cannot handle.
The app would already know the user's AA and could hand over to it.

An app developer would want confidence that if they support handing off arbitrary Solid links, the AA is also the user's preferred default app to open a resource.
If we were to go down this path, I think the SAI spec would need to mandate this.
Alternatively SAI could provide for discovery of a "default app" or "launcher app" that the user would like to use.

[NoelDeMartin]

I have no solutions for this, but in case it's useful I'll share my thoughts.

In Umai, for example, I have this dialog to "Share a recipe". But I wasn't sure what was the best way to do it. Ideally, I'd like to just share the url of the document itself. But since the UX for the person receiving the link is not great (and may depend on the POD provider), I decided to create a "viewer" page for recipes. But yes, as an app developer, what I'd prefer is just sharing the link to the document itself.

Ideally, this could be configured by the person opening the link. Maybe this can be achieved with a browser extension? Or even configured in the user profile with RDF (and expected to be respected by all PODs?). The simil that comes to mind is how this works in Android (maybe also in iOS, but I'm not sure). If you get a link for a PDF file, it will be open with the default PDF reader you have configured. Same with an mp3, JPG, etc. It would be nice if in Solid, we eventually reach a point were people can configure their preferred apps to view documents. And we could have a default view, in case there is no dedicated app, that shows the triples in a more user-friendly way, rather than raw Turtle (Maybe something like Penny, etc).

Or, at risk of making it even more complicated, the rule could be:

1. Does the person opening the link have an app configured for that type of document?
2. If not, does the POD owner have an app configured to display this type of document?
3. Otherwise, show default RDF viewer.

[elf-pavlik]

I have a demo of sharing a resource with another user using a redirect with resource indication https://youtu.be/IXzdH1JqcOA

As you can see, this information is propagated in real time via solid notifications. I could add a push notification to the authorization agent UI on the user's device. When a new resource is shared with them, they could tap the notification, which would take them to their authorization agent, who can offer them to open it with compatible apps that are already authorized or filter apps from the user's connected 'app store' so that they can authorize a new app and open the resource using it.