Exactly, the server shouldn't ignore it, the user via the client should do it if they wanted to.

I don't like the fact that @Mastodon has basically stalled the development of the fediverse, people here are way to afraid of breaking stuff. Don't get me wrong, backward compatibility is cool, but sometimes you gotta do it for the benefit of the whole net.

I've read about some cool FEPs that are basically ignored out of the fear of incompatibility with Mastodon or older versions despite de fact they solve a huge problem.

Wouldn't that be better? Let me see if I can explain what I mean. Here on the fediverse each server is kind of restricted to what the user can post.

@mastodon is for notes

@pixelfed for photos (wouldn't be surprised if it used a note too)

Lemmy only for article objects.

Peertube for videos.

You get the idea.

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.

I've thought about this. All fediverse backends should implement all kinds of objects. I think mbin is a lot better than others because of this.

#Activitypub