feat: helper-ui input-validator update

[SgtPooki]

Title

feat: helper-ui input-validator update

Description

Fixes #66

Notes & open questions

the input validator now accepts the same urls as verified-fetch (more actually since https? is not required) and provides more helpful information

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if necessary (this includes comments as well)
• I have added tests that prove my fix is effective or that my feature works

[SgtPooki]

self review

[2color]

From a code perspective looks really clean and correct for all the formats accepted. all the tests.

A couple points regarding UX:

• The help text with all the accepted formats is overwhelming. My opinion is that we should be a little more prescriptive about the preferred/conventional format while gracefully accepting others (without advertising all of the the graceful cases). The formats with example.com are particularly confusing.
• I'm somewhat surprised that we don't accept ipfs:// and ipns:// paths. I thought those would be considered the canonical form. I'm also that the /ipfs/.. and /ipns/.. are also common conventions in Kubo.
• Perhaps instead of adding /path to each example, you omit it from all and update the note to say that you can suffix any path with a path?

[SgtPooki]

The help text with all the accepted formats is overwhelming. My opinion is that we should be a little more prescriptive about the preferred/conventional format while gracefully accepting others (without advertising all of the the graceful cases). The formats with example.com are particularly confusing.

Ok good to know, do you or @lidel have recommended example text we should include here?

I'm somewhat surprised that we don't accept ipfs:// and ipns:// paths. I thought those would be considered the canonical form. I'm also that the /ipfs/.. and /ipns/.. are also common conventions in Kubo.

😲 I missed that. wow. Will add.

Perhaps instead of adding /path to each example, you omit it from all and update the note to say that you can suffix any path with a path?

good advice

[SgtPooki]

Ok I've got the help text as a table, how is this:

[lidel]

It still feels overwhelming. No need to flood user with all variants and permutations.
We just want to hint how valid value type looks like + maybe link to docs.

Maybe simplify closer to:

⚠️ Invalid address, correct it and try again.

ℹ️ For reference, accepted formats are:

• UNIX-like Content Path (/ipfs/cid/.., /ipns/id/..),
• HTTP Gateway URL (https://ipfs.io/ipfs/cid.., https://cid.ipfs.dweb.link/..),
• Native IPFS URL (ipfs://cid/.., ipns://id/..)

Learn more at Addressing IPFS on the Web

[SgtPooki]

Maybe simplify closer to:

Ok will do

[SgtPooki]

that doesn't look much better to me tbh:

I think we should have a single example per "Type" we want to show:

but there's also some alignment issues with that, so, back to a table but without the header:

[lidel]

Agree, one example per type looks better 👍

Lgtm, but while we are at it, we could improve two things:

• Rename input label from "CID (and path)" to something like "CID, Content Path, or URL"
  • Since it has "CID", add "CID" type (support pasing standalone CID without /ipfs/ prefix)

[SgtPooki]

• Rename input label from "CID (and path)" to something like "CID, Content Path, or URL"
  • Since it has "CID", add "CID" type (support pasing standalone CID without /ipfs/ prefix)

Done since 76ae50c & 30e0382

[SgtPooki]

merging due to implicit approvals via emojis on comments