A Hacky Guide to Hive (part 2.1) YO broadcast

in #dev3 months ago (edited)

Broadcasting

Last post, I talked about how you can get data from the blockchain.
For some applications that might be all you ever need.

But maybe you want to store something on chain.
For example: you want to make a vote:

mouthpiece.png

Python broadcast

Assuming you have Beem installed, the easiest way to vote for this post would be:

from beem import Hive 

hive = Hive(keys=['yourpostingkey'])
account = 'youraccount'

hive.vote(weight=100, account=account, identifier='@felixxx/a-hacky-guide-to-hive-part-21-yo-broadcast')

While this may be a neat example of how to do get the job done, it's not the best way to go about it.
I just wanted to come in hot and start with a working example.

Clearly you could improve this code a lot, but before that, the most important here:
For it to work, there must be a private key stored in the code itself. That's not good. That's not safe.
There are many different ways to make this safer and I will adress some, but for now:

System Design

This may be a hacky guide, but I don't want to write a shitty guide.
The first line of defence against vulnerabilities and errors is to adress them at system design level.

You could go ahead and write a long script that looks something up on chain and then reacts to events somehow and broadcasts a transaction, and loop over all this somehow...
You could automate something on chain like this. That approach works and I've seen it and done it.

If you aren't careful, you will end up with a pile of spagetthi code with your keys somewhere inside of it, though.

I am not the right guy to write a guide on system design, but I'll not just hack away, either.
I don't want to just post code snippets. I will lace in the design principles, that I have settled on.

Python limitations

Leaving design and safety aside: if you look at this stuff with only your Python hat on, eventually you will run into a wall. There are problems that are very hard or impossible to solve, if you try to do everything in a single script.

user broadcast

If you want to have users input something, Python is in most cases the wrong toolbox.

First of all: if you don't have to, you shouldn't be involved in the signing of other people's transactions. In the documentation it says:

By utilizing Authenticating services, you can eliminate or give more confidence to user, so they are assured their keys are safe. They can securely interact with your application, website or service.

So, right out of the gate: I don't want to touch anyone's keys.
And if I don't have the keys, this whole Python-side signing stuff is useless.

The good news: You can just hand over those responsibilities to a third party.
That makes your life easier and the final application safer.

Custom User Client

I need to be careful here to not overuse the expression client.
In the last post, I talked about writing your own custom client for Hive.
That was in Python, and like I wrote above, this can do a lot of things and get you quite far.

But you may also want to build your own custom user client, that allows your users to broadcast to the blockchain, without you being directly involved in signing process. In this case it is easiest to just leave the Python environment and use javascript instead.

If you want to just stay in Python, and don't plan on making user interfaces, the next part might seem useless at first. I am trying to make a point though. Please bear with me...

YO

As an example, I created a really simple game.
It only has one move: an empty custom transaction on the Hive blockchain, of the type 'YO'.

Code Example with Hive Keychain

<!DOCTYPE html>
<html>
<style>button{margin:124px;font-size:48px;}</style>
<button id="yo_button">YO</button>
<script>
let yo_button = document.getElementById("yo_button")
yo_button.onclick = () => {
    window.hive_keychain.requestCustomJson(
        null, 'YO', 'Posting', '{}', 'YO broadcast', (response) => {
            console.log(response.result);
        }
    )
}
</script>
</html>

If it all went right, you can now make a move.
Follow this url:

http://127.0.0.1:8080/yo.html

Result looks like this:

https://hivehub.dev/tx/eb025cf797ee5bc81d7399282268079cc29cc66d

Microservices

Now you have a custom user client in javascript.
It's extremely simple, but it's unique. 🦄
As far as I am aware, only I have ever made a YO on chain.
It's a minimalistic game that only I have played so far, and that has no goal, but ...works.
Maybe you want to join...

Next episode, I will demonstrate how to observe a YO live.
That will end with a YO client in Python, which I can later build a YO API on.

Don't worry! I will connect all the services later.
What I want to emphasize: Even though these services and clients can all work as parts of the same system, they each do fundamentally different jobs.
Looking up Hive blockchain data is a different procedure than broadcasting to the chain.
I will keep this stuff apart on the system level side of things.

This comes with the immediate benefit, that I can work on them separately.
I mean: the broadcasting part of the client already fully works.
Anyone can now YO in 15 lines of code.

Maybe someone wants to even upload this html to their webserver. 😬

Anyways, to build things like this is probably best described as microservice architecture.
Here's a video, that I found eye opening and entertaining. Please watch, if you haven't already.

Get and Set

If you are coming from traditional game- or web-development this might apear unusual or complicated. You might try to view these things as get and set methods; If you don't need to broadcast any other transactions than your own, you could even get away with treating it that way.

While you can access a lot of blockchain information like you would a REST API or something, A Hive broadcast is much different than a set method, though.
That may make some stuff seem more complicated, but it comes with advantages:

Authentication

If you want to build anything that requires users to have an account, you will have to enter the world of user authentication. If you've ever touched the topic before, you know how that can be a huge pain. If not, then google it. There are huge libraries dedicated to user auth, password hashing and whatnot.

Maybe all the above sounded complicated and you don't understand what I am trying to get at. Maybe you can't (at this point) appreciate, how the above demonstration entirely eliminates the need for any authentication measures on your end...

Let me tell you: It's a big deal. That just solved a big problem with no effort. You don't need any infrastructure, no user tables...
A lot of stuff just happened en passant.
I tried leveraging Keychain and Hive's protocol to do the heavy lifting.

Maybe this post explains it better.

Hive Blockchain

I will expand on all this in further posts, but for now:

Trying to build anything directly on chain (for Hive) comes at a price. It has strict limitations.
But if you stay inside this framework, you can build amazingly cheap and tight applications.
the rhymes!

I may have left a lot of threads open with this post.
I hope that with a few more posts, it will all come together.

Maybe all the above wasn't news to you.
Maybe this post was to much talking and to little action.
But I have to go over some fundamental concepts for the rest to make sense.
I'll try sprinklig in useful code examples - maybe that can keep some of you interested, or attract new readers.

Notes

  • This is a work in progress and subject to change.
    With this one, I am really not sure, if I didn't try too much...
  • I appreciate feedback - it could help me a lot, but:
    • please try to not comment 'That's not right' without further explanation.
      At least provide a link or something.
    • please don't just come up with questions just for the sake of it.
      I am trying to publish something helpful here, work with me please.
Sort:  

I was thinking to use Hive SQL instead of the python. Did you use it also?

Like I wrote in the previous post:

This is approach isn't the best for all applications; If you want to do historical stuff, analyzing large amounts of data, statistics and such things, HiveSQL is better.

It depends, on what you are trying to do...

You might try to view these things as get and set methods; If you don't need to broadcast any other transactions than your own, you could even get away with treating it that way.

For this guide, I won't use HiveSQL, no.
You could use this guide to build your own, custom HiveSQL, though...

Hope that helps.

Thanks, yeah, mostly crunching some numbers, so I will check out SQL first.