Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

".i2p" make it flexible #31

Open
Amrosx opened this issue Dec 8, 2022 · 1 comment
Open

".i2p" make it flexible #31

Amrosx opened this issue Dec 8, 2022 · 1 comment

Comments

@Amrosx
Copy link

Amrosx commented Dec 8, 2022

I was wondering if possible to modify this condition inseted of ".i2p" make it accepting any/flexible ending is that possible or has been discussed before. for example I need to set my domain ppp.y is it possible not to use ppp.i2p ?

path: i2p.i2p\core\java\src\net\i2p\client\naming\EepGetAndAddNamingService.java
if (hostname.length() < 516 && hostname.endsWith(".i2p") && ! hostname.endsWith(".b32.i2p")) {

@eyedeekay
Copy link
Contributor

Possible eventually yes, but is it reasonable right now? Probably not. There's a lot that goes into this, and maybe flexibility in our top-level namespace is a reasonable way to start, but meeting all the necessary conditions for such a thing to work is probably hard.

For one thing, just letting people set their own top-level namespaces would introduce a footgun, wherein the user would be able to replace/intercept an existing top-level namespace and MITM themselves. So it would need a way to prevent such a thing from happening.

For another, we might actually have a good reason to change namespaces in the future because real TLD's aren't supposed to contain digits, which besides... some other stuff... is a reason we can't have real TLS certificates like .onion names can. .garlic might be the obvious choice, but that doesn't satisfy "flexibility." In fact, this necessitates narrowing the flexibility of the namespace.

However, human-readable naming is really just an application extension primarily used by the HTTP proxy. If somebody wanted, they could implement their own HTTP proxy with their own ways of mapping keys to values. I've done this, so that applications can maintain their own address books. That might be the quickest way to get what you want, doing it in the core will take a lot of deliberation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants