Closed clehner closed 7 years ago
oh this is cool!
I was actually just now working on some stuff for this type of thing. https://github.com/dominictarr/multiserver
I could merge this in here, but i think it would collide some concerns, which is the problem with wrapping protocols like this, instead of implementing protocols as transforms, you are continually sprouting new options and modes and you still don't have enough.
once multiserver is ready, I think i'll depreciate secret-handshake/net
if this pull request was converted into a multiserver protocol then i think that would be better,
but I could merge it here in the meantime.
What do you think?
multiserver looks great! would the idea be that listening on tor (or cjdns) would be an alternative to listening on tcp+shs, so there would not be a redundant encryption layer? if so then i would skip this PR.
Would using multiserver change how pubs are advertised in messages?
We'll need to keep shs because it provides mutal authentication to your ssb key. but it would mean we could use just about anything as a transport... oh, yeah... like even ssh!
but multiserver would give us the ability to easily add or upgrade protocols.
when a pub is announced, it would be given with all the addresses that it supports, and the other information required to connect to it.
like [transport_address, security_layer, compression]
etc (where transport_address is a tcp, ws, utp, tor, etc (address might be a domain or ip address, but it depends on the transport)
If we added an tunneling api then you could also connect through a peer `[transport_address, secutity_layer, tunnel: transport_address, security_layer]
If you figured out how to make a server that automatically hooked into tor and created a hidden service, then you could turn this PR into a plugin for multiserver. I had a look with this module, https://www.npmjs.com/package/onionservice but couldn't get it working.
closing, since this is better handled by multiserver
Connect to onion addresses via local SOCKS proxy