Add BlueSky/Mastodon API Capabilities

[DrewMcArthur]

User story

As , I can <what?> so that <why?>

I noticed this announcement about the twitter API. I've been finding myself using the BlueSky platform more often than twitter, so I'd love to help implement a similar feature set to use them also/instead.

Best solution for this problem

What does the ideal solution look like?

Feature parity with the twitter api usage, simply posting to bluesky instead.

MVP

What should be possibly built to demonstrate the solution?
Maybe getting one "event" working end-to-end to auto-post on bluesky, but assuming the code is relatively abstracted, once the API is hooked up it shouldn't be too big of a leap to bridge over the existing features to use either API.

Metrics

What metrics will be used to measure impact?
What metrics do you have in place for the twitter api usage? probably the same as those.

Documentation

The goal of the documentation should be to make it easier for others to do this

1. Find how the twitter API works
2. If not sufficiently abstracted, write an interface that covers generic microblogging api usage
3. Figure out how to connect to a bluesky api
4. Implement the interface for bluesky.
5. Ensure that whatever triggers posting will post to any/all api connections that exist (user should be able to post to both platforms if they choose to)
6. Add UI components to enable creating this API connection.

This is something I'd love to contribute to, so if someone can point me in the right direction, help break this down into smaller tasks that would be easier to PR, I'd love to help with this :)

Triage Template (team only)

This template is for members of the team to triage for prioritisation. For more guidance see https://www.loom.com/share/369ab467fbc64dec848085d38ff57ca0:

P1 high frequency, high impact
P2 low frequency, high impact
P3 high frequency, low impact
P4 low frequency, low impact

Examples of high impact - a problem affects users during an essential process (expenses and payments > onboarding and registration > contributing) with no workaround.

High frequency - >10% of users affected (measured as a proportion of total potential users for this case).

Tasks

Beta Give feedback

1. Create MicrobloggingApiInterface

[DrewMcArthur]

I think I see the twitter api hooks here: opencollective-api/server/lib/twitter.ts, but that only appears to be used here, in scripts/tweet.ts, so maybe that's not right.

I think this could be broken up into the following PRs:

• Create a MicrobloggingApiInterface, and put the twitter api behind that.

Then, for each additional microblogging platform, e.g. bluesky/atproto or mastodon/activitypub

• Implement the MicrobloggingApiInterface
• Add UI components for connecting that account

[Betree]

Hi @DrewMcArthur, thanks for proposing your help!

We've started an internal discussion to determine whether this is something we're ready to invest in and maintain in the future. We'll inform you by posting on this issue when a consensus is reached.

[DrewMcArthur]

Awesome, thanks @Betree! I'll have a break in my academic schedule after next week until late January, so I'd love to be able to work on writing that interface then. I think I could tackle this with minimal support, outside of some small pointers & best practices here and there. I'll look forward to the update :)

[Betree]

Hi @DrewMcArthur, after consulting with the rest of the team, here's our position :

1. We want to integrate more with federated/decentralized/libre social networks. There's no reason for us to support Twitter only, except it was already there for historical reasons. The way we want to do it is not fully clear for now. There are discussions about implementing ActivityPub to make Open Collective a federated platform, and it might impact how we think about these integration issues.
2. There is an alternative today: since we expose webhooks, the need described in this issue can already be fulfilled using custom integrations or 3rd party services like N8n or Zapier.
3. As of today, the team doesn't feel we have the capacity to assist, review, and follow up on implementing this issue and maintaining it in the future.

If you're still willing to implement this feature, another option is to develop it as an external app (using OAuth). The impact won't be the same - we don't yet have a "Marketplace" on the website where apps can be publicly listed.

We'll keep this issue open because it's likely that we'll reconsider adding it to the codebase at some point.