Git-ssb is a great proof of the Secure Scuttlebutt community eating its own dogfood. Great Work!
+1. I think it’d be cool if lobste.rs had its own Pub server. What do you say @pushcx?
I don’t know much of anything about ssb but am generally in favor of novel ways to distribute Lobsters links and comments. Grab me on IRC sometime and we’ll talk about what you’re planning before you get too deep into coding.
Dogfood has a negative connotation. Is this like a dry joke or a commendation?
It’s an industry term at this point
right right I just was trying to see if it wasn’t negative because often the term is used disparagingly.
I don’t read it as negative in this case but @soapdog Is the one who can answer for sure.
@voronoipotato and @gerikson, no negative connotation was implied. I used the term as a positive aspect of the ecosystem (which I am a part of). I like when I see communities building their own tools on top of their own tools :-)
This link may be an easier one to understand for people not familiar with SSB
It talks about how to move your code from Github into a decentralized SSB. Even if you don’t want to actually do the conversion, it explains how it all works.
I like the truly p2p aspect here, but it’s a big red flag that SSB seems to refer to a specific node.js implementation and not to a wider protocol with multiple implementations. I did a bit of digging and couldn’t find anything, but maybe I missed something?
The protocol is defined: https://ssbc.github.io/scuttlebutt-protocol-guide/
rust client: https://crates.io/crates/ssb-client
Other versions(go, c, etc) are being worked on as well.
A pity the signing / marshalling algorithm is such a PITA to implement (the signature must be the last key/value pair in the JSON document, and it signs the bytes of the document up to that point).
and order has to be maintained. Indeed. Not sure why they designed it that way.
At least being able to produce a known canonical order is important for signing. And the signature cannot be part of that which it signs.
Oh yeah - the canonical form is nonexistent, you just sign whatever bytes you’ve written so far.
If you were signing a message body (eg a json string value) it would be different - but as it stands relays have to implement white space compatible json marshalling with the sender.
duh! sorry, you are right! asleep at the wheel apparently when I wrote that :)
Having alternate clients is a good start, but is it still true that there’s only one server implementation?
I believe someone is working on a go implementation, but I don’t know where the code may be, and I’m not on my SSB machine to try and find it. But there is definitely only one that’s usable at the moment, that I’m aware of…
and I agree, it’s a good start. It’s also not smartphone/mobile ready yet either, but work is happening on that front as well.