Besides the aforementioned Go-Fed, there’s another Go project FedBox with a C2S implementation, and I believe Bonfire (formerly CommonsPub) also has a C2S implementation.
Other than that I strongly recommend joining SocialHub and participate in the discussions there. Here’s a search for C2S:
The AndStatus client has a nice issue going of stuff they encountered implementing C2S from the client-side:
opened 11:45AM - 09 Dec 18 UTC
Compatibility
## Note on current state (as of 2020-05-24)
### Pleroma
Minimal "client to ser… ver" #ActivityPub implementation is available. It is tested at https://queer.hacktivis.me/AndStatus (that site has the latest Pleroma builds... some requests work at other Pleroma instances also!) and can:
* authenticate using OAuth 2.0, read the Actor's profile...
* read timelines, including notes with attached images;
* post notes, including attached images.
Latest #AndStatus version is here: https://github.com/andstatus/andstatus/issues/456
All critical Pleroma problems fixed as I test developer's builds at https://queer.hacktivis.me/ , so "Basic ActivityPub C2S implementation" could be considered completed.
### Mastodon
Mastodon (not AndStatus!) doesn't give you enough features to switch client connection to ActivityPub simply because Home timeline and posting via ActivityPub connection is not supported yet (corresponding pages give 404 Not found error).
But you can see your authenticated Actor's own posts on Mastodon servers and navigate to other Actors and their posts via them (you can see profiles of other Actors and see their posts...). You can even play with Mastodon as an "ActivityPub" type Social network in AndStatus today (I implemented a hack to log into Mastodon... not ActivityPub way unfortunately...)! But prepare to see empty Home timeline (due to above mentioned deficiency) and to be read-only there for now. Switch to "Sent" timeline and see your Actor's posts, see other actors and their posts similarly...
These new Mastodon improvements make me very optimistic about the future of ActivityPub in the client apps across all server platforms.
## Description
As defined at https://www.w3.org/TR/activitypub/ , ActivityPub provides two layers:
- A server to server federation protocol (so decentralized websites can share information)
- A client to server protocol (so users, including real-world users, bots, and other automated processes, can communicate with ActivityPub using their accounts on servers, from a phone or desktop or web application or whatever)
The "ActivityPub test suite" (worked in 2018-2019... [see on ActivityPub testing here](https://socialhub.activitypub.rocks/t/the-activitypub-test-suite/290/4)) site contained a test suite that checked basic features that are required for a client app to implement #ActivityPub.
Below is a list of corresponding steps/features (for the start, copied from that site), which we are implementing in AndStatus, together with their implementation status:
AndStatus UI changes:
- [x] Add "ActivityPub" type of Social network.
Client: Basic submission
- [x] MUST Client discovers the URL of a user's outbox from their profile
- [x] MUST Client submits activity by sending an HTTP post request to the outbox URL with the Content-Type of application/ld+json; profile="https://www.w3.org/ns/activitystreams"
- [x] MUST Client submission request body is either a single Activity or a single non-Activity Object
- [x] Client submission request is authenticated with the credentials of the user to whom the outbox belongs (this could be using an OAuth 2.0 bearer token or something else)
Currently we reused OAuth 2.0 implementation that works in AndStatus for Mastodon.
Client: Required properties
- [x] MUST Client provides the object property when submitting the following activity types to an outbox: Create, Update, Delete, Follow, Add, Remove, Like, Block, Undo.
- [ ] MUST Client provides the target property when submitting the following activity types to an outbox: Add, Remove.
Client: Add targets on reply
Reply to a post with multiple recipients.
- [x] SHOULD Before submitting a new activity or object, Client infers appropriate target audience by recursively looking at certain properties (e.g. `inReplyTo`, See Section 7), and adds these targets to the new submission's audience. (The client suggests audience targeting based on participants in the referenced thread)
- [x] SHOULD The client also limits depth of recursion used to gather targeting.
Client: Accept header on object retrieval
Trigger the client to retrieve some remote object.
- [x] MUST When retrieving objects, Client specifies an Accept header with the application/ld+json; profile="https://www.w3.org/ns/activitystreams" media type.
1 Like