WebUI Next - Codename Hive

[dignifiedquire]

Preparations for hive

Screens

Home

• Not very interesting or useful at the moment, what else could we show on this screen? We should keep in mind that at least 95% of all people viewing these screens will be newcomers to IPFS for quite a while, so we should optimize for those cases.

  Connections

• Improve map (no more crazy fans)
• Make peer list a table that's easy to navigate

  Files

Take inspiration from Dropbox/Finder/Explorer

• Drag n drop
• Rename
• Delete
• Pin/Unpin
• File type detection
• Thumbnails for images and videos
• Folder navigation

  DAG

• Is this actually needed? Wouldn't it be enough to have this data shown as a details screen from the files panel, and if you enter a hash in the search at the top.

  Config

• The config should not be a json object to edit, but rather toggles and input fields

  Logs

• Never worked for me once, so not sure what to do here

  Stats

• Ideas in #40

  Other thoughts

• Documentation?

  Drafts

  Connections

• V1 https://ipfs.io/ipfs/QmTr8oTzi1upsHhHoK3ixmsxosD7hFMuMgbEZSakMRbTUT

[jbenet]

Some ideas:

• Visualizing subsystems, like bitswap or DHT
  • bitswap in cli: https://www.npmjs.com/package/bsdash
  • dht visualizations could show the routing table, etc

[jbenet]

btw, am ok calling this Hive internally, but not externally. if you mean above just internally, ignore the below.

---

if you want to use hive as a concept to inspire art or naming, i disagee. this is because -- while i very much like the name + concept space -- I would like to keep the name of the WebUI in the space theme, and a name that's cohesive with other tools, and that's super obvious for the use case. Hive introduces a whole new conceptual world (colony insects, and convolved with space, the zerg, formics, etc), and i want to keep all the main products cohesive in theme and in conceptual space. this makes it easy for people to map concepts, and pick up ideas.

if looking for a name to call this, maybe since station is the desktop app:

• Control Room
• The Bridge
• Console
• HUD
• Cockpit

am sure there are more.

---

I still think "Console" or "WebUI or "Web Interface" is going to be the best, as it matches what a ton of other products call this piece of software.

[dignifiedquire]

if you mean above just internally, ignore the below.

Ignoring below, hive was just meant as a codename for the next release, not for the webui itself.

But reading below because the webui could get a nice new name. I do like the idea of calling it "bridge", but then again you are right in the sense that a lot of products already use "WebUI" and it's immediately clear. So I'm fine with just leaving it as it is as well.

[jbenet]

:+1: sounds good! :)

[pjz]

If station is the desktop app, maybe this is the web station ?

[whyrusleeping]

i'd like to see, cpu consumption, memory usage, disk usage, number of goroutines, coffee consumption, and maybe a chart of number of incoming requests per second or something

[daviddias]

I would like for it to show (on top of the ones already added on the thread):

• files I added through the CLI (not just the ones through the webui)
• be able to open DAG, @harlantwood worked in some nice D3 visualization
• able to see which nodes are close to me (through the mdns discovery), so it is easy to verify it is finding (maybe we can even add a tag to the beacon, so that everyone can customize like "David's IPFS Node")
• how long are we connected to a node and how much data have we bitswapped with that Node so far
• have bsdash be part of it (maybe an even nicer bsdash)

[pjz]

If there's a way to tell which data we're serving out is most popular, that would be cool. Maybe limit it to 'most popular pinned items' by tracking the N most popular blocks and then see if they show up as part of the refs of a pinned hash.

[ghost]

i'd like to see, cpu consumption, memory usage, disk usage, number of goroutines, coffee consumption, and maybe a chart of number of incoming requests per second or something

this we can all pull out of /debug/metrics/prometheus, given we expand the CORS headers to /debug

[dignifiedquire]

this we can all pull out of /debug/metrics/prometheus, given we expand the CORS headers to /debug

We can already get from diag/sys

• num goroutines
• disk usage (of the machine)
• memory usage (of the machine)

