There's more than one way to do this, of course. For group-based forums like piefed, I think the most promising way is to automatically create a local community for each person that someone wants to follow. Incoming activity is then put into the appropriate community, and so you have a consistent UI of UserA has posted to technology@wherever, and UserB has posted to [UserB's community]@piefed.social. This avoids the '2 websites in 1' look that can happen when a site wants to display both lemmy-like communities and mastodon-like microblogs.

I haven't done too much work on it, in case this idea gets shot down in flames. So far, what I've got is:

1. A user searches for another remote user, e.g. @freamon@pixelfed.dk

2. When they're found, the user is offered the opportunity to create a 'Follower Community' (for want of a better name. I've been using 'fan club', but that's maybe a bit naff)

3. The community is created, formatted from the profile id, so [https://pixelfed.dk/users/freamon](https://pixelfed.dk/users/freamon) becomes [https://piefed.social/c/pixelfed_dk_users_freamon](https://piefed.social/c/pixelfed_dk_users_freamon)

4. A follow request is sent to the remote user (from the user doing the search, or a dedicated bot account, maybe)

5. Incoming activity will just be to activitystreams and followers, so there won't be any matches in 'to', 'cc' or 'audience'. In that case, 'attributedTo' is looked at, using the same conversion as above: so something from [https://pixelfed.dk/users/freamon](https://pixelfed.dk/users/freamon) will be sent to [https://piefed.social/c/pixelfed_dk_users_freamon](https://piefed.social/c/pixelfed_dk_users_freamon) if it already exists.

6. The posts will show in the community like any other. Other users can then subscribe to the community in the normal way, and get updates whenever the remote actor publishes something for their followers.

7. Posts from Mastodon would need another post-type to look their best (something that simulates how they look over there). Posts from Pixelfed already display well using Masonry:
   On pixelfed:
   
   On piefed:
   

8. Post replies and upvotes (maybe) should make their way back to remote user, the same way they do if they'd actually made a post in a local community.

Random thoughts:
There would need to be an Undo Follow sent if the community was deleted.
A local community called c/pixelfed_dk_users_freamon looks a bit ungainly, but there's likely a way communities like this could be rendered as something like [SELF] in the homepage feed.
I realise pixelfed are planning to implement Groups, but that hasn't really worked out for mastodon, so we'll see how it goes. I think the ability to follow individuals will still be useful.
The remote user could be made a moderator for the local community, and it set to 'mod posts only' so it would only contain stuff from them.
This approach doesn't require any database changes.

I've just bashed this together for now - looking to get your thoughts before I continue ...

Lemmy's spoiler format is

As described here

The regex I've come up with is :{3} spoiler\s+?(\S.+?\n)(.+?)\n:{3}

It won't do spoilers inside spoilers, but that's a pretty niche case.

The changed code is viewable on GitHub

Any thoughts or suggestions for the regex before I create the PR?

I'm assuming that if I create a PR, and if they accept it, they'll (eventually) release a version with it in, and the line in pyfedi's requirements.txt can get version bumped. This seems like the 'proper' way to do it, but it's a bit long-winded, so maybe there's a better way to do it.

I've been thinking about what to do about cross-posts (e.g. where the same link is uploaded to both fediverse@lemmy.world and fediverse@lemmy.ml).

In terms of them being annoying, I don't yet know what to do about that.

My progress so far, and what it requires:
The Community table has an extra field (xp_indicator), for the field which determines if something is a cross-post or not. It defaults to URL, but it could be the title for communities like AskLemmy.
The Post table has an extra field (cross_posts), which is an array of other post ids (Note: this would lock PieFed into using Postgresql)
New posts, for local and ActivityPub, are checked to see if they are a cross-post, and the relevant posts are updated. This also happens for local edits and AP Update. In the DB, the posts in the screenshot looks like:

-[ RECORD 1 ]----------------------------------------------------------
id          | 27
title       | Springtime Ministrone
url         | https://www.bbcgoodfood.com/recipes/springtime-minestrone
cross_posts | {28,29,30}
-[ RECORD 2 ]----------------------------------------------------------
id          | 28
title       | Springtime Ministrone
url         | https://www.bbcgoodfood.com/recipes/springtime-minestrone
cross_posts | {27,29,30}
-[ RECORD 3 ]----------------------------------------------------------
id          | 29
title       | Springtime Ministrone
url         | https://www.bbcgoodfood.com/recipes/springtime-minestrone
cross_posts | {27,28,30}
-[ RECORD 4 ]----------------------------------------------------------
id          | 30
title       | Springtime Ministrone
url         | https://www.bbcgoodfood.com/recipes/springtime-minestrone
cross_posts | {27,28,29}

In the UI, posts with cross-posts get an extra icon, which when clicked bring you to another screen (similar to 'other discussions' in Reddit)

In terms of hiding duplicate posts from the feed, I don't yet know. If it was up to the back-end, it would require some extra DB activity that might be unacceptable speed-wise. This update would mean though, that a future API could provide a response similar to Lemmy for posts, so apps/frontends could merge duplicates the same way some of them do for Lemmy. Likewise, if there was a 'Hide posts marked as read' feature, it could regard any post ids in the cross_posts field as also being Read.

I have to wait a few days until the quota on my ngrok account resets (something in the Fediverse went crazy, I'd guess), so I thought I'd share here in the meantime. Also, it means the PR doesn't come out of the blue, and it can be discussed beforehand.

(also: it turns out I can't spell 'minestrone')