IPFS stewards <> advocates sync

Ecosystem
1

We’re piloting a biweekly sync between IPFS stewards and advocates. Let’s use this thread for meeting recaps and related conversations.

5 Likes
2

April 1

Attendees: @adin @lidel @achingbrain @BigLep @mosh @dietrich @Jorropo

People need more conceptual toolboxes

  • Eg I want to create an efficient index
  • Eg I want to traverse these blocks, how do I do that

We need a place to drop semi-official knowledge

Examples like Adin’s IPNS writeup and other docs that aren’t fully baked enough to go into Docs, but having it will be 100x better than nothing. After exploring many options (blog, discord, hackmd, notion), we decided to try using the wiki feature on this forum (it allows posts to be editable by many people).

There are also stub pages in Docs like Best practices for IPFS builders | IPFS Docs

“Getting Started” content could be better tuned to learning & introduction

  • People think of js-ipfs as a monolith, but it’s more modular by far and you most likely want to use them independently. We have some people who want to build on our stack who aren’t interested in decentralized transfer of data, eg someone is going to host servers with all the data using IPFS content addressing.
  • In browser land, users getting started are probably more interested in a daemon already running somewhere and just using some JS IPLD libraries.
  • Jorropo: Telling people to use go-ipfs as a library is a really big beast with complicated plumbing. You only need a few features provided in all the packages: DHT, bitswap, blockstore. @hector has an IPFS lite package, use that content instead as intro. Imports only the things you need and learn IPFS from the ground up in only 300-500 lines of code, plus better config options. ipfslite package - github.com/hsanjuan/ipfs-lite - pkg.go.dev.
  • Mosh: I"m hearing people looking for the IPFS way to do standard software things, like databases. Do we need better middleware?
  • Lidel: This will get way better when we support IPLD on gateways, namely DAG-JSON. When we remove the need for middleware, devs can just talk javascript and store JSON somewhere.
  • For a lot of people, IPFS = gateways, = UnixFS, != IPLD… smush everything into a directory, or just let the gateways support these things.

There’s an early and important fork in the road when choosing to use IPFS: files vs. data.

We call the whole thing IPFS but if you want dags all the way down, you’re going to need IPLD. This is an important concept for new users to understand but it’s missing an explanation.

Links mentioned:

Next time:

  • April 15
  • As a group, try to create the primer on IPFS for files vs. IPFS/IPLD for data structures.
3 Likes
4

April 29

Attendees: @lidel @adin @mosh

Proposed agenda:

Notes

IPLD/DAG-JSON support on gateways

In go-ipfs 0.13 we introduced the concept of asking for a specific response from gateway. This will be used in the next release to support asking for dag-json and dag-cbor, and therefore any IPLD codec (represented as json/cbor).

It’s useful if people are using IPFS as a backend service for internal usage. In the future you might want a concept of a verifiable-only / trustless gateway.

What is and isn’t IPFS?

The definition of IPFS is blurry. Here are some things that various people think IPFS is:

  • the ipfs.io gateway
  • go-ipfs
  • anything that supports bitswap and the dht
  • anything that supports libp2p — but do you have to support ipld? what if you use http to transport the files?
  • do you have to implement all the codecs?
  • what if i just implement the bittorrent codec?

Where do you draw the line that makes something IPFS or not? How do we choose who gets to make choices? What’s the line between being permissive and gatekeeping?

  • If we are going to insist that IPFS is everything in the universe that’s content addressing, we might want to define a subsystem that has requirements for an X-compatible implementation.
    • For every AND on the client, you have an OR on the server. for every OR on the client, you have an AND on the server.
    • Example: You have a protocol named pandora. If every pandora server must implement bitswap AND graphsync, then every pandora client may implement bitswap OR graphsync to ensure any client can talk to any server.
  • Content routing systems and other things around the edges get more complicated. e.g. if i say you may use DHT on the client OR indexers. Then you have to support both… or have a bridging system.
  • Need to decide if the indexers are a real system or not (multiple entities that you can treat the same way). Most companies would want to only index their own stuff, so if you assume all indexers are indexing everything, you’ll end up not being able to find stuff.

This topic came up because go-ipfs can’t solve every problem. Neither can js-ipfs. Or any monolithic design. We need to redefine the IPFS project & protocol to explicitly make space for new implementations to emerge.

Example: Brave mobile can’t run a full node, battery would die. So they’re taking a new approach, list of public gateways, fetching data and verify locally. Basically a lite ipfs client without libp2p. They may start libp2p amongst a local network.

You could say there are at least 5 IPFS implementations already:

1 Like
5

May 13

Proposed agenda:

  • Welcome @danieln :slight_smile:
  • IPFS camp
    • Proposed “protocol & implementations” track, is that the right theme, what are important discussions, who should chair this track?
  • What else?
6

June 10

Attendees: @mosh @danieln @lidel @discordian @BigLep @adin @Jorropo

Agenda:

1 Like
7

2022-06-10 Actions

  1. :white_check_mark: Archive the #ipfs-gateway-operators channel in IPFS Discord.
  2. :white_check_mark: Add a “Operators” to discuss.ipfs.io: Communities - discuss.ipfs.io that we can point people to: Gateway Operators - discuss.ipfs.io
8

The basic reason, what I think for this is the name/word ‘IPFS’ which is being used by the further mentioned tools with just minor/no change.

9

