Not some huge complex network of IPFS nodes, but 2 people, 3 people. What SSB does right is everything that i dislike about IPFS. Even if i end up using an entirely different p2p tech stack than SSB, it has changed my way of thinking on this. These aren't critiques of SSB exactly, just highlighting some areas (for anyone interested) where SSB is currently weak in my mind. I imagine my own data later will plug into SSB without issue.
Since i know the data layer of SSB is simple, and SSB folks have proven it can handle Git fine (they distribute their source in SSB iirc). I didn't want to invent my own mechanism that would later seem invalid to the community.įor now i decided to hold off and implement my own SSB friendly data storage mechanism. Since the app i was writing wanted multiple devices to author data the notion of a device identity came up, and at the time that didn't seem well (or at all) supported. Shared identities also proved to be a bit of a blocker. Having to reinvent wheels in the application code because SSB-data is mostly (i think?) a JSON blob store felt bad. It felt like i needed to abandon SQL or common application interfaces for data.
Make it pop scuttlebutt how to#
I also had difficulty conceptualizing how to write app data in SSB. If i write an app and start pushing blobs onto the network, will they reject it because they're not of the same type? What if my data is too big? Am i abusing the net? I also found it difficult to determine what the network would accept. While they do have libs, it mostly seemed JavaScript (NodeJS) was the only meaningfully complete lib to use (where as i am on Rust). Conceptually the appendlog is stupid simple, but SSB still has meaningful complexity in the secure handshake implementation. I found it difficult to determine _how_ to achieve this though.
I hope for continued work there.Īs an example, i wanted to write an application on top of SSB. I absolutely love the simplicity of Scuttlebutt, but the APIs and (dev)user extensibility are anything but, imo.
0 kommentar(er)
