One interface

[erlend-sh]

As a user of Weird I currently have two profile screens:

• https://weird.one/auth/v1/account – profile editor
• https://weird.one/u/erlend – network profile

I'm about to have a third:

• https://erlend.sh (erlend.weird.one) – public web profile

That's too many! We should combine the top two into one interface.

Admin screens — the screens used to manage preferences, people, etc. — have a tendency to look like crap. That’s because the majority of development time is spent on the public-facing interface instead.

To avoid crappy-admin-screen syndrome, don’t build separate screens to deal with admin functions. Instead, build these functions (i.e. edit, add, delete) into the regular application interface.

If you have to maintain two separate interfaces (i.e. one for regular folks and one for admins), both will suffer. In effect, you wind up paying the same tax twice. You’re forced to repeat yourself and that means you increase the odds of getting sloppy. The fewer screens you have to worry about, the better they’ll turn out.

That means https://weird.one/auth/v1/account should be a page the user almost never sees, if ever. It's effectively an admin-side backstop for users' profiles.

What users should deal with on a daily basis would be an edit-in-place network profile. That functionality could also extend to their web profile, provided they're using a theme that supports it.

[zicklag]

Inline editing on https://weird.one/u/erlend should be relatively easy, but there might be a challenge making authentication work properly for inline editing on erlend.sh. Since it's a different domain, we can't immediately tell that you're logged in.

@sebadob do you have any ideas for a good way to share your Rauthy session somehow with an alternative domain? ( This seems like a cross-site cookie problem, which I don't know of a good solution for ).

[erlend-sh]

erlend.sh is just a front for erlend.weird.one after all. So, we don’t actually have to auth on erlend.sh, we can just redirect to erlend.weird.one for editing.

[sebadob]

That would be the easiest approach. Otherwise, you would need to implement stateless token auth most probably, if you want to be able to dynamically authenticate all kinds of domains without static config upfront.

[sebadob]

@sebadob do you have any ideas for a good way to share your Rauthy session somehow with an alternative domain? ( This seems like a cross-site cookie problem, which I don't know of a good solution for ).

Yes, don't use the default Rauthy session here at all. The Rauthy session is only meant for authenticating against Rauthy, if you want to edit your own data or log in to one of the clients. If you want to authenticate against other clients, meaning other domains and so on, you should use a proper client and maybe token authentication. Cookies will not work in that case because of as you said the CORS issues.

[zicklag]

The current plan is to try to:

• Create a special page in the Weird.one app that sets a Content Security Policy that allows it to be embedded as an iFrame in the user's configured domain ( erlend.sh or erlend.weird.one ).
• Have that page respond to MessageEvents that allow updating the user's profile.
• The user's custom site theme is then able to embed that page as an iFrame and use PostMessage() to update the profile info.
• Authentication will be "automatic" because the iFrame will already have the Rauthy session cookie set.
• If there is no Rauthy session, then the iFrame will not have the CSP set on it, and it will error when trying to embed. This will be invisible to the user, but the theme should be able to detect it and not add the editing controls to the page.

[erlend-sh]

Quoting you from Discord:

I think iFrame's take up more memory than normal, but it's not more than having another tab open in your browser I don't think.

That’s still a notable performance hit though. At the very least we should do some benchmarks on this to keep ourselves honest.

Will we still be using the iframe method for people who don’t have a custom domain name?

[zicklag]

The iFrame is only used when you're logged in to weird.one and you go to your own webpage.

It will apply whether you use erlend.weird.one or a custom domain.

But it's not like having a full normal tab open, more like opening a tab that has almost nothing in it.

Hovering over the tabs in Chromium shows how much memory they use, though, so it's super easy to test out. 👍️

[erlend-sh]

The iFrame is only used when you're logged in to weird.one and you go to your own webpage.

ah, so it’s quite confined. Sounds fine then.

[erlend-sh]

Inline editing on should be relatively easy

what do the elementary TODOs for that part look like on the design/theme-end? We can set that up as a help-wanted issue.

[zicklag]

Oh, yeah, that's definitely something somebody could get working on.

There are two major steps:

1. Creating the themed user page.
2. Adding inline editing.

For creating the themed user page, we need:

• a new src/lib/themes/[SomeThemeName].svelte file
• It needs to take a Profile as a $prop and render that profile data nicely in the theme.

For adding inline editing we need to:

• Add interactive features to the [SomeThemeName].svelte that let you edit the profile data on the page.
• Add an invisible iFrame and use postMessage() to send the iFrame an updated Profile when the user saves.

I still need to make the invisible iFrame page, but I can do that real quick before we need it, and the first step is just to get the themed user page.

---

Oh, I just realized we want inline editing on the /u/zicklag page, too. That's easier and probably what you meant for a first pass.

That just needs somebody to add the code for giving you some way to edit it when you're logged in. They can use the profile edit page as a reference for how to actually update the profile.

---

From Discord:

Themes shouldn't really be in svelte files like that. Ideally they should be css variables.

Unless these are not just color themes but rather full templates, in which case it's okay I guess.

Yeah, they'll be full templates.

In the long term I think we will actually have the pages rendered by WASM, and our standard, static themes will probalby use Tera templates.

This will allow "themes" to be wildly customizable and eventually extend to CMS-type applications, and being WASM, these apps will be able to run even in the desktop application or eventually the web client, for offline support.

[erlend-sh]

Sidebar

Doesn't matter if you're looking at a chat, forum, wiki, blog etc: you're always gonna appreciate having that optional sidebar there to orient yourself in web-space. Notion made that sidebar particularly interactive and dynamic.

I think the notion sidebar is the perfect CMS interface. It puts the sitemap in the center of the experience.
Blogs, wikis, forums and groupchats alike all have site maps, and they’re all based on the same terrain. They’re just different maps of the same territory.

I made a mockup by making the menu I want in Notion and pasting that on to my Weird site:

The sidebar should be collapsible into icons to conserve space.

We don't need to do anything remotely fancy to begin with; hardcoding a bunch of stuff is fine. We just need to get into the mindset of 'additional pages need to fit into the sidebar somehow'. And this sidebar can be exclusive to the editing page for now. We'll figure out how to incorporate it into themes shortly thereafter.