IPZN is a new ZeroNet based on IPFS, which mean it uses IPFS(libp2p) protocol and IPLD datastructure.
To be compatible, it also supports ZeroNet protocol and ZeroNet data structure (Filesystem).
When all users moved to IPZN, the ZeroNet protocol will be possibly abandoned.
Pros:
Cons:
IPZN's purpose is a general purpose d-app platform/framework, make d-app dev easier.
Currently, go-ipfs's pubsub is not finished, js-ipfs's DHT is not done. So we have to wait for them.
IPZN will support operating IPFS both in js-ipfs direct node js api call, making js-ipfs a dependency, and use js-ipfs-http-client to control external ipfs daemon.
I think we should use typescript, but I haven't learnt it yet.
It has metadata chain, you can think it's chain of content json.
Every site has a metadata chain, each metadata is a ipld block(aka dag object), which has
When you modify a site, the modification is added to pending list.
Then you flush the modifications, all objects are added to ipld by ipfs.add(Not MFS). You got a new metadata
For a user, its contents are stored in 'sites' that has metadata too, for each site respectively.
User contents are propagated with pubsub(WIP).
In api, a ipzn site can query the list of known user content sites.
We won't automatically add user content to sqlite database, except for compatibility.
It takes hours to build a large index site, e.g. search engine horizon. Especially on HDD. Although it seems not significant on small sites, it also has huge effect on performance.
For example, we want to build a decentralized Facebook. Every second a new post is sent, the ipfs client receives the content and adds it to immutable content storage level db, the content won't be modified until garbage collection.
If you use auto sqlite importing，we need a second step after receiving a message.
Because sqlite database is not for storing immutable data, e.g. change post content, the db may be malformed in concurrent operations.
Directly query in ipfs, aggregate data client-side.
In the future, we should use golang for better performance.
Actually partly, and not possible to be fully.
We need multiformats of crypto, encrypt, decrypt and sign, since crypto functions are secure forever. Eddsa is better than what bitcoin uses.
In ipzn, the publoc key and signature are represented as multiformats, but receiving from and sending to ZeroNet, we tranform the format to normal.
Ipzn, in low level, won't care about user content, so data is binary. However, we can't give ZeroNet a content json with a field filled with based encoded random stuff.
So if a site wants compatibility, it needs basic info. And in ipzn, the basic info are stored as bson, but the content to be signed is json. In user content sites, the same.
Give and receive content from ZeroNet, in json.
Sign in json, store in bson.
Note that there's no data directly stored in metadata, only hashes and timestamp.Content json prepared for ZeroNet is a bson of a object in site root directory.
ZeroNet -> Json --Transform--> Bson -> IPZN (-> Dapp)
IPZN -> Bson --Transform--> Json -> ZeroNet
IPZN -> Bson -> Json -> Sign, Bson -> Store
Things above are only for sites wnat compatibility.
We should not use frontend to do heavy work because sometimes the network is very slow if ipzn is running on a vps, i experienced.
So, if things can be done with a single connection, that's good.
Two types of backend, so far
By a node.js pre-render engine, using headless chrome, optional.
For spiders like Google
It's necessary to be indexed by Google
This wastes resources and makes the network centralized, unacceptable for me.
It makes the rich richer, the poor poorer, still not good.
This is the best method, so far, I think
You may say it is not necessary, but imagine that you have some resources, only a few people needs it, there's no enough peers to start downloading from another computer.
So you can download films with bittorrent fastly, and can't download rare stuff.
In order to make others seed your file, when they don't want your file, you have to pay for storage and retrieval.
One day, you also provide file storage to others, you can earn coins then.
That's the transferring of value, which incentives peers to do something.
Except FileCoin for storage, Steemit for quality content, what's missing ?
And with blockchain, we can also:
Centralized dweb search engine can be easily banned, but we really need a search engine for dWeb.
I finally found a way to make decentralized dweb search engine, and of course, not just YaCy.
It seems like a combining of FileCoin and Steemit.
When you search something, the request is broadcasted to all nodes that provide searching service, then they return the result to you. If you are satisfied to the result, you vote for it, and the providers earned money.
Results from nodes are mixed and sorted by their weight/wealth.
Another type of decentralized search engine, this uses less space.
Or it's just a better ZeroSites/index. All nodes can add a description for a site, and sorted by non-blockchain reputation, the peers count a user has.
DAO and the stakeholders in delegated proof-of-stake mechanism give the requester a challenge (e.g. computer generated captcha), and the verifiers vote to determine accept him or not.
Compared to ZeroId, after all, it's still more decentralized.
