p3x.deMore reliably federating microblog responses
submitted by
edited
julianI encountered an odd federation issue where microblog responses do not get reliably federated to threadiverse instances.
Example:
- A user on
threadiA.instancemakes a new post to a category/community onthreadiB.instance. threadiB.instancefederates out the post to all followers per FEP 1b12 (so far so good.)- A second user on
microblog.instancereplies to that post and tags the user onthreadiA.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.
@julian @rimu @nutomic well, thank you for your effort, to make nodeBB federation better.
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.
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.
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.
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)…
!piefed_meta@piefed.social(same instance), and a Mastodon user responds, thenpiefed.socialwill federate the reply :heavy_check_mark:!fedimemes@feddit.uk(different instance), and a Mastodon user responds, then onlypiefed.socialis aware of the response,feddit.ukisn’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.
@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 en.wikipedia.org/wiki/Salmon_( or salmention 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.
@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.
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.