#Relay

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'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'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'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'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'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'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'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'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'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'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'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

Join us tomorrow for another #Tor #relay operator meetup: 🟢 May 10 @ 18.00 UTC.
✏️ Check out the agenda and add your topics: https://forum.torproject.org/t/tor-relays-next-tor-relay-operator-meetup-saturday-may-10th-1800-utc/18771

Join us tomorrow for another #Tor #relay operator meetup: 🟢 May 10 @ 18.00 UTC.
✏️ Check out the agenda and add your topics: https://forum.torproject.org/t/tor-relays-next-tor-relay-operator-meetup-saturday-may-10th-1800-utc/18771

📆It's time for another #Tor #relay operator meetup: Mark your calendars for May 10 @ 18.00 UTC. 🗒️ Find the agenda here and add your topics: https://forum.torproject.org/t/tor-relays-next-tor-relay-operator-meetup-saturday-may-10th-1800-utc/18771

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

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

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

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

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

A topical or community Fediverse Relays — ex: a Paleogenetics relay server, or an animal photography relay server, or a company focused relay server, etc —

Would be similar to the old PlanetPlanet river-of-news feed-reader blogs.

https://web.archive.org/web/20171029175722/http://www.planetplanet.org/

RE: https://mastodon.social/@reiver/114044648006460577

#DeSo #FediDev #FediDevs #FediRelay #Fediverse #FediverseRelay #PlanetPlanet #Relay

A topical or community Fediverse Relays could be very useful (in addition to generic ones).

Ex: a Paleogenetics relay server, or an animal photography relay server, or a company focused relay server, etc

Especially for single-user, community, team, organization, themed, etc server instances

It would also help save storage space on server instances, by the relay being selective in what it shares.

#DeSo #FediDev #FediDevs #FediRelay #Fediverse #FediverseRelay #Relay

The #Fediverse is free, free of censorship, federated and full of great content!

Also the Fediverse - instance admins randomly blocking whole instances just because a single user feels offended of a post by a single instance user. Blocking whole instances is just a finger snip away, censoring unwanted content and parenting users of instances. Defederating just because of… ok no clue :) Using content warner for any possible content just to annoy or aeemmm make it more interesting to other users. Thanks, I’m old enough :) Seeing all the spam because it’s just a thing of 5 minutes automation to create randomly new instances on different domains (or subdomains from dynamic-ip hosters) and to fill the network with automated content.

Sometimes, pros can easily switch into cons… luckily more and more single user instances are raising up for exactly this reasons and can still easily federate by using relays…

#networking #activitypub #mastodon #fediverse #gotosocial #snac #snac2 #opensource #community #socialmedia #relay #abuse #moderation

The #Fediverse is free, free of censorship, federated and full of great content!

Also the Fediverse - instance admins randomly blocking whole instances just because a single user feels offended of a post by a single instance user. Blocking whole instances is just a finger snip away, censoring unwanted content and parenting users of instances. Defederating just because of… ok no clue :) Using content warner for any possible content just to annoy or aeemmm make it more interesting to other users. Thanks, I’m old enough :) Seeing all the spam because it’s just a thing of 5 minutes automation to create randomly new instances on different domains (or subdomains from dynamic-ip hosters) and to fill the network with automated content.

Sometimes, pros can easily switch into cons… luckily more and more single user instances are raising up for exactly this reasons and can still easily federate by using relays…

#networking #activitypub #mastodon #fediverse #gotosocial #snac #snac2 #opensource #community #socialmedia #relay #abuse #moderation

🚀 **Big Upgrade for the relay.uggs.io Relay!** 🐘⚡

Good news, Mastodon admins! Our relay just got a **massive performance boost** to keep your federation fast & smooth! 💨

🔥 **What’s new?**
✅ **💾 32GB RAM & 16 cores** – More power, better performance!
✅ **⚡ SSD-powered** – Lightning-fast response times.
✅ **🛢️ PostgreSQL & Redis** – Better backend, faster caching!
✅ **🚀 Caddy with HTTP/3** – Future-proof & blazing fast!
✅ **🔓 Open registrations** – New instances welcome!
✅ **⚠️ Inactives get removed** – High-quality relaying only!

➡️ Join now: https://relay.uggs.io/

