This way of developing the #fediverse where each server only receive one kind of the objects accepted by #ActivityPub makes it more fragmented it, right? A server should send and receive all kinds of objects and should be up to the client to how to processes those objects.
If an user wants an Instagram-like app just create an account on any service and use and app with that UI, of lager they wanted to see more kinds of objects they should just use another client that supports Note, Article, etc. with the same account on the same server.
Ideally all server should have a shared API.
This fixes #fragmentation, the need to have multiple accounts if you are into multiple kinds of objects/content.
You're viewing a single thread.
19 comments
While I think fragmentation can grow into being a problem, trying to standardize things too much can be problematic too, as the developers would be bloating the software for features that the community may use very little, as well as, by consequence of the bloating, the devs being either limited to a design that needs to take into account the quirks of all object formats, or to make some frankenstein monster design to include those different formats.
A more reliable path, I think, is what Kbin (RIP) and its successor Mbin do, to have a section for articles and one for notes. While it's still more load on the developers and the servers, at least it shouldn't be as much as having to make sense of multiple formats together, since the two sections don't directly interfere with each other. This, on a final point, is, to my understanding, and with their respective proportions, what happens with the Linux family of operating systems, where it's also pretty fragmented, but every once in a while a way to put two different environments together appear, like Wine and Xfce translating Windows and QT5 programs, or AppImage and Flatpak trying to be as universal as possible by depending on as little default dependencies from the host system as possible.