German TLD #180

Ghost commented 2020年05月15日 17:49:47 +02:00

Why do we rely on a foreign country to maintain our TLD? I suggest do change it to .eu or .de.

Why do we rely on a foreign country to maintain our TLD? I suggest do change it to `.eu` or `.de`.

hw commented 2020年05月16日 12:13:17 +02:00

Domains .de suggests a very national scope (surely FOSS should not be bound to national borders?), .eu might be worth a thought. Other projects like wikipedia service multiple country domains for redundancy, this might be an interesting option long-term. However it would imply some spending we need to discuss.

Domains `.de` suggests a very national scope (surely FOSS should not be bound to national borders?), `.eu` might be worth a thought. Other projects like wikipedia service multiple country domains for redundancy, this might be an interesting option long-term. However it would imply some spending we need to discuss.

fnetX commented 2020年05月19日 00:36:58 +02:00

The term "a foreign country" depends on your point of view. Changing it to a German TLD would change it to a TLD managed by a country which is foreign to 99.99 % of the world's population.

I know this comparison is somewhat misleading since the actual user base of Codeberg.org is of course not to be compared with the world's population, but there are many international coders over here, so I'm sure the .org TLD is the best choice for an international project which aims at being an open organization like codeberg does.

I strictly disapprove a change of the TLD. I disapprove an exclusive treatment for Germany (like an additional German TLD). I don't see any need for supporting multiple domains at all.

~ I think that it's not wrong that a TLD is managed by some country, however, it might be better to have a true common management for .org domains. What I find worse is that most TLDs are technically managed by private companies - I'd prefer to change that on a global scale. But that's a different topic to discuss somewhere else :-)

The term "a foreign country" depends on your point of view. Changing it to a German TLD would change it to a TLD managed by a country which is foreign to 99.99 % of the world's population. I know this comparison is somewhat misleading since the actual user base of Codeberg.org is of course not to be compared with the world's population, but there are many international coders over here, so I'm sure the .org TLD is the best choice for an international project which aims at being an open organization like codeberg does. I strictly disapprove a change of the TLD. I disapprove an exclusive treatment for Germany (like an additional German TLD). I don't see any need for supporting multiple domains at all. ~ I think that it's not wrong that a TLD is managed by some country, however, it might be better to have a true common management for .org domains. What I find worse is that most TLDs are technically managed by private companies - I'd prefer to change that on a global scale. But that's a different topic to discuss somewhere else :-)

Ghost commented 2020年05月19日 19:50:19 +02:00

What I had in mind was taking away power from Five Eyes countries after all managing a TLD is something every countriy within the EU can do as well.
I dont know what additinal power a country managing a TLD would have as Im not so deep in that part of networking but I would bet it makes for easier MITM attacks.
Keeping in mind the unstable political situation one might also imagine an export embargo which could potentially cut off access to .org domains for certain countries even though this server is located in Germany and should not be affected by such embargos.
While I agree a federated management of .org domains would be nice I cant see it happenig.
It was certainly not my intention to imply other nationalities shouldnt be able to collaborate here.

What I had in mind was taking away power from Five Eyes countries after all managing a TLD is something every countriy within the EU can do as well. I dont know what additinal power a country managing a TLD would have as Im not so deep in that part of networking but I would bet it makes for easier MITM attacks. Keeping in mind the unstable political situation one might also imagine an export embargo which could potentially cut off access to `.org` domains for certain countries even though this server is located in Germany and should not be affected by such embargos. While I agree a federated management of `.org` domains would be nice I cant see it happenig. It was certainly not my intention to imply other nationalities shouldnt be able to collaborate here.

Pik-9 commented 2020年05月20日 01:21:37 +02:00

I agree with PhilippMayrTH.
In my opinion one the main selling points of this portal and therefore one of the main reasons not to use Github, Gitlab, Sourceforge, Bitbucket, etc. is that it is not US based!
Just think about how much technology and intelligence (and therefore power) is concentrated in that one country. What would happen if the political situation changed and they denied the rest of the world access to their services or just shut them down for whatever reason.

A .de TLD would be a bit country specific indeed, but I consider an .eu TLD a great way to emphasize the fact that this is one of the very few non-US based FOSS hosting platforms.

I agree with PhilippMayrTH. In my opinion one the main selling points of this portal and therefore one of the main reasons not to use Github, Gitlab, Sourceforge, Bitbucket, etc. is that it is not US based! Just think about how much technology and intelligence (and therefore power) is concentrated in that one country. What would happen if the political situation changed and they denied the rest of the world access to their services or just shut them down for whatever reason. A `.de` TLD would be a bit country specific indeed, but I consider an `.eu` TLD a great way to emphasize the fact that this is one of the very few non-US based FOSS hosting platforms.

6543 commented 2020年05月28日 23:19:14 +02:00

I'm for .eu too but as addition - it could be used for loadbalancing too :)

I'm for `.eu` too but as addition - it could be used for loadbalancing too :)

zsoltsandor commented 2020年05月30日 02:09:38 +02:00

As an EU data patriot, I am in favor of the .eu TLD too.

