Connected Placesnew from me: FR#156 - Share Where?
on @Mastodon 's new Share button, the Mastodon API and protocol ownership
silverpillThe 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?
julian@[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...
Matthias Pfefferle@julian @fediversereport you can disable conneg for user facing sites in the advanced settings! Happy to show it to you!
Evan Prodromou
Jupiter Rowland@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
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
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 🤔
@julian @fediversereport it's an interesting question! IANAL, but my understanding is that patents are more for implementations than interfaces.
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.
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.
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."
Ben Pate 🤘🏻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
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.
@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: