Suggestion for Mastodon (to prevent eventual gMastodon instance): cap instance size at 100 - 1,000 account by default. Make it a social contract for instances not to federate with instances greater than that limit.
Or, a few years from now, say hello to “gMastodon”. (See history of email and the Web for a lesson in the future.)
That said, we might already be on that path.
#economiesOfScale #networkEffects #powerDifferentials #ventureCapital
@aral The technically possible condition is “do not federate with more than 100 - 1,000 accounts by instance”, as there is no standardized way to get an instance's user count. ^^
@thomas plus: any API providing that count might as well just lie about it.
@thomas I quite like that.
@theartguy @thomas @aral Yeah ... e.g. scholar.social has ~ 200 active users, but we have had ~ 1900 signups over time
@theartguy @aral To estimate if an account is active, we could base ourselves on the “is an account on our instance following it” so that people can unfollow it to follow another one. And only take into account if the accounts following it are active, which can be determined through last login dates. ^^
@aral Hm, I've wondered too what we do when "google.social" launches on a forked/modified, mastodon-like platform, or even their own #activitypub implementation with google extensions. the #powerdifferential will be heavily weighted towards the expectation that independent servers will implement google's extensions
@aral i think that the fediverse needs to work out OCAP and other security issues in some agreed-upon form before then
@crazypedia @aral I don't believe they will use the mastodon name at all, just the underlying protocols with their own extensions
@troubleMoney @aral sure, I get that. And honestly, social (non-technical) contracts may be all we have to fight it. But the out-sized effect the BigCos have in the social software arena mean we have to have a plan of some kind
@sivy @aral chances are they'd do something like what they did with XMPP and Google Chat: blow a lot of wind about how they're ~FOSS-friendly~ and ~open~, then, once they've grown a user base, throw out the open source and open protocols and create a walled garden (that they then rebrand to leave the stink behind).
If I were some corporate exec at Google or Facebook I'd be wary about joining the fediverse. It's not something they can exclusively control to deliver ads. They wouldn't be able to control the context in which ads were shown and so that could have blowback. They also couldn't enforce "real" names.
But at some point if the fediverse gets popular enough then the advertisers will go where the eyeballs are, however reluctantly.
@aral
Very good point.
I completely agree with this problem [1], but I think the issue is too fundamental to federated tech for a voluntary size cap to fix anything. [2]
I'll also highlight that a large part of Mastodon is in the Amazon cloud, so maaaybe this is a more critical problem. Maybe some people will try to make an ads instance; we won't federate with it. Problem fixed.
@aral An interesting idea. I assume Mastodon . social would be grandfathered in.
@aral 1000 seems like far too low a limit.
Even this instance (soc.ialis.me) has 2407 members right now and most of the time that is not enough to make the "local timeline" feature of Mastodon active enough to fulfill its purpose.
@Laurelai @aral AFAIK, it's not uncommon for there to be a surge of both new and re-used users when someone with a lot of impact mentions being on a particular instance.
With limits like these, it's even possible that the scarcity creates commodification, and economic or trade "value" where there wasn't and shouldn't be one.
What should be done to the 252k users of mastodon.social for example? Which gets forcibly migrated? By what criteria?
@Laurelai @aral The ability to have an actually usable "local timeline" filled with people of similar interests to their own could encourage people to join a specialized instance. It enticed me. :-)
I think positive pull should be preferable to negative limitations. What would be pulling features that still are completely compatible with all other instances... I don't know the APIs, so couldn't say. ;-D
Couldn't Google just make thousands of technically separate instances with a unified onboarding page?
(e.g. 1.google.social, 2.google.social, 3.google.social etc show up as separate, but everyone logs on through google.social)
@switchingsocial Technically, yes. But they couldn’t do that invisibly and they could be blocked. Social acceptance plays a big role.
@aral your trying to come up with an engineering solution to a social/legal problem. Google should have been subject to antitrust law years ago.
@animeirl There’s no reason we cannot have technical regulation alongside legislative regulation. Just like we have tracker blockers alongside the GDPR.
@aral "gMastodon" -- or maybe we should call it Mastitis.
...no, on second thoughts let's not.
wow! Very much possible for them to enter the space
Solution though is not clear what could be!
@aral
Techincally it already happened ; pawoo.net is absolutely gigantic and its owner is a quite big company in Japan
@aral sorry, free software means free software. What you suggest contradicts the gpl license
@astheroth Nope, it doesn’t. The GPL does not dictate the software‘s features or the social norms that the community of people using it decide upon for how they want to use those features. The GPL merely prescribes what is permissible in terms of how the source is made available and distributed and how derivatives are licensed.
@aral if I don't like your community I could fork your software.
@astheroth Goes without saying.
@aral remember in 2006 when everyone loved Google? https://www.youtube.com/watch?v=AZnYRaQfjK4
@whatcraic Sadly, the vast majority in the “web community” still do. People still get enthusiastically congratulated on Facebook threads when they announce that they’ve started working there (or at Facebook, etc.) by some of the most respected names in the industry. Then again, the centralised web created surveillance capitalism so it’s not surprising.
@aral it will start slowly with analytics for Mastodon, AMP/Instant Articles support for Mastodon and earn money with AMP paywall etc
@aral If your problem is "gMastodon", then even capping at 100k or 1 million would suffice - you don't need to have "small" instances only, you just can't have a _majority_ instance.
I'm on an instance with ~10k users, and I'm just about okay with the local timeline on here. I'd guess with 100 people, that would just feel empty.
I'm also not massively sold on having too many instances, because that could fracture the federation via instance blocks.
@aral
Back when Google were still playing the nice guys, people were seeing Google's interest as a validation of XMPP as a viable mainstream technology. They were eager to please. We all know how the story went from there.
This time around, it will be different. We have learned. None of your corporate embrace, extend, extinguish. Our technology is self-validating. We do not need you, and we will not federate with you.
@aral
Wouldn't it just be easier to fix federation relays and then set up a small instance union so the majority of Masto traffic is on and between small instances. Then the SIU just doesn't permit any 5000+ user instances on the relay.