i wrote a blog post about activitypub! i promise it's different from everyone else's blog posts about activitypub, probably!

https://ktn.fyi/blog/posts/20190208-mastodon-is-not-just-a-server
many thanks to @cwebber for inspiring me to write this
Follow

@kity @cwebber I've read your post and while I understand the intent, I have a really hard time figuring out how generic ActivityPub client could work and be useful.

In my mind, ActivityPub deals with the transport/data layer by providing a standard way to represent objects, activities and broacdcast those over the federation.

But how can a client implement a generic and meaningful UX for every server?

@kity @cwebber Sure, you could imagine writing a client that could post to both Plume, Mastodon and Pleroma servers, assuming they support C2S protocol.

But Plume supports Markdown, while Mastodon doesn't. I don't know for Pleroma but you get the idea.

How would the client know what the server support in terms of features?

@kity @cwebber also, projects handle different types of data.

Funkwhale and PeerTube instances deal with Audio and Video media, respectively, PixelFed with images, Mastodon and Pleroma with small-to-medium text, Plume and Write.as with long-form content, etc.

Do you think it's possible to provide a unique and comfortable experience for all those projects ?

@eliotberriot @kity I guess since that was the goal of MediaGoblin, I still hold onto that vision. It's also more true on platforms like Facebook and Google Plus (RIP) than it is on Twitter and some others.

@eliotberriot @kity I think if ActivityPub had launched with a more facebook-like flagship implementation rather than a twitter-like one, people would find this less surprising

@eliotberriot @kity You're right that some level of server feature discovery needs to be done though, and we haven't quite implemented how to do that. XMPP may be a source of inspiration there.

@eliotberriot @kity I also think that @emacsen is right that the "streams" activitypub property may be a way to help here

@cwebber @eliotberriot @kity

The big secret here is that I'd asked "everyone other than Chris" to answer the question at FOSDEM, it's because I'd already asked them this exact question on IRC a month before and they suggested using streams exactly in this way. The reason I didn't want Chris to answer was I was curious to knew what the implementers were thinking (and I already knew what Chris would be likely to say).

@emacsen @cwebber @eliotberriot @kity how would `streams` help with this? my understanding of streams was that they would be used a la Collections on Google+, for arbitrary subsets of your outbox. unless you mean creating a separate stream for each type of payload?

@emacsen @cwebber @eliotberriot @kity my take is more that the current "non-generic" implementations are actually a really bad fit for the c2s api, precisely because they do so much validation server-side. an xmpp-like extension system would quickly become confusing. server feature discovery isn't part of the c2s spec, is it? afaik a lot of that stuff seems to be handled by nodeinfo in the wild.

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

@emacsen @cwebber @eliotberriot @kity yeah that's very much a big part of it, people are looking for "alternatives" and it's easy to promote something as "federated [x]" where everything fits your internal model. it's also easier to develop an app-server than it is a generic one. the server does all the heavy lifting, and you can define an app-specific API for handling just the data the server can process. it sidesteps the problem of server capabilities almost completely, that's the API job now

@emacsen @cwebber @eliotberriot @kity of course there's the new problem: which API methods does a server support? what are the limits of each API field? and that's part of the design of the API rather than the design of the server. hence why modified masto or pleroma servers run into issues with the masto API. the server needs to report info about itself a la /api/v1/instance

@trwnh @cwebber @eliotberriot @kity

Thinking about the issue of the poor state of C2S ActivityPub, implementations, maybe the thing to do is make a new AP client (without a server) that does what we want and is designed to be flexible, and then see which servers support it.

The only big downside I see is that AP doesn't have a standard authentication mechanism, but maybe that can also be modularized and abstracted.

@emacsen @trwnh @eliotberriot @kity I honestly think that oauth 2.0 bearer tokens work just fine for auth, and that's what the AP test suite required

@emacsen #AndStatus Android client allows you to setup as many user accounts as you wish in several types of Social networks (#ActivityPub is in testing now). And it recognizes the same your Actor in different instaces, showing a combine view of one Actor via several networks, or a view of all your Actors...

@eliotberriot @trwnh @kity @cwebber

@andstatus @trwnh @eliotberriot @cwebber @thefaico This is very interesting and I'd like to hear more, but I'm talking about a subscriber needing to subscribe to N streans, not the C2S, but rather a follower.

@emacsen Oh, I understand now. Regarding following different Actors (located at one or different servers) of the same User/Person in one #ActivityPub network.
The problem is only with Actors ("identities" as you called them) that were originally created mostly because networks didn't communicate with each other, and so one person created duplicating Actors in order to be a part of a larger community.
This is exactly why I worked with #ActivityPub W3C working group to clearly separate notions of a User and of an Actor:
E.g. in a data model of #AndStatus client I created separate entities for a User and for an Actor, allowing one User to be linked to more than one Actor. Currently this feature is used to automatically identify and link actors in different networks, having the same WebFingerId (e.g. on different instances of GNU Social or Mastodon), but it can be extended to link (manually for the start...) e.g. Actors that are known to represent the same Person...

PS: Replying to you from my "personal actor".

@thefaico @eliotberriot @andstatus @trwnh @cwebber

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

@yvolk @andstatus @thefaico @trwnh @eliotberriot @cwebber

What I hear you saying is that you think Webfinger is the place to tie streams into, rather than AP itself,. but the AP spec has a section on secondary collections, which is where I would imaging having these. A secondary collection be a reference to another actor. You *could* do that in Webfinger, but you could do it in AP as well and I see no reason not to.