💡 Running a Mastodon instance? Connect now & level up your federation! 🌍
📩 Need help? Ping [@chris](https://social.uggs.io/@chris)!

#Mastodon #Fediverse #ActivityPub #MastoAdmin #FediRelay #Decentralized #SelfHosting #OpenSource #Privacy #MastodonRelay #ServerUpgrade #relay #relayserver #MastoAdmin #selfhosting #selfhosted

🚀 **Big Upgrade for the relay.uggs.io Relay!** 🐘⚡

Good news, Mastodon admins! Our relay just got a **massive performance boost** to keep your federation fast & smooth! 💨

🔥 **What’s new?**
✅ **💾 32GB RAM & 16 cores** – More power, better performance!
✅ **⚡ SSD-powered** – Lightning-fast response times.
✅ **🛢️ PostgreSQL & Redis** – Better backend, faster caching!
✅ **🚀 Caddy with HTTP/3** – Future-proof & blazing fast!
✅ **🔓 Open registrations** – New instances welcome!
✅ **⚠️ Inactives get removed** – High-quality relaying only!

➡️ Join now: https://relay.uggs.io/

💡 Running a Mastodon instance? Connect now & level up your federation! 🌍
📩 Need help? Ping [@chris](https://social.uggs.io/@chris)!

#Mastodon #Fediverse #ActivityPub #MastoAdmin #FediRelay #Decentralized #SelfHosting #OpenSource #Privacy #MastodonRelay #ServerUpgrade #relay #relayserver #MastoAdmin #selfhosting #selfhosted

#HowTo install & run #snac on #FreeBSD - run your own #ActivityPub instance in the #Fediverse!

In the last days I often got asked about #snac / #snac2 as an alternative to #Mastodon and I can highly recommend it! I few months ago, I already wrote a HowTo about setting snac up on a FreeBSD instance - might be worth to share again :) if you’re using snac, you might also want to use my relay service at https://fedi-relay.gyptazy.com to make your posts more visible in the Fediworld.

#opensource #fediverse #fediworld #alternatives #community #FreeBSD #RUNBSD #BoxyBSD #activitypub #mastodon #relay #community #federated

https://gyptazy.com/install-snac2-on-freebsd-an-activitypub-instance-for-the-fediverse/

#HowTo install & run #snac on #FreeBSD - run your own #ActivityPub instance in the #Fediverse!

In the last days I often got asked about #snac / #snac2 as an alternative to #Mastodon and I can highly recommend it! I few months ago, I already wrote a HowTo about setting snac up on a FreeBSD instance - might be worth to share again :) if you’re using snac, you might also want to use my relay service at https://fedi-relay.gyptazy.com to make your posts more visible in the Fediworld.

#opensource #fediverse #fediworld #alternatives #community #FreeBSD #RUNBSD #BoxyBSD #activitypub #mastodon #relay #community #federated

https://gyptazy.com/install-snac2-on-freebsd-an-activitypub-instance-for-the-fediverse/

I just started my Fediverse relay service which is a powerful way to support smaller instances, especially single-user setups, by boosting their visibility and enabling them to connect more easily with the wider network.

You can find more information at:
https://fedi-relay.gyptazy.com

The instance is reachable on IPv4 and IPv6.

#fediverse #opensource #relay #devops #mastodon #pleroma #gotosocial #ipv6

I just started my Fediverse relay service which is a powerful way to support smaller instances, especially single-user setups, by boosting their visibility and enabling them to connect more easily with the wider network.

You can find more information at:
https://fedi-relay.gyptazy.com

The instance is reachable on IPv4 and IPv6.

#fediverse #opensource #relay #devops #mastodon #pleroma #gotosocial #ipv6

It appears that my Mastodon server relay connection to infosec.exchange is no longer functional... no content being delivered for a few days. I know that site has been experiencing problems of various kinds based on posts from @jerry, as operating large Fediverse instances is challenging.

Any suggestions for relays I should I use instead? I'm not looking for a 'whole Fediverse' feed (like mastodon.social), but sites that carry a wide selection of tech traffic would be useful.

#Fediverse #Relay

Here is my xmas present to all the #Mastoadmin of small instances: the new #FediBuzz #relay! https://relay.fedi.buzz/

After being off the the #fediverse for some time I'm struck with how many reposting and adbots there are. Or maybe it's just me going overboard when subscribing to #relay servers?

In any case, it's like the smog of the industrial revolution - It's a very noticeable sign of progression and people jumping on to the steam wagon, but we could still do without it.

Wir haben soeben ein #ActivityPub #Relay für das #Fediverse erstellt: https://relay.kanoa.de

Alle #MastoAdmin|s aus dem deutschen Raum sind herzlich willkommen :mastodance:

We've just moved and upgraded our Scandinavian relay.

If you're not subscribed yet you're welcome to do so 🙂

https://relay.mastodon.nu/

(Please let us know if you encounter any issues)

#mastoadmin #relay #mastodonnu