Running a single user (or small) instance in the Fediverse? Relay instances acting as a spreading proxy can help you to find your content and also to make your posts visible to others - and you can easily join with #Mastodon, #snac and many other ones!

The https://fedi-relay.gyptazy.com relay is mostly for tech related content and just got updates to the manpageblog design.

#mastodon #snac #relay #activitypub #fediverse #federated #bsd #devops #proxmox #ipv6 #opensource #community #debian #python

Running a single user (or small) instance in the Fediverse? Relay instances acting as a spreading proxy can help you to find your content and also to make your posts visible to others - and you can easily join with #Mastodon, #snac and many other ones!

The https://fedi-relay.gyptazy.com relay is mostly for tech related content and just got updates to the manpageblog design.

#mastodon #snac #relay #activitypub #fediverse #federated #bsd #devops #proxmox #ipv6 #opensource #community #debian #python

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.

#fedidev

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.

#fedidev

I might look into getting onto a relay now that I have my own instance. Any recommendations?

#ActivityPub #Relay #Fediverse

My relay instance for the #Fediverse evolved in a great way - more than 120 instances are already connected to boost your posts across the Fediverse.

If you're running #snac / #snac2, #Mastodon, #Pleroma or any other software on the #ActivityPub protocol that supports relay instances - feel free to join the relay! Hopefully #GoToSocial also supports relay services soon! Of course #IPv6 is supported (for IPV6 only instances).

https://fedi-relay.gyptazy.com

#opensource #relay #ipv6 #community #homelab