I can see many articles from other instances that end up in m/random instead of the actual magazine they were posted in. Why is this so? It’s pretty annoying to be unable to view, subscribe to, or block those magazines.
I haven’t fully tested this hypothesis, but it’s based on what I do know.
I believe that when a comment/reply is federated before the main OP thread/article, it “looks at what it’s a reply to” and tries to fetch the “parent” thread. But (and I haven’t verified so I’m not certain yet), when it fetches the parent Thread, I don’t believe that contains the “group/(magazine)” information, just the “thread content/post” part. It’s because magazines are not the author of the Article/Thread, the user account is and so a reply would be to content that the OP account created without reference to the Magazine.
When new content is federated and pushed out at creation time, that does have the associated Magazine information, even though the author is still the user account that created the Article/Thread/Link, etc.
Thanks! But why is this the case? Is it a technical limitation of ActivityPub? Or just a rough edge of the kbin code? (No idea if lemmy instances have the same issue)
Without looking at the exact full data exchange, I can’t say for certain. I don’t even know if the trigger is as I think it might be.
But you can get a sense of where the information for the magazine account is by looking at this sample payload of what it looks like when a new Article/Thread is created and federated out. There is no “inReplyTo” because this is the initial thread/article, but it would point to the direct url for a previous content, not the magazine.
{ "@context": [ "https://www.w3.org/ns/activitystreams", "https://w3id.org/security/v1", { "ostatus": "http://ostatus.org#", "sensitive": "as:sensitive", "votersCount": "toot:votersCount" } ], "id": "https://kbindomain/m/testmagazine/t/16", "type": "Create", "actor": "https://kbindomain/u/demouser", "published": "2023-06-17T18:58:26+00:00", "to": [ "https://kbindomain/m/testmagazine", "https://www.w3.org/ns/activitystreams#Public" ], "cc": [ "https://kbindomain/u/demouser/followers" ], "object": { "id": "https://kbindomain/m/testmagazine/t/1676", "type": "Page", "attributedTo": "https://kbindomain/u/demouser", "inReplyTo": null, "to": [ "https://kbindomain/m/testmagazine", "https://www.w3.org/ns/activitystreams#Public" ], "cc": [ "https://kbindomain/u/demouser/followers" ], "name": "Federation Test", "content": "<p>Test for the body of the article</p>\n", "summary": "Test for the body of the article #testmagazine", "mediaType": "text/html", "url": "https://kbindomain/m/testmagazine/t/1676", "tag": [ { "type": "Hashtag", "href": "https://kbindomain/tag/testmagazine", "tag": "#testmagazine" } ], "commentsEnabled": true, "sensitive": false, "stickied": false, "published": "2023-06-17T18:58:26+00:00", "contentMap": { "en": "<p>Test for the body of the article</p>\n" } } }Just realised your hypothesis doesn’t work, as many of the posts I see ending up in m/random have 0 comments, thus there is no way they could have been referred to by a comment/reply before they were federated.
For Sure. It might not be comments, but some other way the thread shows up without the magazine information. I have seen the same thing you describe but I haven’t been able to capture data on it. I have a few ideas on how to test different scenarios but I need to figure out how to capture the raw data as well to verify.
Doesn’t happen on Lemmy. I assume that’s a kbin-specific bug.
@ernest any chance you could shed some light on this?