June 24th

  • @danieln’s auspinner – a stateless CLI tool to easily pin CAR files to IPFS pinning services. It’s essentially a client for the IPFS Pinning Service API that speaks HTTP and Bitswap.
  • go-ipfs→kubo rename in progress
  • reframe (pluggable routing) pieces are landing in kubo, we will need “DIY content routing” tutorials and examples in near future
4 Likes
10

July 22

3 Likes
12

Aug 5

Participants: @lidel @BigLep @danieln @Discordian @mosh @adin @Jorropo

Agenda:

Notes:

3 Likes
13

@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.

3 Likes
14

That works, and is still reasonable for European timezones. Just moved the invite.

15

2022-08-19

(@mosh will be OOO. Who is game to facilitate?)

Participants:

Agenda:

  1. IPNS Docs
  2. Redirects
  3. Integration story?
    3.1 Lite client for IPFS
  4. IPFS Event

Notes:

IPNS Docs

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.

Redirects

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.
2 Likes
16

2022-09-02

Participants:

Agenda:

  1. Snapshot case study is live on Docs (h/t @danieln)
  2. IPFS Camp (@mosh)
    • Ops updates
    • Content planning
    • Tell me all your other hopes & dreams for Camp
  3. Facilitating this sync (@mosh)
    • Proposal to rotate every month or quarter (alternating between Stewards and Outercore)
  4. 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.
  5. IPNS docs PR Improve IPNS docs by 2color · Pull Request #1258 · ipfs/ipfs-docs · GitHub @danieln
  6. Community calendar (Community Calendar - options other than Google Cal?) @danieln
  7. Clarify DHT in js-ipfs PR docs: clarify state of DHT in js-ipfs by 2color · Pull Request #4181 · ipfs/js-ipfs · GitHub
  8. Other?

Notes:

  • Meta
    • Next time use something like hackmd to do collaborative editing
    • @BigLep Invite Reid to this sync
  • Usecases: please share if there are other interesting IPFS usecases like snapshot
  • IPNS Docs
  • State of js-ipfs union documentation
  • Community Calendar
    • Community Calendar - options other than Google Cal? - #2 by BigLep
    • It’s not easy to just opt into single a specific event
    • Currently, there’s too much clutter when subscribing
    • https://lu.ma/ is already being adopted by Fission
    • 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
    • Specs
      • @lidel have them in better shape
        • UnixFS
        • IPNS
      • Should be part of the implementer’s track
      • This will take stewards’ time
    • Education tracks
      • 101 - Maybe @discordian?
      • 201 - @dnorman: designing decentralized applications
      • 4xx - Optimize in production for performance/scale - ideally someone who is operating IPFS in production at scale. Mosh will check with Dietrich.
  • Virtual
    • Some options to dial in and give virtual talks
3 Likes
17

Quick update on the community calendar and Luma:

18

2022-09-16

Participants

@mosh @lidel @BigLep @Jorropo @reid @taylor @danieln

Agenda

Notes

  • IPFS Camp

    • Goals:
      1. 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.
      2. Build a community that is inspired to build on IPFS (DeSci)
      3. 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,

  • js-ipfs examples repo

    • Why is it in a separate github org?
      • There is a monorepo but also repo for each example and this prevents pollution.
      • example-per-repo is fork-and-go pattern → low friction dx for both usage and contribution. Fork-n-Go
    • Good thing: there is a CI in js-ipfs to ensure examples pass
    • Ownership:
      • js-ipfs maintainer area of responsibility: make sure not breaking examples or updating them if do break
      • for triaging incoming examples, need someone who is deciding whether it’s relevant/useful
        • Decision: devrel will own it
        • Practicalities
          • Org readme
          • Ask #ipdx to setup github-mgmt
    • Example utility:
      • Not all of them are useful
      • Makes sense to go through them one by one
    • Problem:
      • many don’t know they exist
        • We need to get more links.
    • Steve: Meta: should we get Alex to this meeting?

  • IPNS Spec

  • :white_check_mark: Verify domains for IPFS GitHub org!

:closed_book: Action items

  • @Jorropo : think about applied UnixFS talk
  • Engres folks planning on attending should RSVP to the event so that we could get a head count
  • @daniel ask #ipdx to set up the Github management (similar to GitHub - ipfs/github-mgmt) for ipfs-examples
  • @danieln Ask Russel, Lidel, Alex to help with the cleaning of the examples.
2 Likes
19

2022-09-29

Participants

  • Reid
  • Mosh
  • Lidel
  • Jorropo
  • Daniel
  • Tmo

IPFS Stewards <> Advocates sync notes 30.9.2022

Notes

1 Like
20

2022-10-14

Participants

  • Reid
  • Mosh
  • Lidel
  • Jorropo
  • Daniel
  • Discordian
  • Steve
  • Elliot

Discussion topics

  • @discordian How to advance Issues connecting from IPFS nodes over WSS · Issue #18 · libp2p/go-libp2p-relay-daemon · GitHub
  • @danieln IPFS Roadmap & Advocates plan for Q4
    • 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 :slight_smile:
    • 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”
  • Analytics
  • @Jorropo unixfs talk at IPFS Camp
    • Looking for a track to speak at
    • Planning to discuss light IPFS clients & UnixFS
    • Would need about a 15 minute talk duration
3 Likes
22

2022-11-18

Attendees

Notes

23

IPFS Stewards <> Advocates sync 25.11.2022

Participants

Discussion topics