@julian
It is great to see NodeBB trying to work with other platforms to solve issues.

It is supposed to be a federated network, cross-posting is important for many fedi users.

also, if platforms intergrated better it would help discovery and help new and old users of fedi.

@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.

@julian @rimu @andrew_s @melroy @BentiGorlich @nutomic @angusmcleod

I am posting to this from Mastodon, which interfaces with communities on lemmy/pie very awkwardly (but not zero percent).
A good cross posting solution would be one where a user can simply tag the extra communities, like a reply, as then it would be relatively cross platform friendly, and the communities on the other side/server would look for in their database posts with the community tagged / mentioned group 'superuser', say @ examplecommunity @ server.com when they load the community page, regardless if on the actual creation event they only 'officially' store it under one community.
IDK yet (I'll prolly look it up someday) how all these different platforms are organizing their database, but I'm imagining a table like poster | category | tags + msg + mentions | getting pulled when you go to a category; then you could turn off looking at cross-posts that are only in the category because of a tag/mention.

@kirkmoodey@universeodon.com yes, Mastodon compatibility is lacklustre but that's partly because the architecture of Mastodon doesn't lend itself well to categorical organization. That's not a criticism, merely a difference that we have to consider.

Currently, when a user addresses multiple communities, then the existing software (NodeBB included) uses the first one. How the rest of the addressed communities are handled is what's of interest here.

@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?

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.

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?

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.

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.

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.