Following up on this question I asked back in late March, I wanted to continue thinking about how one would handle cross-posting between categories/communities, given that there isn't current consensus on it, and especially given that NodeBB—as of v4.3.0—can now see and browse remote categories.
From that original topic, we can distil the following:
- Both PieFed and Mbin do not natively handle cross-posts, a new entity is made with the crucial bits (link, text, possibly title) copied over and changed if needed, sometimes a "cross-posted from..." helper text is prepended.
- There are legitimate concerns that a cross-post might not succeed depending on privilege settings on the receiving end, so a pre-flight check (or explicit rejection) of some kind might be required.
- Cross-posting can be done by the original author, or another user.
So were an FEP to be written, we'd center it around the following assumptions:
- "A user (which may or may not be the object author) is sharing an object to additional audiences"
- We would use the existing
Announce(Object)model - We would not use
Announce(Activity)because it is not the original object creation that is being announced, but the object itself, to a new audience. - Some form of
Rejecthandling would be required for cases where the cross-post is not allowed - How the receiver handles the activity is out-of-scope of the FEP. It could be that the original object is contained within multiple categories/communities, or a duplicate object could be created — implementor's choice.
This is very similar to an existing announce/boost/reshare, except that instead of addressing the activity to followers list you are addressing it to a group actor's inbox.
Some additional questions:
- Is there desire from PieFed/Lemmy/Mbin for supporting incoming (and possibly outgoing) federation of cross-posting?
- What exactly happens currently if a Group actor receives an
Announce(Object)? My guess is nothing, currently, but let me know otherwise :smile: - Would this allow you to accept cross-posts from other AP applications without needing to refactor any existing code?
- Duplicating the object would mean the discussion is split between objects. The ideal implementation would be the same object present in multiple categories/communities. Is there desire for this in the threadiverse?
@rimu@piefed.social @andrew_s@piefed.social @melroy@kbin.melroy.org @bentigorlich@gehirneimer.de @nutomic@lemmy.ml @angusmcleod@mastodon.social
IMO The simplest way would be to garnish a bit of extra data onto the normal FEP 1b12 process.
Create a new post (Create -> Page to the instance that hosts the community, which in turn does Announce -> Create -> Page to followers) and add an extra field to the
Pagewhich is the URL of the original post. That will establish the association.To reject the cross-post, return HTTP 400 (403?) to the POST to the inbox on the initial Create -> Page ? Or send a Reject activity, either way is fine but the 400 seems easiest. Lemmy returns 400 for a lot of things, PieFed just blindly accepts everything.
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 toCreate([Article|Note|Page])with a back-reference. I think I went the former direction because there is a known fallback mechanism — theAnnounceis treated as a share/boost/repost as normal. However, sending theCreatealso is fine I think.Groupactor and associates the post with that community. If I sent over aCreate(Article)with twoGroupactors addressed, could Piefed associate the post with the first, and initiate a cross-post with the remainingGroupactors?1b12activities 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