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

@[email protected] I'd say a protocol handler would be one small step in making this better handled.

The friction with a global "share to the fediverse" button is the instance chooser. Not knowing what your home instance is is a major sticking point.

A protocol handler could allow you to skip this step, assuming you have an app that has registered against it.

Otherwise, yes, the same fallback would need to continue to exist (enter your home server! blah blah)

@julian @fediversereport Indeed, the Fediverse desperately needs an URI scheme (for example web+ap, but something else might work too).

In XMPP you can implement a provider independent share with feature with xmpp:?message;body=hi

I've trying to make web+ap: happen for a while and #Conversations_im for example auto links URIs like that (my small contribution as someone who is not really in the Fediverse community)

@julian @fediversereport this was tried and then rolled back at some point, for reasons, though I forget what those were

@[email protected] I'd love to learn more about prior attempts at utilising the protocol handler. Was it Mastodon who tried?

cc @[email protected]

@julian @fediversereport https://github.com/mastodon/mastodon/pull/4511 Mastodon, and quite early. I think the removal (or at least depriorization) was because the browser UI for them was very poor and very flaky, though I don't recall details.
Add protocol handler. Handle follow intents by Gargron · Pull Request #4511 · mastodon/mastodon

Example: https://jsfiddle.net/pvyoof6L/3/ (to work properly, run this PR on localhost, and open web UI once prior to running the fiddle) TODO: Follow intent Share (toot) intent Fix Intent/sh...

GitHub
@[email protected] thanks for sharing! I'll have a look through and see what happened

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

@fediversereport @Mastodon it's interesting to mention email protocols like IMAP or SMTP as the example of what should be since neither of those (and indeed POP) started out as a standard either, they lived for a long time as same kind of defacto standards as the Mastodon API but after many versions eventually became actual ones.

@fediversereport @Mastodon Is this a failure of Mastodon for not being more open or on the great AP community for not stepping up and getting a more generic share button setup sooner?

🤔

@phillycodehound @fediversereport @Mastodon I know there's work being done on generic share and follow buttons with the Web Intents stuff by @dansup but in terms of APIs, more definitely needs to be done in that area. I might have an idea but would need to work out the finer details.
@Seth of the Fediverse @Connected Places The great AP community themselves are way more likely to whip up a Mastodon-only share button than a generic Fediverse share button, and they have done so in the past several times AFAIK.

The thinking behind this has always been one of these:
  • Fediverse = Mastodon. The Fediverse only consists of Mastodon.
  • The Fediverse is more than Mastodon, but only barely. It isn't worth supporting all those teensy-tiny side-projects.
  • The Fediverse is more than Mastodon, but it's easier to only support the biggest of all projects than to support all projects.
  • People are more likely to be familiar with "Mastodon" than with "Fediverse", both on Mastodon and outside the Fediverse. Nobody would understand a "Fediverse" share button.

Oh, and Mastodon hasn't failed being more open. Mastodon has decided to not be more open. It's a fully intentional design decision and part of Mastodon's scheme to either make the rest of the Fediverse look bad or exclude it from "the Fediverse".

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon
Netzgemeinde/Hubzilla

