Moving the follow-up here, as Thorsten suggested.
So, I'm arguing that we can side-step the need for "discovery" in the
P2P sense. Or even more fundamentally: P2P has several meanings. There
is "peer-to-peer networking", where nodes build an ad-hoc network in
which they need such peer discovery; and there is "peer to peer" on top
of an existing network in which, as the opposite of "through a central
server". I believe our interest should be in the second kind, as I'll
elaborate below.
On 04/05/2024 13:05, Thorsten Behrens wrote:
How to connect two or more individuals? It requires routing
I would opt for a simple protocol which does not take on problems
more complex than it has to, at least for a preliminary
implementation. Specifically - the Internet routes for us.
Connecting people for peer2peer communication is conventionally called
discovery.
There's ample writeups on the topic, here's two pointers:
* quite an accessible summary: https://jsantell.com/p2p-peer-discovery/
* scientific survey paper: https://www.inets.rwth-aachen.de/wp-content/uploads/2022/07/service_discovery_survey.pdf
Anyway - a server would not necessarily be required. That is, P2P
connection will happen when two users want to connect; but in our
case, they have already "connected" in some other way to agree on
making the P2P connection. So I suggest, in light of my previous
point, that we assume that the two (or more) users have another,
independent means of communication over which they can send some
data for bootstrapping the LibreOffice P2P. And this could be made
easy, UI-wise, so that the user just needs to press a copy button,
and paste some string so that the other user can see it. The other
user copies the string and pastes it into an appropriate area in
their own running LO instance. Then the connection is set up.
So in a word, piggy-backing on another, existing communication
channel?
Sort of, but not exactly. Think about a (non-Internet) phone
conversation. It's a "peer-to-peer" protocol, in the sense that there
isn't some "conversation server" which is active while the two
conversants converse: You dial the other person's number and connect to
them. But this is on top of an established network, which routes things
for you, without you having to "discover" anybody or anything. Also -
the phone number is apriori magic, which in ad-hoc peer-to-peer networks
you typically don't have. You need to know the person or organization
you're calling and obtain a numeric destination handle - not through the
use of your phone for the actual phone call. Maybe you've met and
exchanged numbers, maybe you got a card or saw an ad etc.
So, the "piggy-backing" would the interpersonal/social communication
which made the two (or more) people want to collaboratively edit a
document in the first place, plus the regular IP protocol and its
network structure.
What kind of data? Basically, I assume that would be a tuple of (IP,
port number, public key). I will admit that this doesn't cater to
the case of two firewalled users; that's a situation I'm not
experienced enough in handling, but I do know there are [many
approaches](https://en.wikipedia.org/wiki/NAT_traversal) (Wikipedia)
to handling it. Some may require a third-party "switching server",
some may not. But such a server can probably be very minimal and
hopefully not even aware of what protocol it's being used to allow
connections for.
Or taking the idea one step further: re-using the other, existing
comms channel, also for all of the collaboration traffic!
Well, I'm not sure it would be beneficial to create a strong tie-in
between our comm protocol and a specific choice of how the two users
communicate otherwise. But - that is a possibility. It may make things
easier technically I suppose - especially when it comes to more-than-two
collaborators.
Heiko wrote:
What could be achievable on TDF infrastructure?
Given what I've said above - let's try to make this completely
independent of TDF infrastructure. Either with no switching-server
at all or with something minimal that hopefully might not even need
TDF continuously maintaining a server. Note that maintenance by us
also has privacy implications, much more so than third-party-less
P2P.
Yup. At any rate, requiring any kind of centralized server
infrastructure has inevitable scalability challenges. It would still
be useful if TDF could help with bootstrapping whatever server
infrastructure will be needed, though.
Agreed; let's just think of such a bootstrapping as something to avoid
if possible, even at the cost of some tradeoffs. This relates
specifically to my two points of motivation for this feature (which I'll
quote for those who follow this list but not forum): This
"1. Undermines the paradigm Microsoft, Google and others are pushing,
of your work as a user going through them, visible and data-mine-able to
them, requiring connectivity to their servers…
2. Offers potential for more easily switching between simple
on-your-computer document and collaboratively-edited documented: Instead
of uploading, inviting, controlling access, etc - it would be just
clicking a “connect and edit with” button, entering an address, and when
that session is over - not needing to do anything but click a button or
close LibreOffice, and none is the wiser."
Heiko wrote:
Isn’t it better to share UNO commands and parameters?
Mmm... maybe... but - what about showing the other party's cursor
and mouse movements? You can't do that with UNO commands.
Starting off from Collabora Online - which is a production-ready
implementation of LibreOffice collaboration, that uses both low-level
key & mouse events, as well as UNO commands - I guess the answer is
'both'? ;)
But is that part of the code of COOL under an appropriate license?
Heiko wrote:
How do we solve the situation when one participant enters text and
another deletes the same paragraph?
It doesn't have to be a great solution, as long as it is
consistent. i.e. if users know that two people on a laggy connection
editing the same sentence is likely to get them making changes in
wrong positions etc., they will naturally limit the extent to which
they do this - like we know from Etherpad. Consistency of behavior
and "principle of least astonishment" would be more important than
perfect coordination/synchronization of inputs.
With a dedicated server, you don't even have that problem. All input
will get serialized through this instance, so there's a strict
temporal ordering for all edits. Whatever package reaches the server
first, will 'win' in an edit war. A fully distributed solution (which
is way harder to implement!) has no such strict global ordering per
se, but there's algorithms such as CRDTs[2], which guarantee eventual
consistency in all peers. But you're right, the Etherpad experience
shows that under bad network connectivity, user experience will start
to suffer. For example, all CRDTs I've looked at would always have a
'delete' operation win over other edits, on the same span of text.
And I would say this is good enough. If our protocol was for an online
competitive game, then minimizing this would be a major priority. For
us, it's barely a minor priority, as the practice of editing literally
the same stretch of text at the exact same time is obviously something
to be avoided. Either one person edits and others look and comment, or
multiple people edit different places in the document.
Heiko wrote:
Encryption and data integrity is key.
Perhaps TLS if it's a TCP-based protocol, and DTLS if it's UDP?
Using the exchanged public keys I mentioned before?
Evidently. Or further re-use of existing p2p/chat solutions.
Of course, integrity is somewhat relative here - if you invite the
world to co-edit your document. ;)
Well, we could have two modes:
1. Whoever has the key/access-tuple can join the editing process.
2. Whoever has the key/access-tuple can ask to join the editing process,
and one (or some, or all) of the participants need to approve.
That would be a bit like in Zoom, where some sessions have a "waiting
room" and some are joined automatically using the invite session ID.
Eyal
