I’ve got Evan Prodromou blocked so I didn’t see https://tags.pub when it was announced. If you missed it too: it’s a service that listens on relays for hashtags, and boosts posts containing them, to followers following any given hashtag. To give hashtags much more reachability despite the horizon of federation.

I proposed something like this in the context of natural disaster response. Users could come to a consensus on what hashtag to use for, say, # HurricaneFoobar, and posts containing the hashtag could spread far and wide. But because I care about safety, I suggested that it needed selective outbound relaying, so that only posts containing a list of opted-in hashtags were sent to the relay. I see that managing what gets sent to relays is out of scope for tags.pub.

I also don’t see any mention on the github issue list about tags.pub being able to defederate known bad actors, so I guess there’s nothing stopping your posts from reaching poast and friends, due to ActivityPub’s nontransitive defederation behaviour.

User-to-user and user-to-instance blocks will similarly get laundered, so if you let tags.pub boost your posts you may find unwelcome people reading your posts.

So, this is a cool idea, it could be helpful, but it’s not ready yet IMO.

tags.pub

@futzle yet another "add a tag to your profile to control it" which automatically puts it in the bin as far as I'm concerned.

If you think your service needs something this, maybe work on some general profile extension method to allow user preference flagging for new/unknown application permissions first.

But no, I guess that's not cool and fun.

@mike @futzle I've seen some discussion in the last 24 hours. And, I have to admit I don't fully understand the protocols or rules for how these services work. But, I think I follow the gist of it.

On the surface it looks like a nice idea, but we should listen to experts who are saying there are some show-stopper problems. The big ones I see:
- It's open to abuse. As it stands, it appears to offer ways for bad actors to work-around protections for privacy/security.
- Opt-in by default is nonsense. Expecting users to add a bunch of opt-out hashtags to their profile is unworkable. Most regular users won't know what it means, won't be able to keep up to date, won't hear in time to react pre-emptively, and won't tolerate the additional overhead.
- Making this op-in by default on a server level only moves responsibility and workload onto instance admins. It makes the process even more opaque to users, and does little to ameliorate the underlying problems.
- This all assumes troublesome services respect these tags. Increasingly, we're seeing people cross boundaries and pay no regard to consent, for example, configuring their scrapers to ignore robots.txt. It's a difficult social problem, and there's no easy technical fix like "Simply add a hashtag to your profile".

@DamienWise @mike Yeah I donk know if “opt-in” or “opt-out” are even the right lens to look through. I do know that the software hasn’t considered how it can be used by bad actors, or it has and decided they were not important to delay release.