Support for publishing to IPNS

[swedneck]

Is your feature request related to a problem? Please describe.
It's annoying to have to use the terminal to publish content to an IPNS key, and it alienates non-powerusers.

Describe the solution you'd like
It would be nice if the webui let you generate, organize, and name IPNS keys that files and folders could then be published to via the dropdown menu.

[jessicaschilling]

Thanks for calling this out, @swedneck! Adding to our queue for further prioritization -- it's a large task, but a high-value one. You may also want to see related discussion here: ipfs/ipfs-gui#52

[FledgeXu]

I totally agree with this proposal. If users can use WebUI to publish their CID, that's will be nice.

[lidel]

Given that Brave is adding UI for managing IPNS keys and publishing to them, we should implement bare minimum publishing in ipfs-webui for consistent UX.

All necessary APIs are present, and we have some similar components which we could reuse.

@hacdias thoughts? This is not super urgent, so we can take time and do this at any pace we want, if you have bandwidth.

(1) Add IPNS key management UI to Settings page

• Add "IPNS Publishing Keys" after "Pinning Services"
  • This would be very similar to "Pinning Services" section
    • reuse visual language where possible
    • "Learn more" should link to https://docs.ipfs.io/concepts/glossary#ipns
  • List of available IPNS keys could be fetched via ipfs.key.list() and presented in a table with name and is columns
    • Each table entry has three dot menu button on the right, just like Pinning services with operations for managing the key:
    • self key is special and has no actions
    • additional keys have two actions available
      • "Rename" - ipfs.key.rename
      • "Remove" - ipfs.key.rm
• "Add IPNS key" button below the table
  • opens modal in which user enters name and clicks Generate or Cancel
  • Generate creates a new key via ipfs key gen with implicit defaults
    (right now only ed25519 makes sense, and it is the default, so no need to complicate UI)

Optional, but nice to have is to show which ID has something published on already:

• test if id resolves in offline mode (pfs name resolve /ipns/{id} --offline (means we published to IPNS before and have record cached in the local record store)
• if so, make value in id column clickable
  • onclick should open /ipns/{id} in a new tab on the "available gateway"

(2) Publishing to IPNS id via context action on Files page

• Add "Publish with IPNS" operation at the end of the context menu on the Files page
  • It should open a modal similar to "Set pinning" with slight differences
    • Show the CID about to be published (read-only)
    • List of available keys fetched via ipfs.key.list
    • Radio buttons instead of checkboxes – publishing flow should have only one destination
    • Publish and Cancel buttons on the bottom
    • Publish executes ipfs.name.publish({cid}, {key})

[hacdias]

I think both workflows are great and I will work on them. I don't have any other assignments and this seems to be a great improvement to the current Web UI state.

[ipfs-gui-bot]

🎉 This issue has been resolved in version 2.18.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