If you signup to social media it will pester you for your email contacts, location and hobbies/interests.

Building a signup wizard to use that information to select a instance would seemto be the best approach.

The contacts would let you know what instance most of your friends are located (e.g. look up email addresses).

Topic specific instance, can provide a hobby/interests selection section.

Lastly the location would let you choose a country specific general instance.

It would help push decentralisation but instead of providing choice your asking questions the user is used to being asked.

@ergoplato I didn’t suggest that.

Personally I don’t think its ego. I think you have two issues.

The first is people go through stages learning DevOps. Stage 1 has people deploy a CI because its cool, they build a few basic pipelines and then 90% of people get bored. The 2nd stage is people start extending those pipelines, it results in really complex pipelines requiring lots of unique changes based on the opinion of the writer. You move to the 3rd stage when your asked to recreate/extend for a new project and realise how specific your solutions are.

Learning how to make minor tweaks and hook in a few key points to get what you want takes years. Without that most packagers will want to make big changes upstream which won’t go down well.

The second issue, I have met quite a few developers who become highly stressed when the build system is doing something they haven’t needed to do or understand.

A really simple example I have a Jenkins function which I tend to slip into release pipelines, it captures the release version and creates a version in Jira.

I normally deploy it first as a test before a few other functions to automate various service management requirements.

Its surprising how many devs will suddenly decide every problem (test failed, code failed review, sharepoint breaks, bad os update, etc…) is due to that function.

For me this little function is a test, if the team don’t care I will work to integrate various bits. If they freak out, I’ll revert decide if it is worth walking them through the process or walk away.

One of the reasons for the #DevOps movement is developers see building and packaging as #notmyjob.

The task would historically fall on the most junior member of the team, who would make a pigs ear out of it due to complete lack of experience.

This is compounded by the issue that most C/C++ build systems don’t really include dependency management.

Linux distributions have all tried to work out those dependency trees but they came up with slightly different solutions. This is why there are a few “root” distributions everything branches from.

That means developers have to learn about a few root distributions to design a deb/rpm/aur package systems to base their release around.

That is a considerable amount of learning in a subject most aren’t interested in.

The real question is why don’t package maintainers upstream a packaging solution?

Activity Pub has a few parts, Lemmy implements the Threaded message part.

Mastodon implements a short messaging (posts) part. Meta’s Threads will implement this.

KBin implemented both parts, within KBin you’ll see microblog as an option for magazines (communities/subredits). This shows either ‘posts’ made to the magazine or posts with hastags associated with the magazine.

The posts and threaded message parts have overlap in how they work so mastodon users can see certain threaded messages and comment on them.

KBin/Lemmy should provide a combined local view for duplicated magazines/communities across the fediverse. Treating the concept like a hashtag.

The point of the fediverse is to distribute content so no one has a monopoly. People squatting on communities/magazines don’t understand there is nothing stopping people creating one on a hundred other instances.

Each kbin/lemmy instance decides to follow magazines/communities from others through activity pub and stores it locally for the instance.

Having the UI retrieve all local posts with the same magazine/community name (e.g. m/star_trek@kbin.social c/star_trek@lemmy.world). Wouldn’t be hugely difficult, I believe Kbin uses postgres database as the local store and suspect it would be a tweak to the SQL query it runs.

Even if that wasn’t an option, there is a means to get all of the magazines/communities from the kbin UI/lemmy REST API. As well as retrieve all posts for a specific magazine/community. So you could do it entirely in a web client, for KBin it would be more work.

The combined view wouldn’t change how you comment on specific posts. The issue is where do you post and what view would take dominance (e.g. if a magazine had themed itself).

The solution here would be to default your local instance if it exists or the instance providing the most posts/comments. Perhaps with a drop down so users can choose.

I would also configure things so instances can select a site wide default if they can’t moderate it effectively. For example pushing all posts to the star trek instance rather than local magazine with a mod who is MIA.

This would remove most of the concerns users have about the fediverse, since they wouldn’t be confronted by different instances. To them the fediverse is <insert instance> it would also encourage distribution of content.