Normalization of mention spam in the fediverse

julian

On the eve of me working on federating out mentions from NodeBB, I've started thinking again about how they're used in the fediverse via Mastodon. I've gone on at length about this before, but it bears repeating again:

I think it's absolutely bonkers that replies dogpile mentions just so participants stay in the loop.

It has the unfortunate side-effect of looping people in to a conversation merely because they were mentioned. The even worse side-effect is that if you don't follow along with this convention, the people who are left out simply aren't notified and drop from the conversation. Awful UX!

Mastodon does it because other than a follow, like, or a boost, a mention is the only other way to land a Note into your notifications. So you'll see exchanges where multiple users all start (or end) their posts with a string of mentions as they're having an ad-hoc group conversation.

@foobarbaz @barbaz @quux did you hear about the latest news out of...

This doesn't happen in forums, mostly because if you interact with a topic, the baseline expectation is that you're subscribed to that topic in the future. Replies get sent to your notification box or other dedicated UI widget, and you can easily keep track of your long-running conversations.

In NodeBB, a response within a topic causes the user to automatically follow the topic. Future actions in that topic notify all followers. We collapse related notifications to limit noise, though that is an oft-cited concern against throwing things in a notification inbox.

It sounds like I'm hating on Mastodon, and it's easy for me to do because they're the big fish in the fedi sea, but I still feel this isn't something that needs to exist. Mastodon could potentially create their own dedicated list for "conversations you've interacted with".

I will admit, though, that it is a lot easier to present that data when reply chains are grouped into topics

Blake Leonard

@julian To be honest, I think it might be worth breaking compatibility with Mastodon, although if you can get it to work well with Lemmy and/or Kbin that would be ideal for this. Mastodon deviates from the spec in a lot of key ways, so as long as you keep closer than it to the spec, you get to point out that no, you're doing it right, it's Mastodon that's doing it wrong or missing this thing.

Julian Lam

@blake I plan to do just that.

Playing along with the mention-spam only legitimizes this behaviour. I'm not meaning to take a hardline stance against it or anything, but just feel that there are better approaches.

Even something like "shadow mentioning" all participants in a thread via ActivityPub wouldn't work because not only is it shady it's again legitimizing mention spam, hah!

Unrelatedly, I love how the topic title propagated over to the Iceshrimp instance.

Andy Piper (LOL)

@julian this is something that is the Mastodon roadmap - mention grouping, I mean. Some of the third-party clients already do this by default, or optionally.

Jon Pincus

It's worth looking at what Friendica approaches it. They have a Facebook-like post/reply model, but it also seems to work okay with Mastodon. Agreed that the current Mastodon approach is unfortunate.

Scott Starkey, but spooky

@julian You are absolutely not wrong!

Jupiter Rowland

@julian Mastodon doesn't really have a conversation model at all. It doesn't know what a conversation is because such a thing doesn't exist on Twitter either. The same goes for Pleroma, Misskey and all their forks.

Threads on these projects are loosely tied together from single posts. Any post, regardless of whether it's a reply or not, only goes out to the followers of the poster plus whomever the post mentions.

If Alice posts something, it's her followers and the users mentioned in the post. who are notified about it.

If Bob replies to Alice's post, it's his followers and the users whom he mentions who are notified about it. Alice's followers are not notified unless Bob mentions them one by one. In fact, not even Alice would be notified if Bob didn't mention her.

As far as I know, before nodeBB appeared, there were only a few Fediverse projects that had a concept of conversations:

Mistpark/Friendika/Friendica
Free Friendika (fork of Friendika; defunct)
Friendica Red/Red/the Red Matrix/Hubzilla
Osada (first a fork of Hubzilla, then a fork of Zap, then probably a fork of Zap again; all discontinued)
Zap (fork of the first Osada; discontinued)
Mistpark 2020 (probably fork of Zap or the third Osada; discontinued)
Redmatrix 2020 (probably fork of Zap, the third Osada or Mistpark 2020; discontinued)
Roadhouse (fork of the third Osada/Mistpark 2020/Redmatrix 2020; discontinued)
the Streams repository (fork of Roadhouse)

