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

@obenland@mastodon.social wonderful, good work!

@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

@AltCode One significant potential issues with listing all followed categories in the same kind of layout as /categories is the below-the-fold effect, or the page-2 effect as one might have called it in earlier times. Whatever categories end up falling below a certain scroll distance will just never been seen by most users. If you follow a lot of categories, the ones that end up closer to the bottom of the list than the top will just end up ignored. It doesn't encourage participation, and it also doesn't discourage following a lot of categories that you don't actually care about. And follow relationships are very important under ActivityPub, since they dictate content flow. Bringing in a lot of remote content that no one on the local forum is actually reading or engaging with is very wasteful. An easily accessible compact list might be better, with different sorting options so that users can choose to have categories with new content float to the top. Usually with forum categories, you want the ordering to be static, but that expectation won't necessarily be there for just a list.

I asked in that issue whether Lemmy finds community via to/cc (it does). Does PieFed do the same? Yes - PieFed does the same. It looks in 'audience', then 'cc', then 'to'. It has to, to support all the platforms that haven't adopted 'audience. It's a convenient field, but PieFed won't be affected if Lemmy goes through with removing it. Would this also open up the possibility of a topic/context being part of multiple audiences/communities? Not at present. If you do something like cc: [community1, community2] it will only go to community1 (on both Lemmy and PieFed). There's so many activities that are effectively duplicates, both in normal operation and when platforms are bugged (both Lemmy and Mastodon have gone through phases of sending the same activity multiple times), that you need a way to make sure you're only processing one. On PieFed, this is done by having a UNIQUE constraint of the 'ap_id' column of the Post table (the ap_id of your post is https://community.nodebb.org/post/103806), so it means you can't have the same post in more than one community.

@hamishcampbell @ricmac @evanprodromou @julian Thanks for your kind words. I won't interrupt your discussion with Julian anymore. I hope you reach some accord!

@johnonolan@mastodon.xyz no worries, and thanks! Will do.

I would honestly have been worried if the main people behind the protocol were busy trying to gatekeeep it.

That sounds good

@shoppingtonz@mastodon.social if edits from PieFed aren't reflected here that may be a bug.

1. +1. I will replace webfinger address recommendation with a warning about possible compatibility issues.2. I think observers (and other Application actors on the server) should use a shared key.

Really great talk! I think he did a really good job of introducing the concept of Solid with ActivityPub together, and why this combination would be desirable for people. Super excited to see the future of this project, I would love to see frontends from popular Fediverse servers ported over to ActivityPods app architecture.

> Doesn't this mean Mastodon users et al will no longer get boost notifications when their posts are reshared into a topic? Correct, only OP will be shared. Unless I am mistaken this is how Lemmy implemented it. Announce-ing activities only, and one single Announce(Note) for compatibility with Mastodon.

thisismissem:This sounds like a wonderful FEP! This article published two weeks ago mentions the issue (highlight mine) ..Another example I personally encountered was a frustrating issue while implementing ActivityPub for this blog: updating a post propagated to Lemmy but not Mastodon. Despite the Update activity being accepted, Mastodon silently rejected it unless the updated timestamp changed—a logical but unofficial requirement. Developers must track down subtle implementation details that aren't formally documented, significantly complicating adoption and usage.https://chrastecky.dev/technology/activity-pub-the-good-the-bad-and-the-uglyI'd write it off as a Mastodon-ism, but it's actually better to have that property present, so now it is.So one that's becoming de-facto standard. Ideally if Mastodon introduces such logic, it is up to them to remember to inform the broader developer community via a FEP.---Aside: "If all we have is a Note .. "Overall it is such a pity that everything is to be a Note or else.. And the default pragmatic urge of most devs is to assign app-specific business logic to an existing or custom property within it, to create all the behavioral flavors. And then call it a day "my app works" and throw the protocol decay out in the ecosystem.There are other improvements regarding revision control as long-time open issues, see e.g. @trwnh's https://socialhub.activitypub.rocks/t/exposing-edit-history-via-activitystreams/2930 (mastodon issue # dd. January 2023). In this issue @stevebate suggests previousversions from the ForgeFed Vocabulary.What do we do when we "Edit a Note"? Is using the CRUD of ActivityStreams really the best option, or are we really "Creating a Revision". Shouldn't ActivityPub have a proper way to Revision Control across the board?If my new Fediverse app included both editable and non-editable posts, how I'd hack that in on top of the current mechanism? Just pondering this. It seems we go out of our way not to use the extension mechanism of ActivityPub as it was intended to be used, cramming everything in NoteCrud​. Is that official best-practice for the future fediverse now, I wonder.Many more examples seen in discussions. The ActivityPub specs state that you may ditch JSON-LD for plain JSON, but doesn't say that the whole idea of a semantic type model should be thrown out of the window as well. In https://socialhub.activitypub.rocks/t/distinguish-between-posts-and-direct-messages/2283 the example is people going out of their way not to define ChatMessage in favor of Note + property-logic.

A little semantics thing: I'd argue that HTTP 410 and as:Tombstone are semantically equivalent, i.e.an as:Tombstone should always be served with the HTTP 410 status, andA HTTP 410 status should be treated as a tombstoneSoftware unaware of tombstones will then treat it as a hard delete. "Fully" tombstone aware software can then use logic likeif (status == 200 && contentType is as2) { // treat as normal} else if (status == 410 && contentType is as2 && in body.type) { // also treat as normal} else if (status == 410) { // synthesize a tombstone} else if (status == 404) { // hard delete?} else // existing error handling logic