Irrespective of the merit of such an addition, sponsor= or funding= is probably a better field than money=.
A potential big issue I see, separately from the problem of immutable metadata describing soft details, is clearly distinguishing what content is crates-io affiliated/approved and what content is user-generated.
Currently, it's very clear that the README panel is content directly controlled by the crate, and not by crates-io. The links are sort of a middle ground; their text and purpose is controlled by crates-io and more directly integrated into crates-io controlled content, though they do of course link to 3rd party resources decided by the crate author.
If the crate is able to add its own free-form links in that section, outside of the README panel which is clearly crate specific content, it blurs the line a bit further to what is crates-io content and what is crate controlled content.
If we do add something along these lines, it shouldn't be (forced to be) tied to releases of the crate. Crates-io already has a concept of crate owners; that's the obvious place to put "how to sponsor this developer" links, rather than tying it to the crate. (This model is "selling" support to/from the dev, not "selling" the crate.) Then the crate can have a sponsor tab showing the sponsor info for all of the owners.
While GitHub Sponsors is far from perfect, its UI decisions are worth looking at and drawing inspiration from as an example of how to surface this information.
Yes. It's the best place to do it. How many ppl visit crate pages and click on the various links? By the time you're actively using the crate, you no longer care about things like homepage and whatnot, so a mechanism that works for those actively using crates is the only real option. Let alone when the link didn't originally exist when you first picked the crate, so you'd never be aware of it.
I now hate this proposal. What form is the nag going to come in? Build warnings that I now have to wade through to get to what my real issues are? Automatic opening of some link? The latter triggers every IT-related sense that I have to bring in the ban hammer and block rust from the internal network. I vote no on this. Keep the donation links in the README, and leave it at that.
You're misrepresenting what I don't like about this proposal. It ties the rust environment to something that will trigger psychological responses, ones that I, for one, don't want to have tied to the language or ecosystem. The fact that this argument is getting heated enough that we are arguing like this is itself evidence that it will trigger psychological responses.
Then... put it it in your build.rs file instead? That way you can avoid all the issues with forcing the Cargo team to deal with it, everyone else wondering if they've gotten something nasty on their system, and any other weirdness that we haven't yet accounted for. I mean, @Nemo157 showed an example of how to do it. There's no need for this in Cargo.toml directly.
Edit
@Nemo157, can you please add a link in your earlier message to the proof of concept?
IIRC, the backlash was what led to npm implementing the npm fund command, which is similar to what Soni was proposing in this thread, I think. It's a nice thing to have, but I feel like if people aren't willing to go to a library's GitHub page to find out how to donate, they're not going to bother running a command to do it either.
I don't have the code anymore, I shred -u'd it immediately after making the screenshot; IMO it is essentially a very mild form of malware. It's not too hard to do on linux if you know how the TTY works (I have no idea if there's a way to do something similar on windows).
We don't want ads, we want fixed links beside the crate name. But yes.
(And yeah ofc it was Feross who decided to put wohle-ass ads into the things. Might aswell have put cryptominers while at it. .-. We personally don't think either of those approaches are at all useful, but a simple link to a patreon page or w/e when building the crate would go a long way.)
I had a sudden, odd thought this morning that I can't quite shake out of my head... what are the legal implications of adding a money field or donations field to Cargo? Would this get the Rust Foundation or anyone else involved with rust in legal trouble somewhere around the world? Governments can be very touchy about money issues, and I don't want anyone to get into legal trouble/tax trouble/etc. At least if the payment is in the README, there is a reasonable claim that the end user did the 'bad' thing (at least, from some local jurisdiction's point of view), but if it is implemented in Cargo directly, would there be any claims of culpability against the Rust Foundation/Cargo team?
I know all of that sounds like paranoia and FUD, but it really is intended as an honest question. I just have no idea if I'm being paranoid, or if it is a legitimate concern.
GitHub, setting aside GH sponsors, has built-in support for linking to services like Patreon, and can additionally provide arbitrary links for funding. If GitHub (owned by Microsoft) determined it was acceptable, I presume the same reasoning would apply to Rust. Likewise for npm with their built-in support.
Maybe we could instead add a field "crates_io_author_id" or something. Authors would then set up an ID independend of their crates, where they can add their other information (name, homepage, mail, sponsering link, etc.), which is then referenced in the actual crate. This would allow authors to change there information later on, without changing the crate itself.
crates.io already has support to associate mutable metadata with a crate, currently afaik just the owners and whether the crate is yanked. IIRC one of the future-ideas of removing the authors field from Cargo.toml was that crates.io would be able to start recording that data mutably too. So it seems like adding other sorts of mutable per-crate metadata to crates.io could be allowed. But that feels like it would definitely need an RFC; especially if cargo were to display that data since that would need changes to crates.io + cargo + the registry API spec.
Good point! Like I said, my reply wasn't meant as FUD, it was an honest question.
I wish the Rust Foundation had enough money to pay for enough lawyers to track this issue in all the different jurisdictions. It would help settle this kind of question immediately.
I assumed that the field would simply contain a link to a website such as GH sponsors or Patreon. Since that link can already be added to the Readme or as the homepage field, I don't see what legal problems could arise that don't already exist today.
You're probably right. However, its the degree of separation that concerns me. Rust/cargo/crates.io is neutral and silent on the subject of money. You can put in links to whatever you wish in your README.md file, and it's on you as to where those links point to, and whether or not merely pointing to those links is considered to be illegal in certain jurisdictions.
The issue is that if there is a field within the Cargo.toml file that says money=, some enterprising prosecutor may try to make a case stating that Rust willfully created an environment that condoned some illegal activity. Will the charge stick? I don't think so. Will it be a ridiculous headache that the Rust Foundation has to spend time and effort dealing with? If it came up, probably.
The only reason I decided to bring this up was because of how touchy governments can be about money, and how much of a time and money wasting annoyance it would be to have to deal with it, no matter how ridiculous the charges might be. My own personal opinion is that while it is unlikely to be a major point of concern, I just don't feel like dealing with it, especially when it's so easy to just let people put a link their README.
All that said, if the consensus is that a money= field is OK as long as its just a passive link, I'm OK with that. Anything that's active (like something that pollutes the build logs, or hijacks the user's browser to take them somewhere), I'm against.
This is a terrible idea when it comes to anything money-related, as it means your payment will get sent to some other person, instead of the person you actually intended to pay.
