Closed olizilla closed 4 years ago
We should go ahead and make Web UI and Desktop however we see fit, as those are are explicitly by IPFS for IPFS, but even so, they still must aim to be educational as they will likely be a first point of interaction for many new users.
cc @jessicaschilling
Closing, since this feels pretty baked into the ethos of our "helper apps" at this point ... but feel free to re-open if further discussion is merited 😊
I was thinking about how we reach out to other ipfs files sharing services to see how we can launch https://share.ipfs.io in a productive and collaborative way rather than just missing the fact that their are community priovided alternatives.
why do we make these apps (like ipfs-share-files) when there are community alternatives
I figured 1) it's the dweb, there should be 1000+ file sharing services 2) We do it to learn more about how the protocol should work 3) We do it demo whats possible.
...but if you were an ipfs app developer, you might not want to invest a ton of time into an idea if you thought the IPFS dev team might then build a similar thing and have their one become the de-facto first choice. But we do still need to build out apps and show whats possible. Which got me thinking...
all our apps should aim to be "educational" ...and if we can review other similar services are legit, we should also deliberately point to them from our apps, and call out what features they have that this one does not. As an extention to that, we should keep our apps focused on the simple feature sets and usecase, implemented robustly and have them link through to a walk-thru or explainer. They should be easy to use and robust apps, but also feel educational in tone.
We should make our apps as robust as well built as possible, and call out super clearly the recommended patterns of api usage that we use to make them work, so others can copy and build on them. We should be a little reserved in the features that we add, focusing on doing the basics really well, so that we can point to other apps and say "if you want feature x, try out foofiles".
Each feature we do build should be iteratated on until we think its shows a pattern of usage of IPFS that we'd recommend to others, and it should be clearly documented, either as part of the app or in a linked cookbook of common usecases, or a related proto.school lesson.
transcribed from a conversation with @lidel and @fsdiogo in #ipfs-gui on freenode.