[dignifiedquire]

I've started work on https://github.com/Dignifiedquire/js-ipfs-event-stream which will provide a stream of all data I can get from the ipfs node (log/tail, diag/sys, diag/net for now)

[alexmingoia]

I'd like to propose using "hive" as an opportunity to modularize webui pages into components that can be embedded into other projects such as station.

• Setup a branch webui-hive with a scaffold for tests and builds with webpack (#87, #38).
• Scaffold an application to plug these modules into, consisting of layout and navigation using the design from this connections mockup. Along with error handling and loading indicator components (#81, #49).
• Build out each page described above as a module: Files, connections, node stats, config, and logs.

I'd like to setup the new application scaffold and start the file module in the next sprint. Then finish files in the sprint after that. Then peers, node stats, config, and logs. Package that as the next release and go from there.

The files module would have everything described above, be usable inside electron for station, and build off of ipfs/file-browser.

Thoughts?

[fazo96]

@alexmingoia it would be very cool to have React components or just javascript modules that take an instance of the IPFS API as parameter. It would make developing new web apps easier, for example I could integrate them in my ipfs-boards

[dignifiedquire]

@alexmingoia what you describe in terms of modularization is very much part of the goal of the next steps for the webui. I haven't written this down in full details but if you want to work on this it would be very much appreciated. A couple of things I wanted to use

• Use webpack to build each part of the webui + a wrapper with navigation
• Each part should be setup as a react component so it can be easily integrated and reused
• Use babel for transpiling all nice ES2015 & beyond features
• Do async using async + bluebird (http://babeljs.io/docs/plugins/transform-async-to-module-method/ and http://babeljs.io/docs/plugins/syntax-async-functions/)
• hot reloading of all the things using https://github.com/gaearon/react-transform-boilerplate
• Linting using eslint + babel-eslint + esling-config-standard
• In general pretty similar to the setup used in electron, just for the browser, except for radium I'm not a 100% sure this is the way to go
• Remove jquery (this is important for me)
• If bootstrap is used, use something like https://react-bootstrap.github.io/ and not plain bootstrap

Sorry if this is a bit random, just trying to get everything down so you have an idea what's floating around in my head. Please let me know what you think and don't hesitate to ask questions. Also it would be good if you could join our video sync for Apps on IPFS on Monday: https://github.com/ipfs/pm#stage-2-sprint-discussions as this is a good place to discuss and plan some of these things.

[harlantwood]

Curious to hear more about your thoughts on (no) jquery.

Sounds like a great list with a lot of experience behind it.

[fazo96]

@harlantwood my opinion about jquery is that it's a huge set of functions and pretty heavy on the bandwidth while the app probably uses a low percentage of the actual code in it. For most of the stuff that jquery does, there's usually some other modular library that does it better with fewer kilobytes, like zepto. Also, since it looks like we're already using React, I don't think jQuery has anything to offer.

Of course this is my opinion and a subjective view.

For bootstrap, most of the time less than half of its actual code is used, so I'd suggest including a tool that removes unused css somewhere in the build system.

[dignifiedquire]

Curious to hear more about your thoughts on (no) jquery.

I'm not in general against using jQuery, but this is a react app, so using jQuery is like trying to build a house out of Lego and suddenly throwing around a hammer.

In some more objective terms

• File size. React is already a large library so using two large libraries is impacting the file size quite badly.
• Unpredictable interactions between react and jQuery. Given that react does some very specific things in keeping a virtual DOM and doing DOM diffing you really shouldn't mess around the DOM with jQuery (same goes for manual DOM manipulation without jQuery) or else unpredictable things can happen (best case bad performance, worst case everything breaks down)

[doesntgolf]

@Dignifiedquire I'm not super familiar with either the WebUI or React, but react-lite might be something to check out. It's supposed to be a drop-in replacement for React, just without server side rendering. It's apparently quite a bit smaller.

[hacdias]

WebUI Next? See #749!