Enabling follow your nose when the application does not have or want a new data grant
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 20/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Domain
- backend-api-design
Research direction
Start by reviewing the options in this issue and the linked discussion at data-interoperability-panel#237. A useful outcome would be a resolved direction for handing users from unsupported applications to accessible resources, together with the affected specification requirements; no repository file or test is named.
Written by the indexing model from the issue text.
Description
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 https://github.com/solid/data-interoperability-panel/issues/237
- Just show a 401 error, as already spec-ed
- 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 - 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. - AA is registered at OS level as a handler, e.g. web share target
- Apps shouldn't link to resources they don't support
- Dominant language
- Bikeshed
- Stars
- 58
- Forks
- 18
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from solid/data-interoperability-panel
-
Align with LWS Access Requests and GrantsMay be free again @elf-pavlik claimed this 79 days ago, and no pull request is open. Open
solid/data-interoperability-panel#338 · 11 comments · 1 assignee ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
solid/data-interoperability-panel#337 · 1 comment ·
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
solid/data-interoperability-panel#336 · 2 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
solid/data-interoperability-panel#335 · 3 comments ·
-
Remove `interop:AccessAuthorization`, `interop:AccessGrant` and `interop:AccessNeedGroup`May be free again @elf-pavlik claimed this 514 days ago, and no pull request is open. Open
solid/data-interoperability-panel#334 · 5 comments · 1 assignee ·
All issues in solid/data-interoperability-panel
Similar issues
-
manager: startAgent retains the caller's subscribe/allowSubscribe/allowPublish arrays by referenceOpenarea:manager bug triage:confirmed
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Cotal-AI/Cotal#2874 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
golang/go#82033 · 2 comments ·
Maintainers usually reply within 1 day
-
area: capture good first issue priority: P2 type: defect
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
jiegui2025/hwspec#51 ·
Maintainers usually reply within 1 day
-
[Feature]:Openenhancement
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
thephpleague/commonmark#1159 ·