Juicy Clients
The “juicy client” is not just rich in flavor and thick in texture; it is fluid. It adapts to the presentation needs of the data it receives.
Its fluidity is enabled by a helpful constraint: The loose confines of ActivityPub (plus extensions) provides a cohesive specification to scope & guide different UI implementations co-existing as part of the greater whole of an omni-interface.
If I'm peeking into an ActivityPub instance, show me its preferred UI form. ..on mastodon.social, show me the Mastodon UI. ..on calckey.social, show me the Calckey UI. ..on bookwyrm.social, show me the Bookwyrm UI. ..on mitra.social, show me the Mitra UI. ..on pixelfed.social, show me the Pixelfed UI. (..on bluesky.social, show me the Bluesky UI.)
This is a continuation of 'Sense-making in federated discourse' and 'Feed Overload'
https://writing.exchange/@erlend/110286022480202952
Elk is currently furthest along on the track to becoming a juicy client. It's being developed by developers from the core team of Vue/Nuxt, which is a reasonably well-resourced crew. Additional capacity was unlocked recently since Nuxt was accepted into GitHub Accelerator! 🎉
It also comes with a desktop & mobile(soon) app distribution, based on Tauri. Being cross-platform makes it a strong unifier since both desktop and mobile UI enthusiasts can participate in the product shaping without splitting up into platform-native specializations.
Mitra and Pixelfed are already using Vue for their frontend. In my humble opinion, they'd be better off doing like Takahe and deferring to Elk as a default/recommended frontend. There's bound to be several other standalone Vue frontends for AP/Mastodon out there that likewise ought to consider this line of reasoning.
In any case, the custom UI features of these ActivityPub distributions can be re-implemented by someone in Elk as part of a juicy client strategy. I hope this product design & development strategy will appeal to enough Elk/Vue/JS/UI devs out there that we can turn this into an increasingly concerted effort.
Another promising alternative in this space is Gobo. It has been explicitly designed as a juicy client, or as they put it, a loyal client.
At the Initiative for Digital Public Infrastructure, we believe that a truly sustainable and resilient digital public sphere is possible and is actively being created. We envision a public sphere supported by these three legs:
- Consists of many different platforms with a wide variety of scales and purposes;
- Users can navigate with a loyal client that aggregates, cross-posts, and curates;
- Is all supported by cross-cutting services rooted in interoperable data.
It's made in Svelte, Cloudfront on the frontend. Python, Postgres, and Docker on the backend. A prototype is tentatively going public (and open source?) some time this May.
We believe Gobo needs to allow users to:
- Read and post to multiple social networks from one open source client.
- Pick and choose between algorithms for filtering and sorting the posts from all these networks.
- Design (and potentially share) different algorithms for filtering and sorting.
- Use third-party services to assist in filtering and sorting.
- Audit the performance of these different algorithms as well as the third party services.
If this work inspires you, I wholeheartedly urge you to reach out to the projects above and lend them a hand! 🙌
You can find me as erlend#1111 on the Elk discord.