Skip to content
New issue

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

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

Already on GitHub? Sign in 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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