Self-hosted as an alternative frontend, in "single-instance mode"

[nolanlawson]

This would be useful for admins who just want Pinafore as an alternative UI that only works for their instance. It's possible, but would probably need a separate build system in order to lock it to a single instance and automatically log folks in.

[nolanlawson]

Looks like it's not possible to read the cookie from the main Mastodon site - it's set to HttpOnly and HostOnly, so e.g. pinafore.myinstance.com would not be able to read the cookie from myinstance.com.

[nolanlawson]

I think this could be doable, but Pinafore would have to integrate with the Mastodon/Pleroma server on the backend in order to share the cookie. E.g. it could be embedded into the HTML or accessible via a REST endpoint or something.

[nolanlawson]

Another nice feature would be DEFAULT_LIGHT_THEME=foo or maybe just DEFAULT_THEME or something. An instance like toot.cafe would probably want Majesty for the light theme and Sorcery for the dark theme.

[nolanlawson]

I've been thinking more about this, in context of #891. I think if instance admins wanted to host Pinafore at example.com/pinafore, then that could work. It would solve the cookie issue, because it'd be same-origin. There is also a precedent for this in that Pleroma hosts the Mastodon FE at /web.

I envision something like:

PINAFORE_INSTANCE=example.com PINAFORE_PATH=pinafore yarn build && node server.js

If PINAFORE_PATH is omitted, then the default path is used. This would cover cases like #891 where they want Pinafore to be the primary frontend even for logged-out users.

I believe Sapper supports paths, but I'd need to check.

The logged-out homepage could also contain some boilerplate saying "You're not logged in; please log in at example.com".

[nolanlawson]

I would also ideally like the instance-switcher to be completely disabled in this case, to truly "lock" Pinafore to a given instance.

Also auth() would have to be overridden to use the cookie rather than a token in localStorage.

[uiri]

How would the environment variables translate for a static site export?
Right now this is the easiest way to deploy pinafore as a primary/secondary frontend onto an instance, at least in the case of pleroma.

Outside of that concern, the instance and path configuration model seems good to me.

The ordinary Pinafore login flow is fine. I think it should be preserved other than skipping the instance selection screen. I think that would avoid the auth() issue.

A way to disable the instance-switcher would be nice. Perhaps that should be a separate setting from PINAFORE_INSTANCE and PINAFORE_PATH?

[nolanlawson]

How would the environment variables translate for a static site export?

Pinafore is already a static site (with some mild routing logic). The environment variables would be inlined during build.

A way to disable the instance-switcher would be nice. Perhaps that should be a separate setting from PINAFORE_INSTANCE and PINAFORE_PATH?

Hmmm, I guess I wonder what use case there is to have instance-switching disabled, but not PINAFORE_INSTANCE? Or to have instance-switching enabled, but PINAFORE_INSTANCE also enabled? If it's locked to a specific instance, I think it would be weird to also allow you to log in to other instances. And if it's not locked, then it would make no sense to disable the instance switcher (unless you would only allow them to log into one instance for some reason). Is there a use case I'm not thinking of?

[uiri]

You're right that it makes no sense to have instance switching disabled without locking to a specific instance.

I don't currently use the instance switcher, so I'd be fine if setting PINAFORE_INSTANCE also disabled the instance switcher. On the other hand, the instance switcher doesn't really get in my way, so I don't place too high an importance on that aspect of the feature story.

Now, if someone has a primary account on a Pinafore setup with PINAFORE_INSTANCE set, I could see their wanting to manage some alt accounts from within Pinafore. That said, if the install really is intended to be in a "single-instance" mode, then of course the admin would want to disable the instance switcher even if some users might have a use case for it.

[nolanlawson]

Yeah I think it just complicates things from a UI perspective if there's a default instance that relies on cookies (or similar mechanism), whereas you can also sign into other instances using a different mechanism.

[nolanlawson]

Looks like this may not be possible the way I envisioned it. Even if an admin hosts pinafore at https://example.social/pinafore, it's not enough to get the cookie. The cookie is HTTP-only, and we also need:

• the access token embedded in the HTML
• the CSRF token embedded in the HTML

At least, this is how it seems Mastodon's /web frontend is implemented. So we'd need to inject those two token's into Pinafore's HTML somehow, which would require some changes to the server and possibly some Ruby code.

[ahoeg]

Follow here, would be nice to use pinafore as default FE for a instance with pre-configured instance.

[pwFoo]

Replace default UI and login with username and password would be fine for me, but default instance should be pre-filled.

[saper]

Pinafore as a frontend would also need to accept reply/boost/follow requests done on other instances. Mastodon redirects to the instance interface - the user would need to end up back in Pinafore after logging in.

Also another crazy idea - let people from other instances respond/boost/follow by logging in to the Pinafore frontend using their instance but staying there. I think I need to wrap my head around this.

[tsmethurst]

I've been using Pinafore a lot recently with gotosocial (https://github.com/superseriousbusiness/gotosocial) which doesn't have its own frontend. It would be really really cool to be able to deploy an instance of Pinafore and have it just automatically point towards whatever GoToSocial instance is configured in Pinafore's environment variables. Is this still something you're working on by any chance?

[nolanlawson]

I'm not actively working on it, no. If somebody wants to implement it as described above (e.g. using environment variables during the build process), then I'd be happy to accept a PR. 🙂

[nickspacek]

Over at https://github.com/nickspacek/pinafore/tree/specific-instance I hacked in a couple of environment variables that adjust the display and behavior of login to support single instance mode.

I wonder about having a config file to customize the UI for this use case, to add some flexibility around help text, logo, etc. Thoughts?

[nolanlawson]

@nickspacek For a long time I thought it would be reasonable to set some env vars during build to accomplish this. See #35 (comment)

As long as it's not a huge, invasive PR or has a perf impact for the normal use case, I'd accept a PR to support this. Note you may have to deal with my Sapper fork though: https://github.com/nolanlawson/sapper

[gerwitz]

@nickspacek Handling the incoming links from other instances would seem to also require URLs that use account names (e.g. domain.tld/@user). I think?