PS: I have an EU data patriot project in the pipeline, and guess what, will be hosted on Codeberg Pages, with Gandi as registrar. :)

As an EU data patriot, I am in favor of the `.eu` TLD too. PS: I have an EU data patriot project in the pipeline, and guess what, will be hosted on Codeberg Pages, with Gandi as registrar. :)

hw commented 2020年05月30日 13:12:49 +02:00

As of today, we have registered .eu, too. Not sure however whether gitea can handle multi-TLD hosts, need some testing. Alternatively. we might also consider hosting pages on .eu, allowing nice+short subdomains <username>.codeberg.eu. Thoughts?

As of today, we have registered `.eu`, too. Not sure however whether gitea can handle multi-TLD hosts, need some testing. Alternatively. we might also consider hosting pages on `.eu`, allowing nice+short subdomains `<username>.codeberg.eu`. Thoughts?

zsoltsandor commented 2020年05月30日 13:21:08 +02:00

Pretty urls on .eu - even instead of .io as with others - sounds like a good option too. Right now codeberg.eu is throwing cert error, obviously.

Pretty urls on `.eu` - even instead of `.io` as with others - sounds like a good option too. Right now `codeberg.eu` is throwing cert error, obviously.

zsoltsandor commented 2020年05月30日 13:34:18 +02:00

Regarding the .org TLD, just remember that there was this ownership controversy recently, which luckily didn't go through, but none shall feel relaxed.

Regarding the `.org` TLD, just remember that there was this ownership controversy recently, which luckily didn't go through, but none shall feel relaxed.

hw commented 2020年05月31日 22:16:27 +02:00

Pretty urls on .eu - even instead of .io as with others - sounds like a good option too. Right now codeberg.eu is throwing cert error, obviously.

yeah, currently domain only registered to prevent domaingrabbing.

> Pretty urls on `.eu` - even instead of `.io` as with others - sounds like a good option too. Right now `codeberg.eu` is throwing cert error, obviously. yeah, currently domain only registered to prevent domaingrabbing.

6543 commented 2020年06月02日 14:56:35 +02:00

someone should rename this issue title as the consent is more or less clear now ;)

someone should rename this issue title as the consent is more or less clear now ;)

6543 commented 2020年06月02日 14:58:25 +02:00

As of today, we have registered .eu, too. Not sure however whether gitea can handle multi-TLD hosts, need some testing. Alternatively. we might also consider hosting pages on .eu, allowing nice+short subdomains <username>.codeberg.eu. Thoughts?

it use the host from the request normaly. But there are links wicht are generated from the host written into the config.

this issue should impruve the situation: https://github.com/go-gitea/gitea/issues/11732

> As of today, we have registered `.eu`, too. Not sure however whether gitea can handle multi-TLD hosts, need some testing. Alternatively. we might also consider hosting pages on `.eu`, allowing nice+short subdomains `<username>.codeberg.eu`. Thoughts? it use the host from the request normaly. But there are links wicht are generated from the host written into the config. this issue should impruve the situation: https://github.com/go-gitea/gitea/issues/11732

momar commented 2020年06月06日 00:16:34 +02:00

If we want to use both, bare in mind that it seems like Gitea doesn't add a rel=canonical link, which means that everything shows up twice on Google & Co.!

I'm in favor of deciding on one domain, and have the other just redirect to the correct one. Currently, I don't see anything speaking against continuing using .org as the main domain for the next couple of years.

If we want to use both, bare in mind that **it seems like Gitea doesn't add a [rel=canonical](https://support.google.com/webmasters/answer/139066?hl=en) link**, which means that everything shows up twice on Google & Co.! I'm in favor of deciding on one domain, and have the other just redirect to the correct one. Currently, I don't see anything speaking against continuing using .org as the main domain for the next couple of years.

Ghost commented 2020年06月06日 11:40:25 +02:00

Google (and probably others) support rel as HTTP headers which we should be able to configure in the reverse proxy. See https://support.google.com/webmasters/answer/139066.

Google (and probably others) support rel as HTTP headers which we should be able to configure in the reverse proxy. See https://support.google.com/webmasters/answer/139066.

hw commented 2020年06月06日 19:05:54 +02:00

We could surely inject rel=canoncial in the head template. Still there are absolute links in html, typically generated by config variables DOMAIN, SSH_DOMAIN, ROOT_URL?

We could surely inject `rel=canoncial` in the head template. Still there are absolute links in html, typically generated by config variables `DOMAIN`, `SSH_DOMAIN`, `ROOT_URL`?

zsoltsandor commented 2020年07月21日 03:51:58 +02:00

I've been trying to play around with the Testing instance of Codeberg, and while it seems good to go, Gandi has some problems handling it, anmely the best thing to do is web redirects, and not via ALIAS for the apex, or CNAME for the www.
But redirecting is obviously suboptimal.

I've been trying to play around with the Testing instance of Codeberg, and while it seems good to go, Gandi has some problems handling it, anmely the best thing to do is web redirects, and not via ALIAS for the apex, or CNAME for the www. But redirecting is obviously suboptimal.

