Mastodon normalizer: Difference between revisions

From ludd
Adamw (talk | contribs)
→‎Resources: Link to Bluesky blog post
Adamw (talk | contribs)
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Project|status=beta|url=https://normalizer.webflux.us/}}My crash course in "undirected search" began with two brief but eventful years moonlighting for Jibril Jackson's startup HYVE, which made me aware of Dunbar's number, the limits of how much attention we can pay our friends, and how social media tilts the scales so that the loudest voice is heard most.
{{Project|status=demo|url=https://normalizer.webflux.us/|source=https://gitlab.com/adamwight/mastodon-normalizer}}'''Problem statement:''' Social media amplifies the loudest voices more than is necessary.  In real life, we know that a person who speaks often and loudly might be full of good insights, or they might just suffer from an excess of hot air.  Either way, we aren't obliged to give this person all of our attention just because they're loud.


When @futurebird@sauropods.win mentioned the fun idea of a [https://sauropods.win/@futurebird/109971101661561998 customizable timeline] as something that comes up regularly in discussions about improving Mastodon, I recognized this as the same perennial problem and decided to give a whack at the proposed solution, to see what it looks like.  I'm happy with the results so far!  You can try the demo using your own Mastodon account.
There is rarely any way to deal with this, no alternative between full volume and blocked, to allow us to better hear the quieter voices.


If you like the idea, please feel free to borrow [https://gitlab.com/adamwight/mastodon-normalizer the code], help with the project, or reimplement it on your preferred platform.
== Experimenting with normalization ==
[[File:Preferences for normalizer v0.2.7.png|thumb|Preferences pane]]When @futurebird@sauropods.win mentioned the fun idea of a [https://sauropods.win/@futurebird/109971101661561998 customizable timeline] allowing us to check in on our friends' latest posts, I was excited to see how it might be applied.  I'm happy with the results so far!  You can login to the [https://normalizer.webflux.us/ demo service] using your own Mastodon account and instance, or try out the [https://normalizer.webflux.us/help guided tour] as a guest.


== Normalization ==
Preferences currently look this this.<div style="clear: both;"></div>
[[File:API_Console_-_VU_Meter_Bridge,_API560_10_Band_EQ,_API550A_3_Band_EQ_(2017-01-05_19.45.22_piqsels.com_en).jpg|thumb|It's all about the volume]]
[[File:Equal height.png|right|thumb|Equal height for each author]]
If one topic or author is much more prolific than another, then the louder channel will tend to draw more attention.  This problem is often framed as "signal to noise", but the phrase doesn't quite describe the same problem and would be more accurately applied to spam-filtering.  Here we're looking at something more nuanced which we'll call "loudness normalization" in which the voices may be equally important, we simply want to give each voice a fair chance to be heard.


In audio engineering one loud instrument can often drown out another softer sound.  The standard approach to fix this is to normalize the audio, bringing the average loudness of all instruments to the same level.
The default view is called the "orthogonal" view, which gives each author '''equal vertical space''' in your timeline regardless of how many posts they write or how big their attachments.


As social media readers, we're instinctively aware that each voice has its own style, conciseness and frequency of posting.  We might naturally gravitate towards the bright colors, loud text, frequent posters, and to push back we protect our attention through various strategies: muting the spammiest accounts, automatic filtering, skimming aggressively, and so on(It's also interesting that these strategies have audio analogies: multitrack mixing, noise reduction and fast-forwarding, respectively.)
A more extreme version of this view is the "Check in" mode which shows only one post from each accountThis can be seen as a normalization of both vertical and horizontal space.


The basic normalization suggested by @futurebird is implemented in my demo as the "Check in" mode, and it works by showing exactly one recent post from each account you've subscribed to.
<div style="clear: both;"></div>


== Dimensionality ==
[[File:Normalizer with focused row.png|thumb|Focused and expanded row]]
[[File:Alcudia,_detalle_de_saetera,_sección_norte,_02.jpg|thumb|225x225px|Feeling lucky?]]
Clicking on a row of posts will expand and focusTo expand all posts by default, choose the "natural" row height preference.
Playing with the "check in" mode I found that it successfully levels out authors so that everyone gets an equal chance to be seen, however the limitation of one recent post 's a painfully narrow viewport, like watching an orchestra through an arrowslitHow can we cross the broad perspective of multiple, leveled channels with the known strengths of a chronological timeline and its potential to tell a story?


One obvious visualization is to put the two dimensions at right angles to one another, so a two-dimensional view.  In my demo this is called "Orthogonal" mode and you can scroll between authors vertically, then read individual timelines by scrolling horizontally.  Let me know what you think, dear reader!
<div style="clear: both;"></div>


== Customization ==
== Time dimension ==
Like in a fairy tale, these three experiments—I'm including classic "timeline" with only the time dimension and no normalization—have also satisfied the programming "rule of three" and <ref>Current project status: working on the thing right here in the sentence.</ref>I'm ready to collapse the different feed styles down into something that can be generalized.  As a first step, I'll turn the parameters into visual knobs that can be seen and adjusted by the user.
[[File:Time axis.png|right|thumb|Time axis]]
If we reintroduce the timeline but with its axis tipped by 90 degrees, we can list all of each author's posts as an isolated strip running from left to right.
<div style="clear: both;"></div>


In the long term, the algorithm should be fully flexible and visually-programmable, and there would be a library for sharing your algorithms with others.  
== Development ==
So far, this software is the labor of one unpaid person acting on friendly suggestions.  Contributions, suggestions or other resources are welcome!
 
Its architecture is a server-side, Elixir [https://hexdocs.pm/phoenix_live_view/welcome.html Phoenix Live View] application which updates the user's browser by sending HTML over a websocket.  It's authenticated temporarily to act as the user.  Posts and tokens are kept in server memory and kept as state for the session, then forgotten on close.
 
In the long term, user algorithms will ideally be visually- and script-programmable, and shareable.


== Resources ==
== Resources ==
=== Get involved ===
* Try out the [https://normalizer.webflux.us demo site].
* Read and install the [https://gitlab.com/adamwight/mastodon-normalizer source code].
* Write to @a@social.wikimedia.de


=== Similar projects ===
=== Similar projects ===
Line 32: Line 44:
* Bluesky's [https://blueskyweb.org/blog/7-27-2023-custom-feeds "marketplace of algorithms"].
* Bluesky's [https://blueskyweb.org/blog/7-27-2023-custom-feeds "marketplace of algorithms"].


=== Reporting on the topic ===
=== Reporting related to the topic ===


* Young, Nora (2023-09-08).  [https://www.cbc.ca/radio/spark/eurpoe-digital-services-act-julia-angwin-1.6960911 "As EU law hopes to rein in Big Tech's algorithms, this reporter wants a 'third path'"]. [https://www.cbc.ca/radio/spark Spark].  Retrieved 2023-09-11.
* Young, Nora (2023-09-08).  [https://www.cbc.ca/radio/spark/eurpoe-digital-services-act-julia-angwin-1.6960911 "As EU law hopes to rein in Big Tech's algorithms, this reporter wants a 'third path'"]. [https://www.cbc.ca/radio/spark Spark].  Retrieved 2023-09-11.
== Notes ==
<references />

Latest revision as of 21:02, 19 July 2024

Problem statement: Social media amplifies the loudest voices more than is necessary. In real life, we know that a person who speaks often and loudly might be full of good insights, or they might just suffer from an excess of hot air. Either way, we aren't obliged to give this person all of our attention just because they're loud.

There is rarely any way to deal with this, no alternative between full volume and blocked, to allow us to better hear the quieter voices.

Experimenting with normalization[edit | edit source]

Preferences pane

When @futurebird@sauropods.win mentioned the fun idea of a customizable timeline allowing us to check in on our friends' latest posts, I was excited to see how it might be applied. I'm happy with the results so far! You can login to the demo service using your own Mastodon account and instance, or try out the guided tour as a guest. Preferences currently look this this.

Equal height for each author

The default view is called the "orthogonal" view, which gives each author equal vertical space in your timeline regardless of how many posts they write or how big their attachments.

A more extreme version of this view is the "Check in" mode which shows only one post from each account. This can be seen as a normalization of both vertical and horizontal space.

Focused and expanded row

Clicking on a row of posts will expand and focus. To expand all posts by default, choose the "natural" row height preference.

Time dimension[edit | edit source]

Time axis

If we reintroduce the timeline but with its axis tipped by 90 degrees, we can list all of each author's posts as an isolated strip running from left to right.

Development[edit | edit source]

So far, this software is the labor of one unpaid person acting on friendly suggestions. Contributions, suggestions or other resources are welcome!

Its architecture is a server-side, Elixir Phoenix Live View application which updates the user's browser by sending HTML over a websocket. It's authenticated temporarily to act as the user. Posts and tokens are kept in server memory and kept as state for the session, then forgotten on close.

In the long term, user algorithms will ideally be visually- and script-programmable, and shareable.

Resources[edit | edit source]

Get involved[edit | edit source]

Similar projects[edit | edit source]

Reporting related to the topic[edit | edit source]