Purple Myst @agateblue@mastodon.technology

Hi there!

I'm a french developper, on a daily basis, I work on @funkwhale, a federated audio platform based on #ActivityPub, #Python and #Django.

I'm in the process of splitting my unique account (@eliotberriot) in two distinct ones. One for my personal life, @agate, and this one, for everything that's tech-related.

I thought Mastodon.Technology would be a good pick for that, so thank you for welcoming me!

I'm looking forward to talk with you :)

#introductions

These days, I've been working on a lightweight mood tracking and diary app.

I've used some of them, like Daylio in the past, however I wasn't entirely satisfied, mainly because I wanted something that worked accross multiple devices (incl. desktop), and could handle larger amounts of texts.

Tempo is my second attempt at building something for myself, with a significantly different approach as last time.

In other scenarios, when the front-end is on a completely different domain as the API, then login will use OAuth instead.

The webapp is therefore considered as a third-party app (which it is), and everyone's happy (esp. me, because I don't need to support JWT anywore \o/)

So instead of enforcing an insecure or hacky auth to enable this, in the end I decided to support two auth scheme in parallel:

In typical production deployments, the webapp is served on the same domain as the API. This means we can use cookie/session based auth, transparently and securely (assuming we enforce the proper Cross-Site Request Forgery protections)

This was done through https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/1126

This is invaluable for contributors, because you can `yarn serve` then point the front-end to an existing server (open.audio, demo.funkwhale.audio, your personal pod), and reproduce UI bugs or develop new screens against real, live data.

But, in 99% of Funkwhale deployments, this isn't used.

Then, I remembered why I used JWT over basic cookie/session based auth initially: I wanted a way to login to any instance with any front-end. Phrased differently, I didn't want to have coupling between the front-end and the backend.

A really important use case unlocked by this is the ability to work on the front-end locally without installing a backend , populate data, etc.

The main reason is that the OAuth dance works like this:

1. You are using app X and want to connect it to service Y
2. App X redirects you to service Y
3. Service Y ask you if you want to authorize app X
4. Service Y redirects you to app X

But how can we authorize at step 3 if oauth is needed for authentication? Sounds quite obvious when written like this, but I bumped into this after a whole day of work x)

I've done quite some work done on authentication lately.

Funkwhale has been using Json Web Tokens for two or three years. This worked great, however, now that we also support OAuth, it felt redundant, and JWT doesn't allow granularity in terms of permissions.

Initally, I thought the logical move would be to ditch JWT entirely, and use OAuth everywhere (including our built-in webapp).

However after having a closer look, I realized it wouldn't be possible.

I've also moved all CSS from .vue files to our style directory, meaning it will be easier to maintain and to factorize in the future.

All this work was pretty exhausting and involved, but in the end I think it's worth it.

The attached video showcase how tweaking theme variables, directly in the browser, affects the UI (sorry for my bad color taste ;)

As you can see, it's way less involved that the previous approach wic required overriding existing rules in each theme.

Key points:

- 45% reduction of our CSS (from 715 KiB to 405KiB). It's still huge, but it's less huge ;)
- Use CSS vars for theming, this was actually inspired by the work I've done on Tempo last month
- Writing a new theme now requires 30 lines instead of 300 (and gives a better, more consistent result)
- The new system unlock some interesting features, e.g having a theme editor in the app, or per-user or per-pod themes without rebuilding the front-end

So, a month ago, someone contributed a merge request to improve our theming system (https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/1094). I lacked the time to review it properly at the time, but I got back at it this week.

After playing with it, I decided to go a step further, and do a major cleanup of our CSS to reduce its size and make theming way easier.

Took me a full week, but today I can share the result!

https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/1125

I'm experimenting with basic data visualization on Tempo. Ideally, I'd like to make it easy to answer some questions such as:

- How many entries do I write per day/week/month?
- how well do I sleep?
- how stable is my mood?
- Is a given tag usually positive or negative?

CW: the video includes some neg entries regarding my mood

It's far from complete, but I'm already quite satisfied with the result.

Can't wait to see how Vue 3 performance enhancements affect Funkwhale!