Follow

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

ยท Web ยท 9 ยท 17 ยท 18
So the general idea is that if some new Fediverse project came along and implemented AP C2S as wellas S2S they wouldn't need to bother with an API or have their own client because they could just use an existing one that's close enough?

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

> a PeerTube native client would still be needed to stream with WebTorrent.

So probably an application specific API would be needed along side the C2S as well for that sort of thing or is that TBD at this point?

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

@alexl @cwebber Is there no room/desire for:

?

(That is to say, instance-specific Client-to-Server APIs, that are not intended to federate out, alongside the federating ActivityPub ones?)

@gaditb @alexl No reason that can't be supported, and since we thought s2s would be "harder" than c2s, we figured that this would happen even

@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

@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 I dunno, to me "platforms" in a federated open system are the same as branding. I guess time will tell..

@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

@alexl You know what? Sure. People are excited about federation again and that's good. It's not me who has to roll the boulder up the hill after all, and maybe the API incompatibility issue will be resolved in time

@alexl @tomas

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

@alexl I just explained how. Pleroma and mastodon are targeting people who want microblogging. If you don't recognize server names, you wouldn't even know if people you're chatting with are on Pleroma or mastodon. An AP Note is a Note regardless of where it comes from.

The well written fediverse apps work with both fairly seamlessly. What software a user is using is most likely down to the people and topics on the local timeline.

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

@alexl why couldn't tell your friends to use Pleroma? It doesn't require any more technical knowledge than mastodon. If you web up a pleroma account on the mastoFE and a mastodon account, an end user wouldn't find much difference between the two.

As for the software, you named multiple different types of applications. There's a CMS, static site generators, and hosted blogging platforms and that's how I would group them. So I would say Plume and write.as are targeting the same users, though write.as is targeting more users since it offers a paid service

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

@alexl one of the first things users do on the fediverse is ask about other apps. Having multiple frontends isn't unique to Pleroma. Most existing clients work with both mastodon and Pleroma.

It sounds like you're just talking about different features but a lot of AP services are in active development. They have planned features but that doesn't mean they have a different audience
@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
@alexl Well not completely, AP is written in node.js, the others aren't. @mmn

@alexl @cwebber I still love this image. Every time I see it a little bit of happiness starts bubbling.

@alexl @cwebber supposed to and could be are basically the same no?

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

@alexl @Transflux not with your account but with any mastodon app basically

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

Sign in to participate in the conversation
Mastodon

Fast, secure and up-to-date instance, welcoming everyone around the world. Join us! ๐ŸŒ
Up since 04/04/2017. โœ…

Why should you sign up on mstdn.io?

This instance is not focused on any theme or subject, feel free to talk about whatever you want. Although the main language is english, we accept every single language and country.

We're connected to the whole OStatus/ActivityPub fediverse and we do not block any foreign instance nor user.

We do have rules, but the goal is to have responsible users. So far we haven't had any issue with moderation

The instance uses a powerful server to ensure speed and stability, and it has good uptime. We follow state-of-the-art security practices.

Also, we have over 300 custom emojis to unleash your meming potential!


Looking for a Kpop themed instance? Try kpop.social