Notices by AndStatus (andstatus@loadaverage.org), page 4

@andstatus Yes, it actually is. Plus: I've seen discussions that (a) andstatus has at least preliminary support for ActivityPub, (b) fedilab *does* support friendica in some way because (c) current friendica builds come with ActivityPub support of some sort. I was trying to get these pieces together... 😉

@thefaico @tom79

@z428 As you may see from the discussion it the GitHub issue, the first and maybe the most undefined step in the #ActivityPub #C2S specification is authentication and whoami (account verification/discovery) steps. We agreed on concrete steps and endpoints with pleroma.site developer, but the same probably won't work out of the box with other systems.
Anyway, I'm open to collaboration and aim at creation of really unified API, compliant with ActivityPub C2S.

@yvolk @andstatus @thefaico @trwnh @eliotberriot @cwebber Thanks for your thoughtful explanation, I'm not sure everyone mentioned here wants to be part of this discussion but it's an interesting one for me!

I use the term "identities" specifically to reference the "id" property of the AP spec.

And some of the technologies you mentioned (Webfinger in particular) are not part of AP, so I think it's important to mention that.
[1/?]

@trwnh @cwebber @eliotberriot @kity

Maybe I misunderstand the issue but I think part of it is that right now people are okay with having N ActivityPub identities in a way that mirrors their proprietary service life. "Mastadon, PeerTube, Pixelfed" each on their own. But if you moved the bar the other way, to each of those being some sub-stream of your general AP identity, then you'd insist on a client (or c2s model) that was flexible enough to handle it.