With the sole exception of Free Friendika which was forked due to licensing, these were all created by one and the same guy: @Mike Macgirvin

️ who still maintains and develops (streams). He is currently reworking (streams)' conversation model to become more compatible with the ActivityPub standard ((streams) itself isn't based on ActivityPub, but on Nomad). But it's difficult to make it understandable for something like Mastodon that only understands the very basics of a hopelessly outdated version of the ActivityPub standard and substitutes everything else with non-standard, home-brew hacks.

What is now Friendica was not designed as an alternative to Twitter. It was designed as an alternative to Facebook. And so it as a thread structure like Facebook or Tumblr or a blog: exactly one post plus many comments.

Again, if Alice posts something, it's her followers and the users mentioned in the post. who are notified about it.

But if Bob replies to Alice's post, it's a comment on Alice's post and not a stand-alone post itself. Next to whomever Bob mentions, it's Alice and Alice's followers who are notified. Bob's followers are not notified unless they're mentioned because it's none of their business what Bob comments on Alice's post. And Alice is notified even without a mention, as are her followers.

If Carol comments on Bob's comment, apart from whomever Carol mentions, it's Alice, Alice's followers and Bob who are notified. Again, Carol does not have to mention Alice or Alice's followers or Bob. And again, Carol's followers are not notified, neither are Bob's followers.

By sending the post, Alice automatically follows the thread which this post starts. Thus, she receives special notifications for each comment. Likewise, by commenting, both Bob and Carol subscribe to the thread, follow it and receive special notifications for each new comment, regardless of what within the thread is commented on.

Also, Alice, Bob and Carol have the thread in their respective streams anyway. So even if they unsubscribe from the thread, they still get the same notifications for comments as they get for comments on posts from whomever they follow.

By the way, it's only what Friendica, Hubzilla and (streams) perceive as posts that is drawn into a stream and listed as unread. So even if you follow Bob or Carol, but not Alice, Bob's and Carol's comments don't show up in your stream.

Lastly, it's Alice who owns the whole thread. Including all comments. At least on Hubzilla and (streams), Alice can moderate her own thread and delete posts from it; unfortunately, that deletion is not forwarded to originally ActivityPub-based projects such as Mastodon which don't understand such measures. And self-moderation on (streams) can go even further than on Hubzilla.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Friendica #Hubzilla #Streams #(streams)

julian

Thank you for the succinct writeup. It seems to line up with my expectations of how content is federated out from the Mastodon POV.

One thing I should explicitly point out is that Mastodon does have a concept of conversations. It is outside of the AP standard, but they do send a conversation property along with their note.

One surmises you could use it to link together content into usable threads but it was bespoke to Mastodon and I decided that relying on it would be unwise.

Currently individual posts on NodeBB do not report a context via ActivityPub (that'd probably be the topic identifier). They will eventually report audience (category identifier) so as to be in-line with FEP 1b12.

We use our own method of determining a topic ID based on whether the root node has been seen before but likely this wouldn't conflict with whatever consensus is reached regarding post contexts.

soaproot

@julian I wish Mastodon had better support for following threads. And I'm not the only one, for example see https://github.com/mastodon/mastodon/issues/23702 (and I think maybe some other issues in that github project too). I don't know if this gives you an answer for what NodeBB should do, but you are far from the first person to be asking questions on the subject of replies and threaded conversations.

julian

@[email protected] Thanks for the reply, I'm glad these discussions are taking place.

I independently settled on the approach advocated in that link you shared — given any Note ID, I traverse up the chain until I find the root, and that becomes the original topic post.

If there were some sort of standard for defining a topic ID, I would use that, although I think at present there are no consistent applications.

FEP-400e explicitly mentions forum topics, but I am not entirely certain whether this is something I'd want to follow as topic themselves don't have an "owner".