More reliably federating microblog responses
Technical Discussion
13
Posts
5
Posters
3
Views
-
-
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
-
mradcliffe@nokoto.org apart from the technical details, this approach also is extremely easy to explain to laypeople.
"Follow who this person follows" :heavy_check_mark:
-
I think that my comment on GitHub that Group Actors acting as Starter Packs really comes from how I approach my social network.
I rely on my friends and peers to discover new topics and meet new people.
Friends and peers as Starter Packs work great on a small microblog instance like Mastodon, Misskey, or Sharkey because the federated feed/bubble lists topics written by the amazing people that they are following. This approach is ideal for small instances, but flagship, large and relayed instances make it much harder as the topics are much too diverse.
When a small instance I was part of shutdown, I was really at a loss because I relied heavily on that feature without following people myself i.e. I'm lazy. And so to figure out who to follow, I went back to my peers’ and friends’ following Collection. Note to self, I need to remember to continually discover more people from people I follow now that I am on my own single-actor instance.
This is why I come to the conclusion that people are Starter Packs. Or in other words, Actors are Starter Packs. And more specifically, anyone or thing with a publicly-available following Collection is a Starter Pack.
But making a public directory of everyone is not a good idea and discoverability is hard.
Starter Packs should be (Group) Actors because
Consent is built-in with the Follow Accept/Reject.People that want to explicitly allow followers already have this option.Implementations should use Mastodon’s discoverability property to also limit who a Starter Pack may follow.Revoking consent is mostly built-in with either Remove Follow, Block Undo, or Reject Follow.Discoverability is built-in:The following Collection is available.Group Actors can make posts when their following Collection is updated.Amazing UX designers can make the following Collection more usable in their software.Starter Packs that are used in bad faith can be defederated like any other bad faith Actor or instance.The barrier to implementation is much lower than tacking on anything new to the specification.
-
Currently I am grappling with the specifics behind how to federate out the deletion of a topic in a category (or in ForumWG terms, the deletion of a context from an audience.)
For those unaware, a context is essentially an OrderedCollection containing all objects within its purview.
Deleting a note or other object is easy. If you are same-origin as the object, you Delete(Object), done.
Deleting a context is more difficult... you can't rely on other implementors to store references to your contexts, since it is essentially meaningless to them. Furthermore, if a context is deleted, then when a Delete(Context) is federated out, receivers will have no idea what they're seeing, will try to retrieve the object, and find a 404. So it doesn't even work at all.
Even worse, you can't really delete other peoples' contexts (or for that matter, their content) since you're not same-origin.
Finally, I realized I'm looking at this the wrong way — I'm not deleting contexts, I'm simply removing them from an audience. Remove works perfectly fine when the context continues to exist (as it can be referenced and duck typed). Remove also works for remote content; the same-origin check applies to the audience you're removing from.
If you're deleting a context, you have to be the same-origin, and you really should just federate out deletion of the local members in that collection, via regular Delete(Object).
I suppose federating out self-destruction of a context would be the most complete but it is quite difficult to do when it is no longer resolvable...
-
Yes I'm fine with that. It doesn't make much difference in the end.
-
Thanks Rimu. Will give this a shot.
Upon reflection, since Deletes aren't wrapped in an Announce, then I would recommend that any Move activity we use not be wrapped in Announce either.
-
@julian if you give me any specific examples of when you would want to use null, i can recommend better alternatives. generally, it's always possible that there is missing information.
-
@julian @trwnh there are specifically processing problems with JSON-LD when an `id` property is `null`. I agree, we need better guidance. I'm adding an issue for it.
-
trwnh@mastodon.social said in NodeBB <> Lemmy federation issue (re: nullable image/icon):
> using null is equivalent to just leaving out the statement in the first place.That's not true, there are specific scenarios where having an explicit "no value" is significant vs "missing value"...
