Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test Service-Worker: script behavior #260

Open
lidel opened this issue Jun 23, 2022 · 4 comments
Open

Test Service-Worker: script behavior #260

lidel opened this issue Jun 23, 2022 · 4 comments
Assignees
Labels
effort/days Estimated to take multiple days, but less than a week need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up topic/design-front-end Front-end implementation of UX/UI work topic/design-ux UX strategy, research, not solely visual design

Comments

@lidel
Copy link
Member

lidel commented Jun 23, 2022

Gateways should guard against the risk described in ipfs/kubo#4025
(additional notes in gateway spec draft here)

Not guarding should be punished with a big red error.

@lidel lidel added the need/triage Needs initial labeling and prioritization label Jun 23, 2022
@SgtPooki SgtPooki added P1 High: Likely tackled by core team if no one steps up need/analysis Needs further analysis before proceeding effort/days Estimated to take multiple days, but less than a week and removed need/triage Needs initial labeling and prioritization labels Jun 27, 2022
@SgtPooki SgtPooki added topic/design-front-end Front-end implementation of UX/UI work topic/design-ux UX strategy, research, not solely visual design labels Jul 13, 2022
@SgtPooki
Copy link
Member

Not guarding should be punished with a big red error.

@juliaxbow what should "a big red error" look like, including the consideration of any design changes after #93 ?

@juliaxbow
Copy link
Collaborator

@SgtPooki would this error notice pop up when someone clicked on a "bad" gateway? If so, suggest something like the following (with updated error text)

Error Notice

@SgtPooki
Copy link
Member

SgtPooki commented Jul 21, 2022

@juliaxbow The public gateway checker is more like an api status page: it shows "success" emojis/icons for desired properties of each gateway, or "failure" emojis/icons for undesired properties. i.e. we would want the information communicated without any user interaction


Examples:
Currently, if a gateway is offline, the gateway url is grayed out (or dimmed), if it's online, it displays as a link.
If a gateway supports CORS, it displays a success checkmark emoji, if not, it displays an X emoji.


So I imagine something to communicate not protecting against this error could be

  • a red overlay across the entire horizontal space, with a "more info" question mark.
    • quick solution thats easy to implement but may not support identifying multiple risks
  • a new column/icon for any risks that displays a count of risks not mitigated; when clicked on, you could obtain more info of each risk via a modal
    • slightly more challenging implementation that supports an infinite number of risks as we grow
  • a combination of the above?

@juliaxbow
Copy link
Collaborator

Spoke with the team in the IPFS GUI triage and will work to redesign the public gateway checker at large with considerations around additional columns. Will update this issue as well but it seems the primary issue is being tracked at #93

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/days Estimated to take multiple days, but less than a week need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up topic/design-front-end Front-end implementation of UX/UI work topic/design-ux UX strategy, research, not solely visual design
Projects
No open projects
Status: UX Design Needed
Development

No branches or pull requests

3 participants