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.

4 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
1 Like