Technical implementation proposal for Sponsorship in CLI by kalebfik · Pull Request #14997 · NuGet/Home

kalebfik · Jul 16, 2026

No description provided.

pranathibora14 · Jul 16, 2026

+```mermaid
+flowchart LR
+    A["<b>Gallery Database</b><br/>Stores package state, including sponsorship URLs"]
+    A --> B["<b>Catalog Writer Job</b><br/>Builds append-only catalog entries"]


I believe mutable properties like owners skip the catalog. I think it's read straight from the DB and compared with prior snapshot.

pranathibora14 · Jul 16, 2026

+**Proposed server flow:**
+
+- Add a **sub-command**, e.g. `UpdateSponsorshipCommand`, to the existing `Auxiliary2AzureSearchCommand` array.
+- Following the `UpdateOwnersCommand` pattern, read `PackageRegistration.SponsorshipUrls` per package ID from the Gallery database, diff against the last-indexed snapshot, and push partial-document updates to Azure Search for changed IDs only, setting a new `SponsorshipUrls` field on `SearchDocument`.


I think you should also mention how the first snapshot is created before this job takes over with comparisons with prior snapshots. I believe it's a separate job that does it.

pranathibora14 · Jul 16, 2026

+```
+
+### Proposed alternative design:
+ A dedicated `SponsorshipUriTemplate` V3 resource with per-package-ID fetch, consumed by a new `--sponsor` flag within `dotnet list package`


Our aim with alternative approach is still dotnet package sponsor right?

Yes! After further conversations, dotnet package sponsor is going to be the command used. The updated spec will reflect thsi

pranathibora14 · Jul 16, 2026

