>Easy: None of them is, because Ba*h*nhof is not operating a validator.
You can have a serious conversation or you can joke about a typo.
That isn’t proof of anything. Hosting a `ripple.txt` is **NOT** a prerequisite for operating a validator and never has been. It is true that an operator could **choose** to host such a file and could **choose** to list their validation public keys in that file, but again, it is **NOT** a prerequisite.
>Alternatively https://www.google.com/search?q=site%3Abahnhof.se+ripple also only finds https://www.bahnhof.se/press/press-releases/2017/07/18/fintechbolaget-ripple-valjer-bahnhof-nar-de-ska-etablera-sig-i-europa and this page also doesn’t mention any public key. There is nothing at all on their website mentioning ANY validation key beyond that. So it has to be concluded that Bahnhof is not operating a validator or at least doesn’t want to be associated with running one.
If that’s your conclusion, that’s fine. As it stands now, Ripple, as a validator list publisher, is **attesting** that they have verified that the validator `nHUFzgC9fDw2MEDaiv9JMdBFhtJ6DMKoUCpS8gPGi6tkfbqmTyis` is operated by Bahnhof.
>It would be trivial for Ripple to release also the signed statement(s) by the validator operators instead of just adding a tick mark on a website. They don’t contain secrets and don’t compromise any kind of security. Since this isn’t done… well, Bahnhof certainly doesn’t claim to operate any validator on their homepage and Ripple has some weird standards what a «domain» is (ripple.com/build/xrp-test-net/ apparently is a «domain»?!), so their competence there is questionable at best.
First, re `ripple.com/build/xrp-test-net` being a «domain» I agree that the naming is not ideal; that is certainly **not** a domain, and it’s something that should be fixed. But, honestly, if that’s your concern you’re grasping at straws and if you think that is an indicator of technical competency… well, I consider that an indicator of something as well. But I digress.
As I explained, we are working on making this information available, but I think this is an improvement over what is already there for two reasons:
1. It allows a validator list publisher to *cryptographically attest* to a domain name associated with a validator.
2. It allows someone querying the active lists of a `rippled` instance to get a human-readable and human-relevant name attached to each validator without having to visit a website or access some API that maps validator keys to identities.
To me, both of those are net gain.
>There’s also Namecoin, ENS… even Ripple a few years back wanted to go into this direction with the whole ~name thing.
Re: ~name; Ripple is no longer going into that direction, and let’s be honest here: if we tried to use that for validator names you’d be complaining even louder that you are complaining now.
As for Namecoin, ENS, etc, if you want to see that support, then code it up and submit a PR. Don’t bash a PR by someone else.
>Certificates (e.g. in x509 format) and infrastructure around them already exist, getting one for a validation keypair shouldn’t be too hard and Ripple could operate a CA that signs CSRs from validator operators fulfilling whatever their identification policy is.
Why don’t **you** operate a CA and sign CSRs from validator operators? Then you can enforce whatever identification requirements you want.
>There’s also DNS TXT records if you want to go the domain route, XRPL has even a «domain» field for that purpose that could be used (at last).
We’ve contemplated storing information in DNS TXT records, but there have been a number of issues associated with that, including the fact that getting buy-in to add records to DNS (or post a **ripple.txt**) isn’t always easy, especially with larger organizations.
>I’d claim that Ripple is currently lying about the www.bahnhof.se validator for the reasons listed above.
You know what? I’m done engaging with you.