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

Read URL from package.json #2

Open
egoist opened this Issue Feb 7, 2018 · 31 comments

Comments

@egoist

egoist commented Feb 7, 2018

Feel free to close it if this tool is only made for the maintainers and projects listed in https://github.com/feross/thanks/blob/master/index.js

The feature request is to support "thanks": "url" field in package.json so that all packages with this field set can be displayed in the thanks table. 😄

@feross

This comment has been minimized.

Owner

feross commented Feb 8, 2018

This is a neat idea.

@noffle

This comment has been minimized.

noffle commented Feb 8, 2018

Decentralize! ❤️

@zkat

This comment has been minimized.

zkat commented Feb 9, 2018

One thing worth noting is that you can already add arbitrary contact info for individual authors, which might also be preferable. See the expanded contact info I use for my projects, which already integrates with weallbehave for figuring out who to contact. You can probably reuse this field easily enough, or use it for lookup.

@egoist

This comment has been minimized.

egoist commented Feb 9, 2018

Yep something like author.donation author.patreon author.openCollective look good to me too 😄

@qubyte

This comment has been minimized.

Contributor

qubyte commented Feb 9, 2018

Using the expanded author info is intriguing, particularly when using the url field. If that URL served a document with a link or anchor tag for donations, this'd work well with indie web:

https://indieweb.org/payment
http://microformats.org/wiki/rel-payment

@marijnh

This comment has been minimized.

Contributor

marijnh commented Feb 9, 2018

This'd also address the problem of the burden of keeping the donation link data accurate being on you (if this takes off, I can imagine people submitting PRs to associates some popular developer with a patreon they control)

@tunnckoCore

This comment has been minimized.

Contributor

tunnckoCore commented Feb 9, 2018

I'm both for thanks field and inside author. 🎉 🌮

@btkostner

This comment has been minimized.

btkostner commented Feb 9, 2018

The url field is designed to be a homepage link, which may or may not be a donation link, but it would be best to keep them seperate. While the thanks field would work for this project, I personally think we should use the donation field. It's general enough that it can be used in other projects, and hopefully eventually be a part of the package.json spec. Secondly, allowing contributors.donation has the added benifit of being able to have multiple donation links for a package.

Down the line if we need more information, the donation field could be expanded to an object, similar to the repository field.

{
  "donation": {
    "type": "patreon",
    "url": "..."
  }
}
@pubkey

This comment has been minimized.

pubkey commented Feb 9, 2018

if we put the donation-data inside of a .thanks.json, this logic can later be reused with non-npm-projects.

@qubyte

This comment has been minimized.

Contributor

qubyte commented Feb 9, 2018

@btkostner To be clear, my suggestion does not change that url is for a homepage. The rel-payment microformat (see links) is a way of discovering a donation URL within a page (either as a link tag or an anchor tag). This means that anyone/anything visiting a homepage with one will easily be able to discover a way to donate.

@qubyte

This comment has been minimized.

Contributor

qubyte commented Feb 9, 2018

(something explicit in the package file would also be good, but this would be nice to have as another mode of donation discovery)

@adrianheine

This comment has been minimized.

adrianheine commented Feb 9, 2018

I would love to see @qubyte's suggestion implemented, both for ideological reasons and to ease maintenance. This should only work over HTTPS and validate certs, though. Also, explicit info from package.json should have precedence.

@qubyte

This comment has been minimized.

Contributor

qubyte commented Feb 9, 2018

@adrianheine Agreed on all counts. I'm putting a module together now which does this. I may make the suggestion as a separate issue so I don't hijack this comment thread any further.

@xdamman

This comment has been minimized.

Contributor

xdamman commented Feb 10, 2018

I like @btkostner but I think the type shouldn't be used to say "opencollective" or "patreon" because those can be easily figured out from the url.

Instead the type could be: url or bitcoin or ethereum.
e.g.

{
  "donation": {
    "type": "url",
    "url": "https://opencollective.com/webpack"
  }
}
{
  "donation": {
    "type": "bitcoin",
    "address": "14MEpy5a9MwDZa9CUzrfDhTU8dy2KKJ5mU"
  }
}

Issue: we cannot really use url anymore, hence address or maybe value?

@xdamman

This comment has been minimized.

Contributor

xdamman commented Feb 10, 2018

Alternatively, we could use the key as the type:

{
  "donation": {
    "url": "https://opencollective.com/vuejs",
    "opencollective": "vuejs",
    "btc": "14MEpy5a9MwDZa9CUzrfDhTU8dy2KKJ5mU",
    "bch": "15gftB3fwumFRWGWFhVzTgc4nhM5w1F2Tu",
    "eth": "0x3411356C1f0Bf5D859464eD2AC54DD2C222519B7",
    "ltc": "LUcHis3B8SFtEeZtuCaZoqsyN9XFAKmbCP"
  }
}

