-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create interactive ecosystem directory #61
Comments
Update, 23 Feb 2021
|
Call: Requirements and PrioritizationRefined requirements to include the following:
Next Steps:
|
Update, 5 Mar 2021We had a touch point today where we honed details in the context of low fidelity designs.
Next steps
cc: @jessicaschilling & @D3AS8A |
Stack discussion@jessicaschilling I'd like to start an exploratory discussion here about an alternate stack—still based on Vue. We've been talking about the potential upside of using Vue/Nuxt in place of VuePress for this project. Platform Nuances
DistinctionsSince the IPFS ecosystem is interactive, a great deal of the functionality isn't really content or page-based. Instead it's state-based (i.e., what's the state of a series of filters and other user inputs). The benefits of using Nuxt are:
The VuePress docs themselves have a section about Nuxt, where they stipulate when it's better to use VuePress:
In other words, while Nuxt has a static mode that's comparable, it behaves more like an application. VuePress is designed to behave like a content website. |
[FEEDBACK REQUESTED] @zebateira @jdiogopeixoto @cwaring -- I mentioned @orvn's comment above in our ipfs.io replatforming discussion in ipfs-inactive/website#412, but want to confirm that none of you have any issues with the directory being built on Nuxt as part of a larger IPFS/PL website ecosystem. Can you please weigh in? @orvn -- please note that the same requirements of the "teaser" version to be embedded in various external sites still apply. Correct that this platform decision would have no impact on that work? |
@jessicaschilling it would actually the embeddable piece easier to implement. I mentioned this above, but I didn't use the word teaser (see |
The only reservation is regarding the IPFS requirement, if the end static application is required to run at both root domain (app.website.tld) and gateway access (gateway.ipfs.io/ipfs/cid) then this needs to be evaluated first. |
The legacy Slingshot site (which is on static Nuxt) does get served up by that path: gateway.ipfs.io/ipfs/Qmf3...HortQf Except none of the relative paths for resources work because those are separate CIDs. Does this help shed light on anything @cwaring? |
Actually you may not be aware of the background behind this. In the past if you were using the IPFS browser extension then you would get redirected to a gateway url whenever a Thankfully we now have a root origin support in IPFS so we can access any site from b32cid.ipfs.dweb.link or b32cid.localhost so this doesn't break websites. However for legacy support many gateways still only support /ipfs/cid access so all of our primary websites are designed to work in both scenarios. It also means you can Our VuePress implementation works for both these cases so it would be nice to know if Nuxt can do the same. Webpack sites often have trouble due to dynamic requires and forced absolute paths in the build output but it is possible to hook into the config and dynamically configure the basepath for webpack and vue router. You can see an example of how I did that here: https://github.com/cwaring/vuepress-plugin-ipfs Being Pragmatic and given that this is no longer a critical breaking feature I personally wouldn't say it's a hard requirement, however this should be established early on with whoever is signing this project off because it might not be possible to implement at the end. If you know a way that Nuxt does this out of the box then we have all bases covered! Keen to have your input around this. |
Understood @jessicaschilling, will look into viability and find out if this is a blocker. At the moment I'm optimistic (I suspect it's not a big hurdle).
Ah, you're totally right. I didn't know about the legacy behavior. Thanks for explaining.
For our part of the build process
Thanks! I'll have to read some IPFS docs and test a few things, but this does feel like the kind of thing that's doable for nuxt as well (without taking up excess time). |
Great! I'm also starting on a Nuxt app this week so I'll see how elegantly it can handle relative paths now. The less hacking we have to do the better 🤞 |
Sounds good to me 👍 |
Update, 16 Mar 2021Today we started by briefly talking about the technical stack. We then reviewed prototype feedback, how it fits into the lo-fi design, and what alterations may be necessary.
Next steps
|
Update, 30 Mar 2021In a touch point yesterday we reviewed mid-fidelity designs, with the IPFS brand standards applied, as well as an enhanced mid-fi version of the embedded view. We also spoke about nuxt compatibility with IPFS Gateway routes, which now works (a nuxt module is available here). Key areas we covered were:
Next steps
|
Update, 13 Apr 2021We had a new touchpoint yesterday where we reviewed high fidelity designs and new specifications. Key areas:
Next Steps:
|
Updates, 23 Apr — 14 May 2021We had several touchpoints over the last 3 weeks, including one today. During this time, we kicked off development and hit milestones. In early touchpoints, we covered:
More recently we went over:
Development progress:
Next Steps:
|
We've soft-launched https://ecosystem.ipfs.io, so will close this issue. Follow along with wrap-up and future work at https://github.com/ipfs/ecosystem-directory/! |
Objective
Replace the existing canonical ecosystem diagram with an interactive, information-rich directory that effectively illustrates how IPFS adds critical value and tech enablement for IPFS builder orgs, projects, and industries. Presentation must be at, at minimum, two levels of detail:
Latest status documents
These items are evolving, but the latest will always be listed here. Check back regularly.
Draft features/requirements
It's safe to assume that these requirements are roughly accurate, but please keep in mind that details can change as the project develops. Always assume that materials under "Latest status documents" above are the source of latest truth.
Features: Summary view
An at-a-glance view of top IPFS implementers and the tangible value that IPFS provides them. Includes the following features and requirements:
Features: Detailed view(s)
A not-overwhelming, easily searchable/filterable showcase for exploring how builders leverage IPFS to succeed and the ways in which IPFS provides value. This detailed view may include additional drill-down views subject to prototyping and refinement, but overall includes the following features and requirements:
Industry/subject type(s) (multi-choice filter)
Product focus (this needs refining, particularly vis-a-vis overlap with industry/subject):
IPFS enablers/benefits (multi-choice filter):
Tools/implementations used (multi-choice filter):
Size/scale factor as demonstrated by "big number" metrics (TBD - not for initial release, but should be built with this in mind)
Additional requirements
Must be easily updated via PR, with the awareness that in future we may use Forestry to enable additions and updates AND/OR pull data from a CRM via API(requirements change: data source of truth will live in third-party DB and updated via re-importing JSON from that DB, so update request flow is out of scope here)In the meantime, must include well-written checklist in PR template to make submission as easy and standardized as possibleLegacy documents
Please note that these may be outdated as project requirements continue to develop, and should be used for reference only.
The text was updated successfully, but these errors were encountered: