The C2S part of ActivityPub isn't for everyone, and it's okay. It basically moves too much logic to the client. It prevents any semblance of a good UX because y

The C2S part of ActivityPub isn't for everyone, and it's okay. It basically moves too much logic to the client. It prevents any semblance of a good UX because you have everything — posts you would display in the feed, interactions with your content, etc — in the same inbox. You have to connect to many different domains to render something to the user, and you also have to have a sophisticated caching system on the client. Also good luck loading those full-size images over an EDGE connection. There are 2 kinds of ActivityPub servers. - The "dumb" one, that does minimal processing and simply stores JSON objects. Someone POSTs an activity to its inbox, the server does minimal required verification, stores it, and the client then queries it with GET. And does the reverse for the outbox. That's it. That's where c2s would work fine. - The "smart" one, that treats s2s ActivityPub like an API, comes with a built-in web interface, and stores everything in a way which makes sense for its particular presentation. That's the kind I'm making (Smithereen, it's on the list you linked, btw), and that's what Mastodon is. Implementing c2s in this kind of server is a major pain in the ass, and I won't. You'd have to throw away all your careful optimizations, synthesize ActivityPub objects out of things that never were ActivityPub objects in the first place, do horribly inefficient things to merge notifications and feed and other conceptually unrelated stuff from several different database tables just for the client to split them back apart... Doesn't make much sense. A domain-specific API is the only way to make a client for this kind of server.