More reliably federating microblog responses
Technical Discussion
13
Posts
5
Posters
46
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
-
@evan The groups (private groups, specifically) aspect is the reason why I brought up this topic at all — it was mostly for my understanding of the spec because to my knowledge, there weren't many collections being passed around in recipient fields; the only one being /follower, which isn't always resolvable.
The same issues would occur around private groups... a public group publishing something a /members collection would be addressable, but not a private group or one whose membership list is hidden.
All threadiverse softwares work around this by having the group itself be the distributor, and so you needn't address a members collection, you just need to ensure the group itself is addressed. The rest is implied (which HA! I bet @trwnh@mastodon.social has much to say about implied behaviour)
-
@silverpill @technical-discussion it's part of the outbox delivery algorithm, which bridges between c2s and s2s. the intention is that the outbox publishes activities via c2s, but then optionally delivers based on addressing properties via s2s
(this ends up having other issues in practice due to the lack of an envelope, but at least the intent of "relevant activities should trigger notifications for relevant entities" makes sense, per 6.1 clients "look at" some relevant props)
-
@silverpill @julian @technical-discussion
example: alice and bob on site.example each have followers collections, but alice can't see bob's followers. if alice addresses bob's followers collection, then alice's outbox can't deliver to bob's followers. alice must address bob, and bob can choose to forward to bob's followers (inbox forwarding)
if site.example has a collection of "local users" that alice can see, then alice can address it and alice's outbox can deliver to items
-
@silverpill @julian @technical-discussion
a "local collection" might still have access control on it.
(the interface being assumed throughout the AP spec is HTTP, or at least HTTP semantics; "with the user's credentials" in this case means using an Authorization header that lets the outbox access the collection. it's only confusing if you have a monolith with no boundaries between the outbox and anything else; in that case it'd be "lookup the collection in your db/store/etc")
-
@julian Yes, I think in practice expansion should be performed only for local collections.
the server MUST dereference the collection (with the user's credentials) is confusing, because it sounds like we're talking about remote collections here.
-
@julian well, sure, with a monolithic implementation, the client and the outbox and the delivery agent are all the same app. but they don't have to be. the model is that the client submits to the outbox, and the outbox could also talk to a separate delivery agent internally. it's all opaque from outside the outbox. your internal "outbox" is the code that serializes activities and sends them to the delivery workers.
-
@trwnh@mastodon.social said in Expanding collections on delivery:
> say you are an outbox and you get an activity to: some id. you deref the id and get some info. what do you do?Simple. My outboxes send a "not supported" HTTP tag 🤣
But I'm being facetious.
From a C2S standpoint I suppose that makes sense. Thanks.
-
@julian now remove the requirement. what do you do instead?
- if it has ldp:inbox, send an LDN
...and that's it. at no point were you ever told or required to do anything else, so your followers/audience/members/etc will never get the activity even if addressed, because the collection was never expanded.
