Who will maintain the mailserver?

I have read the description of Waku mailservers(Introduction | Vac RFC). I’m really curious who will maintain these high-cost servers for nothing? Because I do not see any incentive mechanisms for them.
Sorry for being naive.
Thanks.

2 Likes

Blockchain Technology > Web 3.0

explains Ethereum Web 3.0 | Evolution of Internet VIDEO

Thanks for sharing. But you do not answer the question.

1 Like

I don’t believe that you missed anything… to my knowledge, no incentive mechanism currently exists for users. The Status Network is currently maintaining these nodes in AWS as part of an operational budget while a path to decentralization is engineered. I believe that an early discussion on this topic suggested that the community would be incentivized by setting up their own mailservers and staking SNT, and being rewarded in SNT for message delivery on those mailservers. The most recent discussions I’ve seen regarding this involve adding mailservers to the upcoming desktop version of Status, and possibly the mobile version as well through adaptive nodes some time after Nimbus integration. This is not to say that previous plans will be scrapped, only that it’s an ongoing discussion with many facets. The most recent discussion I’ve seen on this topic can be found below.

@VayneTian this thread might also be interesting. You can set up your own ‘mailserver’. Indeed, no incentivization model at this point, but definitely being worked on

2 Likes

Thank you for your reply. In my opinion, if Status Team maintain those mailservers, there are some chances for them to do something bad, such as backdoors, or delete some of the data so that users will never receive them. Desktop version seems cool, in this way, every user can be one of the mailservers and Status can be truly decentralized.

1 Like

Thanks for your reply!

Glad to help! Depending on how the protocol used to negotiate with the clients is engineered, it may not even be possible for data being sent through mailservers to be manipulated/read and then still successfully connect to the client applications. I haven’t read up in detail on how the handshake is done, but the client code is open source… so we can at least trust that clients are connecting to mailservers as intended. Additionally, the protocol would need to be hardened against bad behavior from mailservers that are configured differently/incorrectly for integrity. Otherwise, anyone could set up their own mailserver right now and configure it to do whatever they want to any message being sent through it.

Yes, the scenario you mentioned is very important. Something must be done to guarantee the integrity of mailservers, though I have no idea how to do this. I will do some research on this. Thanks again!