In the typical web marketing infrastructure, a company signs up for an email account for private messages, Twitter/X account for microblogging, YouTube account for video sharing, and Reddit for forum discussion.
With the Fediverse/ActivityPub model, currently a typical user might register a PeerTube account for video sharing, Mastodon for microblogging, and Lemmy for forum discussion. But the data under all those is the same infrastructure, right?
Facebook as a mature software platform has areas of its app for private messaging, microblogging, and video-specific content, all using one user account.
Is it likely that Fediverse apps will evolve toward a similar structure, where a person or company would only need one account and could push out content of all types there, and interact with others’ content with one account?
I don’t think we’re heading towards an everything app, but we may well see an everything account at some point. Companies already use social media management portals to post/respond on multiple platforms; I think if that kind of commercial demand arises for fediverse services, we will probably see similar fediverse management portals which allow you to interact with content on multiple ActivityPub services in a context-sensitive way via one account.
It’s entirely possible that a fediverse platform emerges that’s capable of performing many different kinds of activities. But, the far more likely outcome is that platforms eventually implement the Client-to-Server half of the ActivityPub protocol, which currently very few platforms implement.
The idea is that virtually every Fediverse platform could, in theory, act as clients for one another, enabling a “one account posts everything” possibility with different frontends accessing different subsets of data.
Excuse my ignorance here. To what extent can this problem be simplified with DIDs or Decentralized IDs, rather than “federated accounts”.
Take the example of Filpboard. I signed up to integrate #mastodon with #bluesky. Supposedly, they have AI to process two disparate systems. The result: Nada. Why? Because I have to put some verification HTML in a website.
I have a “domain name handle” that should allow two independent information sources to communicate. The same account, or DID, needs to work on both systems. I don’t see that.
No, you’re not quite understanding what ActivityPub is. The data under all the fediverse services is not the same infrastructure at all. The communication between those various services just uses the same language (ActivityPub). Those various services can interpret and store (or ignore) ActivityPub messages any way they want. Service instances add another layer to the whole thing as well.
In order for an “everything app” to be successful (if you buy the argument that it feasibly can be), it would have to be a centralized service. Decentralization, by its very nature, encourages the opposite of that – want to make some niche service because existing services don’t satisfy some fringe need you have, but still want to interact with others on other platforms? You can do that with the fediverse. But that also means your new service isn’t part of an “everything app”… it just can potentially talk to one that might exist.
I doubt it. I admin a lemmy instance and a regular fediverse instance, and I use them both very differently, because their interfaces lend themselves to different uses. Even though they can communicate with each other, trying to navigate a large number of lemmy groups from Hajkey would be annoying, and trying to follow specific users from lemmy would be annoying.
An all in one app would mash that all together, which would probably be overwhelming and confusing
But the cool thing about open standards is that there’s a clear pathway to creating an everything app. Especially if decentralized ids gain some traction, then we could have an app that combines mastodon and pixelfed but presents the different posts in a sensible way.
I can’t really wrap my head around what such an app could look like, but it’s much more feasible to build one than it would be with closed services. I’m hopeful that freedom to experiment without lockin will lead to some really neat ideas
