mirror of
https://github.com/ipfs/ipfs-blog.git
synced 2026-03-28 17:32:37 +01:00
Compare commits
2 Commits
githubacti
...
feat/task-
| Author | SHA1 | Date | |
|---|---|---|---|
|
339189f51b | ||
|
4d05fbd4fa |
@@ -42,8 +42,8 @@ fields:
|
||||
name: permalink
|
||||
label: Permalink
|
||||
description: 'URL for this post. Must start and end with slashes. <br>For blog posts,
|
||||
include the date: <em>/2022-09-23-descriptive-title/</em><br>For newsletters,
|
||||
use the edition number: <em>/newsletter-123/</em>'
|
||||
include the date: <em>/2022-09-23-descriptive-title/</em><br>For weekly newsletters,
|
||||
use the edition number: <em>/weekly-123/</em>'
|
||||
config:
|
||||
required: true
|
||||
- type: text
|
||||
@@ -77,7 +77,6 @@ fields:
|
||||
- AEgir
|
||||
- API
|
||||
- async/await
|
||||
- Bacalhau
|
||||
- Bitswap
|
||||
- blockstore
|
||||
- bootstrap nodes
|
||||
@@ -120,7 +119,6 @@ fields:
|
||||
- IPLD
|
||||
- js-ipfs
|
||||
- Kademlia
|
||||
- kubo
|
||||
- libp2p
|
||||
- MFS
|
||||
- mobile
|
||||
@@ -152,20 +150,14 @@ fields:
|
||||
target="_blank">file an issue</a> with the details.
|
||||
pages:
|
||||
- src/_blog/2021-05-31-distributed-wikipedia-mirror-update.md
|
||||
- src/_blog/2022-12-07-testground-in-2022.md
|
||||
- src/_blog/2023-01-10-announcing-pin-tweet-to-ipfs.md
|
||||
- src/_blog/2023-01-26-announcing-durin.md
|
||||
- src/_blog/3s-studio-bringing-unreal-engine-to-ipfs.md
|
||||
- src/_blog/a-brave-new-wallet-the-future-of-the-browser-wallet.md
|
||||
- src/_blog/a-guide-to-ipfs-connectivity-in-web-browsers.md
|
||||
- src/_blog/about-500-000-in-prizes-and-grants-for-asia-hackathon-season-2021.md
|
||||
- src/_blog/adding-ipfs-protocol-support-to-chromium.md
|
||||
- src/_blog/announcing-js-ipfs-0.53.0.md
|
||||
- src/_blog/announcing-the-jupiter-hackathon.md
|
||||
- src/_blog/announcing-the-second-ever-ipfs-camp.md
|
||||
- src/_blog/audius-uses-ipfs-for-content-streaming-storage-to-empower-artists-creators-worldwide.md
|
||||
- src/_blog/aug-20-ipfs.io-gateway-outage-resolution-next-steps.md
|
||||
- src/_blog/bacalhau-beta-v1.md
|
||||
- src/_blog/browsers-3000-winners-18k-in-prizes-goes-to-security-cryptography-and-gaming-applications.md
|
||||
- src/_blog/building-web3-berty.md
|
||||
- src/_blog/building-web3-pinata.md
|
||||
@@ -173,7 +165,6 @@ pages:
|
||||
- src/_blog/ceramic-launches-mainnet-using-ipfs-and-filecoin-for-decentralized-storage.md
|
||||
- src/_blog/community-highlight-esteroids.md
|
||||
- src/_blog/congrats-gitcoin-grants-round-9-winners.md
|
||||
- src/_blog/content-addressed-computing-at-ipfs-camp-2022.md
|
||||
- src/_blog/decentralized-games-at-gamedev.js-jam-2021.md
|
||||
- src/_blog/decentralizing-infrastructure-during-scaling-ethereum.md
|
||||
- src/_blog/decentralizing-the-internet-s-root.md
|
||||
@@ -185,7 +176,6 @@ pages:
|
||||
- src/_blog/gala-games-decentralized-gaming-supported-by-ipfs-and-filecoin.md
|
||||
- src/_blog/go-ipfs-0.8.0-and-remote-pinning-is-here.md
|
||||
- src/_blog/go-ipfs-v0.9.0-has-been-released.md
|
||||
- src/_blog/guardian-ipfs-hedera.md
|
||||
- src/_blog/hey-ethdenver-hack-on-ipfs-with-these-bounties.md
|
||||
- src/_blog/how-to-store-and-maintain-nft-metadata.md
|
||||
- src/_blog/how-we-put-ipfs-in-brave.md
|
||||
@@ -199,7 +189,6 @@ pages:
|
||||
- src/_blog/ipfs-as-a-first-class-citizen-in-ffmpeg-who-s-next.md
|
||||
- src/_blog/ipfs-at-ethdenver-2021.md
|
||||
- src/_blog/ipfs-browser-connectivity-walkthrough.md
|
||||
- src/_blog/ipfs-camp-2022-recap.md
|
||||
- src/_blog/ipfs-cluster-scaling-ipfs-data-storage.md
|
||||
- src/_blog/ipfs-community-highlight-omnilingo.md
|
||||
- src/_blog/ipfs-filecoin-and-content-persistence.md
|
||||
@@ -216,7 +205,6 @@ pages:
|
||||
- src/_blog/just-released-ipfs-cluster-0.14.0.md
|
||||
- src/_blog/kitsumon-blends-the-best-of-metaverse-gaming-with-content-addressability.md
|
||||
- src/_blog/libp2p-comes-to-protoschool.md
|
||||
- src/_blog/libp2p-day-2022-recap.md
|
||||
- src/_blog/libp2p-hole-punching.md
|
||||
- src/_blog/libp2p-paris-p2p-festival-2022-recap.md
|
||||
- src/_blog/meet-the-new-ipfs-blog-news.md
|
||||
@@ -254,11 +242,6 @@ pages:
|
||||
- src/_blog/welcome-to-ipfs-news-185.md
|
||||
- src/_blog/welcome-to-ipfs-news-186.md
|
||||
- src/_blog/welcome-to-ipfs-news-187.md
|
||||
- src/_blog/welcome-to-ipfs-news-188.md
|
||||
- src/_blog/welcome-to-ipfs-news-189.md
|
||||
- src/_blog/welcome-to-ipfs-news-190.md
|
||||
- src/_blog/welcome-to-ipfs-news-191.md
|
||||
- src/_blog/welcome-to-ipfs-news-192.md
|
||||
- src/_blog/welcome-to-ipfs-weekly-119.md
|
||||
- src/_blog/welcome-to-ipfs-weekly-120.md
|
||||
- src/_blog/welcome-to-ipfs-weekly-121.md
|
||||
|
||||
6
.github/dependabot.yml
vendored
6
.github/dependabot.yml
vendored
@@ -14,8 +14,4 @@ updates:
|
||||
assignees:
|
||||
- 'zebateira'
|
||||
labels:
|
||||
- 'dependencies'
|
||||
- package-ecosystem: "github-actions"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
- 'dependencies'
|
||||
|
||||
@@ -14,7 +14,7 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout Repo
|
||||
uses: actions/checkout@v4
|
||||
uses: actions/checkout@v2
|
||||
|
||||
- name: Compress Images
|
||||
uses: calibreapp/image-actions@main
|
||||
|
||||
4
.github/workflows/scheduled-publishing.yml
vendored
4
.github/workflows/scheduled-publishing.yml
vendored
@@ -8,11 +8,11 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout repo
|
||||
uses: actions/checkout@v4
|
||||
uses: actions/checkout@v2
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
- name: Check for scheduled posts
|
||||
run: echo "should_publish=$(${{ github.workspace }}/scripts/scheduled-publishing.js)" >> $GITHUB_OUTPUT
|
||||
run: echo "::set-output name=should_publish::$(${{ github.workspace }}/scripts/scheduled-publishing.js)"
|
||||
id: should_publish_step
|
||||
- name: Trigger Fleek Build
|
||||
if: ${{ steps.should_publish_step.outputs.should_publish == 'true' }}
|
||||
|
||||
25
.github/workflows/stale.yml
vendored
25
.github/workflows/stale.yml
vendored
@@ -2,12 +2,25 @@ name: Close and mark stale issue
|
||||
|
||||
on:
|
||||
schedule:
|
||||
- cron: '0 0 * * *'
|
||||
|
||||
permissions:
|
||||
issues: write
|
||||
pull-requests: write
|
||||
- cron: '0 0 * * *'
|
||||
|
||||
jobs:
|
||||
stale:
|
||||
uses: pl-strflt/.github/.github/workflows/reusable-stale-issue.yml@v0.3
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
issues: write
|
||||
pull-requests: write
|
||||
|
||||
steps:
|
||||
- uses: actions/stale@v3
|
||||
with:
|
||||
repo-token: ${{ secrets.GITHUB_TOKEN }}
|
||||
stale-issue-message: 'Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 7 days.'
|
||||
close-issue-message: 'This issue was closed because it is missing author input.'
|
||||
stale-issue-label: 'kind/stale'
|
||||
any-of-labels: 'need/author-input'
|
||||
exempt-issue-labels: 'need/triage,need/community-input,need/maintainer-input,need/maintainers-input,need/analysis,status/blocked,status/in-progress,status/ready,status/deferred,status/inactive'
|
||||
days-before-issue-stale: 6
|
||||
days-before-issue-close: 7
|
||||
enable-statistics: true
|
||||
|
||||
2
.github/workflows/sync-staging.yml
vendored
2
.github/workflows/sync-staging.yml
vendored
@@ -27,7 +27,7 @@ jobs:
|
||||
|
||||
steps:
|
||||
- name: Checkout repo
|
||||
uses: actions/checkout@v4
|
||||
uses: actions/checkout@v2
|
||||
with:
|
||||
fetch-depth: 0
|
||||
- name: Sync target branch
|
||||
|
||||
@@ -1,9 +0,0 @@
|
||||
# This configuration file was automatically generated by Gitpod.
|
||||
# Please adjust to your needs (see https://www.gitpod.io/docs/config-gitpod-file)
|
||||
# and commit this file to your remote git repository to share the goodness with others.
|
||||
|
||||
tasks:
|
||||
- init: npm install && npm run build
|
||||
command: npm run start
|
||||
|
||||
|
||||
69
README.md
69
README.md
@@ -12,65 +12,40 @@ This repository contains code and content for the [IPFS Blog & News](https://blo
|
||||
|
||||
**If you just want to submit a link (event, academic paper, tutorial, video or news coverage) to add to the site, [use this easy form](https://airtable.com/shrNH8YWole1xc70I)!**
|
||||
|
||||
### Creating a new blog post via Github pull request
|
||||
## For post authors/editors
|
||||
|
||||
Each blog post is a markdown file in the [`src/_blog`](./src/_blog) folder, with a little metadata at the top (known as YAML frontmatter) to help us create the post index page.
|
||||
While it's possible to manually PR a new blog post from a local build, **you are strongly encouraged to [use this site's Forestry integration](https://forestry.io) for drafting and editing new content.** Using Forestry offers you WYSIWYG editing (in addition to raw markdown mode), easy image upload/crop tools, and instant previews. If you're an IPFS core team member and don't have Forestry access, contact Jessica Schilling.
|
||||
|
||||
A blog post looks like this:
|
||||
Forestry uses the `staging` branch as a work-in-progress scratchpad for blog content. Once content in `staging` is approved, it can be merged into `main`, which is the branch that feeds the production site at blog.ipfs.tech. Merges into `main` are _automatically deployed_ to the production site using [Fleek](https://fleek.co/).
|
||||
|
||||
```markdown
|
||||
---
|
||||
title: Announcing the New IPFS Community Calendar
|
||||
description: 'Check out the new IPFS community calendar where you can participate and contribute to one of the many working groups advancing IPFS.'
|
||||
author: Daniel Norman
|
||||
date: 2022-12-15
|
||||
permalink: '/2022-12-ipfs-community-calendar/'
|
||||
header_image: '/ipfs-calendar/ipfs-calendar-cover.png'
|
||||
tags:
|
||||
- 'community'
|
||||
- 'calendar'
|
||||
- 'working groups'
|
||||
---
|
||||
### Forestry authoring/editing tips
|
||||
|
||||
## The IPFS community is growing
|
||||
- Use the "Content Types" section of Forestry's left-hand menu to drill down to the type of item (blog post, video, news coverage, event) you want to create/edit.
|
||||
- For card and blog post header images, **be sure to use the [image crop/scale tool](https://blog.ipfs.tech/image-crop/)** to resize and save images so they're the correct dimensions. (Don't have an image? Don't worry, there are generic fallback images.)
|
||||
- Want to embed a YouTube video in a blog post? Switch to raw markdown view and use `@[youtube](videoID)`, substituting the video's unique ID from the URL (e.g. `https://www.youtube.com/watch?v=eFbKKsEoQNg`) for `videoID`.
|
||||
- To switch between WYSIWYG and raw markdown while writing a blog post, choose "Raw Editor" or "WYSIWYG Editor" from the dots menu at the top right of the page:<br/>
|
||||
|
||||
...
|
||||
```
|
||||
### Forestry build preview tips
|
||||
|
||||
**To create your new post** create a new markdown `md` file in `src/_blog` prefixed with the year and month (as a convention) and change the name to be relevant for your post. e.g.
|
||||
While WYSIWYG mode usually gives you a good enough idea of what a blog post will look like, you can also load Forestry's own _build preview_ in a new tab by clicking the eye icon at the top right of the page:<br/>
|
||||
|
||||
```console
|
||||
$ cd src/_blog
|
||||
$ touch 2022-12-community-calendar.md
|
||||
```
|
||||
This build preview lets you preview changes to any content type (not just blog posts), and _does not_ require you to save your changes in order to see them.
|
||||
|
||||
Now edit the metadata at the top of the file.
|
||||
A few tips:
|
||||
|
||||
- `title` - used as the `h1` and `title` tag on the post-page, and the name of the post on the index page. **required**
|
||||
- `description` - used as the meta description tag on the post-page. **required**
|
||||
- `date` - the "_published at_" date, shown on the [blog index page](https://blog.ipfs.io), please update at posting time to reflect current date - **required** (posts will not be displayed until this date on the live blog, but you will see them locally when using `make dev`)
|
||||
- `author` - used to give you credit for your words - **required**
|
||||
- `tags` - used to categorize the blog post
|
||||
- `permalink` - can be used to override the post URL if needed. Please start and end URLs with a `/` (`/my/url/`).
|
||||
- `header_image` - name of the image displayed on the [blog homepage](https://blog.ipfs.tech/). See [Custom header image](#custom-header-image) for more details.
|
||||
- Click the eye icon to _regenerate_ a build preview at any time from a Forestry edit page. You may need to reload the build preview tab if you don't see changes come through immediately.
|
||||
- Occasionally, a build preview page gets stuck at a URL ending in `forestry/pending` or simply won't load. In this case, try the following:
|
||||
- Remove `forestry/pending` from the URL and try again.
|
||||
- Check the Previews section of Forestry's [`Site > Settings` page](https://app.forestry.io/sites/lg5t7mxcqbr-da/#/settings/previews) to see the preview server's current status, start/stop/restart the server, or examine the logs for errors. Simply restarting the preview server can fix many problems.
|
||||
- If all else fails, save your changes, wait a few minutes, and take a look at [Fleek's build of the latest version of the `staging` branch](https://ipfs-blog-staging.on.fleek.co/). It's a considerably slower build/deploy time, but does reflect the latest changes once it finishes deploying.
|
||||
|
||||
#### Custom header image
|
||||
### To deploy to the live site
|
||||
|
||||
Each post can have a custom image that is shown on the [blog homepage](https://blog.ipfs.tech/). To set an image:
|
||||
Changes you _save_ in Forestry are written directly to the `staging` branch and automatically generate a staging preview at https://ipfs-blog-staging.on.fleek.co/.
|
||||
|
||||
1. Add the image into `assets\header_images`. Typically the image is `2048×1152px` in jpg/png.
|
||||
1. Rename the image to match the file name of your post. For example, the `2022-12-community-calendar.md` post uses `2022-12-community-calendar.png` as the header.
|
||||
1. In the post markdown, edit the front-matter to include the `header_image` variable:
|
||||
**Once a staged post is ready to go live, please PR `staging` to `main` using [this handy shortcut](https://github.com/ipfs/ipfs-blog/compare/main...staging?expand=1).** Give your PR a title explaining what changes are inside (the default just says "Staging", which isn't helpful.) _Note that if multiple posts are in-flight in staging and only one is approved to go live, your PR may need some massaging by a reviewer._
|
||||
|
||||
```markdown
|
||||
header_image: 2022-12-community-calendar.png
|
||||
```
|
||||
|
||||
#### Creating a pull request
|
||||
|
||||
To create a pull request, you will need to fork this repository. See the GitHub docs on [how to create a pull request from a fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork). If you have the [GitHub CLI](https://cli.github.com/) installed, you can use the [`gh pr create` command](https://cli.github.com/manual/gh_pr_create) from the terminal to conveniently create a pull request.
|
||||
|
||||
Once you create the pull request, await review. If you have permissions to merge, always preview the post first to ensure everything looks right. You can do this by clicking on the "Details" link next to the **fleek/build** check that runs automatically. Clicking this link will take you to a staging site where you will then need to click on the intended post in the feed to see it.
|
||||
_Note for PR reviewers: While we continue to dogfood Forestry, please leave your edits in comments rather than making additional commits._ As our overall workflow continues to solidify, this direction may change.
|
||||
|
||||
### To add a URL redirect for a blog post
|
||||
|
||||
@@ -95,7 +70,7 @@ To build a local copy, run the following:
|
||||
1. Move into the `ipfs-blog` folder and install the npm dependencies:
|
||||
|
||||
```bash
|
||||
cd ipfs-blog
|
||||
cd ipfs-docs
|
||||
npm install
|
||||
```
|
||||
|
||||
|
||||
1081
package-lock.json
generated
1081
package-lock.json
generated
File diff suppressed because it is too large
Load Diff
@@ -73,6 +73,7 @@
|
||||
"*.{css,styl}": "stylelint --fix"
|
||||
},
|
||||
"dependencies": {
|
||||
"@carsy/task-completion-survey-banner": "^1.3.0",
|
||||
"dayjs": "^1.10.5",
|
||||
"markdown-it-image-lazy-loading": "^1.1.0",
|
||||
"markdown-it-imsize": "^2.0.1",
|
||||
|
||||
@@ -42,18 +42,20 @@ const themeConfigDefaults = {
|
||||
],
|
||||
footerLegal: '',
|
||||
headerLinks: [
|
||||
{ text: 'About', link: 'https://ipfs.tech/' },
|
||||
{ text: 'Community', link: 'https://ipfs.tech/community/' },
|
||||
{ text: 'Developers', link: 'https://ipfs.tech/developers/' },
|
||||
{ text: 'About', link: 'https://ipfs.tech/#why' },
|
||||
{ text: 'Install', link: 'https://ipfs.tech/#install' },
|
||||
{ text: 'Docs', link: 'https://docs.ipfs.tech/' },
|
||||
{ text: 'Team', link: 'https://ipfs.tech/team' },
|
||||
{ text: 'Blog', link: '/' },
|
||||
{ text: 'Help', link: 'https://ipfs.tech/help' },
|
||||
],
|
||||
mobileNavLinks: [
|
||||
{ text: 'About', link: 'https://ipfs.tech/' },
|
||||
{ text: 'Community', link: 'https://ipfs.tech/community/' },
|
||||
{ text: 'Developers', link: 'https://ipfs.tech/developers/' },
|
||||
{ text: 'About', link: 'https://ipfs.tech/#why' },
|
||||
{ text: 'Install', link: 'https://ipfs.tech/#install' },
|
||||
{ text: 'Docs', link: 'https://docs.ipfs.tech/' },
|
||||
{ text: 'Team', link: 'https://ipfs.tech/team' },
|
||||
{ text: 'Blog', link: '/' },
|
||||
{ text: 'Help', link: 'https://ipfs.tech/help' },
|
||||
],
|
||||
}
|
||||
|
||||
@@ -110,18 +112,20 @@ module.exports = {
|
||||
},
|
||||
],
|
||||
headerLinks: [
|
||||
{ text: 'About', link: 'https://ipfs.tech/' },
|
||||
{ text: 'Community', link: 'https://ipfs.tech/community/' },
|
||||
{ text: 'Developers', link: 'https://ipfs.tech/developers/' },
|
||||
{ text: 'About', link: 'https://ipfs.tech/#why' },
|
||||
{ text: 'Install', link: 'https://ipfs.tech/#install' },
|
||||
{ text: 'Docs', link: 'https://docs.ipfs.tech/' },
|
||||
{ text: 'Team', link: 'https://ipfs.tech/team' },
|
||||
{ text: 'Blog', link: '/zh-cn' },
|
||||
{ text: 'Help', link: 'https://ipfs.tech/help' },
|
||||
],
|
||||
mobileNavLinks: [
|
||||
{ text: 'About', link: 'https://ipfs.tech/' },
|
||||
{ text: 'Community', link: 'https://ipfs.tech/community/' },
|
||||
{ text: 'Developers', link: 'https://ipfs.tech/developers/' },
|
||||
{ text: 'About', link: 'https://ipfs.tech/#why' },
|
||||
{ text: 'Install', link: 'https://ipfs.tech/#install' },
|
||||
{ text: 'Docs', link: 'https://docs.ipfs.tech/' },
|
||||
{ text: 'Team', link: 'https://ipfs.tech/team' },
|
||||
{ text: 'Blog', link: '/zh-cn/' },
|
||||
{ text: 'Help', link: 'https://ipfs.tech/help' },
|
||||
],
|
||||
},
|
||||
},
|
||||
|
||||
@@ -35,7 +35,8 @@ module.exports = [
|
||||
{
|
||||
defer: true,
|
||||
'data-domain': 'blog.ipfs.tech',
|
||||
src: 'https://plausible.io/js/plausible.js',
|
||||
'data-api': 'https://proxy.daas.workers.dev/api/event',
|
||||
src: 'https://proxy.daas.workers.dev/js/script.js',
|
||||
},
|
||||
],
|
||||
].concat(favicons)
|
||||
|
||||
@@ -39,7 +39,6 @@ export default {
|
||||
case 'News coverage':
|
||||
case 'Release notes':
|
||||
case 'Tutorial':
|
||||
case 'Ecosystem content':
|
||||
case 'Video':
|
||||
return LinkCard
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@
|
||||
class="text-blueGreen hover:underline"
|
||||
href="#newsletter-form"
|
||||
@click="blockLazyLoad()"
|
||||
>newsletter</a
|
||||
>weekly newsletter</a
|
||||
>{{ `, ` }}
|
||||
<a
|
||||
class="text-blueGreen hover:underline"
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
<div class="flex-shrink lg:max-w-sm xl:max-w-xl mb-4 lg:mb-0">
|
||||
<h2 class="type-h2">Stay informed</h2>
|
||||
<p class="mt-2 mr-2">
|
||||
Sign up for the IPFS newsletter (<router-link
|
||||
Sign up for the IPFS Weekly newsletter (<router-link
|
||||
:to="latestWeeklyPost ? latestWeeklyPost.path : ''"
|
||||
class="text-blueGreenLight hover:underline"
|
||||
>example</router-link
|
||||
|
||||
@@ -13,6 +13,7 @@
|
||||
</div>
|
||||
</div>
|
||||
<div class="pt-8 pb-4 bg-white flex-grow bg-gray-background">
|
||||
<TaskCompletionSurveyBanner project="ipfs" type="sticky" />
|
||||
<SortAndFilter
|
||||
:number-of-posts="pagesToShow.length"
|
||||
:tags="tags"
|
||||
@@ -64,6 +65,8 @@ import uniqBy from 'lodash/uniqBy'
|
||||
import pick from 'lodash/pick'
|
||||
import isEqual from 'lodash/isEqual'
|
||||
import orderBy from 'lodash/orderBy'
|
||||
import TaskCompletionSurveyBanner from '@carsy/task-completion-survey-banner/src/index.vue'
|
||||
|
||||
import countly from '../util/countly'
|
||||
|
||||
const defaultCategory = { name: 'Blog post', slug: 'blog-post' }
|
||||
@@ -76,6 +79,7 @@ export default {
|
||||
SortAndFilter,
|
||||
LanguageSelector,
|
||||
VideoModal,
|
||||
TaskCompletionSurveyBanner,
|
||||
},
|
||||
data: function () {
|
||||
return {
|
||||
@@ -393,4 +397,15 @@ export default {
|
||||
.language-selector {
|
||||
bottom: -3rem;
|
||||
}
|
||||
|
||||
#pl--task-completion-survey-banner {
|
||||
--internal-max-width: 13rem;
|
||||
display: none;
|
||||
}
|
||||
|
||||
@media only screen and (min-width: 640px) {
|
||||
#pl--task-completion-survey-banner {
|
||||
display: inherit;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
|
||||
@@ -52,8 +52,4 @@
|
||||
.custom-block.left {
|
||||
float: left;
|
||||
padding: 1em 1em 1em 0em;
|
||||
}
|
||||
|
||||
.type-rich .cta-button {
|
||||
@apply text-white bg-webBlue hover:bg-blue-800 hover:no-underline font-bold py-2 px-4 rounded mr-2;
|
||||
}
|
||||
@@ -1,6 +1,5 @@
|
||||
@import './fonts/index.css';
|
||||
@import './tailwind.css';
|
||||
@import './prism-okaidia.min.css';
|
||||
|
||||
body {
|
||||
@apply bg-gray-light antialiased;
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
code[class*=language-],pre[class*=language-]{color:#f8f8f2;background:0 0;text-shadow:0 1px rgba(0,0,0,.3);font-family:Consolas,Monaco,'Andale Mono','Ubuntu Mono',monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;-moz-hyphens:none;-ms-hyphens:none;hyphens:none}pre[class*=language-]{padding:1em;margin:.5em 0;overflow:auto;border-radius:.3em}:not(pre)>code[class*=language-],pre[class*=language-]{background:#272822}:not(pre)>code[class*=language-]{padding:.1em;border-radius:.3em;white-space:normal}.token.cdata,.token.comment,.token.doctype,.token.prolog{color:#8292a2}.token.punctuation{color:#f8f8f2}.token.namespace{opacity:.7}.token.constant,.token.deleted,.token.property,.token.symbol,.token.tag{color:#f92672}.token.boolean,.token.number{color:#ae81ff}.token.attr-name,.token.builtin,.token.char,.token.inserted,.token.selector,.token.string{color:#a6e22e}.language-css .token.string,.style .token.string,.token.entity,.token.operator,.token.url,.token.variable{color:#f8f8f2}.token.atrule,.token.attr-value,.token.class-name,.token.function{color:#e6db74}.token.keyword{color:#66d9ef}.token.important,.token.regex{color:#fd971f}.token.bold,.token.important{font-weight:700}.token.italic{font-style:italic}.token.entity{cursor:help}
|
||||
@@ -1,81 +0,0 @@
|
||||
---
|
||||
tags:
|
||||
- Testground
|
||||
title: "Highlights of Testground 2022"
|
||||
description: "Testground is a platform for testing and benchmarking distributed systems. This year, the IPDX team re-ignited the project."
|
||||
date: 2022-12-20
|
||||
permalink: "/testground-highlights-in-2022/"
|
||||
translationKey: ''
|
||||
header_image: /2022-12-07-testground-article-header.png
|
||||
author: Laurent Senta
|
||||
---
|
||||
|
||||
Testground is a platform for testing and benchmarking distributed systems. We used it before to work on massive improvements to IPFS DHT, Filecoin Network, and libp2p. This year, the [IPDX team](https://pl-strflt.notion.site/IPDX-122073392dce454e9ca4b87231034483) re-ignited the project. We started two collaborations, created a new use case for interoperability testing, and welcomed new users and contributors.
|
||||
|
||||
Now that the end of the year is near; it is time for a “bragging session” and to share our master plan to take over the CIs of the entire Protocol Labs Network!
|
||||
|
||||
[[toc]]
|
||||
|
||||
## 🔌 A new use case: interoperability testing for [libp2p](https://libp2p.io/)
|
||||
|
||||
Using Testground, the libp2p team is now testing interoperability between many implementations and versions. The newly introduced tests cover go-libp2p and rust-libp2p versions already, and js and nim support is in the works.
|
||||
|
||||
**Milestones:**
|
||||
|
||||
- **Mixed Builders Feature**: We can now write a test that depends on [multiple builders and languages](https://github.com/testground/testground/pull/1367).
|
||||
- **Interoperability Support Improvements in Go**: Testground can [rewrite mod files](https://github.com/testground/testground/pull/1338), and [overwrite dependencies](https://github.com/testground/testground/pull/1338). This enables users to test many different versions of a library using a single test source.
|
||||
- [**sdk-rust**](https://github.com/testground/sdk-rust): We introduced the [sdk-rust](https://github.com/testground/testground/pull/1287) and [improved it over the year](https://github.com/testground/sdk-rust/pulls?q=is%3Apr+is%3Aclosed).
|
||||
- [**sdk-js**](https://github.com/testground/sdk-js): Thanks to [Little Bear Labs’](https://littlebearlabs.io/) support, the Testground SDK for JavaScript [now works in the browser](https://github.com/testground/sdk-js/pull/26) too.
|
||||
|
||||
We also [presented _how Testground powers libp2p interoperability testing_ at IPFS Camp](https://www.youtube.com/watch?v=b2SkC4dYV-A) (Youtube).
|
||||
|
||||
## 🤹 Massive stability improvements for supported SDKs
|
||||
|
||||
Testground has an issue with flakiness. The project's stability has been on our minds throughout the year, and we have made significant strides in this area.
|
||||
|
||||
**Milestones:**
|
||||
|
||||
- **A refreshed Docker Runner**: to support new languages better and fix concurrency issues, we [rewrote the Docker Runner](https://github.com/testground/testground/pull/1407#issuecomment-1203853804). In our tests, **false negatives went from 40% to <1%.**
|
||||
- **Benchmarking and stability improvements:** we've implemented tooling and [fixes](https://github.com/testground/testground/pull/1421) that help with CI [testing](https://github.com/libp2p/test-plans/pulls?q=is%3Apr+is%3Amerged+merged%3A%3E%3D2022-01-01). Some of this work will soon become part of the Testground Stability Dashboard and custom CI actions.
|
||||
|
||||
## 🐘 EKS Support
|
||||
|
||||
Testground is also designed to run large network tests spanning far beyond what a single machine can handle. With Testground on [EKS](https://aws.amazon.com/eks/) (managed Kubernetes service from AWS), we can support tests with more than 10k nodes.
|
||||
|
||||
**Milestones:**
|
||||
|
||||
- **Preview Support for EKS:** The [Bloxico team](https://bloxico.com/) has been working hard on [Testground EKS support](https://github.com/testground/testground/pull/1350) and [EKS infrastructure setup for Testground](https://github.com/testground/infra/pull/78). A working alpha setup is now available. Other teams, such as [Celestia](https://celestia.org/), are already building on top of it.
|
||||
|
||||
## ✨ And sooooo much more
|
||||
|
||||
✨ The team also dusted off [SDKs](https://github.com/testground/sdk-js/pull/22) and [examples](https://github.com/testground/testground/pull/1306), helped [improve ARM support](https://github.com/testground/testground/pull/1372). We introduced new [features](https://github.com/testground/testground/pull/1481), [bug fixes](https://github.com/testground/testground/pull/1321), and [brought many more improvements](https://github.com/testground/testground/pulls?q=is%3Apr+is%3Aclosed+merged%3A%3E2022-01-01+).
|
||||
|
||||
|
||||
## 🫶 New Users
|
||||
|
||||
New users and contributors are joining the project!
|
||||
|
||||
- [**Celestia**](https://celestia.org/) is using Testground to [test their network](https://github.com/celestiaorg/test-infra). Building on top of our EKS Preview, they simulate between 4 and 6 thousand nodes.
|
||||
- [**Magmo**](https://magmo.com/) is using Testground to test and benchmark their payment channel. They had success with stability and performance measurements. They shared an excellent presentation during [Retrieval Markets Summit](https://www.youtube.com/watch?v=xYn8Evkrs30) (Youtube).
|
||||
- [**status.im**](https://status.im/) is [working](https://github.com/libp2p/test-plans/pull/70) on adding their nim implementation to the libp2p interoperability repository.
|
||||
- [**Sigma Prime**](https://sigmaprime.io/) is using Testground to [test their implementation](https://github.com/ackintosh/discv5-testground) of Ethereum's Peer Discovery Protocol.
|
||||
- [**number0**](https://n0.computer/) uses Testground to benchmark [iroh](https://iroh.computer/), an IPFS implementation written in Rust focused on efficiency. They share numbers on [their website](https://iroh.computer/).
|
||||
- **Moving the Bytes Working Group** uses Testground to benchmark and test bitswap and new protocols for data exchange. You can follow along in [Notion](https://www.notion.so/MTB-WG-Meeting-1-cfeed84309894936bd652f1b47f3221a) and join the [#move-the-bytes-wg](https://filecoinproject.slack.com/archives/C04A22DCQCF) channel on FIL Slack.
|
||||
|
||||
## 🚀 What's Next
|
||||
|
||||
We shared a [Roadmap](https://github.com/testground/testground/blob/master/ROADMAP.md) for what is coming to Testground in 2023. Here are the highlights.
|
||||
|
||||
- **Better Network Simulation & New Features:** We plan on improving [network simulation](https://github.com/testground/testground/issues/1488) for libp2p and the Move The Bytes WG. We are also adding the ability to run [more complex test plans](https://github.com/testground/testground/issues/1493) and [browser support](https://github.com/testground/testground/issues/1386). Testground improves the fastest when it’s “customer-driven”.
|
||||
- **Testing, Stability, and Workflows Improvements:** the team [will invest](https://github.com/testground/testground/issues/1512) in bringing Testground building and testing tools to a state where it's easy & efficient to contribute. We want to improve the scale and stability of changes we can make, encourage external contributions, and communicate clearly about stability & regressions.
|
||||
|
||||
<div class="blog type-rich block w-full p-6 bg-white border border-gray-200 rounded-lg shadow-md dark:bg-gray-800 dark:border-gray-700">
|
||||
|
||||
✨ Testground is like that kid in the back of the class, *"great potential, needs more attention.”* We believe it's brilliant, and we'd like to encourage you to [**join us**](https://docs.testground.ai/v/master/table-of-contents/readme/community)!
|
||||
|
||||
Whether you already know Testground and can't wait for improvements, or you are discovering the project and thinking about using it, we'd like to hear more from you:
|
||||
|
||||
- [Join the Community](https://docs.testground.ai/v/master/table-of-contents/readme/community) and build the future of Testground with us!
|
||||
- Take two minutes to fill out our [User Survey Form](https://docs.google.com/forms/d/e/1FAIpQLScnsIVq2c6nLqchStzX78LyaZxo5CiIJUviMcMuYBz2QdpdMw/viewform) and help us identify pain points.
|
||||
|
||||
</div>
|
||||
@@ -1,49 +0,0 @@
|
||||
---
|
||||
tags:
|
||||
- Pin-Tweet-to-IPFS
|
||||
title: "Announcing Pin Tweet to IPFS"
|
||||
description: "Pin Tweet to IPFS is a web extension which enables users to archive Tweets in a verifiable way."
|
||||
date: 2023-01-10
|
||||
permalink: "/announcing-pin-tweet-to-ipfs/"
|
||||
translationKey: ''
|
||||
header_image: /2023-01-10-pin-tweet-to-ipfs-article-header.png
|
||||
author: David Justice
|
||||
---
|
||||
|
||||
Today we are announcing a [Web Extension](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions) from the Browsers & Platforms team to enable you to archive tweets in a verifiable way.
|
||||
|
||||
### Why?
|
||||
|
||||
Journalists and publishers rely on centralized social media sites and publications to cite sources and reference content for articles. What happens when these sites suffer financial trouble, change ownership, or face aquisition? When the original authors are censored or delete their posts? This can cause a domino effect of lost content, leaving us searching across the web for screenshots (which are easily manipulated), quoted text and archives.
|
||||
|
||||
If we take a look at some recent studies, this centralized content becomes harder to rely on.
|
||||
|
||||
|
||||
> One study estimates that about two percent of the Web disappears from its current location every week
|
||||
> [*source*](https://sites.harding.edu/fmccown/pubs/lost-website-survey-cacm-all-in-one.pdf)
|
||||
|
||||
> The 67.2M collected tweets consist of approximately 65.6M (97.6%) undeleted tweets and 1.6M (2.4%) deleted tweets.
|
||||
> [*source*](https://www.heinz.cmu.edu/~acquisti/papers/Acquisti_Large-Scale_Quantitative_Analysis_of_Deleted_Tweets.pdf)
|
||||
|
||||
*Pin Tweet to IPFS* aims to help users archive these posts in a verifiable way, publishing to the IPFS network through a [pinning service](https://medium.com/pinata/what-is-an-ipfs-pinning-service-f6ed4cd7e475) so that the content can live on verbatim.
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/P6q3lHFPN5o" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
### Under the hood:
|
||||
We are using a new tool, ["save tweet now"](https://webrecorder.github.io/save-tweet-now/), from the [WebRecorder](https://webrecorder.net/) team to create verifiable [WebArChiveZip](https://specs.webrecorder.net/wacz/1.1.1/) files of tweets. We then assist the user in uploading these "WACZ" files to the IPFS network via [web3.storage](https://web3.storage). Here users can store all of their archived tweets in one place, and easily access them via their own IPFS node or other pinning services.
|
||||
|
||||
### Where is it available?
|
||||
|
||||
Pin Tweet to IPFS is currently available in the [Chrome web store](https://chrome.google.com/webstore/detail/pin-tweet-to-ipfs/bkbejdaeamaehgpodkjdbkhkofpijagn) and [Microsoft Edge Add-ons store](https://microsoftedge.microsoft.com/addons/detail/pintweettoipfs/gimajpahenimjjgobbjjidlljnapmfgf).
|
||||
|
||||
<br />
|
||||
<a href="https://chrome.google.com/webstore/detail/pin-tweet-to-ipfs/bkbejdaeamaehgpodkjdbkhkofpijagn" class="cta-button">
|
||||
Get Pin Tweet to IPFS for Chrome
|
||||
</a>
|
||||
<a href="https://microsoftedge.microsoft.com/addons/detail/pintweettoipfs/gimajpahenimjjgobbjjidlljnapmfgf" class="cta-button">
|
||||
Get Pin Tweet to IPFS for Microsoft Edge
|
||||
</a>
|
||||
|
||||
### What's next?
|
||||
|
||||
We're continuing to iterate on *Pin Tweet to IPFS* to make archiving faster and add more verification capabilities. Take a look at our [issue tracker](https://github.com/meandavejustice/pin-tweet-to-ipfs/issues) to stay up to date on upcoming changes, and [submit your feedback](https://github.com/meandavejustice/pin-tweet-to-ipfs/issues/new).
|
||||
@@ -1,82 +0,0 @@
|
||||
---
|
||||
title: "Announcing Durin: a New Mobile App for the IPFS Network"
|
||||
description: "Durin is a native mobile application for iOS and Android that lets you read and share content on the IPFS network"
|
||||
date: 2023-05-11
|
||||
permalink: "/announcing-durin/"
|
||||
header_image: '/durin-featured-image.png'
|
||||
author: David Justice
|
||||
tags:
|
||||
- Durin
|
||||
- mobile
|
||||
- ios
|
||||
- android
|
||||
- app store
|
||||
- web3 storage
|
||||
- web3
|
||||
---
|
||||
|
||||
Today we are excited to announce **Durin**, a native mobile application for [iOS](https://apps.apple.com/us/app/durin/id1613391995) and [Android](https://play.google.com/store/apps/details?id=ai.protocol.durin) built to give users a new way to read and share with IPFS. It also serves as a sandbox for the Browsers & Platforms team to experiment with IPFS in a mobile environment.
|
||||
|
||||
## Background
|
||||
|
||||
To date, it's been difficult to access, upload, and share IPFS content using a mobile device. This is for a number of reasons, one of which is that [Kubo](https://github.com/ipfs/kubo)(the initial implementation of the protocol) was simply not built with mobile in mind. The IPFS approach to P2P for many years was about running servers, but [that is changing](https://blog.ipfs.tech/2023-03-implementation-principles/). In the meantime, we wanted to provide a quick and easy way for users to access basic IPFS features on mobile and set up a testing ground for future explorations.
|
||||
|
||||
## Accessing IPFS Content
|
||||
|
||||
The transport-agnostic nature of IPFS content addresses means there are many ways to find and retrieve content on the IPFS public network. On a mobile device, the best balance of decentralization and device performance is to align with the network model of the device OS - transient connectivity.
|
||||
|
||||
We do this in Durin by connecting to the IPFS network via multiple HTTP gateways. On app launch, Durin pings a list of public gateways, and determines which route is the most reliable and fastest way to access the network. This approach is functional but not optimal. We're working on specifications for multi-gateway connectivity patterns which balance a number of factors - such as verifiability guarantees, reader privacy, and not overloading gateways.
|
||||
|
||||
<br>
|
||||
|
||||
<img src="../assets/announcing-durin-ipfs/gateway-durin.png" alt="gateway list">
|
||||
|
||||
IPFS addresses are not natively supported in most web browsers or any mobile operating systems today. Durin registers as an `ipfs` scheme handler so that addresses are handled when encountered in applications and on the web.
|
||||
|
||||
On iOS Safari `ipfs://` protocol links will be redirected to Durin, where the app will translate and redirect the user to the fastest public gateway, making the content available on mobile. Unfortunately the auto-redirects do not work using Chrome's android app. They have not yet [implemented `registerProtocolHandler`](https://bugs.chromium.org/p/chromium/issues/detail?id=178097&q=protocol%20handler%20mobile&can=2)).
|
||||
|
||||
<br>
|
||||
|
||||
<img src="../assets/announcing-durin-ipfs/durin-redirect.gif" alt="redirect functionality on mobile safari">
|
||||
|
||||
## Sharing to IPFS from Mobile
|
||||
|
||||
Mobile devices are transiently connected and low-powered, so they do not make good servers. For sharing files and data to IPFS, Durin uses a [pinning service](https://docs.ipfs.tech/concepts/persistence/#persistence-permanence-and-pinning) to do this on behalf of the user.
|
||||
|
||||
We currently rely on [web3.storage](https://web3.storage/) for file uploads. `web3.storage` is a service that makes decentralized file storage accessible by hosting data on IPFS for the user, the way a web host does for HTTP today. NOTE: _Using a single service like this is not ideal, as users don’t hold those keys. We plan to experiment with approaches to ensuring maximal user ownership of their data while also providing remote storage and data availability._
|
||||
|
||||
Durin also saves a local history of uploads already shared.
|
||||
|
||||
<br>
|
||||
|
||||
<img src="../assets/announcing-durin-ipfs/filelist-durin.png" alt="uploaded files list">
|
||||
|
||||
Using a single remote service is a usable first step, but doesn't provide long term user control of the data published. We're looking at tighter integration with local OS data storage, local sharing between devices when possible, and pluggable remote service support.
|
||||
|
||||
## Install Durin
|
||||
|
||||
Durin is available now for mobile phones in the iOS app store and Google Play store.
|
||||
<br />
|
||||
<a href="https://apps.apple.com/us/app/durin/id1613391995" class="cta-button"> Get Durin in iOS App Store </a>
|
||||
<br />
|
||||
<a href="https://play.google.com/store/apps/details?id=ai.protocol.durin" class="cta-button"> Get Durin in Google Play Store</a>
|
||||
|
||||
## The Future
|
||||
|
||||
Durin is an experiment in learning how to expose and integrate IPFS features into mobile operating systems in ways which align optimally with those environments. We're trying out variety of ideas from contacts integration, photo sync & backup, filecoin storage, peer to peer bluetooth connectivity.
|
||||
|
||||
We'd love to hear your ideas and feedback, and have you participate!
|
||||
|
||||
* [ipfs-shipyard/durin on Github](https://github.com/ipfs-shipyard/durin)
|
||||
* [HackMd project document](https://hackmd.io/XtxGZoxqQ46X1GO7srrhMQ)
|
||||
* [Feedback link](https://github.com/ipfs-shipyard/durin/issues)
|
||||
|
||||
Join the #browsers-and-platforms channel which is bridged across the [Filecoin Slack](https://filecoin.io/slack/), [IPFS Discord](https://discord.gg/vZTcrFePpt) and [Element/Matrix](https://matrix.to/#/#browsers-and-standards:ipfs.io).
|
||||
|
||||
Checkout the IPFS Thing talk, discussing Durin's role and some future ideas for the app.
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/QkhnKm-fCs4" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
|
||||
|
||||
## Shoutout
|
||||
|
||||
Shout out to [Trigram](https://www.trigram.co/) for continued work on Durin.
|
||||
@@ -1,60 +0,0 @@
|
||||
---
|
||||
title: New Year, New IPFS Community Calendar
|
||||
description: 'Check out the new IPFS community calendar where you can you can discover and register for IPFS community events, working group meetings, and more.'
|
||||
author: Daniel Norman
|
||||
date: 2023-01-05
|
||||
permalink: '/2023-01-ipfs-community-calendar/'
|
||||
header_image: '/ipfs-calendar/ipfs-calendar-cover.png'
|
||||
tags:
|
||||
- 'community'
|
||||
- 'calendar'
|
||||
- 'working groups'
|
||||
---
|
||||
|
||||
## The IPFS community is growing
|
||||
|
||||
Over the last several years, the number of contributors, companies, and working groups advancing IPFS through specs, developer tooling, and implementations has grown significantly.
|
||||
|
||||
This reflects an important shift for the IPFS project — **IPFS is now driven by a thriving community** from all corners of the world.
|
||||
|
||||
This shift is evident on several fronts: the sheer number of working groups regularly meeting, the scope and breadth of new projects (expanding IPFS into compute with [Bacalhau](https://www.bacalhau.org/), and activity in the [IPFS specifications repo](https://github.com/ipfs/specs/) which has spiked in the last year.
|
||||
|
||||
## The New IPFS Community Calendar
|
||||
|
||||
Today, in the spirit of the new year, we're excited to share the new [IPFS Community Calendar](https://ipfs.fyi/calendar) as a hub for all IPFS community events — both offline and online.
|
||||
|
||||
We created this for you and are keen to have you join us.
|
||||
|
||||
🗓 Subscribe to the calendar to be informed about any new events added to the calendar
|
||||
🗳 Register for specific events (and event series for recurring events) in the calendar
|
||||
🎫 If you're organising a meetup or event related to IPFS, submit it for inclusion using the "**Submit** Event" button on [the calendar](https://ipfs.fyi/calendar). Once submitted we'll review it and publish it (assuming it's relevant.)
|
||||
|
||||
<br />
|
||||
<a href="https://ipfs.fyi/calendar" class="cta-button">
|
||||
Subscribe to the IPFS Community Calendar
|
||||
</a>
|
||||
|
||||
## Events for everyone
|
||||
|
||||
The versatility of IPFS attracts a variety of community members such as application developers, game developers, low-level protocol developers, service providers, and artists and creatives.
|
||||
|
||||
The community calendar should serve as the event hub for all these different groups. We already have events covering a wide spectrum of levels and areas of interest to cater to both newcomers and long standing members of the community:
|
||||
|
||||
- [Compute over Data (COD) Working Group](https://lu.ma/codwg) - community of decentralized compute projects and related tooling meeting online every two weeks and in person twice a year to collaborate and raise awareness of our space.
|
||||
- [InterPlantary Office Hours](https://lu.ma/IP-Office-Hours) - a weekly session open to all levels, where you can bring your IPFS questions.
|
||||
- [IPFS Implementers Sync](https://lu.ma/ipfs-implementers) - a meeting for those creating and maintaining IPFS implementations to discuss the protocol, specs, and [IPIPs](https://github.com/ipfs/specs/blob/main/IPIP_PROCESS.md).
|
||||
- [IPFS Content Routing Working Group](https://lu.ma/ipfs-routing-wg) - a work group focused on content routing in IPFS the subsystem responsible for how content is discovered on the IPFS network.
|
||||
- [IPVM Community Call](https://lu.ma/ipvm) - focused on the effort to add content-addressed computation with a virtual machine to IPFS.
|
||||
- [IPFS Thing 2023](https://lu.ma/ipfsthing-preregistration) - an in-person event bringing together maintainers or core contributors of an IPFS implementation, ranging from production usage to working demo.
|
||||
- [Move the Bytes Working Group](https://lu.ma/8kk9i628) - work group focused on shipping a more efficient data transfer protocol for IPFS to replace Bitswap.
|
||||
- [ProbeLab IPFS Network Measurements Office Hours](https://lu.ma/ipfs-network-measurements) - for anyone interested in IPFS network measurements in the IPFS
|
||||
- [This month in IPFS](https://lu.ma/ipfs-live) - a monthly community-oriented live stream to discuss everything going on in the IPFS ecosystem.
|
||||
|
||||
We couldn't be more excited to welcome you to join IPFS events that interest you!
|
||||
|
||||
If you're interested in hosting an event, feel free to submit it for inclusion or [reach out to us](mailto:devrel@ipfs.tech) if you have any questions.
|
||||
|
||||
<br />
|
||||
<a traget="_blank" href="https://ipfs.fyi/calendar" class="cta-button">
|
||||
Subscribe to the IPFS Community Calendar
|
||||
</a>
|
||||
@@ -1,180 +0,0 @@
|
||||
---
|
||||
title: 'IPFS Implementations: It’s Definitely A Thing'
|
||||
description: 'IPFS implementations vary wildly in order to adapt to as many situations as possible, and more keep being created. To bring clarity to the ecosystem, we look at some principles that make IPFS what it is.'
|
||||
author: Robin Berjon
|
||||
date: 2023-03-31
|
||||
permalink: '/2023-03-implementation-principles/'
|
||||
header_image: '/2023-03-implementations-flower.jpg'
|
||||
tags:
|
||||
- 'community'
|
||||
- 'ipfs thing'
|
||||
- 'event'
|
||||
---
|
||||
<style>
|
||||
.type-rich li + li {
|
||||
margin-top:0em;
|
||||
}
|
||||
.type-rich h3 {
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
.type-rich h4 {
|
||||
font-weight: bold;
|
||||
}
|
||||
.type-rich li > ul {
|
||||
padding-top:0;
|
||||
}
|
||||
table {
|
||||
background: #fff;
|
||||
}
|
||||
thead {
|
||||
background: #34797d;
|
||||
color: #fff;
|
||||
}
|
||||
td, th {
|
||||
text-align: left;
|
||||
padding: 0.25em 0.5em;
|
||||
vertical-align: top;
|
||||
}
|
||||
tbody tr:nth-of-type(even) {
|
||||
background: rgba(245, 246, 247, var(--tw-bg-opacity));
|
||||
}
|
||||
tbody tr td:first-of-type {
|
||||
white-space: nowrap;
|
||||
}
|
||||
</style>
|
||||
|
||||
If all you had ever seen were roses, daffodils, and violets, you would probably have a simplistic intuition of what a flower is. But as you discovered more examples of the bountiful world of flowering plants, including some more unusual varieties like the [Hydnora Africana](https://en.wikipedia.org/wiki/Hydnora_africana) sci-fi monsters, the absolutely massive [Corpse Flower](https://en.wikipedia.org/wiki/Amorphophallus_titanum), or perhaps more cutely the [Swaddled Babies](https://gardenofeaden.blogspot.com/2020/03/the-swaddled-babies-orchid-anguloa.html) or the laughing [Bee Orchids](https://www.thehallofeinar.com/2017/06/bee-orchids-with-no-bees-to-love-them/) then your idea of flower would have to grow, until at some point you might start wondering if you really know what counts as a flower.
|
||||
|
||||
In July 2022, a core group of architects, implementers, and committed builders in the IPFS community met in Reykjavik, Iceland for [IPFS þing](https://blog.ipfs.tech/ipfs-ping-2022-recap/), the first-ever gathering focused on growing and diversifying implementations of the IPFS protocol.
|
||||
|
||||
The event kicked off with [a call for more and different implementations](https://www.youtube.com/watch?v=xCGjxdMuKF0&list=PLuhRWgmPaHtQhyXIhu2P6e-8WlYOf8wyH&index=6) so as to make IPFS as usable and accessible as possible in today's multifaceted software environment, able to operate in a wide variety of verticals such as gaming, of languages such as Python, or of architectural constraints such as lite nodes and satellite connectivity. And in the nine months since, that's exactly what has happened: it's springtime in the distributed hemisphere and [we are frolicking across fields of tantalizing IPFS flowers](https://docs.ipfs.tech/concepts/ipfs-implementations/). With so much efflorescence, it's worth taking a step back from this [thriving broader ecosystem](https://ecosystem.ipfs.tech/) and looking at the principles that make IPFS what it is.
|
||||
|
||||
### Table of Contents
|
||||
- [What is IPFS?](#what-is-ipfs)
|
||||
- [IPFS Implementations Today](#ipfs-implementations-today)
|
||||
- [A Broader View](#a-broader-view)
|
||||
- [IPFS Principles](#ipfs-principles)
|
||||
- [Content Addressing](#content-addressing)
|
||||
- [Robustly Transport-Agnostic](#robustly-transport-agnostic)
|
||||
- [Clearer Foundations](#clearer-foundations)
|
||||
- [See You Soon!](#see-you-soon)
|
||||
- [Appendix: Implementations](#appendix-implementations)
|
||||
|
||||
## What is IPFS?
|
||||
|
||||
Quiz time! Which one of these is IPFS?
|
||||
|
||||
- ❓ Users linking to NFT assets over IPFS gateway URLs
|
||||
- ❓ Sharing an image from your phone to Web3.storage
|
||||
- ❓ Web publishing flow of static website from Github to Fleek
|
||||
- ❓ Two people chatting over over a Bluetooth connection using IPFS CID addressed data
|
||||
- ❓ Satellite beacon emitting IPFS CIDs of imagery it'll serve to an IPFS-connected ground station in that six minute window of (relatively) high bandwidth it gets a couple of times per day
|
||||
- ❓ XR headset loading scenes of static content by IPFS CID, content shipped on the hardware by the OEM
|
||||
- ❓ People reading Wikipedia from offline or censorship-resistant sources either due to poor connectivity or to [Internet restrictions](https://twitter.com/dietrich/status/1364978192075866115)
|
||||
|
||||
Answer: *All of the above!*
|
||||
|
||||
These ways of using IPFS are very different from one another — and that's a feature — but they all share two key characteristics:
|
||||
|
||||
1. Data is addressed by unique fingerprints generated from its contents
|
||||
2. Which allows data use to be transport-agnostic.
|
||||
|
||||
This might not feel like a very thorough definition, but it already tells us a lot about what is or isn't an IPFS implementation. Let's look at the lay of the land today, and explore what being an implementation actually means.
|
||||
|
||||
## IPFS Implementations Today
|
||||
|
||||
IPFS implementations vary widely, from OS-level daemons living long and fulfilling lives in data centers, to JavaScript executing in the transient twinkle of a browser tab's eye. They have to exist in the multitude of environments where users access IPFS today, and where developers need to deploy the programs that provide that access. Many of these environments are unforgiving and may explicitly constrain available capabilities to align with the host's requirements or business model, such as mobile operating systems or IoT devices.
|
||||
|
||||
When developers have maximal control of an environment, they can implement IPFS to match the ideal of the vision articulated in the [original white paper](https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf). When the deployment environment is very far from being able to achieve that ideal, or when the use case at hand is too different, implementing IPFS often means reliably getting content-addressed data in or out of that system by whatever means necessary.
|
||||
|
||||
The diversity this demands can be seen in our implementation ecosystem. For instance, we have implementations in [Go](https://github.com/ipfs/kubo), in [Java](https://github.com/Peergos/nabu), and in [JavaScript](https://github.com/ipfs/helia), as well as [one in Rust](https://github.com/n0-computer/iroh) that optimizes for extreme efficiency. We have some targeting [clusters](https://ipfscluster.io/) or [Filecoin](https://github.com/filecoin-project/lotus), meant to work in [mobile](https://github.com/ipfs-shipyard/gomobile-ipfs) or in other [embedded environments](https://github.com/ipfs-rust/ipfs-embed) as well as [for the cloud](https://github.com/elastic-ipfs/elastic-ipfs). And [the list keeps growing](https://docs.ipfs.tech/concepts/ipfs-implementations/).
|
||||
|
||||
## A Broader View
|
||||
|
||||
Today's IPFS ecosystem is larger than most people realize, and most of us only work with a subset of it. This makes it easy to develop a restrictive intuition of what IPFS is.
|
||||
|
||||
For instance, it can be tempting to reach the conclusion that supporting IPFS means being interoperable with [Kubo](https://github.com/ipfs/kubo) or supporting everything that Kubo does. Kubo is, of course, an outstanding implementation but there are excellent reasons to make different decisions if you're targeting different contexts or optimizing for different goals. This is notably true when considering Filecoin: making the data stored by Filecoin storage providers accessible to other IPFS nodes can't just mean connecting Lotus to Kubo.
|
||||
|
||||
Many successful protocols support implementations that only do one thing well, without exercising the entire protocol's capabilities and perhaps even without being fully compliant. For instance, you could write an HTTP server that listens on port 80, throws away any method, path, or header information you send it, and always responds with a code [`418`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418), `Content-Type` set to `image/jpeg`, and [a classic work of art](https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi) in the body. It might not be a fully compliant implementation of HTTP, it's arguably not a very useful implementation of HTTP, but it's still an implementation of HTTP. And there are millions of HTTP servers that don't support everything in the HTTP suite of standards but that nevertheless provide services that are far more valuable than our little thought experiment. The important part is that they can be used to resolve `http` URLs with authority.
|
||||
|
||||
This is a very useful pattern that IPFS supports as well. To give a quick and very dirty example (since that's the point), this [crude 24 line script](https://gist.github.com/darobin/9c9984586dcb133f384d3fd05f3a0bb9) can expose a Git repository as an IPFS gateway simply by making all of its objects accessible via CIDs that prefix the SHA1 hashes with `f017c1114`. Such a script could be used, for instance, to integrate a git repository into an IPFS-based archival system. This is a far cry from being an elegant implementation, and bridging Git to IPFS warrants a cleaner approach, but the point remains that glueing systems into IPFS with a minimalistic approach is no less legitimate a deployment of IPFS than a Swiss Army Knife IPFS library.
|
||||
|
||||
We should also keep in mind that many systems across the IPFS network do peer discovery and content routing outside the public DHT. This includes gateways of course, but also mDNS discovery, Gossipsub peer exchange, pinning service clusters, or wholly separate DHTs. An inclusive — but principled — view of what IPFS includes makes the ecosystem richer and more valuable for all of us.
|
||||
|
||||
|
||||
|
||||
## IPFS Principles
|
||||
|
||||
There are many ways to implement and to use IPFS, and the perspective above barely scratches the surface. But we have to be careful not to be over-inclusive: if almost anything counts as being part of IPFS, what we have isn't an ecosystem but just a bag of unrelated stuff. We need concrete principles that define the ways in which a piece of software meaningfully participates in IPFS.
|
||||
|
||||
These principles provide detail to the key characteristics which we listed at the beginning:
|
||||
|
||||
1. Data is addressed by its contents
|
||||
2. Which allows data use to be transport-agnostic.
|
||||
|
||||
### Content Addressing
|
||||
|
||||
Addressing is such an elementary part of any communication protocol that it is easy to overlook how its properties define the properties of a protocol. IP addresses are assigned based on a hierarchical authority delegated by [IANA](https://www.iana.org/) and [RIRs](https://en.wikipedia.org/wiki/Regional_Internet_registry) to network administrators for local assignment. HTTP builds atop `http` URLs, which are predicated on the domain name system delegating authority to a server, and then that server's operator having full ownership of the names in that space and of the resources they map to. This idea of hierarchy and ownership is deeply ingrained in the web's fundamental architecture documents and it has consequences for how the web works: not only is everyone dependent on DNS, but when visiting a URL you are interacting with a name and a resource that are explicitly defined as someone else's property. In turn, this gives that entity power in the relationship it has with its users.
|
||||
|
||||
IPFS's first defining characteristic is content addressing, and this is reflected in the foundational role that it gives to [CIDs](https://github.com/multiformats/cid). IPFS is, at heart, the space of resources that can be interacted with using a CID.
|
||||
|
||||
This already has multiple consequences. To begin with, CIDs are defined using [multiformats](https://multiformats.io/), which makes them future-proof, self-describing, and extensible. If, for instance, a powerful new hash algorithm surfaces then we aren't either stuck in the past or forced to find a way to upgrade everything. We can progressively roll it out on the IPFS network. Endpoints that need to produce or consume it will need to be upgraded, but the rest of the network won't care.
|
||||
|
||||
This approach also means that IPFS can interoperate with existing content-addressed systems, usually with little more work that what is required to convey whatever hash they use to a CID.
|
||||
|
||||
CIDs form a powerful and load-bearing foundation, while nevertheless being quite simple: Juan's original [CID](https://github.com/multiformats/cid#how-does-it-work) spec is detailed enough for implementation but barely runs to half a page of Markdown, including an enthusiastic parting comment about its simplicity: "*That's it!*"
|
||||
|
||||
|
||||
|
||||
By founding IPFS on CIDs we are paving the way to a [self-certifying web](https://jaygraber.medium.com/web3-is-self-certifying-9dad77fd8d81) that shifts power to people. No need to delegate authority or to give ownership over a location: the CID is a direct relationship between endpoints, between a person and the content that the CID points to. (And [IPLD](https://ipld.io/), which is also distinguished for its systematic reliance on CIDs as links, brings similar benefits to data.)
|
||||
|
||||
And content-addressing is key to enabling the other foundational characteristic, which we turn to next.
|
||||
|
||||
### Robustly Transport-Agnostic
|
||||
|
||||
Addressing content is nice, but it's often more useful if you can also use it to retrieve, move, compute over, or otherwise manipulate some data. Because IPFS is built on CIDs (self-certifying, remember?), we're free to use any transport layer without introducing concerns about the integrity of the content.
|
||||
|
||||
This transport-agnosticity makes the entire network more adaptable to local or specific needs, and it enables experimentation with a wide range of properties about how bytes are located and moved around. It future-proofs the system and makes it nimble when it has to be supported in new places, under new constraints. Developers don't even need to worry about building local- or offline-first: IPFS is both, *always*.
|
||||
|
||||
In taking this aproach, IPFS is revisiting and refreshing two older principles of protocol design. The first is the robustness principle, which has been expressed in different ways over the years but can be summarized as "*Be strict when sending and tolerant when receiving.*" While that formulation of the robustness principle has generally been accepted as unchallenged wisdom, it has recently [come under criticism in the protocol design community](https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance). When a protocol is deployed at a large scale over many years and its implementations err on the side of being tolerant, what actually tends to happen is that interoperability defects accumulate over time until new implementations become too difficult to produce and the protocol starts to decay.
|
||||
|
||||
While we want to avoid protocol decay, some degree of tolerance is nevertheless desirable as it contributes to making the system adaptable to new situations. To address this, instead of being strict in one direction and tolerant in the other, IPFS is strict at the endpoints — where CIDs are produced or verified — and tolerant in between, open to any way that will get the bytes across.
|
||||
|
||||
This new take on robustness, which we might formulate as "*Be strict about the outcomes, be tolerant about the methods*," is an implementation of the [end-to-end principle](https://en.wikipedia.org/wiki/End-to-end_principle). The end-to-end principle states that the reliability properties of a protocol have to be supported at its endpoints and not in intermediary nodes. And that's exactly what CIDs enable.
|
||||
|
||||
## Clearer Foundations
|
||||
|
||||
Put together, content-addressing using CIDs and robust transport-agnosticity are what make IPFS what it is. An IPFS implementation that doesn't build atop the excellent [libp2p](https://libp2p.io/), that doesn't do everything that Kubo does, or that only retrieves verifiable content via HTTP gateways is still an IPFS implementation.
|
||||
|
||||
In order to help clarify both this foundation and everything that sits on top of it we've progressively been [developing better specs](https://github.com/ipfs/specs/), including a [fresh evolution of the IPIP process](https://github.com/ipfs/specs/commits/main/IPIP_PROCESS.md) and a [brand new specs site](https://specs.ipfs.tech/) (and [a IPFS Thing 2023 track to go with](https://2023.ipfs-thing.io/#Standards-Governance-and-DWeb-Policy)!)
|
||||
|
||||
Part of that specification work is this proposal for [a standardized description of the principles that define IPFS](https://specs.ipfs.tech/architecture/principles/). If you are curious to read a more detailed description of the principles described in this post, I encourage you to read it.
|
||||
|
||||
## See You Soon!
|
||||
|
||||
These are exciting times: solidifying our foundations empowers us to build higher and better. The [next IPFS Thing](https://2023.ipfs-thing.io/) is just a few weeks away, April 15th-19th, in Brussels. As a community, we'll be using that opportunity to share, discuss, and blaze forward with many new IPFS capabilities and implementations. We have no doubt that, from these CIDs, many flowers will grow.
|
||||
|
||||
## Appendix: Implementations
|
||||
|
||||
The [table of implementations at docs.ipfs.tech](https://docs.ipfs.tech/concepts/ipfs-implementations/) is the one being actively maintained and you should refer to that one if you are looking for a definitive source as the ecosystem changes fast. However, for illustrative purposes, here is the list of implementations (not counting all manners of tooling and other systems) as this blog post goes to press.
|
||||
|
||||
| Name | Language | What it's trying to do |
|
||||
| -------- | -------- | -------- |
|
||||
| [Elastic provider](https://github.com/ipfs-elastic-provider/ipfs-elastic-provider) | javascript, typescript | Scalable cloud-native implementation. |
|
||||
| [Estuary](https://github.com/application-research/estuary/) | go | Daemon oriented service to pin and onboard IPFS data into Filecoin. |
|
||||
| [Kubo](https://github.com/ipfs/kubo) | go | Generalist daemon oriented IPFS implementation with an [extensive HTTP RPC API](https://docs.ipfs.tech/reference/kubo/rpc/) and [HTTP Gateway API](https://docs.ipfs.tech/reference/http/gateway/). |
|
||||
| [ipfs cluster](https://ipfscluster.io/) | go | Orchestration for multiple Kubo nodes via CRDT / Raft consensus |
|
||||
| [iroh](https://github.com/n0-computer/iroh) | rust | Extreme-efficiency oriented IPFS implementation. |
|
||||
| [Lotus](https://github.com/filecoin-project/lotus) | go | Filecoin node handling consensus, storage providing, making storage deals, importing data, ... |
|
||||
| [Nabu](https://github.com/Peergos/nabu) | java | A minimal Java implementation of IPFS |
|
||||
| [auspinner](https://github.com/2color/auspinner) | go | CLI tool to deal with the pinning service API and upload files through bitswap. |
|
||||
| [barge](https://github.com/application-research/barge) | go | CLI tool with a git like workflow to upload deltas to estuary. |
|
||||
| [Boost](https://github.com/filecoin-project/boost) | go | Daemon to get IPFS data in and out of a Filecoin storage provider. |
|
||||
| [gomobile-ipfs](https://github.com/ipfs-shipyard/gomobile-ipfs) | go | Library oriented ipfs daemon to help embeding Kubo into a mobile app. |
|
||||
| [helia](https://github.com/ipfs/helia) | javascript | A lean, modular, and modern implementation of IPFS for the prolific JS and browser environments, currently pre-alpha but [intended to replace js-ipfs](https://github.com/ipfs/js-ipfs/issues/4336). |
|
||||
| [ipfs-embed](https://github.com/ipfs-rust/ipfs-embed) | rust | Small embeddable ipfs implementation. |
|
||||
| [ipfs-lite](https://github.com/hsanjuan/ipfs-lite) | go | Minimal library oriented ipfs daemon building on the same blocks as Kubo but with a minimal glue layer. |
|
||||
| [ipfs-nucleus](https://github.com/peergos/ipfs-nucleus/) | go | Minimal IPFS replacement for P2P IPLD apps. |
|
||||
| [js-ipfs](https://github.com/ipfs/js-ipfs) | javascript, typescript | Javascript implementation targeting nodejs and browsers. [Development of js-ipfs is being discontinued](https://github.com/ipfs/js-ipfs/issues/4336). |
|
||||
| [bifrost-gateway](https://github.com/ipfs/bifrost-gateway) | go | A lightweight [HTTP+Web Gateway](https://specs.ipfs.tech/http-gateways/) daemon backed by a remote data store. [Verifies CIDs](https://docs.ipfs.tech/reference/http/gateway/#trustless-verifiable-retrieval) and enables trusted (local) use of untrusted (remote) gateways. |
|
||||
@@ -1,118 +0,0 @@
|
||||
---
|
||||
title: What happens when half of the network is down?
|
||||
description: "The IPFS DHT experienced a serious incident in the beginning of 2023, but users hardly noticed thanks to the power of a decentralized network!"
|
||||
author: Yiannis Psaras
|
||||
date: 2023-05-08
|
||||
permalink: '/2023-ipfs-unresponsive-nodes/'
|
||||
header_image: '/2023-05-ipfs-unresponsive-nodes-incident.jpeg'
|
||||
tags:
|
||||
- 'dht'
|
||||
- 'decentralization'
|
||||
- 'resource manager'
|
||||
- 'nodes'
|
||||
---
|
||||
|
||||
It depends on what type of system/network you’re running. In 90% of networks, or networked systems, this is a grand-scale disaster. Alerts are popping up everywhere, engineers go far beyond “day-time work” to get things back to normal, customers are panicking and potentially leaving the platform and the customer care lines are on fire. Half of the network is a large fraction, but I would bet that the same would happen even when 10% or 20% of the network experiences an outage.
|
||||
|
||||
It’s not like that when you run your services on a decentralized, distributed P2P network, such as IPFS! At the beginning of 2023, a critical component of the IPFS network, namely the public IPFS DHT, experienced a large-scale incident. *During this incident, [60% of the IPFS DHT Server nodes became unresponsive](https://github.com/protocol/network-measurements/blob/master/reports/2023/calendar-week-04/ipfs/plots/crawl-unresponsive.png).* Interestingly, **no content became unreachable and almost nothing in the network looked like the majority of the network was basically down**. We did observe a significant increase in the content routing/resolution latency (in the order of 25% initially), but this in no way reflected the scale of the event.
|
||||
|
||||
In this blog post, we’ll go through the timeline of the event from “Detection” to “Root Cause Analysis” and give details about the engineering team’s response. A summarizing talk on the content of this blog post was given at [IPFS Thing 2023](https://2023.ipfs-thing.io/) and can be found [on YouTube](https://youtu.be/8cGEjdCfm14).
|
||||
|
||||
## ❗️Detection: we've got a problem!
|
||||
|
||||
> At the beginning of 2023, a critical component of the IPFS network, namely the public IPFS DHT, experienced a large-scale malfunction. *During this situation, [60% of the IPFS DHT Server nodes became unresponsive](https://github.com/protocol/network-measurements/blob/master/reports/2023/calendar-week-04/ipfs/plots/crawl-unresponsive.png).*
|
||||
>
|
||||
|
||||
Unresponsive here means that nodes would seem to be online, they would accept connections from other nodes, but they wouldn’t reply to requests. Basically, when a node would try to write to one of the unresponsive nodes, the unresponsive node would terminate the connection immediately.
|
||||
|
||||
Given that these nodes seemed to be functional, they occupied several places in other nodes’ routing tables, when in fact they shouldn’t have.
|
||||
|
||||
The problem came down to a misconfiguration of the go-libp2p resource manager - a new feature that shipped with `kubo-v0.17`. The problematic configuration which was applied manually (i.e. was not based on the default values of `kubo-v0.17`) was set to such values that any attempt to interact with the nodes would be flagged as a resource exhaustion event and would trigger the corresponding “defense” mechanism. In practice, this materialized as a connection tear-down. It is worth noting that `kubo` is the most prevalent IPFS implementation using the public IPFS DHT with ~80% of nodes in the DHT being `kubo` nodes (see most recent [stats](https://github.com/protocol/network-measurements/tree/master/reports/2023/calendar-week-17/ipfs#agent-version-analysis)).
|
||||
|
||||
Content was still findable through kubo, so no alarms were raised. However, some of our research teams observed unusual error messages:
|
||||
|
||||
```go
|
||||
> Application error 0x0 (remote): conn-22188077: system: cannot reserve inbound
|
||||
connection: resource limit exceeded
|
||||
```
|
||||
|
||||
Since PUT and GET operations were completing successfully, the error didn’t seem like one that would trigger widespread panic. We were seeing slower performance than normal and had been investigating whether [recent changes with Hydra boosters](https://discuss.ipfs.tech/t/dht-hydra-peers-dialling-down-non-bridging-functionality-on-2022-12-01/15567) had bigger impacts than we were expecting. It was at this time that we had a physical meeting of our engineering teams and one of the items on the agenda was to figure out where this error was coming from.
|
||||
|
||||
## ❓ Diagnosis: what was happening?
|
||||
|
||||
We quickly realized that [there was a resource manager issue where the remote node was hitting a limit and closing the connection](https://github.com/libp2p/go-libp2p/issues/1928). After looking into the details of the resource manager and the error itself (i.e., `cannot reserve **in**bound connection`), we realized that the root cause of the issue was related to the remote node. It turned out that the resource manager was manually misconfigured by a very large percentage of nodes to values that were not in the default configuration by the “vanilla” version of the resource manager that shipped with `kubo-v0.17`.
|
||||
|
||||
As mentioned earlier, the GET and PUT operations were completing successfully, so our next step was to identify the scale of the problem. Our main goals were to figure out:
|
||||
|
||||
- what percentage of nodes in the network were affected
|
||||
- if there was a performance penalty in either the PUT or the GET operation, or both
|
||||
|
||||
Through a combination of crawling the network and attempting connections to all ~50k DHT Server nodes (i.e., those that store and serve provider records and content), we found that close to 60% of the network had been affected by the misconfiguration. Clearly this was a very large percentage of the network, which made it urgent to look into the performance impact. We followed the below methodology:
|
||||
|
||||
1. We wanted to figure out which buckets in the nodes’ routing tables did the affected nodes occupy. We found that they occupied the higher buckets of the nodes’ routing tables, which meant that most likely PUTs would get slower, but GETs should not be affected too much. This is because the DHT lookup from the GET operation terminates when it hits *one* of the 20 closest peers to the target key, while the PUT operation terminates when it has found *all* the 20 closest peers. Since a significant portion of the network was unresponsive, the PUT operation hit at least one unresponsive node, but the GET operation had good chances of finding at least one responsive node within the 20 closest.
|
||||
|
||||
|
||||
<br>
|
||||
2. After further investigation and given the very large percentage of nodes that were affected by the resource manager misconfiguration, we started looking into the impact of the incident to the GET performance.
|
||||
|
||||
A GET request that hits one of the affected, unresponsive nodes would get the connection shut down by the remote, but would get stuck there until it timed out, at which point it would re-issue the request to another peer. The relatively high concurrency factor of the IPFS DHT (`alpha = 10`) helps in this case, as it means that for any given request up to 10 concurrent requests can be in flight. This helps a lot even with a high percentage of unresponsive nodes as it means that at least one of the 10 peers contacted will respond.
|
||||
<br>
|
||||
> This is because the DHT lookup from the GET operation terminates when it hits one of the 20 closest peers to the target key, when the PUT operation terminates when it has found all the 20 closest peers.
|
||||
>
|
||||
|
||||
|
||||
<br>In the meantime, we estimated that a non negligible number of GET requests were hitting at least one unresponsive node during the lookup process. This event results in a timeout and significantly increases the request latency. There is a high probability that an unresponsive node is encountered during the last hops of the DHT walk because unresponsive peers are mostly present in higher buckets as the above figure shows.
|
||||
<br>
|
||||
3. To quantify the impact, we crawled the network and gathered the PeerIDs of unresponsive nodes. We set up six kubo nodes in several locations around the globe and attempted to: i) publish content (PUT), and, ii) retrieve content (GET) for two cases: 1) when interacting with all nodes in the network, and, 2) when ignoring all responses from the unresponsive peers, whose PeerIDs we knew and were cross-checking with in real time.
|
||||
|
||||
- The results we found were as follows:
|
||||
- The PUT operation was slowed down by approximately 10%
|
||||
<br>
|
||||
|
||||
<br>
|
||||
- The GET operation was also disrupted (in contrast to our initial assumption) and was slowed down by approximately 15%, at times reaching closer to 20%.
|
||||
<br>
|
||||
|
||||
<br>
|
||||
4. We also experimented with even higher concurrency factors, in particular with `alpha = 20`, as a potential mitigation strategy. We repeated the same experiment with one extra set of runs: the case where we interact with all nodes in the network (i.e., we do not ignore unresponsive peers), but have higher concurrency factor.
|
||||
|
||||
<br>We found that the performance increased and went back to pre-incident levels. However, it was decided *not* to go down this path, as the increased concurrency factor would: i) increase significantly the overhead/traffic in the DHT network, and, ii) stick with nodes that do not upgrade later on (when the incident is resolved) giving a clear advantage advantage to those nodes.
|
||||
|
||||
|
||||
## 🚑 Mitigation: how we stopped the bleeding.
|
||||
|
||||
The team’s immediate focus became:
|
||||
|
||||
1. [Adding/updating documentation on Kubo’s resource manager integration](https://github.com/ipfs/kubo/blob/master/docs/libp2p-resource-management.md)
|
||||
2. Triaging and responding to user questions/issues ([example](https://github.com/ipfs/kubo/issues/9432))
|
||||
3. Preparing a new kubo release (`v0.18.1`), where the default settings for the resource manager were set to more appropriate values. This reduced the likelihood that someone would need to adjust the resource manager configuration manually, thus avoiding the configuration “footguns”.
|
||||
4. Encouraging as many nodes as possible to upgrade through public forums and direct relationships with known larger scale operators.
|
||||
|
||||
In parallel, we kept monitoring the situation by instrumenting a PUT and GET measurement experiment that was running since before the `kubo-v0.18.1` update, when the affected nodes started updating gradually.
|
||||
|
||||
`kubo-v0.18.1` was [released on the 2023-01-30](https://github.com/ipfs/kubo/releases/tag/v0.18.1) and within the first 10 days, more than 8.5k nodes updated to this release. Our monitoring software allowed us to have an accurate view of the state of the network and observed that the update to the new kubo release brought significant performance increase for the GET operation - more than 40% at the 95th percentile on a sample of ~2k requests, compared to the situation before the `kubo-v0.18.1` release.
|
||||
|
||||
|
||||
|
||||
We also monitored the situation compared to the pre-incident performance by running the experiment where we ignored the set of PeerIDs that were identified as affected by the misconfiguration. As a sample from more than 20k GET operations, in the figure below we show that the impact has reduced to ~5% (mid-February 2023).
|
||||
|
||||
|
||||
|
||||
## 🔧 Addressing the Root Cause
|
||||
|
||||
Our immediate actions managed to stop the bleeding and bring the network back to normal quickly. However, it was clear that we had to implement longer term fixes to protect the nodes’ routing tables from unresponsive peers and to avoid inadvertently making nodes unresponsive. Specifically this translated to:
|
||||
|
||||
1. Revamping the Kubo resource manager UX to further reduce the likelihood of catastrophic misconfiguration. This was completed in [Kubo 0.19](https://github.com/ipfs/kubo/releases/tag/v0.19.0#improving-the-libp2p-resource-management-integration).
|
||||
2. Only adding peers to the routing table that are responsive requests [during the routing table refresh](https://github.com/libp2p/go-libp2p-kad-dht/pull/810) (done) and [upon adding a node to the routing table](https://github.com/libp2p/go-libp2p-kad-dht/issues/811) (in progress - targeting [Kubo 0.21 in May](https://github.com/ipfs/kubo/issues/9814)).
|
||||
|
||||
## 📖 Lessons Learned
|
||||
|
||||
In the days since, we have come away from this experience with several important learnings:
|
||||
|
||||
🗒️ Significant fundamental changes to the codebase (such as retroactively adding resource accounting) is ripe for disruption. This increases the necessity for documentation, announcements, and clear recommendations to node operators.
|
||||
|
||||
⏱️ Monitoring software should always be in place to help identify such events from the start.
|
||||
|
||||
📣 It is challenging to monitor and apply changes directly to the software that runs on nodes of a decentralized network. Well-established communication channels go a long way and help the engineering teams communicate directly with the community. In IPFS, we use a variety of channels including the Discord Server [[invite link](https://discord.gg/ipfs)], Filecoin Slack [[invite link](https://filecoin.io/slack)] (mostly in `#engres-ip-stewards` channel), the [Discourse discussion forum](https://discuss.ipfs.tech/), and the [blog](https://blog.ipfs.tech/).
|
||||
|
||||
🚀 Last, but certainly not least, the decentralized, P2P nature of IPFS kept the network running with all important operations completing successfully (albeit slower than normal). It is exactly because of the structure of the network that there are no single points of failure and performance is not catastrophically disrupted even when more than half of the network nodes are essentially unresponsive.
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: ⛔️ js-IPFS deprecation / replaced by Helia 🌞
|
||||
description: 'js-IPFS is being deprecated, and has been superseded by Helia.'
|
||||
author: Alex Potsides (@achingbrain)
|
||||
date: 2023-05-26
|
||||
permalink: '/202305-js-ipfs-deprecation-for-helia/'
|
||||
header_image: '/2023-05-js-ipfs-deprecation-for-helia-header-image.png'
|
||||
tags:
|
||||
- 'helia'
|
||||
- 'js-ipfs'
|
||||
---
|
||||
|
||||
**TL;DR: [js-IPFS](https://github.com/ipfs/js-ipfs) is being deprecated, and has been superseded by [Helia](https://github.com/ipfs/helia).**
|
||||
|
||||
There are exciting times ahead for IPFS in JS. Some of you may have already heard of [Helia](https://github.com/ipfs/helia), the new implementation that's designed as a composable, lightweight, and modern replacement for js-IPFS.
|
||||
|
||||
It has a [simplified API](https://ipfs.github.io/helia/interfaces/_helia_interface.Helia.html) which can be extended by other modules depending on the requirements of your application such as [@helia/unixfs](https://github.com/ipfs/helia-unixfs), [@helia/ipns](https://github.com/ipfs/helia-ipns), [@helia/dag-cbor](https://github.com/ipfs/helia-dag-cbor) and [others](https://github.com/ipfs/helia#-code-structure).
|
||||
|
||||
It ships with the latest and greatest libp2p, which means it has the best connectivity options, including the new [WebTransport](https://github.com/libp2p/js-libp2p-webtransport) and [WebRTC](https://github.com/libp2p/js-libp2p-webrtc) transports that dramatically improve the connectivity options for browser environments.
|
||||
|
||||
[js-IPFS is in the process of being deprecated](https://github.com/ipfs/js-ipfs/issues/4336) so you should port your apps to Helia to receive bug fixes, features, and performance improvements moving forwards.
|
||||
|
||||
📚 [Learn more about this deprecation](https://github.com/ipfs/js-ipfs/issues/4336) or [how to migrate](https://github.com/ipfs/helia/wiki/Migrating-from-js-IPFS).
|
||||
|
||||
More new blog content discussing Helia coming soon!
|
||||
@@ -1,193 +0,0 @@
|
||||
---
|
||||
title: IPFS Multi-Gateway Experiment in Chromium
|
||||
description: A new approach to implementing ipfs:// and ipns:// support natively in the browser, using a client-only approach and fetching verifiable responses from multiple HTTP gateways.
|
||||
author: John Turpish
|
||||
date: 2023-06-01
|
||||
permalink: "/2023-05-multigateway-chromium-client/"
|
||||
translationKey: 2023-05-multigateway-chromium-client
|
||||
header_image: "/multi-gateway-experiment.png"
|
||||
tags:
|
||||
- browsers
|
||||
- chromium
|
||||
|
||||
---
|
||||
|
||||
[IPFS](https://ipfs.tech) is a protocol suite for a [content-addressed networking](https://en.wikipedia.org/wiki/Content-addressable_network). If you'd like to run a [node](https://docs.ipfs.tech/concepts/glossary/#node) and participate in the peer-to-peer network, by all means [give it a try](https://ipfs.tech/#install)!
|
||||
|
||||
The most important thing to get: With IPFS you can fetch something by a Content ID ([CID](https://docs.ipfs.tech/concepts/glossary/#cid)), which represents what it is, not where it's coming from.
|
||||
|
||||
The other way of fetching things from the IPFS ecosystem is through [IPNS](https://docs.ipfs.tech/concepts/ipns/#mutability-in-ipfs), which allows someone to cryptographically sign a reference to a CID, then you can request whatever content that person/organization is currently pointing to as their site.
|
||||
|
||||
Essentially, `http://` specifies "where" to find it, `ipfs://` specifies "what" to find, and `ipns://` specifies "whose" content to find.
|
||||
|
||||
What about people who don't know about IPFS, and just run across a [link](https://docs.ipfs.tech/concepts/glossary/#link)? What if they'd like to be able to use that link in their browser? This is where a "client" fits in - software that can talk to nodes to fetch the content they want, but without running one yourself.
|
||||
|
||||
## What is this all about?
|
||||
|
||||
Most IPFS clients talk to a particular HTTP [gateway](https://docs.ipfs.tech/concepts/glossary/#gateway). Multi-Gateway Clients proposed in [IPIP-359](https://github.com/ipfs/specs/pull/359) fulfill your requests using multiple [Trustless Gateways](https://specs.ipfs.tech/http-gateways/trustless-gateway/). This gives you more resilience, as you're not dependent on a single HTTP endpoint that can be censored or blocked by your ISP. It also can result in better performance, as you can multiplex requests that would typically run through a single server.
|
||||
|
||||
Here we're talking about [a project to implement IPFS in Chromium](https://github.com/little-bear-labs/ipfs-chromium). The result is an experimental racing multi-gateway client built directly into the browser, which means the same request might get sent to multiple Trustless Gateways, and the first one to get the result verified wins. And it's built into a custom-patched build of Chromium.
|
||||
|
||||
## Why build this?
|
||||
|
||||
This is by no means the first time IPFS has been usable in a browser, or even Chromium-based browsers in particular. Javier Fernández at Igalia has written some good explanations of other approaches that have been taken over at his blog in his post *[Discovering Chrome’s pre-defined Custom Handlers](https://blogs.igalia.com/jfernandez/2022/11/14/discovering-chromes-pre-defined-custom-handlers/)*, and there's an [overview on the IPFS blog](https://blog.ipfs.tech/14-11-2022-igalia-chromium/) as well.
|
||||
|
||||
Most of these approaches share in common the idea of translating IPFS and [IPNS](https://docs.ipfs.tech/concepts/glossary/#ipns) requests, 1:1, into HTTP requests. For example, if you have an HTTP gateway running locally on your machine, something like:
|
||||
|
||||
> ipfs://bafybeihpy2n6vwt2jjq5gusv23ajtilzbao3ekfb2hiev2xvuxscdxqcp4
|
||||
|
||||
might become:
|
||||
|
||||
> http://localhost:8080/ipfs/bafybeihpy2n6vwt2jjq5gusv23ajtilzbao3ekfb2hiev2xvuxscdxqcp4/
|
||||
|
||||
Or maybe it could become
|
||||
|
||||
>[https://ipfs.io/ipfs/bafybeihpy2n6vwt2jjq5gusv23ajtilzbao3ekfb2hiev2xvuxscdxqcp4/](https://ipfs.io/ipfs/bafybeihpy2n6vwt2jjq5gusv23ajtilzbao3ekfb2hiev2xvuxscdxqcp4/)
|
||||
|
||||
Or preferably (when [Origin isolation](https://en.wikipedia.org/wiki/Same-origin_policy) matters):
|
||||
|
||||
>[https://bafybeihpy2n6vwt2jjq5gusv23ajtilzbao3ekfb2hiev2xvuxscdxqcp4.ipfs.dweb.link/](https://bafybeihpy2n6vwt2jjq5gusv23ajtilzbao3ekfb2hiev2xvuxscdxqcp4.ipfs.dweb.link/)
|
||||
|
||||
In each case, you're delegating all the "IPFS stuff", including CID (hash) verification, to a particular node. This is effective for completing requests, but has some trade-offs, including the privacy and integrity risks when using a remote gateway provided by a third-party.
|
||||
|
||||
### Performance
|
||||
|
||||
If the gateway you're using happens to have the data you're seeking already on-hand, your performance will be great, since it can simply return to you what it already has. Perforance might even be better than the multi-gateway client, since no extraneous requests would be made. However, if you were unlucky, that gateway will have to spend more time querying the IPFS network to try to find the data you request before it gives up. The ideal gateway to use may very well depend on what you happen to be doing at the moment - and may differ from one of your tabs to another. A multi-gateway client will have the worst case performance more rarely.
|
||||
|
||||
And while we've been talking about "files" for the most part, IPFS breaks larger files down into "blocks". So you can apply these same techniques at the block level, and it's also conceivable that for a sufficiently large file which exists on multiple gateways you're talking to, a verifying multi-gateway client might be able to be faster than a single-gateway client, since you might be pulling down parts of the file from different sources concurrently. [RAPIDE](https://github.com/ipfs/go-libipfs-rapide/issues/12) is a more advanced in-development client which also makes use of this principle (along with other things). And it's showing promising results - watch a [recent talk from IPFS Thing by Jorropo](https://www.youtube.com/watch?v=Cv01ePa0G58) on it!
|
||||
|
||||
### Installation (vs. local gateway)
|
||||
|
||||
If you're reading this, installing a local node might seem like no big deal to you. However, we want IPFS to be accessible to people who haven't heard of it, and make it easy for them to click a link without having to think about which protocol-handling software they have installed ahead of time.
|
||||
|
||||
One approach is to have the browser install and start its own IPFS node. This is a pretty reasonable approach, but it can raise questions about when to dedicate resources to installation or the node's [daemon](https://docs.ipfs.tech/concepts/glossary/#daemon). The most notable example of this approach is [Brave](https://brave.com/ipfs-support/).
|
||||
|
||||
|
||||
|
||||
However, regardless of whether the browser manages a [Kubo](https://github.com/ipfs/kubo#readme) node as Brave does or implements IPFS natively, the architecture of the application has changed in a significant way - *from being strictly a client, to being a server*.
|
||||
|
||||
Including HTTP-client-only IPFS capabilities in a Chromium-based browser doesn't change the installation experience in a noticeable way, nor require any major rethink of the browser security model.
|
||||
|
||||
### Security (vs. single public gateway)
|
||||
|
||||
Content-addressed networking involves a validation step to make sure that the data you received matches the [hash](https://docs.ipfs.tech/concepts/glossary/#hash) requested (it's a part of the CID). When you're requesting a file from an HTTP gateway, by default, the verification of the content is delegated to the node running the gateway. Further, if you receive the file in its final deserialized form as a response to a single request, naively using just an HTTP client, it's no longer possible to verify locally.
|
||||
|
||||
This is probably fine if the gateway you're talking to is one you're running locally. Presumably you trust that software as much as you trust your own browser.
|
||||
|
||||
The public IPFS gateways today appear to be consistently and reliably returning the correct results. Nonetheless the possibility exists, and it would be preferable if we didn't have to trust. That's why this experimental Chromium implementation uses the [Trustless Gateway](https://specs.ipfs.tech/http-gateways/trustless-gateway/) API and verifies the retrieved content locally.
|
||||
|
||||
## Where is the code?
|
||||
|
||||
In the repo you'll see separation between [component](https://github.com/little-bear-labs/ipfs-chromium/tree/main/component) and [library](https://github.com/little-bear-labs/ipfs-chromium/tree/main/library), where the former contains Chromium-specific code, and the latter contains code that helps with IPFS implementation details that can build without Chromium.
|
||||
|
||||
This distinction disappears when you switch over to the Chromium build. Both sets of source are dumped into a component (basically a submodule) called `ipfs`, that implements the handling of `ipfs://` and `ipns://` URLs.
|
||||
|
||||
Those who embed Chromium into another application generally provide an implementation of a couple of interfaces, namely `ContentClient` and `ContentBrowserClient`. They would need to add a little code to their implementations to use the `ipfs` component. Our repo contains a patch file which alters Chrome's implementations of these two as a demonstration to show how usage might work. That patch file might be useful as-is to someone who uses a patching approach to make a Chromium-derived browser.
|
||||
|
||||
## How (in more detail)?
|
||||
|
||||
### Hooking into Chromium
|
||||
|
||||
* The `ipfs://` and `ipns://` schemes are registered in [`ContentClient::AddAdditionalSchemes`](https://source.chromium.org/chromium/chromium/src/+/main:content/public/common/content_client.h;l=156?q=AddAdditionalSchemes), so the origin will be handled properly.
|
||||
* An interceptor is created in [`ContentBrowserClient::WillCreateURLLoaderRequestInterceptors`](https://source.chromium.org/chromium/chromium/src/+/main:content/public/browser/content_browser_client.h;l=1733?q=WillCreateURLLoaderRequestInterceptors), which just checks the scheme, so `ipfs://` and `ipns://` navigation requests will be handled by `components/ipfs`.
|
||||
* URL loader factories created for `ipfs` and `ipns` schemes in [`ContentBrowserClient::RegisterNonNetworkSubresourceURLLoaderFactories`](https://source.chromium.org/chromium/chromium/src/+/main:content/public/browser/content_browser_client.h;l=1503?q=RegisterNonNetworkSubresourceURLLoaderFactories), so in-page resources with `ipfs://` / `ipns://` URLs (or relative URLs on a page loaded as `ipfs://`), will also be handled by `components/ipfs`.
|
||||
|
||||
### Issuing HTTP(S) requests to Trustless Gateways
|
||||
|
||||
The detailed steps of the algorithm are laid out in [the design doc](https://github.com/little-bear-labs/ipfs-chromium/blob/main/DESIGN.md), but here's the basic idea:
|
||||
|
||||
* An IPFS link will have a CID in the URL. This is the [root](https://docs.ipfs.tech/concepts/glossary/#root) of its [DAG](https://en.wikipedia.org/wiki/Merkle_tree), which contains directly or indirectly all the info needed to get all the files related to the site, and will be the first [block](https://docs.ipfs.tech/concepts/glossary/#block) needed to access the file/resource.
|
||||
* For any given block that is known to be needed, but not present in-memory, send requests to several gateways which haven't responded with an error for this CID yet and don't currently have pending requests to them. These requests have `?format=raw` so that we'll get just the one block (with `Content-Type` [application/vnd.ipld.raw](https://www.iana.org/assignments/media-types/application/vnd.ipld.raw)), not the whole file.
|
||||
* When a response comes from a gateway, hash it according to the algo specified in the CID's [multihash](https://docs.ipfs.tech/concepts/glossary/#multihash). Right now, that has to be sha-256, and luckily it generally is. If the hashes don't match, the gateway's response gets treated much like an error - the gateway gets reduced in priority, and a new request goes out to a gateway that hasn't yet received this request.
|
||||
* If the hashes are equal, store the block, process the block as described in Codecs (below). If the new node includes links to more blocks we also need, send requests for those blocks.
|
||||
* When the browser has all the blocks needed, piece together the full file/resource and create an HTTP response and return it, as if it had been a single HTTP request all along.
|
||||
|
||||
### Codecs
|
||||
|
||||
If a CID is V0, we assume the [codec](https://docs.ipfs.tech/concepts/glossary/#codec) is [`dag-pb`](https://docs.ipfs.tech/concepts/glossary/#dag-pb) (see below). Other CIDs specify the codec, and right now we support these 2:
|
||||
|
||||
#### `raw` (`0x55`)
|
||||
|
||||
A block of this type is a blob - a bunch of bytes. We'll populate the body of the response with it.
|
||||
|
||||
#### `dag-pb` (`0x70`)
|
||||
|
||||
That's [ProtoBuf](https://protobuf.dev/)-encoded [Directed Acyclic Graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph). A block of this type is a node in a DAG, and contains some bytes to let you know what kind of node it is. There is one very special and important type of node ipfs-chromium deals with a lot:
|
||||
|
||||
##### UnixFS Node
|
||||
|
||||
The payload of these nodes have another ProtoBuf layer, and the DAG functions in a conceptually similar way to a read-only file system.
|
||||
|
||||
Not all kinds of UnixFS nodes are fully handled yet, but we cover these:
|
||||
|
||||
###### File (simple case)
|
||||
|
||||
These nodes each have a `data` byte array that is the contents of a file. We'll use those bytes as the body of a response.
|
||||
|
||||
###### File (multi-node)
|
||||
|
||||
In UnixFS a node can represent a file as the concatenation of other file nodes, to which it has `links`. The decision to use this kind of node generally has to do with the size of the file. A single node can't be much more than a megabyte, so files larger than that get cut into chunks and handled as a tree of nodes. There are a couple of reasons for that:
|
||||
|
||||
* Data deduplication (it's possible the same sequences of bytes, and thus same CID, appears in multiple files or even within the same file)
|
||||
* In the case that a gateway were malicious, we wouldn't want to wait until a file of potentially unbounded size finishes downloading before we verify that it's correct. "ipfs-chromium" enforces a limit of 2MB per block.
|
||||
* It enables the possibility that one could concurrently fetch different parts of the file from different gateways.
|
||||
|
||||
If we have all the nodes linked-to already, we can concatenate their data together and make a response body out of it. If we don't, we'll convert the missing links to CIDs and request them from gateways.
|
||||
|
||||
###### Directory (normal)
|
||||
|
||||
In this case the `data` field isn't really important to us. The `links`, however, represent items in the directory.
|
||||
|
||||
* If your URL has a path, find the `link` matching the first element in the path, and repeat the whole process with that `link`'s CID and the remainder of the path.
|
||||
* If you don't have a path, we'll assume you want `index.html`
|
||||
* If there's no `index.html` we'll generate an directory listing HTML file for you.
|
||||
|
||||
###### [HAMT](https://en.wikipedia.org/wiki/Hash_array_mapped_trie) (sharded) Directory
|
||||
|
||||
This is for directories with just too many entries in them to fit in a single block. The links from this directory node might be entries in the directory or they might be other HAMT nodes referring to the same directory (basically, the directory itself is getting split up over a tree of nodes).
|
||||
|
||||
* If you're coming in from another HAMT node, you might have some unused bits of the hash to select the next child.
|
||||
* If you have a path, hash the name of the item you're looking for, pop the correct number of bits off the hash, and use it to select which element you're going to next.
|
||||
* If you don't have a path, we'll assume you want `index.html`.
|
||||
* We don't generate listings of sharded directories today, and this isn't a high-priority as it's an unreasonable use case.
|
||||
|
||||
### Dealing with ipns:// links
|
||||
|
||||
The first element after `ipns://` is the "[ipns-name](https://specs.ipfs.tech/ipns/ipns-record/#ipns-name)".
|
||||
|
||||
* If the name is formatted as a CIDv1, and has its codec set to `libp2p-key` (`0x72`), ipfs-chromium will retrieve a [signed IPNS record](https://specs.ipfs.tech/ipns/ipns-record/#ipns-record) of what it points at from a gateway, and then load that content.
|
||||
* The cryptographic signature in the record is verified using the public key, which corresponds to the "ipns-name"
|
||||
* Note: only two [multibase](https://docs.ipfs.tech/concepts/glossary/#multibase) encodings are fully supported for now: base36 and base32. If your IPNS or DNSLink record points to something base58 that should work, but otherwise avoid it (don't use it in the address bar!).
|
||||
* If the name is not formatted as a CIDv1, a DNS request is created for the appropriate TXT record to resolve it as a [DNSLink](https://dnslink.dev/).
|
||||
|
||||
IPNS names may point to other IPNS names, in which case this process recurses. More commonly they point at an IPFS DAG, in which case ipfs-chromium will then load that content as described above.
|
||||
|
||||
## Bottom Line
|
||||
|
||||
So, in the end, the user gets to treat `ipfs://` links to snapshotted data like any other link, gets the result in a reasonable timeframe, and can rely on the data they get back being the correct data.
|
||||
|
||||
`ipns://` URLs of the DNSLink variety rely only on DNS being accurate.
|
||||
Regular `ipns://` URLs, however, are verified by the cryptographically signed [record](https://specs.ipfs.tech/ipns/ipns-record/).
|
||||
|
||||
## Trying it out
|
||||
|
||||
If you want to try this yourself today, you can [build it](https://github.com/little-bear-labs/ipfs-chromium/blob/main/BUILDING.md) from source, or you may install a pre-built binary from [GitHub releases](https://github.com/little-bear-labs/ipfs-chromium/releases/) or [an IPFS gateway](https://gateway.ipfs.io/ipfs/QmdsmW9pSM8kQsnwFpHrqQFskv6H26XzhnZWYHGVdAfcbm).
|
||||
|
||||
If you'd just like to see it in action, here are the links I use in the video below:
|
||||
|
||||
* `ipfs://bafybeigchjo5f3jyzfjwmbavhr27jwdhu6wwhsodxg4qq4x72aasxewp64/blog.html` - a snapshot of this blog post
|
||||
* `ipns://k51qzi5uqu5dkq4jxcqvujfm2woh4p9y6inrojofxflzdnfht168zf8ynfzuu1/blog.html` - a mutable pointer to the current version of this blog
|
||||
* `ipns://docs.ipfs.tech` - The IPFS documentation.
|
||||
* `ipns://en.wikipedia-on-ipfs.org/wiki/` - Wikipedia, as a big HAMT + DNSLink
|
||||
* `ipns://ipfs.io` - an unusual case: a DNSLink to another DNSLink
|
||||
* `https://littlebearlabs.io` - an HTTPs URL for comparison.
|
||||
|
||||
<iframe width="70%" src="https://www.youtube.com/embed/9XJOktFizlo" frameborder="1" allow="accelerometer; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
|
||||
|
||||
## When could this be widespread?
|
||||
|
||||
This is very experimental, and will not be in mainstream browsers tomorrow. Feel free to vote for [the issue](https://bugs.chromium.org/p/chromium/issues/detail?id=1440503) where we discuss its future.
|
||||
|
||||
## Who is doing this?
|
||||
|
||||
[Little Bear Labs](https://littlebearlabs.io) and [Protocol Labs](https://protocol.ai)
|
||||
@@ -1,170 +0,0 @@
|
||||
---
|
||||
title: A Rusty Bootstrapper
|
||||
description: 'Running rust-libp2p-server on one of our four IPFS bootstrap nodes.'
|
||||
author: Max Inden (@mxinden)
|
||||
date: 2023-07-24
|
||||
permalink: '/2023-rust-libp2p-based-ipfs-bootstrap-node/'
|
||||
header_image: ''
|
||||
tags:
|
||||
- 'Kademlia'
|
||||
- 'Rust'
|
||||
---
|
||||
|
||||
# Summary
|
||||
|
||||
As of July 13, 2023, one of the four "public good" IPFS bootstrap nodes operated by Protocol Labs has been running [rust-libp2p-server](https://github.com/mxinden/rust-libp2p-server) instead of [Kubo](https://github.com/ipfs/kubo), which uses [go-libp2p](https://github.com/libp2p/go-libp2p/). rust-libp2p-server is a thin wrapper around [rust-libp2p](https://github.com/libp2p/rust-libp2p). We run both Kubo and rust-libp2p-server on IPFS bootstrap nodes to increase resilience. A bug or vulnerability is less likely to be in both Kubo and rust-libp2p-server than Kubo alone. In addition to increasing resilience, we gain experience running large rust-libp2p based deployments on the IPFS network.
|
||||
|
||||
|
||||
|
||||
# IPFS Public DHT Bootstrap Nodes
|
||||
|
||||
_What is an IPFS bootstrap node?_
|
||||
|
||||
> A Bootstrap Node is a trusted peer on the IPFS network through which an IPFS node learns about other peers on the network. [...]
|
||||
|
||||
See [IPFS Glossary](https://docs.ipfs.tech/concepts/glossary/#bootstrap-node).
|
||||
|
||||
A new node trying to join the "[public IPFS DHT](https://github.com/ipfs/ipfs/discussions/473)", i.e. trying to bootstrap, will:
|
||||
|
||||
1. Connect to its (pre-) configured bootstrap nodes.
|
||||
2. Run some variation of the [Kademlia bootstrap process](https://github.com/libp2p/specs/tree/master/kad-dht#bootstrap-process) which boils down to iteratively:
|
||||
1. Generating random IDs.
|
||||
2. Asking already discovered nodes whether they know anyone closer to those IDs.
|
||||
|
||||
Thus the only thing that an IPFS bootstrap node needs to do is:
|
||||
|
||||
- Allow incoming connections.
|
||||
- Maintain a healthy Kademlia routing table.
|
||||
- Reply to Kademlia `FIND_NODE` requests based on nodes in its routing table.
|
||||
|
||||
Let's dive a bit deeper. In the case of Kubo the [DNSAddr](https://github.com/multiformats/multiaddr/blob/master/protocols/DNSADDR.md) addresses of the IPFS bootstrap nodes are shipped within the release binary.
|
||||
|
||||
``` go
|
||||
// DefaultBootstrapAddresses are the hardcoded bootstrap addresses
|
||||
// for IPFS. they are nodes run by the IPFS team. docs on these later.
|
||||
// As with all p2p networks, bootstrap is an important security concern.
|
||||
var DefaultBootstrapAddresses = []string{
|
||||
"/dnsaddr/bootstrap.libp2p.io/p2p/QmNnooDu7bfjPFoTZYxMNLWUQJyrVwtbZg5gBMjTezGAJN",
|
||||
"/dnsaddr/bootstrap.libp2p.io/p2p/QmQCU2EcMqAqQPR2i9bChDtGNJchTbq5TbXJJ16u19uLTa",
|
||||
"/dnsaddr/bootstrap.libp2p.io/p2p/QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb",
|
||||
"/dnsaddr/bootstrap.libp2p.io/p2p/QmcZf59bWwK5XFi76CZX8cbJ4BhTzzA3gU1ZjYZcYW3dwt",
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
See [`bootstrap_peers.go` on github.com/ipfs/kubo](https://github.com/ipfs/kubo/blob/v0.21.0/config/bootstrap_peers.go#L11C1-L24C2).
|
||||
|
||||
One can resolve those `/dnsaddr/...` through iterative DNS queries. Below is an example for the node with the peer ID `QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb`. This IPFS bootstrap node is running Kubo.
|
||||
|
||||
```
|
||||
dig +short -t txt _dnsaddr.bootstrap.libp2p.io
|
||||
"dnsaddr=/dnsaddr/am6.bootstrap.libp2p.io/p2p/QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb"
|
||||
[...]
|
||||
```
|
||||
|
||||
```
|
||||
dig +short -t txt _dnsaddr.am6.bootstrap.libp2p.io
|
||||
"dnsaddr=/ip6/2604:1380:4602:5c00::3/udp/4001/quic-v1/p2p/QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb"
|
||||
[...]
|
||||
```
|
||||
|
||||
Finally connecting to the bootrap node shows us the protocols it supports.
|
||||
Below example uses [`libp2p-lookup`](https://github.com/mxinden/libp2p-lookup/) but `ipfs swarm connect` followed by `ipfs id` can be used instead.
|
||||
|
||||
|
||||
```
|
||||
libp2p-lookup direct --address /ip6/2604:1380:4602:5c00::3/udp/4001/quic-v1/p2p/QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb
|
||||
|
||||
Lookup for peer with id PeerId("QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb") succeeded.
|
||||
|
||||
Protocol version: "ipfs/0.1.0"
|
||||
Agent version: "kubo/0.20.0/b8c4725"
|
||||
Listen addresses:
|
||||
- "/ip6/2604:1380:4602:5c00::3/udp/4001/quic-v1"
|
||||
- [...]
|
||||
Protocols:
|
||||
- /ipfs/kad/1.0.0
|
||||
- [...]
|
||||
```
|
||||
|
||||
Note the `Agent version: "kubo/0.20.0/b8c4725"` and the supported protocols `Protocols: - /ipfs/kad/1.0.0`.
|
||||
|
||||
# Motivation
|
||||
|
||||
_Why run both Kubo and rust-libp2p2-server bootstrap nodes?_
|
||||
|
||||
This choice is influenced by three main areas: the benefit of diverse implementations, the opportunity to test rust-libp2p at large scale, and the presence of Rust in the IPFS network.
|
||||
|
||||
Implementation Diversity: Operating both Kubo and rust-libp2p-server bootstrap nodes contributes to the network's overall resilience and security. It's like having a second line of defense; if one system encounters an issue, the other is there to continue functioning. For instance, a recent bug impacted Kubo IPFS bootstrap nodes, closing incoming connections, right after their successful establishment, due to a QUIC version mismatch. By using both Kubo and rust-libp2p-server, we ensure that nodes can still join the network, even if one set of bootstrap nodes is unavailable.
|
||||
|
||||
Testing Rust-Libp2p at Large Scale: Our use of rust-libp2p-server also provides a valuable opportunity to examine how it behaves at a larger scale. Software performance can vary depending on scale, and these differences are hard to predict without actual real-world deployments. Now we can gain insights similar to those we acquired from other large deployments such as [Polkadot](github.com/paritytech/polkadot/) and [Ethereum](https://blog.libp2p.io/libp2p-and-ethereum/).
|
||||
|
||||
Encouraging Rust in the IPFS Network: Lastly, by operating a rust-libp2p bootstrap node, we hope to motivate other developers to build IPFS-based applications using rust-libp2p. This could lead to an increase in the use of Rust, fostering a more diverse and vibrant ecosystem.
|
||||
|
||||
# rust-libp2p(-server) in Action
|
||||
|
||||
_What is rust-libp2p(-server) and how does it operate as an IPFS bootstrap node?_
|
||||
|
||||
[rust-libp2p](https://github.com/libp2p/rust-libp2p) is an implementation of the libp2p specification in Rust, a popular systems programming language. The rust-libp2p project was [initiated around 2018](https://www.parity.io/blog/why-libp2p) and since then, it has powered network like Ethereum through its Rust implementation [Lighthouse](https://github.com/sigp/lighthouse) and [Polkadot](github.com/paritytech/polkadot/) along with the [Substrate](https://github.com/paritytech/substrate/) ecosystem. You can find more rust-libp2p users [here](https://github.com/libp2p/rust-libp2p#notable-users).
|
||||
|
||||
[rust-libp2p-server](https://github.com/mxinden/rust-libp2p-server/) is just thin wrapper around rust-libp2p. It combines rust-libp2p's TCP, QUIC and Kademlia-DHT implementation into a single binary. Looking up the new rust-libp2p-server IPFS bootstrap node `ny5` via [`libp2p-lookup`](https://github.com/mxinden/libp2p-lookup/) confirms just that. Note the `Agent version: "rust-libp2p-server/0.12.0"`. and `Protocols: - /ipfs/kad/1.0.0`.
|
||||
|
||||
|
||||
```
|
||||
libp2p-lookup direct --address /dnsaddr/ny5.bootstrap.libp2p.io
|
||||
|
||||
Lookup for peer with id PeerId("QmQCU2EcMqAqQPR2i9bChDtGNJchTbq5TbXJJ16u19uLTa") succeeded.
|
||||
|
||||
Protocol version: "ipfs/0.1.0"
|
||||
Agent version: "rust-libp2p-server/0.12.0"
|
||||
Listen addresses:
|
||||
- [...]
|
||||
Protocols:
|
||||
- /ipfs/kad/1.0.0
|
||||
- [...]
|
||||
```
|
||||
|
||||
## Some Numbers
|
||||
|
||||
On the new bootstrap node we see around 15 new inbound connections per second. The majority of these connections are established via QUIC (see `ip4/udp/quic`).
|
||||
|
||||
|
||||
|
||||
The node is handling > 30k connections concurrently, thus being connected to roughly [15% of nodes of the public IPFS DHT](https://probelab.io/ipfsdht/#client-vs-server-node-estimate).
|
||||
|
||||
|
||||
|
||||
Across these connections the node handles around 40 Kademlia requests per second, most of which are Kademlia `FIND_NODE` requests.
|
||||
|
||||
|
||||
|
||||
The number of connections does not have a significant impact on CPU usage of the underlying machine.
|
||||
|
||||
|
||||
|
||||
The node uses `< 300 kbyte` of memory per connection.
|
||||
|
||||
|
||||
|
||||
A small tangent: in case you are interested in more IPFS public DHT metrics, take a look at the [probelab DHT metrics and reports](https://probelab.io/ipfsdht/).
|
||||
|
||||
# Closing
|
||||
|
||||
If you want to learn more:
|
||||
|
||||
- Read up on the [libp2p project](https://libp2p.io/)
|
||||
- Explore the [rust-libp2p implementation](https://github.com/libp2p/rust-libp2p)
|
||||
- See the thin rust-libp2p wrapper at [mxinden/rust-libp2p-server](https://github.com/mxinden/rust-libp2p-server/)
|
||||
- And lastly, the [public IPFS DHT measurements](https://probelab.io/ipfsdht/) are always a good read
|
||||
|
||||
A lot of this work was done by [@mcamou](https://github.com/mcamou) from the [Protocol Labs EngRes Bifrost team](https://pl-strflt.notion.site/Bifrost-2423fee6b15243158e85e35d8e22241d?pvs=4). Mario has handled the deployment and the team is operating the bootstrap nodes as a whole. Thanks, [@mcamou](https://github.com/mcamou) and team!
|
||||
|
||||
FAQ:
|
||||
|
||||
- Do I have to use the default bootstrap nodes?
|
||||
|
||||
No, you don't have to use `/dnsaddr/bootstrap.libp2p.io`. You can remove Protocol Labs' default nodes and add your own or use both for better reliability.
|
||||
|
||||
- Do we plan to run rust-libp2p-server on all IPFS bootstrap nodes?
|
||||
|
||||
No.
|
||||
@@ -1,92 +0,0 @@
|
||||
---
|
||||
title: An Observatory for the IPFS Network
|
||||
description: 'The ProbeLab team has built a resilient and fully-automated infrastructure to monitor the performance of core IPFS protocols!'
|
||||
author: Yiannis Psaras (@yiannisbot)
|
||||
date: 2023-08-03
|
||||
permalink: '/2023-ipfs-observatory/'
|
||||
header_image: '/blog-post-probelabio.png'
|
||||
tags:
|
||||
- measurements
|
||||
- DHT
|
||||
- IPNI
|
||||
---
|
||||
|
||||
# tl;dr
|
||||
|
||||
The ProbeLab team has worked hard over the past year to build a resilient and fully-automated infrastructure to monitor the performance of core IPFS stack protocols. All of what we have so far lives at [https://probelab.io](https://probelab.io) with results being auto-updated on a daily basis.
|
||||
|
||||
|
||||
## Why measurement work is important
|
||||
|
||||
Measuring operational networked systems is the cornerstone of system reliability, stability, and great user experience. Unless someone measures the performance of their system, it is very difficult to spot problems and inconsistencies between protocol design and actual operation. Most importantly, it is very difficult to be able to direct engineering effort to the right direction in order to solve actual problems, deal with bottlenecks, and eventually improve performance.
|
||||
|
||||
System and network measurements are normally straightforward when there is a single (or a few) points of control. The task becomes significantly more challenging in the case of open-source, decentralized, and permissionless systems such as IPFS where there is no single point of control (or any gatekeeping entity).
|
||||
|
||||
## ProbeLab
|
||||
|
||||
This is where our team’s efforts come into the picture. ProbeLab is focusing on protocol measurement, benchmarking, and optimization for Web3.0 protocols in general and IPFS in particular. During the past year we strived to build all the necessary tooling and backend infrastructure in order to be able to reliably measure the most critical aspects of the decentralized network. To avoid this being our own knowledge and instead share our findings with the community, we’ve also built a public-facing front-end where our key results are being reported on a daily basis: [https://probelab.io](https://probelab.io)
|
||||
|
||||
One key thing that makes [https://probelab.io](https://probelab.io) different to a dashboard is that there is detailed explanation of the measurement methodology and the measurement setup, so that viewers can understand whether the results they’re observing fit their own setup and use-case. Ultimately, [https://probelab.io](https://probelab.io) should become the point of reference for engineers, as well as executives that are running (or are considering running) their applications on top of the IPFS network.
|
||||
|
||||
## Our focus (so far)
|
||||
|
||||
Apart from [several](https://www.notion.so/pl-strflt/Optimistic-Provide-07ce632c6de54aec953ec0e9ca2bbcf5?pvs=4) [protocol](https://github.com/plprobelab/network-measurements/blob/master/results/rfm16-bitswap-discovery-effectiveness.md) [optimization](https://github.com/plprobelab/network-measurements/blob/master/results/rfm15-nat-hole-punching.md) projects that ProbeLab has taken up so far, our primary focus on the measurements front has been the main component that supports decentralized content routing in the IPFS protocol stack, that is, the IPFS Public DHT network. Our focus has not been a random pick, but instead a thoughtful consideration given that this is where performance has been mostly unknown and mostly unpredictable - until now!
|
||||
|
||||
That said, we have extended our efforts to other critical parts of the architecture, such as the [InterPlanetary Network Indexers](https://docs.ipfs.tech/concepts/ipni/), and we plan to add more components to our monitoring infra in the near future.
|
||||
|
||||
Sample projects where our measurement infrastructure has helped the ecosystem tremendously are:
|
||||
|
||||
- **The Hydra Dial Down:** [Hydra Boosters](https://github.com/libp2p/hydra-booster) are a special type of DHT server node designed to accelerate content routing performance in the IPFS network. They were introduced in 2019 and were intended as an interim solution while exploring other DHT scalability techniques. The IPFS DHT network and its supporting protocols have advanced significantly since then, and the (not insignificant) cost of operating Hydras was put in question by our team. We have found that Hydras improve content routing performance by not more than 10-15% on average, which was considered minor, compared to its operational cost. The team carried out a progressive dial down of Hydras after communicating our intentions with the community (see [details](https://discuss.ipfs.tech/t/dht-hydra-peers-dialling-down-non-bridging-functionality-on-2022-12-01/15567)) and confirmed our performance estimates of a Hydra-less network. You can find an explanatory talk of our measurement estimates at IPFS Camp 2022 [here](https://www.youtube.com/watch?v=zhzxJGoLTg0) and the full project report [here](https://github.com/protocol/network-measurements/blob/master/results/rfm21-hydras-performance-contribution.md).
|
||||
|
||||
- **Unresponsive Nodes Incident:** ProbeLab’s measurement work and tooling has proven critical for incidents that nearly brought the IPFS network to its knees. Around January 2023, a software misconfiguration resulted in more than 50% of IPFS DHT network nodes becoming unresponsive. Through rigorous measurement and analysis of the measurement results, the engineering teams have chosen the right next steps to resolve the situation in record time, something that would have been significantly more difficult without the numbers that the ProbeLab team has provided. You can read all of the details regarding the incident, the response, and the measurements that our team carried out in [this previous blog post](https://blog.ipfs.tech/2023-ipfs-unresponsive-nodes/).
|
||||
|
||||
## ProbeLab Tooling
|
||||
|
||||
Our primary tooling is open-source and linked from the same website under: [https://probelab.io/tools/](https://probelab.io/tools/). There are detailed “how to” guides for each tool so that community members can get familiar and start using them for their own studies. The tools we have used so far include:
|
||||
|
||||
- [`Nebula`](https://probelab.io/tools/nebula/): a libp2p DHT crawler and monitor that is designed to track the liveliness and availability of peers.
|
||||
- [`Parsec`](https://github.com/plprobelab/parsec): a DHT and IPNI performance measurement tool that is used to gather accurate data on the performance of DHT and IPNI lookups and publications.
|
||||
- [`Tiros`](https://github.com/plprobelab/tiros): a retrieval and rendering metrics measurement tool of websites loaded over IPFS. It is designed to help developers monitor and optimize the performance of their IPFS-hosted websites. It also measures and compares the IPFS metrics with their HTTPS counterparts.
|
||||
|
||||
## What we know now that we didn’t know before
|
||||
|
||||
The plots and experiments at [https://probelab.io](https://probelab.io) offer visibility into lots of aspects that were not visible at all beforehand, or at least were not widely available. Our monitoring and observation of IPFS’s primary content routing components’ performance over the last couple of quarters reveals that at the time of writing:
|
||||
|
||||
- More than 25k DHT Server peers stay online for more than 80% of the time of a given week [[link to plot](https://probelab.io/ipfskpi/#dht-availability-classified-overall-plot)]
|
||||
|
||||
|
||||
|
||||
- Despite the above fact, the churn rate in the network is rather high with 80% of DHT Server peers leaving the network in 3hrs or less after they appeared online [[link to plot](https://probelab.io/ipfsdht/#dht-peers-churn-cdf-overall-plot)]
|
||||
|
||||
|
||||
|
||||
- The Median DHT Lookup Performance (i.e., the time to first provider record) is at 600ms as measured from 7 different geographical regions. It is worth highlighting that the lookup performance from the EU and North America, where most DHT nodes reside, is significantly better than other regions and stands at 200-250ms [[link to plot](https://probelab.io/ipfsdht/#dht-lookup-performance-cdf-region-plot)].
|
||||
|
||||
|
||||
|
||||
- Websites hosted on IPFS are served faster over kubo than HTTP for those well-performing regions (EU and North America) [[link to plot](https://probelab.io/websites/#websites-http-comparison-ttfb-p90)].
|
||||
|
||||
|
||||
|
||||
- The [cid.contact](http://cid.contact) IPNI maintains a stable lookup performance below the 300ms mark at the P90 for uncached content and across all 7 regions [[link to plot](https://probelab.io/ipni/cid.contact/#ipni-snapshot-uncached-latencies-cdf-cidcontact-plot)].
|
||||
|
||||
|
||||
|
||||
## Where to find more
|
||||
|
||||
Head over to [https://probelab.io](https://probelab.io) to dive into all the results and explanation of the experiments.
|
||||
|
||||
It is worth noting that we do not provide commentary on the results presented on the website itself. Instead, discussion around results reported at [https://probelab.io](https://probelab.io) is taking place at the [IPFS Discussion Forum](https://discuss.ipfs.tech/c/testing-and-experiments/measurements/39).
|
||||
|
||||
You can reach out to the ProbeLab team (e.g., if you’re interested contributing to the measurement effort, or have a request) through:
|
||||
|
||||
- the `#probe-lab` channel in IPFS Discord [[invite link](https://discord.gg/ipfs)], or Filecoin Slack [[invite link](https://filecoin.io/slack)] (bridged channel).
|
||||
- The team’s email: [probelab@protocol.ai](mailto:probelab@protocol.ai)
|
||||
|
||||
We also hold bi-weekly Office Hours, where we invite the community and our collaborators to join and bring up questions, challenges they face and topics for discussion. You can sign up through [this lu.ma page](https://lu.ma/ipfs-network-measurements).
|
||||
|
||||
<!-- ## A guide for website owners hosting with IPFS
|
||||
|
||||
Last, but not least, we have developed an in-depth methodology to monitor performance of websites hosted on IPFS. We are currently monitoring most of PL’s websites and provide a breakdown of web access performance metrics (primarily using [Web Vitals](https://web.dev/vitals/)). This is very helpful for monitoring overall performance, but especially for debugging in case of poor performance, or errors while fetching website content.
|
||||
|
||||
++ linking to the howto guide as well as how to use it, if we finalise and decide to include. -->
|
||||
@@ -1,110 +0,0 @@
|
||||
---
|
||||
title: Amino (the Public IPFS DHT) is getting a facelift
|
||||
description: 'The ProbeLab team is working on a major refactoring of the Public IPFS DHT (henceforth called Amino) and a new feature which will accelerate the provide operation by several orders of magnitude. Read through to find out the details and how to get involved.'
|
||||
author: ProbeLab
|
||||
date: 2023-09-26
|
||||
permalink: '/2023-09-amino-refactoring/'
|
||||
header_image: '/2023-09-amino-refactoring.png'
|
||||
tags:
|
||||
- 'Amino'
|
||||
- 'IPFS DHT'
|
||||
- 'Reprovide Sweep'
|
||||
---
|
||||
|
||||
Two major items are being announced in this blogpost, both of which are equally exciting and relate to “the Public IPFS DHT” (the [public Kademlia-based DHT](https://docs.ipfs.tech/concepts/dht/#dual-dht) that [Kubo (and other implementations) default to bootstrapping into](https://docs.ipfs.tech/how-to/modify-bootstrap-list/) with the libp2p protocol `/ipfs/kad/1.0.0`), which is henceforth going to be called **“Amino”**. The first relates to a major refactoring of the Amino codebase and the second is an optimization of the publish operation of the protocol, so that providing content to Amino is made much faster and resource-efficient.
|
||||
|
||||
## Why Amino?
|
||||
|
||||
The “Public IPFS DHT” is henceforth going to be called **“Amino”**. This follows along with the trend from 2022 in the IPFS ecosystem to use more precise language to create space for alternative options (i.e., other DHTs). Just as there isn’t one IPFS implementation, there isn’t one content routing system or DHT. “Amino” was chosen from Amino acids - the building block for larger, stronger structures, which is what we believe will happen with this network. There can be several IPFS DHT networks, and they can choose to borrow functionality from the “Amino” network. More context on the naming can be found [here](https://github.com/ipfs/ipfs/discussions/473).
|
||||
|
||||
## Refactoring of `go-libp2p-kad-dht` codebase
|
||||
|
||||
It has long been realized that the current go implementation of libp2p’s Distributed Hash Table (DHT), which is used by IPFS implementations like Kubo and other projects/platforms, is in need of a major revision. The problems that have been identified by core maintainers and community contributors alike can be summarised in the following:
|
||||
|
||||
1. Several years of adding extra features to the codebase and iterations of core functionality have made the DHT faster and more efficient, but have also added substantially to its complexity. It has now become more **difficult to understand and make changes to the code**, which indirectly is pushing developers away from contributing to it.
|
||||
2. **Flaky tests due to concurrency issues**. Unit tests, which evaluate if the implementation is working as expected, are difficult to implement due to extensive parallelization of several parts of the code.
|
||||
3. Lack of unit tests in turn make it **hard to carry out performance evaluation tests**. This has recently resulted in performance evaluation results that are hard to understand or act upon - Bitswap’s `Provider Search` delay is a good example here [[link](https://github.com/ipfs/kubo/pull/9530)].
|
||||
4. The current implementation is carrying a **non-negligible amount of technical debt** that was acquired over the years. For instance, Kademlia should only handle Kademlia identifiers (256-bits bitstrings) internally, but it is currently using strings [[source](https://github.com/libp2p/go-libp2p-kad-dht/blob/b63ad6096833d36b365f1361edab871f6cdc283c/query.go#L83)].
|
||||
|
||||
The [PL EngRes IPFS Stewards team](https://www.notion.so/IPFS-f3c309cecfd844e788d8b9e13472a97b?pvs=21) has been working on a **major refactoring of `go-libp2p-kad-dht`**. In this context, a new library, `go-libdht` defines the basic building blocks for implementing DHTs, and will be used by the refactored `go-libp2p-kad-dht`. The goal of the refactoring project is to address the above challenges. In particular,
|
||||
|
||||
- make the code base easy to modify and improve by making it single-threaded.
|
||||
- allow for sequential, deterministic code execution, making debugging easier, testing more reliable and simulation/reproducibility possible and,
|
||||
- get rid of unnecessary code and complexity.
|
||||
|
||||
### Expected Changes & Timeline
|
||||
|
||||
The refactored codebase is being worked on in the [v2-develop branch of go-libp2p-kad-dht](https://github.com/libp2p/go-libp2p-kad-dht/tree/v2-develop). The current progress, next tasks and open issues can be found at this project board: [https://github.com/orgs/plprobelab/projects/1](https://github.com/orgs/plprobelab/projects/1). The refactored code is expected to be completed, tested and ready for integration into Kubo for further testing during the first half of October.
|
||||
|
||||
Where possible, we aim to remain compatible with version 1. There are no breaking protocol changes planned, and we expect to be able to adhere to the standard Routing interface used by Kubo. The libp2p Kademlia implementation has been battle tested through many years of use, and we want to take advantage of the learnings from that real-world usage while improving the ergonomics and clarity of the code. However, we will be taking this opportunity to look closely at the current code interfaces and to propose improved or new ones.
|
||||
|
||||
Most of the changes being made are internal to the operation of the DHT. We’re creating a new state machine oriented execution model that is very different to the existing implementation. This allows us to bound work and resources more cleanly and prioritize work performed more appropriately. Performance will also be different and, for the initial release, our goal is for this to be similar to the current codebase. However, we expect the new execution model will give us more scope for optimization in the future. Having better control over the scheduling of work will also allow the new implementation to continue to perform well under resource pressure and high load.
|
||||
|
||||
## Making Reprovides to Amino lightning fast
|
||||
|
||||
Content providers with a large number of CIDs to provide to the DHT have traditionally been facing difficulties. The current PUT operation in `go-libp2p-kad-dht` lacks resource efficiency. For every CID being reprovided, the provider performs a lookup and initiates a connection with the top 20 nearest peers *sequentially*. In practice, this means that if a peer needs to be contacted twice for two CIDs, the providing peer needs to open two connections to the same peer at different points in time within the same reprovide task.
|
||||
|
||||
In turn, this results in significant bandwidth requirements and deters large content providers from advertising their content on Amino (the IPFS DHT) due to cost constraints. The sequential manner in which reprovides take place can result in content providers failing to refresh all content within the 48h provider record expiration interval [[link to source](https://github.com/libp2p/go-libp2p-kad-dht/blob/b63ad6096833d36b365f1361edab871f6cdc283c/providers/providers_manager.go#L38)][[link to spec](https://github.com/libp2p/specs/tree/master/kad-dht#content-provider-advertisement-and-discovery)], rendering the content inaccessible.
|
||||
|
||||
Our approach is to optimize the provide process, making it much less resource intensive. This will pave the way for a significantly larger throughput in the number of "provides".
|
||||
|
||||
### High level design of `ReprovideSweep`
|
||||
|
||||
The base premise of `ReprovideSweep` is that **all keys located in the *same keyspace region* are reprovided *all at once,** instead of sequentially,* which is currently the case. This is in contrast to the status quo of re-providing in the current IPFS DHT, where the provider record of each CID is sent out separately, though a new connection.
|
||||
|
||||
Given that some large Content Providers are publishing way more CIDs than there are DHT Servers, by the [pigeonhole principle](https://en.wikipedia.org/wiki/Pigeonhole_principle) there must be DHT Servers that are allocated more than one Provider Record, by a particular Content Provider. The primary rationale is to send/re-provide all Provider Records allocated to the same DHT Server *******at once, instead of having to revisit the same server later on, re-establish a connection, and store the provider record*******.
|
||||
|
||||
However, because sending multiple Provider Records requires a new RPC causing a breaking change, it isn’t trivial to send all Provider Records exactly *at once.* That said, the most expensive part in a (Re)Provide operation is the DHT walk to discover the right DHT Servers to store the Provider Records on, as well as opening new connections to these peers. Once these peers are known, and a connection is already open, the Content Provider can simply reuse the same connection to send multiple individual `Provide` requests, thereby avoiding breaking changes while still reaping performance gains.
|
||||
|
||||
The `go-libp2p-kad-dht` DHT implementation must keep track of the CIDs that must be republished every `Interval` (let’s assume that all Provider Records are republished at the same frequency). The Kademlia identifiers of the CIDs to republish must be arranged in a [binary trie](https://github.com/guillaumemichel/py-binary-trie) to allow for faster access. As each Provider Record is replicated on 20 different DHT Servers, 20 DHT Servers in a close locality are expected to store the same Provider Records (this is not 100% accurate, but suffices for our high-level description here - we’ll publish all the details in a subsequent post, when the solution is in production).
|
||||
|
||||
In a nutshell, the Content Provider will continuously lookup keys across the entire keyspace, hence “sweeping” the keyspace. For each key that is to be published, the Content Provider will find the 20 closest peers, and lookup in its “CIDs Republish Binary Trie” all Provider Records that would belong to those specific 20 remote peers. Doing this match-making exercise, content providers will be able to reprovide all provider records that correspond to a particular peer at once. Based on this logic, Content Providers are only limited by network throughput.
|
||||
|
||||
You can watch a recording from [IPFS Thing 2023](https://2023.ipfs-thing.io/) explaining the concept in more detail [here](https://youtu.be/bXaL64fp55c?si=1LuukjErCG_bz02N).
|
||||
|
||||
### `ReprovideSweep` Performance
|
||||
|
||||
`ReprovideSweep` is not implemented yet, hence, we can only approximate its performance analytically. In the tables below we see that `ReprovideSweep` is improving performance significantly on all fronts and important metrics, assuming that the number of CIDs (`#CIDs`) that a provider wishes to publish is much larger than the number of DHT Server nodes in the network (`#DHT_SERVERs`), i.e. `#CIDs >> #DHT_SERVERs`:
|
||||
|
||||
- The number of DHT Lookups is reduced from being equal to the number of CIDs to be published, down to 1/20th of the number of DHT Server nodes in the network.
|
||||
- The number of connections that need to be opened is also reduced and is equal to the number of DHT Server nodes (if the number of CIDs to be provided is much larger than the number of server nodes in the network).
|
||||
- As we see in the second table, assuming a network size of ~25k DHT Server nodes, the overall improvement in terms of ‘number of connections open’ and ‘number of DHT Lookups’ is significant reaching an improvement of ~800x for 1M CIDs.
|
||||
|
||||
| | Current Reprovide | Reprovide Sweep |
|
||||
| --- | --- | --- |
|
||||
| Number of DHT lookups | #CIDs | ~1/20 * #DHT_SERVERs |
|
||||
| Number of connections to open | 20 * #CIDs | #DHT_SERVERs |
|
||||
|
||||
| #CIDs published | Improvement (#connections, #DHT Lookups) |
|
||||
| --- | --- |
|
||||
| > 1K | - |
|
||||
| 25K | 20x |
|
||||
| 100K | 80x |
|
||||
| 500K | 400x |
|
||||
| 1M | 800x |
|
||||
| 10M | 8’000x |
|
||||
|
||||
### Expected Changes & Timeline
|
||||
|
||||
We are very excited about this change because it will enable large content providers to start using the most resilient and decentralized component of the IPFS network.
|
||||
|
||||
**This change is a client side optmization and doesn’t involve any protocol alteration.** As such, it allows users to immediately benefit from the feature. The interface between `go-libp2p-kad-dht` and [`boxo`](https://github.com/ipfs/boxo), which Kubo uses, must be updated to enable the DHT client to take on the responsibility of managing the reprovide operation.
|
||||
|
||||
The PL EngRes IPFS Stewards team is currently working to define the spec for `ReprovideSweep`, which we hope to have ready in the beginning of October, and we anticipate rolling out this enhancement during Q4’23. We will update the community with a new blogpost or discussion forum post closer to the time. Until then, you can follow developments on this front through this GH issue: [https://github.com/libp2p/go-libp2p-kad-dht/issues/824](https://github.com/libp2p/go-libp2p-kad-dht/issues/824).
|
||||
|
||||
## What’s next
|
||||
|
||||
We believe the above lays the groundwork for more exciting DHT innovation ahead. We have some ideas that we’d love to be talking about and working with the community. We’re still figuring out the best place for this conversation, but subscribe [here](https://discuss.ipfs.tech/t/dht-discussion-and-contribution-opportunities-in-2023q4/16937) if you’re interested in learning about upcoming DHT discussion areas (e.g., at [LabWeek](https://labweek.plnetwork.io/)/[DevConnect](https://devconnect.org/), DHT working group). You can also join the team's Office Hours by subscribing at: [https://lu.ma/ipfs-network-measurements](https://lu.ma/ipfs-network-measurements).
|
||||
|
||||
## How to get involved
|
||||
|
||||
As always, help is more than welcome to accelerate development and make the design more robust through feedback. Here are ways you can get involved:
|
||||
|
||||
- Github repository:
|
||||
- DHT Refactoring: [https://github.com/plprobelab/go-kademlia/](https://github.com/plprobelab/go-kademlia/)
|
||||
- Reprovide Sweep: [https://github.com/libp2p/go-libp2p-kad-dht/issues/824](https://github.com/libp2p/go-libp2p-kad-dht/issues/824)
|
||||
- Slack channel:
|
||||
- `#probe-lab` in [FIL Slack](https://filecoin.io/slack) or [IPFS Discord](https://discord.gg/vj7qWuAyHY) (bridged channel), or
|
||||
- `#kubo-boxo-dev` in FIL Slack
|
||||
- IPFS Discussion forum:
|
||||
- DHT Refactoring and future planning: [https://discuss.ipfs.tech/t/dht-discussion-and-contribution-opportunities-in-2023q4/16937](https://discuss.ipfs.tech/t/dht-discussion-and-contribution-opportunities-in-2023q4/16937)
|
||||
@@ -1,72 +0,0 @@
|
||||
---
|
||||
title: Announcing the Content Tracks for IPFS Thing 2023
|
||||
description: 'An overview of the content tracks that the community will convene around during IPFS Thing 2023.'
|
||||
author:
|
||||
date: 2023-3-29
|
||||
permalink: '/2023-ipfs-thing-content-tracks/'
|
||||
header_image: '/2023-3-29-ipfs-thing-content-tracks.jpg'
|
||||
tags:
|
||||
- 'ipfs thing'
|
||||
- 'event'
|
||||
---
|
||||
|
||||
The IPFS implementers community will be gathering together in Brussels, Belgium in just a few weeks for [IPFS Thing 2023](https://2023.ipfs-thing.io/submit/).
|
||||
|
||||
Today we’re excited to finally share the final list of the content tracks so you can know what to expect! Each track will have a variety of talks and discussions from members of the community.
|
||||
|
||||
If you haven’t registered yet, head on over to [the event website](https://2023.ipfs-thing.io/) to grab your tickets today! [IPFS Thing 2023](https://2023.ipfs-thing.io/) is happening from **April 15-19 in Brussels, Belgium** and will include everything from talks, workshops, discussion circles, hacking time, and more.
|
||||
|
||||
## Opening Keynotes
|
||||
|
||||
During this opening session, we'll hear an overview of the latest implementations, tools, and advancements across the world of IPFS, and celebrate the winners of the IPFS Impact Grants Round 2. (Track lead: [Mosh Lee](https://twitter.com/mishmosh))
|
||||
|
||||
## Standards, Governance, and DWeb Policy
|
||||
|
||||
This track sits at the intersection of IPFS standards, governance, and dweb and regulation. What's the latest on the IPFS protocol and governance? What specific problems do we face regarding existing regulation? What new regulation or changes could be helpful? Are there interesting policy angles that we can surface, develop, and advocate for? How do we make the dweb a robust, sustainable commons? (Track lead: [Robin Berjon](https://mastodon.social/@robin
|
||||
))
|
||||
|
||||
## IPFS Deployments + Operators
|
||||
|
||||
From best practices to the mistakes made along the way, this track is a chance to highlight how members of the community are running IPFS nodes at scale. Let's share what's working well and what implementations can do to make things even better! (Track lead: [James Walker](https://twitter.com/walkah))
|
||||
|
||||
## Interplanetary Databases
|
||||
|
||||
There’s a new class of distributed database technologies building atop steady advances in IPLD & hash linked data structures in general. In this track we’ll gather those brave enough to take on CAP theorem in a decentralized context, share notes on what’s working, and hear presentations from teams pushing the envelope on what databases can do and where they can exist. (Track lead: [J Chris](twitter.com/jchris))
|
||||
|
||||
## Data Transfer
|
||||
|
||||
Come join the Protocol Thunderdome as we battle to determine the best way to move content addressed bytes! We'll review recent progress in data transfer, including work coming out of the Move The Bytes Working Group, and explore how we can make IPFS 10x faster at getting your stuff than Web2! (Track lead: Hannah Howard)
|
||||
|
||||
## Measuring IPFS
|
||||
|
||||
A data-driven approach to the design and operation of IPFS and libp2p through rigorous network measurements, performance evaluation, and recommendations for builders and operators. (Track lead: Yiannis Psaras)
|
||||
|
||||
## IPFS on the Web
|
||||
|
||||
The world wide web is both the biggest deployment vector and least tractable surface for IPFS. There are opportunities and major challenges to bringing IPFS support in web rendering engines and browsers, to web content served through gateways, to IPFS network access from HTTP web apps and browser extensions. This track will have talks on: current and future browser implementations, approaches to managing and publishing IPFS content on the web, building apps that connect to the IPFS from within HTTP contexts, culminating in planning for group working sessions around on specific IPFS+Web challenges on day 4 & 5 of IPFS Thing. (Track lead: [Dietrich Ayala](https://twitter.com/dietrich/))
|
||||
|
||||
## Integrating IPFS
|
||||
|
||||
IPFS is not an island - it exists in diverse environments, manifesting in different ways depending on the use-case, ranging from mobile devices to blockchains to naming systems, even soon in space. These integration points provide interesting opportunities to explore the capabilities of IPFS and muse on what IPFS even is. We’ll hear from folks on what they’re doing, what’s working, and ponder how far we can flex IPFS to fit the multitude of places it needs to be. (Track lead: Ryan Plauche)
|
||||
|
||||
## Decentralized Compute & AI
|
||||
|
||||
We believe computing and AI can become more powerful and useful by embracing content addressing and a “merkle-native” way of doing things. In this track, we'll discuss various projects in this area, sharing R&D experiences, future directions, use cases, and benefits. (Track lead: [Iryna Tsimashenka](https://twitter.com/iryna_it09))
|
||||
|
||||
## Content Routing
|
||||
|
||||
Approaches and protocols to content routing in IPFS, what we've learned so far, and directions for the future. Join this track to explore herding CIDs, bringing content providers closer to the seekers of content, new advances across content routing systems, and a fresh look at the horizon of what's to come. (Track lead: Masih Derkani)
|
||||
|
||||
## HTTP Gateways
|
||||
|
||||
How do we deliver IPFS content to the masses? In this track, we'll dive into the magical and maddening topic of HTTP Gateways. Topics include the evolving semantics of /ipfs/cid, .car blocks and rendered flat files, and large-scale efforts to improve gateway architectures such as Project Saturn and Project Rhea. (Track lead: [Will Scott](https://twitter.com/willscott/))
|
||||
|
||||
## Roadmapping Next Steps out of the IPFS þing
|
||||
|
||||
A discussion / breakout-oriented workshop for defining and committing to next steps out of the week's conversations, which we can land and celebrate at upcoming IPFS events in Q3 / Q4 2023. (Track lead: [Molly Mackinlay](https://twitter.com/momack28))
|
||||
|
||||
---
|
||||
|
||||
We're looking forward to seeing you all soon and exploring these exciting content tracks together in-person!
|
||||
|
||||
Have a talk or workshop to share? You can also [submit a talk](https://2023.ipfs-thing.io/submit/) though April 5.
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: Brave Browser's New IPFS Infobar
|
||||
description: 'We’re excited to share a new IPFS-related feature that appears in the most recent version of Brave.'
|
||||
date: 2023-09-25
|
||||
header_image: '/braveinfobar2.png'
|
||||
tags:
|
||||
- brave
|
||||
- browsers
|
||||
---
|
||||
|
||||
We’re excited to share a new IPFS-related feature that appears in the most recent version of [Brave’s web browser](https://brave.com/). A new IPFS Infobar will appear at the top of the browser when you visit an IPFS compatible resource such as a [CID on a public gateway](https://docs.ipfs.tech/how-to/address-ipfs-on-web/#http-gateways) or a website with a [DNSLink](https://docs.ipfs.tech/concepts/dnslink/).
|
||||
|
||||
By using the IPFS Infobar, you can choose whether you would like to switch to loading the IPFS version of the content. Selections can be made to always load via IPFS or only load it in a specific instance.
|
||||
|
||||
|
||||
|
||||
|
||||
This new feature will increase visibility of IPFS content when it exists and contribute to greater awareness for the benefits that can be had from utilizing content addressing.
|
||||
|
||||
Brave’s IPFS Infobar is a small but mighty new feature that we are excited to see in the wild!
|
||||
|
||||
In addition to the Infobar, there are more tools currently being developed for [Brave](https://brave.com/) by others such as [David Justice](https://github.com/JusticeEngineering) that are worth noting. Some of the prototypes include: Markdown/Wysiwyg webpage creator, Link In Bio/Link List site creator, and the ability to password protect webpages with many more ideas in the works.
|
||||
|
||||
[https://github.com/JusticeEngineering/markdown-publish](https://github.com/JusticeEngineering/markdown-publish)
|
||||
|
||||
[https://github.com/JusticeEngineering/link-list](https://github.com/JusticeEngineering/link-list)
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
title: Content Blocking for the IPFS stack is finally here!
|
||||
description: 'We’re excited to share that content blocking can now be enabled in Kubo and other tools in the IPFS stack.'
|
||||
author: The Bifrost Team
|
||||
date: 2023-04-26
|
||||
permalink: '/2023-content-blocking-for-the-ipfs-stack/'
|
||||
header_image: '/release-notes-placeholder.png'
|
||||
tags:
|
||||
- 'go-ipfs'
|
||||
- 'kubo'
|
||||
- 'badbits'
|
||||
- 'content-blocking'
|
||||
- 'content-moderation'
|
||||
---
|
||||
|
||||
Bifrost (the Protocol Labs NetOps team responsible for the IPFS.io HTTP gateways) is happy to announce that content blocking can now be enabled in Kubo and other tools in the IPFS stack.
|
||||
|
||||
Traditionally, content blocking has been performed only at the IPFS gateway level and directly in Nginx, using the original [Badbits denylist](https://badbits.dwebops.pub/denylist.json). This had a few issues: content on the denylist was not blocked on Kubo and was still available via Bitswap. Additionally, blocking affected concrete CID strings, but not equivalent ones (i.e. those with a different base encoding).
|
||||
|
||||
In order to resolve these issues and to make a long term commitment to improving how we do content moderation in IPFS, we have taken the following steps:
|
||||
- [Submitted IPIP-383](https://github.com/ipfs/specs/pull/383), which defines a much more flexible and efficient compact denylist format. This new format supports different block types and sets a foundation for future work on denylist transparency, sharing, and distribution. For example, every blocked item can now have tags attached to provide metadata such as the reason for the blocking. IPFS implementations can then choose whether to expose that information or not.
|
||||
- [Implemented NOpfs](https://github.com/ipfs-shipyard/nopfs), a Blocker that understands the new compact denylist format and decides whether any CID or IPFS Path should be blocked or not. This Blocker implementation also provides a Kubo plugin which gives Kubo the ability to never download blocked content. NOpfs can also be used separately from Kubo by setting a Web service that returns whether an IPFS path or URL should be blocked or not (upcoming work from our side). This can also be useful for Filecoin Storage providers and anyone who wants to make sure their CIDs have not been included in a denylist.
|
||||
|
||||
In the meantime, we have converted our existing denylist to the new format so that everyone can take advantage of these changes right away: [https://badbits.dwebops.pub/badbits.deny](https://badbits.dwebops.pub/badbits.deny)
|
||||
|
||||
This work is the framing for a larger endeavour to improve content moderation on the IPFS public networks. If you have any questions, need help, or would like to collaborate, then please [reach out via GitHub on IPIP-383](https://github.com/ipfs/specs/pull/383) or [NOpfs](https://github.com/ipfs-shipyard/nopfs)! If you’d like to help further this initiative, you can start by sharing this news with your community and by letting the Kubo maintainers know that you’d like to see this functionality integrated into Kubo as a first class citizen.
|
||||
|
||||
And last of all, it would be remiss of us if we didn’t thank [Hector](https://twitter.com/hecturchi) for all the hard work he put into this. Thank you for all your efforts... they are greatly appreciated!
|
||||
|
||||
The Bifrost Team.
|
||||
@@ -1,505 +0,0 @@
|
||||
---
|
||||
title: 'How to Host Dynamic Content on IPFS'
|
||||
description: 'This article presents a design for hosting dynamic content on IPFS using IPLD, IPNS, and DHT Provider Records.'
|
||||
author: tabcat
|
||||
date: 2023-05-17
|
||||
permalink: '/2023-how-to-host-dynamic-content-on-ipfs/'
|
||||
header_image: '/hosting-dynamic-content.png'
|
||||
tags:
|
||||
- 'dynamic-content'
|
||||
- 'hosting'
|
||||
- 'ipld'
|
||||
- 'ipns'
|
||||
- 'dht'
|
||||
---
|
||||
|
||||
The InterPlanetary File System (IPFS) is a distributed, peer-to-peer file system designed to make the web faster, safer, and more resilient. Although IPFS excels at hosting static content, hosting dynamic content remains a challenge. This article presents a design for hosting dynamic content on IPFS using InterPlanetary Linked Data (IPLD), InterPlanetary Name Service (IPNS), and DHT Provider Records.
|
||||
|
||||
## Table of Contents
|
||||
<!-- TOC start -->
|
||||
|
||||
- [Understanding Key Components](#understanding-key-components)
|
||||
* [IPLD](#ipld)
|
||||
* [IPNS](#ipns)
|
||||
* [PeerID](#peerid)
|
||||
* [Provider Records](#provider-records)
|
||||
- [Defining the Problem](#defining-the-problem)
|
||||
- [Achieving Dynamicity](#achieving-dynamicity)
|
||||
* [Read and Write Steps](#read-and-write-steps)
|
||||
+ [Writing](#writing)
|
||||
+ [Reading](#reading)
|
||||
* [Dynamic-Content IDs](#dynamic-content-ids)
|
||||
* [Manifest Document](#manifest-document)
|
||||
- [Use-case: Edge-computed Applications](#use-case-edge-computed-applications)
|
||||
* [Edge Devices](#edge-devices)
|
||||
* [Pinning Servers](#pinning-servers)
|
||||
* [Replication](#replication)
|
||||
- [Roadblocks and Workarounds](#roadblocks-and-workarounds)
|
||||
* [No 3rd Party Publishing to DHT](#no-3rd-party-publishing-to-dht)
|
||||
* [No Delegated Refreshing of IPNS OR Provider Records](#no-delegated-refreshing-of-ipns-or-provider-records)
|
||||
- [Example](#example)
|
||||
* [Usage](#usage)
|
||||
+ [Clone the Repo](#clone-the-repo)
|
||||
+ [Install Packages](#install-packages)
|
||||
+ [Run Examples](#run-examples)
|
||||
* [What's Happening?](#whats-happening)
|
||||
* [Sample Outputs](#sample-outputs)
|
||||
- [Credits](#credits)
|
||||
- [Get Involved](#get-involved)
|
||||
- [FAQ](#faq)
|
||||
|
||||
<!-- TOC end -->
|
||||
|
||||
|
||||
<br/>
|
||||
|
||||
## Understanding Key Components
|
||||
|
||||
### IPLD
|
||||
|
||||
[IPLD](https://ipld.io/) is a data model for linking and addressing data across distributed systems. In IPFS, IPLD stores immutable data, providing [content-addressed storage](https://en.wikipedia.org/wiki/Content-addressable_storage). Data stored in IPLD has a unique [Content Identifier](https://docs.ipfs.tech/concepts/content-addressing/) (CID) derived from its content, ensuring data integrity.
|
||||
|
||||
### IPNS
|
||||
|
||||
[IPNS](https://docs.ipfs.tech/concepts/ipns/) is a decentralized naming system that allows you to create a mutable reference to an immutable CID. With IPNS, you can create a persistent address that always points to the latest version of your content, even as it changes over time.
|
||||
|
||||
### PeerID
|
||||
|
||||
A [Libp2p PeerID](https://docs.libp2p.io/concepts/fundamentals/peers/#peer-id) is a unique identifier for each node in the network, derived from a [public key](https://en.wikipedia.org/wiki/Public-key_cryptography). PeerIDs help find, identify, and communicate with other nodes.
|
||||
|
||||
### Provider Records
|
||||
|
||||
[Provider Records](https://docs.ipfs.tech/concepts/dht/) are a fundamental part of IPFS's Distributed Hash Table (DHT). When requesting IPFS content, a node queries the DHT for Provider Records associated with the requested CID. These records contain the PeerID of peers with the content, enabling the user to establish a connection and retrieve the data.
|
||||
|
||||
---
|
||||
> **It's important to note that IPNS names and PeerIDs use the same [key structures](https://specs.ipfs.tech/ipns/ipns-record/#ipns-keys).**
|
||||
---
|
||||
|
||||
<br/>
|
||||
|
||||
## Defining the Problem
|
||||
|
||||
Databases on IPFS have been gaining more attention recently. In essence, these database protocols use IPLD to store replica data.
|
||||
And they commonly use a real-time protocol like [Gossipsub](https://docs.libp2p.io/concepts/pubsub/overview/) with IPLD to sync database changes peer-to-peer.
|
||||
Using this design to create [local-first](https://www.inkandswitch.com/local-first/) databases looks quite promising.
|
||||
However, local-first databases are often highly [sharded](https://en.wikipedia.org/wiki/Partition_(database)) and run on end-user devices.
|
||||
|
||||
This presents the problem of peers being few and unreliable to sync with.
|
||||
One solution is to add reliable database peers to the mix, either self-hosted or hosted by a service.
|
||||
There are two disadvantages to this approach:
|
||||
|
||||
- Each project must build infra tooling
|
||||
- Users need a live instance of each database protocol used
|
||||
|
||||
It would benefit all related protocols to have a general solution for asynchronous replication of dynamic content.<br/>
|
||||
*Think pinning layer for dynamic content.*
|
||||
|
||||
This standardized layer would complement the app-specific protocols used for real-time replication.
|
||||
|
||||
<br/>
|
||||
|
||||
## Achieving Dynamicity
|
||||
|
||||
Let's look at a replication algorithm for one of the first databases on IPFS, [OrbitDB](https://github.com/orbitdb). The algorithm is roughly as follows:
|
||||
|
||||
1. Join a shared pubsub channel for the database.
|
||||
2. On seeing a new pubsub peer in the shared channel, attempt to join a direct pubsub channel ([ipfs-pubsub-1on1](https://github.com/ipfs-shipyard/ipfs-pubsub-1on1)).
|
||||
3. On committing an update to the local replica, advertise replica root CIDs on each direct pubsub channel.
|
||||
4. On receiving a replica root CIDs advertisement on a direct pubsub, traverse the remote replica for changes to merge.
|
||||
|
||||
The design presented in this article works similarly but replaces pubsub with Provider Records and IPNS. Essentially, all parts of replication get encoded into ~persistent IPFS components.
|
||||
|
||||
- Provider Records to find collaborators
|
||||
- IPNS to point to the latest version of a device's replica
|
||||
|
||||
---
|
||||
> **Swapping pubsub for ~persistent components makes building on history without any collaborators online possible.**
|
||||
---
|
||||
|
||||
The main contribution is the novel use of Provider Records.
|
||||
Instead of tying a CID to PeerIDs of nodes hosting that content, the records tie a "Dynamic-Content ID" to IPNS names.
|
||||
Each IPNS name resolves to the latest CID of a device's local replica.
|
||||
|
||||
*Collaborating on dynamic content is possible without knowing any previous collaborators or needing them to be online as long as their replica data is kept available via a pinner.*
|
||||
|
||||
If you are familiar with publishing Provider Records to the DHT, *you may have spotted a problem here*.
|
||||
The source of the problem is a check DHT servers do when receiving an `ADD_PROVIDER` query, addressed in [Roadblocks and Workarounds](#roadblocks-and-workarounds).
|
||||
|
||||
<img src="https://raw.githubusercontent.com/tabcat/dynamic-content/master/.assets/dynamic-content-diagram.png" width="333">
|
||||
|
||||
---
|
||||
> **The Merkle-DAGs built with IPLD provide a persistent and efficient layer for collaborators to sync.**
|
||||
---
|
||||
|
||||
<br/>
|
||||
|
||||
### Read and Write Steps
|
||||
|
||||
Describes the process of reading/writing dynamic content to IPFS:
|
||||
|
||||
#### Writing
|
||||
|
||||
1. Make changes to the local replica
|
||||
2. Push replica data to the IPLD pinner
|
||||
3. Republish IPNS to point to new CID root
|
||||
4. Add IPNS key as a provider of the Dynamic Content's ID
|
||||
|
||||
#### Reading
|
||||
|
||||
1. Query the DHT for Providers of the Dynamic Content's ID
|
||||
2. Resolve providers' IPNS keys to CIDs
|
||||
3. Resolve CIDs to IPLD data
|
||||
4. Merge changes with the local replica
|
||||
|
||||
---
|
||||
> **Titling this article 'Replication on IPFS' might have been more accurate, but 'Hosting Dynamic Content on IPFS' sounded waaay better.**
|
||||
---
|
||||
|
||||
<br/>
|
||||
|
||||
### Dynamic-Content IDs
|
||||
|
||||
A Dynamic-Content ID (DCID) looks like a CID. Also, both DCIDs and CIDs reference and identify content on the DHT.
|
||||
|
||||
*Where the two IDs differ is in their creation.*
|
||||
|
||||
While CIDs come from the hash of some static content, DCIDs are a permutation of the CID of a manifest document.
|
||||
This immutable manifest document "describes" the dynamic content.
|
||||
|
||||
As stated in the previous section, DCIDs identify unique dynamic content.
|
||||
They point to IPNS names by using Provider Records on the DHT.
|
||||
|
||||
---
|
||||
> **Disclaimer: Dynamic-Content IDs, or DCIDs, only exist for the purpose of this article. It is not an official spec or part of IPFS. (expect a name change because I also hate "DCIDs" 🤢🤮)**
|
||||
---
|
||||
|
||||
<br/>
|
||||
|
||||
### Manifest Document
|
||||
|
||||
Manifest documents, a term from OrbitDB, describe some unique dynamic content.
|
||||
Manifests are immutable and contain information like the protocol and parameter used.
|
||||
|
||||
This document format is not formally specified, but included below is a specification for this article:
|
||||
|
||||
**dag-cbor**
|
||||
```js
|
||||
// cbor type reference: https://www.rfc-editor.org/rfc/rfc8949.html#section-3.1
|
||||
{
|
||||
protocol: type 3
|
||||
param: type 5
|
||||
}
|
||||
```
|
||||
|
||||
`protocol`: a text string field containing a protocol id
|
||||
|
||||
`param`: a key value map for exclusive use by the `protocol`
|
||||
|
||||
```js
|
||||
// takes description of the dynamic content (protocol + params)
|
||||
// returns manifest (Block) and dynamic-content id (CID)
|
||||
export async function DynamicContent (
|
||||
{ protocol, param }: { protocol: string, param: any }
|
||||
):
|
||||
Promise<{ id: CID, manifest: BlockView }>
|
||||
{
|
||||
|
||||
// create manifest
|
||||
const manifest = await Block.encode({ value: { protocol, param }, codec, hasher })
|
||||
|
||||
// create dcid
|
||||
const dynamic = new TextEncoder().encode('dynamic')
|
||||
const bytes = new Uint8Array(dynamic.length + manifest.cid.multihash.digest.length)
|
||||
bytes.set(dynamic)
|
||||
bytes.set(manifest.cid.multihash.digest, dynamic.length)
|
||||
const dcid = CID.create(
|
||||
manifest.cid.version,
|
||||
manifest.cid.code,
|
||||
await hasher.digest(bytes)
|
||||
)
|
||||
|
||||
return { id: dcid, manifest }
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
Above is a code block from the example attached to this article.
|
||||
It shows a manifest document "describing" the dynamic content using the `protocol` and `param` properties.
|
||||
It also shows the DCID derived from the manifest's CID.
|
||||
|
||||
<br/>
|
||||
|
||||
## Use-case: Edge-computed Applications
|
||||
|
||||
This design is particularly useful when paired with local-first databases.
|
||||
These databases are partitioned (a.k.a. sharded) to only the interested parties.
|
||||
It's common for only a few collaborators to be a part of a database, and there may be long periods without any of them online.
|
||||
This context makes it challenging to build upon the history of collaborators, a challenge this design can potentially solve.
|
||||
|
||||
### Edge Devices
|
||||
|
||||
- Handle application logic and merging of replicas from other collaborators.
|
||||
- Consist of a network of potentially unreliable peers that may come online and go offline at various times.
|
||||
- Ensure the application history is available by commanding pinning servers.
|
||||
|
||||
### Pinning Servers
|
||||
|
||||
- Reliable storage servers that keep dynamic content available on IPFS.
|
||||
- Pin IPLD replicas, and refresh IPNS and Provider Records for clients.
|
||||
- Execute no app-specific code
|
||||
|
||||
### Replication
|
||||
|
||||
The design presented in this article is a replication protocol.
|
||||
However, it is not a real-time replication protocol.
|
||||
Applications with real-time features should include an app-specific replication protocol for use with other online collaborators.
|
||||
Combining two replication protocols with these properties results in preserved and real-time P2P applications.
|
||||
|
||||
---
|
||||
> **Pinning servers, in this context, provide a general and reliable replication layer to fall back on when no other collaborators are online.**
|
||||
---
|
||||
|
||||
<br/>
|
||||
|
||||
## Roadblocks and Workarounds
|
||||
|
||||
It should be clear now that using Provider Records this way was not intended.
|
||||
This brings us to the roadblock...
|
||||
|
||||
### No 3rd Party Publishing to DHT
|
||||
|
||||
[DHT servers validate that the PeerIDs inside received Provider Records match the PeerID of the node adding them.](https://github.com/libp2p/specs/tree/master/kad-dht#rpc-messages)
|
||||
|
||||
This check makes adding Provider Records for multiple PeerIDs to the DHT difficult.
|
||||
Not great if you want to participate in multiple pieces of dynamic content as each will require its own IPNS name.
|
||||
A Libp2p node may only add its own PeerId as a provider. This PeerId is also known as the "self" key.
|
||||
|
||||
There are two workarounds for now:
|
||||
|
||||
1. Use the "self" key for IPNS, and have it point to a CID for a map(DCID -> root replica CID) for all relevant dynamic content.
|
||||
2. Spin up *ephemeral* libp2p nodes to refresh each IPNS name as a provider every [22hours](https://github.com/libp2p/specs/tree/master/kad-dht#content-provider-advertisement-and-discovery).
|
||||
|
||||
### No Delegated Refreshing of IPNS OR Provider Records
|
||||
|
||||
Delegated publishing of IPNS and Provider Records is necessary to realize the edge-computed applications use case.
|
||||
Unfortunately, there are no official plans to add this feature.
|
||||
|
||||
<br/>
|
||||
|
||||
## Example
|
||||
|
||||
---
|
||||
> **USES HELIA 😲🤩 !!!! DHT IN 😵💫 JAVASCRIPT 😵💫 😵 !! DYNAMIC CONTENT ON IPFS!?🧐!?**
|
||||
---
|
||||
|
||||
This example shows dynamic-content replication using IPLD, IPNS, and Provider Records. There are 3 [helia](https://github.com/ipfs/helia) (IPFS) nodes running in a single script, named `client1`, `client2`, and `server`. `client1` and `client2` dial `server` and use the `/ipfs/kad/1.0.0` protocol. After dialing, clients can add IPNS and Provider records to the DHT server. Clients also add IPLD data to `server` programmatically.
|
||||
|
||||
|
||||
|
||||
---
|
||||
> **`client1`, `client2`, and `server ` are all in memory Helia nodes created by a single script.**
|
||||
|
||||
> **IPLD data is added to the server by clients by accessing `server.blockstore.put` from within the script (programmatically). As opposed to using an HTTP API like in any real use-case.**
|
||||
---
|
||||
|
||||
### Usage
|
||||
|
||||
- Requires [npm and Node v18](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm)
|
||||
|
||||
#### Clone the Repo
|
||||
|
||||
`git clone https://github.com/tabcat/dynamic-content.git`
|
||||
|
||||
#### Install Packages
|
||||
|
||||
`npm install`
|
||||
|
||||
#### Run Examples
|
||||
|
||||
There are two example scripts. One is interactive, meaning after the example runs, a REPL starts with global variables available to operate the replication manually.
|
||||
|
||||
The scripts are `npm run example` and `npm run interactive`.
|
||||
|
||||
**If something is broken please open an [issue](https://github.com/tabcat/dynamic-content/issues)!**
|
||||
|
||||
<br/>
|
||||
|
||||
### What's Happening?
|
||||
|
||||
The example consists of 3 [Helia](https://github.com/ipfs/helia) nodes, named `client1`, `client2`, and `server`.
|
||||
The `server` represents a reliable machine used as a
|
||||
|
||||
1. IPLD pinning server
|
||||
2. DHT server
|
||||
|
||||
---
|
||||
> **IPNS and Provider records are both stored in the DHT.**
|
||||
---
|
||||
|
||||
The clients are unreliable machines used to read and write dynamic content.
|
||||
In the example, `client1` does all the writing, and `client2` does all the reading.
|
||||
|
||||
|
||||
|
||||
<br/>
|
||||
|
||||
This is a very high overview of what's going on.
|
||||
Remember, this design uses only IPLD/IPNS/Provider Records.
|
||||
It may be helpful to read [index.ts](./src/index.ts) (~200 LOC) for clarity.
|
||||
|
||||
### Sample Outputs
|
||||
|
||||
In case you are unable to run the example, below shows all the output that would occur:
|
||||
|
||||
<details>
|
||||
<summary>`npm run example`</summary>
|
||||
|
||||
```sh
|
||||
$ npm run example
|
||||
|
||||
> dynamic-content@1.0.0 example
|
||||
> npm run build && node dist/index.js
|
||||
|
||||
|
||||
> dynamic-content@1.0.0 build
|
||||
> tsc
|
||||
|
||||
server is pinning ipld and serving dht ipns and provider records
|
||||
client1: online
|
||||
client1: added new values to set { nerf this }
|
||||
client1: set state: { nerf this }
|
||||
client1: encoded to raw data
|
||||
client1: pushed data to pinner
|
||||
client1: published ipns:12D3KooWRzE1FNCRXuz1C8Z3G8Q5oBg3C5nhKANSsFq377P1mWVn with value cid:bafyreihypffwyzhujryetatiy5imqq3p4mokuz36xmgp7wfegnhnjhwrsq
|
||||
client1: advertised ipns:12D3KooWRzE1FNCRXuz1C8Z3G8Q5oBg3C5nhKANSsFq377P1mWVn as set provider
|
||||
client1: offline
|
||||
|
||||
--- no peers online, Zzzzz ---
|
||||
|
||||
client2: online
|
||||
dht query returned empty response
|
||||
client2: found ipns:12D3KooWRzE1FNCRXuz1C8Z3G8Q5oBg3C5nhKANSsFq377P1mWVn as set provider
|
||||
client2: resolved ipns:12D3KooWRzE1FNCRXuz1C8Z3G8Q5oBg3C5nhKANSsFq377P1mWVn to bafyreihypffwyzhujryetatiy5imqq3p4mokuz36xmgp7wfegnhnjhwrsq
|
||||
client2: resolved ipfs:bafyreihypffwyzhujryetatiy5imqq3p4mokuz36xmgp7wfegnhnjhwrsq to raw data
|
||||
client2: decoded raw data
|
||||
client2: added new values to set { nerf this }
|
||||
client2: set state: { nerf this }
|
||||
client2: offline
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>`npm run interactive`</summary>
|
||||
<br/>
|
||||
|
||||
The interactive example starts a REPL after the example has run.
|
||||
|
||||
```sh
|
||||
$ npm run interactive
|
||||
|
||||
> dynamic-content@1.0.0 interactive
|
||||
> npm run build && node dist/interactive.js
|
||||
|
||||
|
||||
> dynamic-content@1.0.0 build
|
||||
> tsc
|
||||
|
||||
server is pinning ipld and serving dht ipns and provider records
|
||||
client1: online
|
||||
client1: added new values to set { nerf this }
|
||||
client1: set state: { nerf this }
|
||||
client1: encoded to raw data
|
||||
client1: pushed data to pinner
|
||||
client1: published ipns:12D3KooWQXCo6Wzw7NmJRLC2peAX7fU6gHSydEKNAJfyfXCEwHFL with value cid:bafyreihypffwyzhujryetatiy5imqq3p4mokuz36xmgp7wfegnhnjhwrsq
|
||||
client1: advertised ipns:12D3KooWQXCo6Wzw7NmJRLC2peAX7fU6gHSydEKNAJfyfXCEwHFL as set provider
|
||||
client1: offline
|
||||
|
||||
--- no peers online, Zzzzz ---
|
||||
|
||||
client2: online
|
||||
dht query returned empty response
|
||||
client2: found ipns:12D3KooWQXCo6Wzw7NmJRLC2peAX7fU6gHSydEKNAJfyfXCEwHFL as set provider
|
||||
client2: resolved ipns:12D3KooWQXCo6Wzw7NmJRLC2peAX7fU6gHSydEKNAJfyfXCEwHFL to bafyreihypffwyzhujryetatiy5imqq3p4mokuz36xmgp7wfegnhnjhwrsq
|
||||
client2: resolved ipfs:bafyreihypffwyzhujryetatiy5imqq3p4mokuz36xmgp7wfegnhnjhwrsq to raw data
|
||||
client2: decoded raw data
|
||||
client2: added new values to set { nerf this }
|
||||
client2: set state: { nerf this }
|
||||
client2: offline
|
||||
|
||||
--- interactive example ---
|
||||
|
||||
client1: online
|
||||
client2: online
|
||||
|
||||
Usage:
|
||||
|
||||
globals
|
||||
|
||||
help: this message
|
||||
|
||||
client1: helia client node (sender)
|
||||
client2: helia client node (receiver)
|
||||
server: helia ipld/ipns pinner and dht server
|
||||
|
||||
// compare the 2 clients sets
|
||||
set1: client1's set variable
|
||||
set2: client2's set variable
|
||||
|
||||
await connect(<client>) // connects client to server
|
||||
await disconnect(<client>) // disconnects client from server
|
||||
|
||||
await update(...<string[]>) // create and publish changes from client1 - requires client1 to be connected
|
||||
await sync() // syncs changes to client2 - requires client2 to be connected
|
||||
|
||||
>
|
||||
```
|
||||
</details>
|
||||
|
||||
---
|
||||
> **Note: in practice, the DHT queries related to the Dynamic Content's ID only need to be run initially. Afterward, a protocol meant for real-time replication with online collaborators can be used.**
|
||||
---
|
||||
|
||||
<br/>
|
||||
|
||||
## Credits
|
||||
|
||||
Big thanks to [@autonome](https://github.com/autonome), [@SgtPooki](https://github.com/sgtpooki), and [@lidel](https://github.com/lidel) for help writing this article!
|
||||
|
||||
Also thanks to [@willscott](https://github.com/willscott) for answering all my DHT questions in [#libp2p-implementers](https://app.element.io/#/room/#libp2p-implementers:ipfs.io)!
|
||||
|
||||
<br/>
|
||||
|
||||
## Get Involved
|
||||
|
||||
Sound interesting? Get involved! Come [chat](https://matrix.to/#/#hldb:matrix.org)
|
||||
|
||||
Have a question? Create an [issue](https://github.com/tabcat/dynamic-content/issues)
|
||||
|
||||
[I](https://github.com/tabcat)'m implementing this in [tabcat/zzzync](https://github.com/tabcat/zzzync)
|
||||
|
||||
<br/>
|
||||
|
||||
## FAQ
|
||||
|
||||
**Q**: Why not just share an IPNS name between devices to update?
|
||||
|
||||
**A**: IPNS names are not built to handle concurrent writes and should not be extended to do so. They are signed, versioned documents that one device should be able to update. As shown here, they are essential for creating a system that can handle concurrent writes.
|
||||
|
||||
<br/>
|
||||
|
||||
**Q**: Isn't this going to be slow?
|
||||
|
||||
**A**: This design complements real-time replication by providing a general and reliable layer to fall back to. It adds two steps on top of resolving a CID: 1) the DHT provider query and 2) the IPNS name resolutions.
|
||||
Developers must reason how to design replicas for efficient storage and replication over IPLD.
|
||||
|
||||
<br/>
|
||||
|
||||
**Q**: Provider Records do not support this use case. Could this affect DHT measurements?
|
||||
|
||||
**A**: If this use case became prevalent, it could affect DHT measurements. Using Provider Records this way would make it look like the content providers are offline because the PeerIDs are used only for IPNS.
|
||||
|
||||
<br/>
|
||||
|
||||
**Q**: Could IPNS and Provider Records be swapped out for alternatives and achieve the same goal?
|
||||
|
||||
**A**: Absolutely. The goal is to provide a general and reliable replication layer. Additionally, the more widespread the building blocks used, the more existing infrastructure can be leveraged.
|
||||
@@ -1,72 +0,0 @@
|
||||
---
|
||||
title: 'Recap: HTTP Gateways (þing 2023)'
|
||||
description: 'A recap of the new HTTP Gateways track including summaries, links, and videos.'
|
||||
author: Will Scott
|
||||
date: 2023-05-30
|
||||
permalink: '/2023-http-gateways-recap/'
|
||||
header_image: '/http-gateways-recap.jpg'
|
||||
tags:
|
||||
- 'thing'
|
||||
- 'þing'
|
||||
- 'event'
|
||||
- 'recap'
|
||||
- 'track'
|
||||
- 'http'
|
||||
- 'gateways'
|
||||
---
|
||||
|
||||
We had a new track at IPFS Thing last month: a forum focused on HTTP Gateways. As IPFS has scaled, the interactions between IFPS and the surrounding web has also increased. IPFS lives within the web, and as the [browser track](https://blog.ipfs.tech/2023-ipfs-thing-web-track/) noted, HTTP is deeply integrated with IPFS.
|
||||
|
||||
The Gateway track looked at the specific HTTP interface that IFPS as a server provides to web clients, and how the web clients make use of that interface. There are continuing pushes to evolve the interface `/ipfs/<cid>`, but we need to understand both how these primitives should be used by higher level APIs, and how to implement them.
|
||||
|
||||
A specific focus in this track was [Project Rhea](https://pl-strflt.notion.site/Project-Rhea-decentralized-IPFS-gateway-3d5906e7a0d84bea800d5920005dfea6), a cross-cutting project in Protocol Labs to decentralize the current gateways running at [ipfs.io](https://ipfs.io) to be hosted on decentralized infrastructure. This project has led to re-evaluation of the trust relationship between clients and gateways, and the hope that we can reduce the trust and increase the decentralization of gateways even further.
|
||||
|
||||
The talks in the track presented both different models for gateways, as well as implementation details for how components of Project Rhea are built.
|
||||
|
||||
In the rest of this post I'll provide links and brief color to the sessions in the track.
|
||||
|
||||
## What is Rhea?
|
||||
|
||||
[Will](https://wills.co.tt) kicked off the day with an overview of the architecture and goals of project Rhea.
|
||||
|
||||
@[youtube](0eJd2aqqSy8)
|
||||
|
||||
## IPFS Service Worker Gateways
|
||||
|
||||
[Adin](https://github.com/aschmahmann) demonstrated how web clients can reach origin IPFS hosts directly through protocols like webtransport and webRTC. The increasingly complete libp2p stack along with HTTP-compatible services like IPNI are bringing us to a reality where the HTTP gateways become less critical in bridging IPFS support directly to end web users.
|
||||
|
||||
@[youtube](MRIyWXy0ZRc)
|
||||
|
||||
## Web3 CDN Saturn accelerates IPFS & Filecoin retrievals
|
||||
|
||||
Alex Kinstler provided an overview of Saturn as a decentralized CDN and described the service it can provide as a basis for Rhea and as a platform that can host the ipfs.io IPFS gateway.
|
||||
|
||||
@[youtube](f9iUTLtPtKY)
|
||||
|
||||
## Self-hosting IPFS Gateway with bifrost-gateway
|
||||
|
||||
[Lidel](https://github.com/lidel) walked through the architecture of `bifrost-gateway`, a new IPFS implementation that acts as a 'trust gateway'. This component, built for Rhea, provides an HTTP gateway interface compatible with the current gateways which can fetch data from remote nodes via self-verifying car files.
|
||||
|
||||
@[youtube](xhJPz_efAQE)
|
||||
|
||||
## Introduction to Caboose
|
||||
|
||||
[Aarsh](https://github.com/aarshkshah1992/) dove into a 'thick client' for Saturn called Caboose that allows Saturn clients to make requests to close nodes in order to optimize performance of the CDN. In the Rhea use case, Caboose both allows for and improves fraud detection, as well as enabling faster switch-over in the case of a node going down.
|
||||
|
||||
@[youtube](z7a9E735l3Y)
|
||||
|
||||
## Testing Your IPFS Gateway Implementation: A Step-by-Step Guide
|
||||
|
||||
[Piotr](https://github.com/galargh) offered a framework for testing whether an IPFS gateway implementation works as expected. This conformance testing can improve our confidence that new implementations will be compatible with existing applications, and it is much less implementation-specific than previous testing frameworks.
|
||||
|
||||
@[youtube](PmIf77thO_c_)
|
||||
|
||||
## Live CDN Incentives and its Future
|
||||
|
||||
[Claudia](http://w.laudiacay.cool/) sent us off with a great dive into how incentives can be built for a retrieval market CDN. She described how existing primitives can be linked together to support a high performance decentralized CDN that is incentive-aligned with serving content well and quickly.
|
||||
|
||||
@[youtube](yrrAjR03TsU)
|
||||
|
||||
## Conclusion
|
||||
|
||||
I hope this overview of the HTTP Gateways track was helpful for those who couldn't attend IPFS Thing 2023 or for those who did attend but need a refresher. Next year we hope to take this new content track to the next level!
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
title: Introducing Lassie - a retrieval client for IPFS and Filecoin
|
||||
description: 'An overview of the content tracks that the community will convene around during IPFS Thing 2023.'
|
||||
author: Brenda Lee
|
||||
date: 2023-4-6
|
||||
permalink: '/2023-introducing-lassie/'
|
||||
header_image: '/Lassie.png'
|
||||
tags:
|
||||
- 'filecoin'
|
||||
- 'retrieval'
|
||||
---
|
||||
|
||||
We’re excited to share that you can now use a simple retrieval client, named [Lassie](https://github.com/filecoin-project/lassie), to get your data from IPFS and Filecoin. Lassie makes it easy to fetch your data from both the IPFS and Filecoin Network - it will find and fetch content over the best retrieval protocols available.
|
||||
|
||||
For end users and clients, this means you can easily retrieve your content addressed data (using CIDs) from IPFS or Filecoin using the Lassie client, without having to run your own IPFS node or Filecoin node. Simply download the Lassie binary and start retrieving your data with the simple command -
|
||||
|
||||
```jsx
|
||||
lassie fetch <your CID here>
|
||||
```
|
||||
|
||||
In addition to using Lassie directly to retrieve end user content, application developers can leverage Lassie as a library to fetch content from IPFS and Filecoin directly from within an application. Currently, the Saturn Network (a Web3 CDN in Filecoin’s retrieval market) is using Lassie to retrieve data from IPFS and Filecoin.
|
||||
|
||||
Learn more about Lassie with these resources:
|
||||
|
||||
- Github: [https://github.com/filecoin-project/lassie](https://github.com/filecoin-project/lassie)
|
||||
- Overview: [Basic Retrieval](https://docs.filecoin.io/basics/how-retrieval-works/basic-retrieval/)
|
||||
- Technical documentation: [https://github.com/filecoin-project/lassie/tree/main/docs](https://github.com/filecoin-project/lassie/tree/main/docs)
|
||||
- Ask questions: #retrieval-help in [Filecoin slack](https://www.notion.so/54fffa1b90ff4f6180586e79ff11ae17).
|
||||
|
||||
Special thanks to all who have paved the way building out prior retrieval clients ([w3rc](https://github.com/ipfs-shipyard/w3rc), [filclient](https://github.com/application-research/filclient)).
|
||||
|
||||
We encourage you to try this out and share with others who want to retrieve content from Filecoin or IPFS, and look forward to hearing your feedback. You can find us on [Github](https://github.com/filecoin-project/lassie) or #retrieval-help in [Filecoin slack](https://www.notion.so/54fffa1b90ff4f6180586e79ff11ae17).
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
title: Introducing the IPFS Ecosystem Working Group
|
||||
description: 'Nurturing a vibrant and sustainable IPFS ecosystem.'
|
||||
author: The Ecosystem Working Group
|
||||
date: 2023-09-05
|
||||
permalink: '/2023-introducing-the-ecosystem-working-group/'
|
||||
header_image: ''
|
||||
tags:
|
||||
- 'Ecosystem'
|
||||
- 'Working Group'
|
||||
---
|
||||
|
||||
Since its initial release over 9 years ago, IPFS has been stewarded by a variety of teams and individual contributors, both within and outside of Protocol Labs. More recently though, it has lacked a dedicated team focused on nothing other than the success of the IPFS ecosystem. It is with this reality in mind that we are excited to announce the formation of **the brand new IPFS Ecosystem Working Group!**
|
||||
|
||||
At launch, the IPFS Ecosystem WG consists of Protocol Labs contributors, but we are forming with the explicit purpose of spinning out into our own independent entity over the coming months. We believe that this working group and its autonomy will be critical in helping propel IPFS toward a better and even brighter future.
|
||||
|
||||
Initially, we have four core goals:
|
||||
|
||||
1. Foster a thriving ecosystem by advocating for IPFS,
|
||||
2. Build bridges between IPFS and other ecosystems that could benefit from content addressing,
|
||||
3. Grow the community and develop strong and durable community ownership of the IPFS project as a public good, and
|
||||
4. Spin out from Protocol Labs into a self-sustaining organization that can support the IPFS community and build robust, effective governance for the protocol.
|
||||
|
||||
The future of IPFS requires greater degrees of decentralization, so you can expect other IPFS-focused teams to begin spinning out from Protocol Labs in the future as well.
|
||||
|
||||
As we continue to make progress towards these goals, we will provide updates and work in the open so as to keep the entire community in-the-loop with what we’re doing. A thriving ecosystem requires care and attention, and we believe that this new initiative and nimble team will be able to deliver on exactly that. But our work is only part of the story: community ownership means that your voice as IPFS users, operators, or contributors needs to be heard just as much as ours.
|
||||
|
||||
So if you have comments, questions, or concerns, then please join the discussion in the comments section below, via the [Ecosystem section of the IPFS Forums](https://discuss.ipfs.tech/c/communities/ecosystem/15), or the various chat links that follow – together let’s work on making IPFS thrive!
|
||||
|
||||
[Forums](https://discuss.ipfs.tech/c/communities/ecosystem/15) | [Discord](https://discord.com/channels/806902334369824788/1146489977174233098) | [Slack](https://filecoinproject.slack.com/archives/C05PGBP697E) | [Matrix](https://app.element.io/#/room/#ipfs-ecosystem:ipfs.io)
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
title: Announcing IPFS Connect Istanbul 2023
|
||||
description: 'Join the IPFS Community for a full day of workshops, lightning talks, and demos showcasing technology, tools, and innovative projects in the IPFS ecosystem.'
|
||||
date: 2023-09-20
|
||||
header_image: '/ipfsconnect2023.jpg'
|
||||
tags:
|
||||
- events
|
||||
---
|
||||
|
||||
**IPFS Connect** is a community-run regional conference bringing together all of the builders and ecosystems that rely on and use IPFS as the most widely used decentralized content addressing protocol for files and data. This year's event is happening alongside Devconnect and LabWeek23 in **Istanbul, Turkey on November 16**. Join the IPFS Community for a full day of workshops, lightning talks, and demos showcasing technology, tools, and innovative projects in the IPFS ecosystem.
|
||||
|
||||
There are several opportunities for you to get involved with this event whether you're a business, organization, or individual.
|
||||
|
||||
## Present to a large community of builders at IPFS Connect
|
||||
|
||||
We're planning a full day of talks & workshops to prepare and inspire builders from around the globe that are attending Devconnect. This includes large ecosystems and communities that rely on and integrate with IPFS, as well as individual builders joining to hack at ETHGlobal Hackathon that starts the day after IPFS Connect.
|
||||
|
||||
### Presentation & Workshop Types
|
||||
- Lightning talks & demos: short talks presenting your service, code, or app, designed to inspire, get signups, or talk about how you built it using IPFS.
|
||||
- Workshops: we have 2 dedicated workshop spaces that will be running all day. Run a workshop session with attendees walking through your -solution so they're ready to hack the next day.
|
||||
- Discussion: run a collaborative discussion on topics of interest - privacy, self hosting, devops best practices, decentralized data compliance, etc.
|
||||
- Full talks: present in one of two theater spaces, with professional video recording. We want to hear about your technical how-to, user stories, and other talks that inspire and educate.
|
||||
|
||||
Speakers receive a free ticket to the event, as well as discount codes to invite their community
|
||||
|
||||
<a href="https://cfp.ipfsconnect.org/ipfsconnect-istanbul/cfp" class="cta-button">Submit a presentation or proposal</a>
|
||||
|
||||
## Attend and connect with other community members
|
||||
|
||||
Tickets for IPFS Connect are on sale now, so you can register and buy early bird tickets to get full access to the day's events and opportunities: [https://istanbul2023.ipfsconnect.org](https://istanbul2023.ipfsconnect.org)
|
||||
|
||||
<a href="https://istanbul2023.ipfsconnect.org" class="cta-button">Register today</a>
|
||||
|
||||
## Sponsor the event to reach your target audience
|
||||
|
||||
You can learn more about multiple sponsorship opportuntities [via the sponsor deck here.](https://docs.google.com/presentation/d/1UMbRP5pYHDL5TluzBWUuqlo6DB6F1G8bgUZhMa_w_Pc/view#slide=id.p)
|
||||
|
||||
**Developers:**
|
||||
- Beginners to experts in IPFS
|
||||
- Interested in adding IPFS to their Web3 stacks so that dapp front ends are decentralized and want to use off-chain files and data to build more usable apps
|
||||
|
||||
**Startups, DAOs, Sovereign Chains:**
|
||||
- Select technology and service providers building on the IPFS tech stack combined with other Web3 components
|
||||
- Exploring novel use cases for IPFS including provenance, computation, identity, and more
|
||||
|
||||
<a href="https://docs.google.com/presentation/d/1UMbRP5pYHDL5TluzBWUuqlo6DB6F1G8bgUZhMa_w_Pc/view#slide=id.p" class="cta-button">Learn more about sponsoring</a>
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
title: IPFS is now on Bluesky!
|
||||
description: 'We’re excited to share that IPFS now has an official presence on Bluesky, a new decentralized social network that recently spun out of Twitter.'
|
||||
author:
|
||||
date: 2023-04-17
|
||||
permalink: '/2023-ipfs-on-bluesky/'
|
||||
header_image: '/2023-ipfs-on-bluesky.png'
|
||||
tags:
|
||||
- 'social media'
|
||||
---
|
||||
|
||||
We’re excited to share that [IPFS now has an official presence on Bluesky](https://staging.bsky.app/profile/ipfs.tech), a new decentralized social network that recently spun out of Twitter. Powered by the in-development [AT Protocol](https://atproto.com/), Bluesky aims to be a Twitter-like social media client that provides the benefits of interoperation, account portability, and algorithmic choice.
|
||||
|
||||
Up until now, IPFS has only had an official social media presence on Twitter. As the landscape of social media continues to change dramatically, we believe having a presence in more than just one place will be beneficial to the IPFS community, ecosystem, and brand.
|
||||
|
||||
We chose to join Bluesky because it shares many of the [same values and goals](https://specs.ipfs.tech/architecture/principles/) that the IPFS ecosystem has. Additionally, the [AT Protocol](https://atproto.com/) actively utilizes [IPLD](https://ipld.io/) and [content addressing](https://docs.ipfs.tech/concepts/how-ipfs-works/#subsystems-overview). The CEO of Bluesky, Jay Graber, even [gave a talk at IPFS Camp 2022 about Bluesky](https://www.youtube.com/watch?v=jGbBZbl-V8Y) that can be watched below, and her blog post about self-certifying protocols is referenced on the [IPFS Principles](https://specs.ipfs.tech/architecture/principles/#self-certifying-addressability) web page.
|
||||
|
||||
@[youtube](jGbBZbl-V8Y)
|
||||
|
||||
It’s still very early days at Bluesky (and it’s still in private beta), but it has shown early promise in solving some of the critical problems the social web has been plagued with. If you’re on Bluesky and want to keep up with IPFS there, [then give the new profile a follow @ipfs.tech](https://staging.bsky.app/profile/ipfs.tech)!
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
title: 'Recap: Community & Governance (þing 2023)'
|
||||
description: 'A recap of the Community & Governance track including summaries, links, and videos.'
|
||||
author: Boris Mann and Robin Berjon
|
||||
date: 2023-05-23
|
||||
permalink: '/2023-ipfs-community-governance/'
|
||||
header_image: '/community-governance-recap.jpg'
|
||||
tags:
|
||||
- 'thing'
|
||||
- 'þing'
|
||||
- 'event'
|
||||
- 'recap'
|
||||
- 'track'
|
||||
- 'community'
|
||||
- 'governance'
|
||||
---
|
||||
|
||||
Governance and community are two ideas that vibe like they wouldn't live in the same part of town if their lives dependended on it. Community is warm, fun, and fuzzy if probably chaotic and occasionally infuriating, whereas governance sounds a lot more like flossing, something dry and painful that you pretend your project does to make the Serious People go away. But much like the predictable transition from misunderstanding to mutual respect in a buddy movie, these two were destined to form just the dynamic duo we need to take on insuperable odds. Community is the for and by of governance, and, quite frankly, the exercize of governance is messy, chaotic, and a crucible from which new, more resilient communities emerge.
|
||||
|
||||
The full-day Community & Governance track that brought us together at IPFS Þhing 2023 (which you can [watch in its entirety](https://www.youtube.com/playlist?list=PLuhRWgmPaHtTIFbOVO5YfXkoFg6wIGbBN)) had all of that energy and then some. We spent the time bouncing back and forth between how to prevent capture by lumbering megacorporations and how to gather friends for a nice community café, what's a data protection officer and better ways to herd cats, ways of protecting people from some of the worst content on the Internet while supporting censorship-resistance and how to support commons and community ownership. It was a ride and a delightful one too.
|
||||
|
||||
Perhaps the core issue that brought us together across the diverse presentations was that we want to learn from the mistakes of the past and organize the community so that we can bring about a better world. It's not the worst plan.
|
||||
|
||||
## Memory in Uncertainty
|
||||
|
||||
"*Is that an elaborate way of saying everything's fucked?*" That might not be your typical audience question but then this wasn't your typical presentation either (or your typical audience, for that matter).
|
||||
|
||||
Cade Diehm is one of the brains behind [*The New Design Congress*](https://newdesigncongress.org/) (NDC), a research organization that practices "*ethical red teaming*" to identify issues with sociotechnical systems. [WebRecorder](https://webrecorder.net/) and [the Filecoin Foundation](https://fil.org/) hired NDC to take an in-depth look at web archiving (on IPFS) to help identify problems. Cade came to IPFS þing to udpate the community on his findings, which are captured in the [Memory in Uncertainty: Web Preservation in the Polycrisis](https://members.newdesigncongress.org/memory-in-uncertainty-web-preservation-in-the-polycrisis/) report.
|
||||
|
||||
"*The answer,*" Cade told us, "*is: 'kind of.'*" He gave a wide-ranging presentation ranging over the dangers of decentralized technology, the complexity of archives, the challenges presented by the potential weaponization of data, and much more. It provided a powerful call to take the impact of our tech seriously and to keep in mind that tech can only be ethical if it is governed by the people it impacts. Cade concluded with a set of tools to help avoid bad outcomes, because "*not everything is screwed.*"
|
||||
|
||||
@[youtube](TdiQGXSZmCk)
|
||||
|
||||
## Community Organizing
|
||||
|
||||
For all that remote work and online collaboration have improved, it's hard to have a strong and durable sense of community without meeting people in the flesh now and then. Thankfully, we have many gatherings to look forward to this year!
|
||||
|
||||
[Vukasin Vukoje](https://twitter.com/wukoje) made a surprise announcement of a new event series: Compute Camp. Details will be released more fully soon, but the first edition of this series dedicated specifically to distributed compute will take place later this year in Belgrade, Serbia. If you care more about doing things to data and less about where it's stored, this might just be the place for you.
|
||||
|
||||
Yuni Graham and Niki Gokani walked us through the organization of IPFS Camp, which will take place in November in Bangalore. We worked together to figure out what the best structure and content for the event would be. They're looking for volunteers to be part of the content planning work — please consider reaching out if you're interted!
|
||||
|
||||
@[youtube](U5u54jwOg6k)
|
||||
|
||||
And if what you're looking for is a more local IPFS-focused event, why not run your own? Yuni Graham and Nicole Schafer presented IPFS + Friends Café, a collection of local community gatherings to help develop an IPFS community on the ground, around the world. If you're iunterested, they might be able to sponsor such an event as well as assist with logistics and finding some speakers. It would be wonderful to see more local evangelism!
|
||||
|
||||
@[youtube](FII_9VTgDy8)
|
||||
|
||||
## Cat Herding
|
||||
|
||||
A growing community is a blessing, but keeping up with everything that is happening can become overwhelming. Several sessions provided us with both updates and tools to stay on top of future updates.
|
||||
|
||||
Henrique Dias (aka [@hacdias](https://twitter.com/hacdias)) walked us through [specs.ipfs.tech](https://specs.ipfs.tech/), the hot new place to get IPFS specifications. Not all of the IFPS specs have been moved there yet, but they're in the process of being ported over and everything new will be on the specs site from the get-go. This site is intended to grow into the one-stop-shop reference for IPFS implementations, ideally reaching the point at which one could produce an IPFS implementation from scratch using those documents alone (along with the emerging test suite, of course).
|
||||
|
||||
@[youtube](vQVnjEIPuCE)
|
||||
|
||||
At last year's þing in Iceland, the IPIP (IPFS Improvement Process) process was announced. The indefatigable @lidel walked us through all of the IPIP work that has happened since, and it's a lot! Initially announced as a lightning talk, this was more of a twenty minute presentation at lightning speed.
|
||||
|
||||
Keep in mind that this process is open to anyone in the community (and if you're reading this that means *you*). There is an [IPIP Pipeline GitHub project](https://github.com/orgs/ipfs/projects/19) that maintains an up-to-date status of all IPIPs, and the IPIPs get discussed on the [IPFS Implementers Working Group](https://lu.ma/ipfs-implementers). More generally, the [IPFS Community Calendar](https://lu.ma/ipfs) keeps track of the various meetings and events in which the evolution of the IPFS stack gets discussed.
|
||||
|
||||
@[youtube](WcHlV6sQuDI)
|
||||
|
||||
But then again, specs are only one corner of IPFS, and IPFS one corner of a bigger family of technologies. Staying on top of everything that is happening in *\[gestures vaguely around]* this space remains daunting. One novel tool that is already helping people get a clearer sense of what's happening (and that you can use as well) is [Starmap](https://starmap.site/). The core principle of Starmap is very simple: by structuring your GitHub issues according to very simple conventions, you can create a nested tree of issues that spans any arbitrary set of repositories and see all of those organized in a single Starmap.
|
||||
|
||||
The idea is that people should be organizing and coordinating code whichever way they see fit, but it should be possible to obtain an overview of the status of a progress across all of its components nevertheless. One example is the [Kubo/Boxo 2023Q2/Q3 items](https://starmap.site/roadmap/github.com/ipfs/kubo/issues/9817#list).
|
||||
|
||||
Bastien Dehaynin from Fission provided us with a clear and exciting overview and demo of the system. Several people in the room were already users, and there was definite interest in getting a Starmap for specs.
|
||||
|
||||
@[youtube](_HoLDQreF28)
|
||||
|
||||
## Governance
|
||||
|
||||
In order to keep IPFS and its broader ecosystem pushing in a direction that benefits all people, to support impactful collective action and ownership, and to avoid it being captured by larger players, we need to deploy matching governance capabilities. Your friendly here authors, Boris Mann and Robin Berjon, ran a workshop on "What Should We Governance?" with the goal of surfacing risks and pain points regarding governance of the IPFS ecosystem. This produced a lot of very valuable input, yet we feel like we have barely scratched the surface.
|
||||
|
||||
@[youtube](svqlHO3K_RQ)
|
||||
|
||||
Our dynamic duo then split their color-coordinated purple outfits, first with Boris discussing the allocation of funding for code and other community work, and suggesting that it would be great to use Starmap to find which parts of a project are most in need of funding.
|
||||
|
||||
@[youtube](PysiACKo1dI)
|
||||
|
||||
And then Robin talked about the ongoing work in the [Decent Data Compliance WG](https://github.com/DDC-WG) where parties from across the decentralized world are working together to figure out how to manage "[bad bits](https://badbits.dwebops.pub/)", how to protect operators from serving some of the worst content on the Internet (or simply things they don't want to host), and how to make sure that people's privacy rights are respected. There's a lot of work to be done, but it's heartening to see that people are taking these issues seriously.
|
||||
|
||||
@[youtube](bIlji91KEFQ)
|
||||
|
||||
## Where Next?
|
||||
|
||||
The day made it clear that there is strong interest in community and governance in the IPFS universe, and you can expect to hear a lot more on this side of things. While different aspects of these concerns have places where people can gather to discuss them (as seen in the links sprinkled above), overall coordination and cooperation around governance in the decent(ralized) world remains limited. We joked that we might need a "Working Group Working Group" to provide lightweight support for all the community working groups that keep emerging and help them work together. But the feedback was that it might not actually be such a joke of an idea.
|
||||
|
||||
Stay tuned!
|
||||
@@ -1,92 +0,0 @@
|
||||
---
|
||||
title: 'Recap: Content Routing (þing 2023)'
|
||||
description: 'A recap of the Content Routing track including summaries, links, and videos.'
|
||||
author: Masih Derkani
|
||||
date: 2023-05-15
|
||||
permalink: '/2023-ipfs-thing-content-routing-track/'
|
||||
header_image: '/ipfs-thing-2023-recap/content-routing/content-routing-recap-slides.png'
|
||||
tags:
|
||||
- 'thing'
|
||||
- 'þing'
|
||||
- 'event'
|
||||
- 'recap'
|
||||
- 'track'
|
||||
- 'content'
|
||||
- 'routing'
|
||||
---
|
||||
|
||||
The term "content" is ubiquitous in discussions about knowledge sharing, regardless of the platform used. IPFS takes this term to a new level by defining content as an immutable piece of information, identified by a cryptographic hash that defines its identity. Any change in the information results in a different identity, making the content immutable. This property has a subtle yet powerful advantage: a receiver of a piece of information can verify its authenticity based on its identifier. This simple concept leads to an important question: how can one locate shared content using its identity? 🤔 This is where "Content Routing" comes in.
|
||||
|
||||
Content Routing is the crucial first step in exchanging content within the IPFS network. Once a Content Identifier (CID) is generated from a piece of information, Content Routing enables the information to be both discoverable and discovered. In other words, it involves telling the network, "Hey, I have content, and here is its CID," as well as answering peer questions such as "Who has this CID?".
|
||||
|
||||
This seemingly simple yet paramount functionality enables the network to share immutable and verifiable pieces of information. Since the inception of IPFS as a protocol, Content Routing has taken various forms and utilized several techniques to fulfill its promise of sharing knowledge. It remains an essential component of the IPFS ecosystem, as evidenced by its dedicated track at IPFS þing 2023 in Brussels, Belgium, last month.
|
||||
|
||||
At IPFS þing 2022 a year ago, Content Routing was divided into two tracks: [Privacy](https://www.youtube.com/watch?v=VLU44qtXypE&list=PLuhRWgmPaHtTegfLTVFYtTtqTKQEtDvxW) and [Performance](https://www.youtube.com/watch?v=AWbobt9oHZ0&list=PLuhRWgmPaHtSF3oIY3TzrM-Nq5IU_RTXb). This year, both tracks were combined into one glorious Content Routing track that covered both areas. We had the privilege of hosting talks from community leaders who discussed the impressive improvements in performance and scalability of content routing systems, the privacy preservation techniques that cut across different systems, as well as community call-outs and discussions on how to get involved and build a better decentralized web together.
|
||||
|
||||
The track offered a comprehensive view of the content routing evolution since the inception of IPFS and showcased the latest advancements in the IPFS ecosystem. It provided an overview of the [InterPlanetary Network Indexer (IPNI)](https://github.com/ipni) and explained how it enables the mass publication and lookup of content across hundreds of billions of CIDs. The latest developments in reader privacy preservation, a mechanism that allows private lookups of content on both the IPFS DHT and IPNI, were also presented.
|
||||
|
||||
The rest of this blog post offers highlights, links, and a brief commentary on the talks.
|
||||
|
||||
The full playlist of talks at the IPFS þing 2023 Content Routing track can be found [here](https://www.youtube.com/watch?v=oe7fjOl-q0s&list=PLuhRWgmPaHtRBWV3SvInC5ATS8aKV3lsW). To learn more about Content Routing, check out the previous tracks at [IPFS Camp 2022](https://www.youtube.com/watch?v=7nb5oEpURCU&list=PLuhRWgmPaHtRqhFZ-CAstJ0RIq7Vs-4eO) and the [IPFS YouTube channel](https://www.youtube.com/@IPFSbot/playlists).
|
||||
|
||||
## Content Routing Track Introduction by Masih Derkani
|
||||
|
||||
[Masih](https://derkani.org/) presented an overview of Content Routing as a concept, its evolution over time, along with the evolutionary trends of content routing in the IPFS ecosystem. The talk illustrated what routing content in the IPFS network looks like today and explained how the mesh of content providers of different sizes interconnects. It also showcased the sub-systems that enable content routing to "just work", regardless of where the data resides.
|
||||
|
||||
@[youtube](oe7fjOl-q0s)
|
||||
|
||||
## Opening the DHT to large content providers by Guillaume Michel
|
||||
|
||||
How does a 1M x reduction in opened connections sound? That's right, providing data via the DHT is becoming much more efficient for large content providers thanks to "regions". [Gui](https://github.com/guillaumemichel) presented the latest research on how the DHT key space can be divided across regions to reduce the number of connections as well as messages sent to make content discoverable via the IPFS DHT.
|
||||
|
||||
@[youtube](bXaL64fp55c)
|
||||
|
||||
## IPNI: the InterPlanetary Network Indexer by Masih Derkani
|
||||
|
||||
Talking of large content providers, IPNI, the InterPlanetary Network Indexer, is an alternative routing system designed from scratch to provide content by the bucket load. [Masih](https://derkani.org/) presented how IPNI achieves this by betting on storage becoming cheaper and using replicas to reduce the need for trust to provide single hop lookup for trillions of CIDs. He explained how IPNI handles changes in the subset of CIDs advertised by content providers in a super-efficient protocol. IPNI as a concept has been around for about a year; it is the same protocol that makes FileCoin content discoverable over the IPFS network. As a protocol, it has now grown large enough to deserve its own "InterPlanetary" acronym and a growing set of [specifications](https://github.com/ipni/specs).
|
||||
|
||||
@[youtube](_EDJXeDtcX4)
|
||||
|
||||
## cid.contact: one year on by Masih Derkani
|
||||
|
||||
Having made the distinction between "protocol" and "implementation", [Masih](https://derkani.org/) presented a second talk on [`cid.contact`](https://cid.contact), the largest most mature IPNI cluster. `cid.contact` is built into [Kubo](https://github.com/ipfs/kubo) as a default routing system since version [`0.18.0`](https://github.com/ipfs/kubo/releases/tag/v0.18.0) and is the content router of choice for [Lassie](https://youtu.be/d5SzSm8NkUU) used by [Rhea](https://youtu.be/p89i9_AskIw). The talk covered the latest architecture of `cid.contact` and the newest features, such as cascading lookup over IPFS DHT and BitSwap, that make it a one-stop content router, tuned to find content no matter where it might be. `cid.contact` has ingested over 1.3 trillion CIDs from hundreds of providers, and just turned one this April. Happy 1st birthday! 🎂
|
||||
|
||||
@[youtube](CPlOdNqJ8og)
|
||||
|
||||
## IPFS Content Routing Workgroup, an introduction by Torfinn Olsen
|
||||
|
||||
Ever wondered where the content routers meet? 🧙 Look no further; the Content Routing Workgroup is it! [Torfinn](https://github.com/TorfinnOlsen) provided an overview of what the workgroup aims for, how community decisions are made, and how things get prioritized in the pipeline. He presented the roadmap ahead for the workgroup and invited the community to join. The workgroup meetings are public and open to all. You can find recordings of the previous meetups [here](https://www.youtube.com/watch?v=LsCH8xw3__c&list=PLuhRWgmPaHtRP5lVouK_eqhC98xaej6Px). Whether it's the next big idea you'd like to propose or just to observe what content routers get up to all day, you are most welcome.
|
||||
|
||||
@[youtube](MagS8ly_YXE)
|
||||
|
||||
## DHT ~~Double Hashing~~ Reader Privacy Updates & Migration Plan by Yiannis Psaras
|
||||
|
||||
It was at the first IPFS þing in Reykjavík where [Gui](https://github.com/guillaumemichel) presented the idea of [Double Hashing](https://www.youtube.com/watch?v=ZPIDU1-JnVc) in the context of Content Routing. Yep; we love hashes so much we're gonna do it twice! In this technique, rather than looking up a CID straight up, it is hashed again and its "double-hashed" value is the key that's used for lookup. In turn, the lookup results are then returned in encrypted form using the original CID as the encryption key. Pretty nifty, right?! Gui presented two follow-up talks on this at IPFS Camp 2022 further [explaining the core idea](https://youtu.be/VBlx-VvIZqU) and what [transitioning to it would mean for content routing](https://youtu.be/m-6_VZ8e1tk). At Brussels, [Yiannis](https://github.com/yiannisbot) walked us through the latest updates in the rollout of ~~Double Hashing~~ Reader Privacy to the IPFS DHT, one of the routing systems in use today. The initial phase of privacy preservation focuses on the "reader" side, where an external observer cannot know what a user is looking up without knowing the original CID. Later work will build on this to expand the privacy benefits to the "writer" side, i.e., content providers.
|
||||
|
||||
@[youtube](FP4kKemco4w)
|
||||
|
||||
## Double Hashing in IPNI: Reader Privacy at scale by Ivan Schasny
|
||||
|
||||
Privacy preservation is a quality that cuts right across routing systems. ✂️ This means no matter how the content is advertised or found we _want to_ preserve the user's privacy. In this talk [Ivan](https://github.com/ischasny) walked us through what this means for IPNI and how it is changing the architecture of `cid.contact` to incorporate reader privacy at its very core: `cid.contact` is moving to _only_ store encrypted provider records which means even the servers do not know what CIDs are being looked up. He expanded on how this big change is being rolled out garcefully, in stages and what's to come in the near future. Watch the [`#ipni` channel on FileCoin Slack](https://filecoinproject.slack.com/archives/C02T827T9N0) for the latest updates.
|
||||
|
||||
@[youtube](Q46zJ_mai2c)
|
||||
|
||||
## Private data: state of the art by Ian Preston
|
||||
|
||||
Taking things one step further on the privacy front, [Ian](https://peergos.org/about#ian_) and his team have been busy building privacy deep at the heart of [Peergos](https://peergos.org/). How does it work? The talk takes a deep dive into the Peergos architecture and how it utilizes `cryptree+`, BATs, and Capabilities to enable post-quantum ciphertext-level access control with improved metadata preservation and better performance. Ian walked us through the challenges they faced, such as garbage collection, and how the team overcame them to make application sandboxing a piece of cake. 🍰 As for the icing, check out Ian's slides shared right from Peergos [here](https://peergos.net/public/demo/talks/2023/ipfs-thing/private-data/web/index.html?open=true).
|
||||
|
||||
@[youtube](HVyrVUI2-RA)
|
||||
|
||||
## Content Advertisement Mirroring by Andrew Gillis
|
||||
|
||||
As the adoption of IPNI as an alternative content routing protocol continues to grow, so does the need for scaling. 🚀 At IPFS Camp 2022, [Andrew](https://github.com/gammazero) presented how IPNI is [scaling the content routing](https://youtu.be/qaCB0UKqwAk). Building on top of previous work, this talk covered how the replication of content advertisements from providers is making ingestion (and re-ingestion) 5X faster. This means new IPNI instances can use alternative sources to build up their index records with much higher velocity, moving us closer to a federated mesh of IPNI instances that continue to maintain lookup latency in orders of a few milliseconds at 10^15 scale!
|
||||
|
||||
The talk was followed by a discussion on a set of open questions as we scale the IPNI network. Take a look and get involved right from where we left off at the next Content Routing Workgroup meeting!
|
||||
|
||||
@[youtube](6l0i8DjhpLg)
|
||||
|
||||
## A Massive Shout-out
|
||||
|
||||
It's great to see the IPFS community coming together and celebrating the latest advancements in the field. A big thank you to all who attended the track at Brussels and to the speakers who presented and helped generate questions. Last but not least, a massive shout-out to the community that tirelessly drives the vision (a better web for all) forward. 🙇
|
||||
|
||||
See you on the decentralised web! ✊
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
title: IPFS þing 2023 Recap
|
||||
description: 'Highlights, photos, and videos from the annual gathering of the IPFS implementers community.'
|
||||
author:
|
||||
date: 2023-05-04
|
||||
permalink: '/2023-ipfs-thing-recap/'
|
||||
header_image: '/ipfs-thing-2023-recap/ipfs-2023-recap-featured-image.jpg'
|
||||
tags:
|
||||
- 'thing'
|
||||
- 'þing'
|
||||
- 'event'
|
||||
- 'recap'
|
||||
---
|
||||
|
||||
The IPFS implementers community recently came together in Brussels, Belgium for the second year of IPFS þing, an annual gathering dedicated to advancing IPFS implementation. With 12 tracks and over 75 talks, demos, and sessions, the 5-day summit that occurred in April 2023 was a showcase of recent advances across IPFS, a forum for sharing needs from the protocol, and an opportunity to chart new directions for the future of IPFS.
|
||||
|
||||
|
||||
|
||||
Over 130 participants joined for a collection of talks, workshops, discussion circles, hacking time, and many many many hallway conversations. Here are a few memorable highlights:
|
||||
|
||||
* **Operators and Deployments:** In this track, the people putting IPFS into production gathered to share their architectures, best practices, and war stories. We laughed. We cried. We looked at a LOT of graphs. Also, this track had some crazy performance numbers – we learned that IPFS can be _really_ fast. ([YouTube playlist](https://www.youtube.com/playlist?list=PLuhRWgmPaHtTYOY5l8nehP_Vt6Ek-svrp))
|
||||
* **Data Transfer:** Since the last IPFS þing, a few different teams that needed faster transfer speeds came together to form the [Move The Bytes Working Group](https://mtngs.io/ipfs/move-the-bytes-wg/). This track included an update on how things are going with the initiative and showed how IPFS can be 10x faster at getting your stuff than Web2! ([YouTube playlist](https://www.youtube.com/playlist?list=PLuhRWgmPaHtS6WBDGK8oxcBHA6ILKatVk))
|
||||
* **Community and Governance:** IPFS is a public good. It's important that it stays that way, that it resists capture, and that it has great governance by (and for) its community. This track charted a course to broad community participation in everything from core protocol standards to planning the next IPFS Camp (no spoilers – you’ll have to watch the talks to know when and where it’s going to be!). ([YouTube playlist](https://www.youtube.com/playlist?list=PLuhRWgmPaHtTIFbOVO5YfXkoFg6wIGbBN))
|
||||
* **IPFS Gateways:** Gateways (servers that translate between HTTP and IPFS) are the biggest onramp to the IPFS network,but they’re also the biggest single point of centralization. Huge changes are happening in this area, so if you’re a gateway user or if your service links to it, then be sure to watch these videos. ([YouTube playlist](https://www.youtube.com/playlist?list=PLuhRWgmPaHtTapMgLW7rRh92Tk8u7wip5))
|
||||
* **Integrating IPFS:** IPFS is used in environments ranging from tiny IoT sensor platforms to mobile devices to satellites in space. In this track, participants learned how IPFS is being implemented in space, on mobile devices running iOS or Android, and in higher level application constructs like “accounts”! We even learned what an “ipfs run” command would look like for distributed functions. ([YouTube playlist](https://www.youtube.com/playlist?list=PLuhRWgmPaHtTI0MS6ZjSJjBxZp7rcjSS_))
|
||||
* **Content Routing:** The first step to exchange “content” over the IPFS network is to either 1) find the given content by using a Content ID (CID), or 2) publish the given content by making its CID known. The Content Routing track covered a holistic view of the content routing evolution since the inception of IPFS and showcased the latest advancements in this simple yet paramount operation in the IPFS ecosystem. This track provided an overview of the InterPlanetary Network Indexer (IPNI), and expanded on how it enables mass publication and lookup of content across hundreds of billions of CIDs. The latest developments in reader privacy preservation, a mechanism that enables private lookups of content both on the IPFS DHT and IPNI, was also presented. ([YouTube playlist](https://www.youtube.com/playlist?list=PLuhRWgmPaHtRBWV3SvInC5ATS8aKV3lsW))
|
||||
|
||||
|
||||
|
||||
IPFS þing isn’t just about getting things done though… it’s also about doing things together. Because we were in the beating bureaucratic heart of the European Union, we had to ~~flaunt the rules~~ pay respect to the culture and history of the region by visiting the [Atomium](https://atomium.be/home/Index) for dinner on one night and the [Comics Art Museum](https://www.comicscenter.net/en/home) on another. We also held a game night featuring IPFS trivia that you will never be able to guess the answers to, but you may get a chance soon by following IPFS on [Twitter (@ipfs)](https://twitter.com/ipfs) or [Bluesky (@ipfs.tech)](https://staging.bsky.app/profile/ipfs.tech)
|
||||
|
||||
|
||||
|
||||
The closing session of IPFS þing was kicked off by a rousing call to action from [Danny O’Brien](https://twitter.com/mala) highlighting the importance of daily use of IPFS software within the community. This was followed by a group retrospective on the event itself run by IPFS inventor Juan Benet, collecting feedback in real time from all attendees as input into the next one.
|
||||
|
||||
|
||||
|
||||
The event would not have been possible without the dedication of our awesome track leaders, the 75+ speakers and sessions, the 5 IPFS þing Scholars who brought their unique perspectives and experiences to the event, and of course, everyone who traveled from over 30 countries to participate. Thank you to our incredible community for making IPFS þing 2023 an amazing experience, and see you next time!
|
||||
|
||||
Check out the full list of talks on the [IPFS YouTube channel](https://www.youtube.com/@IPFSbot/playlists). You can also head directly to each track’s video playlist:
|
||||
|
||||
* [Opening Keynotes](https://www.youtube.com/watch?v=G2hlQqvjE-Y&list=PLuhRWgmPaHtRnO5G2EF0RxYebcQzLDf5F)
|
||||
* [Measuring IPFS](https://www.youtube.com/watch?v=O8Nk1FN04Q8&list=PLuhRWgmPaHtQkkbiq-PbIkt9_S2NjJz6x)
|
||||
* [IPFS Deployments & Operators](https://www.youtube.com/watch?v=bILa9sPpBMs&list=PLuhRWgmPaHtTYOY5l8nehP_Vt6Ek-svrp)
|
||||
* [Data Transfer](https://www.youtube.com/watch?v=13_zr--akhs&list=PLuhRWgmPaHtS6WBDGK8oxcBHA6ILKatVk)
|
||||
* [IPFS on the Web](https://www.youtube.com/watch?v=dn8PssXkRbY&list=PLuhRWgmPaHtQ-TO65P62tqfUM85HCIqSj)
|
||||
* [Interplanetary Databases](https://www.youtube.com/watch?v=tjSuNmCTnyU&list=PLuhRWgmPaHtTO8hr2CYiJPTSe7wybW_op)
|
||||
* [Content Routing](https://www.youtube.com/watch?v=oe7fjOl-q0s&list=PLuhRWgmPaHtRBWV3SvInC5ATS8aKV3lsW)
|
||||
* [HTTP Gateways](https://www.youtube.com/watch?v=p89i9_AskIw&list=PLuhRWgmPaHtTapMgLW7rRh92Tk8u7wip5)
|
||||
* [Decentralized Compute & AI](https://www.youtube.com/watch?v=LK9QjOJIPkQ&list=PLuhRWgmPaHtQ_lKtbTR-vIW1LYuTjcaPw)
|
||||
* [Integrating IPFS](https://www.youtube.com/watch?v=drvFcbykHYY&list=PLuhRWgmPaHtTI0MS6ZjSJjBxZp7rcjSS_)
|
||||
* [Community & Governance](https://www.youtube.com/watch?v=U2qvvQxIdws&list=PLuhRWgmPaHtTIFbOVO5YfXkoFg6wIGbBN)
|
||||
|
||||
Subscribe to the [IPFS Community Calendar](https://lu.ma/ipfs) to be the first to know about both online and in-person events, including pre-registration for our community-wide [IPFS Camp](https://lu.ma/ipfscamp23-prereg) in autumn 2023!
|
||||
|
||||
|
||||
|
||||
See you there! 🚀
|
||||
@@ -1,73 +0,0 @@
|
||||
---
|
||||
title: 'IPLD: The Data Layer of the Decentralized Web'
|
||||
description: 'How IPLD and content addressing provide the foundation for the decentralized web'
|
||||
author: Mikeal Rogers
|
||||
date: 2023-02-21
|
||||
canonicalUrl: https://medium.com/@mikeal/the-new-data-d6b5e392da43
|
||||
permalink: '/ipld-the-new-data/'
|
||||
header_image: '/ipld-new-data.png'
|
||||
tags:
|
||||
- 'ipld'
|
||||
---
|
||||
|
||||
## The New Data
|
||||
|
||||
What is data? The question is more philosophical than practical, but the definition we seem to be able to agree on is that data is a medium for expression.
|
||||
|
||||
You can express a lot with data, almost anything, but like a painting, the meaning of that expression is subjective and depends on the context you have around it. A pollster publishes data they believe accurately captures the state of mind of a people, but to the statistician [Nate Silver](https://en.wikipedia.org/wiki/Nate_Silver) this data is only one point in a more complex answer to the same question.
|
||||
|
||||
We add meaning to data by altering its context. We link to and from pieces of data to accumulate greater context and therefore greater meaning. We have many means of linking data. A social network captures the expressions of many individuals and connects those expressions with others in a large relational database. The Web connects pages by way of URL links, either within the same site or between any sites on the Web. Nate Silver collects data and links it into a complex model that weights different data points into probabilistic metrics.
|
||||
|
||||
## Content Addressing
|
||||
|
||||
For decades now, researchers and engineers have been building on top of hash-linked data structures. These are structures in which the link from one piece of data to the next is a cryptograph hash of the content being linked to. The first widely adopted use of these data structures was git and in the proceeding decade, we’ve seen an explosion in blockchains and applications built on blockchains all relying on these same hash-linked structures.
|
||||
|
||||
Hash linking has an interesting property, it allows you to create links between pieces of data without actually locating all of that data in a consistent _location_. Databases typically can’t do this, they capture the relationships between pieces of data using their locations on disc. URLs on the Web can link between sites, but those links contain the **location** of that site. With hash linking, you can define a relationship to data you don’t even store, and anyone in the world can provide that data securely.
|
||||
|
||||
Since the link to a piece of data is the hash itself you can always compute the hash again to validate it’s a match. This is what allows trustless p2p networks to exchange hash-linked data, which is how BitTorrent works. This means of addressing data is called “Content Addressing” as opposed to the traditional approach of “Location Addressing.”
|
||||
|
||||
## Limits of Open Source
|
||||
|
||||
People, including me, have become accustomed to saying “Open Source won.” On one level this is true, most of the code in the applications you rely on every day is Open Source. But for many of us Open Source is about values and freedoms as much as it is about code.
|
||||
|
||||
A freedom can’t be measured by the lines of code that fall under a particular license; a freedom is rendered unusable if it is not guaranteed by the final product. Open Source _code_ may have won, but Open Source _applications_ are marginal at best. Most applications are still proprietary and assembled by combining a lot of Open Source code with a little bit of proprietary product code.
|
||||
|
||||
Open Source communities are capable of building products. I’ve been amazed at what Open Source communities can achieve given the right circumstance, the only thing I haven’t been able to see them do well is manage a bank account, which is what you need to build a modern application.
|
||||
|
||||
So much of the application toolchain is Open Source that it’s easy to forget that multi-user applications effectively **require** a recurring data bill. The value of most modern applications isn’t in the user data they capture but in the relationships they build between the data produced by different users. These relationships have not been realistic to build without a large relational database which means a recurring monthly bill.
|
||||
|
||||
If you think about it, there’s nothing other than the database keeping us from building a Twitter or Facebook competitor in a GitHub repo published to [GitHub Pages](https://pages.github.com/) (which is already automatically fronted by Cloudflare). That’s a phenomenal deployment stack, and it’s a significantly better environment to develop and scale than what Facebook and Twitter had when they launched. **But that damn database!**
|
||||
|
||||
## BYOS (Bring Your Own Storage)
|
||||
|
||||
Right now there’s a wide gulf between traditional centralized applications and “DApps” (decentralized applications) built on blockchains. Blockchains provide transactions that allow applications to manipulate shared and even global state without centralization. Since database transactions do something quite similar it may seem like these transactions are what should replace traditional database transactions, but most of applications have very little shared state between users other than the relationships built by way of indexing.
|
||||
|
||||
If you think about how people use Twitter or Facebook, they are effectively publishing into their own namespace—there’s no other users you need to reconcile those transactions with. The relationships that are built between one user’s data and another’s is done secondarily. It’s merely a view that is generated over what individuals are publishing independently. None of this actually requires a decentralized transaction. Rather, it requires decentralized linking.
|
||||
|
||||
It’s not difficult to imagine a workflow in which a user “Signs In” with their data provider the same way people login to third party applications with Google or GitHub. The difference however is that instead of just validating the authentication, the application now stores the user’s data in that provider. This has been possible for some time, but it hasn’t been very practical because we lacked a means for the application to create relationships between data hosted in different providers. Fortunately, content addressing provides us this opportunity.
|
||||
|
||||
The mistake I feel IndieWeb and others have made is to frame the solution to application centralization as a personal application silo or “personal cloud.” This approach makes multi-user applications very difficult and ignores the fact that most users would still prefer to hire a provider than run something themselves. Disambiguating the application centralization from the data centralization exposes a better model where applications can be hosted and maintained by one party and the user can choose their own data provider to be used by that application. This approach also forces an application federation model since any new application can be authenticated to a user’s chosen data provider.
|
||||
|
||||
## IPLD
|
||||
|
||||
For the last few years, the [IPLD](https://ipld.io/) project has provided tooling in a number of languages to address the challenge of working with **content addressed data structures**. It has also enabled people to explore the vast universe of new data structures that can be built on these primitives.
|
||||
|
||||
**The IPLD project (InterPlanetary Linked Data) is the foundational data layer of both [IPFS](https://ipfs.tech/) and [Filecoin](https://filecoin.io/).** Data you create in IPLD can be stored anywhere (local, S3, numerous storage backends). It can even be persisted and distributed with IPFS and stored in Filecoin. For example, [CAR files](https://ipld.io/specs/transport/car/carv1/) provide a uniform format for moving IPLD content-addressed data in a transport-agnostic way with libraries for [Go](https://github.com/ipld/go-car), [Rust](https://crates.io/crates/iroh-car), and [JavaScript](https://github.com/ipld/js-car).
|
||||
|
||||
IPLD isn’t just a means of **representing** data, it’s a means of **linking** data together. You can even link between encoding formats using different hashing methods. The project has substantially matured, and it’s time to start building databases and thinking about how everyday applications can be adapted to these new patterns.
|
||||
|
||||
> **Note:** IPLD can be thought of as a generalization of [UnixFS](https://docs.ipfs.tech/concepts/file-systems/#unix-file-system-unixfs), the default Protocol Buffers based format for representing files and directories in IPFS. In other words, IPLD is a superset of UnixFS and can be used to represent any arbitrary linked data.
|
||||
|
||||
## The Web of Data
|
||||
|
||||
What makes IPLD the data layer of a decentralized web is that it does more than provide a transport-agnostic and universal way to move data to where users want; it enables all future applications to be built on top of every prior application’s data (an approach explored by [Ceramic](https://ceramic.network/)).
|
||||
|
||||
In the same way that a website has the opportunity to link to every other website on the internet, when you build a data structure in IPLD you can link to the data that has been produced by every application that has ever been built. It doesn’t replace a centralized database with a decentralized database... it replaces the nature of data itself.
|
||||
|
||||
Data in IPLD is not captured and controlled by a provider, it’s accessible to the world and can be distributed by anyone in the world. We don’t need to replace Twitter with another Twitter—we can replace Twitter with hundreds or even thousands of applications that all provide different experiences while sharing common notions of a “feed” or “timeline” that continue to link to each other's data.
|
||||
|
||||
This framework opens the door for Open Source communities to create important everyday applications that continue to reinforce Open Source freedoms in a way that licensing can't.
|
||||
|
||||
There’s a real future here, but it requires a lot of us to participate if we want it to succeed. I hope to see all your faces as this community continues to grow.
|
||||
|
||||
> Note: This blog post was originally published on [Medium](https://medium.com/@mikeal/the-new-data-d6b5e392da43) and adapted for the IPFS Blog.
|
||||
@@ -1,122 +0,0 @@
|
||||
---
|
||||
title: 'Recap: IPFS on the Web (þing 2023)'
|
||||
description: 'Track recap with links and serious analysis for the IPFS on the Web track at IPFS þing 2023'
|
||||
author: Dietrich Ayala
|
||||
date: 2023-05-10
|
||||
permalink: '/2023-ipfs-thing-web-track/'
|
||||
header_image: '/ipfs-thing-2023-recap/ipfs-on-the-web-featured-image-2.jpg'
|
||||
tags:
|
||||
- 'thing'
|
||||
- 'þing'
|
||||
- 'event'
|
||||
- 'recap'
|
||||
- 'track'
|
||||
- 'web'
|
||||
---
|
||||
|
||||
The world wide web is both the biggest deployment vector and least controllable surface for IPFS. There are opportunities and challenges with bringing IPFS support to rendering engines, browsers, gateway-served content, web apps, and browser extensions. It is these unique dynamics that motivated us to organize a dedicated content track for them at the annual gathering of IPFS implementers known as IPFS Thing.
|
||||
|
||||
To catch you up to speed, the [*Browsers and the Web Platform* track at IPFS Thing 2022](https://2022.ipfs-thing.io/schedule/#Browsers-and-The-Web-Platform) was only a half day long with a small group of people. It had browser and gateway progress updates, some alternate visions of how a content-addressed web could work on desktop and mobile, and also some straight-up "stuff is hard still" talks. You can listen to [all of these talks](https://www.youtube.com/watch?v=_DGVa2CJjIc&list=PLuhRWgmPaHtTsL76nt_A6CPDe6lW7l6Sz) on YouTube.
|
||||
|
||||
A few months later at [IPFS *Camp* 2022](https://2022.ipfs.camp/#Browsers-Platforms) we had a similar track with many more people and the tone changed a bit — we saw more working code, and even features shipped in products that were represented, and we covered platforms outside of web, like native mobile and space. You can watch the [full playlist of videos](https://www.youtube.com/watch?v=HhCHvuP5IJo&list=PLuhRWgmPaHtQohNbRjFJDS70WoElZ8ep5) on YouTube as well.
|
||||
|
||||
This brings us to IPFS *Thing* 2023 that occurred last month. I had the privilege of broadening the lens even further than we experienced at the previous two gatherings. We examined the opportunities, challenges, products, protocols, and experiments in the intersection of these two distinct paradigms of HTTP and IPFS. This area of the IPFS ecosystem is changing so rapidly that [HTTP Gateways to the IPFS network](https://www.youtube.com/watch?v=p89i9_AskIw&list=PLuhRWgmPaHtTapMgLW7rRh92Tk8u7wip5) had a whole track to itself this year. This gave the Web track more room to move, so we were able to cover everything from naming systems to publishing pipelines and JS toolkits and more.
|
||||
|
||||
In the rest of this blog post you'll find highlights, links, and commentary from the track lead (that's me, Dietrich) on why these talks were selected and why I think they're helping make a better web for us all.
|
||||
|
||||
You can find the full video playlist for the IPFS on the Web track [here](https://www.youtube.com/watch?v=dn8PssXkRbY&list=PLuhRWgmPaHtQ-TO65P62tqfUM85HCIqSj), and I'll link each below as well.
|
||||
|
||||
## IPFS on the Web in 2023 (so far) - Dietrich Ayala
|
||||
|
||||
[Dietrich](https://metafluff.com/) gave a short overview of various initiatives and collaboration projects of the Browsers, Platforms & Standards team at Protocol Labs. It was a peek into the latest IPFS features in Brave Browser, early work into Chromium native support for IPFS, and various other work those weirdos are pushing forward.
|
||||
|
||||
@[youtube](dn8PssXkRbY)
|
||||
|
||||
## What Is The Web? - Robin Berjon
|
||||
|
||||
Good morning. Have you had a coffee yet? Ok great because you're going to need it for this talk. [Robin](https://berjon.com/) sets the perspective for the day by asking us one of the most difficult questions: "What is the web, actually?" It's big. It's special. We complain about it. But we need to have language to describe what it is in order to talk about how it could grow and change. Warning: This talk begins at a point in history over 100 years ago!
|
||||
|
||||
@[youtube](s878bm15mrk)
|
||||
|
||||
## A better web: secure, private, p2p apps with user-owned data and identity - Ian Preston
|
||||
|
||||
[Peergos](https://peergos.org/) has been building *your* private space online for half a decade, and it shows: [Ian](https://peergos.org/about#ian_) and team have built a mostly exilfiltration-proof application platform on IPFS which works in the browsers of today. The idea of web content that can't phone home might make you say "hmmm", but it could just be the antidote to the surveillance-is-required-to-pay-the-bills version of the web we have today.
|
||||
|
||||
@[youtube](mSElk2jcFqY)
|
||||
|
||||
## WNFS: Versioned and Encrypted Data on IPFS - Philipp Krüger
|
||||
|
||||
It's the web. It's p2p. It's files. It's private. It's WNFS! [Philipp](https://irreactive.com/) walks us through how the WebNative Filesystem works, and how it works in browsers specifically. It's not easy, but none of us signed up for easy. That being said, you *can* sign up to join the [WNFS Working Group](https://github.com/wnfs-wg) today after watching this talk.
|
||||
|
||||
@[youtube](LBMyRp4Ywew)
|
||||
|
||||
## Content Based Addressing and the Web Security Model - Fabrice Desré
|
||||
|
||||
Speaking of hard... have you ever decided that the problem you'd like to fix in the world is Google and Apple's stranglehold on our daily digital lives? That's what [Fabrice](https://github.com/fabricedesre) does with [Capyloon](https://capyloon.org/), a complete web-based mobile operating system. When you control the OS, you ~~control the world~~ can do veeeerrrry interesting things. Fabrice gave us a deep dive into the [origin security model](https://www.rfc-editor.org/rfc/rfc6454) today and how radically different it can be in a content-addressed world.
|
||||
|
||||
@[youtube](H_1JVGDnctI)
|
||||
|
||||
## Hello Helia - achingbrain
|
||||
|
||||
Bye Felicia. Hello Helia. Thanks [achingbrain](https://github.com/achingbrain). Welcome to a new way to IPFS in JavaScript, on the web, or on the server... finally with nice things like DHT support. It should've been called banana. But we like it anyway.
|
||||
|
||||
@[youtube](T_FlhkLSgH8)
|
||||
|
||||
## JavaScript performance - how to wring the most out of your Helia deployment - achingbrain
|
||||
|
||||
Hey it's [achingbrain](https://github.com/achingbrain) again, this time with a deep dive into Helia performance and optimizing for the environment you're deploying to. JavaScript is the *fastest* language for the environments it lives in which other languages can't even exist, so take that.
|
||||
|
||||
@[youtube](zPeLYosZ3Ak)
|
||||
|
||||
## Connecting everything, everywhere, all at once with libp2p - Prithvi Shahi
|
||||
|
||||
First, the person who gives this talk is not Prithvi, it's Max. Second, Prithvi is a genius for thinking up a talk like this. Please enjoy all the transports everywhere all of the time.
|
||||
|
||||
@[youtube](zPeLYosZ3Ak)
|
||||
|
||||
## The Incredible Benefits of libp2p + HTTP - Marten Seemann & Marco Munizaga
|
||||
|
||||
In the ageless words of Gandalf, the headmaster of Hogwarts: "be like water". Or something like that. Anyways, if you're familiar with the challenge of writing code for the web that has to pretend that it's not actually stuck in a web browser tab, but instead is actually connected to a global transport-agnostic peer-to-peer network, then you'll understand how important it is to make friends with your environment and use the *!#? out of what it gives you. This talk from Marten and Marco shows you how the changing landscape of the network layer of the web platform is allowing libp2p to operate unfettered while still stuck in a tab in a window in a browser on your computer on earth.
|
||||
|
||||
@[youtube](Ixyo1G2tJZE)
|
||||
|
||||
## The Name Name Service - Blaine Cook
|
||||
|
||||
NNS.. NNS.. NNS... goes the beat. Now that you're bouncing your head, follow along as Blaine Cook shares his vision of how we solve one of the three hardest problems in computer science: how to make the perfect Hollandaise. Er, no that wasn't it. NAMING! Yes, that was it. The Name Name Service is a breathtakingly simple approach to flexible, veriable, integrate-able, old-world-compatible, and human-readable names for our digital things. Thank you Blaine.
|
||||
|
||||
@[youtube](CHiCEd36KtI)
|
||||
|
||||
## Building decentralized websites on IPFS - Ryan Shahine
|
||||
|
||||
Decentralization is cool but it's so hard and you have to be super technical to even... wait, what? I can just... drag and drop? What I see is what I get?! With Portrait, yes. Ryan Shahine shares Portrait's slick and simple site builder for publishing your sites to IPFS. No-code sites for non-technical creators is such a wonderful thing to behold.
|
||||
|
||||
@[youtube](TeFAHmzvIdg)
|
||||
|
||||
## ODD.js, a technical overview - icidasset
|
||||
|
||||
Oddly enough, DID you know UCAN build decentralized applications with that WNFS stuff we heard about earlier? In this preview of the final emergent form of a bunch of Fission's tools coming together like Voltron, you'll meet Odd.js - a toolkit for building applications that has all of the core bits you need, from identity to naming to storage to security. The only odd thing is that we didn't have this yet.
|
||||
|
||||
@[youtube](ByQbY3lNAck)
|
||||
|
||||
## IPFS native frontend development using Importmaps - Dilip Shukla
|
||||
|
||||
Imagine if your CDN was a massive cooperative global distributed network that 1) wasn't a single company, and 2) pushed alllll the way up into your client-side build tooling, making your pages immediately available. WHAT YOUR DOM WAS ACTUALLY A DAG... ok maybe that's too far, but what Lagom is doing is finding exactly what the right balance is. In the future we'll look back and wonder why we didn't do this from the begining...
|
||||
|
||||
@[youtube](4HY_7DxScMo)
|
||||
|
||||
## Explorations into Decentralized Publishing - David Justice
|
||||
|
||||
The Browsers, Platforms and Standards team wants to share our thoughts early and often. And we want to do it on IPFS. There are all kinds of ways to do it, but each have their trade-offs... but it's not clear what those are until you go make a bunch of mistakes. So we're going to make them for you. David Justice is working on approaches for building our team blog with some friends at Trigram and shares what the first stab at it looks like.
|
||||
|
||||
@[youtube](fn5QNvRXMIo)
|
||||
|
||||
## Thank you!
|
||||
|
||||
Thanks to all the speakers for the day and also to the rad people who joined and asked great questions.
|
||||
|
||||
Until our next event, come hang out in our superbridged megachannel:
|
||||
|
||||
* #browsers-and-platforms on Filecoin Slack ([join](https://filecoin.io/slack))
|
||||
* #browsers-and-standards on Element/Matrix ([join](https://matrix.to/#/#browsers-and-standards:ipfs.io))
|
||||
* #browsers-and-standards on IPFS Discord ([join](https://discord.gg/ipfs))
|
||||
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
title: '3S Studio: Bringing Unreal Engine to IPFS'
|
||||
description: 3S Studio can free game developers from platform dependency via IPFS.
|
||||
author: Adam Grodzki
|
||||
date: 2022-11-15
|
||||
permalink: "/2022-11-15-3s-studio/"
|
||||
translationKey: ''
|
||||
header_image: "/0000_v2.jpg"
|
||||
tags: []
|
||||
|
||||
---
|
||||
3S Studio is a game development team that has implemented an IPFS plugin for the popular and widely-used Unreal Engine for 3D computer graphics. The plugin was created with close cooperation with Filecoin Foundation and Protocol Labs and is available on the [official Unreal Engine marketplace](https://www.unrealengine.com/marketplace/en-US/product/ipfs). It can be used directly within C++ and is also fully exposed to Blueprints. The download includes full documentation, learning materials, as well as example content and projects.
|
||||
|
||||
After the September 2022 release for versions 4.27 and 5.0, the team plans to continue updates for all future versions and Unreal Engine 4 as long as new versions don’t rely on UE5-only features.
|
||||
|
||||
# .pak and Modular Gameplay Features
|
||||
|
||||
The most important feature in 3S Studio’s plugin is that, due to the nature of gameplay modular features — being loaded on demand at runtime — the team was able to package them as separate .pak files and load them dynamically into the game. As references are encapsulated within the feature, it requires almost no extra effort to register the newly created asset classes, as features have their own initialization process.
|
||||
|
||||
As Unreal Engine is under active development — tracking new features and plans — 3S Studios foresees that similar treatment will be given to Data Layers. This means that, in the future, it will be able to mount and load objects directly related to quests, events, and context of the gameplay.
|
||||
|
||||
In a demo project, 3S Studio was able to reduce the content size of a game from **2 gigabytes to 40 megabytes**, with the rest of the content being downloaded only on demand. This workflow can potentially decrease installation sizes of games in the future.
|
||||
|
||||
# Supported Platforms
|
||||
|
||||
The common gateways predefined at launch are:
|
||||
|
||||
* IPFS
|
||||
* Cloudflare
|
||||
* Pinata
|
||||
* Infura
|
||||
* Web3.Storage
|
||||
* NFT.Storage
|
||||
* Local desktop node
|
||||
|
||||
Developers can also configure access to any custom gateway such as a private one or a testing environment gateway.
|
||||
|
||||
# Why 3S Studio Uses IPFS
|
||||
|
||||
There are a number of subsystems, cloud storages, and service providers that allow you to store data in the cloud and directly access it from the game. Until now, all of those systems have been centralized and usually require predefinition and provide limited configuration using online proprietary service administration panels.
|
||||
|
||||
This is where IPFS is important for a project like 3S Studio. As a web3-based stack, IPFS brings a lot more to the table for game developers than traditional cloud storage providers thanks to [content-addressing](https://docs.ipfs.tech/concepts/content-addressing/).
|
||||
|
||||
It is also a step forward when compared to other web3 projects such as regular blockchain networks with limited storage functionalities. Many developers approach web3 in ways that feel "forced in" instead of being of actual utility to the end users. IPFS, however, solves many tangible problems for a web3 game developer by helping with:
|
||||
|
||||
* Storage of large quantities of big “save game” files on-chain, solving an issue that already [affects](https://www.gamesradar.com/red-dead-redemption-2-fan-with-nearly-6000-hours-on-stadia-begs-rockstar-for-character-transfer/) users when platforms shut down.
|
||||
* Storage of user data (for example achievements, game progress, anonymous metrics) in a JSON format and track changes for such data using IPNS.
|
||||
* Saving, storing, and sharing between players – schematics, blueprints and other user-created content.
|
||||
* Loading data to disc, or parse directly into memory as usable parameters (string values, texture 2d from image, sound wave from a wave sound file).
|
||||
* Patching games and distributing content, DLCs, cosmetic packs, battle pass content, and live service content.
|
||||
* Allowing the core game to stay the same for everyone with unlimited customizations that are shippable to end-users.
|
||||
|
||||
IPFS even solves issues that modern life-sim and casual games have. It can be easily used for the distribution and storage of vast numbers of user created patterns, blueprints, and parameterized items. This allows developers to create a stack of incremental updates that can be applied in order to a physically shipped base game.
|
||||
|
||||
The biggest feature of using IPFS is that the game’s creators are running the service and no longer depend on third-party services. Centralization of usable features on platforms like Steam put game developers in a weak position where they are vendor-locked and have to give up a 30% cut of their revenue. With IPFS, developers are free from platform dependency.
|
||||
|
||||
# Future Plans
|
||||
|
||||
After the release, 3S Studio plans to continue the development of new IPFS features into the plugin as supplementary tools that will help utilizing the full potential of the distributed game builds.
|
||||
|
||||
By the end of the year, the team aims to implement versioning via IPNS, upload of entire folders and complex structures, and chunking via CAR containers. It will also work on a fully functional and easily configurable workflow for packaging and shipping content in multiple .pak files.
|
||||
|
||||
If you’d like to stay updated on 3S Studio’s plans follow the team on [Twitter](https://twitter.com/3SGameStudio) or visit the [3S Studio website](https://www.3studio.online/).
|
||||
@@ -1,81 +0,0 @@
|
||||
---
|
||||
title: Adding IPFS Protocol Support to Chromium
|
||||
description: Build Chromium with support for “ipfs://” addresses in two lines of code.
|
||||
author: Dietrich Ayala
|
||||
date: 2022-11-14
|
||||
permalink: "/14-11-2022-igalia-chromium"
|
||||
translationKey: 14-11-2022-igalia-chromium
|
||||
header_image: "/ipfs-blog-header_-chromium-protocol-handlers-post.png"
|
||||
tags:
|
||||
- browsers
|
||||
|
||||
---
|
||||
Protocol Labs and Igalia are pleased to announce a major milestone in our efforts to bring more extensibility and user agency to the web and to browsers:
|
||||
|
||||
*Support for pre-defined custom protocol handlers in Chromium!*
|
||||
|
||||
... ummm, what does that even mean? And why should you care?
|
||||
|
||||
In short: You can now build Chromium - the open source browser code used for Chrome, Brave, Edge, Opera and more - with support for "ipfs://" addresses by changing only a couple of lines of code.
|
||||
|
||||
Read on to learn why this is a key step towards browsers that can meet a far more diverse set of user needs while maintaining an interoperable core.
|
||||
|
||||
## Igalia and Protocol Labs
|
||||
|
||||
[Igalia](https://www.igalia.com/) has been working on improving the web for over 20 years. They're an open source consultancy who participate in web standards and work on Chromium, Webkit and Gecko - the three primary web platform rendering engines.
|
||||
|
||||
In 2019, we set up a contract with Igalia to work on web platform features and compatibility fixes to make life easier for decentralized web projects and deployment topologies where the browser interacted with services residing on the same computer.
|
||||
|
||||
This colloboration covered a *lot* of ground - from IANA to WHAT-WG to W3C to IETF to negotiation and coordination with Apple, Google and Mozilla... resulting in a slew of changes catalogued in [this blog post](https://blog.ipfs.tech/2021-01-15-ipfs-and-igalia-collaborate-on-dweb-in-browsers/) in 2021.
|
||||
|
||||
Very few changes were specific to IPFS. A lot of the work was making browsers and the web platform more amenable to localhost-oriented application topologies and non-HTTP protocol work - fixing compat papercuts, aligning security models across engines, cleaning up dusty corners... making the web itself just a little bit better.
|
||||
|
||||
But our larger goal is to bring the web to places where it doesn't work well for people today, and enable experimentation in what a web with alternative protocols can look like. These are paradigmatic changes, so we needed to do more than just surface-level fixes.
|
||||
|
||||
## IPFS Browser Integrations So Far
|
||||
|
||||
IPFS has achieved a signficant amount of support in various ways across a number of browsers, from extensions to different levels of built-in support in Brave and Opera, to experiments with mobile operating systems. Looking back at the [IPFS browser update from 2019](https://blog.ipfs.tech/2019-10-08-ipfs-browsers-update/), the world looks *very* different:
|
||||
|
||||
* The IPFS Companion browser extension is available for [Firefox](https://addons.mozilla.org/en-US/firefox/addon/ipfs-companion/) and for [Chromium-based browsers](https://chrome.google.com/webstore/detail/ipfs-companion/nibjojkomfdiaoajekhjakgkdhaomnch), which pairs with a local IPFS node like [IPFS Desktop](https://docs.ipfs.tech/install/ipfs-desktop/)
|
||||
* [Opera browser](https://www.opera.com/) has support for the `ipfs` and `ipns` schemes in their [Android](https://blog.ipfs.tech/2020-03-30-ipfs-in-opera-for-android/), [iOS](https://blog.ipfs.tech/2021-02-08-opera-ios-and-ipfs/) and desktop browsers, redirecting to the https://dweb.link gateway
|
||||
* [Brave browser](https://brave.com/) bundles IPFS Companion, has `ipfs` and `ipns` scheme support, can redirect to a gateway and also can install and manage a [Kubo IPFS node](https://github.com/ipfs/kubo) to make the browser a full participant in the IPFS public network
|
||||
* [Capyloon](https://capyloon.org/), a web-based mobile operating system based on KaiOS and Firefox OS, and built with Firefox's Gecko rendering engine, has `ipfs` and `ipns` scheme support backed by [Iroh](https://github.com/n0-computer/iroh), a Rust implementation of IPFS from number0.
|
||||
|
||||
There's interest and opportunities and challenges in various browsers - lots of accomplishments, but lots still to figure out.
|
||||
|
||||
|
||||
|
||||
Some notes on the table above:
|
||||
* The native Firefox part is via the work Capyloon is doing to integrate IPFS via a protocol handler and bundling IPFS components in Rust from [Iroh](https://github.com/n0-computer/iroh) into Gecko, in the Capyloon fork, not in Mozilla's core repos. There's a tracking bug open for [IPFS support in Firefox](https://bugzilla.mozilla.org/show_bug.cgi?id=1354807), but no plans from Mozilla to implement at this time.
|
||||
* The [Filecoin support in Brave](https://filecoin.io/blog/posts/brave-browser-adds-filecoin-to-wallet/) is in their native wallet. Also, NFT pinning support will come in 2023 - saving NFT assets and metadata to the local IPFS node and/or [nft.storage](https://nft.storage).
|
||||
|
||||
## Native Integration
|
||||
|
||||
Redirecting `ipfs` and `ipns` to an HTTP gateway is just a step along the road to a truly native integration of IPFS into the web platform. It's not ideal for a number of reasons, but does align with the HTTP-centric nature of the web today, which makes it a relatively simple integration. But without support for non-HTTP protocols in web browser cores, Opera and Brave both had to do custom work in their products to add even this level of integration - which is costly and complex.
|
||||
|
||||
If the underlying engine - Chromium - supported non-HTTP protocols better as a built-in feature, then *embedders* (Chromium lingo for products building on top of it) could more easily integrate and experiment, and we could spend more time working on what truly native IPFS support might look like in the web platform, instead of just redirecting to an HTTP gateway. Igalia agreed it was a worthy goal, and the feedback from the Chromium commmunity around the work was positive, so off we went.
|
||||
|
||||
|
||||
|
||||
## Major Chromium Refactor
|
||||
|
||||
Javi Fernandez of Igalia spent most of the last year refactoring epically large and senstive parts of the Chromium codebase to support non-HTTP addresses across the multiprocess architecture of this massive application. After many stages of work involving code reviews from a huge number of engineers in the Chromium community, Javi made the pre-defined handler approach so simple that embedders now can add a simple redirect integration of IPFS in two lines of code added to the [ChromeContentClient::AddAdditionalSchemes method](https://source.chromium.org/search?q=AddAdditionalSchemes&sq=&ss=chromium):
|
||||
|
||||
> schemes->predefined_handler_schemes.emplace_back(
|
||||
> "ipfs", "https://dweb.link/ipfs/?uri=%s");
|
||||
>
|
||||
> schemes->predefined_handler_schemes.emplace_back(
|
||||
> "ipns", "https://dweb.link/ipns/?uri=%s");
|
||||
|
||||
|
||||
He has detailed the new architecture in a couple of posts:
|
||||
|
||||
- [New Custom Handlers component for Chrome](https://blogs.igalia.com/jfernandez/2022/08/10/new-custom-handlers-component-for-chrome/)
|
||||
- [Discovering Chrome’s pre-defined
|
||||
Custom Handlers](https://blogs.igalia.com/jfernandez/2022/11/14/discovering-chromes-pre-defined-custom-handlers/)
|
||||
|
||||
And recently at IPFS Camp in Lisbon Portugal, Javi gave a talk about this work - which you can watch here:
|
||||
|
||||
@[youtube](WLCJ9ol8Fgk)
|
||||
|
||||
If you're interested in learning more, join the `#browsers-and-platforms` channel on the [Filecoin Slack](https://filecoin.io/slack/), which is bridged also to `#browsers-and-standards` on [Matrix](https://matrix.to/#/%23browsers-and-standards:ipfs.io) and the [IPFS Discord](https://discord.gg/vZTcrFePpt).
|
||||
@@ -1,86 +0,0 @@
|
||||
---
|
||||
title: 'Bacalhau Beta v1: WASM Support, Simplified UX and Better Reliability'
|
||||
description: Bacalhau v1 Beta release and supported features.
|
||||
date: 2022-12-13
|
||||
permalink: '/2022-12-13-bacalhau-beta-v1/'
|
||||
translationKey: ''
|
||||
header_image: "/Compute_Over_Data_Blog_Graphic_for_Bacalhau_beta_version_OPT_3.png"
|
||||
author: David Aronchick
|
||||
tags:
|
||||
- Bacalhau
|
||||
|
||||
---
|
||||
|
||||
Hi all!
|
||||
|
||||
Today, we are EXCEEDINGLY pleased to announce the Beta of **[Project Bacalhau](https://www.bacalhau.org/)**. Bacalhau is a distributed compute network for IPFS data, where users can run arbitrary docker containers and Wasm images against data stored in IPFS. With Bacalhau, we plan to take a meaningful step towards unlocking distributed, content-addressed compute for everyone and improving how people interact with the ever-growing amount of information available.
|
||||
|
||||
## Background
|
||||
|
||||
Since our initial public launch in July, we have heard tons of exciting ways that researchers and entrepreneurs are using Bacalhau. These include:
|
||||
|
||||
- [City of Las Vegas & Blocz.io](https://medium.com/blocz/open-grid-alliance-unleashes-monetization-platform-in-las-vegas-5061eae8f946): Blocz IO is excited to partner with Bacalhau to process real-time CCTV data for the City of Las Vegas. Our combined services will significantly reduce costs and scale up the existing safety capabilities for its visitors.
|
||||
- [Bacalhau Partners with LabDAO to Accelerate Scientific Progress](https://bacalhau.substack.com/p/bacalhau-partners-with-labdao-to): Our goal is to accelerate progress by making scientific tools more accessible - building distributed compute infrastructure is an essential component on the way there. We are excited to be partnering with the Bacalhau team to integrate this piece of the puzzle together.
|
||||
- [Bacalhau Case Studies](https://www.bacalhau.org/casestudies/):
|
||||
- Surface Ocean CO₂ Atlas (SOCAT): [Youtube Demo](https://www.youtube.com/watch?v=t2AHD8yJhLY), [Github](https://github.com/wesfloyd/bacalhau_socat_test)
|
||||
- EUREC4A Cloud Masking: [Github](https://github.com/wesfloyd/how_to_eurec4a)
|
||||
- OpenMM Molecular Simulation: [Github](https://github.com/wesfloyd/openmm-test)
|
||||
|
||||
Based on user feedback, we are introducing a breadth of new features to help people adopt compute over data even faster.
|
||||
|
||||
## Introducing Bacalhau Beta v1
|
||||
|
||||
We are proud to move the Bacalhau API from `alpha` to `beta`. With this change, we are committing to both a more stable API as well as backward compatibility for future versions (`alpha` jobs will not be supported going forward). For most jobs, this will result in no change, but it will require updating the versions of your jobs from `v1alpha1` to `v1beta1`.
|
||||
|
||||
**Note**: This only applies if you are using a JSON or YAML job format - if you are using the CLI, you should be all set.
|
||||
|
||||
Along with this change, we have several additional features that address some big requests:
|
||||
|
||||
- **Improvements to network reliability**: In particular, by switching the way we are using libp2p gossipsub, you should see significantly reduced network latency.
|
||||
- **Native Filecoin support**: via native Lotus integration as well as Estuary integration via an Estuary API key (Estuary publishes results from the network both into IPFS as well as backing them up in Filecoin)
|
||||
- **Support for WebAssembly**: Bacalhau can now deterministically run WASM code either uploaded via the client or stored on IPFS.
|
||||
- **Job pipelines from Apache Airflow**: Jobs can now be chained together via Airflow, Cron scheduling, and more.
|
||||
|
||||
## New Examples
|
||||
|
||||
We also have been running Bacalhau through its paces. Below are just a few of the many examples you can *already run* on Bacalhau against IPFS and/or Filecoin data:
|
||||
|
||||
- [Python - Hello World](https://docs.bacalhau.org/examples/workload-onboarding/trivial-python/)
|
||||
- [R - Hello World](https://docs.bacalhau.org/examples/workload-onboarding/r-hello-world/)
|
||||
- [Rust via WebAssembly](https://docs.bacalhau.org/examples/workload-onboarding/rust-wasm/)
|
||||
- [Python - Pandas](https://docs.bacalhau.org/examples/workload-onboarding/python-pandas/)
|
||||
- [Python - Custom Containers](https://docs.bacalhau.org/examples/workload-onboarding/custom-containers/)
|
||||
- [Image Processing](https://docs.bacalhau.org/examples/data-engineering/image-processing/)
|
||||
- [Parallel Workloads](https://docs.bacalhau.org/examples/data-engineering/simple-parallel-workloads/)
|
||||
- [Blockchain ETL](https://docs.bacalhau.org/examples/data-engineering/blockchain-etl/)
|
||||
- [Oceanography Analysis](https://docs.bacalhau.org/examples/data-engineering/oceanography-conversion/)
|
||||
- Stable Diffusion ([CPU](https://docs.bacalhau.org/examples/model-inference/stable-diffusion-cpu/) and [GPU](https://docs.bacalhau.org/examples/model-inference/stable-diffusion-gpu/))
|
||||
- [Object detection - YOLO](https://docs.bacalhau.org/examples/model-inference/object-detection-yolo5/)
|
||||
- [Speech Recognition with Whisper](https://docs.bacalhau.org/examples/model-inference/Openai-Whisper/)
|
||||
- [Image Generation with StyleGAN](https://docs.bacalhau.org/examples/model-inference/StyleGAN3/)
|
||||
- [Molecular Dynamics - Simulation with OpenMM](https://docs.bacalhau.org/examples/molecular-dynamics/openmm/)
|
||||
|
||||
## Roadmap
|
||||
|
||||
Our goal is to maintain a quarterly release cadence. By the end of the year, we hope to offer the following:
|
||||
|
||||
- Python SDK and SDKs for our API in some other languages too
|
||||
- FIL+ Dashboard
|
||||
- Initial simulator framework
|
||||
- Improved examples
|
||||
- A draft invocation spec in collaboration with the CoD ecosystem
|
||||
- Networking design
|
||||
- Trusted Execution Environment design
|
||||
- An initial game theoretic analysis of the Bacalhau protocol
|
||||
|
||||
## Would you like to learn more? Come help!
|
||||
|
||||
If you would like to learn more about Bacalhau or let us know how you'd like the project to change and help you, visit any of the following:
|
||||
|
||||
- Website: [https://bacalhau.org/](https://bacalhau.org/)
|
||||
- Docs: [https://docs.bacalhau.org/](https://docs.bacalhau.org/)
|
||||
- Mail: [https://groups.google.com/g/bacalhau-discuss](https://groups.google.com/g/bacalhau-discuss)
|
||||
- Slack: [https://filecoin.io/slack](https://filecoin.io/slack) ([#bacalhau](https://filecoin.io/slack) channel)
|
||||
- Github: [https://github.com/filecoin-project/bacalhau](https://github.com/filecoin-project/bacalhau)
|
||||
|
||||
Thank you so much!
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
title: Content Addressed Computing at IPFS Camp 2022
|
||||
description: Check out this recap of the Content Addressed Computing at IPFS Camp
|
||||
2022.
|
||||
author: Warpfork
|
||||
date: 2022-12-01
|
||||
permalink: "/2022-12-01-cod-at-ipfs-camp/"
|
||||
translationKey: ''
|
||||
header_image: "/ipfs-blog-header-cod-track-at-ipfs-camp.png"
|
||||
tags: []
|
||||
|
||||
---
|
||||
In the Compute-Over-Data track at the [2022 IPFS Camp](https://2022.ipfs.camp/), we heard from several projects and lots of people on how the landscape of computing is evolving, and how we believe computing can become refocused and more powerful by embracing content addressing and a “merkle-native” way of doing things. In this post, we’ll do a quick recap of what was covered.
|
||||
|
||||
[Content-addressing](https://proto.school/content-addressing/) and the use of [merkle datastructures](https://en.wikipedia.org/wiki/Merkle_tree) – identifying data by a cryptographic hash – is already a well-known revolution of how data structures can be designed for decentralization, bringing benefits like verifiability, naturally coordination-free data deduplication, and so forth. In examining content-addressed computing, and looking for ways to embrace computing over content-addressed data (sometimes referred to in this community as compute-over-data for short), we look at how we can bring those virtues of verifiability and decentralization to data _processing_ as well as data storage and transport (where content-addressing has already become near-ubitiquous in any modern protocol design), and we look for what new virtues we can discover that are unlocked by giving computations predictable coordination-free identifers.
|
||||
|
||||
A wide range of projects exist in this space! In the videos of the event, you’ll find presentations of projects that are ranging in focus from linux containers and how to unify them with content-addressed storage, all the way to new bytecode VMs which have direct integrations to content-addressed storage and content-addressed code execution primitives. You’ll find approaches to scaling and approaches to user adoption which range from developer-centric build tools, all the way to projects with a focus on massively scaled parallelized compute job scheduling. And you’ll find exploration of virtues of developing systems with computation-addressable primitives, ranging from software security and reproducible builds, to public verifiability, to sheer scaling.
|
||||
|
||||
All of the talks were recorded, and you can also find the full [Compute-Over-Data track playlist](https://www.youtube.com/playlist?list=PLuhRWgmPaHtTU1u9TGOVviM234URBdEGa) on the IPFS YouTube channel.
|
||||
|
||||
Here’s a quick summary of all the talks and their topics:
|
||||
|
||||
* In the keynote: David Aronchik and Wes Floyd introduce us to the potential for revolution in the big data age, and what do we mean by “compute over data”:
|
||||
@[youtube](7XczBBxYTB4)
|
||||
* In “Warpforge — Hashes go in, hashes come out, exec in the middle!”, Eric Evenchick and Eric Myhre introduce Warpforge, a tool for declarative computation and software build pipelines, as well as demonstrate new data structures (in IPLD!) to describe decentralized package management – emphasizing how to collaborate, without enforced central coordination.
|
||||
@[youtube](wcOjT580iaI)
|
||||
* In “Bacalhau — Bringing the Compute to the Data!”, David Aronchick tells the story of the Bacalhau project, its origin, motivations, and progress so far, as well as demos of using it to run distributed compute jobs.
|
||||
@[youtube](Xj3n0uvQSCM)
|
||||
* In “FVM – The (EVM-Compatible!) Filecoin Virtual Machine”, Matt Hamilton shows a new computing environment called the FEVM, which hosts Ethereum-compatible smart-contracts on-chain in Filecoin. This allows smart contracts that integrate with the state storage mechanisms of Filecoin. Applications of this could include automatic storage deal renegociation, among other ideas. Live demos are included!
|
||||
@[youtube](tLJ-ys2G8tU)
|
||||
* In “Zapps — A new standard for go-anywhere linux executables”, Eric Myhre dives into how to ship software on linux, and demonstrates a new way to do it in a drag-and-drop way, with truly minimal system dependencies, and _without_ resorting to containers.
|
||||
@[youtube](Q33LgKAwpZU)
|
||||
|
||||
Tons of questions were asked and answered throughout these talks:
|
||||
|
||||
* Verification of compute in decentralized systems: how can we do it?
|
||||
* Deterministic computation: how does it relate to verification? And is it prevalent in the wild?
|
||||
* What are the interventions we can make if deterministic computation _isn’t_ prevalent in the wild, and we want to make it so, as a community?
|
||||
* How do markets relate to these systems? Can we make decentralized markets for data as well as the _processing_ over that data?
|
||||
* How can we make it easier for people to get started in building new decentralized software?
|
||||
* How do we get software in the hands of end-users with less fuss? How do we make software packages easier to compose, so more people can join us more easily in building data pipelines?
|
||||
* How can we label, annotate, and share references to data, without central coordination? Hash-based identifiers are a given – where do we go from there?
|
||||
|
||||
… and okay, some of these questions are just asked; not all of these questions are _answered_. ;) Some of them are hard questions; some have multiple answers! And for the hard problems remaining, if you want to contribute in some way, you can find more information on getting in touch below. All of these projects are looking for both users and contributors.
|
||||
|
||||
The summaries above hopefully pique your interest – if so, _watch the videos_! Almost every one of these presentations included _live demos_, which are very cool, and hard to summarize in text ;)
|
||||
|
||||
## Getting in touch
|
||||
|
||||
If you’re looking for followup contacts for these groups:
|
||||
|
||||
* There’s a CoD working group representing **lots** of different projects – not just these that spoke at IPFSCamp, but many more too (and it can be a place to represent yours, as well!) – check out [cod.cloud](https://www.cod.cloud/) and the [`#compute-over-data-wg` channel on Filecoin Slack](https://filecoinproject.slack.com/archives/C03MCV5U77C).
|
||||
* More info about Bacalhau can be found [bacalhau.org](https://www.bacalhau.org/), and you can get in touch with them in the [`#bacalhau` channel on Filecoin Slack](https://filecoinproject.slack.com/archives/C02RLM3JHUY)!
|
||||
* More info about Warpforge can be found at [warpforge.io](http://warpforge.io/), and you can get in touch with them in the [`#warpforge` channel in Matrix](https://matrix.to/#/#warpforge:matrix.org) or see the project’s [Community](https://warpforge.notion.site/Community-676332742afa4276be571f7d035d55db) page for more links.
|
||||
* More info about the FVM Project can be found starting at [docs.filecoin.io/fvm](https://docs.filecoin.io/fvm/basics/introduction/), and you can get in touch with them in the [`#FVM` channel on Filecoin Slack](https://filecoinproject.slack.com/archives/C029MT4PQB1)!
|
||||
* More info about the Zapp packaging format can be found at [https://zapps.app/](https://zapps.app/ "https://zapps.app/") .
|
||||
|
||||
For more information about the IPFS Camp 2022 overall, the event info can be found on the [IPFS Camp site](https://2022.ipfs.camp/). More information about the other tracks can be found grouped by [this tag](https://blog.ipfs.tech/?tags=ipfs-camp).
|
||||
@@ -1,14 +0,0 @@
|
||||
---
|
||||
title: Ecosystem content
|
||||
type: Ecosystem content
|
||||
sitemap:
|
||||
exclude: true
|
||||
data:
|
||||
- title: 'libp2p at IPFS þing 2023 Recap'
|
||||
date: 2023-05-11
|
||||
publish_date:
|
||||
card_image: /blog-post-placeholder.png
|
||||
path: https://blog.libp2p.io/2023-libp2p-IPFS-Thing-recap/
|
||||
tags:
|
||||
- libp2p
|
||||
---
|
||||
@@ -1,68 +0,0 @@
|
||||
---
|
||||
title: Guardian - IPFS & Hedera
|
||||
description: Guardian uses Hedera & IPFS to create provenance chains for ESG (Environmental,
|
||||
Social, and Governance) assets
|
||||
author: Marc Johnson, Protocol Labs & Paul Madsen, The HBAR Foundation
|
||||
date: 2022-11-10
|
||||
permalink: "/2022-11-10-guardian-ipfs-and-hedera/"
|
||||
translationKey: ''
|
||||
header_image: "/ipfs-blog-header_-ipfs-__-hedera-blog-post-header.png"
|
||||
tags:
|
||||
- NFTs
|
||||
- CID
|
||||
|
||||
---
|
||||
[Guardian](https://hedera.com/blog/guardian-v2-0-the-next-generation-of-esg-marketplaces-built-on-hedera) is a policy engine that links together tokenized digital environmental assets like carbon offsets, emissions, & RECs (Renewable Energy Certificates) to the physical reporting data that justifies their creation.
|
||||
|
||||
Guardian uses Hedera & IPFS to create provenance chains for ESG (Environmental, Social, and Governance) assets - specifically:
|
||||
|
||||
1. IPFS for decentralized storage of provenance chain artifacts
|
||||
2. Hedera Consensus Service (HCS) to create an immutable & trusted history of all artifacts stored on IPFS
|
||||
3. Hedera Token Service (HTS) to create either fungible or non-fungible tokens corresponding to the MRV data
|
||||
|
||||
When the tokens minted via Guardian are transferred to exchanges, prospective buyers can work backwards from the token to the corresponding The Measurement, Reporting & Verification (MRV) data that records the sustainability asset and be confident of that provenance - specifically the integrity of processes and identities of all parties that are involved in the ‘chain’ of events.
|
||||
|
||||
Guardian uses the W3C standards of Decentralized Identifiers (DIDs), Verifiable Credentials (VCs) and Verifiable Presentations (VPs) in order to capture the digitally signed documents that are stored on IPFS. Guardian uses VCs for a variety of data types - particularly:
|
||||
|
||||
* MRV data capturing the actual carbon reduction, removals or renewable energy generation.
|
||||
* The policies that digitize the methodology. In this context of carbon debits & credits, a methodology is a framework document that defines the rules governing the MRV and the criteria for minting tokens corresponding to that MRV.
|
||||
|
||||
## Example
|
||||
|
||||
Consider a solar farm that creates renewable energy through photovoltaic panels. The owners of the farm wish to sell Renewable Energy Credits (RECs) representing the electricity generated by their panels. They will use Guardian to ensure that those RECs are auditable, discoverable and liquid.
|
||||
|
||||
Guardian will allow the solar farm owners to provide their business information and to describe the farm. This information is fundamental to trusting the RECs that will eventually be issued to represent the farm's electrical output - a farm in sunny Australia will have different annual output than one in cloudy Ireland. This project information will be captured in a digitally signed VC and the corresponding VP stored on IPFS. Guardian will also send an HCS message recording the CID of the file on IPFS to the Hedera network - this first HCS message effectively recording into history the establishment of the solar farm and its information.
|
||||
|
||||
Check out this [example](https://ipfs.io/ipfs/bafkreih6c5pa2u772k45c22e5hyscmv2eao4ntbvmhxym4pve7xevxv4qq) of such a VC recording the geolocation of a USA-based REC project stored on IPFS:
|
||||
|
||||
The proof at the bottom of the VC contains the digital signature of the Issuer of this VC. To verify this signature the public key of this Issuer can be retrieved by resolving the corresponding DID into its DID Document - this is also stored on IPFS.
|
||||
|
||||
If an accredited inspector visits the farm in order to verify the authenticity of the claims made by the owners, e.g. that the farm does indeed have the claimed number of panels and is indeed in sunny Australia, then the subsequent approval will also be captured as a VC and stored on IPFS - once again with a corresponding HCS message adding that approval to the provenance chain.
|
||||
|
||||
For privacy reasons, it may not be appropriate for the inspector’s own details such as their name to be publicly displayed on IPFS, it will be possible for such to only be visible to suitably authorized viewers of the provenance chain, perhaps a government auditor or similar.
|
||||
|
||||
Once the panels are turned on, the kWH of green electricity they start to generate will similarly be recorded - the MRV data captured as a VC, the VP stored on IPFS, and an HCS message sent to stamp these events into history.
|
||||
|
||||
When the solar panels generate 1 mWH of electricity, Guardian will mint a non-fungible token to represent that power. This rule, i.e. that a REC represents 1 mWH of electricity, is encoded in the policy that governs this Guardian instance.
|
||||
|
||||
With this REC now minted, a buyer will be able to work backwards through the provenance chain - this sequence described below:
|
||||
|
||||
1. Begin at the REC token instance
|
||||
2. Confirm the token identifier is appropriate for this Guardian
|
||||
3. Find tx that minted the NFT. For this mint to be valid, it must be provably linked to MRV data that records the generation of 1 MwH of renewable electricity.
|
||||
4. Examine mint tx memo - value is an HCS tx timestamp
|
||||
5. Query mirror for the HCS message tx - it represents the creation and logging of an VP(VC(MRV))
|
||||
6. Confirm the topic identifier is valid for this Guardian
|
||||
7. Examine message contents, grab URL param - it is an IPFS CID
|
||||
8. Resolve CID to retrieve VP(VC(MRV)) - discoverable on [CO2.Storage](https://co2.storage/) and [IPFS Explorer](https://explore.ipld.io/)
|
||||
9. Examine VP(VC(MRV),
|
||||
1. Confirm it maps to the appropriate tokenID
|
||||
2. Verify signatures, retrieve DIDs as necessary
|
||||
3. Confirm the MRV data meets the criteria of the policy
|
||||
10. If the token passes the above checks, purchase
|
||||
|
||||
Once the purchaser has the REC in their own Hedera account, it could be used to offset other tokens representing the purchaser's carbon emissions. These emissions tokens, if created via Guardian, would have their own provenance chain.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Guardian uses Hedera & IPFS to create provenance chains for ESG assets - making tokenized sustainability assets like RECs trusted and discoverable. IPFS provides decentralized storage for the artifacts that make up the provenance chains and Hedera allows for a decentralized audit trail and tokenization layer. Guardian is using IPFS & Hedera together to bring the balance sheet of the planet to a public ledger.
|
||||
@@ -1,287 +0,0 @@
|
||||
---
|
||||
title: 'InterPlanetary Applications: Disco Chat'
|
||||
description: 'Check out Disco Chat, a peer-to-peer chat application built to demonstrate the power of peer-to-peer while enabling other developers to do the same.'
|
||||
author: Discordian
|
||||
date: 2023-01-30
|
||||
permalink: '/interplanetary-apps-disco-chat/'
|
||||
header_image: '/interplanetary-apps-cover.png'
|
||||
tags:
|
||||
- 'ipfs'
|
||||
- 'tutorial'
|
||||
---
|
||||
<style>
|
||||
.type-rich li + li {
|
||||
margin-top:0em;
|
||||
}
|
||||
.type-rich h3 {
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
.type-rich h4 {
|
||||
font-weight: bold;
|
||||
}
|
||||
.type-rich li > ul {
|
||||
padding-top:0;
|
||||
}
|
||||
</style>
|
||||
|
||||
|
||||
<span style="position:relative;top:-1em;">*Disco Chat is a peer-to-peer chat application built using Tauri, JavaScript, and HTML.*</span>
|
||||
|
||||
### Table of Contents
|
||||
|
||||
- [What is Disco Chat?](#what-is-disco-chat)
|
||||
- [Disco Chat's Journey](#disco-chat-s-journey)
|
||||
- [Disco Chat Today](#disco-chat-today)
|
||||
- [Disco Chat's Features](#disco-chat-s-features)
|
||||
- [How Disco Chat Uses IPNS for Mutable Profiles](#how-disco-chat-uses-ipns-for-mutable-profiles)
|
||||
- [IPNS Profiles Technical Breakdown](#ipns-profiles-technical-breakdown)
|
||||
- [How Disco Chat Implements End-to-End Encryption](#how-disco-chat-implements-end-to-end-encryption)
|
||||
- [End-to-End Encryption Technical Breakdown](#end-to-end-encryption-technical-breakdown)
|
||||
- [Wrapping Up](#wrapping-up)
|
||||
- [Links](#links)
|
||||
|
||||
|
||||
In this post we'll go over what Disco Chat is, and the journey of how and why Disco Chat was built. I'll also highlight some of the challenges that were encountered along the way. Having some familiarity with web development will be handy for following along with the technical sections. There's also a Rust component of the application too, but knowledge of Rust isn't necessary to follow along.
|
||||
|
||||
|
||||
## What is Disco Chat?
|
||||
|
||||
**Disco Chat** is a fun, easy-to-use peer-to-peer chat application sporting custom profiles, end-to-end encryption, offline chat sync, and more! It's meant to help show developers how to build applications like it. If you'd like to join in the fun (even if you're not very technical), head over to the [Disco Chat Releases](https://github.com/TheDiscordian/disco-chat/releases) page to grab a binary.
|
||||
|
||||
At it's core Disco Chat uses IPFS & libp2p, powered by a [Kubo](https://github.com/ipfs/kubo) node. It's **written in mostly JavaScript** with the **interface in HTML/CSS** to hopefully make it easy-to-use for most developers today. There's also a **Rust component from [Tauri](https://tauri.app/)** which allows us to have a thin browser to work with on the desktop (and mobile in the future!), **giving us the full power of Kubo**, JavaScript, HTML, and CSS in a single application.
|
||||
|
||||
Disco Chat is based upon [native-ipfs-building-blox](https://github.com/TheDiscordian/native-ipfs-building-blox), which is a great kit for getting started on building desktop IPFS applications using HTML/Javascript (Rust too if you like). If you're looking at taking some code snippets from Disco Chat for a totally different idea, **I highly recommend using native-ipfs-building-blox as a base**.
|
||||
|
||||
### Disco Chat's Journey
|
||||
|
||||
Disco Chat had its **beginnings as a truely minimal in-browser chat application**. You could set a nickname and write messages into a public channel, the backend could support multiple "rooms" but the frontend could not. This application exists today as the write-up [Create a Simple Chat Application](https://docs.ipfs.tech/how-to/create-simple-chat-app/) and a video titled [IPFS: Browser Connectivity Walkthrough](https://www.youtube.com/watch?v=xZiN9dLvMoU). Its goal, similar to Disco Chat, was to provide developers with the scaffolding they'd need to build an in-browser chat application, or whatever else they could dream up.
|
||||
|
||||
From there Disco Chat was born! After building the framework I thought it'd be fun to make my own chat application and see what struggles are involved with it. At this point Disco Chat still worked in a browser, complete with multiple-rooms, markdown, image sharing, video sharing, emojis, multi-line text, and more! It was **exciting opening up a web page that instantly connects you to a serverless chatroom** with other peers.
|
||||
|
||||
Disco Chat, and the original chat example relied on [CircuitRelayV1](https://github.com/libp2p/specs/blob/master/relay/circuit-v1.md) and [libp2p-webrtc-star](https://github.com/libp2p/js-libp2p-webrtc-star). Unfortunately these days it's **much harder to achieve relaying in a browser** with the deprecation of CirvuitRelayV1 in Kubo. On top of this, the **browser environments practically strangle most p2p techniques** making things like hole-punching very hard. That was already enough to convince me to persue other avenues, but now libp2p-webrtc-star is also deprecated in favour of an [upcoming libp2p WebRTC browser-to-browser specification](https://github.com/libp2p/specs/pull/497). So continuing on the browser wasn't really feasible for the time being.
|
||||
|
||||
One day I'd love to see the browser version return, but for now we can continue work in a pseudo-browser environment so **porting it back to browser should be relatively straight-forward**.
|
||||
|
||||
### Disco Chat Today
|
||||
|
||||
I **wanted to keep Disco Chat in the browser** as it's easy to create graphical applications that work cross-platform, not to mention the current popularity of Javascript. First I looked at Electron, but I'm haunted by many complaints developers and users have about the behemoth (not to mention it's quite large). After some searching I **found Tauri, a very thin/lightweight browser view** tied together with Rust.
|
||||
|
||||
From there I **created [native-ipfs-building-blox](https://github.com/TheDiscordian/native-ipfs-building-blox)** to assist in creating desktop applications with a webview powered by a Kubo node in the background. The API on the Javascript side is exactly the same, but by using [kubp-rpc-client](https://github.com/ipfs/js-kubo-rpc-client) it's **Kubo handling all the heavy lifting** like running the IPFS node instead of js-ipfs. This **gives us a lot of powers like advanced hole punching techniques** using CircuitRelayV2 and being able to listen on a socket in general.
|
||||
|
||||
After this I **just dropped the browser-based Disco Chat into the [ui directory](https://github.com/TheDiscordian/disco-chat/tree/master/ui) with some tweaks**. The browser version of Disco Chat used js-ipfs in the browser which was no longer needed in the new Disco Chat which uses Kubo and Kubo RPC API. After this, I cleaned up that ui directory, added a boatload of comments, and implemented IPNS-based profiles and end-to-end encryption.
|
||||
|
||||
## Disco Chat's Features
|
||||
|
||||
Disco Chat has many features, all of which operate peer-to-peer, some notable ones:
|
||||
|
||||
- Chat rooms (not encrypted)
|
||||
- Encrypted direct messages
|
||||
- Emojis
|
||||
- Markdown
|
||||
- Image sharing
|
||||
- Video sharing
|
||||
|
||||
And these are cool, but nothing that stands out as special in the web3 space (except maybe serverless & chainless chat rooms). To make Disco Chat stand out with some useful features other devs could learn from I did some brainstorming and reading with the community and my fellow teammates. I concluded many **devs get hung up on at least these two things** in a distributed and chainless/consensusless environment:
|
||||
|
||||
1. **How to have mutable data beyond just a website / redirect**
|
||||
2. **How to encrypt or hide data**
|
||||
|
||||
So to assist with those problems, I created **IPNS-based profiles** for Disco Chat - to show off mutable data, and a **simple end-to-end encryption** feature - to show the basics of how to hide or encrypt data over IPFS (or any public room). This was made possible as each IPFS node has a unique identifier known as a PeerID which is generated via a keypair. I utilise the PeerID as the IPNS name for profile lookups, and the keypair to generate a secret used for data encryption.
|
||||
|
||||
### How Disco Chat Uses IPNS for Mutable Profiles
|
||||
|
||||
Previously, in the chat example a user's nickname was sent over with each message send. As it evolved into Disco Chat, a CID linking to a profile picture was also sent over with each message. Now, the **profile information isn't sent over at all**! Instead a CID of the profile info itself is published via [IPNS](https://docs.ipfs.tech/concepts/ipns/) using the user's PeerID (also known as their `self` key!). This means if a peer user wants to look another peer up, they already know the peer's PeerID thanks to libp2p, so they **only need to do an IPNS lookup on it to retrieve the profile info as needed / desired**.
|
||||
|
||||
#### IPNS Profiles Technical Breakdown
|
||||
|
||||
The meat of the IPNS Profiles code lives in [ui/peers/ipns.js](https://github.com/TheDiscordian/disco-chat/blob/master/ui/peers/ipns.js), here's a *slightly* modified example, which might be **easier to snatch up as a snippet:**
|
||||
|
||||
```js
|
||||
// fetchPeerInfo will try to resolve a PeerID over IPNS to get their profile information, returning it as an object
|
||||
async function fetchPeerInfo(ipfs, id, timeout) {
|
||||
if (timeout == undefined) {
|
||||
timeout = 5000;
|
||||
}
|
||||
let peer = undefined;
|
||||
for await (const name of ipfs.name.resolve(id, {timeout: timeout})) {
|
||||
peer = name;
|
||||
}
|
||||
if (peer == undefined) {
|
||||
return;
|
||||
}
|
||||
const content = [];
|
||||
try {
|
||||
for await (const chunk of ipfs.cat(peer, {timeout: timeout, length: 1024})) {
|
||||
content.push(chunk);
|
||||
}
|
||||
} catch {
|
||||
return;
|
||||
}
|
||||
if (content.length == 0) {
|
||||
return;
|
||||
}
|
||||
try {
|
||||
peer = JSON.parse(new TextDecoder().decode(content[0]));
|
||||
} catch {
|
||||
return;
|
||||
}
|
||||
return peer;
|
||||
}
|
||||
|
||||
// publishProfile publishes our profile information to IPNS
|
||||
async function publishProfile(ipfs, currentNick, currentImg) {
|
||||
let cid = await ipfs.add(JSON.stringify({nick: currentNick, img: currentImg}));
|
||||
await ipfs.name.publish(cid.cid);
|
||||
}
|
||||
```
|
||||
|
||||
We have two functions here: `publishProfile` and `fetchPeerInfo`.
|
||||
|
||||
**publishProfile** is what publishes your profile info to IPNS. It takes three arguments:
|
||||
- `ipfs` - an [IPFS core API](https://github.com/ipfs/js-ipfs/tree/master/docs/core-api) compatible object
|
||||
- `currentNick` - a string representing the peer's nickname
|
||||
- `currentImg` - a string CID representing the peer's avatar
|
||||
|
||||
**fetchPeerInfo** will fetch another peer's profile information, parse the JSON, and return an object (returning `undefined` upon error). It takes three arguments:
|
||||
- `ipfs` - an [IPFS core API](https://github.com/ipfs/js-ipfs/tree/master/docs/core-api) compatible object
|
||||
- `id` - a string representing the peer's PeerID
|
||||
- `timeout` (*optional*) - an integer representing the time to wait while searching for the profile in milliseconds
|
||||
|
||||
I hope the usage is straight-forward, here's an example:
|
||||
|
||||
```js
|
||||
// Connect to a local Kubo node
|
||||
var ipfs = await IpfsHttpClient.create();
|
||||
// Retrieve our PeerID as a string, and output it to console
|
||||
var me = await ipfs.id().then(id => id.id.toString());
|
||||
console.log(me);
|
||||
|
||||
// Publish our profile with the nickname "Example_Nickname"
|
||||
// and picture "Qmcm32sVsMYhURY3gqH7vSQ76492t5Rfxb3vsWCb35gVme"
|
||||
await publishProfile(ipfs, "Example_Nickname", "Qmcm32sVsMYhURY3gqH7vSQ76492t5Rfxb3vsWCb35gVme");
|
||||
|
||||
// Retrieve our own profile info
|
||||
let peerInfo = await fetchPeerInfo(ipfs, me);
|
||||
// Output our profile info as JSON to console
|
||||
console.log("Got peer info: " + JSON.stringify(peerInfo));
|
||||
```
|
||||
|
||||
### How Disco Chat Implements End-to-End Encryption
|
||||
|
||||
I often see questions along the lines of "How do I hide the data in a CID?" or sometimes "How do I encrypt the data before I add it to IPFS?". For Disco Chat I implemented **one simple scheme** anyone can use. It will **encrypt any data you want** for a specific peer. This ensures you and the peer you're communicating with are the only two people who can decrypt the data.
|
||||
|
||||
#### End-to-End Encryption Technical Breakdown
|
||||
|
||||
<div style="border-left:4px solid #e7c000;border-color:#e7c000;padding:1rem 1.5rem;margin:1rem 0;background-color:#fff7d2">
|
||||
I highly recommend studying the <span style="font-weight:bold;">security implications</span> of using encryption in the wild or seeking consulting on the subject before using a specific scheme.
|
||||
</div>
|
||||
|
||||
Disco Chat's encryption example lives in [ui/crypto.js](https://github.com/TheDiscordian/disco-chat/blob/master/ui/crypto.js). You'll need these libraries to get started:
|
||||
- [noble-ed25519](https://www.npmjs.com/package/@noble/ed25519) - to work with ed25519 keys
|
||||
- [aes-js](https://www.npmjs.com/package/aes-js) - to handle symmetric encryption
|
||||
- [bs58](https://www.npmjs.com/package/bs58) - to decode PeerIDs
|
||||
|
||||
To decrypt a message all a reciever needs is the nonce used to generate the encrypted message, and the encrypted message itself. Here's a code snippet:
|
||||
|
||||
```js
|
||||
// decryptMsg is called by the receiver to decrypt the message. It takes the
|
||||
// encrypted message (msg), the sender's public key (from), and the unique
|
||||
// nonce used to encrypt the message (n). If this message is from ourselves
|
||||
// (me), it will use the `to` key to decrypt it.
|
||||
//
|
||||
// _priv_key is the private key to our PeerID.
|
||||
//
|
||||
// This function can only decrypt messages meant for us, or messages sent by
|
||||
// us.
|
||||
async function decryptMsg(msg, n, from, to, me, _priv_key) {
|
||||
let other_pub = null;
|
||||
if (from != me) {
|
||||
other_pub = bs58.decode(from).subarray(6);
|
||||
} else {
|
||||
other_pub = bs58.decode(to).subarray(6);
|
||||
}
|
||||
let secret = await nobleEd25519.getSharedSecret(_priv_key, other_pub);
|
||||
let encryptedBytes = aesjs.utils.hex.toBytes(msg);
|
||||
let aesCtr = new aesjs.ModeOfOperation.ctr(secret, new aesjs.Counter(parseInt(n)));
|
||||
return aesjs.utils.utf8.fromBytes(aesCtr.decrypt(encryptedBytes));
|
||||
}
|
||||
|
||||
// encryptMsg is called by the sender to encrypt a message. It takes the
|
||||
// message (msg) and the receiver's public key (to). It returns a list
|
||||
// containing the unique nonce and the encrypted message.
|
||||
//
|
||||
// _priv_key is the private key to our PeerID.
|
||||
async function encryptMsg(msg, to, _priv_key) {
|
||||
let other_pub = bs58.decode(to).subarray(6);
|
||||
let secret = await nobleEd25519.getSharedSecret(_priv_key, other_pub);
|
||||
let uniqueN = window.crypto.getRandomValues(new Uint16Array(1))[0];
|
||||
let aesCtr = new aesjs.ModeOfOperation.ctr(secret, new aesjs.Counter(uniqueN));
|
||||
let encryptedBytes = aesCtr.encrypt(aesjs.utils.utf8.toBytes(msg));
|
||||
return [encryptedBytes, uniqueN];
|
||||
}
|
||||
```
|
||||
|
||||
**decryptMsg** decrypts the encrypted message fed to it. It takes six arguments:
|
||||
- `msg` - a string of the encrypted message to decrypt
|
||||
- `n` - an integer representing the nonce used to encrypt the message
|
||||
- `from` - a string CID representing the sender's PeerID
|
||||
- `to` - a string CID representing the reciever's PeerID
|
||||
- `me` - a string CID representing our own PeerID
|
||||
- `_priv_key` - the private key of our own PeerID
|
||||
|
||||
It returns a string of the decrypted message.
|
||||
|
||||
**encryptMsg** encrypts the message fed to it. It takes three arguments:
|
||||
- `msg` - a string to encrypt
|
||||
- `to` - a string CID representing the reciever's PeerID
|
||||
- `_priv_key` - the private key of our own PeerID
|
||||
|
||||
It returns a list containing [encrypted data, nonce]. Both the encrypted data and the nonce will be needed the decrypt the message.
|
||||
|
||||
It's important to note that **these functions generate the secret every single time**. This is a moderately heavy operation, which technically only needs to be done once per peer. So if you're looking for performance, you should be caching secrets. This is left as an exercise for the reader 🙂.
|
||||
|
||||
The biggest challenge to using these functions will likely be in **retrieving your node's private key**. For Kubo, this is stored by default in your config file (`~/.ipfs/config`) and needs to be decoded. In Disco Chat, this is done on the Rust side in [src/main.rs](https://github.com/TheDiscordian/disco-chat/blob/master/src/main.rs#L66). The **[native-ipfs-building-blox](https://github.com/TheDiscordian/native-ipfs-building-blox) scaffolding has the Rust side of this built-in**, and just needs to be exposed on the JavaScript side:
|
||||
|
||||
```js
|
||||
// Connect to a local Kubo node
|
||||
var ipfs = await IpfsHttpClient.create();
|
||||
// Retrieve our PeerID as a string, and output it to console
|
||||
var me = await ipfs.id().then(id => id.id.toString());
|
||||
console.log(me);
|
||||
// A different PeerID for example purposes
|
||||
var notMe = "12D3KooWQLS5bagAnf43kSdf5Nd9yiMW2sBksL43q94nduXzpdpV";
|
||||
|
||||
// retrieve our private key
|
||||
let priv = await __TAURI__.invoke('get_priv_key');
|
||||
// convert our key into something nobleEd25519 likes
|
||||
var _priv_key = Uint8Array.from(atob(priv), c => c.charCodeAt(0));
|
||||
|
||||
// run encryptMsg to get the encryptedMessage and nonce
|
||||
let [encryptedMessage, nonce] = await encryptMsg("hello world", notMe, _priv_key);
|
||||
// we set "from" to "me" because the message is from us
|
||||
let decryptedMessage = await decryptMsg(aesjs.utils.hex.fromBytes(encryptedMessage), nonce, me, notMe, me, _priv_key);
|
||||
|
||||
console.log(decryptedMessage); // "hello world"
|
||||
```
|
||||
|
||||
## Wrapping Up
|
||||
|
||||
Today Disco Chat is one of the best examples to help get developers started building peer-to-peer applications with distributed profiles and encrypted data. It's also a fully-featured chat application that anyone can use. Below I have a couple buttons to grab your own copy of Disco Chat, as well as some links to learn more about libp2p and IPFS. Let's all build and use the future of the web together, today.
|
||||
|
||||
<br>
|
||||
|
||||
<a href="https://github.com/TheDiscordian/disco-chat/releases" class="cta-button">
|
||||
Download DiscoChat
|
||||
</a>
|
||||
<a href="https://github.com/TheDiscordian/disco-chat" class="cta-button">
|
||||
Explore the code on GitHub
|
||||
</a>
|
||||
|
||||
## Links
|
||||
|
||||
- [TheDiscordian/disco-chat: A peer-to-peer messaging app | Github](https://github.com/TheDiscordian/disco-chat)
|
||||
- [TheDiscordian/native-ipfs-building-blox: Create native IPFS powered desktop applications by using HTML/CSS/JS | Github](https://github.com/TheDiscordian/native-ipfs-building-blox)
|
||||
- [Create a simple chat app | IPFS Docs](https://docs.ipfs.tech/how-to/create-simple-chat-app/)
|
||||
- [IPFS: Browser Connectivity Walkthrough (2021) | YouTube](https://www.youtube.com/watch?v=xZiN9dLvMoU)
|
||||
- [Getting Started With IPFS & Filecoin](https://protocollabs.notion.site/Getting-started-with-IPFS-Filecoin-173c73d4d8d64765a42058594bc46bb7)
|
||||
@@ -1,128 +0,0 @@
|
||||
---
|
||||
title: IPFS Camp 2022 Recap
|
||||
description: After a 3 yr hiatus, the IPFS community came together again for IPFS
|
||||
Camp 2022.
|
||||
author: Crystal Mills
|
||||
date: 2022-11-22
|
||||
permalink: "/2022-11-22-ipfs-camp-22-recap/"
|
||||
translationKey: ''
|
||||
header_image: "/ipfs-blog-header_-ipfs-camp-recap.png"
|
||||
tags:
|
||||
- IPFS Camp
|
||||
|
||||
---
|
||||
After a three-year hiatus, the IPFS community came together again for [IPFS Camp 2022](https://2022.ipfs.camp/) from October 28th-30th in Lisbon, Portugal. The 3-day event was a showcase of recent achievements, a celebration of the growing community, and an opportunity to chart new directions for the future of IPFS.
|
||||
|
||||
Over 550 attendees joined for a collection of talks, workshops, discussion circles, hacking time, and dinners. Here are just a few highlights of the over 100 sessions from the 3-day Camp. You can also watch all of the talks on the [IPFS YouTube channel](https://www.youtube.com/c/IPFSbot).
|
||||
|
||||
## The State of the IPFS Ecosystem
|
||||
|
||||
|
||||
|
||||
Much has changed since the IPFS Camp in 2019. Molly Mackinlay, Product and Engineering Lead at Protocol Labs, shared her reflections in her talk, ["The State of the IPFS Ecosystem"](https://www.youtube.com/watch?v=fGwhPLik3_4&t=2s).
|
||||
|
||||
Active monthly users of [IPFS-based dapps and tools](https://ecosystem.ipfs.tech/) has grown from 5 million to 50 million. The number of unique nodes continues to grow, making the network more resilient and distributed, and content more available. Meanwhile, performance is improving even as the network grows: it’s now 50x faster to find content across the network.
|
||||
|
||||
“We are now seeing 400 millisecond find times in IPFS at the 95th percentile,” Mackinlay said. “This is really thanks to all of the groups that went and rewrote the IPFS and libp2p DHT implementation… We improved the set of nodes that route data in IPFS. There was a massive amount of work that went into making that the case.”
|
||||
|
||||
IPFS as a protocol is maturing as well: it’s now supported in 5 browsers, natively or via extension: Brave, Opera, Chromium, Edge, and Firefox. And the recently revamped InterPlanetary Improvement Proposal (IPIP) process offers an open, lightweight process for IPFS protocol improvements with 17 IPIPs submitted since its introduction in July 2022.
|
||||
|
||||
@[youtube](fGwhPLik3_4)
|
||||
|
||||
## IPFS Implementations and Funding
|
||||
|
||||
__
|
||||
|
||||
It’s time to accelerate the IPFS ecosystem, and we’re excited to invest in making IPFS available everywhere! At IPFS Camp, Juan Benet, Michelle Lee, and Dietrich Ayala announced the new IPFS Implementations Fund. This fund will focus on a 5-year strategy to improve availability and developer choice for IPFS.
|
||||
|
||||
“Many IPFS startups have managed to build companies through finding a good VC pathway,” said Juan Benet, IPFS inventor and founder of Protocol Labs. “We wanted to find a way to equally support significantly sized teams working on IPFS implementations as public goods that will be delivered to the whole community.”
|
||||
|
||||
“The scope initially is going to be implementations \[and integrations\] of the protocol into spaces and environments where it’s not today,” said Dietrich Ayala, Ecosystem Lead, Browsers and Platforms at Protocol Labs. “We want many different groups to address a broad spectrum of programming languages, business verticals and diverse runtimes,” added Michelle Lee, Head of Developer Programs at Protocol Labs. “This might include designing for unique operating environments, compatibility with cloud-native tooling or fast-growing technologies such as WASM, or plugins and SDKs for popular.”
|
||||
|
||||
Additional information and how to apply will be released later in 2022.
|
||||
|
||||
@[youtube](dBnmUiKc3P0)
|
||||
|
||||
## Decentralization and Human Rights
|
||||
|
||||
In a main stage panel, three speakers from three different continents described how they have been using IPFS for digital preservation and censorship resistance.
|
||||
|
||||
**The Starling Lab**
|
||||
|
||||
Jonathan Dotan, Founding Director of The Starling Lab, spoke about how the academic research lab is using the latest cryptographic methods and decentralized web protocols to “meet the technical and ethical challenges of establishing trust” in humanity’s digital records. This includes sensitive records that involve the documentation of human rights violations, testimony of genocide, and war crimes. Projects include the Visual History Archive, which introduced tamper proof distributed storage of the largest collection of testimony from survivors of genocide, as well as 78 Days, a [case study](https://www.starlinglab.org/78days/) that documented the presidential transition from Donald Trump to Joe Biden.
|
||||
|
||||
“The Starling Lab was an early entrant into the \[Protocol Labs\] ecosystem because we got really excited about IPFS,” Dotan said. The Starling Lab creates research opportunities for journalists, historians, and lawyers by welcoming them into Web3. By utilizing IPFS, The Starling Lab can help implement tools to combat misinformation, whether accidental or intentional, by tracking “the provenance of digital content through the use of open source tools, best practices, and case studies designed to help reduce information uncertainty.”
|
||||
|
||||
@[youtube](0gbMYNEIVZ8)
|
||||
|
||||
**Not your key, not your content**
|
||||
|
||||
Phoebe Poon, Co-Founder of LikeCoin and Liker Land, spoke about her team's [decentralized publishing infrastructure](https://docs.ipfs.tech/concepts/case-study-likecoin/#ipfs-benefits) as well as tools for independent media. Their work is motivated by the “social context and political landscape in Hong Kong”, where pro-democratic media experience heavy censorship.
|
||||
|
||||
Over 8,000 journalists use Likecoin's IPFS-based publishing tools to ensure content distribution and maintain journalistic integrity.
|
||||
|
||||
**Censorship in Catalonia**
|
||||
|
||||
Xavi Vives, researcher at Interplanetary Mind Map, shared his experience using IPFS to prevent censorship in Catalonia. On October 1, 2017, Catalan citizens pushed for a vote to separate from Spain, and encountered violence and censorship in response.
|
||||
|
||||
“IPFS had a pretty significant role because the site where the people had to check their data for how and when to vote was a static site and was mirrored on IPFS,” Vives said. “So for several days, while the state was shutting down site after site, people were spinning up new nodes.”
|
||||
|
||||
Eventually, citizens couldn’t even access IPFS gateways, and because of this, Vives and others began working on a decentralized voting system called Vocdoni. However, they were building beneath the fear and paranoia of exposure, and spent two years working on the protocol in secret. Because of this, they couldn’t find financing, hire employees, or build a community. To this day, Vocdoni is still under investigation, and has struggled beneath news defamation and conspiracy theories.
|
||||
|
||||
Vives added, “The enemy of decentralization is very powerful… violence, fear, money and control go a long way.”
|
||||
|
||||
## Improving the IPFS Protocol Specification
|
||||
|
||||
@[youtube](1Lm-uh_8sNc)
|
||||
|
||||
In July 2022, the new Interplanetary Protocol Improvement Process (IPIP) was introduced to establish a clear process for proposing and evaluating IPFS protocol improvements.
|
||||
|
||||
|
||||
|
||||
As part of the IPFS Implementations track, IPFS specs steward Marcin Rataj (@lidel) presented an update on IPFS specifications and the IPIP process “Every implementation is a special snowflake. It’s built from different parts of our stack,” said Rataj. “\[Most\] implementations do not implement all the parts. They focus on things that are relevant to use cases \[and that is\] why we are investing in specs to make it easy for people to implement specific blocks of the IPFS stack without having to reference legacy code.”
|
||||
|
||||
Since July, 17 IPIP improvements have been proposed, indicating broader participation in IPFS protocol design. Learn more about the process and how to participate in the \`[ipfs/specs](https://github.com/ipfs/specs/blob/main/IPIP_PROCESS.md)\` repository.
|
||||
|
||||
## Voice Gems: A 1000 Year Archive
|
||||
|
||||
@[youtube](SumKPB7VUDA)
|
||||
|
||||
The [Voice Gems](https://reeps100.com/project/voicegems) project is a “vibrant, unprecedented meditation highlighting the most remarkable, influential, and critically endangered voices on earth to generate digital gemstones and physical sculptures.” The various works can be manifested as NFTs, print, 3-D print, digital video, large scale projection, and cast sculpture. In his talk, Voice Gems creative director Harry Yeff showcased his portfolio of speed-of-light radio transmission, AI synthetic voices, and how emerging technologies provide an artistically explosive and vital discussion on new methods of preservation.
|
||||
|
||||
|
||||
|
||||
“If you remove all musical connotations, there’s a huge responsibility for us to think about what is the scope, what is the limit, but also there are still innovations happening in voice,” said Yeff.
|
||||
|
||||
## Choose Your Own Adventure
|
||||
|
||||
## 
|
||||
|
||||
IPFS Camp 2022 was the first decentralized event of its kind. With over 17 different tracks, attendees had the chance to pick and choose what to join. All of these tracks are also now available on the [IPFS YouTube channel](https://www.youtube.com/c/IPFSbot):
|
||||
|
||||
* [IPFS Implementations](https://youtube.com/playlist?list=PLuhRWgmPaHtQchZjO3xBBFDiiqERmjA-a): Meet the teams taking IPFS to the next level and learn how you can find an IPFS implementation to work on.
|
||||
* [IPFS 101: Introduction & User Apps](https://youtube.com/playlist?list=PLuhRWgmPaHtSLRL9zSyKzjuHSpilhp1kL): A hands on session on getting started with IPFS.
|
||||
* [IPFS 201: Design Patterns & Developer Tools](https://youtube.com/playlist?list=PLuhRWgmPaHtRP0kfWyDuod_kVHE-5dGGL): covering IPFS app architectures, developer tools, design patterns and everything you need to know to build apps using IPFS.
|
||||
* [Content Routing](https://youtube.com/playlist?list=PLuhRWgmPaHtRqhFZ-CAstJ0RIq7Vs-4eO): Approaches and protocols to content routing in IPFS, what we've learned so far, and directions for the future.
|
||||
* [Data Transfer](https://youtube.com/playlist?list=PLuhRWgmPaHtR2-LVmm5_Yv8TA3NhA_QOK): How do IPFS nodes request, send, and receive content?
|
||||
* [Compute Over Data](https://youtube.com/playlist?list=PLuhRWgmPaHtTU1u9TGOVviM234URBdEGa): Producing data without leaving the Merkle Forest - How do we do it?
|
||||
* [IPFS Operators and Enterprise](https://youtube.com/playlist?list=PLuhRWgmPaHtSAA-XdMRvvgsp2fTwQgtLN): Explore applications & deployments of IPFS in large scale cloud & enterprise use cases.
|
||||
* [Measurement and Performance](https://youtube.com/playlist?list=PLuhRWgmPaHtSEd9SWIaoKsxMkannW8zX3): A data-driven approach to the design and operation of IPFS and libp2p through rigorous network measurements, performance evaluation and recommendations for builders and operators.
|
||||
* [Libp2p Day](https://youtube.com/playlist?list=PLuhRWgmPaHtRXZI9K7llOftzDTgS-Nin-): The first ever libp2p Day: a gathering for libp2p builders, contributors, and maintainers.
|
||||
* [Libp2p Privacy](https://youtube.com/playlist?list=PLuhRWgmPaHtRG4jtV_C_RWzp8g95E3tfP): Dive into the current privacy work happening on libp2p and get the chance to provide feedback on direction and next steps.
|
||||
* [Gaming, Metaverse, and Video](https://youtube.com/playlist?list=PLuhRWgmPaHtTAVs3_fI-NG2C3NQknS7IK): Learn more about the landscape of gaming and video production in Web3.
|
||||
* [Browsers & Platforms](https://youtube.com/playlist?list=PLuhRWgmPaHtQohNbRjFJDS70WoElZ8ep5): Learn the current status, ongoing challenges, and upcoming work to integrate IPFS and related technologies into browsers and the web itself.
|
||||
* [Decentralized Science (DeSci)](https://youtube.com/playlist?list=PLuhRWgmPaHtRlUVSiY2fUREl85pgcwxLO): Learn more about the projects that are revolutionizing research through open collaboration on IPFS.
|
||||
* [Lightning Talks 1](https://youtube.com/playlist?list=PLuhRWgmPaHtQkLjEcIlywENb7UkTKp1BT) & [Lightning Talks 2](https://youtube.com/playlist?list=PLuhRWgmPaHtQ2w6a7Y-n6PP9M_8pCvIiq): Explore a lineup of 15-minute talks covering all kinds of juicy IPFS related topics.
|
||||
* [Growing With IPFS](https://youtube.com/playlist?list=PLuhRWgmPaHtS7_4qMSclvVY5xTsm9pF53): Learn about how to grow your skills and/or your project with IPFS.
|
||||
|
||||
## Thank you for making IPFS Camp 2022 an extraordinary experience!
|
||||
|
||||
|
||||
|
||||
The event could not have been possible without the dedication of our awesome track leaders, the 100+ speakers, the 37 IPFS Scholars who were awarded travel stipends and expanded the community, the amazing 20+ volunteers who augmented our event staff, and of course, everyone who traveled from over 30 countries to participate in the 2022 edition of IPFS Camp.
|
||||
|
||||
|
||||
|
||||
Lisbon was a beautiful, friendly, and inspiring city; we want to thank all of the local production staff and community who made IPFS Camp possible. In collaboration with [Renovar a Mouraria](https://renovaramouraria.pt/en/), a non-profit organization that focuses on the inclusion and development of the most diverse neighborhood in Lisbon, school supplies and furniture from the event were donated to the local community. Additionally, through a partnership with [Re-Food](https://re-food.org/en/home/), over 1,000 meals were donated.
|
||||
|
||||
Thank you to our incredible community for making IPFS Camp 2022 an amazing experience. Keep an [eye out for updates](https://twitter.com/IPFS) on the next event!
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
title: Take the IPFS Events 2024 Survey Today!
|
||||
description: 'We need your help! Make your voice heard about upcoming IPFS Events.'
|
||||
date: 2023-09-18
|
||||
tags:
|
||||
- survey
|
||||
- events
|
||||
---
|
||||
|
||||
## **We need your help! Make your voice heard about upcoming IPFS Events 📆**
|
||||
|
||||
Each year, several different IPFS events and gatherings are held at different locations to make space for the community to socialize, learn, and grow together. Many of you have been eagerly awaiting more information about when the next events will be, and we’re excited to begin sharing some of those details with you starting today!
|
||||
|
||||
**IPFS Camp** will take place in **Spring 2024**! IPFS Camp is a large in-person gathering for the entire IPFS community: devs, operators, implementers, researchers – and you!
|
||||
|
||||
**IPFS Thing** is targeted for **Fall 2024**! IPFS Thing is a week-long gathering for the IPFS implementors community. Everything from talks, workshops, discussion circles, hacking time, and more — all focused on advancing IPFS implementations.
|
||||
|
||||
We are currently in the middle of sourcing venues for both events and would love to hear your feedback on where we should be looking and why. [Submit your feedback via the following survey](https://docs.google.com/forms/d/e/1FAIpQLScNP2NKgjVBu80IygfioeTH32aCMYASLBrlQ7q05ub3choHKQ/viewform) **by September 25 at 11:59pm PST** to make sure that you’re voice is heard!
|
||||
|
||||
<a href="https://docs.google.com/forms/d/e/1FAIpQLScNP2NKgjVBu80IygfioeTH32aCMYASLBrlQ7q05ub3choHKQ/viewform" class="cta-button">Fill out the survey</a>
|
||||
@@ -1,87 +0,0 @@
|
||||
---
|
||||
title: Welcome to IPFS News 194!
|
||||
description: Featuring Durin, Helia advancements, recaps of IPFS Thing 2023 from individual track leads, and much more!
|
||||
author: ''
|
||||
date: 2023-06-06
|
||||
permalink: "/newsletter-194"
|
||||
translationKey: ''
|
||||
header_image: "/ipfsnews.png"
|
||||
tags:
|
||||
- newsletter
|
||||
---
|
||||
|
||||
The month of May was packed full of new blog posts, þing 2023 recaps, and exciting milestones in the continued growth of IPFS. This edition of the newsletter covers everything from the launch of a new mobile app called Durin to a blog post explaining how to host dynamic content on IPFS using Helia.
|
||||
|
||||
Let’s dive in…
|
||||
|
||||
## **Brand New on IPFS ✨**
|
||||
|
||||
[Announcing Durin: a New Mobile App for the IPFS Network](https://blog.ipfs.tech/announcing-durin/)
|
||||
|
||||
- Durin is a new experimental app designed to make IPFS more accessible on mobile devices. Whereas in the past interacting with IPFS on mobile was difficult, you can now read and share to IPFS from iPhones and Android devices. [Learn more and download here!](https://blog.ipfs.tech/announcing-durin/)
|
||||
|
||||
[How to Host Dynamic Content on IPFS](https://blog.ipfs.tech/2023-how-to-host-dynamic-content-on-ipfs/)
|
||||
|
||||
- The new JS implementation of IPFS called Helia is finally here and you can do lots of things with it (like connect to the DHT)! In a recent blog post, [@tabcat00](https://twitter.com/tabcat00) presented a way to host dynamic content on IPFS that utilizes Helia. [Check it out!](https://blog.ipfs.tech/2023-how-to-host-dynamic-content-on-ipfs/)
|
||||
|
||||
[IPFS Multi-Gateway Experiment in Chromium](https://blog.ipfs.tech/2023-05-multigateway-chromium-client/)
|
||||
|
||||
- John Turpish of Little Bear Labs goes over a new approach to implementing ipfs:// and ipns:// support natively in the browser, using a client-only approach and fetching verifiable responses from multiple HTTP gateways. [Dive in here](https://blog.ipfs.tech/2023-05-multigateway-chromium-client/)!
|
||||
|
||||
[js-IPFS deprecation / replaced by Helia](https://blog.ipfs.tech/202305-js-ipfs-deprecation-for-helia/)
|
||||
|
||||
- js-IPFS is in the process of being deprecated so you should port your apps to Helia to receive bug fixes, features, and performance improvements moving forwards. [Read more on the IPFS blog](https://blog.ipfs.tech/202305-js-ipfs-deprecation-for-helia/)!
|
||||
|
||||
[IPFS Network Measurement Reports](https://github.com/protocol/network-measurements/tree/master/reports/2023)
|
||||
|
||||
- If you're interested in IPFS Network performance metrics and network cartography, make sure to check out ProbeLab's Weekly reports! The reports are posted every Monday at the [network-measurements repository on Github](https://github.com/protocol/network-measurements/tree/master/reports/2023) with commentary and discussion happening on [the IPFS Discussion Forum](https://discuss.ipfs.tech/c/testing-and-experiments/35). Make sure to get involved in the discussion and reach out through the discussion forum, the network-measurements repository (by opening an issue), or at the #probe-lab channel in the IPFS Discord, or FIL slack.
|
||||
|
||||
[What happens when half the network is down?](https://blog.ipfs.tech/2023-ipfs-unresponsive-nodes/)
|
||||
|
||||
- In 90% of networks, or networked systems, this is a grand-scale disaster... but for IPFS it's a very different story. Find out what happens in [a recent incident report published on the blog](https://blog.ipfs.tech/2023-ipfs-unresponsive-nodes/)!
|
||||
|
||||
[Introducing Rusty Lassie, a Rust wrapper for Lassie](https://crates.io/crates/lassie)
|
||||
|
||||
- A thin library embedding Lassie via CGo and FFI. With Rusty-Lassie, you can easily embed Lassie in your Rust project, start a Lassie HTTP server in a background thread, and retrieve CAR content using any HTTP client. [Learn more about the project here](https://crates.io/crates/lassie)!
|
||||
|
||||
## **IPFS Thing Track Recaps 📝**
|
||||
|
||||
[Recap: Content Routing (þing 2023)](https://blog.ipfs.tech/2023-ipfs-thing-content-routing-track/)
|
||||
|
||||
[Recap: Community & Governance (þing 2023)](https://blog.ipfs.tech/2023-ipfs-community-governance/)
|
||||
|
||||
[Recap: HTTP Gateways (þing 2023)](https://blog.ipfs.tech/2023-http-gateways-recap/)
|
||||
|
||||
[Recap: IPFS on the Web (þing 2023)](https://blog.ipfs.tech/2023-ipfs-thing-web-track/)
|
||||
|
||||
[libp2p at IPFS þing 2023 Recap](https://blog.libp2p.io/2023-libp2p-IPFS-Thing-recap/)
|
||||
|
||||
## **Around the Ecosystem 🌎**
|
||||
|
||||
[Founders Series, Episode 11: Juan Benet of Protocol Labs [Video]](https://www.youtube.com/watch?v=r-nU_MI2lV4)
|
||||
|
||||
- In this talk from LabWeek22 last November in Lisbon, Juan explains the importance of R&D, the lack of funding it receives, and how he hopes to solve this problem with the Protocol Labs Network, an ecosystem of teams based on open source, working together bridge what he calls the innovation chasm — the separation between research and deployment of product. [Watch it on YouTube!](https://www.youtube.com/watch?v=r-nU_MI2lV4)
|
||||
|
||||
[Filecoin & IPFS Ecosystem Roundup [Video]](https://youtu.be/kXnSklUL5NE)
|
||||
|
||||
- In this revamped monthly public video we give builders and community members a platform to share how they’re making web3 work better for all of us. Please [fill out this form](https://airtable.com/shrcadO9WAnQ5nJvA) to nominate a Team/Project to be featured as a 'Win of the Month'! Join us live the first Thursday of every month, and [watch the May round up now!](https://www.youtube.com/watch?v=kXnSklUL5NE)
|
||||
|
||||
[IPNS on Lighthouse](https://twitter.com/nanditmehra/status/1664317411313733634?s=20)
|
||||
|
||||
- IPNS support is now live on Lighthouse. Now build creative dapps with the world's best p2p tech for mutable data. Edit and upload your data and build dynamic NFT collections, mutable file systems, and much more with this IPNS support. [See the announcement on Twitter!](https://twitter.com/nanditmehra/status/1664317411313733634?s=20)
|
||||
|
||||
[IPFS Open Metaverse Base Camp Accelerator](https://twitter.com/OVioHQ/status/1662062713550299136?s=20)
|
||||
|
||||
- We're thrilled to announce the teams making up the latest IPFS Open Metaverse Base Camp accelerator cohort. This 12-week program will accelerate teams leveraging IPFS, Filecoin & [@fvmdev](https://twitter.com/fvmdev), paving the way forwards in the open data economy. [Read all about in this Twitter thead!](https://twitter.com/OVioHQ/status/1662062713550299136?s=20)
|
||||
|
||||
[Filebase for Startups](https://filebase.com/startups/)
|
||||
|
||||
- Filebase now has a program that offers complimentary IPFS storage and dedicated gateways for startups to scale with. You can learn more about it [on their website](https://filebase.com/startups/).
|
||||
|
||||
[Protocol Labs Launch Pad](https://protocol.ai/blog/launchpad-summit-paris-2023/)
|
||||
|
||||
- Launchpad is a blend of two key components: a dynamic four-week virtual learning cohort, where residents actively participate in remote learning seminars, and an unforgettable one-week in-person “colo” Summit. [Learn more on the Protocol Labs blog](https://protocol.ai/blog/launchpad-summit-paris-2023/)!
|
||||
|
||||
[HackFS kicked off on June 2](https://ethglobal.com/events/hackfs2023)
|
||||
|
||||
- Late last week, EthGlobal and Protocol Labs kicked off HackFS 2023 with an incredible summit featuring fireside chats on FVM, presentations on the Protocol Labs builders funnel, and even a talk from a surprise guest. [Check out the event's website to catchup](https://ethglobal.com/events/hackfs2023)!
|
||||
@@ -1,266 +0,0 @@
|
||||
---
|
||||
tags:
|
||||
- libp2p
|
||||
title: libp2p Day 2022 Recap
|
||||
description: Recap of libp2p Day during IPFS Camp 2022 in Lisbon!
|
||||
date: 2022-11-22
|
||||
permalink: "/2022-11-22-libp2p-day-2022-recap/"
|
||||
translationKey: ''
|
||||
header_image: /libp2p-day-blog-header.png
|
||||
author: Prithvi Shahi
|
||||
---
|
||||
|
||||
**Table of Contents**
|
||||
|
||||
[[toc]]
|
||||
|
||||
## Introduction
|
||||
|
||||
<div class="container" style="display:flex; column-gap:10px;">
|
||||
<figure>
|
||||
<img src="../assets/libp2p-day-2022-2.jpg" width="500">
|
||||
<figcaption style="font-size:x-small;">Go, JS, and Rust libp2p core maintainers introduced by Steve Loeppky.
|
||||
<a href="https://twitter.com/IPFS/status/1586670754766143490?s=20&t=I8wcyY6Ie0tPKvQf40Mv0g">[Pic credit.]</a>
|
||||
</figcaption>
|
||||
</figure>
|
||||
<figure>
|
||||
<img src="../assets/libp2p-day-2022-3.jpg" width="500">
|
||||
<figcaption style="font-size:x-small;">Max Inden gave a high level introduction to libp2p.
|
||||
<a href="https://twitter.com/IPFS/status/1586665721559392256?s=20&t=I8wcyY6Ie0tPKvQf40Mv0g">[Pic credit.]</a>
|
||||
</figcaption>
|
||||
</figure>
|
||||
</div>
|
||||
|
||||
Last month, on October 30th 2022, libp2p users and contributors gathered together for the first ever libp2p Day!
|
||||
|
||||
The day included talks from maintainers, contributors, community members, and users. Topics included latest libp2p updates, preview of future roadmap items, bleeding-edge demos on browser connectivity using new transport protocols, and much more.
|
||||
|
||||
Speakers shared new, exciting developments built on libp2p and represented organizations like [Little Bear Labs](https://littlebearlabs.io/), [ChainSafe Systems](https://chainsafe.io/), [Status.im](https://status.im/), [Gather](https://www.gather.town/), [Quiet](https://www.tryquiet.org/), [Pyrsia](https://pyrsia.io/), [Satellite.im](http://satellite.im/), and [Protocol Labs](https://protocol.ai/).
|
||||
|
||||
In the larger context, libp2p Day was hosted at [IPFS Camp 2022](https://2022.ipfs.camp/) as a part of a diverse lineup where speakers covered topics across domains such as libp2p, IPFS, content routing, decentralized computation, and more!
|
||||
|
||||
<blockquote class="twitter-tweet"><p lang="en" dir="ltr">🎥 3 days of <a href="https://twitter.com/hashtag/IPFSCamp?src=hash&ref_src=twsrc%5Etfw">#IPFSCamp</a> in one short video. 23 tracks, 100+ speakers, and the IPFS community.<br>Watch the recap and relive the fun.⛺️️<br>🎉 Who is ready for next year? <a href="https://t.co/IolaZZduIB">pic.twitter.com/IolaZZduIB</a></p>— IPFS (@IPFS) <a href="https://twitter.com/IPFS/status/1587053346829094915?ref_src=twsrc%5Etfw">October 31, 2022</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
|
||||
|
||||
### Goals
|
||||
|
||||
The goals of libp2p Day were to:
|
||||
|
||||
1. Share updates on libp2p and highlight new developments through demos
|
||||
2. Gather the libp2p ecosystem, give a spotlight to projects building on libp2p, and energize the community
|
||||
3. Empower newcomers and existing users to become contributors and spec authors
|
||||
|
||||
### Takeaways
|
||||
|
||||
Some highlights and learnings from libp2p Day and IPFS Camp were:
|
||||
|
||||
#### Browser Connectivity Unlocked
|
||||
|
||||
First-class support for WebTransport enables libp2p nodes running in the browser ([currently limited to Chromium](https://caniuse.com/webtransport)) to connect directly with peers on a host machine. WebTransport support was first added as an experimental feature in [go-libp2p v0.23.0](https://github.com/libp2p/go-libp2p/releases/tag/v0.23.0) and [Kubo v0.16.0](https://github.com/ipfs/kubo/releases/tag/v0.16.0#-webtransport-new-experimental-transport). The remaining WebTransport work is [tracked here](https://github.com/libp2p/go-libp2p/issues/1827).
|
||||
|
||||
WebRTC browser-to-server has also made significant progress. Since libp2p Day, the specification [been merged](https://github.com/libp2p/specs/tree/master/webrtc), and the [rust-libp2p implementation](https://github.com/libp2p/rust-libp2p/commit/a7148648858fe10e9ba4c2793c7e12392b49c0ab) has shipped! The Go and JS implementations are also tracking closely.
|
||||
|
||||
Check out the [WebTransport](#webtransport-transport) and [WebRTC](#why-webrtc) demos below, as well as the [new libp2p connectivity site](https://connectivity.libp2p.io/).
|
||||
|
||||
#### libp2p Interoperability
|
||||
|
||||
The libp2p ecosystem continues to flourish with several implementations, each with its own set of supported features. It’s paramount to ensure these features and implementations are compatible and that new releases don’t introduce regressions. libp2p teams are spending the tail end of 2022 and much of 2023 focusing on testing libp2p interoperability.
|
||||
|
||||
Checkout [libp2p Interoperability Testing with Testground](#libp2p-interoperability-testing-with-testground) to learn more.
|
||||
|
||||
#### Demand for libp2p + HTTP
|
||||
|
||||
With the growing demand for libp2p + HTTP, especially by [Protocol Labs ProductDev](https://pl-strflt.notion.site/Teams-c1757afbec9946d68daadf5bc0212b97) teams like Bedrock and [dag.house](http://dag.house)), the team has started drafting an [HTTP specification](https://github.com/libp2p/specs/pull/477), with plans to make this a top priority going into 2023. libp2p + HTTP will enable use cases like integrating directly with CDN infrastructure or allowing a static HTTP cache to respond to requests from a libp2p node.
|
||||
|
||||
## Recap of talks
|
||||
|
||||
Below is list of all talks alongside a brief outline:
|
||||
|
||||
<div class="container" style="display:flex; column-gap:10px;">
|
||||
<figure>
|
||||
<img src="../assets/libp2p-day-2022-4.jpg" width="500">
|
||||
<figcaption style="font-size:x-small;">Marten Seemann presented on browser connectivity.
|
||||
<a href="https://twitter.com/IPFS/status/1586676794383638535?s=20&t=I8wcyY6Ie0tPKvQf40Mv0g">[Pic credit.]</a>
|
||||
</figcaption>
|
||||
</figure>
|
||||
<figure>
|
||||
<img src="../assets/libp2p-day-2022-5.jpg" width="500">
|
||||
<figcaption style="font-size:x-small;">Dennis Trautwein described solutions to problems encountered during NAT traversal.
|
||||
<a href="https://twitter.com/physikerwelt/status/1586683911584813058">[Pic credit.]</a>
|
||||
</figcaption>
|
||||
</figure>
|
||||
</div>
|
||||
|
||||
### Intro to libp2p: helping with real world application problems
|
||||
|
||||
Max Inden (rust-libp2p maintainer, Software Engineer at Protocol Labs)
|
||||
|
||||
@[youtube](J7ZWbpo2AZk)
|
||||
|
||||
Max introduced libp2p by giving an overview of the supported transport protocols, secure channels, multiplexing mechanisms, how libp2p [traverses NATs](https://research.protocol.ai/publications/decentralized-hole-punching/), how libp2p discovers peers, how libp2p uses [Kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) for peer-to-peer routing, [GossipSub](https://arxiv.org/abs/2007.02754) for publishing and subscribing messages, and how libp2p exchanges data using [BitSwap](https://research.protocol.ai/publications/accelerating-content-routing-with-bitswap-a-multi-path-file-transfer-protocol-in-ipfs-and-filecoin/delarocha2021.pdf). He briefly reviewed the different implementations and projects using libp2p and previewed libp2p’s future focus.
|
||||
|
||||
### A month in PL EngRes libp2p Development and how you can be involved
|
||||
|
||||
Steve Loeppky (Engineering Manager of libp2p team at Protocol Labs)
|
||||
|
||||
@[youtube](sG2j1EqVB0Q)
|
||||
|
||||
Steve outlined a typical month of libp2p development for implementations like Go, JS, and Rust and the work done to support the wider community. He showcased recent work to improve the [libp2p documentation](http://docs.libp2p.io), the [implementation roadmaps](https://github.com/libp2p/specs/blob/master/ROADMAP.md#implementation-roadmaps) and their planned features, and highlighted the team structure, project [values](https://pl-strflt.notion.site/libp2p-a27f9e5cb69648538e444163ce3f7309) and [core tenets](https://github.com/libp2p/specs/blob/master/ROADMAP.md#core-tenets).
|
||||
|
||||
### Browser connectivity state of the union and demo
|
||||
|
||||
Marten Seemann (go-libp2p maintainer, Software Engineer at Protocol Labs)
|
||||
|
||||
@[youtube](qG_1bYVtGO4)
|
||||
|
||||
Marten gave an updated version of a [P2P Paris talk](https://www.youtube.com/watch?v=aXYUw9tikaQ) covering the intricacies of browser communication with other nodes and discussed recent breakthroughs. He outlined the current capabilities with libp2p in the browser and gave an overview of WebSockets, [WebTransport](https://github.com/libp2p/specs/tree/master/webtransport), and [WebRTC](https://github.com/libp2p/specs/tree/master/webrtc), and future next steps.
|
||||
To top it off, Marten linked to [the brand new libp2p connectivity website](https://connectivity.libp2p.io/), a site he put together to make the libp2p connectivity story easier to understand!
|
||||
|
||||
### WebTransport Transport
|
||||
|
||||
Alex Potsides (js-libp2p maintainer, Software Engineer at Protocol Labs)
|
||||
|
||||
@[youtube](Dt42Ss6X_Vk)
|
||||
|
||||
Alex demoed WebTransport [using the browser to fetch a file from Kubo directly](https://github.com/libp2p/js-libp2p-webtransport/tree/main/examples/fetch-file-from-kubo).
|
||||
|
||||
Alex underscored the incredible accomplishment in his talk: browsers can leverage WebTransport to talk directly to a distributed network. He described WebTransport availability in browsers today and how it compares to WebRTC concerning application performance.
|
||||
|
||||
### Why WebRTC
|
||||
|
||||
Ryan Plauche (Software Engineer at [Little Bear Labs](https://littlebearlabs.io/))
|
||||
|
||||
Max Inden ( rust-libp2p maintainer, Software Engineer at Protocol Labs)
|
||||
|
||||
@[youtube](ZBIFFuakFHQ)
|
||||
|
||||
Later, Max dove deeper into WebRTC by offering an overview of its history and describing its advantages, namely, how WebRTC enables connections between peers using [self-signed certificates](https://en.wikipedia.org/wiki/Self-signed_certificate) and allows for hole punching in the browser. He then described the [Browser to Server specification](https://github.com/libp2p/specs/tree/master/webrtc#browser-to-public-server) in greater detail and previewed Browser-to-Browser connectivity.
|
||||
|
||||
From [Little Bear Labs](https://littlebearlabs.io/), Ryan presented the work he and his colleagues [John](https://github.com/John-LittleBearLabs) & [Chinmay](https://github.com/ckousik) accomplished to support WebRTC in libp2p. He gave a fantastic demo of WebRTC browser-to-server using one browser client (a react app with a js-libp2p dialer) and two servers (two go-libp2p listeners). He also verified the demo in real-time using Chrome’s chrome://webrtc-internals page to observe the data channels and prove that the intended messages were passed using WebRTC!
|
||||
|
||||
### Decentralized NAT Hole Punching
|
||||
|
||||
Dennis Trautwein (Research Engineer at [ProbeLab](https://research.protocol.ai/groups/probelab/))
|
||||
|
||||
@[youtube](bzL7Y1wYth8)
|
||||
|
||||
Dennis presented his project on measuring the success rates of the novel decentralized hole-punching mechanism. He described the hole-punching mechanism and gave an overview of the [Direct Connection Upgrade through Relay (DCUtR) protocol](https://github.com/libp2p/specs/blob/master/relay/DCUtR.md). He then discussed how measurements are made and the findings on success rates. Dennis ended the presentation with a call to action: participate in the [NAT Hole Punching Measurement Campaign](https://discuss.libp2p.io/t/call-for-participation-nat-hole-punching-measurement-campaign/1690)!
|
||||
|
||||
### libp2p in Nim
|
||||
|
||||
Tanguy (nim-libp2p maintainer, Software Engineer at [Status.im](https://status.im/))
|
||||
|
||||
@[youtube](Iv9VrLPloGI)
|
||||
|
||||
Tanguy spoke about the [Nim programming language](https://nim-lang.org/) and drew contrasts between the features and goals of Nim, Go, and Rust. He focused on [nim-libp2p](https://github.com/status-im/nim-libp2p) which underpins applications like [Codex](https://github.com/status-im/nim-codex), [Waku](https://our.status.im/peer-to-peer-messaging-where-whisper-falls-short-and-waku-picks-up/), and [Nimbus](https://nimbus.team/). Tanguy detailed currently supported features in nim-libp2p, what it’s missing, and outlined plans for incoming features (GossipSub improvements, Tor transport, C bindings, running in the browser, and Bluetooth transport.)
|
||||
|
||||
Fun fact: nim-libp2p recently became the first libp2p implementation to cut a 1.0 release 🥳
|
||||
|
||||
### libp2p Interoperability Testing with Testground
|
||||
|
||||
Laurent Senta (Productivity Engineer at Protocol Labs)
|
||||
|
||||
@[youtube](b2SkC4dYV-A)
|
||||
|
||||
Laurent gave a talk introducing [Testground](https://docs.testground.ai/) and how it helps achieve libp2p’s interoperability goal ([as mentioned in Steve’s presentation](https://youtu.be/sG2j1EqVB0Q?t=1064).) He explained the importance of interop testing between libp2p implementations and how Testground’s language & runtime agnostic framework is a perfect fit for this use case. In the overview, Laurent described a ping test, how to make a test runnable in Testground, and how build and runtime parameters are specified in test configurations. Notably, he shared how Testground and interop testing has already caught bugs (within a month of tests being enabled)!
|
||||
|
||||
Laurent also previewed upcoming features (support for complex test suites, Node JS and Browser JS tests, etc.) and plans for quality of life improvements (simplify debugging, documentation, and stability improvements.)
|
||||
|
||||
<div class="container" style="display:flex; column-gap:10px;">
|
||||
<figure>
|
||||
<img src="../assets/libp2p-day-2022-6.jpg" width="500">
|
||||
<figcaption style="font-size:x-small;">Drew Ewing presented the Iridium and the Satellite.im project.
|
||||
<a href="https://twitter.com/Satellite_im/status/1586734161066278912">[Pic credit.]</a>
|
||||
</figcaption>
|
||||
</figure>
|
||||
<figure>
|
||||
<img src="../assets/libp2p-day-2022-7.jpg" width="500">
|
||||
<figcaption style="font-size:x-small;">A glimpse into the audience.
|
||||
<a href="https://twitter.com/IPFS/status/1586744753839919107?s=20&t=I8wcyY6Ie0tPKvQf40Mv0g">[Pic credit.]</a>
|
||||
</figcaption>
|
||||
</figure>
|
||||
</div>
|
||||
|
||||
### WebRTC signaling data over QR Codes
|
||||
|
||||
Gorka (Tech lead at [Gather](https://www.gather.town/))
|
||||
|
||||
@[youtube](EQFUPZK9CwI)
|
||||
|
||||
Gorka demonstrated a novel experiment: WebRTC data exchange over QR codes. He described how it’s possible to share any data using QR codes and explained how this method could be used to exchange signaling data to establish a WebRTC connection between two devices on the same network.
|
||||
|
||||
### Formal Analysis of GossipSub
|
||||
|
||||
Ankit Kumar (PhD student at Northeastern University)
|
||||
|
||||
@[youtube](T3QLhijHAwA)
|
||||
|
||||
Ankit presented on work he and his colleagues at Northeastern University did to formally specify the GossipSub protocol. This critical work cross validated the [prose specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md) against GossipSub implementations in the Filecoin and Ethereum networks. Ankit detailed how the team at Northeastern used the [ACL2S theorem prover](http://acl2s.ccs.neu.edu/acl2s/doc/) as a part of the formalization effort and arrived at a scoring function (used to determine good peers vs. bad peers) with four essentials properties needed to prevent Sybil attacks. He shared findings and discussed which properties were satisfied on Filecoin and Ethereum, and outlined future directions to develop a verified network stack.
|
||||
|
||||
### Introducing Quiet - Encrypted P2P team chat without servers, just Tor
|
||||
|
||||
Holmes Wilson (Founder of [Fight for the Future](https://www.fightforthefuture.org/))
|
||||
|
||||
@[youtube](owSd7uuGwmw)
|
||||
|
||||
Holmes presented [Quiet](https://github.com/TryQuiet/quiet), a slack alternative focused on privacy, built on IPFS, OrbitDB, and Tor .onion services. *Quiet teams* operate in private libp2p and IPFS networks (over Tor) which use a modified libp2p WebSockets transport combined with Tor, as well as BitSwap and PubSub for messaging. Holmes also provided contrasts between Quiet and other privacy focused (Signal) and non-privacy focused team messaging apps (e.g. Matrix and Mattermost.)
|
||||
|
||||
### How Pyrsia is Using libp2p To Take Over the World
|
||||
|
||||
Elliot Frisch (Blockchain Developer at [JFrog](https://jfrog.com/))
|
||||
|
||||
@[youtube](aIxmQKWUjNY)
|
||||
|
||||
Elliot introduced and gave a demo of [Pyrsia](https://pyrsia.io/), a binary build & distribution system written in Rust and built on top of libp2p for messaging (instead of HTTP or SSH.) He detailed how Pyrsia seeks to provide provenance when distributing binaries with the aim to prevent known exploits like the [SolarWinds hack](https://www.wired.com/story/solarwinds-hack-supply-chain-threats-improvements/), [Log4Shell exploit](https://news.sophos.com/en-us/2021/12/17/inside-the-code-how-the-log4shell-exploit-works/), [malicious crates in rust](https://blog.rust-lang.org/2022/05/10/malicious-crate-rustdecimal.html), and [domain takeovers](https://jfrog.com/blog/npm-package-hijacking-through-domain-takeover-how-bad-is-this-new-attack/).
|
||||
|
||||
### Decentralized Chat with IPFS & libp2p
|
||||
|
||||
Drew Ewing (CTO at [Satellite.im](http://satellite.im))
|
||||
|
||||
@[youtube](baqWhUACUAg)
|
||||
|
||||
Drew introduced Satellite, a decentralized video, voice, and chat application that utilizes libp2p and IPFS. He described [Iridium](https://github.com/Satellite-im/iridium), an abstraction layer that bootstraps both IPFS and libp2p and uses [DIDs](https://www.w3.org/TR/did-core/) for user identity. He ended the presentation with a demo where he generated a DID, created a new user account, and sent messages. You can play with a demo here: [https://core.satellite.im/](https://core.satellite.im/)
|
||||
|
||||
### DOS Defense - Do’s and Dont’s
|
||||
|
||||
Max Inden ( rust-libp2p maintainer, Software Engineer at Protocol Labs)
|
||||
|
||||
@[youtube](jZrAnnFO-2c)
|
||||
|
||||
Max’s third talk of the day outlined how to prevent DoS attacks by explaining what an application should do (bound resources, enforce backpressure, etc.) and what an app should avoid. This was a fun, interactive session where Max presented code snippets and had participants point out how an attacker could take advantage of flaws in the code.
|
||||
|
||||
### Intro to Lodestar
|
||||
|
||||
Cayman Nava (js-libp2p & [Lodestar](https://github.com/chainsafe/lodestar) maintainer, Blockchain Engineer at [ChainSafe Systems](https://chainsafe.io/))
|
||||
|
||||
@[youtube](1DStPz32k_4)
|
||||
|
||||
Cayman gave an overview of [Lodestar](https://github.com/chainsafe/lodestar), an Ethereum consensus client implemented in TypeScript and its use of js-libp2p. He described the unique challenges of writing high performance TypeScript/JavaScript, and explained how the ChainSafe team uses metrics and CPU profiling to test js-libp2p and Lodestar in production.
|
||||
|
||||
### The power of two choices: Why the Kademlia binary tree isn’t balanced and what we can do about it
|
||||
|
||||
Petar Maymounkov (co-author of [Kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf), Senior Research Engineer at Protocol Labs)
|
||||
|
||||
@[youtube](0dKz_K-7eoI)
|
||||
|
||||
The final talk by Petar was a great way to cap off libp2p Day. Petar discussed peer ID distribution in the Kademlia DHT - existing problems and solutions to those problems. In the first half of the talk, he showed that in an experiment (run many times over) of picking a thousand random numbers and inserting them into a binary tree, the distribution of leaf depths is always going to be the same, even though the tree is different in each experiment. Furthermore, Petar described how a theorem that looks at distribution of depths in the tree can be used to summarize the imbalance/non-uniformity of the Kademlia binary tree.
|
||||
|
||||
The second half of the talk provided a solution and described the power of two choices, an algorithm for picking peer IDs results in an overall more balanced binary tree with a shallower depth distribution. Petar explains that a well-balanced tree can give us a better inference of network size.
|
||||
|
||||
## Get Involved/Stay Tuned
|
||||
|
||||
A big thank you to the attendees, speakers, and organizers of libp2p Day! 🤩 It was a pleasure to have everyone together for the first libp2p Day and we hope to see you at the next one. To those who couldn’t make it this time around, we hope you can make it next time. Until then, these recordings will help you get up to speed.
|
||||
|
||||
- If you’d like to get involved and contribute to libp2p, you can reach out to us using these means: [https://libp2p.io/#community](https://libp2p.io/#community)
|
||||
- If you’re a self-starter and want to start pushing code immediately, feel free to ping the maintainers in any of these help wanted/good first issues: [go-libp2p](https://github.com/libp2p/go-libp2p/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22), [js-libp2p](https://github.com/libp2p/js-libp2p/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22), and [rust-libp2p](https://github.com/libp2p/rust-libp2p/issues?q=is%3Aopen+is%3Aissue+label%3Agetting-started).
|
||||
- If you want to work in and around libp2p full-time, there are various teams hiring including the implementation teams. See [https://jobs.protocol.ai/jobs?q=libp2p](https://jobs.protocol.ai/jobs?q=libp2p) for opportunities across the [Protocol Labs Network](https://plnetwork.io/).
|
||||
- There is a call for participants in the [NAT Hole Punching Measurement Campaign](https://discuss.libp2p.io/t/call-for-participation-nat-hole-punching-measurement-campaign/1690). Please check it out, any help is appreciated!
|
||||
|
||||
To learn more about libp2p generally, checkout:
|
||||
|
||||
- The [libp2p documentation portal](https://docs.libp2p.io/)
|
||||
- The [libp2p connectivity website](https://connectivity.libp2p.io/)
|
||||
- The [libp2p curriculum put together by the Protocol Labs Launchpad program](https://curriculum.pl-launchpad.io/curriculum/libp2p/introduction/)
|
||||
|
||||
You can reach out to us and stay tuned for our next event announcement by joining our [various communication channels](https://libp2p.io/#community), joining the [discussion forum](https://discuss.libp2p.io/), following us on [Twitter](https://twitter.com/libp2p), or saying hi in the #libp2p-implementers channel in the [Filecoin public Slack](http://filecoin.io/slack).
|
||||
|
||||
Cheers!
|
||||
@@ -4,23 +4,6 @@ type: News coverage
|
||||
sitemap:
|
||||
exclude: true
|
||||
data:
|
||||
- title: Brave announces automatic NFT backups and enhanced IPFS/Filecoin support in Brave Wallet
|
||||
date: 2023-05-02
|
||||
publish_date:
|
||||
path: https://brave.com/nft-pinning/
|
||||
tags:
|
||||
- NFTs
|
||||
- Brave
|
||||
- pinning
|
||||
- title: WebTransport in libp2p
|
||||
date: 2022-12-19
|
||||
publish_date:
|
||||
path: https://blog.libp2p.io/2022-12-19-libp2p-webtransport/
|
||||
card_image: "/libp2p_WebTransport_Blog_Header.png"
|
||||
tags:
|
||||
- libp2p
|
||||
- browser
|
||||
- transport
|
||||
- title: Why the Internet Needs the Interplanetary File System
|
||||
date: 2022-10-09
|
||||
publish_date:
|
||||
|
||||
@@ -1,96 +0,0 @@
|
||||
---
|
||||
title: Welcome to IPFS News 195!
|
||||
description: Featuring a deep-dive into the challenges of measuring decentralized networks + more!
|
||||
author: ''
|
||||
date: 2023-07-06
|
||||
permalink: "/newsletter-195"
|
||||
translationKey: ''
|
||||
header_image: "/ipfsnews.png"
|
||||
tags:
|
||||
- newsletter
|
||||
---
|
||||
|
||||
As we enter into the summer months, things are slowing down just a bit as people go on holiday or get some much needed R&R, but that doesn’t mean we don’t have plenty of things to share with you! From a deep-dive into [the challenges of measuring decentralized networks](https://pulse.internetsociety.org/blog/the-challenges-of-measuring-decentralized-networks-the-case-of-the-interplanetary-file-system) to news about Fission adding redirect support of IPFS, this month’s newsletter will keep you in the loop whether this edition finds you in the office, at home, or on the beach. 🏖️
|
||||
|
||||
Let’s jump in!
|
||||
|
||||
## **Brand New on IPFS ✨**
|
||||
|
||||
[Kubo 0.21.0](https://github.com/ipfs/kubo/releases/tag/v0.21.0)
|
||||
|
||||
- Saving previously seen nodes for later bootstrapping
|
||||
- Gateway: `DeserializedResponses` config flag
|
||||
- `client/rpc` migration of `go-ipfs-http-client`
|
||||
- Gateway: DAG-CBOR/-JSON previews and improved error pages
|
||||
- Gateway: subdomain redirects are now `text/html`
|
||||
- Gateway: support for partial CAR export parameters (IPIP-402)
|
||||
- `ipfs dag stat` deduping statistics
|
||||
- Accelerated DHT Client is no longer experimental
|
||||
|
||||
[The Challenges of Measuring Decentralized Networks: The Case of the InterPlanetary File System](https://pulse.internetsociety.org/blog/the-challenges-of-measuring-decentralized-networks-the-case-of-the-interplanetary-file-system)
|
||||
|
||||
- In this new blog post from the Internet Society's (ISOC) Pulse project, Yiannis Psaras of ProbeLab shares their experience measuring the stability, performance, and cartography of InterPlanetary File System (IPFS), one of the largest decentralized, P2P networks in operation. [Read it here!](https://pulse.internetsociety.org/blog/the-challenges-of-measuring-decentralized-networks-the-case-of-the-interplanetary-file-system)
|
||||
|
||||
[June Protocol Labs EngRes All Hands [Video]](https://www.youtube.com/watch?v=7fbhniQJjDw)
|
||||
|
||||
- The PL Engineering and Research (EngRes) Workgroup is formed by teams of core protocol developers, network researchers, and experienced contributors in the Protocol Labs Network. The PL EngRes WG mission is to scale and unlock new opportunities for IPFS, Filecoin, libp2p + IPLD, drive breakthroughs in protocol utility & capability, and scale network-native research & development across the PL Network. The PL EngRes WG hosts monthly all hands meetings to check in on progress, and showcase the growth and new capabilities being unlocked by these research & development teams. [Watch it here!](https://www.youtube.com/watch?v=7fbhniQJjDw)
|
||||
|
||||
[js-IPFS Deprecation Reminder: Move to Helia!](https://blog.ipfs.tech/202305-js-ipfs-deprecation-for-helia/)
|
||||
|
||||
- **js-IPFS is in the process of being deprecated** so you should port your apps to Helia to receive bug fixes, features, and performance improvements moving forwards. [Read more about it here!](https://blog.ipfs.tech/202305-js-ipfs-deprecation-for-helia/)
|
||||
|
||||
## **Around the Ecosystem 🌎**
|
||||
|
||||
[Fission adds redirect support for IPFS](https://fission.codes/blog/introducing-redirect-support-for-ipfs/)
|
||||
|
||||
- Fission is dedicated to building and improving on decentralized web protocols. Redirect support is an officially accepted improvement for IPFS that makes it easier to host modern web applications. [Learn more about it here!](https://fission.codes/blog/introducing-redirect-support-for-ipfs/)
|
||||
|
||||
[IPFS data integrated directly into a blockchain explorer](https://twitter.com/al_koii/status/1665817302279880706?s=20)
|
||||
|
||||
- Koii's distributed computing platform uses [web3.storage](https://t.co/KyqdyMsAQy) as a convenient integration for IPFS. Thanks to the lightning-fast w3link gateway and easy to use SDK, developers building on Koii have an extra edge as they implement P2P apps, distributed AI, and more. [Check it out in this Twitter thread!](https://twitter.com/al_koii/status/1665817302279880706?s=20)
|
||||
|
||||
[Elevate by Outlier Ventures](https://outlierventures.io/elevate/)
|
||||
|
||||
- Elevate is a virtual event series focused on spotlighting Outlier Ventures’ Base Camp Teams. Featuring talks from the very people driving Web3 forward, ELEVATE gives their partners, mentors, program experts and founders themselves an opportunity to showcase the progress they’ve made through their 12-week program. At the virtual event on July 6 (today!) you’ll be able to meet the builders onboarding the next billion users into the Open Metaverse, using IPFS. [Join the event here!](https://outlierventures.io/elevate/)
|
||||
|
||||
[ProbeLab Office Hours: IPFS Network Measurements](https://lu.ma/ipfs-network-measurements)
|
||||
|
||||
- These open office hours are for anyone interested in network measurements in the IPFS network. The session is hosted by the [ProbeLab](https://blog.ipfs.io/2022-06-15-probelab/) team. During this session, they will discuss issues related to ongoing projects and IPFS network measurement topics more generally with the community. If you're working or are interested in contributing, [make sure to join!](https://lu.ma/ipfs-network-measurements)
|
||||
|
||||
[IPFS Multi-Gateway Experiment in Chromium](https://blog.ipfs.tech/2023-05-multigateway-chromium-client/?utm_content=253765483&utm_medium=social&utm_source=twitter&hss_channel=tw-3030006159)
|
||||
|
||||
- Learn about a new approach to implementing ipfs:// and ipns:// support natively in the browser, using a client-only approach and fetching verifiable responses from multiple HTTP gateways. [Check out the blog post!](https://blog.ipfs.tech/2023-05-multigateway-chromium-client/?utm_content=253765483&utm_medium=social&utm_source=twitter&hss_channel=tw-3030006159)
|
||||
|
||||
[Secure Curves in the Web Cryptography API](https://blogs.igalia.com/jfernandez/2023/06/20/secure-curves-in-the-web-cryptography-api/)
|
||||
|
||||
- A new blog post about the collaboration between [@igalia](https://twitter.com/igalia) and [@protocollabs](https://twitter.com/protocollabs) on the implementation of secure curves based on Curve25519 for the Web Cryptography specification. [Read it now!](https://blogs.igalia.com/jfernandez/2023/06/20/secure-curves-in-the-web-cryptography-api/)
|
||||
|
||||
[Where to find the Filecoin Community at EthCC](https://fil-paris.io/)
|
||||
|
||||
- Looking for the Filecoin community during EthCC? Check out [Filecoin Unleashed](https://filecoinunleashed.io) and [Fil Paris](https://fil-paris.io).
|
||||
|
||||
[Accelerate your Web3 journey: Protocol Labs Launchpad Summit on July 16-21](https://protocol.ai/blog/launchpad-summit-paris-2023/)
|
||||
|
||||
- Launchpad is a blend of two key components: a dynamic four-week virtual learning cohort, where residents actively participate in remote learning seminars, and an unforgettable one-week in-person “colo” Summit. **[Learn more on the Protocol Labs blog](https://protocol.ai/blog/launchpad-summit-paris-2023/)**
|
||||
|
||||
## HackFS Winners 🏅
|
||||
|
||||
This year’s [HackFS hackathon](https://ethglobal.com/events/hackfs2023) has come to a close, and several projects were selected as winners for the IPFS category. If you missed it, [learn more about HackFS here](https://ethglobal.com/events/hackfs2023).
|
||||
|
||||
Introducing the HackFS 2023 winners for IPFS…
|
||||
|
||||
[Web3Stash](https://ethglobal.com/showcase/web3stash-mn6iu) by [@mbcse50](https://twitter.com/mbcse50)
|
||||
|
||||
- Web3Stash is a standard library to get a single API to connect to multiple decentralized storage service providers. [Check it out here!](https://ethglobal.com/showcase/web3stash-mn6iu)
|
||||
|
||||
[unid.store](https://t.co/xbh9zYbjm9) by [@_Difint_](https://twitter.com/_Difint_)and [@mr13tech](https://twitter.com/mr13tech)
|
||||
|
||||
- Super simple file sharing - decentralized, quick, and without registration. [Take a look here!](https://ethglobal.com/showcase/unid-store-2yukr)
|
||||
|
||||
[Fileblox](https://ethglobal.com/showcase/fileblox-y0rjm) by [@Lycaoncreatives](https://twitter.com/LycaonCreatives), [@raldblox](https://twitter.com/raldblox), and [@luckscientist](https://twitter.com/luckscientist)
|
||||
|
||||
- FileBlox enables the creation of encrypted NFTs. It solves the right-click-and-save problem for our content creators while letting them get all the benefits of tokenization. [Learn more here!](https://ethglobal.com/showcase/fileblox-y0rjm)
|
||||
|
||||
[Star Streamer](https://ethglobal.com/showcase/star-streamer-huakw) by [@msakiart](https://twitter.com/msakiart)
|
||||
|
||||
- P2P video streaming service for decentralized content sharing with libp2p, ipfs and hypercore. [Check it out here!](https://ethglobal.com/showcase/star-streamer-huakw)
|
||||
@@ -1,73 +0,0 @@
|
||||
---
|
||||
title: Welcome to IPFS News 196!
|
||||
description: Featuring news about a resilient and fully-automated infrastructure to monitor the performance of the IPFS network.
|
||||
author: ''
|
||||
date: 2023-08-09
|
||||
permalink: "/newsletter-196"
|
||||
translationKey: ''
|
||||
header_image: "/ipfsnews.png"
|
||||
tags:
|
||||
- newsletter
|
||||
---
|
||||
|
||||
## **An Observatory for the IPFS Network 🔭**
|
||||
|
||||
We're excited to share that the ProbeLab team has worked hard over the past year to build a resilient and fully-automated infrastructure to monitor the performance of core IPFS stack protocols. The debut of this new measurement platform is big news, and you can learn all about it in a new post on the IPFS blog.
|
||||
|
||||
<a href="https://blog.ipfs.tech/2023-ipfs-observatory/" class="cta-button">Read the blog post</a>
|
||||
|
||||
|
||||
|
||||
## **Brand New on IPFS ✨**
|
||||
|
||||
[A Rusty Bootstrapper](https://blog.ipfs.tech/2023-rust-libp2p-based-ipfs-bootstrap-node/)
|
||||
|
||||
- As of July 13, 2023, one of the four "public good" IPFS bootstrap nodes operated by Protocol Labs has been running rust-libp2p-server instead of Kubo, which uses go-libp2p. rust-libp2p-server is a thin wrapper around rust-libp2p. We run both Kubo and rust-libp2p-server on IPFS bootstrap nodes to increase resilience. [Read more about it on the IPFS blog!](https://blog.ipfs.tech/2023-rust-libp2p-based-ipfs-bootstrap-node/)
|
||||
|
||||
[Dogfooding Announcement: IPFS-Companion Manifest v3 Changes](https://discuss.ipfs.tech/t/announcing-ipfs-companion-mv3-rc-beta/16442/7)
|
||||
|
||||
- The PL EngRes Ignite team has achieved a significant milestone – the completion of IPFS-Companion Manifest v3 changes! IPFS-Companion is browser extension that makes browsing the IPFS web simpler. These changes promise to greatly enhance compatibility with browsers going forward and offer performance improvements. [Read about it and get involved here!](https://discuss.ipfs.tech/t/announcing-ipfs-companion-mv3-rc-beta/16442/7)
|
||||
|
||||
[IPFS Events Planning Meeting](https://lu.ma/ipfseventsplanning)
|
||||
|
||||
- The events team is kicking off a new Events Planning Call today. If you're interested in joining or participating, you can find these meetings on the [IPFS Community Calendar](lu.ma/ipfs), or you can register directly at [lu.ma/ipfseventsplanning](lu.ma/ipfseventsplanning). Today's agenda will be to discuss timing for IPFS Camp and Thing for 2024. Timing will affect the locations that make the shortlist. [Join us here!](https://lu.ma/ipfseventsplanning)
|
||||
|
||||
[Boxo v0.11.0](https://github.com/ipfs/boxo/blob/release-v0.11.0/CHANGELOG.md)
|
||||
|
||||
## **Around the Ecosystem 🌎**
|
||||
|
||||
[Guide: Setting Up a Website on the Distributed Web using Distributed Press](https://medium.com/@lindsay_walker/setting-up-a-website-on-the-distributed-web-7eae22594303)
|
||||
|
||||
- Distributed Press is a tool used to easily host content on distributed, peer-to-peer protocols such as IPFS and Hypercore, using open source tools created by the Distributed Press project. Publishing a static site on distributed protocols means that your website is more resilient and likely to stand the test of time. [Learn how to do it here!](https://medium.com/@lindsay_walker/setting-up-a-website-on-the-distributed-web-7eae22594303)
|
||||
|
||||
[Anytype: A private hub for all your data](https://anytype.io/)
|
||||
|
||||
- Meet Anytype, a private hub for all your data: docs, tasks, files, bookmarks, contacts and more. It’s built on a new architecture that protects your privacy and data sovereignty, even when working across devices. Use it to create elegant dashboards, documents, and knowledge graphs. [Try it out here!](https://anytype.io/)
|
||||
|
||||
[Fleek Network announces new edge platform](https://twitter.com/fleek_net/status/1685997861907890176)
|
||||
|
||||
- Fleek Network's new platform utilizes IPFS/IPLD as the addressability and performance layer of data on the network. [Learn more here!](https://twitter.com/fleek_net/status/1685997861907890176)
|
||||
|
||||
[Admarus: A Peer-to-Peer Search Engine for IPFS](https://blog.admarus.net/blog/mvp-release/)
|
||||
|
||||
- A decentralized search engine for the decentralized web (specifically, IPFS). [Check it out here!](https://blog.admarus.net/blog/mvp-release/)
|
||||
|
||||
[Beloga: A Decentralized Blogging Platform](https://discuss.ipfs.tech/t/beloga-decentralized-blogging-platform-powered-by-ipfs/16727)
|
||||
|
||||
- This new blogging platform has IPFS at its core with posts being securely stored and decentralized, making them tamper-proof and censorship-resistant. [See it for yourself here!](https://discuss.ipfs.tech/t/beloga-decentralized-blogging-platform-powered-by-ipfs/16727)
|
||||
|
||||
[Filebase introduces custom comain support for dedicated IPFS gateways](https://filebase.com/blog/introducing-custom-domain-support-for-dedicated-ipfs-gateways/)
|
||||
|
||||
- With the introduction of custom domain support, users can now attach their domain names to their dedicated gateways, bolstering their brand consistency and accessibility. [Learn more about it in this blog post announcement!](https://filebase.com/blog/introducing-custom-domain-support-for-dedicated-ipfs-gateways/)
|
||||
|
||||
[IPFSnodes.com](https://ipfsnodes.com/)
|
||||
|
||||
- A community created dashboard with lots of data and information about the IPFS network and its nodes. [Take a look at it here!](https://ipfsnodes.com/)
|
||||
|
||||
[Open Data Hackathon](https://www.encode.club/open-data-hack)
|
||||
|
||||
- This upcoming hackathon features a $1,000 IPFS bounty. [Learn more and get involved here!](https://www.encode.club/open-data-hack)https://www.encode.club/open-data-hack
|
||||
|
||||
[The Evolution of Filecoin and IPFS: An Overview of Challenges and Future Opportunities](https://medium.com/filemarket-xyz/the-evolution-of-filecoin-and-ipfs-an-overview-of-challenges-and-future-opportunities-795ce237c4b6)
|
||||
|
||||
- A new article on FileMarket about the evolution of Filecoin and IPFS that is based on an AMA with Juan Benet during Filecoin Unleashed Paris 2023. Read through it here!
|
||||
@@ -1,52 +0,0 @@
|
||||
---
|
||||
title: Welcome to IPFS News 197!
|
||||
description: Featuring an announcement about the new Ecosystem Working Group and Kubo v0.22.0
|
||||
author: ''
|
||||
date: 2023-09-12
|
||||
permalink: "/newsletter-197"
|
||||
translationKey: ''
|
||||
header_image: "/ipfsnews.png"
|
||||
tags:
|
||||
- newsletter
|
||||
---
|
||||
|
||||
## **Introducing the Ecosystem Working Group 🔭**
|
||||
|
||||
Since its initial release over 9 years ago, IPFS has been stewarded by a variety of teams and individual contributors, both within and outside of Protocol Labs. More recently though, it has lacked a dedicated team focused on nothing other than the success of the IPFS ecosystem. It is with this reality in mind that we are excited to announce the formation of **[the brand new IPFS Ecosystem Working Group](https://blog.ipfs.tech/2023-introducing-the-ecosystem-working-group/)**!
|
||||
|
||||
<a href="https://blog.ipfs.tech/2023-introducing-the-ecosystem-working-group/" class="cta-button">Read the blog post</a>
|
||||
|
||||
## **Brand New on IPFS ✨**
|
||||
|
||||
[Kubo v0.22.0](https://github.com/ipfs/kubo/releases/tag/v0.22.0)
|
||||
|
||||
- Gateway: support for order= and dups= parameters (IPIP-412)
|
||||
- ipfs name publish now supports V2 only IPNS records
|
||||
- IPNS name resolution has been fixed
|
||||
- go-libp2p v0.29.0 update with smart dialing
|
||||
|
||||
[IPFSConnect Istanbul](https://istanbul2023.ipfsconnect.org/)
|
||||
|
||||
- Have you checked out [IPFSConnect](https://twitter.com/IPFSConnect) yet? It's a community-run meetup of developers and designers building on top of IPFS. Join us in Istanbul on Nov 16th for a day of workshops + talks! [Learn more here!](https://istanbul2023.ipfsconnect.org/)
|
||||
|
||||
## **Around the Ecosystem 🌎**
|
||||
|
||||
[LabWeek23 is happening November 13-17](https://23.labweek.io/)
|
||||
|
||||
- Have you booked your travel yet? [LabWeek23](https://23.labweek.io/) is happening in Istanbul, Türkiye, from November 13-17, alongside Devconnect! This is your chance to connect and collaborate with visionaries and teams that are domain leaders in ZK Proofs, AI and blockchain, DeSci, decentralized storage, gaming in Web3, public goods funding, cryptoeconomics, and much more. [Learn more about it here!](https://23.labweek.io/)
|
||||
|
||||
[A Beginner's Guide to IPFS Content Addressing](https://filebase.com/blog/a-beginners-guide-to-ipfs-content-addressing/)
|
||||
|
||||
- Learn how to harness the power of the InterPlanetary File System for seamless content distribution by checking out this comprehensive guide to IPFS content addressing by Filebase. [Read it here!](https://filebase.com/blog/a-beginners-guide-to-ipfs-content-addressing/)
|
||||
|
||||
[Fleek's new app is in closed alpha](https://blog.fleek.xyz/post/fleekxyz-alpha-release/)
|
||||
|
||||
- "The day is finally here–the first step of the new Fleek, both app and brand ⚡ Let’s set the stage: This is not the full release of the new Fleek app. Today marks the start of our initial closed testing phase, leading up to an open testing period, and later in September, the full v1 release of the new app." [Learn more in this blog post!](https://blog.fleek.xyz/post/fleekxyz-alpha-release/)
|
||||
|
||||
[New git-ipfs remote bridge](https://twitter.com/momack28/status/1697072752266706979?s=20)
|
||||
|
||||
- "Love git and IPFS? There's a new git-ipfs remote bridge that lets you snapshot new git releases to IPFS for self-hosting, immutable versioning, and decentralized replication. Go InterPlanetary!" [Check it out here!](https://github.com/ElettraSciComp/Git-IPFS-Remote-Bridge)
|
||||
|
||||
[Encrypted file support will be added to Cedalio soon](https://medium.com/@cedalio/product-update-uploading-files-has-never-been-easier-7b328def728a)
|
||||
|
||||
- "Introducing the ability to define file types within your GraphQL schema, while we handle the rest. To stay in sync with our company core values, we store files in IPFS, a decentralized peer-to-peer protocol for storing and sharing files across a distributed network. As of now, files stored in IPFS are not encrypted; however, we’re excited to announce that support for encryption will be added in early October." [Learn more via their product update!](https://medium.com/@cedalio/product-update-uploading-files-has-never-been-easier-7b328def728a)
|
||||
@@ -1,370 +1,308 @@
|
||||
---
|
||||
data:
|
||||
- title: 'Just released: Kubo 0.22.0!'
|
||||
date: "2023-08-08"
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/kubo/releases/tag/v0.22.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- kubo
|
||||
- title: 'Just released: Kubo 0.21.0!'
|
||||
date: "2023-07-03"
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/kubo/releases/tag/v0.21.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- kubo
|
||||
- title: 'Just released: Kubo 0.20.0!'
|
||||
date: "2023-05-09"
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/kubo/releases/tag/v0.20.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- kubo
|
||||
- title: 'Just released: Kubo 0.19.2!'
|
||||
date: "2023-05-03"
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/kubo/releases/tag/v0.19.2
|
||||
tags:
|
||||
- go-ipfs
|
||||
- kubo
|
||||
- title: 'Just released: Kubo 0.19.1!'
|
||||
date: "2023-04-05"
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/kubo/releases/tag/v0.19.1
|
||||
tags:
|
||||
- go-ipfs
|
||||
- kubo
|
||||
- title: 'Just released: Kubo 0.19.0!'
|
||||
date: "2023-03-20"
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/kubo/releases/tag/v0.19.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- kubo
|
||||
- title: 'Just released: Kubo 0.18.1!'
|
||||
date: "2023-01-30"
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/kubo/releases/tag/v0.18.1
|
||||
tags:
|
||||
- go-ipfs
|
||||
- kubo
|
||||
- title: 'Just released: Kubo 0.18.0!'
|
||||
date: '2023-01-23'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/kubo/releases/tag/v0.18.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- kubo
|
||||
- title: 'Just released: Kubo 0.17.0!'
|
||||
date: '2022-11-22'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/kubo/releases/tag/v0.17.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- kubo
|
||||
- title: js-ipfs 0.64.0
|
||||
date: '2022-09-07'
|
||||
publish_date: '2022-09-07T12:00:00+00:00'
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs-v0.64.0
|
||||
card_image: /header-image-js-ipfs-placeholder.png
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: js-ipfs 0.63.0
|
||||
date: '2022-05-22'
|
||||
publish_date: '2022-05-22T12:00:00+00:00'
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs-v0.63.0
|
||||
card_image: /header-image-js-ipfs-placeholder.png
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: js-ipfs 0.62.0
|
||||
date: '2022-01-27'
|
||||
publish_date: '2022-01-27T12:00:00+00:00'
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs-v0.62.0
|
||||
card_image: /header-image-js-ipfs-placeholder.png
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: js-ipfs 0.61.0
|
||||
date: '2021-12-15'
|
||||
publish_date: '2021-12-21T12:00:00+00:00'
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.61.0
|
||||
card_image: /header-image-js-ipfs-placeholder.png
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: js-libp2p v0.40.0
|
||||
date: '2022-10-17'
|
||||
publish_date: '2022-10-17T12:00:00+00:00'
|
||||
path: https://github.com/libp2p/js-libp2p/releases/tag/v0.40.0
|
||||
card_image: /header-image-libp2p.png
|
||||
tags:
|
||||
- libp2p
|
||||
- title: js-libp2p v0.39.0
|
||||
date: '2022-09-07'
|
||||
publish_date: '2022-09-07T12:00:00+00:00'
|
||||
path: https://github.com/libp2p/js-libp2p/releases/tag/v0.39.0
|
||||
card_image: /header-image-libp2p.png
|
||||
tags:
|
||||
- libp2p
|
||||
- title: js-libp2p v0.38.0
|
||||
date: '2022-08-17'
|
||||
publish_date: '2022-08-17T12:00:00+00:00'
|
||||
path: https://github.com/libp2p/js-libp2p/releases/tag/v0.38.0
|
||||
card_image: /header-image-libp2p.png
|
||||
tags:
|
||||
- libp2p
|
||||
- title: 'Just released: Kubo 0.16.0!'
|
||||
date: '2022-10-04'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/kubo/releases/tag/v0.16.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- title: 'Just released: Kubo (formerly go-ipfs) 0.15.0!'
|
||||
date: '2022-08-30'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/kubo/releases/tag/v0.15.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- kubo
|
||||
- title: Kubo (formerly go-ipfs) v0.14.0 Release is out!
|
||||
date: '2022-07-21'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/kubo/releases/tag/v0.14.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- kubo
|
||||
- title: go-ipfs 0.13.0 Release
|
||||
date: '2022-06-09'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.13.0
|
||||
tags:
|
||||
- browsers
|
||||
- libp2p
|
||||
- security
|
||||
- gateways
|
||||
- CID
|
||||
- Docker
|
||||
- IPLD
|
||||
- go-ipfs
|
||||
- title: js-libp2p v0.37.0
|
||||
date: '2022-05-16'
|
||||
publish_date: null
|
||||
path: https://github.com/libp2p/js-libp2p/releases/tag/v0.37.0
|
||||
card_image: /header-image-libp2p.png
|
||||
tags:
|
||||
- libp2p
|
||||
- title: go-ipfs 0.12.0 Release
|
||||
date: '2022-02-18'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.12.0
|
||||
tags:
|
||||
- blockstore
|
||||
- go-ipfs
|
||||
- IPFS Desktop
|
||||
- title: js-libp2p v0.36.0
|
||||
date: '2022-01-25'
|
||||
publish_date: null
|
||||
path: https://github.com/libp2p/js-libp2p/releases/tag/v0.36.0
|
||||
card_image: /header-image-libp2p.png
|
||||
tags:
|
||||
- libp2p
|
||||
- title: go-ipfs 0.11.0 Release
|
||||
date: '2021-12-09'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.11.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- title: js-ipfs 0.60.0
|
||||
date: '2021-11-12'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.60.0
|
||||
card_image: /header-image-js-ipfs-placeholder.png
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: js-ipfs 0.59.0
|
||||
date: '2021-09-24'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.59.0
|
||||
card_image: /header-image-js-ipfs-placeholder.png
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: go-ipfs v0.10.0 has been released!
|
||||
date: '2021-10-01'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.10.0
|
||||
tags:
|
||||
- Bitswap
|
||||
- go-ipfs
|
||||
- IPLD
|
||||
- title: js-ipfs 0.58.0
|
||||
date: '2021-08-17'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.58.0
|
||||
card_image: /header-image-js-ipfs-placeholder.png
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: IPFS Cluster 0.14.1
|
||||
date: '2021-08-16'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/ipfs-cluster/releases/tag/v0.14.1
|
||||
card_image: /077-collaborative-clusters-header-image.png
|
||||
tags:
|
||||
- IPFS Cluster
|
||||
- title: js-ipfs 0.57.0
|
||||
date: '2021-08-11'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.57.0
|
||||
card_image: /header-image-js-ipfs-placeholder.png
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: js-ipfs 0.56.0
|
||||
date: '2021-07-27'
|
||||
publish_date: '2021-07-27T12:00:00+00:00'
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.56.0
|
||||
card_image: /header-image-js-ipfs-placeholder.png
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: go-ipfs 0.9.1
|
||||
date: '2021-07-21'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.9.1
|
||||
tags:
|
||||
- go-ipfs
|
||||
- title: IPFS Cluster 0.14.0
|
||||
date: '2021-07-09'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/ipfs-cluster/blob/master/CHANGELOG.md
|
||||
tags:
|
||||
- IPFS Cluster
|
||||
- title: go-ipfs 0.9.0
|
||||
date: '2021-06-22'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.9.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- title: js-ipfs 0.55.1
|
||||
date: '2021-05-11'
|
||||
publish_date: '2021-05-11T12:00:00+00:00'
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.55.1
|
||||
card_image: /header-image-js-ipfs-placeholder.png
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: js-ipfs 0.55.0
|
||||
date: '2021-05-10'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.55.0
|
||||
card_image: /header-image-js-ipfs-placeholder.png
|
||||
tags:
|
||||
- breaking change
|
||||
- js-ipfs
|
||||
- title: IPFS Desktop v0.15.0
|
||||
date: '2021-05-05'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/ipfs-desktop/releases/tag/v0.15.0
|
||||
tags:
|
||||
- pinning
|
||||
- Windows
|
||||
- IPFS Desktop
|
||||
- title: ipfs-webui v2.12.0
|
||||
date: '2021-04-19'
|
||||
publish_date: null
|
||||
path: https://github.com/ipfs/ipfs-webui/releases/tag/v2.12.0
|
||||
tags:
|
||||
- release notes
|
||||
- title: IPFS Remote Pinning GitHub Action
|
||||
date: '2021-03-21'
|
||||
path: https://github.com/marketplace/actions/ipfs-remote-pinning
|
||||
card_image: /2021-03-23-cardheader-ipfs-remote-pinning.png
|
||||
tags:
|
||||
- pinning
|
||||
- title: js-ipfs 0.54.3
|
||||
date: '2021-03-09'
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.54.3
|
||||
tags:
|
||||
- js-ipfs
|
||||
- AEgir
|
||||
- title: IPFS Companion 2.17.3
|
||||
date: '2021-01-29'
|
||||
path: https://github.com/ipfs-shipyard/ipfs-companion/releases/tag/v2.17.3
|
||||
tags:
|
||||
- IPFS Companion
|
||||
card_image: /release-notes-placeholder.png
|
||||
- title: IPFS Companion 2.17.2
|
||||
date: '2021-01-20'
|
||||
path: https://github.com/ipfs-shipyard/ipfs-companion/releases/tag/v2.17.2
|
||||
tags:
|
||||
- IPFS Companion
|
||||
card_image: /release-notes-placeholder.png
|
||||
- title: IPFS Desktop 0.14.0
|
||||
date: '2021-02-23'
|
||||
path: https://github.com/ipfs-shipyard/ipfs-desktop/releases/tag/v0.14.0
|
||||
tags:
|
||||
- IPFS Desktop
|
||||
card_image: /release-notes-placeholder.png
|
||||
- title: go-ipfs 0.8.0
|
||||
date: '2021-02-18'
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.8.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
card_image: /release-notes-placeholder.png
|
||||
- title: IPFS Cluster 0.13.1
|
||||
date: '2021-01-14'
|
||||
path: https://github.com/ipfs/ipfs-cluster/releases/tag/v0.13.1
|
||||
tags:
|
||||
- IPFS Cluster
|
||||
card_image: /release-notes-placeholder.png
|
||||
- name: IPFS Companion 2.17.0
|
||||
title: IPFS Companion 2.17.0
|
||||
path: https://github.com/ipfs-shipyard/ipfs-companion/releases/tag/v2.17.0
|
||||
date: '2021-01-11'
|
||||
tags:
|
||||
- IPFS Companion
|
||||
card_image: /release-notes-placeholder.png
|
||||
- name: go-libp2p 0.13.0
|
||||
title: go-libp2p 0.13.0
|
||||
path: https://github.com/libp2p/go-libp2p/releases/tag/v0.13.0
|
||||
date: '2020-12-19'
|
||||
tags:
|
||||
- libp2p
|
||||
card_image: /release-notes-placeholder.png
|
||||
- name: js-libp2p 0.30.0
|
||||
title: js-libp2p 0.30.0
|
||||
path: https://github.com/libp2p/js-libp2p/releases/tag/v0.30.0
|
||||
date: '2020-12-16'
|
||||
tags:
|
||||
- libp2p
|
||||
card_image: /release-notes-placeholder.png
|
||||
- name: js-ipfs 0.52.3
|
||||
title: js-ipfs 0.52.3
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.52.3
|
||||
date: '2020-12-16'
|
||||
tags:
|
||||
- js-ipfs
|
||||
- name: IPFS Desktop 0.13.2
|
||||
title: IPFS Desktop 0.13.2
|
||||
path: https://github.com/ipfs-shipyard/ipfs-desktop/releases/tag/v0.13.2
|
||||
date: '2020-10-12'
|
||||
tags:
|
||||
- IPFS Desktop
|
||||
- name: IPFS Web UI 2.11.4
|
||||
title: IPFS Web UI 2.11.4
|
||||
path: https://github.com/ipfs-shipyard/ipfs-webui/releases/tag/v2.11.4
|
||||
date: '2020-10-12'
|
||||
tags:
|
||||
- IPFS Web UI
|
||||
- name: go-ipfs 0.7.0
|
||||
title: go-ipfs 0.7.0
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.7.0
|
||||
date: '2020-10-12'
|
||||
tags:
|
||||
- go-ipfs
|
||||
- name: IPFS Cluster 0.13.0
|
||||
title: IPFS Cluster 0.13.0
|
||||
path: https://github.com/ipfs/ipfs-cluster/releases/tag/v0.13.0
|
||||
date: '2020-10-12'
|
||||
tags:
|
||||
- IPFS Cluster
|
||||
title: Release Notes
|
||||
type: Release notes
|
||||
sitemap:
|
||||
exclude: true
|
||||
exclude: true
|
||||
data:
|
||||
- title: js-ipfs 0.64.0
|
||||
date: 2022-09-07
|
||||
publish_date: 2022-09-07T12:00:00+00:00
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs-v0.64.0
|
||||
card_image: "/header-image-js-ipfs-placeholder.png"
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: js-ipfs 0.63.0
|
||||
date: 2022-05-22
|
||||
publish_date: 2022-05-22T12:00:00+00:00
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs-v0.63.0
|
||||
card_image: "/header-image-js-ipfs-placeholder.png"
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: js-ipfs 0.62.0
|
||||
date: 2022-01-27
|
||||
publish_date: 2022-01-27T12:00:00+00:00
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs-v0.62.0
|
||||
card_image: "/header-image-js-ipfs-placeholder.png"
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: js-ipfs 0.61.0
|
||||
date: 2021-12-15
|
||||
publish_date: 2021-12-21T12:00:00+00:00
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.61.0
|
||||
card_image: "/header-image-js-ipfs-placeholder.png"
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: js-libp2p v0.40.0
|
||||
date: 2022-10-17
|
||||
publish_date: 2022-10-17T12:00:00+00:00
|
||||
path: https://github.com/libp2p/js-libp2p/releases/tag/v0.40.0
|
||||
card_image: "/header-image-libp2p.png"
|
||||
tags:
|
||||
- libp2p
|
||||
- title: js-libp2p v0.39.0
|
||||
date: 2022-09-07
|
||||
publish_date: 2022-09-07T12:00:00+00:00
|
||||
path: https://github.com/libp2p/js-libp2p/releases/tag/v0.39.0
|
||||
card_image: "/header-image-libp2p.png"
|
||||
tags:
|
||||
- libp2p
|
||||
- title: js-libp2p v0.38.0
|
||||
date: 2022-08-17
|
||||
publish_date: 2022-08-17T12:00:00+00:00
|
||||
path: https://github.com/libp2p/js-libp2p/releases/tag/v0.38.0
|
||||
card_image: "/header-image-libp2p.png"
|
||||
tags:
|
||||
- libp2p
|
||||
- title: 'Just released: Kubo 0.16.0!'
|
||||
date: 2022-10-04
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/kubo/releases/tag/v0.16.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- title: 'Just released: Kubo (formerly go-ipfs) 0.15.0!'
|
||||
date: 2022-08-30
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/kubo/releases/tag/v0.15.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- kubo
|
||||
- title: Kubo (formerly go-ipfs) v0.14.0 Release is out!
|
||||
date: 2022-07-21
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/kubo/releases/tag/v0.14.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- kubo
|
||||
- title: go-ipfs 0.13.0 Release
|
||||
date: 2022-06-09
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.13.0
|
||||
tags:
|
||||
- browsers
|
||||
- libp2p
|
||||
- security
|
||||
- gateways
|
||||
- CID
|
||||
- Docker
|
||||
- IPLD
|
||||
- go-ipfs
|
||||
- title: js-libp2p v0.37.0
|
||||
date: 2022-05-16
|
||||
publish_date:
|
||||
path: https://github.com/libp2p/js-libp2p/releases/tag/v0.37.0
|
||||
card_image: "/header-image-libp2p.png"
|
||||
tags:
|
||||
- libp2p
|
||||
- title: go-ipfs 0.12.0 Release
|
||||
date: 2022-02-18
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.12.0
|
||||
tags:
|
||||
- blockstore
|
||||
- go-ipfs
|
||||
- IPFS Desktop
|
||||
- title: js-libp2p v0.36.0
|
||||
date: 2022-01-25
|
||||
publish_date:
|
||||
path: https://github.com/libp2p/js-libp2p/releases/tag/v0.36.0
|
||||
card_image: "/header-image-libp2p.png"
|
||||
tags:
|
||||
- libp2p
|
||||
- title: go-ipfs 0.11.0 Release
|
||||
date: 2021-12-09
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.11.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- title: js-ipfs 0.60.0
|
||||
date: 2021-11-12
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.60.0
|
||||
card_image: "/header-image-js-ipfs-placeholder.png"
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: js-ipfs 0.59.0
|
||||
date: 2021-09-24
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.59.0
|
||||
card_image: "/header-image-js-ipfs-placeholder.png"
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: go-ipfs v0.10.0 has been released!
|
||||
date: 2021-10-01
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.10.0
|
||||
tags:
|
||||
- Bitswap
|
||||
- go-ipfs
|
||||
- IPLD
|
||||
- title: js-ipfs 0.58.0
|
||||
date: 2021-08-17
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.58.0
|
||||
card_image: "/header-image-js-ipfs-placeholder.png"
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: IPFS Cluster 0.14.1
|
||||
date: 2021-08-16
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/ipfs-cluster/releases/tag/v0.14.1
|
||||
card_image: "/077-collaborative-clusters-header-image.png"
|
||||
tags:
|
||||
- IPFS Cluster
|
||||
- title: js-ipfs 0.57.0
|
||||
date: 2021-08-11
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.57.0
|
||||
card_image: "/header-image-js-ipfs-placeholder.png"
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: js-ipfs 0.56.0
|
||||
date: 2021-07-27
|
||||
publish_date: 2021-07-27T12:00:00.000+00:00
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.56.0
|
||||
card_image: "/header-image-js-ipfs-placeholder.png"
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: go-ipfs 0.9.1
|
||||
date: 2021-07-21
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.9.1
|
||||
tags:
|
||||
- go-ipfs
|
||||
- title: IPFS Cluster 0.14.0
|
||||
date: 2021-07-09
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/ipfs-cluster/blob/master/CHANGELOG.md
|
||||
tags:
|
||||
- IPFS Cluster
|
||||
- title: go-ipfs 0.9.0
|
||||
date: 2021-06-22
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.9.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
- title: js-ipfs 0.55.1
|
||||
date: 2021-05-11
|
||||
publish_date: 2021-05-11T12:00:00.000+00:00
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.55.1
|
||||
card_image: "/header-image-js-ipfs-placeholder.png"
|
||||
tags:
|
||||
- js-ipfs
|
||||
- title: js-ipfs 0.55.0
|
||||
date: 2021-05-10
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.55.0
|
||||
card_image: "/header-image-js-ipfs-placeholder.png"
|
||||
tags:
|
||||
- breaking change
|
||||
- js-ipfs
|
||||
- title: IPFS Desktop v0.15.0
|
||||
date: 2021-05-05
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/ipfs-desktop/releases/tag/v0.15.0
|
||||
tags:
|
||||
- pinning
|
||||
- Windows
|
||||
- IPFS Desktop
|
||||
- title: ipfs-webui v2.12.0
|
||||
date: 2021-04-19
|
||||
publish_date:
|
||||
path: https://github.com/ipfs/ipfs-webui/releases/tag/v2.12.0
|
||||
tags:
|
||||
- release notes
|
||||
- title: IPFS Remote Pinning GitHub Action
|
||||
date: 2021-03-21
|
||||
path: https://github.com/marketplace/actions/ipfs-remote-pinning
|
||||
card_image: "/2021-03-23-cardheader-ipfs-remote-pinning.png"
|
||||
tags:
|
||||
- pinning
|
||||
- title: js-ipfs 0.54.3
|
||||
date: 2021-03-09
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.54.3
|
||||
tags:
|
||||
- js-ipfs
|
||||
- AEgir
|
||||
- title: IPFS Companion 2.17.3
|
||||
date: 2021-01-29
|
||||
path: https://github.com/ipfs-shipyard/ipfs-companion/releases/tag/v2.17.3
|
||||
tags:
|
||||
- IPFS Companion
|
||||
card_image: "/release-notes-placeholder.png"
|
||||
- title: IPFS Companion 2.17.2
|
||||
date: 2021-01-20
|
||||
path: https://github.com/ipfs-shipyard/ipfs-companion/releases/tag/v2.17.2
|
||||
tags:
|
||||
- IPFS Companion
|
||||
card_image: "/release-notes-placeholder.png"
|
||||
- title: IPFS Desktop 0.14.0
|
||||
date: 2021-02-23
|
||||
path: https://github.com/ipfs-shipyard/ipfs-desktop/releases/tag/v0.14.0
|
||||
tags:
|
||||
- IPFS Desktop
|
||||
card_image: "/release-notes-placeholder.png"
|
||||
- title: go-ipfs 0.8.0
|
||||
date: 2021-02-18
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.8.0
|
||||
tags:
|
||||
- go-ipfs
|
||||
card_image: "/release-notes-placeholder.png"
|
||||
- title: IPFS Cluster 0.13.1
|
||||
date: 2021-01-14
|
||||
path: https://github.com/ipfs/ipfs-cluster/releases/tag/v0.13.1
|
||||
tags:
|
||||
- IPFS Cluster
|
||||
card_image: "/release-notes-placeholder.png"
|
||||
- name: IPFS Companion 2.17.0
|
||||
title: IPFS Companion 2.17.0
|
||||
path: https://github.com/ipfs-shipyard/ipfs-companion/releases/tag/v2.17.0
|
||||
date: 2021-01-11
|
||||
tags:
|
||||
- IPFS Companion
|
||||
card_image: "/release-notes-placeholder.png"
|
||||
- name: go-libp2p 0.13.0
|
||||
title: go-libp2p 0.13.0
|
||||
path: https://github.com/libp2p/go-libp2p/releases/tag/v0.13.0
|
||||
date: 2020-12-19
|
||||
tags:
|
||||
- libp2p
|
||||
card_image: "/release-notes-placeholder.png"
|
||||
- name: js-libp2p 0.30.0
|
||||
title: js-libp2p 0.30.0
|
||||
path: https://github.com/libp2p/js-libp2p/releases/tag/v0.30.0
|
||||
date: 2020-12-16
|
||||
tags:
|
||||
- libp2p
|
||||
card_image: "/release-notes-placeholder.png"
|
||||
- name: js-ipfs 0.52.3
|
||||
title: js-ipfs 0.52.3
|
||||
path: https://github.com/ipfs/js-ipfs/releases/tag/ipfs%400.52.3
|
||||
date: 2020-12-16
|
||||
tags:
|
||||
- js-ipfs
|
||||
- name: IPFS Desktop 0.13.2
|
||||
title: IPFS Desktop 0.13.2
|
||||
path: https://github.com/ipfs-shipyard/ipfs-desktop/releases/tag/v0.13.2
|
||||
date: 2020-10-12
|
||||
tags:
|
||||
- IPFS Desktop
|
||||
- name: IPFS Web UI 2.11.4
|
||||
title: IPFS Web UI 2.11.4
|
||||
path: https://github.com/ipfs-shipyard/ipfs-webui/releases/tag/v2.11.4
|
||||
date: 2020-10-12
|
||||
tags:
|
||||
- IPFS Web UI
|
||||
- name: go-ipfs 0.7.0
|
||||
title: go-ipfs 0.7.0
|
||||
path: https://github.com/ipfs/go-ipfs/releases/tag/v0.7.0
|
||||
date: 2020-10-12
|
||||
tags:
|
||||
- go-ipfs
|
||||
- name: IPFS Cluster 0.13.0
|
||||
title: IPFS Cluster 0.13.0
|
||||
path: https://github.com/ipfs/ipfs-cluster/releases/tag/v0.13.0
|
||||
date: 2020-10-12
|
||||
tags:
|
||||
- IPFS Cluster
|
||||
|
||||
---
|
||||
|
||||
@@ -30,8 +30,8 @@ This blog entry intends to give an update on what is happening with IPFS develop
|
||||
- [Seize and Leverage New Browser-Friendly P2P Transports](#seize-and-leverage-new-browser-friendly-p2p-transports)
|
||||
- [Support Fully Speced Delegated Routing Protocols and Endpoints](#support-fully-speced-delegated-routing-protocols-and-endpoints)
|
||||
- [PL Delegate and Preload Nodes Will Be Shutting Down](#pl-delegate-and-preload-nodes-will-be-shutting-down)
|
||||
- [Release Helia in 2023](#release-helia-in-2023)
|
||||
- [Pause js-ipfs Maintenance Once Helia Is Released](#pause-js-ipfs-maintenance-once-helia-is-released)
|
||||
- [Release Pomegranate in 2023](#release-pomegranate-in-2023)
|
||||
- [Pause js-ipfs Maintenance Once Pomegrate Is Released](#pause-js-ipfs-maintenance-once-pomegrate-is-released)
|
||||
- [A New Name Is Coming](#a-new-name-is-coming)
|
||||
- [Doc Updates Galore](#doc-updates-galore)
|
||||
- [🗺 Timeline](#%F0%9F%97%BA-timeline)
|
||||
@@ -42,11 +42,11 @@ This blog entry intends to give an update on what is happening with IPFS develop
|
||||
To help with this update, the following names and terms will be used to aid with clarity:
|
||||
|
||||
- [Kubo](https://github.com/ipfs/kubo) – This project was formerly known as _go-ipfs_. See [here](https://github.com/ipfs/kubo/issues/8959) for more info.
|
||||
- [js-ipfs](https://github.com/ipfs/js-ipfs) - This is the long-standing IPFS implementation written in JS. As described below, we will be deprecating it after Helia is released. We’re currently not planning to rename this implementation [like we did with Kubo](https://github.com/ipfs/ipfs/issues/470) given its limited lifespan.
|
||||
- [Helia](https://github.com/ipfs/Helia) - This is a [to-be-created IPFS implementation in JS](https://github.com/ipfs/helia/issues/2) that is discussed below. The final name is TBD (to be determined), and you can track the naming effort [here](https://github.com/ipfs/helia/issues/3). While it will use many of the underlying libraries of js-ipfs (e.g., [js-libp2p](https://github.com/libp2p/js-libp2p), [js-ipfs-bitswap](https://github.com/ipfs/js-ipfs-bitswap)), it is a separate project with a different API.
|
||||
- IPFS-in-JS - This refers broadly to the development of IPFS using the JavaScript and TypeScript languages. It doesn’t mean the “js-ipfs” project or “Helia”.
|
||||
- [js-ipfs](https://github.com/ipfs/js-ipfs) - This is the long-standing IPFS implementation written in JS. As described below, we will be deprecating it after Pomegranate is released. We’re currently not planning to rename this implementation [like we did with Kubo](https://github.com/ipfs/ipfs/issues/470) given its limited lifespan.
|
||||
- [Pomegranate](https://github.com/ipfs/pomegranate) - This is a [to-be-created IPFS implementation in JS](https://github.com/ipfs/pomegranate/issues/2) that is discussed below. The final name is TBD (to be determined), and you can track the naming effort [here](https://github.com/ipfs/pomegranate/issues/3). While it will use many of the underlying libraries of js-ipfs (e.g., [js-libp2p](https://github.com/libp2p/js-libp2p), [js-ipfs-bitswap](https://github.com/ipfs/js-ipfs-bitswap)), it is a separate project with a different API.
|
||||
- IPFS-in-JS - This refers broadly to the development of IPFS using the JavaScript and TypeScript languages. It doesn’t mean the “js-ipfs” project or “Pomegranate”.
|
||||
- Delegate nodes - These are nodes that expose the [`/api/v0/dht/*` endpoints of the Kubo RPC API](https://docs.ipfs.tech/reference/kubo/rpc/#api-v0-dht-findpeer) for delegated routing. Because **js-ipfs** nodes don’t have the DHT enabled by default and wouldn’t make good DHT servers in browsers anyways, they need the help of **delegate** nodes to resolve DHT queries.
|
||||
- Preload nodes - These are nodes that expose the `/api/v0/refs` [endpoint of the Kubo RPC API](https://docs.ipfs.tech/reference/kubo/rpc/#api-v0-refs) which can be called so that the remote node will fetch CIDs (but not pin). This is necessary to ensure that blocks that are added in the browser are *preloaded* onto a long-running IPFS node so that it’s made available to the rest of the network. Preload nodes garbage collect those blocks after a period.
|
||||
- Preload nodes - These are nodes that expose the `/api/v1/refs` [endpoint of the Kubo RPC API](https://docs.ipfs.tech/reference/kubo/rpc/#api-v0-refs) which can be called so that the remote node will fetch CIDs (but not pin). This is necessary to ensure that blocks that are added in the browser are *preloaded* onto a long-running IPFS node so that it’s made available to the rest of the network. Preload nodes garbage collect those blocks after a period.
|
||||
|
||||
## ⏳ IPFS-in-JS Development History
|
||||
|
||||
@@ -158,7 +158,7 @@ We never had full compatibility between Kubo and js-ipfs, we don’t think we ca
|
||||
In practical terms, this translates to:
|
||||
|
||||
1. ipfs-http-client will remain the RPC-over-HTTP API for controlling js-ipfs (you can also use ipfs-grpc-client over WebSockets). The current js-ipfs RPC APIs will be maintained until js-ipfs support ceases (discussed below).
|
||||
2. With investment in Helia, a new RPC API for Helia will emerge.
|
||||
2. With investment in Pomegranate, a new RPC API for Pomegranate will emerge.
|
||||
3. We won’t test that ipfs-http-client has compatibility with recent versions of Kubo.
|
||||
4. If you want to control a Kubo node via JS, use the Kubo-specific library [js-kubo-rpc-client](https://github.com/ipfs/js-kubo-rpc-client) (api).
|
||||
|
||||
@@ -182,16 +182,16 @@ Given the new browser-friendly p2p transports discussed above, we’ll shut down
|
||||
|
||||
For delegated routing, one can configure [Reframe](https://blog.ipfs.tech/2022-09-02-introducing-reframe/) endpoints. When it comes to providing content from a browser node, it will be up to developers to account for user behavior like closing tabs or laptop lids. The general recommendation is to either run your own preload node or upload content explicitly to a pinning service for providing.
|
||||
|
||||
### Release Helia in 2023
|
||||
### Release Pomegranate in 2023
|
||||
|
||||
Helia is the to-be-developed IPFS implementation with all that we’ve learned over the last 8 years while leveraging what is available to us in JS runtime.
|
||||
Pomegranate is the to-be-developed IPFS implementation with all that we’ve learned over the last 8 years while leveraging what is available to us in JS runtime.
|
||||
|
||||
Some defining attributes include:
|
||||
|
||||
1. Web-first isomorphic API - run in browsers, electron, node, deno, bun, etc - no node.js APIs, only standard JavaScript (e.g. web streams, not node streams, Uint8Arrays not Buffers). Node APIs will only be considered for special cases like mDNS.
|
||||
2. Leaner API not tied to the legacy “core API” concept - Helia will not have API compatibility with js-ipfs. It will expose a more ergonomic JS-developer-first API than what we have with the js-ipfs “core API” that was heavily influenced by Kubo. (One can also create an adapter from the “core API” to Helia’s API if they want to drop Helia to their existing application using js-ipfs’ ipfs-core.)
|
||||
2. Leaner API not tied to the legacy “core API” concept - Pomegranate will not have API compatibility with js-ipfs. It will expose a more ergonomic JS-developer-first API than what we have with the js-ipfs “core API” that was heavily influenced by Kubo. (One can also create an adapter from the “core API” to Pomegranate’s API if they want to drop Pomegranate to their existing application using js-ipfs’ ipfs-core.)
|
||||
3. ESM and TypeScript only - There’s no more debate on the utility of these for JS development. We’ll adopt them from day one.
|
||||
4. Leverage existing interplanetary libraries - While we’re moving away from the interface and composition in js-ipfs, we’re not abandoning the underlying layers like js-libp2p, js-bitswap, etc. Those libraries have received a lot of maintenance attention in the last 18 months (including TypeScript and ESM updates) and are battle-tested in production. We will depend on them in Helia as well.
|
||||
4. Leverage existing interplanetary libraries - While we’re moving away from the interface and composition in js-ipfs, we’re not abandoning the underlying layers like js-libp2p, js-bitswap, etc. Those libraries have received a lot of maintenance attention in the last 18 months (including TypeScript and ESM updates) and are battle-tested in production. We will depend on them in Pomegranate as well.
|
||||
5. Unified file API - high-level commands that act like a filesystem and return CIDs. For example:
|
||||
|
||||
```jsx
|
||||
@@ -205,34 +205,32 @@ Some defining attributes include:
|
||||
```
|
||||
|
||||
6. Expose a block API for low-level IPLD operations.
|
||||
7. Focus on the browser use case - We won’t do anything that precludes operating in NodeJS or a cloud service worker, but by default, we will prioritize delivery paths that deliver browser functionality sooner. This is because the browser runtime is the unique runtime the Helia IPFS implementation can enable that other implementations can’t. As a result, it means there aren’t plans to invest in things like a JS implementation of the HTTP Gateway spec. We’ll let other implementations like Kubo, Iroh, etc. pursue that use case.
|
||||
8. Enable configurable levels of delegation. With routing, retrieval, and providing there will be varying levels of delegating from none (all handled by the local Helia node) to full (all handled by [HTTP Gateways](https://docs.ipfs.tech/reference/http/gateway/) and [Pinning Services](https://docs.ipfs.tech/how-to/work-with-pinning-services)).
|
||||
7. Focus on the browser use case - We won’t do anything that precludes operating in NodeJS or a cloud service worker, but by default, we will prioritize delivery paths that deliver browser functionality sooner. This is because the browser runtime is the unique runtime the Pomegranate IPFS implementation can enable that other implementations can’t. As a result, it means there aren’t plans to invest in things like a JS implementation of the HTTP Gateway spec. We’ll let other implementations like Kubo, Iroh, etc. pursue that use case.
|
||||
8. Enable configurable levels of delegation. With routing, retrieval, and providing there will be varying levels of delegating from none (all handled by the local Pomegranate node) to full (all handled by [HTTP Gateways](https://docs.ipfs.tech/reference/http/gateway/) and [Pinning Services](https://docs.ipfs.tech/how-to/work-with-pinning-services)).
|
||||
|
||||
### Pause js-ipfs Maintenance Once Helia Is Released
|
||||
### Pause js-ipfs Maintenance Once Pomegrate Is Released
|
||||
|
||||
Shortly after you can add and cat files across the network with Helia, [PL EngRes](https://pl-strflt.notion.site/PL-EngRes-Public-b5086aea86ed4f81bc7d0721c6935e1e) will cease maintenance on js-ipfs. In the absence of an established group with a credible track record to take js-ipfs over, the community is welcome to fork js-ipfs and maintain the fork. (We want to avoid issues that can occur with casually giving away publishing rights.)
|
||||
Shortly after you can add and cat files across the network with Pomegranate, [PL EngRes](https://pl-strflt.notion.site/PL-EngRes-Public-b5086aea86ed4f81bc7d0721c6935e1e) will cease maintenance on js-ipfs. In the absence of an established group with a credible track record to take js-ipfs over, the community is welcome to fork js-ipfs and maintain the fork. (We want to avoid issues that can occur with casually giving away publishing rights.)
|
||||
|
||||
As discussed before, **we are not** ceasing support and development of many of the libraries that js-ipfs depends on like js-libp2p and js-bitswap. These projects will be actively maintained as core dependencies to Helia and other projects.
|
||||
As discussed before, **we are not** ceasing support and development of many of the libraries that js-ipfs depends on like js-libp2p and js-bitswap. These projects will be actively maintained as core dependencies to Pomegranate and other projects.
|
||||
|
||||
### A New Name Is Coming
|
||||
|
||||
As outlined [here](https://github.com/ipfs/ipfs/issues/470), Protocol Labs wants to make space for additional IPFS implementations to be made, including in JS. We want to make it clear that js-ipfs is not IPFS and that js-ipfs is not **_the_** IPFS implementation in JS. go-ipfs successfully made this transition earlier in 2022 with its [minimal rename to Kubo](https://github.com/ipfs/kubo/issues/8959). We will certainly not make the same name-squatting mistake with a new implementation like Helia. Details and plans will be shared [here](https://github.com/ipfs/ipfs/issues/470) and in the [IPFS forums](https://discuss.ipfs.tech).
|
||||
As outlined [here](https://github.com/ipfs/ipfs/issues/470), Protocol Labs wants to make space for additional IPFS implementations to be made, including in JS. We want to make it clear that js-ipfs is not IPFS and that js-ipfs is not **_the_** IPFS implementation in JS. go-ipfs successfully made this transition earlier in 2022 with its [minimal rename to Kubo](https://github.com/ipfs/kubo/issues/8959). We will certainly not make the same name-squatting mistake with a new implementation like Pomegranate. Details and plans will be shared [here](https://github.com/ipfs/ipfs/issues/470) and in the [IPFS forums](https://discuss.ipfs.tech).
|
||||
|
||||
### Doc Updates Galore
|
||||
|
||||
From [dedicated websites](https://js.ipfs.tech/), [examples](https://github.com/ipfs-examples/js-ipfs-examples), to [official docs](https://docs.ipfs.tech/reference/js/api/), and [courses](https://proto.school/course/ipfs), many places will need updating in light of new names and implementations. This is going to be a sizable undertaking that hasn’t been scoped out yet. This will be tracked [here](https://github.com/ipfs/Helia/issues/4).
|
||||
From [dedicated websites](https://js.ipfs.tech/), [examples](https://github.com/ipfs-examples/js-ipfs-examples), to [official docs](https://docs.ipfs.tech/reference/js/api/), and [courses](https://proto.school/course/ipfs), many places will need updating in light of new names and implementations. This is going to be a sizable undertaking that hasn’t been scoped out yet. This will be tracked [here](https://github.com/ipfs/pomegranate/issues/4).
|
||||
|
||||
## 🗺 Timeline
|
||||
|
||||
The timeline for enacting all of the above is still actively being figured out. We’ll be updating the [proposed roadmap](https://github.com/ipfs/Helia/blob/main/ROADMAP.md).
|
||||
The timeline for enacting all of the above is still actively being figured out. We’ll be updating the [proposed roadmap](https://github.com/ipfs/pomegranate/blob/main/ROADMAP.md).
|
||||
|
||||
## 🤝 Ways You Can Help
|
||||
|
||||
1. 🗳 Propose a [name for the new “Helia” JS library](https://github.com/ipfs/Helia/issues/3) and cast your votes.
|
||||
2. 🗣 Give feedback on the [Helia roadmap](https://github.com/ipfs/Helia/issues/5). Let us know how you’re using js-ipfs now so we can see if/how your use case would be supported with Helia in the future.
|
||||
3. 🫂 Join the team - we’re hiring and need more JavaScript and TypeScript developers who are eager to make the vision above a reality. It’s ideal if you have experience working at the protocol/bytes/streams level. Please learn more [here](https://github.com/ipfs/Helia/issues/6).
|
||||
1. 🗳 Propose a [name for the new “Pomegranate” JS library](https://github.com/ipfs/pomegranate/issues/3) and cast your votes.
|
||||
2. 🗣 Give feedback on the [Pomegranate roadmap](https://github.com/ipfs/pomegranate/issues/5). Let us know how you’re using js-ipfs now so we can see if/how your use case would be supported with Pomegranate in the future.
|
||||
3. 🫂 Join the team - we’re hiring and need more JavaScript and TypeScript developers who are eager to make the vision above a reality. It’s ideal if you have experience working at the protocol/bytes/streams level. Please learn more [here](https://github.com/ipfs/pomegranate/issues/6).
|
||||
4. ✋ Contribute - Open source contributors welcome. Have a great idea and need some funding? Consider a [grant request](https://github.com/ipfs/devgrants).
|
||||
|
||||
Thank you for reading and being on this journey to make IPFS exceptional in JS runtimes!
|
||||
|
||||
> Note: An earlier version of this blog post referred to Helia as Pomegranate. The blog post has been updated to reflect the name [chosen by the community.](https://github.com/ipfs/Helia/issues/3#issuecomment-1344434531)
|
||||
@@ -4,14 +4,6 @@ type: Video
|
||||
sitemap:
|
||||
exclude: true
|
||||
data:
|
||||
- title: 'This Month in IPFS - January 2023'
|
||||
date: 2023-01-26
|
||||
publish_date: 2023-02-06T12:00:00+00:00
|
||||
path: https://www.youtube.com/watch?v=kRzNohHeRaM
|
||||
tags:
|
||||
- community
|
||||
- demo
|
||||
- interview
|
||||
- title: 'Meet the Web3 Builders: Pinata'
|
||||
date: 2021-07-26
|
||||
publish_date: 2021-07-26T12:00:00+00:00
|
||||
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
title: Welcome to IPFS News 188!
|
||||
description: 'The potential benefits of IPFS over WebDAV, plus more in IPFS News 187. '
|
||||
author: Emily Vaughan
|
||||
date: 2022-11-16
|
||||
permalink: "/weekly-188/"
|
||||
translationKey: ''
|
||||
header_image: "/ipfsnews.png"
|
||||
tags:
|
||||
- weekly
|
||||
|
||||
---
|
||||
## Protocol Labs and Igalia add IPFS Protocol Support to Chromium
|
||||
|
||||
|
||||
|
||||
In a major milestone, we’re excited to announce [**support for pre-defined custom protocol handlers in Chromium**](https://ipfs.us4.list-manage.com/track/click?u=25473244c7d18b897f5a1ff6b&id=93fad387d0&e=c8385b3b0b)! You can now build Chromium, the open source browser code used for Chrome, Brave, Edge, Opera, and more, with support for “ipfs://” addresses by changing only a couple of lines of code.
|
||||
|
||||
IPFS has gained support in several ways across various browsers. From extensions to different levels of built-in support in Brave and Opera, to experiments with mobile operating systems, the network looks much different than it did in 2019.
|
||||
|
||||
Learn more about why this is a key step toward browsers that can meet a far more diverse set of user needs while maintaining an interoperable core.
|
||||
|
||||
|
||||
|
||||
## **Brand New on IPFS ✨**
|
||||
|
||||
1. The InterPlanetary Name System (IPNS) spec has been [overhauled and expanded](https://github.com/ipfs/specs/blob/main/ipns/IPNS.md)!
|
||||
2. Jonathan Victor kicked off the [Gaming, Metaverse, and Video](https://www.youtube.com/watch?v=1x2kWcl9V6M) track at IPFS Camp and talked about how developers can create long term value through gaming in the future.
|
||||
3. Guardian is a policy engine that also uses Hedera & IPFS to create provenance chains for ESG assets. [Learn more on the IPFS Blog](https://blog.ipfs.tech/2022-11-10-guardian-ipfs-and-hedera/)!
|
||||
4. [Learn more](https://blog.ipfs.tech/state-of-ipfs-in-js/) about the history of IPFS development in JS, decisions by some maintainers on what to do going forward, and ways you can help.
|
||||
|
||||
## **Around the ecosystem 🌎**
|
||||
|
||||
A new blog on TL;DR dives into the [tokenomics behind Filecoin](https://medium.com/tldrfilecoin/filecoin-tokenomics-understanding-an-advancing-economy-ef319632ffa8) and explains how they help drive long-term demand for network resources. Unlike other storage networks, the Filecoin token is primarily concerned with incentivizing reliable services and facilitating the on-chain economy.
|
||||
|
||||
Filecoin Saturn is an [open-source, community-run Content Delivery Network](https://strn.network/) (CDN) built on Filecoin. Because it is trustless, permissionless, and inclusive, anyone can run Saturn software, contribute to the network, and earn Filecoin.
|
||||
|
||||
Protocol Labs and Filecoin Foundation announced the launch of the [Decentralized Storage Alliance](https://filecoin.io/blog/posts/introducing-the-decentralized-storage-alliance/), a first-of-its-kind, member-led industry organization to drive awareness and adoption of decentralized technologies, such as Filecoin, IPFS, and libp2p, and help enterprises in Web2 make the transition to Web3.
|
||||
|
||||
Protocol Labs is bringing web users across the globe more control and independence by advancing technology for the benefit of humanity. We are now a [member of the Internet Society](https://www.internetsociety.org/about-internet-society/organization-members/stories/protocol-labs/), a global non-profit organization “empowering people to keep the Internet a force for good.”
|
||||
|
||||
Technological advances have enabled mass surveillance at a scale unimagined even by "1984," George Orwell's dystopian novel published in 1949, but how do we fight against Orwellian Systems? Juan Benet and Max Tegmark discussed these issues in [Breakthroughs in Computing](https://www.youtube.com/watch?v=_5ZxcxS3o3k).
|
||||
|
||||
Filecoin Green launched [CO2.Storage](https://co2.storage/), a Web3 data storage solution that intends to enable transparency for carbon offsets and address traditional storage solutions for all types of digital environmental assets, including renewable energy credits.
|
||||
|
||||
If you care about P2P, libp2p and IPFS, then you care about the most important unsolved piece of protocol design in P2P Networks: NAT Hole Punching. [Learn more](https://discuss.libp2p.io/t/call-for-participation-nat-hole-punching-measurement-campaign/1690) about the NAT Hole Punching Measurement Campaign and [sign up to participate](https://docs.google.com/forms/d/1eXLNaJZIUOJtcRS-S0JmXiQuhfmBuAnWm6uueDJgn0w/viewform?edit_requested=true).
|
||||
|
||||
## **Want to help build the new internet? 💼**
|
||||
|
||||
[**Content Writer:**](https://ipfs.us4.list-manage.com/track/click?u=25473244c7d18b897f5a1ff6b&id=0bc80c63eb&e=c8385b3b0b) Edge & Node is a core development team behind The Graph, working to build a vibrant decentralized future. The team is dedicated to the proliferation of web3 applications that share value, utilize dynamic incentives, and build for human coordination. The Digital Content and Social Media Writer will be responsible for the conceptualization and production of at least 3-5 long form pieces each month about The Graph, Edge & Node and House of Web3. Topics may vary but will focus on The Graph and Edge & Node updates, announcements, education, events, innovations, and more. The Content Writer will create and publish content on social media platforms multiple times per day. In addition, they'll partner with the Marketing team to create messaging around company OKRs, and more. **Edge and Node**, Remote.
|
||||
|
||||
[**Director of Engineering:**](https://ipfs.us4.list-manage.com/track/click?u=25473244c7d18b897f5a1ff6b&id=7029564a70&e=c8385b3b0b) The Transmute team is looking to add a Director of Engineering with specific expertise in enterprise security software development, engineering management and technical product strategy. This is a senior role that reports directly to the CTO. Your primary responsibility will be to build and lead a high-performing team of engineers who can build enterprise-scale B2B products. Writing code regularly is not a requirement, but weighing in on architecture decisions, technical product direction, and software development lifecycle issues is. **Transmute**, Austin, TX.
|
||||
|
||||
[**NodeJS developer | FinTech:**](https://ipfs.us4.list-manage.com/track/click?u=25473244c7d18b897f5a1ff6b&id=ab32876ca6&e=c8385b3b0b) Super Mojo is an embedded finance checkout experience for NFT marketplaces. You will build a distributed financial platform which executes transactions in milliseconds and enables a magical checkout experience for Super Mojo users. You will help with designing and heavily contributing to the product architecture and foundation and work with teams across the organization, including product, legal, and business development to think beyond the technical implications of your design decisions. **Super Mojo**, San Francisco, CA.
|
||||
|
||||
[**Sr. Software Engineer, Distributed Systems**](https://ipfs.us4.list-manage.com/track/click?u=25473244c7d18b897f5a1ff6b&id=ffe8baaadd&e=c8385b3b0b): Protocol Labs is hiring a Sr. Distributed Systems Engineers to work on the JavaScript and Go implementations of protocols like IPFS, Filecoin and libp2p. Enthusiasm about the decentralized web and blockchains has brought an influx of people who want to use distributed systems but who don't know how to build the necessary infrastructure. Protocol Labs is building that infrastructure. To continue that work, they’re looking for people who thoroughly understand the principles of distributed systems and who will lean into the challenges of applying those principles in open-source code that will be deployed worldwide. **Protocol Labs**, Remote.
|
||||
|
||||
[**Brand Designer**](https://ipfs.us4.list-manage.com/track/click?u=25473244c7d18b897f5a1ff6b&id=345459346a&e=c8385b3b0b): Pinata Technologies, Inc. is building the tools and infrastructure for a more free and empowering Web3 generation through IPFS. Their vision is to foster a sense of place for every creator on the internet that is uniquely theirs. Pinata is looking for a brand designer to join their team! This role will be responsible for creating designs for our website and digital marketing efforts, as well as creatives for traditional mediums. This person will report to the Marketing team and receive guidance from the Creative Director. This person should feel comfortable presenting new creative concepts and ideas to both the Marketing team as well as across the business team. **Pinata**, Remote.
|
||||
@@ -1,64 +0,0 @@
|
||||
---
|
||||
title: Welcome to IPFS News 189!
|
||||
description: 'Learn all about the current state of the IPFS Ecosystem, plus more in
|
||||
IPFS News 189. '
|
||||
author: Crystal Mills
|
||||
date: 2022-11-30
|
||||
permalink: "/weekly-189/"
|
||||
translationKey: ''
|
||||
header_image: "/ipfsnews.png"
|
||||
tags:
|
||||
- IPFS Camp
|
||||
- kubo
|
||||
- weekly
|
||||
|
||||
---
|
||||
## **The State of the IPFS Ecosystem**
|
||||
|
||||
|
||||
|
||||
Since the last IPFS Camp in 2019, we have seen tremendous growth throughout [the entire IPFS ecosystem](https://youtu.be/fGwhPLik3_4)! This year’s three-day event had over 550 attendees, but the growth of the community goes beyond that.
|
||||
|
||||
Active monthly users of IPFS-based dapps and tools has grown from 5 million to 50 million. The number of unique nodes continues to grow, making the network more resilient and distributed, and content more available. Meanwhile, performance is improving even as the network grows: it’s now 50x faster to find content across the network.
|
||||
|
||||
Thank you to everyone who has become a part of the growing IPFS community! Learn more about the state of the IPFS ecosystem, the new IPFS Implementations Fund, and check out the full list of panels and presentations in the [IPFS Camp 2022 Recap](https://blog.ipfs.tech/2022-11-22-ipfs-camp-22-recap/)!
|
||||
|
||||
## **Brand New on IPFS ✨**
|
||||
|
||||
1. Kubo 0.17.0 is out! TAR Response Format on Gateways provides a vendor-agnostic way of downloading entire directories using HTTP. This and more are all [highlighted in the full release notes](https://github.com/ipfs/kubo/releases/tag/v0.17.0).
|
||||
2. 3S Studio is a game development project that has implemented an IPFS plugin for the popular and widely-used [Unreal Engine](https://blog.ipfs.tech/2022-11-15-3s-studio/) for 3D computer graphics.
|
||||
3. [Learn how you can now build Chromium](https://blog.ipfs.tech/14-11-2022-igalia-chromium/) - the open source browser code used for Chrome, Brave, Edge, Opera and more - with support for "ipfs://" addresses.
|
||||
4. Estuary v0.2.0 is now live! The [release includes](https://twitter.com/Estuary_Tech/status/1597313610019393536) major fixes, improvements, and the first official feature-complete release of Autoretrieve.
|
||||
|
||||
## **Around the ecosystem 🌎**
|
||||
|
||||
Last month, libp2p users and contributors gathered together for the [first-ever libp2p Day](https://blog.ipfs.tech/2022-11-22-libp2p-day-2022-recap/)! The day included talks from maintainers, contributors, community members, and users.
|
||||
|
||||
What role does the Filecoin community play in the trajectory of decentralized AI? Juan Benet and Illia Polosukhin spoke about the [convergence of AI and Web3](https://www.youtube.com/watch?v=sQZJjH2wZHw&t=2s).
|
||||
|
||||
Where is big data heading next and how are data engineers going to process it? [Learn more](https://www.youtube.com/watch?v=RZopDyTJ1pk) about how projects like the Bacalhau Project are revolutionizing the big data age with compute over data.
|
||||
|
||||
[FVM](https://www.youtube.com/watch?v=RvM-B0E9Hoc) delivers on-chain programmability to the Filecoin network. Learn more about the Filecoin Virtual Machine from the FVM Keynote at the FEVM Summit!
|
||||
|
||||
ConsensusLab is proud to announce its first [deployment of Spacenet](https://github.com/consensus-shipyard/spacenet), the new generation Filecoin testnet. It is based on the Trantor BFT-style ordering protocol implemented using the Mir framework, cutting down transaction latency from 30s to around 1s.
|
||||
|
||||
The upcoming [Filecoin upgrade to network version 17, Shark](https://filecoin.io/blog/posts/filecoin-network-v17-shark-upgrade/), will bring a range of improvements and simplifications that set the stage for programmable storage: smart contracts that interact with storage deals and providers.
|
||||
|
||||
The Filecoin community is sponsoring the first-ever blockchain gaming conference in Bengaluru. Join builders and ecosystem partners at The Den on December 5th and [participate in workshops](https://eiusgtz4fq6.typeform.com/to/iIA5f27F?typeform-source=events.godwoken.com) designed to educate developers on the advantages of blockchain technology for game development.
|
||||
|
||||
Protocol Labs’ mission is to drive breakthroughs in computing to push humanity forward, but what does that actually mean? Protocol Labs Founder Juan Benet explained the vision for the company, touching on [securing the internet and establishing digital human rights](https://www.youtube.com/watch?v=8lDwBnQ9Wuc).
|
||||
|
||||
The Protocol Labs Network is a hub for over 500 startups at various stages of funding designed to turbocharge Web3 projects. [Learn more](https://www.youtube.com/watch?v=3JRg66DC3ok&t=3s) about how founders can get involved!
|
||||
|
||||
## **Want to help build the new internet? 💼**
|
||||
|
||||
[**Senior Software Engineer, Backend:**](https://angel.co/company/pinatacloud/jobs/2488893-senior-software-engineer-backend) Pinata Technologies, Inc. is building the tools and infrastructure for a more free and empowering Web3 generation through IPFS. Their vision is to foster a sense of place for every creator on the internet that is uniquely theirs. Pinata is looking for a Senior Backend Software Engineer to join their team! You will report to their Engineering Manager while working with the Engineering team to make the experience of creating and distributing content easier through client-side tools and applications. In this role, you will largely be responsible for backend development using Node.js. **Pinata**, Remote.
|
||||
|
||||
[**Backend/API Engineer**](https://www.linkedin.com/jobs/view/backend-api-engineer-at-textile-3376425642?refId=rYACbGKfnvYvqiFQ6B%2BTEQ%3D%3D&trackingId=EySJEEN839Nc6zxTail21w%3D%3D&trk=public_jobs_topcard-title): Textile's mission is to accelerate the exchange of information on the Internet. We are a technology company focused on building tools that help developers leverage open networks, protocols, and blockchains. We are a small, fully remote team aligned in our vision to experimentally change the relationship between technology and data. You can learn more about our products and services through our documentation and our GitHub organization. We are a fully open source company.
|
||||
Textile's infrastructure is written primarily in Golang and sits at the heart of Textile's products and gRPC services. It is built on top of protocols like Libp2p, IPFS, and Filecoin and is deployed to Google Kubernetes Engine. Your role will interact with layers throughout the stack and own responsibilities from research and development to implementation and production monitoring. **Textile**, United States.
|
||||
|
||||
[**Content Writer:**](https://boards.greenhouse.io/edgeandnode/jobs/4111144005) Edge & Node is a core development team behind The Graph, working to build a vibrant decentralized future. The team is dedicated to the proliferation of web3 applications that share value, utilize dynamic incentives, and build for human coordination. The Digital Content and Social Media Writer will be responsible for the conceptualization and production of at least 3-5 long form pieces each month about The Graph, Edge & Node and House of Web3. Topics may vary but will focus on The Graph and Edge & Node updates, announcements, education, events, innovations, and more. The Content Writer will create and publish content on social media platforms multiple times per day. In addition, they'll partner with the Marketing team to create messaging around company OKRs, and more. **Edge and Node**, Remote.
|
||||
|
||||
[**NodeJS developer | FinTech:**](https://www.linkedin.com/jobs/view/nodejs-developer-fintech-at-supermojo-3356945255?refId=8qQPjwNzIDpcuwJDzbSMow%3D%3D&trackingId=i9xHYRlVTS2pJfbq3%2F7S5A%3D%3D&trk=public_jobs_topcard-title) Super Mojo is an embedded finance checkout experience for NFT marketplaces. You will build a distributed financial platform which executes transactions in milliseconds and enables a magical checkout experience for Super Mojo users. You will help with designing and heavily contributing to the product architecture and foundation and work with teams across the organization, including product, legal, and business development to think beyond the technical implications of your design decisions. **Super Mojo**, San Francisco, CA.
|
||||
|
||||
[**Sr. Software Engineer, Distributed Systems**](https://boards.greenhouse.io/protocollabs/jobs/4283628004): Protocol Labs is hiring a Sr. Distributed Systems Engineers to work on the JavaScript and Go implementations of protocols like IPFS, Filecoin and libp2p. Enthusiasm about the decentralized web and blockchains has brought an influx of people who want to use distributed systems but who don't know how to build the necessary infrastructure. Protocol Labs is building that infrastructure. To continue that work, they’re looking for people who thoroughly understand the principles of distributed systems and who will lean into the challenges of applying those principles in open-source code that will be deployed worldwide. **Protocol Labs**, Remote.
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
title: Welcome to IPFS News 190!
|
||||
description: 'Learn more about Content Addressed Computing, highlighted during IPFS
|
||||
Camp 2022, plus more in IPFS News 190. '
|
||||
author: Crystal Mills
|
||||
date: 2022-12-14
|
||||
permalink: "/weekly-190/"
|
||||
translationKey: ''
|
||||
header_image: "/ipfsnews.png"
|
||||
tags:
|
||||
- IPFS Camp
|
||||
- weekly
|
||||
|
||||
---
|
||||
## **Content Addressed Computing**
|
||||
|
||||
|
||||
|
||||
In the Compute-Over-Data track at [IPFS Camp 2022](https://2022.ipfs.camp/), several projects and IPFS contributors highlighted [how the landscape of computing is evolving](https://blog.ipfs.tech/2022-12-01-cod-at-ipfs-camp/), and how they believe computing can become refocused and more powerful by embracing content addressing and a “merkle-native” way of doing things.
|
||||
|
||||
Content-addressing and the use of merkle data structures– identifying data by a cryptographic hash – is already a well-known revolution of how data structures can be designed for decentralization, bringing benefits like verifiability, naturally coordination-free data deduplication, and more. Learn more in [this recap](https://blog.ipfs.tech/2022-12-01-cod-at-ipfs-camp/) of the Compute-Over-Data track from IPFS Camp.
|
||||
|
||||
## **Brand New on IPFS ✨**
|
||||
|
||||
1. Try the new [CID byte length viewer](https://cid.ipfs.tech/#%F0%9F%9A%80%F0%9F%AA%90%E2%AD%90%F0%9F%92%BB%F0%9F%98%85%F0%9F%92%AA%F0%9F%A5%B3%F0%9F%98%B4%F0%9F%8E%82%F0%9F%91%89%F0%9F%92%A7%F0%9F%93%8D%F0%9F%8C%B4%F0%9F%98%AA%F0%9F%98%AE%F0%9F%8E%88%F0%9F%9A%A9%F0%9F%99%88%F0%9F%98%A5%F0%9F%98%B0%F0%9F%94%B5%F0%9F%98%A1%E2%9C%8A%F0%9F%8D%92%F0%9F%90%BE%F0%9F%8E%89%F0%9F%98%87%F0%9F%8E%A4%E2%9D%8C%F0%9F%98%8F%F0%9F%8C%8D%F0%9F%8C%98%F0%9F%A5%82%E2%9C%8B%F0%9F%98%B9%F0%9F%93%8D%F0%9F%99%84) in IPFS CID inspector!
|
||||
2. Learn more about [content retrieval and peer-to-peer](https://hackernoon.com/content-retrieval-and-peer-to-peer-storage-a-practical-explainer-for-ipfs-gateways) storage in a practical explainer for IPFS gateways.
|
||||
3. December is [NAT Hole Punching](https://github.com/dennis-tra/punchr/releases/tag/v0.9.0) month, where we measure the success rate of hole punching in libp2p with the help of our community.
|
||||
4. Together with the 4EVERLAND Public Gateway, the 4EVERLAND [Dedicated Gateway](https://medium.com/4everland/4everland-dedicated-gateway-announcement-8afe65e45060) provides faster and more stable access to IPFS content.
|
||||
|
||||
## **Around the ecosystem 🌎**
|
||||
|
||||
The first-ever Hack FEVM welcomed over [400 hackers to build and showcase 117 projects](https://filecoin.io/blog/posts/announcing-the-hack-fevm-finalists/) with over $50,000 awarded through various prizes! This hackathon introduced FEVM to the wider Ethereum ecosystem, with close mentorship and resources that supported hackers and their projects.
|
||||
|
||||
With the tech support of IPFS and Filecoin, every [asset on the Numbers Mainnet](https://www.numbersprotocol.io/blog/numbers-mainnet-ushering-in-a-new-era-of-digital-media-trust) has a unique Numbers ID. All metadata, asset changelogs and licenses are stored on-chain to assure integrity of the digital assets.
|
||||
|
||||
"The underlying foundation of the internet is fundamentally insecure and relies on trust. That's what we're trying to upgrade." Watch the [full episode featuring Juan Benet](https://www.youtube.com/watch?v=NHdZaAIGQnM) on the Defiant News podcast!
|
||||
|
||||
Did you miss the Protocol Labs Ecosystem Working Group All Hands in December? Watch the [full presentation here](https://www.youtube.com/watch?v=iQq0OyTtC7w&list=PL_0VrY55uV1_B19kuAg-ExQ-Wa2d1hCbf).
|
||||
|
||||
The Next Video Build hackathon sponsored by Livepeer is on its way! [Register for the hack](https://encodeclub.typeform.com/nextvideobuild?typeform-source=t.co), build a cool project and grab a piece of the $50k+ prize pool.
|
||||
|
||||
The [Space Warp](https://spacewarp.fvm.dev/) program is launching! It aims to [help the builder community accelerate](https://filecoin.io/blog/posts/announcing-space-warp-journey-to-fvm-launch-on-filecoin-mainnet/) the development of new value-adding apps on the Filecoin network in preparation for FVM mainnet launch in February.
|
||||
|
||||
Estuary is excited to announce a [partnership with Encloud](https://twitter.com/Estuary_Tech/status/1600951830506536960)! Encloud is a Web3 toolkit that is using Estuary to easily onboard private data to the Filecoin network.
|
||||
|
||||
Want to build on the Filecoin Virtual Machine (FVM) but not sure how to contribute? Here are [24 ideas from the FVM dev team](https://rfs.fvm.dev/) for apps, building blocks & systems to build on FVM.
|
||||
|
||||
DWeb Camp 2022 welcomed builders to a five-day retreat to come together and discuss how the natural world can inform the ethical and practical foundation of Web3. Check out the [recap to learn more](https://medium.com/@filecoingreen/redwood-reflections-dweb-camp-2022-f7eca51f1b1c)!
|
||||
|
||||
Filecoin TL;DR aims to simplify the state of the Filecoin Network and ecosystem in a way that is quick, easy, and digestible for all stakeholders. [Learn more](https://tldr.filecoin.io/) about the FIL token beyond market movements.
|
||||
|
||||
## **Want to help build the new internet? 💼**
|
||||
|
||||
[**Content Writer:**](https://ipfs.us4.list-manage.com/track/click?u=25473244c7d18b897f5a1ff6b&id=ab470f1edc&e=c8385b3b0b) Edge & Node is a core development team behind The Graph, working to build a vibrant decentralized future. The team is dedicated to the proliferation of web3 applications that share value, utilize dynamic incentives, and build for human coordination. The Digital Content and Social Media Writer will be responsible for the conceptualization and production of at least 3-5 long form pieces each month about The Graph, Edge & Node and House of Web3. Topics may vary but will focus on The Graph and Edge & Node updates, announcements, education, events, innovations, and more. The Content Writer will create and publish content on social media platforms multiple times per day. In addition, they'll partner with the Marketing team to create messaging around company OKRs, and more. **Edge and Node**, Remote.
|
||||
|
||||
|
||||
[**NodeJS developer | FinTech:**](https://ipfs.us4.list-manage.com/track/click?u=25473244c7d18b897f5a1ff6b&id=93e5622a2e&e=c8385b3b0b) Super Mojo is an embedded finance checkout experience for NFT marketplaces. You will build a distributed financial platform which executes transactions in milliseconds and enables a magical checkout experience for Super Mojo users. You will help with designing and heavily contributing to the product architecture and foundation and work with teams across the organization, including product, legal, and business development to think beyond the technical implications of your design decisions. **Super Mojo**, San Francisco, CA.
|
||||
|
||||
|
||||
[**Go Software Engineer:**](https://ipfs.us4.list-manage.com/track/click?u=25473244c7d18b897f5a1ff6b&id=755d96fc67&e=c8385b3b0b) Sonr needs a developer thats exceptional at bridging the gap between planning and implementation on our networking infrastructure. Sonr is a data delivery protocol that integrates Identification, Discovery, Delivery, and Transmission for a seamless Web3 experience. **Sonr**, Remote.
|
||||
|
||||
|
||||
[**JS IPFS and libp2p Systems Engineer**](https://ipfs.us4.list-manage.com/track/click?u=25473244c7d18b897f5a1ff6b&id=c917e0ccd8&e=c8385b3b0b)[**:**](https://ipfs.us4.list-manage.com/track/click?u=25473244c7d18b897f5a1ff6b&id=de8b935036&e=c8385b3b0b) Protocol Labs is hiring a JS IPFS and libp2p Systems Engineer. Systems Engineering lies at the core of many projects at Protocol Labs, next to Research and Distributed Systems. JavaScript Systems Engineering sits on the front line of pushing the DWeb forward by building the implementation that will enable JS environments like browsers, Node, Deno, Electron, etc. to be fully capable nodes on the IPFS network.This requires rigorous engineering from protocol design through all the phases of implementation. Protocol Labs strikes a balance between pragmatism, deeply informed protocol design, and strict application of strong engineering principles. All of this happens in an environment defined by curiosity, passion, and a love for open source. **Protocol Labs**, Remote.
|
||||
|
||||
|
||||
[**Project Manager:**](https://ipfs.us4.list-manage.com/track/click?u=25473244c7d18b897f5a1ff6b&id=6394810748&e=c8385b3b0b) The Graph ecosystem continues to grow, and they're looking for a Project Manager to support activities including, but not limited to, governance and internal processes and operations. The Graph is the indexing and query layer of web3. The Graph Network’s self service experience for developers launched in July 2021. Developers build and publish open APIs, called subgraphs, that applications can query using GraphQL. The Graph supports indexing data from multiple different networks including Ethereum, NEAR, Arbitrium, Optimism, Polygon, Avalanche, Celo, Fantom, Moonbeam, IPFS, and PoA with more networks coming soon. To date, tens-of-thousands of subgraphs have been deployed on the hosted service, and now subgraphs can be deployed directly on the network. Over 28,000 developers have built subgraphs for applications such as Uniswap, Synthetix, KnownOrigin, Art Blocks, Balancer, Livepeer, DAOstack, Audius, Decentraland, and many others. **The Graph**, United States.
|
||||
@@ -1,57 +0,0 @@
|
||||
---
|
||||
title: Welcome to IPFS News 191!
|
||||
description: IPFS is going to space to improve the speed of data transfer, plus more
|
||||
in IPFS News 191
|
||||
author: Crystal Mills
|
||||
date: 2023-01-20
|
||||
permalink: "/weekly-191"
|
||||
translationKey: ''
|
||||
header_image: "/ipfsnews.png"
|
||||
tags:
|
||||
- weekly
|
||||
|
||||
---
|
||||
## **IPFS to Launch Into Space**
|
||||
|
||||
|
||||
|
||||
The Filecoin Foundation [**announced**](https://twitter.com/IPFS/status/1616110027261227009?s=20&t=fv3FslvX-vH59U0lkAn4nw) a first-of-its-kind mission to [**send IPFS into space**](https://fil.org/blog/ff-x-lockheed-martin-mission-announcement/) in 2023. The mission will happen aboard Lockheed Martin’s LM 400 Technology Demonstrator spacecraft, a “software-defined satellite” that is created to support numerous missions. After the spacecraft is in orbit, it will use its “SmartSat™ software-defined satellite technology to upload and perform the IPFS demonstration.” This mission will showcase how IPFS uses content addressing to speed up data transfer across long distances.
|
||||
|
||||
## **Brand New on IPFS ✨**
|
||||
|
||||
1. New year, new [IPFS Community Calendar](https://blog.ipfs.tech/2023-01-ipfs-community-calendar/)! Subscribe to [the calendar](https://lu.ma/ipfs) to be informed about any new events.
|
||||
2. [Pin Tweet to IPFS](https://blog.ipfs.tech/announcing-pin-tweet-to-ipfs/) aims to help users archive posts in a verifiable way, publishing to the IPFS network through a pinning service.
|
||||
3. Learn more about Testground, a [platform for testing](https://blog.ipfs.tech/testground-highlights-in-2022/) and benchmarking distributed systems.
|
||||
4. IPFS Thing now has a confirmed location: Brussels, Belgium. [Pre-registration](https://lu.ma/ipfsthing-preregistration) is open!
|
||||
|
||||
## **Around the Ecosystem 🌎**
|
||||
|
||||
The FVM ([Filecoin Virtual Machine](https://filecoin.io/blog/posts/the-filecoin-virtual-machine-explained/)) brings smart contracts and user programmability to the Filecoin blockchain, unlocking the world's largest open-access data economy. Join the Filecoin Community at the EthGlobal FVM Space Warp Hackathon to be one of the first to build on FVM and win over $150K in prizes. [Apply](https://ethglobal.com/events/spacewarp) before the deadline, January 20, 2023 at 11:59PM EST.
|
||||
|
||||
For other FVM opportunities check out the [Space Warp](https://spacewarp.fvm.dev/) program! It aims to help the builder community accelerate the development of new value-adding apps on the Filecoin network in preparation for FVM mainnet launch this year.
|
||||
|
||||
Learn more about [WebTransport](https://blog.libp2p.io/2022-12-19-libp2p-webtransport/#what-is-webtransport), a new transport protocol and Web API currently under development. It seeks to address several use cases, including browser gaming, live streaming, multimedia applications, and more.
|
||||
|
||||
Telnyx worked with the Filecoin team and ecosystem to build [Telnyx Storage](https://filecoin.io/blog/posts/telnyx-builds-innovative-low-cost-object-storage-on-the-filecoin-network/). Telnyx Storage offers low-cost, low-latency file retrieval from a dense network of storage PoPs, with zero egress fees.
|
||||
|
||||
NFTStar is building an [integrated and global sports](https://filecoin.io/blog/posts/case-study-why-nftstar-trusts-decentralized-cloud-storage-for-sports-collectibles/) metaverse platform based in Singapore. Its goal is to create a Web3 community that fosters direct connections between sports stars and their fans.
|
||||
|
||||
Rolling Stone partnered with The Starling Lab to help investigate alleged war crimes using modern cryptography and Filecoin’s decentralized storage. [Learn more](https://investigation.rollingstone.com/dj-photo-war-crimes-bosnia/) and explore the archive!
|
||||
|
||||
The FVM Imaginarium Campaign is putting the spotlight on the teams who are building incredible use cases and introducing new opportunities and concepts on FVM. The first spotlights [Magmo](https://filecoin.io/blog/posts/the-fvm-imaginarium-magmo-brings-state-channels-to-the-filecoin-virtual-machine/), a development studio and research team that’s a part of Consensys Mesh
|
||||
|
||||
[Storage.market](https://storage.market/) is now live! Dive into the information hub on data storage products, showing analytics on the storage market and recent news.
|
||||
|
||||
Decentralized Science, or DeSci, is a Web3 movement that aims to improve the current flow of science by improving the research funding process, facilitating unrestricted sharing of knowledge and shifting ownership to researchers. [Learn more](https://plnnews.substack.com/p/web3-in-60-desci) at _Web3 in :60_!
|
||||
|
||||
[Filecoin Green’s](https://green.filecoin.io/) next meetup kicks off on January 24 at 1 PM ET! [Tune in](https://twitter.com/filecoingreen/status/1616088196944744450) for a special edition carbon offset roundtable.
|
||||
|
||||
## Want to help build the new internet? 💼
|
||||
|
||||
[**NodeJS developer | FinTech:**](https://www.linkedin.com/jobs/view/nodejs-developer-fintech-at-supermojo-3356945255?refId=8qQPjwNzIDpcuwJDzbSMow%3D%3D&trackingId=i9xHYRlVTS2pJfbq3%2F7S5A%3D%3D&trk=public_jobs_topcard-title) Super Mojo is an embedded finance checkout experience for NFT marketplaces. You will build a distributed financial platform which executes transactions in milliseconds and enables a magical checkout experience for Super Mojo users. You will help with designing and heavily contributing to the product architecture and foundation and work with teams across the organization, including product, legal, and business development to think beyond the technical implications of your design decisions. **Super Mojo**, San Francisco, CA.
|
||||
|
||||
[**People Manager, PL Network:**](https://boards.greenhouse.io/protocollabs/jobs/4769907004) Protocol Labs is hiring a People Manager, PL Network. The People Manager, PL Network role is highly versatile and execution oriented. You will have the opportunity to add value to the collective of 200+ PL Network startups around the world, building the future of web3, by managing projects and strategic initiatives that elevate their people practices and programming. **Protocol Labs**, Remote.
|
||||
|
||||
[**Project Manager:**](https://the-graph.breezy.hr/p/bfa7fef3dc32-project-manager) The Graph ecosystem continues to grow, and they're looking for a Project Manager to support activities including, but not limited to, governance and internal processes and operations. The Graph is the indexing and query layer of web3. The Graph Network’s self service experience for developers launched in July 2021. Developers build and publish open APIs, called subgraphs, that applications can query using GraphQL. The Graph supports indexing data from multiple different networks including Ethereum, NEAR, Arbitrium, Optimism, Polygon, Avalanche, Celo, Fantom, Moonbeam, IPFS, and PoA with more networks coming soon. To date, tens-of-thousands of subgraphs have been deployed on the hosted service, and now subgraphs can be deployed directly on the network. Over 28,000 developers have built subgraphs for applications such as Uniswap, Synthetix, KnownOrigin, Art Blocks, Balancer, Livepeer, DAOstack, Audius, Decentraland, and many others. **The Graph**, United States.
|
||||
|
||||
[**Engineering Manager, Stewards libp2p:**](https://boards.greenhouse.io/protocollabs/jobs/4765047004) Engineers, researchers, and operators work in the open to improve the internet — humanity's most important technology — as we explore new advances at the intersection of many exciting fields (web3, cryptography, networks, distributed systems) and cultures (startups, research, open-source, distributed work). Stewards libp2p sets direction/standards for projects, protocols, and architecture. Cultivate a vibrant contributing community around libp2p! **Protocol Labs**, Remote.
|
||||
@@ -1,72 +0,0 @@
|
||||
---
|
||||
title: Welcome to IPFS News 192!
|
||||
description: Learn about IPFS Thing 2023, Community Impact Awards, and much more in
|
||||
this month's round-up of IPFS news.
|
||||
author: ''
|
||||
date: 2023-03-27
|
||||
permalink: "/newsletter-192"
|
||||
translationKey: ''
|
||||
header_image: "/ipfsnews.png"
|
||||
tags:
|
||||
- weekly
|
||||
|
||||
---
|
||||
## **Register for IPFS Thing 2023 🎟️**
|
||||
|
||||
We’re only a few weeks away from this year’s week-long gathering for the IPFS implementers community. [IPFS Thing 2023](https://2023.ipfs-thing.io/) is happening from **April 15-19 in Brussels, Belgium** and will include everything from talks, workshops, discussion circles, hacking time, and more — all focused on advancing IPFS implementations.
|
||||
|
||||
[**Grab your tickets today before time runs out!**](https://2023.ipfs-thing.io/) Use code “THING23” at checkout by March 31 to get them for only $299.
|
||||
|
||||
For those attending, you can also [submit a talk or track online.](https://2023.ipfs-thing.io/submit/)
|
||||
|
||||
## **Vote in the IPFS Community Impact Awards 🏅**
|
||||
|
||||
The next round of IPFS Community Impact Awards will be awarded very soon — in April 2023. In this upcoming round, we’d like to invite the broader community to vote! If any of these are true, you’re eligible to vote and help recognize the most valuable projects that are advancing the IPFS project and community!
|
||||
|
||||
* You attended IPFS þing 2022, or
|
||||
* You contributed to the Kubo, Helia, Nabu, or Iroh repos prior to 2022.03.22, or
|
||||
* You are building a project within the [**IPFS Fund Scope**](https://www.youtube.com/watch?v=YfpnGPYddK8&t=772s)
|
||||
|
||||
If you meet any of the above criteria, please [submit this eligibility form ](https://airtable.com/shrXvfDLEoYjFGWV9)and look out for a confirmation. For questions, please email [**impact-evaluator@protocol.ai**](mailto:impact-evaluator@protocol.ai).
|
||||
|
||||
## **Brand New on IPFS ✨**
|
||||
|
||||
[Kubo v0.19.0](https://github.com/ipfs/kubo/releases/tag/v0.19.0)
|
||||
|
||||
* Improving the libp2p resource management integration
|
||||
* Gateways
|
||||
* Signed IPNS Record response format
|
||||
* Example fetch and inspect IPNS record
|
||||
* Addition of "autoclient" router type
|
||||
* Deprecation of the `ipfs pubsub` commands and matching HTTP endpoints
|
||||
|
||||
[Cluster v1.0.6](https://github.com/ipfs-cluster/ipfs-cluster/releases/tag/v1.0.6)
|
||||
|
||||
* IPFS Cluster v1.0.6 is a maintenance release with some small fixes. The main change in this release is that pebble becomes the default datastore backend.
|
||||
|
||||
[Brand new 3-part intro to IPFS in the docs](https://docs.ipfs.tech/concepts/what-is-ipfs/)
|
||||
|
||||
* As part of our ongoing efforts to make the IPFS docs even better, we’ve created a new section that does a better job at covering the basics. [Check it out for yourself!](https://docs.ipfs.tech/concepts/what-is-ipfs/)
|
||||
|
||||
[Helia Demo Day recordings](http://ipfs.fyi/helia-demo)
|
||||
|
||||
* If you missed the live events about Helia (the new implementation of IPFS in JavaScript), then you can [catch up](http://ipfs.fyi/helia-demo) thanks to these handy videos!
|
||||
|
||||
[IPLD: The Data Layer of the Decentralized Web](https://blog.ipfs.tech/ipld-the-new-data/)
|
||||
|
||||
* A recently published post on the IPFS blog goes in-depth into how IPLD does more than just provide a universal way to move data to where users want; it also enables all future applications to be built on top of every prior application’s data. [Read it now](https://blog.ipfs.tech/ipld-the-new-data/)!
|
||||
|
||||
[New IPFS website coming soon](https://twitter.com/IPFS/status/1638225746010185760?s=20)
|
||||
|
||||
* We recently posted a teaser on Twitter for the upcoming ipfs.io website redesign. We’ve been hard at work revamping the entire IPFS website, and we’re excited for it to go live in the near future — stay tuned!
|
||||
|
||||
## **Around the Ecosystem 🌎**
|
||||
|
||||
* [The IPFS community was at GDC last week](https://twitter.com/IPFS/status/1638253848711032851?s=20) with [3SGame Studio](https://www.3studio.online), makers of the [IPFS plugin for Unreal Engine](https://www.unrealengine.com/marketplace/en-US/product/ipfs). The plugin speeds up game loading by up to 40x.
|
||||
* Want to see how others are scaling IPFS? [Here's how Near Form designed Elastic IPFS](https://www.nearform.com/blog/designing-cloud-based-architecture-with-infinite-scalability-elastic-ipfs-provider/), a cloud-native implementation of IPFS with infinite horizontal scalability that powers [NFT.Storage](https://nft.storage) and [Web3.Storage](http://web3.storage)
|
||||
* [Check out this great Twitter thread from @jalil_eth](https://twitter.com/jalil_eth/status/1628176052764942338?s=20) that explains how IPFS addresses work and why they are so important for NFTs! With real-world examples!
|
||||
* We love it when people host their websites using IPFS, and [this helpful guide by @juanbeencoding from Fleek](https://blog.fleek.xyz/post/hosting-on-ipfs-best-practices-troubleshooting/) covers some excellent best-practices for how to do it effectively.
|
||||
* [Learn how to throw your ebook library at IPFS](https://dustri.org/b/how-to-throw-your-ebook-library-at-ipfs.html) in this recently released tutorial.
|
||||
* [Academic research on implementing Swarm’s Alpha Entanglement in IPFS](https://twitter.com/IPFS/status/1633367698724798464?s=20) using IPFS Cluster to increase reliability.
|
||||
* [Fireproof](https://twitter.com/FireproofStorge) is a new dynamic database product created by [@jchris](https://twitter.com/jchris) that has IPFS at its core. Use it to quickly add dynamic data to any app or page.
|
||||
* [A new tool](https://nouns.build) from Zora called Nouns Builder enables anyone to create a Nouns-style DAO without any code. The best part? It utilizes the power of IPFS. The next generation of DAOs will have a solid data foundation.
|
||||
@@ -1,78 +0,0 @@
|
||||
---
|
||||
title: Welcome to IPFS News 193!
|
||||
description: Featuring Bluesky, a recap of IPFS Thing 2023, Brave's enhanced IPFS support, content blocking in Kubo, and much more!
|
||||
author: ''
|
||||
date: 2023-05-09
|
||||
permalink: "/newsletter-193"
|
||||
translationKey: ''
|
||||
header_image: "/ipfsnews.png"
|
||||
tags:
|
||||
- newsletter
|
||||
---
|
||||
|
||||
A lot has happened since the previous newsletter over a month ago. [IPFS Thing took place in Brussels](https://blog.ipfs.tech/2023-ipfs-thing-recap/), we created a [Bluesky](https://blog.ipfs.tech/2023-ipfs-on-bluesky/) account, [Brave released automatic NFT backups to IPFS](https://brave.com/nft-pinning/), [content blocking can now be enabled in Kubo](https://blog.ipfs.tech/2023-content-blocking-for-the-ipfs-stack/), plus so much more! Read on to catch up with what’s happened in the ecosystem over the last few weeks.
|
||||
|
||||
## **Recap: IPFS Thing 2023 🔄**
|
||||
|
||||
The IPFS implementers community recently gathered in Brussels, Belgium for the second year of [IPFS þing](https://2023.ipfs-thing.io/), an annual gathering dedicated to advancing IPFS implementation. With 12 tracks and over 75 talks, demos, and sessions, the 5-day summit that occurred in April 2023 was a showcase of recent advances across IPFS, a forum for sharing needs from the protocol, and an opportunity to chart new directions for the future of IPFS.
|
||||
|
||||
[Read the recap on the blog for photos, videos, and summaries!](https://blog.ipfs.tech/2023-ipfs-thing-recap/)
|
||||
|
||||
## **Brand New on IPFS ✨**
|
||||
|
||||
**[IPFS is now on Bluesky!](https://blog.ipfs.tech/2023-ipfs-on-bluesky/)**
|
||||
|
||||
* We’re excited to share that IPFS now has an official presence on [Bluesky](https://blueskyweb.xyz/)! We chose[ ](https://twitter.com/bluesky)Bluesky because it shares many of the same values and goals that the IPFS ecosystem has. Additionally, they actively utilize IPLD and content addressing. [Read more about it](https://blog.ipfs.tech/2023-ipfs-on-bluesky/)!
|
||||
|
||||
**[Content Blocking for the IPFS stack is finally here!](https://blog.ipfs.tech/2023-content-blocking-for-the-ipfs-stack/)**
|
||||
|
||||
* Traditionally, content blocking within the IPFS ecosystem has been performed only at the IPFS gateway level and directly in Nginx, using something called the "Badbits denylist" — but now it can be enabled in Kubo & other tools in the IPFS stack too! [Check out the blog post for more info.](https://blog.ipfs.tech/2023-content-blocking-for-the-ipfs-stack/)
|
||||
|
||||
**[What happens when half of the network is down?](https://blog.ipfs.tech/2023-ipfs-unresponsive-nodes/)**
|
||||
|
||||
* The IPFS DHT experienced a serious incident in the beginning of 2023, but users hardly noticed thanks to the power of a decentralized network. [Read all about it in a new incident report!](https://blog.ipfs.tech/2023-ipfs-unresponsive-nodes/)
|
||||
|
||||
**[IPFS Principles](https://specs.ipfs.tech/architecture/principles/)**
|
||||
|
||||
* As mentioned above, IPFS recently joined a new social media network called [Bluesky](https://blueskyweb.xyz/) because it shares many of the same values that the IPFS ecosystem has. But what are those values exactly? You can [read all about IPFS Principles in a new specs doc](https://specs.ipfs.tech/architecture/principles/) edited by[ Robin Berjon](https://twitter.com/robinberjon).
|
||||
|
||||
**[Kubo 0.20.0](https://github.com/ipfs/kubo/releases/tag/v0.20.0)**
|
||||
|
||||
* This update includes:
|
||||
* Switch to `boxo/gateway` library
|
||||
* Improved testing
|
||||
* Trace Context support
|
||||
* Removed legacy features
|
||||
|
||||
**[Kubo 0.19.2](https://github.com/ipfs/kubo/releases/tag/v0.19.2)**
|
||||
|
||||
**[Kubo 0.19.1](https://github.com/ipfs/kubo/releases/tag/v0.19.1)**
|
||||
|
||||
|
||||
## **Around the Ecosystem 🌎**
|
||||
|
||||
* [Brave announces automatic NFT backups and enhanced Filecoin support in Brave Wallet](https://brave.com/nft-pinning/)
|
||||
* We're excited to share that the latest version of Brave’s web browser introduces automatic NFT backups to IPFS. Brave Wallet users can avoid the permanent loss of NFT metadata and gain peace of mind thanks to this new feature. [Check it out!](https://brave.com/nft-pinning/)
|
||||
* [Introducing Lassie - a retrieval client for IPFS and Filecoin](https://blog.ipfs.tech/2023-introducing-lassie/)
|
||||
* Lassie makes it easy to fetch your data from both the IPFS and Filecoin Network - it will find and fetch content over the best retrieval protocols available. [Read more about it on the IPFS blog](https://blog.ipfs.tech/2023-introducing-lassie/)!
|
||||
* [IPFS Implementations: It’s Definitely A Thing](https://blog.ipfs.tech/2023-03-implementation-principles/)
|
||||
* In a new blog post,[ Robin Berjon](https://twitter.com/robinberjon) talks about how the world of IPFS implementations has diversified greatly over the past 9 months: “Springtime in the distributed hemisphere and we are frolicking across fields of tantalizing IPFS flowers.” [Read the entire blog post](https://blog.ipfs.tech/2023-03-implementation-principles/)!
|
||||
* [IPFS Open Metaverse Base Camp Accelerator](https://outlierventures.io/ipfs-open-metaverse-base-camp/)
|
||||
* The latest cohort kicked-off on May 8, 2023. Co-delivered by Protocol Labs and Outlier Ventures, the program will run for 12 weeks and provide the teams in the cohort with the knowledge, networks, and capital they need to succeed as startups in Web3. Teams will pitch their products and services at Demo Day in August. [Visit the website to learn more!](https://outlierventures.io/ipfs-open-metaverse-base-camp/)
|
||||
|
||||
|
||||
## **IPFS Thing 2023 on YouTube 📺**
|
||||
|
||||
All of the talks and presentations from this year’s gathering of the IPFS implementers community are now available on YouTube. If you weren’t able to attend, now is the perfect chance to catch up! Below you will find links to playlists for each content track:
|
||||
|
||||
* [Opening & Keynotes](https://www.youtube.com/playlist?list=PLuhRWgmPaHtRnO5G2EF0RxYebcQzLDf5F)
|
||||
* [Community & Governance](https://www.youtube.com/playlist?list=PLuhRWgmPaHtTIFbOVO5YfXkoFg6wIGbBN)
|
||||
* [Integrating IPFS](https://www.youtube.com/playlist?list=PLuhRWgmPaHtTI0MS6ZjSJjBxZp7rcjSS_)
|
||||
* [Decentralized Compute & AI](https://www.youtube.com/playlist?list=PLuhRWgmPaHtQ_lKtbTR-vIW1LYuTjcaPw)
|
||||
* [HTTP Gateways](https://www.youtube.com/playlist?list=PLuhRWgmPaHtTapMgLW7rRh92Tk8u7wip5)
|
||||
* [Content Routing](https://www.youtube.com/playlist?list=PLuhRWgmPaHtRBWV3SvInC5ATS8aKV3lsW)
|
||||
* [Interplanetary Databases](https://www.youtube.com/playlist?list=PLuhRWgmPaHtTO8hr2CYiJPTSe7wybW_op)
|
||||
* [IPFS on the Web](https://www.youtube.com/playlist?list=PLuhRWgmPaHtQ-TO65P62tqfUM85HCIqSj)
|
||||
* [Data Transfer](https://www.youtube.com/playlist?list=PLuhRWgmPaHtS6WBDGK8oxcBHA6ILKatVk)
|
||||
* [IPFS Deployments & Operators](https://www.youtube.com/playlist?list=PLuhRWgmPaHtTYOY5l8nehP_Vt6Ek-svrp)
|
||||
* [Measuring IPFS](https://www.youtube.com/playlist?list=PLuhRWgmPaHtQkkbiq-PbIkt9_S2NjJz6x)
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 182 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 418 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.6 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 55 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 78 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 495 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 65 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 118 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 68 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 81 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 152 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 51 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 135 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 67 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 95 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 39 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 434 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 89 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.7 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 682 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 423 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.3 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.6 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 916 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 842 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1014 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 310 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 62 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 211 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 322 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 70 KiB |
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user