Re: Question collaborative editing - Wikipedia reference

[Qiantan Hong <qhong@mit.edu>]

[-- Attachment #1.1: Type: text/plain, Size: 2611 bytes --]

> 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.

- 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.



[-- Attachment #1.2: Type: text/html, Size: 3785 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1858 bytes --]