Cross-posts are entirely new and separate posts from their originals.

@rimu@piefed.social excellent... yes this is the kind of difference I'd love to explore and potentially put together an FEP for...

Hmm... considering that Piefed cross-posts are entirely separate posts, then if the original is edited, then the modification is not carried over to the cross-posted post, correct?

I'm thinking that for NodeBB we could continue to have cross-posts reference the canonical topic. They'd simply be part of a separate audience as well.

Whether this is local-only or not, I am not sure yet. Perhaps for federation purposes we'd still report the original category (if there is one) under audience

Might want to use a custom taxonomy/tag type for cross-posts. That's what we use for saving messages in "folders".  While we don't typically federate these, I would imagine  you might want to share those tags with software that supports cross-posting.

Yes the modification is not carried over and the cross-post will often have a different author from the original too. While creating the cross-post the cross-poster could have edited the title and description, too. The only connection is that they have the same url (in the attachment). Lemmy adds the text "cross-posted from link-to-original" to the beginning of the body content but it's just text, not an attribute on the Activity.

Room for improvement!

Also moving what NodeBB calls a topic (a post in Lemmy/PieFed) from what NodeBB calls a category (community in Lemmy/PieFed) into a different category (without spawning a new topic or leaving the old copy behind) is much needed but not implemented in Lemmy/PieFed/Mbin.

One thing that you have to consider is that some forums and categories might have post permissions attached to them. For example, many Hubzilla forums restrict creating new posts to members of the forum. (To become a member of a forum, you would need to connect to or follow the forum, and then be allowed to join by the administrator, either automatically or by admin approval.) In that case, not everyone can create a new top level post. There may also be comment restrictions as well, regarding who can comment on a post in the forum.

If you were to cross post between multiple forums or categories, if you want them to be synced, you would have to take into account the relevant permissions, and decide what to do with posts that don't conform.

One option is for the admin of a forum to allow which other forums they allow a full sync (ignoring existing forum permissions and providing an exception for other trusted forums). If a cross-posted post comes from a non-trusted forum, then no exceptions will be allowed and the existing forum permissions are enforced.

Of course, nothing has to be done about this and we can just let the forums enforce their own permissions. But if we don't communicate these permissions, some users might not realize why their cross-post has been silently dropped since the UI does not make it clear that a user had to be a member of certain forums to post to that forum.

@scott@loves.tech how does Hubzilla communicate this to other 'za instances?

Something like a boolean for whether the public can post would take you part of the way there.

I guess the real problem here is that we should be able to use the aptly named 'newsgroups' header field -- just like USENET in the days of yore. Otherwise there's a problem aggregating/routing replies. Especially with Mastodon involved, because the authors of each comment can change the recipients to anybody they want.  I brought up a 'replyTo' field for this use case a few years back, but it didn't get any traction and was subsumed by Conversation Containers. I guess the bottom line is that I don't see any way out of this without an FEP; because each commenter will need to be able to automatically route replies to every forum involved. Best I can come up with on short notice is Conversation Containers where the context and/or target are arrays of Collections and you'll be sending your replies to all of them.

Based on the replies received, it does sound like at present that if cross-posting is a consideration, it is something done locally, and not something that is explicitly declared when federating outward or retrieved via AP.

There are also multiple definitions of cross-posting:

1. Multiple, disparate topics sharing the same attachment url (PieFed)
2. Author targeting multiple audiences
3. Non-author sharing object to additional audiences

One of those is really not like the other, which does complicate things somewhat. Thankfully, it does seem like that the way PieFed handles it, is local to the instance.

A good first step might be to narrow down the definition of cross-posting—at least from a protocol level—to a combination of the latter two:

> "A user (which may or may not be the object author) sharing an object to additional audiences"

Of course, this also happens to be what I'm looking for: the association of an as:announce activity with an as:target pointing to an as:Group actor.

Would this be of interest to anybody here? The fallback mechanism is to just treat the announce as usual.

>the association of an as:announce activity with an as:target pointing to an as:Group actor.

I was thinking about adding target on Announce to bring FEP-1b12 and Conversation Containers closer to each other (in CC we have Add with target).

Can't Group simply be in to of Announce?

@silverpill @julian i was going to say that yes, to/cc/audience are more specific versions of target, specifically audience targeting. not sure Announce.target is needed here... what would be ideal is if multiple Announces existed, one for each category. an AP Announce represents a "share" and not necessarily a "reshare", so it's not like one of them has to be the "original"; they can all exist at the same tier.

@trwnh@mastodon.social sure, makes sense. That to/cc already exist in the wild as arrays means one less thing to worry about with multiple cross posts.