from julian@community.nodebb.org to swicg-threadiverse-wg@community.nodebb.org on 31 Mar 19:31
https://community.nodebb.org/post/104060
tl;dr — how do PieFed/Lemmy/Mbin handle cross-posting?
Currently, when a NodeBB admin moves a topic from the uncategorized pseudo-category into a local category, we federate out an as:Announce
, people typically think of that as a "boost" or "share".
That worked fine when the entirety of the category list was your local categories plus the "uncategorized" pseudo-category. However, now that NodeBB is moving towards supporting remote categories (via group actors), this UX makes less sense. We wouldn't want to "move" a topic out of the category it is supposed to be in, just for visibility to other local users. Additionally, topic moving was limited to administrators, and from the get-go we knew it would eventually cause issues because people other than admins would want to share topics to other local users.
This is where the "cross-post" functionality comes in, which is entirely new to NodeBB. I don't think this is new to other AP-enabled threaded discussion software. The idea would be that if a new topic comes in, whether it's uncategorized or not, any user could "cross-post" that topic to a local category, where it would be visible to other users on that instance. On the ActivityPub side, we would then federate out an as:Announce
as we already do.
Is this what PieFed/Lemmy/Mbin already do, if they support cross-posting? What other alternative solutions would there be to this problem?
cc @rimu@mastodon.nzoss.nz @andrew_s@piefed.social @nutomic@lemmy.ml @bentigorlich@wehavecookies.social
#crossposting #lemmy #mbin #piefed #swicg-threadiverse-wg #threadiverse
threaded - newest
@julian On Mbin we don't have a button so the user can cross post it to another magazine/community/group. What we count as "crossposts" are just posts linking the same URL (and sometimes title matching, though I don't like that part). But like Rimu said these are entirely different entities with different apIds often from different instances
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.
Cross-posts are entirely new and separate posts from their originals.
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:
attachment
url (PieFed)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:
Of course, this also happens to be what I'm looking for: the association of an
as:announce
activity with anas:target
pointing to anas: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
onAnnounce
to bring FEP-1b12 and Conversation Containers closer to each other (in CC we haveAdd
withtarget
).Can't
Group
simply be into
ofAnnounce
?@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.