Comment by 2color
1 year ago
As someone who's been active in the IPFS community, it's really exciting to see how Anytype uses content addressing to manage and sync data under the hood (https://github.com/orgs/anyproto/discussions/15).
I think the fact that local-first P2P apps cannot be built directly on the web is a shame, some of the building blocks, like WebRTC are there, but browsers still lack some APIs to allow for more bottom-up innovation and experimentation with new protocols in the browser.
TLDR for others: Anytype is using IPLD (https://ipld.io/), which is a project that came out of IPFS, but Anytype doesn't use IPFS itself (nor libp2p, or multiformats).
Seemingly they felt it was necessary to write their own network layer and more as stable identifiers and logic for merging documents was too complicated to put on top of IPFS:
> We also considered using IPFS, but its approach to content identifiers didn’t meet our use cases. While IPFS could address our requirements for hybrid networking, it uses CID to describe documents, and this CID changes with each modification. However, we need documents to have stable identifiers for linking and other purposes.
> Creating stable identifiers and implementing logic to merge different document states on top of IPFS would be too complex, so we chose a straightforward approach.
Not sure I understand correctly. They found the data model of IPFS not good enough, so they ended up using the data model provided by IPFS in the form of IPLD, but the things they weren't against (the networking layer) were the things they wrote themselves?
Surely I must misunderstand something here.
I'll try to clarify: For syncing objects (anytype native data structure), we use IPLD in conjunction with our own networking layer. For file synchronization, however, we opt for IPFS without libp2p, since a faster method is necessary to improve the user experience. This strategy ensures our file storage is compatible with the public IPFS network and incentive-based storage networks like Filecoin and Arweave. Additionally, it provides a significantly faster experience for our users now. This approach works much better for cases when you have many small files ( what often the case in pkm and communication).
IPLD and IPFS aren't the same thing. In fact the deployed IPFS doesn't use IPLD. Think of IPLD as akin to protocol buffers or GraphQL Schema or JSON schema or JSON-LD. It deals with encoding and representing pointers/links, not networking.
IPFS last I checked still has an extreme bandwidth wasting habit. Unless something has changed, which would be awesome, They spam want lists to all connected peers just in case they have a block of data, and there can be dozens to hundreds of peers at once.
You could make a chromium fork with the server-required measures disabled but so far nobody has succeeded in finding a business model to fund that long term.
There's no server required measures. There's even a flag that lets you treat a specific IP as a secure context for domainless stuff(Hopefully nobody ruins that).
The problem is actual missing features that would need to be added. Mozilla tried with FlyWeb but abandoned the project.