update zsync links

Author: iTrooz

source/packaging-guide/optional/updates.rst

@@ -20,7 +20,7 @@ Making AppImages updateable via external tools
 
 To make an AppImage updateable, you need to embed information that describes where to check for updates and how into the AppImage. Unlike other Linux distribution methods, the information where to look for updates is not contained in separate repository description files such as :code:`sources.list` that need to be managed by the user, but is directly embedded inside the AppImage by the author of the respective AppImage. This has the advantage that the update information always travels alongside the application, so that the end user does not have to do anything special in order to be able to check for updates.
 
-Currently, there is only one backend available to update AppImages : `ZSync2 <https://travis-ci.org/TheAssassin/zsync2/>`__. The tool you use to package the AppImage will also generate a .zsync file if you gave it enough data to do so
+Currently, there is only one backend available to update AppImages : `ZSync2 <https://github.com/AppImage/zsync2>`__. The tool you use to package the AppImage will also generate a .zsync file if you gave it enough data to do so
 
 .. warning:: The .zsync file contains the filename of the AppImage. This mean that you **should not**, as a packager, rename the .AppImage file after it's creation. Else the update will fail because zsync will look for the original filename of the AppImage you host. If you want to rename the AppImage, you should use the options of the tool you use to create the AppImage.
 
@@ -210,7 +210,7 @@ See this easy example for an update check:
 
 This is faster and less verbose than an exception based workflow, however, you can't see what caused the update check to fail.
 
-This can be found out using the built in status message system. Every :code:`Updater` instance contains a message queue. All methods within the updater and the systems it uses (like e.g., `ZSync2 <https://travis-ci.org/TheAssassin/zsync2/>`__, which is one of the backends for the binary delta updates) add messages to this queue, which means that all kinds of status messages ever generated by any of the libraries will end up there.
+This can be found out using the built in status message system. Every :code:`Updater` instance contains a message queue. All methods within the updater and the systems it uses (like e.g., `ZSync2 <https://github.com/AppImage/zsync2>`__, which is one of the backends for the binary delta updates) add messages to this queue, which means that all kinds of status messages ever generated by any of the libraries will end up there.
 
 .. note::