#Relay

Here's something really useful I've found.

One of the great things about the Fediverse is being able to follow hashtags.

But.

If someone puts up a post using that hashtag, and no-one on your instance follows that person or anyone who shares it, it won't appear in your feed.

This is particularly common if you're on a small or single-user instance.

Here's the solution.

First, follow @_followback

It will follow you back.

And then tags.pub bot then reshare all of your posts that use hashtags.

So if you do a post with the hashtag #Fediverse, then @fediverse will share your post.

Here's where the magic happens.

The tags.pub bot will do the same thing to everyone else who follows that followback account.

So if you follow @fediverse, then you'll get a feed of everyone who uses #Fediverse on the Fediverse.

And you'll see their posts even if no-one on your instance follows them.

And it works for all hashtags.

Just put the name of the hashtag, followed by @tags.pub

So @tech follows all posts using #tech, for example.

Or @news follows all posts using #news

#relay #relays #selfhosted #selfhosting #Mastodon #feditip #feditips #fedihelp

Here's something really useful I've found.

One of the great things about the Fediverse is being able to follow hashtags.

But.

If someone puts up a post using that hashtag, and no-one on your instance follows that person or anyone who shares it, it won't appear in your feed.

This is particularly common if you're on a small or single-user instance.

Here's the solution.

First, follow @_followback

It will follow you back.

And then tags.pub bot then reshare all of your posts that use hashtags.

So if you do a post with the hashtag #Fediverse, then @fediverse will share your post.

Here's where the magic happens.

The tags.pub bot will do the same thing to everyone else who follows that followback account.

So if you follow @fediverse, then you'll get a feed of everyone who uses #Fediverse on the Fediverse.

And you'll see their posts even if no-one on your instance follows them.

And it works for all hashtags.

Just put the name of the hashtag, followed by @tags.pub

So @tech follows all posts using #tech, for example.

Or @news follows all posts using #news

#relay #relays #selfhosted #selfhosting #Mastodon #feditip #feditips #fedihelp

Anyone have any nice #mastodon relays to recommend?

I have:
relay.mastodon.nu
relay.infosec.exchange
relay.toot.io

I would love a relay for mastodon.social and maybe mstdn.social

#mastodonrelay #relay

I'm thinking about setting up and running my own #relay #server for #mastodon and #pleroma as there seems to be a decreasing number of these that take in core and key traffic as times goes by. Resulting in fewer initial servers being maintained long term. The #fediverse and #ActivityPub deserve some love.

Tor's next #relay operator meetup will take place this Sunday, Feb 1st at FOSDEM '26 (@fosdem). We have no agenda to make time for your questions and topics. 📆 Find all details here: https://fosdem.org/2026/schedule/event/DRMMAB-tor_relay_operator_meetup/

Tor's next #relay operator meetup will take place this Sunday, Feb 1st at FOSDEM '26 (@fosdem). We have no agenda to make time for your questions and topics. 📆 Find all details here: https://fosdem.org/2026/schedule/event/DRMMAB-tor_relay_operator_meetup/

So I've noticed over the past day or so the FediBuzz Relay ( https://relay.fedi.buzz/ ) doesn't appear to have fetched any new posts.

Is this a me thing, or is this an issue for anyone else?

#Fedibuzz #relay #askFedi #selfhost #GoToSocial

So I've noticed over the past day or so the FediBuzz Relay ( https://relay.fedi.buzz/ ) doesn't appear to have fetched any new posts.

Is this a me thing, or is this an issue for anyone else?

#Fedibuzz #relay #askFedi #selfhost #GoToSocial

I know a lot of people on Fedi don’t like Nostr, but I just released the latest version of HAVEN. I feel especially proud of this one, not because it’s the best, cleanest of most exiciting code I’ve ever written (It isn't), but because it’s humbling to contribute to a project that Nostr Monitors shows as representing between 8 and 13% of all active Nostr relays. Real humans running infrastructure to enable social media. I dig it.

https://njump.me/nevent1qqstgahjq50e5xultcuq2grlje42txexv3fg28lawfmwr0swv9cl06cpypmhxue69uhksctkv4hzuctrvd5k7mre9eek7cmfv9kz76twvfhhsq3qa6we08n7zsv2na689whc9hykpq4q6sj3kaauk9c2dm8vj0adlajqxpqqqqqqz9eewyj

#Haven #Nostr #Relay #OpenSource

I know a lot of people on Fedi don’t like Nostr, but I just released the latest version of HAVEN. I feel especially proud of this one, not because it’s the best, cleanest of most exiciting code I’ve ever written (It isn't), but because it’s humbling to contribute to a project that Nostr Monitors shows as representing between 8 and 13% of all active Nostr relays. Real humans running infrastructure to enable social media. I dig it.

https://njump.me/nevent1qqstgahjq50e5xultcuq2grlje42txexv3fg28lawfmwr0swv9cl06cpypmhxue69uhksctkv4hzuctrvd5k7mre9eek7cmfv9kz76twvfhhsq3qa6we08n7zsv2na689whc9hykpq4q6sj3kaauk9c2dm8vj0adlajqxpqqqqqqz9eewyj

#Haven #Nostr #Relay #OpenSource

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

Excited to see @tor_ama host a session to answer all your burning questions about #Tor #relay operations.
https://www.reddit.com/r/TOR/comments/1krv4rt/tor_operators_ask_me_anything_13062025/

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

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

🚀 **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

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