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?
the formatting is up to the client that displays the content, interestingly enough. AP just has a "message type" fields and different clients care about different types.
i'm not really sure what that gossip method achieves. surely if it's just post metadata we're talking a hundred bytes at most. running it separate from the main feed seems like it would just bork every single AP client that tries to use content published by this hypothetical one.
Yes, the automation datastream would need to be segregated, and probably ephemeral.
The point is that if you want posts to spontaneously coalesce with some kind of shared Metadata, you want the ML content analysis information of the post to go out before the actual post is published so the final post Metadata can include the "group" tag or whatever you want to call it.
Alternately you could do it after the fact by editing the post, but that seems like there would probably be some degree of chicken and egg scenario.
All of this could be done by the client completely independent of post metadata of course, but then how do you make the relation of the posts to each other consistent between multiple users? Is that even a desireable/necessary goal is a question I suppose.
i don't understand this assertion at all. the post is the post. surely we want to classify the post based on the content of the post? tags are contained in posts. your client can just add the relevant info before sending it. figure out potential categories locally, query the server for which of them are popular, and either pick one or have the user select one.
The difference is that I'm talking about the automation creating completely new groupings, most akin to a community on Lemmy, that coordinated across multiple users, in my mind "simultaneously" with the user still agreeing to opt in to inclusion in that group.
There is an alternative way to do this, which would be that the automation groups the posts after posting, however there is a question there about opt-in, will users want to opt existing posts in after the fact?
One way that definitely would be easiest to implement would be if these groupings are essentially threads with a single piece of content as the "start" / "seed" of the thread and the other posts relating to that thread. Regarding opt-in for that I suppose it could be as easy as enabling/disabling "thread seeding"
so fun fact, that's already how lemmy works. communities are not a thing in ap, so you can technically post to whatever community you want, existing or not. the lemmy software then limits users from posting to nonexistent communities. and ap already has the notion of posts having parents, so threading is also built in.