Notifications in the Master Protocol

[zathras-crypto]

During some discussion today I wanted to press for an alerting capability as we get closer to having a UI released and thus likely an increase in the end user base.

That discussion fleshed out some bits on using the Bitcoin Alert system, and one of the points raised by @CraigSellars was that it is feasible that since the alert key we use will not be recognized by regular Bitcoin Core clients it's very possible that our alerts won't get relayed.

As such I proposed that we embed a new transaction type within the Master Protocol spec, a 'notify' message which will be acknowledged only if sent by trusted addresses embedded within the source.

I'm on a plane for most of tomorrow and will flush this out into a more thorough proposal, but @Michael noted would be good to get the conversation started ASAP.

I'm initially thinking a new transaction type, with the following fields: expirytime (int) - only display the notification until this time ignoreversion (int) - only display the notification if the client version is <= this field (non reference clients can use this how they see fit) notification (null term string, max 255 bytes) - the notification

I can then build in something into the UI that is seperate to the alert system for bitcoin to display these notifications in the walletframe, and we'll need to add an RPC call for integrators to check such periodically such as getnotifications_MP.

Benefits are that we do not need to break into the p2p comms channels to relay alerts (bitcoin alerts are not a standard block or tx message but another tcp packet), do not have to worry about relaying, and we leave the original alert system in place for the bitcoin side of Master Core (which I am a big proponent of), and have a new notification system entirely under our own control. Also means we can have not one shared alert key but several trusted alert addresses which can be added/removed as developers leave/join the project without having to reissue a shared key.

Just initial thoughts, will flesh out some more over coming days but please comment/feedback.

Thanks Z

[ghost]

'ack' on this, this is going to really impact (in a good way) our ability to reach out to users with a low communication overhead

[dacoinminster]

Cool idea. I'll put together a pull request for this today. I needed something to do while I'm offline this afternoon, and this is perfect :)

On Tue, Sep 30, 2014 at 9:30 AM, Faiz Khan notifications@github.com wrote:

'ack' on this, this is going to really impact (in a good way) our ability to reach out to users with a low communication overhead

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/spec/issues/265#issuecomment-57341715.

[dexX7]

Yay, I like it and I'm +1 on this for a long time.

[dexX7]

It would be nice to avoid the creation of a very specific "notify mastercore client users that xxx"-transaction, but rather get a general purpose message broadcast transaction which does not enforce a scope or format of the message.

A Mastercore client could watch for messages that have specific properties (e.g. signed by 3MaSterCoreMultiSig) or or some specific format and use those as trigger for update notifications.

Related: #111 Add version numbers into the blockchain + (sort of) #115 Clarification about "Publish Data" - in #111 are a lot of cross references which all tackle this topic partly.

[dacoinminster]

Please take a look at pull request #267 for my shot at implementing this.

I have the privkey for the vanity address mentioned here, which I will deliver through other channels.