We're approaching the point at which we can start building a new WebUI, using the existing WebUI as a working prototype for what we want to build.

I'd like to put forward some suggestions for your approval for how we build the new app in terms of the tech we use and how it's implemented.

Styles

As a team I believe we're already sold on atomic styling as a methodology and have already used Tachyons on public Protocol websites, within Companion and Desktop as well as Tachyons inspired atoms in ipfs-css.

The existing WebUI uses Less CSS, but using Tachyons largely removes the need for it and means we'll not need a build step to transpile it - hooray!

Frontend framework

I think it's a good idea to stick with a framework that's well known and widely used. The WebUI will have a lot of exposure to users through being bundled with go-ipfs (initially at least) as well as being used in Desktop and Companion (in the near future) so keeping the barrier super low by sticking to familiar concepts and ideas will encourage the community to invest and contribute more readily.

The existing WebUI is built with React, but I'd like to suggest using Preact, which is an alternative and largely compatible with React and has a much smaller file size.

I think the drastically smaller file size is more than enough reason to at least try Preact, and if we encounter significant issues then we should be able to easily switch back to React.

State management

Currently the WebUI is using Redux to manage global state and Redux Saga to create and execute asynchronous actions. I've used Redux in quite a few other projects. There's a ton of benefits but what I love the most is that it makes your actions and components much easier to isolate and test. I'd like to continue using something like this to manage state.

A common pain point with Redux seems to be the amount of "boilerplate" code that has to be written to reduce state and create actions. I'm mildly in agreement with that sentiment so I'm in favour of trying out something new but similar.

I feel that Redux Saga is difficult to understand initially, and that doesn't further our goal to encourage community or even team contributions. In my opinion, async/await is a easier concept to understand than generators and having seen both these language features come into existence the sense I have got is that async/await is much more popular and accessible within the javascript community.

@olizilla suggested unistore as an alternative to Redux. It's a tiny library (650b) and it allows you to create async actions (using async/await) by default. I'm totally up for giving it a shot.

Routing

TLDR;

I think we can just use react-router or preact-router depending on the frontend framework. Sadly we'll have to use hash based routing for the time being. There's no progressive web app generators or routing libraries I know of that don't have issues with routing relative to a particular directory.

Routing backstory

Initially @olizilla and I were thinking of a hash per section e.g.

https://ipfs.io/ipfs/Qmhash0 # ---> home
https://ipfs.io/ipfs/Qmhash1 # ---> mfs explorer
https://ipfs.io/ipfs/Qmhash2 # ---> ipld explorer
# ...etc.

...because we could upgrade sections independently.

However that makes single page app routing difficult (impossible?). We could link to these pages individually, but it would cause a full page reload...

Instead I'd have liked to do:

https://ipfs.io/ipfs/Qmhash/
https://ipfs.io/ipfs/Qmhash/files
https://ipfs.io/ipfs/Qmhash/ipld
# ...etc.

...but off the shelf routing libraries want to assume you're working from the root of a domain, not a subpath, so it means that things might work here:

https://webui.ipfs.io/
https://webui.ipfs.io/files
https://webui.ipfs.io/ipld
# ...etc.

...but not at the aforementioned hash from a gateway.

I'm interested to hear recommendations for routing libs that might allow for this (maybe we should just roll our own) so in the interests of getting things working I suggest we just use hash based routing for now:

https://ipfs.io/ipfs/Qmhash/
https://ipfs.io/ipfs/Qmhash/#/files
https://ipfs.io/ipfs/Qmhash/#/ipld
# ...etc.

Transpiling

The current WebUI is ES2015+ and I'm happy to stick with that. We have to transpile JSX anyway (assuming that we want to use JSX) and so we might as well take advantage of ES2015+ features :D.

I'd like to ensure we include a class fields transform so that we don't have to do any manual binding of instance methods, so we can easily define static class properties and so we can avoid a bit of boilerplate writing constructors to create default state.

Linting

I'd like to use standardjs for linting as I've found that it has sensible defaults and is good at catching common mistakes before runtime. I have no desire to configure and maintain a custom eslint (or similar) and considering standard is in use by many other JS IPFS projects it makes sense to stick with it.

Bundlers

I find webpack config confusing and I'm much more inclined to just use browserify to bundle up our codes. I was hoping we'd be able to use factor-bundle (as we have done on a bunch of the Protocol websites as well as in Companion) to pull out common dependencies but hash based routing means that we'd just have to load everything anyway since everything is served from the root of the application.

Do people have strong feelings about using webpack or other (rollup‽)?

Testing

I'd like to see good test coverage from day 0. I'm well aware that the vast majority of IPFS projects use mocha but I'd like to throw in my preferences for consideration:

I've always been a fan of tape but nowadays I've been leaning more towards ava since it's like tape, but concurrent tests, promises support and you can write tests in ES2017 out of the box.

For coverage I've switched to nyc, which is basically istanbul but with concurrency support.