In what way do you think Webfinger is more appropriate?

@emacsen I mentioned WebFingerId not as a part of WebFinger protocol, but only as an artificially created identifier, helping to figure out the same actors via old-style (Twitter-like...) client APIs (which don't provide globally unique identifiers of actors (users...)).
As we're currently are figuring out, how to use #ActivityPub C2S protocol in the real world :-) I see that WebfingerId isn't really needed in ActivityPub API: Actor's profile has enough information to know both username and hostname of an actor (what constitutes WebFingerId).
I think that you will be interested to read our discussion on this here: https://github.com/andstatus/andstatus/issues/499

@cwebber @thefaico @eliotberriot

@trwnh @emacsen @eliotberriot @kity Yes, why can't each type of payload be one of those arbitrary subsets? :)

@cwebber @emacsen @eliotberriot @kity your client would expect the server to have those streams already, which is not guaranteed. or it would need to create those streams itself. right? we're still assuming the server is like imap/smtp here so it'd be kind of like making folders/labels i guess?

@cwebber @emacsen @eliotberriot @kity it might even be possible to bridge email and activitypub with a generic server that speaks both protocols, huh?

@trwnh @emacsen @eliotberriot @kity Someone mentioned something like ActivityPub-ish design using ActivityStreams over SMTP at FOSDEM and I forget who it was or if it was real or a joke

@cwebber @emacsen @eliotberriot @kity i've joked about activitypub over smtp before but now i'm thinking this mad lad might actually do it

@cwebber
Host-meta seems like a decent place to put domain-wide capabilities. But correct me if I wrong, ActivityPub is trying to not make /.well-known a requirement (as long as URLs are in use) so this might be harder?
@kity @eliotberriot

@cwebber @eliotberriot @kity isn't " be doomed to failure" the only inspiration one can get from XMPP?

@jack @eliotberriot @kity I definitely don't feel that way! There's a lot to learn from and love from XMPP... and it's even great to use!

@cwebber @kity I find it really hard to imagine myself using the same client for Funkwhale, PeerTube and Mastodon, like I would find it weird to use the same client to interact with SoundCloud, YouTube and my emails.

I'd be limited by the common denominators of each project, would'nt I?

@eliotberriot
I really wish I didn't forget to mention words "backend" and "frontend" at FOSDEM.

Pleroma is an example of a backend that has multiple frontends /built in/ (even if they serve the same purpose of microblogging, not sharing other content).

Having Pleroma or Mastodon backend with a forum (inspired by phpBB, vBulletin, BuddyPress) UI or vote-news-site (inspired by Hacker News or Reddit) UI would let me use the same fediverse identity to participate in different ways.

I mean... Threads already branch out in fediverse, and different UI would make it possible to read them in a more efficient way.

Similar applies to imageboardish UI (Pixelfed) or news writer/reader UI (read.ly, write.ly).

@kity @cwebber
@eliotberriot @cwebber so i think you've got it a bit backwards here; i'm talking about a generic *server* that can (extensibly) route and handle anything a client sends. in this scenario, your client could be the mastodon interface, which is great for microblogging, but you could also use the peertube interface to post and interact peertube content. in this world all activitypub servers would basically be "generic" reimplementations of the same concept, and the clients would differentiate how you interact with the platform (moving the user-agent aspect from being embedded in the server to being a user-controlled aspect)

@kity @cwebber thank you for the explanation, it's clearer now. So pretty much like XMPP servers like Prosody from what I understand?

@eliotberriot @cwebber i'll be honest i've never used xmpp before, but someone else might have an answer 😅

@eliotberriot @kity @cwebber *maybe*? i'm not sure to what extent xmpp servers store data and how, but i'd say probably in the sense that email servers can host your emails and xmpp servers can host your messages.

a generic AP server would at minimum handle delivery of AS documents generated by the client -- the recipient can parse and validate, perhaps the server can tell the client whether the response was 200 OK or if there was some error (i.e. "was this message delivered successfully?")

@eliotberriot @kity @cwebber so in that sense it would be delivery server only (like SMTP) but then one step above that would be to have the server also manage data *storage* and not just delivery (a la IMAP).

in that case, the server stores your inbox and outbox and all the AS documents and Activity stuff, and allows fetching the content on valid GET requests. but there is no standard authentication/authorization flow, so we're kind of limited to allowing public fetching if we want full compat

@eliotberriot @kity @cwebber as far as the client would be concerned, the generic Server doesn't have a way to dictate limitations. but rather, the client would fetch only the AP documents that could be validly displayed within that client. so if the client wants Note objects under 500 characters, it would get your inbox and filter for Note type, then filter for length.

that's kind of wasteful i guess? which is why most AP projects chose to reject incoming Activity that they don't understand.

@eliotberriot @kity btw @cwebber feel free to correct me if i'm wrong, this is just my understanding of what a generic AP server would be like :)

@eliotberriot
@kity @cwebber
Think Tumblresque UI but with native support for embedding peertube videos, funkwhale audio, pixelfed photos, mastodon/pleroma toots, and plume longform posts in one delicious endless scroll. #ActivityPub

@eliotberriot @kity @cwebber pleroma supports markdown, mastodon is the odd one out in this regard.
Sign in to participate in the conversation
Mastodon

mastodon.eliotberriot.com is one server in the network