This is IPFS and it theory will use the javascript IPFS server in your browser unless it can find a local IPFS daemon on your machine. (Or perhaps it uses one of the gateways?)
How do they prevent the data from disappearing if everyone disconnects?
This is IPFS and it theory will use the javascript IPFS server in your browser unless it can find a local IPFS daemon on your machine. (Or perhaps it uses one of the gateways?)
How do they prevent the data from disappearing if everyone disconnects?
Currently, PeerPad only uses the JavaScript implementation of IPFS (https://github.com/ipfs/js-ipfs) but using a local daemon if it exists makes sense.
> How do they prevent the data from disappearing if everyone disconnects?
Right now, we're not preventing that. You'll have to be online to share the content (or have someone else pin the content).
We do have a open issue for being able to select a pinning service, which would solve this issue: https://github.com/ipfs-shipyard/peerpad/issues/90
It uses WebRTC for peer-to-peer communication, which is yet unsupported / untested in some browsers.
To answer your question: The collaborative data is saved locally by every participating peer.
There are plans to add remote tracking and pinning, increasing the persistence and availability guarantees: https://github.com/ipfs-shipyard/peerpad/issues/90
If I understand correctly, each keystroke in the pad generates a new snapshot, which has a distinct IPFS ID.
Should the remote pinning service publish a list of all IPFS IDs on the p2p network, and store each individual document (each one keystroke away from the previous one) in the history graph?
Should it keep the complete list of CRDT operations, and map IPFS IDs to CRDT operations IDs, so that it can reconstruct any document when it is requested?
Is there a way to use the properties of CRDT that I am not seeing?
Each keystroke produces a change in the CRDT, which is then eventually propagated to all participating nodes.
Each CRDT message is signed and encrypted before being sent over the IPFS pubsub network.
This protocol is not IPFS-specific, but there are plans to change this: https://github.com/ipfs-shipyard/peerpad/issues/107
The snapshotting occurs over IPFS, producing a static and encrypted self-contained snapshot, published over IPFS.
It is possible to access the CRDT properties inside the core library, where the CRDT is formed: https://github.com/ipfs-shipyard/peerpad-core/blob/master/sr... . This could be exposed if you would require it..
Nevermind. I was testing quickly in the airport between flights. Now I see I just had a flaky connection.