This neighbor has no internet connection, so there is no way that it has metric of 0 to the exit. It should be Infinity. Looking at the console, this is a backend issue @ttk2
yes it is, we drop in 0 in cases when we can’t figure things out, obviously it should be the reverse.
But I’m going to come out and say I think the whole principle of the screen is poorly founded, the issue is that it’s a screen that determines ‘link to internet’ as the ‘link to the selected exit’ this means that if we don’t have a selected exit this screen can’t display anything useful, likewise this exits don’t advertise routes to other exits so when you have an exit as a neighbor you get this wonky situation where you’re looking for a route to your selected exit from a different exit and determine that that exit has no internet access!
Can we sit back and rethink this screen in terms of what’s really useful to people @Deborah what do you really want from a neighbors screen? Maybe survey users as to what they need.
I think that the usefulness of a screen showing connections to physical neighbors is pretty obvious. I mean maybe an in depth user study would have surprising results, but at this time it seems like a relatively safe bet and we don’t have the user base necessary to do a good study.
The ability to see which neighbors have strong connections to the selected exit is also pretty useful, since it surfaces the information that will be used by the routing protocol to select which neighbor to router through. I’ve glossed over this in the visual design as “connection to internet” but of course we can change the wording. We can have a state for this screen that tells them that there is no connection to the internet because no exit is selected or something.
This is not an issue since we will not be showing connections to exits as neighbors on this neighbors screen for much longer.
That being said this issue is in the backlog and nobody is assigned to work on it right now. Not sure how high of a priority it is. We could just remove the “connection to internet” side of the screen until it is fixed.
this would probably do the job just fine.
Ok I think I have a proper solution for this, right now the /neighbors endpoint queries debtkeeper.
If we move debt visualization over into the soon to be ready debts endpoint and then /neighbors can query against TunnelManager, Tunnel manager knows what tunnels are manual peers and which ones are not and can display a simple boolean to tell you which is which. Should be an easy re-factor but it’s last on the list of things to do in this dashboard set of changes.
I’m curious as to what happens when a neighbor who was previously connected goes offline? Will they cease to exist when they don’t pay their ip leasing fee?
Perhaps it is as useful of a function to know about what users you were previously connected with that now you are not, as to know which you are currently connected to.
When the ip leasing fee is not paid, and then has to be renewed when the user resumes payment, do they get a new ip address and would that then show up as a different user in the neighbors page?
Their tunnel will be cleaned up from the page after 15 minutes of no activity (very conservative, could be less) or if they expire their subnet dao registration they will be kicked off
Jehan and I where discussing it, it doesn’t make sense for their to be ‘late’ fees, since you could create a new identity with little to no loss in theory. So we should just let them have their old identity if they haven’t abandoned it so long it got deleted. As for when that happens, who knows.
we currently don’t keep that history but I guess we could.
With any kind of prepaid service, in my experience, the situation of running out of funds is frequent. If the subnet DAO organizers have to sign a multi-sig every time this occurs, it might be annoying. Is there a way we can hold their ip address on hold for a month or so?
The IP address will currently be held indefinitely, I’m just talking about how long it takes us to kick them off the network once they are no longer registered.
What I aiming at here is a troubleshooting tool. If you aren’t getting paid what you are expecting, a user could check the neighbors tool to see who is offline? Especially useful if you are a gateway, however, even an intermediary node may want to pinpoint where the problem occurred - a neighbor that was previously connected, now is not.
Ah I see what your getting at, we can store a history of tunnels including people we kicked off for dao membership lapse, then present that to the UI.