-
Notifications
You must be signed in to change notification settings - Fork 97
Create 2018-11-21--gui-and-in-web-browsers-weekly.md #771
Conversation
meeting-notes/2018/2018-11-21--gui-and-in-web-browsers-weekly.md
Outdated
Show resolved
Hide resolved
|
||
- @lidel | ||
- Done: | ||
- Moved meeting notes to [team-mgmt](https://github.com/ipfs/team-mgmt/pull/760) and added Zoom Call URL to [IPFS Calendar (UTC)](https://calendar.google.com/calendar/embed?src=ipfs.io_eal36ugu5e75s207gfjcu0ae84@group.calendar.google.com&ctz=UTC) with Oli as co-host. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thaank you ❤️
- @fsdiogo | ||
- Done: | ||
- Share Files working without public gateways | ||
- https://github.com/ipfs-shipyard/ipfs-share-files/pull/44 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw, this is kind of the same as https://filenation.io. What is different in this app that justifies creating and maintaining another codebase?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I follow the question in the image. This is not supposed to mimic a gateway, the visible url and # is for the app internal routing.
It's similar in the way that is an app to share files, yes.
- FileNation sends an email with a link where you can download the file, it doesn't provide a direct link for you to share instantly with anyone. In Share Files you get a direct link to the app where you can see the files listing and download them.
- Share Files takes advantage of a local daemon if you're running one, works great with IPFS Companion too and uses
js-ipfs
as fallback if needed. - Share Files is going to be integrated in Web UI and in IPFS Companion.
- In my opinion Share Files is a lot more appealing and ready-to-use to quickly get a link to share with anyone.
- We own the Share Files code and it's UI direction, as we're trying streamline the UI across our apps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To compliment Diogo's points, there is a relevant background discussion in ipfs/ipfs-gui#34 (Design: Share files via IPFS).
IIRC historical reasoning for ipfs-share-files was along these lines:
- It is a good opportunity for dogfooding our upload and fallback APIs (we squashed a lot of bugs while working on upload in ipfs-companion, ipfs-webui and now pushing boundaries even further with ipfs-share-files)
- Lack of a good Sharing App that "is always there and just works" could hurt IPFS in the long run because general public often associates bad UX with low quality software.
Third party solutions come and go and are not robust enough. Some require a writable gateway, use centralized backend or don't use js-ipfs fallback at all etc. - Apart from technical reasons we wanted a branded Sharing App as a platform to gently introduce IPFS concepts to the general public.
- Share Files working without public gateways | ||
- https://github.com/ipfs-shipyard/ipfs-share-files/pull/44 | ||
- Enable dir listing and downloading folder structures | ||
- https://github.com/ipfs-shipyard/ipfs-share-files/pull/47 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be cool to have channels just like the exchange files example has
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that is something that is being discussed (ipfs/ipfs-gui#52, ipfs/ipfs-gui#36) but probably will fall under the Web UI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is also ipfs/ipfs-gui#57 ("hackpad for file sharing" ) which is exactly about taking the "exchange files example", refining the UX and integrating it with ipfs-webui (directly or via ipfs-share-files).
The wow factor of doing this right could be massive. This will happen for sure, but we want to get MVP with basic sharing out of the door, and iterate from there.
- Write interop tests for CIDv0/1 put and get | ||
- @fsdiogo | ||
- Done: | ||
- Share Files working without public gateways |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could it use the Service Worker Gateway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could. Right now it's using ipfs-redux-bundle that chooses the best available connection and fires up a js-ipfs
instance as a fallback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
woa! I didn't know about that!
Can someone do a video tutorial pleaaase?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ipfs-redux-bundle is React-specific lib we use internally for R&D in WebUI/Companion/Desktop, API is not stable yet :)
In the following weeks we will extract the fallback logic into a separate, framework-agnostic lib and make tutorials for that.
Co-Authored-By: lidel <lidel@lidel.org>
Closes ipfs/in-web-browsers#133