What Status Desktop is to me

Status Mobile
1

Problems that exist that desktop could solve (non-exhaustive)

  1. mobiles are resource limited
  2. many communicate via their desktop/laptop
  3. there aren’t enough nodes in the various networks being used
  4. node management is hard

My thoughts

As we’ve built out the Status mobile app, we’ve increasingly realized how resource restricted these devices are. Our reach continuously exceeds our grasp, and we have no base to maintain decentralization as we continue to host more infrastructure in response to user growth. This is exactly what we do not want, and it is not sustainable.

We have tried to tell people they can run their own node, not depend on us (which has always been true!), but the user has no real reason to get over the barrier of entry other than if they are super paranoid or really altruistic. Running a Status/Ethereum/IPFS/etc node(and other infrastructure) serves no purpose to the user, and is based in altruism or severe personal preference/requirements.

The Status Desktop client serves as a reason a user runs all of these things. If it optional to run all of these services in the background, and mange them via the application, then a user can easily transition from a leech in the network, to the backbone, depending on their available resources.

Furthermore, for hairy feature situations (push notification, mailserver privacy, persistance of any kind, social backup, etc), the desktop may provide a layer of acceptable compromise as a user will either run a desktop node themselves, or know someone who is running one that they trust.

If we look at the typical hardware of a desktop user, it is:

  • on the majority of the time
    • varies with latpop
  • connected to a constant power source
    • varies with laptop
  • typically connected to a stable, high bandwidth network
    • varies with laptop
  • typically low on resource consumption during normal use
  • running a OS that is amenable to OS software installation
  • isolated and trusted physically
    • varies greatly with server/desktop/laptop

A case for modularity

To move things even more forward, designing desktop appropriately allows us to run various services indenpendantly, and desktop be the management interface. For instance, one could delegate their Status node and mailserver to a rasberry pi like device, their Ethereum/IPFS node to a NanoPC T4, and their desktop client to a laptop.

The desktop client becomes a management/monitoring interface to their Web3 world, all the while allowing them to connect to their respective social groups, access the world of Web3, and supporting the underlying infrastructure that runs all of these networks while simultaneously providing value to the user. It gives options to the user to conduct themselves the way they want to. For those that done care, download a client, get started, flip a switch to run it in the background, stop caring.

Modularity also allows us to create client interfaces that serve various purposes a user may have:

  • slack/discord like communication platform
  • decentralized application browser
  • asset management
  • telegram-like public chat
  • twitter-like social broadcasting service
  • an ETH2 staking node interface
  • etc

Support the mobile app while it needs it

That is just an interface that links to backends properly, but the infrastructure HAS TO BE RUN by the community, and mobile phones can’t do it (at least yet, or in the forseeable future). As we grow, the supporting infrastructure MUST grow with us, and the balance of who runs it MUST rely on the community to do, even if they don’t realize their doing it. Our comms are always obfuscated and encrypted, so a user supporting the network does not give them extra information to hoard, in fact, it does exactly the opposite as we spread the load across a larger distribution of people.

If the underlying network infrastructure is large, we can then lean on them as the technolgoy grows, and it’s developme serves as the basis of functinalty as mobile functionality grows to be able to meet its demands. In other words, a robust desktop client ecosystem becomes the feature set mobile works to acheive, and if built correctly, ends up being a flip of a switch when the hardware / resource constraints dissappear. Think about what you do with your phone now, 99% of that function was delegated to specialized hardware at one point, until the technology caught up.

12 Likes
2

I was excited to see that the desktop version of Status was more recently prioritized for development again, especially in light of mobile hardware limitations and the current lack of decentralization. Additionally… personal nodes in the form of a StatusBOX, for example, could support users with no access to desktop-class hardware… and incentivizing such contributors with SNT (with SNT staking to prevent abuse) could help to defray the cost of such hardware. If the Status budget allows for this, such low-cost devices could even be donated to communities… or even be awarded as prizes for compelling contest entries.

Despite all of that, continuing to improve protocol efficiency (lowering the bandwidth/computational cost of running a node) may still be the best way to help improve decentralization. Mobile devices have built-in cellular network connections that can transmit continuously… plus mobile hardware and cellular bandwidth is continuing to become relatively more affordable, while their computational efficiency appears to be improving at a more rapid rate than desktop hardware. The new $399 iPhone SE chipset and many new 5G devices are prominent examples. I’d love the option to enable a Status node right from the mobile app.

3

Sure, but as far Status Desktop goes, the emphasis I am trying to encourage is not on the UI itself, ie not emulating slack vs telegram. Rather the fact that the UI is superficial, and I am looking to encourage a deeper thought, coming at it from first principles. The Status user doesn’t change, but the goal of managing a node, and the relationship between mobile and desktop becomes the emphasis. And in reality, whatever is changed on desktop, should equally apply to the mobile client.

It would be a mistake to split focus and treat Mobile and Desktop as separate products. Take for example the air-gapped signing feature we’ve discussed for desktop. Why can’t I have a mobile client and air-gap sign transactions from another mobile client? There’s no technical limitation, only the initial mental framework that boxes the thinking.

We’ve explored this idea a few times, the problem with commodity hardware is that there is a lot of overhead, the sanest choice is to do a white-label product with a vendor who already has the supply chain setup. https://dappnode.io comes to mind however they use NUC’s and entry price point is a little higher than we’d want. Ideally we were using Raspberry PI’s or something, Element14 offers raspberry pi customization services for bulk orders, but even then we’d need to ensure we have an upgrade-able network. There’s a lot of work as it’s essentially an entirely new product, we’d also have to do pre-orders to gauge actual market interest.

It’s much more effective to treat desktop resources as the backbone of the network while also providing a great user-interface. Doing this work first, would make it much easier to put together a box if someone was inclined.

Activating the radio like this drains the battery very quickly. That’s why we currently have semi-stale discovery. It’s also my concern with the push to only allow p2p notifications on Android, and not offer an off-by-default-and-warn-you-if-you-turn-it-on centralised notifications. I’m waiting to see a report that proves this won’t be an issue.

Yes so would I, which is why we are doing work on “Adaptive Nodes” that change their capability depending on the hardware resources available to it, it’s perfectly feasible to run a Status node from a mobile device if it is charging and on wifi, for example. Before we do that, I imagine we’ll integrate Nimbus into the app.

6 Likes
4

As far as testing goes the impact of the background service on battery is negligeable

I checked batterystats for when Notifications are ON and OFF and app on background, and values are almost the same (during 2h: 0.18% when PN OFF and 0.19% when PN are ON) .

We’ll see once it is released how it goes with more use cases

3 Likes