When I asked that final question I didn’t ask to because a) I’m planning to do so and b) to have your permission. It’s obvious that if I wanted to do it I could do it. That goes without saying. And it’s also obvious that actions have consequences. Not sure why I would think otherwise.
But this is not the discussion we’re having. Or at least not the discussion I’m having. I was asking because I was interested in your opinion in the context of a protocol that has been designed to help power social experiences.
And the question remains: from a protocol implementation perspective, do you think people should be able to implement what they want with it and still be connected with the rest of the fediverse (even if only partially) or do you think people should all follow the same set of rules and all should implement the same set of features to make all platforms fully interactive with each other?
No-one yelled at the developers of Lemmy for having their own creative interpretation of AP. That should be all the answer you need. Consider why dansup got yelled at for what appears to be a very similar decision on the surface.
I honestly don’t know how Lemmy is implemented. Do they only partially plug into the rest of the fediverse? Never used it and never had an account there.
I explained it a few posts ago. In case the difference isn’t clear, Lemmy does something genuinely different, yet they still did their best to ensure at least partial compatibility with Mastodon and similar, in a way that makes sense to both sides. Exactly the opposite of what Pixelfed does by dropping posts it’s perfectly capable of showing. It’s the difference between a TUI client like toot at least giving you the alt text of pictures (and the text part of the post) and silently dropping those posts because after all they’re outside its scope. Is it clear yet? This is about playing nice with others no matter what the rules say.
Ok so what I get is that for you, and correct me if I’m wrong, it’s a matter of intentions. You’re cool with someone building something that doesn’t work 100% as long as they made the effort to try get there, like in the Lemmy case. So even if their implementation doesn’t entirely work you’re fine with that because they attempted to make it work. While you don’t agree with what Pixelfed was doing because it was a deliberate choice not to make it work 100%.
Yeah, it’s bleak landscape out there for art sites right now. See for instance Bee’s site reviews and The Death of DeviantArt (+ discussion on PF). So in concept I understand the appeal of an image-focused site for artists and photo bloggers… and in practice, I don’t think any of this is the way to go.
I’m not sure I understand your question. You’re asking about designing a network? Did you mean software? Because if you meant software – people can and have designed fediverse software for other sorts of formats (ex. Lemmy, Friendica, Peertube, Plume, Writefreely, etc.). Some of those are barely used, but their existence itself isn’t particularly controversial.
write.as is a long-form blogging platform that speaks AP. WordPress has plugins that let it speak AP. I can’t comment on how well these work, however, and they might have gotten better since the last time I used either.
I have since decided, that I don’t not understand enough on the protocol side to have a strong opinion
I generally agree that enabling users to follow mastodon accounts and then dropping the majority of posts is pretty egregious.
But I do wonder what the actual difference between pixel fed and masterton will be once they enable text posts. At that point, (to my naive understanding), they sound like they’ll be the same thing but with different clients.
I suppose the difference between pixel fed and lemmy is that any jank in the compatibility of the latter and mastodon is more self-evident, and lemmy never advertised itself as a way of following mastodon accounts like PixelFed sometimes has.
Does the author of that post then expect that Pixelfed will support Lemmy and Piefed posts as well? It would not make sense and it would crush the Pixelfed server.
Does the author expect Mobilizon (event management) servers to display Pixelfed images? It would be ridiculous. So should Mobilizon stop using activitypub because I can’t use it to look at people’s pictures, Peertube videos or watch Loops videos?
Should Peertube create 4 more feeds? Feeds for photos, Lemmy communities, loops videos and mobilizon events? Or should they just continue focusing on videos?
Why does he expect he should only use one application on the Fediverse?
So you add the text support. Then what’s next? He writes a blog post complaining that you didn’t implement quote posts, polls, and a whole list of Mastodon features? Now, instead of improving Pixelfed and Loops you’re supposed to work on text posts, Peertube integration, and threadiverse capability? Nobody is going to toss their Mastodon account and just use Pixelfed no matter what you do.
Pixelfed is an image management and sharing system, and its development should focus on this core capability.
The blog post was not thought through, IMHO. And at the end of the day, I will bet you he wouldn’t turn off his Mastodon account and just use Pixelfed, no matter how well you implement that text feature and address his attack.
I’ve been loosely… I’m not super smart at this following AtProto (the protocol Bluesky runs on) development for a while, until (to me) it started to feel like the devs lost sight of AtProto and started… just focusing on Bluesky. (So that’s how I’ll express my understanding of this blog post.)
The idea of AtProto was that a single user’s account data hosted on a PDS (near-equivalent to a Fediverse instance/server) could hold posts in multiple kinds of schemas or “post types”.
A schema for microblog posts
A schema for macroblog posts
A schema for… livestreamed videos!
A schema for subreddit like communities
These schemas being like, pretty easily parseable JSON data structures that anyone can make that’re ideally also documented somewhere.
And then different AtProto AppViews, ie:
Bluesky proper
Leaflet.pub, a blogging and document service on AtProto
Stream.place, a livestreaming service on AtProto
Nooki.me, a thing with Reddit-like structure on AtProto
can then choose how they would like to interpret and display content in a user’s account data written under a different post schema than the ones they focus on.
What I’m getting from the linked blogpost is that, in this analogy via parallel, every post should be written under Mastodon’s post schema, every post should be visible within the Mastodon AppView, and reversibly, every ActivityPub AppView must have an answer for posts written in the Mastodon post schema, OR ELSE!!(?)
A common, existing criticism of AtProto “not being a real protocol” or “being miles behind ActivityPub” is that the most popular alternative AppViews are essentially just BlueSky clones that post in the Bluesky post schema and have AppViews designed around that.
But this blog post is making me feel as if that’s what people want of ActivityPub? Everything just being different flavors of Mastodon?
This seems like a pretty sound solution. Perhaps then the AppViews could offer users a setting of whether they want to or not see microblog posts, macroblog posts, livestream posts, etc.
This is an excellent point. Either the protocol and all it’s clients/servers have to be direct and verbose making sure users know everything (“Beware: Pixelfed is a client that will exclusively show posts with images attached to them, nothing more.” — plastered all over the signup page) or they can be abstract and simple in user experience allowing them to not know anything, but they have to support every possible protocol option that user might encounter.
It’s just the classic situation of “will the developer put in the time to code this feature or will they put in the time to declare that they will not support this feature”.
So to answer the overarching question that is the title of this topic: No. And I don’t think it’s that deep.
The way I see it, if “most Pixelfed users aren’t aware that Pixelfed only shows AP posts that have manually attached picture in them” is true, then the Pixelfed developer’s decision to have Pixelfed work like that isn’t the problem — the problem is them inadequately informing the users of how Pixelfed works.
And if Pixelfed working differently would be a better solution — anyone is free to create the next alternative.
My understanding is that this describes a problem applicable to small sites that get linked on a Mastodon website, which draws on the linked site’s metadata and then propagates the link from there. I’m not sure if the same issue applies to other federated websites interfacing with each other. If it does, then I would think the same would apply to Pixelfed regardless, right…? Someone fill me in here.
Yeah, the so-called “Mastodon stampede” is not a protocol issue but the result of a Mastodon-specific design decision. The Mastodon devs didn’t want to put page metadata into the post payload itself (the chunk of data that gets federated between Mastodon servers via ActivityPub) because they didn’t want bad actors to federate malicious links disguised as harmless ones. This means that in order to show OpenGraph link previews on posts, every Mastodon server will make its own visit to any URL contained in a post. If a post with a certain URL winds up being federated widely (because the post was made or boosted by someone with a bunch of followers), the URL can get thousands of visits in a relatively short span as the post is federated and servers all start simultaneously fetching the content.
It can be super frustrating for small sites on small servers. It’s a very unfortunate design decision, and one that we’re stuck with until someone figures out another approach that the developers find agreeable.
OR ELSE!!