I agree with @Gargron
about ActivityPub Client-to-Server API putting a lot of work onto the front-end, but at the same time that would allow more functionality (especially to do with supporting other types of activities and objects) and innovation to be focused on the client side, which would make identity a bit less messy (people could follow me once and get my toots, video, photos, etc, and vice versa, I could have one unified timeline mixing different kinds of content). The answer to "what's a good alternative to Facebook" isn't one platform like Hubzilla, it's an ecosystem of truly interoperable apps. We've got the right tools, we just need to tie them together in useful and non-competitive ways.
A few of us are working on adapting the Client to Server API into a GraphQL schema, which I think will provide the best of both worlds, lots of flexibility for client apps while being easy to implement as the server can still to most of the ActivityPub/ActivityStreams heavy lifting.
Some of our immediate goals for #CommonsPub
- Federation that works for any type of activity, object, and field (including extensions). Side effects could be controlled by a sort of plug-in system similar to WordPress (including just bridging to an existing non-Elixir app's API). #MoodleNet
will be a plug-in that extends #CommonsPub
- GraphQL as the primary client API, with some generic very flexible and powerful (but complex) endpoints, and plug-ins being able to add endpoints to make things easier for their specific use case or client app.
- Support for Groups.
- Users can have several Actors. Actors can have relationships (and capabilities /permission) with each other.
- More kinds of Actors, including Group and Organization.
Some goals we don't have right now (put would accept merge requests for) :
- ActivityPub C2S API
- Mastodon API