Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Allow pins to have arbitrary metadata #670

Closed
7 of 9 tasks
victorb opened this issue Feb 13, 2019 · 6 comments · Fixed by #891
Closed
7 of 9 tasks

Allow pins to have arbitrary metadata #670

victorb opened this issue Feb 13, 2019 · 6 comments · Fixed by #891
Assignees
Labels
exp/novice Someone with a little familiarity can pick up help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked

Comments

@victorb
Copy link

victorb commented Feb 13, 2019

Pre-check

  • This is not a IPFS Cluster website content issue (file those here)
  • I read the troubleshooting section of the website and it did not help
  • I searched for similar issues in the repo without luck
  • All my peers are running the same cluster version
  • All my peers are configured using the same cluster secret

Basic information

  • Type (mark as appropiate):
    • Bug
    • Feature request
    • Enhancement

Description

Currently, ipfs-cluster allows users to attach a title metadata which is stored together with the pins but separate from the pin itself.

For Cube (and other use cases as well), it'd be very helpful if ipfs-cluster could store additional metadata as well. Things that come into my mind is things like tags, links to other resources and description. Hopefully it can be implemented in a way that arbitrary structures can be supported.

The way the metadata would be created could be either when creating the pin itself, after the creation of a pin in ipfs-cluster (attaching metadata). We would also need to have a way of updating/deleting metadata. With this, comes the need of having a log of the modifications to metadata. Not sure if this is needed in a first iteration on ipfs-clusters side.

On the other hand, this issue comes from ipfs-shipyard/cube#12 which brings up the thought that maybe metadata is not something that we need directly in ipfs-cluster, maybe should stay a user-land thing instead. I'll leave that up to the cluster team to think about.

@victorb victorb added the kind/enhancement A net-new feature or improvement to an existing feature label Feb 13, 2019
@hsanjuan
Copy link
Collaborator

Yes, this is going to arrive pretty pretty soon.

@hsanjuan hsanjuan added exp/novice Someone with a little familiarity can pick up P1 High: Likely tackled by core team if no one steps up labels Feb 13, 2019
@hsanjuan
Copy link
Collaborator

This was fixed but there are some cosmetic things missing:

  • Metadata cannot be set from the rest/client or ctl
  • Metadata not shown on ctl (I think).

@hsanjuan hsanjuan added help wanted Seeking public contribution on this issue status/ready Ready to be worked labels Jul 23, 2019
@kishansagathiya
Copy link
Contributor

some option like --metadata a=2,b=random

@hsanjuan
Copy link
Collaborator

I wonder if this is a good usecase for stringSlice. --metadata a=b --metadata c=f ... it is not nice to disallow the use of a , in the metadata just so this can pase.

@hsanjuan
Copy link
Collaborator

hsanjuan commented Sep 6, 2019

@kishansagathiya this is missing for the add command.

@kishansagathiya
Copy link
Contributor

kishansagathiya commented Sep 10, 2019

It is done for add as well.
Take a look at this test da02357

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
exp/novice Someone with a little familiarity can pick up help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants