very nice stuff!
If I get to play another open air this season, this will definitely be on the menu... :)
the annoyances of devops....
looks like the certificates for viewer.ssb and my git.ssb instance weren't renewed in time..
Sooo here is my blast from the past-ish collection:
feels like ages since I dropped off here... let's see what I missed.
I would have liked to prepare more questions but right now I just wanted to share this:
Depending on the severeness of the underlying annoyance, I found that self-serving tinkering leads to more annoyance if it doesn't work out as fast or good as I hoped/expected.
right and important, while giving me the bored ugh beforehand, leads to a happier buzz afterwards because it's not on the big pile of waiting stuff anymore.
I still do plan to write the spec, but I need to read on v8 and intricacies of utf16 surrogate glyph substitution, and especially document the exact way floats are serialized into json (v8 does so roughly in 4kloc). For the spec to be correct (ie document what all the baked in js semantics do in reality).
@ezdiy: That sounds like a nightmare task... Maybe I misunderstood but you outlined a way that sounded simpler than this on github once.
I fear I know the answer to this but is there a recording available or was it live only?
Nice! Flume feels really snappy!
This also stops the miserable slowdown that can happen after the entire db accidentally gets cached
Thanks a zetaton to all of you!
Having played it now, your fears are correct. It's more of an expansion then a new iteration. More of the (good) same.
These are perfectly valid questions!!
Can only answer the
req of the top of my head. Since both sides can initiate calls, you use the -1 to signal replies.
That sounded harsh... it's a good suggestion! We should make a future features list or issue.
i get your point. It's just that in it's current state every customization involves command or editing .ssb/config.
I think you don't need support in ssb for this. Linux should be able to Cover you using Filesystem links like this:
ln -s /mnt/removable/ssb $HOME/.ssb
backing up ~/.ssb/secret and then rm -rf ~/.ssb would have been a better strategy?
yup, that's how I do it if I'm in doubt about my local state. :)
Is there potential for a netsplit-like situation, where two clusters that are weakly linked can have different ideas about reality and keep diverging?
This potential rises when you break ssb's (current) golden rule of having your
.ssb/secret on multiple devices at the same time. If you create new messages on each of them and manage to get
pub_b you broke replication of your feed for good, since ssb doesn't do any merging.
I didn't follow your incident/post-mortem closely but it sounds like you installed ssb, made some posts that got out, ran into problems, wiped
.ssb but kept the
secret and tried again. In a sense having two virtual devices. Re-using the secret would have been fine if you synced to the old state first.
Hope this compressed explanation made some sense.
oh.. My brain somehow trimed the
Handbook of ... from the OP and thought it meant the Schneier book. Titles.....
also spoiler alert: NaCL/sodium/... is designed with usability in mind. Meaning making it difficult for the writer of the software to build broken things, like using AES but constructing the the block chains wrong or not understanding IVs fully, leading to cryptoanalyis attacks.
that beeing said, if you really want to understand how these constructions work and why they are solid, I'm not sure traveling back through time (meaning starting from todays standards and seeing how they are built) is the best way. Understanding RSA and it's concepts and than going to ECC might be less convoluted. ECC uses similar prinicples but on a different number field IIRC.
what would you imagine the landing page showing instead?
I'm fine with what it displays but thought about a paginated version instead.
Would make it cachable and only return data when the daemon finishes getting it's data (no stalling).
Good to know on the lost connection thing. I guess i'll add a loop/cronjob to restart mine until it's fixed.
This...! Speaking of: we should maybe improve the hosting quallity of git.scuttlebot.io. It hangs most of the time I try it. :-X
Fearing that this would also be true for the 2nd, I only played a couple of levels yet. I have some treveling ahead of me today. Will see how long the new one is afterwards.
I agree, the first one was short. Though I was pumped about it back then and played it in one quick rush.
hrm.. the math roughly depends on which age and kind of crypto you want to learn.
Also not sure if teaching publications caught up to modern stuff like epliptic curves already.
Quite sure they havn't caught up to post-quantum stuff, since good/best practices are still heavily debated.
Also you should think about if you want to learn how to build constructions (primitives like RSA or AES), use them (i don't care about the inner workings of this black box, just tell me how to chain my bytes into them (i.e. pick AES with a certain block mode)) or analyze them (what is the weakness of this specific construction). All of these are pretty wide fields.
I hear the Schneier book is really good to understand does and don'ts for users of existing constructions but that might not be what you are after...
non-paper resource-suggestion-wise, I'd really suggest wikipedia since it offers the most fine grained access to this rabbit-hole.
It will also be hard to follow but you can choose your own path. That whipped up with some talks that offer head-dives into topics. Might not be your style but I like beeing flushed with new ideas and later pick up questions that stuck. The evolution of TLS and it's faults might be an intersting lantern for your journey.
Paging my fellow cypherwizard @keks for further suggestions.
thanks for this! I'm with andre, the more the marryer!
not much to add to what @mikey outlined but if you are like me and like to learn from other implementations, you can have a look into go-muxrpc. Might clean up some brainfog (or add it YMMV ;)). the codec just manages which stream belongs to which rpc call.
once you have that layer, you will see that what the
$ sbot .. cli offers you is also what the sbot peers use to replicate with each other.
It's a thoughtfull puzzler and comes with a kind and loving story line.
Also you get to twist and turn the space around you and walk on walls.
If you like Escher's space bending works and are privileged with an iOS device, I urge you to check out Monument Valley (2).
I'm really _wow_ed by the will power from you guise to do this in C. Big cypher-hats off!
i would target just the minimum needed for replication, and then run scuttlebot locally with the minimal node as its only peer
that is a really good short/medium-term solution!!
similarly to a Bitcoin SPV node
Yes! i Always thought about liteclients like this.
how do you test this stuff?
Have to mull over that one some more but assuming we stick with muxrpc I'd guess black-box-ish? Similary to the test-vectors for shs we could just spec some alice and bob feeds. The test program would then just be a muxrpc client running static queries with expected results.