safe means that the string will not be escaped by the template engine: https://djc.github.io/askama/filters.html#safe

Since you are always setting the value from the filter (trusted source) this is fine here.

Could be refactored

something like

let matches = [
    ("736f6c6f706f6f6c2e6f7267", "solopool.org"),
    ("7370622e78797a", "p2p-spb"),
];

for &(str_to_match, str_to_show) in &matches {
    if coinbase_string.contains(str_to_match) {
        let output = html! {
            str_to_show
        };
        return Ok(output.into_string());
    };
}

Having to maintain two lists of miners in two different codebases is a bit annoying, but I'm not sure how we could keep the miner parsing in a single place and make it work for both js and rust code. I can think of a few ideas, but it would all take some work and we are not getting new miners very often, so not sure if the extra effort would pay off vs just maintaining the logic in two places in the foreseeable future.

this says Mining-Dutch in hex?

I think all this hex makes it very hard to read / maintain this code (and there's already an issue in the comment above). Instead, I think it makes more sense for each miner to use a regex, like this: https://docs.rs/regex/latest/regex/bytes/struct.Regex.html#method.captures

Since each miner has a relatively simple condition, this seems like a better approach.

For example, the regex for ViaBTC could be (not tested as I don't have an example coinbase):

use regex::bytes::Regex;

let reg_viabtc = Regex::new("ViaBTC(.*/Mined by (?P<mined_by>\w+)/)?")?;
if let Some(captures) = reg_viabtc.captures(coinbase_data) {
   if let Some(mined_by) = captures.name("mined_by") {
      return Ok(format!("ViaBTC | Mined by {}", String::from_utf_lossy(mined_by.as_bytes())));
   }
   return Ok("ViaBTC".to_string());
}

safe means that it's HTML safe, but since miner data (e.g. for ViaBTC) could be anything this likely could be used inject HTML; the safe should be removed

yes, this is much better. I didn't think this would work since coinbase data can sometimes parse with crazy stuff in utf8 (line breaks, unknown characters, etc).

In testing, it works.

nice, much cleaner approach thanks

could keep these vectors in an array. but, since they are long and must be manually formatted to meet line break requirements, I think it is easier to maintain / read in this "one at a time" format.

There's regex::bytes::Regex for exactly this, regex::Regex indeed wouldn't work.

A bump to 1.79 was attempted recently (D16361) and was not successful (it was breaking the windows build).
I think this should be this own diff if needed. I would advise against doing it in that diff or make that diff depend on the new feature because it can be more difficult that you think to change the version.

I'm not sure what you mean—this just changes how the code has the test data written; my suggestion is that instead of having it in hex to have it as byte string literal instead. The way I converted them was via python:

>>>bytes.fromhex('0378120c182f5669614254432f4d696e6564206279203236303738362f103b6fa20ff3648a69acc31ed9b4946c00')

b'\x03x\x12\x0c\x18/ViaBTC/Mined by 260786/\x10;o\xa2\x0f\xf3d\x8ai\xac\xc3\x1e\xd9\xb4\x94l\x00'

ok cool. I don't have any insight or preference to what is here, just what I happened to find first that led to passing tests.