search

ipfs / ipfs-gui

Creating standards and patterns for IPFS that are simple, accessible, reusable, and beautiful
105 stars 17 forks source link

Consider abandoning Web UI? #4

Closed ghost closed 6 years ago

ghost commented 6 years ago

We could instead ship ipfs-companion with go-ipfs and js-ipfs. There's a ton of overlap and we could avoid some of that, as well as the burden of maintenance and harmonization.

ghost commented 6 years ago

We could instead ship ipfs-companion with go-ipfs and js-ipfs

Regardless of abandoning Web UI, we absolutely should ship ipfs-companion with at least go-ipfs.

Stebalien commented 6 years ago

It's a desktop app, right? That'll increase the distribution size significantly. The WebUI is nice because it can be fetched on-demand.

On Thu, Dec 14, 2017 at 5:47 PM, Lars Gierth notifications@github.com wrote:

We could instead ship ipfs-companion with go-ipfs and js-ipfs

Regardless of abandoning Web UI, we absolutely should ship ipfs-companion with at least go-ipfs.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/protocol/pm-ipfs-gui/issues/4#issuecomment-351785509, or mute the thread https://github.com/notifications/unsubscribe-auth/AAS8eWR3NgLBG1vCYvPi9lZNe98bQVdpks5tAV8tgaJpZM4RCbht .

victorb commented 6 years ago

we absolutely should ship ipfs-companion with at least go-ipfs.

How would that work? Ship the installation files of the extension? I think both Firefox and Chrome forces you do jump through additional hoops if you don't install from their extension "stores", which makes the installation process a bit more complicated.

daviddias commented 6 years ago

I'm not sure if I can see what is being proposed here:

Are you switching them up?

ghost commented 6 years ago

(I didn't read up on what new names you came up with in that call today.)

Are you switching them up?

Nah.

I was just thinking maybe we could live with just 2 of the 3. They all have more overlapping features than distinct features. This probably originates from their organic growth over the course of the last few years. There was never really a cohesive plan of which ground each of the three apps should cover (aka design). Before we sink time and attention into it: is there a plan now? The triangle in the readme isn't very convincing to be honest :)

The Web UI came to mind because 1) it can't be updated independently of go-ipfs, 2) it's current deployment is a huge hack, and 3) it kind of encourages people to open up the API port 5001 to other hosts (I stopped counting how often I told people on IRC not to do that).

we absolutely should ship ipfs-companion with at least go-ipfs.

How would that work? Ship the installation files of the extension? I think both Firefox and Chrome forces you do jump through additional hoops if you don't install from their extension "stores", which makes the installation process a bit more complicated.

Yeah forget what I said for now -- I still think it's an idea worth evaluating, but I don't wanna clutter up this issue.

hacdias commented 6 years ago

Just some random thoughts on this: what if Station could literally be a station? Despite its functionality as a menubar application, it could also be a full fledged desktop application where you could control your IPFS node, update the ipfs version, and so on, replacing the WebUI.

daviddias commented 6 years ago

@hacdias the reality is that given that Station is an Electron App and that WebUI is just a browser page, you can spawn an Electron page that looks like a native app that is just that Web page, making station feel like a fully fledged desktop application.

@lgierth got it. I was missing your point because as @VictorBjelkholm pointed out, we can't install a browser extension on people's browser by installing a binary.

victorb commented 6 years ago

Something that might work would be to move webui into something like ipfs-ui, and have it load in the browser just like it works today with go-ipfs, but also load it in ipfs-station. ipfs-station and webui would have the same UI and the same functionality, except webui only connects to external nodes (not bundled) and ipfs-station ships with a go-ipfs node.

That way, we can keep webui functionality (drag and drag files in browser with go-ipfs for example) and station, while only having to develop and maintain one ui.

ghost commented 6 years ago

But do we want to maintain a management web app while also maintaing a browser extension and desktop app with the same functionality?

victorb commented 6 years ago

But do we want to maintain a management web app while also maintaing a browser extension and desktop app with the same functionality?

My argument was that we could maintain one UI + wrappers + extension way easier than maintaining two UIs + wrappers + extension, while keeping the same functionality as we have today. Many folks appreciate being able to use the webui without any bloaty desktop applications + if we in the future have API tokens (or with ssh today) you can access a nice UI for your remote daemon with very little effort.

More of a personal argument but I prefer applications that can work directly in the browser as it's easier to install, update, takes up less space and I basically live in the browser already. Although, I can see the value for other people to have a desktop application.

olizilla commented 6 years ago

This was a key question that came up in the meeting. We can take a moment to review the role of webui, companion and dashboard and figure out which chunks of UX can be re-used, and which will have to be duplicated because of the specific needs of desktop/addon/webui.

I feel like there is growing support for re-considering station as the default ipfs installable that we point most users to. It can be responsible for integrating ipfs into the users live in a visually pleasing way (so they want to use it) and it has the option of installing the command line version, and potentially provide a bridge to the connectNative api in the addOn, so a user could choose to manage (start/stop etc) their ipfs node from either the system tray or the browser.

I think it's useful to have a web app that provides a dashboard for the ipfs in command line flavour, but it's worth reviewing in terms of how we might share chunks of it with os integration.

I think we need all 3 parts. The command line tool benefits from the existence of the webui, as it is (currently) commonly used without any other app. The os integration would be the obvious place to put more edcational / onboarding content and to do a load of work on making the UX super nice and explaining what ipfs does under the hood for those that are interested. I'm pretty sure we need the add-on in order to get push towards a seamless experience of using ipfs as part of your daily life on the web.

lidel commented 6 years ago

A lot changed since December. Namely, window.ipfs got introduced and it is slowly changing the way we think about building things that use IPFS API.

Closing this one, as follow-up discussion continued in https://github.com/ipfs-shipyard/pm-ipfs-gui/issues/41. tl;dr starts from https://github.com/ipfs-shipyard/pm-ipfs-gui/issues/41#issuecomment-374775995