@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...

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!