Peer-to-peer hypermedia protocol


IPFS powers the Distributed Web

A peer-to-peer hypermedia protocol to make the web faster, safer, and more open.

Forum Matrix IRC Discord Changelog #204


Full contents

Quick summary

The IPFS project seeks to evolve the infrastructure of the Internet and the Web, with many things we've learned from successful systems, like Git, BitTorrent, Kademlia, Bitcoin, and many, many more. This is the sort of thing that would have come out of ARPA/DARPA, IETF, or Bell Labs in another age. IPFS is a free, open-source project with thousands of contributors.

IPFS (the InterPlanetary File System) is a hypermedia distribution protocol addressed by content and identities. It enables the creation of completely distributed applications, and in doing so aims to make the web faster, safer, and more open.

IPFS is a distributed file system that seeks to connect all computing devices with the same system of files. In some ways, this is similar to the original aims of the Web, but IPFS is actually more similar to a single BitTorrent swarm exchanging Git objects. You can read more about its origins in the paper IPFS - Content Addressed, Versioned, P2P File System.

IPFS is becoming a new major subsystem of the internet. If built right, it could complement or replace HTTP. It could complement or replace even more. Let's go point-by-point into how.

IPFS is a protocol:

  • Defines a content-addressed file system
  • Coordinates content delivery
  • Combines Kademlia + BitTorrent + Git

IPFS is a file system:

  • Has directories and files
  • Is a mountable filesystem (via FUSE)

IPFS is a web:

  • Can be used to view documents like the conventional web
  • Files are accessible via HTTP at<path>
  • Browsers and extensions can learn to use the ipfs:// URL or dweb:/ipfs/ URI schemes directly
  • Hash-addressed content guarantees authenticity

IPFS is modular:

  • Connection layer over any network protocol
  • Routing layer
  • Uses a routing layer DHT (Kademlia/Coral)
  • Uses a path-based naming service
  • Uses a BitTorrent-inspired block exchange

IPFS uses crypto:

  • Cryptographic-hash content addressing
  • Block-level deduplication
  • File integrity plus versioning
  • File-system-level encryption plus signing support

IPFS is p2p:

  • Worldwide peer-to-peer file transfers
  • Completely decentralized architecture
  • No central point of failure

IPFS is a CDN:

  • Add a file to the file system locally, and it's now available to the world
  • Caching-friendly (content-hash naming)
  • BitTorrent-based bandwidth distribution

IPFS has a name service:

  • IPNS, an SFS-inspired name system
  • Global namespace based on PKI
  • It serves to build trust chains
  • It's compatible with other NSes
  • Can map DNS, .onion, .bit, etc to IPNS

Learn how IPFS works

To learn more about how IPFS works, explore the following resources:

Current state of IPFS

IPFS is a work in progress! It is an ambitious plan to make the internet more free, open, secure, and high-performance. It builds on the good ideas of numerous battle-tested distributed systems.

Today, there is one main, reference IPFS protocol implementation (in Go) with more on the way (including JavaScript and Python).

Try it out

The go-ipfs implementation was released as an alpha distribution in February 2015 and since then has been making regular releases on the road to beta. Notably, js-ipfs is also well along the way in progress. Want to get started with the IPFS alpha? Try these resources:

A word on security

The IPFS protocol and its implementations are still in heavy development. This means that there may be problems in our protocols, or there may be mistakes in our implementations. And — though IPFS is not production-ready yet — many people are already running nodes on their machines, so we take security vulnerabilities very seriously. If you discover a security issue, please bring it to our attention right away!

If you find a vulnerability that may affect live deployments — for example, by exposing a remote execution exploit — please send your report privately to [email protected]. Please do not file a public issue.

If the issue is a protocol weakness that cannot be immediately exploited, or something not yet deployed, just discuss it openly.

Get involved

The IPFS project is big — with thousands of contributors in our community — and you're invited to join! Check out the Community section of the IPFS Docs for all the details on how to get involved, including the official IPFS forums, our chat channels, social media, meetups and ProtoSchool workshops, and more.

