-
Notifications
You must be signed in to change notification settings - Fork 490
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
feat: peers table enhancements #1616
Conversation
@lidel and/or @rafaelramalho19 -- I realize it's a stretch to get this into 2.11, but wanted to at least stub out something that would be easier to wire up in 2.12. Happy to plug away at any guidance you might want to give yourselves if that's easier than just asking you to do it. 😊 |
Sidenote: when we ship these improvements we should also update geoip database (idea how to do this faster: ipfs-shipyard/ipfs-geoip#68 (comment)), because the moment we bring people's focus to the Peers screen, they will notice faster-than-lings pings ;) |
Wired up copying: I realized showing the green snackbar was not the best UI for providing feedback, especially when details behind each cell can be copied separately. After some trial&error I implemented something different, a form of in-place confirmation: IMO its less noisy, and more intuitive for this specific UI, but lmk your thoughts @jessicaschilling |
@lidel - great idea! |
@lidel One quick thought - could we shorten the dwelltime of the phrase "Copied!"? 2sec should be enough. |
Quick note on unblocking 80% of this PR:
Note: a better course of action may be to close this PR without merging, and open a new one, porting only the minimum set of features that work. |
For now we show them in tooltips, will be refined later
This ensures users do lookups as soon as we ship the latest version, without waiting 1 week for old cache to expire.
Sadly I was not able to make things performant enough: - in/out adds 1 HTTP request PER peer (and cant be cached as it is dynamic) - agent also adds one (but could be cached) We need better API than HTTP, maybe RPC over websockets or pubsub. To salvage this PR I replaced mentioned columns with open libp2p streams, which does not require any additional requests, but is pretty useful, gives us insight if peer was used only for kad DHT, bitswap, pubsub etc.
d57d150
to
8510d39
Compare
@jessicaschilling sadly I was not able to make things performant enough to run decently on low-power machines:
We need better API than HTTP, maybe RPC over websockets or pubsub. To salvage this PR I replaced mentioned columns with "open libp2p streams" column, which does not require any additional requests, but is pretty useful, gives us insight if peer was used only for kad DHT, bitswap, pubsub etc: Mind doing quick 👀? |
@lidel Works for me. Two thoughts:
|
Thanks! Should be ready:
|
Summary
This PR stubs out but doesn't finish #1602. All elements are on the page, with dummy values and visual styling as outlined in #1602, but the following still need to be wired up:
"In/Out" column:
rateIn
,rateOut
,totalIn
,totalOut
inpeer-locations.js
to display in table body and hover state--
ifsum(TotalIn, TotalOut)
= 0"Peer ID" column:
"Connection" column:
direction
to the hover text as such:/multi/addr (outbound)
(note this doesn't appear if using js-ipfs)"Agent" column:
agent
inpeer-locations.js
based onAgentVersion
(viaipfs id <PeerId>
)DHT
,Bitswap
(note this doesn't appear if using js-ipfs)Screenshot