我们小型实例只能靠#中继#relay 才能和社区连接起来了，发现越是偏技术向的社区，就越容易出现在较小的实例里，可能是因为喜欢折腾技术的都会自己开一个。而那些大型实例的信息说实话确实有点out of domain了，看不太懂。
不知道这种中继方不方便被直接post出来，不过也没有在他们的网站里找到相关说明，希望没事吧。
目前我们加入了6个中继：
https://relay.nya.one/inbox
https://relay.isle.moe/inbox
https://relay.furca.top/inbox
https://relay.dragon-fly.club/inbox
https://relay.mstdn.one/inbox
https://relay.acg.mn/inbox
relay
没什么用但是造了个#relay 玩：
https://relay.pari.cafe/inbox
https://relay.pari.cafe/actor
前端明天做（）
歇了
I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
Curious what others think about this approach.