Current problem
On "free static hosting" solutions, you don't usually get DNS access, but you will get a subdomain with arbitrary content on it. So, you cannot do the DNS verification, you must do
.well-known.
But if you have an account on multiple instances (or even multiple accounts on the same instance), you cannot verify your domain on all of them! This is because the code only checks that the response body is exactly the token it needs, compared to the DNS codepath where it only requires that one of the records is the token it needs.Proposed change
There should be a way for multiple fluxer verification tokens to be contained in the same
.well-known method. Perhaps by just checking if the response to .well-known/fluxer-verification contains the token at all, instead of checking that it is exactly the expected token.Platform
API, Self-hosting
Additional information
Simply adding arbitrarily many lines to the response at
.well-known/fluxer-verification is unsustainable if you have a LOT of accounts (should that even be supported?). There's a size limit, after all.
For Discord, the current property can even be seen as desirable: maybe they intentionally don't want alt accounts verifying the same domain (e.g. to prevent those e-gangster types from showing "their name" on a dozen squared acounts they stole with cool usernames)?
But for Fluxer, we definitely want accounts on multiple instances to be able to verify a domain. So maybe .well-known/fluxer-verification/fluxer.com could contain one token, and another at .well-known/fluxer-verification/fluxfur.com, and a third at .well-known/fluxer-verification/chat.example.com?
The same could really apply for DNS. _fluxer.{domain to be verified}. might contain a lot of TXT records if a user has a lot of accounts on a lot of instances. maybe we could check fluxer.com._fluxer.{domain to be verified}?
If we want to support many alt accounts verifying on the same instance, it might even make sense to have the full path be .well-known/fluxer-verification/:domain/:uid (e.g. .well-known/fluxer-verification/fluxfur.com/1543080498799050752).
another alternative that i will briefly bring up is scrapping the current domain verification system entirely, and replacing it with rel=me (which intrinsically always supports many-to-many links).
at the end of the day, domains are moreso infrastructure. but websites are homes on the Web. it is weird to verify ownership of infrastructure, in the social connections panel.
domains connections have an "open link" button on profile pages. it is very strange that there's not even a semblance of a requirement that the link target should perhaps be a website.
i don't think domain verification in the current form makes sense to have on Fluxer at all. i think it only works the way it currently does because it's how Discord does it.
i don't feel very strongly that it needs to go. but i do think it should work across multiple instances (hence the feature request)