SL Manifest docs & feedback

[kzu]

UPDATED: I've polished a v1.0.0-rc 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/1.0.0-rc.md)

[kzu]

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.

[maxisam]

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

[kzu]

That's why I'm giving ample time and opportunity to provide feedback.

[kzu]

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.

[kzu]

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.