Proposal

Add custom database columns to the local_site and local_user tables and corresponding config keys in the editSite and saveUserSettings interfaces. Data type would be text and the column name could be user_custom or something like that.

Rationale

Many 3rd party Lemmy UIs offer more config options than are covered by the discrete config keys currently exposed via saveUserSettings and in the MyUserInfo interface. A custom field where a JSON blob could be stored would allow 3rd party Lemmy UI clients to save site-level and user-level config options to the API similar to how Lemmy-UI has its settings saved.

Currently, 3PAs largely (exclusively?) utilize local storage which limits any persistence to individual devices/browsers. Adding those text columns and exposing them via the getSite, editSite and saveUserSettings interfaces would allow 3rd party apps the ability to persist settings across devices by serializing them to JSON and storing/serving from the API.

Use Cases

  • Application settings and preferences
  • Keyword filters
  • Favorite community lists
  • Community group lists
  • Structured site-level data such as rules, public community groups, report and moderation templates, etc.

Possible Cons

  • Would slightly increase amount of data returned in the getSite API call due to the extra data in the local_site and my_user keys.
  • 3PA developers would have to share this field.
    • Not really a concern for the Lemmy devs, but there would ultimately need to be some cooperation between 3PA devs to avoid contention (e.g. a container with namespaces, etc).

Workarounds Considered

Adding a backend server to each 3rd party UI is possible but may be overkill for the relatively common and simple task of persisting settings. A custom field exposed by the Lemmy API would alleviate that. For use-cases more advanced than simple settings storage, the 3PA dev may opt to build their own backend anyway.

In Tesseract, the current workaround is done by allowing export and import of user settings to a JSON file which can be loaded into a new device/browser. While that’s better than nothing, it’s far from ideal.

Thoughts?

Update: To test the viability of this RFC, I’ve horribly abused the theme field to store about 60 KB of JSON user settings data. Aside from breaking the CSS in Lemmy-UI (as expected), everything works great. The additional payload data in the getSite response doesn’t seem to be causing much of an impact. I may leave this in the next release under “advanced settings” with appropriate warnings as well as adding a “restore” button to restore it to a valid theme value. Ultimately, though, a dedicated field for 3PAs to use would be ideal.