More reliably federating microblog responses
Technical Discussion
13
Posts
5
Posters
47
Views
-
I 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.instanceshows the microblog response.threadiB.instance, the party responsible for federating content to followers, is not aware of the new content. Likewise, any followers ofthreadiB.instancedo 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 againstcrust.piefed.social. Alas, while the activity was accepted, the activity seems to have been ignored. - A user on
-
undefined nodebb@fosstodon.org shared this topic on
-
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.
-
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.
-
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)...
- If rimu@piefed.social posts to
!piefed_meta@piefed.social(same instance), and a Mastodon user responds, thenpiefed.socialwill federate the reply :heavy_check_mark: - If rimu@piefed.social posts to
!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.
- If rimu@piefed.social posts to
-
@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. -
@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.@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 @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.
-
@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.
-
@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.
@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 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
trwnh@mastodon.social mm so in that case would you say that Mastodon is practicing salmention?
(Gosh, what part of speech is salmention anyway)
-
@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.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
NodeBB now sneaks in a mention to the category/community, and this gets pre-filled in the Mastodon composer.
I tested it against piefed's crust instance, and the response from Mastodon to my post on NodeBB successfully made its way to crust for distribution :tada:
-
@julian Love to hear it ππΌππΌ
-
@bsky.brid.gy@bsky.brid.gy what! NodeBB has been sending out preview for quite awhile now, but there are exactly zero receivers. Mastodon doesn't support it.
I think with this change BridgyFed would be the first one.
-
@bsky.brid.gy oooh, thank you so much! Especially allowing the repky function to accounts that are not bridged! This is amazing!
-
@bsky.brid.gy keep up the great work!
-
@julian I really tried. Maybe should have reached for AI. I'll look into that web+ap:// scheme, thank you!
-
@travisfw@fosstodon.org I don't blame you for not reading through the whole thread.
Suffice to say I think there is merit in using web+ap:// scheme at the browser (and possibly app) level.
PWAs can register themselves as a handler of those types (web+), and on the web side there are tricks to allow for the opening of them in the PWA or falling back to browser https.
It's worth experimentation, I think.
-
@julian it's complicated, isn't it. I was focusing on the narrower case of one app calling a default (or system dialog to choose) app to handle the post, rather than even necessarily involving the browser. But could one solution (somewhere in that veritably long-ass thread) serve the whole matrix of calling web->web, web->app, app->app, and app->web?
