new from me: FR#156 - Share Where?

on @Mastodon 's new Share button, the Mastodon API and protocol ownership

https://connectedplaces.online/reports/fr156-share-where/

FR#156 – Share Where?

On Mastodon's new Share button, and protocol ownership.

connectedplaces.online

@fediversereport Good overview as usual.

One point I would have added is that, while Mastodon announced this Share button a while back, a “pure” ActivityPub-based way to expose share URLs and similar features exists in FEP-3b86 (https://fediverse.codeberg.page/fep/fep/3b86/) and has also been gaining prominence recently (c.f. the list of implementations).

For example, ActivityPub for WordPress published its v8.0.0 today, which includes new “Like” and “Share” buttons that use this proposal.

Index - Fediverse Enhancement Proposals

@julian a thats a good addition, thanks!
@julian @fediversereport i would not say that this is "pure" or "activitypub-based" -- it is a webfinger-based mechanism. the activitypub-based mechanism is POST to outbox.

@trwnh Yes, that's accurate. I meant “pure” colloquially in contrast to “implementation-specific” (hence the scare quotes), but it is indeed WebFinger that's being extended, not ActivityPub itself.

@fediversereport

@julian @fediversereport the implementation is still specified by that FEP, though? it assumes that the target template of each link is following the protocol defined by its link relation. so it's a kind of bespoke API endpoint (one for each activity type, with seemingly no way to prefill any information except the type and the object, and even then only for an extremely limited subset of types)

@trwnh Your point is going over my head.

(a) Yes, the FEP specifies some behavior, with the goal being that different ActivityPub server software can implement it to achieve vendor-independent share (etc.) buttons.

(b) I've never implemented FEP-3b86 myself, so I'm probably the wrong person to discuss possible shortcomings. Going by the examples, its mapping of parameters to object properties appears to make it quite flexible. But I don't know – take it up with @benpate. 🙂

@fediversereport

@julian we may just be using words differently. my confusion was regarding "activitypub-based" and "[not] implementation-specific". to me, both of those statements are false.

i think i may have already mentioned to @benpate the lack of flexibility with the FEP and also the explosion of one-off "intents", as i prefer a single outbox, much as i prefer my definition of "activitypub server" to involve publishing arbitrary activities without enumeration. ;)

@julian @benpate i guess in that regard, my idea of a "share" button is "something that will let me publish any arbitrary activity". i kind of wonder what it would look like to have 28 buttons on a page instead of 1...

@trwnh @julian

I have a hard time visualizing what this UX would look like, and I'd *love* to dig through a drawing, or mock up, or product demo to showcase this idea. If it works, let's build it.

At the end of the day, I'll use whatever the best solution is for the end user, regardless of just about everything else. :)

I'd say "ActivityPub-based" is pretty close, though we could split hairs and say that #FEP3b86 does use the Activity Vocabulary.

The FEP just documents the real-world interfaces that we already have, so that websites can link to them remotely.

But I'm not sure you could make real "Share" "Like" or "Follow" buttons with just ActivityPub. It's fine for what it does, but there's a lot it DOESN'T do... and that's ok.

We're building an ecosystem, not a single protocol.

@trwnh @julian

@julian @fediversereport

Mastodon's share button is a step forward. And we can celebrate that while also hoping that they don't stop here, and open it up to work with other Fediverse apps in the future.

@dansup is also working on a promising open implementation called @webintents. And hopefully someday I can publish my own share buttons, too.

The good news: everyone recognizes the need, and we're getting lots of ways to solve this problem.