Mastodon: Don't use "mastodon" or "mstdn" in domain names
20 points by cxplay
20 points by cxplay
Well, this isn't exactly "news":
Social media guidelines
The name and handle of your social media account and any and all pages cannot begin with a Mastodon word mark, or a similar mark (e.g. "mastodoon", "mast0don", "mstdn"). In addition, Mastodon logos cannot be used in a way that might suggest affiliation with or endorsement by Mastodon.
—— https://github.com/mastodon/joinmastodon/~ (2022)
But this is the first time they've included proactive reminders within the software.
My feeling is that mastodon.example.com, where example.com is an existing thing, especially if it’s a single-user installation, should be considered fair use (descriptive/nominative) and thus exempt from trademark use restrictions, while examplemastodon.com is likely to be subject to a trademark policy.
That really reminds me of Rust's trademark policy.
Remember that overreach is normal in a lot of these sorts of legal documents—it’s almost never punishable, so why not try to claim more than the law actually allows?
it’s almost never punishable, so why not try to claim more than the law actually allows?
Because you're wasting goodwill?
Ever find a copy of mediawiki on a sharepoint.xyz.corp server? Really tells you everything you would want to know about sharepoint. Really.
I wonder if banning mastodon.xyz.corp is intentionally a way to avoid getting that kind of bad press...
Still new information for a lot of people, I suppose. I am currently on a Mastodon server with "mastodon" in its domain name (mastodon.gamedev.place), and it feels like a pretty common practice from other servers as well
Yes, many people, myself included, are in the habit of using the app name directly as a subdomain when deploying online services.
Of course. It's a long-standing practice to do this, e.g. irc://irc.quakenet.org. It's [application].example.org. And it works for pretty much everything except organizations like Mastodon that apparently like trademark lawyering. Very telling, in my opinion.
That's not the application name, that's the protocol name. Using activitypub.example.com, or even fediverse.example.com would be fine.
Yeah it's a bad example but the point stands. piwik.example.org for your piwik analytics instance, gitlab.example.org for your git hosting, jellyfin.example.org for your self hosted jellyfin instance. I've certainly done that sort of thing many times.
The distinction you make is technically correct, but this distinction is often not drawn in naming. For instance, TeamSpeak is not a protocol, it's an application, and the URLs are usually called ts. or ts3..
My Fediverse instance is pleroma.debian.social. I wish they’d not used the current software in the name, because it will be awkward (one way or another) to switch it later.
That said I think we lack an appropriate word that is conceptually somewhere between “Fediverse” (too generic, covers non-microblogging things) and “mastodon”.
A nice thing is you can have a different WEB_DOMAIN (for the web app) and LOCAL_DOMAIN (for the handles/account) : https://docs.joinmastodon.org/admin/config/#web_domain
On one hand, it feels bad when projects do trademark shenanigans that make me feel like I got tricked, or that something is being taken away.
On the other hand, I understand the project not wanting to seem even remotely affiliated with some viewpoints and content that get posted on some instances.
TBH, I'll file that patch under "user service". It informs users early so that they don't figure out later.
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Can someone who understand Github better than explain what this means?
This might be because the branch corresponding to the PR on GitHub was cleaned up after being merged, which is why you're seeing this prompt. I have now updated the link to point to the main branch commit.
Github treats a repository and all its Github forks as one repository on some level, so commits in any of them are available under it. But obviously a commit in a fork is not actually part of the parent, hence the warning.
GitHub also changes the commit hash when you merge a PR, even if you do rebase, because they add metadata. This was the one thing that Azure DevOps did better than GitHub: PRs were tracked using tags, so you could do a fast-forward merge from their PR flow (GitHub also appears to track this via another mechanism: if you do a push to the mainline with a commit from a PR, it will close the PR and label the commit in the UI as merging the PR).
If you merge a PR with rebase and then delete the PR branch, all commits with the hash from the PR branch will show up like this on GitHub, but will be retained indefinitely because the PR keeps a reference to them. Finding the corresponding commit in the main branch is annoying.
If you do a merge commit, they will show up, but then you can't have linear history.
Huh. I would have guessed that recent waves of "verify your account" spam from mastodon.cloud had something to do with this, but I think the PR is just barely before it.