TLDR: Customized a browser as dedicated Fediverse front-end, use existing web clients for per-service UI, manage account/password with password manager, and merge the notifications from multiple services into one inbox? Is this possible/good?
Hello all,
It’s me, an eager fediverse adopter who wants all their friends to get onboard and craves an all-in-one solution for federated content, but who knows no code and barely enough IT to get by reading git documentation.
I’ll start by saying that one thing is clear, diversity and experimentation is the essence and benefit of the Fediverse concept. To me, new and exciting ways to use ActivityPub (and other distributed social/comms protocols) get me thrilled and ready for more. The challenge I, and I’m sure many adopters face is the challenge as old as the internet: platform fatigue.
While I want to use all the amazing services the Fediverse offers, managing clients and accounts for each one, and specifically the notification streams coming from all of them, often feels burdensome, decreasing my engagement.
So here’s a simple thought experiment I’ve been playing with: what is the simplest, lowest friction method of accessing and managing multiple notification/content streams without needing to consolidate or centralize client/server development across multiple projects? And further more, how can this set of notifications (and subsequent content interaction) be consolidated yet separated from the other non-fediverse notifications/content across multiple devices?
My naive user mind has pointed me in the direction of dedicated browser instances with customized UI. When I have a webapp I need rapid access to and notifications from I install a dedicated browser instance (or “app” in Edge speak, I know, booo). This works well for me, and in some cases uses less memory than a dedicated application for some reason (looking at you Discord).
So what if a customized browser could be built off of an existing project (probably going to have to be Firefox based, though all eyes on Ladybird), that has a built in password/account manager, and pulls the notification streams from all of the services those accounts interact with into a merged list. Then add filter options for that list including service, account, media type, etc.
All interactions with notifications pulls up a tab of a webclient the user designates for that service, ideally reusing the same single tab unless the user specifically selects open new tab. Each designated service appears on the toolbar as a bookmark, showing notification number beside it. Total notifications and the shortcut to the unified notifications service/Inbox lives on the left or right side of the toolbar and is emphasized.
And that’s it, everything Fediverse under one hood, separate from the main browser, not scattered across multiple installed applications, and with each client self-updating.
The challenge? Of course it is merging all the notification streams. Based on what I know of ActivityPub this seems achievable, but the details are beyond me. I am reminded of RSS emerging as the means of addressing a very similar challenge with the emergence of blogs, perhaps an ActivityPub to RSS gateway/bridge could even be the solution to merge the notification streams and then off the shelf RSS reader extensions could serve for the master notification inbox.
I am also reminded of my beloved Trillian which merged IM services under a single application hood, but faced an ever stacking development load as each service changed. Glad to see they still exist, but it seems like the browser route could avoid that centralized dev burden.
Thoughts from more experienced minds than I? Does this make any sense?
Who said that? The browser still needs to be a browser in order to open links in posts. Similar to how Interstellar the client I’m using right now brings up a browser window when I click a link.
no it doesn’t. most clients open third-party links in the actual browser. interstellar has a setting for that.
i’m saying that the functionality you’re describing is already perfectly encapsulated by a normal browser, and what you want is that, but limited to a handful of sites.
This is an issue of reading comprehension, I’m talking about a browser with a UI customized to fit Fediverse needs first and websites second, plus a service embedded in the browser to pull unification from each service into a single stream.
Preserving website functionality is still essential to the browser, because both the fediverse clients and the links posted on them should in my opinion be opened in that same browser by default (or set to open a different browser if the user prefers).
Im just talking about UI, no one said anything about blocking websites. Just because the address bar doesnt live onscreen by default doesn’t mean it should be eliminated entirely.
so a set of pwas with a tabbed ui on top. right. i think my sticking point is, what is the “tailored ui” that fediverse services require? if we’re already using the web interfaces of the services themselves, what is left? notification handling? because personally i don’t want notifications to be locked in an app, my desktop handles my notification feed. i used to have those notification counters on my tabs, using a little js snippet that rendered a number on the favicon. but then i realised that i was just reinventing a thing that was already handled at another level.
Why don’t the highest use rate clients for Fediverse services look like standard browsers? There is a level of pure aesthetic sensibility at play.
I’m interested in what you mean by your desktop handling your notifications, do you have a central log of notifications you can access via your desktop?
This is actually a pretty great angle I hadn’t fully thought out, most clients do push notifications, so is what I’m really talking about just a push notification log with the ability to filter for a set of designated sources? That would definitely handle a hefty chunk of what I’m getting at, the rest is basically just a browser skin and some extensions.
they don’t? i feel like they pretty much do, considering they’re all web pages.
every desktop environment i’ve used in the past 10 years has this, it’s basically been the default from windows 8 forward. GNOME puts them front and center in a dropdown in the middle, windows and deepin has a sidebar, KDE pops out a whole window for them.
basically the crux of it is what you want to do with your notifications. for me, a notification is an indicator that someone wants something, so the action it should perform is bring me to whoever it is. if that’s all you need, then you’re already there because every client i’ve used already has notification settings that allow you to filter stuff.
the reason i’m asking questions is that you’re all over the stack here. you’re talking about a user chrome, then you’re talking about consolidating messages, then about notification filters. i think it can all coalesce into something if you start from the capabilities of activitypub itself. it’s basically a messaging system at its core, with clients all deciding how to handle the contents of each message. i’ve long thought that neither twitterlikes or redditlikes actually play to the strength of the protocol, and that activitypub needs some sort of killer app to really shine. if you think you have something, you should let it form into a coherent idea and present it.
I’m going to have to dive into push notification handling, I basically minimize the use of push notifications at my desktop level to only push work related content, and use the notification system of the clients to handle the “recreational” content which leaves me checking lots of platforms separately.
It makes sense that there should be the ability to create separate profiles with different filters and behaviors at the push notification manager level, I just haven’t thought to look into it before.
Regarding killer apps for ActivityPub, and unified clients, I have a second idea which I didn’t want to cloud this thread with that seems somewhat inevitable that will require a central portal with access to all services (and accounts?). That is a single publishing UI where the user creates/uploads any piece of content and then it suggests what venue/service/account to publish it on and related add-ons like hash tags, etc. With the Fediverse the APIs are open and multiplatform publishing clients (like FediPlan) already exist, so a level of light ML/AI for publication seems inevitable.
The next level of this, and what could be a “Killer App” is spontaneously generated affinity grouping via content aware publishing, meaning that the publishing client not only suggests where the posts should go, but also has a metalayer where the publishing clients instances “gossip” about the content being published and then create brand new “spontaneous” venues to publish that content in alongside other similar content being published by other users. Suddenly your text post about a super-niche interest or problem is pooled with posts by other users on the same topic, and bam you have a relevant discussion group of commenters/posters.
Problems of course arrise from this re:advertisers/promoters as well as unsavory/harmful mutual interests, but to be honest I think this is more of an inevitability than a possibility, so getting ahead to architect it in a way that minimizes potential abuse before the corpos get on it is probably a good idea.
hm, i think there’s some confusion regarding AP here. there’s no “deciding where things should go”; every frontend can “see” every type of post, even if the format is off. what you’re describing by is essentially how it already works, no multiple accounts needed. the frontend just needs to decide how to handle it. for lemmy-to-masto the handling is pretty basic, you can see it by going to a mastodon server and searching for your lemmy account (formatted as @yourname@yoursite.blah).
for the “gossip” thing, every server already publishes every new thing. it’s up to other servers to decide how to handle it.
regarding the automated tagging system, i actually had a similar idea recently. i think a big flaw with lemmy/mbin/piefed is the keeping of communities from reddit; if the already extant tags were used instead, the cross-posting problem would go away completely since comments would be attached to posts rather than communities.
anyway: it would not be difficult to just use words in a post to assign it tags, but i question the usefulness of doing that. some sort of analysis would help, as you say, but then we’re introducing nondeterministic behaviour. there is definitely a discoverability problem on fedi, and something like this could definitely help with some polish.