Opened 7 years ago

Closed 4 years ago

#1355 closed enhancement (wontfix)

List of registered domains to prevent cybersquatting on I2P

Reported by: hermitcrab Owned by:
Priority: minor Milestone: n/a
Component: apps/addressbook Version:
Keywords: Cc:
Parent Tickets: Sensitive: no


Nestukuku a p2p routing system has a limit of 256 domains a user can register, i think it would be useful hardcoding a limit like that into I2P router (100?200?250 domains?).

When the user register a domain I2P could create a list where future domains would be put in. Domains could have a timestamp valid for X years (maybe 4 or 5), once the timestamp would expire the user could renew the domain or abandon it.

When the user reaches the limit of registerable domains in his list he could get a warning message asking him to delete some domains to make space for the domain he was going to register, in this way you avoid people registering hundreds (if not thousands) of domain names.


Change History (3)

comment:1 Changed 7 years ago by user

our domain name system is local to the end user.
there are subscriptions but their servers do not know your identity, and that's good.

expiring domains has pros n cons. And without it there'll always be voices urging for such a system, and with it, others would raise their hand and feel their souverainty was taken away.
Maybe the only solution is to have it optional, since domains are local anyway, and have the user decide if he keeps his domins for good or expires them after a certain time.
But certain time of what? last visit? coul be. A site I don't visit, is likely not so interesting. and if I don't like that, I disable expiring.

re cybersquatting: who comes first is served first.
As long as it's somehow useful.
What does that mean?
IMHO, the providers of naming services should:
1) check whether the registered dest is really up at time of registration
2) ideally sporadically check the dest if it is still alive, otherwise possibly stop dsitributing it after n unresponsive connection attempts on different days
3) make sure only one domain (maybe two, that'S arguable) are linked to one dest

I know, it's not a bullet-proof thing. But it's something.

if someone registered many but doesn'T service them, the naming service expires them and would make the domain available again for legit users.
The hairy thing is how to distribute the new legit dest for that domain to users?
maybe there could alwas be up to two dests in the locaal susidns or whatever system.
The old one, and potentially a new one.
if the user tries to access the site with an updated dest, a warning screen is shown, notifying of the dest change, so the user is not tricked into believing the site is still operated by the same guys as before. The user then decides whether to follow the new dest and save it, or keep the old one in case it comes back to live again.
For convenience it should also offer to backup it.
Screen similar to today's addresshelper screen.
What if several changes occured before the user tried to access the site? wouldn't then more than two entries be needed? No.
the user is only interested in the last state he knew (original one, or acknowledged change) and the now alive new addition. who came in between and went again, is not of interest, i think. so the 'old' entry gets overwritten only once the user accepts, while the 'new' entry gets overwritten once naming service subscription brings something new.

sorry, my comment got a big long.
summing up
1) naming services like stats, i2host, inr should have some countrermeasures
2) an optional local expiry of old/unused domains - also to keep file small
3) a sytem of old dest key backupped and new dest receive via subscription, with user interference to decide.

comment:2 Changed 7 years ago by zzz

Component: unspecifiedapps/addressbook
Type: defectenhancement

Not really related to I2P software at all, but to registration services. And I don't see how this is feasible anyway. There's no way to associate a destination with a user's identity. For good reason. But I'll leave open for further comment.

Candidate for "not a bug" or "wontfix"

comment:3 Changed 4 years ago by zzz

Milestone: 0.9.18n/a
Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.