Brendan Enrick  ðŸ’»ðŸŒ®Nov 13, 2022

Was anyone realistically thinking about creating a #dotnet implementation of #mastadon ?

I sorta started on it, but wasn't going to continue if there's a #Microsoft led effort.

If there's no existing project, I'll try to gather some collaborators and continue.

Who's interested in trying to get a #dotnet7 version going?

#OSS #foss

Please boost to help me find people or a project! Thanks! 

Show threadEliot Lash
@brendoneus I think the optimal way for new Mastodon client libraries to be written would be for someone to tackle https://github.com/mastodon/mastodon/issues/1404 to hook up a tool to automatically generate an #OpenAPI spec. Then tools like openapi-generator could be used to generate a client. Very little code would need to be written by hand, and it would benefit the creation of clients in any language supported by the generator. #MastoDev
API Documentation via Swagger / RAML / Others · Issue #1404 · mastodon/mastodon

In order to provide more accessible informations about REST API usage, it would be great to have an API specification in Swagger (http://swagger.io/) or RAML (http://raml.org/). Great job ^^

GitHub
Nov 13, 2022 at 10:58pmWeb
Show threadAndy PiperNov 13, 2022
@Eliot_L @brendoneus fwiw there are at least a couple of (recent) efforts to make an OpenAPI spec for the Mastodon API that I've found on GitHub to help to address that issue
Show threadEliot LashNov 13, 2022
@andypiper @brendoneus
That's good. Still, I think a handwritten OpenAPI spec is always going to be inferior to an autogenerated one because it will have to be manually kept up to date as the API evolves. Also, autogenerated specs make it easier to generate clients on demand that could consume new APIs exposed by mastodon forks.
Show threadlpachecoNov 14, 2022
@Eliot_L @andypiper @brendoneus shouldn’t it be the other way around? Manually write and update the OpenAPI spec and then automatically derive from that the stubs for the server and clients? Just like RPC, CORBA and WSDL?
Show threadEliot LashNov 14, 2022
@lpacheco @andypiper @brendoneus I think you can go about it either way. At my last job we used to use a framework plugin to generate our OpenAPI spec and it worked well, and it kept the same development flow as before we had a spec. You can go spec-first but I think it would require a bigger shift in development mindset that might be difficult for people to adapt to in an open source project.
Show threadMark Derricutt (talios)Nov 14, 2022
@andypiper @Eliot_L @brendoneus I was quite surprised it was a stock HTTP style API - I was kinda expecting some fancy modern day GraphQL type thing - but that doesn't really fit with ActivityStreams etc.
Show threadEliot LashNov 14, 2022
@talios @andypiper @brendoneus To be fair, keep in mind that development of Mastodon was started in 2016 by a single developer. What might seem obvious in hindsight might not have been as obvious then. And I think these things are more difficult to bolt on after-the-fact.
Show threadMark Derricutt (talios)Nov 14, 2022
@andypiper @brendoneus @Eliot_L true - I'm not even sure Graphql would be good either (subscriptions maybe) but you'd still need federation.
Show threadVictor HogemannNov 14, 2022

@Eliot_L @brendoneus perhaps we can start by implementing the ActivityPub specification, and then moving into cloning the Mastodon feature set?

https://www.w3.org/TR/activitypub

ActivityPub

The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.