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?
You might be interested in my proposal for a Social Web Browser. I am working on the idea, but the main challenge is that I see a bit of a generation conflict: greybeards who grew up the www prefer general “browsers” which can navigate an abstract graph, while the younger people want to rely on platforms and they prefer use-specific “apps”. You can see this issue right here in this thread: all the people telling you “just use mbin” or arguing in terms of capabilities from server-side software are completely missing the point.
@Coopr8 Yeah, why not? :) I’m all for tools that try to simplify the way people interact with the fediverse.
While I think choice is good, the vast amount of Fediverse apps can also be quite a mouthful for people not used to the ecosystem
Just use mbin. No need to go out of your way.
I do use M.Bin, but I want Peertube, Pixelfed, Looped, etc. to feed notifications into my inbox, and I dont want the burden of development of that UI to fall on m.bin devs when they should probably just focus on continuing to optimize text content functions. Also I think it is totally possible someone will come out with something better than m.bin and it would be nice if that was just plug and play into my inbox rather than requiring a full migration.
Personally, I think it would only work out if the programmer tries to reconstruct posts from different formats in a format that works out for each. Otherwise it becomes what it already is, a glorified browser with multiple profiles enabled, and with over-preference for a type of engine.
My opinion is, take note of the major platforms for each engine and/or experience, and recommend them based on your friends’ tastes.
The rest, centralization, would be replaced by what I call propagation (iirc people call it “to federated”?), which people directly and indirectly do, like boosting posts (Mbin / microblogging stuff) and commenting so people following the user see the original post too, following people and following Peertube channels on Peertube and the “threadiverse” so one’s account is a bridge for propagation, up/downvoting, etc. And as this web of social medias grows, tendency is that it keeps growing exponentially until either it takes over like email, or stagnates.
This logic, I think, is similar to recommending Linux Mint or immutable distros to Linux novices, the “safe bet” for them before they get used to the technical side or while Linux wouldn’t (past tense) become accessible.
I have two challenges to this take.
Firstly, the theory that cross-propagation of media will lead to growth across multiple platforms starting with one as the “mainline” to recommend to new entrants heavily relies on Superusers who not only use multiple platforms for content discovery, but also then take the additional step to cross-post that media from one silo into the other, for example posting a peertube link into a miroblog post. For most people they will instead interact with the content in each silo, commenting on or favoriting the peertube post within the peertube client and leaving it at that.
Secondly is the attention economy factor and platform inertia. Essentially social media platforms have successfully commodified/colonized a growing percentage of total attention hours for average users, and when interacting with content most users are passive consumers for a substantial percentage of the total content they are served. When entering a new platform, for it to serve as a viable alternative it must serve up an amount of content that allows them to both use the platform for an appreciable percentage of their total media consumption (otherwise the ratio of times checking the platform to reward for the check drops below acceptability) and provide them with a level of engagement that provides platform satisfaction, which typically starts close to where they were on average with the other platforms they use. Then you have this issue of content-fit which is a whole different issue to address, which we will leave aside for the most oart but it is worth pointing out majorly impacts the number of interactions a user puts in to the content as well as overall satisfaction.
Unifying the inbox reduces one of the barriers to wider adoption by improving the ratio of number of times the platform is checked to the amount of content available for interaction, thereby making the fediverse a more likely source of overall content to be maintained in the user’s set if options. Each platform individually will struggle with this until adoption passes a certain threshold. Each one individually feels “empty” to users when compared to their usual, which is a turn off for both consumers and creators, while in aggregate the picture is much better.
On the first point, propagation happens passively too. For example, if someone follows me on Mastodon, this reply will be pulled to his/her feed as a microblogging post, and will be discoverable on any feeds my account later appears. I remember also testing around between Lemmy and Mbin how liking/upvoting works, and doing that on Lemmy while the Mbin account followed it also showed posts previously not on my Mbin instance.
Similarly, Mbin (and dunno about Lemmy but I’d imagine it’s the same) pulls Peertube channels as magazines/communities, and iirc Peertube channels can also be followed as users on microblogging platforms, and in both cases their video uploads automatically appear on the respective text feeds.
And about the second point, I agree, but that’s also why I suggest recommending major platforms. For example, Lemmy.World and Mastodon.Social are likely to have far more publications being posted on or propagated to than Mbin or PieFed instances, since the former two are around for much longer, and not actively trying to be toxic (at least from what I can observe).
I don’t like the idea, but at least one such application is already being developed:
Thanks, this is definitely the direction I was imagining, though it takes the tac of trying to be a primary browser with Fediverse features, rather than a Fediverse dedicated browser instance, so they will be forced to sacrifice UI streamlining for website-centric UI.
What don’t you like about the idea of you dont mind explaining?
I would like to use a single account for everything, rather than separate accounts for different kinds of content. A server that works like super-app.
Combining notification streams is precisely the mission statement of UnifiedPush.
so… a web browser that stops you from going to every site.
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.
Both Mastodon and Lemmy (and Mbin) expose an API, which can be used to develop an alternative client (for e.g. mobile). This allows even for several alternative front-ends, like Elk, Phanpy and pl-fe for Mastodon (and Pleroma and Akkoma and some Misskey forks and several projects for single-user-instances - all of these extend Mastodon API in some way), or Photon, mlmym and Blorp for Lemmy. GoToSocial (made for single-user-instances) does not provide any webUI, pointing to these alternative front-ends. Lemdro.id even swapped its interface for Photon.
Mastodon clients list (scroll down) and Lemmy clients list
Technically one is able to develop a Fediverse instance software which would provide both Mastodon API (likely with extensions) and Lemmy API. With e.g. microblogging (and maybe events?) used via pl-fe and Threadiverse content more easily available via Photon or Blorp? But I am not aware of any project like that.
I’ve seen this ask come up a number of times now – and to a certain extent, the Piefed and Mbin frontends do kinda to it already in that you can have your microblog and threaded content in the same UI. But before taking that further with pixelfed/loops integration as well, ask whether it’s really a good idea. There’s a reason why Twitter, Facebook, and Reddit are separate sites, and why none have tried to implement the UI or feature set of the other. I would make the case that the fediverse would really benefit from a portable user IDs auth system that could be used between different services or instances (which Nostr kinda does, and there are other zero-knowledge proof-based services that could be integrated), but with regard to content display and just interacting with content, having 3 different tabs open with the 3 different kinds of content/conversations just makes a lot more sense to me.
Aha, but you see my proposal specifically keeps the web clients for the specific content streams up to the user rather than baking them in. I like M.Bin so thats what I use for threads and microblogs, so thats what I would select as my service for that content within the browser.
What I want is a unified inbox, with a move from each notification over to the webclient I choose to interact with the content. To be more specific I want a text-only inbox, but I want it to include headlines/captions/descriptions for multimedia content so I can have my Peertube, Pixelfed, Loops, Threads, Microblogs and whatever else all accessible from a single point of contact.
I definitely agree on the portable account point, it always reminds me of Solid the private data project by Sir Tim Berners-Lee. Seems like ATProtocol may have been influenced by it?
Honest feedback, I’d absolutely hate it. Just like I absolutely hated all attempts to centralise shit like social media apps.
