dfyx@social.helios42.de because followers and outbox collections can be faked.

trwnh@mastodon.social but as:Public is not a dereferenceable URL. Needs to be special cased anyway. End of the day nothing changes, it needs special handling for all the cases anyway. cc silverpill@mitra.social

silverpill@mitra.social nice job! Congratulations on the release now you must maintain it for free forever.

Man!!! That screenshot takes me back..

trwnh@mastodon.social before, I was not sending Accept at all, now I am sending application/jrd+json.

Hey rimu@piefed.social thanks for responding (and sorry for the late reply!) I am not married to the Announce([Article|Note|Page]) approach, so I am definitely open to Create([Article|Note|Page]) with a back-reference. I think I went the former direction because there is a known fallback mechanism — the Announce is treated as a share/boost/repost as normal. However, sending the Create also is fine I think. However, do we need a backreference? In my limited research, it seems that Piefed, et al. picks the first Group actor and associates the post with that community. If I sent over a Create(Article) with two Group actors addressed, could Piefed associate the post with the first, and initiate a cross-post with the remaining Group actors? Secondly, is how to handle sync. 1b12 relies on communities having reciprocal followers in order for two-way synchronization to be established. On my end since I know it is cross-posted I will now send 1b12 activities to cross-posted communities, but can Piefed, et al. send 1b12 activities back as well, in the absence of followers? cc andrew_s@piefed.social nutomic@lemmy.ml melroy@kbin.melroy.org bentigorlich@gehirneimer.de

@pfefferle@mastodon.social just wanted to poke you about this issue again. The latest updates to NodeBB now do a webfinger backcheck to ensure that the actor has a valid webfinger entry for their purported handle. If it does not, then the user is not properly created. Mastodon also does this. This check is probably for security as well as for preventing handle collisions. The multilingual plugin in conjunction with the ActivityPub plugin creates users that share the same handle, and that causes issues with federated content. For example, this article by @jonvt@vivaldi.com will load up just fine in Mastodon, but this japanese article by @akira@vivaldi.com will not, because that second article's attributedTo is https://vivaldi.com/ja/?author=176, which fails that check (the author's ID is actually https://vivaldi.com?author=176 as per the handle backcheck) cc @AltCode