update ssb-conn to 0.12.0

[staltz]

Updating ssb-conn from 0.11.3 to 0.12 tweaks the scheduler with a few improvements:

• Connect to slightly less staged friends
• Connect to less rooms (from 10 to 5)
• Treat rooms as non-syncable peers

Note though that Patchwork was using ssb-conn 0.10.3 so it will also get these long-due updates:

• Dont use deprecated ssbRef.parseAddress in scheduler
• has-network => has-network2 (removes some weird unnecessary module.exports hacks)
• on-change-network => on-change-network-strict (uses JavaScript "use strict")
• Scheduler: update grace period for connecting peers
• Remove hacks for DHT addresses in the (legacy compatibility) gossip plugin

Other transitive dependencies updated by this PR:

• promisify-tuple: 1.0.0 => 1.0.1
• pull-ping: 2.0.2 => 2.0.3
• ssb-conn-hub: 0.2.4 => 0.2.7
  • make sure all the rpc.close calls have callbacks
  • improve inferredType for DHT peers
  • remove hacks related to DHT addresses
• ssb-conn-query: 0.4.1 => 0.4.4
• ssb-room: 1.0.0 => 1.1.3
  • client plugin: gracefully close RPC connection with server

This PR was tested in production locally on my laptop, I ran Patchwork with these updates and it worked fine.

[Powersource]

Nice,

there's a slightly weird effect when manually disconnecting from everything at the same time. But I'm guessing that was there before.

Only tried this with pubs but at least that works for me :) (btw do you have a room invite I could use?)

[christianbundy]

Thanks @staltz!

Very happy about the 'use strict'. In case you didn't see, I tried to take care of that for all of our dependencies and tracked them here: ssbc/ssb-server#683

[staltz]

there's a slightly weird effect when manually disconnecting from everything at the same time. But I'm guessing that was there before.

It was probably there before. I think unfortunately to fix this properly requires a rework of the connections tab. That's if I interpret "weird effect" correctly as what's in my mind.

@christianbundy This fixed just one or two cases of 'use strict'. Would be good to fix all others. You may notice that it's a fork package, so it bothers Dominic et al less, but it's also a problem that there's a fork. Might try to get it merged into upstream at some point.

[christianbundy]

Would be good to fix all others. You may notice that it's a fork package, so it bothers Dominic et al less, but it's also a problem that there's a fork. Might try to get it merged upstream at some point.

I think forking is the best solution, see this comment. I really wish forks weren't such a hassle, I keep thinking about how cool it would be if we had lots of closely-related forks with slightly different answers to problems like:

• which patches are merged
• npm or yarn
• javascript or typescript
• do we care about strict parsing
• do we care about style guides
• do we care about linter rules
• do we want experiments or stability

I think npm limits us here a lot, but I keep thinking that there might be a simple way to do it with Git maybe a Git-based package manger. 🤔

[staltz]

Oh, seems like you just nerd-sniped yourself! It's either gonna turn out to be an amazing project or a time-consuming one, or both.