create account

A Hacky Guide to Hive (part 2.1) YO broadcast by felixxx

View this thread on: hive.blog |  peakd.com |  ecency.com
dev · @felixxx · (edited)
$17.88
A Hacky Guide to Hive (part 2.1) YO broadcast
## Broadcasting 

[Last post](https://peakd.com/dev/@felixxx/a-hacky-guide-to-hive-part-15), 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](https://files.peakd.com/file/peakd-hive/felixxx/23tRrRPGbYfyCGnXPHV7aVow71dGKnoNVAeJNDbhht5R2ZKNGeyfMk1Ds3XeSNHPgD6zA.png)

### Python broadcast

Assuming you have [Beem](https://github.com/holgern/beem/tree/master) 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](https://developers.hive.io/) 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](https://github.com/hive-keychain/hive-keychain-extension/blob/master/documentation/README.md#requestcustomjson)

```
<!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>
```
- save as ``yo.html``
- you **need** Keychain browser extension installed
[for chrome](https://chromewebstore.google.com/detail/hive-keychain/jcacnejopjdphbnjgfaaobbfafkihpep)
[for firefox](https://addons.mozilla.org/en-US/firefox/addon/hive-keychain/)
you **don't** want the SDK or anything else from https://github.com/hive-keychain
- you will have to **serve** this somehow, otherwise keychain won't work.
From **inside** the directory, which ``yo.html`` is stored in:
``python -m http.server -b 127.0.0.1 8080``
- Alternatively, in Visual Studio Code, try [Live Server](https://github.com/ritwickdey/vscode-live-server)

- For other _requests_: [The part of keychain's documentation that you actually need](https://github.com/hive-keychain/hive-keychain-extension/blob/master/documentation/README.md) 

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](https://www.youtube.com/watch?v=y8OnoxKotPQ), 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](/@brianoflondon/hive-has-the-best-log-in-and-authentication-system-on-the-internet) 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.
<sub>**the rhymes!**</sub>

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.
👍  , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , and 144 others
properties (23)
authorfelixxx
permlinka-hacky-guide-to-hive-part-21-yo-broadcast
categorydev
json_metadata"{"app":"peakd/2024.8.7","description":"Broadcasting, Hive Keychain, Microservices, YO","format":"markdown","image":["https://files.peakd.com/file/peakd-hive/felixxx/23tRrRPGbYfyCGnXPHV7aVow71dGKnoNVAeJNDbhht5R2ZKNGeyfMk1Ds3XeSNHPgD6zA.png"],"tags":["dev","hive-dev","hivedev","hive"],"users":["felixxx","brianoflondon"]}"
created2024-09-18 15:00:57
last_update2024-09-18 15:18:21
depth0
children3
last_payout2024-09-25 15:00:57
cashout_time1969-12-31 23:59:59
total_payout_value8.949 HBD
curator_payout_value8.926 HBD
pending_payout_value0.000 HBD
promoted0.000 HBD
body_length9,414
author_reputation216,289,007,274,068
root_title"A Hacky Guide to Hive (part 2.1) YO broadcast"
beneficiaries[]
max_accepted_payout1,000,000.000 HBD
percent_hbd0
post_id137,182,725
net_rshares60,052,217,949,813
author_curate_reward""
vote details (208)
@mypathtofire · 
I was thinking to use Hive SQL instead of the python. Did you use it also?
properties (22)
authormypathtofire
permlinkre-felixxx-2024918t172340216z
categorydev
json_metadata{"content_type":"general","type":"comment","tags":["dev","hive-dev","hivedev","hive"],"app":"ecency/3.1.5-mobile","format":"markdown+html"}
created2024-09-18 15:23:39
last_update2024-09-18 15:23:39
depth1
children2
last_payout2024-09-25 15:23:39
cashout_time1969-12-31 23:59:59
total_payout_value0.000 HBD
curator_payout_value0.000 HBD
pending_payout_value0.000 HBD
promoted0.000 HBD
body_length74
author_reputation606,099,559,725,191
root_title"A Hacky Guide to Hive (part 2.1) YO broadcast"
beneficiaries[]
max_accepted_payout1,000,000.000 HBD
percent_hbd10,000
post_id137,183,090
net_rshares0
@felixxx · 
Like I wrote in the [previous post](/@felixxx/a-hacky-guide-to-hive-part-15):

>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.
👍  
properties (23)
authorfelixxx
permlinkre-mypathtofire-sk0lsl
categorydev
json_metadata{"tags":["dev"],"app":"peakd/2024.8.7"}
created2024-09-18 15:31:39
last_update2024-09-18 15:31:39
depth2
children1
last_payout2024-09-25 15:31:39
cashout_time1969-12-31 23:59:59
total_payout_value0.000 HBD
curator_payout_value0.000 HBD
pending_payout_value0.000 HBD
promoted0.000 HBD
body_length619
author_reputation216,289,007,274,068
root_title"A Hacky Guide to Hive (part 2.1) YO broadcast"
beneficiaries[]
max_accepted_payout1,000,000.000 HBD
percent_hbd10,000
post_id137,183,211
net_rshares36,413,086,738
author_curate_reward""
vote details (1)
@mypathtofire · 
Thanks, yeah, mostly crunching some numbers, so I will check out SQL first.
properties (22)
authormypathtofire
permlinkre-felixxx-2024918t1734466z
categorydev
json_metadata{"content_type":"general","type":"comment","tags":["dev"],"app":"ecency/3.1.5-mobile","format":"markdown+html"}
created2024-09-18 15:34:03
last_update2024-09-18 15:34:03
depth3
children0
last_payout2024-09-25 15:34:03
cashout_time1969-12-31 23:59:59
total_payout_value0.000 HBD
curator_payout_value0.000 HBD
pending_payout_value0.000 HBD
promoted0.000 HBD
body_length75
author_reputation606,099,559,725,191
root_title"A Hacky Guide to Hive (part 2.1) YO broadcast"
beneficiaries[]
max_accepted_payout1,000,000.000 HBD
percent_hbd10,000
post_id137,183,240
net_rshares0
Help/Feedback