@jupiter_rowland I do agree with you... Mastodon isn't the whole Fediverse. I also agree with you that most wouldn't now what a Fediverse share was. But that comes down to education.
@fediversereport @Mastodon The share button does not use the Mastodon API and has nothing to do with whether 3rd party apps or different platforms choose to implement the Mastodon API or not.
@Gargron @fediversereport @Mastodon Can the share button also link to other platforms, or only to a Mastodon instance?
@hiker @Mastodon @fediversereport If it has a /share page, it works. The tool doesn't care.
@Gargron
But why is it called Mastodon Share Button and not Fediverse Share Button? @Mastodon @fediversereport
@hiker @Mastodon @fediversereport My impression is that a lot of people would be upset with us if we published something claiming to be a "fediverse" tool, as if we own the fediverse. Of course, there's also not nearly the same amount of brand recognition for the fediverse as a concept. There are at least 3 unofficial symbol proposals and most people outside the fediverse aren't familiar with any of them.
@hiker @Mastodon @fediversereport Probably the body best suited to publish something like a fediverse share tool is the @swf. Regardless, I think we're well within our rights to publish a tool our users asked for, catered to our own platform. Not everything has to be for everyone. PeerTube has a PeerTube app and Sepia Search, nobody is upset (nor should they be) that those don't work with Mastodon.
@[email protected] that actually makes a lot of sense. I don't want to subscribe to the idea that you're on your way to the third E (😝)... that you're simply trying to stay in your lane is the simplest most logical explanation.
@Gargron @fediversereport @Mastodon @[email protected] @[email protected] it’s not really a ‘federated network’ if things don’t work across platforms?
e.g
Link type posts by Lemmy / piefed do not federate the url, trying to share cross platform is bad.
Maybe a federated network should spend some time making things work
@ozzy @fediversereport @Mastodon @swf @hiker I think things work pretty well right now. You’ll never have 100% feature parity between platforms, sometimes it doesn’t even make sense. Some code forges now use ActivityPub between themselves, but I think most would agree it would be ridiculous to expect to be able to send a pull request to a code repository from Pixelfed or Mastodon. The important bits are the bits that are in common.
@Gargron
If everyone now starts incorporating features into their own software that are incompatible with other platforms, this contradicts the idea of a federated network.
@Mastodon @fediversereport @swf

@hiker @Gargron @Mastodon @fediversereport @swf

If everyone implemented the exact same features, what would be the point of having dozens of different fediverse software projects in the first place? The only thing they'd differ in would be the UI then.

Imo it's cool that we have so many different projects with different visions that still can do basic communication with each other without sacrificing their uniqueness. It feels very human.

@frog_reborn
But this is about a “external” function—why should websites only want to add Mastodon button? Why not include the entire Fediverse?@[email protected] @Mastodon @fediversereport @swf
@Mastodon @fediversereport glad to see an extended critique of the way the Mastodon API has been getting entrenched in the Fediverse to the expense of the ActivityPub API

@fediversereport

The Mastodon API is open source, but it is not an open standard. It is designed, maintained, and changed by one project, without input from the rest of the ecosystem.

Not without. The design of this API is shaped by the needs Mastodon users. Sometimes PRs are submitted by developers of 3rd party clients and by developers of other servers. Independent implementers of Mastodon API often extend it, and copy each other's extensions, there is even a discussion about Mastodon API Enhancement Proposals (similar to FEPs).

So I think that by now it is very much an open standard.

ActivityPub API may have W3C's stamp or approval, but that doesn't mean anything if nobody uses it.

P.S. Does your blog not federate anymore?

@[email protected] yea I was about to ask, @[email protected]

AP.space has everything up until this one I think. @[email protected] isn't posting anymore.

@julian @silverpill @laurenshof

yeah, unfortunately I had to turn off federation for my wordpress blog. a persistent issue with how the cache interacts with ap makes the website show raw json when it gets popular. this has been a structural issue for a long time, and after it happened 4 times in a row on my most recent posts ive decided im done with it, because it was a major net negative on my distribution

@julian @silverpill @laurenshof its a big bummer tbh, i really wanted this to work. ive tried it for a long time, and i think its important as a writer about this ecosystem to dogfood the systems you write about, but it was simply not feasible anymore
@[email protected] have you tried debugging this with @[email protected]? It sounds like something that he'll have encountered and resolved before...
@julian @fediversereport you can disable conneg for user facing sites in the advanced settings! Happy to show it to you!
@pfefferle @julian @fediversereport 👏🏼👏🏼👏🏼👏🏼👏🏼
@silverpill @Connected Places The problem with the Mastodon client API is still that it's a Mastodon API. As in, geared towards only one Fediverse server application. In fact, as in, geared towards a very lack-lustre server application that lacks features which have been present in many other places in the Fediverse for years.

