Repository navigation
Enforce some daily publish limits #21
Description
Activity
- changed the title
[-]Grace period before enforcing an aggressive daily publish limit[/-][+]Daily publish limits[/+]on May 27, 2025 - changed the title
[-]Daily publish limits[/-][+]Enforce some daily publish limits[/+]on May 27, 2025 I'd be pretty fine not having this for launch - as long as we have some basic moderation tools that allow us to e.g. 'delete all packages by this uploader'. Or perhaps having very high limits (e.g. 1000 packages per day).
I think in practice people are unlikely to abuse this, and the severity of impact is fairly low - compared to how annoying a limit of 1 or 10 servers might be for the power users of MCP (who are crucial to the ecosystem!). I say this as someone who seems ~reasonably likely to exceed 10 servers per day occasionally.
I don't want to rely too heavily on moderation here long term - would agree with low limits if this does turn out to be a problem. Just that I'd lean towards this probably not being a problem by default.
(Also if this is a widespread problem, I think another issue will be people creating many accounts and spreading quota across them - that will make things more difficult... I wonder if a Claude-powered screening would be useful here for spam packages).
Fair, I don't feel strongly on this. We did receive consistent advice from some major registry maintainers (npmjs, packagist) that spam of various kinds will be a problem at some point ("people will spam any popular system they can find on the internet"), so I wouldn't bank on it not being abused, but I agree that having a hard limit here could be problematic for power users.
I don't mind punting this to post-go-live if we do have reasonable moderation mechanisms in place as you said.
Agree re: Claude-powered screening as well, and maybe that subsumes this need if done well - #101
Reacted by adam jones- added 7 commits that reference this issue
on Sep 13, 2025 Closing this one out. The per-user daily publish-count limit proposed here was punted pre-launch, and in the seven months since, the abuse pattern that actually materialized was per-IP request bursts rather than spammy publishes. That's being addressed via the nginx-layer rate limit that's already in place (180 rpm per IP, burst 3x, returns 429), though we do see alerts from time to time and the tuning is tracked in #826. #746 covers the alerting side. We plan to revisit the rate-limiting story more broadly as part of the ingress gateway migration (#844). Easy to reopen if per-user publish quotas become a concrete need.
We originally planned to rate limit authenticated users to one new server per user/org per day.
@SecretiveShell flagged: "please hold off on this for the initial week, as I and probably many other people would want to add their multiple existing servers in one go when it initially launches"
This makes sense to me. If we do enforce that rate limit, we'll want some initial grace period at least. But it may be worth reconsidering the rate limit pace altogether (maybe there will be plenty of use cases where e.g. an enterprise adopts MCP and wants to launch dozens of servers on one day?).
So I think: