@alexl That seems right to me.
@cwebber thank you!
@hankg it could be possible when AP C2S API is enough and the UX of the native client is similar to the Web one. One could use a Mastodon client to manage his PeerTube notifications but a PeerTube native client would still be needed to stream with WebTorrent.
What would be more useful is for example logging in a blog or an issue tracker or anything else and comment with your own AP-server account (for example a Mastodon one), with your nickname, handle and avatar always updated.
@hankg If I understand correctly one could extend ActivityPub for what makes sense, in this case a feature that could be implemented by platforms supporting videos and define other API for features specific for its service.
For example ForgeFed is extending ActivityPub for services like GitHub, GitLab, Gitea, Gogs with activities like pull requests, forks and issue tracking.
@gaditb when needed
@alexl Note that different software is likely to have different features, for example a peertube client may be sharing videos via webtorrent while mastodon client wouldn't. So not all clients would be equal; a general purpose AP client would only do general standard AP stuff.
@fr33domlover of course, but how is this different from Google+ and YouTube clients for Android that shares the same account? I'm assuming one uses all the clients he needs, not a single one
@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.
@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...
@tomas *didn't follow it
@tomas Mastodon and Pleroma target different users, same for Plume and Write.as. Different user experience, different hardware resources needed. Different developing models (community-driven etc). Different languages, frameworks and technologies.
AP is intended to federate everything around the concepts of activities. How can you think an all-in-one social network would be better? We had Diaspora already. AP can be a totally new approach to Web not only social networks
Mastodon and Pleroma target different users, same for Plume and Write.as
That’s not true. They’re targeting the same space and same users. They have different UX because they’re different projects built by different teams. These AP projects fall into buckets like (microblogging, macroblogging, video sharing) and any client made for one would likely work for another project in the same bucket. Specific features may be missing or only available on specific servers, but the overall experience should be the same.
@0x1C3B00DA of course they target different users, I don't really understand how you can disagree on this
@0x1C3B00DA Come on, Mastodon and Pleroma are very different, I can say to each of my not-geek friends to join Mastodon, I can't with Pleroma.
"Microblogging" is very generic, or do you think that WordPress, Tumblr, Drupal, Joomla, Blogger, Hugo, Jekyll, Plume, Write.as target the same users because they are about blogging?
@0x1C3B00DA "MastoFE"... let's complicate things. After all Arch is easy to install and use, no? No need to reccomend distro like Ubuntu or Mint
About the second part, you got it...
@0x1C3B00DA of course they have different audience, I can't really get your point
@0x1C3B00DA did you notice that Write.as doesn't support comments?
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.
@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.
@tuttle you are not fun
@Transflux but the first one is generic AP concept, the second how actual platforms would be, to make it clear what supporting ActivityPub means in real world applications
@alexl well pleroma can make use of the msdtn Web ui so it's already like "How it could be".
@Transflux can I login in every Pleroma instance with my Mastodon account?
@alexl no. That doesn't make any sense actually.
@Transflux so why do websites, apps and services implement login with providers like Google, Facebook, GitHub etc? Never heard of nomadic identities like on Hubzilla? Isn't Disqus so popular because you don't need to register on each site to leave a comment? Wouldn't be useful to login on websites and apps and perform actions with one single account with updated nickname and avatar and the link to profile page?
@alexl ah you talk oauth like things. OK didn't think of that since pleroma and mastodon are very similar... sure the less fragmentation the better. I don't see anything like that in the diagram tho.
@Transflux according to the diagram I would be able to login in a PeerTube instance with my Mastodon account, leave comments to videos and then receive notifications of replies on my Mastodon native client. This is not just about login like oauth.
You have to think more about this, it's possible and we are just stupid in performing the same actions in different sites (even multiple instances of the same platform) duplicating accounts, each one with its database entries and models.
@alexl you mean this to be the link from a client to a different instance?
@Transflux I mean just what happens now with Mastodon and its native clients: they can display account profiles from other sites (not Mastodon instances) that implement them as ActivityPub's actors. They do so trying to retrieving informations with ActivityPub, inform the user that the profile can be incomplete and provide a way to open the same resource as web page on its own site.
@Transflux *trying to retrieve