3 ms·

I absolutely love the simplicity of Scuttlebutt, but the APIs and (dev)user extensibility are anything but, imo. I hope for continued work there. As an example

I absolutely love the simplicity of Scuttlebutt, but the APIs and (dev)user extensibility are anything but, imo. I hope for continued work there. As an example, i wanted to write an application on top of SSB. I found it difficult to determine _how_ to achieve this though. Conceptually the appendlog is stupid simple, but SSB still has meaningful complexity in the secure handshake implementation. While they do have libs, it mostly seemed JavaScript (NodeJS) was the only meaningfully complete lib to use (where as i am on Rust). I also found it difficult to determine what the network would accept. 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 had difficulty conceptualizing how to write app data in SSB. It felt like i needed to abandon SQL or common application interfaces for data. Having to reinvent wheels in the application code because SSB-data is mostly (i think?) a JSON blob store felt bad. Shared identities also proved to be a bit of a blocker. 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. I didn't want to invent my own mechanism that would later seem invalid to the community. For now i decided to hold off and implement my own SSB friendly data storage mechanism. 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 imagine my own data later will plug into SSB without issue. These aren't critiques of SSB exactly, just highlighting some areas (for anyone interested) where SSB is currently weak in my mind. I love SSB. Even if i end up using an entirely different p2p tech stack than SSB, it has changed my way of thinking on this. What SSB does right is everything that i dislike about IPFS. SSB is small, simple tooling. It feels like Git. Not some huge complex network of IPFS nodes, but 2 people, 3 people. It can work over P2P, email, floppy disk. It can be more, but it also can be less. And that's something more projects could adopt.

pmayrgundter 6y ago
Thanks for the analysis. Have you checked out Matrix? I'm looking for a p2p network layer and am most attracted to it so far but haven't used any of them yet
- adkadskhj 6y ago
  I've been debating Matrix too! Though, i've not looked into it. My hope was to make (as i mentioned) a Git-like layer for my data that was in the way i wanted (wheels reinvented hah), which would work over SSH/Email/etc, and then plug it into a mature P2P setup. Matrix is definitely on the list of P2P impls i want to look into. Though so far i've never heard of anyone actually using Matrix for a generic P2P backend. I'm curious what you've found on Matrix for this use case?
  - pmayrgundter 6y ago
    Just been poking around the site really, and I dig their vision. This in particular is inspiring and exactly what I've been hoping for too for a long time: https://matrix.org/blog/2017/04/04/opening-up-cyberspace-with-matrix-and-webvr https://matrix.org/blog/2017/04/04/opening-up-cyberspace-wit...
nanomonkey 6y ago
I agree that the nodejs implementation makes contributing and using the libraries difficult. There are rust libraries being worked on and incorporated into the project as we speak, so if you feel like contributing, now might be a good time to look back into the project. Alternatively, if you're interested in a replicated datatype that was written specifically for Rust, which is more compact than JSON, I'd suggest looking at RON: http://replicated.cc/ http://replicated.cc/ https://github.com/gritzko/ron https://github.com/gritzko/ron
jhardy54 6y ago
I've wanted to write a longer blog post about this, but after a few years of working on SSB I appreciate you highlighting these pain points. I think everyone in the SSB maintainer community feels the same way. My hot take: Scuttlebutt should be something that you can implement yourself in an afternoon. I've done this a few times, using Python, Node.js, and Deno, but I've only implemented the message type. (Not Multiserver, MuxRPC, Secret-Handshake, Box-Strean, Private-Box, or any of the other protocols that are associated with SSB.) > It feels like Git. You got it. You could express an SSB chain with Git and a pre-commit hook (to verify messages), but using Git as your database is even harder than learning the toy database that SSB uses. Various links: - My SSB data expressed as a Git repository (outdated): https://github.com/christianbundy/ssb-git-data https://github.com/christianbundy/ssb-git-data - My speedrun SSB implementation with SQLite, using HTTP for replication: https://github.com/christianbundy/http-ssb https://github.com/christianbundy/http-ssb

pmayrgundter 6y ago

Thanks for the analysis. Have you checked out Matrix? I'm looking for a p2p network layer and am most attracted to it so far but haven't used any of them yet

adkadskhj 6y ago
I've been debating Matrix too! Though, i've not looked into it. My hope was to make (as i mentioned) a Git-like layer for my data that was in the way i wanted (wheels reinvented hah), which would work over SSH/Email/etc, and then plug it into a mature P2P setup. Matrix is definitely on the list of P2P impls i want to look into. Though so far i've never heard of anyone actually using Matrix for a generic P2P backend. I'm curious what you've found on Matrix for this use case?
- pmayrgundter 6y ago
  Just been poking around the site really, and I dig their vision. This in particular is inspiring and exactly what I've been hoping for too for a long time: https://matrix.org/blog/2017/04/04/opening-up-cyberspace-with-matrix-and-webvr https://matrix.org/blog/2017/04/04/opening-up-cyberspace-wit...

nanomonkey 6y ago

I agree that the nodejs implementation makes contributing and using the libraries difficult. There are rust libraries being worked on and incorporated into the project as we speak, so if you feel like contributing, now might be a good time to look back into the project. Alternatively, if you're interested in a replicated datatype that was written specifically for Rust, which is more compact than JSON, I'd suggest looking at RON: http://replicated.cc/ http://replicated.cc/ https://github.com/gritzko/ron https://github.com/gritzko/ron

jhardy54 6y ago

I've wanted to write a longer blog post about this, but after a few years of working on SSB I appreciate you highlighting these pain points. I think everyone in the SSB maintainer community feels the same way. My hot take: Scuttlebutt should be something that you can implement yourself in an afternoon. I've done this a few times, using Python, Node.js, and Deno, but I've only implemented the message type. (Not Multiserver, MuxRPC, Secret-Handshake, Box-Strean, Private-Box, or any of the other protocols that are associated with SSB.) > It feels like Git. You got it. You could express an SSB chain with Git and a pre-commit hook (to verify messages), but using Git as your database is even harder than learning the toy database that SSB uses. Various links: - My SSB data expressed as a Git repository (outdated): https://github.com/christianbundy/ssb-git-data https://github.com/christianbundy/ssb-git-data - My speedrun SSB implementation with SQLite, using HTTP for replication: https://github.com/christianbundy/http-ssb https://github.com/christianbundy/http-ssb