Why is Pixelfed an extra network and not just a Mastodon client?

Submitted ⁨⁨3⁩ ⁨weeks⁩ ago⁩ by ⁨SebZuen@leminal.space⁩ to ⁨fediverse@lemmy.world⁩

Hey group,

Why is there not a Mastodon client to only utilize the media grid and pack it into an Instagram layout?

When I was exploring Bluesky and its clients a while ago, I actually liked the approach of having one central protocol and then having clients strip different masks over it. The Flashes app, for example, packed the media posts from your regular Microblog-profile into a Instagram-layout, while still keeping all your regular followings.

The federation between Pixelfed instances and Masto instances doesn’t seem to be 100% working to my eyes.

Please correct me if I got sometthing wron or you know about obvious alternatives that I havents stumbled upon yet.

Cheers! Enjoy the sun today!

source

Comments

Sort:hotnew top

tofu@lemmy.nocturnal.garden ⁨3⁩ ⁨weeks⁩ ago
Because each Fediverse software has it’s own things and they aren’t necessarily compatible. Off the top of my head, pixelfed allows more images per post and has stories. You can’t do that on Mastodon, even with a special client.

source
ignirtoq@feddit.online ⁨3⁩ ⁨weeks⁩ ago
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.

source
- rglullis@communick.news ⁨3⁩ ⁨weeks⁩ ago
  
  It stores the complete data for any given user post in its databases
  
  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.
  
  This means each one has its own data model, internal storage architecture, and streams/APIs.
  
  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?
  
  Because they were built for different purposes, they support different features
  
  Like OP said, on bluesky is possible to have different “shells” that interact with the network. Why wouldn’t that be possible on ActivityPub?
  
  source
  - CombatWombatEsq@lemmy.world ⁨3⁩ ⁨weeks⁩ ago
    [deleted]
    source
    -> View More Comments
  - ademir@lemmy.eco.br ⁨2⁩ ⁨weeks⁩ ago
    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) mastodon.social/@kariboka/116032991048115380
    
    Gostaria de te convidar pra dar ideias ou participar o quanto você puder/quiser
    
    source
    -> View More Comments
scytale@piefed.zip ⁨3⁩ ⁨weeks⁩ ago
IMO, it’s simply because they are supposed to be different kinds of social media, the same way Twitter is different from Instagram. One is primarily for microblogging and the other is catered for images/videos. Sure you can probably create a different UI for twitter to make it look like instagram, but by trying to merge them you inadvertently dilute their core features. Pixelfed probably has more features that cater to images and videos, while Mastodon does not because it’s primarily a text platform. And Mastodon has more microblogging features that Pixelfed does not require for it to be an image sharing platform. So why would a user want to use mastodon with a more image-focused UI if they want to share photos (and not microblog) when they can just use Pixelfed that is designed for it?

I don’t think activitypub has anything to do with it, it’s just that both platforms were designed for different things. When a platform tries to be everything, it usually becomes messy. Look at short form video for example. At first it was just vine, then tiktok of which it was the primary feature. Now every social media has its own short form video (reels, shorts, etc.) because they’re trying to grab users by being an everything app, and they get bloated.

source
SebZuen@leminal.space ⁨3⁩ ⁨weeks⁩ ago
Hey y’all! Thanks for taking the time to share your technical and philosophical knowledge!

I think I fall prey early on to making too much of marketing claims like ‘all platforms can speak to each other’ for the Fediverse. Now, I understand better that the platform-tech might be friendly with each other, but do not necessarily have to use the same slang.

my dilemma is that I truly appreciate grassroot/self-governed/community places – but then again: network effects network effects network effects are the only way to get people to switch.

Bottomline is that this is a dilemma as old as the fediverse. Thanks for thinking along,

AND BETTER ENJOY YOUR WEEKEND!!!

@tofu@lemmy.nocturnal.garden @ignirtoq@feddit.online @montag@friendica.xyz @scytale@piefed.zip @Steve@communick.news @DrCake@lemmy.world @Auster@thebrainbin.org @maegul@lemmy.ml @kbal@fedia.io @mrdown@lemmy.world

source
Steve@communick.news ⁨3⁩ ⁨weeks⁩ ago
It comes down to two fundamental conceptions of what the Fediverse should be.

One is a single account, all access, everything does anything any other thing does, kind of vision.

