Open alanshaw opened 3 years ago
Sounds like a nice UX improvement.
I think we could support:
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?
not inherently opposed, but skeptical. IIRC there were 3 reasons we passed on this feature during the initial implementation.
ipfs add
defaults in the config file too and we passed for the same reason--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 termI'd argue this is way simpler case than ipfs add
, but yes, we should account for the future of ipfs pin
here:
ipfs add
, remote service names are arbitrary anyway (picked by user) and do not impact produced CIDs--service
is missing, then we know user has ipfs config --json Pinning.DefaultRemoteService
set – again, no ambiguityipfs 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
.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>
Having to specify
--service xxx
when using all of theipfs 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: