I'm feeling more confident about the idea that Soapbox can be a separate service that runs alongside Pleroma.
It can implement features such as Groups and Recurring Donations, while being written in literally any language. It exposes endpoints like `/api/soapbox/groups` to be used by the frontend, and it can talk to Pleroma by making API calls. The frontend can literally pass a user Authorization token through the Soapbox service and then to Pleroma to get a result. If that doesn't work, Soapbox could always I/O the SQL database directly.
The best thing is, soapbox-fe can detect if Soapbox is available, and fall back to only basic Pleroma features if it isn't. Fundamentally it's just a really nice skin for a Pleroma server, but if you take the extra time you can also add the extra features. If it can manage to use only the Mastodon API to do stuff, it could work with a pluggable backend.
One problem I've encountered while writing frontend code (in Elm) to work on Gab, Pleroma, and Mastodon backends is that there is no API to query backend features. You have to try an extended API call, notice whether it returns an error, and then remember that for each server. Or at least that's what I'm doing, having no other ideas.
@billstclair Maybe I could expose an endpoint like GET `/api/soapbox/features`, where a non-200 response signals the frontend that there's no extra features and a 200 response lists the available features
Can't help you off the top of my head. If I were doing it, I'd think hard about it for an hour or two, and then sleep once or twice before deciding.
@billstclair Haha that's what I always do 😃
@alex @billstclair you are basically talking about making soapbox a plugin for pleroma, if I understand correctly
