03:38:30  * lachenmayerquit (Ping timeout: 260 seconds)
03:38:30  * McJesusquit (Ping timeout: 260 seconds)
03:43:39  * McJesusjoined
03:43:51  * lachenmayerjoined
06:24:41  * fotoveritequit (Quit: fotoverite)
08:14:21  * contrahaxjoined
08:59:15  * contrahaxquit (Quit: Sleeping)
10:50:29  * parshap_joined
10:51:39  * thealphanerdquit (Quit: farewell for now)
10:51:58  * foreigneyejoined
10:52:10  * thealphanerdjoined
10:52:27  * paul_irishjoined
10:52:35  * yangwao_joined
10:53:06  * mikeal_joined
10:53:33  * tanepiperquit (Ping timeout: 260 seconds)
10:53:33  * gozalaquit (Ping timeout: 260 seconds)
10:53:34  * TatumCreativequit (Ping timeout: 260 seconds)
10:53:34  * dubroy__________quit (Ping timeout: 260 seconds)
10:53:34  * parshapquit (Ping timeout: 260 seconds)
10:53:34  * jhieseyquit (Ping timeout: 260 seconds)
10:53:35  * mattronixquit (Ping timeout: 260 seconds)
10:53:35  * mikealquit (Ping timeout: 260 seconds)
10:53:35  * ELLIOTTCABLEquit (Ping timeout: 260 seconds)
10:53:35  * eyeforeigneyequit (Ping timeout: 260 seconds)
10:53:36  * yangwaoquit (Ping timeout: 260 seconds)
10:53:36  * lachenmayerquit (Ping timeout: 260 seconds)
10:53:36  * McJesusquit (Ping timeout: 260 seconds)
10:53:36  * rwaldronquit (Ping timeout: 260 seconds)
10:53:37  * mint_xianquit (Ping timeout: 260 seconds)
10:53:38  * jaz303quit (Ping timeout: 260 seconds)
10:53:38  * paul_irish_quit (Read error: Connection reset by peer)
10:53:38  * jaz303joined
10:53:41  * McJesisjoined
10:53:42  * dubroy__________joined
10:53:52  * dubroy__________quit (Changing host)
10:53:52  * dubroy__________joined
10:54:13  * rwaldronjoined
10:54:22  * mikeal_changed nick to mikeal
10:54:29  * ELLIOTTCABLE_joined
10:55:20  * lachenmayerjoined
10:56:16  * mint_xianjoined
10:56:28  * parshap_changed nick to parshap
11:00:01  * jaz303quit (Ping timeout: 260 seconds)
11:00:01  * jaz303joined
11:00:28  * fotoveritejoined
11:02:04  * tanepiperjoined
11:02:20  * mattronixjoined
11:03:34  * jhieseyjoined
11:03:49  * gozalajoined
11:03:52  * TatumCreativejoined
12:39:36  * fotoveritequit (Quit: fotoverite)
14:05:13  * drayniumjoined
14:49:04  * drayniumquit (Ping timeout: 240 seconds)
14:49:15  <substack>mafintosh: what do you think about aliasing flush-write-stream to be `to2` on npm (which is available)
14:49:26  <substack>that way there is a nice symmetry with from2
14:50:31  * substackis going through stream libs and ogd's mississippi for a stream workshop to put together a good list
14:51:46  * drayniumjoined
15:11:54  * drayniumquit (Quit: ZNC 1.7.x-nightly-20160225-9b31a077 - http://znc.in)
15:12:30  * drayniumjoined
15:19:43  * drayniumquit (Quit: ZNC 1.7.x-nightly-20160225-9b31a077 - http://znc.in)
15:33:03  <mafintosh>substack: i like that
15:54:30  <substack>also "to2" is a funny name
16:07:44  * contrahaxjoined
16:15:56  <yoshuawuyts>redis streams! - https://twitter.com/antirez/status/739396440552800256
16:21:40  <yoshuawuyts>clients keep cursors on a log structure that Redis hosts, allowing for consumption at their own pace of data - apparently like Kafka but minus buying into the complexity it brings
16:27:12  <substack>why not save a step, and turn every client into a server
16:27:25  <substack>mafintosh: https://www.npmjs.com/package/to2
16:28:55  <yoshuawuyts>substack: you mean that as in replicating the data in a swarm?
16:30:21  <substack>if a node needs some data, it seems like the best architecture is for that node to connect to the producer of the data and to other nodes that are interested in that same data
16:30:46  <substack>because then there is no bottleneck and the load can be spread out
16:31:05  <substack>it also means you can be really bad at devops
16:32:00  <substack>it also means your system will magically handle rolling network outages
16:33:51  <substack>it also means you can use signing and crypto to handle security instead of api tokens or some other hack of a solution
16:37:43  * contrahaxquit (Quit: Sleeping)
16:39:10  <substack>and I mean, if you are already building a distributed system, might as well go all the way!
16:45:48  <yoshuawuyts>but for a mad amount of data, wouldn't the overhead of the message metadata seriously impact the network? - with a redis cluster living on every node, replication is handled by redis as the cluster, onto which other nodes can latch and consume at their own pace - dropping the data once they're done; with optimized datastructures for this in Redis
16:46:15  <yoshuawuyts>I think I'm seeing what you're saying as an equally viable alternative - ghmmm
16:47:03  <yoshuawuyts>like: a P2P cluster can definitely be optimized, so the message overhead might be higher initially than something like a Redis stream, but yeah wouldn't per se stay an issue
16:47:46  <substack>I think it would be easier to start out with a naive p2p topology and tune it for particular load profiles
16:48:08  <yoshuawuyts>yup yup
16:48:16  <substack>but then, I don't live in enterprise land where they use these tools so I'm just speculating
16:48:58  <yoshuawuyts>actually I'm intimately familiar with the use case that drove Redis streams as I've consulted on the project
16:48:59  <substack>but I think the scale that you get in fully p2p systems like bittorrent completely dwarfs the size that any enterprise system could ever be
16:49:17  <yoshuawuyts>think what you're saying would work actually
16:50:32  <substack>maroon five is now playing in the distance, in front of the presidential palace
16:50:42  * substackin bucharest
16:51:20  <yoshuawuyts>maroon 5 against humanity
17:51:57  * ins0mniajoined
20:38:23  <substack>mafintosh: browser-sync-stream next needs to support live patching, hot-reload style
20:39:02  <substack>not because I actually want or care about that, but just to one-up all that webpack noise :p
20:40:29  <substack>I think this could be easily done with a patch() function that injects the module definitions from one browserify bundle into another
20:43:04  <substack>you could even live-patch users in production
20:43:10  <substack>because why not
20:51:43  <mafintosh>substack: nice idea. would be great for demos