Convener: Samir Al-Battran (@samir@m.fedica.com)

Participants who chose to record their names here:

• Emelia Smith (@thisismissem@hachyderm.io)
• Nik Clayton (@nikclayton@mastodon.social)
• Petri Kajander (@petri@mstdn.social)
• Jeff Sikes (@box464@mastodon.social)
• Ben Pate (@benpate@mastodon.social)
• Rimu Aktinson
• Marc Coquand

Agenda:

• Open discussion about how to help developers build tools for the Fediverse
• What kind of tools we need to onboard users to the Fediverse
• The need for bridge tools between legacy social media and the Fediverse to make the process easier for new users

Tags / links to resources / technology discussed, related to this session:

• https://datatracker.ietf.org/doc/html/rfc8414
• https://fedidevs.org
• https://gotosocial.org/ - “generic” ActvityPub server?
• https://funfedi.dev
• https://testcontainers.com/
• https://funfedi.dev/quickstart/

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

• If you’re using OAuth 2.0 for authorisation of your API, implement RFC 8414 for authorization server metadata: this gives client application a way to discover the capabilities / scopes available in your API, and allows narrowing of scopes when narrower scopes are available.
• Monetisation: we live in a capitalist society whether you like it or not, so money is a requirement for building things.

Better catalogs for developers to set the expectations for what’s recommended for what’s supported on each platform

User expectation is different, users coming from different platforms have different understanding of how the Fediverse works.

Turnkey solutions, you get a software that does one thing that you want, vs the Fediverse you have to make many choices, including picking the instance to start on. What is the user using the Fediverse for, then choosing the server is more important decision based on their interests. Users being on multiple platforms dilutes their presense and engagement on each individual platform. There needs to be a bridge for users to read all their content in one place

Following community instead of users.

Lack of centralized locations for user feedback to understand the user needs

App discovery: currently, the word of mouth. Having an “app store” to catalog the different apps and categorized by which platform they support would go a long way in helping with app discovery.

Having standard ActivityPub server to make the process of developing apps a lot easier because integrating the ActivityPub specs is very difficult, especially if this was not the core of the tools being built Fedidevs.org could be a good starting point to connect developers with similar technology skills

Discussions around testing and integration tests. Feditest can potentially help guidance in ingtest different implementations