ActivityPub NuGet package

[kirkbrauer]

Is your feature request related to a problem? Please describe.
@benrick I saw that you mentioned on Mastodon that we want to make this modular so it can potentially replace some components of Mastodon over time.

We need to ensure that the project structure is setup in a way that enables this. I think that best way to start is to treat each subcomponent (e.g. ActivityPub, WebFinger, Mastodon Admin API, Mastodon API, etc.) as separate projects or solution folders so that each one could potentially be distributed as a NuGet package or library in the future.

Describe the solution you'd like
I think the ActivityPub project is a great place to start, as it provides a relatively small surface area to cover and would be great for project visibility if it is published as a NuGet package, potentially making it the first public implementation of ActivityPub available for .NET. Of course, in order to do this, this library must be designed from the start to be extensible and flexible enough to be used in non-Mastodon ActivityPub services. I'd love to hear any suggestions on how we could make this feasible.

Describe alternatives you've considered
Another option could be to start with ActivityPub, but spin it off into an entirely separate repo when it has matured enough. However, in this situation, since the Mastodon implementation would basically be a way to dogfood the implementation, a monorepo might be the best be for now.

[benrick]

I was thinking that we split along the lines of their executables. From my understanding, they've got two web endpoints, one for short interactions and one for longer. Then they've got a background process. Separating out the specs could make them reusable elsewhere, so there's value there as well. Don't want to get too ambitious though.

[kirkbrauer]

@benrick Ive got to read up on exactly how that do all that. For us, we could have multiple entry point applications that call extension methods on the ActivityPub library to configure their endpoints. I don't think we should limit anyone to have two executables because theoretically you could jam it all into a single one due to the performance benefits of .NET.

[benrick]

Yes, there are advantages in some platforms to splitting REST API from Socket connections, but I don't think there's as much benefit in dotnet.

…

Message ID: ***@***.***>

[benrick]

This is very related to #28 , but this is more related to creating the nuget package than the library code itself.

[edmistond]

I'm thinking the technique described here might be worth looking at. For simplicity's sake (and dotnet being rather faster than Ruby) we should initially keep it simple, but I think keeping in mind that we might want to split things out later is worth keeping in mind too.

[kirkbrauer]

@edmistond yes, that is exactly what my current work project looked like before we evolved it into having microservices. However, the microservices themselves have a pretty similar structure, just limited to a specific subdomain. I think the "service" model presented in this blog is pretty interesting. One disadvantage I did find with the modular monolith architecture was the tendency to have these huge services with tons of mixed-in database and business logic. That is one thing I really like about CQRS is the fact that your handlers pretty much follow the purest SOLID principles with SRP being supreme. Striking a balance between those two extremes will be key here.

[benrick]

Yeah, I think architecturally, there's likely not a scalability reason for us to build the same structure as the ruby project. The only reason would be to allow for a single project of ours to replace a single project of theirs. That's clearly a "nice to have" ability, not a requirement.

Yeah, let's keep it modular, so that we can do that later if we want. And we can have WebApp use both modules.