Re: Question collaborative editing - Wikipedia reference

[Jean Louis <bugs@gnu.support>]

* Qiantan Hong <qhong@mit.edu> [2020-10-06 04:04]:
> > But this has 3 main problems.
> > 
> > 1) On one hand such services require some servers (to work like google
> > spreadsheet) and need to be provided somehow... something difficult as I
> > don't think gnu or fsf have resources to maintain a service like that
> > and provide it.

Comment on crdt.el in the regard to above quote is that the server is
on Emacs, so there need not be and should not be any third party to
provide any service to provide service to Emacs, as Emacs is providing
server through crdt.el

Please look at how Gobby real time simultaneous editor is working,
that is very similar now to crdt.el

If user have Emacs with public IP address, all such user need to do is
to tell the IP address and port and password to the collaborator, they
can already connect.

If user do not have public IP address but user is behind the router,
then such user who connects over network or administrator who is
helping users to connect over the network is assumed to have
sufficient knowledge how to click few times or setup router to port
forward from local network to public network.

If user has VPS or dedicated server, then such can use ssh to port
forward to the public server, or can use permanent VPN to connect to
other collaborators which is anyway best setup. When I say permanent
VPN, I mean "private" network and not VPN through third parties.

To use VPS, today it is about $5 or less, expenses are not high. 

And let us not forget that there are many organizations where such
collaborative simultaneous editing can take place who need not have
any Internet connection, they may have their hotspots for local
network or ethernet wire networks.

> > 2) On the other hand it will be better if the service is somehow
> > distributed in order to give more privacy-security but also to reduce
> > the load of the servers...

We speak here of editing of a file, not transfer of huge binaries with
many users. So there is no expected high load on the server. I cannot
possibly understand why should simultaneous real time editing be
distributed, maybe you think in similar fashion like Tor is doing it,
but that is all definitely not necessary for Emacs to handle. You can
handle your routing anyway through Tor, I am sure it will work, and
you can route traffic through VPN, SSH and maybe other means. 

> > I still can't find any infrastructure we can
> > use, cause most of the peer-to-peer libraries are for C++, javascript,
> > Node.js and so on (example: webrtc). Just on yesterday I found
> > n2n... But I am not a web specialist so it requires a lot of
> > experimenting time for me.

For crdt.el is definitely not needed, just as in Gobby editor is not
needed. Collaborators who connect over Internet will have enough
networking skills to connect to each other by using methods as I have
explained above. Simplest method is ssh, and if any of collaborators
have public IP exposed, such could be preferred server, and everybody
else could connect to such, by doing simple ssh command with port
forwarding, and editing afterwards.

> > 3) The other workflow (create a local server for others) is the
> > "simplest" approach at the moment. But that is a problem for many use
> > cases due to dynamic ip addreses, firewalls, opening ports and so on. It
> > is fine for a class room or company, but not for working from  home.

All solutions for that already exists, see above.

> On this topic, I'm considering supporting sending the traffic over
> IRC. Seems that it solves all those problem, what do you guys think?

I think I feel like "abused" when I hear that.

> The process will be that one user create a channel with a random
> name, say on freenode.net, then they share the channel name
> with other user (maybe via IRC as well!). Others can then join the
> channel, and it behaves basically like TCP. To avoid spamming
> the same authentication protocol for TCP (to be implemented) can
> also work on IRC. The messages from user without authentication
> are simply discarded.

Please no.

:-)


Jean