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

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

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

Follow

@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

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!