hw commented 2020年07月21日 22:27:46 +02:00

what problems exactly?

what problems exactly?

zsoltsandor commented 2020年07月22日 00:16:13 +02:00

SSL problems, the cert belonging to codeberg-testing.org, not codeberg.eu. But now I'm playing around with KeyCDN too, not exactly the solution I was looking for in Netlify replacement, but almost. I will nag them about the custom HTTP headers feature.
Oh, and they are Swiss, so it's all green from me.

SSL problems, the cert belonging to codeberg-testing.org, not codeberg.eu. But now I'm playing around with KeyCDN too, not exactly the solution I was looking for in Netlify replacement, but almost. I will nag them about the custom HTTP headers feature. Oh, and they are Swiss, so it's all green from me.

zsoltsandor commented 2020年07月22日 02:06:27 +02:00

Right now, I have the apex ALIAS pointing to keepyourdataineurope.codeberg.eu, not testing www for now, it's not even in CNAME.

I'm getting this while testing in a Tor session in Brave (Tor = no cache). If I click to proceed on anyway, I get to the main page of codeberg-testing, but it takes my URL, and shows the cert as belonging to codeberg-testing.org.

When I did it with KeyCDN in between, with www CNAME pointing to the KeyCDN address, and the apex ALIAS pointing to www, I got no HTTPS problem, but again, my own domain was displayed, the cert had the proper url (with www, because I set that one up to be used), but I got the main page of codeberg-testing.org.

Right now, I have the apex ALIAS pointing to keepyourdataineurope.codeberg.eu, not testing www for now, it's not even in CNAME. I'm getting this while testing in a Tor session in Brave (Tor = no cache). If I click to proceed on anyway, I get to the main page of codeberg-testing, but it takes my URL, and shows the cert as belonging to codeberg-testing.org. When I did it with KeyCDN in between, with www CNAME pointing to the KeyCDN address, and the apex ALIAS pointing to www, I got no HTTPS problem, but again, my own domain was displayed, the cert had the proper url (with www, because I set that one up to be used), but I got the main page of codeberg-testing.org.

zsoltsandor commented 2020年07月22日 02:30:37 +02:00

I'm also doing some checks with hardenize.com and internet.nl, they are throwing some errors related to the cert situation.

I'm also doing some checks with hardenize.com and internet.nl, they are throwing some errors related to the cert situation.

hw commented 2020年07月22日 12:04:32 +02:00

SSL problems, the cert belonging to codeberg-testing.org, not codeberg.eu [...]

What do you mean by "belong to"?

> SSL problems, the cert belonging to codeberg-testing.org, not codeberg.eu [...] What do you mean by "belong to"?

hw commented 2020年07月22日 12:05:55 +02:00

(the .eu domain is using a dedicated wildcard certificate which should not have any relation to -test?)

(the .eu domain is using a dedicated wildcard certificate which should not have any relation to -test?)

zsoltsandor commented 2020年07月22日 19:52:04 +02:00

Probably easier to show in screenshots.
As you can see the @ is ALIAS pointing to keepyourdataineurope.codeberg.eu - which, should the test phase move to the production server will stay the same url, even if different IP. So, this should be good and fault tolerant.
But I get the errors for the cert as shown in the Hardenize and the internet.nl screens.
The ALIAS record resolves to the IPv4 and IPv6 addresses correctly, but loads (after falling on its face with a cert error) the main page of codeberg-test.org.

Probably easier to show in screenshots. As you can see the @ is ALIAS pointing to keepyourdataineurope.codeberg.eu - which, should the test phase move to the production server will stay the same url, even if different IP. So, this should be good and fault tolerant. But I get the errors for the cert as shown in the Hardenize and the internet.nl screens. The ALIAS record resolves to the IPv4 and IPv6 addresses correctly, but loads (after falling on its face with a cert error) the main page of codeberg-test.org.

zsoltsandor commented 2020年07月22日 23:46:19 +02:00

But if I use KeyCDN, the cert becomes more-or less dandy, with a bit of a glitch, but I still get the codeberg-test.org main page.
Thus my mta-sts.txt remains unreachable. And everything else. :(

But if I use KeyCDN, the cert becomes more-or less dandy, with a bit of a glitch, but I still get the codeberg-test.org main page. Thus my mta-sts.txt remains unreachable. And everything else. :(

hw commented 2020年07月23日 21:39:12 +02:00

The user repo name is determined from the subdomain in the request. If the request contains no subdomain, default (home) page will be rendered. For what you try to attempt it seems we would need to implement some registry of domain mappings (and some scheme to prove ownership). Ideas+contributions in this area absolutely welcome!

The user repo name is determined from the subdomain in the request. If the request contains no subdomain, default (home) page will be rendered. For what you try to attempt it seems we would need to implement some registry of domain mappings (and some scheme to prove ownership). Ideas+contributions in this area absolutely welcome!

fnetX commented 2021年04月26日 23:51:27 +02:00

Anyone who wants to add some ideas for codeberg.eu, please refer to #316 now.

Anyone who wants to add some ideas for codeberg.eu, please refer to #316 now.