Btw, those are real values for VueJS (source).

@adrianheine

This comment has been minimized.

adrianheine commented Feb 10, 2018

donation could be an array with each entry having type (eth, btc, opencollective, url) and value (?) fields.

@xdamman

This comment has been minimized.

Contributor

xdamman commented Feb 10, 2018

That looks much more verbose. An array of just types and values really sounds like an object with attribute and value no? Also, an object makes it much easier to quickly test if a project supports a certain donation method (if (pkg.donation.btc) {})

The only reason to have an array would be if we want to store more data (e.g. current balance?). But I don't think that this is the place for it.

@marijnh

This comment has been minimized.

Contributor

marijnh commented Feb 10, 2018

There's an argument to be made for allowing both per-author and per-project links. A multi-author project might want to provide separate links or a single one (say, to an open collective), depending on how it's organized.

@adrianheine

This comment has been minimized.

adrianheine commented Feb 10, 2018

@xdamman You can have multiple values for a specific protocol, you can have multi-dimensional values for a protocol, and you emphasize that the protocol is not from a small, fixed set.

@adrianheine

This comment has been minimized.

adrianheine commented Feb 10, 2018

@marijnh I imagine the flow like this:

  1. Check if there is a hard-coded value for the project
  2. Otherwise, check if the project has a donation value in package.json
  3. Otherwise, check if there is some standalone file like maybe thanks.json or donations.json?
  4. Otherwise, check if the project's homepage has a payment rel
  5. Otherwise, check if there is a hard-coded value for the npmjs.com maintainers
  6. Otherwise, check if there is a donation value in the author members in package.json
  7. Otherwise, check if the author's homepages have a payment rel

I think 3 and 7 would be the preferred ways, 1, 5 deprecated and 2, 4, 6 totally acceptable.

@bumi

This comment has been minimized.

bumi commented Feb 12, 2018

I was experimenting with a similar idea a while ago for ruby gems (bundler thankyou). My goal was to use bitcoin as a system to transfer some tip directly to all dependencies (one payment to all)
I liked the idea of transferring value directly and NOT require a service provider (like paypal, opencollective, etc.) (service providers could still offer services for either party (payee or recipient))

Having the donation data in the package description (package.json, etc.) allows us to reuse the current trusted infrastructure, it is super easy for the package maintainer and donations can be defined for every version (for example: ruby on rails could donate the "thanks" for v 4.x to railsgirls)

I like the simple key/value proposal by @xdamman 👍
IMO the goal should be to have a minimal, small standard and maintainer should be always in full control over the entry. No third party system should be assumed. This gives everybody the choice and could allow tools and services evolve for either party and all different package managers.

@balupton

This comment has been minimized.

Contributor

balupton commented Aug 9, 2018

Thought I'd jump in with what we do with the Bevry ecosystem (around 300 packages).

We use boundation to generate and update projects, this injects the following package.json code

  "badges": {
    "list": [
      "travisci",
      "npmversion",
      "npmdownloads",
      "daviddm",
      "daviddmdev",
      "---",
      "patreon",
      "opencollective",
      "flattr",
      "paypal",
      "bitcoin",
      "wishlist",
      "---",
      "slackin"
    ],
    "config": {
      "patreonUsername": "bevry",
      "opencollectiveUsername": "bevry",
      "flattrUsername": "balupton",
      "paypalURL": "https://bevry.me/paypal",
      "bitcoinURL": "https://bevry.me/bitcoin",
      "wishlistURL": "https://bevry.me/wishlist",
      "slackinURL": "https://slack.bevry.me"
    }
  },

Which is rendered in the READMEs using projectz, which forwards that field to badges to get the rendered badges.

There was a plan so that Projectz will pull in the sponsors, and render them automatically in the readme. Already it just shows those in the "sponsors" package.json field (similar to authors, contributors, maintainers). However, I never got around to finishing the remote sponsor fetching as fittingly, there were no funds to support development. To some extent, the project sponsored that I setup to fetch, correlate, and expose such data, seemed to have a lot of the goals of thanks.

The upcoming goal is for a cloud project to routinely run projectz against the projects, so that READMEs stay up to date with the latest information. As well as a cloud project to routinely run boundation against the projects, so that they always stay up to date with the latest conventions.

As an aside, there are more nifty things in our community, such as editions and awesome-travis which allows us to write esnext, yet still support and test on node 0.8 etc. As well as automatic documentation publishing for commits, branches, and tags. However, that isn't related to this issue.

@pastudan

This comment has been minimized.

