Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Quotas for file and event storage #3339

Open
ara4n opened this issue Jun 4, 2018 · 3 comments
Open

Quotas for file and event storage #3339

ara4n opened this issue Jun 4, 2018 · 3 comments
Labels
A-Media-Repository Uploading, downloading images and video, thumbnailing A-Moderation Tools for moderating HSes: event redaction, media removal, purge admin API, reports from users, ... O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Blocks non-critical functionality, workarounds exist. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements.

Comments

@ara4n
Copy link
Member

ara4n commented Jun 4, 2018

Something that keeps coming up is the need to track which users are responsible for chewing all the storage on your server - whether that's by storing lots of stuff in the media repo, or by joining massive rooms and chewing all your DB (or submitting loads of events).

We probably need to distinguish storage which the user created directly (i.e. by sending a file or event) or indirectly (by accessing a file or a room).

We probably care more about directly attributable storage costs, as indirect ones are going to be shared across a bunch of users - plus tracking the indirect ones could result in a metadata leak for e2e rooms (i.e. which users have access to the files in a given room)

@neilisfragile neilisfragile added z-feature (Deprecated Label) z-p2 (Deprecated Label) labels Jun 8, 2018
@stonie08
Copy link

Having some kind of per-user storage-quota would be a really nice addition. I also see this as a possible issue for larger hosted instances as having unrestricted media storage might result in the service being misused as unlimited cloud storage.
Even in self-hosted-home-user-home-server settings it'd allow people to more easily hand-out accounts on their servers, without being worried about users taking up too much/all of their storage. It's much easier to do this if it's possible to allocate a maximum storage they can use.

Without deeper knowledge of the protocol/server or client implementations I'd personally like to see a configurable per-user/per-group storage quota, combined with some kind of client-side export of messages and media. Ideally it is easily possible for the user to backup all the old messages (e.g. all messages before dd/mm/yyyy) in some standardized format to make room for new messages/media.
Maybe also a configuration option to decide on what happens if the quota is exceeded: Either receiving messages stops working or the oldest elements are removed. The seconds option might make for a smoother experience for users not interested in really old messages.

@abeluck
Copy link

abeluck commented Apr 16, 2020

We're also worried about our synapse instances being used as illicit file sharing platforms.

Our instances have a quite high max file upload (in the GBs). We're building on the synapse+matrix ecosystem to provide non-standard user experiences (not just whatsapp or slack like) and file sharing is an important part of that, but we're worried we can effectively be DoSed by bad actors looking for a file sharing avenue.

This isn't a hypothetical worry either, we ran open XMPP servers for years and this is very very common in that space.

@clokep
Copy link
Member

clokep commented Apr 16, 2020

We're also worried about our synapse instances being used as illicit file sharing platforms.

There are some tools in the admin APIs to quarantine media. Regardless it sounds like your issue isn't really about quotas but about managing content for other reasons. If so, could you please open a new issue with more details!

@MadLittleMods MadLittleMods added A-Moderation Tools for moderating HSes: event redaction, media removal, purge admin API, reports from users, ... A-Media-Repository Uploading, downloading images and video, thumbnailing labels Dec 8, 2022
@DMRobertson DMRobertson added S-Minor Blocks non-critical functionality, workarounds exist. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements. O-Occasional Affects or can be seen by some users regularly or most users rarely and removed z-p2 (Deprecated Label) z-feature (Deprecated Label) labels Dec 13, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Media-Repository Uploading, downloading images and video, thumbnailing A-Moderation Tools for moderating HSes: event redaction, media removal, purge admin API, reports from users, ... O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Blocks non-critical functionality, workarounds exist. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements.
Projects
None yet
Development

No branches or pull requests

7 participants