The other is a, we do our thing, you do yours, we can do together where appropriate, kind of vision.

I fall into the later. I have no problem with multiple accounts for different kinds of content and entertainment. You may fall closer to the former.

source
DrCake@lemmy.world ⁨3⁩ ⁨weeks⁩ ago
I guess it’s a case of “why not”. I’m sure someone could make a client that does the same thing but there’s a few features of mastodon that are geared towards text content rather than just images (quote posts). Likewise there’s probably some features that make sense for an image first platform that probably aren’t needed for mastodon (showing camera setting used).

Hopefully federation between the two does improve to the point that you maybe couldn’t tell at first glance of a profile is on one or the other.

source
Tuuktuuk@nord.pub ⁨1⁩ ⁨week⁩ ago
Does the Pixelfed app then not show the grid well enough? What is the problem you are trying to solve?

source
maegul@lemmy.ml ⁨3⁩ ⁨weeks⁩ ago
It’s an old conversation and it’s not you.

I don’t have links to anything on hand, but you’re not the first and won’t be the last to wonder about this and (maybe) start criticising it.

I also can’t give you the technical details (I’ve even forgotten a lot since I last cared about this), but basically, IIRC, it’s as you intuit … The platforms can be in the fediverse and still do kinda their own thing such that platform interop is not well guaranteed, arguably at all.

In the end, I convinced my self it’s a core problem of federated social media and failing at it was a huge missed opportunity to have an awesome feature that the commercial platforms lacked. “Federation happened in the client” was my way of trying to capture this perspective.

BlueSky probably doesn’t do any better but they architecture and protocol might point in the right direction.

source
montag@friendica.xyz ⁨3⁩ ⁨weeks⁩ ago
The simple answer is because Mastodon is a microblogging platform that allows a maximum of four images per post. Pixelfed is a platform for sharing images that can display any number of images per post. The two platforms communicate with each other via the ActivityPub protocol, but have different orientations and target audiences.
source
mrdown@lemmy.world ⁨3⁩ ⁨weeks⁩ ago
Mastodon already fetch from all type of fediverse platforms. Wht do you want just yet another mastodon client?

source
kbal@fedia.io ⁨3⁩ ⁨weeks⁩ ago
It is not, so far as I know, an "extra network." It's one of many types of instance on the fediverse. Many of them have features that do not perfectly interoperate with others. The more popular ones eventually get to be widely supported as things evolve. Mastodon is not the standard, it's just one among many.

Also, you're a lemmy user. It's one of the worst when it comes to interoperating smoothly with the rest of the network.

source
rako@tarte.nuage-libre.fr ⁨3⁩ ⁨weeks⁩ ago
That’s historical and can be traced back to how it was formed: some of the people were coming from the instances perspective, where a bunoh of people congregate and network, some from the individual website perspective where you can do absolutely anything and everything you want, you’re home after all. So it landed somewhere in the middle: some very basic use cases were laid out, every platform did whatever they wanted and tried to fit the basic use cases in. Now we have independent platforms doing what they want and if we’re nice we can, maybe, talk with others.

It’s a sad state but some platforms, like emissary and bonfire, are trying to go beyond and offer the possibility for anyone to build their own interface on top. One should also defocus from mastodon and look closer at the friendica family of software which have always looked at fulfilling many usecases, so compability can be better than others

source
Auster@thebrainbin.org ⁨3⁩ ⁨weeks⁩ ago
The way I understand it, no one should deal with those they don't want to, and that's best done bilaterally than having to deal with the choices of a central governance. And ActivityPub should go by this principle. Instances decide if they want relations with other instances. Users decide if they want relations with other users, communities, tags, and instances. If a given instance does something the user doesn't like, the user can pick another instance without inhering the choices of the previous, but still being able to access the environment and choose whom to deal with.

Also, in a process, whatever it may be, it's the point that more parts depend on that if it fails, the more damage happens. While AT Protocol's PDS system helps lowering stress on specific instances, the tendency is to have only a handful few, as "they already do all the job", so if a PDS node fails, more strain goes to the others, if the site owner chose or remembered to put back up nodes. Meanwhile, if an instance dies on ActivityPub, just a small part of the environment dies, but even posts from that dead instance may keep propagating. It's a situation of safety versus server optimization, I'd say.

source