Problem
One of the things that annoys me about Tesseract is that preferences, groups, and favorites are not synced between devices.
The user preference keys available in the Lemmy API don't even begin to scratch the surface of what Tesseract needs to store, so to date, it has only exposed the API-based user settings that affect the behavior of the API (show bot accounts, is bot account, return unread posts only, etc). Every other setting as well as groups/favorites, are stored in the browser's local storage.
For a long time, Tesseract has had a very hacky "solution" where Tesseract can (manually) backup and restore its settings to Lemmy by abusing the theme preference since it's a text column in the database (the settings get serialized to a JSON string and replace the value of the theme setting). That's typically how I sync my settings across devices. However, that's not ideal, breaks Lemmy-UI for your account until you restore it to a valid value, and is susceptible to the whims of the Lemmy devs who tend to break everything I try to do because "that's not how Lemmy-UI does things".
The other option implemented currently is manually downloading / restoring a JSON file and syncing that between devices manually.
Neither of those are great, but they do work.
Solutions?
I'm looking for a solution that would allow only authorized users to POST/GET their own user settings, etc while minimizing overhead for the user. Basically, I want it to be as seamless as possible. I've listed a couple of options on which I'm looking for feedback, possible gotchas, etc. Other suggestions are welcome as well.
Option 1: Utilize the Lemmy JWT
Send the Authorization: Bearer {JWT} header to Tesseract's internal API the same way it's sent to the Lemmy API.
Pros
- Least amount of overhead for end-users
- Seamless integration
- Easy to implement
Cons
- Some admins may not be comfortable plugging their JWT secret into a 3rd party app
- Would only work with the default instance Tesseract is deployed to
- If Tesseract is deployed "unlocked" to allow adding accounts from other instances, only the account on the "main" instance would be able to use settings sync.
- Would not work for a shared/hosted instance that's open to everyone
Option 2: DM-Based Auth Tokens
After a successful login (to any instance), Tesseract generates and sends a DM to the user with an auth token. That token would then be entered into the app settings (or perhaps picked up automatically by an app handler and automatically inserted?).
Pros
- Used by other Fediverse apps (Canvas and Fediseer, for example) and seems to be a valid method of cross-instance authentication
- Would allow multiple accounts on different instances to authenticate
- Relatively seamless if the auth tokens can be automatically intercepted and stored by the app itself (rather than requiring the user to copy it from the DM and insert it into the app settings).
Cons
- More complex; Tesseract doesn't currently have the ability to send ActivityPub messages directly, nor do I have experience on that front. Alternatively, the admin who deploys Tesseract would need to provision a "service" account on the default instance, and DMs would be sent via the Lemmy API.
- ???
Other Options
If you have any other suggestions, I'm all ears. Most of my experience with authz is in an enterprise environment (LDAP/OAuth) or with a single source of truth for user accounts. I try to never half-ass authz implementations, and this is no exception. If I can't make it secure and relatively seamless for the user, then I won't implement it at all.