-
Notifications
You must be signed in to change notification settings - Fork 489
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
chore: update peers table #1062
Conversation
Some visual tweaks
Also, paging @ericronne |
Some interesting stuff going on here. Currently scratching my head and wireframing a little on this … |
@ericronne Let's chat about it on the call in a few mins! |
@ericronne nice, but the location column is a best effort, and only works for peers who are connected via ipv4 connections... we don't want to give folks who have embraced the ipv6 future a second class status in the peers tab. |
Posting quick feedback I mentioned during the call: Location and Latency columns should be next to each other. If the default sort method uses either of them, peers from the same countries will usually have similar values, which will make the latency-location link more intuitive. |
I added sorting by latency, on my fork of this branch, but I'm not sure if it makes sense to open a separate PR for it. How should I proceed? |
Identicons solve a lot of issues related to PeerIDs being super long and hard to compare. We probably need to tweak the color palette used for creating identicons, to ensure they feel as they belong to the UI and IPFS colors, but I am 👍 for adding them, especially if we move LOCATION column between CONNECTION and LATENCY – PEER ID column will look more interesting with them. @JustMaier Are we able to generate them with CSS? |
@lidel We can pull the colors from the theme.json in Here's what it looks like with the theme colors: I'm wondering if maybe it'd look better with a different style of identicon though. Here's a different type of identicon: Between the two, I think I prefer the first one though... |
@JustMaier let's move Identicon discussion to #935 to unblock this PR (if we add identicons, it should be in a separate PR) |
Thanks for this @JustMaier! I'd argue we should add the ability to sort the columns as we have in the FilesPage, I'd prefer to leave the natural sorting instead of sorting by latency by default. What do you think? |
@fsdiogo I agree. It'd be nice to be able to sort the table and it looks like it's a feature in As for default sorting, I do think that there should be some default, the "natural" sorting is just random as far as I can tell, and latency seems like a decent default since it's important to peer network performance. |
Yeah, you can either open a PR to this branch or we could merge this one and you PR That way we could open another one to add the identicons too! |
Just submitted the PR to this branch. In my opinion, the change is small enough that it should be rolled into this branch/PR. |
@fsdiogo please double check the logic for how we determine if a peer is a bootstrap node. I am connected to a bootstrap node, but it does not show up in the notes field: $ ipfs bootstrap | grep 128.199.219.111
/ip4/128.199.219.111/tcp/4001/ipfs/QmSoLSafTMBsPKadTEgaXctDQVcqN88CNLHXMkTNwMKPnu
$ ipfs swarm peers | grep 128.199.219.111
/ip4/128.199.219.111/tcp/4001/ipfs/QmSoLSafTMBsPKadTEgaXctDQVcqN88CNLHXMkTNwMKPnu |
@fsdiogo please right align the latency column so the user can visually scan the numbers |
@JustMaier very exicited to see your work on peer identity icons. In general we've been sticking to keeping PRs as small and focused as possible, even if that means having lots of small ones. We've also found it useful to keep a single contributer per PR so that each changeset has a clear owner to drive it through. We'll get this PR merged today, then we can focus on sorting and icons! |
@fsdiogo could you give some background on why we only display the country code? I'm mildly in favour of being less explicit about the inferred location of a given peer, and I still feel that it sends a confusing message to new users (is ipfs tracking me? is my node telling people where I live?) but as @ericronne pointed out it's perhaps the only information that we show that has immediate meaning to new users, and it's kinda fun to know that there are folks all over the world using IPFS. The change to use just the 2 letter country code makes the geolocation more corse grained, but perhaps Unless there are strong reasons to change the location format, I suggest we revert it the location values to how they are in the current release. |
Yeah, my main point was for privacy reasons, as you said, so the user wouldn't think we were tracking them. The other reason was to make the table a bit less wide. Alright, I'll revert to keep it as is! 👍 |
Done!
Thanks so much for your contribution @JustMaier 🙌 I agree with @olizilla, we should hold it for a minute until this one is merged, then we'll review and merge yours! |
Yeah, something is not right. What I'm doing right now is fetching the bootstrap peers that are in the current IPFS config and comparing them with the current peer being analyzed. It doesn't seem to be working because the current peer is something like
and a bootstraps is
so they never match up. Am I missing something obvious? |
The items in the array returned from
|
Something to be aware of: Ref. ipfs/notes#201, multiformats/multiaddr#34, libp2p/specs#45 |
For this check, do we want to just compare peerIds? A unique peerId could be flagged as a bootstrap node if it's peer ID matches one of the bootstrap peerIds? We'd have to slice off the peerId from each boostrap multiaddr, but then we'd just been comparing multihashes rather than needing to check for |
This is what I have right now, but it still doesn't seem to match anything: |
I'd go with @olizilla suggestion (#1062 (comment)). Just make sure you do the bootstrap check before the relay check, because bootstraps could also be relays in the future. |
@fsdiogo yep that's the suggestion. Grab the peerids for the bootstrap nodes, and compare it with the peerId of the peer. Of note, I think your proposal could work, but |
You are 💯right, calling |
Your version is fine, let's get it mergable! |
Here goes an initial refactor of the peers page discussed in #1058: