Status and Ethereum network future

Messenger
1

We’ve had some amazing work in the recent months on our P2P layer, made our messaging much more reliable and less traffic-hungry, optimized it for mobile devices usage patterns and made messaging latency lower and more predictable.

At the same time, we slowly started pivoting from a promise of being a truly decentralized system (by “truly decentralized” I mean the level of decentralization in Ethereum network; let’s assume it’s decentralized enough for our case) to the system that relies on a fleet of servers owned by Status, with a hope of developing incentivization strategy that will allow scale the cluster by other users running status server.

In other words, there are clearly some notable and real mismatches between Ethereum P2P implementation and our needs/limitations as a mobile (I hope some more specific details will be described in this thread). We have two options:

  1. Continue to focus on Ethereum Network as our P2P layer and be an Ethereum citizen. This implies heavy investment into Ethereum ecosystem, developing Whisper, Swarm or whatever it’ll be in the future the bases of Ethereum.
  2. Build our own solution, run and rely on own cluster, incompatible with Ethereum and come up with the solution for incentivizing people to run our software.

The first option, in my opinion, puts notable limitations on what we can do and somehow on the speed of development too. We constrained by the Ethereum network properties and design decisions that might be suboptimal for our case. It’s our responsibility to choose the right trade-offs and find the best solutions under this constraints and do our best to contribute into ethereum official implementation and/or specifications to continue to be a part of the Ethereum network and meet our needs.

The second option gives us much more flexibility, control and guarantees over performance and reliability of an app. We’re free to implement our own protocols and solutions and optimize them for mobile networks as much as we want. Considering the unclear future of Whisper protocol (some people suggested its development can be discontinued at some point), we’ll be unaffected by whatever is happening on that side of Ethereum development. However, this option is clearly a pivot to our initial strategy of being a part of the Ethereum ecosystem.

Let’s use this thread to synchronize on what’s future we want for Status because this pivot is already happening and I don’t sync everyone on the same page as for the Status and Ethereum future. I’ll put my personal take on it in the first comment.

1 Like
2

While I definitely can relate to all the design considerations in favour of the second option, I still think that “being a part of Ethereum network” is a higher priority than technical challenges. If we prioritize technical challenges over it, it’s easier to make a centralized solution. Way easier.

But, as I believe, we’re not going to make “yet another messenger”, we’re trying to become a part of the larger yet-to-be-explored world of Ethereum. And – this is important to understand – not only become a part of it but actually enable the whole new class of communication, apps and interactions in this world. We strive to bring decentralized apps to the billions of non-technical users and show that effective and reliable communication is more than possible in the fully decentralized computer, open a window to the decentralized world of Ethereum, so to speak.

I don’t see how we can enrich Ethereum ecosystem without being a part of it.

4 Likes
3

Thanks for writing up your thoughts Ivan!

I don’t think the options are mutually exclusive, but if I had to choose, we should always be leaning towards contributing to the community. There’s a certain hacker and contributing to the community mentality that binds these seemingly opposed idea’s.

For example “Whisper” is what we (or anyone) makes it, it is not a static technology to be used by engineers - it is an influx protocol that is shaped by the people producing the collective good. getting more people involved is why the Ethereum Improvement Proposal methodology exists.

Also can you please highlight the tradeoffs we’re making that is making what we’re doing more centralized? Afaik we’re still using Whisper more or less as it is off the shelf?

3 Likes
4

In the past week or so, there have been a few discussions around this or related topics on Slack so I’d like to thank you for putting it here!

I believe that being a part of the Ethereum network is necessary for us to be successful. However, Ethereum has never been built with mobile devices in mind. When you think about that it’s not really surprising. Looking for peers using DHT, exchanging metadata, synching the chain, broadcasting Whisper messages, all these operations are pretty heavy.

The solution that started crystalizing in my mind is a hybrid approach where our cluster is a part of the Ethereum network but nodes in the cluster support more services and protocols which are crucial for a great mobile experience (status nodes). The example is a more suitable discovery protocol.

The next step is to evolve our cluster to become a community cluster. We need to provide tools and clear instructions for anyone who would like to run it and it can’t be more complicated than running a geth client.

Finally, we must build incentivization and curation layers because (1) why someone would like to run a status node at all and (2) some of these nodes could be unreliable or act weirdly and they should be filtered out or there might be some attack vectors that the cluster should be able to push back.

At some point, our custom protocols and services should mature and they might get incorporated to other clients and something like status node won’t be necessary at all.

1 Like
5

I’m not sure this is true. Light clients have been part of the discussion since day one and light clients and mobile clients are a big key to the web3 vision. It’s understood that most people cannot and will not run the entire chain on their device so they either need to run another full node themselves or offload that to someone else for a fee.

One thing I’ve never gotten a good answer on is if channels in Status are “Status channels” or global Whisper channels.

When you are in the #ethereum channel, you are talking about Ethereum with everyone else in the world. Any dapp that’s connected to the whisper network can access and contribute to this conversation. You could use other tools to access the same conversation, not just Status.

I personally don’t think Status is worth making unless the channels inside it are Whisper channels. Otherwise you’re making “just another messenger” with its own walled network.

