In this series of articles I will discuss WeiTch, an open source messaging protocol for Bitcoin SV.
Introduction
Twetch, and its recently launched competitor Weiblock, are Web services which allow users to publish content on the BSV blockchain (Bitcoin SV, also known as Bitcoin). In order to publish content, users need to create a Money Button account, which both serves as a Bitcoin wallet and as a user account. Once the account is created, users can login (using Money Button SSO) to the platform of their choice and swipe Money Button to post messages on the blockchain. Those messages broadcasted on the Bitcoin network (and included in blocks) are extracted by Twetch and Weiblock applications, processed and rendered on their fancy-looking websites, so that users can see what other users swipe, interact with the content and publish on the blockchain. Those applications are an alternative to microblogging platforms such as Twitter, and while Twitter keeps the published messages on record in their own datacentres, the published messages here are kept on record publicly on the decentralised Bitcoin blockchain. However, despite those messages being publicly available, Twetch and Weiblock do not use a standardised messaging format, which means messages posted on Weiblock are only visible on Weiblock and messages posted on Twetch are only visible on Twetch. At first, this seems understandable, as both platforms are businesses and their profits come directly from users. I believe their business model is not only compatible but would also benefit from using a standardised protocol and sharing the user base. In this first article I will explain why I consider a standardised messaging protocol to be important, how those applications and future applications can benefit from it and what would be the positive impact on user experience.
What are messages?
Before I begin, I first need to clarify the definition I will use for "messages" in the context of my articles.
A message is a set of information contained in a Bitcoin transaction, formatted in a specific way to carry the necessary information in order to perform certain actions such as: publish, interact and update data at application level.
A couple of examples...
- I wish to publish a link to a website on Twetch, the message would look like:
MB4070:CREATEPOST:"Guys, check this blog: http://blog.bsv.sh/"
2. I wish to edit my previous post:
MB4070:EDITPOST:fe32f029b77..[TX_ID]..d2d341147d5305:"Guys, check this blog: https://blog.bsv.sh/ (Edit: use HTTPS)"
3. I wish to like someone's post:
MB4070:LIKEPOST:fe32f029b77..[TX_ID]..d2d341147d5305
4. I wish to edit my Weiblock profile:
MB4070:EDITPROFILE:BIO:"I am a nice person."
5. I wish to hide a previous post:
MB4070:DELETEPOST:fe32f029b77..[TX_ID]..d2d341147d5305
6. I wish to mute a specific user (hide all his posts and interactions with me):
MB4070:MUTEUSER:MB2022
7. I wish to follow a specific user:
MB4070:FOLLOWUSER:MB3667
8. I wish to send a private message to a group of users:
MB4070:PMGROUP:ENC:MB271,MB773,MB4070:"QklFMQPBpGfFSQZxVFAOnXjHxoqC7rqE7iko+TwyVEJ0Vfinti5v9+bdCypdL7BJSMgLV4NyVdmWPEZ5q17cAh1sJyCmJqh6gtMAFTADqo30J+dPhQ=="
All of the above are messages as I would describe them. Those messages are embedded within Bitcoin transactions and broadcasted on the blockchain. Any blockchain explorer and any software that can pull raw transaction data from the blockchain can decode and read those messages. Software designed to understand those messages can trigger (or not) the associated action(s) described by those messages.
A few technical problems to solve...
As you can imagine, designing a standardised protocol cannot be that simple. And the above messages, if used as such, have serious security flaws.
What the protocol mainly needs to resolve are the following aspects:
- Authenticity
Lack of authenticity would mean that anyone can craft messages for anyone else's Money Button. For instance, if I (MB4070) wish for Marquee (MB271) to mute Elon Moist's account (MB2022), I would just submit a transaction containing the following message:
MB271:MUTEUSER:MB2022
This, you can find from example 6 above, where I have replaced my own MB4070 by Marquee's MB271.
A solution to this problem is using cryptographic signatures.
My Money Button wallet signs the message and appends the signature:
MB271:MUTEUSER:MB2022:H60QRuJ0Egqbb3YlUE0giRrqD6Y2+607JTmuvWrVGaAqG+OwFOm1NMB0HvkGPKgN/XzEDthmUmiIQvUpn3Nbd5A=
The key used to sign the message being tied to a wallet, any application is able to verify that the content is authentic and was published by the Money Button wallet mentioned. But in this specific case, the application will attempt to verify the signature using the message owner's public key (MB271), which will not match with the provided signature because the signature appended was faked (as I don't know MB271's private key to produce a valid signature).
Applications would therefore ignore messages that don't contain a valid signature by default.
2. Replay attacks
Another issue caused by allowing users to broadcast their own messages is the likelihood of replay attacks. If a user wishes to perform a malicious action on the application, such as liking a post more than once, he could attempt to send the following message in several different transactions:
MB4070:LIKEPOST:fe32f029b77..[TX_ID]..d2d341147d5305
This problem cannot be solved using the protocol itself, but must be solved at application level by the application's own logic. When the application pulls transactions from the blockchain and processes conflicting actions or actions that have already been performed, it needs to apply certain rules. In this specific case, the application should ignore any LIKEPOST actions from MB4070 for the post fe32f029b77..[TX_ID]..d2d341147d5305 after the first message of this kind is processed.
3. Unauthorised actions
Certain unauthorised action restrictions can be enforced at protocol-level using cryptographic signatures (similar to the authenticity case detailed above). Others must be enforced at application-level using the application's logic.
For instance, if MB271 has broadcasted the following transaction to mute MB4070:
MB271:MUTEUSER:MB4070
Then, MB4070 shouldn't be allowed (at application level) to send a private message to MB271, but the message can still be broadcasted on the blockchain:
MB4070:PMUSER:MB271:QklFMQPZFKO/PYj6JvVBzcYRhio4/UDl/a93jsRwqMi4x9SXGCT7RTKc9GW7PvvEN9qvrjkJOQtLZvUAgpKXQ2svclT4nRr0ioDJ5+yaILNzSpnq7g==
When the application processes this message, it will verify if in its own local database MB271 ever instructed to mute MB4070. If that's the case and MB4070 is still muted, then the message will not be displayed to MB271.
4. What about the other issues?
By default, what the protocol cannot handle must be handled by the application's logic. You might have thought of:
- Copyrighted or illegal content that applications need to reject
- Money Button users that do not exist in the application's database or do not exist at all
- Messages that are broken/unreadable
- Messages that contain actions that do not exist or only exist for specific apps
- Protocol version handling
- And more
I will detail some of those issues in other articles.
Benefits for the business
After playing around with Twetch and Weiblock, I now have a good understanding of the proprietary messaging protocol that they use respectively for their platform. There is good, there is bad, and there is ugly.
As an example, this is a non-exhaustive list of malicious actions that can (or could) be performed:
- Sending messages using another user's identity
- Liking posts more than once
- Posting unauthorised content-type
- Causing denial of service with maliciously crafted messages
- Stealing other users' transactions and embedding the content in a message
- Posting content that doesn't exist on the blockchain
- Underpaying fees to follow, like, post, reply, activate features and so on
Using a standardised protocol will help those platforms and similar platforms fix and avoid making similar mistakes in the future. A well-designed, universal and secure protocol can benefit all. It will also help those platforms focus more on front-end application specifics such as fancy and useful features for a better user experience. Which is what users value and why users will pay the fees for those platforms to have their messages processed there.
A standardised protocol will also help disaster recovery. Currently Twetch cannot rebuild its local database solely using blockchain transactions as certain specific actions and data are stored off-chain (in their own local database). A standardised protocol will ensure applications can easily rebuild their local database.
Finally, other applications will be encouraged to activate optional "pay PlatformX fees" options where users can choose to pay additional fees for their message to reach PlatformX: Twetch, Weiblock or any other platforms, at the same time using a single transaction.
Benefits for the users
The number one benefit for users is that they would theoretically (and if they pay the right fees) have their messages processed by more than one platform at once.
Let's say MB4721 wishes to send a message on both Twetch and Weiblock. He would simply have to mention that he wishes his message to reach both platforms (it could be as simple as a checkbox to check) and swipe his Money Button. When he mentioned he wishes his message to reach both platforms, his Money Button added an additional output to the transaction which corresponds to the fees he has to pay for his message to appear on that optional platform.
If he wants to post on Twetch only, this is how his transaction (TX1) would look like:
TX1 output1 (contains the message):MB4721:CREATEPOST:"Guys, check this blog: https://blog.bsv.sh/"
TX1 output2 (is a payment for Twetch fees):0.000078125 BSV
TX1 output3 (change)
If he wants to post on both Twetch and Weiblock, this is how his transaction (TX2) would look like:
TX2 output1 (contains the message):MB4721:CREATEPOST:"Guys, check this blog: https://blog.bsv.sh/"
TX2 output2 (is a payment for Twetch fees):0.000078125 BSV
TX2 output3 (is a payment for Weiblock fees):0.000035411 BSV
TX2 output4 (change)
Since both platforms understand the protocol, his post will appear on both. He will, however, have to pay for the correct amount of fees for each platform, as otherwise his message might be rejected (not processed) by the platform(s) for which he underpaid the fees.
This way, MB4721 is able to reach communities that prefer to use Weiblock, to receive likes, replies, followers, etc. for his content on both Twetch and Weiblock platforms. All that with a single Money Button swipe of his message.
Another benefit for users is the that there will certainly be more applications built using a universal protocol. Applications that can not only provide similar functionalities to Twetch and Weiblock, but also provide other functionalities (messaging automation) and support other platforms (native support for mobile). Applications that might not necessarily be developed by Twetch or Weiblock devs.
For users, availability of their messages and interactions is important. If one business fails, users will wish for someone to build an application to revive the social interactions. Currently this is not something that can be developed easily using Weiblock or Twetch protocols as it requires dedicating time to reverse the protocol (and debug...), build an application that processes all messages properly (something I doubt is achievable accurately due to numerous proprietary protocol issues) and finally, adapt the platform to guess unknown off-chain transactions (data stored on Twetch's own database and Weiblock own database that was potentially lost). Users would therefore benefit from a universal protocol: if one platform goes down, all their messages can effortlessly be retrieved and processed by another platform.
Finally, users will not be restricted to using one single platform. They will have the freedom to decide which one they prefer to use to interact with everyone. Which will help during downtime, but also connect people instead of being divided across communities: are you on Instagram or on Twitter? Are you on Twetch or on Weiblock?
Conclusion
This first article was an introduction to why a standardised messaging protocol can benefit us all. It was intentionally high-level and did not dive into the protocol specifics. By raising awareness about the importance of protocol standardisation due to the imminent emergence of visionary microblogging blockchain-powered applications I hope we can work together to build essential and well-designed tools our developers need.
Please give me your thoughts and suggestions in your comments. I will try to dedicate time to write the next part of this series of articles as soon as possible.
