没什么用但是造了个#relay 玩：
https://relay.pari.cafe/inbox
https://relay.pari.cafe/actor
前端明天做（）
歇了
relay
New video! I'm hacking an automotive relay into my desoldering station to circumvent the long wiring activating the vacuum pump.
YouTube: https://youtu.be/bUXVoJblRGA
PeerTube: https://makertube.net/w/iic1m8JD1K3Mo1fxMvc7Dz
#ZD915 #DesolderingStation #Modification #Relay #Wiring #Mod
The #Fediverse is growing and we're welcoming more and more new single user instances but #federation can become challenging.
With #Relay instances, single user and smaller instances can quickly become federated and grow which is supported by many Fediverse applications like #snac #snac2 #Mastodon #Pleroma etc.
More information at:
https://fedi-relay.gyptazy.com
#fedi #community #fediworld #federated #opensource #fedirelay
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.