Forking off tootsuite or glitch-soc?


As the maintainer of the glitch-soc fork, I’m wondering whether it would make more sense to fork from upstream (tootsuite) or glitch-soc.

Indeed, glitch-soc already implements a bunch of changes that I think would immediately benefit the fork (bookmarks, configurable list replies, hiding follower counts, …)

On the other hand, there are things that are not necessary for the fork (e.g., the extended theme system and the multiple front-ends), or could be done better (e.g., local-storage VS backend-stored setting for auto-unfolded content warnings).


I think it should be as easy as possible for Mastodon instances to migrate to the fork, at least at the beginning. I don’t know if there are big incompatibilities in gitch-soc that would prevent people to just change the repo url and to run normal update commands, but if that’s the case being based on tootsuite seems a better option to me.

If tootsuite is forked, wouldn’t it be possible to port the glitch-soc patches that are interesting (I think you did a PR on tootsuite for bookmarks (or maybe not?) that could be merged in the fork). And if glitch-soc is forked, the parts that are useless to the fork could probably be removed, and those which need to be improved, improved.


Migrating to glitch-soc is as easy as changing the repo URL and running the normal update commands. One important thing is that the resource requirements to build the front-end are higher, though (see “Multiple front-ends”).

Porting changes from glitch-soc is possible, of course, but that would require a bit of work, as the front-ends have diverged quite a bit.

Now, let me expand a bit on glitch-soc changes I wrote earlier as not being necessary for the fork or could be done in a better way.

Multiple front-ends

One of the early choices made in glitch-soc was to allow multiple, possibly very different front-ends (called “flavours”). This feature is not aimed at end-users providing their own front-ends, but aimed at admins instead, and as far as I know, it is not actually used in the wild except for the two flavours glitch-soc comes with.

glitch-soc comes with the “vanilla” flavour, which is upstream’s client front-end, modified as little as possible, and the “glitch” flavour, which has diverged quite a bit and includes other functionality.

Some glitch-soc users do prefer the vanilla flavour over the glitch-soc one, but I did not really manage to get a actual feedback to close the gap…

The costs of this flavour system are that it adds a bunch of fairly complex code (that, thankfully, does not need to change often), and that building the front-ends is much more resource-intensive.

Local storage VS backend-stored setting

In upstream’s front-end, most settings are stored on the server, which has the benefit of providing a consistent experience over multiple devices, but prevents users to have different configs on different devices.

Most of glitch-soc-specific settings are stored in local storage, which means the config is dependent on the device the front-end is running.

There is an added issue with glitch-soc-specific settings being stored in local storage: indeed, one specific setting (CW auto-unfold) has been implemented upstream after it was implemented (using local-storage) in glitch-soc, meaning there is no easy migration path for this setting to be merged with upstream’s one.

If forking glitch-soc, there is an opportunity to rethink this.


To be honest I like a lot the Glitch-soc frontend layout and options, but I feel that if we use that as a base for the fork, we may want to a few things:

  • ditch the multiple front-ends code to make the builds less resource-intensive and make it easier to contribute;
  • integrate the glitch-soc specific options into the Mastodon Preferences page so it feels more native and less confusing;
  • sometimes two features has been implemented differently; use upstream code if the feature isn’t inherently better.

After that we can publish our code as «[fork name] 2.7.0» and then start to improve/introduce new features.