fully seperating UI from backend, remote logon, and preparing for the future

[ghost]

a big part of why alternate masto-web-clients dont exist, i believe, is that they are still linked, and remain in the same github/infoarea. as such, many might get the wrong illusion that alternate UIs CAN'T exist, and i propose seperating the two entirely to resolve this.

alongside this, a powerful feature to have, and one that would encourage swapping to new instances with unique UIs, is making any web-portal able to "remote login" to another instance, to allow users on say, mastodon.social, to try an alternate UI from a different hosted masto instance, to make it easier to swap around, experiment, and find an instance you like, from a user perspective. this also opens up the oppurtunity for a mastodon mobile site to be entirely seperate from the main site, but also be the same instance, if this makes sense.

thank you for listening

[ineffyble]

I definitely think splitting the code would make sense:

Shortest-term: Move the actual code for the web client to its own repo, and add that repo as a git submodule in this one.

Medium-term: Make clients more modular, so that one or more clients can be installed on a Mastodon back-end instance at customized routes

Medium-long term: separate above so that you could have a web client on its own server/database.

[marrus-sh]

See #652 for one approach to this

[wxcafe]

I'm really into this too yeah

[nightpool]

we've seen a couple of alternative web clients for mastodon pop up over the past couple months—Halcyon is probably the biggest one.

What additional changes do you think are worth the complexity cost of trying to figure out how to convey this to users? Matrix implements a similar split (identity server vs homeserver vs web client server) and it's basically a never-ending nightmare of confusion, in my experience.

[wxcafe]

I think it's clearly better in terms of code management, for one thing, and as long as the default UI is pulled-in at install via a git submodule the admins won't notice a thing, except for those who want to use a different UI who will then just pull a different repo in place of the UI. The Matrix situation is different in so far that you have to install both the homeserver and the web client and they're clearly different projects with separate instructions to install them etc, and that is what confuses users imo

[nightpool]

Okay, this is what I read from the issue description:

is making any web-portal able to "remote login" to another instance, to allow users on say, mastodon.social, to try an alternate UI from a different hosted masto instance, to make it easier to swap around

That seems ripe for user confusion.

Anyway, i'm not sure how this would be accomplished technically. Would the submodule expose a ruby gem that has the right templates? How would you hook it into the asset pipeline? Who would handle calling webpacker and how would the development flow work?

Furthermore, I'm all for making things more modular but I don't know if separate repos is the right call here. It just makes it hard to keep things in sync when stuff changes. Pull requests that depend on pull requests from other repos are a PITA to manage, and it makes development much harder for not a lot of gain, especially because Mastodon still only has one full-time developer. Any additional overhead is specifically taken from one person's development time and isn't meaningfully amortized over a large team the way it might work for a larger project.

[wxcafe]

yeah, I agree what you're talking about isn't such a great idea.

I think that what @ineffyble said

Shortest-term: Move the actual code for the web client to its own repo, and add that repo as a git submodule in this one.

Medium-term: Make clients more modular, so that one or more clients can be installed on a Mastodon back-end instance at customized routes

Medium-long term: separate above so that you could have a web client on its own server/database.

is a really good idea. I can understand the added work part of this, tho, especially given we still can't manage to have tagged releases of the documentation that are coordinated with the releases of mastodon...

[nightpool]

in order:

1. "shortest-term" I've already addressed why I don't think this is a good idea. Apart from the technical challenges i just don't think we'll get a meaningful payback for the significant procedural/logistical overhead at the current size of the project. But good in theory, if we handwave non-technical costs.
2. "medium-term" this is probably a good idea, but seems hard. would be interested in reviewing this if someone had a good proposal. I know the fork has already done some work in this direction, that's definitely a good starting point for anyone interested.
3. "medium-long term" The web client is already a trivial rails wrapper around a single-page javascript application, i'm not sure that having it on it's own server makes any sense. would it just serve a single route? If it's decoupled from rails entirely that would make the most sense, but what are we going to do about the static pages? Would those have to take an entire API roundtrip to get rendered? Would they live on the API server? Either way seems bad. In general, seems like a lot of work for little gain.

[wxcafe]

alright, then let's close this issue if we don't want to implement it?

[clworld]

I think that making default web ui portable is good for users who don't like default appearance and want to customize it.
But repos shouldn't be separated. Because default web UI must catch up on time with API enhancement/changes.

[wxcafe]

@nightpool @Gargron what do we do with this? there's no point in keeping it open if we don't want to implement it, and if we do we should probably specify exactly how.

[aral]

I was just about to make the same suggestion so I’m glad @Hoodiek already did in January.

Separating the Mastodon server from the current default web interface can pave the path to Mastodon becoming the server for the next web. Let me try and explain:

Today, the web is client/server and centralised. We have web servers, which are – for the most part – interoperable and they serve web apps/sites, where the actual functionality/content is implemented. If the next web is going to be decentralised/federated or even equinodal/p2p, imagine Mastodon as the first next generation web server. The first implementation of a server for the federated web/fediverse. A fedeweb/fediverse (feb?) server, if you will. Instead of serving a web site/web app, it serves a febsite/febapp. The default app that it ships with it is the current febapp – Mastodon – a microblogging application. (Bear with me if this is not as clear as it should be; it’s my first attempt at articulating it in writing.)

Now imagine that the app the feb server serves can be easily switched. Instead of the default microblogging application, we could, for example, create a personal site feb application. And publishing it is as easy as it is with a web site – you point the feb server to the root of the febsite/app. The main page has the person’s public posts. In another section, you can see the posts of the people that they are following. It has a lot of the features of the standard microblogging interface but it is presented very differently.

So the feb server becomes, in essence, a web server with built-in federation operations. A next generation web server for the next iteration of the web.

Now let’s imagine that a city wants to give every one of their citizens their own place on the Internet. They create a custom feb application that gives everyone their own feb site. Citizens can use the system to follow and interact with each other, neighbourhood communities, and city departments, etc. They can use it – via semantic extensions to the messaging system which could be implemented via a plugin/extensions system – to (e.g.) browse and check out books from their local library.

I see a future where Mastodon could become the engine of the next web. The separation of server/app is a crucial first step in achieving that.

CC @Gargron

PS. I’m not sure that the project needs to be split up into different repositories, etc., to implement this. The simple ability to configure the interface you want to use (e.g., default Mastodon or “the interface in this directory I’ve specified in this config file”) should suffice. (Which, I see, is similar to the approach @marrus-sh took with their instance.) Update: having looked into the code, I see now that it would require quite a bit of refactoring/abstraction.

PPS. Federated apps built on the server would be implemented using the API as @Gargron points out in #652 (comment). However – unless I’m missing something – addressing (URLs), etc., especially re: .well-known, etc., would require the app to be a first-class citizen like the default app (Mastodon).

[wakest]

Would love to see this discussion continue. Seems a lot of progress has been made in many areas since this discussion was taking place and maybe it would be a good time to think about this one again...

[ThisIsMissEm]

I've been thinking about this a little, and you could do it by having a node.js server running the frontend code, then in development a proxy for /web and in production an nginx configuration with an upstream based on the path.

The main thing is the initial server-side fetch & redirect of accounts/statuses/tags/etc. You'd need an API to fetch the settings from initial_state_params. Mainly it'd mean that you'd have to build Mastodon as API-first, which presently it isn't entirely (but it's close).

You'd also need some way to exchange a rails session cookie for a bearer token (I think)