> They own the domain.

It seems like a wasted opportunity to set up a new domain (in this case: wikimedia.social) rather than use an existing one with a subdomain, e.g. social.wikimedia.org or social.wikimediafoundation.org. With a new domain I still have to do the work to verify whether the domain is indeed owned by the Wikimedia Foundation.

There's some background at https://phabricator.wikimedia.org/T337586 - a wikimedia.org subdomain was out of the question due to security concerns (it'd involve giving a third party a SSL certificate for wikimedia.org) [1], and wikimediafoundation.org was ruled out because it could cause confusion about volunteers' relationship to the Foundation [2]

[1]: https://phabricator.wikimedia.org/T337586#8932905 [2]: https://phabricator.wikimedia.org/T337586#8936483

From your first link, it seems the decision to use a different new domain stems from difficulties getting the server's HSTS policy right, and it even seems they had a similar issue in the past with having the store as a subdomain [1].

If that's true, for a use case as functionally basic as having a store and a social instance in their respective subdomains, it looks to me like a complete failure of HSTS, a case of technology causing problems that shouldn't exist to begin with.

[1]: https://phabricator.wikimedia.org/T337586#8920625

It's not linked there (or on any Wikitech pages I can find), but I can imagine there's a secondary concern of *.wikimedia.org cookies getting sent to third parties - e.g. Stack Overflow has separate second-level domains (stackoverflow.email/stackoverflow.blog) for their 3rd-party-hosted email service and blog for exactly this reason (cf. https://nickcraver.com/blog/2017/05/22/https-on-stack-overfl...)

Seems the real issue is that Mastodon is too hard to self host if not even Wikimedia wants to do it.

> it'd involve giving a third party a SSL certificate for wikimedia.org

You can have certificates for subdomains. With Let's Encrypt you still need to control the root domain to generate them so they'd have to setup something for that. But that's more a can't-be-bothered concern than an actual security concern. Teaching the public to trust random domains being authentic is a much much bigger security concern anyway.

I think it'd be great if there was a way to push the identity through a different domain. @[email protected] or such. Needing subdomains is so clunky - imagine if you were [email protected], yuck.

We can get half way there with /.well-known/webfinger - but the alias that provides doesn't show up in the feed, so that's not the username I find from links like OP's.

There is a way in activitypub, but Mastodon itself doesn't support it well. Takahē supports it (https://jointakahe.org/).

It can accrue reputation the same way Wikipedia.org did while providing a spot to add other things like PeerTube without worrying about the security peculiarities that led to them choosing this route in the first place.

https://phabricator.wikimedia.org/T337586#8920625

They don't really control this server - they're using masto.host to host their instance.

Yes, but they COULD. If for some reason they decide that something's wrong with their host, they could just go offline, export the data onto a new host somewhere, move some DNS targets and set up some redirects, and bam, new server. The point is that some one social media company doesn't have a lock on the site.

They control it a whole lot more than they do Twitter, Facebook, or any other central platform.

Control is a sliding scale. They could run it on a physical box in Wikimedia headquarters and you could still argue they don't fully control the server because their ISP could always cut them off.

You have to make reasonable decisions based on your threat model and how easy it would be to move up the level-of-control ladder if needed. Getting on Mastodon at all represents a huge leap forward, and frees them up to migrate to a higher level of autonomy later.

Nobody would argue that because if they did control the servers an ISP change would be effortless.

Which is the point, the move to a higher level of autonomy is not going to happen later. It's far too much effort once they've already settled in.

We should praise organizations that actually seek to normalize control over servers, not praise relying on yet another "fully managed" service. We can do that while also recognizing that them being on fediverse is nice in general. All of these are possible without stating falsehoods like "They control the servers".

> if they did control the servers an ISP change would be effortless.

I don't know where in the world you are, but I want to live there. Changing my ISP is far more intimidating to me than migrating a database and a few DNS records.

> We should praise organizations that actually seek to normalize control over servers, not praise relying on yet another "fully managed" service.

What would be enough to satisfy you? A VPS on AWS? A VPS on a smaller provider? A dedicated box at Hetzner? Or would it have to be a machine that they built from scratch and can physically access?

They control the identities, and if they wanted to they could transition the identities at the price of—at worst—data loss. It’s the difference between having a blog using the Medium CMS and hosting and having one on a subdomain of medium.com—you can switch away in the former case but you’re completely stuck in the latter (which is why Medium took away the first option and Substack never had it).

> This is how the Web is supposed to work.

More like: this in how the Internet is supposed to work. ActivityPub is hardly "web" because it's not trying to attract traffic on a specific website.

ActivityPub is inherently web because it's a recommendation by the W3C (World Wide Web Consortium):

https://www.w3.org/TR/activitypub/

Missing the point huh?

if the web people wrote a spec involving the web I'd say there's a fair chance it's web related.