pastudan commented Oct 26, 2018

I had a similar idea, and found this thread as I was halfway through building a similar tool. I built a platform for handling software donations, givethanks.app, and a specification for adding donation metadata to your package.json, the Donate Spec. I'd love to get everyone's thoughts, particularly on the spec.

While developing the spec, I tried to keep everything as generic as possible. As @btkostner said above, I think this has a higher chance of getting adopted into the main package.json spec if we use donate instead of thanks and keep the spec as platform agnostic as possible

Feross' thanks is a great utility, and I plan on making a PR that consumes the spec after getting some community input. That way, authors won't need to continue making PRs into this repo to get listed.

@tunnckoCore

This comment has been minimized.

Contributor

tunnckoCore commented Oct 26, 2018

@pastudan cool one! 💯 But from the spec, i can't get how we can define multiple platforms - for example Bitcoin, Paypal, Thanks and Patreon? Only seeing "multiple recipients" which is.. kinda confusing to me, it means another thing?

Note that i didn't read it completely, just glance looked over the spec.

@pastudan

This comment has been minimized.

pastudan commented Oct 26, 2018

@tunnckoCore yeah, you can actually support multiple platforms and/or multiple recipients!

Check out the 3rd example here: https://github.com/ThanksApp/donate-spec#3-multiple-platforms

EDIT: Re-read your comment. You can also add multiple platforms for a single recipient, by just putting the platforms key in the top level. Example:

...
"donate": {
  "name": "Dan Pastusek",
  "email": "dan@hexial.com",
  "platforms": [
    {
      "platform": "Thanks",
      "address": "https://givethanks.app/u/pastudan"
    },
    {
      "platform": "Ethereum",
      "address": "0xBdcD67A49d61029e142492F33E42AA8b5Eb627DC"
    }
  ]
}
@tunnckoCore

This comment has been minimized.

Contributor

tunnckoCore commented Oct 26, 2018

Oooh, got it. I'm the recipient, yea 😆 The spec definitely sounds good to me and like it should be included in the package.json spec too. 💯 🥇
Chosen words are perfect - donate, platform, platforms, address.

edit: Maybe you should add this example there too. Yea, this example is explicitMultiPlatform type.

@balupton

This comment has been minimized.

Contributor

balupton commented Oct 26, 2018

I've added support for Buy Me A Coffee, Liberapay, Thanks App, and Boost Lab to badges. So you can generate the donation buttons in your READMEs using projectz.

A good next step would be for projectz to read the "badges" config and the "donate" config and do any appropriate merging of the two, so the two properties can generate each other.

@pastudan

This comment has been minimized.

pastudan commented Oct 26, 2018

@balupton yeah, merging those two would be awesome! You seem to have started standardized list of funding platforms. That's something that I hinted at toward the bottom of the spec, but it would be nice to have a definitive list somewhere. i.e, should it be always lowercase paypal, stylized PayPal, or title case Paypal?

@balupton

This comment has been minimized.

Contributor

balupton commented Oct 26, 2018

@pastudan perhaps we can do a trimmed down version of my unfinished sponsored project, where people can signup, list all their donation platforms, and it spurts out the donate and badges config for them to use, as well as a nice profile page that they can link to

It could even be used like so with the donate spec:

 "donate": {
    "recipients": ["balupton", "pastudan"]
 },

Which then calls say https://sponsored.app/recipient/balupton.json and https://sponsored.app/recipient/pastudan.json to fetch their latest and most accurate donate platform spec config.

Or with weighting it could do:

 "donate": {
    "recipients": [{"id": "balupton", "weight": 50}, {"id": "pastudan", "weight": 50}]
 },

Perhaps even the service could import people's github and npm packages, to allow a always up to date way of generating the appropriate spec info, without needing to specify it in the packages themselves. Such as https://sponsored.app/github/bevry/badges.json or https://sponsored.app/npm/badges.json. For instance, I maintain about 200 packages, and not everyone will be prepared to adopt the complex automated setup that I do, as detailed a few posts earlier.

Actually, for that last point, perhaps it could make use of the tech https://github.com/boost-lab/algorithm that https://boost-lab.app developed for figuring out the weighting automatically, rather than having users be required to update it all for their hundreds of packages. That would be even simpler!

And eventually, if anyone is interested, then it could even be used to add the dynamic features that sponsored was meant to have

@balupton

This comment has been minimized.

Contributor

balupton commented Oct 26, 2018

Adding in @jing-c from https://boost-lab.app to the discussion.

@martinszy

This comment has been minimized.

martinszy commented Dec 6, 2018

Hey, what about civic.json? http://open.dc.gov/civic.json/
Is it possible to consider also expanding that standard?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment