Allow bypassing file expiry with a mechanism similar to server boosts

Problem

Files expire eventually after being posted, which means that old conversations may be rendered unreadable. Alt text helps here, assuming that it is retained even after the file is deleted, but this is not ideal. (As a side note, I think it should be easier to add alt text, as the current “edit attachment” modal is rather non-obvious.) Of course, Fluxer cannot pay out-of-pocket for all the file hosting, but this file expiry occurs despite the fact that users may be willing to pay themselves.

Proposed solution

Provide a mechanism similar to Discord server boosts that allows communities to retain their files for longer. In particular:

• All files are retained for at least the length of the global expiry rules.
• The cumulative file size of all uploaded files inside each community is calculated to form a “community size”.
• Servers have a default “maximum community size” of 0 bytes. Any user in the server may pay a recurring fee to increase this size (ideally pay-for-what-you-use billing with a maximum cap).
• If the community size exceeds the maximum community size, uploaded files will be deleted under the usual global expiry rules.
• If the community size is under the maximum community size, uploaded files will be retained indefinitely.

Here are a couple alternatives to this approach, which have their advantages and disadvantages:

1. Add these limits on a per-user, rather than per-community, basis. This would allow users who care about their message longevity to preserve their own conversations in every community, even if they don’t want to support all the messages from all of the communities they participate in. I believe this would not solve the problem as effectively, as what we see in Discord is that most users don’t pay at all, while a few are able to pay, and so this approach would still result in many conversations becoming unreadable.
2. Integrate external file-hosting services into the Fluxer client, to allow people to use them if so desired. This has the disadvantage of the longevity of the conversations relying on two services, not just one.
3. Do nothing, and tell users to self-host for these features. I don’t think this is ideal because it places the financial burden on the community owners, where funds could often be provided by the members instead.