More reliably federating microblog responses
Technical Discussion
13
Posts
5
Posters
39
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
-
thisismissem hah yeah, I was doing dinnertime and didn't have the bandwidth to answer, one sec 🙂
-
silverpill@mitra.social mm I may have been premature regarding phasing out Announce(Delete).
nutomic@lemmy.ml made it clear that it wasn't going anywhere, and I will remove the "backwards compatibility" label from it in my draft.
-
I'll need a bit more than upvotes here
-
julian since you asked!
-
Hi all,
I've recently had some questions about what tool to use for note taking during taskforce meetings, personally I've been using hedgedoc from social.coop, but it's a private instance and you need an invited account. I've also used hackmd in the past. I've seen other taskforces use Google Docs, and I think one even used CryptPad.
Officially the W3C way of scribing meetings is via an IRC bot: https://www.w3.org/2006/tools/wiki/WebExBestPractices#Meeting_Record_(Minutes)
However, this isn't necessarily the most approachable to many members of the Social Web CG.
At the end of the day, the most important part is that taskforce leads capture meeting notes and preserve them, e.g., in the taskforce github repository on swicg or swicg/meetings. (I could also automate taskforce to swicg/meetings sync)
I currently own the socialcg.org and swicg.org domains, and I'd be happy to spin up a hedgedoc server on a subdomain there that taskforce leads can use for creating and taking meeting notes. However, to do this I'd need to figure out some funding for it (not particularly a lot, but some amount of money — somewhere in the range of €60-180 a year, I'd guess).
What tooling would you like to use for taking meeting notes? Would having a hedgedoc install for the CG be valuable?
(I am also in the process of hosting the Activity Summary Bot on a VPS, which produces these emails to the mailing list weekly: https://lists.w3.org/Archives/Public/public-swicg/2025Oct/0028.html — it was running on github actions but kept failing there due to GitHub restrictions, so I've had a VPS on a server sponsored by one of the large fediverse hosts to replace GitHub Actions for more reliable delivery)
Yours,
Emelia
-
@nutomic if you're implying that I should have spoken sooner, I'm pretty sure I did. I remember exchanging messages with both you and @dessalines when you started lemmy...
I have no specific memory about this topic, but to my recollection lemmy federation was pushed as fait-accomplit at one point without me seeing any previous research on your guys part.
-
@julian This sounds like an implementation detail to me. Some fedi platforms delete a child object when its parent is deleted, others don't.
If you want to make the removal of a subtree explicit, I'd recommend a Remove where object is an array (similar to what @mariusor suggested):
Remove(object: Note[], target: Context)This also helps with migrating away from Announce(Delete). I saw your FEP draft, will provide more feedback once I read it in full.
-
I fail to see what the fundamental difference is. If you are unsure about the target with Delete/Object, you can also resolve the context of Object to figure that out. Anyway the instance where the Group is hosted is always the authority, so the state there is the correct one.
Actually I would rather think of this from a different perspective, namely from the perspective of the mod who clicks the remove button. That would happen when a post is offtopic or violates the rules, and then the intent clearly is to remove all replies as they are not useful. It wouldnt make sense to leave up a single reply two levels deep just because it wasnt included in the context for some reason.
