ドメイン直下にユーザー名を置くURL構造について

なんのことかと言うと、https://github.com/shimataroとかhttps://twitter.com/shimataro999みたいなURL構造のことです。Facebookもそんな感じですね。

ぶっちゃけ、よくそんな無茶苦茶な構造を技術リーダーが許したな、というのが正直な感想なんですが、みなさんはどうでしょうか。

無茶苦茶だと思う理由

わざわざ書くまでもないと思いますが、loginとかstaticみたいなユーザー名を登録されたらやばいですよね。かの伝説のosushi.loveもやらかしてます。

「loginとかstaticみたいな他の意味で使うものは禁止リストに入れて、ユーザー名として取得できないようにすればいい」というかもしれませんが、果たして特殊なパスを網羅できる自信はありますか？

あとで「これ忘れてた！」と気づいたときに、すでにユーザー名が登録されていたらどうしますか？そもそも最初に網羅できたとしても、後から「こういうページも作りたいからこの文字列も特殊なパスにしよう」となることはいくらでもあると思うのですが。

そもそも、同じURL構造でも後に続く文字列によってユーザーページになったりログイン画面になったりするとかユーザー名とURLパスの名前空間が同じとか気持ち悪くて仕方ないんですが、みなさんはどうでしょうか（2回目）。

許される場合

全ての文字列をユーザー名として扱い、ログインなどの特殊な意味を持つものは全て別ドメイン（サブドメインとかTLDを別のものにするとか）で実装する…とかなら一貫性があるので許せます。別にお前に許しをもらわんでもええわとか言わない。

あるいはこうするとか

ユーザーページのURLは https://example.com/@shimataro のように先頭に@をつけるというルールにすれば、loginみたいなURLとバッディングすることもないのでいいんじゃないかと思いましたがどうでしょう。

それに、この方法ならloginというユーザーも登録できます（ユーザーページは https://example.com/@login ）。

それとも、とっくにこんな方法は思いついていて検討もしたけど、その結果やっぱりドメイン直下にユーザー名をベタで置こうという結論に至ったのでしょうか。GitHubやらTwitterやらFacebookいったトップ企業がこんな方法を思いついてないわけがないのでおそらく何か理由があるんでしょうが、やっぱりわかりません。

意外とみんな細かいことにはこだわらず、「あとから別のパスが必要になったらその時考えればいいや」みたいなノリだったりして。。。