feat: IPNS Publishing

[hacdias]

Closes #1482.

• Add IPNS key management UI to Settings page
• Publishing to IPNS id via context action on Files page

A bunch of screenshots

The context menu is a bit unaligned. The same happens with the Pinning Services context menu. The target reference seems correctly set so I'm not sure why's this miscalculation happening.

[hacdias]

This one is ready @lidel :D

[lidel]

Finally, got to spend some time with this :)
Works really good, want to include it in go-ipfs 0.11 if possible.

Before we merge this, need to add some e2e tests tomorrow:

• add key and confirm pet name is added to the table
  • publish to the key from files
    • confirm link on the settings screen got updated
  • remove key and confirm it's gone from the table

For now, pushed small changes which tweak some modals a bit:

[lidel]

Added E2E tests and cleaned them up a bit, should be pretty robust now that we use playwright.

---

@hacdias I think we have UX gap around publishing, which blocks this from being shipped.

Need some sort of confirmation that publishing was successful.

Visual feedback on IPN Publish

Right now I click Publish and nothing happens.
We need three states:

• "Publishing in progress"
• "Publishing successful" / "Publishing failed"

A nice flow would be if clicking on "Publish" displayed spinner until ipfs.name.publish returns result (success/error), and then:

• if error, show error inside of the modal.
• if success, show "Succes, published at {keyid}" and below the same UI we have on "Share" modal, where user can copy a shareable link to /ipns/ address at a public gateway.

@hacdias will you have bandwidth to add this?
I think it is better to wait and polish the experience, so I'm descoping this from go-ipfs 0.11, so there is no rush.

[hacdias]

@lidel I'll work on it.

[hacdias]

@lidel it's still missing the actual spinner. Could you just validate if the workflow is good?

[lidel]

@hacdias yes, the user flow ending with "sharing screen" and "Copy" action is perfect 👌

Figuring out an engaging spinner will be tricky – some thoughts:

• IPNS publishing can take up to a minute atm because (iirc) it puts IPNS record in 20 peers, and it has to find the right ones first. (It is faster if Accelerated DHT Client is enabled, but can't use it by default yet).
• A fake progressbar that assumes to take ~1m should be enough of feedback / setting expectations. We can improve it later.
• We don't have tracing API to see actual IPNS record puts as they happen (yet). If you want to get creative, we could inform user about DHT traversal, eg. show random DHT walk with await first(ipfs.log.tail()) or fake it for now. Goal is to communicate to user that "IPNS publishing is in progress, may take big long"

ps. fysa pushed two changes:

• Finished E2E tests for IPNS publishing – they now confirm IPNS record was updated by doing ipfsn.name.resolve.
• Added some copy text above the shareable link. (just a draft, when we are done we will ask a native speaker to proofread and refine messaging and UI)

  

[hacdias]

A fake progressbar that assumes to take ~1m should be enough of feedback / setting expectations. We can improve it later.

I will do this. Seems to be the easiest. Using a spinner would probably not be the greatest idea idea, indeed, as it does not give feedback.

[hacdias]

@lidel I added a progress bar that is initially 60 seconds. After each publishing, we average the current expected time with the new time it take. I think that this way, it should improve and have better expectations over time.

[lidel]

@hacdias really nice!

• I adjusted the rolling average to overshoot rather than undershoot (apps fake progress and usually finish around 75% to give that "snappy feeling", we guess based on past times, which is better, but still should overshoot to avoid being stuck at 100%) + added brief explainer what is happening, so the wait is a bit more justified:

  

• Pretty close to being mergable. I'm marking this as blocked on go-ipfs roadmap:
  • We need to figure out if it is ok to ship the GUI for IPNS before we have things like Enable IPNS over pubsub by default  kubo#8591 and IPNS Pubsub Reprovider Duration (GC for unused topics) kubo#8586 in go-ipfs, or are those worth waiting for. Will pick this up and make the decision in January.

[lidel]

💭 nit: I wonder if we could remove setInterval here and use css animations instead somehow? (would look less choppy, we could also make it more engaging by making it non-linear).

I'm thinking setting progress to 100% and using animation: progressBar ${expectedPublishTime}s ease-in-out for customizing the progress animation instead.

Just an idea, feel free to ignore.

[hacdias]

@lidel I added an option that will make ProgressBar use CSS animations. I also added an overflow: hidden to the parent div so that the colored part/progress does not overflow.

[lidel]

@hacdias I don't believe ipfs/kubo#8591 or ipfs/kubo#8586 will happen this quarter, let's not wait anymore. I think it is ok for us to ship it because IPNS publishing should be in IPFS Desktop, and unlike the upstream kubo (go-ipfs), IPFS Desktop has IPNS over pubsub enabled by default, so performance will be acceptable.

Mind resolving conflicts in this PR and pinging me when ready? 🙏

[SgtPooki]

@juliaxbow this is a great candidate for your review and help!

[hacdias]

I tried a different of rebasing and I guess I messed up this PR. Sorry for that and won't happen again. The branch is fine, but this PR got closed and I can't re-open it.

Continue on #1973.