We've reached a pretty stable API, and IPFS now runs pretty reliably. People are already using IPFS from other languages, primarily JS through https://www.npmjs.com/package/ipfs-api

There's been talk about organizing an effort to get API bindings for more languages. Maybe we can start with:

• C/C++
• C#
• Erlang
• Go - https://github.com/ipfs/go-ipfs-api
• Haskell
• Java - https://github.com/ipfs/java-ipfs-api
• Javascript - https://github.com/ipfs/node-ipfs-api
• Lua
• PHP
• Python - https://github.com/ipfs/python-ipfs-api
• Ruby
• Rust
• ObjC
• Swift
• Scala - https://github.com/ipfs/scala-ipfs-api

The API is very simple -- it is just a REST-like HTTP + JSON API. Do we have any volunteers to help out with languages listed above (or others)? Please respond here if you can dedicate a good chunk of time. (I'll prepare a guideline doc for implementors in the meantime.) Then we can have a bunch of people working on this at the same time, which will make it go way faster. And then we can release them all in one go!

I will use this issue to note thoughts regarding Linked Data in the IPFS context. Note this is just brainstorming.

The power of the semantic web is worth considering. While it hasn't really "taken off," it's TRTTD when it comes to data structuring.

@msporny created the wonderfully simple JSON-LD. Since IPFS is a ~~tree~~ dag structure, the JSON-LD spec (or a simplified version of it) might fit IPFS really, really well. This would give IPFS all the power of the semantic web with very little overhead.

This would mean the addition of a @context link (doesn't have to be that key, or even in the Links structure, could be its own field).

I hesitate to say there MUST always be a context in objects, as I'm sure this would hamper IPFS use. A strong design decision is to give the user entirely free reign on data format.

But perhaps there is some middle ground. At the very least, we should support the optional addition of an @context type of thing. Will continue to think about it.

Actually, @msporny, i'm really curious to hear your thoughts. Check out this project (paper, talk) and lmk your thoughts.

This is the thread for IPFS Weekly Updates. Please subscribe if you would like to be notified each week about updates regarding IPFS!

If you would like to have an update in your inbox, sign up for emails at https://tinyletter.com/ipfsweekly.

IPFS Weekly #1

Welcome to the first edition of IPFS Weekly!

IPFS is a new hypermedia distribution protocol, addressed by content and identities, aiming to make the web faster, safer, and more open. In these posts, we will try to highlight some of the development that happened in the past week. For anyone looking to get involved, follow the embedded hyperlinks, search the wealth of information on github or join us on IRC (#ipfs on the Freenode network).

Since this is our first time launching the Weekly, we've included several past weeks. This is partially because we've been refining our process, and wanted to make the first weekly a great one. In the future, they will be released weekly. If you have any feedback about this process in general, let us know here. Thanks!

December 21

Here are some of the highlights for the December 21 Sprint:

32c3

Not too much happened during this sprint, because it was the holidays - however, it was also the 32nd CCC. @whyrusleeping, @diasdavid, @lgierth, @Dignifiedquire and more of the team were over there in Hamburg.

• @whyrusleeping gave a lightning talk (see above).
• @whyrusleeping @diasdavid and @Dignifiedquire led an install party and live demo.
• @MrChrisJ led a discussion about his Full Node project, which includes IPFS.
• We met lots of our users, and other groups (including Tahoe-LAFS, tor, etc).

Updates

• (go-ipfs) @whyrusleeping and @diasdavid did amazing work closing around 200 issues as part of the "Great go-ipfs Issue Party of 2015".
• (registry-mirror) npm on IPFS was furthered by @diasdavid by making it work with 0.4.0. Currently, there are 130,000 modules and it's going strong.
• (go-ipfs) @lgierth set up namaka and hiiaka (NUC nodes at our table at 32c3). This is pretty cool. CF. ipfs/infrastructure#142.
• (readme-standard) @RichardLitt had his own great issue party. He's most proud of breaking ground on the future readme standard for IPFS.
• (webui) @Dignifiedquire did some awesome work improving the webui using webpack.
• He also managed to release rust-multiaddr and rust-multihash, which means more languages now implement the orginal multihash and multiaddr specs.

For more updates, see the sprint issue.

December 14

Here are some of the highlights for the December 14 Sprint:

Releases

• @whyrusleeping shipped fs-repo-migrations! These are migrations for the filesystem repository of ipfs clients. This tool is written in Go, and developed alongside go-ipfs, but it should work with any repo conforming to the fs-repo specs.
• @Dignifiedquire did some great work with rust-multiaddr, which is a Rust implementation of @jbenet's multiaddr.

Updates

• (registry-mirror) @diasdavid worked on the npm on IPFS project. This involved some new features, moving the mirror to a different server, and making it work better with larger dirs and with 0.4.0.
• [(js-ipfs)](//github.com/ipfs/js-ipfs @diasdavid pushed some major updates for js-ipfs, too.

Not much else to report this week; a lot of people are off to enjoy CCC, and the holidays.

December 7th

Here are some highlights of what happened during the December 7 Sprint :

Releases

• @whyrusleeping shipped IPFS version 0.3.10! It contains 74 new commits since the previous version and you can get it here.
• npm on IPFS! registry-mirror is a new tool that enables distributed discovery of npm modules by fetching and caching the latest state of npm through IPNS. For more info, see this blog post by @diasdavid .
• @jbenet released a new tool/library called dnslink that makes it easy to resolve dns links (special TXT records in a domain name that can point to paths, like an IPFS path)

Updates

• (infrastructure) On the infrastructure side of things, @lgierth has bootstrapped two new storage, each with 17 TB of disk space!
• (api) @RichardLitt has [reached a draft 1]((//github.com/ipfs/api/pull/13) of the much needed API documentation.
• @harlantwood wrote a bit of nodejs code that spins up a fresh IPFS node, sets it to a known ID, and publishes to IPNS using that node.
• (specs) The new IPFS Linked Data (IPLD) spec is actively being iterated on in the specs repository. Join the discussion here!

Active stuff

• @robcat and @fazo96 have done great work integrating IPFS with pacman (the package manager for Arch Linux). They can now install arch packages straight from IPFS! For more details, see this active discussion.
• @Dignifiedquire has been working on an attractive new distribution page for IPFS, which will be the new landing page to download all things IPFS. You can see the latest screenshots here.

Contributors

Across the entire IPFS GitHub organization, the following people have committed code since December 7th. (We're autogenerating this list using this tool, so please let us know if your name isn't here.) In the future, we will also include people who comment, as they are also super important; bear with us while we develop that technology.

• @alexmingoia (Alex Mingoia)
• @chriscool (Christian Couder)
• @diasdavid (David Dias)
• @digital-dreamer
• @Dignifiedquire (Friedel Ziegelmayer)
• @djdv (Dominic Della Valle)
• @fazo96 (Enrico Fasoli)
• @greenkeeperio-bot
• @harlantwood (Harlan T Wood)
• @hcs64 (Adam Gashlin)
• @ianopolous (Ian Preston)
• @ivilata (Ivan Vilata-i-Balaguer)
• @jbenet (Juan Benet)
• @jedahan (Jonathan Dahan)
• @Kubuxu (Jakub Sztandera)
• @kyledrake (Kyle Drake)
• @lgierth (Lars Gierth)
• @NeoTeo (Teo Sartori)
• @ralphtheninja (Lars-Magnus Skog)
• @ReadmeCritic
• @rht
• @RichardLitt (Richard Littauer)
• @travisperson (Travis Person)
• @wasserfuhr (RainerWasserfuhr)
• @whyrusleeping (Jeromy Johnson)
• @zignig (Simon Kirkby)

Thanks, and see you next week!

• Richard Littauer and Andrew Chin

Send us feedback about the Weekly

IPFS Weekly #2

IPFS is a new hypermedia distribution protocol, addressed by content and identities, aiming to make the web faster, safer, and more open. In these posts, we highlight some of the development that has happened in the past week. For anyone looking to get involved, follow the embedded hyperlinks, search the wealth of information on GitHub or join us on IRC (#ipfs on the Freenode network).

Here are some of the highlights for the January 5th Sprint:

Updates

• (specs) There was much debate in the IPLD spec about pathing notation. @mildred in particular did a lot of good work.
• (go-ipfs) The IPFS Docker image is now tested automatically on Travis, thanks to @ChristianKniep, @whyrusleeping, and @chriscool. For more, see the go-ipfs#2064 pull request.
• (js-ipfs) Now you can do npm i -g js-ipfs and use jsipfs (the javascript impl of IPFS) with bootstrap + id + version commands, fully compatible with the go-ipfs repo, thanks to @diasdavid!
• (project-repos) A very cool organization-wide dashboard that provides a status overview of all the IPFS repos was launched. By @harlantwood.
• (community) @RichardLitt merged the pull request for JavaScript guidelines for IPFS repos. This is a major step towards standard JavaScript repositories within IPFS.
• (community) @NeoTeo, @whyrusleeping, and @diasdavid hosted a small meetup in Copenhagen! Eight people in total showed up for an intro to IPFS, a Q&A session, and some good conversation!

Work in Progress

• (distributions) @Dignifiedquire further developed the distributions page. Click here for a preview!
• (go-ipfs) @lgierth continued the work towards the dev040 migration. Notably we have two new gateways to aid in the transition: http://v04x.ipfs.io and http://v03x.ipfs.io
• (archives) @Dignifiedquire has added to IPFS a dump of the Stackexchange archives! Details are in the archives repo. We are always looking for more help with archiving important datasets, so feel free to join us in the archives repo!

Contributors

Across the entire IPFS GitHub organization, the following people have committed code since January 4th. (We're autogenerating this list using this tool, so please let us know if your name isn't here.) In the future, we will also include people who comment, as they are also super important; bear with us while we develop that technology.

• @chriscool (Christian Couder)
• @ChristianKniep (Christian Kniep)
• @diasdavid (David Dias)
• @Dignifiedquire (Friedel Ziegelmayer)
• @eminence (Andrew Chin)
• @greenkeeperio-bot
• @ianopolous (Ian Preston)
• @jbenet (Juan Benet)
• @Kubuxu (Jakub Sztandera)
• @lgierth (Lars Gierth)
• @noffle (Stephen Whitmore)
• @ralphtheninja (Lars-Magnus Skog)
• @ReadmeCritic
• @RichardLitt (Richard Littauer)
• @whyrusleeping (Jeromy Johnson)
• @yuvallanger (Yuval Langer)

Thanks, and see you next week! If you have cool things to share for the next weekly, drop us a line in the next weekly sprint issue!

• Richard Littauer and Andrew Chin

Submit feedback about this issue here, or send us feedback about the IPFS Weekly in general.

It is a bit of mouthful to explain that the js-ipfs-api is the client library that implements the same js-ipfs API but it is just a client.

Other project call these libraries SDK or simply, clients.

Fun history fact, we had multiple confused users opening multiple issues assuming that js-ipfs-api is the JS implementation. It only stopped when we put a giant banner image in every repo that is a client library -> https://github.com/ipfs/js-ipfs-api/#--

If someone wants to create an IPFS implementation in a new language, the best starting point is to create the supporting libp2p and multiformats modules. Those modules are useful beyond IPFS and you absolutely need them in order to have a working IPFS implementation in your language.

I've noticed that at present, ipfs uses two types of resource indication:

/ipfs/hash/path/to/resource

and

http://localhost:8080/ipfs/hash/path/to/resource

Neither of these are standard URLs. A standard URL would look like:

ipfs://hash/path/to/resource

Why don't you use that rather than:

/ipfs/hash/path/to/resource

?

FYI https://github.com/Ayms/node-Tor, javascript implementation of the Tor protocol in node and at browser side, in case it can be of some interest for IPFS one day (maybe missing in the description "IPFS is anonymous")

See the demo app

Hey,

IPFS looks amazing, though its missing one key aspect of a file system, and that is permissions. Lets say that I create a file that I only want to share with my friends (or some list of nodes). The simple example would be a social profile. It would be nice to have the classic unix user/group model implemented in IPFS.

I'm not even sure where to start on something like this without a central authority to enforce the permissions, but it seems like it would be a useful thing to have.

The project directory in this repo has many sections, maybe some of them (like Applications) should be merged with awesome-ipfs for example by linking awesome-ipfs here instead of having duplicate data

This is my first stab at designing solid working groups that can tackle different verticals of the IPFS project independently. This comes as a follow up of many informal conversations that many of us had.

The wording still has ways to improve and we should expand on the responsibilities list, specially after checking in with whom has been taking more or less those responsibilities for the last year or so.

There is also an open question on what is the life cycle of a working group and if we are going to have captains for each of these.

UPDATE: See https://github.com/ipfs/ipfs/pull/285#issuecomment-412347667

I'm not sure that this is not implemented already, in this case this should be seen as request for documentation. :-)

I want to run ipfs node (at least to cache accessed entries) on computer in LAN that has no direct access to internet (no inbound connections at all, outbound connection only via restrictive proxy - ports 80 and 443 only). I have several options to connect outside available:

1. Mentioned restrictive http proxy.
2. Tor (socks and privoxy).
3. Socks via ssh tunnel to home computer (via tor).

How should I configure ipfs to work in such environment?

This is a tracking issue for shutting down the PL-hosted delegate and preload nodes that are relied upon currently by js-ipfs. This is discussed in https://blog.ipfs.tech/state-of-ipfs-in-js/#pl-delegate-and-preload-nodes-will-be-shutting-down

This issue needs to be fleshed out with specific steps (including communication) and timeline, but for now is serving as a tracking issue that can link to.

As part of https://2022.ipfs-thing.io, we want to:

1. Drive home the message that IPFS is many implementations by multiple groups. Basically IPFS is not go-ipfs or Protocol Labs. https://github.com/ipfs/ipfs-docs/pull/1193
2. Provide accurate information about how to engage with the community.

Historically:

1. "ipfs" has been used to denote "go-ipfs" (Kubo), which is wrong since ipfs is bigger than a particular implementation.
2. Community information has been spread across various GitHub repos.

We want to have canonical information about IPFS implementations and community information that other places can link to. https://docs.ipfs.io is the intended place that we should link to.

This tracks the work to cleanup old/wrong areas about our "docs". Example areas in scope:

• https://github.com/ipfs/ipfs
• https://github.com/ipfs/ipfs-docs
• https://github.com/ipfs/community
• https://github.com/ipfs/team-mgmt
• https://github.com/ipfs/roadmap
• https://github.com/ipfs/notes

There is a lot of stuff (including cruft) in these repos. To maintain focus and contain the scope, this issue is focused on the two items above.

This issue is here so can link to it in various PRs to provide context.

• [x] https://github.com/ipfs/ipfs-docs/pull/1193
• [x] https://github.com/ipfs/ipfs-docs/pull/1195
• [x] https://github.com/ipfs/ipfs/pull/486
• [ ] https://github.com/ipfs/ipfs-docs/issues/1194
• [x] https://github.com/ipfs/community/pull/760
• [x] https://github.com/ipfs/team-mgmt/pull/1204
• [x] https://github.com/ipfs/roadmap/pull/92
• [x] https://github.com/ipfs/js-ipfs/pull/4157
• [x] https://github.com/ipfs/js-ipfs/pull/4156
• [x] https://github.com/ipfs/js-ipfs/pull/4158
• [x] https://github.com/ipfs/js-ipfs/pull/4159
• [x] https://github.com/ipfs/js-ipfs/pull/4160

Howdy o/

I just now learned of this list of HTTP API clients and would like to include my own (almost finished) implementation in Scheme.

I was hoping to get a few doubts cleared up before publishing in the Scheme's own package list as well, so if anyone can chime in, please do (here)!

Problem

Right now, the default config in IPFS/libp2p nodes use bootsrappers hosted by PL. We should be looking into ways we can make the default bootstrapping more robust.

Ideas

(1) remember peers across restarts, decreasing impact of bootstrappers going dark (leveraging prior art from bittorrent and tor projects) (2) include bootstrappers maintained by different organizations, decreasing risk of Facebook-like catastrophic bootstrapper misconfiguration

Background

“IPFS” is an ambiguous term in part because multiple “things” are called “IPFS”, including the Go and JS reference implementations of the “IPFS bundling” that were sponsored by Protocol Labs being named “go-ipfs” and “js-ipfs”. Protocol Labs wants to make space for additional implementations to be made, including in Go and JS. PL found with the Filecoin protocol that the “one protocol multiple implementations” conversation was helped when implementations didn’t use “filecoin” in the name. This is why the original “go-filecoin” implementation was renamed to “venus” and the mainnet reference implementation was named “lotus”, even though it also is written in Go.

In addition, IPFS nodes have varying levels of compliance among them. For example, the ipfs.io gateways can be considered to have two types of content routing: the IPFS Public DHT, and peering agreements with Pinata, Infura, Textile, etc. This leads to user confusion when a partner’s data loads on the gateways but not via Brave's local go-ipfs node. We believe it’ll be useful for users to be able to say that a provider’s nodes are not X (a TBD name) compliant since they do not advertise their data in the IPFS Public DHT, and Brave nodes currently only support X compliant data providers.

Problems To Solve

1. Identify new names for go-ipfs and js-ipfs.
2. Identify a name for the “public IPFS DHT” so we can say that “$implementation nodes are $X compliant data providers.

Proposed Method

Create 2 separate GitHub discussions in https://github.com/ipfs/ipfs:

1. Renaming go-ipfs
2. Naming the “public DHT”

The discussions will link to this document explaining the purpose and rationale. Anyone who wants to propose an idea, can start a discussion “answer” following a template like:

*Name:* 
*Reason it’s great:* 
*How it reads in multiple sentences:*
*Callouts concerning recognition, pronunciation, spelling, length, and/or SEO:* 

Submissions should be in by EOD Wednesday, 2021-11-03, so can vote Thursday and Friday.

Others can then:

1. comment on the “answer” if they have things to add to it and/or
2. “thumbs up“ 👍 if they’re in favor

Many naming idea can be seeded from Sheet of IPFS-related Names.

We’ll announce after Lab Week in the discussions the decided names and the timeline for making the repo/doc naming updates.

FAQ

What is the scope here? Are we renaming binaries, repos, etc.?

The exact scope/plan of renames (particularly with regard to go-ipfs) is TBD. We need to think through the implications on the community of changing these things. There is non-trivial work to:

1. Rename the ipfs/go-ipfs repo given there are some who consume go-ipfs as a library and likely scripts that hit that path.
2. Rename the ipfs binary as this is strewn throughout docs, scripts, etc.

The beachhead to start is to pick a name for the current "go-ipfs" IPFS implementation. For examples, let's call it "banana". At the top of the of the ipfs/go-ipfs repo, we'd have a note that says something like:

This repo is for the "banana" implementation of IPFS. It was formally called "go-ipfs". You can find other IPFS implementations in Go and other languages here.

Because of non-trivial work, we haven't changed the name of the repo or the binary. The progress of that work can be tracked here.

In addition, until the renaming work above is completed, any CLI reference in the ipfs.io docs for the "ipfs" binary should also map to this "banana" implementation.

We have picked the name "banana" now even without doing the full rename to ensure we don't add more that needs to be renamed in the future. It allows us to start referring to this specific IPFS implementation that was originally sponsored by Protocol Labs with clear communication. For example, the team of maintainers for "banana" can refer to themselves as the "banana maintainers" and name their support channels as such.

"banana" is expected to take a direct dependency on the to-be-written go-lib-ipfs project (see https://github.com/ipfs/go-ipfs/issues/8543). We aren't propagating the "banana" name to go-lib-ipfs because there isn't banana-specific choices in that repo. banana-specific code like banana's configuration system (which currently lives in ipfs/go-ipfs-config) will move into the banana repo directly. Future implementations of IPFS that are written in go (e.g., ipfs/rainbow) can choose to use go-lib-ipfs or not. This is similar to how anyone making an IPFS implementation in go can choose to depend on go-libp2p or not.

What order will the rename happen?

Per above, there are different layers to the rename. The order/timeline is still TBD, but needs to account for:

1. Public chat/discussion channels
2. Docs
3. GitHub repo
4. binary

Why do this on GitHub?

1. It’s visible to the community and easily discoverable
2. GitHub allows a user to thumbs up/ multiple items, but only one “thumbs up” per item.
3. It gives visibility to who voted for certain items (so can make sure are picking an option that has up votes from multiple parties)

Why don’t we use the GitHub “upvote” functionality?

We’re not proposing to use the official “upvote” functionality because it doesn’t give visibility to the voter.

Why now?

Protocol Labs is kicking off Lab Week where it and other partners in the ecoyostem are gathered to discuss “PLv8” and its principles around scaling our networks and doubling down on ecosystem growth & agency. In this context, actually getting decisions made and a plan made for a rename in 2021 seem appropriate.

What about renaming “js-ipfs”?

This will likely happen as well, and we’ll be having conversations on 2021-11-03 about the the different parts of js-ipfs, which parts are reusable, and which parts should get a new name. For reference, js-ipfs has:

1. a CLI (ipfs-cli)
2. a programmatic interface based on the CLI (ipfs-core)
3. an HTTP API based on the CLI (ipfs-http-server) and a client for that API (ipfs-http-client)
4. a gRPC-over-websocket API server (ipfs-grpc-server) and client (ipfs-grpc-client)

The HTTP interface mirrors the current go-ipfs HTTP API, and we will talk through how renaming elements on the go side should affect the JS side.

What about naming the “spec for an IPFS client”?

If someone wanted to implement a new IPFS client and still maintain network compatibility, where might they might look and how they might refer to "network compatibility"? There's nothing today stating that all nodes must be able to communicate via TCP + Noise + Mplex (the most widely supported libp2p combination) whether directly or via some proxy. Similarly, there's nothing saying nodes need to support protocols like identify or Bitswap. We believe it might be helpful to have a spec + name for the thing most people implicitly think of when they're talking about "the network" which is the minimal subset of protocols that a greenfield IPFS client would need to implement to be compatible with existing clients in a growing way. That said, this “spec + name” is not in the current renaming effort, but we’ll have a parallel conversation about this during Lab Week 2021.

Actions

• [x] Get agreement on whether using GitHub discussions or another mechanism
• [x] @biglep enable GitHub discussions on ipfs/ipfs repo.
• [x] @biglep create 2 discussions for the votes to do the week of 2021-11-01.
• #471
• #473
• [x] @biglep schedule time to discuss JS naming
• [x] @biglep schedule time to determine whether to spec/name “an IPFS client”” ~- [ ] @momack2 or @biglep solicit votes/nominations during LabWeek.~
• [ ] @biglep Outline sequence of events for the actual renaming
• [ ] @biglep Do 202201 version of nominating/voting, including surfacing better in public (Matrix/Discord, discuss.ipfs.io)
• [x] @biglep Setup something like https://Ipfs.io/implementations to make clear "go-ipfs" is only one of many