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:

  1. 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.
  2. 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.
  3. 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 Reject handling 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:

  1. Is there desire from PieFed/Lemmy/Mbin for supporting incoming (and possibly outgoing) federation of cross-posting?
  2. What exactly happens currently if a Group actor receives an Announce(Object)? My guess is nothing, currently, but let me know otherwise :smile:
  3. Would this allow you to accept cross-posts from other AP applications without needing to refactor any existing code?
  4. 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

  • julian@community.nodebb.orgOP
    link
    fedilink
    arrow-up
    2
    ·
    10 days ago

    @ludrol@szmer.info yes, you’re right about that. The silver lining here is that we’re at a point where the major players’ implementations are local-only, so we don’t have to work around with a pre-existing implementation and ensure compatibility.

    The second point is that a “cross-post” could have multiple meanings, including manually creating a new post about a link already present in multiple communities. What I’m hoping to describe is a common way that items can be cross-posted natively between instances, while hopefully preserving their reply-trees.

    • Ludrol
      link
      fedilink
      arrow-up
      1
      ·
      9 days ago

      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?

      If the link goes to a controversial news article and it’s get posted into pro- and against- community/group the comments will spiral out of control and it won’t be a pleasant place.

      Maybe it could be implemented as a toggle per group/instance within one fedi software. It shouldn’t be in Activity Pub protocol.