Well, for example pleroma but some things should be defined.
The authors (and people like me) tried to bring people together for this but it failed somehow.
Yet, problems exist for endpoints like media, a query language and some activities like blocking.
However see also
It would require meeting and talking together.
Ok I lacked the general view on the issue
As for the technicalities, they a re a bit too entrenched for me
Thanks anyway 🙏
I am building a c2s client myself. But for the browser.
So, I am stuck because of (a few) things lacking. This is frustrating.
So tell anybody that implementors must meet and talk more …
therer was a try to make c2s
but it didn't really worked out. The main problem was collecting reactions on post, comments and likes, and when they are from other instances, c2s spec requires to fetch them from sources and it takes ages. The only way to solve it is caching, I think, which is not described in spec, which means client non-compatible with activitypub
> when they are from other instances, c2s spec requires to fetch them from sources and it takes ages
That's how the web works in general though isn't it? A website has to load resources from other servers all the time. And yes there are a number of ways of making this less painful for the user, caching being one of them. C2S doesn't make matters much worse than Mastodon's client API does in my opinion.
this “load” of resource perhaps could be mitigated using something like redis as a backend, instead of postgress like almost everyone is doing. I mean, you can store JSON, HGET and MGET are allowing to retrieve everything by value…
some of this “load” issue is self-inflicted IMHO.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!