With setting value:

  1. only local data writes, returning a specific error to federation peers that it is in read-only mode and not accepting new comments, posts, likes, subscribes from peer servers.

  2. a federation-only mode where local users are not allowed to change their settings, delete their data, create new posts, create new comments, record votes, edit, etc.

  3. read-only mode site-wide, both local API users and federated peers not allowed to write data.

The second one would also be useful when a site wants to go offline and has a period of time it is ‘archived’ like GitHub archives projects.

I think upgrade instructions for new versions would have recommendation to set this on for a 5 minute period and do a shakedown read-only test of the site before throwing the switch to allow new data inserts into the PostgreSQL database backend.

Standard response codes issued to all peer servers and API clients as to the specific read-only nature of the instance so they can generate an appropriate message in their user interface.

I am making this recommendation based on the version 0.18.1 severe performance problems that Lemmy is having with 1 million comments in the database. To scale, it is essential that new versions can be released into production and rolled-back.

  • RoundSparrowOPM
    1·
    1 year ago

    Nice to have variation of the idea…

    On both the API front-door and federation back-door, a simple stand-alone application (“dummy_lemmy_server”) that can be run that responds to all requests with the same response-code that the server is in read-only (really won’t even provide data) mode. Something to put in place during major server hardware changes/relocation and migration database updates.

  • RoundSparrowOPM
    1·
    1 year ago

    Clearly people would want to extend this feature, some obvious improvements:

    1. allow admins only to do writes so they can test creating posts and comments. Variations of this could include specific members of a local community as an approved-writer list.

    2. Specific peer servers rejected or not with federation incoming - so that specific test peer servers can be allowed in for testing of federation.

    3. Allowing users to delete their accounts if the site is in a read-only shutdown mode to allow individuals to purge data before tossing out the whole database.

     

    But the key things is the feature listed in the above posting, that gets the code points identified and allows people to code more sophisticated variations of the feature into the code. The URGENCY of the performance problems in the Lemmy version 0.18.1 era is why I think this addition to the Rust code is critical and important.