@cwebber I made these diagrams, can you please tell me if my understanding is correct?

@alexl You could think even bigger. There shouldn't be "Mastodon" or "PeerTube" native clients, but rather everything should be specified in RFCs such that entirely generic clients can be written. Then trouts could be applied to certain BDFLs until they actually implement said RFCs

@tomas there would be confusion, see XMPP clients... we need very different platforms (blogging, microblogging, newspapers, video and audio streaming, issue tracking, collaborative editing, ) each one with its own user experience but federating "actions" and "objects".

For example I could use even a Mastodon client to reply to comments in a issue on GitLab but I would still need a native GitLab client to perform actions like pull request or fork.

@alexl Myes, but a lot of these things would need to be implemented in most clients anyway. Webtorrent for example, would be useful in all kinds of places, not just PeerTube. And if you have that in your generic AP microblogging client, and the client knows about banggroups, then it is effectively also a PeerTube client. But that said, branding can be a very useful and good thing.

You know, the comparison to XMPP is apt. I've said before that AP will start having the same problems that XMPP has had to deal with. This always happens.

@tomas I disagree, it's not a matter of just branding, but having different platforms with different features for different people. If an actor is on another platform expect less interactions with one using the same platform or login in the other platform with the same account and enjoy it.

XMPP approach was proven wrong and in fact anything else follow it so I don't know what you are referring to...

@alexl what do you imply that !XMPP's approach was? And how does it differ from ActivityPub's approach?

@mmn
I'm not an expert but my understanding is:

XMPP: trying to define spec per-feature, hope people implement XMPP servers and clients, assuming the user knows each client and each server which feature/spec support.

ActivityPub: federating everything that involves actions, actors and objects, defining how communications happen and provide some example of actions etc for common use cases.

Every platform can implement AP because is very abstract, see Mastodon.

@alexl Right, I think you've managed to misunderstand both XMPP _and_ AP in this case.

You might want to check out the well authored, established and implemented XEPs out there for XMPP and compare with AP where this doesn't exist for the most part. The AP base spec might be object agnostic, which I think you're using as the base argument?, but XMPP is too.

They're not comparable in maturity.

@mmn XMPP totally failed, it was OK for very basic single chat ten years ago. Now clients for Android, desktop and Web implement different sets of features.

With XMPP I can't say to someone "register to platform.com and download a client for your device". Instead Mastodon IS a platform and it has ITS OWN clients that offers consistent UX.

XMPP can't be abstract as AP because they are protocols for totally different things. Matrix replaces XMPP.

@alexl Yes, and even more, ActivityPub, XMPP and Matrix are different to each other in the sense they all are run SMTP under the hood. @mmn