Ipfs-companion: Add scoping for window.ipfs.name.publish and window.ipfs.key

[lidel]

Problem

• window.ipfs.name.publish enables sites to publish content to IPNS
• keys can be listed via ipfs.keys.ls
• this results in sites being able to publish arbitrary CID under any key
  
  
  
  • v2.2.0 assumes ACL dialog asking for access too ipfs.name.publish and ipfs.keys.ls is enough, shifting responsibility to user
  
  

This PoC will use default key and publish under your PeerID:

ipfs.name.publish('/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR', (err, name) => console.log(err, name))

Potential Solutions

• leave it as-is (shifting responsibility to user does not smell good)
• fix it: ipfs.keys and ipfs.name.publish should be scoped in a fashion similar to ipfs.files
  
  
  
  • website should not be able to sniff out what keys are in my possession
  
  
  • names of keys generated via window.ipfs.key.gen should be prefixed with unique scope and everything that is not in scope should be filtered out in all window.ipfs.keys.*
  
  
  • ipfs.name.publish defaults to self key if key name is not provided which means publishing to /ipns/<PeerID>
    
    
    
    
    
    • should this behaviour should be left intact? if so, we need to generate a new key just for the current scope and explicitly add it to the call behind the scenes.
    
    
    
  
  

cc @alanshaw

[lidel]

For now we will disable key and name.publish and keep this issue open until proper sandboxing is implemented.

[edrex]

This is the missing piece to allow apps to mutate a data set ala Beaker right?

CC @Jermolene

[lidel]

@edrex Yes, basically scoping ipfs.name.publish and ipfs.key aims to enable web apps to create an app-specific key(s) and use it to publish content to /ipns/<keyid>.

Digression: restoring those APIs in window.ipfs was on the back-burner because js-ipfs does not support IPNS yet (but we are _really_ close, see https://github.com/ipfs/js-ipfs/issues/209#issuecomment-438680997 :sparkles:) and we want to deliver the same API experience when user switches between js-ipfs and go-ipfs backends.

[satazor]

@lidel Now that js-ipfs supports IPNS, can we resume the discussion around this topic? To give you some context, both ipfs.name.publish and ipfs.key is used by https://github.com/ipfs-shipyard/nomios-web, a Identity Wallet based we are building. More specifically, we need to be able to import the key that controls your DID to be able to update it, via IPNS publish.

Using companion would improve the experience, specially in workshops were things work really fast inside the same network. I will be giving a workshop in IPFS Camp about Nomios and would be really nice if we could use companion 🙏

[lidel]

@satazor we can add ipfs.name.publish, however ipfs.key is bit tricky, depending on which subcommands you need. AFAIK go-ipfs v0.4.20 does not support key import and key export.
Do you need those in Nomios?

[satazor]

Thanks for the quick response. Yes we need to be able to import a key in order to publish a IPNS record with it (it’s different than the one used to identify the peer). Note that we only need to import it because ipfs.name.publish only supports custom keys via name and not via pkcs8 pem directly, which is unfortunate.

[lidel]

@satazor if you need import/export to work with go-ipfs, then we need https://github.com/ipfs/go-ipfs/issues/4240#issuecomment-494607171 to get addressed first.

If you are okay with doing the demo with js-ipfs, then we can add it and release before IPFS Camp.
Do you have sample key and JS code I could use for testing?

[lidel]

Closing due to https://github.com/ipfs-shipyard/ipfs-companion/issues/589#issuecomment-712356448

IPNS resolution via js-ipfs running on a page in web browser is tracked in https://github.com/ipfs/js-ipfs/issues/2921