3 ms·

If you don't mind me asking, what browser and version did you use? It uses WebRTC for peer-to-peer communication, which is yet unsupported / untested in some b

by pgte 9y ago

If you don't mind me asking, what browser and version did you use? 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 https://github.com/ipfs-shipyard/peerpad/issues/90

espadrine 9y ago
How would remote pinning work? 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?
- pgte 9y ago
  Remote pinning would work as any other node that you give the permissions to read the feed. This node would follow the CRDT changes, persisting them locally. 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 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/src/backend/crdt.js https://github.com/ipfs-shipyard/peerpad-core/blob/master/sr... . This could be exposed if you would require it..

by pgte 9y ago

espadrine 9y ago

How would remote pinning work? 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?

pgte 9y ago
Remote pinning would work as any other node that you give the permissions to read the feed. This node would follow the CRDT changes, persisting them locally. 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 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/src/backend/crdt.js https://github.com/ipfs-shipyard/peerpad-core/blob/master/sr... . This could be exposed if you would require it..