starred/karakeep

Fork 0

mirror of https://github.com/karakeep-app/karakeep.git synced 2026-04-25 16:06:04 +03:00

[GH-ISSUE #1587] [FR] Rate limit setting for per-domain bookmarking / archiving #993

New issue

Open

opened 2026-03-02 11:54:14 +03:00 by kerem · 2 comments

kerem commented

2026-03-02 11:54:14 +03:00

Owner

Originally created by @ahgraber on GitHub (Jun 10, 2025).
Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/1587

Describe the feature you'd like

As far as I can tell, Karakeep just triggers async bookmark jobs and does not rate limit the outgoing requests. This can lead to an unintentional DDOS of or blacklist from destination websites. Just as #1139 would help with staying within API limits on AI Inference, I'm proposing adding domain-specific rate limits to limit unintentional DDOSing of websites.

Rate-limiting should be applied at the per-domain level; this implies some level of tracking so each domain can track its own use
There should be a practical default limit (n requests / 60 seconds)
Users should be able to configure per-domain overrides

Open question - I'm not sure whether a sliding window, leaky bucket, etc. limiter would be most advisable... although if any are easily available without custom coding, I'd use them :)

Describe the benefits this would bring to existing Karakeep users

Some domains will blocklist your IP if you make too many requests too frequently (e.g., arxiv.org). It is possible to get blacklisted if you either make bookmarks programmatically through the API or rapidly create bookmarks by iterating over a ton of open tabs. This feature would protect users and websites from unintentional abuse.

Can the goal of this request already be achieved via other means?

Only manually - users have to limit how frequently they request karakeep archive a site on a given domain.

Have you searched for an existing open/closed issue?

I have searched for existing issues and none cover my fundamental request

Additional context

No response

Originally created by @ahgraber on GitHub (Jun 10, 2025). Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/1587 ### Describe the feature you'd like As far as I can tell, Karakeep just triggers async bookmark jobs and does not rate limit the outgoing requests. This can lead to an unintentional DDOS of or blacklist from destination websites. Just as #1139 would help with staying within API limits on AI Inference, I'm proposing adding domain-specific rate limits to limit unintentional DDOSing of websites. 1. Rate-limiting should be applied at the per-domain level; this implies some level of tracking so each domain can track its own use 2. There should be a practical default limit (n requests / 60 seconds) 3. Users should be able to configure per-domain overrides Open question - I'm not sure whether a sliding window, leaky bucket, etc. limiter would be most advisable... although if any are easily available without custom coding, I'd use them :) ### Describe the benefits this would bring to existing Karakeep users Some domains will blocklist your IP if you make too many requests too frequently (e.g., arxiv.org). It is possible to get blacklisted if you either make bookmarks programmatically through the API or rapidly create bookmarks by iterating over a ton of open tabs. This feature would protect users and websites from unintentional abuse. ### Can the goal of this request already be achieved via other means? Only manually - users have to limit how frequently they request karakeep archive a site on a given domain. ### Have you searched for an existing open/closed issue? - [x] I have searched for existing issues and none cover my fundamental request ### Additional context _No response_

kerem added the

feature request

status/approved

pri/low

labels

2026-03-02 11:54:14 +03:00

kerem commented

2026-03-02 11:54:14 +03:00

Author

Owner

@MohamedBassem commented on GitHub (Jun 15, 2025):

I like the idea, but it's going to be a ton of work to implement because the queuing library we're using doesn't currently support ratelimits. So I'd like to see more demand for this feature first before implementing it.

@MohamedBassem commented on GitHub (Jun 15, 2025): I like the idea, but it's going to be a ton of work to implement because the queuing library we're using doesn't currently support ratelimits. So I'd like to see more demand for this feature first before implementing it.

kerem commented

2026-03-02 11:54:14 +03:00

Author

Owner

@ahgraber commented on GitHub (Jun 15, 2025):

Fair enough, thanks for considering!

@ahgraber commented on GitHub (Jun 15, 2025): Fair enough, thanks for considering!

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/karakeep#993

No description provided.

Rows
Columns