If the channels in Status are “Whisper channels” then number 1 is the way to go. If they’re “Status channels” then number 2 starts to make more sense but then Status loses some of its magic, in my opinion.

2 Likes
6

They have been a part of the discussion, yes, but their priority is rather low (e.g. Swarm has just started working on it recently). Also, it’s not only about LES but other essential protocols like Discovery as well. My point was that all these technologies and protocols were not designed with mobile as the primary platform and if we want to provide great mobile experience, we must use different ones (of course not for everything).

When you are in the #ethereum channel, you are talking about Ethereum with everyone else in the world. Any dapp that’s connected to the whisper network can access and contribute to this conversation. You could use other tools to access the same conversation, not just Status.

I think that it’s exactly what Status should be aiming for. There is still a lot of work ahead:

  • prepare a spec for creating topics and sym keys from channel names,
  • prepare a payload spec,
  • a mobile client being a part of such a network would consume a huge amount of data so again some master node with custom protocols seems required; hence that hybrid approach I mentioned.

Unfortunately, I don’t know if there is any active work around that at the moment.

1 Like
7

Ethereum has never been built with mobile devices in mind

Ethereum is a protocol under heavy development, and we are part of the community that can affect its direction and success, on mobile platforms and elsewhere.

By developing the status application, and by working on the mobile experience, we gain first-hand experience of the pain points and the problems that need solving, and become the experts that cover this facet of making Ethereum work across a broad range of devices and use cases, both at the lowest protocol layer (promoting development of light clients and service models for running / incentivising full nodes) and application level (such as a chat or key exchange protocol on top of the whisper base spec)

It’s important to keep in mind that decentralization needs to happen at multiple levels, not just in the nodes/code running the system but also in the community and the organizations supporting their development - by being part of the community, we both benefit and increase its resilience to shocks.

We are already working on several projects in this direction: Nimbus, ULC/LES service model, PSS/Light client support for Swarm, Status Desktop etc making sure not only that we get the features we need, but also that they get deployed in a way that can sustain itself, long after Status is gone.

As far as chat protocols go, and chat channels - we’ve also had several discussions about the importance to specify the application level protocol unambiguously and in detail (wire-level, through a schema for example, that is not tied to any particular programming language), such that it can be reimplemented by others. Keep in mind that whisper was not made for chat, to begin with, we’re just bending it that way / layering on top of it.

At this early stage in chat development, there are several ongoing development efforts to create such a protocol - we have one, Mainframe is working on another (over PSS), as is Swarm City (of the ones I know about) - eventually, once we have something that is of sufficient quality for public review, I imagine the way forwards might be to “standardise” it somehow, through an EIP for example.

3 Likes
8

Someone correct me if I’m wrong but it’s my understanding that Status is running a geth light client with --shh flag to enable whisper, yeah?

That means that every Status user is an Ethereum node, and they’re all running whisper. Since whisper has been pretty alpha for a while, and especially since it’s behind a flag, not many users are using it. Few users is bad for p2p and is surely a contributing factor for deliverability problems. But the more users Status has, the more whisper nodes there are, and that could actually be good for deliverability, no?

Are there other reasons for Status to have a cluster besides helping deliverability problems and for mailservers (which also solves a deliverability problem)? Bootnodes also?

Wouldn’t an “ideal” p2p solution include users being mailboxes for each other?

1 Like
9

I am sorry, I missed your message in this thread :confused:

Someone correct me if I’m wrong but it’s my understanding that Status is running a geth light client with --shh flag to enable whisper, yeah?

Currently, the app does not run LES so it’s an Ethereum (geth) client with --shh flag and sync disabled. This will be changed soon and LES and/or ULC support will be provided.

But the more users Status has, the more whisper nodes there are, and that could actually be good for deliverability, no?

The app uses “light” Whisper mode. It means it does not relay messages to its peers. It’s done so in order to reduce the amount of sent data.

The other thing is that the app sessions (by session I mean time when the app runs in the background) are usually very short. Until the mobile client is advertised within the network, the session might be already closed or will close in a few minutes. This introduces congestion within the network and discovery protocol table as many of found peers are already offline.

Are there other reasons for Status to have a cluster besides helping deliverability problems and for mailservers (which also solves a deliverability problem)? Bootnodes also?

No other reasons really. We have two main issues that we try to solve: (1) finding reliable peers supporting Whisper with proper (from our point of view) configuration, (2) finding reliable peers with high uptime almost instantly. That’s why we keep our cluster with Whisper and bootnode clients.

Wouldn’t an “ideal” p2p solution include users being mailboxes for each other?

In the ideal world yes. However, if we want to keep the data transfer and CPU usage to a minimum, we need to use “light” mode for almost every protocol we run within the app today.

A solution for this might be a concept of master nodes. These nodes would be incentivized for providing additional services. For example, one can run a master node with MailServer capability and get some SNT for doing that. Another idea is Desktop clients serving as master nodes that would relay messages and also work as mailboxes.

2 Likes
10

This seems like a perfect place where users can contribute data in exchange for payment. Perhaps users could fine tune how much data they are willing to contribute and how much returns that will earn them. That even turns into an arbitrage opportunity for users whose data plans are cheaper than how much they’d be getting paid by the whisper network. Don’t know if that’s a good or bad thing, but it seems interesting nonetheless.