Patchwork: Add electron updater so Patchwork automatically can get the latest version

[mrchrisadams]

Hi there,

I get that Patchwork is supposed to be decentralised, and yet, I'd still find it useful if Patchwork, when there _was_ an internet connection, was able to update itself without the user having to manually download the latest version each time.

If you're not using Linux, I'm not aware of a easy to do this.

However, I think you can add auto-update functionality like provided by Sparkle, by using electron-updater.

Would something like this be something that would be accepted to the project if I worked on it?

If so, I'm happy to have a go at it.

[mrchrisadams]

Oh neat, so it look like you can do this with Homebrew too - this isn't a bad stopgap, assuming the homebrew version is recent:

brew search patchwork
==> Searching local taps...
==> Searching taps on GitHub...
homebrew/cask/patchwork

And it looks recent:

brew cask info patchwork
patchwork: 3.9.0
https://github.com/ssbc/patchwork
Not installed
From: https://github.com/caskroom/homebrew-cask/blob/master/Casks/patchwork.rb

[mrchrisadams]

Ah, it looks like this might be a better bet to look in to, right?

https://github.com/ssbc/patchwork-builder

[mrchrisadams]

Hello @mmckegg, I'm standing next to you at jsconf 👋

_(context: I added this as joke when we were chatting at the conference, looking at github together as a reminder to talk about this. Without that context it can totally look a bit weird…)_

[daviewales]

So... Here's a possibly related idea.

Suppose Patchwork had its own SSB feed. Then, suppose the latest version of patchwork was posted on said SSB feed.

Now, suppose functionally was added to the Patchwork client to automatically update itself if it's subscribed to the Patchwork SSB feed and it receives an updated file.

Now, anyone who follows the Patchwork feed will get Patchwork updates, even if they are off-grid!

[cryptix]

@daviewales I like your idea! from the docmentation it seems like this might be easy-ish to implement:

Different providers supported out of the box (GitHub Releases, Amazon S3, DigitalOcean Spaces, Bintray and generic HTTP(s) server).

So we _just_ need to find the provider documentation and make a handler for that.

OTOH: We might want to support multiple providers if that is possible? My fear is that if there is yet another case of a malformed message, ssb won't be able to update. A fallback to GitHub Releases (while we are still here anyway) would be preferable, at least.

[daviewales]

If we're using SSB as the transport, then Patchwork could run a local webserver on localhost, and when you receive the latest file from the Patchwork update feed, it can autoupdate from localhost.

Then we could use the generic provider.
(Documentation here)

There is one problem I can see with this. People may not want to store every Patchwork release ever on their computer. Does SSB support optional files? (e.g. like how git-lfs doesn't fill the git tree with different versions of large binary files, but instead just commits a list of references to the files. SSB could add the hash of the updated file to the append only feed, but distribute the file itself optionally alongside. So people could choose to keep only the last few versions of Patchwork on their computer.)

[mmckegg]

@daviewales

What you are describing is the case with blobs. They only get synced when you specifically request them.

[christianbundy]

We're using electron-builder in master now, so I'd merge a PR for this. :+1:

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?