IPFS user, @danieln is interviewing them for a case study and also user feedback
They’re very happy using IPFS as the main storage layer for votes and metadata
IPNS doesn’t work for them because pinning services mostly don’t support it. Can make it work if you look into the nooks and crannies.
In parallel with the case study, @danieln will pull together practical tips for IPNS into a guide (eg translating the tradeoffs, publishing into docs, etc.)
web3.storage has a w3name service they’re rolling out to try and do IPNS pinning… they have to deal with tradeoffs but they have a service here which is both easy to use and nobody has bothered with it. IIRC, they just set all record lifetimes to one year by default and call it a day.
@mosh : I got feedback that 8am Pacific (15UTC) would make the meeting more Pacific accommodating. Are you ok to update? I can shuffle any EngRes Stewards meetings around to accomodate.
Discussion around *.storage’s naming solution (w3name). Our docs should cover the kind of details that w3name is glossing over. We don’t want to hide over the security details/implications.
Meta: launchpad docs.
Sometimes what is copied is going to be out of date. Ideally should be linked to canonical source and remove from launchpad docs.
There is concern about how this translates to native implementations (e.g., Brave Mobile and how it won’t use Kubo)
Will let marinate while Lidel is out
Positive here is that we have real users and usecases on this
Integrations
Needing more input on languages, hardware, sandboxing of network requests
Want a doc that says “this is what the Chrome peopleare willing to tolerate, this is what the curl people are willing to tolerate”
ONe thing have learned: there won’t be one language or implementation that will rule them all. There isn’t a world of write in C and use everywhere
Have success when folks in Ecosystem go and talk with the communities, ask what they want, etc. Wanting to understand their workflows, if there are internal champions, how they do testing, etc. This is a slow very-attentive approach.
Usecase: Gateway range request. Input: car, path, and range request and returns bytes.
It may be useful for Mark to report back on who he’s spoken with, what he’s hearing, etc.
UnixFS
EngRes focus on specs
Outercore understands the needs and the mechanisms for working with parties
We then meet as an IPFS community on how to get this delivered.
Proposal to rotate every month or quarter (alternating between Stewards and Outercore)
Jourdan, virtual events producer at PL, is proposing bringing back a regular quarterly virtual community event. May have already spoken with some people here already.
Ideally we’d show all the different events and let users choose
@danieln will reach out to Yuni,Andrew Woo and even Luma to ask about better Google Calendar integration. Specifically, if we can have Luma export and update events to the shared Google Calendar.
IPFS Camp
It is happening Oct 28-30
There are lots of tracks
Things we hope to see happen
Wish there was less FOMO - missing out on the shared experience.
there will be an everyone-togrther kickoff session, 2-3 hours on the first day
Want to go deeper into the use cases and apps built on top of IPFS
Greatly increase the number of people who can significantly contribute to the project. We want folks who can help with content routing, CID versions, etc. so they can build great dev tools, etc.
Build a community that is inspired to build on IPFS (DeSci)
Fun (memorable, relationship building)
Scaling our efforts through better specs and documentation.
Lidel would be open to give a revised version of the IPIP talk.
How could to Stewards help given that we have about a month?
Is it more about content creation? better specs?
Mosh: The community is more blocked by knowledge than software
Daniel: if you’re building applications, what do you need to know,
For “Create a Simple Chat App” we heavily utilize CircuitRelayV1, since it was removed from Kubo, we looked at using libp2p-relay-daemon, but haven’t been able to connect to it from the JS side in browser (or desktop).
It sees we have a bug related to Secure websockets in go-libp2p that touches TLS termination
Additional notes from Mosh based on conversations with Daniel, Biglep, Lidel, Dietrich, Reid, JB, Molly
Reposition IPFS as a production-grade solution for key problems with building on today’s web, vs. a cool thing for hackers to try. Improve our internal understanding, & then communication, of what 2-4 use cases IPFS is great at solving, then double down on features, messaging, and devrel for those.
Most devs want end-to-end example apps that showcase the power & capabilities of IPFS (docs & blogs today often focus on 1 feature at a time, which is harder to translate into practice). 2 examples are coming soon
Accelerator & seed-stage teams need stronger & more personal technical guidance for making tradeoffs & decisions.
On-ramps for learning & contributing are hard to navigate
Everything should be slightly uncomfortably open (example: roadmap docs themselves)
Specs feel abandoned. IPIP is a good first step.
Docs has accumulated a lot of duplicate material
Smaller-contributions: lacking contributor guides, good first issues, etc.
“Even if we invite people to the restaurant, there are no chairs.”
Traffic on our owned properties is very, very low – a good IPFS blog post gets 300 views. Need to take this show on the road, to conferences beyond Web3, popular programming podcasts, etc.
What are they key quesitons we want to answer?
Getting insight on IPFS reposition around production scale / converge on 2-4 killer use cases
Pull out what the details are and what are the gaps
Understanding others experience contributing to the project
Personas
Contributors
Operators
Consumers / app builders on top
Altruists - fans of the protocol
Another option: going to the other tracks and listening what users are saying like “DeSci”