@dansup Go for it! It’s always seemed like a chicken-and-egg problem: nobody builds C2S servers because there’s no clients, and nobody builds clients because there’s no servers.
If you could get even one good client off the ground, it might bootstrap the whole C2S ecosystem.
And I, for one, will absolutely follow you there. I’d much rather build a solid C2S server instead of implement the Mastodon API.
@benpate@dansup I believe the primary reason there are no widely-used C2S user-facing clients (vs testing tools) is that the standard C2S API is not sufficient for a decent UX. If you compare the Mastodon client API with the AP C2S API, there's a significant disparity in features.
The list is longer than that, but it would need a long form post to cover all of what would be needed to have something similar to the Mastodon UX. This is easy to confirm if you compare the APIs.
It's possible to implement some of those features in a ad hoc way using AS2 data structures, but I believe many UI developers prefer an API that's standardized across server implementations.
@mariusor@jenniferplusplus@benpate I apologize that my response to your replies were hurtful. I actually felt like you were being a little dismissive about the larger issue of C2S deficiencies relative to the Mastodon API (and why C2S is not widely used) and that you were challenging me to defend my position on that issue. Showcasing experiments with C2S UIs would be a great topic for a different discussion thread. (I plan to dig into your implementation further when I have time.)
@steve you might be right, I might have been dismissive of your comments and I apologise if I started it. :D
I think my position stems from the impression that I get from comments similar to yours, that C2S is not really under consideration due to its perceived issues, and that the implementers automatically default to anything else. That's probably not the case always.
I'll try to keep that in check for the future and be less defensive. ☮️
The others are not really API related in my opinion. Every client should be able to implement them with some creativity on top of existing inbox/outboxes. (Nothing says a client can't have its own storage that remaps a/many inbox/outbox(es) content into a feed of some sort)
@mariusor@benpate@dansup I claim you can't build a C2S UI that has feature and UX parity with Mastodon UIs using your FEP and only client-side inbox/outbox processing. It's easy to prove me wrong. Just build it. 😉 That said, I don't know the Loops requirements, so maybe it's sufficient for that.
"...but I believe many UI developers prefer an API that's standardized across server implementations..."
This pretty much sums up the whole issue with ActivityPub.
Add to that: we're currently living in the world of "Mastodon-flavored-ActivityPub". If someone shipped a definitive C2S app, it could easily become the de-facto standard. I'll bet most devs (both client and server) would rather follow a well-defined API, and not have to greenfield their own design.
> If someone shipped a definitive C2S app @benpate the definitive C2S app would be something that looks like an email client because that is the immediate UI that can be mapped to the inbox/outbox model that @steve was decrying. Here's some C2S apps for you: https://releases.bruta.link, https://brutalinks.tech
Add comment