I want to have e2e browser tests, but I'm just so disheartened with selenium based browser testing frameworks. Is there something better than nightwatch.js? Is there any selenium alternatives that have some traction and are maintained?

Build tools

AEgir is the obvious choice, but proposals above for bundling and testing are at odds with what AEgir provides. Shall we just use AEgir? I'd prefer to use browserify but it's not the end of the world if we use webpack and likewise for mocha.

Otherwise, I'm an advocate for no build tool and just npm scripts. @olizilla and I have been using npm-run-all quite extensively and with great success but I have been getting frustrated with ordering and dependent tasks. I basically want to be able to define dependencies (other npm scripts) that need to execute before mine does and have the library figure out what the ordering should be. Kinda like async.auto. @olizilla pointed out that I was describing makefiles so I think we should just use make (which we have done already in IPLD website IPFS website and others). That said, make is not platform independent - Windows users might have a bad time.

I'd like to hear your thoughts and if I've missed anything! Lets build glorious future together 🚀

April 2020 update

Let's use this issue as a placeholder for future work on component-izing UI elements (including documenting them, style-guide-wise) in a manner that can easily be reused by all our helper apps as well as anyone else who'd like to build on the core IPFS look and feel.

Note: this should probably end up with its living home in the IPFS UI Style Guide. See issue ipfs-inactive/ipfs-ui-style-guide#2 (closed in favor of this meta-issue).

Original issue text follows:

Over the last week, I opened some issues, PRs and a repository. All about the same thing: reusable components. And I'm opening this issue to get a central point to discuss everything about this and define priorities and goals.

So, first of all, the references:

• ipfs-desktop
  • ipfs/ipfs-desktop#596
• ipfs-webui
  • ipfs/ipfs-webui#616
  • ipfs/ipfs-webui#618
• ipfs-react-components: https://github.com/ipfs-shipyard/ipfs-react-components

@akrych published the first Web GUI Kit on #7 yesterday and it is amazing and there are some things I want to get clear before moving more than I've moved.

During the last week, I fixed some stuff on Desktop, but it was on the PR related to the components so this won't get merged soon, but I am proposing the following.

About IPFS Desktop

