@clayote @jsit Yeah, enough people are concerned about this that I unsubscribed tags.pub from the open registration relays it used:
https://socialwebfoundation.org/2026/06/28/unsubscribing-tags-pub-from-open-registration-relays/
@clayote @jsit Yeah, enough people are concerned about this that I unsubscribed tags.pub from the open registration relays it used:
https://socialwebfoundation.org/2026/06/28/unsubscribing-tags-pub-from-open-registration-relays/
@jsit relay.an.exchange and relay.uggs.io
The premise was that people who used open-registration relay servers wanted their content distributed widely (the relay part) and did not control which servers it went to (the open registration part).
That didn't match with people's expectations. In particular, unlike other relays, tags.pub gives notifications and lets people opt out. So, people who didn't even know their content was being shared to a relay suddenly did.
> tags.pub is now unsubscribed from the open registration relay servers it was previously using.
Hm I’m confused about this. What were these relay servers specifically and why was tags.pub using them? And how did this result in posts being visible in ways that surprised users?
@jsit I don't want to surprise people and I don't want to distribute content outside of people's comfort zone. tags.pub still has the ability to subscribe to another relay, but I probably won't use it unless I talk it through with the relay operator first.
@jsit yes.
@evan How was tags.pub boosting posts from people who hadn’t followed its follow back bot? Is relaying your instance with tags.pub equivalent to having all your users follow the follow back bot?
@jsit the open registration relays.
@evan So the people who were surprised to see this — was their instance relaying with tags.pub? Or was their instance relaying with another relay that connected to tags.pub?
How were their posts being boosted?
@jsit that's correct.
One important point: we use block-respecting boosts, so if someone on a server you blocked follows a tag that you posted with, your post won't be shared with them.
@evan OK so:
1. Instance admin connects to tags.pub relay
2. Instance user posts a hashtag
3. tags.pub sees the post and boosts it
4. The boost is sent to other, potentially objectionable instances through the public relays
Is that right?
That still seems “opt-in,” but through the actions of the instance admin rather than the user. *Somebody* related to the user/instance did take *some action* that resulted in these posts being sent to the relays.
tags.pub didn’t proactively go out and start scraping these posts without having been told about them.
@jsit thanks. I think you have it upside-down: we were receiving content from open registration relays, and boosting it. People didn't like that, so we stopped.
@evan Thanks. I think this is all important nuance that’s being lost. It seems like most people think this was a blind scraper.
At worst, the tags.pub documentation did not make clear enough that posts it saw — posts it was *specifically given permission to use* by instance admins or users — would be sent to relays, or which relays those were.
(That is, if I’m still understanding all this correctly, which I may not be.)
@jsit yes
@evan OK, so the people who were surprised to see their posts being boosted — that likely happened because their instance was subscribed to one of these public relays?
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.