Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Feature: Pre-release notifications #5108

Merged
merged 2 commits into from Feb 10, 2021
Merged

New Feature: Pre-release notifications #5108

merged 2 commits into from Feb 10, 2021

Conversation

ghost
Copy link

@ghost ghost commented Jan 23, 2021

Fixes #4532

Adds the ability for pre-release notifications to be sent by the admin key holder.
Users have the option in Settings to subscribe for pre-release notifications. (Default=off).


Screenshots

Generating a pre-release notification:

image

User setting for subscribing to pre-release notifications:

image

Notification of a pre-release:

image

Notification link is shown in the footer bar (if subscribed) :

image


Testing matrix for alert messages:

The alert can be either a regular release notification, a pre-release notification, or simply an general-purpose message. This is a list of tests performed:

  • Verify that a general text alert message can be sent by old and new clients.
  • Verify that a general text alert message can be received by old and new clients.
  • Verify that a general text alert message can be removed by old and new clients.
  • Verify that a software release message can be sent by old and new clients.
  • Verify that a software release message can be received by old and new clients.
  • Verify that a software release message can be removed by old and new clients.
  • Verify that a software PRE-release message can be sent by new clients.
  • Verify that a software PRE-release message can be received by new clients.
  • Verify that a software PRE-release message can be removed by new clients.
  • Verify that a software PRE-release message does not affect old clients (it is not seen).
  • Verify that a software PRE-release message removal does not affect old clients.
  • Verify that a software PRE-release message followed by a software release message for the same version is handled correctly.
  • Verify that the PRE-release message only pops up on clients that have opted-in via the User Preferences setting.
  • Verify that the footer PRE-release notification link only shows up on clients that have opted-in via the User Preferences setting.
  • Verify that if user responds with "Ignore this version" option the software release message is not shown again upon startup.
  • Verify that if user responds with "Ignore this version" option the software pre-release message is not shown again upon startup.

@ripcurlx ripcurlx added this to the v1.6.0 milestone Jan 24, 2021
@ghost ghost mentioned this pull request Jan 24, 2021
Copy link
Contributor

@chimp1984 chimp1984 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK

I assume the alert will fail if the version of the alert sender and the receiver is not the same as a new field got added and the signature check will fail as the hash of the payload is different.
If that is the case (I have not tested it) I think it is also not a big problem, we just need to be aware and Alert sender should use only the old version until most ppl have updated.
Alternatively we could pack the new data into the extraDataMap, but I think its not worth it for that case. Old users who have not updated for longer time will miss Alerts once the alert sender uses the new version.

@ghost
Copy link
Author

ghost commented Jan 31, 2021

@chimp1984 That was one of the tests, and it does work. I send a full-release alert New version available, 1.9.9 from 1.5.5 to older versions (e.g. 1.5.4, etc); they handle it correctly, displaying the download screen.

Seems it is the textual alert message that is signed, not the proto object. So extending the proto object is fine.

private void signAndAddSignatureToAlertMessage(Alert alert) {
String alertMessageAsHex = Utils.HEX.encode(alert.getMessage().getBytes(Charsets.UTF_8));
String signatureAsBase64 = alertSigningKey.signMessage(alertMessageAsHex);
alert.setSigAndPubKey(signatureAsBase64, keyRing.getSignatureKeyPair().getPublic());
}

@sqrrm sqrrm merged commit cedf108 into bisq-network:master Feb 10, 2021
@ghost ghost mentioned this pull request Feb 28, 2021
@ghost ghost deleted the pre_release_notifications branch May 29, 2022 22:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add option to specify which type of release to upgrade to (i.e. release/pre-release)
3 participants