Re: Question collaborative editing.

[Ergus <spacibba@aol.com>]

On Tue, Sep 29, 2020 at 12:35:54PM -0500, Karl Fogel wrote:
>On 29 Sep 2020, Ergus wrote:
>>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.
>>
>>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... 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.
>>
>>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.
>
>It's okay if a central server is required, as long as it's free software.  In practice, there would be a few "well-known" central servers that people use (the way many people just use https://pad.riseup.net/ for Etherpad today).  One of those well-known servers can even be set as the default in the client code in Emacs.  If some people want to use a different server instance to collaborate, all they have to do is set that variable, or specify the server through some interactive prompt.
>
>This doesn't necessarily imply OT instead of CRDT or vice-versa.  Still, despite the "CRDTs are the future" message at https://josephg.com/blog/crdts-are-the-future/, I suspect that for Emacs's purposes OT might be the better solution: simpler to implement and maintain.  In any case, I hope development of this feature doesn't block on decentralization.  While decentralization would be nice, it's not required; people can set up their own servers when they really need to.
>
>Best regards,
>-Karl
>
Hi Karl:

In the library level we could (and maybe should) implement both (OT and
CRDT). This will only require a hint from the server side (or the
connection starter client) to inform the client's libraries "what to use
this time". Then practice will say what's better.

ATM we could start with a C library in order to provide a nice free
back-end editor agnostic. Because IMO the most interesting part of this
will be to open emacs to interact with other editors with a free
infrastructure emacs-centric.

IMO: it should/must be like Tandem but made in C and using free
libraries. Without python or JS dependencies and with a JSON (or
standard interface).