What would cross-posting between instances look like in ActivityPub?

[gunchleoc@mastodon.scot]

@julian @kirkmoodey Mastodon is currently working on a spec for their groups implementation. Maybe get everybody together to hash out a common spec, including those who already have a group implementation like Friendica/Hubzilla, Misskey/IceShrimp/Sharkey, Pleroma/Akkoma?

[rimu@piefed.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 Page which 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 so we have some prior art in that direction.

[jdp23@socialhub.activitypub.rocks]

gunchleoc:

Mastodon is currently working on a spec for their groups implementation.

Any links to this and/or discussion of how it relates to other FEPs?

[ludrol@szmer.info]

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.

[erlend_sh@socialhub.activitypub.rocks]

https://github.com/mastodon/mastodon/pull/19059

[jdp23@socialhub.activitypub.rocks]

THanks ... turns out I knew about that: the implementation for the NLNet grant, but never released. My impression is that it's been on hold since then, and there's so much other discussions of group-releated FEPs that I certainly hope they'll incorporate newer thinking if and when it moves forward.

[julian@community.nodebb.org]

I haven't looked into the differences between their implementation and how groups are implemented using 1b12, but what I have discovered is that the 1b12 community is much larger than I gave it credit for.

[projectmoon@forum.agnos.is]

How would this work on the NodeBB side? Multiple categories associated with one topic?

[julian@community.nodebb.org]

[email protected] basically, yes. It would be a little too involved to upend the entire system to support multiple cids per topic — a lot of our existing code relies on cid being a single value.

This would be an add-on logic of sorts, where each topic has a canonical category, but can also be cross-posted to other communities/categories.

[julian@community.nodebb.org]

Hey [email protected] 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.

1. 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?
2. 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 [email protected] [email protected] [email protected] [email protected]