spaduf

I think you can be certain that preparations have been made. Whether it'll be enough is a different question

I think one thing you're missing here is that under such a system the defaults would likely become your locally hosted /c/books rather than the largest one. Even still you'd probably see posts from the largest books communities because /c/books@your_instance follows multiple /c/books@big_instance. Community blocking would likely still work as it currently does so any books communities that you were not fond of could still be blocked.

There is still the issue of where do you post and I think the answer looks something like:

• Post in /c/books@your_instance if you want to talk to your neighbors
• Post in /c/books@big_instances if you want to talk to everybody

Which is more or less how most people would decide where to post book stuff anyway.

This is not hobby software, this is public good software. They are paid in large part by grants

I really don't hate this idea from a lemmy centric UX perspective but how do you handle federation with other platforms?

Really like your protocol handlers contribution here. Seems tough to square with multiple accounts though.

Yup that'd be sick

Might just be one of those closed dependencies they have you opt into at install time

I think the major advantage with this model is that it gives those local communities a little more flavor while allowing the same functionality as the large communities (probably a good place to apply scaled sort). It also allows for a sort of curated multi-reddit functionality. Most importantly, it seems flexible and generalizable enough to allow for building advanced group features on all platforms, while still advancing the goal of inter-operability. A more straightforward multi-community functionality or the OP solution would have a lot of unanswered questions regarding federation. I'd be curious to see how kbin does it and whether that federates well. All that said, I think a lot of communities probably should be looking at negotiating a merge.

Turning the fediverse button into an "open on my instance" with similar functionality to subscribing may also be a solution here. Bonus points if it'll also open a comment on mastodon.

Another option here is FEP-d36d which is a standard for group-to-group following. This looks to me like a slightly more organic and opt-in approach.

There's also FEP-d36d which is a standard for group-to-group following. In Lemmy terms, a community could subscribe to another community.

While I agree with the content of that article I don't know if we should give up on Eugen just yet. The Mastodon team has not disclosed what their plan is regarding the groups rework currently on the mastodon roadmap. There is an old proposal here, but I think we have good reason to believe that implementation will be revisited. To that end, it is very important to advocate for the adoption of FEP-1b12 which is the standard that Lemmy uses.

It may also be a good idea to advocate for the adoption of FEP-d36d both here and on lemmy. This is a standard for group-to-group following. Effectively allowing communities to subscribe to other communities.

Here's a slightly older but fairly comprehensive write-up of the situation: https://blog.erlend.sh/group-convergence