devlooped
SL Manifest docs & feedback
UPDATED: I've polished a v2.0.0-rc.1 version of the JWT manifest(s) used by the new SL (both sponsorable and sponsor).
Please give it a read and let me know your feedback 🙏: https://www.devlooped.com/SponsorLink/ (source at docs/spec/2.0.0-rc.1.md)
A sample library consuming this new manifest-based SL for testing the end-to-end experience is available at https://www.nuget.org/packages/SponsorableLib.
Please give it a try and provide early feedback.
TL:DR; Some accuse you of 'activism' to try and coopt(force) support. Perhaps that is not an an unfair framing, terming.. however, if you were to buy into that way of looking at things; shouldn't you instead try to get support for your cause, by inspiring others to support it? - What better way to accomplish that than to make a special version of the package to help stimulate its continued development, so that others can support you willingly? That way the 'activism' is where it should rightly be, in the hands of a crowd that wants a fairer and just world.
Kzu, with a ll due respect, I think that you essentially burned the "goodwill" by secretly injecting something that superficially looked really suspicious if not malicious, and without very careful handling could really have been a problem.
Seeing as we all depend on the goodwill and trust of others, might I suggest inverting control? What about simply making a forked version of the nuget package which is simply Moq+Sponsorlink?- Making it entirely an opt-in.
In my opinion, It's totally fine if a developer chooses to start using a version that nags about how it would be nice if devs/the company they work for sponsored the company, if they are not doing so (Or in the future stop doing so). Contrarily, however, I think it is unacceptable to simply start egressing information out of closed systems that should be secure; this should always be a conscious choice/decision or explicit and integral to the functioning of software.
I understand that was not the intention perhaps of this feedback, but I don't see any feedback coming, and things have been so quiet that I can only summise that MoQ is not doing well.
Good luck, irrespective the choices to be made!
Contrarily, however, I think it is unacceptable to simply start egressing information out of closed systems that should be secure; this should always be a conscious choice/decision or explicit and integral to the functioning of software.
I take it that you didn't read the spec on which this issue is asking for feedback on.
I can only summise that MoQ is not doing well.
You'd be wrong:
The issue is always that there are a few vocal complainers, but the vast user-base doesn't care much. We're just all trying to get the user base to support the project in some way. Not even a license change seems to be of much consequence, which is precisely why I'm not keen on giving up on SL just yet.
@kzu ah...this is definitely a wrong attitude. If you think vast user-base doesn't care, you are playing with the fire. I just came to check because I have an issue in my repo reminding me keep an eye on Moq. I haven't migrated to other lib because I want to trust you that you will do the right thing and have more communication with the community. Yes, doing migration is time consuming but not that bad with AI now. If you still having this kinda mindset thinking no one cares, you are just killing your best project.
I really appreciate your time on Moq. I have couple open source projects, so I get it. I hope you can get what you want and not pissing off the community.
The specification draft (beta?) is mostly for the manifest. There's not a lot about how it'll actually be used in the process, (e.g. in the SponsorLink library). This is a crucial omission, as the process and the format need to fit each other (mostly the format being driven by the process and not the opposite). Is the SponsorLink supposed to be the "tool or library author to verify sponsorships in a secure, offline, and local manner"? Also:
Token Signing Implementations may choose to sign the JWT using a private key through a backend service. Although this is optional, it is recommended to prevent unauthorized alterations to the manifest.
If the token is not signed, then what's its value? It can be procured by anyone, circumventing its whole purpose. If the token is signed, then who's the central entity to sign tokens, containing information about various sponsored projects/organizations? How will this solution ensure sponsors privacy (e.g. anonymity), if the information about all sponsorships would need to be passed to the central token signer? How would that token signer verify, that the sponsorship proofs are legit? If each sponsor issues (and signs) individual tokens, then the concept of holding a collection of sponsorship hashes does not make sense, and there needs to be support for a repository of tokens and not just a single SPONSORLINK_MANIFEST variable holding one.
It seems to me, that you are basically trying to build a system for issuing digital licences, without acknowledging that you are. You're trying to provide a way for a user/organization to be able to locally prove to a piece of software, that they've fulfilled some requirement, for the software to exhibit a behaviour (which may be actually to not do something). E.g. prove, that "sponsorship" fee was paid, so the "free" software library will stop harassing the library consumer (software vendor). There are software solutions addressing this already. Including open source solutions.
I know I'm probably wasting my time here, but no amount of technical discussion can help with the community relations issue this project is facing.
- The way sponsorlink was introduced in Moq was a major trust buster. The way it initially got removed made things worse.
- Combative attitude towards negative feedback on the core premise of the idea erodes trust even further.
To put it bluntly, asking community to help with re-introducing an unwanted feature does not come across as a sincere intent to listen.
There are software solutions addressing this already. Including open source solutions.
Sure. There's solutions to pretty much everything under the sun, I know.
The goal is not 100% infallibility, but just a convenient and easy way for someone to get a manifest so local checks work. The format, being JWT and straightforward, allows for consumers (MSBuild tasks, run-time libraries, IDE extensions, code analyzers, whatever) to check and provide selective behavior in any way they want. SL won't dictate anything about that. It will be entirely up to the library author/manifest consumer.
So, this is not a mechanism to enforce licensing. Not even large game companies with hundreds of devs get to totally avoid pirating. The goal is to be a low-hanging fruit that's better than nothing at all, which is what OSS has today with basically just begging for sponsorships.
If each sponsor issues (and signs) individual tokens, then the concept of holding a collection of sponsorship hashes does not make sense, and there needs to be support for a repository of tokens and not just a single SPONSORLINK_MANIFEST variable holding one.
Well, as a simplifying assumption, I'd say nobody other than me will be using this mechanism. I intend on providing an oss backend that will issue the manifests and sign them (which you would emit and download with a tool like gh-sponsors), then your package would check the expected signature.
Anyone would provide such a CLI tool to emit the manifest and store it in some other envvar (named after their account, for example), and then check that envvar instead. That should be clarified in the spec, thanks!
Ideally, something like this would already be provided out of the box by each platform supporting sponsors (i.e. the GH CLI out of the box for any GH Sponsors project, Patreon and others), so there wouldn't be a need to aggregate or distribute multiple manifests.
Thanks @hilari0n, many of your comments are addressed in the latest spec and reference GH implementation spec. Yes, unsigned manifests was a dumb idea. A central one for all sponsorables was another lousy one.