search

vacp2p / research

Thinking in code
MIT License
62 stars 4 forks source link

Mailserver V2 #38

Closed decanus closed 3 years ago

decanus commented 4 years ago

Problem

Mailservers currently have several issues, firstly, it has a high reliability assumption. It needs to be online all the time in order to receive packets for others. Secondly, it currently sends messages to its peers in an asynchronous manner, making it a stateful construct on the request basis.

Goals

The goals we have for our next version of Mailservers should enable them to run well on desktops meaning that any desktop client can be a Mailserver. To do this we may need to figure out a solution for the high reliability assumption, although the desktop will be more reliable than a mobile phone it still won't be highly available like a dedicated server. This means we would need to have some form of replication over various Mailservers making them more of a reliable store for conversations. Users should be able to use their desktop as a more reliable message store for their conversations. This would mean that peers participating in the conversation should both be able to connect to the mailserver, and that the mailservers data should be replicated over various nodes for reliability.

Request / Response

One of the changes we want in the next iteration is to make querying from the mailserver easier. Right now a client sends a query to the mailserver and asychronously receives an answer at some point in the future. The UX of this isn't great and should be updated. This problem however also has to do with the way whisper works, and that messages of a specific size will be ignored, hence they are not bundled. More on this can be found in the issue vacp2p/specs#122

Replication

We need to think if and how a mailserver should replicate itself. I personally think that it may be ideal for a mailserver to replicate its contents or parts of its contents over x neighbours. For the start we can use a very minimal tit-for-tat model, if a user lets me replicate to it, I give it an allocation too, if it then no longer holds the data that I may want in the future, I punish it for doing so by lowering its allocation.

Thoughts on privacy and security

One thing we need to consider is how these v2 changes will affect the security and privacy of mailservers, what kind of metadata is leaked and how can we avoid as much leakage as possible.

Notes

oskarth commented 4 years ago

bit of a hacky construct. We want to bring on several changes that make them easier to use and more reliable. This means they will function better for desktops as well as being easier to synchronize from the phone.

Can we be more specific about the problems that exist with them? Right now this doesn't seem very objective ("hacky" "several changes" "reliable (in what sense?) "better for desktop" (in what sense?) "easier to sync" (in what sense?)

For inspiration of non-exhaustive list of currently defined objective problems, we have https://specs.vac.dev/specs/waku/mailserver.html#security-considerations

decanus commented 4 years ago

@oskarth addressed some of your points.

cammellos commented 4 years ago

I think also we should tackle first the hardest problem (which is currently solved by mailservers):

1) A is a light mobile client 2) B is a light mobile client 3) A goes online, B is offline, 4) A sends a private message to B, A goes offline 5) B goes online, B receives a message

Desktops don't currently solve that problem, unless you are asking them to store any message and act as full nodes, which is unlikely to work as the network scales (there's also a problem of discovery, but that's easier to solve).

On top of that gaps are not easily detectable, as there's no way to check consistency.

This is similar to the problem of syncing the ethereum blockchain, with a major disadvantage that there's no way to check that the history is consistent.

I think we should solve this use case first, because taking any direction without having explicitly solved this problem might just turn out to be a random walk.

It might very well be that mailservers as they are are just fine technology-wise (they solve our use case), and we need an incentivisation layer on top of that, with spotty checks for consistency (I guess you heard this one before :) ), getting rid of the high availability requirements is non-trivial.