If you're interested in how the project is organized at a higher level, visit the IPFS Team & Project Management repo.

There's also a weekly IPFS newsletter (subscribe here) and regularly-updated blog.

Help and documentation

If you're looking for help learning about or building with IPFS, start with these resources:

If you've found a bug or want to make a feature request regarding a specific component of IPFS, please open an issue in the appropriate repo so that it can be triaged and responded to as quickly as possible.

Links and resources

The IPFS project is big (and expanding every day!), so we've excerpted some frequently-used links and other resources below. However, we encourage you to explore both the main IPFS GitHub org (for core implementations and other mission-critical work) and the IPFS Shipyard GitHub org, home to incubated projects by the IPFS community.

Protocol implementations

These are the current implementations of IPFS:

Language Project Completeness
Go reference
JavaScript alpha
Rust alpha
Python starting (inactive)
C starting (inactive)

If you would you like to start your own language implementation of IPFS, check out the Specifications. The specs are still evolving, but the core formats are stable and can be built on. Make sure to post an issue if you would like to start an effort, as many people have expressed interest in contributing to new implementations.

HTTP client libraries

The following HTTP client libraries are either complete or under development. All welcome contributions! If you would like to create a new library, please see the IPFS HTTP Client Implementation Guide, and tell us so we can help.

Language Client library Status
Go Active
Java Active
JavaScript Active
Python Active
Scala Inactive
Clojure Active
Clojurescript Active
Haskell Inactive
Swift Active
CommonLisp Inactive
Rust Active Inactive Inactive Inactive
Ruby Inactive Active
Mac Automator Inactive
Pharo Active
PHP Inactive Inactive
C# Inactive Active
C++ Active
Erlang Inactive

GUIs and helper apps

  • ipfs-companion - The IPFS web browser extension.
  • ipfs-webui - The IPFS WebUI app.
  • ipfs-desktop - A menubar/tray desktop app.
  • ipfs-gui - Coordinating development, user experience, and maintenance of IPFS GUIs.
  • i18n - The IPFS Translation Project: crowdsourcing translations of IPFS GUIs and websites.

Apps and data sets on IPFS

  • Awesome IPFS - an ever-growing list of apps, data sets, and other inspirational resources built on IPFS.

Specs and papers

Installation and update tools