This will be the priority for now. @akrych will start drawing some wireframes for it and we can start implementing the new UI on it right after. I started using the ipfs-react-components library on the PR I created (ipfs/ipfs-desktop#596) but I'm thinking about moving the components to a directory on IPFS-Desktop or use a Git Submodule.

Why? There is an issue with Electron Forge and it is making it very hard to deploy and develop faster since I can't link the module.

Steps I suggest to do:

1. Move the ipfs-react-components components again to IPFS-Desktop repository.
2. Fix the issues I've got listed on ipfs/ipfs-desktop#596.
3. Implement the new UI scheme and during this part of the development, always make the components the more abstract as possible so they can be easily moved to a shared library.
4. Make this awesome!

About IPFS Companion

Since I'm not really into IPFS Companion, I'd like to ask you what do to next here 😄 /cc @lidel

About IPFS WebUI

After having IPFS Desktop with a nice UI and UX everyone agrees with (as you said @olizilla), we can move to IPFS WebUI. I was taking a look at the OKRs we've got defined for this quarter and saw this:

ipfs-dashboard is built as a reusable replacement for ipfs-web-ui

It was classified with priority 4. My suggestion is to forget the PR I started (ipfs/ipfs-webui#618) and start working on ipfs-dashboard using the new elements and the new UI. And, when it gets finished, we can replace IPFS WebUI by IPFS Dashboard.

About the Reusable Components

So, as you all probably know, I created a repository called ipfs-react-components and I was very happy because it was all working. But now it seems it was slowing me down a bit. My suggestions here are to:

1. Wait until we have the new GUI Kit implemented on ipfs-desktop.
2. Then implement this elements and move some of the other reusable elements created on ipfs-desktop to that repo.
3. Then, use it during the development of IPFS Dashboard.

In the meanwhile, all the components we make should be "stupid" components, I mean, they don't need Electron's or the browser APIs to work. They receive information and they just work.

What do you all think? Let's make this clear and move forward fast. 😄 Sorry for not having this clear yet.

I had an opportunity to talk with enthusiastic non-technical person and she asked interesting question: "sounds cool, but after I install it, how can I control how much disk space IPFS can use?".

AFAIK right now one can set StorageMax via commandline or by editing JSON at http://127.0.0.1:5001/webui/#/config:

I think we can agree that editing JSON by hand is.. not the best UX :) There is a real need for simplified and intuitive UI for setting selected configuration keys, StorageMax being the most obvious one, Gateway port being another one. Less is more. It is ok to have UI only with a few settings, leaving the rest to commandline or "Advanced Mode".

Open Questions

• Which configuration keys should have UI for setting them?
  What is most likely changed after installation?

• Should we leave option to edit full config in JSON format?
  Perhaps it could be initially hidden under a button saying "Advanced Mode" or something like that.

Idea extracted from: #34 (comment)

• we have ability to expose a mutable folder under permalink /ipns/<KeyID>
  • there is an option to create as many keys as you want, so we can have multiple mutable folders
  • this could be complimentary way of sharing things that require more dynamic approach than "sharing static snapshot"
• it could be integrated within File Browser as a "special folder" (or as a badge on any folder)
  • context-click on folder, select "Publish as a live folder on IPNS"
  • is is extremely important to get UI right, and make it super obvious that the folder shared this way is mutable

Open Questions

• how to name/present this feature to differentiate it from static sharing of immutable /ipfs/?
• what happens with a key when "shared live directory" is removed from MFS?
• are we able to watch MFS directory for changes in an efficient way?
• how long IPNS address will be valid without reproviding? Should we communicate it to the user?
  • eg. I share from my laptop, then close it and go for 3 day vacation.

One of the points brought up during the kick off call is what tools and services to use to collaborate in this project.

Historically, we have used at Protocol Labs a waterfall style where:

• One of us brain dumps the idea for the design (in a very comprehensive way) - Github issue
• Wireframe gets created and iterations start to happen - Invision or Zeplin
• Design and Content gets created - Invision or Zeplin
• Code gets written

This process is not set in stone and I would love to have something that after the first launch, we can open to the community and make it easier for everyone to contribute with changes (git/github style).

What is everyone's experience? What worked really well in the past and what didn't?

What is the main purpose of WebUI, or whatever it will become? WebUI has a lot of good ideas in it, but it's due to some UX & perf issues and some missing features, I don't think it is able to do a great job yet.

Companion's purpose is clear as it is greatly limited in what it can do by being confined to the WebExtension apis. It is to integrate IPFS functionality into the browser. It can offer IPFS info to the user about content that is in the current tab, and it can provide a drop-down menu of options. Significant features (add / share file, browse files) have to be offloaded to a web ui, either custom to Companion and bundled with it (as per the current impl of file upload) or it can directly hand off to a separate app (WebUI... or possibly Desktop via protocol handlers? @lidel @hacdias is that possible?)

Desktop as a standalone app, has the most freedom in how we build it, what it does, and how it looks. We could rethink it as a minimal menubar application, with it's main purpose to keep an ipfs daemon running and indicate to the user at the OS level that IPFS is available, along with OS integration so it shows up in the native file browsers. This is how Dropbox works right now

Alternatively, we could make it a full screen, desktop app, and have it do everything (file-browser, dag explorer, ipfs node manager, PIN a dataset). This'd be more like an IPFS Workbench app (think db explorer).

There is a desire to decouple to WebUI from go-ipfs deployment, to allow us to iterate on it separately, and to avoid sending the message that people should open api ports on their own ipfs gateways! There is clearly a desire for an IPFS node management app, that let's a gateway admin see what's going on with a given IPFS node. But we could rethink that as a single app that could be pointed at any IPFS node (there is a missing authentication story here, but we should come up with with the best apps we can think of and then describe what's needed to get there, and bump the priority on issues we need to fix to make it happen)

Background

Feature request spawned from discussion in #9:

Should we implement an OS integration, so you see IPFS files in your preferred file browser?
– @diasdavid, #9 (comment)

It's worth pointing out at this juncture that Dropbox has a web based file explorer as well as a native integration.
[..]
it makes sense to have a native integration to avoid alienating those users who don't understand "where the files are going", [..] familiarity is the really big one - Using something you already have (the native OS file explorer) but with extra bells and whistles is probably way easier than learning a completely new app. I'm speculating that most people nowadays are comfortable using their native OS file explorer and I reckon that's probably what Dropbox also gambled on (ahem, researched well ;)). Dropbox is pretty popular and in my experience seems to be understood well by most people technical or not.
[..]
There's also the reason that IPFS has already done a lot of low level work to expose itself as a regular Unix filesystem. It seems rude to not take advantage of that when it's so easy to do so.
– @alanshaw, #9 (comment)

Work towards native OS integration

Open Problems

• research if FUSE is a silver bullet for targeted platforms
• research how to add context actions to native file managers
• address key pain point: many FUSE libraries don’t support file locking, which many native apps rely on

Rules of Thumb

• make sure experience is seamless and intuitive on OSX and Windows (the biggest GUI-oriented user base)
• when in doubt, follow patterns established by things like Dropbox to decrease cognitive load on newcomers
• things that can't be supported via native integration can be delegated via context menus to web-based counterpart

Prior Work

• https://github.com/mafintosh/fuse-bindings

FUSE on Windows: there's a nice package called Dokany which allows us to use FUSE bindings on Windows.
– @hacdias, #9 (comment)

As for native integration, I wrote something a while ago for myself and put it up here
https://ipfs.io/ipfs/zDMZof1m1fX98cTLyC2VLe9iDQQhWgDLu5foshBSsxSWHQNuiyYV
It's a glorified wrapper for ipfs.exe and a bridge between the Windows shell.
– @djdv, #9 (comment)

@akrych while you review the multiple UIs, could you start porting the current WebUI to https://app.zeplin.io/project/5a32d45d1a17248135241058 in a WireFrame format so that we can use it to do design brainstorming.

Make sure to go through https://docs.google.com/document/d/1HzwTYo4BDDH4WIh0EULh0U9_WnT84FacDUdVtTExluQ/edit#heading=h.a415cvyt09h4 and also check out the alternative version ipfs/ipfs-webui#229

Another take on "mutable sharing" (other being #52) is bi-directional exchange space in which all parties can add files (and organize them in directories!).

This could be useful collaboration tool, think http://hackmd.io/ but for file sharing.

Prior art:

• open exchange files example from js-ipfs repo in two tabs (PR, here is WebRTC version – may crash browser)

As per our roadmap (#47), the next step to take is to create the wireframes for WebUI and then build it and make it awesome. So, I decided to open this issue to list the current features of WebUI, some suggestions and inspirational dashboards.

Current Features

• Node informations such as:
  • ID
  • Public Key
  • Addresses
  • Location
• Peers:
  • Number os peers
  • Information about peers
  • A globe showing their location (this globe consumes a lot of GPU and makes the page very slow on not so fast machines).
• A file browser to add, remove, rename and manage MFS files.
• Preview files (music, video, images and PDFs).
• Page to edit the node settings.
• Object explorer (see #11).

There is also a logs page, which is not directly accessible through the sidebar, but you can to its URL (/logs). It's a bit buggy and can even block the page due to the huge amount of requests it makes.

Suggested features

It's true that WebUI has some interesting features, but it could be a lot better. Let's see some things I'd like to see in WebUI:

• A new name. I know this is not a feature, but WebUI is a weird name to call to a Dashboard like this. Please see ipfs/ipfs-webui#612.
• A page to see statistics and beautiful graphs showing the change on Upload and Download speeds and the storage and some stuff like that.
  • We could store this data on localStorage so every time the user loaded the page, we would have something to start the graphics with.
• A way better file manager where we can move, download and copy files with better previews.
• The brand new IPLD Explorer.

ipfs/ipfs-companion#418 adds Protocol Indicator to Location Bar in Firefox.

Initial implementation looks like this:

• no icon – regular non-IPFS resource
• grey icon – valid IPFS resource, but loaded from a public gateway (via HTTP)
• aqua icon – IPFS resource loaded via user's custom gateway (aka "actual IPFS was used")

Is this clear enough, or should we create custom icon for public HTTP gateway (half-aqua or something)?

If we create something custom for transport indicator, icons should feel native, blend-in and support for dark/light themes in Firefox.

Together with @olizilla we've identified some UX challenges related to sharing files via IPFS (#34), and one of ideas was to provide an opt-in trust-based way for a group of friends to participate in a "pinning buddy system".

Disclaimer:

This may exist in some shape and form already (see Prior Art below), this issue is just a placeholder to investigate UX around making it work for casual users with minimal friction possible.

Use Case

"How to keep shared content around when you shut down your laptop?"

Things like Filecoin or commercial pinning services are one way to solve pinning, but hobbyist users and developers may not want to go that route.

UX of Pinning Buddy System

Rough idea is to provide a super easy way for group of people to opt-in to a scheme where they pin each others pins without any money/goods being exchanged in the process. Think "group of friends", "small software house" or "members of local hackerspace".

How we can make the processs as simple as possible?
Ideally, it would be one-time opt-in that looks roughly like this:

• generate unique secret/key (pubsub room id?) for the group
• share it between your friends (IM, email)
• everyone adds it to the config of own IPFS node
• from now every pin made by a member of the group will be automatically advertised (eg via pubsub) and all group members will preload/pin it in best-effort

Security Considerations

• It should be explicitly documented as trust-based alternative to things like commercial pinning services. It means, you trust every group member with the knowledge what are your pins.
• Should opt-in have an open or closed characteristic?
  • open: new members just add the same key (probably better UX)
  • closed: adding new member requires everyone to switch to a new key (better security, as it would enable things like key being a product of PeerIDs of all "whitelisted" members)

Prior art

• https://github.com/ipfs/ipfs-cluster (Collective pinning and composition for IPFS)
• http://mars.i.ipfs.team:9444/ (manual gx package pinning)
• https://github.com/BrendanBenshoof/cachewarmer/ (opt-in cache warming, seems to be dead, but provided "buddy system" feel we aim for)
• https://github.com/ipfs/pinbot-irc (a bot for the ipfs irc channel that pins things)
• https://github.com/tableflip/ipfs-friends

Hi all! I'm thinking that now that a team is assembled and we have identified goals, it is a good time to move this repo into the open so that others can subscribe to it. What do you think?

This is a placeholder issue for us to have this discussion.

@olizilla and @alanshaw brought up a ton of valuable points to the discussion, some of them were focused on the lack of Style Guide and Language.

@olizilla @alanshaw, mind sharing a recap here?

it would be good to have a font that can be used for fancy headers across ipfs-companion, ipfs-desktop and ipfs-dashboard, and any other ipfs apps.

https://ipfs.io currently uses Brandon Text - https://www.myfonts.com/fonts/hvdfonts/brandon-text/

Who is the license holder for the copy that is currently used on ipfs.io?

The license is here: http://www.myfonts.com/viewlicense?type=web&buildid=3229221

The license seems pretty standard, but somewhat restrictive:

Use of the Licensed Web Fonts with technologies other than @font-face, such as sIFR, Cufón or Typeface.js, is not allowed.

You must retain the page view tracking code, as supplied in the Web Font Kit, on all Websites that Use the Licensed Web Fonts.

The Licensed Web Fonts may be used on any Website owned or controlled by you (subject to the next bullet point). The total traffic, measured in page views, of all Websites Using a Licensed Web Font must be no greater than the number of page views specified in your account at located at www.myfonts.com

At time of purchase, it seems that number of page views specified in your account was set 10,000 / per month

Settling on a more permissively licensed font would be great.

per @lidel's comment, would I be able to get access to the Zeplin project? (my Zeplin account is hearcomestreble gmail.)

thank you in advance for the help!

Let's get Agatha using all of the tech we create :)

Let's also use this as an experiment to get feedback from a user trying them for the first time. For this I ask:

• @lidel can you guide Agatha on installing ipfs-companion. Perhaps share links first and then if there are questions, set a quick call to answer them?
• @hacdias can you do the same for webui and station?
• @akrych can you write notes from your experience as a user? A UX review in depth.

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.

From the readme

• Design
  • Assets in Google Drive
  • Invision
    • Webui
  • Design Tools Research

The assets link is missing, and I don't have permission to view the invision for webui or the Design Tools Research.

Please can have? I am [email protected] for googly things. [email protected] is an alias for that so should work too. I'm [email protected] on invision.

All three apps provide drag'n'drop and and a file picker dialog to add a file, but there are problems with each one. What is the ideal UI/UX for adding files to your IPFS repo.

This is closely related to the next step Share Files via IPFS discussed in #34

The current state of things is described here: https://github.com/ipfs-shipyard/pm-ipfs-gui/blob/master/research/README.md#add-files

Note: This issue is part of a larger pinning service integration epic undertaken spring/summer 2020.

Pinning content is a new idea to most users, so we need to invest some energy in coming up with a good way of explaining it and helping the user build a useful mental model of how it works and why it's interesting.

A use-case for this is the data-together idea of sharing the hosting of content you feel is important. You can go to https://archives.ipfs.io/ and grab a hash for a dataset and replicate it all to your repo, to add more copies of it to the network and increase it's availability.

More simply you can use it to mark content that you think is important and you want to preserve.

On the flip side, a user should never have to think about pinning their own content. When I add a file to an app, I expect it to stay their until I choose to remove it. We need a clear mechanism to deal with managing repo-size and purging old content.

The current state of things is described here: https://github.com/ipfs-shipyard/pm-ipfs-gui/blob/master/research/README.md#pinning

Current State

It's alive! https://github.com/ipfs/i18n

• Thank you all for help and smoke-testing the setup! ❤️
• Crowdsourcing translations from IPFS Community
• Everyone can join using github account!
• Missing language? Join and request it via Transifex
• I moved docs and reading material to a dedicated project at https://github.com/ipfs/i18n ✨
  • Feel free to improve it with best practices and resources useful for others

Dear future reader:

If you have trouble with i18n framework, translation site, locale format or want to add project to Transifex please fill an issue here.

(Original issue below)

Background

References

Transifex

• Installing the Transifex Client
• Understanding .tx/config file
• Manual sync via Transifex Client
  • Using Transifex with GitHub in Your Development Workflow
    • Syncing a local project to Transifex with the Transifex Client
    • Integrating the Client with CI (Travis CI, but same will work with Jenkins)
• Sync automation
  • Option A: Automatically updating source files 👌 👌 (#50 (comment))

    Transifex will check [Github] URL for updates twice per day and if there are any changes to the file

  • Option B: set up Jenkins: Localizing with the Transifex Client
  • Option C: Setting up an instance of Txgh (third-party sync server between Transifex and GitHub)
• Neat features:
  • Translation Memory:

    Without going into too much technical detail, Translation Memory is a database of previously completed translations. Each time a translation is submitted, it's saved to this database. In the future, if a phrase similar to the original source string appears, the translation is presented to the translator as a suggestion. Let's look at an example.

  • Sharing Translation Memory across all projects (paid feature)
  • Crowdsourcing Mode (paid)
• Bonus: eye savers for night owls 🦉
  • Dark Theme for OLED
  • Geeko Dark Theme

An IPLD explorer could be hugely useful for letting people play with IPLD and IPFS to build an intuition of how it fits together.

WebUI has a DAG (IPLD) explorer. It takes an IPFS hash (also due a rename to CID) and lists out all the links or data that in the object the CID points to. In the case of a directory, you can see a list of the files it contains, and each filename is a link to it's IPLD object, allowing you drill down, navigating through the links. Where a hash points to data, the raw data is rendered in plain text.

The UI/UX should be improved but the idea is interesting, and could become a vital tool for helping people to understand IPFS and IPLD.

Project description: https://github.com/protocol/pm-ipfs-gui/blob/master/proj-descriptions/IPLD_EXPLORER.md

The current state of things is described here: https://github.com/ipfs-shipyard/pm-ipfs-gui/blob/master/research/README.md#dag--ipld-explorer

Hi all! Opening an issue here as a kind reminder for our Weekly Sync Up today. I've went ahead and created a cryptpad for the agenda -- https://cryptpad.fr/code/#/1/edit/0AusscnkNOaSznOD64ugTQ/GR44ww6gAWnepTQwC4KENE9Z --, the zoom url is the same as last week, that is: https://protocol.zoom.us/j/497645692. Add the things you want to bring up to the Agenda.

Unfortunately, @akrych is not feeling well this week and won't be able to join us.

Hey guys! I'm me, and I would like to help out with whatever needs an extra pari of designer eyes.

My background is more or less 10 years of UI/UX working on everything from marketing websites to bigger products. My last job was at https://typeform.com and now I'm working with a little bit of everything. I was involved a bit with Filecoin and Coinlist some months back too.

The past year I've been focused more on building design systems, and figuring out good ways for that to work at scale. But also working with more gritty product design work as well as marketing sites.

You can see some of my projects here: http://linusekenstam.com - Or just ask some questions and I'd be happy to try to answer them and give more info.

/ L

Following up on @hacdias' question and the IPFS in Web Browsers Working Group formation, owning this project, I propose that we only have one Weekly sync up for the Working Group and respective projects rather than multiple independent sync-ups.

The team is small now (~6 people) and a one hour long call should e enough. What do you think?

Companion redirects all 4 flavours of IPFS address to your local IPFS repo, so you get the benefit of loading content of the distributed web. It would be rad if Desktop did something similar at the OS level.

Hi all! New sync up today, the first of 2018!

Here are all the links. Please add items to the agenda as you see fit.

• Zoom: https://protocol.zoom.us/j/497645692
• Cryptpad: https://cryptpad.fr/code/#/1/edit/71JXIlyz0RusM5sfhkKFgQ/aAVKndz2rAe8A94-3r-U7m1N/
• Notes from the previous meeting: https://github.com/protocol/pm-ipfs-gui/blob/master/meeting-notes/2017-12-21--ipfs-gui-weekly-sync-up.md

Expected list of attendees:

(really need to automate the generation of this issues.. maybe Bjelkholm god hears my prayers 🙏🏽)

As we agreed earlier we need some design inspirations examples for desktop :) We have some - but I would like to invite you to search some more desktop/file applications that you like.

It will also extremely useful for me if you point shortly "what do you like" and "what do you don't like" in specific app/design. The negative examples can be even more useful for design than positive ones :) 👍

Some examples that we already mention in others issues:

Dropbox

Keybase

Webtorrent

Dat desktop

https://github.com/dat-land/dat-desktop#dat-desktop

Tranmission

Forever

ipfs/awesome-ipfs#128

File Browser by hacdias

https://filebrowser.github.io/

ETA April 2020: Let's also consider the "pinning buddy system" thoughts originally in #36 as one way to introduce Cluster concepts.

@hsanjuan made the good point that the IPFS Web UI could usefully show info about IPFS Cluster nodes if the api is available.

As we discussed about having a Cluster tab in the IPFS web UI, here are some pointers and thoughts.

• Every cluster peer exposes their own REST API endpoint (at tcp/9094 by default)
• GET /id shows Cluster peer information
• GET /peers gives an array of [/id] for every cluster peer
• API docs: https://cluster.ipfs.io/developer/api/
• Someone wrote a cluster api client already (not sure if it's complete): https://github.com/te0d/js-ipfs-cluster-api
• Regarding response formats:
  • /id /peers return https://godoc.org/github.com/ipfs/ipfs-cluster/api#IDSerial
  • /pins returns [] of https://godoc.org/github.com/ipfs/ipfs-cluster/api#PinInfoSerial
  • /allocations returns [] of https://godoc.org/github.com/ipfs/ipfs-cluster/api#PinSerial

Things we need

• Support CORS Headers in Cluster for browsers to be happy showing stuff from here.
• See my list of peers with their names and IDs (or a fancy diagram).
• Display the pin statuses (/pins), filter, sort them etc. CIDs would have links to the IPLD explorer.

...and more input!

• What extra info does cluster expose that we'd benefit from visualising?
• What blockers are there to re-using the new Web UI with cluster today?

Just to let y'all now that we won't be doing a sync up tomorrow. Enjoy your holidays time! 🎄🎇

Edit: April 2020

Placeholder issue for reviewing and acting on accessibility overall for Desktop, Companion, and WebUI. Suggest that we dig into this mid-2020 once we've got an additional round of issues for the apps overall knocked out. Please see specific issues that have been closed in favor of this meta-issue:

• ipfs/ipfs-webui#756 for existing discussion around keyboard-only navigation
• ipfs/ipfs-webui#1350 for specific user-provided guidance around keyboard nav and breadcrumbs
• ipfs-shipyard/ipfs-share-files#66 for keyboard nav in share-files app

Original issue specs

This is a placeholder issue for coming up with a strategy to tackle accessibility in our apps and documentation

The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.

Accessibility is essential for developers and organizations that want to create high quality websites and web tools, and not exclude people from using their products and services. #

Tasks

• identify potential accessibility problems in User Journey (#6)
  • create/track accessibility issues in responsible repos
    (eg. website, desktop, Companion, Dashboard)
• include accessibility tips and guidelines in our Style Guide (#7) and other materials, make sure materials themselves follow good practices

References / Reading Material

• Accessibility Resources @ w3.org
• Automation
  • http://pa11y.org, https://github.com/pa11y/pa11y
  • https://www.axe-core.org, https://github.com/dequelabs/axe-core#axe-core
  • https://github.com/github/accessibilityjs

How do we make sharing files via IPFS feel great? It's the first thing I tried to do with IPFS, and I think it's something we should invest some time into making really good.

This is closely related to "Add files" #35 and "File Browsing" #9, as you might want to add and share a new file, or browse for a file you added to IPFS previously and (re)share that.

Related issue on companion: ipfs/ipfs-companion#342

The current state of things is described here: https://github.com/ipfs-shipyard/pm-ipfs-gui/blob/master/research/README.md#sharing-files

How should we indicate to the user that they have peers. That they are participating in the distributed web with many other people.

How much info should we show about who and where you are connecting to? What can I do with it?
What functionality could we add to turn this into a great feature, or is it purely informative? Can I block or mark peers as friends (see: #36) for example? Chat? Browser files other peers?

What shouldn't we show? Is it creepy to show peoples geocoded locations from their public ip? This is related to the more general question of what ipfs node stats we should show and how #33

The current state of things is described here: https://github.com/ipfs-shipyard/pm-ipfs-gui/blob/master/research/README.md#connections--peers

Part of UX improvements for sharing local files (#342)

Idea extract from #34 (comment) and ipfs/ipfs-companion#342

Provide easy way to share secrets

• encryption and decryption happen client-side (JS)
  • use well known, audited library
• an option to encrypt content before upload via AES
  • uploader can choose enter a secret (password) for encryption or it will be generated automatically
    • ideas: it can be a "password" in proquint form, or a "key" in hash part of the URL
  • produce additional static landing page that instead of details about uploaded data prompts receipent for secret required for decryption
  • after decryption, show regular landing page (#34 (comment))

@olizilla since this was moved from shipyard I no longer have write permissions to this repository. Could you add me, please? Every time I try to do something on Waffle board, it just shows me a message saying 'Only collaborators can update cards.'.

@olizilla asked a very good question during OKR discussion:

A logo for DashboardWebUI, Desktop and Companion to give each an identity that shows they separate parts that work together?

In the last call -- https://github.com/protocol/pm-ipfs-gui/blob/master/meeting-notes/2017-12-14--ipfs-gui-kickoff.md -- we reached a consensus that WebUI needs a new name as it currently is a very misleading name or just not informative at all.

My first proposal is ipfs-control-room so that we have a:

• ipfs-station - Docking station on a user machine
• ipfs-control-room - Dashboard for the user to control its station and/or ship
• ipfs-companion (or ipfs-ship !!) - The vessel that takes you through the DWeb

In my head, it makes it a sweet evolution from the era where people Surfed the Web to the era where people Spacetravel the DWeb!

Other ideas?

There should be no friction for an app to connect to a locally running IPFS node. It's useful to be able to connect to an IPFS node running on another machine. Companion supports this now, as it used to require an external IPFS node to run, but cannot install one as it is packaged and distributed as a WebExtension.

We should consider not bundling WebUI with go-ipfs (See: #4) as it causes people to open up their api port to the public internet, which is a significant security issue. Rethinking WebUI as an IPFS dashboard / explorer / workbench app (like say a database explorer app) that can configured to connect to any IPFS node, local or remote, and have it display stats and a file browser #9 and IPLD explorer #11 would be really interesting.

The current state of things is described here: https://github.com/ipfs-shipyard/pm-ipfs-gui/blob/master/research/README.md#control-which-ipfs-node-you-connect-to

It's time to make a venue for posting content generated by researchers at PL.

I don't think we need a new domain - the most logical place to put this would be https://protocol.ai/research
I don't think we need much design - I want it to be pretty brutalist

I think it should be on IPFS
I think it should be user friendly - ideally researchers could preview and post markdown with images without needing to ask for help
I think it should also be useable on the filecoin blog, main PL blog, and perhaps even the IPFS "starlog" blog

Perhaps most importantly, this effort ideally should not cause a noticeable slow down other IPFS projects - this likely means bringing in an external individual or team.

@olizilla, any recommendations?

Background

I see an opportunity to make people familiar with https://multiformats.io

Things like CID/multihash are already present in our UIs, but we still use URL for things like IPFS API or HTTP Gateway in GUI of ipfs-companion.

At the same time, go-ipfs (commandline daemon) is already printing these addresses as multiaddr:

API server listening on /ip4/0.0.0.0/tcp/5001
Gateway (readonly) server listening on /ip4/0.0.0.0/tcp/8080

Tasks

See if below things exist and create if they do not:

• reusable converter between URL and multiaddr ?
• HTML5 comes with built-in validation for URL in input, we should create a polyfill that does the same for CID and multiformats (at least multihash and multiaddr) and can be used across all GUIs.

Go over our GUI apps and create issues in dedicated repository if there are places where we could use Multiformat but don't yet:

• Desktop https://github.com/ipfs-shipyard/ipfs-desktop
• Companion https://github.com/ipfs-shipyard/ipfs-companion
• WebUI https://github.com/ipfs-shipyard/ipfs-webui
• should we add anything else here?

Project roadmap for our IPFS In Web Browsers Working Group:

@akrych noted that we have various issues related to this, but no "meta-issue" to track progress across all repos, so here it is :)

There is ongoing work that could (potentially) benefit from a common "template":

• Display a Landing Page on New Installs / Big Updates (ipfs/ipfs-companion#324)
• Check Page for Distributed Web (ipfs/in-web-browsers#61)
• <your project, library that lacks nice landing page/template>

So far we:

• started with initial mockups for a Landing Page at WIP PR ipfs/ipfs-companion#326
• work-in-progress: ipfs-ui-style-guide – a shared style guide for UI design in the IPFS universe that extracts common visual features from prior art, builds on top of it and documents everything in reusable form

Let's keep this ticket open to improve discoverability of related efforts until we have a single template page that follows style guide and can be quickly dropped into projects (eg. static-page-demo.html in ipfs-ui-style-guide repo?).

@diasdavid are you going to create a recurring Zoom call (the same time, same link)?

cc @victorbjelkholm

What controls should an app provide for managing an IPFS node? Desktop let's you Start/stop the daemon, but WebUI and Companion don't.

Beyond that, bandwidth throttling, Repo size management would be super helpful. Why would a user want to stop their daemon process? Perhaps start/stop is less useful than actually being able to reduce and manage the amount of system resources it consumes.

The current state of things is described here: https://github.com/ipfs-shipyard/pm-ipfs-gui/blob/master/research/README.md#start--stop-ipfs-node

Examples: https://github.com/marcin212/ipfs-gui
Examples: https://github.com/bogdoslav/ipfs-windows-installer
Other solutions: https://github.com/Siderus/Orion
Items needed:

• Installer and Uninstaller
• Send To IPFS similar to Email/zip
• On-off switch and Startup Widget
• Autostart and TOR/I2P options

Just came across the research-project within this repository and came across the following in the first line:

want to make IPFS GUIs beautiful, reusable, and unified

Is this not missing the single most important part, functional / easy to use? It's great that we want to it to be beautiful, but it should be functional and easy for the user foremost.

ETA (April 2020):

This may be superseded by ipfs/ipfs-webui#1003 (dashboard-style revision of entire UI).

Original issue:

All three apps show IPFS node stats as part of the initial UI that is show the user first, at startup.

Let's identity which bits of information a useful to which users and under what circumstances. What background knowledge is needed to interpret the data. What unit should it be presented in? How frequently does the info change? Is it most useful as a current value, or is it best presented as the change over time of the value?

The current state of things is described here: https://github.com/ipfs-shipyard/pm-ipfs-gui/blob/master/research/README.md#ipfs-node-info

A pleasing file browsing is essential. People have strong opinions about how they should work and a lot of experience using native desktop file browsers on their OS of choice.

With MFS, IPFS has a filesystem api that we can map to a traditional posix / unix like filesystem. But IPFS also has additional concepts like the CID, immutability, and file sharing, content pinning that we need to find a good way to articulate to the user.

Should all IPFS apps share a common file browser implementation or should they redirect the user to an improved WebUI, so the reuse is at the application level? Should we implement an OS integration, so you see IPFS files in your preferred file browser? What does a great file browsing experience with IPFS super powers looks like?

Project description: https://github.com/protocol/pm-ipfs-gui/blob/master/proj-descriptions/FILE_BROWSER.md

The current state of things is described here: https://github.com/ipfs-shipyard/pm-ipfs-gui/blob/master/research/README.md#browsing-files