Read URL from package.json

[egoist]

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 is a neat idea.

[hackergrrl]

Decentralize! ❤️

[zkat]

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]

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

[qubyte]

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'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]

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

[btkostner]

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]

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

[qubyte]

@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]

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

[adrianheine]

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]

@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]

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]

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]

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

[xdamman]

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]

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]

@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]

@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]

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]

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]

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]

@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]

@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]

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]

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]

@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]

@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]

Adding in @Jing-C from https://boost-lab.app to the discussion.

[martinszy]

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