00:35:06  * DarkGodquit (Ping timeout: 240 seconds)
01:41:06  * devurandomjoined
04:07:49  * SkyRocknRolljoined
05:50:00  * rendarjoined
07:20:33  * SkyRocknRollquit (Ping timeout: 258 seconds)
07:23:06  * DarkGodjoined
07:37:20  * SkyRocknRolljoined
08:47:37  * yumaikaschanged nick to tester
08:47:43  * testerchanged nick to yumaikas
08:55:30  * ld74joined
08:55:59  <ld74>Hey guys, wanted to ask if it's possible to use ECDSA with the openssl lib in luvit
10:36:42  * ld74quit (Ping timeout: 260 seconds)
10:55:24  * DarkGodquit (Remote host closed the connection)
11:54:03  * DarkGodjoined
13:00:02  * ld74joined
13:57:41  * SkyRocknRollquit (Read error: Connection reset by peer)
14:00:22  * ld74quit (Ping timeout: 258 seconds)
14:00:40  * ld74joined
14:39:09  <SinisterRectus>ld74: idk what that is, but this is what luvit uses https://github.com/zhaozg/lua-openssl
14:40:12  <SinisterRectus>via https://github.com/luvit/luvi/tree/master/deps
14:45:35  <creationix>ld74: I don't think our openssl bindings can use it, but I think I packaged some tweetnacl bindings for luvit...
14:46:05  <creationix>related, blake2b bindings https://github.com/creationix/lit-blake2b
14:46:25  <creationix>and tweetnacl https://github.com/creationix/lit-tweetnacl
14:46:41  <creationix>the test app shows how you can consume it https://github.com/creationix/lit-tweetnacl/tree/0004a98edbf7e1f762f5207d3c5441b64d164196
15:47:15  * ld74_joined
15:47:35  * ld74quit (Ping timeout: 240 seconds)
15:47:42  * ld74_changed nick to ld74
15:48:41  <ld74>SinisterRectus: Yeah been using openssl for RSA but was wondering if ecdsa is available. ecdsa is basically similar to RSA, just provides shorter public & private keys while remaining secure the same way.
15:51:10  <ld74>Gonna check tweetnacl creationix, thanks.
16:01:27  <ld74>aw, no prebuilt binary for win x64
16:05:27  <ld74>could we hope for a win prebuilt binary?
16:05:53  <creationix>yeah ed25519 has crazy fast key generation compared to RSA, especially on mobile or web
16:05:59  <creationix>and the shorter keys are nice too
16:06:52  <creationix>ld74: I might have a windows install laying around somewhere, I don't have one handy. Is this something you urgently need?
16:09:09  <ld74>Not urgent but it'd be cool to have.
16:10:05  <ld74>I've been playing around the bitcoin proof of concepts (mining, signing tranasctions etc), trying to somewhat recreate it in luvit to understand it better.
16:10:22  <creationix>nest stuff. I was trying to implement datprotocol in luvit
16:10:30  <creationix>uses a lot of the same crypto as blockchain stuff
16:10:54  <ld74>haven't heard about that. gonna check it out.
16:11:34  * Andolsjoined
16:24:29  * SkyRocknRolljoined
16:28:34  * DarkGodquit (Remote host closed the connection)
16:29:08  * SkyRocknRollquit (Client Quit)
16:29:32  <creationix>ld74: dat's really cool. So far the only implementation is in node.js and it's kinda heavy. I'd love a more efficient implementation for embedded linux devices. https://datproject.org/
16:29:40  <creationix>also #dat here on freenode
16:38:12  <ld74>Yeah looks pretty interesting.
17:04:50  <Soni>what's dat
17:05:44  <creationix>dat is a really nice P2P system for replicating datasets
17:05:57  <creationix>think of it as improved and more flexible bittorrent
17:08:37  <Soni>does it work over NAT?
17:08:48  <creationix>yep, uses DHT and UBP hole punching
17:08:51  <Soni>does it have encryption/security?
17:08:53  <creationix>*UDP
17:09:00  <creationix>yep, encryption and privacy
17:09:06  <Soni>hmm sounds neat
17:09:12  <creationix>and multiple levels of abstraction
17:09:20  <Soni>can it be made lightweight?
17:09:32  <creationix>hypercore is an append-only log, hyperdb is a key/value store, hyperdrive is a full filesystem abstraction
17:09:35  <Soni>and easy to implement?
17:09:51  <creationix>it's fairly easy to implement, but there are a lot of parts
17:09:53  <Soni>and can I just have something to send simple files?
17:11:23  <creationix>libsodium handles all the crypto (ed25519, blake2b, siphash, xchacha20, etc..)
17:11:58  <Soni>I mean is it easy to implement from scratch?
17:12:13  <creationix>depends on your skill level
17:12:15  <Soni>(e.g. pure lua, pure ANSI C, pure python, etc)
17:12:32  <creationix>the crypto bits aren't hard, but assuming you have libsodium, it's not too bad
17:12:46  <creationix>I mean crypto *is* hard
17:13:15  <Soni>how do I send/serve a single file with no metadata other than length?
17:13:47  <creationix>you might be able to make something at the hypercore level
17:14:10  <creationix>peers get a API where they can read any entry by index and get notified when new items are pushed
17:14:15  <creationix>the items can be raw file data if you want
17:14:41  <creationix>hypercore is the hardest part to implement from scratch I think
17:14:48  <Soni>how good is it for short-lived stuff?
17:14:51  <creationix>merkle trees, protobufs, utp, dht,e tc
17:15:07  <Soni>(I wanna get a file from point A to point B only once and be done with it)
17:15:19  <creationix>it's probably overkill for what you want
17:15:31  <Soni>I also want authentication
17:15:34  <creationix>but libsodium directly can help
17:15:41  <Soni>does it do authentication?
17:15:48  <creationix>use secret box (encrypted and authenticated messages)
17:16:05  <Soni>and it does NAT traversal which is a big deal
17:16:55  <creationix>well, libsodium won't help with the nat traveral
17:17:12  <Soni>I need NAT traversal, simple username auth, and serving a single short-lived file
17:17:39  <creationix>so with dat, there are no usernames, anyone with the public key can discover and decrypt a dataset
17:18:05  <creationix>the public key *is* the url, it's never transferred over the network
17:18:15  <Soni>ok
17:18:16  <creationix>dat://[hex od 32 bytes public key]
17:18:28  <Soni>can I nuke the data tho?
17:18:45  <creationix>well, if you stop seeding it, it will be gone
17:18:53  <Soni>ok
17:19:07  <creationix>also you don't have to connect to the bittorrent DHT, you can use a custom signaling server and any protcol
17:19:09  <Soni>eh it's good enough I guess
17:19:18  <creationix>the dat sync protocol just needs a TCP-like stream
17:19:30  <creationix>UTP is a stream on top of UDP so that hole punching is easier
17:19:30  <Soni>does it leak IP?
17:19:40  <creationix>(TCP nat traversal is hard)
17:20:17  <creationix>while you're seeding, your address is obviously visible (how else could anyone connect to you)
17:21:27  <Soni>but say you're sending from machine A to machine B
17:21:38  <Soni>does machine B know machine A's IP?
17:22:00  <creationix>that depends entirely on how you connect them
17:22:06  <creationix>but most likely yes, how else do you connect?
17:22:22  <Soni>using something like i2p?
17:22:31  <creationix>you could host a simple tunnel and have both connect toit
17:22:34  <Soni>where nodes in the network give me path?
17:22:44  <creationix>nat traversal and privacy in one!
17:22:58  <Soni>meh
17:23:14  <creationix>i2p would work too
17:23:23  <creationix>dat's sync protocol doesn't care how you connect
17:23:33  <Soni>i2p is too slow and bulky
17:23:37  <Soni>it needs a router
17:23:40  <creationix>the default discovery and connectivity is UTP discovered using DHT
17:23:45  <Soni>it's not a special-purpose, fast protocol
17:23:50  <creationix>(same as modern bittorrent peers)
17:24:20  <creationix>the fact is, if A wants to send file to B over the internet without exposing it's IP address, it needs to go through a proxy
17:24:25  <creationix>no getting around that
17:24:48  <Soni>ok
17:26:25  <creationix>but if you don't mind hosting a proxy, it can listen on websocket or something.
17:26:25  <creationix>A connects to server passing in discovery key of dataset. Server waits for B to connect with same discovery key and then proxies data between them.
17:26:25  <creationix>The data is E2E encrypted so the tunnel can't actually ready anything
17:26:38  <creationix>discovery key is hash of public key
17:27:17  <creationix>so A gives B the public key url via some side channel, A and B then both connect to server using discovery key
17:27:58  <creationix>once the file transfer is done, A simply disconnects. B could share it with others if it wanted, but that's not A's concern
18:01:26  * ld74quit
18:53:05  * DarkGodjoined
18:59:37  * ld74joined
19:05:52  <Soni>creationix: looks interesting tho
19:06:01  <creationix>yep, lots of fun
19:28:26  <Soni>creationix: wanna help me replace IRC DCC?
19:28:35  <Soni>creationix: any way to do chat over dat?
19:28:46  <Soni>(even if not particularly fast)
19:33:28  <creationix>dat replicates very fast
19:33:36  <creationix>pushes are live to anyone connected
19:33:57  <creationix>but a single hypercore has only one writer, so for a chat room, you'd need multiple hypercores (one for each person talking)
19:34:31  <creationix>hyperdb has multi-writer using multiple hypercores, but is also adds on a HAMT structure for k/v storage
19:34:55  <creationix>I'd like something in between that's multi-writer, but still a set of raw append-only streams
19:47:40  <Soni>creationix: so one-on-one DCC chat is easy?
19:49:57  <creationix>sounds easy. Just share public keys with eachother and connect computers to replicate the two datasets
19:50:27  <creationix>messages can contain msgpack serialized data so that you can mix messages and files
19:50:47  <creationix>and the peer can choose to download files or now (dat supports lazy syncing)
19:50:53  <creationix>*download or not
20:05:50  <Soni>cool
21:11:23  * Andolsquit
21:27:56  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
21:35:03  * ld74_joined
21:36:35  * ld74quit (Ping timeout: 240 seconds)
23:49:30  * ld74_quit