Mastadon oauth provider?

[snarkipus]

I wasn't sure whether to put this in the Remark42 project or here - apologies if I guessed wrong.

Feature Request: Mastadon oath provider

• Mastadon Docs
• Mastodon API Docs

Given the recent massive migration from Twitter to Mastadon, having that option would be convenient. I did check, and unfortunately it's not listed in the auth0 marketplace.

Unfortunately, I know next to nothing about Go otherwise I'd take a whack myself.

Thoughts?

[paskal]

Oauth docs: https://docs.joinmastodon.org/methods/oauth/

In #137, @einarpersson wrote:

In the light of the exodus from Twitter to Mastodon maybe it could be worth doing a push and implementing Mastodon as a provider?

I have only done a little Go last couple of years but could take a look at it if it is of interest (and if I could get some help along the way if necessary).

Note: I come here from umputun/remark42#477

In umputun/remark42#477 @umputun wrote:

<...> I'm not sure either how Mastodon is "far more interesting and valuable than Twitter". The goal is to allow a typical internet user to log in and twitter is a much more popular platform. In this context "more interesting" doesn't really matter, but more popular is a thing.

My concern is the same, according to the information I found Mastodon got around a million registrations after the recent events versus 230 million daily active users of Twitter. I would propose getting back to that discussion once it becomes popular, for example, with 50 million daily active users.

[snarkipus]

As an alternative viewpoint, I would just put forward that the "migration" seems relatively concentrated in the tech community. If that community happens to be the target audience, a nominal DAU metric might not be as meaningful.

From my perspective, this request isn't meant to be mutually exclusive to a Twitter mechanism, just additive.

While I'm probably not the right person to do it, would you (@paskal @umputun) be open to a PR if someone was motivated enough to implement this feature?

[paskal]

There is no single Mastodon server to have authorisation work with, so your users would be a subset of their full auditory tied to one of the 73 servers they have listed. It's up to @umputun, but I would say "no" I wouldn't approve a PR with that functionality because I think it will complicate the code with little to no real-life utility.

The Mastodon concept is not working well with authentication in the way it's designed to work in this package now: we support a few big providers to make the user's experience smooth. The Mastodon approach would support an unknown number of providers by setting up an URL for the provider by the user or something among these lines. That's a more hacker-ish and specialised approach, and I don't think we intend to go in that direction.

Now even 50 million daily active users wouldn't convenience me, as we would need to change the architecture of this library and remark42 to support it properly, and it's unlikely someone not working on the project already would be able to make such changes in a way which would satisfy the current set of maintainers, and I would rather spend the same time working on improving the user experience rather than this.

I would keep this case in mind when working on multi-domain setup (umputun/remark42#1139) as it would require a change of the architecture of this package and it might be the case that multi-OAuth-servers setup will fit somewhere into it.

[snarkipus]

Ah, I see ... I wasn't aware of the underlying complexity of the request. It makes sense that the federated nature of Mastodon is an entirely different problem with regards to oath.

Thank you for looking into it - maybe there will be a more elegant solution upstream at some point that trivializes the implementation.

[umputun]

I have a hard time seeing how this is even supposed to work for such a distributed/federated system. One of the implementations I have found seems to default to https://mastodon.social/ but allows to set the custom auth URL. The similar thing most likely can be implemented here as well; however, I don't get how users will actually use it in practice. It may work only in case all the users who are logging into the system with auth library (for example, remark42) will have to be on the same mastadon server (default or custom). To me, such a fundamental limitation makes no sense.

Any alternative implementation should allow users (?) to set the endpoint for the auth somehow. This is a security nightmare and, in addition, not something we can easily add to the current auth library.

[moussaclarke]

There seems to be some related discussion about this topic here: mastodon/mastodon#4800

Not sure whether IndieAuth is something to consider?