#dat

i was just running npm install but i think i'll clone from git and start monkeying with node-gyp

it's quite entertaining plugging in a mouse and keyboard to my phone

ls

err, wrong ... computer

hehehe

pvh: using the ssh server in termux is really great for this

pvh: https://termux.com/ssh.html

just found prebuildify too

er, the prebuildify for ia32 from when you did this earlier, i'm guessing?

oh, no, i see that's just what the youths call x86 now

haha ya, what node call it

pvh: which phone are you using?

galaxy s8

this yak's getting a little fuzzy

on the pixel it was easy to setup the ssh stuff and build tools

pvh: i'm guessing the s8 is 64 bit right/

yeah

so far build tools and such have been fine, it's just griping about wanting -fPIC. i'm fiddling with the libutp.gyp but i'm not sure this is a better use of time than just experimenting with my existing apps. i'll keep you posted.

that rings a bell

The fpic stuff

bnewbold_: you suggested adding a timestamp to hyperdb entries right?

been thinking that might be a good idea!

cause that the only time to add a timestamp to a delete

which seems v useful in conflict resolution

pfrazee: thoughts o/

mafintosh: I'm +1 on timestamps yeah

mafintosh: I wasnt clear, are deletes being explicitly recorded now?

pfrazee: yuh (makes multiwriter much easier)

mafintosh: great

as its hard otherwise to see if a delete is a 404 or an actual delete in a conflict scenario

right

mafintosh: I did, but was thinking of it being completely separate from any protocol/automation concerns

bnewbold_: like making it opt-in

bnewbold_: i'm gonna make a proof of concept impl in hyperdb of that

it could definitely help *humans* resolve conflicts

I wouldn't want to incentivize people to fake the timestamps to be "newer" (or even in the future) as a way to force-resolve conflicts

bnewbold_: right

perhaps we need a way to attach metadata to a delete also

bnewbold_: but on machines with v little clock skew (i.e. machines you control) it could be v useful

mafintosh: sorry, i'm a little lacking context but i have also already solved this problem a bit

we concluded that deletes are / should be based on a vector clock and an item identity

but i don't know whether hyperdb has the notion of an update independently from a set

in the event of an ambiguous vector clock between a delete and a value i'd suggest you have a special tombstone value that appears in the nodes list

QUIC API for WebRTC https://w3c.github.io/webrtc-quic

super excited for this

rrrrgh... yoshuawuyts how decent-friendly is QUIC? my extremely poor understanding left me somewhat dubious about QUIC's role in a p2p system

pvh: I tend to think about it mostly as "better TCP"

pvh: a big problem right now w/ WebRTC is that the transport protocol is hard to implement and kind of obscure

pvh: given HTTP/3 is likely going to be HTTP/2 over QUIC, support for it should become reasonably widespread

pvh: but yeah, none of that addresses some of the other problems with WebRTC - feel reading the spec / commenting on it might be useful

pvh: is that.. an answer?

yoshuawuyts: my experience was that WebRTC is ultimately worthless because of the signalling problems

i say this having done a shitload of work on various signalling strategies for http://github.com/automerge/trellis

pvh: yeah, I hear u

are they adding QUIC but not plain old UDP?

there's also just a lot of stuff in there which is extremely important if you're negotiating a video channel and just gratuitously complicated in all other cirumstances

laduke13: it's already built on UDP

with their own ordered channel implementation on top

can't really holepunch TCP :)

but I want regular UDP

pvh: iirc the interest in QUIC was that it was faster at establishing peer connections, which was a big bottleneck in the webrtc implementation of hypercore

laduke13: oh, you can have unordered too

yoshuawuyts: okay, i took a look. my sense is that this is mostly an optimization problem... i think.

what they want to do is listen on a single UDP port for all the various things WebRTC likes to do

https://www.meetup.com/papers-we-love-too/event... for any one in the Bay Area interested in quic

pvh: gotcha

bret: i was going to skip but now yoshuawuyts has me thinking i should go

you can meet my manager :v

who's that?

the speaker David

oh, i think we've met before :)

hmmm, so the biggest question I've got right now is: how important are STUN/TURN?

so, STUN is basically a whatismyIP.com api

this is a bit of an exaggeration, but only a bit of one

they are used for webrtc handshakes iirc

TURN is that except it also handles being a router

TURN is STUN+traffic routing

TURN is for when clients cant be directly connected right?

pvh: TURN forwards traffic through a central server?

TURN is generally the central server, yes

i suppose at some scale you'd probably farm the connection out to a convenient node

what STUN does is return a list of candidate IPs you can offer another peer to connect to

TURN does the same but includes a low-priority candidate that will be the proxy

in-ter-es-ting

so what would a scenario be where you would want to use TURN?

when can't a client connect directly?

well, if you're skype and you don't want someone's shit network topology to result in not being able to route a call

yoshuawuyts: I TURN is the part for that yeah

i believe reading anecdotally that about 95% of calls are routed directly but 5% get carried over TURN

cooool!

if 1/20 skype calls failed that'd be a big problem, so you pay for a bunch of bandwidth around the world and carry the traffic yourself when you can't broker a direct connection

I would need a TURN server at wework, since they block a ton of things, including dat 🤬

maybe

pvh: oh that's interesting

google runs free public STUN servers (which they politely ask you not to use in production at scale) but TURN is expensive project infrastructure

okay, this is all making sense now

cool!

so once you have your STUN packets, you need to give them to your dance partner

that's where the signalling server comes in

for someone with a low budget, using TURN is perfectly ok - but TURN would likely rack up some cost

at the tradeoff that there will be more faults

nice, okay!

you both rendezvous at some shared connection point, say websocket.mycoolapp.com/S3cretMeetingURL

then i pass you the STUN/TURN packets i got and you give me yours

and we both start blind-firing UDP packets at all those addresses

(there's a nonce in there to make sure we find the right peer)

our intervening NAT routers infer a network connection out of the packet flow

now what I wonder is if there's a way to get ephemeral peer connections in that new proposal

I'm guessing... not

it's sort of orthogonal

they appear to be discussing how you'd pack traffic for all these pieces into a single UDP channel

pvh: the QUIC multiplexing one that is, right?

yeah

i mean, ephemeral in what sense?

pvh: to be able to create DHTs

oh, yes, i see

it's generally kind of expensive to connect over webrtc due to all the frippery of SIP and SDP

pvh: connect to a peer, ask questions, disconnect. I bet there's some forwarding network topology stuff you could do - and maybe that's the answer! - but quickly being able to connect on known ports is real useful

you have to STUN/TURN, then go to a signalling server and SIP/SDP and then start making connections

pvh: that's the "here's an offer for someone to connect to" / "the offer is now consumed" bit, right?

on top of all that presumably you need to establish an encrypted channel, all of which takes a few seconds

the tricky part is that both peers need to know the identity of the other

you can't open a UDP channel without the other peer knowing an IP/port to fire packets at

pvh: ah yes, that sounds like what I was thinking about

and that needs to happen concurrently

:(

er, simultaneously

this is why bootstrapping on the bittorrent DHT is kind of great

as long as there are some public nodes you can bootstrap off with real TCP connections you can use that to upgrade to UDP to your peers

same with the littlebits.org DNS-SD servers

pvh: thanks heaps for the explanations btw!

pvh: this is all really helpful :D