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?

Follow

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

· · Web · 0 · 0 · 1
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!