Additional resources

  • distributions - Source code for the IPFS distributions website,
  • infra - Tools for maintaining infrastructure for the IPFS community.
  • testground - Tools for testing distributed software at scale.
  • ipfs-cluster - Provides data orchestration across a swarm of IPFS daemons by allocating, replicating, and tracking a global pinset distributed among multiple peers.
  • ipfs-shipyard - A wide range of incubated projects by and for the IPFS community.
  • website - Source code for the IPFS website,



  • IPFS API bindings

    IPFS API bindings

    We've reached a pretty stable API, and IPFS now runs pretty reliably. People are already using IPFS from other languages, primarily JS through

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

    • C/C++
    • C#
    • Erlang
    • Go -
    • Haskell
    • Java -
    • Javascript -
    • Lua
    • PHP
    • Python -
    • Ruby
    • Rust
    • ObjC
    • Swift
    • Scala -

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

    opened by jbenet 76
  • IPFS-LD - Linked Data

    IPFS-LD - Linked Data

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

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

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

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

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

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

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

    opened by jbenet 34
  • IPFS Weekly Updates

    IPFS Weekly Updates

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

    If you would like to have an update in your inbox, sign up for emails at

    IPFS Weekly #1

    Welcome to the first edition of IPFS Weekly!

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

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

    December 21

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


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


    For more updates, see the sprint issue.

    December 14

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



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

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

    December 7th

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


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


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

    Active stuff

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


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

    Thanks, and see you next week!

    • Richard Littauer and Andrew Chin

    Send us feedback about the Weekly

    IPFS Weekly #2

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

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


    Work in Progress


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

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

    • Richard Littauer and Andrew Chin

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

    opened by RichardLitt 31
  • rename *-ipfs-api to *-ipfs-http-client ??

    rename *-ipfs-api to *-ipfs-http-client ??

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

    Other project call these libraries SDK or simply, clients.

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

    opened by daviddias 29
  • 🌟 Do you want to implement IPFS in a new language, get started here!

    🌟 Do you want to implement IPFS in a new language, get started here!

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

    opened by flyingzumwalt 28
  • Why doesn't ipfs use real URLs?

    Why doesn't ipfs use real URLs?

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




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


    Why don't you use that rather than:



    opened by timthelion 28
  • node-Tor is now open source in clear and modular

    node-Tor is now open source in clear and modular

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

    See the demo app

    opened by Ayms 19
  • Permissions



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

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

    opened by nbingham1 19
  • Merge project directory with awesome-ipfs?

    Merge project directory with awesome-ipfs?

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

    opened by fazo96 14
  • IPFS Team Structures - Working & Research Groups (Was:

    IPFS Team Structures - Working & Research Groups (Was: "Proposal: IPFS Working Groups")

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

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

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

    UPDATE: See

    opened by daviddias 13
  • IPFS daemon behind (corporate) firewall

    IPFS daemon behind (corporate) firewall

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

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

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

    How should I configure ipfs to work in such environment?

    opened by pyhedgehog 11
  • [Tracking Issue] Shutdown PL-hosted delegated and preload nodes

    [Tracking Issue] Shutdown PL-hosted delegated and preload nodes

    This is a tracking issue for shutting down the PL-hosted delegate and preload nodes that are relied upon currently by js-ipfs. This is discussed in

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

    opened by BigLep 0
  • Cleanup

    Cleanup "docs" around other implementations and the IPFS community

    As part of, we want to:

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


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

    We want to have canonical information about IPFS implementations and community information that other places can link to. is the intended place that we should link to.

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


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

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

    • [x]
    • [x]
    • [x]
    • [ ]
    • [x]
    • [x]
    • [x]
    • [x]
    • [x]
    • [x]
    • [x]
    • [x]
    opened by BigLep 0
  • Add Scheme client

    Add Scheme client

    Howdy o/

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

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

    opened by siiky 1
  • Make default bootstrappers used by IPFS/libp2p be a more robust list.

    Make default bootstrappers used by IPFS/libp2p be a more robust list.


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


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

    opened by BigLep 2
  • Renaming ipfs implementations 2021/2022 edition

    Renaming ipfs implementations 2021/2022 edition


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

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

    Problems To Solve

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

    Proposed Method

    Create 2 separate GitHub discussions in

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

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

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

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

    Others can then:

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

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

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


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

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

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

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

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

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

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

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

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

    What order will the rename happen?

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

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

    Why do this on GitHub?

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

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

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

    Why now?

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

    What about renaming “js-ipfs”?

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

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

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

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

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


    • [x] Get agreement on whether using GitHub discussions or another mechanism
    • [x] @biglep enable GitHub discussions on ipfs/ipfs repo.
    • [x] @biglep create 2 discussions for the votes to do the week of 2021-11-01.
    • #471
    • #473
    • [x] @biglep schedule time to discuss JS naming
    • [x] @biglep schedule time to determine whether to spec/name “an IPFS client”” ~- [ ] @momack2 or @biglep solicit votes/nominations during LabWeek.~
    • [ ] @biglep Outline sequence of events for the actual renaming
    • [ ] @biglep Do 202201 version of nominating/voting, including surfacing better in public (Matrix/Discord,
    • [x] @biglep Setup something like to make clear "go-ipfs" is only one of many
    opened by BigLep 16
A peer-to-peer hypermedia protocol
An imageboard, but images are stored in a peer-to-peer network

Interplanetary File Dumpster An imageboard, but images are stored in a peer-to-peer network Features: Easy file sharing without registration and SMS.

George 94 Sep 30, 2022
DeepValueNetwork is a peer-to-peer database network managed and hosted by its community.

DeepValueNetwork To understand what DeepValueNetwork will be, I suggest you read this document. In progress This software is currently being developed

DeepValue Network 335 Dec 10, 2022
📦 Command line peer-to-peer data transfer tool based on libp2p.

pcp - Peer Copy Command line peer-to-peer data transfer tool based on libp2p. Table of Contents Motivation Project Status How does it work? Usage Inst

Dennis Trautwein 911 Jan 5, 2023
Group peer to peer video calls for everyone written in Go and TypeScript

Peer Calls v4 WebRTC peer to peer calls for everyone. See it live in action at The server has been completely rewriten in Go and all th

Peer Calls 1.2k Dec 30, 2022
gopunch is a go implementation of a peer-to-peer chat service built using UDP hole punching.

Gopunch gopunch is a go implementation of a peer-to-peer chat service built using UDP hole punching. This is a toy implementation that I put together

Peyton Walters 10 May 24, 2022
Steve - A peer-to-peer (p2p) decentralized network

Steve Steve is a peer-to-peer (p2p) decentralized network that enables people to

Steve Care Software Inc 4 Feb 5, 2022
wire protocol for multiplexing connections or streams into a single connection, based on a subset of the SSH Connection Protocol

qmux qmux is a wire protocol for multiplexing connections or streams into a single connection. It is based on the SSH Connection Protocol, which is th

Jeff Lindsay 205 Dec 26, 2022
A simple tool to convert socket5 proxy protocol to http proxy protocol

Socket5 to HTTP 这是一个超简单的 Socket5 代理转换成 HTTP 代理的小工具。 如何安装? Golang 用户 # Required Go 1.17+ go install Docker 用户 docker pull m

mritd 10 Jan 2, 2023
Pure-Go library for cross-platform local peer discovery using UDP multicast :woman: :repeat: :woman:

peerdiscovery Pure-go library for cross-platform thread-safe local peer discovery using UDP multicast. I needed to use peer discovery for croc and eve

Zack 577 Jan 8, 2023
Package arp implements the ARP protocol, as described in RFC 826. MIT Licensed.

arp Package arp implements the ARP protocol, as described in RFC 826. MIT Licensed. Portions of this code are taken from the Go standard library. The

Matt Layher 305 Dec 20, 2022
Gmqtt is a flexible, high-performance MQTT broker library that fully implements the MQTT protocol V3.1.1 and V5 in golang

中文文档 Gmqtt News: MQTT V5 is now supported. But due to those new features in v5, there area lots of breaking changes. If you have any migration problem

null 817 Jan 5, 2023
A TCP Server Framework with graceful shutdown, custom protocol.

xtcp A TCP Server Framework with graceful shutdown,custom protocol. Usage Define your protocol format: Before create server and client, you need defin

xfx 139 Dec 7, 2022
Go library for writing standalone Map/Reduce jobs or for use with Hadoop's streaming protocol

dmrgo is a Go library for writing map/reduce jobs. It can be used with Hadoop's streaming protocol, but also includes a standalone map/reduce impleme

Damian Gryski 103 Nov 27, 2022
Diameter stack and Base Protocol (RFC 6733) for the Go programming language

Diameter Base Protocol Package go-diameter is an implementation of the Diameter Base Protocol RFC 6733 and a stack for the Go programming language. St

Alexandre Fiori 214 Dec 28, 2022
SMPP 3.4 Protocol for the Go programming language

SMPP 3.4 This is an implementation of SMPP 3.4 for Go, based on the original smpp34 from Kevin Patel. The API has been refactored to idiomatic Go code

Alexandre Fiori 198 Dec 13, 2022
Implementation of the FTPS protocol for Golang.

FTPS Implementation for Go Information This implementation does not implement the full FTP/FTPS specification. Only a small subset. I have not done a

Marco Beierer 27 Mar 14, 2022
network multiplexing and framing protocol for RPC

TChannel Network multiplexing and framing protocol for RPC Read the Docs Languages: Node.js, Python, Go, Java Questions: Open a Github issue Uber's OS

Uber Open Source 1.2k Nov 26, 2022
Inspired by go-socks5,This package provides full functionality of socks5 protocol.

The protocol described here is designed to provide a framework for client-server applications in both the TCP and UDP domains to conveniently and securely use the services of a network firewall.

Zhangliu 69 Dec 16, 2022