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:
-
A user searches for another remote user, e.g.
@freamon@pixelfed.dk -
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)
-
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) -
A follow request is sent to the remote user (from the user doing the search, or a dedicated bot account, maybe)
-
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. -
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.
-
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:
-
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 ...
Whoa. No way, sorry.
Both users and communities are represented in ActivityPub as actors (a 'Group' is just a type of actor). We would then have two actors for each user. I don't know how we would make WebFinger work well with this, or how other ActivityPub-based software would cope with it.
Because our users are Actors, we can easily code PieFed to do Follow activities on them in a way that other AP software will understand. It'll be the same as a Follow on a community, except with a different target. If we created a fake community for each user then we wouldn't need to code any new Follow logic (a very minor gain - Follow is one of the simplest activities there are) but we would need to work around the clumsy relationship between this fake community and it's user, in all parts of the system, forever. Nope, nope, nope.
I'm happy to work with you to impart the ActivityPub fundamentals you need to tackle this elegantly and discuss software architecture changes. We'd need a video call or two and share screens, etc. Please use https://cal.com/webdevsolutions/30min to book a time.
Well, that's a strong response haha (infinitely better than no response, of course).
To clarify: the fake community is only for remote actors. How remote actors would follow local users on piefed is up to them. The fake community is mostly for convenience - it's just a place to put content that's consistent with the existing UI.
At the moment, a scenario would be:
andrew@piefed.socialwants to followwarsandpeas@mastodon.social, so searches for them and sends a Follow request.becky@piefed.socialwants to followwarsandpeas@mastodon.social, so searches for them and sends a Follow request.When
warsandpeas@mastodon.socialmakes a post, it's sent to andrew's and becky's shared inbox atpiefed.social/inboxThe ActivityPub JSON for his post would only have
activitystreamsandwarandpeas/followersin it.The challenge is what to do with this.
kbin.socialsolves the problem with having two front pages - one for 'threads', and one for 'microblog'. Lemmy doesn't solve the problem - it just doesn't let you follow users. If piefed were to implement a solution similar to kbin, this would be a big undertaking, and would result in the same '2 front pages' problem.The alternative scenario I'm proposing.
andrew@piefed.socialwants to followwarsandpeas@mastodon.social, so searches for them and sends a Follow request.After it is sent, a community called
piefed.social/c/mastodon_social_users_warandpeasis created.becky@piefed.socialwants to followwarsandpeas@mastodon.social, so searches for them. She is told that a 'follower community' has been set up for them, and so follows that.For incoming activity from
warsandpeas@mastodon.social, if it's not in reply to something, or to a lemmy community, or anything recognisable from 'audience', 'to', or 'cc', the match is made betweenwarsandpeas@mastodon.socialandc/mastodon_social_users_warandpeas. The relationship is one-way, and only exists when it needs to. For outside users, 'warsandpeas' would still be a Person on mastodon, andc/mastodon_social_users_warandpeaswould be a Group on piefed. The WebFinger and ActivityPub response would be the same as for any other Group. Lemmy users could conceivably subscribe to[!mastodon_social_users_warandpeas@piefed.social](/c/mastodon_social_users_warandpeas@piefed.social), and it would act as a bridge between Mastodon and Lemmy. The Group itself doesn't know which user it is for, but it wouldn't need to: it's just the Group that posts from a particular user would be directed into if there was nowhere else for them to go.The advantage of 'fake communities' is that they provide part of a consistent UI, with all users posting into a community, so everything can be presented on one front page. Replies from other followers of the remote actor would be added to the post (as
inReplyTowould match theidof the post). Comments from subscribers to the local community would reach the remote actor, as they would be in reply to the post's author, and so would be sent in the usual way.An example of an existing fake community is !tails@lemmon.website. How this works is I have an actor on lemmon.website that subscribes to Mastodon users. I receive their stuff like any other follower, and then Announce it out as if it had been sent to
lemmon.website/c/tails/tails. That community is nothing more than a JSON file and a ruby script, but it's enough for other ActivityPub actors to follow, and interact with. An example can be seen at: https://piefed.social/post/71314 (although a better example exists for the same post at https://endlesstalk.org/post/29465340 as this has the author on Mastodon and a user on lemmy responding to each other. Why the piefed.social post doesn't show these is a different problem)It's fair enough is this all seems too hacky. (I don't think I'm set up for video-conferencing, btw. It's something I'll look into, as I can see the benefit of it)
Tone is tricky in text, isn't it :)
To me, the question of how to make the UI work is quite different to how to federate posts and different again from how to follow actors. And Mastodon integration. You are trying to tackle all of those at once, which is a lot.
There is a lot to unpick here. I'll need a bit of time to put together a decent counter-proposal.
Zooming out for a minute: IMO we still have heaps to do to improve integration with Lemmy/Mbin. Other group-oriented platforms look to be a more natural fit than Mastodon, also. If we spread ourselves too thinly we run the risk of losing focus and having a bunch of stuff that sort-of-mostly works. Even with our existing scope and feature set, the issue queue just keeps getting longer.
I'll get back to you :)