this post was submitted on 31 Jan 2026
62 points (97.0% liked)
Fediverse
40167 readers
132 users here now
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, Mbin, etc).
If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration)
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Bluesky is one, single platform. It stores the complete data for any given user post in its databases and provides that through its data stream and APIs. This means every different client someone writes has access to all the same data as every other client, because they're all going through Bluesky. This also means if Bluesky doesn't support some feature, no clients can either.
The architecture of the Fediverse is different. Forgetting ActivityPub for a moment, Mastodon is one platform and Pixelfed is another. This means each one has its own data model, internal storage architecture, and streams/APIs. Because they were built for different purposes, they support different features. I don't use either, but I expect there are image-related features in Pixelfed that are just not possible in a Mastodon client, not because someone hasn't written a client capable of it, but because Mastodon doesn't have the internal data storage nor API to support it in any client.
Where ActivityPub comes in is a unified stream language. When a post pops up on a platform, that platform has the complete data and translates as much as it can into an ActivityPub message to send to other platforms. Some platforms haven't figured out yet how to pack all of their relevant data into an ActivityPub message, so some data may be lost in the sending. And different platforms may not support storing all the data in a given ActivityPub message they receive, especially if it's from a feature they don't provide, so some data may be lost in the receiving.
Ultimately this means even with ActivityPub linking things together, the data flow isn't perfect/complete. So different data is available to any even theoretical Mastodon client compared to a Pixelfed client because the backend platforms are different. Their APIs expose different data in different, often incompatible ways, so even if someone wrote an image-focused client for Mastodon, it wouldn't be possible to do everything an image-focused client for Pixelfed could do, because the backend platforms focus on different things.
That is not fully correct. The index the data from the different personal data servers, and they host the largest personal data server out there, but you can have your own PDS and interact with other Bluesky users without having to rely on their data.
Yeah, but why? ActivityPub already provides the "data model" and the API. Internal storage is an implementation detail. Why do we continue to accept this idea that each different mode of interaction with the social graph requires an entirely separate server?
Like OP said, on bluesky is possible to have different "shells" that interact with the network. Why wouldn't that be possible on ActivityPub?
Oi! Vou falar com outros devs brasileiros amanhã sobre criar um implementação genérica do protocolo, com diferentes módulos para cada API (Mastodon, Lemmy, etc) https://mastodon.social/@kariboka/116032991048115380
Gostaria de te convidar pra dar ideias ou participar o quanto você puder/quiser
Cara, eu já estou com com uns 70% da API do Lemmy implementada, e passei esse fim de semana todo trabalhando numa entensão pro browser que "puxa" o grafo social localmente e mostra os dados, como se fosse um browser. Quero ver se consigo fazer posts via C2S antes de ir dormir. :)
Tudo isso pra dizer: sim, eu tenho muito pitaco pra dar nessa história...
It is not. A server that "speaks" the ActivityPub is not that difficult to build, I've done it. The complexity is in getting the data from the social graph into and creating a good UX for users who are too used with the "app-centric" mentality.
Not "stored on activitypub", but each book could be represented with RDF (it could be something as sophisticated as using DublinCore or as simple as just using isbns to uniquely identity the books (
urn:isbn:1234556789) , and then each activity for "CombatWombatEsq read a book" would be an activity where you are the actor and the book is the object. Then it would be up to the client to expand that information. Your client app could take the ISBN and query wikidata, or Amazon, or nothing at all...You know that the whole of wikidata can be copied with just a few hundreds of GBs, right? There are plenty of examples of community-driven data providers (especially in the *arr space), so I can bet that there would be more people setting up RDF data servers (which is mostly read-heavy, public data sharing) than people willing to set up their Mastodon/Lemmy/GoToSocial server - because that involves replicating data from everyone else, dealing with network partitions, etc...
Also, there are countless ways to make this less dependent on any big server, the client could pull specific subsets of the data and cache data locally so the more they are used the less they would need to fetch remote resources.
Think of it like this: a client-first application that understands linked data would be no different than a traditional web browser, but the main difference is that the client would only use json-ld and not HTML.