Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Let servers pass configuration information to clients #669
Right now the model for Mastodon with respect to clients is that instances have their own settings, clients have their own settings, and the two don't really communicate with each other much. As a matter of fact, the only way for the Mastodon server to communicate with a client about basic configuration settings is through
I think giving clients access to site metadata in this fashion will both promote federation and the development of third-party apps, as users will be able to find and interact with instances which best suit their preferences and needs. #654 provides one means of communicating (some of) this data, although a public file at, say,
I think we have a fundamental disagreement about the role of server customizations. I do not believe that servers should have any control or influence over the presentation of clients. If you choose TootyFruity, then you choose the UX and color scheme and settings of that app, not your home instance. The server is concerned only with processing data. If a setting affects how data is processed, then it's part of the server settings and no business of client apps. And the server should not provide localizations to clients either. It's hard enough to maintain localizations for the strings in the web app, you don't want to be predicting or limiting what kind of strings app developers will need and then centrally storing it for all apps.
Essentially, when I open my xmpp app and connect to a server, I don't really care about the server or what colors its admin chose for its homepage. I am concerned with talking to my contacts using the app I chose. It's the same here. There is a bit more concern for servers in our case given the importance of moderation policies, but that's stuff you figure out while signing up, not during day-to-day usage (same argument for site title - when while using the app do you feel the need to be reminded of the site title, after login?).
For upload and character limits, it makes more sense to exchange that information. However, I will not officially support variable values for those things. I have observed the effect of varying sets of capabilities-via-extensions in the xmpp ecosystem and the gnu social ecosystem, and I believe one thing that I want to enforce in Mastodon is equality of service. That on a technical level, whichever instance you choose, it will have equal capabilities and parameters.
You obviously spent a lot of time and effort on this idea, and I want to commend you for that. However, I do not agree with this direction for the aforementioned reasons. I hope it made sense. Sorry.
To elaborate a bit more on some other points... The web UI is bundled with the server, yes, but it is just another API app. However, just like Tusky has its own setting storage, the web UI also needed its own setting storage. That's what INITIAL_STATE is. I'm sorry that it has caused confusion. Extracting colors throughout the styles into variables was for the sake of code DRYness and easier customization, but it was only about the existing UI, those color variables were never intended to be a semantic on-its-own thing to be applied to anything else. All of the colors and variable names were picked precisely around the design I've come up with.
My decisions are almost never final and subject to future changes of opinion, new evidence/arguments, etc etc. Just laying out my current reasoning here.