Proposal : Separate Mastodon in two : API server and frontend

Mastodon is a monolithic project and one current massive issue is theming.

I propose we separate the project in 2:

  • One for the API/backend/instance administration
  • One for the Frontend

The fontend would be the only thing users see and would contains only UI(webpack, react, css…).
The backend would contain the api.

With this separation, we could have a faster moving frontend, custom frontends…etc.
We could imagine a lot of stuff like, multiple frontends for an instance or multiple backends for one frontend.

I think it is still possible to do that while it is still a young project and it will bring a lot for the future.

5 Likes

I’m not an instance admin, yet, but if your concern is really about theming, then there might be a simpler way for Mastodon to give aspiring instance owners what they need…

I’m familiar as an admin using Flarum, an open source forum alternative/competitor to Discourse. That system also bakes in the presentation, but it provides a “CSS Override” editor in the admin-side. So for people comfortable with combing through the DOM and hunting down selectors, etc, you can override any aspect of layout and presentation you want. It’s just a big textarea box that you put your overriding CSS rules in then save. Done.

This is the most direct approach for people who are not “developer” inclined. For those that are developer inclined, they can create a presentation plugin of whatever scope/nature they want using the API, I think. I’m not a developer, so that part is a little gray for me. But a plugin can then be shared with the community too.

I haven’t seen any talk about Mastodon plugins yet anywhere, even in the fedaverse, so I don’t know if that’s a future possibility or not.

Anyway, even just a CSS override editor would be significant for those who wanted to offer a dark on light theme, for example.

It’s more than CSS for the front end. Look at what Pawoo.net is doing, they added tons of features to the interface and completely customized the frontend. We should be able to do that without fearing conflicts to update the back end.
It would also permit to have multiple frontends for the same instance (a bit like birdsite and Tweetdeck).

1 Like

But that’s not the relationship that Tweetdeck has to Twitter. Tweetdeck is a completely separate website that uses OAuth with the Twitter API. This is already possible with Mastodon and I highly encourage that method for alternative UIs, see for example https://github.com/naumanni/naumanni

Twitter use Oauth tokens for Tweetdeck AND the website (and mobiles apps). The API server should not provide a frontend and we should be able to change it without keeping the default one.

It helps scaling instances, helps for the future (if you want to do a completely new default backend for Mastodon 2.0, you won’t have any issue)… etc.

Naumanni is fine but if I want people on my instance to get that instead of the default frontend, I currently can’t.

Honestly, I can’t see any downsides to separation but I can see a lot of them for keeping them together. And if you want to keep them together, you can still do a package release (like docker has done recently when switching to moby).

Here are the downsides:

  1. When setting up a new instance, you have to piece stuff together
  2. Separate release cycle/management means instead of having one project for Mastodon you now have two, with double the effort required to maintain it

That’s why you do specs and avoid breaking changes to API. Then an out of date front won’t be an issue.

You already have to piece together stuffs already to install an instance.

I’m into this idea and I think it’s worth working toward, though not sure by whom or with what priority.

I think rather than debate whether it’s worth doing based on the upsides and downsides we should rather dig into them and try to get a more detailed idea of how to implement and address those things.

Some stuff I wonder about:

  1. Are all actions necessary for users implemented in the API (and by this I mean under the /api/v1 namespace), and if not what is missing?
  2. What will instance setup look like in this new world where front and back are split? How can we make it easier?
  3. What will release and change management be like? What processes can we implement to make this smoother? @Naouak has already mentioned specs (automated testing), but is there more?
  4. What happens to the admin interface in this context?

Let’s get into the details! Maybe it won’t be so tough or maybe we will come up with other good ideas to implement.

3 Likes

i would like to chime in to say my piece (since this was a thing i requested in the past on the github as well)

it has a lot of advantages, and from what i have heard, one of the reasons GNUSocial is liked is the multiple UI options (albeit all forcibly bundled with a UI if i understand correctly)

a better solution than this is to just straight up have some sort of setup wizard or installer, while i do not know how MUCH that would require, i could definitely imagine a command line tool at the very least that allows you to pick a UI to have bundled with the instance you are hosting.

i do not know how hard it will be to seperate them, nor how much the resources cost to host one of these user-side clients, but i can only see good coming of this seperation.

examples include: multi-account support being much easier to implement by seperating the two, and allowing a user to “try a UI” on an instance that hosts a seperate UI choice, via logging into their existing instance. this would allow someone to try the newer UI on a newer distribution of mastodon while keeping the same account, etc.

the only negative i have heard is the ones that gargron suggested. an argument i would have against this is to not seperate the github itself, and instead seperate into two subfolders, with an option somewhere to enable or disable the UI.

this would keep the same amount of effort to maintain it, while allowing all of the positives as far as i understand it.