Here are some notes of what I have been working on: https://docs.google.com/document/d/18H70nQZVXh5Mw96dj5sUswICj6VKqwtrMjHTatB6ESs/edit?usp=sharing

i like the concept of lowering the barrier of entry to ”the people’s internet”

;)

Youtube, reddit, facebook, all the silos of the internet are becoming increasingly censored.

And they will probably at some point disappear

maybe it might be a decade or two, but eventually

Can someone help me out with this error? Its a recent node (1.3.3-dev from git), tx_index=1, explorer config still default http://95.216.163.181:8080/?search=snow%3An68quspj47vmpz05kdy9nppjlpew9c8xq95z8gxq

Did some styling on the explorer: http://95.216.162.15/

On that error, I suspect you don't have addr_idx=true on the node

yes, correct

@Fireduck Have you thought about utilizing IPFS for the web of nodes that host the content in your design?

Nope, what is IPFS?

Interplanetary File System. It is a distributed network of nodes that host files and each file is addressed with a hash

https://en.m.wikipedia.org/wiki/InterPlanetary_File_System InterPlanetary File System (IPFS) is a protocol and network designed to create a content-addressable, peer-to-peer method of storing and sharing hypermedia in a distributed file system. IPFS was initially designed by Juan Benet, and is now an open-source project developed with help from the community.

Several crypto projects use it in their network

The one that uses it best is bit.tube

Any technical overview?

Who stores the data and what is their motivation?

Hold on let me pull it up

On mobile so hard to find things

From what I know about it, each client in the network hosts a seeding node. The clients are people who utilize the software to access files in the network.

The average Joe using the product can host a seed node if it is integrated into the application

Here is the Github with links to everything about it including the technical speca

https://github.com/ipfs/specs/blob/master/README.md ``` # Specifications  [ [ [ [ > This repository contains the specs for the IPFS Protocol and associated subsystems. Some day we will hopefully transform these specs into RFCs. For now, they assume a high level of familiarity with the concepts. ## Table of Contents - [Work In Progress](#work-in-progress) - [Specs](#specs) - [High level Architecture of IPFS](/architecture) - [IPLD](https://github.com/ipld/specs) - [libp2p](https://github.com/libp2p/specs) - [IPRS](https://github.com/libp2p/specs/blob/master/IPRS.md) - [bitswap](/bitswap) - [Files API and MFS](/files) - [Public API (CLI, HTTP and Core)](/public-api) - [DEX - Importers and Exporters](/dex) - [keychain](/keychain) - [keystore](/keystore) - [Repo](/repo) - [Protocol Driven Development](https://github.com/ipfs/pdd) - [Contribute](#contribute) - [License](#license) ## Work In Progress **Specs are not finished yet. We use the following tag system to identify their state:** -  - this spec is a work-in-progress, it is likely not even complete. -  - this spec is a rough draft and will likely change substantially. -  - this spec is believed to be close to final. Minor changes only. -  - this spec is likely to improve, but not change fundamentally. -  - this spec will not change. Nothing in this spec repository is `permanent` yet. The most important pieces of IPFS are now `reliable` or `stable`. Many subsystems remain as `draft`. Note that, as in many IPFS repositories, most of the work is happening in [the issues](https://github.com/ipfs/specs/issues/). Go take a look! ## Specs The specs contained in this repository are: **IPFS Protocol:** - [protocol](/architecture) - the top-level spec and the stack - [overviews](/overviews) - quick overviews of the various parts of IPFS **Networking layer:** - [libp2p](https://github.com/libp2p/specs) - libp2p is a modular and extensible network stack, built and use by IPFS, but that it can be reused as a standalone project. Covers: - network - the network layer spec - routing - the routing layer spec - kademlia - Kademlia DHT - relay - the relay protocol - dnssd - mDNS for local area networks - snr - supernode delegated routing - multirouter - combines multiple others **Records, Naming and Record Systems:** - [IPRS](https://github.com/libp2p/specs/blob/master/IPRS.md) - InterPlanetary Record System - IPNS - InterPlanetary Naming System **Data Structures and formats:** - [IPLD](https://github.com/ipld/spec) - InterPlanetary Linked Data. - [unixfs](/unixfs) - [multiformats](http://github.com/multiformats/multiformats) - [multihash](https://github.com/multiformats/multihash) - self-describing hash digest format. - [multiaddr](https://github.com/multiformats/multiaddr) - self-describing addressing format. - [multicodec](https://github.com/multiformats/multicodec) - self-describing protocol/encoding streams (note: a file is a stream). - [multistream](https://github.com/multiformats/multistream) - multistream is a format -- or simple protocol -- for disambiguating, and layering streams. It is extremely simple. **Files / Mutable File System:** - [Files Impl and API](/files) - Virtual File System interface, unix like, on top of the MerkleDAG **Block Exchanges:** - [bitswap](/bitswap) - BitTorrent-inspired exchange **Specific Internal Components:** - Blocks and Block Service - DAG and DAG Service - Data Importing - [Repo](/repo) - IPFS node local repository spec **Public APIs:** - [Core API](/public-api/core) - IPFS programatic interface - [HTTP API](https://github.com/ipfs/http-api-spec) - IPFS HTTP API specification - [CLI](/public-api/cli) - Command Line Interface **Key Management:** - [KeyStore](/keystore) - Key management on IPFS - [KeyChain](/keychain) - Distribution of cryptographic Artificats **Other/related/included:** - [PDD](https://github.com/ipfs/pdd) - Protocol Driven Development ## Contribute Suggestions, contributions, criticisms are welcome. Though please make sure to familiarize yourself deeply with IPFS, the models it adopts, and the principles it follows. Please be aware that specs are really hard to design by committee. Treat this space like you would the workshop of an artist. Please suggest improvements, but please don't be disappointed if we say no to something. What we leave out is often more important than what we add in. Feel free to join in. All welcome. Open an [issue](https://github.com/ipfs/specs/issues)! This repository falls under the IPFS [Code of Conduct](https://github.com/ipfs/community/blob/master/code-of-conduct.md). [ ## License TBD. See https://github.com/ipfs/specs/issues/137. ```

What prevents me from filling it with TB of nonsense?

None that I know of. If you allow anyone to upload to the network via their client, then anyone can do anything with it. I would come down to you limiting that access in the client software

If someone really wanted to spam the network then they would need to find their own way to access the network not through your client software

do you know how much network overhead it has for random access?

I imagine it depends on how much data is stored on it

The files are distributed on the network so scaling is pretty efficient. The more nodes on the network equals less overhead for a person hosting a node

The more centralized means a lot more resources are used for a host

I was thinking of mining over it, but thats probably not an option anyway

No you can't mine on it. It only hosts files. You would need to host IPFS separate from the SnowBlossom blockchain

But you could make it where being able to access the network through the client requires Snow

Something along these lines. I wouldn't make snow a prerequisite to use the network

Projects that require coins to use the product don't do well

It could maybe host the snowfields

For the IPFS sort of thing, everyone needs to be able to write as much as they want to their own channels

if anyone else cares to mirror and seed is another question

I think I am going to be reimplementing a lot of what IPFS does, but need this channel overlay layer to do what I have in mind