Self-Updating Status

This had been sitting on my hdd gathering dust so thought would publish it:


We have binaries (Desktop and APK’s) that have no distribution channels and therefore have no managed upgrades. Status should be able to independently inform the user that new binaries are available and give the user a means to voluntarily upgrade.


  • Friends don’t let friends run untrusted binaries.
  • Multiple parties sign builds, providing some assurance that
    • the binaries and tool chain were not tampered with
    • that the same source code was used.
  • Checking for updates should be ‘passive’ in terms of requests.
  • Updating should be voluntary.
  • A user should have ready access to a tool than can (build and) check binaries against the respective hash of binary


Status should check an on-chain contract that anybody can publish to (by locking, maybe even staking SNT, although slashing conditions sounds hard), to be read by anyone.

The contract contains a data structure that contains something like:
(this is pseudo code, I haven’t written Solidity in years, don’t hurt me!)

struct Signature {
    bytes32 r;
    bytes32 s;
    uint8 v;
    bytes32 hash;
    address signer;
    uint256 stake;
    bool upvote; // (optional?) approve or disprove a build

struct Build {
        uint16 major;
        uint16 minor;
        uint16 patch;
        bytes32 ext;
        // Hashes & Urls
        string gitremote;
        bytes20 sha1git; // git commit hash, TODO: pointer into mango?
        bytes32 sha256bin; // binary hash
        string[] urls; // ipfs/swarm hash and/or http urls
        Signature[] signatures; // Build must have at least 1 signature to exist.

struct Platform {
	Build[] builds; // prepend only? linked list or mapping more suitable?
// oh god I have no idea what I'm doing
mapping(string => Platform); // Android, iOS, macOS, Win, Nix, etc.
mapping(mapping(bytes20 => string) => Build) CommitPlatform; // Lookup Build from Git Commit and Platform
mapping(bytes32 => Build) Binary; // Lookup Build  from Binary hash

I imagine the client will be initially distributed with a list of signatories, from there it could populate it’s list from mutual contacts (might not be practical)

The idea is that a client would:

  1. Query the contract for the current platform.
  2. Enumerate & Display a list of published builds that is ordered & weighted by:
  • semantic version number.
  • Most signatures from client’s trusted list.
  • Most signatures in relation to all enumerated Builds
  • Ignore all builds that have less than N signatures.
  • M amount SNT ‘staked’ (again how to slash?)
  • favouring user’s preferred choice of binaries ipfs/swarm/http
  • filter on git remote.
  1. Notify user when new candidate is available.
  2. Allow the user to view the list and optionally choose which version to install or ignore, while offering the top-most entry as most likely candidate.

A tool that checks binaries, should be able to se the same contract to look up a Build by Platform, by Git Commit or by Binary Hash, and offer to publish a signature. It should be used in the e2e build process.

Perhaps signatures can offer an ‘upvote’ or ‘downvote’ to distinguish between expressly malicious builds and apathy toward a build.

@iurimatias @arnetheduck @ricardo3 @rramos @igor @pedro @adam @cammellos @oskarth @petty


I think this is an important move towards our principles. I totally agree is a problem, and agree with the solution you suggest.

Also I think that…

  1. Self-Updates I think are good thing, however users should be able to have control over the automatic installation, a downgrade option would be awesome for a bad release scenario.

  2. We can start by replacing this Status - Grab The Latest Builds! by get.statusnet.eth/nightly, and providing a list of builds which are signed by a trustful account/person/system. Maybe ropsten only? Not need high security, as users would not use keys containing value in mainnet, a clear message they should use it on ropsten only.

  3. Ideally we would think going towards in-chain democracy, but while we develop that, we can use a multisig between developers which are responsible to build that code - this later might become a selected multisig from developers to request vote into democracy (with a lower quorum?).

    • For get.statusnet.eth/releases a high quorum would be required to get listed because the changelog might not be accepted by the community.
    • For get.statusnet.eth/nightly could be a different concept, because voters don’t need to care about what changed, but donwload and check if the reproducible build meets the source-code,
  4. This would be a reference only value, node forks would be able to co-exist as long they don’t cause troubles (like parity, geth, harmony, etc), as they might get isolated from main status nodes, which would be rejecting to connect with them because they are wasting their processing/network with invalid messages.
    This is not about blockchain fork, because the underlying blockchain is ETH, where status network is over whisper, some smart contracts are being used in ETH, specially when funds are evolved, as we want benefit of ETH security for this type of transactions.

  5. The releases could also be informed without use of smart contract, by including this capability over status nodes, making they track and inform the latest build between each other, however this would be considerably more limited and less safe then light node reading from smart contract.

  6. This don’t removes the need of a web2 release portal for on-boarding, but everything should be available on decentralized network as “main source of information”, so whoever already is in, can trust the network for updates.

  7. The Curation Market proposed by Andy @cryptowanderer is an interesting tool to build a community reputation for 3rd dapps, however for status releases we might want to have a “one way only” to ensure that a build is consensus, this is important to clients make sure they would be capable to connect in main status network as is defined by the SNT holders community. However it could be used to list what is the best rated alternative client/fork or best rated version between releases.

Thanks for reading! :blush:


Thanks for your thoughts @ricardo3

Yes agreed, what I was proposing would enable exactly this.

I struggle with this idea, I think this would lead to censorship and tyranny of the majority, the approach I was suggesting would allow anyone to publish and anyone to choose what binaries they want to run, while having some sane defaults.

With new messaging protocol, I agree

Yes if it works it could definitely be useful here.

I totally agree that there should be some mechanism to auto-update Status app outside AppStore/GP. In general, I like this approach with consensus-based update.

As a first step towards it, we need to make reproducible builds, that we are slowly moving towards…


Reproducible builds is a focus that moves us closer to having solutions like this that other platforms simple can’t provide (or haven’t thought to because they don’t operate like us)

1 Like

Started thinking about treating git commit history and binary hashes as Schelling Points, started a side project to make this a generalized tool for pseudo-anonymously & trustlessly coordinating sourcecode and releases.