+```mermaid
+flowchart LR
+    A["<b>Gallery Database</b><br/>Stores package state, including sponsorship URLs"]
+    A --> B["<b>Catalog Writer Job</b><br/>Builds append-only catalog entries"]


Can you confirm if catalog writer job will get involved here?

pranathibora14 · Jul 16, 2026

+
+#### Proposed server flow: DB → API data flow
+
+- A new, dedicated **Sponsorship Snapshot Job**:


It might be good to mentioned that you want to consider reusing the Auxiliary2AzureSearch job here to get opinions on that and see if it's feasible.

Nigusu-Allehu · Jul 22, 2026

@@ -1,31 +0,0 @@
-name: IceBox Upvote Watcher


assuming these removes are accidental and can be brought back

Nigusu-Allehu · Jul 22, 2026

+
+#### Data assumptions
+
+- The client expects optional `sponsorshipUrls` as `IReadOnlyList<string>`.


We could be more specific about what the new json in the registration resource would look like after including this new sponsorshipUrls property

updating spec to reflect this!

nkolev92 · Jul 22, 2026

+}
+```
+
+**Ten sponsors** (matching NuGet.org's current policy cap)


Call out we're not validating anything client side.,

Yes, I'd rephrase to say Client is showing whatever the server provides. And as of the time of this spec, that's max 10 URLs.

Nigusu-Allehu · Jul 22, 2026

+- Candidate A extends `ListPackageCommand` with a new report flag.
+- Candidate B registers `dotnet package sponsor` but still routes into the same metadata-fetch, model, and renderer internals.
+
+Planned code updates:


nit: This is a very thorough write-up, and I appreciate the level of detail in the planned code updates. For a design spec, this may be more detail than necessary. Since implementation details can change, including too much code-level detail can make the spec stale over time.

nkolev92 · Jul 22, 2026

+
+#### Source transport dependency and client abstraction
+
+This proposal assumes the CLI consumes sponsorship data from the Registration API.


How do we detect that registration supports sponsorship?

I'm sure you have a plan, but just calling it out here would nbe good.

nkolev92 · Jul 22, 2026

+
+## Unresolved Questions
+
+1. Which command surface ships: `dotnet package list --sponsor` or `dotnet package sponsor`?


If we're not making dotnet package sponsor default to nuget.org only, then I don't mind dotnet package list --sponsor. Seems simnpler.

The issue with defaults is what's the privacy risk of exposing package IDs to nuget.org unintentionally?

Do we simply respect package source mapping, so if it's enabled, we only check sponsorship for packages that were mapped to "https://api.nuget.org/v3/index.json"?
All other packages IDs mapped to other sources, we say "N/A" or something for the sponsorship URL output?

I think if we add it to dotnet package list --sponsor then we should implement PSM.
Or at least assume we will implement it at some point.

All other packages IDs mapped to other sources, we say "N/A" or something for the sponsorship URL output?

Assuming we can detect the difference between no sponsorship details and no sponsorship period, then we can say N/A or whatever.
We can also just not show it at all. IMO, I'd just keep it simple and not show it at all.

nkolev92 · Jul 22, 2026

+## Unresolved Questions
+
+1. Which command surface ships: `dotnet package list --sponsor` or `dotnet package sponsor`?
+2. Should `--include-transitive` be supported?


IMO, yes.

Real question si what's the default.

If we support --include-transitive, that implies the default is top-level only.

If we support --include-transitive, that implies the default is top-level only.

Correct.

Maybe we keep it simple and we just show them all?

I honestly don't know if people would sponsor transitive packages and how they'd feel about that.

Your proposal sounds more like, show all by default, then have --exclude-transitive to only output the top-level?

nkolev92 · Jul 22, 2026

+1. Which command surface ships: `dotnet package list --sponsor` or `dotnet package sponsor`?
+2. Should `--include-transitive` be supported?
+For example, if package A depends on package B, should sponsorship data for package B also be shown?
+3. Should the command special-case NuGet.org by default?


If we default to nuget.org, imo we should choose dotnet package sponsor.
If we don't, then I think both are an option.

Nigusu-Allehu · Jul 22, 2026

+```
+
+```json
+{


Should we have a version for this json

Nigusu-Allehu · Jul 22, 2026

+dotnet package list --sponsor
+
+# Candidate B
+dotnet package sponsor


If we go with this one let's make sure to add an allow insecure connections option like dotnet package list.

I'd rather have someone ask for this.

The expectation is that this would only be used against nuget.org in practice right?
that should always be https only.

Technical implementation proposal

57f0829

kalebfik requested a review from a team as a code owner July 16, 2026 14:14

kalebfik linked an issue Jul 16, 2026 that may be closed by this pull request

Design Spec for Sponsorships in CLI #14999

Open

pranathibora14 reviewed Jul 16, 2026

View reviewed changes

Kaleb Fikadu added 2 commits July 20, 2026 12:42

full update of spec to reflect only server side changes

2c0fbbc

technical spec for client

5d8d60f

Nigusu-Allehu reviewed Jul 22, 2026

View reviewed changes

nkolev92 reviewed Jul 22, 2026

View reviewed changes

Nigusu-Allehu reviewed Jul 22, 2026

View reviewed changes

nkolev92 reviewed Jul 22, 2026

View reviewed changes

Nigusu-Allehu reviewed Jul 22, 2026

View reviewed changes


		#### Proposed server flow: DB → API data flow

		- A new, dedicated Sponsorship Snapshot Job:


		#### Data assumptions

		- The client expects optional `sponsorshipUrls` as `IReadOnlyList<string>`.


		#### Source transport dependency and client abstraction

		This proposal assumes the CLI consumes sponsorship data from the Registration API.


		## Unresolved Questions

		1. Which command surface ships: `dotnet package list --sponsor` or `dotnet package sponsor`?

+              ```
+              ```json
+              {

Search code, repositories, users, issues, pull requests...

Uh oh!

Conversation

kalebfik commented Jul 16, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Nigusu-Allehu Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Nigusu-Allehu Jul 22, 2026 •

edited

Loading