Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let servers pass configuration information to clients #669

Open
marrus-sh opened this Issue Mar 14, 2017 · 4 comments

Comments

Projects
None yet
5 participants
@marrus-sh
Copy link
Contributor

marrus-sh commented Mar 14, 2017

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 window.INITIAL_STATE—which, obviously, requires the client to be hosted from the same server as the instance. Here's my argument for why this approach falls short:

  • Site title : This one's pretty straightforward. When I log into mastodon.social I want my client to read "Mastodon". When I log into mycoolinstance.space I might expect "Cool Instance Deluxe™®" instead. Clients should have access to a Mastodon instance's title.

  • Maximum characters : Suppose I create a Mastodon instance at 140chars.net and configure that instance such that the character limit is 140 instead of 500. Now I connect to that instance in Tusky, which assumes (and is forced to) that the character limit is the Mastodon default. You see the problem.

  • Media filesize limit : Same issue as maximum characters. The client has no way of knowing what files the server will accept.

  • Localization data : Right now clients are required to maintain their own localization data. This is fine, but instances should have the option of passing localization data to client, and there should be a standardized set of localization parameters for clients to look out for. Otherwise, I might configure im-a-pirate.social to say "Arrr, Matey!" instead of "What is on your mind?" and "Aye!" instead of "Toot", only to find that these settings are ignored by any client which tries to access my site.

  • Links : The default Mastodon web client displays links to /about/more and /terms, but clients should not assume that instances will have these pages or that they will be at these locations. It would be nice if Mastodon provided clients with a listing of links to resources on the site. Doubly-nice if these links supported localization as well. (The Settings page is a particularly notable instance of this.)

  • Styling : Right now Mastodon allows instances to configure their colour schemes by editing variables.scss, but it would be nice if clients had access to a minimal set of colours as well. (Of course, they could choose not to respect these.) These should be semantically labeled; for example, primary-color or site-background. It would be the responsibility of clients to ensure that proper contrast was maintained when deploying these colours.

    (Other potentially useful styling information: the site background image, site preferred fonts)

  • Client-specific information: Clients may want to provide additional configuration options to servers, and servers should have a means of interacting with these. For example, the client.labcoat.display property might be used to tell the Labcoat client which display modes to use when rendering a given instance. There should be a standard designated area and procedure for specifying client-specific options, which should be namespaced in some manner.

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, /config.json (or similar) would serve just as well.

@Gargron

This comment has been minimized.

Copy link
Member

Gargron commented Mar 15, 2017

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.

@Gargron

This comment has been minimized.

Copy link
Member

Gargron commented Mar 15, 2017

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.

@adbelle

This comment has been minimized.

Copy link
Contributor

adbelle commented Mar 15, 2017

I see no reason that site title, maximum characters, and filesize limit shouldn't be completely exposed for the purposes of application usage.

@ashfurrow ashfurrow added the api label Apr 23, 2017

abcang added a commit to pixiv/mastodon that referenced this issue Sep 15, 2017

Merge pull request tootsuite#669 from pixiv/fix/account_pinned_status
Fix Api::V1::Accounts::PinnedStatusesController#index

abcang added a commit to pixiv/mastodon that referenced this issue Dec 18, 2017

@giromide

This comment has been minimized.

Copy link

giromide commented Sep 3, 2018

@Gargron I would like to back support of the "site title" request above, but I prefer it just be standard that the title be "Mastodon | BASE_URL" rather than something to be configured.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.