This means that you can use a whole lot of microblogging server applications with Mastodon clients. You can even use Friendica with some Mastodon clients. But then you're limited to the features which Mastodon has as well because the Mastodon client API doesn't support any features that Mastodon doesn't have. Why should it, after all?

At the end of the day, the Mastodon client API is designed and maintained by the Mastodon developers. It's them who decide what it can do and what it can't do. For one, they won't waste their time adding features to it that Mastodon itself doesn't have. Besides, if they did, they'd support Mastodon's direct competition and strengthen their advantages over Mastodon when they could throw rocks into their paths instead like they've always done.

This, by the way, is also one reason why both the developers of Hubzilla and the developer of (streams) and Forte refuse to implement the Mastodon client API. It simply wouldn't cover at least 90% of the features of these server applications, including features which you'll need all the time, everyday. That, and they don't want their software to end up at the mercy of Mastodon's developers and Mastodon's product politics by making it depend on Mastodon's technology. They'd rather have no native mobile app at all (and currently they do).

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Hubzilla #Streams #(streams) #Forte #MastodonAPI #MastodonClientAPI
Netzgemeinde/Hubzilla

@silverpill @fediversereport

It would probably be really good for the ecosystem if @Mastodon was explicit about reuse and reimplementation of its API.

In particular, a license or IP non-assertion pledge that says, as far as Mastodon is concerned, anyone can clone their API in a new implementation, regardless of code license, and Mastodon won't assert patent, trademark, copyright, or other rights against them.

@[email protected] can one even patent an API 🤔

@[email protected]

@julian @fediversereport it's an interesting question! IANAL, but my understanding is that patents are more for implementations than interfaces.

@julian @fediversereport

That said, if the interface contract defines some behaviour that requires a patented technique, you might not be able to implement the interface correctly without violating the patent.

@julian @fediversereport

For example, back when the compression used in GIF format was patented, you couldn't implement a `encodeGIF(filename)` interface correctly without violating the patent.

@julian @fediversereport

A non-assertion pledge by Mastodon makes it clear that third-party developers don't have to worry about that. "We think you can clone this API without violating any of our patents [especially because we don't hold any!], nor trademarks or other IP protections. We will not make it hard for you to implement this API freely."

There was a huge fight about this (in US courts, at least) between Google and Oracle. It was over copyrights, not patents, but I think it still applies.

The US Supreme Court ruled that it was fair use to implement someone else’s API.

It should be “settled law” but that doesn’t stop someone else from suing you anyway, or making life difficult (as Apple does) for 3rd party API implementators in other ways.

More info for those interested: https://www.google.com/search?q=oracle+java+api+lawsuit

@julian @evan @fediversereport

Bevor Sie zur Google Suche weitergehen

I think that’s why Mastodon’s pledge is important. They’re basically saying: you’re safe to use our API, no matter what we might be able to enforce legally.

It’s the right thing for them to do.

@julian @evan @fediversereport

@benpate @julian @fediversereport there are a few tools for this. One of the easiest would be publishing the API definition as a Report from the W3C Social Web Community Group. The Contributor License Agreement (CLA) for community groups covers most of what you need and has been well reviewed by expensive lawyers:

https://www.w3.org/community/about/process/cla/

W3C Community Contributor License Agreement (CLA) | Community and Business Groups

@fediversereport

This is a really nice read, and I would love to keep up with your stuff, but I don't do newsletters. Any chance you could implement an RSS feed, or did I just not see it?

@ryusei thanks! https://connectedplaces.online/rss i do have an rss feed, but could probably make it clear with a button that i do

@fediversereport

Ty. You'd be surprised at how many article sites made for Fedi don't have RSS. It's pretty wild to me.

@fediversereport I've read on the latest Trunk and Tidbits, published after this newsletter, that mastodon is joining the W3C, so maybe they are going to pick up their responsibilities in solving the issue?
Really liked the article btw, pretty clear even to a layman like myself