More reliably federating microblog responses

[julian@activitypub.space]

I encountered an odd federation issue where microblog responses do not get reliably federated to threadiverse instances.

Example:

1. A user on threadiA.instance makes a new post to a category/community on threadiB.instance.
2. threadiB.instance federates out the post to all followers per FEP 1b12 (so far so good.)
3. A second user on microblog.instance replies to that post and tags the user on threadiA.instance (the category/community is omitted — this is how microblogs address content)

In this scenario, only the post on threadiA.instance shows the microblog response. threadiB.instance, the party responsible for federating content to followers, is not aware of the new content. Likewise, any followers of threadiB.instance do not receive the content.

How do Piefed and Lemmy handle this scenario? I attempted to address this by having NodeBB federate out Announce(Create(Object)) directly to the group actor, and tested this against crust.piefed.social. Alas, while the activity was accepted, the activity seems to have been ignored.

cc rimu@piefed.social nutomic@lemmy.ml

[wjs018@crust.piefed.social]

Do you mean this post? I've not done too much with activitypub code, but it does look like the post made it to crust successfully.

[julian@activitypub.space]

Sort of. That's the post I made to test what would happen.

I created the post, which was sent over to crust, that worked fine.

Responses from microblogs (specifically this one and this second one) are addressed to my test instance, but crust is out of the loop because it isn't addressed.

bb tried to forward the activity back to crust but I think this isn't an accepted flow currently.

Edit: I made a third reply that specifically mentioned crust, and it does show up, as expected.

[uriel@x.keinpfusch.net]

@julian @rimu @nutomic well, thank you for your effort, to make nodeBB federation better.

[rimu@piefed.social]

I haven't looked into this particular case at all but Mastodon has a well known problem where people don't see all the replies in a thread. It's been broken like that since forever. This may be that.

[julian@activitypub.space]

Mastodon's issue with not seeing all the replies is actually only slightly related to this one.

So, yes — it's because Mastodon (and other similar microblogs) are not sending the replies everywhere, but FEP 1b12 is supposed to work around the need to do so. It does work, but only if the originating server is addressed.

So bear with me (this time I'll use real instances)...

• If rimu@piefed.social posts to !piefed_meta@piefed.social (same instance), and a Mastodon user responds, then piefed.social will federate the reply :heavy_check_mark:
• If rimu@piefed.social posts to !fedimemes@feddit.uk (different instance), and a Mastodon user responds, then only piefed.social is aware of the response, feddit.uk isn't, and cannot federate the reply out :x:

There would ideally need to be a way for third-party instances to keep the distributor up to date in cases where replies are made that unintentionally omit the distributor instance.

[trwnh@mastodon.social]

@julian @rimu yes the ideal solution is for mastodon to address / deliver to more inboxes (e.g. `context.inbox` or `context.attributedTo.inbox`) but the historical solution to work around that is stuff like salmon protocol https://en.wikipedia.org/wiki/Salmon_(protocol) or salmention https://indieweb.org/Salmention

the idea is simple -- when you receive a reply, you ping anyone upstream of you in the reply chain, and propagate:

- a posts.
- b replies to a.
- c replies to b. b pings a.
- d replies to c. c pings b. b pings a.

[trwnh@mastodon.social]

@julian @rimu of course, this does gets unwieldy for long reply chains, broken reply chains, etc etc... which is why people later moved to hub models like websub (formerly pubsubhubbub). but with the migration from ostatus to activitypub, we've made backwards progress on this issue because everyone just does direct delivery now without any propagation.

[julian@activitypub.space]

trwnh@mastodon.social ah... I didn't realise that "send the activity to all concerned parties" had a name — salmentation.

We already do that, especially since tagging and addressing aren't bound together like on Mastodon.

[trwnh@mastodon.social]

@julian activitypub uses a direct delivery model so it relies on you discovering "all concerned parties" at your own discretion -- there's a bit of the AP spec (6.1 client addressing) that calls out certain properties as worth checking for actors to suggest, like to/cc/audience but also attributedTo/actor, object, target, inReplyTo, tag, and you should probably add context to the list of those properties to check. you might also consider other properties as socially salient to keep in the loop.

[trwnh@mastodon.social]

@julian salmention (not salmentation, it's a portmanteau of salmon + mention, because salmon swim upstream) instead has you propagate mentions upward, so it's more than just direct delivery

[julian@activitypub.space]

trwnh@mastodon.social mm so in that case would you say that Mastodon is practicing salmention?

(Gosh, what part of speech is salmention anyway)

[trwnh@mastodon.social]

@julian no, mastodon doesn't use salmon anymore, not since a long time ago. they switched to websub then activitypub direct delivery.

on the indieweb side, salmention is an extension to webmention, where upon receiving a webmention where someone replied to you, you add that reply to your html then send a webmention up the reply chain to whoever you replied to, and they will fetch your html and find the new downstream reply, add it to *their* html, send a webmention upstream, and so on.