Default remote pinning service

[alanshaw]

Having to specify --service xxx when using all of the ipfs pin remote commands is repetitive and time consuming. It would be faster to type and slightly easier to script if you could set a default pinning service that is used if no --service is specified.

I bet that most people will only set 1 remote pinning service up anyway so not having to specify each time would be really useful.

Maybe a config option like:

ipfs config --json Pinning.DefaultRemoteService nft.storage

[lidel]

Sounds like a nice UX improvement.

I think we could support:

• implicit default when user has only one remote service set up
• explicit default when Pinning.DefaultRemoteService is set to the name of one of services
  (ipfs pin remote service rm would clear Pinning.DefaultRemoteService if used as the default)

@ipfs/wg-pinning-services @obo20 – thoughts?

[aschmahmann]

not inherently opposed, but skeptical. IIRC there were 3 reasons we passed on this feature during the initial implementation.

• it makes it harder to know what users are doing when they post a command without also posting their config
  • people have asked for setting ipfs add defaults in the config file too and we passed for the same reason
• we were hoping to unify this with a local pinning API and then not passing --service would mean local pin. i.e. didn't want to get people in the habit of not passing --service if we were just going to take it away in the short-medium term
• dev time during the initial implementation

[lidel]

I'd argue this is way simpler case than ipfs add, but yes, we should account for the future of ipfs pin here:

• Unlike parameter space of ipfs add, remote service names are arbitrary anyway (picked by user) and do not impact produced CIDs
• If --service is missing, then we know user has ipfs config --json Pinning.DefaultRemoteService set – again, no ambiguity
• If we want to support ipfs pin --service pinata then we could make future-proof this by naming this to generic Pinning.DefaultTarget (or plural *Targets, if we want to support pining to multiple places at once). By default, it would be pinning to local.

[Gozala]

I was thinking what if we got rid of —service and instead required ipfs pin <where>.

That way local pinning would turn into:

ipfs pin local add <cid> and ipfs pin add would just be a shortcut

And remote pins will be:

ipfs pin pinata add <cid> of course on could also just bind service to name remote which effectively will give us what @alanshaw was asking here ipfs pin remote add <cid>