Re: Question collaborative editing - Wikipedia reference

[Ergus]

This email is from my absolute ignorance about advanced networks:

On Tue, Oct 27, 2020 at 10:45:28PM +0000, Qiantan Hong wrote:
> > Just as Gobby editor, it leaves connecting issues to the
> > administrator, it does not solves it itself. It is external issue.
>
> We might be able to automate this as best effort and eliminate
> the need for any network knowledge/expertise for most users.
> I will explain below.
>
> > Sorry for coming late to the party, and for this naïve and perhaps repeated 
> > question/suggestion (I tried searching the archive but could not find any efficient 
> > or reliable way), but can some service running on Savannah or Gnu.org 
> > <http://gnu.org/> act as the central point, for those cases when the 
> > collaborators cannot easily connect by other means?'
>
> I don’t think that’s an ideal way to do it, unless we really don’t know
> how to do it by other means, for the followingreasons:
>
> - I assumes either Savannah or Gnu.org <http://gnu.org/> server is just a 
> single server
> with a fixed geolocation on the planet. It might work well for computers
> around it, but the latency will be huge if the computer happen to be
> in the other hemisphere from our server. CDN can’t help anything here.
>
> - This will overlay all the traffic through GNU server, which is unnecessary
> in lots of cases (e.g. when it’s possible to use STUN to traverse the NATs).
> That will put maintenance burden on the server admin I think
>
> I’m roaming through relevant material recently and I think I have those
> options in mind
>
> - use libnice to do the NAT traversal job. It will be convenient if there’s
> any TCP tunneling tool built on libnice. Nobody mention any so far, so
> maybe we need to implement one in C.
From my point of view (where I usually tend to reinvent the wheel). The
GNU servers could act just as "rendezvous" servers to establish the
connections between remote users.

Lets say a users1 starts a public-remote session and gets a hash, ID,
whatever. Then share that hash with the other users and they can connect
directly to his emacs. To add extra security, the user could have
another hash that is never sent to the server but used to autenticate on
his session and needs to be shared directly with his "friends".

The server is somehow a cheap process that only receives requests like
"new session -> store ip+port -> return hash (ID)" and "connect to ID
(the hash): return ip+port". With a timeout +keep-alive check and so.

After that we only need a UDP hole punching algorithm to connect
remotely directly between emacs servers p2p. This is very simple to
implement in C, the algorithms for hole punching are actually very
simple, considering the complex architectures (old and new) and with
this we can cover probably most of the networks around, complex NATs and
90% of the routers ISP providers around.

The central server does not need to know/store/log or get track of the
connections between remote session, redirect any editing information. It
just remember the sessions started or that sent a keep alive in the
last... lets say 15 minutes.

I didn't find any library to do this and I am totally out of time, I
tried some basic examples available on internet/github codes and they
seemed to work for simple application traversing the NATs...

Just as examples:

[1] https://github.com/ckennelly/hole-punch
[2] https://github.com/mwarning/UDP-hole-punching-examples


> - use ipfs p2p tunneling functionality
> https://docs.ipfs.io/reference/cli/#ipfs-p2p 
> <https://docs.ipfs.io/reference/cli/#ipfs-p2p>
> I can immediately add some elisp to automate this such that user just issue
> the new session Emacs command, then get a accessible IPFS URI,
> if we think this is the way to go. I dislike the IPFS implementation however
> because it’s return in a UNIXer language whose name shall not be mentioned.
> Also IPFS is not a GNU project.
>
> - use Tor hidden service.
> It happens to traverse NAT (or some firewall) as a byproduct of its anonymity.
> Some drawback
>   + we also pay the anonymity tax - lower bandwidth and higher latency,
>      because of the relays between.
>   + starting hidden service require changing some config file and usually
>      require root access, which make it a bit more cumbersome to automate
>      in Elisp.
>
> - GNUnet. I wish we were running our whole Internet over it. However
>   I doubt gnunet-cadet is usable with acceptable latency right now.